Architecting Secure Serverless Applications REPEAT SVS309-R2

© 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved.
SVS309-R2
Architecting secure serverless

applications
Josh Kahn (he/him)
Principal Solutions Architect
Tech Leader – Serverless
AWS
Security is everyone’s
responsibility
Four principles to securing serverless
applications
1. Understand shared responsibility model
2. Grant least privilege
3. Implement defense in depth
4. Secure your software supply chain
Let’s apply these principles to a sample architecture
Order service Payment service
Loyalty service
AWS Step
Functions
fulfillment
workflow
Let’s apply these principles to a sample architecture
3 Order service Payment service
Loyalty service
4 2
Software supply chain 1
AWS Step
Functions
fulfillment
workflow
SECURITY PRINCIPLE #1
Understand shared
responsibility with AWS
Shared responsibility with AWS
Customer data
Customers are
responsible for
Customer
Platform, applications, IAM their security and

compliance
Operating system, network, and firewall configuration IN
the cloud
Client-side data encryption and Server-side encryption Network traffic protection
data integrity authentication (file system and/or data) (encryption/integrity/identity)
Foundation services
AWS is
Compute Storage Database Networking responsible for
AWS
the security
OF
AWS infrastructure Regions, AZs, and data centers the cloud
With serverless, AWS takes a greater share of
responsibility
Customer Customer data, applications, IAM
Data encryption and Application Internet access

integrity authentication management Monitoring and logging
(tools provided by platform)
Network traffic protection

Code encryption
AWS IAM
Platform management Firewall configuration

(data at rest)
(data in transit)
AWS
Operating system and network configuration
Compute Storage Database Networking
AWS Infrastructure Regions, AZs, and data centers
Lambda service composed of control and data planes
Control plane
• Management APIs, such as
o CreateFunction
o UpdateFunctionCode Controller
• Requires IAM permission to access
Data plane
• Invoke Lambda function via Invoke Requests
• IAM permission or resource policy Data plane

Responses
• When invoked, executes code on Client
o Existing execution environment, if exists

o New environment, after allocation
Secure Lambda functions with AWS IAM
Function policy Execution role
• Defines how function can be invoked • Defines which AWS resources can access via IAM
• Supports cross-account access • Used for poll-based invocations (Lambda polling)
• Used for synchronous and asynchronous invocations
“Actions on API Gateway A can invoke Lambda “Lambda function A can write data to
function B” DynamoDB Table B”
Function policy Execution role
Secure other resources with AWS IAM
Resource policy Execution role
• Defines access to event bus, for example PutEvent • Assumed by event bus to determine access to AWS
resources
• Use conditions to scope permissions
• Allows cross-account access
• Allows cross-account access
“Principals in Account A can publish new order
events to the event bus in Account B” “Event Bus A can publish events to Event Bus B”
Account A – Web store Account B – Central event bus Account C – Invoice

processing
New order New order
created created
publishes
eCommerce Rules
Event Bus
Resource policy Execution role

Grant least privilege
What does it mean to grant least privilege?
• Grant only the essential
privileges needed to perform
intended work
• Attach to function via AWS IAM
execution role
o Prefer unique role per function
o Assign fine-grained permissions
o Enforce permission boundaries
• Be specific: Identify limited set of

resources and actions allowed
o Scrutinize use of “*”
AWS SAM accelerates policy, role development
Amazon API AWS Lambda Amazon DynamoDB

Gateway
Practice defense in depth
Common vectors of attack
App vulnerabilities Dependencies Host/network
SQL injection Libraries Patching

Cross-site scripting (XSS) Distributions Network segmentation
OWASP Top 10 Base images
Common vulnerabilities
and exposures (CVE)
How to practice defense in depth?
• Implement multiple,
redundant measures across
system to address common AWS Fargate
task
Amazon DynamoDB
table
attack vectors Amazon

API Gateway
• Leverage AWS managed AWS Lambda Amazon S3
services and integrations function bucket
• Consider service features,

e.g., backup and encryption
AWS KMS key
AWS WAF AWS IAM
Brief aside on Firecracker
Firecracker is built on KVM, the same

hypervisor that EC2 Nitro instances are
built on.
Hardware virtualization ensures that

tasks from different customers can run
safely on the same physical machine.
Lambda function isolation Lambda function
boundary
• Each function runs in a dedicated Function,

layer code
Function,
layer code
Function,
layer code
Function,
layer code
execution environment
o Each execution environment handles Lambda Lambda Lambda Lambda
one concurrent invocation runtime runtime runtime runtime
Execution Execution Execution Execution

environment environment environment environment
• Execution environment may be
reused between invocations MicroVM MicroVM MicroVM MicroVM
o Use caution when storing sensitive
data in memory or /tmp
Hypervisor
• AWS maintains runtime and Host OS

execution environment
o Patching, etc. Lambda worker (EC2 instance, bare metal)
o Does not apply to container

packaging or customer runtimes
AWS account boundary
Securing a serverless web service
Amazon AWS Amazon

API Gateway Lambda DynamoDB
Request validation Sanitize input
Authorization Execution role
mTLS Minimize dependencies
Rate limiting Vulnerability scanning
Throttling
AWS WAF
XSS rules
SQLi rules
OWASP Top 10
Secure your software

supply chain
Secure your software supply chain
• Keep it simple
o Prefer single responsibility
do “x”
o Easier to debug; cleaner IAM privileges
• Again, never hardcode secrets do “y”

in code
do “z”
• Leverage code and vulnerability
scanning
o Don’t forget dependencies
Managing dependencies is key
• Understand you dependencies: • Leverage dependency check

https://deps.dev/ tools, such as
o OWASP
• Minimize dependencies o Protego

o Snyk
o Twistlock
• Keep dependencies up-to-date
to reduce risk and effort o Puresec
Common security topics
How do I secure access to my API? Are API
keys good enough?
• Options for authorization:
o IAM
o Cognito user pool/JWT AWS Fargate Amazon DynamoDB
task table
o Lambda authorizer
• Can be used with: Amazon

API Gateway
o AWS WAF AWS Lambda Amazon S3

function bucket
o Resource policies
o Mutual TLS (mTLS)
Should my Lambda function be VPC-enabled?
• Lambda functions always run in
VPCs owned by the Lambda
service team Customer VPC AWS Lambda Service VPC
o When VPC is enabled, configured with

access to your VPC via an ENI
• Lambda functions are always Elastic network
interface(s)
VPC to VPC
NAT
invoked via Invoke action
o Access controlled by AWS IAM
• Answer: Only if your function

needs access to resources in
the VPC
How should I handle secrets?
• Function requires static, sensitive data
o For example, API key or password
• While convenient, do not use Lambda

environment variables
o Accessible to anyone with access to the function
AWS Secrets
• Answer: Use purpose-built services, Manager
such as AWS Secrets Manager secured
with IAM permissions
How do I know my code has not been
changed?
• Use IAM permissions to limit
create/update actions
• Monitor with AWS Config,
AWS CloudTrail
• Leverage code signing to
cryptographically sign code
o Allow deployment of functions only
from trusted publishers
Thank you!
Josh Kahn
@joshuaakahn

Architecting Secure Serverless Applications REPEAT SVS309-R2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Architecting Secure Serverless Applications REPEAT SVS309-R2

Uploaded by

Copyright:

Available Formats

© 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved.

Architecting secure serverless

2. Grant least privilege

3. Implement defense in depth

4. Secure your software supply chain

Platform, applications, IAM their security and

Data encryption and Application Internet access

Network traffic protection

Platform management Firewall configuration

Operating system and network configuration

Compute Storage Database Networking

AWS Infrastructure Regions, AZs, and data centers

• Requires IAM permission to access

• IAM permission or resource policy Data plane

o Existing execution environment, if exists

Function policy Execution role

Account A – Web store Account B – Central event bus Account C – Invoice

Resource policy Execution role

Grant least privilege

• Be specific: Identify limited set of

Amazon API AWS Lambda Amazon DynamoDB

Practice defense in depth

App vulnerabilities Dependencies Host/network

SQL injection Libraries Patching

attack vectors Amazon

• Leverage AWS managed AWS Lambda Amazon S3

services and integrations function bucket

• Consider service features,

Firecracker is built on KVM, the same

Hardware virtualization ensures that

• Each function runs in a dedicated Function,

Execution Execution Execution Execution

• AWS maintains runtime and Host OS

o Does not apply to container

Amazon AWS Amazon

Secure your software

• Again, never hardcode secrets do “y”

• Understand you dependencies: • Leverage dependency check

• Minimize dependencies o Protego

• Can be used with: Amazon

o AWS WAF AWS Lambda Amazon S3

o When VPC is enabled, configured with

• Answer: Only if your function

• While convenient, do not use Lambda

You might also like