감사 로그 기록과 규정 준수

An audit log records who did what, when, and to which resource. Unlike debug logs, it exists to answer accountability and compliance questions.

Operational logs help engineers debug; audit logs prove what happened for security and regulators.

• Operational: verbose, short-lived
• Audit: structured, long-retained, tamper-evident

Every audit event should capture the essentials clearly.

Audit logs must be tamper-evident. Write them to append-only storage so records cannot be silently altered or deleted.

Those who can act on a system should not be able to edit its audit log. Store audit data in a separate, restricted store.

Compliance frameworks dictate how long audit logs must be kept, often years. Lifecycle policies must respect these minimums, not just cost.

• PCI DSS, SOC 2, GDPR set retention rules

Audit logs must avoid storing secrets or excessive personal data. Record identifiers and actions, not passwords or full payloads.

Hashing or signing log batches lets you prove later that records were not modified, strengthening the audit trail.

Ship audit events to a dedicated index with strict access controls, separate from noisy operational logs, so queries and reviews stay clean.

Observability adds value by alerting on suspicious audit patterns, like privilege escalations or mass deletions, in real time.

A complete program defines what to audit, secures and retains the records, verifies integrity, and reviews them regularly to satisfy auditors.

You learned that audit logs record who did what to which resource and when, that they must be tamper-evident, access-controlled, and retained per compliance rules, and that they should exclude secrets. Integrity verification and real-time alerting on suspicious events let observability strengthen security and compliance.