Основы безопасности данных
Введение
Безопасность данных — это не отдельная дисциплина, а фундаментальный слой Data Governance. Без надёжной защиты все остальные элементы governance — каталоги, политики качества, compliance-процессы — теряют смысл. Утечка конфиденциальных данных может уничтожить репутацию организации и привести к многомиллионным штрафам.
В этом уроке мы рассмотрим принципы Data Security (безопасность данных), подходы к шифрованию, моделирование угроз и стратегию defence in depth.
Принципы Data Security
Data Security (безопасность данных) охватывает три ключевых области, известных как CIA-триада:
| Принцип | Описание | Пример нарушения |
|---|---|---|
| Confidentiality (конфиденциальность) | Данные доступны только авторизованным пользователям | Утечка клиентских данных через незащищённый API |
| Integrity (целостность) | Данные не изменены несанкционированно | SQL-инъекция, подменяющая записи в БД |
| Availability (доступность) | Данные доступны, когда нужны | DDoS-атака на аналитическое хранилище |
Каждый элемент governance-программы должен учитывать все три аспекта. Шифрование обеспечивает confidentiality, контрольные суммы — integrity, резервное копирование — availability.
Шифрование данных
Data Encryption (шифрование данных) — преобразование данных в нечитаемый формат с использованием криптографических алгоритмов. Шифрование применяется на двух уровнях:
At Rest (на диске)
Данные шифруются при хранении — на дисках серверов, в бэкапах, в облачных хранилищах.
-- PostgreSQL: field-level encryption с pgcrypto
-- Шифрование PII-столбца email
INSERT INTO customers (email_encrypted)
VALUES (pgp_sym_encrypt('[email protected]', 'encryption_key'));
-- Дешифрование при чтении
SELECT pgp_sym_decrypt(email_encrypted, 'encryption_key')
FROM customers;Основные подходы:
- Transparent Data Encryption (TDE) — шифрование на уровне СУБД, прозрачно для приложений
- Field-level encryption — шифрование отдельных столбцов (PII, финансовые данные)
- Disk encryption — шифрование всего диска (BitLocker, LUKS)
In Transit (при передаче)
Данные шифруются при передаче между системами — API-вызовы, репликация, ETL.
# TLS 1.3 для PostgreSQL
ssl = on
ssl_cert_file = '/etc/ssl/server.crt'
ssl_key_file = '/etc/ssl/server.key'
ssl_min_protocol_version = 'TLSv1.3'Key Management (управление ключами) — критически важный процесс: ключи хранятся в Hardware Security Module (HSM) или Key Management Service (KMS), ротируются регулярно, доступ к ним ограничен.
Моделирование угроз
Моделирование угроз (threat modeling) — систематический процесс выявления потенциальных атак и уязвимостей. Для данных используется подход STRIDE:
| Угроза | Описание | Пример в контексте данных |
|---|---|---|
| Spoofing | Подмена идентичности | Использование чужих учётных данных для доступа к БД |
| Tampering | Несанкционированное изменение | Подмена записей аудит-лога |
| Repudiation | Отрицание действия | Пользователь отрицает удаление записей (нет audit trail) |
| Information Disclosure | Утечка данных | SQL-инъекция, экспортирующая PII |
| Denial of Service | Отказ в обслуживании | Перегрузка аналитического хранилища |
| Elevation of Privilege | Повышение привилегий | Аналитик получает admin-доступ через эксплойт |
Сценарий: DataTech Solutions (ДатаТех Солюшенз)
В DataTech обнаружили критическую уязвимость: все 7 сотрудников команды данных используют общие учётные данные для доступа к PostgreSQL. Один аккаунт
datauserс паролем, который не менялся 2 года. Последствия:
- Spoofing: невозможно определить, кто выполнил запрос — все используют одни credentials
- Repudiation: сотрудник может отрицать удаление записей — нет идентификации
- Information Disclosure: увольняющийся сотрудник сохраняет доступ — пароль общий
- Отсутствие audit trail: все действия записываются как
datauser
Defence in Depth
Стратегия Defence in Depth (эшелонированная защита) предполагает несколько слоёв безопасности, где каждый слой компенсирует потенциальные слабости других:
| Слой | Механизм | Что защищает |
|---|---|---|
| Сетевой | Firewall, VPN, network segmentation | Периметр доступа |
| Идентификация | SSO, MFA, Identity Management | Аутентификация |
| Авторизация | RBAC, ABAC, Row-Level Security | Права доступа |
| Данные | Encryption, masking, tokenization | Содержимое данных |
| Мониторинг | Audit logging, alerting, SIEM | Обнаружение инцидентов |
Zero Trust (нулевое доверие) — архитектурный подход, при котором ни один пользователь или система не получает доверие по умолчанию. Каждый запрос аутентифицируется и авторизуется, даже внутри корпоративной сети. Принцип: never trust, always verify.
Итоги
- CIA-триада (Confidentiality, Integrity, Availability) — фундамент безопасности данных
- Шифрование at rest и in transit — базовый механизм защиты конфиденциальности
- Key Management — управление ключами критично: хранить в HSM/KMS, ротировать регулярно
- Моделирование угроз (STRIDE) — систематический подход к выявлению уязвимостей
- Defence in depth — несколько слоёв защиты, где каждый компенсирует слабости других
- Zero Trust — never trust, always verify, даже внутри периметра
В следующем уроке мы рассмотрим RBAC (Role-Based Access Control) — основную модель контроля доступа, и реализуем её в PostgreSQL на примере FinSecure Bank.