Нередко наши клиенты, уже использующие облака для работы с персональными данными, задаются вопросом: а подходят ли облачные сервисы для бэкапов ПДн? Сегодня мы на собственном опыте покажем, какие требования к резервному копированию ПДн и данных ГИС предъявляют регуляторы, как их выполняет сервис-провайдер в облаке и как мы решаем насущные задачи клиентов по обеспечению доступности персональных данных при использовании распределенной инфраструктуры.
Экспертом при подготовке статьи выступил Алексей Афанасьев (#CloudMTS).
Требования со стороны регуляторов
Практически все наши клиенты используют сервисы резервного копирования. При этом, работая с персональными данными, они понимают, что регуляторы предъявляют достаточно высокие требования к безопасности такой чувствительной информации. Предлагаем на нашем провайдерском опыте разобраться, как эти меры выполняются в облаке.
Прежде чем перейти к техническим вопросам, обсудим требования регуляторов по работе с ИСПДн и меры, которые необходимо выполнить при организации резервного копирования персональных данных.
Если как следует ознакомиться с основным регулирующим законом, 152-ФЗ «О персональных данных», а именно со ст. 19, можно увидеть следующее:
Статья 19. Меры по обеспечению безопасности персональных данных при их обработке
1. Оператор при обработке персональных данных обязан принимать необходимые правовые, организационные и технические меры или обеспечивать их принятие для защиты персональных данных от неправомерного или случайного доступа к ним, уничтожения, изменения, блокирования, копирования, предоставления, распространения персональных данных, а также от иных неправомерных действий в отношении персональных данных.
2. Обеспечение безопасности персональных данных достигается, в частности:
…
7) восстановлением персональных данных, модифицированных или уничтоженных вследствие несанкционированного доступа к ним;
Иными словами, закон гласит, что на случай несанкционированного вмешательства, при котором ПДн были уничтожены или повреждены, необходимо иметь средства для их восстановления.
Вывод №1, очевидный. Бэкапы не являются задачей на усмотрение оператора ПДн, а, согласно требованиям 152-ФЗ, лежат в его зоне ответственности: резервное копирование ПДн — его прямая обязанность.
Строя свою ИС, работающую с ПДн и ГИС, важно учитывать требования приказов ФСТЭК №17 и №21, которые относят средства резервного копирования к средствам защиты информации.
Приказ ФСТЭК №17:
20. Организационные и технические меры защиты информации, реализуемые в информационной системе в рамках ее системы защиты информации, в зависимости от угроз безопасности информации, используемых информационных технологий и структурно-функциональных характеристик информационной системы должны обеспечивать: … доступность информации…
20.11. Меры по защите среды виртуализации должны исключать несанкционированный доступ к информации, обрабатываемой в виртуальной инфраструктуре, и к компонентам виртуальной инфраструктуры, а также воздействие на информацию и компоненты, в том числе к средствам управления виртуальной инфраструктурой, монитору виртуальных машин (гипервизору), системе хранения данных (включая систему хранения образов виртуальной инфраструктуры), сети передачи данных через элементы виртуальной или физической инфраструктуры, гостевым операционным системам, виртуальным машинам (контейнерам), системе и сети репликации, терминальным и виртуальным устройствам, а также системе резервного копирования и создаваемым ею копиям.
Приказ ФСТЭК №21:
ЗСВ.8 Резервное копирование данных, резервирование технических средств, программного обеспечения виртуальной инфраструктуры, а также каналов связи внутри виртуальной инфраструктуры
ОДТ.4 Периодическое резервное копирование персональных данных на резервные машинные носители персональных данных
ОДТ.5 Обеспечение возможности восстановления персональных данных с резервных машинных носителей персональных данных (резервных копий) в течение установленного временного интервала
Вывод №2. Клиент, работая с ПДн в облаке, обязан решить вопрос доступности информации и, как следствие, регулярно выполнять резервное копирование.
Помимо приказов выше, необходимо обратить внимание на следующие нормативные документы:
Эти документы указывают на необходимость использования средств оперативного восстановления информации и фиксируют максимальное время восстановления доступа к потерянным или измененным вследствие несанкционированного доступа данным — не более 8 часов.
Вывод №3. Приказы выше не устанавливают никаких требований к техническим особенностям системы или методикам выполнения резервного копирования. Однако максимальное время, за которое необходимо восстановить доступ к данным, зафиксировано в этих нормативных актах и составляет 8 часов.
Давайте подытожим. Приведенные выше документы обязывают оператора иметь систему резервного копирования ПДн, с помощью которой информация должна быть восстановлена не более чем за 8 часов.
Соответственно, оператор ПДн обязан выполнить это требование, отразив технические решения в организационно-распорядительной документации, и корректно использовать их на протяжении всей работы с ИС.
Пользователи облака, аттестованного по 152-ФЗ, получают в свое распоряжение готовую инфраструктуру, готовую к работе с ПДн. Другие сервисы, используемые в защищенном облаке, также должны соответствовать требованиям регуляции. BaaS-решения — не исключение. Поэтому провайдер, предоставляя пользователям защищенной инфраструктуры бэкап-инструменты, помимо технических возможностей выполнения резервного копирования, должен обеспечить и соответствие требованиям регуляции.
Как решаются вопросы бэкапа со стороны провайдера
Наше облако аттестовано по требованиям УЗ-1 и К1, соответственно, в нем уже решены два типа задач:
резервное копирование непосредственно облачной инфраструктуры и обеспечение высокой доступности данных;
предоставление бэкап-сервисов пользователям этого облака.
В части обеспечения доступности информации (ОДТ) мы как провайдер решаем следующие задачи:
Периодическое резервное копирование конфигурации компонентов инфраструктуры защищенного сегмента на резервные носители информации (ОДТ.4).
Обеспечение возможности восстановления конфигурации компонентов инфраструктуры защищенного сегмента облака с резервных носителей (т.е. из резервных копий) в течение установленного временного интервала (ОДТ.5).
В части защиты среды виртуализации (ЗСВ):
Резервное копирование данных, резервирование технических средств, программного обеспечения виртуальной инфраструктуры, а также каналов связи внутри виртуальной инфраструктуры защищенного сегмента облака (ЗСВ.8).
Технически эти требования по резервному копированию облачной инфраструктуры реализуются на базе продуктов Veeam. Они хорошо зарекомендовали себя в системах виртуализации. Но это не единственная причина, почему для сегмента 152-ФЗ мы выбрали именно это решение:
Veeam Backup & Replication имеет сертифицированную версию с классификацией по 4-му уровню — отсутствие недекларированных возможностей;
благодаря наличию сертификата с ним легко проходить аттестацию.
Использование этого решения позволяет нам не только защищать свою инфраструктуру, но и предоставлять возможности резервного копирования пользователям нашего защищенного облака. С помощью Veeam пользователи облака могут бэкапить компоненты своей ИС, выполняя все требования регуляторов, которые мы обсудили выше.
Клиенты нашего облака в рамках одной инфраструктуры получают не только соответствующее 152-ФЗ IaaS-решение, но и готовый инструмент бэкапа, ответственность за который лежит на наших плечах. Пользователю остается лишь корректно настроить задачи резервного копирования и следить за их выполнением.
Таким образом, задача резервного копирования данных ИС клиента, находящихся в аттестованном облаке, решается без каких-либо лишних телодвижений. Во-первых, для этого есть полностью готовые к использованию сервисы. Во-вторых, данные не выходят за пределы аттестованного решения провайдера, поэтому обсуждать вопросы связности площадок не имеет смысла.
Однако клиенты не всегда ограничиваются исключительно сервисами одного провайдера. Многие используют собственные мощности или набор облаков различных поставщиков. Именно поэтому более сложна и интересна ситуация, когда у клиента существует потребность бэкапить персональные данные со своей локальной площадки в облако. Мы как провайдер помогаем таким клиентам решать эту задачу с использованием наших BaaS-сервисов.
Бэкап персональных данных с собственной локальной площадки в облако
При передаче резервных копий за пределы собственной защищенной площадки (то есть в репозиторий провайдера) в первую очередь необходимо решить вопрос безопасности. Построение распределенной системы резервного копирования складывается из трех задач. Посмотрим, что это за задачи и как они решаются:
Задача | Решение |
Защита данных при передаче по недоверенным каналам связи | Использование сертифицированных крипторешений |
Защита взаимодействующих площадок при подключении к публичным сетям | Использование сертифицированных средств межсетевого экранирования |
Обеспечение высокой доступности согласно требованиям регулятора (помним про 8 часов на восстановление) | Построение отказоустойчивой архитектуры решения |
Рассмотрим каждый из этих вопросов подробнее на практике.
Как выполнить безопасный обмен данными между площадкой клиента и облаком?
Есть два способа: зашифровывать бэкап перед отправкой либо воспользоваться защищенным каналом для передачи бэкапа. Поскольку представленные современные средства резервного копирования не имеют функционала сертифицированных средств шифрования, соответственно, не имеют каких-либо сертификатов СКЗИ, первый вариант отпадает. Поэтому систему нужно построить накладными средствами, решив вопрос защиты каналов с помощью установки криптошлюзов.
Клиент, работая с облаком, привык пользоваться гибкими решениями и инструментами. В облаке, как известно, не приветствуется использование программно-аппаратных решений, поэтому стоит обратить внимание на виртуальные криптошлюзы.
У такого подхода есть очевидные плюсы. Виртуальный шлюз легко и быстро устанавливается, не требует колокации и лишних затрат, у него отсутствуют характерные для аппаратных решений проблемы. Кроме того, виртуальные шлюзы (в отличие от аппаратных) хорошо масштабируются с точки зрения производительности — при увеличении задействованных vCPU растет и производительность решения. Работа с ВМ, которая будет представлять криптошлюз, не требует «удаленных рук» и присутствия инженеров на площадке.
Как защитить площадки, участвующие в обмене данными, при подключении к публичным сетям?
На стороне локальной площадки клиента вопрос межсетевого экранирования обеспечивается установкой программно-аппаратного решения, которое, как правило, сертифицировано и как криптошлюз, и как межсетевой экран.
В облаке мы используем виртуальные криптошлюзы. Да, такие решения могут не иметь сертификатов необходимого уровня по межсетевому экранированию, однако это и не нужно. Аттестованное облако уже защищено общим сертифицированным межсетевым экраном, поэтому надобность в применении отдельных сертифицированных решений отпадает.
Реализация отказоустойчивой архитектуры решения
В большинстве случаев отказоустойчивые решения строятся методом дублирования или кластеризации. Такой подход оправдан при построении систем на базе программно-аппаратных решений. На стороне облака виртуальные аплайнсы дают нам преимущества — они могут быть легко забэкаплены, как и любые другие элементы инфраструктуры.
Своим клиентам мы предлагаем решение на базе продуктов С-Терра. Этот инструмент решает все задачи организации высоконадежной и защищенной связности двух площадок для передачи бэкапов ПДн. В линейке продуктов С-Терра имеются различные варианты программно-аппаратных и виртуальных криптошлюзов. Благодаря широкой линейке можно подобрать оптимальное решение как по производительности, так и по и отказоустойчивости. Производительность шлюзов С-Терра в зависимости от модификации варьируется от 100 Мбит/c до 10 Гбит/с, поэтому и клиент, и мы как провайдер всегда сможем подобрать наиболее оптимальное для своих задач решение.
Варианты подключения локальной площадки клиента к BaaS-сервису
Обмен данными между площадками может быть организован двумя способами.
Veeam Cloud Connect Backup
Схема используется в том случае, когда у клиента есть сервер Veeam Backup & Replication. Он выполняет резервное копирование объектов со своей площадки, а облако используется как репозиторий. Связь организуется между самим Veeam Backup & Replication и репозиторием через описанный выше защищенный канал связи.
С использованием агентов
В случае, когда у клиента отсутствует сервер Veeam Backup & Replication на своей площадке, вместо него для резервного копирования используются агенты на серверах и ВМ. Управление осуществляется через Veeam Service Provider Console.
Эти сценарии в дальнейшем могут обеспечить и другие возможности.
Восстановление в облако провайдера
При работе с собственной площадкой и хранением резервных копий в облаке, в случае выхода из строя локальных серверов, клиент может восстановиться прямо в аттестованном сегменте облака и продолжить там работу до того момента, пока локальная площадка не будет восстановлена.
Миграция инфраструктуры
В случае, если клиент хочет перенести данные с одной площадки на другую, VCC позволяет решить и такую задачу.
Amoled
Правила пользования S-Terra, с. 15, для исполнения КС2 требуется АПМДЗ на аппаратную платформу (т.е. на виртуальную машину поставить нельзя). Как вы умудрились пройти аттестацию по К1 с криптошлюзом на виртуалке? =)
it_sec Автор
По требованиям регулятора для ГИС в качестве СЗИ необходимо рассматривать только сертифицированные решения, что очевидно. С другой стороны, на текущий момент нет действующего документа, определяющего требования к классу используемых криптосредств. Для ряда клиентов (в случаях повышенных требованиях описанных частных моделях нарушителя) мы можем рассмотреть использование необходимых ПАК с более высоким классом, чем КС1.