Введение

SOX foundational control — Segregation of Duties (SoD). Идея: один и тот же актор не должен initiate, execute, approve и monitor одну и ту же критическую операцию. Если single actor контролирует всё, fraud + error тривиальны. Эта логика разработана для accounting (clerk записывает invoice ≠ supervisor approving, ≠ treasurer paying, ≠ аудитор reviewing).

В мире данных применяется тот же принцип, но акторы часто запутаны. Инженер пишет пайплайн; тот же инженер мерджит PR; тот же инженер деплоит; тот же инженер мониторит метрики. Причина — небольшие команды, on-call rotations, DevOps culture. Результат — SoD violation by default.

SwiftRide T+3M Big 4 finding 9: «Пайплайн SwiftPay payouts — single инженер написал, мерджил, деплоил, и on-call для CDE-SWR-003. SoD не enforced. Material risk: unauthorised value change OR error без peer detection до prod».

В этом уроке разберём 4-actor model в data-контексте, как реализовать через GitHub + CODEOWNERS + Snowflake roles + monitoring rotation, и какие компенсирующие контроли возможны в small-team environments.

Классическая 4-actor model SoD

Изначальная рамка: 4 distinct роли для material operation.

Критическое правило: каждая роль должна быть filled by distinct individual. Минимум 3-4 разных людей для одной material operation. Single-person bypass — SoD violation.

Почему все 4 нужны

• Initiator + Approver один человек → unauthorised changes (нет peer review).
• Approver + Executor один человек → нет checkpoint между approval и execution; rubber-stamp.
• Executor + Monitor один человек → инженер деплоит bug, мониторит без bias (не будет флажить собственные ошибки).
• Initiator + Monitor один человек → инженер пишет пайплайн, мониторит собственную работу — confirmation bias.

SoD в data-контексте — вызовы

Challenge 1 — DevOps culture: «who writes runs»

Индустриальный стандарт: «you build it, you run it». Инженер responsible за пайплайн + on-call. Это прямой конфликт с разделением executor + monitor в SoD.

Митигация: «build it, run it» ротируется между членами команды; Инженер A builds Pipeline X, Инженер B builds Pipeline Y; on-call shared rotation across team (не per-pipeline).

Challenge 2 — Маленькие команды: 2-3 человека

Если команда имеет 3 инженера + 1 lead, сложно найти 4 distinct individuals для каждой material operation.

Митигация: cross-team enrolment. SwiftRide: изменения пайплайна SwiftPay — Finance Lead approver, Data Platform инженер executor, Data Quality team monitor. Роли взяты из разных команд.

Challenge 3 — Emergency changes

2 AM production-инцидент; один инженер present. Нельзя ждать 4-person review.

Митигация:

• Emergency hot-fix branch с CSO retroactive approval в течение 24h.
• Post-emergency обязательно: retro PR с полным review; retro ServiceNow CR; еженедельный CSO review emergency changes (anti-pattern catch — если emergency changes частые, normal process broken).

Challenge 4 — Service accounts

Пайплайн работает как service account (Airflow runner). Service account не «person». Кто executor?

Митигация: поведение service account определяется кодом; код authored + approved людьми. Service account = «executor от имени approved кода». Логированный trail per code change (PR SHA → deploy → service-account run).

SwiftRide дизайн SoD для пайплайна payouts SwiftPay

5 distinct individuals (Anna, Carlos, Priya, Yuki, Sami) across 4 разных команд (Data Platform, Finance Data Office, Data Quality, SwiftPay business). Каждый PR на material CDE-пайплайн SwiftPay проходит этот flow.

Реализация — инструменты

GitHub branch protection + CODEOWNERS

CODEOWNERS file в repo:

# Material CDE pipelines — Finance Lead + Data Platform Lead approval обязательны
/dbt/models/marts/swiftpay/*.sql              @finance-lead-carlos @data-platform-lead-priya
/dbt/models/marts/driver_earnings/*.sql       @finance-lead-carlos @data-platform-lead-priya
/dbt/models/marts/revenue/*.sql               @cfo-office @data-platform-lead-priya

# Schema migrations — требуют 3 approvals
/dbt/schema/marts/swiftpay/*.yml              @finance-lead-carlos @data-platform-lead-priya @security-lead-sven

# CDE registry entries
/cde-registry/*.yaml                          @cdo-office @data-platform-lead-priya

Branch protection rule на main:

• Pull request обязателен (нет direct push).
• Approvals: 2 reviewers (один ОБЯЗАТЕЛЬНО CODEOWNERS).
• Signed commits required.
• Status checks: dbt compile + dbt test должны pass.
• Нет bypass даже для admins (force-push отключён).

Snowflake RBAC

Роли разделены по функции:

• ROLE_DATA_PLATFORM_ENGINEER — read all schemas; write в dev_* schemas только; НЕ МОЖЕТ модифицировать production CDE tables напрямую.
• ROLE_AIRFLOW_RUNNER_PROD — write production CDE schemas; granted только Airflow service account; учётные данные service account в Vault, ротируются 90d.
• ROLE_DATA_OWNER_FINANCE — read production financial CDE; НЕ МОЖЕТ модифицировать напрямую.
• ROLE_AUDIT_READ_ONLY — read all CDE + evidence_index; НЕ МОЖЕТ модифицировать; granted Big 4 + internal audit для evidence review.

SoD enforcement: инженер (роль Data Platform Engineer) не может write в production CDE напрямую — должен пройти через approved PR → Airflow Runner. Direct UI changes к CDE блокированы RBAC. Если break-glass needed, ACCOUNTADMIN role (3 named accounts) требует 2-person concurrent approval через Saviynt PIM.

Airflow + service accounts

Airflow DAG запускает только код, который уже в main branch (signed commits, CODEOWNERS approved). Service account credentials отделены от human credentials. Service account audit log → CloudTrail + Snowflake access_history → S3 7y.

On-call rotation

Data Quality team управляет PagerDuty rotation для material CDE-пайплайнов. DQ-команда отдельная от Data Platform team (другая reporting line). DQ-инженер, делающий review alerts ≠ инженер, написавший пайплайн. Квартальная rotation предотвращает мониторинг одним и тем же человеком одного пайплайна больше 3 месяцев.

Компенсирующие контроли — когда SoD непрактичен

Реальный мир: не каждая команда может позволить 4 distinct individuals per material CDE. Маленький стартап, weekend incident, niche expertise. SoD не всегда достижим; компенсирующие контроли предоставляют альтернативное обеспечение.

Pattern 1 — CSO / executive override

Один individual может совмещать roles (например, CTO пишет + деплоит), но КАЖДОЕ действие требует CSO retrospective sign-off в течение 24h. Sign-off включает review полного change diff.

Плюсы: сохраняет agility; обеспечивает executive-level check. Минусы: CSO становится bottleneck; rubber-stamp risk.

Pattern 2 — Log-everything pattern

Один актор может execute, но каждое действие logged immutably с полным контекстом. Independent reviewer (Big 4, internal audit) reviews logs post-facto на cadence.

Реализация: каждый SQL query (Snowflake query_history), каждый API call (CloudTrail), каждый git commit (signed) — archived 7y; reviewed monthly независимой role.

Плюсы: работает для очень маленьких команд; trail-driven assurance. Минусы: detective only; bad action уже произошло; reliance на log integrity.

Pattern 3 — 4-eyes principle минимум

Если 4 distinct actors непрактичны, обеспечить минимум 2 distinct individuals per material operation (4-eyes principle). Один initiates, один approves. Executor + monitor могут совпасть с initiator, если логирование сильное.

Плюсы: минимальное SoD coverage; достижимо в 3-person team. Минусы: monitoring blind spot.

Pattern 4 — External attestation

Material CDE controls attested внешним auditor периодически (например, квартальный Big 4 sample testing). External обеспечивает independence, отсутствующую внутри.

Плюсы: highest credibility evidence. Минусы: дорого; lags.

Perspective PCAOB: compensating controls приемлемы, если «(a) achieve relevant control objective; (b) operating effectively; (c) tested». Нет магии; те же evidence + testing requirements, как direct SoD.

PCAOB ожидания по SoD

PCAOB AS 2201 ¶.36 — ITGC integral part of top-down approach. SoD — core ITGC. PCAOB testing focus:

• Provisioning — кто approves новые access combinations? Conflicting roles flagged?
• Periodic review — конфликты SoD идентифицированы + resolved cadence?
• Privileged combinations — ACCOUNTADMIN + production write — split? Logged?
• Audit log — действия traceable к individual actor; service accounts к triggering human commit?

PCAOB 2024 inspection — SoD violations часто missed на data systems specifically (focus исторически на ERP / finance systems). Data systems с production write + monitoring один человек — частый undetected gap.

PCI-DSS v4.0.1 Req. 6.4 — для card-data systems: developers не могут access production environments; отдельные functional areas. SwiftPay (PCI-scope) — SoD strict; engineers не могут SELECT card data даже read-only.

Anti-patterns

SoD «реализован» через role names, не actual separation

Паттерн: team имеет «Reviewer» role label, но тот же engineer signs off как Author и Reviewer.

Почему плохо: label cosmetic; actual механизм неизменен.

Fix: enforce через tooling — GitHub branch protection no-self-review; CODEOWNERS не может approve own PR.

Service accounts как «4-й актор»

Паттерн: «pipeline runs as airflow_runner — это наш executor».

Почему плохо: поведение service account определяется кодом, committed людьми. Не может служить independent SoD role.

Fix: service account = executor от имени approved кода; logged trail per code change (PR → deploy → run); humans hold accountability за то, что делает service account.

Emergency change без retroactive review

Паттерн: hot-fix в 2 AM, нет review, merged напрямую к prod, «мы review завтра». Завтра никогда не приходит.

Почему плохо: SoD bypass без compensating retro-control = unchecked production change.

Fix: emergency change protocol предписывает retroactive PR + retroactive CR в течение 24h; еженедельный CSO sign-off на emergency change digest; trend tracking для anti-pattern (frequent emergencies = normal process broken).

CODEOWNERS file outdated

Паттерн: CODEOWNERS lists former employee; ничего не ломается при PR; тот же engineer может self-approve фактически.

Почему плохо: SoD existed in past, не sustained.

Fix: CODEOWNERS file как code — reviewed квартально; tied к Okta termination flow (employee disabled → CODEOWNERS auto-update; gap → alert).

Резюме

• SoD 4-actor model: initiator (пишет PR) ≠ approver (reviews + authorises) ≠ executor (деплоит) ≠ monitor (наблюдает). Минимум 3-4 distinct individuals per material operation.
• Data world challenges: DevOps culture «you build it, you run it», небольшие команды, emergency changes, service accounts. Каждое addressable через cross-team enrolment, retroactive review, log-everything pattern.
• Реализация: GitHub branch protection + CODEOWNERS (PR review enforcement); Snowflake RBAC (executor isolation); Airflow service accounts (signed code только); on-call rotation cross-team (monitor separation).
• Compensating controls когда SoD непрактичен: CSO override, log-everything pattern, 4-eyes minimum, external attestation. PCAOB acceptable если achieve control objective + operating effectively + tested.
• PCAOB 2024 inspection — SoD violations on data systems frequently undetected gap. PCI-DSS v4.0.1 Req. 6.4 — SDLC SoD обязателен для card-data.
• Design SwiftRide SwiftPay: 5 distinct individuals across 4 teams; CODEOWNERS enforces; Airflow runner executes signed code; DQ team rotation monitors; Steward attests квартально.

В M5.8 разберём lineage-as-control — как OpenLineage column-level facets гейтят schema changes на CDE; impact analysis автоматизирован.