Architecting Security and Governance Across Multi Accounts
•
5 likes•2,965 views
Whether it is per business unit or per application, many AWS customers use multiple accounts to meet their infrastructure isolation and billing requirements. In this session, we discuss considerations, limitations, and security patterns when building out a multi-account strategy. We explore topics such as identity federation, cross-account roles, consolidated logging, and account governance. At the end of the session, we present an enterprise-ready, multi-account architecture that you can start leveraging today.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Architecting Security and Governance Across Multi Accounts
Similar to Architecting Security and Governance Across Multi Accounts (20)
More from Amazon Web Services
More from Amazon Web Services (20)
Recently uploaded
Recently uploaded (20)
Architecting Security and Governance Across Multi Accounts
- 1. Architecting Security and Governance Across a Multi-Account Strategy Dave Walker, Specialist Solutions Architect, Security and Compliance
- 2. What to expect from the session • "Everything Starts with a Threat Model" • Control Mapping • Existing Multi-Account Strategies, and Multi-Account Planning • Organizations • Baselining Individual Accounts • Putting it Together
- 3. “Start Here”
- 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 • Dan Ionita's "Gazetteer of threat / risk modelling frameworks": http://eprints.eemcs.utwente.nl/23767/
- 5. “Everything starts with a threat model” • Constrain scope of potential threats to individual accounts • Plan for incident response and forensics • Protect your log records from tampering and unauthorised reads
- 7. 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
- 9. Why a Mapping of Security Controls? • PCI-DSS • standards for merchants which process credit card payments and have strict security requirements to protect cardholder data. A point- in-time certification. • SOC 1-3 • designed by the “big 4” auditors as an evolution of SSAE16, SAS70 etc, and to address perceived shortcomings in ISO27001. A continuous-assessment certification, covering process and implementation. • ISO 27001 • outlines the requirements for Information Security Management Systems. A point-in-time certification, but one which requires mature processes.
- 10. General Headings: • Infrastructure meta-security • Host security • Network security • Logging and Auditing • Resilience • User Access Control and Management • Cryptography and Key Management • Incident Response and Forensics • “Anti-Malware” • Separation of Duty • Data Lifecycle Management • Geolocation • Anti-DDoS
- 11. “Can our current Security Functions be mapped onto AWS?” AWS Environment Management Logging and Auditing Asset Management Management Access Control Configuration Management Configuration Monitoring AWS CloudTrail AWS Config, API AWS IAM, Organizations Web Console AWS CloudFormation AWS OpsWorks CLI API SDKs Amazon CloudWatch
- 12. “Can our current Security Functions be mapped onto AWS?” Network AWS to Customer Networks Layer 2 Network Segregation Stateless Traffic Management IPsec VPN Firewall/ Layer 3 Packet Filter IDS/IPS Managed DDoS Prevention Internet and/or Direct Connect Amazon VPC Network Access Control Lists VPC VGW, Marketplace Security Groups AWS CloudTrail, CloudWatch Logs,SNS, VPC Flow Logging Included in Amazon CloudFront
- 13. “Can our current Security Functions be mapped onto AWS?” Encryption, Key Management Data-In-Flight Volume Encryption Object Encryption Key Management Dedicated HSMs Database Encryption IPsec or TLS or your own Amazon EBS Encryption Amazon S3 Encryption (Server and Client Side) AWS Key Management Service AWS CloudHSM TDE (RDS / Oracle EE) Encrypted Amazon EBS (with KMS) Encrypted Amazon Redshift
- 14. “Can our Current Security Functions be mapped onto AWS?” Data Management Hierarchical Storage Deletion Protection Versioning Archiving Amazon S3 Lifecycle Amazon S3 MFA Delete Amazon S3 Versioning Amazon Glacier (optionally, with Vault Lock)
- 15. “Can our Current Security Functions be mapped onto AWS?” Host / Instance Security Traditional Controls Instance Management Incident Management Asset Management Instance Separation Traditional Controls (mostly) Delete-and-promote More alternatives! “What the API returns, is true” PCI Level 1 Hypervisor Dedicated Instances
- 16. “Can our Current Security Functions be mapped onto AWS?” Logging, Analysis, Alerting Traditional OS Sources Database Logs Traditional OS Sources CloudWatch Logs EC2 Systems Manager Inventory RDS / Redshift Logs
- 17. Logs→metrics→alerts→actions AWS Config CloudWatch / CloudWatch Logs CloudWatch alarms AWS CloudTrail Amazon EC2 OS logs Amazon VPC Flow Logs Amazon SNS email notification HTTP/S notification SMS notifications Mobile push notifications API calls from most services Monitoring data from AWS services Custom metrics
- 19. The Story So Far • MASCOT • fully role- and identity-managed implementation from ProServe • Presented at Re:Invent 2016 SAC319 (https://www.youtube.com/watch?v=pqq39mZKQXU ), SAC320 (https://www.youtube.com/watch?v=xjtSWd8z_bE ) • Bertram Dorn's work from 2014 • similar structure, but a number of differences • https://youtu.be/CNSaJs7pWjA • Neither covers Organizations (quite yet) • MASCOT has coverage for KMS
- 20. What Needs Segregating from What? • Obvious cases first: • Read access to Billing and Log records from everyone, except Auditors and Security • ...and even then, access should be limited to appropriate cases • consider evidential weight • Prod from Dev, Test and Staging • remember Knight Capital? • also "bug ringfencing" • Compliance in-scope from out-of-scope • auditors need to see a hard scope boundary • you will want to keep in-scope environments as small as possible • use both AWS Accounts and VPCs for this
- 21. • Less obvious cases: • Look at your own org chart and body of policies • Consider how Separation of Duty and Need to Know operate • both within and between departments • Within org charts, policy, compliance scoping, and the need to ringfence dev accounts where bugs could impact API access, lies the answers to "how many: • AWS Organizations • KMS CMKs • AWS accounts • ...do I need?" What Needs Segregating from What?
- 22. Organizations
- 24. Today Jump Account Your Cloud Team Dev Account Prod Account Data Science Account Audit Account Cross Account Trusts Cross Account Resource Access You
- 27. 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.
- 28. • 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
- 29. • 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
- 30. Key Features • Policy framework for multiple AWS accounts. • Group-based account management. • Account creation and management APIs. • Consolidated billing for all AWS accounts in your organization. • Enable Consolidated Billing Only or All Features.
- 31. 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.
- 32. How to get started? • Revisit or create your account segmentation strategy. • Decide which type of organization is right for you. • Organize your AWS accounts according to it. • Test & begin to apply SCPs slowly. • Iterate on SCPs to achieve your desired state.
- 33. Pricing & Availability • Available at no additional charge. • Global service. • Accessed through endpoint in N. Virginia region.
- 34. 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
- 35. { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "*", "Resource": "*" }, { "Effect": "Deny", "Action": "redshift:*", "Resource": "*" } ] } { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": [ "ec2:RunInstances", "ec2:DescribeInstances", "ec2:DescribeImages", "ec2:DescribeKeyPairs", "ec2:DescribeVpcs", "ec2:DescribeSubnets", "ec2:DescribeSecurityGroups" ], "Resource": "*" } ] } Blacklisting example Whitelisting example
- 36. 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
- 37. More on SCPs • Service Control Policies • ...which look like IAM policies • (but without support for Conditions, in v1.0) • Imposed by Master account on child accounts • essentially concatenate with per-child-account IAM policies • Allows / Denies access to specific per-service API calls, or whole services • as with IAM policies, a single explicit Deny overrides any number of explicit Allows • But: they are also applied to the root user in the child account • Here's where we get into Mandatory Access Control! J
- 38. More on SCPs • Also: • you don't have to apply an SCP before you populate your account with assets... • this lends the idea of "immutable infrastructure" to other services, from the point of view of the child accounts • (including Serverless) • eg: • S3 websites which can't have their contents changed • Lambda functions which are invoke-only "black boxes" • ACM cert / key pairs which can't be deleted • Prevent CloudTrail, Config ever being turned off • ...
- 39. More on SCPs • In Practice: • the imposer of the SCP in the Master account gets no privilege in the child account's service, as a function of this capability • this makes SCPs a neat 2-person rule mechanism, too
- 43. Now Add an Incident Response Baseline: • Have a small NACLed subnet per AZ, per VPC for isolation of misbehaving instances • flip their ENIs to it, as needed • Have a Forensics role like the Audit role, per-account • read-only access to (essentially) everything • Have a runbook so a Forensic Investigator can work with the network admin team to: • provision a forensic workstation AMI onto the isolation subnet • open a hole in the NACL to the workstation from an appropriate bastion (or use Run Command to remotely operate forensic CLI tools)
- 44. Potential Further Extensions • EC2 Systems Manager • Inventory: like OSQuery • State Manager: like OpenSCAP • DMZs • Bastions • Management networks
- 47. Billing Records Handled by Organizations Master ItemDescription UsageStart Date UsageEnd Date UsageQuanti ty Currency Code CostBefo reTax Cred its TaxAm ount TaxTy pe TotalCo st $0.000 per GB - regional data transfer under the monthly global free tier 01.04.14 00:00 30.04.14 23:59 0.00000675 USD 0.00 0.0 0.0000 00 None 0.00000 0 $0.05 per GB-month of provisioned storage - US West (Oregon) 01.04.14 00:00 30.04.14 23:59 1.126.666.5 54 USD 0.56 0.0 0.0000 00 None 0.56000 0 First 1,000,000 Amazon SNS API Requests per month are free 01.04.14 00:00 30.04.14 23:59 10.0 USD 0.00 0.0 0.0000 00 None 0.00000 0 First 1,000,000 Amazon SQS Requests per month are free 01.04.14 00:00 30.04.14 23:59 4153.0 USD 0.00 0.0 0.0000 00 None 0.00000 0 $0.00 per GB - EU (Ireland) data transfer from US West (Northern California) 01.04.14 00:00 30.04.14 23:59 0.00003292 USD 0.00 0.0 0.0000 00 None 0.00000 0 $0.000 per GB - data transfer out under the monthly global free tier 01.04.14 00:00 30.04.14 23:59 0.02311019 USD 0.00 0.0 0.0000 00 None 0.00000 0 First 1,000,000 Amazon SNS API Requests per month are free 01.04.14 00:00 30.04.14 23:59 88.0 USD 0.00 0.0 0.0000 00 None 0.00000 0 $0.000 per GB - data transfer out under the monthly global free tier 01.04.14 00:00 30.04.14 23:59 3.3E-7 USD 0.00 0.0 0.0000 00 None 0.00000 0
- 48. AWS CloudTrail logs can be delivered cross- account CloudTrail can help achieve many tasks Accounts can send their trails to a central account Central account can then do analytics Central account can: ‣ Redistribute the trails ‣ Grant access to the trails ‣ Filter and reformat Trails (to meet privacy requirements)
- 49. S3 Subtleties • S3 write-only cross-account sharing • Share write-only (no reading or listing of contents) from owner account via bucket policy • Writer accounts have IAM permissions to write
- 51. Staging and Masking Logs • We can mask PII in CloudTrail logs • Bertram Dorn has a Lambda function for it • Originally intended as a proposal to address considerations in upcoming German privacy law • Can be generalised to other consistent AWS log formats
- 52. Staging and Masking Logs • Extend it to mask relevant fields in: • CloudWatch logs • ELB, CloudFront, Amazon VPC flow log, etc. records • ...all of which use CloudWatch Logs • If we use CloudWatch Events, we can use a Lambda function to land our logs in a local S3 bucket, then use a cross-account Lambda function to mask-and-forward • Config records can be forwarded as-is
- 53. Staging and Masking Logs • Flow Logs etc • in CW Logs Local masking Lambda Local S3 bucket Cross-acct Lambda Consolidated logs bucket
- 54. Log Analytics • Splunk, SumoLogic, other AWS Marketplace products • ElasticSearch and Kibana • https://aws.amazon.com/blogs/security/how-to-optimize-and-visualize- your-security-groups/ • Athena • "Run SQL against S3" • QuickSight • Intended for Business Intelligence, but bendable to purpose... ?
- 55. On-premise bucket AWS Account: Bill Aggregation IdP server Organization member account Organization non-member account API Endpoints Read-only, read-all flow API and IAM call flow Logging traffic flow Billing traffic flow
- 56. On-premise bucket AWS Account: Bill Aggregation IdP server AWS Organizations Organization member account Organization non-member account API Endpoints Read-only, read-all flow API and IAM call flow Logging traffic flow Billing traffic flow
- 57. On-premise AWS Lambda role bucket AWS Account: Bill Aggregation and Anonymisation bucket IdP server AWS Organizations Organization member account Organization non-member account API Endpoints AWS Account: Anonymised Bills Read-only, read-all flow API and IAM call flow Logging traffic flow Billing traffic flow
- 58. AWS Account: Log aggregation On-premise bucket AWS Lambda role bucket AWS Account: Bill Aggregation and Anonymisation bucket IdP server AWS Organizations Organization member account Organization non-member account API Endpoints AWS Account: Anonymised Bills Read-only, read-all flow API and IAM call flow Logging traffic flow Billing traffic flow
- 59. On-premise AWS Lambda role bucketbucket AWS Account: Anonymised Logs AWS Lambda role bucket AWS Account: Bill Aggregation and Anonymisation bucket IdP server AWS Organizations Organization member account Organization non-member account API Endpoints AWS Account: Log aggregation and anonymisation AWS Account: Anonymised Bills Read-only, read-all flow API and IAM call flow Logging traffic flow Billing traffic flow
- 60. role On-premise AWS Lambda role bucketbucket AWS Account: Anonymised Logs AWS Lambda role bucket AWS Account: Bill Aggregation and Anonymisation bucket AWS IAM IdP server AWS Organizations Organization member account Organization non-member account AWS Account: IAM Federation API Endpoints AWS Account: Log aggregation and anonymisation AWS Account: Anonymised Bills Read-only, read-all flow API and IAM call flow Logging traffic flow Billing traffic flow
- 61. role On-premise AWS Lambda role bucketbucket AWS Account: Anonymised Logs AWS Lambda role bucket AWS Account: Bill Aggregation and Anonymisation bucket AWS IAM IdP server AWS Organizations Organization member account Organization non-member account AWS Account: IAM Federation API Endpoints AWS Account: Security Team AWS IAM Scanning tools Forensics tools AWS Account: Log aggregation and anonymisation AWS Account: Anonymised Bills Read-only, read-all flow API and IAM call flow Logging traffic flow Billing traffic flow
- 62. AWS Account: Resources AWS IAM role On-premise AWS Lambda role bucketbucket AWS Account: Anonymised Logs AWS Lambda role bucket AWS Account: Bill Aggregation and Anonymisation bucket AWS IAM IdP server AWS KMS AWS Organizations Organization member account Organization non-member account AWS Account: IAM Federation API Endpoints AWS Account: Security Team AWS IAM Scanning tools Forensics tools AWS Account: Log aggregation and anonymisation AWS Account: Anonymised Bills Read-only, read-all flow API and IAM call flow Logging traffic flow Billing traffic flow
- 63. AWS Account: Resources AWS IAM role On-premise AWS Lambda role bucketbucket AWS Account: Anonymised Logs AWS Lambda role bucket AWS Account: Bill Aggregation and Anonymisation bucket AWS IAM IdP server AWS IAM AWS Account: Resources AWS KMS AWS Organizations Organization member account Organization non-member account AWS Account: IAM Federation API Endpoints AWS KMS AWS Account: Security Team AWS IAM Scanning tools Forensics tools AWS Account: Log aggregation and anonymisation AWS Account: Anonymised Bills Read-only, read-all flow API and IAM call flow Logging traffic flow Billing traffic flow
- 64. AWS Account: Resources AWS IAM role On-premise AWS Lambda role bucketbucket AWS Account: Anonymised Logs AWS Lambda role bucket AWS Account: Bill Aggregation and Anonymisation bucket AWS IAM IdP server AWS IAM AWS Account: ResourcesAWS IAM AWS KMS AWS Organizations LDAP AWS Account: Shared Svcs AWS CloudHSM Organization member account Organization non-member account AWS Account: IAM Federation API Endpoints AWS KMS Internal DNS Scanning tools AWS Account: Security Team AWS IAM Scanning tools Forensics tools AWS Account: Log aggregation and anonymisation AWS Account: Anonymised Bills Read-only, read-all flow API and IAM call flow Logging traffic flow Billing traffic flow
- 65. AWS Account: Resources AWS IAM role On-premise AWS Lambda role bucketbucket AWS Account: Anonymised Logs AWS Lambda role bucket AWS Account: Bill Aggregation and Anonymisation bucket AWS IAM IdP server AWS Account: Audit (Internal) AWS IAM AWS Account: ResourcesAWS IAM AWS KMS AWS Organizations LDAP AWS Account: Shared Svcs AWS CloudHSM Organization member account Organization non-member account AWS Account: IAM Federation API Endpoints AWS KMS Internal DNS Scanning tools AWS Account: Security Team AWS IAM Scanning tools Forensics tools AWS Account: Log aggregation and anonymisation AWS Account: Anonymised Bills Amazon QuickSight Read-only, read-all flow API and IAM call flow Logging traffic flow Billing traffic flow
- 66. AWS Account: Resources AWS IAM role On-premise AWS Lambda role bucketbucket AWS Account: Anonymised Logs AWS Lambda role bucket AWS Account: Bill Aggregation and Anonymisation bucket AWS IAM IdP server AWS Account: Audit (Internal) AWS IAM AWS Account: Resources AWS Account: Audit (External) AWS IAM AWS KMS AWS Organizations LDAP AWS Account: Shared Svcs AWS CloudHSM Amazon Athena Organization member account Organization non-member account AWS Account: IAM Federation API Endpoints AWS KMS Internal DNS Scanning tools AWS Account: Security Team AWS IAM Scanning tools Forensics tools AWS Account: Log aggregation and anonymisation AWS Account: Anonymised Bills Amazon QuickSight Read-only, read-all flow API and IAM call flow Logging traffic flow Billing traffic flow
- 67. AWS Account: Resources AWS IAM role On-premise AWS Lambda role bucketbucket AWS Account: Anonymised Logs AWS Lambda role bucket AWS Account: Bill Aggregation and Anonymisation bucket AWS IAM IdP server AWS Account: Audit (Internal) AWS IAM AWS Account: Resources AWS Account: Audit (External) AWS Account: Regulator AWS IAM AWS KMS AWS Organizations LDAP AWS Account: Shared Svcs AWS CloudHSM Amazon Athena Amazon Redshift* Organization member account Organization non-member account AWS Account: IAM Federation API Endpoints AWS KMS Internal DNS Scanning tools AWS Account: Security Team AWS IAM Scanning tools Forensics tools AWS Account: Log aggregation and anonymisation AWS Account: Anonymised Bills Amazon QuickSight Read-only, read-all flow API and IAM call flow Logging traffic flow Billing traffic flow
- 68. AWS Account: Resources AWS IAM role On-premise AWS Lambda role bucketbucket AWS Account: Anonymised Logs AWS Lambda role bucket AWS Account: Bill Aggregation and Anonymisation bucket AWS IAM IdP server AWS Account: Audit (Internal) AWS IAM AWS Account: Resources AWS Account: Audit (External) AWS Account: Regulator AWS IAM AWS KMS AWS Organizations LDAP AWS Account: Shared Svcs AWS CloudHSM Amazon Athena Amazon Redshift* AWS Account: Incident Response Organization member account Organization non-member account AWS Account: IAM Federation API Endpoints AWS KMS Internal DNS Scanning tools AWS Account: Security Team AWS IAM Scanning tools Forensics tools AWS Account: Log aggregation and anonymisation AWS Account: Anonymised Bills Amazon QuickSight Read-only, read-all flow API and IAM call flow Logging traffic flow Billing traffic flow
- 69. AWS Account: Resources AWS IAM role AWS Account: Log aggregation and anonymisation On-premise AWS Lambda role bucketbucket AWS Account: Anonymised Logs AWS Lambda role bucket AWS Account: Bill Aggregation and Anonymisation bucket AWS Account: Anonymised Bills AWS IAM IdP server AWS Account: Audit (Internal) AWS IAM AWS Account: Resources AWS Account: Audit (External) AWS Account: Regulator AWS IAM AWS KMS AWS Organizations LDAP AWS Account: Shared Svcs AWS CloudHSM Amazon Athena Amazon QuickSight Amazon Redshift* bucket AWS Account: Forensic Repo AWS Account: Incident Response bucket AWS Account: Forensic Working Repo Read-only, read-all flow API and IAM call flow Logging traffic flow Billing traffic flow Organization member account Organization non-member account AWS Account: IAM Federation API Endpoints AWS KMS Internal DNS Scanning tools AWS Account: Security Team AWS IAM Scanning tools Forensics tools
- 70. Compliance Enablers: https://aws.amazon.com/compliance/compliance-enablers/ Risk & Compliance Whitepaper: https://aws.amazon.com/whitepapers/overview-of-risk-and-compliance/ Compliance Centre Website: https://aws.amazon.com/compliance Security Centre: https://aws.amazon.com/security Security Blog: https://blogs.aws.amazon.com/security/ Well-Architected Framework: https://aws.amazon.com/blogs/aws/are-you-well-architected/ AWS Audit Training: awsaudittraining@amazon.com Helpful Resources
- 71. The Shared Security Model in Detail: https://youtu.be/RwUSPklR24M IAM Recommended Practices: https://youtu.be/R-PyVnhxx-U Encryption on AWS: https://youtu.be/DXqDStJ4epE Securing Serverless Architectures: https://www.youtube.com/watch?v=8mpTpOXmws8 Helpful Videos
- 72. Thank you!
Editor's Notes
- The 3 standards everyone asks me about, outside of industry-specific ones PCI *is* industry-specific to a large degree, but if you need SOC, it's also good to have as SOC doesn't cover everything. For exampole, PCI has most detailed treatment of how AWS works with you and your investigators in the event of forensics work being needed. PCI and ISO are assessed point-in-time, SOC is assessed over a period. Be sure to look into the details, and get the standards for the details you need.
- These are the 12 top-level subject areas I get asked about, and where I'd start on a mapping.
- The start of a mapping, at AWS level. As well as CloudWatch for monitoring hypervisor-visible load - so, CPU and network I/O, you also have CloudWatch Logs which can give you info on memory and storage capacity.
- Direct Connect gives you known routing to your DX partner and on to us - also consistent performance. VPC, see "A Day in the Life of a Billion Packets" Most interesting here, is IDS / IPS and Managed DDoS - as it happens we released a new reference architecture whitepaper on this last Friday. There's a bit more later on host- or network-based IDS / IPS.
- Post-LogJam, we've supplanted service suites which included SSL to ones which are TLS only in ELB ELB encryption is transparent when using KMS. KMS makes key management, including rotation, easy. CloudHSM can integrate with Safenet KeySecure for S3 encryption and key management, and ProtectV for encryption of EBS volumes, including root volumes of EBS-backed instances. CloudHSM is the option to go for when you need hard asurance that AWS can't get access to your keys. Redshift can talk directly to CLoudHSM, as can Oracle EE deployed on top of RDS.
- Lifecycle Management = hierarchical management, and Glacier vault contents aren't modifiable in-place once written. Actually get one more step on this – EBS gets snapshotted to S3. Deletion protection and versioning on S3 gives you something close to an append-only filesystem - great for logs and other data where you want to have measures in place to preserve evidence or other important data which shouldn't be modifiable.
- Trad controls on-instance still work - except TPM, but some of this can be worked around. Asset management - "No virtual desks to hide your virtual servers under". No way of provisioning something other than via the API, so the feedback loop is closed - API returns truth.
- Trad controls on-instance still work - except TPM, but some of this can be worked around. Asset management - "No virtual desks to hide your virtual servers under". No way of provisioning something other than via the API, so the feedback loop is closed - API returns truth.
- This leads into a program called GoldBase Talk about Launch Constraints – Leveraging an IAM Role to perform Launch for User Talk about Template Constraints – limiting VPCs, Instance Types etc
- aka "how to manage your logging buckets, continued". If you share your versioned, MFA-delete bucket write-only across accounts from a dedicated Audit acct to Production, Staging, etc, then the policy on the bucket and the contents are both invisible and immutable to the account it's being shared with, even its root user - and having spent about half my working life in a multilevel, cross-domain, modified Bell-LaPadula world, this amounts to Mandatory Access Control. You can also set SELinux up in properly constrained Enforcing Mode on EC2 - you could set up user-data at instance launch time to call a script to generate keys and then go into Enforcing mode, if you need to simulate TPM functionality. There may be better ways of doing this, as CloudHSM can be called from Java as well as PKCS#11 - get creative!