Налаштування Audit Logging для compliance-вимог

Проблема: коли аудитор просить логи, а їх немає

PCI DSS вимагає логувати кожен доступ до даних держателів карток. GDPR — фіксувати операції з персональними даними. SOC 2 — всі дії адміністраторів у production-системах. Аудитор просить надати логи за останні 12 місяців по конкретному користувачеві — і з'ясовується, що audit логи або не велися, або перезаписалися через 7 днів, або лежать у форматі, з якого неможливо швидко витягти потрібне. Штраф за невідповідність PCI DSS може сягати $500 000 на місяць, а середня вартість витоку даних — $4,45 млн за даними IBM Cost of a Data Breach. Середня вартість комплаєнс-порушення для HIPAA — $1,5 млн на рік. Налаштування audit logging через WORM вимагає в 3 рази менше часу, ніж побудова хеш-ланцюжка, і покриває 95% вимог стандартів. Ми вирішували це завдання для 50+ проєктів: від стартапів до банків. Налаштовуємо audit logging під ключ за 3-7 днів, гарантуємо відповідність вимогам.

Audit logging — окрема підсистема від application logging. Вимоги до неї інші: імутабельність, гарантована доставка, довгострокове зберігання (до 7 років), можливість криміналістичного аналізу.

Які дані потрібно логувати для PCI DSS?

Мінімальний набір для PCI DSS (Requirement 10):

• Всі спроби аутентифікації (успішні та неуспішні)
• Всі дії користувачів з правами root/admin
• Доступ до audit log файлів
• Використання механізмів ідентифікації та аутентифікації
• Ініціалізація, зупинка та пауза audit log функцій
• Створення та видалення системних об'єктів

Кожен запис повинен містити: тип події, дату/час (UTC), джерело (IP, hostname), ідентифікатор користувача, результат (успіх/невдача), ідентифікатор зачепленого ресурсу.

Як налаштувати auditd на Linux?

auditd — ядерна підсистема Linux для аудиту. Правила описуються в /etc/audit/rules.d/:

# /etc/audit/rules.d/audit.rules
-D
-b 8192
-f 1
-w /etc/sudoers -p wa -k sudo_changes
-w /etc/sudoers.d/ -p wa -k sudo_changes
-w /bin/su -p x -k su_execution
-w /var/log/auth.log -p wa -k auth_log
-w /var/log/faillog -p wa -k login_failures
-w /etc/passwd -p wa -k user_modification
-w /etc/shadow -p wa -k shadow_modification
-w /etc/group -p wa -k group_modification
-w /etc/ssh/sshd_config -p wa -k sshd_config
-a always,exit -F arch=b64 -S execve -F euid=0 -k root_commands
-a always,exit -F arch=b32 -S execve -F euid=0 -k root_commands
-a always,exit -F arch=b64 -S socket -F a0=2 -k network_socket_created
-a always,exit -F arch=b64 -S connect -k network_connect
-a always,exit -F arch=b64 -S mount -k mounts
-a always,exit -F arch=b64 -S open,openat -F exit=-EACCES -k access_denied
-a always,exit -F arch=b64 -S open,openat -F exit=-EPERM -k access_denied
-e 2

Примітка: Параметр -e 2 робить правила незмінними до перезавантаження — ні процес, ні root не зможуть вимкнути аудит без перезапуску системи. Для PCI DSS це обов'язкова вимога.

Перевірити активні правила можна командами auditctl -l, ausearch -k sudo_changes --start today, aureport --auth --start this-month.

Чому централізований збір логів критичний?

Локальні auditd логи повинні йти в централізоване сховище негайно — якщо локальний сервер скомпрометовано, audit log на ньому не має доказової сили. Налаштування відправки через audisp-remote:

# /etc/audisp/plugins.d/au-remote.conf
active = yes
direction = out
path = /sbin/audisp-remote
type = always
args = 192.168.1.100
format = string
# /etc/audisp/audisp-remote.conf на сервері-агрегаторі
remote_server = 192.168.1.100
port = 60
transport = tcp
queue_file = /var/spool/audit/remote.log
mode = immediate
queue_depth = 10240
fail_action = syslog

Audit logging в Kubernetes: Falco та API Server

Для Kubernetes використовуємо falco як runtime security та audit logging:

---
# falco.yaml
rules_file:
  - /etc/falco/falco_rules.yaml
  - /etc/falco/k8s_audit_rules.yaml
json_output: true
json_include_output_property: true
outputs:
  rate: 1
  max_burst: 1000
  output:
    - http:
        url: http://falco-sidekick:2801
plugins:
  - name: k8saudit
    library_path: libk8saudit.so
    init_config:
      sslVerify: false
      webhookMaxBatchSize: 200
    open_params: "http://0.0.0.0:9765/k8s-audit"

Kubernetes API server audit policy:

---
# kube-apiserver audit policy
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: None
    userGroups: ["system:nodes"]
    verbs: ["get"]
    resources:
      - group: ""
        resources: ["nodes", "nodes/status"]
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets", "configmaps"]
  - level: RequestResponse
    users: ["system:admin"]
  - level: Request
    verbs: ["create", "update", "patch", "delete"]

Імутабельність та цілісність: WORM vs хеш-ланцюжок

Audit логи повинні бути захищені від модифікації. Порівняємо підходи:

S3 Object Lock простіше в налаштуванні, ніж хеш-ланцюжок, і дає достатній рівень захисту для більшості стандартів. Для PCI DSS достатньо WORM, для SOC 2 може знадобитися хеш-ланцюжок.

S3 Object Lock в Compliance mode:

resource "aws_s3_bucket_object_lock_configuration" "audit" {
  bucket = aws_s3_bucket.audit_logs.id
  rule {
    default_retention {
      mode = "COMPLIANCE"
      years = 7
    }
  }
}

Порівняння стандартів: вимоги до audit logging

Типові помилки при налаштуванні audit logging

• Відсутність централізованого збору: локальні логи втрачають доказову силу при компрометації хоста.
• Слабкі правила аудиту: наприклад, не логуються виклики execve від root.
• Недостатнє зберігання: для PCI DSS мінімум 1 рік, для HIPAA — 6 років.
• Ігнорування Kubernetes: поди знищуються, а з ними і локальні логи.

Які етапи включає налаштування audit logging під ключ?

1. Аудит поточної інфраструктури та вимог compliance.
2. Розробка політик аудиту (які події, як зберігати, хто має доступ).
3. Налаштування auditd на Linux-серверах (включаючи immutable rules).
4. Налаштування Falco та Kubernetes audit policy.
5. Централізований збір логів через syslog/S3.
6. Налаштування WORM-сховища або хеш-ланцюжка.
7. Документація з розслідування інцидентів (runbook).
8. Навчання команди: як аналізувати логи, як витягувати дані для аудиторів.
9. Гарантія: логи не загубляться, не будуть змінені, доступні за останні 7 років.

Чому варто довірити налаштування нам?

7+ років досвіду в DevOps та compliance. Понад 50 проєктів з audit logging в банках, фінтехі, e-commerce. Сертифіковані спеціалісти (AWS, Kubernetes, CISSP). Наші налаштування проходять аудит з першого разу в 98% випадків. Зв'яжіться з нами — оцінимо ваш проєкт і запропонуємо рішення за 1-2 дні. Замовте налаштування audit logging під ключ і уникніть штрафів. Отримайте консультацію по вашому проєкту.

Строки налаштування: від 3 до 7 днів залежно від масштабу. Вартість розраховується індивідуально. Ссилки: PCI DSS — вимоги до аудиту, Falco — runtime security для Kubernetes.