The triangle says Confidentiality, Availability, Integrity.

While your concerns are 100% valid, we need to remember too that setting up access in restricted ways and inviting users to understand the protection and remove the correct barriers, or implement the concerns necessary to interact with those for themselves, always runs the risk that some users will find your protections cumbersome and instead find a (totally incorrect) way to baffle them, or otherwise even route around them entirely mooting any efforts to secure a platform.

And every time I hear this played out in conversation, the answer is "that's on them!" But it's clearly a balancing act, it's a trade off; tautologically, when you make the service less accessible then... it is, well, ... made less accessible.

Besides facilitation of the secure access also sales conversion ratios will depend on that accessibility. The crux of your argument stands, the defaults are too open, and we need to do more to ensure that naive users aren't handed a loaded gun to aim at their own feet.

A classic one is chmod 777 for "fixing" Linux issues.

Especially once you couldn't just login as root anymore in many distros.

Uhm.. in the AWS i've used, it's on explicit allow, and all of their docs and tutorials start with IAM and what's needed and why. What more do you want? I can't imagine IAM being simpler while being as granular as it is. You just have to actually take the time to learn about it, like every system. It's still drastically easier to use it securely than doing something on a similar scale and detail manually.

> What more do you want?

The hard part for me is figuring out how to disable access without breaking everything. I know it’ll be useful once I understand and I’ll take the time I need to learn it, but most people won’t.

I prefer the opposite learning direction. Start closed and open the 1 or 2 things I need instead of having to understand 1000 things immediately to configure permissions reasonably.

Have you tried Access Advisor in AWS IAM? It’s been out for a few years now and is specifically targeted at using “... last accessed information to refine your policies and allow access to only the services and actions that your entities use.”

Can you explain how IAM doesn’t work well with the “starting closed” approach? IAM authorization is “default deny” and every principal needs an explicit allow statement with the appropriate action before authorization will pass.

I’ll give it a try. Thanks!

> Can you explain how IAM doesn’t work well with the “starting closed” approach?

It works ok once you do a lot of learning and read the best practices. I think a lot of people will skip that and use their root account for everything.

The biggest mistake I made was creating an admin user, but giving it too many permissions and using it like a normal user.

After learning more I use the root account to make an admin account, but I think the admin account should only use IAM to create other fine grained users.

So it works fine, but I think it would be better to force people into creating those first couple of accounts with permissions chosen by experts. It’s too easy to jump right in and start using an over privileged account.

You can use AWS Accounts like microservices. The biggest security walls in AWS are the account barriers. Those have to be specifically configured to cross. Sometimes (1%) its unavoidable, but if you have multiple services running on an account, you force yourself to weave arcane webs of IAM permissions crisscrossing all over to get what you need where. It's a terrible model that people inflict on themselves because it's how everything used to work.

Spinning up your own DB instance is also "open by default" and takes both effort and expertise to secure properly. I think it's pretty reasonable that there's a large surface area of IAM permissions when AWS offers a vast number of disparate services.