Загружаем 1ОПД
Подготавливаем страницу…
Подготавливаем страницу…
152-ФЗ требует не только собирать согласия, но и доказать их хранение. 1ОПД построен так, что в нормальной работе потерь данных нет вообще, а в катастрофическом сценарии — максимум 6 часов. Никакого «бэкап раз в сутки и надеемся».
RTO — за сколько восстановим работу. RPO — сколько данных потеряем в худшем случае.
| Сценарий | RTO | RPO | Чем покрыто |
|---|---|---|---|
| Один сервер БД крашится | 30-60 секунд | 0 (потерь нет) | Yandex Cloud HA: синхронная replica в другой зоне + автоматический failover |
| Случайное удаление или порча данных | ~10 минут | 1-2 минуты | Point-in-Time Recovery: восстановление на любую секунду в течение 30 дней |
| Деплой / рестарт сервера приложения | 5-30 секунд | 0 (потерь нет) | Локальный spool-gateway буферизует POST-запросы в Redis (TTL 24ч) → replay после restart |
| Вся виртуальная машина приложения падает | 1-2 минуты | 0 (потерь нет) | DR spool VM в другом регионе принимает запросы + auto DNS-failover, replay при recovery |
| Весь Yandex Cloud недоступен | несколько часов | ≤ 6 часов | Зашифрованные бэкапы каждые 6 часов у независимого облачного провайдера |
Каждый слой защищает от своего класса сбоев. Они работают одновременно, не зависят друг от друга и физически разнесены по разным провайдерам.
PostgreSQL работает в режиме High Availability: master в Москве, синхронная replica в Питере. Каждая транзакция фиксируется одновременно на двух серверах в разных дата-центрах.
При падении основного сервера Yandex автоматически переключает на replica за 30-60 секунд. Приложение продолжает работать с тем же подключением, клиенты не замечают сбоя.
Каждая операция INSERT/UPDATE/DELETE фиксируется в журнале транзакций (WAL) и попадает в облачный архив через секунды.
Восстановим базу на любую секунду в течение 30 дней. Случайно удалённое юр.лицо? Откатим. Bug в коде испортил данные? Поднимем состояние «до». Спор по дате согласия? Подтвердим состояние БД в нужный момент.
Любой POST-запрос на создание согласия проходит через буфер. Если БД или приложение временно недоступны — запрос не теряется, а сохраняется и доставляется при восстановлении.
Уровень А (95% сбоев — деплой, OOM, restart): локальный spool-gateway на той же VM хранит запрос в Redis с TTL 24 часа и автоматически retry'ит когда backend ответит. Клиент видит HTTP 202 «accepted», даже если бэкенд в этот момент перезапускается. Уровень Б (катастрофа — вся VM down): отдельная stand-by VM в другом регионе (Санкт-Петербург, независимый провайдер) с auto-DNS-failover. При недоступности основного сервера ≥60 секунд трафик переключается туда, запросы сохраняются в flat-file. После восстановления replay-daemon в течение 30 секунд переносит накопленные согласия обратно в БД.
Каждые 6 часов делаем полный pg_dump базы, шифруем AES-256 и заливаем в S3-хранилище у независимого облачного провайдера — другая инфраструктура, отдельная учётная запись.
Защита от катастрофы вида «весь Yandex упал» или «нам залочили аккаунт». Бэкапы зашифрованы клиентским ключом — даже утечка хранилища не даст доступа к данным. Хранение: 30 дней ежедневных копий + 365 дней ежемесячных. Pg_dump делается с replica, не нагружает основную БД.
Защита многоуровневая. Каждый клиент 1ОПД лежит в отдельной PostgreSQL-схеме (tenant_<slug>) — даже с украденным application-токеном злоумышленник видит только данные одного тенанта. PostgreSQL-роли разделены: приложение (app) не может делать DDL, миграции делает отдельная роль (migrator), write-path использует api_writer с минимальными правами. WAL непрерывно архивируется в облако, off-site копия зашифрована отдельным клиентским ключом, секреты в Yandex Lockbox с регулярной ротацией. Компрометация одного слоя не даёт целостных данных.
Off-site копия у независимого облачного провайдера обновляется каждые 6 часов — другая инфра, другая учётная запись. DR spool VM в Санкт-Петербурге принимает запросы клиентов, пока Yandex восстанавливается. Это сценарий «1 в N лет», но мы к нему готовы.
Восстановим за ~10 минут через Point-in-Time Recovery. PITR держит окно 30 дней — можно откатить точно к моменту «за минуту до» удаления. Потеря данных за это окно — 1-2 минуты максимум.
Да. Каждое воскресенье автоматически скачивается последний шифрованный бэкап, расшифровывается и проверяется через pg_restore --list. В чат админов идёт Telegram-алёрт: «✓ drill OK, N объектов» или «✗ FAILED». «Бэкап есть» ≠ «бэкап работает» — мы не верим на слово.
Нет, разделены на уровне БД. Каждый клиент 1ОПД получает отдельную PostgreSQL-схему (tenant_<slug>), запросы выполняются с явным search_path только для нужного тенанта. Дополнительно есть автоматический cross-tenant leak test в pre-promote-чеклисте: перед каждым релизом проверяем, что запрос от tenant A не возвращает строки tenant B. Бэкенд-bug не сможет вернуть чужие данные.
Нет. Любой POST на создание согласия проходит через spool-gateway: если в момент запроса бэкенд перезапускается (5-30 сек), запрос буферизуется в Redis на той же VM с TTL 24 часа, клиенту возвращается HTTP 202 «accepted». Replay-daemon retry'ит автоматически после рестарта. За последние месяцы при множественных деплоях — 0 потерянных запросов согласий. Каждый промоут на прод проходит через 23-этапный smoke-test на dev-окружении с копией prod-данных, плюс автоматический backup PostgreSQL делается прямо перед релизом.
Каждые 60 секунд автоматический canary проверяет: spool-gateway alive, Redis OK, backend reachable, queue depth ≤ порога, replay не отстаёт, диск свободен, TLS-сертификат не подходит к истечению. При любом отклонении — Telegram-алёрт сразу в чат админов. Канарь работает и на основной VM, и на DR-VM в другом регионе. Тишина = всё OK.
Каждое действие сотрудника 1ОПД (вход в impersonate клиента, изменение договора, удаление юр.лица), создание/отзыв согласия, удаление ПДн субъекта — пишется в audit_log с timestamp, user_id, IP и метаданными. Это покрывает требования 152-ФЗ к доказательству обработки.
Это худший сценарий: одновременное падение основной БД + replica + DR spool VM + всего Yandex Cloud в течение 6 часов (между двумя off-provider бэкапами). Вероятность — близкая к нулю. В нормальной работе и в подавляющем большинстве сценариев потерь данных нет вообще (RPO 0).
ООО «Дисконто» (оператор платформы 1ОПД) внесено в реестр операторов персональных данных Роскомнадзора. Архитектура защиты соответствует:
Согласия, политики, уведомление РКН, обращения субъектов — закроем всё. Вы занимаетесь бизнесом, мы — защитой данных ваших клиентов.
Получить консультацию →