Глава 16. Классификация и управление данными

«Данные — это то, что мы защищаем. Всё остальное — средства доставки.»

В предыдущих частях книги мы выстраивали защиту вокруг идентичности, устройств, сетей и приложений. Но все эти механизмы существуют ради одной цели — защиты данных. CISA выделяет Data как пятый столп Zero Trust Maturity Model, а отчёт CISA по внедрению ZTA (январь 2025) прямо указывает: столп данных — наиболее проблемный для большинства организаций.

16.1 Зачем: данные как центр Zero Trust

Традиционная модель защищала периметр: если трафик внутри сети — ему доверяли. Data-centric security переворачивает модель: защита привязана к самим данным, а не к месту их хранения.

NIST SP 800-207, тенет 4:

«All data sources and computing services are considered resources.»

NSA в апреле 2024 года выпустила руководство «Advancing Zero Trust Maturity Throughout the Data Pillar», определяющее 7 ключевых возможностей:

#	Возможность	Описание
1	Data Catalog Risk Alignment	Инвентаризация данных с привязкой к рискам
2	Enterprise Data Governance	Политики маркировки, доступа и жизненного цикла
3	Data Labeling & Tagging	Метки классификации, интегрированные в контроль доступа
4	Data Monitoring & Sensing	Обнаружение аномального доступа и перемещения
5	Data Encryption & Rights Management	Шифрование + DRM для данных за пределами организации
6	Data Loss Prevention (DLP)	Предотвращение несанкционированного копирования и отправки
7	Data Access Control	Гранулярный контроль доступа на основе атрибутов

Источник: NSA, «Advancing Zero Trust Maturity Throughout the Data Pillar», April 2024

CISA ZTMM v2 определяет четыре уровня зрелости для столпа данных:

Traditional — ручная категоризация, неполная инвентаризация, шифрование фрагментарно
Initial — автоматизация атрибутов и политик, начальная интеграция между столпами
Advanced — кросс-функциональная координация, централизованная видимость
Optimal — непрерывная автоматизация, адаптивные политики на основе аналитики

В этой главе мы покроем классификацию (возможности 1-3), DLP (6) и шифрование (5). Контроль доступа к данным (7) и мониторинг (4) — тема главы 17.

16.2 Классификация данных

Стандарты и уровни

Классификация — фундамент data-centric security. Без неё невозможно определить, какие данные защищать и как.

FIPS 199 (Standards for Security Categorization) определяет три уровня воздействия для федеральных систем:

Уровень	Описание
Low	Ограниченное негативное воздействие на операции, активы или людей
Moderate	Серьёзное негативное воздействие
High	Катастрофическое негативное воздействие

Оценка ведётся по трём измерениям CIA: конфиденциальность, целостность, доступность.

ISO 27001 (Annex A 5.12) не предписывает конкретные уровни — организация определяет их самостоятельно. Рекомендуемая практика — от 3 до 4 уровней:

Уровень	Пример данных	Контроли
Public	Маркетинговые материалы, документация	Нет ограничений
Internal	Внутренние процедуры, организационная структура	Аутентификация сотрудников
Confidential	Персональные данные, финансовая отчётность	Шифрование, контроль доступа, аудит
Restricted	Ключи шифрования, данные о слияниях	MFA, мониторинг, DLP, DRM

Больше 4 уровней редко оправданно: сложность администрирования перевешивает пользу (ISO 27001 Annex A 5.12 рекомендует простоту).

Ручная vs автоматическая классификация

Подход	Плюсы	Минусы
Ручная	Точность для контекстных данных	Не масштабируется, зависит от людей
Автоматическая	Масштаб, единообразие	Ложные срабатывания, стоимость
Гибридная	Баланс точности и масштаба	Сложность оркестрации

NSA рекомендует: по мере роста зрелости маркировка должна становиться автоматизированной для обеспечения масштаба и точности.

Microsoft Purview: sensitivity labels

Microsoft Purview — наиболее зрелая платформа для автоматической классификации в корпоративной среде.

Компоненты:

Sensitivity labels — метки, привязанные к документам и email. С декабря 2025 года Microsoft модернизировал иерархию: вместо parent-child модели введены label groups для гибкой реорганизации
Trainable classifiers — ML-модели для обнаружения специфического контента (контракты, резюме, исходный код)
Sensitive Information Types (SIT) — 300+ шаблонов (SSN, кредитные карты, IBAN) с regex + ML
Exact Data Match (EDM) — сопоставление с конкретными записями из базы данных

Auto-labeling работает в двух режимах:

Client-side — в приложениях Office (Word, Excel, PowerPoint) при создании/редактировании
Service-side — для данных в SharePoint, OneDrive, Exchange (ретроспективное сканирование)

AWS Macie

Amazon Macie — сервис обнаружения чувствительных данных в S3, использующий ML и pattern matching.

150+ managed data identifiers — предварительно обученные детекторы (PII, PHI, финансовые данные, учётные данные)
Custom data identifiers — regex + proximity keywords для специфических форматов
Automated discovery — непрерывное профилирование S3-бакетов с оценкой sensitivity score
Интеграция — EventBridge → Lambda → автоматическое применение меток/ограничений

GCP Sensitive Data Protection

Ранее Cloud DLP, с 2023 года — Sensitive Data Protection (SDP).

200+ infoTypes — детекторы по категориям (PII, финансовые, медицинские, учётные данные)
Discovery scan — профилирование BigQuery, Cloud SQL, Cloud Storage
Inspection — on-demand сканирование с результатами по каждому infoType
De-identification — маскирование, токенизация, шифрование с сохранением формата (FPE)

Ценообразование:

Функция	Стоимость
Discovery (профилирование)	$0.03/ГБ (лимит 3 ТБ/таблица)
Inspection (on-demand)	$1.00/ГБ (первый ГБ бесплатно)
Subscription (discovery)	$2,500/мес (фиксированная)

Источник: cloud.google.com/sensitive-data-protection/pricing

16.3 Предотвращение утечек (DLP)

DLP — это не один продукт, а набор политик и инструментов, предотвращающих несанкционированное перемещение данных за пределы разрешённого контура.

Microsoft Purview DLP

Единая платформа DLP для всего стека Microsoft 365:

Канал	Покрытие
Exchange Online	Входящие/исходящие email (новые, не архив)
SharePoint & OneDrive	Существующие + новые файлы
Teams	Сообщения каналов и чатов (E5 лицензия)
Endpoint DLP	Windows 10/11, macOS Catalina+
Cloud Apps	Интеграция с Defender for Cloud Apps

Пример политики DLP (PowerShell):

powershell

# Создание DLP-политики для блокировки отправки PII за пределы организации
New-DlpCompliancePolicy -Name "Block External PII" `
  -ExchangeLocation All `
  -SharePointLocation All `
  -OneDriveLocation All `
  -Mode Enable

New-DlpComplianceRule -Name "Block SSN External" `
  -Policy "Block External PII" `
  -ContentContainsSensitiveInformation @{
    Name = "U.S. Social Security Number (SSN)";
    minCount = 1
  } `
  -BlockAccess $true `
  -BlockAccessScope NotInOrganization

AWS Macie + EventBridge

В AWS DLP реализуется через цепочку сервисов:

Macie Discovery → Finding → EventBridge Rule → Lambda → S3 Block Public Access
                                              → SNS → Security Team
                                              → Step Functions → Quarantine

GCP SDP + Cloud Functions

bash

# Создание инспекционного задания для BigQuery
# storage-config.json содержит конфигурацию таблицы
cat > /tmp/storage-config.json << 'EOF'
{
  "big_query_options": {
    "table_reference": {
      "project_id": "my-project",
      "dataset_id": "customer_data",
      "table_id": "orders"
    }
  }
}
EOF

gcloud dlp jobs create inspect \
  --project=my-project \
  --display-name="Inspect orders" \
  --info-types="CREDIT_CARD_NUMBER,PHONE_NUMBER" \
  --min-likelihood=LIKELY \
  --storage-config-file=/tmp/storage-config.json

16.4 Шифрование: три состояния данных

Zero Trust требует защиты данных во всех трёх состояниях: в покое (at rest), в передаче (in transit) и в обработке (in use).

Data at Rest: управление ключами (KMS)

Все крупные облачные провайдеры предоставляют managed KMS с FIPS-валидированными модулями:

Характеристика	AWS KMS	GCP Cloud KMS	Azure Key Vault
Защита ключей	HSM всегда (FIPS 140-3 L3)	Software (FIPS 140-2 L1) или HSM (FIPS 140-2 L3)	Standard (FIPS 140-2 L1) или Premium HSM (FIPS 140-3 L3)
Стоимость ключа/мес	$1.00	$0.06 (Software), $1.00 (HSM)	$0.03/10K операций + $1.00/ключ (HSM)
Автоматическая ротация	Да (ежегодно)	Да (настраивается)	Да (настраивается)
BYOK	Да	Да (EXTERNAL, $3.00/мес)	Да
Выделенный HSM	CloudHSM ($1.45-1.60/ч)	Включено в HSM-ключ	Managed HSM (отдельный сервис)

Важно: AWS KMS хранит все ключи в HSM (FIPS 140-3 Level 3) — «software-only» варианта нет. GCP и Azure предлагают выбор между программной и HSM-защитой.
Источники: aws.amazon.com/kms/pricing, cloud.google.com/kms/docs/protection-levels, learn.microsoft.com/azure/key-vault/keys/about-keys

NIST SP 800-57 Part 1 Rev 5 определяет рекомендуемые криптопериоды для разных типов ключей (Table 1). Ключевой принцип: симметричные ключи шифрования данных имеют ограниченный период использования для создания шифротекста (originator-usage period) и более длительный период для расшифровки (recipient-usage period).

PCI DSS 4.0 (Requirement 3.6.4) не предписывает конкретный срок, но требует определить криптопериод на основе отраслевых практик и автоматизировать ротацию.

Пример: AWS KMS с автоматической ротацией (Terraform)

hcl

resource "aws_kms_key" "data_encryption" {
  description             = "Data-at-rest encryption key"
  enable_key_rotation     = true  # Ежегодная автоматическая ротация
  deletion_window_in_days = 30

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid    = "AllowKeyAdministration"
        Effect = "Allow"
        Principal = {
          AWS = "arn:aws:iam::123456789012:role/KeyAdmin"
        }
        Action   = ["kms:Create*", "kms:Describe*", "kms:Enable*",
                    "kms:List*", "kms:Put*", "kms:Update*",
                    "kms:Revoke*", "kms:Disable*", "kms:Get*",
                    "kms:Delete*", "kms:ScheduleKeyDeletion"]
        Resource = "*"
      },
      {
        Sid    = "AllowKeyUsage"
        Effect = "Allow"
        Principal = {
          AWS = "arn:aws:iam::123456789012:role/AppRole"
        }
        Action   = ["kms:Encrypt", "kms:Decrypt",
                    "kms:GenerateDataKey*"]
        Resource = "*"
      }
    ]
  })

  tags = {
    Classification = "confidential"
    Environment    = "production"
  }
}

resource "aws_kms_alias" "data_encryption" {
  name          = "alias/data-encryption"
  target_key_id = aws_kms_key.data_encryption.key_id
}

Data in Transit: TLS 1.3

TLS 1.3 (RFC 8446, август 2018) — обязательный стандарт для данных в передаче:

1-RTT handshake (вместо 2-RTT в TLS 1.2) — сокращение задержки
0-RTT resumption — для повторных соединений (с оговоркой по replay-атакам)
Удалены устаревшие алгоритмы: RC4, DES, 3DES, MD5, SHA-1, статический RSA
Forward secrecy обязателен — только (EC)DHE key exchange

В Kubernetes шифрование in transit обеспечивается через mTLS (см. главу 12). В облаках — TLS по умолчанию для API, а для внутреннего трафика:

Облако	Шифрование между зонами	Шифрование внутри зоны
AWS	По умолчанию (Nitro)	По умолчанию (Nitro)
GCP	ALTS (Application Layer Transport Security)	ALTS
Azure	MACsec (между ЦОД)	Программное шифрование

Data in Use: конфиденциальные вычисления

Конфиденциальные вычисления (Confidential Computing) защищают данные во время обработки в процессоре, используя аппаратные Trusted Execution Environments (TEE).

Confidential Computing Consortium (Linux Foundation) объединяет индустрию вокруг открытых стандартов. Ключевые проекты:

Проект	Назначение
Gramine	Лёгкая гостевая ОС для запуска приложений в изолированной среде (SGX)
Open Enclave SDK	Фреймворк для разработки TEE-приложений с единой абстракцией
Keystone	Открытый TEE на архитектуре RISC-V
Veraison	Компоненты для построения сервиса верификации аттестации

Источник: confidentialcomputing.io/projects/current-projects

Аппаратные технологии:

Технология	Вендор	Механизм
Intel TDX	Intel	Trust Domains — изоляция VM с шифрованием памяти
AMD SEV-SNP	AMD	Secure Encrypted Virtualization с Secure Nested Paging
ARM CCA	ARM	Confidential Compute Architecture для серверных ARM

Облачные предложения:

Облако	Сервис	Технология
AWS	Nitro Enclaves	Изолированная VM без persistent storage и сети
GCP	Confidential VMs	AMD SEV-SNP, шифрование памяти прозрачно для приложения
Azure	Confidential Computing	Intel SGX (DC-series), AMD SEV-SNP (DCa-series), Intel TDX

Конфиденциальные вычисления — наиболее быстрорастущая область. На момент написания большинство реализаций требуют специализированных экземпляров VM и имеют ограничения по производительности (5-15% overhead для SEV-SNP).

16.5 Лаборатория: GCP Sensitive Data Protection

Цель

Настроить автоматическое обнаружение чувствительных данных в BigQuery с помощью GCP Sensitive Data Protection.

Предварительные требования

Проект GCP с BigQuery
Включённый API: dlp.googleapis.com
Роли: roles/dlp.admin, roles/bigquery.dataViewer

Шаг 1: Подготовка тестовых данных

sql

-- Создание тестового датасета и таблицы
CREATE SCHEMA IF NOT EXISTS dlp_lab;

CREATE OR REPLACE TABLE dlp_lab.customers AS
SELECT
  'John Smith' AS full_name,
  '[email protected]' AS email,
  '555-01-2345' AS ssn,
  '4532015112830366' AS credit_card,
  '+1-555-0123' AS phone
UNION ALL
SELECT 'Jane Doe', '[email protected]',
  '555-67-8901', '5425233430109903', '+1-555-0456'
UNION ALL
SELECT 'Bob Wilson', '[email protected]',
  '555-23-4567', '4916338506082832', '+1-555-0789';

Шаг 2: Создание inspection template

bash

# Создание шаблона инспекции с набором infoTypes
gcloud dlp inspect-templates create \
  --project=my-project \
  --location=global \
  --display-name="PII Detection Template" \
  --description="Detects PII in BigQuery tables" \
  --info-types="CREDIT_CARD_NUMBER,EMAIL_ADDRESS,PHONE_NUMBER,US_SOCIAL_SECURITY_NUMBER,PERSON_NAME" \
  --min-likelihood=POSSIBLE \
  --include-quote

Шаг 3: Запуск инспекционного задания

bash

# Конфигурация хранилища для инспекции
cat > /tmp/bq-storage-config.json << 'EOF'
{
  "big_query_options": {
    "table_reference": {
      "project_id": "my-project",
      "dataset_id": "dlp_lab",
      "table_id": "customers"
    }
  }
}
EOF

# Запуск инспекции таблицы BigQuery
gcloud dlp jobs create inspect \
  --project=my-project \
  --display-name="Inspect customers table" \
  --inspect-template="projects/my-project/locations/global/inspectTemplates/PII_Detection_Template" \
  --storage-config-file=/tmp/bq-storage-config.json

Шаг 4: Просмотр результатов

bash

# Получение статуса и результатов задания
gcloud dlp jobs list --project=my-project --location=global

# Детализация конкретного задания
gcloud dlp jobs describe JOB_ID \
  --project=my-project \
  --location=global

Ожидаемый результат — обнаружение 5 типов infoType в таблице:

infoType	Количество	Likelihood
CREDIT_CARD_NUMBER	3	VERY_LIKELY
US_SOCIAL_SECURITY_NUMBER	3	LIKELY
EMAIL_ADDRESS	3	VERY_LIKELY
PHONE_NUMBER	3	LIKELY
PERSON_NAME	3	POSSIBLE

Шаг 5: De-identification (опционально)

bash

# Деидентификация — замена кредитных карт на маскированные значения
gcloud dlp text deidentify \
  --project=my-project \
  --content="Customer card: 4532015112830366" \
  --info-types="CREDIT_CARD_NUMBER" \
  --deidentify-config='{
    "info_type_transformations": {
      "transformations": [{
        "info_types": [{"name": "CREDIT_CARD_NUMBER"}],
        "primitive_transformation": {
          "character_mask_config": {
            "masking_character": "*",
            "number_to_mask": 12
          }
        }
      }]
    }
  }'

Результат: Customer card: ************0366

Очистка

bash

bq rm -r -f dlp_lab
gcloud dlp inspect-templates delete \
  projects/my-project/locations/global/inspectTemplates/PII_Detection_Template

16.6 Чек-лист

[ ] Данные инвентаризированы и каталогизированы (NSA: Data Catalog Risk Alignment)
[ ] Определена схема классификации (3-4 уровня, привязанных к контролям)
[ ] Автоматическая классификация развёрнута (Macie / SDP / Purview)
[ ] DLP-политики покрывают основные каналы (email, хранилище, endpoint)
[ ] Data at rest зашифрованы с FIPS-validated managed KMS
[ ] Ключи ротируются автоматически (PCI DSS 4.0 Req 3.6.4)
[ ] TLS 1.3 для всех внешних соединений, mTLS для внутренних
[ ] Конфиденциальные вычисления оценены для критических рабочих нагрузок
[ ] Sensitivity labels интегрированы с контролем доступа (см. главу 17)

16.7 Итоги

Data-centric security — это не один инструмент, а система из классификации, DLP и шифрования, работающих вместе. Классификация определяет что защищать, DLP контролирует куда данные могут перемещаться, шифрование защищает данные когда они вне контроля.

Ключевые выводы:

Начинайте с инвентаризации — нельзя защитить то, о чём не знаешь (NSA: Data Catalog Risk Alignment)
Автоматизируйте классификацию — ручная маркировка не масштабируется
Шифруйте всё, управляйте ключами — облачный KMS покрывает 90% сценариев, CloudHSM/Key Vault Premium — для регуляторных требований
DLP — это процесс, а не продукт — начните с мониторинга, переходите к блокировке

В следующей главе мы рассмотрим контроль доступа к данным: ABAC, мониторинг активности баз данных, lineage и управление данными для AI/ML.

Глава 16. Классификация и управление данными ​

16.1 Зачем: данные как центр Zero Trust ​

16.2 Классификация данных ​

Стандарты и уровни ​

Ручная vs автоматическая классификация ​

Microsoft Purview: sensitivity labels ​

AWS Macie ​

GCP Sensitive Data Protection ​

16.3 Предотвращение утечек (DLP) ​

Microsoft Purview DLP ​

AWS Macie + EventBridge ​

GCP SDP + Cloud Functions ​

16.4 Шифрование: три состояния данных ​

Data at Rest: управление ключами (KMS) ​

Data in Transit: TLS 1.3 ​

Data in Use: конфиденциальные вычисления ​

16.5 Лаборатория: GCP Sensitive Data Protection ​

Цель ​

Предварительные требования ​

Шаг 1: Подготовка тестовых данных ​

Шаг 2: Создание inspection template ​

Шаг 3: Запуск инспекционного задания ​

Шаг 4: Просмотр результатов ​

Шаг 5: De-identification (опционально) ​

Очистка ​

16.6 Чек-лист ​

16.7 Итоги ​

Глава 16. Классификация и управление данными

16.1 Зачем: данные как центр Zero Trust

16.2 Классификация данных

Стандарты и уровни

Ручная vs автоматическая классификация

Microsoft Purview: sensitivity labels

AWS Macie

GCP Sensitive Data Protection

16.3 Предотвращение утечек (DLP)

Microsoft Purview DLP

AWS Macie + EventBridge

GCP SDP + Cloud Functions

16.4 Шифрование: три состояния данных

Data at Rest: управление ключами (KMS)

Data in Transit: TLS 1.3

Data in Use: конфиденциальные вычисления

16.5 Лаборатория: GCP Sensitive Data Protection

Цель

Предварительные требования

Шаг 1: Подготовка тестовых данных

Шаг 2: Создание inspection template

Шаг 3: Запуск инспекционного задания

Шаг 4: Просмотр результатов

Шаг 5: De-identification (опционально)

Очистка

16.6 Чек-лист

16.7 Итоги