Hacker News new | past | comments | ask | show | jobs | submit login
AWS Security Maturity Roadmap [pdf] (summitroute.com)
78 points by sciurus 18 days ago | hide | past | favorite | 7 comments



I do feel I should know this - but is there a good "low level" explanation of how SSO / 2FA / Cloud providers should work - all the docs seem to be "how to" not "this certificate is used to perform this action which then ...

I am slightly shocked by the number of seemingly incompatible ways to secure our new cloud environments and want to look around before i throw out authid

Just as part of what I am trying to read around on::

The "dynamic secrets" feature of Vault is ideal for scripts: an AWS access key can be generated for the duration of a script, then revoked. The keypair will not exist before or after the script runs, and the creation of the keys are completely logged.

This is an improvement over using something like Amazon IAM but still effectively hardcoding limited-access access tokens in various places. https://www.vaultproject.io/docs/use-cases

Now I like that idea ... but where does it sit on the spectrum of good and bad?


> an AWS access key can be generated for the duration of a script, then revoked. The keypair will not exist before or after the script runs, and the creation of the keys are completely logged

I'm not totally sure what your goals are, or the overall context, but a few issues with this approach:

You can only create these access keys for IAM users, and each user can only have two keys at a time. So if you're using this as a "service account", you pretty much have to have an IAM user for each task. If you need to scale to 100 concurrent tasks, that's either going to take up 50-100 IAM users (from your limited quota) or you're going to have to figure out some other scheme for managing lifecycle of access keys.

Instead, just use IAM roles and sts:AssumeRole into the role. You can sts:AssumeRole as many times as you want, there is no limit to how many 'tasks' you can have assuming the same role at a time. Credentials from sts:AssumeRole are inherently time-limited (and you can set a tighter expiration than the default) and you can additionally constrain what the resulting credentials can do with the `policies` or `policyarns` parameter. The role assumption is logged and you can impute the expiration of the assumption from the sts:AssumeRole event (because it either includes the DurationSeconds parameter value or you can assume the default).


We've used this roadmap at my company and it's been extremely useful. When others ask me for advice on AWS security this is the first thing I send them.


Does anyone have the LaTeX version of this, the presentation of the text is very well-organized.


Author here. Thank you. I haven't made the repo for this doc public, but the LaTeX setup is based on an older document of mine here: https://github.com/0xdabbad00/research/tree/master/emet_unco...


Thanks!


Great resource, will be using this as a blueprint for getting our AWS environment up to code




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: