CMK Key Policy and FSx Windows Self Managed

Question

Trying to understand the role a CMK can play in protecting data.  Obviously one layer of protection is the ACLs we use to lock down folders on our FSx share by allowing only certain AD users/groups read, write permissions etc.

What role does the CMK key play?  Can a policy on that key for that file system add a second layer, disallowing some AD users (federated roles) to decrypt etc. ?  My initial testing with a CMK key policy on an FSx file system doesn't seem to bear this out.  Hope my question makes sense.

Thanks

Answer

Hi,

ACLs and CMKs address two different aspects of security. ACLs provide access control, to say who can do what actions on the given resource.

Key Management and CMKs are used for encryption of data at rest. Which means, even if someone has access to the data, can they still make sense of it. Encryption happens at two different layers, AWS service layer and the user layer. Services like EBS, S3 can use KMS keys for encryption of data that is being written into the service. So, even if someone did accidentally have access to the physical media, they'd still not be able to decipher it. However, as a user, the encryption would be transparent to you as the service would decrypt the data before returning it to you.

You can also use CMKs for client side encryption. In this case, you encrypt the data before you write it to the service. So, let's say, you use KMS to encrypt some fields before writing them to a database row. In this case, the database administrator will not be able to read the data. This is often a requirement for workloads with regulatory requirements. You could further use IAM policies to control access to the KMS APIs to decide which user/role is allowed to do the encryption/decryption operation. In this case, if an application is running in EC2, you can use instance roles to grant permissions to the code to invoke the KMS APIs.

Hope that helps!

CMK Key Policy and FSx Windows Self Managed

Relevant content