Облачные вычисления в России: возможности, вызовы и риски

1. Я бы сказал, что облачного провайдера надо выбирать в соответствии с моделью угроз заказчика. Что может являться подтверждением соответствия? Тут ничего нового придумать не получится – это или результаты аттестации экспертной организации в области безопасности, причем не всех подсистем провайдера, а конкретной услуги или набора услуг, которые будут приобретаться. А также согласование защитных мер и обязательств в договоре на оказание услуг (если мы обсуждаем собственную информацию заказчика). Если же мы говорим об информации, охраняемой федеральным законодательством, – персональные данные, разного типа конфиденциальная информация, – то тут мы можем говорить о том, что провайдер должен предоставить результаты аттестации услуги или комплекса услуг экспертной организации, уполномоченной ФСТЭК, где будет указан класс защиты обрабатываемой информации.

2. Конечно. Путем выставления необходимых требований при выборе облачного провайдера и их закрепления в договорных отношениях.

3. Многих заказчиков, особенно малого, а временами и среднего бизнеса, не волнуют слова про "потерю контроля", "обеспечение безопасности", и т.п. – у них и своих-то подразделений соответствующих нет. Их волнует, чтобы IT-системы надежно и недорого обеспечивали достаточную поддержку их бизнеса. Если при этом провайдер еще будет "прикрыт" соответствующей аттестацией и сможет в договоре прописать, что обеспечивает защиту ПДн, то это будет еще одним плюсом для таких заказчиков.

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

5. Не обязательно. Зависит от категории обрабатываемой информации. Если провайдер обрабатывает только собственную информацию частных предприятий – может, и не надо ему никаких средств защиты, кроме тех, которые защищают его самого. Если ПДн малых предприятий – то уже возникают требования по применению сертифицированных средств. Если же это облако, обрабатывающее конфиденциальную и другую информацию, охраняемую федеральным законодательством, в интересах государственных учреждений, – то тут уже и сертифицированные средства, и аттестация…

6. Не думаю, что существенно. Потому что он регулирует "Организацию предоставления услуг облачных вычислений органам государственной власти, органам местного самоуправления, органам управления государственными внебюджетными фондами, иным органами и организациям". И там закреплены те самые требования по сертификации, аттестации и т.п., о которых мы говорили выше. Говоря же о реальном развитии облачных технологий, мы должны опираться на потребности массового коммерческого рынка. И адекватность и эффективность предложений именно для него. Именно это и будет ключевым фактором развития облачных технологий. l

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

2. Формально да. Методом заключения каких-либо соглашений, регулирующих вопросы безопасности. Фактически же реальных механизмов влияния на эксплуатацию средств ИБ поставщика облачных услуг у потребителя быть не должно.

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

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

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

6. Начнем с того, что это пока проект. Статус на данный момент: закончено общественное обсуждение. На развитие собственно облачных вычислений, безусловно, окажет ускоряющее воздействие, ведь в нем определены поправки, которые формализуют важные пункты взаимодействия между поставщиком и потребителем облачных вычислений – вопросы регулирования цен, ответственности поставщика и потребителя, общих подходов к обеспечению показателей безопасности, особенно для государственных облачных систем. Однако конкретики в части средств защиты информации (кроме того, что они должны быть сертифицированы) данный закон не несет. Это должно уточняться руководящими документами соответствующих ведомств.

1. Я бы начал с ключевого для России вопроса: "Кто (будет) виноват?". Другими словами, как относиться менеджерам ИБ к переходу компании в облака? Можно ли в этом случае какие-то задачи и ответственность перенести на облачного провайдера? Считать ли это облегчением хоть в какой-то степени или, напротив, дополнительным обременением?

2. Думаю, ни для кого не сюрприз, что вне зависимости от того, где находятся и обрабатываются данные компании, ее сотрудников, бизнес-партнеров и клиентов, ответственность за их безопасность и соответствие систем защиты требованиям регуляторов остается на плечах ИБ-менеджеров компании. Даже если провайдер предоставляет актуальные сертификаты ISO/IEC 27001 и др., никто не гарантирует вам 100% защиту. Аттестация? Да, если информационная система (совокупность аппаратных и программных средств) прошла необходимую аттестацию, можно попытаться прикрыться этим фактом. Но, во-первых, во внешнем ЦОДе обычно вам выделяется лишь часть его ресурсов, причем виртуальных, что позволяет провайдеру более гибко управлять загрузкой ЦОДа и быстро отвечать вашим же меняющимся требованиям. Будет ли готов провайдер зафиксировать ваш "контейнер" и провести его аттестацию как информационной системы – вопрос, как минимум, открытый. Во-вторых, переходя в облако, вы обычно обеспечиваете доступ в него с большего количества и разнообразия клиентских устройств, в том числе и мобильных. Плюс защита на уровне каналов связи. О какой аттестации в таком случае может идти речь? Разве только использование неких "компенсационных мер", что на самом деле не решает проблему.

3. И тут появляется другой классический вопрос: "Что делать?" Ответ, естественно, один – обеспечивать надежную защиту данных, где бы они ни находились и куда бы ни передавались. Облачная среда – среда провайдера, поэтому хранимые в облаке и на мобильных устройствах сотрудников данные должны быть зашифрованы, равно как и при их передаче по каналам связи. Контроль доступа к ним должен включать усиленную аутентификацию и единую авторизацию (Single Sign-On), однозначно идентифицируя пользователя на любом его устройстве и вне зависимости от его местонахождения. Добавляем сюда продуманную защиту от вредоносных программ по всем каналам – Web, E-mail, на уровне сети и на уровне файлов – и… переходим к следующему шагу.

4. Никто не застрахован от изощренных направленных атак – APT (Advanced Protection Threat), поэтому построив защиту, расслабляться еще рано. Грамотно спланированная и реализованная защита – это лишь первая часть марлезонского балета. И поскольку идеальной защиты не бывает, необходимо перейти к следующему этапу – выявление атаки и организация правильного реагирования. Чем раньше будет обнаружено вторжение и чем грамотней будет механизм реагирования, тем меньший ущерб будет нанесен. APT-решения (Advanced Threat Protection) уже есть и продолжают развиваться, но они не панацея. Необходимо перейти к концепции минимизации доверия: никто никому не доверяет без явной и подтвержденной необходимости, и ничего не разрешено по умолчанию. Кроме того, вся активность в ваших сетях должна оцениваться с точки зрения появления аномалий, каждая из которых должна стать предметом отдельного изучения специалистов ИБ. Кстати, а у многих ли из вас ведется мониторинг исходящего трафика, и, например, сопоставление его с IP-адресами известных C&C-серверов? Боюсь, что это был риторический вопрос. Какая в этом специфика для облачных сред? Только одна – вам надо строить решение совместно с провайдером…

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