Securing Serverless Architectures

Transcription

1 Securing Serverless Architectures Dave Walker, Specialist Solutions Architect, Security and Compliance Berlin 12/04/ , Web Services, Inc. or its Affiliates. All rights reserved.

2 With Thanks To:

3 Agenda Serverless Architectures: What they Are Caveat Emptor? Constraining Access and Permissions Wrapping Functions API Gateway and Service API Endpoints Generalising Across Serverless Functions Conclusions

4 Serverless Architectures: What They Are

5 Serverless Architectures: What they Are The shiny new thing though S3 has been around for 10 years, now Object stores, object transmission and aggregation pipelines, object format tranformers, standalone code execution systems Abstract (and sometimes, Container) Services looks after the underlying OS, High Availability, Scaling, often Application, transparently Often event-driven ( triggers etc) Customers only need to worry about their functionality

6 Serverless Services

7 For Example Backend Logic IoT Activity Indicator Activity Website Internet API Gateway Chat Service Messages Dynamo Streams Twilio Web Hosting Search Service Slack Chat Elasticsearch Service

8 Caveat Emptor?

9 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

10 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

11 Control Points and Out-of-band Attacks (Almost) 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 connectionmonitored API Endpoint calls need Sigv4 SHA256 HMAC with Secret Access Key (240-bit entropic) over REST request REST calls are checked for formation correctness Looking pretty well-covered

12 In-band Attacks There are more variables here consider access methods and content sizes:

13 Constraining Access and Permissions

14 IAM is your First Port of Call Quickest and highly effective way to reduce risk of serverless misbehaviour at sub-data level All API access should be Role-based Roles can be given to EC2 Instances and functions Roles use ephemeral 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 (Coming Soon)

15 IAM is your First Port of Call API calls can be constrained in IAM by Source IP address Get the range from We could use this to ensure that only our wrapper functions can call our main functions or the real API endpoints Recent development: verify when permissions were last used See Tx280RX2WH6WUD7/Remove-Unnecessary-Permissions-in- Your-IAM-Policies-by-Using-Service-Last-Access

16 Wrapping Functions

17 Let s start with Why? It s a great test case, as: 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 Risk: you can write insecure code in any language (including Node.js, Java, Python and anything you can call from them )

18 Let s start with Already good info on developing functions functions run in an IAM role Consider cross-account function calls (see ) Now let s add a front-end wrapper / filter and back-end / side API checker

19 Wrapping Functions bucket API Gateway DynamoDB

20 Wrapping Functions bucket API Gateway DynamoDB Back end Front end Trigger event source Our original function

21 Wrapping Functions 1. Event triggers wrapper bucket API Gateway DynamoDB

22 Wrapping Functions 1. Event triggers wrapper bucket API Gateway DynamoDB 2. Wrapper passes trigger data to analyser

23 Wrapping Functions 1. Event triggers wrapper bucket API Gateway DynamoDB 2. Wrapper passes trigger data to analyser 3. Analyser reads data

24 Wrapping Functions 1. Event triggers wrapper bucket 4. Wrapper invokes Function API Gateway DynamoDB 2. Wrapper passes trigger data to analyser 3. Analyser reads data

25 Wrapping Functions 5. Function reads data and processes as normal 1. Event triggers wrapper bucket 4. Wrapper invokes Function API Gateway DynamoDB 2. Wrapper passes trigger data to analyser 3. Analyser reads data

26 Wrapping Functions First function, configured to trigger on the event, is a front-end wrapper Passes copy of trigger event input and context to analysis engine (hello, Alert Logic J ) Optionally, waits for content OK response from analysis engine (in-band checking) to determine whether main function should be invoked or calls main function immediately, if performance is more critical (out-of-band checking) Has the same IAM Read / Get permissions in its role as the main function, plus what s needed to send trigger info and invoke the main function

27 Wrapping Functions Analysis Engine Needs IAM permissions to be able to read from the trigger source Needs to be configurable to respond to the calling function after checks are complete (in-band checking, IPSstyle) and / or raise alerts eg via SNS if badness is found (out-of-band checking, IDS-style) In discussion with Alert Logic (co-inventors), but concept and invocation mechanisms are non-exclusive

28 Wrapping Functions Second function, invoked by the first, is our main function Modify the permission conditions in the IAM role so that this function can only be called from IP addresses in the AMAZON range in the same Region ie our wrapping function Consider passing and verifying a shared secret With the front-end wrapped, now let s look at the back

29 API Gateway and API Endpoints

30 API Gateway and API Endpoints bucket API Gateway DynamoDB Back end

31 API Gateway and API Endpoints Consider API Gateway as a protective front-end onto the main API Endpoints Can rate-limit calling frequency Can have back-end functions on each of REST GET, PUT, POST, PATCH, DELETE, HEAD, OPTIONS to check call content Supports Sigv4 and generates logs So, we have a back-end wrapper function J But we need to make API Gateway the target(s) for calls to API Endpoints, in our main function Easy!

32 Endpoint mappings in boto and Java SDK: boto/boto/endpoints.json and aws-java-sdk-core/src/ main/resources/com/amazonaws/partitions/ endpoints.json { "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"

33 Wrapping Functions Hack the in-environment SDK for your own main function! 2-stage function needed, in the execution context: 1. Verify that the endpoints as defined in the SDK are your own API Gateway endpoints; set them if not 2. Invoke the actual doing stuff function

34 Generalising Across Serverless Functions

35 Filtering API Calls API Gateway DynamoDB

36 Filtering Kinesis (and some other) Streams Kinesis Kinesis DynamoDB ElastiCache

37 Services with Trigger Support Config CloudWatch S3 DynamoDB Kinesis SNS SES Cognito CloudFormation

38 Conclusions

39 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 functions can provide useful tap / inspection / filter hook points for queues and pipelines functions can themselves be used as wrap and filter hook points on the input to functions

40 Further Food for Thought? Using Serverless Capabilities to Add Security Functionality to More Traditional Services Config Rules already does this GitHub repo at CI / CD: Add a final post-deploy step onto CodePipeline, and API Gateway as a front-end to pentest infrastructure, to automatically call a pentest down onto the newly-deployed components Let s discuss

41