Cloud security posture on AWS

Cloud security posture is a plain question: does the configuration of your cloud environment match what your policies say? Under the shared responsibility model, AWS secures the infrastructure that runs its services. How you configure accounts, identities, networks and storage is yours, and that is the part your auditor tests.

The difficulty on AWS is breadth. There are many services, many regions, and usually more accounts than anyone has listed. A posture program that works picks the small set of controls that matter most, applies them across every account by default, and keeps a record that they held.

This article covers that set: account structure, root and human access, logging, continuous evaluation, data exposure, and how each turns into audit evidence. It describes principles and the native services involved, not console steps, which change often. For the general idea of where the provider's job ends and yours begins, see explaining shared responsibility to customers.

Start with account structure #

On AWS, the account is the strongest isolation boundary you have. Permissions, networks and most quotas stop at the account edge unless you deliberately connect them. Use that.

A structure that holds up under audit, managed through AWS Organizations:

• A management account that runs nothing but the organization itself. Service control policies do not restrict the management account, so anything deployed there sits outside your guardrails.

• Separate production and non-production accounts, so a developer's broad access in a sandbox does not reach customer data.

• A security or audit account that holds delegated administration for security services and receives findings.

• A log archive account that receives logs from every other account and that few people can modify.

This also makes audit scope easier to state. "Production runs in these three accounts" is a sentence an auditor can test. "Production is the resources tagged prod in our main account" is not.

Guardrails with service control policies #

Service control policies set the maximum permissions available in member accounts. They do not grant anything. Use them for the rules that should never have exceptions: preventing anyone from stopping or deleting the organization trail, leaving the organization, or operating in regions you do not use. Changes to these policies are changes to controls, and belong in the same reviewed path as other infrastructure changes.

Root and human access #

The root user of each account can do almost anything and cannot be restricted by IAM policies. Give it a strong password and MFA, create no access keys for it, use it only for the few tasks that require it, and alert on every sign-in. AWS Organizations can also manage root access centrally for member accounts, which lets you remove standing root credentials from them.

People should sign in through federation, either AWS IAM Identity Center or your own identity provider, and receive short-lived role sessions. IAM users with long-lived access keys are a frequent finding in AWS reviews, because the keys end up in laptops, scripts and CI variables. Enforcing MFA at the identity provider covers AWS sign-in too; see enforcing MFA for every user.

Workloads should use IAM roles attached to the instance, container task or function, never access keys stored on a host. For EC2, require version 2 of the instance metadata service, which makes it much harder for a server-side request forgery flaw to steal the instance's role credentials.

IAM Access Analyzer helps on both fronts. It reports resources shared with principals outside your organization, and unused roles, keys and permissions that are candidates for removal.

Logging you will be asked for #

CloudTrail records API activity. The console's event history shows management events for the last 90 days by default, which is not a retention control. An organization trail that delivers to a bucket in the log archive account is. Turn on log file integrity validation, restrict who can modify the bucket, and block deletion of the trail through a service control policy.

Data events, such as object-level reads in S3, are not recorded by default. Turn them on for the buckets and functions that hold or process sensitive data. They add volume and cost, so be selective and document the choice.

AWS Config records the configuration history of your resources. It is the service that answers "what did this security group look like in March", which is the question a Type II period raises. Enable the recorder in every account and every region you use.

VPC Flow Logs record network traffic metadata, useful for investigations and for evidence that segmentation works.

Where these logs go next, and how long you keep them, is covered in centralized logging for compliance.

Continuous evaluation and threat detection #

Two native services do most of the work, ideally enabled organization-wide with the security account as delegated administrator.

AWS Security Hub aggregates findings and evaluates accounts against published standards, including AWS's own foundational security best practices and the CIS AWS Foundations Benchmark. Pick one standard as your baseline rather than enabling every one and drowning in duplicates.

Amazon GuardDuty analyzes CloudTrail events, VPC flow logs and DNS logs to detect suspicious behavior, such as credentials used from unusual locations or instances contacting known malicious hosts.

Enable both in every region, including regions you do not use, or block those regions with a service control policy. An attacker with stolen credentials will happily launch resources in a region nobody watches.

Data exposure: storage, encryption and network #

The configuration mistakes that expose data most directly:

1. Public storage. Turn on S3 Block Public Access at the account level. New buckets block public access by default, but older buckets and account settings may predate that. Use Access Analyzer to confirm nothing is shared outside the organization unintentionally.

2. Unencrypted volumes and databases. Enable default EBS encryption in every region. RDS encryption is chosen when an instance is created; an existing unencrypted instance has to be migrated through an encrypted snapshot copy. Use customer-managed KMS keys where you need control over who can decrypt, as discussed in key management and rotation.

3. Open administrative ports. No security group should allow SSH or RDP from the whole internet. Systems Manager Session Manager gives shell access through IAM, with logging, and no inbound port at all.

Turning posture into audit evidence #

Under SOC 2, these controls support CC6.1 (logical access), CC6.6 (protection against threats from outside the system boundary), and CC7.1 and CC7.2 (detecting configuration changes and anomalies). Under ISO 27001:2022 they map to Annex A 5.23 (information security for use of cloud services), 8.9 (configuration management), 8.15 (logging) and 8.16 (monitoring activities). The SOC 2 framework page sets out the criteria in full.

Collect these on a schedule, not once before fieldwork. A monthly export of each row is the difference between "it is configured correctly today" and "it was configured correctly throughout the period".

How TrustLynce helps #

TrustLynce continuous monitoring runs control checks against the AWS accounts you connect and routes failures to their owners. Evidence collection pulls configuration on a schedule, timestamped and attributed, so the evidence column above builds up across the audit period.