1) CloudTrail
1.1) AWS CloudTrail
• Provides governance, compliance and audit for your AWS Account
• CloudTrail is enabled by default!
• Get a history of events / API calls made within your AWS Account by:
• Console
• SDK
• CLI
• AWS Services
• Can put logs from CloudTrail into CloudWatch Logs or S3
• A trail can be applied to All Regions (default) or a single Region.
• If a resource is deleted in AWS, investigate CloudTrail first!
1.2) CloudTrail Diagram
1.3) CloudTrail Events
• Management Events:
• Operations that are performed on resources in your AWS account
• Examples:
• Configuring security (IAM AttachRolePolicy)
• Configuring rules for routing data (Amazon EC2 CreateSubnet)
• Setting up logging (AWS CloudTrail CreateTrail)
• By default, trails are configured to log management events.
• Can separate Read Events (that don’t modify resources) from Write Events (that may modify resources)
• Data Events:
• By default, data events are not logged (because high-volume operations)
• Amazon S3 object-level activity (ex: GetObject, DeleteObject, PutObject): can separate Read and Write Events
• AWS Lambda function execution activity (the Invoke API)
• CloudTrail Insights Events:
• See next slide
1.4) CloudTrail Insights
• Enable CloudTrail Insights to detect unusual activity in your account:
• inaccurate resource provisioning
• hitting service limits
• Bursts of AWS IAM actions
• Gaps in periodic maintenance activity
• CloudTrail Insights analyzes normal management events to create a baseline
• And then continuously analyzes write events to detect unusual patterns
• Anomalies appear in the CloudTrail console
• Event is sent to Amazon S3
• An EventBridge event is generated (for automation needs)
1.5) CloudTrail Events Retention
• Events are stored for 90 days in CloudTrail
• To keep events beyond this period, log them to S3 and use Athena
1.6 CloudTrail – Solution Architecture:
1.6.1) Delivery to S3
1.6.2) Multi-Account, Multi-Region Logging
1.6.3) Alert for API calls
• Log filter metrics can be used to detect a high level of API happening
• Ex: Count occurrences of EC2 TerminateInstances API
• Ex: Count of API calls per user
• Ex: Detect high level of Denied API calls
1.6.4) Organizational Trail
1.7) CloudTrail: How to react to events the fastest?
Overall, CloudTrail may take up to 15 minutes to deliver events
• EventBridge:
• Can be triggered for any API call in CloudTrail
• The fastest, most reactive way
• CloudTrail Delivery in CloudWatch Logs:
• Events are streamed
• Can perform a metric filter to analyze occurrences and detect anomalies
• CloudTrail Delivery in S3:
• Events are delivered every 5 minutes
• Possibility of analyzing logs integrity, deliver cross account, long-term storage
2) KMS
2.1) AWS KMS (Key Management Service)
• Anytime you hear “encryption” for an AWS service, it’s most likely KMS
• Easy way to control access to your data, AWS manages keys for us
• Fully integrated with IAM for authorization
• Seamlessly integrated into:
• Amazon EBS: encrypt volumes
• Amazon S3: Server-side encryption of objects
• Amazon Redshift: encryption of data
• Amazon RDS: encryption of data
• Amazon SSM: Parameter store
• Etc…
• But you can also use the CLI / SDK
2.2) KMS – KMS Key Types
• Symmetric (AES-256 keys)
• First offering of KMS, single encryption key that is used to Encrypt and Decrypt
• AWS services that are integrated with KMS use Symmetric KMS keys
• Necessary for envelope encryption
• You never get access to the KMS key unencrypted (must call KMS API to use)
• Asymmetric (RSA & ECC key pairs)
• Public (Encrypt) and Private Key (Decrypt) pair
• Used for Encrypt/Decrypt, or Sign/Verify operations
• The public key is downloadable, but you can’t access the Private Key unencrypted
• Use case: encryption outside of AWS by users who can’t call the KMS API
2.3) Types of KMS Keys
• Customer Managed Keys
• Create, manage and use, can enable or disable
• Possibility of rotation policy (new key generated every year, old key preserved)
• Can add a Key Policy (resource policy) & audit in CloudTrail
• Leverage for envelope encryption
• AWS Managed Keys
• Used by AWS service (aws/s3, aws/ebs, aws/redshift)
• Managed by AWS (automatically rotated every 1 year)
• View Key Policy & audit in CloudTrail
• AWS Owned Keys
• Created and managed by AWS, use by some AWS services to protect your resources
• Used in multiple AWS accounts, but they are not in your AWS account
• You can’t view, use, track, or audit
2.4) KMS Key Material Origin
• Identifies the source of the key material in the KMS key
• Can’t be changed after creation
• KMS (AWS_KMS) – default
• AWS KMS creates and manages the key material in its own key store
• External (EXTERNAL)
• You import the key material into the KMS key
• You’re responsible for securing and managing this key material outside of AWS
• Custom Key Store (AWS_CLOUDHSM)
• AWS KMS creates the key material in a custom key store (CloudHSM Cluster
2.5) KMS Key Source
2.5.1) Custom Key Store (CloudHSM)
• Integrate KMS with CloudHSM cluster as a Custom Key Store
• Key materials are stored in a CloudHSM cluster that you own and manage
• The cryptographic operations are performed in the HSMs
• Use cases:
• You need direct control over the HSMs
• KMS keys needs to be stored in a dedicated HSMs
• HSMs must be validated at FIPS 140-2 Level 3 (KMS validated at FIPS 140-2 Level 2)
2.5.2) External
• Import your own key material into KMS key, Bring Your Own Key (BYOK)
• You’re responsible for key material’s security, availability, and durability outside of AWS
• Must be 256-bit Symmetric key (Asymmetric is NOT supported)
• Can’t be used with Custom Key Store (CloudHSM)
• Manually rotate your KMS key (Automatic Key Rotation is NOT supported)
2.6) KMS Multi-Region Keys
• A set of identical KMS keys in different AWS Regions that can be used
interchangeably (~ same KMS key in multiple Regions)
• Encrypt in one Region and decrypt in other Regions (No need to re-encrypt or making cross-Region API calls)
• Multi-Region keys have the same key ID, key material, automatic rotation, …
• KMS Multi-Region are NOT global (Primary + Replicas)
• Each Multi-Region key is managed independently
• Only one primary key at a time, can promote replicas into their own primary
• Use cases: Disaster Recovery, Global Data Management (e.g., DynamoDB Global Tables), Active-Active Applications that span multiple Regions, Distributed Signing applications, …
