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

Несмотря на относительную "молодость" технологии облачных вычислений, о безопасности передачи, обработки и хранения данных в облаке написано немало статей и даже проектов стандартов. В большинстве публикаций рекомендации с учётом и без учёта требований ИБ повторяют друг друга, причём часто дословно. Тем не менее некоторые положения, особенно в наиболее часто повторяющихся моментах, на наш взгляд, нуждаются в серьёзном рассмотрении и уточнении специалистами. Как гласит старинная французская поговорка, дьявол скрывается в деталях. Данная статья посвящена некоторым существенным моментам, которые не всегда раскрываются в публикациях.

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

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

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

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

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

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

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

Токеном в западной литературе называют аутентификатор (секрет). В качестве аутентификатора может использоваться пароль, одноразовый пароль или закрытый ключ. В последнем случае (самом защищённом по требованиям ИБ) в качестве идентификатора используется цифровой сертификат, связывающий идентификаторы пользователя (записанные в соответствующие поля сертификата) и сам секрет с конкретной личностью.

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

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

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

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

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

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

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

Что делать?

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

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

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