Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://www.techtarget.com/searchcloudcomputing/tip/An-introduction-to-AWS-IAM-best-practices below:

An introduction to AWS IAM best practices

Part of: A quick guide to AWS identity and access basics

• Stephen J. Bigelow,

Published: 02 Jun 2021

IT teams need to ensure that only known and trusted users can access their organization's vital applications and data.

Cloud users rely on services, like AWS Identity and Access Management (IAM), to secure and manage access across the vast portfolio of AWS services and resources -- and even federate a level of access control between AWS and local data center resources.

Let's take a closer look at AWS IAM, learn how it works and review best practices to help use resources securely.

AWS IAM is an Amazon cloud offering that manages access to compute, storage and other application services in the cloud. IAM's primary capability is access and permissions. It provides two essential functions that work together to establish basic security for enterprise resources:

• Authentication. Authentication validates the identity of a user. It is typically handled by checking credentials -- such as usernames and passwords -- against an established database of credentials within the AWS IAM service. Advanced authentication might include multifactor authentication (MFA), which couples traditional credentials with a third form of authentication, such as sending a unique code to a user's smartphone.
• Authorization. Once a user is authenticated, authorization defines the access rights for that user and limits access to only the resources permitted for that specific user. Not every user will have access to every application, data set or service across the organization. Authorization typically follows the concept of least privilege, where users receive the minimum access rights that are necessary for their jobs.

IAM deals with four principle entities: users, groups, roles and policies. These entities detail who a user is and what that user is allowed to do within the environment:

• Users. A user is one of the most basic entities in IAM. A user is typically a person or a service, such as an application or platform, which interacts with the environment. An IT teams assigns users authorization credentials, such as a username and password, which validate the user's identity. Users can then access resources that are assigned through permissions or policies.
• Groups. A group is a collection of users that share common permissions and policies. Any permissions associated to a group are automatically assigned to all users in a group. For example, placing a user into an Administrator group will automatically assign the user any permissions given to the Administrator group. IT teams can move users between groups and  automatically shift permissions as groups change.
• Roles. A role is a generic identity that is not associated with any specific user. Roles do not use passwords and can be assumed by authorized users. Roles enable varied users to temporarily assume different permissions for different tasks.
• Policies. Policies are AWS objects that are attached to users, groups, roles or resources that define the permissions granted to those identities. When a user tries to access a resource, the request is checked against the associated policies. If the request is permitted, then it is granted. If not, it is denied. AWS policies are based on six different criteria: identity, resources, permission boundaries, service control policies, access control lists and session policies. IT teams can attach multiple policies to each identity for more granular control of permissions.

IAM is fully interoperable with most compute, container, storage, database and other AWS cloud offerings. However, IAM is not fully compatible with all offerings on the platform, so it is best to check compatibility before implementing the service. For example, Amazon Elastic Compute Cloud (EC2) does not fully support resource-level permissions or authorization based on tags.

IT teams can manage and share a single business account between many different users -- each using unique credentials. Administrators can create policies to establish granular permissions and grant users access to different resources depending on their identity. Changes to IAM, such as creating or updating users, groups, roles and policies, take time because changes must be replicated to multiple servers globally. This means changes to IAM should not be critical or time dependent.

The common IAM process breaks down into four distinct phases:

1. Make a request. The IAM process starts with a person or an application called the principal. Every principal has credentials under an AWS root account and must already be signed into AWS to make requests. A principal then makes a request or takes an action involving a resource.
2. Send details to AWS. Every request to AWS includes necessary details such as the actions, the resources involved, any policies related to the principal, data about the resources involved -- such as an Amazon EC2 instance tag -- and other data, such as IP addresses and time codes. These details are used to evaluate and authorize the request.
3. Authorize the request. AWS checks the principal's authentication and compares the associated policies against the request. In this phase, IAM evaluates whether the user or application has permission to perform the requested action on the desired resource. If the principal does have authorization, the request is approved and the process continues. If not, the request is denied. When a principal involves multiple policies, all policies must allow the request or it will be denied.
4. Process the request. When the request of an authenticated principal is authorized, the request can be processed. This typically involves performing a desired action on an intended resource, such as getting data from a storage instance. AWS will generate any suitable responses to the principal, such as data streams and success or failure messages.

IT teams can access AWS IAM four ways: AWS Management Console, AWS Command Line Interface (CLI), SDKs and APIs. Each technique is used for different purposes, but the underlying IAM service is the same. IT pros use the AWS Management Console or AWS CLI to make requests that are processed through IAM, while applications use the SDK or API.

• Console. The AWS Management Console is the most common and familiar means of working with IAM. Individual users that routinely access AWS resources and services will generally log in and access AWS through the browser-based interface.
• CLI. Power users that require a faster or more efficient means of interacting with AWS can opt for the CLI or AWS Tools for Windows PowerShell. CLI tools are useful for tasks such as script building and automation.
• SDKs. AWS provides SDKs that include libraries that support software development projects in various languages. The SDKs enable developers to include programmatic requests and support access to IAM services.
• API. Rather than an SDK, programmers can use the IAM HTTPS API to make programmatic calls to AWS IAM. Users must include code to sign API calls with their AWS credentials.

IAM is essential to cloud security, but it also poses some complexity for inexperienced cloud administrators. Here are some best practices to enhance IAM effectiveness and help avoid common security mistakes.

Never use root credentials. A business might create a single AWS account with root credentials and then establish many different users and roles with other credentials. The root account should always be the most protected and secure entity within an AWS environment. Never use or share root credentials under any circumstances -- even for administrative activities.

Use groups for IAM policies. While it is possible and sometimes necessary to apply policies to individual users, it's better to apply group policies instead. For example, rather than managing policies for 10 individual HR staff members, put them into an HR group and apply a single HR policy to the entire group. This is faster and causes fewer oversights that compromise security. Groups also make it easier to move users as their jobs change.

Apply conditions to IAM policies. AWS users can apply conditions to policies that place additional stipulations on resource access. Conditions could include date and time limitations, IP source address ranges and require Secure Sockets Layer encryption. For example, conditions may specify that users must authenticate with MFA before they are allowed to terminate an EC2 instance. Conditions are not always necessary, but they add another layer of security for sensitive requests.

Use least privilege in IAM. The principle of least privilege gives users only the minimum access rights to do their job, and no more. Users and groups should be given only the minimum rights to accomplish necessary tasks.

Use MFA for better security. IAM supports multifactor authentication, which requires an additional credential based on a physical item that the user possesses. While MFA may not be appropriate for all cloud users, it is a useful addition for high-security users such as cloud administrators and senior business staff.

Use strong passwords. IAM allows cloud administrators to implement a custom password policy that can force stronger password selection -- such as longer strings with mixes of case, numerals and symbols -- and require regular password changes. Stronger passwords are more difficult to crack through systematic attempts and enhanced cloud security.  

Use unique access keys. Access keys are used as credentials for applications. Keys act as the password for applications. Encrypt all keys that are embedded in an application and never use the same key for more than one application. It may be safer and more effective to set up an application to receive temporary credentials using IAM roles rather than using access keys.

Remove outdated IAM credentials. Locate and remove IAM passwords and keys that are idle to increase security. Principals that no longer use IAM, such as users that left the company or deprecated applications, no longer need credentials. Remove those credentials to prevent the principals from accessing the environment in the future.

Review IAM policies and permissions regularly. Business and security needs change over time. Establishing and applying policies is just a start. Review and update policies on a regular basis to ensure that the organization's security posture meets business and compliance demands. If a group no longer needs a specific resource, remove that resource from the group policy to prevent unwarranted access.

Monitor the AWS account. Log files are a primary source of security information that yield details about user access, actions, outcomes and resource status. AWS provides logging features in multiple AWS services, including Amazon CloudFront, AWS CloudTrail, Amazon CloudWatch, AWS Config and Amazon Simple Storage Service. Cloud administrators should take advantage of every relevant log service to validate and maintain security in the AWS cloud.

Part of: A quick guide to AWS identity and access basics

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4