Skip to content

Instantly share code, notes, and snippets.

@marcinantkiewicz
Created July 22, 2022 20:04
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save marcinantkiewicz/75b97b2290710862d6d469c9caad9da9 to your computer and use it in GitHub Desktop.
Save marcinantkiewicz/75b97b2290710862d6d469c9caad9da9 to your computer and use it in GitHub Desktop.
ASAP
* No IAM users, the exceptions are cases where username/password is a requirement that cannot be changed.
* Users login as roles, it OK to start with * for Action and Resource
* Role policy requires MFA
* use aws-vault
Practices/functionality to adopt soon
* create org structure
* terraform (or similar)
* account per project/environment
* use SCP to limit what can be done in child accounts
* enable cloudtrail, flowlows, guardduty
* log into security account
* unless API limits are a concern use param/secret store for service credentials
* maybe: use KMS to allow access to infra (s3) but not the contents
* careful with managed policies, esp footguns such as read-only policies allowing access to s3 content.
* learn how to troubleshoot access issues from CF logs
* something like SSM session manager for access, at minimum bastion + ssh ProxyJump
* aws config
* Security Groups with minimal permissions close to the service config, where they are easy to maintain.
* Collect logs, see if Athena+logs in S3 is worse than what you have
* use privalink to avoid routing out to AWS APIs from VPCs that do not require it (vpc service endpoints)
* modularize AWS services in (terraform) and use modules to ensure that necessary config is in place
SCP to adopt
* deny access via root user
* limit services and regions
* force cloudtrail, guardduty, log into sec account
* probably: strict control over public S3 buckets, and s3 in general
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment