Data Security

Understand the security posture of supported AWS data resources.

Identity security answers: who can do what? Data Security adds another question: what is the posture of the resource being accessed? Securitain combines resource-security context with IAM analysis so teams can investigate both identity and data risk.

Where to find Data Security

The current navigation includes:

• Overview
• S3 Storage
• KMS & Encryption
• Datastores
• Sensitive Access

Sensitive Access and Identity-to-Data Intelligence are documented separately. This guide covers S3, KMS, RDS and DynamoDB as supported by the current real Data Security collector.

Assessment model

Customer AWS Account
       ↓
Read-oriented assessment
       ↓
S3 / KMS / RDS / DynamoDB
       ↓
Resource posture
       +
Open findings
       +
Supported sensitive-access relationships

Overview

The Data Security Overview summarizes the selected account scope. Current aggregate concepts include total data assets, critical findings, high findings, total open findings, service cards, encryption coverage, backup coverage where supported, and latest scan context.

S3 Storage

S3 security depends on several resource controls. The current Securitain scanner collects supported S3 bucket posture including encryption, public accessibility, versioning, access logging, region, findings and supported classification metadata.

The current real frontend table displays:

• Bucket Name
• Encrypted?
• Public Access?
• Versioning?
• Findings

S3 encryption

S3 buckets should use appropriate encryption at rest. Securitain can determine whether supported bucket default encryption is configured and can identify the encryption type where available. Encryption should be interpreted together with KMS access when customer-managed keys are used.

S3 public access

S3 exposure can arise from multiple AWS controls. Securitain uses supported AWS resource posture signals to identify buckets represented as publicly accessible. Public access deserves investigation.

S3 versioning

S3 versioning can improve resilience by preserving prior versions of objects. The current scanner can represent whether versioning is enabled. Lack of versioning is primarily a resilience/data-protection posture issue. It is not equivalent to identity compromise.

S3 access logging

The backend evaluates supported bucket access-logging posture. Logging is an important audit control that can help detect unauthorized or unexpected bucket access after the fact.

KMS & Encryption

KMS controls the keys used by many AWS encryption workflows. Securitain currently inventories supported KMS key posture and evaluates key-rotation context.

The current real frontend table displays:

• Key Name
• Auto Rotation?
• Findings

Automatic key rotation

Automatic key rotation is an important key-management control for supported KMS key types. Securitain can identify supported keys where automatic rotation is not enabled. The correct remediation depends on key type, key ownership, application architecture and regulatory requirements. Not every KMS key type supports the same rotation behavior.

KMS and data reachability

KMS permission can be critical when data is encrypted with a customer-managed key.

Data resource access
      +
KMS decrypt access
      ↓
Readable encrypted data

Datastores

The current real collector supports Amazon RDS and Amazon DynamoDB. The current frontend table displays Resource Name, Type, Encrypted?, Public Endpoint? (for applicable services), Backup Encrypted?, and Findings.

Amazon RDS

Securitain can collect supported RDS instance posture including:

• encryption at rest
• public accessibility
• automated backup posture
• engine/resource type and region
• findings

For encrypted RDS resources, KMS can also be part of the security relationship. Use Identity-to-Data and KMS analysis for broader access context. Automated backup status is a resilience/data-protection concern and should not be described as equivalent to encryption or identity-access risk.

Publicly accessible RDS

Amazon DynamoDB

The current scanner can inventory DynamoDB tables and their encryption context. DynamoDB is encrypted at rest by AWS. The security distinction involves the type of key used.

DynamoDB
  ↓
Encryption at rest
  ├── AWS-owned key
  └── Customer-managed KMS key

Current Data Security findings

Representative current resource-posture finding concepts include:

• S3: encryption missing, public exposure, versioning disabled, access logging disabled
• KMS: automatic key rotation disabled
• RDS: storage encryption disabled, publicly accessible, automated backups disabled
• DynamoDB: key-management posture involving AWS-owned vs customer-managed encryption

Data classification

The backend can preserve supported data-classification context when available from recognized resource metadata or tags. This is not the same as data-content discovery.

Data Security vs Resource Policies

A complete investigation may need both.

Data Security vs Identity-to-Data

A resource can be strongly encrypted and still be accessible to too many principals. Likewise, identity access can be tightly scoped while the underlying resource has poor resilience configuration.

Investigating a high-risk data resource

1. 1

   Identify the resource

   Determine service, name, region and AWS account.

2. 2

   Review posture

   Check encryption, public exposure, backup/versioning and key rotation where applicable.

3. 3

   Review findings

   Understand what condition is actually detected.

4. 4

   Review resource policy

   Use Resource Policies if the service supports resource-side authorization.

5. 5

   Review identity reachability

   Use Sensitive Access / Identity-to-Data.

6. 6

   Review KMS relationship

   For encrypted resources, understand key access and permissions.

7. 7

   Remediate

   Apply customer-controlled change and verify in a later assessment.

Regional coverage

Data Security collection is available for supported AWS services and regions. See Supported AWS Services & Coverage for current regional scope. S3 bucket inventory is handled at the global/list level and should not be generalized to all regional service behavior.

Evidence and limitations

Data Security assessment depends on:

• supported services and regions
• AWS read permissions and resource configuration availability
• scan freshness and selected account scope

Related guides