4. Security is a Shared Responsibility
Customer Applications & Content
Platform, Applications, Identity & Access Management
Operating System, Network & Firewall Configuration
Client-side Data
Encryption
Server-side Data
Encryption
Network Traffic
Protection
Customers are
responsible for their
security IN the
Cloud
AWS is
responsible for
the security OF the
Cloud
NetworkingDatabasesStorageCompute
Edge
Locations
Availability
Zones
Regions
AWS Global
Infrastructure
Foundation
Services
5. Encryption key management platforms
Topic On-Prem HSM AWS CloudHSM AWS KMS
Where keys are generated and
stored
Client AWS AWS, Client
Where keys are used AWS EC2 + Client
Network + 3rd party Apps
AWS + 3rd party Apps AWS + 3rd party Apps
Performance/Scale/HA
Responsibility
Client Client + AWS AWS
Price (initial entry) $$$ $$ $
Who controls key generation
and access
Client Client Client, AWS
FIPS 140-2 Compliant Yes Yes No
Options vary based on use case. Price and serviceability matter.
6. Large professional services firm seeking to move client facing work from on-prem SharePoint to SaaS
enterprise file sync and share (EFSS) platform
Will migrate 20,000 users
Push with cultural shift of collaboration from (1) email attachments to shareable links and (2) extending
availability of data from device-centric to user-centric access
Security is at the forefront in planning the rollout – project focused on cloud security foundation
Project security requirements:
1. Secure data so only those that need it can access it -> cloud enabled IAM and IGA
2. Data Loss Prevention (DLP) capabilities extended to the cloud -> cloud access security broker (CASB)
3. Encryption required, and we “own the keys” -> Encryption key management (Cloud HSM, KMS)
EFSS Client controlled
encryption (at rest)
Users
7. Project flow
1) Understand business requirements (i.e., rationale for “own the keys”)
2) Determine security requirements for key management and usage
3) Evaluate serviceability of existing on-prem encryption key management
operations and extension to cloud
4) Conduct market sweep for encryption key management solutions and
compatibility with EFSS
5) Evaluate available solutions
6) Implement solution and key management process
7) Document runbook!
8. “Own the keys” requirement
For third-party managed data repository or application that will contain
company confidential or restricted data we should CONTROL the
encryption key to control risk mitigation around a third-party gaining
access to data without our permission or even our knowledge.
• Government agencies to subpoena that data from the third-party without our knowledge and
opportunity to respond.
• Cyber criminals and cyber activists that may be able to bypass third-party software or security
controls, or take advantage of known vulnerabilities or even simple omissions of security measures
• Employees of the third-party who need the ability to manage the systems that house our data but
we don’t want those employees to have the ability to view or make a copy of that data for
themselves.
9. Requirements selection and product evaluation
Topic
Description
Option 1
EFSS managed
• Use native EFSS key
management solution
• Encrypt EFSS domain key with
client key created and owned in
AWS CloudHSM.
• Encrypt EFSS domain key with
client key generated within
AWS KMS
• Encrypt EFSS tenant key with
external master key created
and owned in on-prem HSM
Single tenant key storage
Client controls key
High availability
Key rotation capabilities
Auditing/reporting
Existing support w/ EFSS
Key data residency
Single tenant key storage
Client controls key
High availability
Key rotation capabilities
Auditing/reporting
Existing support w/ EFSS
Key data residency
Single tenant key storage
Client controls key
High availability
Key rotation capabilities
Auditing/reporting
Existing support w/ EFSS
Key data residency
Single tenant key storage
Client controls key
High availability
Key rotation capabilities
Auditing/reporting
Existing support w/ EFSS
Key data residency
• No additional investment
needed
• Can implement immediately
• Control and authority over keys w/
FIPS 140-2, Level 2
• Leverage in-house SafeNet
expertise to operation
• Simpler EKM integration with
AWS services
• Scalable with other SaaS
• Leverage existing AWS ops
team
• Leverage current KMS
operations
• FIPS 140-2, Level 2
• Control of key is EFSS • Clunky HA and potentially $$$
expansion to accommodate data
residency reqs
• Not single tenant
• Not FIPS 140-2, Level 2
• Less scalable and costly
depending on granularity of
data residency requirements
Features
Pros
Option 3
AWS KMS
Option 4
On-prem SafeNet Luna
Option 2
AWS CloudHSM
Key Risks
10. KMS Runbook topics
1) Security fundamentals:
- Least privilege access, RBAC
- Logging and monitoring
2) Segregation of duties:
- Key usage
- Key management
3) Key backup and recovery:
- AWS region dependencies
- Regulatory requirements (i.e., GDPR)
4) Key rotation
Customer Master
Key(s)
Data Key 1
Amazon S3
Object
Amazon
EBS
Volume
Amazon
Redshift
Cluster
Data Key 2 Data Key 3 Data Key 4
EFSS
11. Key Lessons/Tools/Takeaways
• Understand business, security, and legal requirements per solution
- Smaller team, agile and scalable needs: KMS
- Regulatory requirements, control over key services: CloudHSM
• Encrypt data at rest in the cloud to help mitigate external risk factors
• Align key operations to security principles and to serviceability with
vision of long-term encryption key management
• Ask for external help, evolving marketplace
- AWS KMS, CloudHSM best practices
- Alert Logic Cloud Insights