Загружаем 1ОПД
Подготавливаем страницу…
Подготавливаем страницу…
152-ФЗ требует не только собирать согласия, но и доказать их хранение. 1ОПД построен так, что в нормальной работе потерь данных нет вообще, а в катастрофическом сценарии — максимум 6 часов. Никакого «бэкап раз в сутки и надеемся».
RTO — за сколько восстановим работу. RPO — сколько данных потеряем в худшем случае.
| Сценарий | RTO | RPO | Чем покрыто |
|---|---|---|---|
| Один сервер БД крашится | 30-60 секунд | 0 (потерь нет) | Yandex Cloud HA: синхронная replica в другой зоне + автоматический failover |
| Случайное удаление или порча данных | ~10 минут | 1-2 минуты | Point-in-Time Recovery: восстановление на любую секунду в течение 30 дней |
| Наш сервер приложения падает | 1-2 минуты | 0 (потерь нет) | DR spool VM в другом регионе принимает запросы + auto DNS-failover |
| Весь Yandex Cloud недоступен | несколько часов | ≤ 6 часов | Зашифрованные бэкапы каждые 6 часов у независимого облачного провайдера |
Каждый слой защищает от своего класса сбоев. Они работают одновременно, не зависят друг от друга и физически разнесены по разным провайдерам.
PostgreSQL работает в режиме High Availability: master в Москве, синхронная replica в Питере. Каждая транзакция фиксируется одновременно на двух серверах в разных дата-центрах.
При падении основного сервера Yandex автоматически переключает на replica за 30-60 секунд. Приложение продолжает работать с тем же подключением, клиенты не замечают сбоя.
Каждая операция INSERT/UPDATE/DELETE фиксируется в журнале транзакций (WAL) и попадает в облачный архив через секунды.
Восстановим базу на любую секунду в течение 30 дней. Случайно удалённое юр.лицо? Откатим. Bug в коде испортил данные? Поднимем состояние «до». Спор по дате согласия? Подтвердим состояние БД в нужный момент.
Отдельная виртуальная машина в другом регионе работает как stand-by. Auto-DNS-failover переключает трафик при недоступности основного сервера.
Когда основной сервер недоступен > 60 секунд, DNS автоматически указывает на резервную VM. Она принимает все POST-запросы клиентов в локальную очередь. После восстановления основного сервера replay-daemon перенакатывает накопленные согласия обратно в БД. Клиенты ничего не замечают.
Каждые 6 часов делаем полный pg_dump базы, шифруем AES-256 и заливаем в S3-хранилище у независимого облачного провайдера — другая инфраструктура, отдельная учётная запись.
Защита от катастрофы вида «весь Yandex упал» или «нам залочили аккаунт». Бэкапы зашифрованы клиентским ключом — даже утечка хранилища не даст доступа к данным. Хранение: 30 дней ежедневных копий + 365 дней ежемесячных.
Доступ к БД ограничен Row-Level Security — даже с украденным application-токеном злоумышленник видит только свои данные. WAL непрерывно архивируется в облако, off-site копия зашифрована отдельным ключом. Компрометация одного слоя не даёт целостных данных.
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>), плюс Row-Level Security блокирует cross-tenant запросы на уровне БД. Даже бэкенд-bug не сможет вернуть чужие данные.
Каждое действие сотрудника 1ОПД (вход в impersonate клиента, изменение договора, удаление юр.лица), создание/отзыв согласия, удаление ПДн субъекта — пишется в audit_log с timestamp, user_id, IP и метаданными. Это покрывает требования 152-ФЗ к доказательству обработки.
Это худший сценарий: одновременное падение основной БД + replica + DR spool VM + всего Yandex Cloud в течение 6 часов. Вероятность — близкая к нулю. В нормальной работе и в подавляющем большинстве сценариев потерь данных нет вообще (RPO 0).
ООО «Дисконто» (оператор платформы 1ОПД) внесено в реестр операторов персональных данных Роскомнадзора. Архитектура защиты соответствует:
Согласия, политики, уведомление РКН, обращения субъектов — закроем всё. Вы занимаетесь бизнесом, мы — защитой данных ваших клиентов.
Получить консультацию →