Created
July 22, 2022 20:04
-
-
Save marcinantkiewicz/75b97b2290710862d6d469c9caad9da9 to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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