What's changed: Deepened SCS-C02 Chapter 2 (added comparison tables, scenarios, FAQs, exam traps, deep-dive paragraphs to each section; localized figures to Japanese)
2.1Collecting and Protecting Logs
Understand log design—CloudTrail (API auditing), VPC Flow Logs, S3/service logs, organization trails, and tamper protection. Build comprehensive, tamper-resistant logging.
Comprehensive logging underpins security monitoring. Design what to record from where and how to prevent tampering.
2.1.1Log sources and protection
- CloudTrail: API audit logs (who/when/what); organization trail aggregates all accounts.
- VPC Flow Logs: record network traffic metadata (incl. accept/reject).
- Service logs: enable per-service logs like S3 access/ELB/CloudFront/WAF.
- Log protection: prevent tampering/deletion with a dedicated log account + S3 Object Lock (WORM) + KMS encryption.
Common on SCS-C02: API auditing = CloudTrail (organization trail), network = VPC Flow Logs, log tamper protection = S3 Object Lock (WORM) + dedicated log account, log encryption = KMS. Protecting the CloudTrail logs themselves (separate account + WORM) is commonly tested.
SCS-C02 logging design probes "comprehensiveness, tamper resistance, encryption, and aggregation." CloudTrail records management events (resource operations) plus data events (high-volume operations like S3 object access, Lambda invokes) and Insights events (anomalous API volume), with an organization trail aggregating all members’ trails into a dedicated log-archive account. Log file integrity validation (digests) detects tampering, and the destination S3 is protected with Object Lock (compliance-mode WORM) + versioning + MFA Delete + KMS (SSE-KMS) + a restrictive bucket policy. For networking, enable VPC Flow Logs (per ENI/subnet/VPC, accept/reject, to S3 or CloudWatch Logs), DNS via Route 53 Resolver query logs, and per-service S3 access/server access logs, ELB, CloudFront, WAF logs. Crucially, collect logs into a dedicated account separated from their source, restrict access with least privilege, and ensure integrity with encryption and WORM so attackers cannot erase traces. The logs GuardDuty ingests behind the scenes (flow/DNS/CloudTrail) need no separate enablement, but for investigation and compliance, explicitly preserve logs. The key is to aggregate CloudTrail org trail + VPC Flow Logs + service logs into a dedicated log account with WORM/KMS tamper resistance.
| What to record | Log | Key point |
|---|---|---|
| API ops (who did what) | CloudTrail (org trail) | Mgmt/data/Insights events; integrity validation |
| Network traffic | VPC Flow Logs | ENI/subnet/VPC; accept/reject |
| Service-specific | S3/ELB/CloudFront/WAF logs | Explicitly enable per service |
| Log protection | Dedicated account + WORM + KMS | Object Lock; versioning; least privilege |
Scenario: An audit requires "retain API and network logs for all accounts for 7 years, immutable even to administrators." → Aggregate the CloudTrail organization trail and each VPC’s flow logs into S3 in a dedicated log-archive account, protect with Object Lock (compliance mode) + versioning + SSE-KMS (WORM), and enable log file integrity validation. Tightly restrict access with a bucket policy + least privilege, and transition long-term retention to Glacier via lifecycle.
FAQ: CloudTrail management vs data events? Management events are control-plane operations (create/modify/delete resources, logins) recorded by default. Data events are high-volume data-plane operations (S3 GetObject/PutObject, Lambda Invoke), which are voluminous and costly so they are explicitly enabled. To audit object access in S3, you need data events.
Exam trap: Storing CloudTrail logs in a deletable-by-anyone S3 in the same account as the source lacks tamper resistance and is wrong—an attacker can erase traces. The answer is a dedicated log-archive account + Object Lock (WORM) + KMS. Also, enabling logs after an incident records no past events, so CloudTrail/flow logs/GuardDuty must be enabled always, in advance.
2.1.2Section summary
- Logs = CloudTrail (API)/VPC Flow Logs (NW)/service logs
- Protection = dedicated log account + WORM + KMS
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Record API operations across all org accounts centrally and tamper-resistantly. What?
Q2. Record VPC traffic metadata (incl. accept/reject) for investigation. What do you enable?
Q3. Protect the CloudTrail audit logs themselves from deletion/tampering. How?