Configuring AWS Identity and Access Management is typically seen as the customer's responsibility for security. This is predicated on the "shared responsibility model" where security and compliance responsibility is shared between the cloud provider (AWS) and the customer.

We believe that the "shared responsibility model" comes with certain assumptions. We assume that the cloud provider provides clear instructions for how to use their tools and to configure infrastructure. Part of that assumption is that IAM actions and permissions are clear and unique. What would be the point if we block 1 IAM action only to find that there's another we missed (similar to a game of whack-a-mole).

In this talk, we've go through increasingly potentially problematic examples of duplicitous IAM Permissions: permissions that effectively let us achieve the same goal. These examples include retrieving data, setting permissions (resource-based policies), and more. We'll cover impact and how these leads to blind spots in security including our monitoring and alerting defenses, preventative issues, and more.