Настраиваем защиту персональных данных в Yandex Cloud

Ответ короткий. Провайдер закрывает свою часть инфраструктуры. Клиент закрывает свою конфигурацию, данные, доступы, ключи, резервные копии и эксплуатационные процедуры. Если это не зафиксировано в архитектуре, облако быстро превращается в дорогой VPS с красивой консолью.

Yandex Cloud имеет подтвержденное соответствие требованиям 152-ФЗ и аттестаты для уровней защищенности УЗ-1 и УЗ-2. Это полезная база. Но она не отменяет проектирование системы защиты персональных данных. Аттестованная площадка не исправит роль editor, выданную стажеру на весь каталог. Не зашифрует таблицу, если приложение пишет туда открытые поля. Не восстановит регламент, если резервные копии лежат в той же зоне отказа и доступны тем же учеткам.

Модель разделения ответственности: где заканчивается провайдер

В облаке нельзя строить безопасность по старой схеме «железо в стойке, значит всё наше». В Yandex Cloud работает модель разделения ответственности. Она нормальна для IaaS/PaaS. Но ее часто читают как рекламную формулировку. Это ошибка.

Провайдер отвечает за физическую безопасность дата-центров, базовую облачную инфраструктуру, устойчивость сервисов, часть сетевого и платформенного слоя. Клиент отвечает за то, что разворачивает поверх: виртуальные машины, базы, сервисные аккаунты, сетевые правила, политики доступа, ключи, бэкапы, обработку инцидентов на уровне своих приложений.

Схематично это выглядит так:

Главный практический вывод: сертификаты облака входят в пакет доказательств, но не заменяют вашу модель угроз, матрицу доступа и эксплуатационные регламенты.

Аттестованное облако снижает часть инфраструктурного риска. Оно не чинит плохую архитектуру доступа.

Для защиты персональных данных сначала нужно определить контур обработки. Не «у нас есть облако», а конкретно:

1. Какие персональные данные обрабатываются: ФИО, телефон, email, паспортные данные, платежные идентификаторы, биометрия, медицинские сведения.

2. Где они лежат: Managed PostgreSQL, Object Storage, диски VM, очереди, логи, аналитические витрины.

3. Кто к ним обращается: приложение, администратор, аналитик, подрядчик, сервисный аккаунт CI/CD.

4. Как данные проходят по системе: прием, обработка, хранение, выгрузка, удаление.

5. Где появляются копии: бэкапы, дампы, логи, тестовые среды, BI-инструменты.

Последний пункт обычно ломает красивую схему. В продакшене всё закрыто. Потом разработчик снимает дамп базы, кладет его в тестовый каталог, а доступ к нему получает вся команда. С точки зрения инцидента это не «тестовый контур». Это утечка.

152-ФЗ и уровни защищенности: что дает облако

Yandex Cloud заявляет соответствие требованиям 152-ФЗ «О персональных данных» и имеет подтвержденные аттестаты соответствия уровням защищенности УЗ-1 и УЗ-2. Также в контексте облачной безопасности часто фигурируют PCI DSS, ISO 27001, ISO 27017, ISO 27018. Эти стандарты полезны при аудите поставщика и выборе платформы.

Но для системы персональных данных этого мало. 152-ФЗ требует не только подходящей инфраструктуры. Нужны организационные и технические меры. Нужно понимать актуальные угрозы. Нужно назначить ответственных. Нужно ограничить доступ. Нужно вести учет. Нужно обеспечить восстановление. Нужно контролировать действия администраторов.

Уровень защищенности зависит не от названия облака, а от характеристик информационной системы персональных данных: типа данных, категорий субъектов, количества записей, актуальных угроз, наличия специальных категорий. Универсального уровня «для всех SaaS» нет.

Практический порядок такой:

1. Описать ИСПДн. Не общими словами. Перечень компонентов: облачная сеть, подсети, ВМ, базы, хранилища, балансировщики, очереди, функции, CI/CD, внешние интеграции.

2. Классифицировать данные. Разделить персональные данные, технические идентификаторы и обезличенные данные. Не смешивать в одной таблице всё подряд без причины.

3. Определить уровень защищенности. УЗ-1 или УЗ-2 могут быть достижимы на базе возможностей Yandex Cloud, но конкретная конфигурация зависит от системы.

4. Сопоставить меры с облачными сервисами. IAM, KMS, Security Groups, журналы событий, резервное копирование, мониторинг.

5. Зафиксировать остаточные риски. Например, доступ подрядчика к продакшен-базе. Или хранение персональных данных в логах приложения.

Здесь уместна жесткая граница. Если компания работает в регулируемой отрасли — медицина, финтех, государственный контур, массовая обработка чувствительных данных — нужен индивидуальный аудит. Нельзя брать чужой чеклист из блога и считать его эквивалентом проектной документации. Особенно если рядом с персональными данными есть финансовые риски, как в P2P-кредитовании и краудлендинге, где приходится учитывать не только ИБ, но и модель доходности, налоги и риск-профиль заемщиков — для смежного понимания полезно посмотреть материалы про P2P-кредитование и краудлендинг.

IAM: сначала роли, потом инфраструктура

Большинство утечек в облаке выглядит скучно. Не уязвимость нулевого дня. Не сложная атака на гипервизор. Обычная избыточная роль. Открытый доступ. Сервисный аккаунт без ротации ключей. Администратор, который остался в проекте после увольнения.

В Yandex Cloud IAM нужно настраивать до деплоя данных, а не после. Иначе роли разрастаются как технический долг: сначала всем нужен editor, потом «разберемся», потом продакшен уже обрабатывает ПДн.

Минимальный принцип: субъект получает только те права, которые нужны для конкретной операции. Не для удобства. Не «на всякий случай». Не «пока тестируем».

Разделите людей, сервисы и роботов

В нормальной архитектуре есть три типа субъектов:

• Пользователи. Администраторы, разработчики, аналитики, сотрудники поддержки.
• Сервисные аккаунты. Приложения, функции, виртуальные машины, CI/CD-пайплайны.
• Внешние участники. Подрядчики, аудиторы, интеграции, временные команды.

Для каждого типа нужна отдельная политика. Человек не должен использовать сервисный аккаунт как личный ключ. Приложение не должно работать под учеткой администратора. CI/CD не должен иметь право читать персональные данные, если его задача — деплой контейнера.

Рабочая модель доступа:

2FA должна быть включена для всех учетных записей, которые имеют доступ к Yandex Cloud. Не только для администраторов. Учетка аналитика с доступом к выгрузкам иногда опаснее администратора без доступа к данным.

Роли назначаются на минимальном уровне

В Yandex Cloud права можно выдавать на разных уровнях иерархии. Ошибка — назначать широкую роль выше, чем нужно. Если сервису нужен доступ к одному каталогу, не надо давать права на всё облако. Если приложение пишет в один бакет, не надо давать управление всеми объектными хранилищами.

Порядок настройки:

1. Создать отдельные каталоги под prod, stage и dev.

2. Запретить использование персональных данных в dev по умолчанию.

3. Завести сервисные аккаунты под конкретные приложения и задачи.

4. Назначить роли на минимально возможном уровне.

5. Включить 2FA для пользователей.

6. Запланировать регулярную ревизию IAM: не реже, чем релизный цикл или кадровые изменения.

Не стоит пытаться сделать IAM «один раз». Это живой объект. Команда меняется. Сервисы добавляются. Права расползаются. Ревизия доступа должна быть таким же процессом, как обновление зависимостей.

Сетевая изоляция: Security Groups без широких дыр

Security Groups в Yandex Cloud работают как виртуальный межсетевой экран для управления входящим и исходящим трафиком на уровне сетевых интерфейсов. Это не декоративный слой. Это базовая линия обороны между интернетом, приложением, базой и внутренними сервисами.

Типовая плохая конфигурация:

• SSH открыт из 0.0.0.0/0;
• база данных принимает подключения из всей подсети;
• outbound разрешен полностью;
• stage и prod живут в одной сети;
• админские панели доступны без VPN или bastion-хоста;
• правила не документированы.

Для системы с персональными данными такая конфигурация не проходит даже прагматический здравый смысл.

Базовый сетевой паттерн

Для большинства SaaS-систем достаточно трех сегментов:

1. Публичный слой. Балансировщик, API gateway, фронтовые компоненты. Только необходимые входящие порты.

2. Прикладной слой. Виртуальные машины, контейнеры, функции, backend-сервисы. Нет прямого входа из интернета.

3. Данные. Базы, очереди, внутренние хранилища. Доступ только от прикладного слоя и администрирования через контролируемый канал.

Правила Security Groups должны описывать связи сервисов, а не абстрактные разрешения. Не «разрешить PostgreSQL для подсети». А «разрешить PostgreSQL от security group backend к security group database». Это снижает риск при росте инфраструктуры.

Пример логики правил без псевдографики:

Outbound часто оставляют полностью открытым. Это удобно для деплоя. И плохо для расследования. Если злоумышленник получает доступ к приложению, полный outbound упрощает вывод данных. Ограничить исходящий трафик сложнее, но для контуров с ПДн это нормальная инженерная цена.

Сеть не должна доверять приложению только потому, что оно «наше». Компрометация backend — обычный сценарий, а не экзотика.

Шифрование: KMS, HSM и контроль ключей

Шифрование нужно делить на два слоя: данные при хранении и данные при передаче. TLS закрывает канал. Он не защищает базу, если учетная запись приложения скомпрометирована. Шифрование диска не спасает от администратора с правами чтения таблиц. KMS не помогает, если ключ доступен тому же сервисному аккаунту, который утек вместе с приложением.

Yandex Key Management Service позволяет управлять ключами шифрования. В контексте защиты персональных данных важна возможность использовать аппаратные модули безопасности HSM, сертифицированные ФСТЭК. Типовой криптографический стандарт для KMS — AES-256.

Практическая задача не в том, чтобы «включить шифрование». Практическая задача — построить управление ключами.

Что шифровать

В системе с ПДн обычно шифруются:

• диски виртуальных машин, если на них есть данные или временные файлы;
• объектные хранилища с документами, выгрузками, вложениями;
• резервные копии;
• поля в базе, если требуется защита отдельных атрибутов;
• секреты приложения, если они хранятся вне специализированного секрет-хранилища;
• логи, если туда попадают идентификаторы пользователей.

Отдельно надо вырезать привычку писать персональные данные в логи. Потом эти логи уходят в мониторинг, SIEM, техническую поддержку, тестовые выгрузки. Формально база закрыта. Фактически ФИО и телефон гуляют по диагностике.

Как управлять ключами

Ключи должны иметь владельца, назначение и срок жизни. Если ключ создан «для проекта», через год никто не понимает, что им зашифровано и можно ли его ротировать.

Минимальная спецификация ключа:

Ключи prod и stage не должны совпадать. Ключи для бэкапов и основной базы тоже лучше разделять. Иначе компрометация одного доступа открывает слишком большой радиус поражения.

Сервисный аккаунт приложения должен иметь право использовать конкретный ключ, но не управлять всеми ключами. Управление KMS — отдельная административная функция. Если приложение может и читать данные, и менять ключевую политику, граница защиты условна.

Резервное копирование: восстановление важнее наличия бэкапа

Резервное копирование входит в зону ответственности клиента. Облако дает инструменты. Политика остается вашей.

Плохая политика: «бэкапы включены». Хорошая политика отвечает на четыре вопроса:

1. Какие данные копируются.

2. Как часто.

3. Где хранятся.

4. Как быстро и кем восстанавливаются.

Для персональных данных добавляется пятый вопрос: кто имеет доступ к резервным копиям. Бэкап базы часто содержит больше данных, чем рабочие таблицы. В продакшене доступ ограничен приложением. В бэкапе лежит монолитный дамп, который можно скачать одним действием. Это отдельный актив риска.

Минимальный набор мер:

• шифровать резервные копии через управляемые ключи;
• разделить права на создание, чтение и удаление копий;
• хранить копии в изолированном контуре доступа;
• тестировать восстановление, а не только создание;
• контролировать срок хранения;
• удалять копии по регламенту, если данные больше не нужны.

Тест восстановления должен быть регулярным. Иначе бэкап — это вера, а не механизм. Проверять нужно не только технический restore, но и права: кто может инициировать восстановление, кто получает доступ к восстановленной базе, как исключить попадание реальных ПДн в тестовую среду.

Мониторинг и реакция: видеть не только падения сервиса

В ИБ мониторинг отличается от эксплуатационного мониторинга. CPU, latency и ошибки 500 нужны. Но для защиты персональных данных этого мало. Нужно видеть действия с доступом и данными.

События, которые должны попадать в контроль:

• выдача и отзыв IAM-ролей;
• создание новых сервисных аккаунтов;
• изменение ключей KMS и политик доступа к ним;
• изменение Security Groups;
• открытие публичного доступа к объектам;
• массовое чтение или выгрузка данных;
• создание дампов продуктивной базы;
• входы без 2FA или подозрительные попытки входа;
• обращения к админским интерфейсам вне рабочего паттерна.

Реакция на инцидент не должна начинаться с вопроса «кто у нас отвечает за облако». Для системы с ПДн нужен заранее описанный порядок:

1. Зафиксировать событие и время.

2. Ограничить доступ скомпрометированного субъекта.

3. Сохранить журналы для расследования.

4. Проверить радиус поражения: какие данные могли быть прочитаны, изменены или удалены.

5. Ротировать ключи, токены, пароли, если есть риск компрометации.

6. Восстановить систему из доверенного состояния.

7. Обновить IAM, Security Groups и процедуры, если инцидент связан с конфигурацией.

Точные показатели времени реакции со стороны провайдера зависят от выбранного уровня технической поддержки. Поэтому нельзя строить план инцидента на абстрактном «облако поможет». Поможет — в рамках SLA и своей зоны ответственности. Ваши роли, ключи и данные останутся вашими.

Типовые ошибки при защите ПДн в Yandex Cloud

Ошибки повторяются. Технологии меняются медленнее, чем привычка выдавать лишние права.

1. Считать соответствие облака соответствием системы

Yandex Cloud может соответствовать 152-ФЗ и иметь аттестаты УЗ-1, УЗ-2. Но ваша система становится соответствующей только после настройки, документации и эксплуатации мер защиты. Иначе это перенос риска в облако без управления риском.

2. Давать широкие IAM-роли на верхнем уровне

Роль на весь каталог или облако быстрее. Потом она становится нормой. Потом никто не знает, почему у подрядчика остался доступ к production.

3. Использовать реальные ПДн в dev и stage

Это одна из самых дорогих привычек. Dev-контур обычно хуже защищен, чаще доступен, активнее меняется. Если нужны тестовые данные — используйте синтетические или обезличенные.

4. Оставлять сетевые правила «на время настройки»

Временные правила живут дольше архитектуры. 0.0.0.0/0 для SSH или базы — не временное решение, а отложенный инцидент.

5. Хранить персональные данные в логах

Логи размножаются. Их читают больше людей. Их выгружают в сторонние системы. Маскируйте поля, режьте payload, отделяйте технические идентификаторы от реальных ПДн.

6. Не разделять ключи шифрования

Один ключ на все — удобная точка отказа. Компрометация или ошибка в политике доступа затрагивает сразу несколько классов данных.

7. Не тестировать восстановление

Бэкап без восстановления — файл неизвестного качества. Особенно если он зашифрован ключом, который удалили, или лежит в контуре, к которому потеряли доступ.

Итоговая рабочая последовательность

Настройка защиты персональных данных в Yandex Cloud должна идти не от интерфейса консоли, а от контура данных. Сначала описание ИСПДн. Потом роли. Потом сеть. Потом ключи. Потом резервное копирование и мониторинг. В обратном порядке получается косметика.

Рабочий порядок внедрения:

1. Описать все места хранения и обработки ПДн в облаке.

2. Разделить prod, stage и dev по каталогам, сетям и ключам.

3. Включить 2FA для всех учетных записей с доступом к облаку.

4. Настроить IAM по принципу минимальных прав.

5. Создать сервисные аккаунты под конкретные приложения и пайплайны.

6. Закрыть сетевой доступ через Security Groups: только нужные направления и порты.

7. Включить шифрование с использованием KMS, при необходимости — HSM.

8. Разделить ключи по назначению и контурам.

9. Настроить резервное копирование с шифрованием и тестом восстановления.

10. Включить мониторинг событий IAM, KMS, сети, хранилищ и операций с данными.

11. Описать порядок реакции на инциденты.

12. Проводить ревизию прав и правил после релизов, кадровых изменений и новых интеграций.

Главное ограничение остается прежним. Yandex Cloud дает инфраструктурную базу, соответствие ряду требований и набор сервисов безопасности. Защита персональных данных возникает только после того, как клиент правильно настроил IAM, сеть, шифрование, резервное копирование и контроль событий. Всё остальное — маркетинговый шум вокруг незащищенной конфигурации.