IAM & Organization


  • Registered with an e-mail address.
    • ❗ Not required for non-root accounts in AWS Organizations
    • Owner usually means the e-mail owner of the registered account.
  • Root Account
    • User with e-mail address that created the account.
    • 💡 Create new IAM user with administrator privileges and lock away root account credentials. NEVER USE ROOT ACCOUNT FOR EVERY DAY AWS ACTIVITY. It allows unlimited access on your resources, hence, it is safe to proceed with IAM user. Also enable MFA on root account.


  • Centralized control of your AWS account.
    • Each API call to AWS is authorized using IAM.
  • Shared Access to your AWS account
  • Global. Does not apply to regions.
    • So you will use the same IAM configuration no matter if you use one of all regions.
  • Identity Federation
    • Federating Users of Mobile/Web app using Cognito
      • Using Amazon Cognito will create identities (with the help of Mobile SDK) for users and sync across devices.
    • Federating Users with OpenID Connect (OIDC) or public identity service provider
      • Using third-party services like Facebook, Google or any identity providers (IdP) compatible with OIDC can federate users.
        • 💡 Amazon recommends against it, use Cognito or Web Identity Federation only for advanced scenarios.
    • Federating users with SAML 2.0
      • If companies managing users with identity store like Microsoft Active Directory and Active Directory Federation Service can federate users with single-sign on (SSO) to aws management console. Company can create trust between organization as an identity provider (IdP) and AWS as the service provider if it is compatible with SAML 2.0
    • Federating users by creating a custom identity brokers
      • If identity store is not compatible with SAML 2.0 then custom identity broker application can be built.
  • Multifactor Authentication
    • 💡 If your MFA device is lost/damaged/notworking:
      • You can sign in using alternative methods of authentication.
        • E.g. sign in by verifying your identity using the email and phone that are registered with your account.
  • Provide temporary access for users/devices and services where necessary
  • Supports password policies:
    • Enforce strong password
    • Password rotation policy, e.g. expire after 90 days.
  • Credential report: See which users are using what permissions.
  • Integrates with many different AWS services
  • Supports PCI DSS Compliance
  • IAM Certificate store: Legacy way to upload certificates, use Certification Manager instead.
  • IAM Query API to make direct calls to the IAM web service.

IAM Entities

IAM entities

  • Principal is an entity in AWS that can perform actions and access resources.
    • IAM Users
      • Programmatic Access: ID + secret key
        • Mostly for machines.
        • 💡 Best practice for services is to assume roles
        • Assigned an Access Key ID and Secret Access Key when first created.
        • Secrets are only shown once after created, then needs to be regenerated to reveal/download again.
        • ❗ IDs are permanent you need to manually rotate (make active/disable, delete or create new)
      • Console Access: Password
        • 💡 Ensure no one share same users by creating different users per person.
        • By default, newly created IAM users has no permissions.
    • IAM Roles
      • 💡 Use cases:
        • Create roles and can then assign them to AWS resources
        • Give cross-account access to users.
        • Instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it.
          • 💡 However for unique access of one you can delegate a role through:
            • In account add trust policy that specifies which trusted account members are allowed to assume the role.
            • The trust policy specifies which trusted account members (principals) are allowed to assume the role.
      • Credentials are rotated automatically -> Only temporary access.
        • Uses STS with expirations to generate secret id + secret key.
      • You can only assume one role a time
  • IAM Groups
    • A collection of users under one set of permissions (policies)
    • 💡 Use groups to assign permissions instead of individual users, because users in group inherit the permissions from groups.
    • A group is not an identity and cannot be identified as a principal in an IAM policy,
  • IAM Policies
    • JSON document that defines one (or more) permissions
    • Resource-based: To supported AWS resources, who can access them.
    • Identity-based: Assigned to roles, users, groups, who they can access.
    • Overlap => Deny overrides allow.
    • To define resources ARN’s are used (Amazon Resource Names) to uniquely identify AWS resources
    • 💡 Principle of Least Privilege: Always adhere to it when creating IAM user, restrict access with only resources/actions to do the job.

IAM Authentication to Services

  • Most of AWS services authenticates a user / role.
  • User / role (IAM) credentials must be sent in header
    • It’s called Sig v4 AWS Signature Version 4 Signing Process
    • You sign all requests with signed using an access key (derivation of access key ID + secret access key) in header
  • All requests to AWS API’s are signed automatically by SDK/CLI.

AWS Organizations

  • Consolidate multiple AWS accounts into an organization that you create and centrally manage
    • Enforce Service Control Policy (SCP) centrally on root or OU’s.
      • Also SCP has precedence over individual’s permission.
      • Best suitable for restricting access across multiple accounts in an organization.
  • Grouping all of your AWS accounts into Organizational Units (OUs) as part of a hierarchy
    • Hierarchical based control over groups of IAM users and roles, within multiple Accounts.
  • Allows Consolidated billing: Multiple standalone accounts are combined and may reduce your overall bill
    • They can still be tracked individually and the cost data can be downloaded in a separate file.
  • Allows you to create accounts programmatically.

Identity federation & SSO

  • Federation lets users outside of AWS to assume temporary role (using STS) for accessing AWS resources without having to create a user in AWS.
  • Federation assumes a form of 3rd party authentication e.g. LDAP, Microsoft Active Directory (=~ SAML), SSO, Open ID, Cognito
    • Single Sign On
    • Open ID
    • Cognito

AWS STS - Security Token Service

  • Allows to grant limited and temporary access (permissions) to AWS resources
  • Token is valid for between 15 minutes to one hour (must be refreshed)
  • Used mostly for:
    • Generates tokens when assuming roles.
    • Cross Account Access that allows users from one AWS account access resources in another
      • Flow
        1. Define an IAM role for another account to access
        2. Define which accounts can access this IAM role
        3. Use AWS STS (Security Token Service) to retrieve credentials and impersonate the IAM role you have access to (AssumeRole API)
    • Federation (Active Directory)
      • Provides a non-AWS user with temporary AWS access by linking users Active Directory credentials
      • Uses SAML (Security Assertion markup language)
      • Allows Single Sign On (SSO) which enables users to log in to AWS console without assigning IAM credentials
    • Federation with third party providers (Cognito & Web Identity Federation)
      • Cognito: Used mainly in web and mobile applications
      • Web Identity Federation: Makes use of Facebook/Google/Amazon etc. to federate them


  • STS is common service to create credentials after identity validation
    • Identity validation can be done through SAML, Cognito or Custom Identity Broker application.

SAML based federation

  • To integrate Active Directory / ADFS with AWS (or any SAML 2.0)
  • An IdP authenticates on on-prem store and then exchanges SAML assertion that has roles with STS to get a redirect URL with token.
  • SAML based federation

Custom Identity Broker Application

  • 💡 Use only if identity provider is not compatible with SAML 2.0
  • You have to program Identity Broker that must determine the appropriate IAM policy. Identity broker based federation

AWS Cognito

  • Managed identity broker for web identity federation
  • User pools
    • Handles registration, authentication, account recovery.
    • Synchronizes user data for your users, username etc.
      • Uses Push Synchronization to & SNS to push updates to sync data across multiple devices.
    • Includes JWT tokens from third party authentication providers.
  • Identity Pools
    • User directory for clients.
    • Allows users to obtain temporary AWS credentials to access AWS resources.
    • Flow
      • User logs into federated identity provider & gets third party authentication token.
      • Send third party authentication token to Cognito
        • Cognito returns Cognito ID with temporary AWS credentials
    • E.g. Provide (temporary) access to write to S3 bucket using Facebook Login
    • 💡 Good for authenticating B2B & B2C users for web + mobile applications.
  • Web Identity Federation
    • An alternative to Cognito
    • ❗ AWS recommends Web Identity Federation only for advanced scenarios.
    • 💡 Mostly try to use Cognito, because it does most of the behind-the-scenes work with public identity provider services for you.

AWS Single Sign On (SSO)

  • Centrally Managed Single Sign On across multiple AWS Accounts and Business Applications (Office 365, SalesForce, Box)
  • One login gets you access to management console securely
  • Integrated with Microsoft Active Directory
  • Only helpful for Web Browser, SAML 2.0 enabled applications.
    • E.g. IdP (Identity Provider) initiated single sign on

Cognito vs SSO

  • Amazon Cognito
    • Customer-targeted IAM and user directory solution.
    • For customers/developers building B2C or B2B apps for their customers
  • Amazon SSO
    • Focused on SSO for employees accessing AWS and business apps

AWS Directory Service

  • AWS managed Active Directory
  • 💡 Use cases
    • Can use it as an actual Microsoft Active Directory
    • Easily migrate directory-aware, on-premises workloads
    • Easily extend existing domains
    • 💡 Choose to integrate with on-prem ID if you don’t want to setup federation / SAML infrastructure for SSO
  • Integrations
    • SSO with corporate credentials to e.g. WorkSpaces, WorkDocs, or WorkMail.
    • AD-aware EC2 instances, RDS SQL etc.
  • AD Connector
    • Directory gateway to redirect directory requests to on-premises AD without caching any information in the cloud.
    • Eliminates the need for directory synchronization and the cost and complexity of hosting a federation infrastructure.
    • Enforce on-prem policies in cloud.
    • Use existing MFA infrastructure for MFA.
  • Simple Active Directory
    • Standalone managed directory.
    • Subset of features from Microsoft AD based Directory Service.
    • Easier to manage Linux

Encryption in AWS

Encryption in AWS

Encryption key

  • Two solutions currently exist for managing encryption keys:
    • Hardware security modules (HSM)
      • HSM = Hardware security module
      • Designed and certified to be tamper-evident and intrusion-resistant, provide the highest level of physical security, no hardware sharing.
      • AWS CloudHSM
        • Cloud-based hardware security module (HSM)
        • Single-tenant access to HSM, hardware maybe shared.
        • Enables you to easily generate and use your own encryption keys on the AWS Cloud.
        • Primarily intended to support customer-managed applications that are specifically designed to use HSMs
        • CloudHSM cluster contains at least two HSMs => min 1.000$ per month.
        • Can have automatic back-ups
        • Lose the keys => no way to recover
    • Key management services (KMS)
      • Also known as a cryptographic key management service (CKMS)
      • Enables clients to manage encryption keys without concerns about HSM appliance selection or provisioning
      • Usually come with more scalability, availability, native integration with other services such as databases, Bring Your Own Key (BYOK) that allows you use external HSM for master keys.
      • AWS KMS is AWS offering for a key service system.

AWS KMS - Key Management Service

  • An integrated & managed approach for generating, distributing and managing cryptographic keys for devices and applications
    • Managing a key includes maintaining their key policies, IAM policies, enabling/disabling them, rotating. adding tags. creating aliases, scheduling for deletion.
      • Rotation policies e.g. key must be changed ever year
  • Monitoring: Audit key usage using CloudTrail
  • Integrates with e.g. EBS (volumes), S3 (SSE), Redshift, RDS and SSM.
    • IAM for authorization: 💡 Can add external accounts that can use the key.
  • 💡 Managed KMS key per service is created for AWS services e.g. one for CodeCommit, one for RDS, one for S3, one for Lambda…
  • Has API’s in CLI /SDK
  • Customer Master Keys (CMKs)
Type Can view Can manage Account-specific Price
Customer managed CMK ✔️ ✔️ ✔️ Monthly fee key + usage
AWS managed CMK ✔️ ️✔️ No monthly fee, just usage
AWS owned CMK Free
  • ❗ The value in KMS is that the CMK (Customer Master Key) used to encrypt data can never be retrieved by the user.
  • The CMK can be rotated for extra security.
  • Encrypted secrets can be stored in the code / environment variables
    • E.g. encryption helpers in lambda environment variables.
    • No one can decrypt without having access through IAM
  • KMS can only help in encrypting up to 4KB of data per call
  • ❗ KMS can only encrypt up to 4KB of data per call
    • 📝 If data > 4 KB, use envelope encryption
    • Envelope encryption = Encrypt your key (data key) using master key.
  • To give access to KMS to someone
    • Make sure the Key Policy allows the user
    • Make sure the IAM Policy allows the API calls
  • Flow
    • Encrypt API: KMS checks IAM permissions & performs encryption & sends encrypted secret
    • Decrypt API: KMS check IAM permissions & performs decryption & sends decrypted secrets (in plain-text)

AWS Systems Manager - Systems Manager Parameter Store

  • Secure storage for configuration and secrets
  • (Optional) Seamless Encryption using KMS
    • Requires KMS policy to be activated
  • Serverless, scalable, durable, easy SDK, free
  • Version tracking of configurations / secrets
  • Configuration management using path & IAM
    • 💡 Best practice to give IAM role for reading only the needed parameter
    • For plain text configurations it’s enough to give SSM read permission
      • For decrypted parameters, you also need to give IAM permission to KMS.
  • Notification with CloudWatch Events
  • Integration with CloudFormation
  • Flow:
    • Application sends encrypted configuration to SSM Parameter Store
    • SSM Parameter Store checks IAM permissions
    • SSM Parameter Store decrypts configuration using AWS KMS
    • Application receives plain-text configuration from SSM Parameter Store.
  • Supports hierarchy, e.g. my-department/my-app/dev/db-url.
  • Configurations are retrieved using GetParameters or GetParametersByPath API.
  • Two ways of accessing from portal:
    1. EC2 Systems Manager - Parameter Store
    2. from AWS Systems Manager -> Parameter Store.
  • Two tier of parameters:
Feature Standard Advanced
Max parameter 10.000 No limit
Max value size 4 KB 8 KB
Parameter policies None Available
Pricing Free Charges apply
  • Parameter must have:
    • Name (e.g. /my-app/dev/db-url)
    • Type: String, StringList (comma separated), SecureString

Encryption types

  • Encryption in flight (SSL)
    • Data is encrypted before sending and decrypted after receiving
    • SSL certificates help with encryption (HTTPS = SSL enabled)
    • Encryption in flight ensures no MITM (man in the middle attack) can happen
      • I.e. No one inspecting the traffic can see data
    • Flow
      • You send data SSL encrypted with key and over HTTPS
      • Server (HTTPS website) decrypts data with SSL key.
  • Server side encryption at rest
    • Encryption/decryption is handled by server-side
      • Data is encrypted after being received by the server
      • Data is decrypted before being sent
    • Used by many AWS services
    • It’s stored in a encrypted form thanks to a key (usually a data key)
    • The encryption / decryption keys must be managed somewhere and the server must have access to it.
      • Usually stored in KMS (Key Management Service)
    • Flow
      • Object is being sent using HTTP(s)
        • Server (e.g. EBS AWS service) encrypts object with data key & saves it
      • Object is requested using HTTP(s)
        • Server decrypts object with data key & sends it
    • ❗ Requires migration (through Snapshot Backup) to enable/disable in EBS Volumes, RDS databases, ElastiCache, EFS
    • In S3, it’s in-place e.g. you encrypt & decrypt with parameters.
  • Client side encryption
    • Data is encrypted by the client and never decrypted by the server
    • Data will be decrypted by a receiving client
    • The server should never not be able to decrypt the data
    • 📝Could leverage Envelope Encryption
      • You encrypt encryption key with Envelope Key in KMS.
      • You manage encryption key, AWS manages Envelope Key.
    • Flow:
      • Client encrypts object with Client side data key & sends
      • Object is stored in encrypted form in AWS
      • Client retrieves encrypted object and decrypts with Client side data key

Licenses and Attributions

Speak Your Mind