AWS Security: Identity, Data Protection, and Detection

Protect Identities and Privileged Actions

AWS security follows shared responsibility: AWS protects the cloud infrastructure, while customers control identities, data, configuration, network exposure, and workload code.

Defense in depth combines least-privilege IAM, private network paths, encryption, secret management, vulnerability management, logging, detection, and rehearsed response.

Security controls should be testable. A denied request, an encrypted object, a GuardDuty finding workflow, or a recoverable backup provides stronger evidence than a policy document alone.

Use federation and MFA for people, roles for workloads, and separate break-glass access for emergencies. Review trust policies and privilege-escalation paths, not only the permissions attached to a role.

Remove unused keys and require short sessions for sensitive roles.
Restrict role passing and policy administration.
Use organization service control policies as guardrails, not replacements for IAM.

Reduce Data and Network Exposure

Classify data, encrypt it in transit and at rest, and control who may use the encryption key. Keep databases and internal services private and expose only reviewed entry points.

Store secrets in a managed service and rotate them.
Use resource policies and VPC endpoints to narrow data paths.
Block unintended public access continuously.

Detect Misconfiguration and Threats

CloudTrail, Config, Security Hub, GuardDuty, Inspector, Access Analyzer, and service logs answer different questions. Route findings to an owner and enrich them with account, environment, and resource context.

Aggregate findings across accounts and Regions.
Prioritize exploitable exposure and privileged identity events.
Suppress noise only with a documented reason and expiry.

Prepare for Containment and Recovery

Incident plans should cover credential revocation, network isolation, evidence preservation, clean restoration, and communication. Pre-create response roles and test them before a real account compromise.

Protect logs and backups in a separate account where appropriate.
Practice isolating a compromised instance without destroying evidence.
Record lessons from exercises as preventive controls.

Shared Responsibility by Service

AWS secures facilities, hardware, foundational networking, and managed-service infrastructure according to each service contract. The customer secures identities, data, configuration, application code, and chosen network exposure. The exact boundary changes from EC2 to RDS to Lambda, so write responsibilities per component rather than repeating one generic diagram.

For EC2, the customer owns guest operating-system patching, installed packages, host configuration, and application runtime. RDS moves more database infrastructure operations to AWS, while the customer still owns database users, schema, queries, network access, and data. Lambda removes server administration but leaves code, dependencies, event policy, execution role, and data protection with the customer.

Translate the model into an ownership matrix with control, evidence, frequency, and escalation. A control without an owner is not transferred to AWS by omission. Revisit the matrix when changing service or deployment model because managed does not always mean managed at the layer the team assumed.

Document responsibility for every service layer.
Name the evidence that proves each control works.
Reassess ownership when the architecture changes.
Do not confuse managed infrastructure with managed application security.

Identity and Secret Controls

Use federation and MFA for people, roles for workloads, narrowly scoped trust, and temporary sessions. Protect root and emergency access separately. Review privilege escalation paths involving `iam:PassRole`, policy creation, trust modification, KMS administration, CloudFormation, and access to deployment systems rather than judging roles only by their names.

Store secrets in Secrets Manager, Parameter Store where appropriate, or another approved vault. Encrypt them, restrict read and administrative actions separately, rotate through an application-compatible process, and prevent values from entering source, images, environment dumps, command history, and logs. Rotation is incomplete until running workloads consume the new value.

Use IAM Access Analyzer to validate policies and review external access. Remove unused identities, credentials, and permissions, but preserve tested emergency capabilities. A least-privilege program needs evidence from real API use and explicit ownership for rare disaster actions.

Review privilege-escalation chains, not only attached policy names.
Separate secret use from secret administration.
Test rotation with running workloads.
Expire temporary privilege automatically where possible.

Data and Key Protection

Classify data before selecting storage and logging. Record allowed Regions, accounts, principals, network paths, retention, deletion, backup, and recovery. Encrypt in transit and at rest, but recognize that encryption cannot repair an overbroad principal that is authorized to decrypt and read the data.

A KMS key policy is part of authorization. Separate key administration from key use, scope grants and service conditions, monitor scheduled deletion, and ensure backup or replica recovery can access the required key. Customer-managed keys provide more control and more operational responsibility; service-managed choices can be appropriate when that control is unnecessary.

Prevent public and cross-account exposure through organization policies, public-access blocks, resource policies, Access Analyzer, VPC endpoints, and recurring tests. Apply tokenization, masking, or field-level controls when broad application access is unnecessary. Include logs, snapshots, exports, and caches in the data inventory.

Classify copies, logs, and backups as well as primary data.
Separate KMS use and administration.
Test encrypted recovery in the target account and Region.
Continuously verify public and cross-account exposure.

Workload and Network Protection

Expose the smallest entry surface through load balancers, API gateways, or CloudFront and keep application and data tiers private where practical. Restrict security groups, outbound access, VPC endpoints, and origin paths. AWS WAF filters selected web requests; Shield capabilities address denial-of-service protection; neither fixes insecure application logic or authorization.

Patch operating systems, container bases, language dependencies, functions, and managed-engine versions through a tracked lifecycle. Amazon Inspector and image scanning can identify supported vulnerability findings, but the team must prioritize exploitability, rebuild artifacts, deploy fixes, and verify closure. Remove unsupported software before an emergency upgrade is required.

Harden runtime identities, metadata access, filesystem permissions, container capabilities, and administrative paths. Validate untrusted input, enforce authorization at the business object, and perform application security testing. Cloud controls complement secure code; they do not replace it.

Keep internal tiers behind reviewed entry points.
Control outbound paths and metadata access.
Patch by rebuilding and redeploying immutable artifacts.
Verify object-level authorization in application tests.

Detection and Finding Ownership

CloudTrail records API activity, Config evaluates and records resource configuration, GuardDuty detects selected threat patterns from supported data sources, Security Hub CSPM aggregates and evaluates findings, Macie helps discover sensitive S3 data, and Detective can support investigations. These services overlap operationally but do not produce interchangeable evidence.

Delegate security administration across an organization to a security tooling account where appropriate, aggregate all enabled Regions, and protect the log archive separately. Normalize account, environment, owner, exposure, and resource criticality so a finding can be prioritized. Enable a service only with an alert destination, responder, severity rule, and suppression process.

Tune noise through documented filters with an owner and expiry rather than hiding whole categories indefinitely. Measure time to triage and remediate, test a known finding path, and verify that the security team can assume a response role without depending on a compromised workload administrator.

Know what evidence each security service provides.
Aggregate across accounts and enabled Regions.
Assign every actionable finding to an owner.
Expire suppressions and test detection paths.

Containment and Recovery Drill

Prepare incident roles, clean communication, evidence buckets, credential-revocation procedures, network isolation, backup access, and known-good deployment paths before an incident. Separate containment from destruction: terminating a suspected instance or deleting a role may erase evidence and make scope harder to determine.

For a credential event, identify the principal and sessions, preserve CloudTrail and workload evidence, limit or revoke access, inspect persistence and privilege escalation, rotate affected secrets, and restore through reviewed configuration. For data exposure, determine exact resource policy, object or record scope, time window, access evidence, and legal notification path.

Run tabletop and technical exercises that isolate a workload, revoke a role session path, restore encrypted data, and deploy a clean revision. Record decision authority and recovery time. Feed the lessons into preventative and detective controls rather than treating the exercise report as the final security outcome.

Preserve evidence before destructive containment.
Pre-create narrow incident-response roles.
Test encrypted recovery with separated administrators.
Convert exercise findings into owned controls.

Control Evidence and Exceptions

Represent important security controls as testable outcomes: a denied public request, a role that cannot exceed its boundary, an encrypted restore, a detected configuration change, or a revoked session path. Store owner, scope, evidence location, test frequency, and failure response. Policy prose alone does not show that the deployed control works.

Security exceptions need a business reason, compensating control, approving owner, affected resources, and expiration. Tag or inventory them and alert before expiry. Revalidate after architecture changes because an exception accepted for one private data path may become unsafe after a new public endpoint or cross-account integration.

Test controls from an attackers or unauthorized principals path.
Give exceptions an owner and automatic expiry signal.
Reassess exceptions when exposure or data classification changes.

Security Control Examples

Find IAM Users with Access Keys

aws iam list-users --query "Users[].UserName"
aws iam list-access-keys --user-name alice

Contain a Suspected Access-Key Leak

GuardDuty reports API calls from an unusual location for a long-lived IAM access key.

Contain a Suspected Access-Key Leak

Constraints: Evidence must be retained; containment should not destroy the ability to investigate; production has an alternate role path.
Decision: Disable the key, preserve CloudTrail and workload logs, rotate dependent credentials, scope affected resources, then remove the key.
Verification: The old key is denied, the workload runs through its role, and the incident timeline identifies every attempted action.
Failure test: Replay a harmless signed request with the disabled key and confirm denial is logged.

Output

Expected evidence: The old key is denied, the workload runs through its role, and the incident timeline identifies every attempted action.

This is a worked engineering decision, so the result is operational evidence rather than terminal output.

Before you move on