This whitepaper is for historical reference only. Some content might be outdated and some links might not be available. # Identity Management and Access Control capability The Identity Management and Access Control (IMAC) capability will help you build and monitor IAM permissions in your environment. This capabilities will enable you to structure your organization, organize your resources within defined isolated groups following the principal of least privilege (PoLP). The following guidance will help your team develop a framework to manage your environment and provide access to your services. **Category:** Security **Stakeholders: ** + Security (Primary) + Operations + Central IT + Software Engineering **Personas: ** + **Cloud Team** - the team(s) who make AWS available to customers. + **Identity Management Team **– the members of the cloud subject matter expert (SME) team responsible for Identity Management and Access control in the cloud. + **Information Security Team** - the team responsible for security in the cloud. + **Consumer **- everyone who needs to access the cloud platform. **Supporting capabilities**: [Governance Capability](governance-capability.md) **Scenarios:** + **CF2 - S1: Identity management** + **CF2 - S4: Identity Operations** + **CF2 - S7: Permissions management** Topics + [Overview](imac-overview.md) + [Structure the environment](structure-the-environment.md) + [Define functions and responsibilities to manage your environment](define-functions-and-responsibilities-to-manage-your-environment.md) + [Federated access](federated-access.md) + [Delegate the administration of different services](delegate-the-administration-of-different-services.md) + [Establish preventive controls across your environment](establish-preventive-controls-across-your-environment.md) # Overview When you are building your environment, access to your platform, your resources, and your applications needs to be established. First to build the environment, and second, to operate the environment through the established capabilities and services you build on it. As you structure your environment, you want to delegate administrative tasks to different teams, and separate responsibilities across different functions. For example, implementing security tooling, managing the network, or creating central repositories. Different teams may be responsible, and granting access to administer and consume this resources and services you are building within the environment. Access to your environment should be secured to all users, regardless of the function they will be responsible for. Enabling a form of multi-factor authentication (MFA) for every user is a requirement in order to meet a minimum-security standard. # Structure your identities to access your environment Once your roles have been defined and you have decided what services you will start using, you need to structure your environment in a way that allows you to assign and separate the responsibilities previously described. We recommend that you start small where you can, and separate the security functions, workload environments (separating production from the rest of the environments), and sandbox environments. You can achieve this by using a mechanism to create isolated group of resources from each other. **You can group workloads with a common business purpose** in a distinct isolated group of resources. This enables you to align the ownership and decision making with the isolated group of resources and avoid dependencies and conflicts with how workloads in other isolated group of resources are secured and managed. Workloads often have distinct security profiles that require separate control policies and mechanisms to support them, you can **apply distinct security controls by environment.** When you limit sensitive data stores to an account that is built to manage it, you can more easily **constrain the number of people and processes that can access and manage the data store**. This approach simplifies the process of achieving least privilege access. In the early stages of a workload’s lifecycle, you can help **promote innovation** by providing your builders with separate isolated group of resources in support of experimentation, development, and early testing. Organizations often have **multiple IT operating models** or ways in which they divide responsibilities among parts of the organization to deliver their application workloads and platform capabilities. Additionally, creating isolated group will help you organized your resources** based on their function**, and **share them across these the** different isolated groups when needed. Restrictions can also be applied across isolated group of resources that perform a similar action **applying common policies.** # Define functions and responsibilities to manage your environment Federated access grants you the ability to efficiently manage the access to the environment, and should be established and operated centrally. The benefits of managing your identities and controlling access to your environment centrally, allows you to quickly create, update, and delete the permissions and policies you need to meet your business requirements. From granting or revoking permissions to specific users or roles, or by establishing preventative controls on your overall environment, your security teams can manage access to the environment from one place. The responsibilities to perform certain actions of the environment need to be separated. Granting permissions to perform only the necessary actions to specific roles, and users, depending on the purpose of the service being established, achieving a least privileged access model. You also need to ensure that you group different users by their job family to access different tools with a different set of permissions, and that regardless of the user, there may be some preventative controls needed to set centrally to prevent access or modification to certain resources and areas of your environment. We recommend that you establish Multi-Factor Authentication (MFA) for every role that has access to your environment, a minimum requirement is to establish MFA for administrator roles. This adds an extra layer of protection on top of your sign-in credentials. Additionally, it is very important that every ***root user user*** has MFA enabled. For access to your organizational account, the root user user MFA needs to be enabled, and the access key and password should be stored separately. When establishing your environment, you need to set the following functions in your environment, these functions will enable you to manage your overall infrastructure: + The **Environment administrator role** manages the overall environment, creates isolated group of resources, sets guardrails, and delegates the administration of different services to the appropriate isolated group of resources and teams. + The **Network administrator **manages the network. This function will have access to create and configure network topologies, DNS, VPNs, and build network security across your environment. Network administrators are responsible for securing the network and distributing resources workloads. + The **Directory Services administrator **manages access to the environment. This function creates, updates, deletes, assigns, and removes access from different users to the environment. + The **Security administrator **manages security services and tools across your environment, ensuring all your services and workloads are running on a secured infrastructure. This function has access to the environment to remediate any possible security threat. + The **Billing administrator** manages the spend of your environment and creates budgets and alerts based on the forecasting of your expenses. This function is also responsible to pay the invoice for your environment. + The **Read Only Security** function is used to monitor the environment. Security administrators can use this function to oversee the environment in real time and interact with the different security tools, without having full access to the environment + The **Security Audit **is an exclusively read only function intended to grant access to external or internal auditors that need to examine the environment. + The **Log Storage administrator **manages the log storage in your environment. This function creates or updates the resources needed to security and immutably store your logs, and manages the environment when changes need to be applied. + The **Shared Services administrator **manages all the shared services across the environment. For example, this function is used to set up a central DNS or a central Template Management function. + The **Support** function will have access to read only permissions for the infrastructure and not the data within each of the isolated group of resources in the environment. This will allow the cloud team to help troubleshooting the environment, and the workload infrastructure when deployed, helping the team solve any issues with the environment or internal workflows. When necessary, it can be used to escalate to find resolution to your cloud service provider. These functions with the appropriate permissions and boundaries should be assigned to the user groups which job family needs to perform tasks related to the roles above. This will allow them to access, monitor, operate, update, and secure the environment as needed to meet your business requirements. These functions represent responsibilities within your cloud environment, and multiple functions can be assumed by the same team or person. To achieve this, you will need to build isolation boundaries to limit the access from each group to the services and tools needed to build, deploy, and operate. In some cases, these groups will need to work together to establish a connection to consume services between the boundaries isolating the resources, to create a cohesive environment that is secure and scalable, and provide access to these services to workloads or other foundational services within the environment. # Federated access Federation is a common approach to building access control systems which manage users centrally within a central Identity Providers (IdP) and govern their access to multiple applications and services acting as Service Providers (SP). An identity provider enables you to manage your user identities outside of the application, service, or solution; and give these external user identities permissions to use AWS resources in your account. This is useful if your organization already has its own identity system, such as a corporate user directory or managed identity service. The process of federation allows you to centrally manage user credentials which grant access to applications. The centralization of user credentials in one data store allows you to effectively manage the lifecycle of the user and impose security requirements such as password policies, MFA requirements, and service principals. If a user leaves the company, they can simply delete the user’s corporate identity, which then also revokes access to all your federated environments. When you use an identity provider, you don't have to create custom sign-in code or manage your own user identities. The IdP provides that for you. Your external users sign in through a well-known IdP, such as a log in with Amazon, Facebook, or Google. You can give those external identities permissions to use AWS resources in your account. Identity providers help keep your AWS account secure because you don't have to distribute or embed long-term security credentials in your application. # Delegate the administration of different services As your environment grows, the complexity of managing your environment will increase with the amount of isolated group of resources you have. In order to effectively manage your environment, you will need to have a level of automation that matches the complexity of your environment. Each team in your organization will assume different roles to manage different aspects of the environment. Delegating the administration of the services that the team will be managing in your environment will allow them to establish boundaries for data and security separately, they can build or deploy the necessary automation they need to operate and oversee the environment as they require, without affecting other teams or environments. For example, delegate the management of security services to your security team, delegate the infrastructure deployments, and template management to your Operations and Central IT teams, and delegate the management of your identity to your Identity or Security team. # Establish preventive controls across your environment Only granting permissions does not guarantee that our environment is fully secured. To ensure that only the services that are intended to be used by the assigned roles, you need to limit what actions can be performed in your overall environment. For example, to limit the modification of the logs that are being stored in your log storage. To prevent anyone from deleting or modifying these logs by mistake, you need to enable preventive controls to restrict the deletion on the logs in your log storage. On AWS this can be accomplished by applying [service control policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) to your accounts. These policies allow you to limit certain actions within a specific account, but you can also use them to prevent access to services completely, or limit the actions in your environment in specific regions that are not approved for use in your environment.