Grokking all of that is a massive undertaking, but it really NEEDS to be done by anybody deploying critical systems on AWS. I wish they would go so far as to require some confirmation that the security docs were reviewed before being able to deploy to a particular service. At least in cases where PII is involved, it’s not optional in many jurisdictions to ignore them.
Sure that UX could hurt adoption, but wouldn’t it ultimately boost retention? Success with a cloud IT org means nothing breaks and nothing leaks. Part of helping customers succeed is helping them not to fail to the point of catastrophic business risk. How many billions of private records have been leaked from S3 or ElasticSearch because of simple, detectable, preventable misconfiguration.
AWS provides a number of security and compliance services today- for a price. They would do well to suggest sane defaults like they do with a default VPC.
I think you're confusing what the default VPC actually is. Most people would consider it anti-pattern. Back in the days the concept of a VPC didn't exist in AWS, so when it was introduced they also introduced the concept of a default VPC for new accounts. All new resources was created into by default in order to make it easier for people to keep working as they were used to.
It only has a single subnet for each availability zone, which is connected to an Internet Gateway, effectively granting all resources with a public address assigned to it Internet access. That combined with the default security group was a recipe for unintended consequences.
One thing I'd recommend is reading up on the Well-Architected Framework[0]. It approaches all the essentials in AWS and will likely save people from reinventing the wheel badly. There are aspects of the Well-Architected Framework that I don't follow, but those aspects become very clear when you understand what they're trying to make you do with it.
This is where many folks don’t understand enterprise. The tech has gotta work but it shouldn’t impact the business in a negative way either. This is why out of the box, no vendors are perfect for us in the banking world because they just don’t get it yet and hence, kicks off a huge wave of customisations just to get it up to an enterprise security standard.
You have to use IAM, but if you're feeling particularly rebellious then you can setup one Admin account and one API account with liberal permissions and never touch IAM again. For obvious reasons it wouldn't be recommended...
I know that you said "For obvious reasons it wouldn't be recommended..." but for anyone else reading please do not do this under any circumstances. If any of your applications get compromised the attacker will have full control of your entire AWS account.
Can you please share those tweets? IAM is kind of a critical piece in AWS Security :) What comes to mind is perhaps people recommending to use IAM Roles instead of IAM Users. (which has a lot of benefits, these are temporary credentials and you don't need to pass things as env vars / config files etc, lowers the risk of accidentally pushing creds to source code etc)
IAM is going to be "required" for the root account, though, shutting that away is a good practice.
In lieu of IAM you can use federated access from an identity provider like Okta. That will lease a role which can then adopt other roles (even across accounts). Okta is integrated with a more formal IT system like Active Directory and then all your accesses and identity can be managed by them. I think this is the AWS side doc for the setup https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_pr...
Now I understand - you are talking about IAM users versus assumed roles, instance roles, and the like. Definitely a best practice to utilize those over IAM users but you never get away from IAM entirely, its the corner stone of all access control within AWS. Difference is that with assumed roles and similar you get short lived credentials that need to be renewed periodically (usually behind the scenes) whereas IAM user credentials exist until you remove them (though best practice is to rotate them periodically.) There are some instances where you can't get away from them easily - remote access to S3 buckets is a biggie, even though I can get assumed role credentials through my identity provider, I've yet to find an S3 client (besides the cli) that can utilize them. Access to SES for applications that need raw SMTP credentials from an IAM user. My CDN can make requests to S3 buckets with AWS v2 signatures, that needs IAM user credentials also (though the actual policy is limited to the buckets with public content and only getting known objects, no listing).
Sure that UX could hurt adoption, but wouldn’t it ultimately boost retention? Success with a cloud IT org means nothing breaks and nothing leaks. Part of helping customers succeed is helping them not to fail to the point of catastrophic business risk. How many billions of private records have been leaked from S3 or ElasticSearch because of simple, detectable, preventable misconfiguration.
AWS provides a number of security and compliance services today- for a price. They would do well to suggest sane defaults like they do with a default VPC.