Turning up Security on Database Services Part 4

In this article, we explore various security considerations for database services on AWS. Following our discussion on DATS as an add-on for DynamoDB, we now focus on security configurations for OpenSearch and OpenSearch Serverless. Both services offer similar security mechanisms worth understanding.

OpenSearch supports various resource-based policies along with IP-based policies for controlling access. Note that IP-based policies essentially function as identity-based policies by evaluating the user's IP address.

In the diagram above, security groups function like a private link to a data node, which processes incoming data. OpenSearch is widely used for indexing and search processes. Here are some key technical aspects of OpenSearch Service's architecture:

• OpenSearch Service is a managed service supporting OpenSearch and providing Kibana.
• Clusters are not solely composed of a single node type; a distributed search environment is recommended.
• The optimal setup includes dedicated master nodes and the Kibana interface.
• OpenSearch Service handles data persistence internally instead of relying only on external services.

For instance, consider a resource-based policy that incorporates an IP condition. Notice the "Principal" element in the policy below:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": [
        "es:ESHttp*"
      ],
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": [
            "192.0.2.0/24"
          ]
        }
      }
    }
  ],
  "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*"
}

This policy restricts access so that only requests originating from the IP range 192.0.2.0/24 are allowed. The policy is intentionally repeated to emphasize its importance.

To integrate IAM with OpenSearch for access management, you can use IAM users and groups with tailored policies attached at the resource entry point (the domain endpoint). Additionally, OpenSearch supports fine-grained access control, enabling administrators to specify permissions right down to the index or document level.

The fine-grained access control in OpenSearch works alongside security groups to validate client requests within the VPC. The typical access control sequence is as follows:

1. A client sends a request that enters the VPC.
2. The security group authorizes the request to reach the domain.
3. IAM credentials are verified.
4. The access policy confirms the user's permission for the targeted URL or URI.
5. Fine-grained access control applies specific permissions, returning either the full or a partial dataset.

When deploying search applications, implementing fine-grained access control is essential to ensure that users have the minimum permissions required to access specific indexes or documents.

OpenSearch fine-grained access control also supports multiple authentication methods, including native local user access, Cognito, and IAM. Although Cognito may sometimes be omitted as an option, IAM remains the primary method for secure authentication.

Endpoints and private links continue to play critical roles. Only VPC interface endpoints are appropriate for connecting to OpenSearch Service. Remember, gateway endpoints are exclusively used with services like S3 and DynamoDB, while VPC peering and Direct Connect do not attach to specific services.

Reviewing the architecture:

To secure data as it travels between nodes, enable node-to-node encryption on OpenSearch Service. For data at rest, the service provides AES-256 encryption through the Key Management Service, applicable to components such as data nodes and log storage.

A key feature of OpenSearch is its security analytics, which monitors infrastructure and ingests data from various sources to detect anomalous activities in real time. This feature triggers alerts (via Slack, email, SNS, etc.) based on pre-configured security rules. Note that security analytics is supported in OpenSearch 2.5 and later.

Enhanced security analytics in OpenSearch can be visualized through dashboards that display security metrics and trends, offering valuable insights via anomaly detection in your logs.

The discussion now turns to open source databases and their security on AWS. We will now focus on ElastiCache, AWS’s managed version of Redis or Memcached, optimized for caching and ephemeral data storage.

ElastiCache is primarily designed for transient data rather than long-term storage. Its basic architecture for Redis includes a primary node handling write operations and replica nodes for read requests. Furthermore, it supports automatic partitioning across multiple shards when operating in Redis cluster mode.

Security for ElastiCache involves the use of IAM for managing access. For example, an EC2 client armed with a designated role can access ElastiCache using temporary security credentials. While IAM policies define permissions for ElastiCache operations, data-level security within Redis is managed separately through the Redis authentication mechanism.

When evaluating IAM integration with ElastiCache, it is important to recognize that while IAM controls access to the cache service, the Redis authentication mechanism governs operations within the Redis environment.

Network isolation is crucial in AWS. For services like Redis on ElastiCache, deploy them within a VPC and utilize either VPC peering or an interface endpoint (not a gateway endpoint) to achieve private connectivity between services.

For encryption, ElastiCache supports both in-transit encryption (leveraging Redis auth) and encryption at rest. These measures ensure that data remains secure both as it moves between nodes and when stored on disk with help from AWS Key Management Service.

ElastiCache also offers extensive logging options that enhance security and troubleshooting:

• Redis Slow Log

  The Redis slow log captures commands that exceed a specified execution time, which is useful for troubleshooting latency. It logs only the commands that exceed the threshold, rather than providing a full real-time feed.

• The ElastiCache events log records changes such as modifications to cache clusters and parameter groups. These events can be subscribed to via Amazon SNS and are retained for a set period.
• Engine logs offer insights into the Redis engine's behavior, logging errors or capacity issues such as evictions. These logs integrate seamlessly with CloudWatch Logs.

Additionally, AWS provides real-time monitoring via CloudWatch, and the ElastiCache console supports automated service updates. Users can schedule or trigger engine version upgrades according to recommended apply dates. This self-service update feature ensures clusters consistently run the latest security fixes.

In summary, ElastiCache supports encryption for data in transit and at rest, provides comprehensive logging and monitoring capabilities, and offers a straightforward mechanism for applying service updates through the AWS console or API. These features are essential for managing both the security and performance of your cache clusters.

This concludes our discussion of the security features for OpenSearch and ElastiCache. In the next section, we will transition to exploring security options for open source databases such as MongoDB and Cassandra, and how AWS enhances security for these platforms.