We learn the IAM Key Features in this section.

The IAM Key Features include:

Multi-Factor Authentication (MFA)

  • adds an extra layer of security to AWS infrastructure
  • adds a second method of authentication
  • With MFA, authentication also requires entering a One-Time Password (OTP) from a small device.
  • MFA device can be small hardware device to carry or virtual device via an app on smart phone
  • MFA can be assigned to any IAM user account – whether person or application.
  • If IAM user is person with MFA, attempts to access AWS Management Console, after providing their password, will be prompted to enter current code displayed on their MFA device before being granted access.
  • For an IAM application with MFA, it must query application user to provide current code, which the application will then pass to the API.
  • recommended that AWS customers add MFA protection to their root user.

Rotating Keys

  • The security risk of any credential increases with age of credential.
  • Hence, security best practice is to rotate access keys associated with IAM users.
  • IAM facilitates this process by allowing two active access keys at a time.
  • The process to rotate keys can be conducted via the console, CLI, or SDKs:

Steps for rotating key implementation

  • Create a new access key for the user.
  • Reconfigure all applications to use the new access key.
  • Disable the original access key (disabling instead of deleting at this stage is critical, as it allows rollback to the original key if there are issues with the rotation).
  • Verify the operation of all applications.
  • Delete the original access key.

Resolving Multiple Permissions

  • multiple permissions will be applicable when determining whether a principal has privilege to perform some action.
  • permissions may come from multiple policies associated with a principal or resource policies attached to the AWS resource in question.
  • conflicts between these permissions are resolved, as
    • Initially the request is denied by default.
    • All the appropriate policies are evaluated; if there is an explicit “deny” found in any policy, the request is denied and evaluation stops.
    • Then, if no explicit “deny” is found and an explicit “allow” is found in any policy, the request is allowed.
    • If there are no explicit “allow” or “deny” permissions found, then the default “deny” is maintained and the request is denied.
  • Exception to it, if an AssumeRole call includes a role and a policy, the policy cannot expand the privileges of the role (for example, the policy cannot override any permission that is denied by default in the role).
Menu