Как выбрать облачного провайдера, соответствующего требованиям применимых стандартов, разделить зоны ответственности и составить однозначное ТЗ, мы рассказывали в предыдущих постах.

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

Стандартизация в облаках

Сначала маленькое, но важное уточнение про внутренние и невидимые клиентам процессы облака. 

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

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

• Однотипность оборудования также позволяет и планировать его обслуживание, и иметь склад гарантированно подходящих запчастей (или даже подменных серверов). Это положительно влияет на время доступности облака.

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

• В стандартах управления информационной безопасностью, таких как ISO 27001, Cloud security alliance или ГОСТ Р 57580.1-2017 есть требование о разработке стандартов документации и регламентировании деятельности. Это еще одна причина, заставляющая провайдеров делать экземпляры своих сервисов как можно более похожими друг на друга, а в идеале – идентичными.

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

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

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

Провайдер имеет возможность оказывать  и нестандартные услуги с помощью создания частного облака. Частное облако – это облако, собранное на отдельном наборе оборудования (серверов, СХД, сетевого оборудования), и полностью отделенное от общего облака. Оно отдельно управляется и может отвечать каким-то иным, относительно стандартного облака, требованиям: как в части безопасности, так и в части применяемых ИТ-решений. Естественно, такое облако получается дороже, чем стандартное, а процесс его создания занимает некоторое время.

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

Сложные сценарии ИБ в облаках

Логи административного доступа

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

В случае с системами, размещаемыми в облаке – это достаточно сложный и многокомпонентный запрос:

1. Часть логов безопасности создается на уровне самих ВМ и ОС клиента и выше, и с ними проблем нет: уровень ОС (в IaaS) доступен клиенту. Он может использовать любой механизм сбора и обработки таких логов.

2. Часть действий клиента происходит в интерфейсе портала управления облаком: вход администраторов; создание, удаление, запуск и остановка виртуальных машин; подключение виртуальных дисков и настройка виртуальных сетей.

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

3. Часть действий над системами, обслуживающими ресурсы клиента, происходит со стороны собственных сотрудников и собственной инфраструктуры облачного провайдера: это обслуживание оборудования, устранение мелких или крупных неисправностей, обновление и прочие регламентные работы в инфраструктуре облака, а также работы по заявкам клиентов облака.

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

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

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

Отказоустойчивость и катастрофоустойчивость

Облачная инфраструктура в базе обеспечивает достаточно хорошую отказоустойчивость на уровне оборудования: облака построены с заранее заложенной аппаратной избыточностью: возможность выключения какой-то доли физических узлов просто закладывается в проект облака. Как следствие, если выключение какого-то количества физических узлов действительно происходит, то клиент обычно этого даже не видит. Функции мониторинга состояния виртуальных машин в современных гипервизорах реализованы достаточно хорошо, что позволяет настроить, например, автоматическую перезагрузку зависших виртуальных машин.

Такая отказоустойчивость облака уже настолько вошла в привычку, что клиенты не всегда задумываются о том, что вся отказоустойчивость облака предоставляется только на уровне ВМ и ниже. А от сбоев ОС или ПО на сервере облако защитить не может: повышать надежность работы, например, сервера приложений нужно его  кластеризацией.  

Эта сложность особенно ярко проявляется при запросе на катастрофоустойчивость:

Катастрофоустойчивость в облаке может быть реализована как минимум двумя способами:

1. Построение метрокластера – единого кластера виртуализации, распределенного между несколькими территориями.

   При этом способе между территориями синхронизируются состояния виртуальных машин. При выходе из строя одной территории – та же ВМ автоматически запускается на другой территории.  

   Таким образом, для способа характерны следующие особенности:

   • Необходимость в технически сложной синхронизации данных ВМ. Причем как хранимых на диске ВМ данных, так и данных о состоянии ВМ (упрощенно – данных из оперативной памяти ВМ).

   • Единая, распределенная между двумя территориями сетевая подсистема: на другой территории заработает та же самая ВМ с теми же самыми IP-адресами, и взаимодействующая с внешним миром через те же протоколы и сокеты.

   • Реализация мониторинга состояния на уровне физического оборудования облака и состояния ВМ. То есть уровень ОС и тем более ПО – не может отслеживаться. И если в супернадежной ВМ вдруг зависнет, например, сервер приложений – то никакого переключения на другую территорию не случится: основная территория и ВМ же живы.

2. Настройка нескольких раздельных пулов ресурсов (по пулу на каждой территории) и реализация катастрофоустойчивости на уровне приложений. Фактически – создание двойного набора ВМ (по набору на каждой территории) и настройка кластеризации между ВМ между территории.

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

Если провайдер гарантирует соответствие облака каким-либо требованиям по безопасности в облаке, то область соответствия (облако) должна быть ограничена и отделена от всех прочих сетей (интернета, провайдерских сетей, и т.д.) межсетевыми экранами.

При построении метрокластера – провайдер должен сделать единый сетевой периметр на второй территории. И, что самое сложное – обеспечить защиту канала связи между территориями.

Сложность вызвана тем, что разные стандарты предъявляют разные требования к защите канала – вплоть до ГОСТ-криптографии, а сам канал, позволяющий синхронизировать состояния ВМ между территориями – это очень высокопроизводительный. Защитить такой канал с помощью ГОСТ-VPN – очень сложно и дорого. И далеко не всем клиентам нужно.

Поэтому, не все провайдеры готовы обеспечить соответствие высоким уровням (УЗ1 и УЗ2) 152-ФЗ или ГИС в метрокластере. Такую возможность, если она требуется, нужно уточнять у провайдера.

В случае же с созданием нескольких пулов ресурсов – по пулу на территорию, каналы связи между территориями также необходимо защищать, но это можно сделать на уровне, видимом одному конкретному клиенту – то есть существенно проще.

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

Особенности использования модели PAYG

Облако позволяет достаточно легко создавать и уничтожать виртуальные ресурсы. Этим удобно пользоваться, и это дает возможность создать модель оплаты по факту потребленных ресурсов – Pay As You Go (PAYG).

Модель PAYG достаточно быстро нашла своих потребителей и пользуется устойчивым спросом, особенно в сегменте e-commerce и FinTech.

С темой безопасности использование модели PAYG пресекается косвенно следующим образом:

• Модель лицензирования используемого ПО, в том числе средств защиты.

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

• Средства защиты сети. 

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

  Сертифицированные ФСТЭКом межсетевые экраны уровня границ сети – должны быть сертифицированы по профилю защиты ИТ.МЭ.А<N>.ПЗ (где N – уровень соответствия), который в явном виде требует реализации в виде аппаратного решения. Это значит, что виртуальных сертифицированных межсетевых экранов уровня границ сети просто не может существовать.

  В силу особенностей требований к алгоритму ГОСТ – абсолютное большинство ГОСТ-VPN шлюзов реализуется в виде физического оборудования. Про предоставление ГОСТ-VPN по модели PAYG я вообще не слышал.

  Провайдер вряд ли сможет предоставить оборудование по модели PAYG, т.е. клиенты, у которых есть желание получать услуги по модели PAYG и есть требования к применению сертифицированного сетевого оборудования (межсетевых экранов или ГОСТ-VPN), должны быть готовы к тому, что часть предложения провайдера будет содержать фиксированную стоимость.

• Аттестация контура, получаемого по PAYG.

  Некоторые клиенты предъявляют требования к проведению работ по аттестации системы, размещаемой в облаке, и по получению ресурсов в облаке по модели PAYG. Это требование может быть выполнено с очень существенными ограничениями по двум причинам: во-первых, для аттестации нужно множество СЗИ, лицензирование большей части которых не позволит реализовать преимущества модели PAYG. Во-вторых, процедура аттестации требует создания так называемого Паспорта системы – документа, описывающего все узлы аттестуемой системы. При изменении аттестованной системы относительно паспорта – аттестат перестает действовать. Т.е. нельзя динамически менять количество ВМ в аттестуемом контуре — провайдер должен как-то обсудить с клиентом, что после работ по аттестации, клиент может выключать временно ненужные машины, но не может их удалять или создавать новые.

• Частное облако по модели PAYG и с аттестацией.

  Ну и наконец – комбинация вышеперечисленного:

  Если клиенту по каким-то причинам требуется частное облако, то я не очень представляю, как провайдер сможет его предоставлять по модели PAYG. Но даже если провайдер придумает, как это можно сделать, то аттестовать облако, в котором динамически меняется количество ресурсов – просто не удастся.

Совмещение требований по аттестации и соответствию «продвинутым» стандартам ИБ

Аттестация, как уже было написано выше, требует неизменности системы. Под условия неизменности попадают, кроме состава узлов (серверов), еще и версии ПО и прошивок внутри аттестованной системы. Версии ОС и СЗИ должны не изменяться, либо сведения об обновлениях должны периодически вноситься в паспорт системы. Для сертифицированных СЗИ, обновления также должны проходить проверку соответствия условиям сертификации.

«Продвинутые» стандарты ИБ , включая PCI DSS, ГОСТ Р 57580.1, и, особенно ISO 27001, требуют внедрения процедур управления защищенностью, в том числе процессов контроля обновлений и уязвимостей, а также периодической установки обновлений и патчей. 

Очень тяжело одновременно поддерживать неизменность системы и установку обновлений☺.

Поэтому достаточно сложно обеспечить аттестацию какой-либо системы и ее соответствие требованиям PCI DSS, или ГОСТ Р 57580.1, или тем более ISO 27001.

Чаще всего, такое совмещение достигается созданием двух контуров безопасности, один из которых неизменен, а другой – обновляется. Что, естественно, стоит денег.

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

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

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

Требования к работам по проектированию безопасности должны отталкиваться от:

• Используемого технологического стека.

• Бизнес-требований к надежности.

• Применимых требований законодательных и отраслевых стандартов.

• Желаемых конкурентных преимуществ от реализации соответствия добровольным стандартам.

Кстати, если вы не уверены в том, какие стандарты и на каком уровне соответствия вам нужны – то скрининг применимых и рекомендованных требований тоже можно сделать на аутсорсе. 

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