AWS Security & Encryption
Why encryption? Encryption in flight (SSL)
• Data is encrypted before sending and decrypted after receiving
• SSL certificates help with encryption (HTTPS)
• Encryption in flight ensures no MITM (man in the middle attack) can happen
Why encryption? Server side encryption at rest
• Data is encrypted after being received by the server
• Data is decrypted before being sent
• It is stored in an 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
Why encryption? 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 not be able to decrypt the data
• Could leverage Envelope Encryption
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
KMS – Customer Master Key (CMK) 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 CMKs
• Necessary for envelope encryption
• You never get access to the 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
AWS KMS (Key Management Service)
• Able to fully manage the keys & policies:
• Create
• Rotation policies
• Disable
• Enable
• Able to audit key usage (using CloudTrail)
• Three types of Customer Master Keys (CMK):
• AWS Managed Service Default CMK: free
• User Keys created in KMS: $1 / month
• User Keys imported (must be 256-bit symmetric key): $1 / month
• + pay for API call to KMS ($0.03 / 10000 calls)
AWS KMS 101
• Anytime you need to share sensitive information… use KMS
• Database passwords
• Credentials to external service
• Private Key of SSL certificates
• The value in KMS is that the CMK used to encrypt data can never be retrieved by the user, and the CMK can be rotated for extra security
AWS KMS 101
• Never ever store your secrets in plaintext, especially in your code!
• Encrypted secrets can be stored in the code / environment variables
• KMS can only help in encrypting up to 4KB of data per call
• If data > 4 KB, use envelope encryption
• To give access to KMS to someone:
• Make sure the Key Policy allows the user
• Make sure the IAM Policy allows the API calls
birinci öz keyinle sifrele sonra gönderdikden sonra yeniden sifrelenir ve stapthot gönderilir
KMS Key Policies
• Control access to KMS keys, “similar” to S3 bucket policies
• Difference: you cannot control access without them
• Default KMS Key Policy:
• Created if you don’t provide a specific KMS Key Policy
• Complete access to the key to the root user = entire AWS account
• Gives access to the IAM policies to the KMS key
• Custom KMS Key Policy:
• Define users, roles that can access the KMS key
• Define who can administer the key
• Useful for cross-account access of your KMS key
1Create a Snapshot, encrypted with your own CMK
2. Attach a KMS Key Policy to authorize cross-account access
3. Share the encrypted snapshot
4. (in target) Create a copy of the Snapshot, encrypt it with a KMS Key in your account
5. Create a volume from the snapshot
KMS Automatic Key Rotation
• For Customer-managed CMK (not AWS managed CMK)
• If enabled: automatic key rotation happens every 1 year
• Previous key is kept active so you can decrypt old data
• New Key has the same CMK ID (only the backing key is changed)
KMS Manual Key Rotation
• When you want to rotate key every 90 days, 180 days, etc…
• New Key has a different CMK ID
• Keep the previous key active so you can decrypt old data
• Better to use aliases in this case (to hide the change of key for the application)
• Good solution to rotate CMK that are not eligible for automatic rotation (like asymmetric CMK)
KMS Multi -Region Keys
KMS Multi-Region Keys
• Identical KMS keys in different AWS Regions that can be used interchangeably
• Multi-Region keys have the same key ID, key material, automatic rotation…
• Encrypt in one Region and decrypt in other Regions
• No need to re-encrypt or making cross-Region API calls
• KMS Multi-Region are NOT global (Primary + Replicas)
• Each Multi-Region key is managed independently
• Use cases: global client-side encryption, encryption on Global DynamoDB, Global Aurora
DynamoDB Global Tables and KMS MultiRegion Keys Client-Side encryption
• We can encrypt specific attributes client-side in our DynamoDB table using the Amazon DynamoDB Encryption Client
• Combined with Global Tables, the client-side encrypted data is replicated to other regions
• If we use a multi-region key, replicated in the same region as the DynamoDB Global table, then clients in these regions can use lowlatency API calls to KMS in their region to decrypt the data client-side
• Using client-side encryption we can protect specific fields and guarantee only decryption if the client has access to an API key
Global Aurora and KMS Multi-Region Keys Client-Side encryption
• We can encrypt specific attributes client-side in our Aurora table using the AWS Encryption SDK
• Combined with Aurora Global Tables, the client-side encrypted data is replicated to other regions
• If we use a multi-region key, replicated in the same region as the Global Aurora DB, then clients in these regions can use low-latency API calls to KMS in their region to decrypt the data client-side
• Using client-side encryption we can protect specific fields and guarantee only decryption if the client has access to an API key, we can protect specific fields even from database admins
S3 Replication Encryption Considerations
• Unencrypted objects and objects encrypted with SSE-S3 are replicated by default
• Objects encrypted with SSE-C (customer provided key) are never replicated
• For objects encrypted with SSE-KMS, you need to enable the option
• Specify which KMS Key to encrypt the objects within the target bucket
• Adapt the KMS Key Policy for the target key
• An IAM Role with kms:Decrypt for the source KMS Key and kms:Encrypt for the target KMS Key
• You might get KMS throttling errors, in which case you can ask for a Service Quotas increase
• You can use multi-region AWS KMS Keys, but they are currently treated as independent keys by Amazon S3 (the object will still be decrypted and then encrypted)
AMI Sharing Process Encrypted via KMS
AMI in Source Account is encrypted with KMS Key from Source Account
Must modify the image attribute to add a Launch Permission which corresponds to the specified target AWS account
Must share the KMS Keys used to encrypted the snapshot the AMI references with the target account / IAM Role
The IAM Role/User in the target account must have the permissions to DescribeKey, ReEncrypted, CreateGrant, Decrypt
When launching an EC2 instance from the AMI, optionally the target account can specify a new KMS key in its own account to re-encrypt the volumes
SSM Parameter Store
• Secure storage for configuration and secrets
• Optional Seamless Encryption using KMS
• Serverless, scalable, durable, easy SDK
• Version tracking of configurations / secrets
• Configuration management using path & IAM
• Notifications with CloudWatch Events
• Integration with CloudFormation
AWS Secrets Manager
• Newer service, meant for storing secrets
• Capability to force rotation of secrets every X days
• Automate generation of secrets on rotation (uses Lambda)
• Integration with Amazon RDS (MySQL, PostgreSQL, Aurora)
• Secrets are encrypted using KMS
• Mostly meant for RDS integration
AWS Certificate Manager (ACM)
• Easily provision, manage, and deploy TLS Certificates
• Provide in-flight encryption for websites (HTTPS)
• Supports both public and private TLS certificates
• Free of charge for public TLS certificates
• Automatic TLS certificate renewal
• Integrations with (load TLS certificates on)
• Elastic Load Balancers (CLB, ALB, NLB)
• CloudFront Distributions
• APIs on API Gateway
• Cannot use ACM with EC2 (can’t be extracted)
ACM – Requesting Public Certificates
List domain names to be included in the certificate
• Fully Qualified Domain Name (FQDN): corp.example.com
• Wildcard Domain: *.example.com
Select Validation Method: DNS Validation or Email validation
• DNS Validation is preferred for automation purposes
• Email validation will send emails to contact addresses in the WHOIS database
• DNS Validation will leverage a CNAME record to DNS config (ex: Route 53)
It will take a few hours to get verified
The Public Certificate will be enrolled for automatic renewal
• ACM automatically renews ACM-generated certificates 60 days before expiry
ACM – Importing Public Certificates
• Option to generate the certificate outside of ACM and then import it
• No automatic renewal, must import a new certificate before expiry
• ACM sends daily expiration events starting 45 days prior to expiration
• The # of days can be configured
• Events are appearing in EventBridge
• AWS Config has a managed rule named acm-certificate-expiration-check to check for expiring certificates (configurable number of days)
API Gateway - Endpoint Types
• Edge-Optimized (default): For global clients
• Requests are routed through the CloudFront Edge locations (improves latency)
• The API Gateway still lives in only one region
• Regional:
• For clients within the same region
• Could manually combine with CloudFront (more control over the caching strategies and the distribution)
• Private:
• Can only be accessed from your VPC using an interface VPC endpoint (ENI)
• Use a resource policy to define access
ACM – Integration with API Gateway
• Create a Custom Domain Name in API Gateway
• Edge-Optimized (default): For global clients
• Requests are routed through the CloudFront Edge locations (improves latency)
• The API Gateway still lives in only one region
• The TLS Certificate must be in the same region as CloudFront, in us-east-1
• Then setup CNAME or (better) A-Alias record in Route 53
• Regional:
• For clients within the same region
• The TLS Certificate must be imported on API Gateway, in the same region as the API Stage
• Then setup CNAME or (better) A-Alias record in Route 53
AWS WAF – Web Application Firewall
• Protects your web applications from common web exploits (Layer 7)
• Layer 7 is HTTP (vs Layer 4 is TCP/UDP)
• Deploy on
• Application Load Balancer
• API Gateway
• CloudFront
• AppSync GraphQL API
• Cognito User Pool
WAF does not support the Network Load Balancer (Layer 4)
• We can use Global Accelerator for fixed IP and WAF on the ALB
AWS WAF – Web Application Firewall
• Define Web ACL (Web Access Control List) Rules:
• IP Set: up to 10,000 IP addresses – use multiple Rules for more IPs
• HTTP headers, HTTP body, or URI strings Protects from common attacks - SQL injection and Cross-Site Scripting (XSS)
• Size constraints, geo-match (block countries)
• Rate-based rules (to count occurrences of events) – for DDoS protection
• Web ACL are Regional except for CloudFront
• A rule group is a reusable set of rules that you can add to a web ACL
AWS Shield: protect from DDoS attack
• DDoS: Distributed Denial of Service – many requests at the same time
• AWS Shield Standard:
• Free service that is activated for every AWS customer
• Provides protection from attacks such as SYN/UDP Floods, Reflection attacks and other layer 3/layer 4 attacks
• AWS Shield Advanced:
• Optional DDoS mitigation service ($3,000 per month per organization)
• Protect against more sophisticated attack on Amazon EC2, Elastic Load Balancing (ELB), Amazon CloudFront, AWS Global Accelerator, and Route 53
• 24/7 access to AWS DDoS response team (DRP)
• Protect against higher fees during usage spikes due to DDoS
• Shield Advanced automatic application layer DDoS mitigation automatically creates, evaluates and deploys AWS WAF rules to mitigate layer 7 attacks
AWS Firewall Manager
• Manage rules in all accounts of an AWS Organization
• Security policy: common set of security rules
• WAF rules (Application Load Balancer, API Gateways, CloudFront)
• AWS Shield Advanced (ALB, CLB, NLB, Elastic IP, CloudFront)
• Security Groups for EC2, Application Load BAlancer and ENI resources in VPC
• AWS Network Firewall (VPC Level)
• Amazon Route 53 Resolver DNS Firewall
• Policies are created at the region level
• Rules are applied to new resources as they are created (good for compliance) across all and future accounts in your Organization
WAF vs. Firewall Manager vs. Shield
• WAF, Shield and Firewall Manager are used together for comprehensive protection
• Define your Web ACL rules in WAF
• For granular protection of your resources, WAF alone is the correct choice
• If you want to use AWS WAF across accounts, accelerate WAF configuration, automate the protection of new resources, use Firewall Manager with AWS WAF
• Shield Advanced adds additional features on top of AWS WAF, such as dedicated support from the Shield Response Team (SRT) and advanced reporting.
• If you’re prone to frequent DDoS attacks, consider purchasing Shield Advanced
AWS Best Practices for DDoS Resiliency Edge Location Mitigation (BP1, BP3)
• BP1 – CloudFront
• Web Application delivery at the edge
• Protect from DDoS Common Attacks (SYN floods, UDP reflection…)
• BP1 – Global Accelerator
• Access your application from the edge
• Integration with Shield for DDoS protection
• Helpful if your backend is not compatible with CloudFront
• BP3 – Route 53
• Domain Name Resolution at the edge
• DDoS Protection mechanism
AWS Best Practices for DDoS Resiliency Best pratices for DDoS mitigation
• Infrastructure layer defense (BP1, BP3, BP6)
• Protect Amazon EC2 against high traffic
• That includes using Global Accelerator, Route 53, CloudFront, Elastic Load Balancing
• Amazon EC2 with Auto Scaling (BP7)
• Helps scale in case of sudden traffic surges including a flash crowd or a DDoS attack
• Elastic Load Balancing (BP6)
• Elastic Load Balancing scales with the traffic increases and will distribute the traffic to many EC2 instances
AWS Best Practices for DDoS Resiliency Application Layer Defense
• Detect and filter malicious web requests (BP1, BP2)
• CloudFront cache static content and serve it from edge locations, protecting your backend
• AWS WAF is used on top of CloudFront and Application Load Balancer to filter and block requests based on request signatures
• WAF rate-based rules can automatically block the IPs of bad actors
• Use managed rules on WAF to block attacks based on IP reputation, or block anonymous Ips
• CloudFront can block specific geographies
• Shield Advanced (BP1, BP2, BP6)
• Shield Advanced automatic application layer DDoS mitigation automatically creates, evaluates and deploys AWS WAF rules to mitigate layer 7 attacks
AWS Best Practices for DDoS Resiliency Attack surface reduction
• Obfuscating AWS resources (BP1, BP4, BP6)
• Using CloudFront, API Gateway, Elastic Load Balancing to hide your backend resources (Lambda functions, EC2 instances)
• Security groups and Network ACLs (BP5)
• Use security groups and NACLs to filter traffic based on specific IP at the subnet or ENI-level
• Elastic IP are protected by AWS Shield Advanced
• Protecting API endpoints (BP4)
• Hide EC2, Lambda, elsewhere
• Edge-optimized mode, or CloudFront + regional mode (more control for DDoS)
• WAF + API Gateway: burst limits, headers filtering, use API keys
Amazon GuardDuty
• Intelligent Threat discovery to Protect AWS Account
• Uses Machine Learning algorithms, anomaly detection, 3rd party data
• One click to enable (30 days trial), no need to install software
• Input data includes:
• CloudTrail Events Logs – unusual API calls, unauthorized deployments
• CloudTrail Management Events – create VPC subnet, create trail, …
• CloudTrail S3 Data Events – get object, list objects, delete object, …
• VPC Flow Logs – unusual internal traffic, unusual IP address
• DNS Logs – compromised EC2 instances sending encoded data within DNS queries
• Kubernetes Audit Logs – suspicious activities and potential EKS cluster compromises
• Can setup CloudWatch Event rules to be notified in case of findings
• CloudWatch Events rules can target AWS Lambda or SNS
• Can protect against CryptoCurrency attacks (has a dedicated “finding” for it)
Amazon Inspector
• Automated Security Assessments
• For EC2 instances
• Leveraging the AWS System Manager (SSM) agent
• Analyze against unintended network accessibility
• Analyze the running OS against known vulnerabilities
• For Containers push to Amazon ECR
• Assessment of containers as they are pushed
• Reporting & integration with AWS Security Hub
• Send findings to Amazon Event Bridge
]
What does AWS Inspector evaluate?
• Remember: only for EC2 instances and container infrastructure
• Continuous scanning of the infrastructure, only when needed
• Package vulnerabilities (EC2 & ECR) – database of CVE
• Network reachability (EC2)
• A risk score is associated with all vulnerabilities for prioritization
Amazon Macie
• Amazon Macie is a fully managed data security and data privacy service that uses machine learning and pattern matching to discover and protect your sensitive data in AWS.
• Macie helps identify and alert you to sensitive data, such as personally identifiable information (PII)
Amazon Macie is a fully managed data security service that uses Machine Learning to discover and protect your sensitive data stored in S3 buckets. It automatically provides an inventory of S3 buckets including a list of unencrypted buckets, publicly accessible buckets, and buckets shared with other AWS accounts. It allows you to identify and alert you to sensitive data, such as Personally Identifiable Information (PII).
CloudHSM
• KMS => AWS manages the software for encryption
• CloudHSM => AWS provisions encryption hardware
• Dedicated Hardware (HSM = Hardware Security Module)
• You manage your own encryption keys entirely (not AWS)
• HSM device is tamper resistant, FIPS 140-2 Level 3 compliance
• Supports both symmetric and asymmetric encryption (SSL/TLS keys)
• No free tier available
• Must use the CloudHSM Client Software
• Redshift supports CloudHSM for database encryption and key management
• Good option to use with SSE-C encryption
CloudHSM vs. KMS
AWS Shared Responsibility Model
• AWS responsibility - Security of the Cloud
• Protecting infrastructure (hardware, software, facilities, and networking) that runs all the AWS services
• Managed services like S3, DynamoDB, RDS, etc.
• Customer responsibility - Security in the Cloud
• For EC2 instance, customer is responsible for management of the guest OS (including security patches and updates), firewall & network configuration, IAM
• Encrypting application data
• Shared controls:
• Patch Management, Configuration Management, Awareness & Training
Example, for RDS
• AWS responsibility:
• Manage the underlying EC2 instance, disable SSH access
• Automated DB patching
• Automated OS patching
• Audit the underlying instance and disks & guarantee it functions
• Your responsibility:
• Check the ports / IP / security group inbound rules in DB’s SG
• In-database user creation and permissions
• Creating a database with or without public access
• Ensure parameter groups or DB is configured to only allow SSL connections
• Database encryption setting
Example, for S3
• AWS responsibility:
• Guarantee you get unlimited storage
• Guarantee you get encryption
• Ensure separation of the data between different customers
• Ensure AWS employees can’t access your data
• Your responsibility:
• Bucket configuration
• Bucket policy / public setting
• IAM user and roles
• Enabling encryption
Last updated