The Identity and Access Management (IAM) service controls access for individuals, teams, and AWS services. For direct access to the AWS console and API's, AWS recommends segmenting IAM users by groups and attaching IAM policies to those groups. There are four default groups created for your account:

  • auditors - intended to be used for granting access to individuals responsible for verifying compliance and security posture. Permissions are listed in the SecurityAudit managed AWS policy.
  • developers - for developers who need access to application deployment and storage services. Permissions are listed in the developers-access custom policy; certain destructive actions in various services have been disabled.
  • external_admin_systems - for use by Healthcare Blocks external management systems responsible for configuration management.
  • system_admins - for individuals responsible for monitoring AWS services and security events. Permissions are listed in the system-admins-access custom policy.

Changes to the policies associated with the above groups should be requested through a support ticket.

Note that AWS recommends against the use of the AdministrativeAccess IAM policy and similar variants. Providing full administrative privileges instead of restricting to the minimum set of permissions that the user is required to do exposes the resources to potentially unwanted actions.

FAQ: why shouldn't we attach AWS managed policies to IAM groups?
Unfortunately AWS allows only 10 managed policies to be associated with IAM groups, making it extremely difficult to grant access to a broader set of services.

Multi-Factor Authentication
AWS recommends the use of multi-factor authentication (MFA) for any user that has AWS console and external API access (e.g. AWS CLI). The multifactor-auth-enforcement IAM policy attached to the above IAM user groups enforces the use of MFA, which can be facilitated through a virtual device such as a password manager app that supports MFA tokens or a hardware key. AWS has published compatible solutions on

Use a Hardware MFA Device for the Root Account 
AWS recommends using a hardware multi-factor authentication (MFA) device for the root account. Instructions for activating the device can be found on this page.

Creating a New IAM User for Console Access

  1. Go to IAM and Users
  2. Enter a User name, select AWS Management Console access and choose the Autogenerated password option, requiring password at next sign-in
  3. Attach one of the IAM user groups
  4. The login credentials should be shared securely with the person at the moment the individual is ready to sign into the console.

Activating a New User Account
When a new IAM user signs into the AWS console for the first time, he/she will be required to change their password. The individual should then click their name in the top navigation bar and go to My Security Credentials to register a device under the Multi-factor authentication section. After the device is registered, the individual should sign out of the console and sign back in. At that point, he/she will have access to the services associated with their IAM user group.

Password Policy
The current AWS console password policy can be found under IAM / Account settings. The policy's configuration adheres to the CIS AWS Foundations Benchmark and should not be modified. One of the requirements is for passwords to be reset every 90 days. IAM console users will be automatically prompted to change their password when it is close to expire/has expired.

Avoiding Root Account Usage
New AWS accounts start with a primary ("root") account. AWS advises that this account can be used for initial setup of access and billing but going forward, it should not be used for daily activities. Minimizing the use of this account and adopting the principle of least privilege for access management reduces the risk of accidental changes and unintended disclosure of highly privileged credentials. A CloudWatch alarm, root-account-usage, has been created to monitor the root account.

AWS API Access
AWS services such as EC2 include the ability to attach IAM "roles" which define the permissions available for interacting with other AWS services. Instead of creating an IAM user and credentials for your applications, the recommended practice is to defer to the roles associated with your instances or containers. Healthcare Blocks manages IAM roles for your instances / containers, therefore if your application needs access to a specific compute or database service, please create a support request.

For individuals who need to make programmatic calls to AWS from the AWS CLI, Tools for PowerShell, AWS SDKs, or direct AWS API calls from outside of the AWS environment, a set of IAM access keys will need to be created. Individuals can have a maximum of two access keys (active or inactive) at a time. Go to the IAM user's profile and click the Security credentials tab. Create an access key and secret key and share them securely with the end user. IAM access keys should be rotated every 90 days per CIS Benchmark 1.4.

Individuals should protect any IAM keys stored on their local machine. Healthcare Blocks recommends using the cross-platform aws-vault tool. The additional benefit of using this tool is that it can help facilitate the MFA token step when authenticating to the AWS APIs.