Загружаем 1ОПД
Подготавливаем страницу…
Подготавливаем страницу…
152-ФЗ требует от оператора не только получить согласие субъекта, но и подтвердить его хранение. В нормальной работе 1ОПД не теряет данные вообще, в катастрофическом сценарии окно потери не превышает 6 часов.
RTO: за сколько мы восстановим работу. RPO: сколько данных потеряем в худшем случае.
| Сценарий | RTO | RPO | Чем покрыто |
|---|---|---|---|
| Отказ одного сервера БД | 30-60 секунд | 0 (потерь нет) | Автоматическое переключение на горячую копию в другом ЦОД |
| Случайное удаление или порча данных | ~10 минут | 1-2 минуты | Восстановление на любую секунду в пределах 30 дней |
| Деплой / рестарт сервера приложения | 5-30 секунд | 0 с 05.08.2026 | Приём согласий буферизуется и доставляется после восстановления; недоставленное не удаляется, а уходит в очередь на разбор |
| Отказ виртуальной машины приложения | 1-2 минуты | 0 с 05.08.2026 | Резервный контур принимает запросы, накопленное доставляется после восстановления; недоставленное сохраняется до ручного разбора |
| Отказ основного облачного провайдера целиком | несколько часов | ≤ 6 часов | Зашифрованная копия у стороннего провайдера, обновляется несколько раз в сутки |
Каждый слой защищает от своего класса сбоев. Слои работают одновременно, не зависят друг от друга и разнесены по разным площадкам и провайдерам. Устройство защиты мы не публикуем: ниже обязательства перед клиентом, а не схема системы.
База работает в режиме высокой доступности: каждая транзакция фиксируется одновременно в двух разных дата-центрах.
При отказе основного сервера нагрузка переключается на горячую копию автоматически, за десятки секунд. Приложение продолжает работать, клиент сбоя не замечает.
Каждое изменение данных попадает в журнал транзакций, и журнал непрерывно уходит в защищённый архив.
Мы восстановим базу на любую секунду в пределах 30 дней: вернём случайно удалённое юридическое лицо, поднимем состояние до ошибки в коде, подтвердим состояние базы на дату спорного согласия.
Запрос на создание согласия проходит через буфер. Если база или приложение временно недоступны, буфер удерживает запрос и доставляет его после восстановления.
Это закрывает и частые короткие перерывы (деплой, рестарт), и отказ машины приложения целиком: на этот случай есть резервный контур в другом дата-центре. Запросы, которые не удалось доставить с первого раза, не пропадают молча: они уходят в отдельную очередь разбора и попадают в дежурный алёрт.
Несколько раз в сутки мы снимаем полную копию базы, шифруем её и размещаем у независимого облачного провайдера: другая инфраструктура, отдельная учётная запись.
Это защита от катастрофы вида «основной провайдер недоступен» или «нам заблокировали аккаунт». Ключ шифрования хранится отдельно от самой копии, поэтому доступ к хранилищу доступа к данным не даёт. Храним 30 дней ежедневных копий и 365 дней ежемесячных. Копию снимаем так, чтобы не нагружать основную базу.
Защита многоуровневая. Данные каждого клиента 1ОПД изолированы на уровне базы, поэтому доступ к одному контуру не открывает данные остальных. Права разделены по принципу минимальных привилегий: учётная запись приложения не может менять структуру базы, а запись данных идёт под отдельной ограниченной учётной записью. Значения персональных данных зашифрованы, ключ шифрования хранится отдельно от базы, секреты лежат в защищённом хранилище и регулярно меняются. Компрометация одного слоя целостных данных не даёт.
Зашифрованная копия базы лежит у независимого провайдера: другая инфраструктура, отдельная учётная запись, обновляется несколько раз в сутки. Приём согласий на это время принимает резервный контур в другом дата-центре. Сценарий редкий, но мы отрабатываем его на регулярных учениях по восстановлению.
Мы восстановим их примерно за 10 минут: база откатывается точно к состоянию за минуту до удаления, окно отката составляет 30 дней. Потеря данных при таком откате не превышает 1-2 минут.
Да, еженедельно: копию скачивают, расшифровывают и разворачивают заново, а результат уходит дежурному алёртом. Наличие копии мы не считаем доказательством того, что она восстановится.
Нет, данные разделены на уровне базы: у каждого клиента 1ОПД свой изолированный контур, и запрос выполняется только в его границах. Изоляция держится на двух независимых слоях — отдельная схема на клиента и политики доступа на уровне строк. Перед каждым релизом мы прогоняем тест на утечку между контурами: проверяем, что запрос одного клиента не возвращает ни строки другого. Это снижает риск межклиентского доступа и проверяется на каждом релизе.
Нет. Запрос на создание согласия проходит через буфер: пока приложение перезапускается, буфер удерживает запрос и отвечает клиенту «принято», а после восстановления доставляет его в базу. Запросы, исчерпавшие попытки доставки, уходят в отдельную очередь разбора и попадают в дежурный алёрт, а не пропадают молча. Перед каждым выкатом на прод мы прогоняем автоматические проверки и снимаем резервную копию базы.
Дежурный мониторинг круглосуточно проверяет, что приём согласий работает, база достижима, очередь не растёт и сертификаты в порядке. При любом отклонении алёрт немедленно уходит дежурному. Мониторинг работает и на основном контуре, и на резервном.
В журнал попадает каждое действие работника 1ОПД в кабинете клиента, создание и отзыв согласия, уничтожение персональных данных субъекта: время, кто совершил операцию, адрес и служебные метаданные. Эта запись подтверждает, кто и когда совершил операцию.
Это худший сценарий: одновременный отказ основной базы, её горячей копии, резервного контура и всего основного облака в промежутке между двумя копиями у стороннего провайдера. В штатной работе и в большинстве аварийных сценариев потерь данных нет вообще.
ООО «Дисконто» (оператор платформы 1ОПД) внесено в реестр операторов персональных данных Роскомнадзора. Архитектура защиты соответствует:
Согласия субъектов, редакции политики, уведомление Роскомнадзора, обращения субъектов: платформа держит записи, юристы 1ОПД принимают правовые решения.
Получить консультацию →