Unit 6: The Security Pillar

CSC301 — Introduction To Cloud Computing 8 min read

Security in the AWS Well-Architected Framework is the ability to protect data, systems and assets while delivering business value through risk assessment and mitigation. Everything in this unit rests on the AWS shared responsibility model and the principle of least privilege.

  • Shared responsibility: AWS secures the cloud (hardware, global infrastructure, managed-service internals); the customer secures in the cloud (data, IAM configuration, OS patching, network rules).
  • Least privilege: grant only the permissions required to perform a task, and no more.
  • Defence in depth: layer controls — identity, network, host, data — so no single failure is total.
  • Traceability: monitor, alert and audit every action in near real time.
  • Encryption everywhere: protect data at rest and in transit by default.

II. Identity and Access Management

Controlling who is authenticated and what they are authorised to do.

Identity and Access Management (IAM) is the global, free AWS service that governs authentication (proving identity) and authorisation (granting permissions) for all API calls.

A. Introduction to Identity and Access Management

IAM defines the identities that interact with AWS and the policies that bound them.

  • Principals: entities that make requests — IAM users, groups, roles, or the root user.
  • Policies: JSON documents evaluated on every request; Effect, Action, Resource, Condition.
  • Policy types: identity-based (attached to a principal) versus resource-based (attached to a resource such as an S3 bucket).
  • Evaluation logic: implicit deny by default; an explicit Allow grants access; an explicit Deny overrides any allow.
JSON
{ "Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::reports/*" }

B. Protecting AWS credentials

Credentials are the keys to the account and must be hardened at the root first.

  • Root user: lock away after setup — enable MFA, delete root access keys, never use for daily work.
  • Multi-Factor Authentication (MFA): a second factor (virtual, hardware or FIDO security key) layered on the password.
  • Access keys: long-lived key pairs for programmatic access; rotate regularly and never embed in code — use roles instead.
  • IAM Access Analyzer / credential report: surfaces unused keys and passwords older than a chosen threshold.

C. Fine-grained Authorization

Permissions can be narrowed far below the "whole service" level.

  • Resource-level permissions: restrict actions to specific ARNs, e.g. a single DynamoDB table.
  • Condition keys: Condition blocks test request context — aws:SourceIp, aws:MultiFactorAuthPresent, aws:RequestedRegion.
  • Tag-based (ABAC) control: match a principal tag to a resource tag so one policy scales across many resources.
JSON
"Condition": { "StringEquals": { "aws:ResourceTag/team": "${aws:PrincipalTag/team}" } }

D. Permission Boundaries

A permissions boundary caps the maximum permissions an identity can ever receive.

  • Mechanism: a managed policy set as a boundary on a user or role; effective permissions are the intersection of the boundary and the identity policy.
  • Delegation use case: lets an administrator safely allow developers to create roles without granting escalation beyond the boundary.
  • Contrast with policy: a normal policy grants; a boundary only limits — it never grants on its own.

E. Roles

Roles deliver temporary credentials to whoever assumes them, removing long-lived keys.

  • Trust policy: defines who may assume the role (a service, account or federated identity).
  • STS AssumeRole: issues short-lived credentials (default one hour) via AWS Security Token Service.
  • Common uses:
    • EC2 instance profile: an application on an instance calls AWS with role credentials, no stored keys.
    • Cross-account access: a role in account B trusts account A.
    • Federation: SAML or web-identity users assume a role for console or API access.

F. Enforcing Service-Level Protection

Guardrails above the individual identity constrain entire accounts.

  • Service Control Policies (SCPs): AWS Organizations policies that cap the permissions of all principals in member accounts — e.g. deny use of unapproved regions.
  • Resource-based policies: an S3 bucket or SQS queue policy enforces who may touch the resource regardless of their identity policy.
  • VPC endpoint policies: restrict which principals and resources traffic through a private endpoint may reach.

III. Detective Controls

Recording, monitoring and investigating activity to detect threats.

Detective controls do not prevent actions; they capture and analyse them so that misconfiguration and compromise are discovered quickly.

A. Detective Controls

These establish the audit trail and telemetry on which investigation depends.

  • Logging: capture API calls, resource state and application output.
  • Monitoring: alarm on metrics and anomalous patterns.
  • Auditing: continuously verify configuration against desired baselines.

B. CloudTrail

CloudTrail records every API call made in the account as an event.

  • Event types: management events (control-plane, e.g. RunInstances), data events (object-level, e.g. S3 GetObject), and insight events (anomalous call rates).
  • Trail: delivers logs continuously to an S3 bucket, optionally to CloudWatch Logs; a multi-region, organisation trail captures all accounts.
  • Integrity: log-file validation uses SHA-256 hashing and signing to prove logs were not tampered with.

C. CloudWatch Logs

CloudWatch Logs centralises and acts on log streams from services and applications.

  • Structure: log events grouped into log streams inside log groups, each with a retention setting.
  • Metric filters: match patterns in logs (e.g. repeated Failed logins) and emit a metric that drives an alarm.
  • Subscriptions: stream logs in real time to Lambda or Amazon OpenSearch for processing.

D. Searching Logs with Athena

Athena runs standard SQL directly over logs stored in S3 without loading a database.

  • Serverless: define a table schema over CloudTrail/VPC Flow Log files; pay per data scanned.
  • Example query: find who deleted a security group.
SQL
SELECT eventtime, useridentity.username, sourceipaddress
FROM cloudtrail_logs
WHERE eventname = 'DeleteSecurityGroup';
  • Optimisation: partition by date and use columnar (Parquet) formats to cut scan cost.

E. Auditing Resource Configuration

AWS Config records configuration state and evaluates it against rules over time.

  • Configuration items: point-in-time snapshots of each resource's settings, kept as a timeline.
  • Config rules: managed or custom checks (e.g. "S3 buckets must not be public") that flag non-compliant resources.
  • Remediation: trigger an SSM Automation document to fix drift automatically.

F. Amazon GuardDuty

GuardDuty is a managed threat-detection service using machine learning and threat intelligence.

  • Data sources: CloudTrail events, VPC Flow Logs and DNS logs — no agents required.
  • Findings: typed and severity-scored, e.g. cryptocurrency mining, communication with known-bad IPs, credential exfiltration.

G. Amazon Inspector

Inspector automates vulnerability assessment of workloads.

  • Scope: EC2 instances, container images in ECR, and Lambda functions.
  • Checks: software CVEs and unintended network exposure, continuously as inventory changes.
  • Output: a risk-prioritised score combining CVE severity with reachability.

H. Amazon Detective

Detective helps investigate the root cause of findings after an alert.

  • Graph model: ingests CloudTrail, VPC Flow and GuardDuty data into a linked behaviour graph.
  • Investigation: visualises baseline versus anomalous activity for an IP, account or role, shortening triage.

I. Security Hub

Security Hub aggregates and prioritises findings across security services.

  • Aggregation: pulls from GuardDuty, Inspector, Macie and Config into one normalised format (ASFF).
  • Standards: automated checks against CIS AWS Foundations, PCI DSS and AWS Foundational Security Best Practices, producing a compliance score.

IV. Protecting Network Boundaries

Controlling traffic flow into, out of and within the network.

Network controls form the perimeter and internal segmentation of the VPC.

  • Security groups: stateful, instance-level virtual firewalls; return traffic is implicitly allowed; rules are allow-only.
  • Network ACLs: stateless, subnet-level rules evaluated in numbered order with explicit allow and deny.
  • AWS WAF: filters HTTP(S) at the application layer against SQL-injection, cross-site scripting and rate-based rules.
  • AWS Shield: DDoS protection — Standard is automatic; Advanced adds detection, mitigation and cost protection.
  • AWS Network Firewall: managed stateful firewall for VPC-wide traffic inspection.
  • VPC endpoints: keep traffic to AWS services on the private AWS network rather than the internet.

V. Data Encryption

Rendering data unreadable without the correct key, at rest and in transit.

Encryption is the last line of defence, ensuring stolen data remains useless.

A. Encryption at rest

  • AWS KMS: creates and controls customer master keys (CMKs); integrates with S3, EBS, RDS and more.
  • Envelope encryption: data is encrypted with a data key, which is itself encrypted by the CMK — only the small data key crosses the wire.
  • Key policies and rotation: key policies govern key use; automatic annual rotation is available for KMS keys.
  • CloudHSM: dedicated hardware security modules for single-tenant, FIPS 140-2 Level 3 key custody.

B. Encryption in transit

  • TLS: all AWS service endpoints support HTTPS; enforce it via a policy condition aws:SecureTransport = true.
  • ACM: AWS Certificate Manager provisions and auto-renews TLS certificates for load balancers and CloudFront.

C. Data classification and discovery

  • Amazon Macie: uses machine learning to discover and classify sensitive data such as PII in S3, flagging unencrypted or public objects.