Security

• 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)
• CloudTrail 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

  • 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
• CloudTrail Events Retention

  • Events are stored for 90 days in CloudTrail

  • To keep events beyond this period, log them to S3 and use Athena
• If you have created an organization in AWS Organizations, you can create a trail that logs all events for all AWS accounts in that organization.
• 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
• 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)
• KMS - Key Types

  • 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
• KMS 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
• KMS 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
• KMS 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
• KMS Key Source – 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
• 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
• SSM Parameter Store

  • Secure storage for configuration and secrets

  • Optional Seamless Encryption using KMS

  • Serverless, scalable, durable, easy SDK

  • Version tracking of configurations / secrets

  • Security through IAM
• AWS Secrets Manager

  • Meant for storing secrets (e.g., passwords, API keys, …)

  • Capability to force rotation of secrets every X days

  • Automate generation of secrets on rotation (uses Lambda)

  • Natively supports Amazon RDS (all supported DB engines), Redshift, DocumentDB

  • Support other databases and services (custom Lambda

  function)
• SSM Parameter Store vs Secrets Manager

  • Secrets Manager ($$$):

  • Automatic rotation of secrets with AWS Lambda

  • Lambda function is provided for RDS, Redshift, DocumentDB

  • KMS encryption is mandatory

  • Can integration with CloudFormation

  • SSM Parameter Store ($):

  • Simple API

  • No secret rotation (can enable rotation using Lambda triggered by EventBridge)

  • KMS encryption is optional

  • Can integration with CloudFormation

  • Can pull a Secrets Manager secret using the SSM Parameter Store API]
• RDS - Security

  • KMS encryption at rest for underlying EBS volumes / snapshots

  • Transparent Data Encryption (TDE) for Oracle and SQL Server

  • SSL encryption to RDS is possible for all DB (in-flight)

  • IAM authentication for MySQL, PostgreSQL and MariaDB

  • Authorization still happens within RDS (not in IAM)

  • Can copy an un-encrypted RDS snapshot into an encrypted one

  • CloudTrail cannot be used to track queries made within RDS
• SSL – Server Name Indication (SNI)

  • SNI solves the problem of loading multiple SSL certificates onto one web server (to serve multiple websites)

  • It’s a “newer” protocol, and requires the client to indicate the hostname of the target server in the initial SSL handshake

  • The server will then find the correct certificate, or return the default one

  Only works with ALB & NLB, not CLB
• SSL – Man in the Middle Attack How to prevent

  Use a DNS that has DNSSEC

  • To send a client to a pirate server, a DNS response needs to be “forged” by a server which intercepts them

  • It is possible to protect your domain name by configuring DNSSEC

  • Amazon Route 53 supports DNSSEC for domain registration.

  • Route 53 supports DNSSEC for DNS service as of December 2020 (using KMS)

  • You could also run a custom DNS server on Amazon EC2 for example (Bind is the most popular, dnsmasq, KnotDNS, PowerDNS).
• AWS Certificate Manager (ACM)

  • To host public SSL certificates in AWS, you can:

  • Buy your own and upload them using the CLI

  • Have ACM provision and renew public SSL certificates for you (free of cost)

  • ACM loads SSL certificates on the following integrations:

  • Load Balancers (including the ones created by Beanstalk)

  • CloudFront distributions

  • APIs on API Gateways
• ACM – Good to know

  • Possibility of creating public certificates

  • Must verify public DNS

  • Must be issued by a trusted public certificate authority (CA)

  • Possibility of creating private certificates

  • For your internal applications

  • You create your own private CA

  • Your applications must trust your private CA
• ACM - Good to know

  • Certificate renewal:

  • Automatically done if generated provisioned by ACM

  • Any manually uploaded certificates must be renewed manually and re-uploaded

  • ACM is a regional service

  • To use with a global application (multiple ALB for example), you need to issue an SSL certificate in each region where you application is deployed.

  • You cannot copy certs across region
• 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
• S3 Encryption for Objects

  • SSE-S3: encrypts S3 objects using keys handled & managed by AWS

  • SSE-KMS: leverage KMS to manage encryption keys

  • Key usage appears in CloudTrail

  • objects made public can never be read

  • On s3:PutObject, make the permission kms:GenerateDataKey is allowed

  • SSE-C: when you want to manage your own encryption keys

  • Client-Side Encryption

  • Glacier: all data is AES-256 encrypted, key under AWS control
• HTTPS is mandatory for SSE-C
• Events in S3 Buckets

  • S3 Access Logs:

  • Detailed records for the requests that are made to a bucket

  • Might take hours to deliver

  • Might be incomplete (best effort)
• S3 Events Notifications:

  • Receive notifications when certain events happen in your bucket

  • E.g.: new objects created, object removal, restore objects, replication events

  • Destinations: SNS, SQS queue, Lambda

  • Typically delivered in seconds but can take minutes, notification for every object if versioning is

  enabled, else risk of one notification for two same object write done simultaneousl
• Events in S3 Buckets

  Trusted Advisor:

  • Check the bucket permission (is the bucket public?)

  Amazon EventBridge:

  • Need to enable CloudTrail object level logging on S3 first

  • Target can be Lambda, SQS, SNS, etc…
• S3 Security

  • User based

  • IAM policies - which API calls should be allowed for a specific user from IAM console

  Resource Based

  • Bucket Policies - bucket wide rules from the S3 console - allows cross account

  • Object Access Control List (ACL) – finer grain

  • Bucket Access Control List (ACL) – less common
• Use S3 bucket for policy to:

  • Grant public access to the bucket

  • Force objects to be encrypted at upload

  • Grant access to another account (Cross Account)
• S3 Bucket Policies Optional Conditions on:

  • SourceIp: Public IP or Elastic IP | VpcSourceIp: Private IP (through VPC Endpoint)

  • Source VPC or Source VPC Endpoint – only works with VPC Endpoints

  • CloudFront Origin Identity

  • MFA
• Can generate S3 pre-signed URLs using SDK or CLI. Which is valid for a default of 3600 that can be changed.
• S3 Object Lock & Glacier Vault Lock

  S3 Object Lock

  • Adopt a WORM (Write Once Read Many) model

  • Block an object version deletion for a specified amount of time

  Glacier Vault Lock

  • Adopt a WORM (Write Once Read Many) model

  • Lock the policy for future edits (can no longer be changed)

  • Helpful for compliance and data retention
• S3 - Access Points

  • Access Points simplify security management for S3 Buckets

  • Each Access Point has:

  • its own DNS name (Internet Origin or VPC Origin)

  • an access point policy (similar to bucket policy) – manage security at scale
• S3 Access Points can be configured to be accessible only from within the VPC. To access the Access Point, you must create a VPC Endpoint (Gateway or Interface Endpoint). The VPC Endpoint Policy must allow access to the target bucket and Access Point¹².
• Amazon S3 Multi-Region Access Points provide a global endpoint for routing Amazon S3 request traffic between AWS Regions. With S3 Multi-Region Access Points, you can create a single access point name that is globally unique and can be used to access objects stored in Amazon S3 buckets across multiple regions. This means that you no longer need to manage multiple access points, each with its unique name, in each region where your data is stored
• S3 Object Lambda is a feature of Amazon S3 that allows you to add your own code to modify and process data as it is returned to an application.
• DDoS Protection on AWS

  • AWS Shield Standard: protects against DDoS attack for your website and applications, for all customers at no additional costs

  • AWS Shield Advanced: 24/7 premium DDoS protection

  • AWS WAF: Filter specific requests based on rules

  • CloudFront and Route 53:

  • Availability protection using global edge network

  • Combined with AWS Shield, provides DDoS attack mitigation at the edge

  • Be ready to scale – leverage AWS Auto Scaling

  • Separate static resources (S3 / CloudFront) from dynamic ones (EC2 / ALB)
• AWS Shield

  • 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, Route 53

  • 24/7 access to AWS DDoS response team (DRP)

  • Protect against higher fees during usage spikes due to DDoS
• AWS WAF – Web Application Firewall

  • Protects your web applications from common web exploits (Layer 7)

  • Deploy on Application Load Balancer (localized rules)

  • Deploy on API Gateway (rules running at the regional or edge level)

  • Deploy on CloudFront (rules globally on edge locations)

  • Used to front other solutions: CLB, EC2 instances, custom origins, S3 websites

  • Deploy on AppSync (protect your GraphQL APIs)