Шифрование – путь к безопасному облаку?

Алексей
Сабанов

Заместитель генерального директора ЗАО “Аладдин Р.Д."

Александр
Додохов

Руководитель направления защиты баз данных ЗАО “Аладдин Р.Д."

Определение типа облака

Чтобы аккуратно рассмотреть затрагиваемые вопросы, сначала очертим область исследования. Как правильно определить тип облака с точки зрения информационной безопасности? Из разных моделей облаков (частное, гибридное, отраслевое, публичное) основной научный интерес для специалистов ИБ представляют вопросы обеспечения безопасной работы в публичном облаке. Действительно, для частного облака задачи ИБ (обеспечение доступности, целостности и конфиденциальности информации) понятны: корпоративный ЦОД, как правило, находится внутри защищенного периметра предприятия – владельца облака. Переход к облачным вычислениям в данном случае является естественным шагом развития грид-вычислений.

Специалистам понятно, как обеспечить ИБ в частном облаке. Используемые в настоящее время публичные облака от Amazon, Microsoft, IBM, Oracle, etc., а также некоторые (если не сказать большинство) из строящихся государственных облаков на федеральном и отраслевом уровнях следует относить к публичным. Доказательство этого тезиса укладывается в несколько предложений. Федеральное облако, связанное с порталом государственных и муниципальных услуг, является публичным по определению, поскольку "участниками электронного взаимодействия в информационных системах (ИС) является неопределенный круг лиц и в использовании которых (ИС) этим лицам не может быть отказано" (ст. 2 п. 13 Федерального закона № 63-ФЗ "Об электронной подписи"). Да и владельца информации в данной государственной информационной системе (ГИС) определить трудно. Формально это Минком-связь, но кто реально отвечает за безопасность данных, остается вопросом… В полной мере это утверждение относится и к строящемуся облаку Минздрава. Кроме упомянутой открытости, имеется еще одно обстоятельство, играющее в сторону публичности данной ГИС. Если в 2013 г. аукцион выиграла одна провайдерская компания, на следующий год скорее всего выиграет другая. Кто в конечном счете является фактическим владельцем данных этой ГИС? Как будет организован процесс миграции медицинских и персональных данных в случае смены провайдера облака? Кто будет отвечать за последствия? Следовательно, можно квалифицировать и эту ГИС как публичное облако.

Определившись с предметом рассмотрения (публичное облако), попробуем перейти к проблемам шифрования.

Шифрование как средство обеспечения конфиденциальности данных в облаке

Рассмотрим вопрос об обеспечении конфиденциальности данных ограниченного доступа при их хранении, передаче и обработке в публичном облаке. Проще всего разобрать тему, опираясь на цитаты из первой десятки ссылок, выскочивших в поисковике, изучение которых сразу вызывает вопросы у читателя.

Приведем цитату №1: "Лучшая мера по защите расположенных в хранилище данных – использование технологий шифрования. Провайдер всегда должен шифровать хранящуюся на своих серверах информацию клиента для предотвращения случаев неправомерного доступа. Провайдер также должен безвозвратно удалять данные тогда, когда они больше не нужны и не потребуются в будущем". Видимо, имеется в виду хранилище (и сервер) в облаке, так как статья посвящена облакам. Попробуем обсудить наиболее актуальные детали вопроса шифрования.

Предлагаемые провайдерами способы защиты конфиденциальной информации (КИ), которая хранится и обрабатывается в облаках, как правило, основаны на шифровании всего объема информации (всей базы данных) или (реже) на различных вариантах фрагментации и шифрования. Для задачи обработки КИ, одним из видов которой часто являются персональные данные (ПДн), такое предложение имеет два существенных недостатка. Во-первых, предлагаемые провайдером подходы подразумевают значительную вычислительную нагрузку на компьютер клиента и серверы в облаке. Во-вторых, в данных подходах ситуация с разделением ответственности за обеспечение конфиденциальности ПДн между оператором персональных данных и провайдером облачных услуг перед субъектами ПДн становится запутанной не только с очевидной и хорошо известной юридической точки зрения (кто несет юридическую ответственность за безопасность КИ?), но и с точки зрения организационно-технической (как безопасно организовать процесс шифрования и расшифровки данных?).

Самым существенным с точки зрения безопасности процессов шифрования является вопрос об управлении ключами шифрования и особенно задача их безопасного распределения. Далеко не праздными кажутся связанные с этим обстоятельством следующие вопросы: каким образом провайдер обеспечит защищенное распределение ключей шифрования всем пользователям, допущенным к КИ, из числа сотрудников арендатора облачного пространства? Какие алгоритмы шифрования провайдер будет использовать – для всех арендаторов разные или единые? И какие именно? Если западные, то они не удовлетворяют текущим требованиям российского законодательства. Если ГОСТ, то существует вероятность нарушения требований по учету СКЗИ, не говоря уже об ответственности за несанкционированный вывоз (случайный или преднамеренный) клиентского СКЗИ за рубеж РФ.

Какие гарантии удаления данных провайдер может дать арендаторам? Тем более если данные надо удалять после завершения срока действия договора, по складывающейся практике не всегда заканчивающегося мирно.

Следующая цитата: "Зашифрованные данные при передаче должны быть доступны только после аутентификации. Данные не получится прочитать или сделать изменения, даже в случае доступа через ненадежные узлы… Наиболее распространенным способом аутентификации является защита паролем. Однако провайдеры, стремящиеся предложить своим клиентам более высокую надежность, прибегают к помощи более мощных средств, таких как сертификаты и токе-ны". Цитата порождает массу вопросов, особенно вторая часть. Спишем явно некорректные формулировки на непрофессиональный перевод. Сделаем некоторые разъяснения сначала об аутентификации, сертификатах и токенах. Аутентификацией называется процесс, состоящий из двух взаимосвязанных процедур: подтверждения подлинности предъявленных заявителем идентификаторов (идентификатора) с помощью аутентификатора и проверки принадлежности аутентификатора (секрета, который знают обе стороны взаимодействия или о существовании которого знают обе стороны). Токеном в западной литературе называют аутенти-фикатор (секрет). В качестве аутентификатора может использоваться пароль, одноразовый пароль или закрытый ключ. В последнем случае (самом защищенном по требованиям ИБ) в качестве идентификатора используется цифровой сертификат, связывающий идентификаторы пользователя (записанные в соответствующие поля сертификата) и сам секрет с конкретной личностью. Сертификат выдается удостоверяющим центром, отвечающим за идентификацию владельца сертификата и правильность заполнения полей, за что пользователь расписывается при выдаче собственноручно. Применение сертификата и закрытого ключа в качестве аутентификатора позволяет применять двустороннюю (строгую) аутентификацию сервера и легального пользователя перед его доступом к зашифрованным данным, находящимся в облаке. Безопасная схема распределения ключей шифрования при применении сертификата доступа проста и понятна: ключи шифрования можно рассылать пользователю в зашифрованном на его открытом ключе виде. Единственным не до конца решенным вопросом при этом является проблема трансляции доверия аутентификации легального пользователя корпоративной (локальной) сети к данным в облаке. Приемлемые схемы трансляции доверия будут представлены в следующей статье. Заметим, что рекомендуемые многими облачными провайдерами схемы трансляции доверия относятся только к использованию паролей (SAML). Как при этом можно безопасно распределить ключи шифрования, остается загадкой.

Опустим традиционное "кто виноват?" и перейдем сразу к разделу "что делать?".

Что делать?

Исходя из вышесказанного, становится очевидным, что обеспечение безопасности информации в ИС, размещаемой в публичном облаке, а также ответственность за безопасность информации полностью ложится на владельца ИС. Таким образом, выбор методов и средств защиты определяется исходя из специфики каждой ИС, размещаемой в публичном облаке. Однако существует несколько общих рекомендаций, в частности по технологии шифрования информации и аутентификации, применимых к таким ИС:

• шифрование не всей, но такой критичной к раскрытию части информации, без наличия которой общая информативность ресурса стремится к нулю;
• запрет хранения ключей шифрования в облачной инфраструктуре;
• распространение ключей шифрования (и следовательно, прав доступа) только для авторизованных пользователей, самой безопасной схемой при этом является производство и управление ключами внутри защищенного периметра локальной корпоративной сети;
• авторизация пользователя только после прохождения процедуры строгой взаимной аутентификации.

Подобный подход снимает с владельца ИС ряд серьезных задач по защите информации, например, по безопасному резервному копированию БД, необходимости удаления ненужной конфиденциальной информации, репликации и т.п.