Identity Access Management IAM
Amazon Web Services (AWS) offers high level data protection when compared to an on-premises environment, at a lower cost. Among various AWS security services, Identity and Access Management (IAM) is the most widely used one. It enables secure control access to AWS resources and services for the customers. Customers can create and manage AWS users as well as groups, and provides necessary permissions to allow or deny access to AWS resources. In a simple term IAM provides an infrastructure necessary to control authentication and authorization for its customers account.
AWS Identity access management capabilities
- AWS Identity and Access Management (IAM) enables customers to securely control access to AWS services and resources for their users.
- Using IAM, customers can create and manage AWS users and groups, and use permissions to allow and deny their access to AWS resources.
- IAM makes it easy to provide multiple users secure access to AWS resources.
Multi Factor Authentication
Customers can add two-factor authentication to their account and to individual customers (users) for extra security.
- With MFA customers or their users must provide not only a password or access key to work with user account, but also a code from a specially configured device.
- By using the Multi-factor authentication customers can easily add the two-factor authentication not only for their account but also for the individual users for more security.
- AWS Identity and Access Management (IAM) lets customers manage several types of long-term security credentials for IAM users using the following
- Passwords:- Used to sign in to secure AWS pages, such as the AWS Management Console and the AWS Discussion Forums.
- Access keys:- Used to make programmatic calls to AWS from the AWS APIs, AWS CLI, AWS SDKs, or AWS Tools for Windows PowerShell.
- Amazon CloudFront key pairs:- Used for CloudFront to create signed URLs.
- SSH public keys:- Used to authenticate to AWS CodeCommit repositories.
- X.509 certificates:- Used to make secure SOAP-protocol requests to some AWS services.
Manage federated users and their permissions :–
- Customers can enable identity federation to allow existing identities (users, groups, and roles) in their enterprise to access the AWS Management Console, call AWS APIs, and access resources, without the need to create an IAM user for each identity.
- Access and Federation :– User can grant other people permission to administer and use resources in your AWS account without having to share your password or access key.
- AWS offers multiple options for federating customers identities in AWS. One of them being AWS Identity and Access Management (IAM) which enable users to sign in to their AWS accounts with their existing given credentials.
Manage IAM users
AWS clients can grant other people permission to administer and use resources in their AWS account without having to share their password or access key. They can also create users in IAM, assign them individual security credentials (such as access keys, passwords, and multi-factor authentication devices), or request temporary security credentials to provide users access to AWS services and resources. You can manage permissions in order to control which operations a user can perform. IAM users can be:
- Privileged administrators who need console access to manage your AWS resources.
- End users who need access to content in AWS.
- Systems that need privileges to programmatically access your data in AWS.
Securing Application Access
AWS Identity and Access Management (IAM) helps customers control access and permissions to thier AWS services and resources, including compute instances and storage buckets. they also can use IAM features to securely give applications that run on EC2 instances the credentials that they need in order to access other AWS resources, like
- S3 buckets and RDS
- DynamoDB databases.
The AWS Security Token Service (STS)
IAM roles allow customers to delegate access to users or services that normally don’t have access to their organization’s AWS resources. IAM users or AWS services can assume a role to obtain temporary security credentials that can be used to make AWS API calls. In other word AWS customers don’t have to share long-term credentials or define permissions for each entity that requires access to a resource. Using the AWS Security Token Service (STS), that is a web service that enables customers to request temporary, limited-privilege credentials for IAM users or for users that they authenticate (federated users).
- Customers do not have to distribute or embed long-term AWS security credentials with an application.
- Customers can provide access to their AWS resources to users without having to define an AWS identity for them.
- The temporary security credentials have a limited lifetime.
- After temporary security credentials expire, they cannot be reused.
- AWS STS are features of customers AWS account offered at no additional charge. However customers will bare that are charged they access other AWS services using your IAM users or AWS STS temporary security credentials.
Granular permission enables customers to grant the permissions for different according to their resources. Customers can give the whole access to AWS services, while limiting the other users to read-only access along with the administrator EC2 instances in order to access the process of billing information. These services include;
- Amazon Elastic Compute Cloud (Amazon EC2).
- Amazon Simple Storage Service (Amazon S3).
- Amazon DynamoDB, Amazon Redshift.
- For other users, customers can allow
- Read-only access to just some S3 buckets,
- Permission to administer just some EC2 instances, or
- Access to customer billing information but nothing else.
- IAM also enables customers to add specific conditions such as time of day to control how a user can use AWS,
- Their originating IP address, whether they are using SSL, or
- Whether customers have authenticated with a multi-factor authentication device.
The description of power user access given by AWS is “Provides full access to AWS services and resources, but does not allow management of Users and groups.” The power to manage user is the highest privilege operation in AWS thus it is provided to the administrative access policy only.
- Power users are just below the Root user and have all the privileges the Root user has with the exception of the ability to manage the IAM users.
- Roles and Temporary Security Tokens
AWS IAM role is same as the user in which AWS identity with certain permission policies to determine specific identity that can or cannot be done with AWS. One can also use similar roles to delegate certain access to the users, applications or else services to have access to AWS resources.
- Roles are used to grant specific privileges to specific entities for a set duration of time. These entities can be authenticated by AWS.
- AWS provides these entities with a temporary security token from the AWS Security Token Service (STS), which lifespan run between 5 min to 36 hours.
- Customers can create roles in IAM and manage permissions to control which operations can be performed by the entity.
- Customers can also define which entity is allowed to assume the role. In addition, they can use service-linked roles to delegate permissions to AWS services that create and manage AWS resources on your behalf.
- Granting permissions to users from other AWS accounts, whether you control those accounts or not known as Cross-Account Access
- IAM users can temporarily assume a role to take on permissions for a specific task.
- Temporary credentials are primarily used with IAM roles and automatically expire.
- A role can be assigned to a federated user who signs in using an external identity provider.
- IAM roles can be used for granting applications running on EC2 instances permissions to AWS API requests using instance profiles.
- Only one role can be assigned to an EC2 instance at a time.
- Using IAM roles for Amazon EC2 removes the need to store AWS credentials in a configuration
- IAM Role Delegation has two policies:
- Permissions policy – grants the user of the role the required permissions on a resource.
- Trust policy – specifies the trusted accounts that are allowed to assume the role.
An IAM role is very similar to a user, in that it is an identity with permission policies that determine what the identity can and cannot do in AWS. However, a role does not have any credentials (password or access keys) associated with it. Instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it. An IAM user can assume a role to temporarily take on different permissions for a specific task. A role can be assigned to a federated user who signs in by using an external identity provider instead of IAM. AWS uses details passed by the identity provider to determine which role is mapped to the federated user.
An IAM group is a collection of IAM users. Groups let Root users specify permissions for multiple users, which can make it easier to manage the permissions for those users. Customers can use groups to specify permissions for a collection of users, which can make those permissions easier to manage for those users. Any user in that group automatically has the permissions that are assigned to the group.
- A group is not an identity and cannot be identified as a principal in an IAM policy.
- Groups are collections of users and have policies attached to them.(admin, developers, human resources…)
- A group can contain many users, and a user can belong to multiple groups.
- Groups can’t be nested; they can contain only users, not other groups.
- Use the principal of least privilege when assigning permissions.
- Customers cannot nest groups (groups within groups).
The “identity” aspect of AWS Identity and Access Management (IAM) helps customers with the question “Who is that user?”, often referred to as authentication. Instead of sharing their root user credentials with others, they can create individual IAM users within their account that correspond to users in their organization. IAM users are not separate accounts; they are users within customers’ accounts. Each user can have its own password for access to the AWS Management Console.
Using the following elements, IAM provides the infrastructure necessary to control authentication and authorization for customers’ accounts. They are Principal, Request, Authentication, Authorization, Actions (Operations), and Resource.
A principal is a an IAM entity or application that is allowed to interact with AWS resources, or that can make a request for an action or operation on an AWS resource. The principal is authenticated as the AWS account root user. A principal can be permanent or temporary, and it can represent a human or an application. The administrative IAM user is the first principle, which can allow the user for the particular services in order to assume a role.
- There are three types of principals: root users, IAM users, and roles/temporary security tokens.
- Root User
The username and password customers used to create an AWS account for the first time is called root user account. This account contains one important right that no other account created under IAM will have – the right to delete the entire AWS account including all storage, all EC2 instances, containers and everything else for that matter.
- The account root user credentials are the email address used to create an account and a password. The root account has full administrative permissions and it cannot be restricted.
- It’s AWS recommendation that customers not to use the root user for their everyday tasks.
- Best practice for root accounts:
- Don’t use the root user credentials.
- Don’t share the root user credentials.
- Create an IAM user and assign administrative permissions as required.
- Enable MFA
- IAM user
An IAM user is an entity that customers create in AWS. The IAM user represents the person or service who uses the IAM user to interact with AWS. A primary use for IAM users is to give people the ability to sign in to the AWS Management Console for interactive tasks and to make programmatic requests to AWS services using the API or CLI. A user in AWS consists of a name, a password to sign into the AWS Management Console, and up to two access keys that can be used with the API or CLI. IAM user accounts are user accounts which customers can create for individual services offered by AWS.
Root Users can create IAM, and assign them individual security credentials such as words, access keys, passwords, and multi-factor authentication devices, or request temporary security credentials to provide users access to AWS services and resources.
- IAM user represents the person or service who uses the IAM user to interact with AWS.
- A primary use for IAM users is to give people the ability to sign in to the AWS Management Console for interactive tasks and to make programmatic requests to AWS services using the API or CLI.
- Root users can create IAM users, attach group level policies or user level policies and share these IAM accounts with other entities.
- Group level and user level policies restrict and authorize individual IAM users to AWS services under Root user account.
- IAM users are individuals who have been granted access to an AWS account. Each IAM user has three main components:
- A user-name.
- A password.
- Permissions to access various resources.
- Customers have persistent identities set up through the IAM service to represent individual people or applications.
A Request is a process where a principal send to AWS in order to use the AWS Management Console, the AWS API, or the AWS CLI. The request includes:
- Actions or operations – The actions or operations that the principal wants to perform.
- Resources – The AWS resource object upon which the actions or operations are performed.
- Principal – The person or application that used an entity (user or role) to send the request. Information about the principal includes the policies that are associated with the entity that the principal used to sign in.
- Environment data – Information about the IP address, user agent, SSL enabled status, or the time of day.
- Resource data – Data related to the resource that is being requested. This can include information such as a DynamoDB table name or a tag on an Amazon EC2 instance.
AWS gathers the Request information into a request context, which is used to evaluate and authorize the request.
Principal, Request, Authentication, Authorization, Actions (Operations), and Resource.
The type of instance that client specify determines the hardware of the host computer used for their instance. Each instance type offers different compute, memory, and storage capabilities and are grouped in instance families based on these capabilities. Each instance type provides higher or lower minimum performance from a shared resource.
Authorization is a process of specifying exactly what actions a principal can and cannot perform in AWS resources. This will be possible after IAM has authenticated the principal, then IAM must manage the access of that principal to protect the client AWS infrastructure. Authorization is handled in IAM by defining specific privileges in policies and associating those policies with principals.
- Effect:– Allow or Deny.
- Service:– Most AWS Cloud services support granting access through IAM, including IAM itself.
- Resource:– The resource value specifies the specific AWS infrastructure for which this permission applies.
- Action:– Action value specifies the subset of actions within a service that the permission allows or denies.
- Condition:–The condition value optionally defines one or more additional restrictions that limit the actions allowed by the permission.
After AWS approves the operations of customers’ request, they can be performed on the related resources within their account. A resource is an object that exists within a service. the resources include an Amazon EC2 instance, an IAM user, and an Amazon S3 bucket. The service defines a set of actions that can be performed on each resource.
A principal must be authenticated (signed in to AWS) using their credentials to send a request to AWS.
To authenticate from the console as a root user, customers need to sign in with their email address and password.
- IAM provide customers their account ID or alias, and then their users name and password.
- Principal can be authenticated three ways :
- By using User name and Password
- By using access key, that’s a combination of an access key ID (20 characters) and an access secret key (40 characters).
- Access Key/Session Token—When a process operates under an assumed role, the temporary security token provides an access key for authentication.
After the request has been authenticated and authorized, AWS approves the actions or operations in customers’ request. Operations are defined by a service, and include things that the customer can do to a resource, such as viewing, creating, editing, and deleting that resource. IAM supports approximately 40 actions for a user resource, including the following actions:
To allow a principal to perform an operation, you must include the necessary actions in a policy that applies to the principal or the affected resource
Operations (Actions) are defined by a service that include things such as viewing, creating, editing, and deleting that resource by customers. In order to get granted in these Operations, Principals (Root user,IAM user, and Role) request need to pass Authentication and Authorization.
- User Policy:–These policies exist only in the context of the user to which they are attached. In the console, a user policy is entered into the user interface on the IAM user page.
- Managed Policies:–These policies are created in the Policies tab on the IAM page (or through the CLI, and so forth) and exist independently of any individual user. In this way, the same policy can be associated with many users or groups of users.
- Group Policy:– These policies exist only in the context of the group to which they are attached. In the AWS Management Console, a group policy is entered into the user interface on the IAM Group page.
- Managed Policies:– In the same way that managed policies (discussed in the “Authorization” section) can be associated with IAM users, they can also be associated with IAM groups.
A policy is an object in AWS that, when associated with an identity or resource, defines their permissions. AWS evaluates these policies when a principal uses an IAM entity (user or role) to make a request. Permissions in the policies determine whether the request is allowed or denied. Most policies are stored in AWS as JSON documents. Policies are documents that define permissions and can be applied to users, groups and roles.
- Policy documents are written in JSON (key value pair that consists of an attribute and a value).
- All permissions are implicitly denied by default.
- The IAM policy simulator is a tool to help customers understand, test, and validate the effects of access control policies.
- There are three basic steps where every user has to follow to get authenticated in an enormous way. Starting from selecting certain Policy Type, then Add the respective statements, and finally Generate Policy as per the requirement
- These are in the policy container for certain permissions where customers can select anyone from respective policies such as IAM Policy, S3 bucket policies, and SNS topic policy, SQS queue policy, VPC endpoint policy etc.
- Then adding statements is the respective policy to have a formal description for single access permission. The Final one, Generate Policy is a document that acts as a container for one or else massive statements.
- The control provided by IAM is granular enough to limit a single user to the ability to perform a single action on a specific resource from a specific IP address during a specific time window.
The IAM console includes policy summary tables that describe the access level, resources, and conditions that are allowed or denied for each service in a policy. Policies are summarized in three tables: the policy summary, the service summary, and the action summary
- The policy summary table is grouped into one or more Uncategorized services, Explicit deny, and Allow sections. If the policy includes a service that IAM does not recognize, then the service is included in the Uncategorized services section of the table. If IAM recognizes the service, then it is included under the Explicit deny or Allow sections of the table, depending on the effect of the policy (Deny or Allow).
- The service summary table includes a list of the actions and summaries of the permissions that are defined by the policy for the chosen service. You can view a service summary for each service listed in the policy summary that grants permissions. The table is grouped into Uncategorized actions, Uncategorized resource types, and access level sections. If the policy includes an action that IAM does not recognize, then the action is included in the Uncategorized actions section of the table. If IAM recognizes the action, then it is included under one of the access level (List, Read, Write and Permissions management) sections of the table.
- The action summary table includes a list of resources and the associated conditions that apply to the chosen action. To view an action summary for each action that grants permissions, choose the link in the service summary. The action summary table includes details about the resource, including its Region and Account. You can also view the conditions that apply to each resource. This shows you conditions that apply to some resources but not others.
IAM best practices
Lock away the AWS root user access keys:- The access key for customers AWS account root user gives full access to all their resources for all AWS services, including customers’ billing information. Its important not to share AWS account root user password or access keys with anyone
Use groups to assign permissions to IAM users:- Instead of defining permissions for individual IAM users, it’s usually more convenient to create groups that relate to job functions (administrators, developers, accounting, etc.). Next, define the relevant permissions for each group. Finally, assign IAM users to those groups. All the users in an IAM group inherit the permissions assigned to the group. That way, you can make changes for everyone in a group in just one place. As people move around in your company, you can simply change what IAM group their IAM user belongs to.
Use Access Levels to Review IAM Permissions:- To improve the security of your AWS account, you should regularly review and monitor each of your IAM policies. Make sure that your policies grant the least privilege that is needed to perform only the necessary actions.
- When AWS customers review a policy, they can view the policy summary that includes a summary of the access level for each service within that policy. AWS categorizes each service action into one of five(List, Read, Write, Permissions management, or Tagging) access levels based on what each action does.
Use Roles to Delegate Permissions:- Don’t share security credentials between accounts to allow users from another AWS account to access resources in your AWS account. Instead, use IAM roles. Customers can define a role that specifies what permissions the IAM users in the other account are allowed. They can also designate which AWS accounts have the IAM users that are allowed to assume the role.
Rotate Credentials Regularly:- It is important to change the root passwords and access keys regularly, and make sure that all IAM users in the account do as well. That way, if a password or access key is compromised without Principal knowledge, they can limit how long the credentials can be used to access their resources. They can apply a password policy to their account to require all their IAM users to rotate their passwords. Customers can also choose how often they must do so.
Monitor Activity the AWS Account:- By using logging features in AWS customers can determine the actions users have taken in their account and the resources that were used. The log files show the time and date of actions, the source IP for an action, which actions failed due to inadequate permissions, and more.
Create individual IAM users:- Its important not to use AWS account root user credentials to access AWS. Instead, create individual users for anyone who needs access to the AWS account.
Grant Least Privilege:- When creating IAM policies, it is important to follow the standard security advice of granting least privilege, or granting only the permissions required to perform a task. Determine what users (and roles) need to do and then craft policies that allow them to perform only those tasks.
- Start with a minimum set of permissions and grant additional permissions as necessary. Doing so is more
secure than starting with permissions that are too lenient and then trying to tighten them later.
Configure a Strong Password Policy for the Users:- When letting the users to change their own passwords, they should be required to create strong passwords and that they rotate their passwords periodically. On the Account Settings page of the IAM console, you can create a password policy for your account. You can use the password policy to define password requirements, such as minimum length, whether it requires non-alphabetic characters, how frequently it must be rotated, and so on.
Enable MFA for privileged users:- For extra security, we recommend that customers to require multi-factor authentication (MFA) for all users in your account. With MFA, users have a device that generates a response to an authentication challenge. Both the user’s credentials and the device-generated response are required to complete the sign-in process. If a user’s password or access keys are compromised, customers account resources are still secure because of the additional authentication requirement.
Do Not Share Access Keys:- Access keys provide programmatic access to AWS. Do not embed access keys within unencrypted code or share these security credentials between users in your AWS account. For applications that need access to AWS, configure the program to retrieve temporary security credentials using an IAM role. To allow customers users for individual programmatic access, create an IAM user with personal access keys.
Remove Unnecessary Credentials :- Remove IAM user credentials (passwords and access keys) that are not needed. Passwords and access keys that have not been used recently might be good candidates for removal. Customers can find unused passwords or access keys using the console, using the CLI or API, or by downloading the credentials report.
AWS Security Hub provides customers with a comprehensive view of their security state in AWS and helps them check their compliance with the security industry standards and best practices. Security Hub collects security data from across AWS accounts, services, and supported third-party partner products and helps customers analyze their security trends and identify the highest priority security issues.
- Security Hub reduces the effort to collect and prioritize security findings across accounts from integrated AWS services and AWS partner products.
- Security Hub automatically runs continuous, account-level configuration and compliance checks based on industry standards and best practices, such as the Center for Internet Security (CIS) AWS Foundations Benchmarks.
- Security Hub consolidates customers security findings across accounts and provider products and displays results on the Security Hub console pages.
- Security Hub supports integration with Amazon CloudWatch Events, which lets customers automate remediation of specific findings by defining custom actions to take when a finding is received.
Web Application Firewall (WAF)
AWS WAF is a web application firewall that helps protect customers web applications or APIs against common web exploits that may affect availability, compromise security, or consume excessive resources. AWS WAF gives customers control over how traffic reaches your applications by enabling them to create security rules that block common attack patterns.
- AWS WAF lets you create rules to filter web traffic based on conditions that include IP addresses, HTTP headers and body, or custom URIs.
- AWS WAF allows customers to create a centralized set of rules that they can deploy across multiple websites.
- AWS WAF provides real-time metrics and captures raw requests that include details about IP addresses, geo locations, URIs, User-Agent and Referers. AWS WAF is fully integrated with Amazon CloudWatch, making it easy to setup custom alarms when thresholds are exceeded or particular attacks occur.
- AWS WAF provides organizations with the ability to create and maintain rules automatically and incorporate them into the development and design process via APIs.
Network firewalls built into Amazon VPC.
- In transit encryption using TLS across all services.
- Private or dedicated connections into your data centre
- Technologies built from the ground up for resilience in the face of DDoS attacks.
- Services can be used in combination to automatically scale for traffic load.
- Autoscaling, CloudFront, Route 53 can be used to prevent DDoS.
- At rest encryption available in EBS, S3, Glacier, RDS (Oracle and SQL Server) and Redshift.
- Key management through AWS KMS – you can choose whether to control the keys or let AWS.
- Server side encryption of message queues in SQS.
- Dedicated hardware-based cryptographic key storage using AWS CloudHSM, allowing you to satisfy compliance requirements.
APIs to integrate AWS security into any applications you create.
AWS Support provides tools and resources to help users make sure their AWS environment is built and operated to be Secure, Highly available, Efficient, and Cost effective.
- With a focus on the security and operational health of user infrastructure, AWS Support provides:
- Real-time insight through AWS Trusted Advisor.
- Trusted Advisor is an online tool that serves as users customized cloud expert, and helps them provision their resources by following best practices.
- Trusted Advisor inspects users AWS environment and finds opportunities
- To save Money
- Improve system performance and reliability, or
- Help close security gaps.
- Real-time insight through AWS Trusted Advisor.
- Proactive support and advocacy through Technical Account Manager (TAM).
- Users TAM is their single point of contact and advocate who provides technical expertise across the full range of AWS services.
- TAMs work closely with users to deliver proactive guidance and early awareness of new features and recommendations. And should any unplanned issues arise, their TAM ensures that they are resolved as swiftly as possible.
- The full range of AWS Trusted Advisor checks is available to all customers with Business and Enterprise Level Support, and Technical Account Managers are included with Enterprise Support.
- With a focus on the security and operational health of user infrastructure, AWS Support provides:
AWS Shield is a managed Distributed Denial of Service (DDoS) protection service that safeguards applications running on AWS. AWS Shield provides always-on detection and automatic inline mitigations that minimize application downtime and latency, so there is no need to engage
- AWS Shield is closely related to both AWS WAF and also the AWS Firewall Manager.
- All AWS customers benefit from the automatic protections of AWS Shield Standard, at no additional charge. AWS Shield Standard defends against most common, frequently occurring network and transport layer DDoS attacks that target customers web site or applications.
- Customers can use AWS Shield Standard with Amazon CloudFront and Amazon Route 53 to receive comprehensive availability protection against all known infrastructure (Layer 3 and 4) attacks.
- AWS Shield Advanced is available globally on all Amazon CloudFront, AWS Global Accelerator, and Amazon Route 53 edge locations. Customers can protect their web applications hosted anywhere in the world by deploying Amazon CloudFront in front of their application.
- AWS Shield Standard is always-on heuristics-based network flow monitoring and inline mitigation against common, most frequently occurring network and transport layer DDoS attacks.
Customer responsibility “Security in the Cloud”: The customer assumes responsibility and management of the guest operating system (including updates and security patches), other associated application software as well as the configuration of the AWS provided security group firewall.
AWS responsibility “Security of the Cloud” – AWS is responsible for protecting the infrastructure that runs all of the services offered in the AWS Cloud. This infrastructure is composed of the hardware, software, networking, and facilities that run AWS Cloud services.
- Cloud security at AWS is the highest priority.
- As an AWS customer, users will benefit from a data center and network architecture built to meet the requirements of the most security-sensitive organizations.
- An advantage of the AWS cloud is that it allows customers to scale and innovate, while maintaining a secure environment.
- Customers pay only for the services they use, meaning that users can have the security they need, but without the upfront expenses, and at a lower cost than in an on-premises environment.
- Cloud security at AWS is the highest priority.
Monitoring and Logging
Deep visibility into API calls through AWS CloudTrail, including who, what, when, and from where calls were made
Log aggregation options, streamlining investigations and compliance reporting
Alert notifications through Amazon CloudWatch when specific events occur or thresholds are exceeded
Identity and Access Control
- AWS Identity and Access Management (IAM) lets you define individual user accounts with permissions across AWS resources
- AWS Multi-Factor Authentication for privileged accounts, including options for hardware-based authenticators
- AWS Directory Service allows users to integrate and federate with corporate directories to reduce administrative overhead and improve end-user experience
- Real-time insight through AWS Trusted Advisor
- Proactive support and advocacy with a Technical Account Manager (TAM)
Compliance Assurance Programs:- From certifications, regulations to frameworks, AWS has you covered. Some of those included are
- DoD SRG, FIPS (US)
- ISO 9001, CISPE, GLBA
- UK Data Protection Act
- EU Data Protection Directive
- G-Cloud , NIST, UK Cloud Security Principles.
Creating an IAM User
It is AWS recommendation not to use the AWS account root user for any task where it’s not required. Instead, create a new IAM user for each person that requires administrator access. Then make those users administrators by placing the users into an “Administrators” group to which you attach the Administrator Access managed policy.
Thereafter, the users in the administrators group should set up the groups, users, and so on, for the AWS account. All future interaction should be through the AWS account’s users and their own keys instead of the root user. However, to perform some account and service management tasks, you must log in using the root user credentials. To view the tasks that require you to sign in as the root user, see AWS Tasks that Require Account Root User.