Пришла как-то к нам заявка на услуги облака. Мы прикинули в общих чертах, что от нас потребуется, и отправили в ответ список вопросов для уточнения деталей. Затем проанализировали ответы и поняли: заказчик хочет размещать в облаке персональные данные второго уровня защищенности. Отвечаем ему: «У вас второй уровень персданных, извините, можем только частное облако сделать». А он: «Знаете, а вот в компании X мне могут все и в публичном разместить».
Фото Steve Crisp, Reuters
Странные дела! Мы пошли на сайт компании X, изучили их аттестационные документы, покачали головами и поняли: открытых вопросов в размещении персданных очень много и их стоит хорошенько провентилировать. Чем мы и займемся в этом посте.
Как все должно работать
Для начала разберемся, по каким признакам персональные данные вообще относят к тому или иному уровню защищенности. Это зависит от категории данных, от количества субъектов этих данных, которые хранит и обрабатывает оператор, а также от типа актуальных угроз.
Определение типов актуальных угроз приведено в постановлении Правительства РФ №1119 от 1 ноября 2012 г. «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»:
«Угрозы 1-го типа актуальны для информационной системы, если для нее в том числе актуальны угрозы, связанные с наличием недокументированных (недекларированных) возможностей в системном программном обеспечении, используемом в информационной системе.
Угрозы 2-го типа актуальны для информационной системы, если для нее в том числе актуальны угрозы, связанные с наличием недокументированных (недекларированных) возможностей в прикладном программном обеспечении, используемом в информационной системе.
Угрозы 3-го типа актуальны для информационной системы, если для нее актуальны угрозы, не связанные с наличием недокументированных (недекларированных) возможностей в системном и прикладном программном обеспечении, используемом в информационной системе.»
Основное в этих определениях — наличие недокументированных (недекларированных) возможностей. Для подтверждения отсутствия недокументированных возможностей ПО (в случае с облаком это гипервизор) проводится сертификация ФСТЭК России. Если оператор ПДн принимает, что таких возможностей в ПО нет, то и соответствующие угрозы неактуальны. Угрозы 1-го и 2-го типов операторы ПДн крайне редко принимают актуальными.
Помимо определения уровня защищенности ПДн оператор должен также определить конкретные актуальные угрозы для публичного облака и, исходя из выявленного уровня защищенности ПДн и актуальных угроз, определить необходимые меры и средства защиты от них.
У ФСТЭК все основные угрозы четко перечислены в БДУ (банке данных угроз). Провайдеры и аттестаторы облачных инфраструктур в работе используют эту базу. Вот примеры угроз:
УБИ.44: «Угроза заключается в возможности нарушения безопасности пользовательских данных программ, функционирующих внутри виртуальной машины, вредоносным программным обеспечением, функционирующим вне виртуальной машины». Данная угроза обусловлена наличием уязвимостей программного обеспечения гипервизора, обеспечивающего изолированность адресного пространства, используемого для хранения пользовательских данных программ, функционирующих внутри виртуальной машины, от несанкционированного доступа со стороны вредоносного программного обеспечения, функционирующего вне виртуальной машины.
Реализация данной угрозы возможна при условии успешного преодоления вредоносным программным кодом границ виртуальной машины не только за счёт эксплуатации уязвимостей гипервизора, но и путем осуществления такого воздействия с более низких (по отношению к гипервизору) уровней функционирования системы».
УБИ.101: «Угроза заключается в возможности осуществления несанкционированного доступа к защищаемой информации одного потребителя облачных услуг со стороны другого. Данная угроза обусловлена тем, что из-за особенностей облачных технологий потребителям облачных услуг приходится совместно использовать одну и ту же облачную инфраструктуру. Реализация данной угрозы возможна в случае допущения ошибок при разделении элементов облачной инфраструктуры между потребителями облачных услуг, а также при изоляции их ресурсов и обособлении данных друг от друга».
Защититься от этих угроз можно только с помощью гипервизора, поскольку именно он управляет виртуальными ресурсами. Таким образом, гипервизор необходимо рассматривать как средство защиты.
И в соответствии с приказом ФСТЭК №21 от 18 февраля 2013 г., гипервизор должен пройти сертификацию на отсутствие НДВ по 4 уровню, иначе использование персональных данных 1 и 2 уровня с ним будет незаконно («п.12. … Для обеспечения 1 и 2 уровней защищенности персональных данных, а также для обеспечения 3 уровня защищенности персональных данных в информационных системах, для которых к актуальным отнесены угрозы 2-го типа, применяются средства защиты информации, программное обеспечение которых прошло проверку не ниже чем по 4 уровню контроля отсутствия недекларированных возможностей»).
Нужным уровнем сертификации, НДВ-4, обладает только один гипервизор, российской разработки — Горизонт ВС. Мягко говоря, не самое популярное решение. Коммерческие облака, как правило, строятся на базе VMware vSphere, KVM, Microsoft Hyper-V. Ни один из этих продуктов не имеет сертификации на НДВ-4. Почему? Вероятно, получение такой сертификации для производителей пока экономически не оправдано.
И остается нам для персданных 1 и 2 уровня в публичном облаке лишь Горизонт ВС. Sad but true.
Как все (на наш взгляд) работает на самом деле
На первый взгляд, все достаточно строго: указанные угрозы должны устраняться правильной настройкой штатных механизмов защиты гипервизора, сертифицированного по НДВ-4. Но есть одна лазейка. В соответствии с Приказом ФСТЭК №21 («п.2 Безопасность персональных данных при их обработке в информационной системе персональных данных (далее — информационная система) обеспечивает оператор или лицо, осуществляющее обработку персональных данных по поручению оператора в соответствии с законодательством Российской Федерации»), провайдеры самостоятельно оценивают актуальность возможных угроз и в соответствии с этим выбирают меры защиты. Поэтому, если не принять актуальными угрозы УБИ.44 и УБИ.101, то не возникнет и потребности использовать сертифицированный по НДВ-4 гипервизор, который как раз и должен обеспечивать защиту от них. И этого будет достаточно для получения аттестата соответствия публичного облака 1 и 2 уровням защищенности ПДн, которым будет вполне удовлетворен Роскомнадзор.
Конечно, помимо Роскомнадзора с проверкой может прийти ФСТЭК — и эта организация куда более дотошна в технических вопросах. Ее наверняка заинтересует, почему именно угрозы УБИ.44 и УБИ.101 были признаны неактуальными? Но обычно ФСТЭК предпринимает проверку только когда получает информацию о каком-то ярком инциденте. В этом случае федеральная служба сначала приходит к оператору персданных — то есть заказчику облачных услуг. В худшем случае, оператор получает небольшой штраф — например, для Twitter в начале года штраф в похожем случае составил 5000 рублей. Затем ФСТЭК идет дальше, к провайдеру облачных услуг. Которого вполне может лишить лицензии из-за невыполнения нормативных требований — а это уже совсем другие риски, как для облачного провайдера, так и для его клиентов. Но, повторяюсь, для проверки ФСТЭК обычно нужен четкий повод. Так что облачные провайдеры готовы идти на риск. До первого серьезного инцидента.
Есть еще группа «более ответственных» провайдеров, которые считают, что можно закрыть все угрозы, дополнив гипервизор надстройкой типа vGate. Но в распределенной между заказчиками виртуальной среде для некоторых угроз (например, приведенной выше УБИ.101) действенный механизм защиты можно реализовать только на уровне сертифицированного по НДВ-4 гипервизора, поскольку любые системы-надстройки на штатные функции работы гипервизора по управлению ресурсами (в частности, оперативной памятью) не влияют.
Как работаем мы
У нас есть облачный сегмент, реализованный на гипервизоре, сертифицированном ФСТЭК (но без сертификации на НДВ-4). Этот сегмент аттестован, так что в облаке на его основе можно размещать персональные данные 3 и 4 уровней защищенности — требования по защите от недекларированных возможностей здесь соблюдать не нужно. Вот, кстати, архитектура нашего защищенного сегмента облака:
Системы для персональных данных 1 и 2 уровней защищенности мы реализуем только на выделенном оборудовании. Лишь в этом случае, например, угроза УБИ.101 действительно не актуальна, поскольку серверные стойки, не объединенные одной виртуальной средой, не могут влиять друг на друга даже при размещении в одном ЦОД. Для таких случаев мы предлагаем услугу аренды выделенного оборудования (ее еще называют Hardware as a service, оборудование как сервис).
Если же вы не уверены, какой уровень защищенности требуется для вашей системы персональных данных, мы также помогаем в их классификации.
Вывод
Наше небольшое исследование рынка показало: некоторые облачные операторы для получения заказа вполне готовы рискнуть и безопасностью данных клиентов, и собственным будущим. Но мы в этих вопросах придерживаемся иной политики, которую вкратце описали чуть выше. Будем рады ответить в комментариях на ваши вопросы.
Автор: Ашот Даниелян
