1. Принципы
- Минимизация — обрабатываем только те данные, которые необходимы для оказания услуги.
- Минимальные привилегии — доступ выдаётся под конкретную задачу и отзывается при её завершении.
- Защита по умолчанию — безопасные настройки применяются без действий со стороны Заказчика.
- Прослеживаемость — значимые действия фиксируются в журналах.
- Проверяемость — меры регулярно тестируются, а не только декларируются.
2. Управление доступом
2.1. Доступ сотрудников к продуктивным средам предоставляется по заявке, согласуется руководителем и пересматривается не реже одного раза в квартал.
2.2. Обязательна многофакторная аутентификация для административных учётных записей и доступа к инфраструктуре.
2.3. Доступ к данным Заказчика предоставляется только в объёме, необходимом для поддержки, и фиксируется в журнале с указанием причины.
2.4. При увольнении или изменении роли доступы отзываются в течение 1 рабочего дня.
3. Защита данных
| Область | Мера |
|---|---|
| Передача | TLS 1.2+ для всего внешнего трафика, HSTS, запрет устаревших шифров |
| Хранение | Шифрование дисков и резервных копий (AES-256), раздельное хранение ключей |
| Секреты | Хранение в защищённом менеджере секретов, ротация не реже одного раза в год |
| Изоляция | Логическое разделение данных Заказчиков, разделение сред dev / stage / prod |
| Резервные копии | Ежедневное копирование, хранение 30 дней, регулярная проверка восстановления |
| Журналы | Централизованный сбор, защита от изменения, хранение 12 месяцев |
4. Безопасная разработка
4.1. Изменения проходят код-ревью и автоматизированные проверки перед выпуском в продуктивную среду.
4.2. Зависимости и образы контейнеров сканируются на известные уязвимости; критические уязвимости устраняются в течение 7 календарных дней, высокие — 30 дней.
4.3. Продуктивные данные не используются в тестовых средах без обезличивания.
5. Управление инцидентами
5.1. Инциденты классифицируются по степени влияния; для каждого назначается ответственный за реагирование.
5.2. Заказчик уведомляется о подтверждённом инциденте, затронувшем его данные, без неоправданной задержки и не позднее 24 часов с момента установления факта.
5.3. Уведомление содержит характер инцидента, категории затронутых данных, принятые меры и рекомендации Заказчику.
5.4. По завершении расследования формируется отчёт с анализом причин и планом устранения.
6. Непрерывность и доступность
6.1. Целевые показатели доступности определяются SLA.
6.2. Целевое время восстановления (RTO) и целевая точка восстановления (RPO) согласовываются в Заказе исходя из требований Заказчика.
6.3. План восстановления тестируется не реже одного раза в год.
7. Работа с подрядчиками
7.1. Перед подключением субпроцессора проводится оценка его практик безопасности.
7.2. С подрядчиками заключаются соглашения о конфиденциальности и обработке данных с обязательствами не ниже установленных настоящей Политикой.
7.3. Перечень субпроцессоров предоставляется Заказчику по запросу; об их изменении Заказчик уведомляется в порядке, предусмотренном DPA.
8. Сообщение об уязвимостях
8.1. Мы приветствуем ответственное раскрытие уязвимостей. Сообщения направляйте на alibek.abdekov2110@gmail.com с темой «Security».
8.2. Просим не публиковать сведения об уязвимости до устранения и не проводить тестирование, приводящее к отказу в обслуживании или доступу к чужим данным.
8.3. Мы подтверждаем получение сообщения в течение 3 рабочих дней и информируем о ходе устранения.