AWS for Industries

FSI Services Spotlight: Featuring Amazon Kendra

In this edition of Financial Services Industry (FSI) Services Spotlight monthly blog series, we highlight five key considerations as they pertain to Amazon Kendra, including achieving compliance, data protection, isolation of compute environments, audits with APIs, and operational access and security. For each of these five areas, we will provide specific guidance, suggested reference architectures, and technical code that can help streamline service approval for the featured service, which may need to be adapted to your specific use case and environment.

Amazon Kendra is an intelligent search service powered by machine learning. Amazon Kendra reimagines enterprise search for your websites and applications so your employees and customers can easily find the content they are looking for, including business documents, corporate glossaries, and internal websites, even when it is scattered across multiple locations. Amazon Kendra provides native and partner-developed connectors for popular data sources like Amazon Simple Storage Service (Amazon S3), SharePoint, ServiceNow, OneDrive, Salesforce, and Confluence so you can easily add data from different content repositories and file systems into a centralized location. This enables you to use Amazon Kendra’s natural language search capabilities to quickly find and return the most relevant answers to your questions from within a document, whether that is a text snippet, FAQ, or PDF document. Figure 1 illustrates a standard Amazon Kendra setup.

Figure 1. Amazon Kendra setup

When you type a question, whether it’s through Q&A chatbots, agent-assist, or custom web search, the service uses machine learning (ML) algorithms to understand the context and return the most relevant results. Unlike conventional search technology, natural language search capabilities return the answers you’re looking for quickly and accurately, no matter where the information lives within your organization.

One of the use cases for Amazon Kendra in FSI is minimizing regulatory and compliance risk by enhancing regulatory intelligence. For example, PricewaterhouseCoopers (PwC) has designed a product for regulated industries, providing access to regulatory and compliance information as well as proprietary PwC insights. PwC is now developing and testing enhanced search capabilities using Amazon Kendra to allow users to ask natural language questions, which is a dramatic improvement over traditional keyword searching methods and manual reviews of documents.

Another use case is to increase employee productivity by creating a unified search and discovery experience with faster access to relevant information. Workgrid (a Liberty Mutual Company) offers a self-service Q&A builder that requires no programming. Amazon Kendra is capable of extracting answers directly from the vast quantities of documents (e.g., PDF documents) that exist across the enterprise and helps extend Workgrid’s Chatbot’s ability to fast-track the delivery of accurate answers to customers.

Achieving compliance with Amazon Kendra

Cloud security is top priority at AWS. As an AWS customer, you benefit from a data center and network architecture that is built to meet the requirements of the most security-sensitive organizations. Third-party auditors regularly assess the security and compliance of Amazon Kendra as part of multiple AWS compliance programs.

As part of our shared responsibility model, AWS includes Amazon Kendra in the scope of the following compliance programs. Customers can obtain corresponding compliance reports under an AWS non-disclosure agreement (NDA) through AWS Artifact.

  • SOC 1,2,3
  • PCI
  • ISO/IEC 27001:2013, 27017:2015, 27018:2019,ISO/IEC 9001:2015 and CSA STAR CCM v3.0
  • FedRAMP Moderate(3PAO Assessment)
  • ENS High

Customer compliance responsibility when using Amazon Kendra is determined by the sensitivity of their data, their organization’s compliance objectives, and applicable laws and regulations. AWS provides resources to customers for compliance validations.

Data protection with Amazon Kendra

The AWS shared responsibility model applies to data protection in Amazon Kendra. AWS is responsible for protecting the global infrastructure that runs all of the AWS Cloud. AWS customers are responsible for maintaining control over their content that is hosted on this infrastructure.

At AWS, we recommend our customers secure their data in transit and at rest by encrypting it. For encryption of data in transit, Amazon Kendra uses the HTTPS protocol to communicate with your client application. It uses HTTPS and AWS signatures to communicate with other services on your application’s behalf. Clients must support Transport Layer Security (TLS) 1.2 or later. Clients must also support cipher suites with perfect forward secrecy (PFS) such as Ephemeral Diffie-Hellman (DHE) or Elliptic Curve Ephemeral Diffie-Hellman (ECDHE). Additionally, requests must be signed by using an access key ID and a secret access key that is associated with an IAM principal. Or you can use the AWS Security Token Service (AWS STS) to generate temporary security credentials to sign requests.

AWS Key Management Service (AWS KMS) makes it easy for you to create and manage cryptographic keys and control their use across a wide range of AWS services and in your applications. AWS KMS is integrated with Amazon Kendra to simplify using your keys to encrypt your data.

By default, Amazon Kendra encrypts your data at rest with KMS key owned by AWS. However, you can optionally choose from one of the three types of keys to encrypt your data at rest:

• An AWS owned customer master key (CMK). This is the default.
• An AWS managed CMK. This key is created in your account and is managed and used on your behalf by Amazon Kendra.
• A customer managed CMK. You can create the key when you are creating an Amazon Kendra index or data source, or you can create the key using the AWS KMS console.

When you create a key using the AWS KMS console, you must give the key the following policy that enables Amazon Kendra to use the key. If you create a key with the Amazon Kendra console, the policy is applied to the key for you. For more information, see Using Key Policies in AWS KMS in the AWS Key Management Service Developer Guide.

{
	"Version": "2012-10-17",
	"Statement": [{
		"Effect": "Allow",
		"Principal": {
			"Service": "kendra.amazonaws.com"
		},
		"Action": [
			"kms:Encrypt",
			"kms:Decrypt",
			"kms:ReEncrypt*",
			"kms:GenerateDataKey*",
			"kms:DescribeKey",
			"kms:CreateGrant",
			"kms:RetireGrant"
		],
		"Resource": "arn:aws:kms:us-east-1: 111122223333:key/1234abcd12ab34cd56ef12345678990ab"
	}]
}

Data security

Using IAM policies, Permission boundaries or Service Control Policies customers can limit access to information stored.

The following example policy grants an IAM user or role in your AWS account permission to use the Query operation with any resource tagged with the key department and the value finance.

{
   "Version": "2012-10-17",
   "Statement": [{
  	"Effect": "Allow",
 	"Action": [
 	"kendra:Query"
 	],
   	"Resource":"arn:aws:kendra:us-east-1:111122223333:index/abcd-1234",
   	"Condition": {
 		"StringEquals": {
 			"aws:ResourceTag/department": "finance"
 		}
   	}
   }]
}

The following Service Control Policy ensures that any user or role that don’t have Tag with key department and the value finance is denied access to run query operation on that Index.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": [
                "kendra:Query"
            ],
            "Resource":"arn:aws:kendra:us-east-1:111122223333:index/abcd-1234",
            "Condition": {
                "StringNotEqualsIfExists": {
                   "aws:PrincipalTag/department": "finance"
                }
            }
        }
	]
}

Isolation of compute environments with Amazon Kendra

Amazon Kendra is a managed service that does not have any compute resources on the customer’s side of the shared responsibility model. As a managed service, Amazon Kendra is protected by the AWS global network security procedures.

You can establish a private connection between your VPC and Amazon Kendra by creating an interface VPC endpoint. Interface endpoints are powered by AWS PrivateLink, a technology that enables you to privately access Amazon Kendra APIs without an internet gateway, NAT device, VPN connection, or AWS Direct Connect connection. Instances in your VPC don’t need public IP addresses to communicate with Amazon Kendra APIs. Traffic between your VPC and Amazon Kendra does not leave the Amazon network.

Following is an example of an endpoint policy for Amazon Kendra. When attached to an endpoint, this policy grants access to the listed Amazon Kendra actions for specific principals on specific resource. Customers can choose to limit the Amazon Kendra actions in this endpoint policy to fine tune access, and align with least privilege principle.

{
   "Statement":[
      {
         "Principal":"arn:aws:iam::111122223333:role/service-role/App-AmazonKendra",
         "Effect":"Allow",
         "Action":[
            "Query"
         ],
         "Resource":"arn:aws:kendra:us-east-1:111122223333:index/abcd-1234"      }
   ]
}

Automating audits with APIs with Amazon Kendra

Amazon Kendra provides CloudWatch Logs to provide detail on the operation of data sources. Amazon Kendra creates two types of log streams:

All service calls for Amazon Kendra are logged via AWS CloudTrail . AWS CloudTrail captures all API calls from Amazon Kendra as events, including calls from the Amazon Kendra console and from code calls to the Amazon Kendra APIs. If you create a trail, you can enable continuous deliver of CloudTrail events to and Amazon S3 bucket, including events for Amazon Kendra. If you don’t configure a trail, you can still view the most recent events in the CloudTrail console in Event history. For more information, see Logging Amazon Kendra API calls with AWS CloudTrail logs.

Following is an example of what a CloudTrail log looks like for the Query operation:

{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "[YOUR-PRINCIPAL-ID]",
"arn": "[YOUR-PRINCIPAL-ARN]",
"accountId": "[YOUR-ACCOUNT-ID]",
"accessKeyId": "[YOUR-ACCESS-KEY-ID]",
"userName": "[YOUR-USERNAME]"
},
"eventTime": "2021-07-20T19:29:04Z",
"eventSource": "kendra.amazonaws.com",
"eventName": "Query",
"awsRegion": "us-east-1",
"sourceIPAddress": "[YOUR-SOURCE-IP]",
"userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36",
"requestParameters": {
"indexId": "[YOUR-INDEX-ID]"
},
"responseElements": null,
"requestID": "02413adf-edcb-4dbd-984e-d85b78f6ab4d",
"eventID": "634f3628-4837-4f56-a135-f7c3d58ca8d6",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "[YOUR-RECIPIENT-ACCOUNT-ID]",
"eventCategory": "Management"
}

Operational access and security with Amazon Kendra

AWS customers in the financial services industry may require visibility to any access to their data stored in AWS. Customers can review third-party auditor reports such as the AWS SOC 2 Type II report, ISO 27001, and others in AWS Artifact.

Amazon Kendra stores data only for the use of the index that the data is related to. Customer data is not used for any general model training. See AWS Machine Learning and Artificial Intelligence Services in AWS Service Terms for details.

When you create an index, data source, or an FAQ, Amazon Kendra needs access to the AWS resources required to create the Amazon Kendra resource. You must create an AWS Identity and Access Management (IAM) policy before you create the Amazon Kendra resource. When you call the operation, you provide the Amazon Resource Name (ARN) of the role with the policy attached.

The following example shows a required role policy to enable Amazon Kendra to use an Amazon S3 bucket as a data source. For more information, see IAM roles for indexes, IAM roles for data sources, and IAM roles for FAQs.

{
    "Version": "2012-10-17",
    "Statement": [
         {
            "Action": [
                "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:s3:::bucket name/prefix"
            ],
            "Effect": "Allow"
        },
        {
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::bucket name/prefix"
            ],
            "Effect": "Allow"
        },
        {
            "Effect": "Allow",
            "Action": [
                "kendra:BatchPutDocument",
                "kendra:BatchDeleteDocument"
            ],
            "Resource": [
                "arn:aws:kendra:region:account ID:index/index ID"
            ]
        }
    ]
}

Conclusion

In this post we reviewed Amazon Kendra and highlighted key information that can help FSI customers accelerate the approval of the service within these five categories: achieving compliance, data protection, isolation of compute environments, automating audits with APIs, and operational access and security. While not a one size fits all approach, the above guidance can be adapted to meet your organization’s security and compliance requirements and provide a consolidated list of key areas to focus on with Amazon Kendra.

In the meantime, be sure to visit our AWS Industries blog channel and stay tuned for more financial services news and best practices.

TAGS:
Ramesh Balajepalli

Ramesh Balajepalli

Ramesh Balajepalli is a Senior Solutions Architect at AWS. He enjoys working with customers to solve their technical challenges using AWS services. In his spare time, you can find him spending time with family and cooking.

Amir Imani

Amir Imani

Amir Imani is an AI/ML Specialist at AWS. He is focused on helping Media and Entertainment customers build and operationalize end-to-end machine learning solutions on AWS. Amir also teaches a Machine Learning course at Pratt Institute School of Information. In his spare time, he enjoys reading ML blogs and cycling in New York City.