IAM Identities
The one identity that comes with every new AWS account is the root user. By default, root has full rights over all the services and resources associated with your account. This makes sense since there would otherwise be no way for you to get things done with the services that lie beyond root control. On the other hand, having everything in the hands of this one user makes root an attractive target for hackers: they only need to get the root password or access keys to compromise the entire account. To reduce your exposure to this vulnerability, AWS suggests that you heavily protect your root account and delegate specific powers for day-to-day operations to other users. Figure 6.1 shows the checklist of Amazon’s recommended actions in the Security Status section of a typical account’s IAM home page.
IAM Policies
Your first job should be to understand how policies are used to control the behavior of IAM identities. An IAM policy is a document that identifies one or more actions as they relate to one or more AWS resources. Finally, the policy document determines the effect permitted by the action on the resource. The value of an effect will be either Allow or Deny. A policy might, for instance, allow (the effect) the creation of buckets (the action) within S3 (the resource). Of course, the way resources and actions are defined will vary according to the particular service you’re working with. IAM provides hundreds of preset policies that can be viewed from the Policies page that’s accessed from the IAM Dashboard. You can filter policies using key words to narrow down your search. You can also create your own policy using the tools available through the Create policy page in the Dashboard or by manually crafting your own using JSON-formatted text. The following example is a JSON AdministratorAccess policy document from the IAM Dashboard interface. Note how it allows the identity holding the policy to perform any () action on any () resource in your account.
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: ““, “Resource”: ““
}
]
}
Any action that’s not explicitly allowed by a policy will be denied. But wait, if all actions are implicitly denied, why would you ever need to explicitly invoke “Deny” within a policy? Such policies could be useful in cases where a user requires access to most—but not all—resources within a domain. “Deny” can single out exactly those resources that should remain off-limits. When you associate a policy document with an IAM identity, that identity will now be bound to the policy’s powers and limitations. A single IAM policy can be associated with any number of identities, and a single identity can have as many as 10 managed policies (each no greater than 6,144 characters) attached to it. This raises the potential for trouble: what happens if two policies are associated with a single identity conflict? What if, for instance, one policy permits a user to create new S3 buckets and the second forbids it? AWS always resolves such conflicts by denying the action in question. You should also bear in mind that, in general, an explicit deny effect will always overrule an allow.
User and Root Accounts
The best way to protect your root account is to lock it down by doing the following:
■ Delete any access keys associated with root.
■ Assign a long and complex password and store it in a secure password vault.
■ Enable multifactor authentication (MFA) for the root account.
■ Wherever possible, don’t use root to perform administration operations.
Before all that, however, you must create at least one new user and assign it enough authority to get the necessary work done. Typically, that will involve giving your main admin user the AdministratorAccess policy, through which you’ll be able to use that user to create other users, groups, and roles—each with just enough power to perform its specific task.
When you create a new IAM user, you’ll have the option of applying a password policy. This policy can be set to enforce the minimum lengths and complexity along with the maximum lapsed time between password resets. Getting your team members to use only higher-quality passwords is an important security precaution. Users can open the My Security Credentials page (accessed via the pull-down menu beneath the user’s name in the console) to manage their security settings. As you can see in Figure 6.2 , that page includes sections for the following:
■✓ Updating a password
■✓ Activating or managing MFA
■✓ Generating or deleting access keys for managing your AWS resources through the AWS CLI or programming SDKs
■✓ Generating key pairs for authenticating signed URLs for your Amazon CloudFront distributions
■✓ Generating X.509 certificates to encrypt Simple Object Access Protocol (SOAP) requests to those AWS services that allow it
Obviously, not all of those items will be relevant to all of your users.
Access Keys
Access keys provide authentication for programmatic or CLI-based access. Rather than having to find a way for your application to input a traditional username and password, you can make your local environment aware of the access key ID and secret access key. Using that information, your application or command can pass authentication data along with each request. You learned about access keys in action in Chapter 2, “Amazon Elastic Compute Cloud and Amazon Elastic Block Store.” You should also become familiar with the AWS access key lifecycle and how it should be managed.
Also read this topic: Introduction to Cloud Computing and AWS -1
Deactivating Unused Keys
Each active access key is a potential source of account vulnerability. Audit the keys associated with each of your users from time to time, and if you can confirm that any of these keys are not currently being used, deactivate them. If you have no plans to use them in the future, delete them altogether.
Key Rotation
Best practices require that you regularly retire older access keys because the longer a key has been in use, the greater the chance that it’s been compromised. Therefore, it makes good sense to set a limit—perhaps 30 days—beyond which keys must be deleted and replaced by new ones. Key rotation is automated for IAM roles used by EC2 resources to access other AWS services. But if your keys are designated for your own applications, things can be more complicated. It’s a good idea to follow this protocol:
- Generate a new access key for each of your users. Users can also be given the ability to manage their own keys.
- Update your application settings to point to the new keys.
- Deactivate (but don’t delete) the old keys.
- Monitor your applications for a few days to make sure all the updates were successful. The CLI command aws iam get-access-key-last-used –access-key-id ABCDEFGHIJKLMNOP can be used to determine whether any applications are still using an old key.
- When you’re sure you have everything, delete the old keys. Key rotation can be enforced by including rotation in the password policy associated with your IAM user accounts.
Groups
Creating individual users with just the permissions they’ll need to perform their duties can be a secure and efficient way to manage AWS operations. But as your account becomes busier and more complex, it can also become a nightmare to manage. Say, for instance, you’ve given some level of access to a half a dozen admins and a similar number of developers. Manually assigning appropriate access policies to each user can be time-consuming. But just imagine how much fun you’ll have if you need to update permissions across the entire team—perhaps applying one set of changes for just the developers and another for the admins. The solution for such scenarios is to create a separate IAM group for each class of user and then associate each of your users with the group that fits their job description. You could create one group for developers, another for admins, and a third for your design team. Now, whenever you need to make changes to a particular class’s access profile, rather than having to edit each user account, you just update the appropriate group. If you’re adding an Elastic Beanstalk workload, you can open it up for the entire developers’ group with a single action. If you’re no longer running your video content through Amazon Elastic Transcoder, you can remove access from the design group.
Roles
An IAM role is a temporary identity that a user or service seeking access to your account resources can request. This kind of authorization can solve a lot of logistical problems. You might have users who will occasionally need to shut down and restart EC2 instances after an update. To prevent accidental shutdowns, however, you’d rather they didn’t normally have that power. Much the way sudo works on a Linux or macOS machine—or the runas command syntax on Windows—you can allow your user to assume an authorizing role for only as long as it’s needed. You might also want to temporarily give users from another AWS account—or users who sign in using a federated authentication service—access to resources on this account. An IAM role (which by default expires after 12 hours) is often the best mechanism for making this work. You create a new role by defining the trusted entity you want given access. There are four categories of trusted entity: an AWS service; another AWS account (identified by its account ID); a web identity who authenticates using a login with Amazon, Amazon Cognito, Facebook, or Google; and SAML 2.0 federation with a SAML provider you define separately. Once your entity is defined, you give it permissions by creating and attaching your own policy document or assigning one or more preset IAM policies. When a trusted entity assumes its new role, AWS issues it a time-limited security token using the AWS Security Token Service (STS).
Authentication Tools
AWS provides a wide range of tools to meet as many user and resource management needs as possible. The IAM functionality that you’ve already seen is only part of the story. The Amazon Cognito, AWS Managed Microsoft AD, and AWS Single Sign-On services are for handling user authentication, while AWS Key Management Service (KMS), AWS Secrets Manager, and AWS CloudHSM simplify the administration of encryption keys and authentication secrets.
Amazon Cognito
Cognito provides mobile and web app developers with two important functions.
■ Through Cognito’s user pools, you can add user sign-up and sign-in to your applications.
■ Through Cognito’s identity pools, you can give your application users temporary, controlled access to other services in your AWS account.
Building a new user pool involves defining how you want your users to identify themselves when they sign up (attributes such as address or birth date) and sign in (username or email address). You can also set minimum requirements for password complexity, multifactor authentication, and email verification. When you set up an identity pool, you define the pool from which your users can come (using Cognito, AWS, federated, or even unauthenticated identities). You then create and assign an IAM role to the pool. Once your pool is live, any user whose identity matches your definition will have access to the resources specified in the role.
People also ask this Questions
- What is a defense in depth security strategy how is it implemented?
- What is AWS Solution Architect?
- What is the role of AWS Solution Architect?
- Is AWS Solution Architect easy?
- What is AWS associate solutions architect?
- Is AWS Solutions Architect Associate exam hard?
Infocerts, 5B 306 Riverside Greens, Panvel, Raigad 410206 Maharashtra, India
Contact us – https://www.infocerts.com
