Новости из Блогов Безопасность облаков. Просто? А вот фиг!

Все как сговорились и все пишут и пишут про безопасность облаков, про то, как это легко сделать на той-то или иной платформе. Правда, рассматривают этот вопрос почему-то с точки зрения облачного провайдера и только с технологической точки зрения. Обычно все приводят примерно такую схему и начинают ее обсуждать. А вот в IaaS можно сделать так и активно задействовать механизмы защиты на уровне виртуализации. А вот в PaaS мы можем на приложения возложить механизмы защиты. Ну и т.д.

​

Красиво, ничего не скажешь. Multitenancy, изоляция потребителей, контроль доступа... Все правильно. Но почему-то мы забываем, что в безопасности облаков то, как защищается инфраструктура самого облака - вопрос хоть важный, но все равно не единственный. Ведь помимо облака у нас есть еще его пользователи - корпоративные или частные.



И вопрос в этом случаев звучит уже не только "как защитить инфраструктуру облачного провайдера?", но и "как безопасным образом работать с инфраструктурой облачного провайдера?". А по статистике (не помню чьей) до 90% предприятий передают в облаков свои данные вообще без защиты. И какой тогда смысл в защите облака, если на подступах к нему все передается в открытом виде?

Но допустим мы решили и эту проблему и включили между облаком и потребителем облачных услуг функция шифрования. И вот тут нам подлянку подкидывает визуализация. Как обычно мы изображем облако? Правильно, как облако ;-) И мы забываем, что на самом деле это может 2, 5, 10, 20 площадок, разбросанных по России или по миру. И правильная реализация подключения к облаку подразумевает адаптивный и динамический выбор "ближайшего" облачного шлюза. Ближайшего по критериям времени отклика, загруженности и другим параметрам. Ограничить подключение потребителя определенным шлюзом неразумно; сразу теряется смысл половина смысла перехода к модели облачных вычислений.

И вот тут вступает в силу российское законодательство, которое в ряде случаев обязывает нас применять только сертифицированные средства защиты, включая и криптографические. А сертифицировать можно только то, что реализует наши ГОСТы. И вот тут всплывает то, на что обычно большинство облачных провайдеров в России пока забивает болт. Чтобы облачная схема на отечественной криптографии заработала в полный рост, каждую площадку надо оснастить отечественной СКЗИ с ее "удобными" механизмами управления ключами, не всегда присутствующей интеграцией с PKI, без отзыва сертификатов и т.п. А чтобы оснастить кажду площадку, ее надо вывезти за пределы России и ввезти в пределы той страны, где расположен ЦОД облачного провайдера. Задача не из легких. А еще и на мобильных клиентах (включая iPad, iPhone, BlackBerry, Android) поставить сертифицированную криптографию.

​

Но это тоже не все. В Cisco есть такая штука, которая называется Cisco Cloud Risk Assessment Framework. Вот ее фрагмент, включающий 10 ключевых областей, которые мы изучаем, прежде чем принять решение о переходе на облачные вычисления. К слову сказать, Cisco использует свыше 400 облачных и аутсорсинговых провайдеров по всему миру и поэтому для нас защита при переходе на облака - это не просто маркетинг, а реальная и ежедневная бизнес-задача.

Итак Cisco Cloud Risk Assessment Framework. Обратите внимание, что безопасность инфраструктуры, о которой в-основном только и говорят - это всего один из вопросов. И находится он далеко не на первом месте. Давайте обратимся к третьему домену - регулятивному. Это то, что касается облачных провайдеров во всем мире, но имеет особую специфику в России. В частности, вспомним позицию ФСТЭК по лицензированию деятельности по ТЗКИ. Что она означает? А то, что облачному провайдеру нужна (по мнению регулятора) лицензия ФСТЭК на ТЗКИ. Да и лицензия ФСБ по ПП-313 тоже не помешает. А они есть? Увы. Является ли это проблемой для потребителя? Нет?! А может да? Но пойдем дальше.

​

Посмотрим на пресловутый ФЗ-152. Персональные данные... Тема, ставшая притчей воязыцех, но по-прежнему актуальная. Но не в контексте 21-го приказа. С ним-то как раз все ясно. А что у нас с выполнением статей 6 и 9 закона, предусматривающих наличие согласия на обработку персональных данных. Ну, допустим, мы можем получить согласие не только у корпоративного потребителя, но и у частного (хотят тут и есть сложности с электронной формой согласия). Но что делать с трансграничной передачей в страны, необеспечивающие адекватную защиту прав субъектов ПДн? Например, США не относятся к адекватным странам. И как быть, если у облачного провайдера площадка в США (например, у Amazon)? Статья 12 подразумевает получение письменного согласия. А облачный SaaS-провайдер, который может сам арендовать мощности у провайдеров IaaS или PaaS, знает, в каких странах находятся площадки, где будут храниться и обрабатываться ПДн? А если знает, то берет ли он согласие на трансграничку во все эти страны? С каждого субъекта? А облачный провайдер - это одно юрлицо или множество (в каждой стране свое)? А не имеют ли доступ к ПДн третьи лица, обслуживающие инфраструктуру ЦОДа? А согласие на передачу ПДн этим третьим лицам есть?

А ведь есть еще 351-й Указ Президента. Депутат Железняк 19-го июня предложил законодательно запретить хранить за границей персональные данные россиян и информацию госорганов. Фиг с ними с персданными. Ну не смогут патриоты Госдумы пользоваться Visa и MasterCard и летать к своим детям и недвижимости заграницу (SABRE-то хранит все не в России). Ну и ладно! А вот идея с запретом хранения данных госорганов за рубежом могла бы быть новацией, если бы не 351-й Указ Президента, датированный 2008-м годом и не определяющий того же. Его, правда, писали люди грамотные. Они ничего не запрещали, а регламентировали обработку информации госорганов в Интернет, в т.ч. и за пределами РФ. И одним из условий такой обработки было использование сертифицированных средств защиты информации. В случае с облаками их надо использовать везде, где могут оказаться данные органов государственной власти РФ. А оказаться они могут везде. Достаточно вспомнить, как могут перемещаться виртуальные машины между физическими серверами и даже отдельными площадками в рамках облачной инфраструктуры (вы, кстати, не задумывались - а информация при перемещении внутри облака шифруется?).

А ведь еще и вопрос аттестации может возникнуть, если провайдер планирует обрабатывать данные из государственных или муниципальных информационных систем. По 17-му приказу ФСТЭК аттестация должна быть проведена обязательна. А как ее провести аттестационной лаборатории, если данные хранятся не у обладателя информации, а у облачного провайдера? А если у него несколько площадок и есть зарубежные, то ситуация становится вообще патовой. Это, кстати, причина, почему Банк России не очень любит облака в банковской деятельности. Дело даже не в том, что остается открытым вопрос передачи банковской тайны организации, которая не имеет права с ней работать. Дело в другом - банковский надзор любит "руками щупать" то, что проверяет. А что он может пощупать в облаке, принадлещаем не проверяемому банку? Ничего. И выводы по результатам проверок он может сделать не те, на которые рассчитывают апологеты облаков. Тут, кстати, совет - пишите письма в ЦБ, чтобы финансовый регулятор сформулировал свою позицию по облакам в банковской деятельности.

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

​

ЗЫ. Сейчас запущен ряд инициатив по адаптации российского законодательства к облачным вычислениям. ФСТЭК также готовит ГОСТ по безопасности облаков. А вот у ФСБ пока никаких изменений - они стабильно требуют лицензирования и сертифицированной криптографии.

Автор: Алексей Лукацкий
Дата: 24 июня 2013 г.
http://lukatsky.blogspot.ru/2013/06/blog-post_24.html