Upload
amazon-web-services
View
1.897
Download
3
Embed Size (px)
DESCRIPTION
This session brings together the interests of engineering, compliance, and security experts, and shows you how to align your AWS workload to the controls in the HIPAA Security Rule. You hear from customers who process and store Protected Health Information (PHI) on AWS, and you learn how they satisfied their compliance requirements while maintaining agility. This session helps security and compliance experts find out what is technically possible on AWS and learn how implementing the Technical Safeguards in the HIPAA Security Rule can be simple and familiar. We walk through the Technical Safeguards of the Security Rule and map them to AWS features and design choices to help developers, operations teams, and engineers speak the language of their security and compliance peers.
Citation preview
November 12, 2014 | Las Vegas, NV
HLS401
Architecting for HIPAA Compliance on AWS
Bill Shinn, AWS Dan Stover, Emdeon Jason McKay, LogicWorks
Frank Macreery, Aptible
AWS HIPAA ProgramAligning services and workloads to the HIPAA Security Rule
Bill Shinn, AWS Principal Security Solutions Architect
AWS HIPAA Program
Strong presence in healthcare and life
sciences from our roots
Business Associates & January, 2013
Omnibus Final Rule
Starting signing Business Associate
Agreements (BAA) in Q2 2013
Program is based on Shared Security
Responsibility Model
AWS HIPAA Program is aligned to
NIST 800-53 & FedRAMP
Authorizations
Alignment to HIPAA Security Rule
HIPAA Security Rule(45 CFR Part 160 and Subparts
A and C of Part 164)
NIST 800-66An Introductory Resource Guide
for Implementing the Health
Insurance Portability and
Accountability Act (HIPAA)
Security Rule
NIST 800-53 Moderate baseline + FedRAMP
Controls
AWS HIPAA Eligible Services
Customer may use all services within a “HIPAA Account”
Customers may process, store, or transmit ePHI using only Eligible
Services
Amazon EC2Elastic Load
Balancing
(TCP mode only)
Amazon S3Amazon EBS Amazon Glacier Amazon Redshift
AWS HIPAA configuration requirements
Customers must encrypt ePHI in transit and at rest
Customers must use EC2 Dedicated Instances for instances processing,
storing, or transmitting ePHI
Customers must record and retain activity related to use of and access to
ePHI
Office of Civil Rights Audit Protocol & Shared Security
Responsibility
Section
Established
Performance
Criteria Key ActivityCustomer
ResponsibilityAWS
Responsibility
AWS
Certification
Reference Additional Guidance
¤164.312(b):
Audit controls-
Implement
hardware,
software, and/or
procedural
mechanisms that
record and
examine activity
in information
systems that
contain or use
electronic
protected health
information.
Determine the
Activities that
Will be Tracked
or Audited
Inquire of management
as to whether audit
controls have been
implemented over
information systems
that contain or use
ePHI.
Obtain and review
documentation relative
to the specified criteria
to determine whether
audit controls have
been implemented
over … Yes Yes
NIST 800-53
AU-1, AU-2, AU-
3,
AU-4, AU-6, AU-
7
Customers processing, storing
or transmitting ePHI in AWS
must utilize a level of audit
logging sufficient to record all
activity related to use of and
access to protected health
information.
When using services such as
Amazon S3 or Amazon
Redshift, customers should
evaluate native logging
features such as Amazon S3
bucket logging to determine
how these features may assist
in meeting the implementation
specification.
(example – 45 CFR 164.312(b)
AWS HIPAA Web Tier Reference Architecture
VPC Public Subnet 10.40.1.0/24 VPC Public Subnet 10.40.2.0/24
AZ A AZ B
Public ELB in
TCP mode w/ Proxy Protocol
HAProxy tier – if needed, session state
managed via client-side cookie inserted by
HAProxy.
SSL termination/re-encryption. Keys stored in
Amazon S3, retrieved by AWS
CloudFormation at system launch using
entitlements of IAM role for Amazon EC2.
Support for Proxy Protocol & x-forwarded-for
HAProxy/
Public
SSL
HAProxy/
Public
SSL
HAProxy/
Public
SSL
HAProxy/
Public
SSL
Web
Server/
Private
SSL
Web
Server/
Private
SSL
Web
Server/
Private
SSL
Web
Server/
Private
SSL
VPC Private Subnet 10.40.3.0/24 VPC Private Subnet 10.40.4.0/24
HAProxy tier performs backend encryption
between HAProxy nodes and Web nodes.
Keys stored in Amazon S3, retrieved by AWS
CloudFormation at system launch using
entitlements of IAM role for Amazon EC2.
SG: WebSecurityGroup
SG: ELBSecurityGroup
SG: HAProxySecurityGroup
EmdeonA case study of automation and change management
Dan Stover, Emdeon
Emdeon on AWS
Automation and change management
Focus on the ability to make changes fearlessly
Build a culture that values experimentation and agility
Provide full auditability into the source of changes
Enable software architectures in a tangible way
Limit the ability to bypass security controls
Management VPC
Pre-Production VPC
Production VPC
Access controls (164.312(a)(1))
Template everything
CI/CD and testing
Assume roles
No human interaction with PHI
Audit controls (164.312(b))
AWS CloudTrail
High degree of transparency
Change control
Elegant patching
Integrity controls (164.312(c))
Limited production access
Debugging w/o PHI
All transactions persisted in Amazon
S3
Backup policy
Transmission security (164.312(e))
SSL everywhere with zero touch
Generate keystores
Build AMIs
Configure
passthrough
LogicWorksBuilding a cloud-based health information exchange
Jason McKay, VP of Engineering
Orion HIE overview
About LogicWorks
Existing private cloud solution
HIE project was well timed to integrate our healthcare and our AWS
focus with a good customer
Challenges
Unknown number of subscribers (had to be ready for scale).
Aggressive timelines aided by agility in AWS.
Dev/test
Day 1: Work begins on Dev/test AWS environments for HIE.
Day 1: AWS servers deployed, VPC configured, Dedicated instances used, EBS
volumes encrypted.
Day 3: Dev/test environments ready for Orion Application team. Alert Logic IDS and
Log Manager installed.
Stage/prod
Day 1: Logicworks received specs for stage/prod.
Day 2: Quote for Stage/Prod sent to Orion for review.
Day 21: Stage turned over to Orion developers.
Seized the opportunity to architect differently than we do in private cloud.
Solution
Availability enhancements (distribute app tiers across AZs)
Tools to achieve secure design (core services hub and SDLC environment spokes, VPC peering, use of
ACLs and security groups)
Encrypted EBS for PHI data
IAM roles for secure API interaction
Instances/EBS designed for performance (architecting performance for Oracle database tier)
IDS/Log analysis
AWS Cloudtrail reporting and alerting
Architecture overview
Dev DMZ Subnet
Dev Trusted Subnet
Test/Train/DemoDMZ Subnet 1
Test/Train/DemoTrusted Subnet 1
Dev Database SubnetTest/Train/Demo
Database Subnet 1
Test/Train/Demo DMZ Subnet 2
Test/Train/DemoTrusted Subnet 2
Test/Train/DemoDatabase Subnet 2
Availability Zone A Availability Zone B
StageDMZ Subnet 1
StageTrusted Subnet 1
StageDatabase Subnet 1
Stage DMZ Subnet 2
StageTrusted Subnet 2
StageDatabase Subnet 2
Availability Zone BAvailability Zone A
ProdDMZ Subnet 1
ProdTrusted Subnet 1
ProdDatabase Subnet 1
Prod DMZ Subnet 2
ProdTrusted Subnet 2
ProdDatabase Subnet 2
Availability Zone BAvailability Zone A
Prod DMZ Subnet 3
ProdTrusted Subnet 3
ProdDatabase Subnet 3
Availability Zone C
Non-Prod VPC Prod VPCStage VPC
Dev Shared DMZSubnet 1
Dev Shared InternalSubnet 1
Dev DB Subnet 1
Prod Shared DMZSubnet 1
Prod Shared InternalSubnet 1
Prod DB Subnet 1
Availability Zone A
Customer Specific Shared VPC
Dev Shared DMZSubnet 2
Dev Shared InternalSubnet 2
Dev DB Subnet 2
Prod Shared DMZSubnet 2
Prod Shared InternalSubnet 2
Prod DB Subnet 2
Availability Zone B
Prod CA DMZSubnet 1
Prod CATrusted Subnet 1
Prod CADatabase Subnet 1
Prod CA DMZ Subnet 2
Prod CATrusted Subnet 2
Prod CADatabase Subnet 2
Availability Zone BAvailability Zone A
Customer AgnosticShared Prod VPC
Stage CADMZ Subnet 1
Stage CATrusted Subnet 1
Stage CADatabase Subnet 1
Stage CA DMZ Subnet 2
Stage CATrusted Subnet 2
Stage CADatabase Subnet 2
Availability Zone BAvailability Zone A
Customer AgnosticShared Stage VPC
Non-ProdDMZ Subnet 1
Non-ProdTrusted Subnet 1
Non-ProdDatabase Subnet 1
Non-Prod DMZ Subnet 2
Non-ProdTrusted Subnet 2
Non-ProdDatabase Subnet 2
Availability Zone BAvailability Zone A
Customer AgnosticShared Non-Prod VPC
OrionDMZ Subnet 1
OrionTrusted Subnet 1
OrionDatabase Subnet 1
Orion DMZ Subnet 2
OrionTrusted Subnet 2
OrionDatabase Subnet 2
Availability Zone BAvailability Zone A
Orion Management VPC
VPC Peering Connection
VPC Peering Connection
VPC Peering Connection
VPC Peering Connection
VPC Peering Connection
VPC Peering ConnectionVPC Peering Connection
VPC Peering Connection
VPC Peering Connection VPC Peering Connection
Customer AWS Account
Orion AWS Account
Architecture overview
Dev DMZ Subnet
Dev Trusted Subnet
Test/Train/DemoDMZ Subnet 1
Test/Train/DemoTrusted Subnet 1
Dev Database SubnetTest/Train/Demo
Database Subnet 1
Test/Train/Demo DMZ Subnet 2
Test/Train/DemoTrusted Subnet 2
Test/Train/DemoDatabase Subnet 2
Availability Zone A Availability Zone B
StageDMZ Subnet 1
StageTrusted Subnet 1
StageDatabase Subnet 1
Stage DMZ Subnet 2
StageTrusted Subnet 2
StageDatabase Subnet 2
Availability Zone BAvailability Zone A
ProdDMZ Subnet 1
ProdTrusted Subnet 1
ProdDatabase Subnet 1
Prod DMZ Subnet 2
ProdTrusted Subnet 2
ProdDatabase Subnet 2
Availability Zone BAvailability Zone A
Prod DMZ Subnet 3
ProdTrusted Subnet 3
ProdDatabase Subnet 3
Availability Zone C
Non-Prod VPC Prod VPCStage VPC
Dev Shared DMZSubnet 1
Dev Shared InternalSubnet 1
Dev DB Subnet 1
Prod Shared DMZSubnet 1
Prod Shared InternalSubnet 1
Prod DB Subnet 1
Availability Zone A
Customer Specific Shared VPC
Dev Shared DMZSubnet 2
Dev Shared InternalSubnet 2
Dev DB Subnet 2
Prod Shared DMZSubnet 2
Prod Shared InternalSubnet 2
Prod DB Subnet 2
Availability Zone B
Prod CA DMZSubnet 1
Prod CATrusted Subnet 1
Prod CADatabase Subnet 1
Prod CA DMZ Subnet 2
Prod CATrusted Subnet 2
Prod CADatabase Subnet 2
Availability Zone BAvailability Zone A
Customer AgnosticShared Prod VPC
Stage CADMZ Subnet 1
Stage CATrusted Subnet 1
Stage CADatabase Subnet 1
Stage CA DMZ Subnet 2
Stage CATrusted Subnet 2
Stage CADatabase Subnet 2
Availability Zone BAvailability Zone A
Customer AgnosticShared Stage VPC
Non-ProdDMZ Subnet 1
Non-ProdTrusted Subnet 1
Non-ProdDatabase Subnet 1
Non-Prod DMZ Subnet 2
Non-ProdTrusted Subnet 2
Non-ProdDatabase Subnet 2
Availability Zone BAvailability Zone A
Customer AgnosticShared Non-Prod VPC
OrionDMZ Subnet 1
OrionTrusted Subnet 1
OrionDatabase Subnet 1
Orion DMZ Subnet 2
OrionTrusted Subnet 2
OrionDatabase Subnet 2
Availability Zone BAvailability Zone A
Orion Management VPC
VPC Peering Connection
VPC Peering Connection
VPC Peering Connection
VPC Peering Connection
VPC Peering Connection
VPC Peering ConnectionVPC Peering Connection
VPC Peering Connection
VPC Peering Connection VPC Peering Connection
Customer AWS Account
Orion AWS Account
Compliance and controls – access controls
164.312(a) Access control
Unique User Identification — SSO; MFA; actions in the console traceable through AWS
CloudTrail; utilize additional services and aggregate with log management system with
server logs; IAM for controlling access rights (clients are responsible for analyzing the
access needs of their users; enable their continued use of internal authentication
mechanisms where they’re already managing this — i.e., LDAP/AD).
Emergency Access Procedure — DR/BCP to provide continued access to ePHI; also,
resiliency in terms of having EBS snapshots, multi-AZ, and multi-region deployments.
Compliance and controls – access controls (con’t)
164.312(a) Access control
Automated logoff — for administrators connecting directly to servers already baked into the
hardened image (for the AWS console, this is handled with AD as the identity provider).
Terminating access no longer needed — handled through SSO integration with AD.
Encryption at rest — use of EBS volumes in AWS CloudFormation templates — automated
mounting of encrypted EBS volumes that store critical binaries and PHI.
Compliance and controls – audit controls
164.312(b) Audit controls — record and examine activity in systems that contain or
use ePHI
Alert Logic – use of Log Manager: on-instance deployment; roles are configured, and instances register
themselves with Alert Logic.
AWS CloudTrail use, reporting/alerts on specific types of actions. AWS Cloudtrail also logs to Alert Logic
Log Manager.
ACLs, security groups — standardized networking restrictions forcing administration through jump boxes
tracking administrators’ actions.
Automated snapshot with success/fail logging to an Amazon S3 bucket. Integrated with Amazon
CloudWatch for alerting on failed snaps.
Compliance and controls – additional controls
164.312(d) Person or Entity Authentication
MFA tokens for verification that the person connecting is the one claimed.
164.312(e) Transmission Security
Encryption — can talk about the hub-and-spoke model for the management environment for
their future growth; central location that they connect to using VPN.
Additional Application Controls
Automated updating of DNS on instance deployment replacement.
ASGs of 1/1/1 to preserve unique role in application stack while maintaining HA.
Results
Rapidly onboard new clients with minimal work.
More easily iterate on architecture and design. Continuous
improvement.
Readily reproducible in other regions as business needs dictate.
Architecting for HIPAA compliance:Dev Ops for HIPAA
Frank Macreery, Aptible
Layers of responsibility
Physical SafeguardsFacility management
Physical contingency plans
General
Technical Safeguards
Encryption
Backups
Instance access (SSH)
Application-Specific
Technical Safeguards
Authentication
Access controls
PHI access logs
Physical Safeguards
General
Technical Safeguards
Application-Specific
Technical Safeguards
Aptible architecture overview
+
Division of Responsibility
General
Technical Safeguards
Application-Specific
Technical Safeguards
Division of responsibility
AWS CloudFormation template sets up secure network layout
Chef (OpsWorks) recipes + custom tools manage general security
functions like SSL termination, EBS volume encryption, and backups
Applications run within Docker containers and manage their own
framework-specific security/logging
General Safeguard: Unique SSH Identities
Regulatory requirement: "Assign a unique name and/or number for
identifying and tracking user identity."
Aptible implementation: AWS IAM + AWS OpsWorks
Other potential solutions: Custom Chef recipes + data bag for authorized
keys
AWS OpsWorks Deny by Default
SSH access is granted:
Only to IAM user
Only on a temporary basis
Chef-configured cron task locks down instances hourly
gem install opsworks-cli
opsworks allow frank --stack my-stack
opsworks lockdown --stack my-stack
General safeguard: auditing SSH access
Regulatory requirement: "Implement hardware, software, and/or
procedural mechanisms that record and examine activity in information
systems that contain or use electronic protected health information"
Aptible implementation: AWS OpsWorks + Deny by Default + AWS
CloudTrail
Other potential solutions: Authy, syslog + Logstash + Elasticsearch +
Kibana
Addressing application-specific safeguards
Challenge: Many frameworks, many libraries, many specific
implementation decisions
Solution: One "compliance API" to manage audit artifacts and mapping
from artifact type to requirements, many clients
Application-specific safeguard: authentication
gridiron.create_audit_log(
criterion: 'authentication_event',
timestamp: 1414368280,
uuid: 'f59c9a72-2f28-4b6b-93e…',
authentication_method: 'token',
…
)
Application-specific safeguard: authentication
Authentication audit log
(Satisfies requirements)
§ 164.312(a)(1): Access control
§ 164.312(a)(2)(i): Unique user identification
§ 164.312(d): Person or entity authentication
(…)
Please give us your feedback on this
presentation