Security

When you build systems on AWS infrastructure, security responsibilities are shared between you and AWS. This shared responsibility model reduces your operational burden because AWS operates, manages, and controls the components including the host operating system, the virtualization layer, and the physical security of the facilities in which the services operate. For more information about AWS security, visit AWS Cloud Security.

IAM roles

AWS Identity and Access Management (IAM) roles allow customers to assign granular access policies and permissions to services and users on the AWS Cloud. This solution creates IAM roles that grant the solution’s AWS Lambda functions access to create Regional resources. During deployment, Research Service Workbench names the created IAM roles with the specified  SolutionName and StageName.

Amazon Cognito

With Amazon Cognito, you can add user sign-up and sign-in features and control access to your web and mobile applications. Amazon Cognito provides an identity store that can scale to millions of users. This service is used for creating a User Pool that acts as the default identity provider for the application. This User Pool also manages various authorization roles that a user can be granted access to within the application. Cognito therefore serves as the authentication source and facilitates user authorization processes for the application.

Amazon Virtual Private Cloud

The Amazon Virtual Private Cloud (VPCs) in this solution control and isolate network traffic into research compute environments. We recommend that you review the configuration and further restrict access as needed after deploying the solution. Research Service Workbench creates network components like VPC and associated public subnets via the default installation method. However, users could enter their pre-configured network components into the application for more granular network management.

Amazon CloudWatch

Research Service Workbench on AWS enables logging in the API Gateway by default. Find your logs in Amazon CloudWatch within your log group at:  /aws/api-gateway/<name of your API>.

Log groups created in the main account by Research Service Workbench contain the namespace (ie.  swb-<stage>-<regionShortName>) in their names.

Audit log example:

{
"timestamp": 1679705065785,
"actor": {
"id": "1910dae1-3b34-4356-b823-26664bda8d01",
"roles": [
"ITAdmin",
"<projectIdRedacted>#ProjectAdmin"
]
},
"action": "isAuthorizedOnRoute",
"source": {
"serviceName": "DynamicAuthorizationService6"
},
"requestBody": {
"authenticatedUser": {
"id": "<userUuidRedacted>",
"roles": [
"ITAdmin",
"<projectIdRedacted>#ProjectAdmin"
]
},
"route": "/environmentTypes/<envTypeIdRedacted>/configurations",
"method": "POST"
},
"statusCode": 200,
"logEventType": "audit"
}

API request log example:

{
timestamp: 1679705065786,
awsRequestId: 'sampleRequestId',
logEventType: 'audit',
action: 'POST /environmentTypes/<envTypeIdRedacted>/configurations',
actor: { uid: '<userUuidRedacted>' },
source: { ip: '<IP1Redacted>, <IP2Redacted>' },
body: {
type: 'sagemakerNotebook',
description: 'Example config 1',
name: 'config 1',
estimatedCost: 'estimated cost',
params: [ [Object], [Object], [Object], [Object] ]
}
}

Metrics

Amazon CloudWatch stores the default metrics for AWS Lambda and Amazon API Gateway. For the full list of available metrics, see:

• Working with AWS Lambda function metrics – AWS Lambda

• Amazon API Gateway dimensions and metrics – Amazon API Gateway

Research Service Workbench on AWS does not produce any custom metrics.

Canaries

Research Service Workbench on AWS does not create any canaries by default. You can use Amazon CloudWatch Synthetics to create canaries, configurable scripts that run on a schedule, to monitor your endpoints and APIs. If desired, please refer to the user guide for Using synthetic monitoring within Amazon CloudWatch.

Security groups

The security groups created in this solution control and isolate network traffic between the Lambda functions, CSR instances, and remote VPN endpoints. We recommend that you review the security groups and further restrict access as needed once the deployment is up and running.

Protecting availability

To protect the availability of Research Service Workbench (RSW) from network request overload, you can optionally configure the solution with throttling limits, a deny list, or both.

Throttling limits

Throttling your APIs protect the solution from being overwhelmed by too many requests. You can control the throttling limit with Amazon API Gateway, a fully managed service which makes it easy for developers to create, publish, maintain, monitor, and secure APIs. the solution sets the API Gateway rate limit and burst limit to throttle requests per second and concurrent requests, respectively. For more information on API Gateway throttling, see Throttle API requests for better throughput.

The solution uses AWS Lambda, a serverless, event-driven compute service that lets you run code for virtually any type of application or backend service without provisioning or managing servers, as a compute layer. The Lambda reserved concurrency limit sets the maximum number of concurrent instances for a function. For more information on lambda reserved concurrency, see Configuring reserved concurrency.

To ensure Lambda can handle the maximum API load, the API Gateway throttle limit has been set to the same as the reserved concurrency. By default, the solution sets a throttle limit of 200 requests per second. To adjust the limit in your deployment, see Update throttle limits with API Gateway and Lambda reserved concurrency.

Deny list

To protect the solution from being flooded with requests from one or more IP addresses, you can configure a deny list using AWS WAF, a web application firewall that controls access to your APIs. You can set up custom rules to block or allow access to the solution's APIs based on requests to your API. To block a set of IP addresses, see Add deny list using AWS WAF.