Users (one physical user = one AWS user) and Groups (groups contain only users, no subgroups)
The permissions boundary for an IAM entity (user or role) sets the max permissions that the entity can have
IAM Role
Roles hand out automatic credentials and permissions
Giving permissions to non-humans, such as services / applications
Giving permissions to federated / outside users & groups
Authorisations from identity providers (like AWS Cognito) are mapped to your IAM role(s), NOT users or groups
to pass the role to service, the users need to have iam:PassRole permission; to see, using iam:GetRole
Roles can only passed to what their trust allows, using “Trust Relationships”
IAM Policies
assign permissions, using JSON documents
using “least privilege principle”
consist of
version
id (optional)
statement
Sid (optional)
Effect: Allow or Deny
Principal: account/user/group/role
Action: list of action, like S3:GetObject, S3:PutObject, iam:PassRole, iam:GetRole
Resource: AWS resource
Condition (optional)
Permission Evaluation Flow
If there’s explicit DENY, end flow with DENY
Else, if there is an ALLOW, end flow with ALLOW
Else, DENY
Dynamic Policy, with variable as ${aws:username}
Policy Management
AWS Managed Policy
Customer Managed Policy, has version control + rollback
Inline Policy, strict 1-to-1 relationship with principal; would be also deleted while delete principal
IAM Password Policy, set minimum length, require specific character types (number, upper/lower-case letters, non-alphabetic), expiration, and re-use forbidden
Multi Factor Authentication (MFA)
IAM Security/Audit Tools
IAM Credentials Report (account-lv)
IAM Access Advisor (user-lv), for check/revise the permissions granted with usage
AWS Certificate Manager (ACM)
manage SSL/TLS certificates, for in-flight encryption of websites (HTTPS)
SSL refers to Secure Sockets Layer, used to encrypt connections
TLS refers to Transport Layer Security, which is a newer version
request temporary limited-privilege (15mins to 1 hour) credentials for IAM users, or for users that you authenticate such as federated users from an on-prem directory
APIs
AssumeRole
AssumeRoleWithSAML
AssumeRoleWithWebIdentity -> using Cognito Identity Pools instead
GetSessionToken, for MFA (returns “Access ID”, “Secret Key”, “Session Token”, and “Expiration Date”)
GetFederationToken
GetCallerIdentity
DecodeAuthorizationMessage
STS for MFA, needs
using GetSessionToke api
in IAM Policy, need set in Conditions (in statement), as “aws:MultiFactorAuthPresent:true”
Federation: STS can be used Federation (typically with Azure AD). It uses SAML 2.0 for authentication to grant temporary access based on the AD creds
Single Sign-On: STS can be used to develop a custom identity broker for SSO to a service such as the AWS management console:
Verify that the user is authenticated on the local IDP (AD)
Call STS AssumeRole or GetFederationToken API to get temp credentials
Pass the temp creds to AWS federation endpoint to request a sign-in token
Construct a URL to the service that includes the token which can be provided to the user
AWS Directory Services
for MS Active Directory (AD), with AD Domain Services
AWS Managed Microsoft AD
an AD instance on AWS, connecting as “trust” with on-premise AD; users are managed on AWS locally; support MFA
AD Connector
as (Directory Gateway) proxy only, using on-premise AD to manage; support MFA
Simple AD
a seperate AD on AWS, no connection with on-premise AD
Encryption
Best practice is to lock away or delete the root user access keys. Never store in an S3 bucket, even if encrypted
Never ever store your secrets in plaintext, especially in your code!
Encryption in flight
SSL/TLS is for encrypting data in transit, not data at rest.
SSL/TLS is synonymous with HTTPS traffic. It goes over port 443.
Server-side encryption at rest
Data is encrypted after being received by the server, and decrypted before being sent
So the data stored is in an encrypted from
Types
SSE-C: use customer-provided keys and manage them yourself
SSE-S3, SSE-SQS, SSE-DDB: Amazon manages the keys
SSE-KMS: keys are managed in Amazon Key Management Service
CloudHSM: generate and use your own encryption keys, held in the cloud in Amazon’s HSM
Client-side encryption
Data stored is also in an encrypted from
but the is encrypted before sending to the server, and decrypted in client side after being received
AWS Key Management Service (KMS)
AWS manages encryption keys for us
Fully integrated with IAM for authorization
Able to audit KMS Key usage using CloudTrail
KMS Keys is the new name of KMS Customer Master Key (KMS CMK)
Symmetric (AES-256 keys)
AWS services default
must call KMS API
encrypt up to 4 KB of data through KMS
to encrypt > 4KB with KMS Encrypt API call, need to use Envelope Encryption (aka GenerateDataKey API), let client side to Encrypt/Decrypt with DEK received
GenerateDataKey: generates a unique symmetric data key (DEK)
returns a plaintext copy of the data key
AND a copy that is encrypted under the CMK
GenerateDataKeyWithoutPlaintext
Generate a DEK that is encrypted under the CMK
Decrypt: decrypt up to 4 KB of data (also “Data Encryption Keys”)
AWS Managed Key (free): aws/service-name, automatic renew every 1 year
Customer managed keys created in KMS: $1 / month, can be renewed automatic & on-demand
Customer managed keys imported: $1 / month, only manual rotation
AWS Encryption SDK has already implemented Envelope Encryption
the feature – Data Key Caching, can reuse the data keys, with LocalCryptoMaterialsCache
Request Quotas: if got ThrottlingException, use exponential backoff (backoff and retry); and all cryptographic operations (aka Encrypt and Decrypt), they share a quota
To hugely reduce the cost on S3 encryption, use “S3 Bucket Key”
CloudHSM
Compared with KMS, AWS provisions encryption with dedicated hardware (HSM = Hardware Security Module)
Encryption keys are managed on client side
Good option to use with SSE-C encryption
CloudHSM clusters are spread across Multi AZ (HA)
AWS System Manager (SSM) Parameter Store
Secure storage for configuration and secrets
Version tracking of configurations / secrets
Allow to assign a TTL to a parameter (expiration date) to force updating or deleting sensitive data such as passwords
AWS Secrets Manager
Capability to force rotation of secrets every X days
Automate generation of secrets on rotation (uses Lambda)
Integration with Amazon RDS (MySQL, PostgreSQL, Aurora)
Mostly meant for RDS integration
AWS Nitro Enclaves
Process highly sensitive data in an isolated compute environment (like Personally Identifiable Information (PII), healthcare, financial, …)
Fully isolated virtual machines, hardened, and highly constrained (Not a container, not persistent storage, no interactive access, no external networking)
Helps reduce the attack surface for sensitive data processing apps
Cryptographic Attestation – only authorized code can be running in your Enclave
Only Enclaves can access sensitive data (integration with KMS)
Amazon GuardDuty
use with CloudWatch+SNS to trigger notifications to services
AWS Accounts
To apply security restrictions across multiple AWS accounts, use Service Control Policy (SCP). For just a single account, use IAM policies.
You can migrate an account to another AWS organization, e.g. if you divest a business unit