BCSE355L

AWS Solutions Architect

Dr. [Link]
Assistant Professor Senior Grade II
School of Computer Science and Engineering
Vellore Institute of Technology, Vellore
 BCSE355L -AWS Solutions Architect

Module 6
 AWS Security
• TLS encryption is used.
 Server side (at rest)
• Data is encrypted after being received by the
server.
 Client Side
• Encryption by client cannot be decrypted by
server
• Can be decrypted by receiving client only.
AWS shared responsibility model

8
 AWS responsibility: Security of the
cloud
AWS responsibilities:
• Physical security of data centers
AWS services – Controlled, need-based access

• Hardware and software

infrastructure
Compute Storage Database Networking
– Storage decommissioning, host
operating system (OS) access
AWS Global Regions logging, and auditing
Infrastructure
Availability
Zones
Edge • Network infrastructure
locations – Intrusion detection

• Virtualization infrastructure
– Instance isolation

9
 Customer responsibility: Security in
the cloud
Customer responsibilities:
• Amazon Elastic Compute Cloud
(Amazon EC2) instance operating
Customer data
system
– Including patching, maintenance
Applications, IAM
• Applications
Operating system, network, and firewall – Passwords, role-based access, etc.
configuration • Security group configuration
Client-side
data
Network • OS or host-based firewalls
Server-side traffic – Including intrusion detection or
encryption
encryption protection
and data
(file system (encryption,
prevention systems
integrity
authenticatio
or data) integrity, • Network configurations
identity)
n • Account management
Customer-configurable – Login and permission settings for each
user

10
 Service characteristics and security
responsibility (1 of 2)
Example services managed by the customer Infrastructure as a service (IaaS)
• Customer has more flexibility over configuring
networking and storage settings
• Customer is responsible for managing more
aspects of the security
Amazon Amazon Elastic Amazon • Customer configures the access controls
EC2 Block Store Virtual Private Cloud
(Amazon EBS) (Amazon VPC)
Platform as a service (PaaS)
• Customer does not need to manage the
underlying infrastructure
• AWS handles the operating system, database
Example services managed by AWS
patching, firewall configuration, and disaster
recovery
• Customer can focus on managing code or data

AWS Amazon AWS Elastic

Lambda Relational Database Beanstalk
Service (Amazon RDS)

11
 Service characteristics and security
responsibility (2 of 2)
SaaS examples Software as a service (SaaS)
• Software is centrally hosted
• Licensed on a subscription model or
pay-as-you-go basis.
AWS Trusted AWS Amazon Chime • Services are typically accessed via web
Advisor Shield browser, mobile app, or application
programming interface (API)
• Customers do not need to manage the
infrastructure that supports the
service

12
AWS account root user access versus
IAM access
• Best practice: Do not use the AWS
Account account root user except when
root IAM necessary.
user • Access to the account root user
requires logging in with the email
address (and password) that you
used to create the account.
• Example actions that can only be
done with the account root user:
• Update the account root user
password
• Change the AWS Support plan
• Restore an IAM user's permissions
• Change account settings (for
example, contact information,
allowed Regions)

13
 Securing a new AWS account: Account
root user
Step 1: Stop using the account root user as soon as possible.
– The account root user has unrestricted access to all your resources.

• To stop using the account root user:

1. While you are logged in as the account root user, create an IAM user for
yourself. Save the access keys if needed.
2. Create an IAM group, give it full administrator permissions, and add the
IAM user to the group.
3. Disable and remove your account root user access keys, if they exist.
4. Enable a password policy for users.
5. Sign in with your new IAM user credentials.
6. Store your account root user credentials in a secure place.

14
 Securing a new AWS account: MFA
Step 2: Enable multi-factor authentication (MFA).
– Require MFA for your account root user and for all IAM users.
– You can also use MFA to control access to AWS service APIs.

• Options for retrieving the MFA token –

– Virtual MFA-compliant applications:
• Google Authenticator.
• Authy Authenticator (Windows phone app).
– U2F security key devices: MFA token
• For example, YubiKey.
– Hardware MFA options:
• Key fob or display card offered by Gemalto.
15
 Securing a new AWS account: AWS
CloudTrail
Step 3: Use AWS CloudTrail.
– CloudTrail tracks user activity on your account.
• Logs all API requests to resources in all supported services your account.
– Basic AWS CloudTrail event history is enabled by default and is free.
• It contains all management event data on latest 90 days of account activity.
• To access CloudTrail –
1. Log in to the AWS Management Console and choose the CloudTrail service.
2. Click Event history to view, filter, and search the last 90 days of events.
• To enable logs beyond 90 days and enable specified event alerting, create a
trail.
1. From the CloudTrail Console trails page, click Create trail.
2. Give it a name, apply it to all Regions, and create a new Amazon S3 bucket for log
storage.
3. Configure access restrictions on the S3 bucket (for example, only admin users
should have access).
16
 Securing a new AWS account: Billing
reports
Step 4: Enable a billing report, such as the AWS Cost and
Usage Report.
• Billing reports provide information about your use of AWS resources and
estimated costs for that use.

• AWS delivers the reports to an Amazon S3 bucket that you specify.

– Report is updated at least once per day.

• The AWS Cost and Usage Report tracks your AWS usage and provides estimated
charges associated with your AWS account, either by the hour or by the day.

17
 Activity: Scenario 1 of 2
Consider this deployment. Who is responsible – AWS or the customer?

1. Upgrades and patches 6. Oracle upgrades or

to the operating system patches If the Oracle
AWS Cloud on the EC2 instance? instance runs as an
Virtual Private Amazon RDS instance?
2. Physical security of the
Cloud (VPC) data center? 7. Oracle upgrades or
patches If Oracle runs on
3. Virtualization an EC2 instance?
infrastructure?
8. S3 bucket access
4. EC2 security group configuration?
Amazon Amazon Oracle settings?
Simple EC2 instance
5. Configuration of
Storage
applications that run on
Service the EC2 instance?
(Amazon S3)
AWS Global Infrastructure

18
 Activity: Scenario 1 of 2 Answers
Consider this deployment. Who is responsible – AWS or the customer?

1. Upgrades and patches 6. Oracle upgrades or

to the operating system patches If the Oracle
AWS Cloud on the EC2 instance? instance runs as an
• ANSWER: The Amazon RDS instance?
Virtual Private
Cloud (VPC) customer • ANSWER: AWS
2. Physical security of the 7. Oracle upgrades or
data center? patches If Oracle runs on
• ANSWER: AWS an EC2 instance?
• ANSWER: The
Amazon 3. Virtualization customer
Amazon Oracle
Simple infrastructure?
EC2 instance 8. S3 bucket access
Storage • ANSWER: AWS
configuration?
Service 4. EC2 security group
(Amazon S3) • ANSWER: The
settings?
AWS Global Infrastructure customer
• ANSWER: The
customer
5. Configuration of
applications that run on
the EC2 instance?
• ANSWER: The
customer
19
 Activity: Scenario 2 of 2
Consider this deployment. Who is responsible – AWS or the customer?

Secure Shell (SSH) 1. Ensuring that the AWS 6. Ensuring network isolation
keys Management Console is not between AWS customers' data?
hacked?
7. Ensuring low-latency network
2. Configuring the subnet? connection between the web
AWS Command Line server and the S3 bucket?
AWS Interface (AWS CLI) 3. Configuring the VPC?
Management 8. Enforcing multi-factor
Console 4. Protecting against network authentication for all user logins?
outages in AWS Regions?
Internet
gateway 5. Securing the SSH keys
VPC

Subnet

Web server on
Amazon EC2

S3 bucket with
objects
 Activity: Scenario 2 of 2 Answers
Consider this deployment. Who is responsible – AWS or the customer?
1. Ensuring that the AWS Management
Console is not hacked? 6. Ensuring network isolation
Secure Shell (SSH)
keys • ANSWER: AWS between AWS customers' data?
• ANSWER: AWS
2. Configuring the subnet?
• ANSWER: The customer 7. Ensuring low-latency network
AWS Command Line connection between the web
AWS Interface (AWS CLI) 3. Configuring the VPC? server and the S3 bucket?
Management
• ANSWER: The customer • ANSWER: AWS
Console
4. Protecting against network outages in 8. Enforcing multi-factor
Internet authentication for all user logins?
AWS Regions?
gateway
• ANSWER: AWS • ANSWER: The customer
VPC
5. Securing the SSH keys
Subnet • ANSWER: The customer

Web server on
Amazon EC2

S3 bucket with
objects
 Overview of Compliance in AWS
• When customers move their production
workloads to the AWS cloud, both parties
become responsible for managing the IT
environment.
• The customers are responsible for setting up their
environment in a secure and controlled manner.
• The customers also need to maintain adequate
governance over their entire IT control
environment.
 Strong Compliance Governance
• By deploying to the AWS Cloud, customers have options to apply
different types of controls and various verification:
• Take a holistic approach. Review the information available from
AWS together with all
• other information to understand as much of the IT environment as
they can. After this is
• complete, document all compliance requirements.
• 2. Design and implement control objectives to meet the
organization’s compliance
• requirements.
• 3. Identify and document controls owned by all third parties.
• 4. Verify that all control objectives are met and all key controls are
designed and operating
• effectively.
 AWS KMS
Anytime you hear “encryption” for an AWS service, it’s most likely KMS
• AWS manages encryption keys for us
• Fully integrated with IAM for authorization
• Easy way to control access to your data
• Able to audit KMS Key usage using CloudTrail
• Seamlessly integrated into most AWS services (EBS, S3, RDS, SSM…)
• Never ever store your secrets in plaintext, especially in your code!
• KMS Key Encryption also available through API calls (SDK, CLI)
• Encrypted secrets can be stored in the code / environment variables
 KMS Keys Types
• KMS Keys is the new name of KMS Customer Master Key
• Symmetric (AES-256 keys)
– • Single encryption key that is used to Encrypt and Decrypt
– • AWS services that are integrated with KMS use Symmetric CMKs
– • 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
 KMS
• Types of KMS Keys:
– • AWS Owned Keys (free): SSE-S3, SSE-SQS, SSE-DDB (default
key)
– • AWS Managed Key: free (aws/service-name, example: aws/rds
or aws/ebs)
– • Customer managed keys created in KMS: $1 / month
– • Customer managed keys imported (must be symmetric key):
$1 / month + pay for API call to KMS ($0.03 / 10000 calls)
• Automatic Key rotation:
– • AWS-managed KMS Key: automatic every 1 year
– • Customer-managed KMS Key: (must be enabled) automatic
every 1 year
– • Imported KMS Key: only manual rotation possible using alias
Copying snapshots across regions
 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
• 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
 Copy snapshots across accounts
[Link] a Snapshot, encrypted with
your own KMS Key (Customer
Managed Key)
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 CMK
in your account
5. Create a volume from the
snapshot
KMS Multi-Region Keys
 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 Multi- Region
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 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
 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
• Unencrypted objects and objects encrypted with SSE-S3 are replicated by
default
• Objects encrypted with SSE-C (customer provided key) can be 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
1. AMI in Source Account is encrypted
with KMS Key from Source Account
2. Must modify the image attribute to
add a Launch Permission which
corresponds to the specified target
AWS account
3. Must share the KMS Keys used to
encrypted the snapshot the AMI
references with the target account /
IAM Role
4. The IAM Role/User in the target
account must have the permissions
to DescribeKey, ReEncrypted,
CreateGrant, Decrypt
5. 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
• Security through IAM
• Notifications with Amazon
EventBridge
• Integration with CloudFormation
Parameter tiers
 Parameters Policies (for advanced
parameters)
Allow to assign a TTL to a parameter (expiration date) to
force updating or deleting sensitive data such as
passwords
Can assign multiple policies at a time
 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 attack – 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
WAF – Fixed IP while using WAF with a
Load Balancer
• WAF does not support the Network Load
Balancer (Layer 4)
• We can use Global Accelerator for fixed IP and
WAF on the ALB
 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
 Comparisons
• 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