[zackmorris]

I've dabbled in dev ops in recent months and found that setting up AWS services is relatively straightforward. Although for anyone reading this, do yourself a favor right now and learn to automate the manual steps with something like Terraform or you'll most likely never get anywhere in any reasonable amount of time.

I found IAM to be an anti-pattern. I grew up on the Mac in a sandboxed, single-user environment with no console. And I've always approached roles and permissions as something that should be backend-only. So for web hosting, it should be host-only and not exposed to the customer.

So to me, a service like VPC should have created a sandbox that handles IAM internally. It should have provided the customer with all AWS services exposed (even oddballs like SES) in that sandbox only (not accessible from outside) similarly to how managed hosting worked a decade ago.

Basically IAM feels like hand waving to me. Few insights can be gleaned by looking at the roles and permissions by eye. So I would argue that most AIM setups as they stand now are probably insecure.

The way it should probably work is, the customer would set up a series of access tests that run similarly to Postman and exercise the infrastructure the way that something like Dredd does with Swagger or API Blueprint. They would "prove" the permissions ruleset by traversing the AWS infrastructure, telling you which ones to add/remove.

So conceptually, I think that the article or something similar is how IAM should have worked in the first place. Thought I'd use this opportunity to ask any dev ops people about this, because it feels like I'm missing something fundamental here. Any approaches to formally proving that IAM roles and permissions are secure would be greatly appreciated!

[rasguanabana]

On one hand you have people setting wildcards in IAM policies for development phase (and forgetting to close them down afterwards). It’s hard to figure out permissions beforehand - this would help in these cases, but still taking IAM setup deduced from your traffic does not mean this setup is secure.

On the other hand you have complex architectures and no real overlap in their authorization patterns. It’s impossible to automate creation of secure "sandbox" setup for your specific use case.

You can’t really delegate security of your architecture to a single service - you need to address it yourself. Security can be implemented only in the service, not as a service.

[zackmorris]

Ya I've done that hah. I think an ok plan might be to set up infrastructure with open IAM rules and write all of the backend and frontend acceptance tests for an app. Then close all IAM rules and open them one by one until all of the tests pass again.

Maybe AWS could provide a way to track access attempts and then have an interface for the user to grant them one by one. I understand that this might be challenging to design, but I view these sorts of challenges as the "real work" of computer science, otherwise there's just nothing there.

I encounter that a lot when I have a preconceived notion of the heart of a strategy (including edge cases), only to find that it wasn't addressed, and in fact wasn't even mentioned.

Yes these things are hard, but Amazon has billions and billions of dollars.

[musingsole]

This is a thriving service market at the moment. DivvyCloud is an example: https://aws.amazon.com/solutionspace/financial-services/solu...

[thrixton]

I do wish AWS made it easier to view and debug permission errors. It should be possible with Cloudtrail but I've never found a quick and easy filter that would show denied errors so I can add the requisite permissions. Even better if it presented a policy with the permission present. MS has a decent system with their graph API explorer [1], where it will show you what permission is needed and has the ability for you to grant that permission on the Web UI, this is a step in the right direction.

[1]https://developer.microsoft.com/en-us/graph/graph-explorer

[uzakov]

Hey! So to touch on a couple of points: Scott Piper is probably one of the most known AWS sec experts, check out his websites. https://summitroute.com/blog/

"Any approaches to formally proving that IAM roles and permissions are secure would be greatly appreciated! " Are you looking for a way to see that you have set up your policies correctly?

[zackmorris]

Ya after writing it, I think what's going on is that I do everything declaratively now. So it's great that AWS lets us create the AWS policy files rather than making us manage permissions through code.

But I want to see the infrastructure as a big spreadsheet, turn on a policy, and see the accessible services highlight. basically I need something like an acceptance/integration test that proves that my permissions work like I think they do.

Without something formal like that, I can't help but feel that IAM is risky to rely on alone. To the point that, I would be wary of using it, and even view it as more of a liability than a useful tool. This is really a general conceptual issue with the abstraction of roles/permissions from a computer science perspective. My gut feeling is probably that the general authentication-based logins of the open internet and circles of trust are better mechanisms for securing services. That said, I do really appreciate that we can reference security group ids in new security group rules. Once I started chaining the references like that, and having subnet rules in a central place, things worked more smoothly.

I would never use roles/permissions for new development though is what I'm trying to say (whether for web development or web hosting). I don't think it makes sense to screen access by which network was used, or the source IP of the user trying to gain access. These are somewhat antiquated notions that make sense for sysadmins, but I don't think they make sense for the vast majority of use cases that web developers encounter. We could just use the open web's CLIENT_ID=abc, CLIENT_SECRET=xyz pattern for all AWS services. But maybe there's some advantage with roles and permissions that I'm not seeing.

Sorry I come off as Negative Nancy, but this issue really concerns me, and I don't see much talk about it on sites like Stack Overflow.

[Terretta]

Pull this thread...

Zelkova uses automated reasoning to analyze policies and the future consequences of policies. This includes AWS Identity and Access Management (IAM) policies, Amazon Simple Storage Service (S3) policies, and other resource policies. These policies dictate who can (or can’t) do what to which resources. Because Zelkova uses automated reasoning, you no longer need to think about what questions you need to ask about your policies. Using fancy math, as mentioned above, Zelkova will automatically derive the questions and answers you need to be asking about your policies, improving confidence in your security configuration(s).

https://aws.amazon.com/blogs/security/protect-sensitive-data...

Maybe start at Provable Security: https://aws.amazon.com/security/provable-security/

[uzakov]

Dont worry, I didn't feel that you were a "negative nancy" :)

> "But I want to see the infrastructure as a big spreadsheet, turn on a policy, and see the accessible services highlight. basically I need something like an acceptance/integration test that proves that my permissions work like I think they do."

This problem can be solved by having your infrastructure etc as Terraform templates, and writing unit tests for those. Additionally you can use 3rd party solutions, depending on what you mean by "see the accessible services highlight"

> " I don't think it makes sense to screen access by which network was used, or the source IP of the user trying to gain access."

I would say this is additional thing you would do, but not the only.

> "But maybe there's some advantage with roles and permissions that I'm not seeing."

Let me/us know and maybe either me or someone else can help you. Hopefully my message didnt come as condescending. PS I dont work for AWS