Схема размещения баз данных и систем резервного копирования
Документ, показывающий, где физически живут данные: основная база, её реплики, резервные копии, тестовые среды и файловые хранилища с выгрузками — с указанием площадок, сроков хранения копий и того, кто к ним имеет доступ.
Зачем нужен документ
Перечень систем отвечает на вопрос, какие базы есть. Сведения о размещении — в какой стране они стоят. Схема размещения отвечает на третий вопрос, который на практике оказывается самым тяжёлым: сколько существует копий и где они. Ответ почти всегда удивляет самих владельцев системы.
У одной боевой базы обычно есть реплика для отчётов, ночные резервные копии на отдельном хранилище, недельные и месячные архивы, копия на случай катастрофы у другого провайдера, тестовая среда, куда разработчики залили дамп продуктива полгода назад, и папка с ручными выгрузками у аналитика. Это семь мест с одними и теми же персональными данными, и защищено из них по-настоящему обычно одно.
Документ нужен не ради красивой картинки, а чтобы меры защиты применялись ко всем копиям сразу. Пока схемы нет, разговор о доступе, шифровании и сроках хранения ведётся про продуктивную базу, а утечка происходит из архива, о котором забыли.
Чем грозит отсутствие
Резервная копия — это полная база. Разница только в том, что за ней обычно никто не следит: она лежит в хранилище, доступ к которому есть у администратора и у подрядчика, а данных в ней больше, чем в продуктиве, потому что там вся история.
Как ещё называют этот документ
Что должно быть в документе
Требований к форме нет. Критерий полноты жёсткий и проверяемый: по схеме должно быть видно каждое место, где сегодня лежат персональные данные, включая временные и забытые.
Требования законодательства
Как связан с другими документами
Схема — техническая основа для решений об уровне защищённости, угрозах и доступе.
Когда обновлять документ
Схема устаревает быстрее любого другого документа комплекта: инфраструктура меняется без приказов и уведомлений.
Что спросит проверяющий
Разговор о копиях — быстрый способ понять, насколько система защищена на самом деле. Именно поэтому его заводят почти всегда.
Разбор эксперта
Самый неприятный разговор при аудите — про тестовую среду. Схема выглядит аккуратно: продуктив в защищённом контуре, доступ по ролям, копии по расписанию. А потом выясняется, что год назад разработчики развернули тестовый стенд и залили туда дамп боевой базы, чтобы «проверить на реальных данных». Стенд живёт до сих пор, пароли там простые, обновлений не было, в мониторинг он не включён. Формально это полноценная информационная система персональных данных, о которой не знает никто, включая ответственного за обработку. Правильное решение известно и недорого: данные для тестов обезличиваются при выгрузке, а не копируются как есть.
Второе — про доступ к резервным копиям. В матрице доступа обычно аккуратно расписано, кто что видит в системе: менеджер свои сделки, бухгалтер свои документы. И тут же администратор или подрядчик имеет полный доступ к хранилищу бэкапов, то есть возможность одним движением получить всю базу целиком, минуя любые роли. Разграничение в системе имеет смысл ровно настолько, насколько ограничен доступ к копиям, и это стоит проверять первым делом.
И третье, о чём почти не думают, — удаление. Субъект отозвал согласие, организация честно удалила его записи из рабочей базы, ответила в срок. А в архивах резервных копий эти записи продолжают лежать месяцами, и при восстановлении они вернутся. Полностью вычищать бэкапы обычно невозможно и не требуется — но нужно иметь понятный срок жизни копий и процедуру, при которой восстановленные данные проходят повторную чистку. Без этого фраза «данные уничтожены» не соответствует действительности, и при разборе это становится видно.
Начните с честного вопроса «сколько у нас копий» и запишите все найденные места, включая тестовые стенды и папки с выгрузками. Обезличивайте данные для тестовых сред — это самая результативная мера из недорогих. Ограничьте доступ к хранилищу копий сильнее, чем доступ к самой системе. И задайте срок жизни архивов: вечные копии увеличивают возможный масштаб утечки, ничего не давая взамен.
Александр КеллерманнГенеральный директор, ведущий аудитор ISO/IEC 27001, Комитет по информационной и правовой безопасностиПодробнее об экспертеЧастые вопросы
Нет. Таблица «система — площадка — тип копии — срок хранения — доступ» полнее и проще в поддержке. Рисунок полезен как приложение, но сам по себе редко отвечает на вопросы проверяющего.
Обязательно, и особенно если в них есть реальные данные. Тестовый стенд с копией боевой базы — это полноценная ИСПДн, к которой применяются те же требования.
Да, требование локализации распространяется и на копии: это те же базы данных с теми же сведениями о гражданах РФ.
Прямого требования шифровать нет, но это самая эффективная мера для копий: украденный или потерянный архив без ключа не превращается в утечку. Ключи при этом не должны храниться вместе с копиями.
Удалить из рабочей базы, а для архивов установить понятный срок хранения и процедуру повторной чистки после восстановления. Полное вычищение архивов технически возможно редко, и это признаётся практикой.
Ведёт ИТ, утверждает и контролирует ответственный за обеспечение безопасности. Схема, которую ведёт только ИТ и никто не проверяет, обычно отстаёт от реальности на одно-два изменения.
Схема всё равно нужна: оператор отвечает за данные независимо от того, кто обслуживает серверы. Сведения о площадках и копиях запрашиваются у подрядчика и закрепляются в договоре вместе с поручением на обработку.