Недавно мне довелось выступать на конференции, полностью посвященной облакам, - стартапы и уже существующие не один год компании наперебой заманивали в свои сети доверчивых ИТ-директоров и ИТ-менеджеров. "У нас самое лучшее соотношение цены и качества!" "У нас есть ЦОД не только в России, но и в Европе!" "Наша платформа размещена в США на самых надежных серверах Amazon!" "Наши облака полностью защищены!" "Мы соответствуем ФЗ-152!" И так далее, и тому подобное...
Но стоило мне только задать несколько наводящих вопросов по двум аспектам - безопасность и соответствие законодательству по персональным данным, - как сразу же высветился целый ряд проблем, о которых заказчику облачных услуг никто не удосуживается рассказать. Отчасти это происходит из-за непонимания самими облачными провайдерами, что же такое безопасность вообще и информационная безопасность в частности. Отчасти - из-за ориентации на западные практики, сильно отличающиеся от российских. Иногда это банальный обман заказчика, верящего провайдеру на слово и не проверяющего его заявления. Один из облачных провайдеров так ответил по поводу данной коллизии: "Заказчики не спрашивают нас про безопасность, а нам тратиться на невостребованную услугу не резон". Но какой бы ни была причина - результат один. Данные или приложения, переданные в облако, не являются ни защищенными, ни соответствующими требованиям российского законодательства. Да и сами облачные провайдеры подчас не соблюдают необходимых условий, позволяющих им на законных основаниях хранить и обрабатывать информацию своих клиентов. Продолжительные и неоднократные дискуссии с облачными провайдерами не привели к пониманию с их стороны. Вот так и появился этот материал, чтобы помочь ИТ-специалистам осознанно подходить к выбору облачного провайдера.
Сразу хочу отметить, что представленный в статье чек-лист с вопросами, которые стоит задавать облачному провайдеру, достаточно объемный и учитывает практически все основные направления обеспечения безопасности. Это результат долгой работы нашей компании с различными облачными провайдерами. Но далеко не все из описанных в чек-листе требований нужны клиентам. Это классическая дилемма: что важнее, безопасность или удобство? А если безопасность, то какая нужна нам - для работы или для галочки (для выполнения не всегда адекватных требований законодательства)? И конечно, не стоит забывать, что передавая данные или приложения в облака, мы не снимаем с себя ответственности за защиту на клиентской стороне. Известен такой парадокс: конфиденциальности в облаках требуют почти все (особенно после истории со Сноуденом), а вот о том, безопасен ли канал, соединяющий клиента и облачного провайдера, почему-то забывают. Свыше 80% компаний, "ушедших" в облака, никак не защищают информацию, отправляемую через провайдера, - трафик передается в открытом виде. Как можно требовать безопасности от провайдера, если мы не можем сами ее обеспечить? Но вернемся к выбору облачного провайдера с точки зрения безопасности.
Начните с главного
Экономия и возможность сосредоточиться на основных компетенциях - основной мотив перехода к облакам. Но очевидно, что принимая такое решение, необходимо взвесить все риски - стратегические, юридические, операционные, финансовые... Готовы ли мы отдать "чужому дяде" свои данные и приложения? Не ответив положительно на этот вопрос, переходить к остальным глупо. А ответив, вы должны будете задать себе основной вопрос: чего опасаться при переходе в облака? Потери данных? Кражи приложений? Модификации данных? Доступа к данным спецслужб и иных третьих лиц? Невозможности "достучаться" до облачного провайдера? Масок-шоу на стороне поставщика услуг и "выемки" ваших данных? Перехода прав на ваши приложения к провайдеру? Угроз много и сформировать их модель можете только вы - ни один облачный провайдер вам тут не поможет. Это ваши риски и ваши угрозы - поставщик услуг может только помочь их нейтрализовать или отказаться от борьбы с ними, если для него расходы будут велики.
Сформировав модель угроз, вы можете переходить к составлению списка требований по защите. И вот тут вам поможет чек-лист, к составу которого мы и переходим.
Чек-лист
Список вопросов, ответы на которые вы должны получить от облачного провайдера, выглядит следующим образом:
- Защита данных и обеспечение privacy
- Управление уязвимостями
- Управление identity
- Объектовая охрана и персонал
- Доступность и производительность
- Безопасность приложений
- Управление инцидентами
- Непрерывность бизнеса и восстановление после катастроф
- Ведение журналов регистрации (eDiscovery)
- Сompliance
- Финансовые гарантии
- Завершение контракта
- Интеллектуальная собственность
Защита данных - вопрос № 1
Когда мы говорим о безопасности облаков, то, очевидно, первое, что нас интересует, - как будут защищены данные, передаваемые в это облако. И тут впору задать следующие вопросы, ответы на которые помогут вам лучше сориентироваться при возникающих рисках и сложностях:
- Какие данные я готов передать в облако?
Для ответа на этот вопрос у вас должна быть проведена классификация данных с их приоритезацией по различным критериям - важность, конфиденциальность, частота использования, скорость доступа, отнесение к той или иной тайне и т. п. От такой классификации зависит, что вы сможете отдать в облако, а что должны обрабатывать самостоятельно.
- Как мои данные отделены от данных других клиентов?
Где хранятся мои данные? Неважный с технический точки зрения вопрос становится очень актуальным в контексте выполнения требований законодательства о персональных данных. Согласно Федеральному закону № 152-ФЗ "О персональных данных" трансграничная передача данных (то есть за пределы Российской Федерации) требует от оператора персональных данных письменного согласия на это со стороны субъекта, чьи данные будут переданы за границу. Если облако располагается только в России, то подобная проблема отсутствует, а если нет, то вам необходимо получить согласие всех субъектов персональных данных. Именно вам, а не облачному провайдеру. И то, что он преподносит как свое преимущество, для вас превращается в ночной кошмар, так как получить письменное согласие от человека, который ни разу не слышал о ФЗ-152, непросто.
- Как обеспечивается конфиденциальность и целостность моих данных?
- Как осуществляется контроль доступа к моим данным?
- Как данные защищены при передаче от меня к облачному провайдеру?
Это еще одна головная боль - причем как с технической, так и с организационной точки зрения. Согласно ряду нормативных актов конфиденциальность информации должна обеспечиваться с помощью сертифицированных в ФСБ шифровальных средств. Можно ли ожидать, что на площадке Amazon или Azure такие средства есть? Вряд ли. В случае с использованием IaaS-модели такие средства можно установить в арендуемой инфраструктуре самостоятельно, а вот в SaaS и PaaS -почти нереально. Но даже если вы и самостоятельно установите средства шифрования на удаленной площадке, то возникнет вопрос об их экспорте за пределы РФ, а это очень и очень нетривиальная задача, поскольку требуется получить кучу согласований от разных ведомств.
- Как данные защищены при передаче от одной площадки облачного провайдера до другой?
- Реализованы ли меры по контролю утечек данных?
- Может ли третья сторона получить доступ к моим данным? Кто, как и при каких условиях?
- Все ли мои данные удаляются по завершении предоставления сервиса?
Стой! Кто идет?
Управление идентификационными данными пользователей - непростая задача в корпоративной сети, и для ее решения применяются различные технологии и продукты. А теперь задайте себе вопрос: как аутентифицируются мои пользователи при доступе к чужой инфраструктуре? Можно ли интегрировать каталог учетных записей облачного провайдера с моим? Если нет, кто будет переносить данные из моего каталога в облачный? А кто будет управлять чужим каталогом? А защищать? Видите, как много вопросов возникает при решении всего одной задачи? И ведь чем больше систем вы переносите в облако, тем более непростым окажется решение задачи. Возможно, стоит задуматься о федеративной системе идентификации и аутентификации...
Безопасность приложений
Данные, передаваемые в облака, находятся там не сами по себе (если это, конечно, не файловое хранилище). Они обрабатываются различными приложениями - ERP, CRM, SCM, HRM и т. п. Низкая защищенность таких приложений, особенно самописных, - очень распространенная проблема. Поэтому стоит задать облачному провайдеру следующие вопросы:
- Исполняются ли рекомендации OWASP при разработке приложений? Чем это можно подтвердить?
- Проходило ли приложение внешнюю сертификацию и тестирование? По ряду нормативных актов это либо уже является (например, в PA DSS или при защите персональных данных), либо может стать (при защите банковской тайны) обязательной нормой.
- При оказании облачных услуг существуют ли приложения третьих фирм? Какие?
- Какие защитные меры приложений применяются? Web Application Firewall? Database Firewall? Сканеры защищенности приложений? Аудит БД?
Управление уязвимостями
Какой бы совершенной ни была система защиты в начале эксплуатации, со временем степень ее надежности уменьшается. Некорректные настройки, уязвимые обновления, найденные новые дыры... Причин много, а результат один - снижение уровня безопасности. Контролировать его можно и нужно, но как эту задачу решает (и решает ли) облачный провайдер? Как часто сканируется инфраструктура на предмет ее защищенности? Кем и с помощью чего выполняется сканирование? Может ли заказчик проводить внешнее сканирование "своего" облака? На каких условиях? Какова процедура устранения уязвимостей и установки патчей?
Управление инцидентами
Еще одна особенность возникает, когда происходит инцидент безопасности. Кто и как должен реагировать на него? При наличии разных ответственных за инфраструктуру, за приложения и данные вопрос отнюдь не праздный. Ситуация еще больше осложняется, если облачный провайдер находится за границей, в другом часовом поясе и общаться с ним приходится на его родном языке. Это явно не способствует оперативности реагирования на инциденты безопасности.
Если ваша политика реагирования на инциденты подразумевает не просто устранение последствий и недопущение повтора инцидентов, но и взаимодействие с правоохранительными органами, то следует уточнить ответы на такие вопросы:
- Как облачный провайдер обеспечивает сбор доказательств несанкционированной деятельности? Как долго облачный провайдер хранит журналы регистрации и возможно ли увеличение этого срока?
- Можно ли организовать хранение логов во внешнем хранилище? Как?
- Предоставляются ли журналы регистрации заказчику? В каком формате и на каком языке?
Интеллектуальная собственность
Другой вопрос, который вообще непонятно к чьей компетенции относится, тоже очень важен. Речь идет о правах на информационные ресурсы и интеллектуальную собственность. Кому принадлежат права на информацию, переданную облачному провайдеру? А на резервные копии? А на реплицированные данные? А на журналы регистрации? А на приложения?
Аналогична ситуация с правами на интеллектуальную собственность. Какие виды интеллектуальной собственности вы планируете передавать в облако:
- Приложения (программы для ЭВМ) и базы данных
- Телевизионное вещание (IPTV)
- Секреты производства (ноу-хау)
- Промышленная собственность (изобретения и т. п.)
- Средства индивидуализации (товарные знаки и т. п.)
Задача не только в составлении перечня таких сведений, но и в ее оценке и введении режима коммерческой тайны. И здесь нас подстерегает еще одна трудность. Если режим защиты коммерческой тайны сложно установить у себя на предприятии (а это действительно непросто), то как это сделать на чужом предприятии? А если он не введен, то говорить о защите прав вообще не имеет смысла - ни один суд не примет иск в подобной ситуации.
Завершение контракта
Завершение контракта - еще одна тема, о которой мало кто думает в процессе заключения облачного договора. Что вы будете делать, если решите не продлевать контракт с облачным провайдером? А что будет с вашими данными и приложениями? И это только первая порция вопросов. К другим относятся:
- Какова процедура возврата данных и приложений? В каком формате? Сроки возврата?
- Как убедиться, что данные уничтожены, а ваши приложения не будут использоваться другими? В какой момент они будут уничтожены? Каковы гарантии?
Контроль превыше всего
Еще одно отличие в обеспечении безопасности облачной инфраструктуры от традиционной - необходимость контроля, потребность в котором при переходе на облачные вычисления становится еще более острой. Ведь если вы не можете самостоятельно защитить данные и приложения и перекладываете ответственность на других, то внедрить меры контроля просто обязаны. При этом заказчик вынужден требовать от исполнителя определенных гарантий, позволяющих ему выполнять свои обязанности в части внутреннего контроля над информационными потоками, а на это готова пойти не каждая компания.
Законодательство
Соответствие законодательным требованиям, пожалуй, самая больная тема, касающаяся облачных вычислений. Связано это с тем, что действующее законодательство как в сфере информационной безопасности, так и в других областях регулирования, например, персональных данных, создавалось, когда облаков еще не было и не могло учитывать появление подобных услуг. Поэтому достаточно забавно слышать или видеть заявления облачных провайдеров о том, что они "полностью соответствуют ФЗ-152". Если буквально следовать всем подзаконным актам, то облачный провайдер должен иметь лицензии ФСТЭК и ФСБ на деятельность в области защиты информации и шифрования, использовать сертифицированные средства защиты, аттестовать свои информационные системы (при работе с госорганами), иметь в штате не менее трех специалистов с высшим образованием в области информационной безопасности, и т. д. и т. п. Я не знаю в России облачных провайдеров, которые могли бы похвастаться таким богатством.
Я не готов вдаваться в тонкости нормативного регулирования облаков; только намечу основные моменты, на которые следует обратить внимание при выборе облачного провайдера и заключения договора с ним:
- Обязанность защищать конфиденциальную информацию (в российском законодательстве существует 65 видов тайн, требующих защиты).
- Защита прав субъектов персональных данных и самих персональных данных.
- Защита государственных информационных ресурсов, в том числе и при передаче их в облака.
- Защита банковской тайны и иных сведений ограниченного доступа, обрабатываемых банками и иными участниками Национальной платежной системы.
- Обеспечение СОРМ.
- Сбор и хранение данных для судебных разбирательств (eDiscovery).
- Юрисдикция и ответственность.
Заключение
Берясь за написание этой статьи, я не ставил перед собой задачу осложнить развитие рынка облачных вычислений в России. Просто, переходя к ним, надо осознавать, что такое безопасность облачной инфраструктуры, что вам может и что должен предлагать облачный провайдер и как проконтролировать, что он вас не обманывает. Ели вы взвешиваете все плюсы и минусы, то переход к облакам может действительно дать те преимущества, о которых там много и упорно вещают различные аналитики и продавцы облачных услуг.