Unified Authentication and Authorization Mechanisms

The security mechanisms that define and manage identity and access management are among the most critical parts of an information security program. They serve to ensure that only authenticated principals (users, roles, groups, applications, and other identities) are authorized to access the targeted resource in the manner intended and with least privilege. A major feature that many organizations strive for is unified authentication across enterprise services. This feature allows for identity validation that is applicable to the entire portfolio of services. Executing on this functionality is difficult especially when dealing with diverse systems that require custom credential formats or have incompatible authorization models.

With AWS, customers gain the ability for unified authentication and authorization across all AWS services to enforce least privilege. AWS Identity and Access Management (IAM) allows customers to authenticate to any AWS service using the same credential format. IAM supports multiple means of authentication, including console-based user passwords, and federation using external identity providers. Customers can configure the modes of authentication in IAM to require multifactor. AWS enables customers to control access to their resources in AWS services using policy-based authentication mechanisms. Each policy is populated either by the customer or by AWS, if using AWS managed policies, with definable elements that work together to construct granular and conditional “allow” or “deny” actions on particular resources. Customers can share or reuse policies across identities both within and between accounts, regardless of how those identities are authenticated. The robustness of these capabilities allows customers to architect a wide range of isolation and enforcement mechanisms of cloud resources and application level elements. This can be done using role-based access control (RBAC) methods or attribute-based access control (ABAC) methods or both.

Customers can use policies in multiple ways including 1) controlling which resources a set of users can access, 2) controlling which users can access a given resource, 3) controlling which AWS services can be used, and 4) controlling which users are allowed to modify policies. All policies allow the use of conditions to further scope access. For example, a customer could enforce a policy that only allows access to contents in an Amazon Simple Storage Service (Amazon S3) bucket if the user also has access to the decryption key managed in the AWS Key Management Service and the request is made over a specific VPC. Any ability to modify such a policy could be scoped down to a limited set of modifications that could only be made by a select set of administrators, all of whom must authenticate using multiple factors. Policies can be enforced across multiple accounts using AWS Organizations. 

This level of control, deep integration, and wide interoperability would be exceedingly difficult to implement and manage in a traditional on-premises enterprise environment with physically separated and disparate systems. Most organizations use a combination of access and identity management solutions that vary across business unit and applications, but also across different layers of the infrastructure “stack” — network devices, virtualization, operating systems, and applications. This leads to a large set of identity services that need to be bound together and managed in a unified way. Adding to the management complexity, integration of these systems usually requires significant manual work coupled with continual care and attention as other parts of the service portfolio are brought into the fold. Additionally, uniform access policies still have to be crafted to help ensure enforcement cascades down to the system and data levels across an enterprise. 

With AWS, policy-based security management gives customers several distinct advantages. Security policies can be crafted to be both human and machine readable. This means that, while treating policy as code, it can also be a representative artifact for governance, risk and compliance efforts. This vastly improves clarity, accuracy, and transparency by letting stakeholders readily see actions that can and cannot be taken while being able to execute that policy directly in the service. Policies can be programmatically built and managed in a pipeline as code. This enables the same configuration management control over policy that an organization has with their application code. Another distinct benefit is the ability to utilize test automation in a pipeline, just like you would with software development, in order to verify and validate that policies function as expected. An example of this is IAM Access Analyzer, which customers can use to continuously evaluate permissions granted in policies to identify resources that can be accessed from outside a customer’s AWS account. IAM Access Analyzer uses automated reasoning, which applies logic and mathematical inference to evaluate hundreds or even thousands of policies across a customer's environment in seconds.