Облачные сервисы вошли в повестку российских ИТ-директоров не от хорошей жизни. Бюджеты 2009 года урезаны, и аренда вычислительных мощностей выглядит дешевле, чем закупка серверов. Но за привлекательной ценой стоит вопрос, который провайдеры обходят стороной: кто отвечает за безопасность ваших данных, когда они лежат в чужом ЦОДе? Ответ – обе стороны, и граница ответственности проходит не там, где её обычно рисуют в коммерческих предложениях.

Где провайдер заканчивает, а заказчик начинает

Провайдер отвечает за инфраструктуру: физическую охрану дата-центра, питание, охлаждение, сеть, гипервизор. Это его зона, и спрашивать за неё нужно с него. Но всё, что выше гипервизора, – гостевая ОС, СУБД, прикладной код, права доступа, шифрование, резервные копии – остаётся на вас. Провайдер не настроит за вас политику паролей и не зашифрует таблицу с персональными данными.

Эта граница смещается в зависимости от модели сервиса. При аренде виртуальной машины (IaaS) на заказчике почти всё, включая патчинг ОС. При аренде готового приложения (SaaS) провайдер берёт на себя больше, но и тогда управление учётными записями и классификация данных остаются вашими. Опасность в том, что заказчик подписывает договор, считая, что «купил безопасность целиком», а по факту купил только нижний слой.

Регуляторный контекст: 152-ФЗ и его последствия

Для России это не абстракция. Федеральный закон 152-ФЗ «О персональных данных» вступил в силу в январе 2007 года, а с 1 января 2010 года все информационные системы персональных данных должны быть приведены в соответствие требованиям ФСТЭК и ФСБ. До этого срока – меньше года. Размещение ИСПДн у внешнего провайдера не снимает с оператора ответственности перед регулятором: оператор персональных данных по закону – это вы, а не дата-центр.

Отсюда практические следствия. Провайдер должен подтвердить аттестацию площадки и применяемые средства защиты, иметь сертификаты ФСТЭК на используемые СЗИ. Договор должен фиксировать, где физически хранятся данные, кто имеет к ним доступ и как организовано уничтожение. Для госсектора трансграничная передача данных за пределы РФ во многих случаях недопустима, и это нужно проверять до миграции, а не после.

Как закрепить ответственность на бумаге

Модель разделённой ответственности работает только тогда, когда она прописана в договоре и SLA, а не подразумевается. Составьте матрицу: по каждому уровню – от физической безопасности до резервного копирования – укажите, кто отвечает, как это контролируется и что происходит при инциденте. Серая зона, не закреплённая ни за кем, – это будущая брешь.

На практике большинство организаций приходит не к полному облаку, а к гибридной схеме: критичные системы остаются внутри периметра, второстепенные выносятся наружу. Мы подробно разбирали такой подход в материале о гибридных ИТ-ландшафтах, и именно он сегодня выглядит разумным компромиссом между ценой и контролем. При этом важно заранее понимать, какие данные куда уходят: грамотная архитектура слоя данных и отчётности помогает отделить то, что можно вынести, от того, что должно остаться внутри.

Выстроить эту границу, подготовить ИСПДн к требованиям 2010 года и проверить договор с провайдером на реальные, а не декларативные гарантии – это и есть практическая работа по информационной безопасности, которую стоит начинать до миграции, а не после первого инцидента.

Вывод

Облако не снимает с вас ответственность за данные – оно перераспределяет её. Провайдер защищает инфраструктуру, оператор защищает данные и отвечает перед регулятором. Прежде чем переносить системы наружу ради экономии, зафиксированной в плане ИТ-бюджета на 2009 год, пропишите границу ответственности в договоре. Дешёвое облако без понятной модели разделения рисков обходится дороже собственного сервера.