You've seen how MongoDB combines master keys and data encryption keys to secure your data. Now it's time to put that knowledge into practice and enable encryption at rest on your deployment. To do this, we'll start by reviewing what a key management system and the key management interoperability protocol are. Then we'll discuss what it means for a KMS to be KMIP compliant. After that, we'll explore how to enable encryption using a KMIP server. Finally, we'll verify that encryption at rest has been successfully implemented. Let's get started. In order to enable encryption at rest, we first need to have a KMIP compliant KMS. KMS or a key management system is used by organizations to securely manage their keys. Security keys can get unruly, and it's crucial to be able to create, store, and manage them. A forgotten key that lands in the wrong hands can have devastating consequences. When choosing a KMS, we have multiple options. AWS, Google, and Azure all have their own key management services. You also have the option to set up your own. Setting up a KMS for a master key is beyond the scope of this video. To learn how to set up a KMS, check out the documentation of the provider that you choose. It's also important to know that the KMS that you choose must be KMIP compliant. The key management interoperability protocol is an open standard for exchanging cryptographic keys and operations between key management systems and clients. KMIP standardizes key management tasks like creation, deletion, and retrieval, ensuring interoperability across different vendors. KMIP is useful because it allows a database system like MongoDB to seamlessly integrate with a third party key management service to securely manage encryption keys. So when you use a KMIP server as a KMS to store keys, for example, your team can manage those keys the same way across different systems, streamlining security compliance and avoiding the time consuming task of handling encryption keys by hand. Now let's look at how to set up encryption at rest for a self managed deployment. For demonstration, we'll be configuring encryption at rest on a fresh replica set with no existing data on it. If you wish to encrypt existing data on a replica set that is in use, this process is a little bit different. This is because you'll need to enable encryption for each member in the replica set by performing a rolling initial sync. Let's talk briefly about a rolling initial sync. Performing a rolling initial sync involves stopping one replica set member at a time, deleting all data files, and enabling encryption at rest for that member, restarting it, and then allowing it to perform an initial sync to replicate data from the other replica set members. This process would then be repeated for the other members. This ensures that the encryption process is handled correctly and does not corrupt or interrupt the replica set's functionality. To learn more about how to encrypt data with a rolling initial sync, visit MongoDB's documentation. In this demonstration, because the replica set that we're using doesn't contain existing data, all we need to do is update the MongoDB configuration file for each member. To enable encryption at rest, we first specify the security option. Under the security option, we set the "enableEncryption" option to true. This option enables encryption for the WiredTiger storage engine. It must be set to true in order to pass in encryption keys and configurations. Next, we specify that we are using a KMIP server. Under this option, we need to provide some information regarding the server so that MongoDB can authenticate and securely retrieve the keys needed for encrypting data at rest. The "keyIdentifier" identifies the key to use as the master key. If left unspecified, MongoDB requests that the KMIP server create a new key to use as the system key. Next, we specify the "serverName" of the KMIP server that stores the key. We can use either the host name or IP address of the KMIP server to connect to. You can specify multiple servers as long as they are separated by a comma. TLS requires that the server name must match the subject alternative name and the certificate presented by the KMIP server. If it does not match, the MongoD process will not start. Then we provide the "port" of our KMIP server is running on. Next, since we'll be exchanging information between the server that runs the MongoD process and the KMIP server, we'll need to make sure it's secure. To do this, we need to provide the path to a "serverCAFile" and "clientCertificateFile". These files are located on the MongoD server. If you need a refresher on this, check out our skill badge on network encryption. Finally, we'll provide the challenge password for our client certificate. With that complete, we have enabled encryption and pointed MongoDB to our master key, which resides on a KMIP server. But we also need data encryption keys to encrypt and decrypt data stored on disk. So where are they? Good question. The data encryption keys are created and managed by MongoDB when encryption is enabled, meaning we don't have to do it ourselves. Now we just need to restart the MongoD process so it can use the new configuration. To verify if it's working, we can check the MongoD logs for messages signifying a successful connection server. Keep in mind, you'll need to repeat this configuration process for each member in your replica set. Awesome work. Now that you know what encryption at rest is and how to configure it for MongoDB, try it out on your own MongoDB deployments. Before you go, let's quickly recap what we learned in this lesson. First, we learned that in order to configure encryption at rest, we need a key management system that is KMIP compliant. KMIP, the key management interoperability protocol, standardizes key management tasks like creation, deletion, and retrieval, ensuring interoperability across different vendors. After that, we configured a fresh replica set to use encryption at rest. Finally, we used the MongoD logs to verify that we were indeed connected to our KMIP server and our data was encrypted.