If you haven't already, we strongly recommend you check out parts 1, 2, and 3 of this series. That way you can get all of the information needed to make sure your AWS configuration is as safe as possible. Let's get right into it.

Amazon OpenSearch Service

Amazon OpenSearch Service is a managed solution designed to simplify the deployment, operation, and scaling of OpenSearch clusters within the AWS Cloud environment. Acting as the successor to the Amazon Elasticsearch Service, this managed service supports both OpenSearch and the legacy Elasticsearch OSS, specifically up to version 7.10, which marks the final open-source release of the software. Upon creating a cluster, users are given the flexibility to choose their preferred search engine.

22. Ensuring Encryption at Rest for Amazon OpenSearch Domains

To enhance the security of sensitive data in OpenSearch, it is advisable to enable encryption at rest for your OpenSearch configuration. Elasticsearch domains has a feature for encrypting data (using Advanced Encryption Standard algorithm with 256-bit keys (AES-256)) at rest, using AWS KMS to store and manage encryption keys.

‍

Begin by listing all currently available Amazon OpenSearch domains:

<pre class="codeWrap"><code>aws es list-domain-names --region REGION</code></pre>

Next, verify if the data-at-rest encryption feature is enabled:

<pre class="codeWrap"><code>aws es describe-elasticsearch-domain
--region REGION
--domain-name DOMAIN_NAME
--query 'DomainStatus.EncryptionAtRestOptions'</code></pre>

If the Enabled flag is set to false, it indicates that data-at-rest encryption is not active for the specified Amazon Elasticsearch domain. Rectify this by:

<pre class="codeWrap"><code>aws es create-elasticsearch-domain
   --region REGION
   --domain-name DOMAIN_NAME
   --elasticsearch-version 5.5
   --elasticsearch-cluster-config InstanceType=m4.large.elasticsearch,InstanceCount=2
   --ebs-options EBSEnabled=true,VolumeType=standard,VolumeSize=200
   --access-policies file://source-domain-access-policy.json
   --vpc-options SubnetIds=SUBNET_ID,SecurityGroupIds=SECURITY_GROUP_ID
   --encryption-at-rest-options Enabled=true,KmsKeyId=KMS_KEY_ID</code></pre>

Upon provisioning the new cluster, transfer the existing data (exported from the original cluster) to the newly created cluster.

Once all data is successfully uploaded, it is safe to delete the unencrypted OpenSearch domain to cease incurring charges for the resource:

<pre class="codeWrap"><code>aws es delete-elasticsearch-domain
--region REGION
--domain-name DOMAIN_NAME</code></pre>

Amazon SageMaker

This facilitates seamless deployment into a production-ready hosted environment and stands as a fully managed machine learning service (end-to-end), empowering data scientists and developers to efficiently construct and train machine learning models offering a full-fledged solution for model creation, training, and deployment.

23. Ensuring Limited Internet Access for SageMaker Notebook Instances

If your SageMaker instance lacks a Virtual Private Cloud (VPC) configuration, it will have direct internet access enabled by default. It is recommended to set up your instance with a VPC and adjust the default setting to "Disable — Access the internet through a VPC."

‍

However, it's important to note that for training or hosting models from a notebook, internet access is required. To enable internet access, ensure that your VPC includes a NAT gateway and that your security group permits outbound connections. Detailed instructions on connecting a notebook instance to VPC resources can be found in the "Connect a notebook instance to resources in a VPC" section of the Amazon SageMaker Developer Guide.

‍

Additionally, it is crucial to restrict access to your SageMaker configuration exclusively to authorized users. Limit users' IAM permissions to modify SageMaker settings and resources, thereby adding to the security of your SageMaker environment.

1. Get into the AWS Management Console by visiting https://console.aws.amazon.com/sagemaker/.

2. In the navigation panel, go to Notebook and select Notebook instances.

3. Choose the specific SageMaker notebook instance for examination, and click on the instance name (link).

4. Navigate to the Network section on the selected instance configuration page. Check for VPC subnet IDs and security group IDs. If these network configuration details are unavailable and the status reads "No custom VPC settings applied," it indicates the notebook instance is not running within a VPC. Follow the steps in this conformity rule to deploy the instance within a VPC. Alternatively, if the notebook instance operates within a VPC, inspect the Direct internet access configuration attribute. If set to Enabled, the Amazon SageMaker notebook instance is publicly accessible.

5. If the notebook has direct internet access enabled, rectify it by recreating it using the following CLI command:

<pre class="codeWrap"><code>aws sagemaker create-notebook-instance
   --region REGION
   --notebook-instance-name NOTEBOOK_INSTANCE_NAME
   --instance-type INSTANCE_TYPE
   --role-arn ROLE_ARN
   --kms-key-id KMS_KEY_ID
   --subnet-id SUBNET_ID
   --security-group-ids SECURITY_GROUP_ID
   --direct-internet-access Disabled</code></pre>

AWS Lambda

This allows you to execute code without the hassle of setting up or overseeing servers. You're only charged for the time your code is actively running, with no fees during idle periods. This service supports diverse applications and backend services, all managed seamlessly without user intervention.

‍

Simply upload your code, and Lambda handles the entire process of running and scaling it while ensuring high availability. Automation is at its core, and your code can be configured to trigger automatically from various AWS services or be directly called by web or mobile applications.

‍

Ensuring the security and auditing of the code executed in Lambda functions is crucial. Neglecting this aspect could expose vulnerabilities, potentially serving as the initial access point for attackers. Stay vigilant to mitigate potential risks.

24. Utilize Approved Runtimes for Lambda Functions

This AWS security best practice suggests verifying that the Lambda function configurations align with the expected values established for the approved runtimes in each language. This measure evaluates function settings for the following runtimes: nodejs16.x, nodejs14.x, nodejs12.x, python3.9, python3.8, python3.7, ruby2.7, java11, java8, java8.al2, go1.x, dotnetcore3.1, and dotnet6. The AWS Config rule excludes functions with an image package type.

‍

Lambda runtimes are constructed from a mix of an operating system, programming language, and software libraries, all of which are subject to maintenance and security updates. When a runtime component is no longer eligible for security updates, Lambda marks the runtime as deprecated.

‍

Even if you cannot generate functions using the deprecated runtime, the function remains accessible for processing invocation events. Ensure your Lambda functions are up-to-date and avoid using outdated runtime environments.

Retrieve the names of all Amazon Lambda functions present in the chosen AWS cloud region:

<pre class="codeWrap"><code>aws lambda list-functions
 --region REGION
 --output table
 --query 'Functions[*].FunctionName'</code></pre>

Now, inspect the runtime details available for each function:

<pre class="codeWrap"><code>aws lambda get-function-configuration
 --region REGION
 --function-name FUNCTION_NAME
 --query 'Runtime'</code></pre>

Compare the returned value with the updated list of Amazon Lambda runtimes supported by AWS, along with the end-of-support plan outlined in the AWS documentation.

If the runtime is unsupported, rectify it to employ the latest runtime version. For instance:

<pre class="codeWrap"><code>aws lambda update-function-configuration
 --region REGION
 --function-name FUNCTION_NAME
 --runtime "nodejs16.x"</code></pre>

AWS Key Management Service (AWS KMS)

The AWS Key Management Service (AWS KMS) is a cloud-scaled encryption and key management solution. Other AWS services leverage AWS KMS keys and features, and you can also employ them to secure data within your custom applications utilizing AWS.

25. Avoid Accidental Deletion of AWS KMS Keys

Once deleted, KMS keys cannot be recovered. Additionally, if a KMS key is deleted, any data encrypted under that key becomes permanently unrecoverable. If important data has been encrypted using a KMS key slated for deletion, it is advisable to decrypt the data or re-encrypt it under a new KMS key, unless intentional cryptographic erasure is the goal.

‍

When a KMS key is set for deletion, a mandatory waiting period is in place to allow for the reversal of deletion if it was scheduled in error. The default waiting period is 30 days, but it can be reduced to as little as seven days when scheduling the deletion of the KMS key. During this waiting period, the scheduled deletion can be canceled, and the KMS key will not be deleted.

Enumerate all Customer Master keys available in the chosen AWS region:

<pre class="codeWrap"><code>aws kms list-keys --region REGION</code></pre>

Execute the describe-key command for each CMK to identify any keys slated for deletion:

<pre class="codeWrap"><code>aws kms describe-key --key-id KEY_ID</code></pre>

The output of this command displays the selected key's metadata. If the KeyState value is marked as PendingDeletion, the key is scheduled for deletion. If this is unintended (which is often the case), cancel the deletion with:

<pre class="codeWrap"><code>aws kms cancel-key-deletion --key-id KEY_ID</code></pre>

Amazon GuardDuty

Amazon GuardDuty is a service for ongoing security monitoring. It aids in detecting unforeseen and potentially unauthorized or malicious activities within your AWS environment.

26. Activate GuardDuty

It is strongly advised to enable GuardDuty across all supported AWS Regions. Enabling GuardDuty allows it to produce insights into unauthorized or unusual activities, even in Regions that are not actively utilized. This also permits GuardDuty to oversee CloudTrail events for global AWS services, such as IAM.

‍

Retrieve the IDs of all existing Amazon GuardDuty detectors. A detector is an entity representing the AWS GuardDuty service, and it must be created for GuardDuty to function:

<pre class="codeWrap"><code>aws guardduty list-detectors
--region REGION
--query 'DetectorIds'</code></pre>

If the output of the list-detectors command shows an empty array, there are no GuardDuty detectors present. In this scenario, the Amazon GuardDuty service is not activated in your AWS account. If so, establish a detector using the following command:

<pre class="codeWrap"><code>aws guardduty create-detector
--region REGION
--enable</code></pre>

Once the detector is activated, it will commence fetching and analyzing separate data streams from AWS CloudTrail, VPC flow logs, and DNS logs to generate findings.

AWS Compliance Standards & Benchmarks

Establishing and sustaining the security of your AWS infrastructure is a continual task that demands considerable time. To enhance your efforts, it is advisable to adhere to the relevant compliance standard(s) for your industry. These standards outline the necessary requirements for securing your cloud environment effectively.

‍

Given the continuous nature of securing your environment and aligning with a security standard, it is beneficial to periodically execute policies. For instance, running the CIS Amazon Web Services Foundations Benchmark allows for auditing your system, highlighting any non-conformities discovered based on AWS security best practices.

Conclusion

Moving everything to the cloud brings lots of new possibilities, but it also means there are more ways for bad things to happen. Every new service you use from AWS has its own possible dangers that you should know about and be ready for.