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.

Security best practices

QnABot on AWS is designed with security best practices in mind. However, the security of a solution differs based on your specific use case. Adding additional security measures can add to the cost of the solution. The following are additional recommendations to enhance the security posture of QnABot on AWS in production environments.

Amazon S3 access logging bucket configuration

We recommend having a central access logging Amazon S3 bucket, and updating the S3 buckets that this solution creates to allowing access logging. QnABot on AWS by default configures a central access logging Amazon S3 bucket to store access logging. For more information about Amazon S3 access logging see Enabling Amazon S3 server access logging in the Amazon Simple Storage Service User Guide.

Multi-factor authentication (MFA) in Amazon Cognito user pools

This solution creates only one user in its Cognito user pools. MFA is not activated by default; however, we recommend using MFA for users in Cognito for a stronger security posture in production workloads. For more information about setting up MFA in Cognito, see Adding MFA to a user pool and Adding advanced security to a user pool in the Amazon Cognito Developer Guide.

Single sign-on with AWS IAM Identity Center

Solution administrators can also federate into the content designer UI and OpenSearch Dashboards using single sign-on with AWS IAM Identity Center. In this case, IAM Identity Center serves as the identity provider for the Cognito user pool. Additionally, using Cognito, you can configure a SAML or OpenID Connect identity provider to federate with as well.

When users federate into Cognito, a user profile is dynamically provisioned for them, but they will not be granted access to QnABot on AWS until they are added to the Admins group. For more information about automating using a Lambda trigger see Customizing User Pool Workflows with Lambda in the Amazon Cognito Developer Guide.

AWS WAF for Amazon API Gateway

When the chatbot application is open to public access in production, we recommend allowing AWS WAF for API Gateway. For guidance about setting up AWS WAF, see Using AWS WAF to protect your APIs in the Amazon API Gateway Developer Guide. We also recommend reviewing the AWS Best Practices for DDoS Resiliency whitepaper for information about protecting your AWS applications from Distributed Denial of Service (DDoS) attacks.

For best security practices, we recommend adding rules/rule groups when creating your web access control list (ACL) in AWS WAF. AWS WAF provides the ability to set AWS managed rules and custom rule groups which the customer creates and maintains. We recommend adding Core rule set and Known bad inputs managed rule groups when setting up your web ACL. See AWS WAF rule groups in the AWS WAF, AWS Firewall Manager, and AWS Shield Advanced Guide for more information on setting up managed and created rule groups.

Creating a custom domain in Amazon API Gateway

By default, QnABot deploys the default domain in API Gateway. The default domain uses a TLS version 1.0 security policy, which uses outdated encryption protocols and weak encryption cyphers. We recommend that the customer sets up a custom domain name and uses a TLS version 1.2 security policy. See Choosing a security policy for your custom domain in API Gateway in the Amazon API Gateway Guide.

Children Online Privacy Protection Act (COPPA) settings for Amazon Lex

When using this solution to create or update an Amazon Lex chatbot, set the Amazon Lex API childDirected parameter to true if the bot’s users are subject to COPPA. For more information, see DataPrivacy in the Amazon Lex API Reference.

AWS CloudFormation parameters

Before deployment, we recommend reviewing the PublicOrPrivate parameter. It has two possible values: Public or Private. We recommend choosing Private unless the use case for this solution dictates having the chatbot open to the public without needing to sign up or register. If you select Public, we recommend enabling AWS WAF for Amazon API Gateway.

Amazon Cognito

The solution uses a Cognito user pool for controlling administrative access to the QnABot on AWS content designer UI, Amazon Lex web client, and OpenSearch Dashboards. Users are also required to be members of the Admins group in the Cognito user pool.

The content designer UI requires that you sign in with credentials defined in an Amazon Cognito user pool. Using temporary AWS credentials from Cognito, the content designer UI interacts with secure API Gateway endpoints backed by the content designer’s Lambda functions.

The Amazon Lex web client is deployed to an Amazon S3 bucket in your account, and accessed via API Gateway. An API Gateway endpoint provides run time configuration. Using this configuration, the web client connects to Cognito to obtain temporary AWS credentials, and then connects with the Amazon Lex service.

AWS Lambda

The solution uses Lambda functions. Depending on your use case, we recommend that you configure Lambda function-level concurrency run limits. Adding concurrency limits can prevent a rapid spike in usage and costs, while also increasing or lowering the default concurrency limit.

IAM roles

IAM roles allow customers to assign granular access policies and permissions to services and users on the AWS Cloud. This solution creates IAM roles with least privileges that grant the solution’s resources with needed permissions.

CloudWatch Logs

For QnABot on AWS, CloudWatch Logs are set by default to never expire. You can Export log data to Amazon S3.

Data storage and protection

The solution uses multiple services to store and protect your data. This solution defaults to the following when storing and protecting the customer’s data:

Service/Resource	Default
CloudWatch Logs	- Default CloudWatch Logs set to Never Expire.
DynamoDB	- User table stores chat message history (per user) – never expires. - Data fully encrypted at rest (managed by DynamoDB). - Point-in-time recovery enabled by default. - Continuous backups disabled. - Does not store PII data.
OpenSearch Dashboards index	- Default expiry set to 30 days.
Amazon S3	- Default Never Expire for Metrics bucket and Export bucket. - All buckets are enabled with server-side encryption (SSE) by default. See Setting default server-side encryption behavior for Amazon S3 buckets for additional guidance. - Access logging is disabled, customer can configure. For additional guidance, see Setting default server-side encryption for Amazon S3 buckets in the Amazon Simple Storage Service User Guide.
Amazon Lex	- Default, logs not enabled. For additional guidance, see Conversation Logs in the Amazon Lex V2 Developer Guide. - Encrypting conversation logs is optional, but can be implemented if needed. For additional guidance, see Encrypting Conversation Logs in the Amazon Lex V2 Developer Guide. - Audio logs are stored in Amazon S3 (default encryption). - The childDirected parameter for COPPA defaults to false. For additional guidance, see DataPrivacy in the Amazon Lex API Reference. - PII redaction capability is implemented on logs.
AWS Key Management Service	- The solution can store PII data. By default, DynamoDB is encrypted, but we recommend using Customer Managed Keys (CMK) if you intend to store sensitive data. For additional guidance, see the utility_scripts section in the GitHub repository.
Amazon Data Firehose	- SSE enabled via AWS KMS key.