Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
Already have an account? Sign In »
4 hours 53 minutes
welcome to a new module involved Fundamentals.
If you think back when we started our discussion about vault and having an overview, there were three key capabilities that we talked about
there was storing static secrets.
There was generating dynamic secrets. And then finally, there was encryption as a service, and we've covered two of those three pillars thus far in this module. We're gonna expand on the encryption as a service capabilities that vault has.
And we're gonna do this by exercising those capabilities themselves and their provided Visa vee, the transit secrets engine.
We're gonna perform encrypting decrypt operations using that transit secret engine.
We're gonna talk about ways to handle the rotation of the underlying encryption keys that engine itself is using to perform those encrypt decrypt operations. We're gonna manage some keys generated and the retrieval of those keys.
And finally, we're gonna use this engine to verify encrypted messages have not been tampered with by any third parties.
In this specific video, we're going to review the value of the transit Secrets engine.
We're gonna enable the transit secret engine on our own. Dev server. We're gonna generate an encryption key. We're gonna encrypt a simple message. And then we will decrypt a simple message.
Here we have, ah, simple diagram provided by Hash Corp
And if you recall some of the main motivators behind, using the encryption as a service is one. It's hard to do correctly. Yes, there's lots of libraries and things of that nature, but sometimes the devil's in the details and you miss a key point or your developers miss a key point.
They may overlook things and not do the encryption properly.
Additionally, if you're doing the encryption decryption in the applications themselves directly, those applications need direct access to the keys that are used to perform these different encrypt decrypt operations. So that means you have to worry about distributing the underlying encryption keys that are basis for which
the operations are taking place.
However, if we look at this diagram, we could see a simple use case where we have sensitive data.
Let's say we have a program IQ programmatic process that then reaches out to vault, sends the sensitive data to vault over secured channel, of course
and vault, using the keys that it itself a storing takes that sensitive data, encrypts it and then returns the cipher text the encrypted version of that sensitive data.
Subsequently, the sensitive data in cipher text format that will then be persisted to some sort of, ah, database, some sort of a storage bucket. Something of that nature. For long term,
you might think to yourself, Well, we enable encryption in our database so the data itself, when it's at rest, it's encrypted, and that's great. But the problem can arise quickly is if you have, say, the credentials for connecting to that database. Leak somehow,
and you have, ah, bad actor that has the sequel
authentication credentials. They can connect to that database. They run some sequel queries all of a sudden there retrieving all that data. So while the underlying files persisted in storage, are encrypted
the data when its load up from the database isn't encrypted. So there's a common use case where particularly sensitive data points, whether it's a relational database and no sequel, document based Bay database like Mongo DB. There certain attributes we don't even want to have those be visible to the database itself
in an unencrypted format. We want that encrypted, so when the database is up and running,
it's decrypting all of the Persisted files.
But the value for some of those attributes that itself is encrypted and is really adds an extra layer when you have highly sensitive, personally identifiable information ph i personal health information or other things like purchase transactions and, of course, credit card numbers.
All of these capabilities take place using vaults. HTTP. A p I,
and it's quite scalable to if you get a vault cluster in place. We're talking about handling 15 to 20,000 requests per second. That's a lot of encryption and decryption operations that you could be performing.
And even though all this stuff is done through the A P, I were going to be working with Web interface for simplicity to exercise these different capabilities as a first step. Go ahead and start the vault server in dev mode if it's not already running. And of course, we want to get a copy of the route token,
we're gonna navigate over to the Web, you y for the rest of this particular lesson,
and we need to get the transit secrets engine going. So let's do this through the Web. You I enable a new secrets engine. Here's the transit secrets engine. That's what's gonna do. We can change the path. Of course, the default is transit. Let's call this encryption as a service, and that will be the Mount Point
with secrets engine enabled. We need to create an encryption key.
Let's stick with that good old James Bond analogy and in this case will call this the, um
I don't know. We'll say this is This is Ah,
the M I six encryption key.
Okay, you can specify the different types of encryption keys you want to use. I'm gonna stick with the default here. Now we have an encryption key. We've enabled the transit secrets engine. So let's take some actions using this key.
What are these things we can do? Well, the first we can do is encrypt. So Well, let's say this is a secret message for James Bond.
all of the encryption text when when you send it to vault needs to be in base 64. So the space characters this kind of stuff doesn't work. The web you I provides. It's a nice easy button to base 64 encoded. If you were using command line interface or some sort of programmatic AP. I want to make sure that any data you send into vault
that you want it to be encrypted. That data itself is in base 64 encoding.
And as I'm sure you're familiar based 64 itself, it's not encryption. It is simply encoding because you don't need any special key to encode or decode contents using base 64.
So I'm gonna encode this in base 64 I'm gonna move forward and encrypt and will copy this off to the side. Now, let's go ahead and decrypt this message. So here we have the cipher text going. Teoh, make sure we've pasted this in
and let's perform the decrypt operation.
And the decrypt just gave us the value, but it is encoded in base 64. So let's run the decode from base 64. And sure enough, there it is. The secret message for James Bond.
So this would give you a simple taste of the most fundamental encryption and decryption as a service capability that vault Brinks for the remainder videos in this module. Please keep your local vault deaf server up and running.
This way, we don't have to go through the process of re enabling the transit secrets engine and resetting a new key. We're just going to continue to use this m I six key.
And just to recap, we talked about encryption as a service. Why you'd want to do it, how it can scale some of the benefits we went through and enabled the Transit Secrets engine, which is the encryption. As a service provider involved, We created a special key for M I six. We then encrypted a message using that special key,
and we decrypted that message using the same key.