2. Agenda
• "Everything Starts with a Threat Model"
• Access Control
• with IAM
• ...and Organizations
• Encryption at Rest
• with KMS
• ...or CloudHSM
• Encryption in Transit
• When it's needed
• Key Management:
• DIY
• EC2 Systems Manager Parameter Store
4. “Everything starts with a threat model”
• STRIDE, DREAD, others
• Identify:
• Actors
• Vectors
• “Bad stuff that could happen when bad people get creative”
• Probabilities and consequences of bad stuff happening
• Apply technical and procedural mitigations
• All the way up the OSI stack, from network to application
5. Attack vectors
• Application-level and API-level attacks
• “If it takes input, it likely has an in-band attack vector”
• “If it has a control point, it likely has an out-of-band attack
vector”
• “Even if it doesn’t itself have a useful compromise, it might be
a useful propagation vector”
• A successful attack = disruption or corruption of service
output, or reduction in responsiveness to future service
calls, or being a conduit of “bad content” to vulnerable
consumers of the service
• Consider the OWASP Top 10 and other application-level
attacks
6. Control points and out-of-band attacks
• Everything in our list has an API endpoint
• API endpoints are exposed to the Internet over HTTPS, using
TLS 1.2 and unidirectional trust via s2n
• API endpoints are scaled, rate-managed, and connection-
monitored
• API endpoint calls need Signature Version 4
• SHA256 HMAC with secret access key (240-bit entropic) over
REST or Query request
• REST and Query calls are checked for formation correctness
• Looking pretty well-covered
7. Making TLS work better in your apps
• “signal to noise”
• A TLS library designed by AWS to help your developers
implement transport security with faster performance
• Avoids implementing rarely-used TLS options and
extensions; ~6,000 lines of code
https://github.com/awslabs/s2n
9. Resource-based policy
• Ideal for cross-
account permissions,
supports all S3
actions
Bucket policies
S3 access logging
CloudTrail Integration
Logging
S3 access control and auditing
Resource-based policy
• Object-level ACL for very
specific object-level grants
and access policy
management
• Bucket-level ACL for log
delivery
ACLs
Control API calls to S3
• Programmatic access by
applications by using roles
• User-, group-, or role-
based access policy
IAM policies
17. What do customers want to do?
Use AWS
account
boundaries for
isolation.
Centrally
manage
policies across
many accounts.
Delegate
permissions,
but maintain
guardrails.
See combined
view of all
charges.
18. Introducing AWS Organizations
Control AWS service
use across accounts
Policy-based management for multiple AWS accounts.
Consolidate billingAutomate AWS
account creation
19. Automate the creation of AWS accounts for
different resources.
• API driven AWS account creation.
• Use APIs to add the new account to a group
and attach service control policies.
• Use API response to trigger additional
automation (eg deploy CloudFormation
template)
Typical Use Cases
20. Create different groups of accounts for
development and production resources.
• Organise groups into a hierarchy.
• Apply different policies to each group.
• Alternatively, group according to lines-of-
business or other desired dimensions.
Typical Use Cases
21. Typical Use Cases
Control the use of AWS services to help
comply with corporate security and
compliance policies.
• Service Control Policies (SCPs) help you
centrally control AWS service use across
multiple AWS accounts.
• Ensure that entities in your accounts can use
only the services that meet your corporate
security and compliance policy
requirements.
22. How is Organizations different from IAM?
• Create groups of AWS accounts with AWS
Organizations.
• Use Organizations to attach SCPs to those groups to
centrally control AWS service use.
• Entities in the AWS accounts can only use the AWS
services allowed by both the SCP and the AWS IAM
policy for the account.
23. Pricing & Availability
• Available at no additional charge.
• Global service.
• Accessed through endpoint in N. Virginia region.
24. Service Control Policies (SCPs)
• Enables you to control which AWS service APIs are
accessible
- Define the list of APIs that are allowed – whitelisting
- Define the list of APIs that must be blocked – blacklisting
• Cannot be overridden by local administrator
• Resultant permission on IAM user/role is the intersection
between the SCP and assigned IAM permissions
• Necessary but not sufficient
• IAM policy simulator is SCP aware
26. Best practices – AWS Organizations
1. Monitor activity in the master account using CloudTrail
2. Do not manage resources in the master account
3. Manage your organization using the principal of “Least privilege”
4. Use OUs to assign controls
5. Test controls on single AWS account first
6. Only assign controls to root of organization if necessary
7. Avoid mixing “whitelisting” and “blacklisting” SCPs in organization
8. Create new AWS accounts for the right reasons
29. Where are keys generated and stored?
• Hardware you own?
• Hardware the cloud provider owns?
Where are keys used?
• Client software you control?
• Server software the cloud provider controls?
Who can use the keys?
• Users and applications that have permissions?
• Cloud provider applications you give permissions?
What assurances are there for proper security around keys?
“Key” questions to consider with any solution
30. Client-side encryption
• You encrypt your data before data submitted to service
• You supply encryption keys OR use keys in your AWS account
• Available clients:
• S3, EMR File System (EMRFS), DynamoDB, AWS Encryption SDK
Server-side encryption
• AWS encrypts data on your behalf after data is received by service
• 19 integrated services including S3, Snowball, EBS, RDS, Amazon
Redshift, WorkSpaces, Amazon Kinesis Firehose, CloudTrail
Options for using encryption in AWS
31. Your
applications
in your data
centre
Your key
management
infrastructure in EC2
Your encryption
client application
Your key management
infrastructure Your application
in EC2
Your encrypted data in select AWS services
Client-side encryption in AWS
S3, EMRFS, DynamoDB, and AWS Encryption SDK
32. Amazon S3 Web
Server
HTTPS
Customer
data
Amazon S3
storage fleet
Key is used at S3 web server, and then deleted.
Customer must provide same key when
downloading to allow S3 to decrypt data.
Customer-
provided key
Server-side encryption in AWS
S3 server-side encryption with customer-provided encryption keys (SSE-C)
Plaintext
data
Encrypted
data
Customer-
provided key
33. AWS Key Management Service (AWS KMS)
• Managed service that simplifies creation, control, rotation, deletion,
and use of encryption keys in your applications
• Integrated with 19 AWS services for server-side encryption
• Integrated with AWS service clients/SDKs
• S3, EMRFS, DynamoDB, AWS Encryption SDK
• Integrated with CloudTrail to provide auditable logs of key usage for
regulatory and compliance activities
• Available in all commercial regions except China
35. How clients and AWS services typically integrate with KMS
Two-tiered key hierarchy using envelope
encryption
• Unique data key encrypts customer data
• KMS master keys encrypt data keys
Benefits
• Limits risk of compromised data key
• Better performance for encrypting large
data
• Easier to manage small number of
master keys than millions of data keys
• Centralized access and audit of key
activity
Customer master
keys
Data key 1
S3 object EBS
volume
Amazon
Redshift
cluster
Data key 2 Data key 3 Data key 4
Custom
application
KMS
36. Your application or
AWS service
+
Data key Encrypted data key
Encrypted
data
Master keys in
customer’s account
KMS
How AWS services use your KMS keys
1. Client calls kms:GenerateDataKey by passing the ID of the KMS master key in your
account.
2. Client request is authenticated based on permissions set on both the user and the key.
3. A unique data encryption key is created and encrypted under the KMS master key.
4. The plaintext and encrypted data key is returned to the client.
5. The plaintext data key is used to encrypt data and is then deleted when practical.
6. The encrypted data key is stored; it’s sent back to KMS when needed for data decryption.
38. You control how and when your KMS keys are used
Sample permissions on a key:
• Can only be used for encryption and decryption by <these users and
roles> in <these accounts>
• Can be used by application A to encrypt data, but only used by
application B to decrypt data
• Can only be used to decrypt an EBS volume if the volume was attached
to an instance by an authorized user
• Can be managed only by this set of administrator users or roles
Fully integrated with AWS policy definition language and Identity and
Access Management
39. Auditability of KMS key usage through
AWS CloudTrail
"EventName":"DecryptResult", This KMS API action was called…
"EventTiime":"2014-08-18T18:13:07Z", ….at this time
"RequestParameters":
"{"keyId":"2b42x363-1911-4e3a-8321-6b67329025ex”}”, …in reference to this key
“EncryptionContext":"volumeid-12345", …to protect this AWS resource
"SourceIPAddress":" 203.0.113.113", …from this IP address
"UserIdentity":
“{"arn":"arn:aws:iam:: 111122223333:user/User123“} …by this AWS user in this account
40. New feature: Bring Your Own Key
• You control how master keys are generated
• You store the master copy of the keys
• You import the key into KMS and set an optional expiration time
in the future
• You can use imported keys with all KMS-integrated services
• You can delete and re-import the key at any time to control
when AWS can use it to encrypt/decrypt data on your behalf
• Works with standards-based key management infrastructure,
including SafeNet Gemalto and Thales e-Security
41. Bring Your Own Key
Import encrypted key material
under the KMS CMK key ID;
set optional expiration period
Import
Your key material
protected in KMS
Download a public
wrapping key
KMS
Download
RSA public key
Create customer master key
(CMK) container
Empty CMK container
with unique key ID
KMS
Creates
Export your key material
encrypted under the public
wrapping key Your key
management
infrastructure
Export
Your 256-bit key
material encrypted
under KMS public key
42. KMS APIs to build your own applications
Example management API actions
• CreateKey, CreateAlias
• ImportKeyMaterial NEW
• DeleteImportedKeyMaterial NEW
• DisableKey
• EnableKeyRotation
• PutKeyPolicy
• ListKeys, DescribeKey
Example data API actions
• Encrypt
• Decrypt
• ReEncrypt
• GenerateDataKey
32 API actions and growing
http://docs.aws.amazon.com/kms/latest/APIReference/Welcome.html
43. KMS assurances
Why should you trust AWS with your keys?
• Your plaintext keys are never stored in non-volatile memory
• There are no tools in place to access your physical key material
• You control who has permissions to use your keys
• There is separation of duties between systems/operators that use
master keys in KMS and ones that use data keys
• You can find evidence of every KMS API call in CloudTrail
• Third-party evidence of these controls:
• Service Organization Control (SOC 1/2/3)
• PCI-DSS
• ISO 27017/27018
• In evaluation for FIPS 140-2 Level 2 with Level 3 physical security
44. Pricing for KMS
$1 / key version / month
$0.03 per 10,000 API requests (in commercial regions)
• 20,000 free requests per month
45. Alternatives to KMS
In order to have different controls over the security of your keys
1. AWS CloudHSM
2. AWS Partner solutions
3. Do It Yourself
46. AWS CloudHSM
• You receive dedicated access to HSM
appliances
• HSMs located in AWS data centers
• Managed and monitored by AWS
• Only you have access to your keys and
operations on the keys
• HSMs are inside your Amazon VPC—
isolated from the rest of the network
• Uses Gemalto SafeNet Luna SA HSM
appliances
CloudHSM
AWS administrator—
Manages the appliance
You—Control keys and
crypto operations
Amazon VPC
47. AWS CloudHSM
Available in eight regions worldwide
• US East (N. Virginia), US West (Oregon), AWS GovCloud (US), EU
(Ireland), EU (Frankfurt), Asia Pacific (Sydney), Asia Pacific (Singapore)
and Asia Pacific (Tokyo)
Compliance
• Included in AWS PCI DSS and SOC compliance packages
• FIPS 140-2 level 2 (maintained by Gemalto SafeNet)
Typical use cases
• Use with Amazon Redshift and RDS for Oracle
• Integrate with third-party software (Oracle, Microsoft SQL Server,
Apache, SafeNet)
• Build your own custom applications
48. SafeNet ProtectV manager
and Virtual KeySecure
in EC2
EBS volume encryption with CloudHSM and
Gemalto SafeNet Software
Gemalto SafeNet ProtectV with Virtual KeySecure
CloudHSM stores the master key
SafeNet
ProtectV
client
CloudHSM
Your encrypted data
in EBS
Your applications
in EC2
ProtectV client
• Encrypts I/O from
EC2 instances to EBS
volumes
• Includes preboot
authentication
49. Pricing for CloudHSM
• HSM provisioned in any region has a $5,000 one-time charge
• Starting at $1.88/hour metered charge after setup
• Hourly rate varies by region
• As low as $21,500 in year one; $16,500 in subsequent years
• Requests not billed; limited only by the device capacity
• Varies depending on algorithm and key size
50. Comparing CloudHSM with KMS
CloudHSM
• Dedicated access to one or more HSM
devices that comply with government
standards (FIPS 140-2, Common Criteria)
• Broad range of symmetric and asymmetric
algorithms
• Generate or import keys
• You control all access to your keys and
the application software that uses them
• Supported applications:
• Your custom software
• Third-party software
• AWS services: Amazon Redshift, RDS for Oracle
KMS
• Highly available and durable key storage,
management, and auditable service
• AWS-managed root of trust
• AES256-GCM and configurable key rotation
• Generate keys in-service or BYOK
• Easily encrypt your data across AWS
services and within your own applications
based on policies you define; full CloudTrail
integration
• Supported applications:
• Your custom software built with AWS SDKs/CLI
• AWS services (S3, EBS, RDS, Amazon Aurora,
Amazon Redshift, WorkMail, WorkSpaces,
CloudTrail, Elastic Transcoder)
51. Partner solutions in AWS Marketplace
• Browse, test, and buy encryption and key management solutions
• Pay by the hour, monthly, or annually
• Software fees added to AWS bill
• Bring Your Own License
52. Your encryption
client application
Your key management
infrastructure
Your
applications
in your data
centre
Your application
in EC2
Your key
management
infrastructure in EC2
Your encrypted data in AWS services
…
DIY key management in AWS
Encrypt data client-side and send ciphertext to AWS storage services
53. Comparison of key management options
KMS CloudHSM
AWS Marketplace
Partner Solutions
DIY
Where keys are
generated and stored
AWS, or imported by
you
In AWS, on an HSM
that you control
Your network or in
EC2 instance
Your network or in
AWS
Where keys are used AWS services or your
applications
AWS or your
applications
Your network or your
EC2 instance
Your network or your
EC2 instance
How to control key use Policy you define;
enforced by AWS
Custom code +
SafeNet APIs
Vendor-specific
management
Config files, vendor-
specific management
Responsibility for
performance/scale
AWS You You You
Integration with AWS
services?
Yes Limited Limited Limited
Pricing model Per key/usage Per hour Per hour/per year Variable
54. AWS database services and encryption at rest
Server-side encryption with KMS
RDS MySQL
RDS PostgreSQL
RDS SQL Server
RDS Oracle
RDS MariaDB
Amazon Aurora
Amazon Redshift
Server-side encryption with CloudHSM
Amazon Redshift
RDS Oracle TDE
Microsoft SQL TDE (not RDS engine)
Client-side encryption for
row/column/field-level protection
DynamoDB encryption client
Build your own with AWS SDK
third-party solutions
56. When it's Needed
• Across the Internet: of course
• https session termination
• in ELB / ALB?
• in CloudFront?
• in EC2 instances?
• Within a VPC...?
• HIPAA mandates encryptioon in transit for in-scope services
• PCI-DSS doesn't...
• Control 4 says "encrypt across public networks"
• Audit reports assert a VPC isn't a public network...
57. Options
• Do It Yourself (with S3 and KMS)
• EC2 Systems Manager Parameter Store
• Note:
• "The Magic's in the Scoping"
• In the following, KMS isn't in-scope for HIPAA and EC2 Systems
Manager Parameter Store and Run Command have yet to integrate
into our audit cycles at time of writing, but they don't touch PHI / CVV /
PAN...
69. Parameter Store
• Centrally store and find configuration and access data
• Repeatable, automatable management (e.g. SQL
connection strings)
• Granular access control – view, use and edit values per
parameter
• Encrypt sensitive data at rest in-store using your own AWS
KMS keys
70. Parameter Store – Getting started
• Parameter: Key-value pair
• Secure Strings: Encrypt sensitive parameters with your
own KMS or default account encryption key
• Reuse: In Documents and easily reference at runtime
across EC2 Systems Manager using {{ssm:parameter-
name}}
• Access Control: Create an IAM policy to control access
to specific parameter; apply as a Role to users, EC2
instances and Lambda functions as needed