FSI Services Spotlight: Featuring Amazon OpenSearch

In this edition of the Financial Services Industry (FSI) Services Spotlight monthly blog series, we highlight five key considerations of Amazon OpenSearch: achieving compliance, data protection, isolation of compute environments, automating audits with APIs, and operational access and security respectively. Each of the five areas will include specific guidance, suggested reference architectures that can help streamline service approval of Amazon OpenSearch in your environment. These may need to be adapted to your business, data residency, compliance and security requirements.

Amazon OpenSearch Service is a managed service that makes it easy for you to perform interactive log analytics, real-time application monitoring, website search, and more. Amazon OpenSearch Service is a managed service that uses machine learning to detect anomalies early so you can identify a problem’s root cause. Amazon OpenSearch Service provides integrations with other AWS services and a choice of open source engines, including OpenSearch and ALv2 Elasticsearch.

Financial institutions are leveraging Amazon OpenSearch for a number of workloads across banking, capital markets, and insurance. Toronto based fintech company KOHO Financial (KOHO) is democratizing access to personal finance solutions by offering Canadians accessible and affordable spending and savings products. They historically ran its data and machine learning applications on third party clouds. This created operational complexities for KOHO’s engineers and business users, often delaying teams by 1–24 hours. KOHO developed Instant Pay, a free payroll benefit that gives working Canadians on-demand access to their earnings ahead of their paychecks. To empower its customers to search their KOHO card transactions, KOHO uses Amazon OpenSearch Service, which makes it simple to perform interactive log analytics, real-time application monitoring, website searches, and more. Though KOHO has a small technology team, using managed services on AWS saves time and labor so that the team has more time to innovate.

Resilience and Data residency in Amazon OpenSearch Service

The AWS global infrastructure is built around AWS Regions and Availability Zones. AWS Regions provide multiple physically separated and isolated Availability Zones, which are connected with low-latency, high-throughput, and highly redundant networking. With Availability Zones, you can design and operate applications and databases that automatically fail over between Availability Zones without interruption. Availability Zones are more highly available, fault tolerant, and scalable than traditional single or multiple data center infrastructures.

In addition to the AWS global infrastructure, OpenSearch Service offers several features to help support your data resiliency and backup needs:

• Multi-AZ domains and replica shards
• Automated and manual snapshots

Achieve compliance with Amazon OpenSearch

Security is a shared responsibility between AWS and the customer. AWS is responsible for protecting the infrastructure that runs AWS services in the AWS Cloud and also provides you with services that you can use securely. Your responsibility is determined by the AWS service that you use. On the customer’s side of the shared responsibility model, customers should first determine their requirements for network connectivity, encryption and access to other AWS resources. We will dive deeper into those topics in the upcoming sections.

Amazon OpenSearch falls under the scope of the following compliance programs with regards to AWS’s side of the shared responsibility model. In following sections, we will cover topics on the customer side of the shared responsibility model.

• HIPAA
• FedRAMP
• DoD CC SRG
• SOC
• PCI
• ISO & CSA STAR
• FIPS 140-2

If you have compliance requirements, consider using any version of OpenSearch or Elasticsearch 6.0 or later. Earlier versions of Elasticsearch don’t offer a combination of encryption of data at rest and node-to-node encryption and are unlikely to meet your needs. You might also consider using any version of OpenSearch or Elasticsearch 6.7 or later if fine-grained access control is important to your use case.

Regardless, choosing a particular OpenSearch or Elasticsearch version when you create a domain does not guarantee compliance. Your compliance responsibility when using OpenSearch Service is determined by the sensitivity of your data, your company’s compliance objectives, and applicable laws and regulations. AWS provides the resources to help with compliance.

Infrastructure security in Amazon OpenSearch

As a managed service, Amazon OpenSearch Service is protected by the AWS global network security procedures that are described in Amazon Web Services: Overview of Security Processes

You use AWS published API calls to access the OpenSearch Service configuration API through the network. Clients must support Transport Layer Security (TLS) 1.0 or later. We recommend TLS 1.2 or later. To configure the minimum required TLS version to accept, specify the TLSSecurityPolicy value in the domain endpoint options:

aws opensearch update-domain-config --domain-name my-domain --domain-endpoint-options '{"TLSSecurityPolicy": "Policy-Min-TLS-1-2-2019-07"}'

Clients must also support cipher suites with perfect forward secrecy (PFS) such as Ephemeral Diffie-Hellman (DHE) or Elliptic Curve Ephemeral Diffie-Hellman (ECDHE). Most modern systems such as Java 7 and later support these modes.

Additionally, requests to the configuration API 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.

Depending on your domain configuration, you might also need to sign requests to the OpenSearch APIs. For more information, see Making and signing OpenSearch Service requests

Data protection with Amazon OpenSearch

The security in Amazon OpenSearch service is a shared responsibility between AWS and you. The shared responsibility model describes this as security of the cloud and security in the cloud. As described in this model, AWS is responsible for protecting the global infrastructure that runs all of the AWS Cloud. You are responsible for maintaining control over your content that is hosted on this infrastructure. For data protection purposes, we recommend that you protect AWS account credentials and set up individual users with AWS IAM Identity Center (successor to AWS Single Sign-On) or AWS Identity and Access Management (IAM). That way, each user is given only the permissions necessary to fulfill their job duties. We also recommend that you secure your data in the following ways:

• Use multi-factor authentication (MFA) with each account.
• Use SSL/TLS to communicate with AWS resources. We recommend TLS 1.2 or later.
• Set up API and user activity logging with AWS CloudTrail.
• Use AWS encryption solutions, along with all default security controls within AWS services.
• Use advanced managed security services such as Amazon Macie, which assists in discovering and securing sensitive data that is stored in Amazon S3.

If you require FIPS 140-2 validated cryptographic modules when accessing AWS through a command line interface or an API, use a FIPS endpoint. For more information about the available FIPS endpoints, see Federal Information Processing Standard (FIPS) 140-2.

Encryption At-Rest

Encryption at rest if critical requirement to meet regulatory compliance to ensure only authorized principals can access the sensitive data on underlying storage. To keep this data secure Amazon OpenSearch service domains offer encryption at rest uses  AWS Key Management Service (AWS KMS) to store and manage your encryption keys and the Advanced Encryption Standard algorithm with 256-bit keys (AES-256) to perform the encryption. This feature encrypts All indexes, OpenSearch Logs, Swap files, automated snapshots and all other data in the application directory.

Figure 1: Encryption at-rest on OpenSearch

Figure 2: Enabling encryption at-rest

Manual snapshots, slow Logs and error logs are not encrypted just by enabling encryption of data at rest. You can take additional steps to protect them.

Manual snapshots: You currently can’t use AWS KMS keys to encrypt manual snapshots. You can, however, use server-side encryption with S3-managed keys or KMS keys to encrypt the bucket you use as a snapshot repository. For instructions, see Registering a manual snapshot repository.

Slow logs and error logs: If you publish logs and want to encrypt them, you can encrypt their CloudWatch Logs log group using the same AWS KMS key as the OpenSearch Service domain. For more information, see Encrypt log data in CloudWatch Logs using AWS KMS in the Amazon CloudWatch Logs User Guide.

Encryption In-Transit

For data in transit, AWS offers Secure Socket Layer SSL/TLS encryption. In order to ensure the encryption of data containing sensitive information while in transit below mechanisms can be applied.

1. Secure traffic coming to the domain from AWS CLI, SDK, Client applications  –  In order to secure traffic between the end users and Amazon OpenSearch domains/dashboards a custom URL can be created and secured by generating a certificate in AWS Certificate Manager (ACM) or importing one of your own.
2. Enable Node to Node encryption – To prevent potential attackers from intercepting traffic between Amazon OpenSearch nodes enable node to node encryption using TLS, this ensures the cluster is secured and all communications within the VPC are secured. To enable node to node encryption requires you to use any version of OpenSearch, or Elasticsearch 6.7 or later.

Isolation of compute environments with Amazon OpenSearch

We recommend customers to launch Amazon OpenSearch Service domains in a VPC. Enabling VPC access provides following features.

1. Logical isolation from other virtual networks in the AWS Cloud, which hides Amazon Open Search Service behind private routing.
2. Deploys ENIs into VPC of your choice for each of your data nodes.
3. Provides Security groups to stop private traffic.

Below diagram shows VPC architecture for one Availability Zone.

Figure 3: VPC-based OpenSearch architecture

Customers can also access their Amazon OpenSearch domain by setting up an OpenSearch Service-managed VPC endpoint (powered by AWS PrivateLink). When customers use an interface VPC endpoint, communication between their VPC and Amazon OpenSearch is conducted entirely within the AWS network without using an internet gateway, network address translation (NAT) device, virtual private network (VPN) connection, or AWS Direct Connect connection.

Figure 4: Private access to Amazon OpenSearch

See this blog  and architecture for more details on how to enable private access to Amazon OpenSearch from your client applications in another VPC.

Before launching OpenSearch service domain within VPC, consider the following limitations:

• If you launch a new domain within a VPC, you can’t later switch it to use a public endpoint. The reverse is also true: If you create a domain with a public endpoint, you can’t later place it within a VPC. Instead, you must create a new domain and migrate your data.
• You can either launch your domain within a VPC or use a public endpoint, but you can’t do both. You must choose one or the other when you create your domain.
• You can’t launch your domain within a VPC that uses dedicated tenancy. You must use a VPC with tenancy set to Default.
• After you place a domain within a VPC, you can’t move it to a different VPC, but you can change the subnets and security group settings.
• To access the default installation of OpenSearch Dashboards for a domain that resides within a VPC, users must have access to the VPC. This process varies by network configuration, but likely involves connecting to a VPN or managed network or using a proxy server or transit gateway. To learn more, see About access policies on VPC domains, the Amazon VPC User Guide, and Controlling access to OpenSearch Dashboards.

Automating audits with APIs with Amazon OpenSearch

Financial institutions are often required to audit their AWS services for usage, user activities, and any resource changes as part of their standard IT security and compliance policies. You can use AWS CloudTrail to log all API calls to the Amazon OpenSearch service and Amazon CloudWatch to log all audit logs.

Third-party auditors assess the security and compliance of Amazon OpenSearch service as part of AWS compliance programs. These include PCI and HIPAA BAA. AWS Security Hub provides a comprehensive view of your security state within AWS that helps to check your compliance with security industry standards and best practices.

Amazon OpenSearch service Logs

Amazon OpenSearch Service integrates with AWS CloudTrail, a service that provides a record of actions taken by a user, role, or an AWS service in OpenSearch Service. CloudTrail captures all configuration API calls for OpenSearch Service as events. The captured calls include calls from the OpenSearch Service console, AWS CLI, or an AWS SDK. If you create a trail, you can enable continuous delivery of CloudTrail events to an Amazon S3 bucket, including events for OpenSearch Service. If you don’t configure a trail, you can still view the most recent events on the CloudTrail console in Event history. Using the information collected by CloudTrail, you can determine the request that was made to OpenSearch Service, the IP address from which the request was made, who made the request, when it was made, and additional details. CloudTrail captures calls to the Configuration API, such as CreateDomain and GetUpgradeStatus

Amazon OpenSearch audit Logs

With fine-grained access control in Amazon OpenSearch Service, you can enable audit logs for your data. Audit logs are highly customizable and let you track user activity on your OpenSearch clusters, including authentication success and failures, requests to OpenSearch, index changes, and incoming search queries. The default configuration tracks a popular set of user actions, but we recommend tailoring the settings to your exact needs. OpenSearch Service publishes audit logs to CloudWatch Logs

Operational access and security control with Amazon OpenSearch

Accessing other AWS Services

Amazon OpenSearch Service uses AWS Identity and Access Management (IAM) service-linked roles. A service-linked role is a unique type of IAM role that is linked directly to OpenSearch Service. Service-linked roles are predefined by OpenSearch Service and include all the permissions that the service requires to call other AWS services on your behalf.

A service-linked role makes setting up OpenSearch Service easier because you don’t have to manually add the necessary permissions. OpenSearch Service defines the permissions of its service-linked roles, and unless defined otherwise, only OpenSearch Service can assume its roles. The defined permissions include the trust policy and the permissions policy, and that permissions policy cannot be attached to any other IAM entity.

For information about other services that support service-linked roles, see AWS services that work with IAM and look for the services that have Yes in the Service-linked roles column. Choose a Yes with a link to view the service-linked role documentation for that service.

Amazon OpenSearch Service security has following main layers:

Network

The first security layer is the network, which determines whether requests reach an OpenSearch Service domain. If you choose Public access when you create a domain, requests from any internet-connected client can reach the domain endpoint. If you choose VPC access, clients must connect to the VPC (and the associated security groups must permit it) for a request to reach the endpoint.

Domain access policy

The second security layer is the domain access policy. After a request reaches a domain endpoint, the resource-based access policy allows or denies the request access to a given URI. The access policy accepts or rejects requests at the “edge” of the domain, before they reach OpenSearch itself.

For example, the following resource-based policy grants test-user full access (es:*) to the subresources on test-domain:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::123456789012:user/test-user"
        ]
      },
      "Action": [
        "es:*"
      ],
      "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*"
    }
  ]
}

Two important considerations apply to this policy:

These privileges apply only to this domain. Unless you create similar policies on other domains, test-user can only access test-domain.

The trailing /* in the Resource element is significant and indicates that resource-based policies only apply to the domain’s subresources, not the domain itself. In resource-based policies, the es:* action is equivalent to es:ESHttp*.

For example, test-user can make requests against an index (GET https://search-test-domain.us-west-1.es.amazonaws.com/test-index), but can’t update the domain’s configuration (POST https://es.us-west-1.amazonaws.com/2021-01-01/opensearch/domain/test-domain/config). Note the difference between the two endpoints. Accessing the configuration API requires an identity-based policy.

You can specify a partial index name by adding a wildcard. This example identifies any indexes beginning with commerce:

arn:aws:es:us-west-1:987654321098:domain/test-domain/commerce*

In this case, the wildcard means that test-user can make requests to indexes within test-domain that have names that begin with commerce.

To further restrict test-user, you can apply the following policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::123456789012:user/test-user"
        ]
      },
      "Action": [
        "es:ESHttpGet"
      ],
      "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/commerce-data/_search"
    }
  ]
}

Now test-user can perform only one operation: searches against the commerce-data index. All other indexes within the domain are inaccessible, and without permissions to use the es:ESHttpPut or es:ESHttpPost actions, test-user can’t add or modify documents.

Fine-grained access control

The third and final security layer is fine-grained access control. After a resource-based access policy allows a request to reach a domain endpoint, fine-grained access control evaluates the user credentials and either authenticates the user or denies the request. If fine-grained access control authenticates the user, it fetches all roles mapped to that user and uses the complete set of permissions to determine how to handle the request.

Roles are the core way of using fine-grained access control. In this case, roles are distinct from IAM roles. Roles contain any combination of permissions: cluster-wide, index-specific, document level, and field level.

After configuring a role, you map it to one or more users. For example, you might map three roles to a single user: one role that provides access to Dashboards, one that provides read-only access to index1, and one that provides write access to index2. Or you could include all of those permissions in a single role.

Users are people or applications that make requests to the OpenSearch cluster. Users have credentials—either IAM access keys or a user name and password—that they specify when they make requests. With fine-grained access control on Amazon OpenSearch Service, you choose one or the other for your master user when you configure your domain. The master user has full permissions to the cluster and manages roles and role mappings.

• If you choose IAM for your master user, all requests to the cluster must be signed using AWS Signature Version 4. For sample code, see Signing HTTP requests to Amazon OpenSearch Service.We recommend IAM if you want to use the same users on multiple clusters, if you want to use Amazon Cognito to access Dashboards, or if you have OpenSearch clients that support Signature Version 4 signing.
• If you choose the internal user database, you can use HTTP basic authentication (as well as IAM credentials) to make requests to the cluster. Most clients support basic authentication, including curl, which also supports AWS Signature Version 4 with the –aws-sigv4 option. The internal user database is stored in an OpenSearch index, so you can’t share it with other clusters. We recommend the internal user database if you don’t need to reuse users across multiple clusters, if you want to use HTTP basic authentication to access Dashboards (rather than Amazon Cognito), or if you have clients that only support basic authentication. The internal user database is the simplest way to get started with OpenSearch Service.

Fine-grained access control offers the following benefits:

1. Role-based access control
2. Security at the index, document, and field level
3. OpenSearch Dashboards multi-tenancy
4. HTTP basic authentication for OpenSearch and OpenSearch Dashboards

Cross-service confused deputy prevention

The confused deputy problem is a security issue where an entity that doesn’t have permission to perform an action can coerce a more-privileged entity to perform the action. In AWS, cross-service impersonation can result in the confused deputy problem. Cross-service impersonation can occur when one service (the calling service) calls another service (the called service). The calling service can be manipulated to use its permissions to act on another customer’s resources in a way it should not otherwise have permission to access. To prevent this, AWS provides tools that help you protect your data for all services with service principals that have been given access to resources in your account.

We recommend using the aws:SourceArn and aws:SourceAccount global condition context keys in resource policies to limit the permissions that Amazon OpenSearch Service gives another service to the resource.

The following example shows how you can use the aws:SourceArn and aws:SourceAccount global condition context keys in OpenSearch Service to prevent the confused deputy problem.

{
  "Version": "2012-10-17",
  "Statement": {
    "Sid": "ConfusedDeputyPreventionExamplePolicy",
    "Effect": "Allow",
    "Principal": {
      "Service": "es.amazonaws.com"
    },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": {
        "aws:SourceAccount": "123456789012"
      },
      "ArnLike": {
        "aws:SourceArn": "arn:aws:es:region:123456789012:domain/my-domain"
      }
    }
  }
}

Authentication for OpenSearch Dashboard

SAML authentication for OpenSearch Dashboards

SAML authentication for OpenSearch Dashboards lets you use your existing identity provider to offer single sign-on (SSO) for Dashboards on Amazon OpenSearch Service domains running OpenSearch or Elasticsearch 6.7 or later. To use SAML authentication, you must enable fine-grained access control.

SAML authentication for OpenSearch Dashboards lets you use third-party identity providers to log in to Dashboards, manage fine-grained access control, search your data, and build visualizations. OpenSearch Service supports providers that use the SAML 2.0 standard, such as Okta, Keycloak, Active Directory Federation Services (ADFS), and Auth0.

SAML authentication for Dashboards is only for accessing OpenSearch Dashboards through a web browser. Your SAML credentials do not let you make direct HTTP requests to the OpenSearch or Dashboards APIs.

Amazon Cognito authentication for OpenSearch Dashboards

You can authenticate and protect your Amazon OpenSearch Service default installation of OpenSearch Dashboards using Amazon Cognito. Amazon Cognito authentication is optional and available only for domains using OpenSearch or Elasticsearch 5.1 or later. If you don’t configure Amazon Cognito authentication, you can still protect Dashboards using an IP-based access policy and a proxy server, HTTP basic authentication, or SAML.

Conclusion

In this post we reviewed Amazon OpenSearch and highlighted key information that can help FSI customers to accelerate the approval of OpenSearch 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 guidance provided can be adapted to meet your organization’s security and compliance requirements and provide a consolidated list of key areas to focus on for Amazon OpenSearch. In the meantime, be sure to visit AWS FSI Services Spotlight Blog Series and stay tuned for more financial services news and best practices. For more information, visit the AWS Financial Services page and AWS Compliance Center and read the Security Pillar – AWS Well-Architected Framework whitepaper.