KMS key per application or per service

0

I’m trying to figure out the best approach when deploying applications and encrypting them with KMS. All deployments will be done via code.

Is it best practice to have a key per service? Would it be overkill to have a key per application, per service?

example :

One Key Per-Application • Application – SWG-Archive • Key: Alias/SWG-Archive • One key to encrypted EBS , S3, File gateway

Many keys per application • Application – SWG-Archive • Key: o Alias/SWG-Archive/S3 o Alias/SWG-Archive/ebs o Alias/SWG-Archive/file_gareway

Which is the best approach.

demandé il y a 2 ans1365 vues
1 réponse
0
Réponse acceptée

Hi,

I don't think there is a 'one size fits all' answer here. I think you need to think about: -

  • Account strategy - are you separating by environment, application, business unit, scope of external accreditation (e.g. PCI-DSS)
  • Who's developing / administering the applications (one team, multiple teams etc.) and whether it's being done via shared tooling, separate tooling etc.
  • How highly you want to separate your data

I wouldn't personally suggest you create a central KMS account and then share the keys out from there in a large environment. It's complex from a permissions point of view and in very large environments you could end up with throttling issues.

You also want to think about the costs of KMS. There's a cost per key, and also the way you use KMS in services like S3 can significantly impact the cost of KMS API usage.

There's an AWS best practice guide to KMS that might be useful to you here.

I'd be inclined to go for one key per application, rather than a shared key per service, or multiple keys per application, unless you're specifically trying to do something different with the data and want to limit the rights to a certain area (e.g. archive) using both IAM permissions as well as limits on what can be done with the keys, yuor application uses different classifications of data that you need to treat differently (different algorithms, being backed by a HSM etc.) or using different purposes (e.g. encrypt / decrypt versus sign/verify).

Mark

répondu il y a 2 ans
  • Thank you for your very detailed answer, the question was very open-ended but you have helped a lot. The links you provided for further reading were very useful as well :) .

Vous n'êtes pas connecté. Se connecter pour publier une réponse.

Une bonne réponse répond clairement à la question, contient des commentaires constructifs et encourage le développement professionnel de la personne qui pose la question.

Instructions pour répondre aux questions