Облака, облачные сервисы, облачные технологии. Если раньше, чтобы читатели не спутали эти термины с обычными облаками, мы использовали кавычки, то теперь, похоже, в этом нет необходимости, об облаках не читал только ленивый. Многие заказчики уже работают в облаках, а некоторые только пытаются попробовать облачную кухню: присматриваются к этим технологиям, стараясь примерить их для своих нужд, выбирая, какие части бизнес-процессов имеет смысл отдать в облака. Их волнует вопрос: если в конечном счете им что-то не понравится, как сложно будет вернуться к своей печке, от которой они пляшут в сторону облаков, или по крайней мере сменить одного облачного провайдера на другого. Тех же из заказчиков, кто уже принял решение частично переходить в облака, волнует вопрос правильного составления договора с облачным провайдером и самое главное – как будет обеспечена защита отданных в облака данных. А для этого нужно сначала защитить сами облака.
Рустем ХАЙРЕТДИНОВ,
заместитель генерального директора компании InfoWatch:
Передавая данные в облако, нужно быть уверенным, что вы в любой момент можете отказаться от услуг провайдера, получив обратно все свои данные. Это касается всех провайдеров, но в последнее время нужно быть очень внимательными с зарубежными серверами – они сами и данные на них могут стать недоступными ввиду американских санкций без всякой возможности выгрузить данные. Конфиденциальность хранимых и обрабатываемых данных декларируют все облачные сервисы, но надо внимательно изучать детали договора, чтобы понять уровень ответственности. Облачные вычисления – совместная работа владельца данных и владельца инфраструктуры и прикладного ПО, поэтому иногда довольно трудно определить, кто виноват в конкретном инциденте – провайдер или пользователь. Чтобы не разочаровываться, необходимо проиграть все возможные сценарии «если, то» до заключения договора.
Дмитрий КАРТАШОВ,
специалист по ИБ, Orange Business Services Россия и СНГ:
Во-первых, клиенту необходимо определиться с моделью предоставления сервиса – это может быть IaaS, PaaS или SaaS. В договоре необходимо четко прописать зоны ответственности клиента и провайдера, список контактных лиц, процедуру взаимодействия с дежурной службой провайдера в круглосуточном режиме без выходных. Также необходимо заключить SLA, в котором прописать уровень доступности сервиса: как правило, не ниже 99,5% времени. Стоит обратить внимание на георезервирование площадки, где располагается платформа провайдера (наличие плана DRP). Еще один обязательный пункт договора – ответственность за выполнение требований по безопасности. Если необходимо соответствие определенному стандарту или ФЗ, например PCI DSS, ФЗ-152, КИИ и т. п., то лучше сразу прописать в соглашении конкретный набор технических мер защиты. Если необходима возможность проведения аудита со стороны заказчика, прописать сроки и контактных лиц. А вот договор о неразглашении является де-факто стандартной частью процесса заключения соглашения с облачным провайдером. В довершение нелишним будет уточнить у провайдера наличие сертификатов Uptime Institute на data-центр, где он развернул свою платформу или владеет им на правах собственника, а также уровень – Tier 1, 2, 3, 4.
Сергей ЗОЛОТУХИН,
специалист по информационной безопасности компании Group-IB:
После подписания договор станет единственным документом, регулирующим правовые отношения между провайдером и клиентом. Чем подробнее в нем прописаны детали сервисов, тем легче контролировать их выполнение, а в случае нарушения условий договора и предъявлять обоснованные претензии. Поэтому в договоре должны быть прописаны точные числовые характеристики предоставляемых сервисов, которые можно проконтролировать: ширина полосы пропускания каналов, выделяемое пространство, объемы трафика, время доступности и другие, в зависимости от особенностей предоставляемых услуг. Обязательно должны быть указаны организационные меры и процедуры обеспечения сервиса, в частности перечень мер и средств защиты, процедуры резервного копирования и т. д. В современной практике это, как правило, фиксируется в отдельном соглашении об уровне сервиса, так называемом SLA. При выборе провайдера необходимо обращать внимание на такие вещи, как меры обеспечения физической безопасности, информационной безопасности самой инфраструктуры провайдера, наличие дополнительных сервисов безопасности, которые могут предоставляться клиенту по запросу, как то: контроль трафика/почты, аудит сервисов и т. д., обеспечение функций резервного копирования, резервного питания и т. д. Очень важно, чтобы в договоре была прописана ответственность провайдера за компрометацию инфраструктуры и, как следствие пользовательских сервисов, недоступность по SLA. И конечно же, нельзя забывать про требования законодательства: к примеру, если мы говорим про Россию и ФЗ-152, то ЦОД/провайдер должен быть готов к работе с персональными данными, хранить их и обрабатывать на территории РФ. Наличие у провайдеров сертификатов соответствия и информации по периодическим аудитам поможет понять уровень провайдера.
Олег ИШАНОВ,
директор по информационной безопасности компании Acronis:
Облачные контракты имеют свою специфику, поэтому следует учесть уровень SLA, а также выяснить, какие штрафные санкции полагаются за его несоблюдение. Важно оценить соответствие требованиям законов, которые регулируют работу с вашими данными, а также наличие соответствующих сертификатов, выданных доверенными источниками, например ISO27001, PCI-DSS, HIPAA и т. д. Если вы планируете обрабатывать в облаке данные, относящиеся к определенной категории, будь то персональные данные (PII), данные о состоянии здоровья (PHI) или данные держателей платежных карт (CHD), вы должны быть уверены, что ваш провайдер также выполняет требования, предъявляемые к обработке и обеспечению безопасности этих категорий данных. Я рекомендую всем пользователям при выборе облачного провайдера обращать внимание на возможность и простоту переноса данных/сервисов на платформу другого провайдера. Это позволит легко сменить провайдера в случае необходимости, а также заставит поставщика услуг быть более внимательным к установленным договором обязательствам.
Евгений ХРАПОВСКИЙ, руководитель направления по развитию виртуального ЦОД «Инфосистемы Джет»:
Важно четко определить схему коммуникации со службой поддержки: каналы обращения к ней, количество обрабатываемых обращений и скорость реагирования на них. Должны быть согласованы и прописаны временные рамки окон, в которые провайдер может проводить регламентные работы по обслуживанию и модернизации инфраструктуры, и их количество. Необходимо проработать вопрос с лицензиями на ПО – можно использовать свои, если такие уже куплены, или взять у провайдера в аренду. Важно четко определить процессы перехода в облако и выхода из него. Как быстро предоставят ресурсы, кто будет проводить миграцию, есть ли какие-то дополнительные требования со стороны провайдера, можно ли использовать пробный период на время развертывания систем? На все эти вопросы в договоре должны быть четкие ответы.
Как проверить степень соответствия предлагаемых облачным провайдером защитных мер их реальной степени защиты?
Рустем Хайретдинов (InfoWatch): Редкий провайдер пустит «проверяющего» в свою инфраструктуру со своими инструментами анализа, скорее пользователь сможет заказать такой мониторинг у провайдера как дополнительную услугу. Пока самостоятельно протестировать защиту провайдера не представляется возможным, поэтому пользователям приходится верить провайдеру на слово. Обычно в набор «инструментов продаж» облачных услуг входит описание продуктов и процедур защиты, таких как антивирус, WAF, NGFW, «песочницы», антиDDoS, постоянный мониторинг трафика и системных событий, регулярные пентесты и другие.
Екатерина СЮРТУКОВА,
руководитель направления сервиса и аутсорсинга центра ИБ компании «Инфосистемы Джет»:
Самый эффективный способ проверить реальную защиту любого ресурса, в том числе и облачного, – провести внешнее и внутреннее сканирование на уязвимости и тестирование на проникновение. Сканирование ресурсов и пентесты дают комплексную картину реальной защищенности предоставляемых облачных ресурсов и помогают проверить, как провайдер в зависимости от модели предоставления услуг – IaaS, SaaS, PaaS – контролирует различные уровни безопасности. Проводить сканирование можно с помощью специализированных облачных сервисов или приобрести on-premise-решение. Для самого простого анализа подойдут и бесплатные инструменты, которые легко найти в Сети. Сканирование позволит выявить известные уязвимости, а также найти небезопасные конфигурации и настройки как в инфраструктуре, так и в сервисах. Для проведения пентестов, как правило, привлекают специальные команды – многие IT-интеграторы предоставляют такие услуги. Специалисты вручную или с помощью инструментов имитируют действия потенциального нарушителя, пытаются эксплуатировать выявленные уязвимости в облаке, проверяют возможность доступа к облачной инфраструктуре и т. д. Этот способ позволяет в реальном времени увидеть, как отработают средства защиты и как отреагирует служба эксплуатации облачного провайдера: зафиксирует ли попытку атаки и какие действия предпримет. Важно понимать, что границы легитимности таких проверок очень размыты. И даже если компания проверяет безопасность своих ресурсов, размещенных в облаке, сканирование и пентесты должны быть согласованы с облачным провайдером и регламентированы договором. Помимо вопросов законности, есть еще важный аспект – наличие риска деструктивных последствий таких тестирований. Облачный провайдер должен знать о тестировании, чтобы подготовиться со своей стороны: проверить наличие резервных копий и т. д. Если с облачным провайдером не удается согласовать проведение сканирования и пентестов (а это действительно сложно), и нет возможности на практике проверить реальную защиту, подтверждением того, что меры по безопасности все же реализованы, могут служить сертификаты соответствия облачной инфраструктуры международным ИБ-стандартам, например PCI DSS, и наличие аттестации платформы на соответствие требованиям ФЗ № 152. Также можно запросить результаты прохождения независимых ИБ-аудитов.
Дмитрий КАРТАШОВ (Orange Business Services):
Проверку степени соответствия защитных мер можно провести по формальному признаку, запросив сертификаты на соответствие платформы требованиям необходимых стандартов. Кроме того, можно запросить результаты проведенных независимых технических аудитов по тестированию на проникновение, анализу защищенности веб-ресурса или провести аудит своими силами, если это прописано в договоре.
Сергей Золотухин (Group—IB):
К сожалению, провести проверку реальной защищенности облака провайдера для заказчика практически нереально. Ни технически, ни организационно. При желании облачный провайдер может провести аудит своей инфраструктуры внешней независимой компанией. Хорошей практикой было бы обязательное предоставление заказчикам заключений аудитов безопасности, проведенных внешними организациями, результатов реальных тестов на проникновение, аудита кодов приложений. Еще одна проблема заключается в том, что техники и тактики атакующих постоянно совершенствуются, поэтому необходимо регулярно следить за тем, чтобы уровень защиты инфраструктуры всегда оставался на высоте. Сейчас на рынке активно развивается направление услуг Red-Teaming – это регулярная, в течение года, проверка надежности защитных мер и способности провайдера противодействовать атакам. Услуги Red-Teaming сейчас начали предлагать компании, стоящие на переднем крае борьбы с киберпреступниками, а не только частные лица. Наличие официального договора на Red-Teaming у провайдера является хорошим аргументом в пользу сотрудничества.
Можно ли осуществить мониторинг аномалий в облаке, которое клиент хочет использовать?
Екатерина СЮРТУКОВА («Инфосистемы Джет»):
Если планируется размещать в облаке действительно критичную инфраструктуру, при выборе облачного провайдера желательно согласовать предоставление «пробных» ресурсов и провести серьезное нагрузочное тестирование, сканирование на уязвимости и тестирование на проникновение. Это поможет понять реальную отказоустойчивость и защищенность предоставляемых ресурсов. Согласовать такие тестирования достаточно сложно. Поэтому выбор поставщика облачных услуг следует начать с базовых вопросов: как обеспечивается разделение данных и приложений разных клиентов, как происходит процесс аутентификации и авторизации, как выявляются инциденты безопасности, какие действия предпринимает облачный провайдер при наступлении ИБ-инцидента и т. д. Ответы на эти вопросы помогут понять, насколько серьезно провайдер подходит к вопросам обеспечения безопасности. У некоторых облачных провайдеров мониторинг инцидентов реализован как базовый механизм обеспечения ИБ и входит в стоимость предоставления ресурсов/сервисов, при этом, как правило, настроены самые базовые сценарии выявления инцидентов. Если размещаемые ресурсы действительно критичны, необходимо согласовать возможность расширенного мониторинга инцидентов ИБ в рамках дополнительной услуги с учетом специфики информационных систем и процессов компании.
Олег ИШАНОВ (Acronis):
Мониторинг, безусловно, возможен. Но далеко не для всех сервисов и клиентов такой функционал будет доступен. Необходимо проверить наличие сертификатов у провайдера, а также уточнить, когда он последний раз проходил аудит и какие выводы были сделаны по его итогам. Однако в данном вопросе очень многое зависит от реализации конкретной облачной инфраструктуры. Так, например, пользователи решений SaaS, скорее всего, будут строго ограничены методами и средствами самого сервиса, а в случае IaaS могут получить полный контроль над системами и реализовать необходимый уровень контроля и мониторинга.
Могут ли облака обеспечить степень защиты, которые предъявляют к гостайне? Если не сейчас, то в будущем?
Рустем Хайретдинов (InfoWatch):
Требования по защите государственной тайны подразумевают обработку данных в закрытом контуре. Поэтому пока, если эти требования не изменятся, обработка информации, содержащей гостайну, в облаках производиться не будет.
Дмитрий КАРТАШОВ (Orange Business Services):
Думаю, теоретически да, но в далеком будущем. Сейчас во всех документах, касающихся защиты гостайны, нет даже упоминания облачных технологий, только локальное размещение информационных систем. Когда эта возможность будет прописана в нормативных документах законодательства, обеспечить необходимый уровень защиты и конфиденциальности данных можно будет с использованием уже существующих технологий VPN c шифрованием по ГОСТ, сертифицированных ФСБ средств защиты и т. д.
Сергей Золотухин (Group—IB):
Если говорить о защите, то мы рекомендуем делать ставку на технологии выявления и предотвращения атак. Мы наблюдаем рост интереса провайдеров именно к решениям класса Threat Intelligence для защиты бизнеса и частных пользователей от широкого спектра атак, включая целевые. Данные технологии могут эффективно применяться для защиты гостайны, однако эта сфера регулируется отдельно: для нее существуют свои нормативные документы, средства защиты проходят сертификацию, информационные системы аттестуются на соответствие требованиям безопасности. Требования достаточно строгие, и я не думаю, что в обозримом будущем провайдеры смогут их выполнить. Сейчас здесь речь может идти только о частных облаках. Также нет оснований полагать, что требования к защите как-то смягчатся, в современных условиях информационной войны они скорее будут ужесточаться.
Олег ИШАНОВ (Acronis):
На сегодняшний день мне не известны случаи обработки такой информации в облаках – возможно, существуют какие-то ведомственные частные data-центры для этих целей. Тем не менее облака все активнее используются для межведомственного обмена и работы государственных организаций, оперирующих достаточно важной информацией, но к которой не применяется гриф государственной тайны. Так что в будущем никто не исключает создания облачных платформ, соответствующих даже самым строгим требованиям регулятора.
Разные типы данных требуют разной степени ИБ-обеспечения. Насколько широк список предлагаемых облачными провайдерами комплексов защитных мер для разных типов информации?
Рустем Хайретдинов (InfoWatch):
Чтобы обрабатывать разные данные по-разному, надо уметь классифицировать эти данные. Облачные провайдеры этого делать не умеют, да и не стремятся. Они предлагают своим клиентам самим определить, какая защита необходима их данным: базовая или более дорогая продвинутая. Например, доступность в продвинутой будет выше – не 99,5%, а 99,8%. Выбрав подходящий план, заказчик сам решает, какие именно данные обрабатывать и защищать согласно этому плану.
Олег ИШАНОВ (Acronis):
Да, действительно, можно защитить данные разными способами, однако провайдеры редко предлагают пользователям выбор из десятков вариаций. В основном они стараются обеспечивать некий средний уровень безопасности для своей платформы, чтобы удовлетворить потребности наибольшего количества клиентов.
Кроме того, существуют облачные сервисы, изначально соответствующие по своим требованиям определенным отраслевым стандартам PCI DSS, применяемым к финансовому сектору. Соответствие медицинским стандартам, таким как HIPAA, открывает двери для размещения карт пациентов и хранения других данных в облаке. Такой подход встречается сегодня все чаще, и клиенты выбирают не просто уровень защиты, а приобретают подписку на сервис, изначально соответствующий их бизнес-требованиям.
Екатерина СЮРТУКОВА («Инфосистемы Джет»):
В зависимости от того, какие именно информационные системы размещает компания, она может приобрести по сервисной модели и необходимые ИБ-сервисы. Например, если размещается корпоративная почта, облачные провайдеры могут обеспечить ее защиту от спама и различного рода атак, а если критичное веб-приложение – защиту от DDoS и атак на само приложение. Таким образом, у компаний появляется возможность сразу под ключ получить комплексное решение, включающее и безопасность. Являясь облачным провайдером, мы также предлагаем большой перечень услуг и сервисов по ИБ на базе нашего виртуально ЦОДа. В их числе как базовые услуги по защите инфраструктуры – антивирус, защита почты и доступа в Интернет (прокси), обнаружение и предотвращение вторжений (IPS/IDS), защита каналов связи (VPN) и т. д., так и сервисы мониторинга и выявления инцидентов ИБ Jet CSIRT. Отдельно предлагаем заказчикам сервис защиты веб-приложений от DDoS и WAF – хакерских атак, взлома и утечки информации. Состав мер и сервисов по ИБ зависит от того, какие информационные системы размещаются в облаке, как осуществляется к ним доступ, какие данные хранятся и т. д. Так как все это определяет актуальный перечь угроз и, соответственно, формирует требования к механизмам защиты. Например, подходы к обеспечению безопасности доступа будут совершенно разными, если доступ к ресурсам осуществляется через web или по выделенным каналам связи. Так же и для обеспечения защиты персональных данных: набор мер и состав сервисов ИБ будет зависеть от модели угроз и классификации ПДн (1–4 УЗ).
Дмитрий КАРТАШОВ (Orange Business Services):
Как правило, основной набор защитных мер один и тот же и уже дополняется в соответствии с требованиями того или иного стандарта, набора данных. Тем более требования многих руководящих документов и отраслевых стандартов пересекаются, поэтому городить под каждый тип обрабатываемых данных свой набор защитных мер и средств не имеет смысла.
Сергей Золотухин (Group—IB):
Современные технологии, такие как NFV – виртуализация сетевых функций, которая в основном используется операторами связи, SDN, тонкие клиенты и др., действительно позволяют пользователям самостоятельно выбрать комплекс мер защиты из наборов, предлагаемых провайдером. Так, стандартные наборы, как правило, содержат базовые сервисы типа виртуальных частных сетей (VPN), динамическую адресацию (DHCP), межсетевое экранирование, средства обнаружения и предотвращения вторжений и т. д. В свою очередь, продвинутые варианты могут включать в себя облачные средства выявления целевых атак, сложных угроз в трафике, защиту от утечек, защиту пользовательских порталов, репутационные сервисы и даже данные киберразведки. Основная проблема заключается в отсутствии у пользователей знаний о современных атаках и годами крепнувшей вере в то, что стандартный антивирус поможет избежать неприятностей. Это рождает ложное чувство защищенности. Соответственно, интерес пользователей к сервисам безопасности не столь высок, как требует ситуация, и это не позволяет провайдерам активно развивать сервисы безопасности. В итоге страдают и пользователи, не получающие надежной защиты, и сами провайдеры из-за подрыва доверия к облачным сервисам как таковым.
Уровень доверия к облачным инфраструктурам за последние годы заметно подрос – привело ли это к началу использования консервативно настроенными госорганами облаков? Есть ли какое движение в этом вопросе?
Рустем Хайретдинов (InfoWatch):
Госорганы ориентируются не на собственное мнение, а на требования регуляторов. Поэтому большинство облачных сервисов для госструктур по-прежнему недоступно. Тем не менее «Ростелеком» сейчас строит доверенное облако, против использования которого регуляторы не возражают, и некоторые сервисы из него уже доступны. Так что можно сказать, что облака уже приходят в госы.
Олег ИШАНОВ (Acronis):
Облачные технологии – это следующий этап развития после виртуализации. И если госорганы работают с виртуальными машинами, у них неизбежно возникает желание перенести часть из них в облачную среду. Проблема скорее в том, чтобы облако соответствовало их требованиям. На данный момент мы наблюдаем переход государственных структур на облачные сервисы в малозначимых для их деятельности процессах. Перевод же основной деятельности по-прежнему практически не рассматривается.
Дмитрий КАРТАШОВ (Orange Business Services):
Да, несомненно, время вносит свои коррективы. Уже сейчас многие облачные провайдеры предлагают хранить персональные данные клиентов на виртуальной платформе, и при этом обеспечивается полное соответствие требованиям действующего законодательства. Кроме того, сами регуляторы – ФСТЭК, РКН – пересмотрели свое критическое отношения к облакам и при проверках выдают положительные заключения по их использованию для хранения и обработки различных типов конфиденциальной информации: SOC, ГИС и т. д.
Сергей Золотухин (Group—IB):
В госорганах частные облака уже давно используются прежде всего для предоставления облачных сервисов населению. Эти сервисы очень высоко нагружены, требуют постоянной оптимизации и увеличения выделенных ресурсов, а также серьезной отказоустойчивости, поэтому классический подход тут использовать нельзя. Как показал опыт эксплуатации порталов оказания госуслуг в электронном виде, сегодня фокус обеспечения безопасности облаков смещается. Вопросы защиты внутренней облачной инфраструктуры решаются достаточно эффективно, а вот сам организационный процесс разработки/обновлений, равно как и защита простых пользователей порталов госуслуг, не обеспечиваются на должном уровне. Например, это показал прошлогодний инцидент с вредоносным кодом на портале госуслуг. На наш взгляд, развитие безопасности облачных порталов будет идти в направлении защиты самого слабого звена – пользователя: будут развиваться средства выявления признаков атак на стороне пользователей порталов, сотрудников ведомств, разработчиков и т. д.
Какие проблемы законодательства мешают развитию облачных сервисов?
Рустем Хайретдинов (InfoWatch):
Пока нет реальной судебной практики по разрешению споров о компенсации ущерба от инцидентов между провайдерами и их клиентами. Провайдеры не берут на себя ответственность, сравнимую с потерями клиентов, а ограничиваются рамками SLA, которое обычно не предусматривает компенсации. Поэтому клиенты пока опасаются отдавать критичные данные в облака, если есть хоть какая-то альтернатива.
Олег ИШАНОВ (Acronis):
Любая законодательная инициатива создает для ИТ определенные проблемы, так как ограничивает возможности и заставляет искать обходные пути вместо прямых и простых. Так, многие компании решили закрыть свой бизнес в Европе, чтобы не попасть под действие санкций GDPR (General Data Protection Regulation). Как сообщают в издании TechRepublic, они просто блокируют пользователей из Евросоюза. Впрочем, подобных коллизий достаточно и в России. Например, по оценкам «Интерфакса», на реализацию «закона Яровой» нужно порядка 60 млрд рублей. И в этом контексте важно обеспечить 100%-ное хранение данных, что заставляет компании изначально рассматривать уже проверенные и зарекомендовавшие себя решения. К тому же новые законы и инициативы правительства порой могут быть трактованы двояко, и поэтому компании предпочитают не пренебрегать рисками и не уходят в облако без анализа ситуации. Напротив, появление все новых ограничений заставляет компании постоянно проверять, можно ли обрабатывать те или иные данные в облаке, а некоторые игроки просто сохраняют текущую инфраструктуру, которая соответствует требованиям всех законодательных актов, и не переходят в облако, даже если это абсолютно эффективно с экономической точки зрения.
Источник: Журнал IT-News № 06/2018