Введение

SwiftRide T+11M, Internal Audit задаёт простой вопрос: «Покажите список всех production-систем, которые хранят, обрабатывают или передают данные CDE-SWR-003 (driver earnings). Включая всё — прикладные сервисы, базы данных, кеши, message-брокеры, BI-инструменты, ETL-воркеры, third-party SaaS». Ответ должен составлять базис уверенности Big 4. Engineering Director собирает группу: Data Platform Lead Priya, SwiftPay Tech Lead Marko, Platform Engineering Lead Yuki, Security Lead Daria. Через 2 часа обсуждения: «приблизительно 47 систем, но не уверены насчёт edge-кейсов — staging-зеркало? CDC-реплики? аккаунт Snowflake reader для BI? OpenLineage Marquez? Confluent-коннектор? записи ML feature store? retention VPC flow log, который хранит метаданные IP?».

«Приблизительно» — не защищаемо при аудите. Findings Internal Audit SwiftRide T+11M: инвентаризация активов для CDE-несущих систем неполна. Периметр ICFR по AS 2201 ¶.18 зависит от полного знания, где течёт CDE. DORA Arts. 5-16 явно требует инвентарь ICT-активов + классификацию по критичности. Партнёр Big 4: «без полной инвентаризации активов ICFR-мнение нельзя выдать как unqualified opinion».

M8.3 — как этот разрыв закрывается через CMDB + тегирование + обнаружение дрейфа + scorecards Backstage. И как DORA Register of Information (Arts. 28-44) построен поверх этого базиса.

Требования CMDB для CDE-несущих систем

Configuration Management Database (CMDB) — авторитетная инвентаризация IT-активов и их атрибутов. Для CDE-несущих систем CMDB должна содержать:

Атрибуты по системе:

• system_id — стабильный идентификатор (UUID или slug).
• system_name — человекочитаемое имя.
• system_type — application / database / cache / message-broker / BI / ETL / SaaS-vendor / infrastructure.
• business_owner — Business Owner по M7.5 (1L accountable).
• data_steward — операционный стюард.
• cde_handling.stores — список CDE-ID, где система постоянно хранит данные.
• cde_handling.processes — список, где система трансформирует / вычисляет.
• cde_handling.transmits — список, где система передаёт данные downstream (топик Kafka, API-эндпоинт).
• criticality — производное от обрабатываемых tier CDE (максимальный tier).
• regulator_context — флаги периметра GDPR / SOX / DORA / EU AI Act / PSD2 / IFRS / AMLR.
• bcp_ref — ссылка на BIA (M6.2); RTO / RPO унаследованы.
• lifecycle_state — proposed / active / deprecating / retired.
• dependencies.upstream — список system_id upstream.
• dependencies.downstream — список downstream.
• vendor_relationships — если часть системы полагается на внешнего вендора (Confluent / Snowflake / Databricks / Okta).
• cost_center — для финансового трекинга.
• evidence_endpoint — где собираются доказательства контролей для этой системы (S3-путь).
• last_verified — timestamp последней верификации инвентаря.

Выбор CMDB в SwiftRide: Backstage с кастомным плагином swr-cde-systems + ServiceNow CMDB для интеграции с legacy-системами. Цель pre-IPO T+15M — полное покрытие Backstage с ServiceNow как вторичным архивом.

Распространение тегов через стек

Теги — runtime-механизм распространения метаданных владения / классификации через всю инфраструктуру. Без тегов инвентарь CMDB дрейфует.

Стандартная схема тегов SwiftRide (T+12M):

Паттерн Terraform-модуля: cde_tagged_resource

Стандартный паттерн SwiftRide для CDE-несущих ресурсов — wrapper-модуль Terraform, который обеспечивает тегирование + эмитит события метаданных.

# infrastructure/modules/cde_tagged_resource/main.tf
module "cde_tagged_resource" {
  source = "./modules/cde_tagged_resource"
  
  resource_kind = "snowflake_table"
  resource_fqn  = "PROD_PAYMENTS.SWIFTPAY.FCT_DRIVER_EARNINGS"
  
  cde = {
    id              = "CDE-SWR-003"
    tier            = 1
    business_owner  = "[email protected]"
    data_steward    = "[email protected]"
    regulator_context = ["sox", "dora", "psd2", "gdpr"]
    bcp_ref         = "BIA-SWR-003"
    retention       = "P7Y"
    sensitivity     = "financial"
  }
  
  # Auto-emits k8s label propagation для downstream workloads.
  emit_lineage = true
}

Модуль делает:

1. Валидирует, что cde.id существует в каталоге OpenMetadata (вызов API).
2. Валидирует, что cde.tier соответствует tier в реестре.
3. Применяет теги ресурсов AWS (S3-бакеты, RDS, ECS).
4. Применяет теги объектов Snowflake (для объектов warehouse).
5. Эмитит Terraform-вывод в metadata-emitter Lambda (для baseline дрейфа).
6. Записывает событие OpenLineage “cde-resource-tagged” с полным контекстом.
7. Вызывает каталог API Backstage для регистрации компонента.

Антипаттерн: теги только постфактум. Инженер создаёт ресурс через aws_s3_bucket напрямую; CDE-теги добавлены через aws_resource_tagging_api после создания; первый прогон terraform plan показывает “no changes”; теги дрейфуют со временем. Исправление: принудительно требовать, чтобы CDE-затрагивающие ресурсы шли только через модуль cde_tagged_resource; CI-проверка блокирует PR, если прямой тип ресурса AWS используется для CDE-путей.

DORA Register of Information — маппинг CMDB → регуляторный артефакт

DORA Art. 28 требует Register of Information (RoI), подаваемый ежегодно (первая подача 30 апреля 2025) с ICT-договорённостями с third-party, поддерживающими критические или важные функции. RoI содержит:

• Идентификация поставщика ICT third-party.
• Характеристики контракта (дата начала, периметр, критичность, зависимости).
• Поддерживаемые категории функций.
• Трансграничные потоки данных (расположение дата-центров, обработка).
• Цепочка субподрядчиков.
• Индикаторы concentration risk.

Маппинг RoI в SwiftRide:

Генерация RoI = автоматический скрипт по CMDB + контрактам; ручное ревью перед подачей; совместное подписание CDO + Risk Function + General Counsel; подача через портал ESA ежегодно (следующая: 30 апреля 2027).

Назначение CTPP 18 ноября 2025. EBA/EIOPA/ESMA назначили 19 CTPPs, включая крупных гиперскейлеров. Snowflake — не в первоначальном списке CTPP (но AWS — да; это базовая инфраструктура для Snowflake). Назначение влияет на обращение с риском вендора: CTPP требует юр. лица EU, ежегодных надзорных сборов, принятия инспекций ESA. Для SwiftRide AWS = CTPP = дополнительные накладные расходы управления поставщиками по DORA Art. 30 (due diligence субподрядчика).

Обнаружение дрейфа через terraform plan + scorecards Backstage

Дрейф = состояние в production расходится с предполагаемым (Terraform-defined). Источники дрейфа:

• Ручные изменения в AWS Console (инженер обходит Terraform).
• Действия auto-scaling (легитимные, но не отслеживаются).
• Обновления на стороне вендора (добавление фич Snowflake).
• Неполная ротация тегов (новый ресурс создан без CDE-тегов).

Ежедневная задача обнаружения дрейфа:

# infrastructure/drift_detection/daily_check.py
def detect_cde_drift():
    """Daily job — runs 03:00 UTC."""
    results = []
    
    for tfstate in get_all_cde_tfstates():
        plan = run_terraform_plan(tfstate)  # exit code 2 = changes detected
        
        if plan.has_changes:
            for change in plan.changes:
                if is_cde_resource(change.resource):
                    results.append({
                        "tfstate": tfstate,
                        "resource": change.resource_address,
                        "drift_type": change.action,  # update / replace / delete
                        "drift_attributes": change.before_after_diff,
                        "cde_id": extract_cde_id_tag(change.resource),
                        "severity": classify_drift_severity(change),
                    })
    
    # SEV-1 drift: tag deletion / encryption disabling / public access enabling
    # SEV-2 drift: ownership tag change / retention change
    # SEV-3 drift: cosmetic (description / non-functional)
    
    emit_evidence(results, control_id="CHANGE-MGMT-DRIFT-DAILY")
    for r in results:
        if r.severity in ("SEV-1", "SEV-2"):
            create_jira_ticket(r)
            page_oncall(r) if r.severity == "SEV-1" else None

Обнаруженный дрейф = либо одобренное изменение (отсутствует апрув CAB → governance gap), либо неавторизованное изменение. Оба = control deficiency под AS 1305 ¶.01.

Scorecards Backstage: SwiftRide T+12M развернул плагин swr-cde-scorecard, который вычисляет скор по каждой системе:

Сводный скор по CDE. Порог: системы tier 1 ≥ 90%; tier 2 ≥ 80%; tier 3 ≥ 70%. Дашборд виден офису CDO + Audit Committee; тренды трекаются как KPI M8.8.

Состояние инвентаря активов SwiftRide T+12M

Внедрение Backstage. 60% CDE-несущих систем зарегистрированы в Backstage (T+12M); цель 100% T+15M. Блокеры миграции: 8 SaaS-вендорных систем требуют кастомной работы по интеграции API; 12 legacy-сервисов без Helm chart.

ServiceNow CMDB. 80% финансово-релевантных систем; цель 100% T+15M (для готовности раскрытия ITAM для NYSE листинга).

Scorecard полноты тегов (CDE-SWR-003 tier 1):

• Ресурсы AWS: 32 из 38 полностью тегированы (84%) → цель 100% Q1 2027.
• Объекты Snowflake: 17 из 17 полностью тегированы (100%) → поддерживается.
• Воркпейлоады K8s: 22 из 28 полностью тегированы (78%) → цель 100% Q4 2026 (обновления Helm chart).
• Vendor-системы: 4 из 4 метаданных задокументированы в ServiceNow (100%).

Обнаружение дрейфа. Живо с Q3 2026; Q3 обнаружено 14 SEV-1/2 событий дрейфа; 12 разрешены в SLA; 2 эскалированы из-за попытки обхода (уведомление Internal Audit).

Антипаттерны

Инвентарь через интервью

Паттерн: инвентаризация активов захватывается через квартальные интервью команд; лаг 60+ дней; новые сервисы пропущены; deprecated-сервисы всё ещё в списке.

Почему плохо: устаревшее; не audit-grade; периметр AS 2201 ¶.18 неверифицируем.

Исправление: автоматическое обнаружение (OpenLineage + сканы тегов + Snowflake query history + AWS resource API); интервью дополняют, не заменяют.

Тегировать-но-не-обеспечивать

Паттерн: теги существуют на большинстве ресурсов; CI не обеспечивает; некоторые ресурсы без тегов; дрейф накапливается.

Почему плохо: проверка тегов на уровне ресурса нужна на создании; backfill дороже принуждения.

Исправление: pre-commit Terraform-проверка + CI-шаг cde-resource-tag-validate; провал тега → провал сборки; ежеквартальный sweep дрейфа с авто-ремедиацией для tier 1.

CMDB как point-in-time снапшот

Паттерн: CMDB обновляется ежеквартально через bulk-импорт; промежуточное состояние расходится; “last_verified” > 90 дней по многим записям.

Почему плохо: устаревшие данные — аудит полагается; design effectiveness AS 2201 ¶.30 под вопросом.

Исправление: потоковые обновления CMDB (обновление дескриптора Backstage в режиме реального времени + API-хуки ServiceNow); цель свежести 95% записей < 30 дней.

Постфактумная генерация DORA RoI

Паттерн: подача RoI пишется вручную каждый год из CMDB + spreadsheets; качество данных переменное; срезы в подаче под дедлайн.

Почему плохо: расхождение между RoI и фактическими операциями = supervisory finding; явное требование DORA Art. 28.

Исправление: генерация RoI = пайплайн (CMDB → автоматический скрипт → ревью → подача); ручные правки флагируются и отслеживаются; перед подачей совместное подписание CDO + Risk Function + General Counsel.

Резюме

• CMDB для CDE-несущих систем требует богатых метаданных по системе: business owner, data steward, cde_handling (stores/processes/transmits), criticality, regulator context, ссылка BCP, lifecycle, зависимости, vendor relationships, evidence endpoint.
• Тегирование распространяется через 6 слоёв — каталог (OpenMetadata) → IaC (Terraform) → теги ресурсов AWS → теги объектов Snowflake → теги K8s + Datadog → эмиссия доказательств.
• Стандартная схема тегов: cde:id, cde:tier, cde:business_owner, cde:data_steward, cde:regulator_context, cde:bcp_ref, cde:retention, cde:sensitivity, cde:evidence_endpoint.
• Паттерн Terraform-модуля cde_tagged_resource обеспечивает тегирование + валидирует членство в каталоге + эмитит события метаданных.
• DORA Register of Information (Arts. 28-44) маппится из CMDB; первая подача 30 апреля 2025; назначение CTPP 18 ноября 2025 (19 провайдеров) влияет на обращение с AWS как critical third-party.
• Scorecards Backstage — скор по системе (полнота тегов + свежесть владения + статус дрейфа + BCP связан + доказательства операционны + lineage активен + дескриптор актуален); tier 1 ≥ 90%, tier 2 ≥ 80%, tier 3 ≥ 70%.
• Ежедневная задача обнаружения дрейфа terraform plan; SEV-1/2 дрейф = Jira-тикет + страница on-call; еженедельное обновление Backstage.
• SwiftRide T+12M: 60% внедрение Backstage; 80% ServiceNow CMDB; обнаружение дрейфа живо в Q3; 14 событий дрейфа Q3 / 12 разрешены в SLA / 2 эскалированы.

В M8.4 разберём реагирование на инциденты — severity matrix + уведомление нескольких регуляторов (с RegulatoryNotificationTimeline).