Security and compliance

Shared responsibility model

AWS is responsible for security of the cloud. The customer is responsible for security in the cloud.

Think “who can physically touch it?” If it’s the building, host or hypervisor, it’s AWS. If it’s what you configure or put on top, it’s you.

Responsibility shifts with the service

The more managed the service, the more AWS does.

Shared controls

Some controls apply to both, each in their own part:

• Patch management: AWS patches the infrastructure. The customer patches guest OSs and applications.
• Configuration management: AWS configures its devices. The customer configures their OS, databases and applications.
• Awareness and training: AWS trains its staff. The customer trains theirs.

Compliance and governance

AWS compliance programmes include SOC 1/2/3, ISO 27001, PCI DSS, HIPAA eligibility, FedRAMP and GDPR support. AWS compliance is for the infrastructure. The customer must still use services in a compliant way. Compliance requirements vary by service: not every service is in scope for every programme, so check AWS Services in Scope by Compliance Program. Requirements also vary by industry and geography, such as data residency rules.

Where logs live

• CloudTrail for API activity (management events by default for the last 90 days in event history; create a trail to store logs in S3 long term).
• CloudWatch Logs for application and system logs.
• VPC Flow Logs for network traffic metadata.
• S3 server access logs and ELB access logs for requests.
• AWS Config for configuration history.

Trap: CloudTrail vs CloudWatch. CloudTrail answers “who made this API call?” CloudWatch answers “how is it performing?” Config answers “what did it look like, and is it compliant?”

Encryption

• AWS Key Management Service (KMS) creates and manages keys and integrates with most services. KMS keys never leave the service unencrypted. Use customer managed keys for control and audit over rotation and use.
• AWS CloudHSM gives you a dedicated, customer-controlled hardware security module (single tenant), for strict compliance needs where you must control the keys yourself.
• AWS Secrets Manager stores and automatically rotates credentials such as database passwords and API keys. Systems Manager Parameter Store stores configuration and secrets values, with simpler features and no built-in rotation.
• ACM provisions and renews public TLS certificates for services such as CloudFront and load balancers.
• Encrypting at rest is a benefit of cloud security, and encryption is usually one setting to turn on.

Identity and access management

IAM building blocks

• AWS managed policies are created and kept up to date by AWS. Customer managed policies are yours. Inline policies are embedded in one identity.
• Everything is denied by default. An explicit deny always wins over any allow.
• Least privilege: give only the permissions needed for the task, no more. Start narrow and widen.
• IAM is global, free of charge, and not tied to a Region.

Authentication methods

• MFA adds a second factor (virtual authenticator app, FIDO2 security key or hardware token). Enable it for the root user and for all privileged users.
• Access keys (access key ID and secret) are for programmatic access (CLI, SDK, API). Rotate them, never embed them in code, never share them. Prefer roles.
• Password policy sets complexity, expiry and reuse rules for IAM users.
• Cross-account roles let a user in one account assume a role in another, without sharing credentials.
• Federation lets users sign in with an external identity provider (corporate directory through SAML 2.0 or OIDC), and it avoids creating an IAM user for each person.
• AWS IAM Identity Center (successor to AWS Single Sign-On) is the recommended way to give workforce users single sign-on across many accounts and applications, with permission sets. Amazon Cognito is for customer sign-in to your own web and mobile apps (user pools and identity pools). AWS Directory Service provides managed Microsoft Active Directory.
• AWS Resource Access Manager (RAM) shares resources such as subnets across accounts.

The root user

The root user is the identity created with the account, using the email address. It has unrestricted access that can’t be limited by IAM policies.

Protect it:

• Enable MFA, use a strong unique password, and don’t create access keys for it.
• Don’t use it for daily work. Create an administrative identity (or use IAM Identity Center) instead.
• Lock away the credentials.

Tasks only the root user can do (commonly tested):

• Change the account settings: account name, email, root password, root access keys.
• Close the AWS account.
• Change or cancel the AWS Support plan.
• Restore IAM user permissions when the only admin is locked out.
• Register as a seller in the Reserved Instance Marketplace.
• Enable MFA Delete on an S3 bucket, and configure some S3 bucket policies after a mistake that locks everyone out.
• View some billing data before delegation (IAM access to billing must be activated by root first).

Everything else, including creating IAM users and launching resources, should not use root.

Services for protecting and detecting

Network-level controls

Because security groups are stateful, return traffic is allowed automatically. A NACL needs explicit rules for both directions.

Security resources and documentation

• AWS Marketplace sells third-party security products (firewalls, antivirus, SIEM) that deploy on AWS.
• Where to find security information: AWS Security Center (the security landing page), AWS Security Blog, AWS Knowledge Center (answers to common questions), AWS re:Post, security bulletins and whitepapers.
• Trusted Advisor security checks flag things such as open security groups, root MFA missing and public S3 buckets. The full set of checks needs a Business or higher support plan. Basic and Developer see the core security checks and service limits only.
• Report abuse (spam, malware, resources used for attacks) to the AWS Trust and Safety team.
• Penetration testing against some services is allowed without prior approval, but you can’t attack AWS itself or run DoS tests without following the policy.