Анализ ГОСТ «Требования по защите информации, обрабатываемой с использованием технологии облачных вычислений»

В настоящий момент подготовлен проект ГОСТ «Требования по защите информации, обрабатываемой с использованием технологии облачных вычислений», пока стандарт не введен в эксплуатацию, но его уже можно использовать в качестве источника информации при планировании защищенной облачной инфраструктуры.

Каковы цели и назначения данного ГОСТ?

В первой и второй главе предоставлена информация о назначении данного ГОСТ, основные тезисы:

●   стандартизация требований по технической защите информации от несанкционированного доступа в облачной инфраструктуре;

●   стандарт не претендует на полноту и авторами ГОСТ рекомендуется использовать другие стандарты и требования, также приводятся ссылки на стандарты, которые использовались при разработке текущего ГОСТ.

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

Определения относительно облачных услуг довольно информативные и дают основное представление о терминологии «облаков». Представлен полный перечень видов облачных услуг (SaaS, PaaS, IaaS, DaaS и прочие), рассмотрены модели облачного размещения (частное облако, публично облако, гибридное облако). Но тут тоже можно высказать некоторые замечания.

Что такое «частное облако»?

Наибольший интерес представляет определение частного облака. В соответствии с ГОСТ, частное облако – это «модель облачного владения, в которой поставщик облачных услуг и все потребители облачных услуг принадлежат одной организации». Хотя на самом деле это является лишь одним из вариантов создания частного облака, в практике же, частное облако может предоставляться и сторонней организацией (провайдером или интегратором) – см. статью Гибридные облака среднему и малому бизнесу.

Какие требования к архитектуре облака предъявляет данный ГОСТ?

Состав и структура информационных систем, построенных с использованием технологий «облачных вычислений» (ИСОТ) представлена в виде схемы.

В состав ИСОТ могут входить следующие элементы:

1.     со стороны потребителей облачных услуг:

●   рабочие станции пользователей;

●   облачные периферийные устройства;

●   сетевое оборудование;

2.     со стороны поставщиков облачных услуг:

●   пограничный сервер;

●   функциональные сервера;

●   сетевое оборудование;

●   хранилища данных.

Что требуется защищать в соответствии с ГОСТ?

Объекты для защиты можно разделить на три основные группы:

Оборудование и платформа

●   физические и виртуальные устройства обработки данных (аппаратное обеспечение, виртуальные машины, облачные клиенты)  

●   системы обработки информации, их компоненты (вычислительные сети, системы и сети репликации; системы резервного копирования; узлы, на которых функционируют: ПО управления облачным сервером, ПО, осуществляющее сетевое взаимодействие по протоколу http, ПО гипервизоров; узлы, арендуемые потребителями облачных услуг);

●   системное и прикладное ПО, сетевые службы;

●   объекты файловой системы виртуальных и физических дисков, данные на машинных носителях информации;

●   средства защиты информации (средства аутентификации, антивирусные средства, средства обеспечения функционирования облачной инфраструктуры);

Каналы и потоки

●   каналы передачи данных, сетевые потоки (информационные потоки между компонентами инфраструктуры, сегментами ИСОТ, между различными ИСОТ при межоблачном взаимодействии, сетевые соединения (сеансы связи), маршруты передачи сетевых пакетов);

●   служебная информация виртуального и физического сетевого оборудования;

●   процессы и потоки, запущенные в оперативной памяти;

Информация и данные

●   конфиденциальная информацию везде, где она располагается: на носителях, при передачи по каналам связи и т.д.

●   служебная информация физических и виртуальных устройств обработки и передачи данных (временные файлы, временные данные, создаваемые в процессе миграции виртуальных машин, по её завершении, в процессе сеанса связи облачного клиента с облачным сервером, сетевые адреса, сетевые имена);

●   микропрограммное обеспечение виртуальных и физических устройств обработки данных сетевого оборудования;

●   служебная информация системного и прикладного ПО;

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

●   базы данных, структурные элементы баз данных (учётные записи и идентификаторы пользователей, аутентификационная информация субъектов доступа, базы данных признаков вредоносных компьютерных программ (вирусов), базы решающих правил средств защиты информации);

●   служебная информация средств защиты информации (обязанности, полномочия (роли) субъектов доступа, параметры аутентификационной информации субъектов доступа, методы, типы и правила разграничения доступа, число параллельных сеансов доступа для каждой учётной записи пользователей облачной инфраструктуры, состав и содержание информации о событиях безопасности, подлежащих регистрации, журналы регистрации событий безопасности, конфигурационные файлы, ключи системного реестра, записи баз данных).

Опять-таки, в ГОСТ не указано, с помощью каких средств производить защиту. Вероятно, подразумевается необходимость использовать соответствующие ФЗ для защиты той или иной информации.

Какие угрозы безопасности выделяются согласно ГОСТ?

Раздел 5.2 ГОСТ целиком посвящен угрозам безопасности. Угрозы безопасности разделены на 2 подраздела:

●   угрозы безопасности информации для потребителей облачных услуг

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

Что угрожает пользователям облаков

Организационные риски:

●   Неопределенность ответственности – опасность возникает в случае если между провайдером и потребителем отсутствует четкое разделение ответственности по обеспечению безопасности инфраструктуры

●   Привязанность к определенному провайдеру – это возникает, если провайдер применяет не стандартное ПО, данные и ВМ не могут быть экспортированы и перенесены на другой сервис

Технические риски:

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

●   Отсутствие защищенного доступа – как следствие повышается угроза атак типа «человек по середине», либо опасность «фишинга»

●   Недостаток управления информацией/облачными ресурсами – выражается в том, что в связи с распределенностью облачной инфраструктуры, данные пользователей могут передаваться зарубежным резидентами (трансграничная передача), что может повлечь за собой определенные правовые нарушения в связи с действующим законодательством.

Злоупотребление и недобросовестность:

●   Потеря доверия – технологии применяемые провайдером скрыты от пользователя, потребитель не может дать оценку реализованной на стороне провайдера защищенной среды

●   Потеря и уточки данных – является прямым следствием 6го пункта, в связи с недостатками управления защитой, средствами аутентификации, ключами шифрования велик риск их компрометации и потери.

Угрозы безопасности поставщика услуг

Организационные риски:

●   Распределенная ответственность – отсутствие четкого распределения ответственности затрудняет обеспечение безопасности облачной инфраструктуры

●   Конфликт юрисдикций различных стран – в трансграничной передаче информации конфиденциального характера может быть отказано в соответствии с требованиями соответствующих нормативных правовых актов.

●   Некачественный перенос инфраструктуры в облако – перенос инфраструктуры в облако требует серьезного пересмотра политики безопасности, также есть опасность выявления различных несовместимостей на уровне ПО и оборудования.

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

Технические риски:

●   Несогласованность политик безопасности – в следствие децентрализованной облачной инфраструктуры, политики безопасности элементов инфраструктуры могут отличаться, к примеру одно средство зашиты может закрыть доступ к определенному элементу инфраструктуры, а другое наоборот может предоставить доступ.

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

●   Приостановка оказания услуг в следствие технических сбоев – к данной угрозе относятся любые сбои на уровне канала связи, выход из строя оборудования? Что может повлечь временную либо полную недоступность облачного сервиса конечному потребителю.

●   Невозможность миграции ВМ из-за несовместимости оборудования или ПО – различные поставщики облачных сервисов в процессе предоставления услуг могут использовать различное аппаратное и программному обеспечение, что в итоге может привести к невозможности переноса облачной инфраструктуры на хостинг другого провайдера

●   Незащищенное администрирование облачных услуг – в случае отсутствия зашиты панели управления облачными услугами, реквизиты доступа могут быть перехвачены злоумышленниками.

●   Общедоступность инфраструктуры - Так как пользователи облачных услуг (в том числе конкурирующие между собой) делят одну и ту же инфраструктуру, то возникают угрозы нарушения конфиденциальности или целостности данных путём осуществления прямого доступа к защищаемым данным пользователей

●   Использование технологий виртуализации, которые в свою очередь предполагают определенные риски. (см. Обзор ГОСТ Р 56938-2016 «Защита информации при использовании технологий виртуализации».

●   Нарушение доступности облачного сервиса – в соответствии с сервис-ориентированным подходом, реализуемым в облаках, в случае нарушения доступности облачной инфраструктуры будет прекращено оказание облачных услуг всем потребителям.

Злоупотребление и недобросовестность:

●   Недобросовестность поставщиков облачных услуг – прежде всего не правильное хранение реквизитов пользователей (в открытом виде)

●   Злоупотребление со стороны поставщика облачных услуг – прежде всего связано с действиями инсайдеров

●   Злоупотребление со стороны пользователя облачных услуг – пользователь может установить на предоставленный ресурс вредоносное ПО, которое сможет влиять в целом на облачный сервис.

Какие способы по защите информации в облаке предполагает ГОСТ?

Шестой раздел ГОСТ полностью посвящен вопросам обеспечения безопасности различных видов облачных услуг, причем требования предъявляются именно к владелицу облака. Требования представлены для каждого типа услуг, в том числе для самых экзотических TaaS (доверие как сервис), NaaS (подключение как сервис) и TraaaS (прозрачность как сервис).

Для каждой услуги приведено описание угроз безопасности, характерные для конкретной услуги (так же раздельно для владельца облака и пользователя) и меры по защите информации с расстановкой по разделам, напоминающим 21 и 17 приказы ФСТЭК.  Требования практически полностью дублируются для видов облачных услуг и большая часть требований идентична требованиям ГОСТ по защите виртуализации, поскольку облачная инфраструктура реализуется за счет технологии виртуализации.

Ожидалось увидеть таблицу соответствия мер защит к угрозам, однако все представлено списками. Потребуется ручная доработка для удобства анализа угроз и дальнейшего использования.

В чем недостатки ГОСТа?

Хотелось бы заострить внимание на двух моментах:

1.     В данном ГОСТ не представлены требования к средствам защиты, в том числе не представлены ссылки на соответствующие документы, в которых такая информация присутствует.

2.     Если сопоставить ГОСТ по защите виртуализации и ГОСТ по защите облаков, то складывается впечатление, что оба стандарта составлялись независимо друг от друга одинаковые понятия описаны по-разному, глоссарий отличается, что в перспективе может породить путаницу при использовании обоих документов.   

Данный ГОСТ, как и указано в первой части не является универсальным, поэтому для построения защиты потребуется прибегать к большому числу сопутствующих материалов. Кроме того, имеются определенные разночтения с практическим применением облаков (например, определение частного облака)

Как можно использовать данный ГОСТ?

ГОСТ собрал довольно большой объём информации по обеспечению безопасности облачных услуг, что в первую очередь порадует облачных провайдеров и вендоров облачных услуг – можно брать и использовать.

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

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