Account Separation and Mandatory Access Control
•Download as POTX, PDF•
6 likes•5,283 views
This document discusses implementing mandatory access control and account separation on AWS to improve security. It recommends: 1. Using SELinux on AWS instances to enforce mandatory access control policies that cannot be changed, even by administrators. 2. Implementing the first native MAC service on AWS, Glacier Vault Lock, which sets immutable policies on vaults. 3. Structuring AWS accounts to separate resources, logging, auditing and billing into different accounts controlled by cross-account access policies and IAM roles to restrict what actions and resources each account can access.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Account Separation and Mandatory Access Control
Similar to Account Separation and Mandatory Access Control (20)
More from Amazon Web Services
More from Amazon Web Services (20)
Recently uploaded
Recently uploaded (20)
Account Separation and Mandatory Access Control
- 1. Account Separation and Mandatory Access Control on AWS Dave Walker Specialist Solutions Architect, Security and Compliance 16/03/16
- 2. Mandatory Access Control? • Contrast with Discretionary Access Control – u/g/o / rwx file permissions – Under the control of the file owner • MAC is a function of core system policy – Immutable to all system users; sometimes also invisible to them – …including root • Epitomised in SELinux, descended from Orange Book B1 systems – Sometimes extended to do multilevel / cross-domain security
- 3. Mandatory Access Control? • SELinux on AWS – RHEL, Ubuntu, SuSE, etc AMIs… – (Don’t forget FreeBSD and other Community AMIs) • First native MAC service on AWS: Glacier Vault Lock – Set a Policy and fix it in place – Even the account owner can’t change it, until its time lock expires – Designed to meet SEC “Books and Records” requirements (Rule 17a- 4(f)) • Also FINRA Rule 4511, CFTC Regulation 1.31 • How can we make more services behave similarly? – Cross-account access gets us close!
- 4. S3 Subtleties • Versioning • MFA Delete – Put these together, and you get something which looks a lot like an append-only object store – …consider evidential integrity and weight – Consider adding lifecycle policies to rotate into Vault-Locked Glacier • Good for long-term log retention
- 5. S3 Subtleties • CloudTrail, Config, CloudWatch Logs, ELB logs, VPC Flow Logs – Make them write-only for production / resource accounts • No means to read or list bucket contents – Make them read-only for audit accounts • Though audit user activities may need to be written to logs too – Potentially to a different log location • Create a separate Logging account and apply cross-account sharing:
- 6. 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
- 7. S3 Subtleties: Log Bucket Policy, Part 1 • (Actual policy won’t fit here, but…): – Start with the cross-account bucket policy for writing CloudTrail logs, at https://blogs.aws.amazon.com/security/post/Tx1QT0TX44KW7XM/Sha ring-AWS-CloudTrail-Log-Files-Between-Accounts Scenario 1 – Add the Sid + Effect + Principal + Action + Resource aggregate objects from the bucket policy for Config, at http://docs.aws.amazon.com/config/latest/developerguide/s3-bucket- policy.html , applying the same principles – Add s3:GetBucketLocation permissions, to handle cross-Region logs • (we want to log from all Regions to 1 bucket) – Add the following for CloudWatch Logs:
- 8. S3 Subtleties: Log Bucket Policy, Part 2{ "Sid": "Cross-account write allow for CloudWatch Logs, mediated by control below", "Effect": "Allow", "Principal": ] "AWS": "arn:aws:iam::Writer-Account-ID:root”, <Add other accounts here> ], "Action":[ "s3: PutObject", "S3: GetBucketLocation" ], "Resource":"arn: aws: s3:::myorg-logbucket/<optionalprefix>/AWSLogs/*" }, { "Sid":"Control to require full control grant on write", "Effect":"Deny", "Principal":[ "AWS":"arn: aws:iam::Writer-Account-ID:root”, <Add other accounts here> ], "Action": [ "s3:PutObject", "s3:GetBucketLocation" ], "Resource": "arn:aws:s3:::myorg-logbucket/<optional prefix>/AWSLogs/*", "Condition": { "StringNotEquals": { "s3:"bucket-owner-full-control" } }}
- 9. S3 Subtleties: Log Bucket Policy, Part 3 • Audit users (in another account) will need read-only access to your log bucket; see https://blogs.aws.amazon.com/security/post/Tx1QT0TX44KW7XM/Sharing -AWS-CloudTrail-Log-Files-Between-Accounts , again (Scenario 2) • Good to do via a Role which has to be explicitly assumed; again, see the URL above
- 10. S3 Subtleties: Log Bucket Policy and IAM • Point CloudTrail and Config in other accounts to our log bucket for writing, when setting these accounts up • IAM policy to add to each log-generating account to allow cross-account writing: { "Version": "2012-10-17", "Statement": [ { "Sid": ”Cross-account Write", "Effect": "Allow", "Action": [ "s3:PutObject”, ”s3:GetBucketLocation” ], "Resource": [ "arn:aws:s3:::myorg-logbucket" ] } ]}
- 11. Detailed Billing: Sample Records ItemDescription UsageStar tDate UsageEn dDate UsageQua ntity Currenc yCode CostBef oreTax Cre dits TaxAm ount TaxT ype 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.0000067 5 USD 0.00 0.0 0.0000 00 None 0.0000 00 $0.05 per GB-month of provisioned storage - US West (Oregon) 01.04.14 00:00 30.04.14 23:59 1.126.666. 554USD 0.56 0.0 0.0000 00 None 0.5600 00 First 1,000,000 Amazon SNS API Requests per month are free 01.04.14 00:00 30.04.14 23:5910.0 USD 0.00 0.0 0.0000 00 None 0.0000 00 First 1,000,000 Amazon SQS Requests per month are free 01.04.14 00:00 30.04.14 23:594153.0 USD 0.00 0.0 0.0000 00 None 0.0000 00 $0.00 per GB - EU (Ireland) data transfer from US West (Northern California) 01.04.14 00:00 30.04.14 23:59 0.0000329 2 USD 0.00 0.0 0.0000 00 None 0.0000 00 $0.000 per GB - data transfer out under the monthly global free tier 01.04.14 00:00 30.04.14 23:590.02311019USD 0.00 0.0 0.0000 00 None 0.0000 00 First 1,000,000 Amazon SNS API Requests per month are free 01.04.14 00:00 30.04.14 23:5988.0 USD 0.00 0.0 0.0000 00 None 0.0000 00 $0.000 per GB - data transfer out under the monthly global free tier 01.04.14 00:00 30.04.14 23:593.3E-7 USD 0.00 0.0 0.0000 00 None 0.0000 00
- 12. Linked Accounts • Consolidate daily Detailed Billing logs into one bucket, for all accounts • Now put it all together…
- 13. The Base Account Structure AWS Account Root Account • No Access Keys • MFA Enabled • Raise Alert on Login IAM Master • No Access Keys • MFA Enabled • Raise Alert on Login Define IAM Policies Enable IAM Managers (User or Role) • Have Passwd Policy • Enforce Passwd Rotation • Have Acct Questions set up • Have Info eMail set up IAM Manager • No Access Keys • MFA Enabled Create IAM Users/Groups/Roles Use Pre-Defined Policies
- 14. The Larger Picture BILLING S3 Holder CloudTrail Config CW Logs S3 Holder BILL CloudTrail IAMUser IAM User Assum e Role IAM User Assum e Role IAM User Assum e Role Resources IAM ROLE IAM ROLE IAM ROLE Backup Data Backup S3 Holder Audit Display Rights STS { "Version": "2012-10-17", "Statement": [ { "Sid": ”STS-Only", "Effect": "Allow", "Action": [ "sts:AssumeRole" ], "Resource": [ "*" ] } ] }
- 15. There’s One More Account to Consider… • (…and it won’t fit on the diagram) • Service Catalogue – Also has cross-account capability – Repository for CloudFormation templates, golden AMIs… – …add latest database backups and other necessary datasets, and you have an Intellectual Property Holding Account • Something to copy cross-Region for DR • See http://aws.amazon.com/servicecatalog/faqs/ for cross-account access
- 16. Raising Alerts • Raise (through CloudTrail, watched by a Lambda function triggered on bucket writes) an Alert (through, eg, SNS) if: – Any account’s root user logs in – Any IAM-Master account logs in – Billing/CloudTrail accounts have another S3 Bucket created – IAM-User generates any new AWS resource – IAM-User generates any CloudTrail events other than assume-role and console login – IAM-User logs in to any Resource Accounts (besides IAM-Manager) – Resource-Account has IAM-Users assigned (besides IAM-Master/IAM-Manager)
- 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
- 18. Also: • Federate from IAM-User to another IdP • Filter on LDAP DN elements; ou=, dc= • Result: no PII in IAM! – See page 20 of https://d0.awsstatic.com/whitepapers/aws-whitepaper- single-sign-on-integrating-aws-open-ldap-and-shibboleth.pdf • Set account and contact details to an email alias and a PABX hunt group, and arrange with your AM to have your billing invoiced to your company accounts • …no PII in your AWS account – unless you explicitly need to process PII in your AWS environment
- 19. Other Resources • Re:Invent 2015: “Wrangling Security Events in the Cloud” (SEC308) – https://www.youtube.com/watch?v=uc1Q0XCcCv4 – Further ways to enable service configuration immutability • Essentially, “config-correcting Lambda functions”
- 21. Account Separation and Mandatory Access Control on AWS Dave Walker Specialised Solutions Architect, Security and Compliance 28/01/16
Editor's Notes
- 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!