Жизнь ГИС в облаке: не говорите сразу «нет»

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

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

image-loader.svg

Публичные облака и возможность их применения для ГИС


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

Большая часть аттестованных IaaS-сервисов из предлагаемых на рынке, — это облака для работы с ПДн. Такие решения IaaS обладают аттестатом или оценкой соответствия. Однако требования для работы с ПДн и ГИС при общей схожести имеют существенные отличия. Если сервис IaaS аттестован для ГИС, вполне возможно, он имеет аттестацию для работы с ПДн. Но обратное, как правило, неверно.

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

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

Конечно, такое «уникальное» решение будет соответствовать необходимым требованиям, и вопросов с его защищенностью и прохождением процедуры аттестации ИС не возникнет. Но вот его эксплуатация вряд ли обойдется без трудностей и дополнительных затрат.

  • Во-первых, сложности начнутся с миграции. Просто так «заехать» в облако не получится. Если раньше вы работали на VMware или Hyper-V и решили перенести существующие ВМ в другую среду виртуализации типа специального KVM, для оптимальной работы существующие ВМ фактически придется пересобрать. Это может потребовать экспертизы технических специалистов и, как правило, отнимет немало времени и других ресурсов. Владельцам текущих конфигураций будет очень жаль, что унаследовать преднастроенные ВМ в большинстве случаев не получится.
  • Во-вторых, вы можете столкнуться с нехваткой экспертизы. Если ваши технические специалисты раньше использовали распространенные платформы виртуализации, «пересадка» на другую консоль управления и другие интерфейсы потребует получения новой экспертизы. Есть и иной путь — найти новых сотрудников с компетенциями в выбранном нетиповом решении. Однако любой из этих вариантов грозит лишними расходами и потерей времени.
  • Из первых двух сложностей следует третья — вендорлок. Когда вы работаете в виртуальной среде типа VMware, вы привыкаете использовать типовые решения наподобие NSX Edge, понимаете, как построена сетевая связность между вашими ВМ, очевидны используемые вами решения для бэкапа, например, Veeam (большинство провайдеров используют такой бэкап как сервис в рамках своих облаков). Совокупность этих и подобных им сервисных решений представляет собой некую экосистему, в которой ваши коллеги и компания в целом привыкли работать. С одной стороны, это привычно и удобно, с другой, это можно назвать вендорлоком. Вендорлок — это по сути ваша привычка работы в экосистеме. А как мы знаем, привычка вторая натура смена экосистемы почти всегда болезненна и некомфортна. Поскольку VMware сегодня де-факто является отраслевым стандартом, этого вендорлока вы не чувствуете. Например, вы без труда можете переехать от одного провайдера к другому — облака на базе VMware есть у всех. Однако при миграции с VMware на другую платформу виртуализации с привычной экосистемой придется попрощаться. И вы фактически поменяете один вендорлок (понятный, с привычными «плюшками») на другой (новый и специфичный). Вендорлок таит проблемы не только на входе. Он может создать неприятности в самый неожиданный момент. Когда вы можете перестраивать свои ВМ, связи между ними, делать новые настройки бэкапа или пытаться уйти с одной системы на другую. Если в будущем вам придется мигрировать снова на VMware, вы будете вынуждены еще раз пережить этот процесс миграции со сменой платформы.
  • К тому же, если вы используете сервисы сразу нескольких облачных провайдеров в составе мультиоблака, построение бесшовной информационной системы будет затруднено из-за различий между системами виртуализации и вышеупомянутого вендорлока.


Есть альтернатива — найти провайдера, облако которого подходит для размещения ГИС и построено на базе типовых решений, к которым привык клиент.

Такое облако, как и множество публичных, построено на решениях VMware. У него будут все необходимые документы (аттестат по требованиям ГИС, выписка из модели угроз, разделение зон ответственности и пр). Работать с таким решением будет не сложнее, чем с обычным неаттестованным публичным облаком.

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

Как устроено наше облако для ГИС


Как я уже сказал, к IaaS для размещения ГИС предъявляются более строгие требования, чем к облакам для ПДн. В частности, все используемые в решении средства защиты информации обязательно должны быть сертифицированы. Процедура аттестации здесь более строга, чем аттестация для работы с ПДн. Размещение ИС с реальными данными, а затем ее оценка эффективности — вариант неприемлемый. Процедуру аттестации необходимо пройти до ввода в эксплуатацию и наполнения данными. Ее проводит аттестатор, компания-лицензиат ФСТЭК с правом на проведение аттестационных испытаний.

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

Отмечу ряд особенностей аттестации на соответствие 17 приказу:

  • Конкретизирован перечень исходных данных, предоставляемых при аттестационных испытаниях: ОРД, проектная и эксплуатационная документация, ТЗ на СЗИ, результаты анализа уязвимостей, материалы предварительных и приемочных испытаний (аттестационные испытания могут быть совмещены с проведением приемочных испытаний).
  • Определены особенности аттестации ИС на основе результатов аттестационных испытаний выделенного набора ее сегментов, а также условия и порядок распространения аттестата соответствия на другие сегменты ИС.
  • Аттестат соответствия выдается на весь срок эксплуатации ИС. Ответственность за поддержание соответствия системы защиты информации возлагается на оператора (владельца) ИС.
  • Проведение аттестационных испытаний ИС работниками, осуществляющими проектирование и (или) внедрение СЗИ, не допускается.
  • Анализ уязвимостей информационной системы, в том числе вызванных неправильной настройкой ПО и СЗИ.
  • Испытания СЗИ путем осуществления попыток НСД к ИС в обход ее СЗИ
  • При аттестации ИС используются результаты аттестации общей инфраструктуры оператора ИС.
  • Периодичность проведения контроля за обеспечением уровня защищенности информации для ГИС класса К1 — не реже 1 раза в год, для ГИС классов К2 и К3 — не реже 1 раза в два года.


У всех облачных провайдеров есть свои особенности. Я хочу далее кратко пояснить, как устроено облако для ГИС на примере сервиса #CloudMTS, с которым я непосредственно работаю.

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

image-loader.svg

1. Межсетевой экран и средство обнаружения вторжений на границе сети Сегмента ИС.
2. Сертифицированный криптографический шлюз.
3. Средство защиты платформ виртуализации VMware на различных уровнях инфраструктуры:

  • на уровне сети управления (3а),
  • на уровне ESXi-хостов (3 б),
  • на уровне объектов доступа в среде виртуализации (3в).


4. Средства управления СЗИ на сервере управления подсистемой информационной безопасности.
5. Средство анализа защищенности на базе сканера уязвимостей.

и средства защиты в сегменте удаленного управления, размещаемые за пределами ЦОД:

6. Комплексное средство защиты АРМ администраторов инфраструктуры и безопасности.
7. Криптографическое средство защиты канала передачи данных.

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

В составе облачной ИС клиента должны быть представлены средства защиты информации:

8. Межсетевой экран и средство обнаружения вторжений на границе виртуальной сети.
9. Средство антивирусной защиты для виртуальных машин.
10. Средство защиты от несанкционированного доступа для виртуальных машин.

За пределами Сегмента ИС во внешних по отношению к облаку #CloudМТS сегментах инфраструктуры клиента представлены следующие дополнительные средства защиты информации:
11. Сертифицированный криптографический шлюз во внешних сегментах ИС на площадке клиента Облака.
12. Комплексное средство защиты АРМ пользователей ИС, размещаемых в рамках ЛВС клиента Облака.

За пределами Сегмента ИС клиента во внешних по отношению к облаку #CloudМТS сетях (в том числе, в сетях общего пользования, в сети интернет — за пределами контролируемых сегментов клиента облака), представлены следующие дополнительные средства защиты информации:
13. Комплексное средство защиты АРМ мобильных пользователей, размещаемых за пределами ЛВС клиента Облака.
14. Сертифицированное криптографическое средство защиты канала передачи данных мобильных пользователей, размещаемых за пределами ЛВС клиента Облака.
15. Средство защиты для мобильных устройств (смартфоны, планшеты) пользователей, размещаемых за пределами ЛВС клиента Облака.

Отдельно стоит сказать про отказоустойчивость. Этот вопрос со стороны клиентов облака при размещении ГИС стоит намного острее, нежели в случае с обычным IaaS. Часто предъявляются требования повышенной отказоустойчивости или даже катастрофоустойчивости. Поэтому сервис #CloudMTS построен на базе нескольких площадок, аттестованных по требованиям работы с ПДн и ГИС (УЗ-1, К1), связанных между собой site-to-site VPN-туннелем на базе сертифицированных криптошлюзов. Отказоустойчивость каналов также соблюдена. Благодаря такой связности площадок возможно построение DRaaS, перекрестные бэкапы и миграция.

Тяжело в учении на бумаге, легко в бою


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

Медицинская платформа, подключенная к ГИС, в облаке #CloudMTS


Петербургская ИТ-компания «Нетрика Медицина», разрабатывающая и интегрирующая решения для государственного и частного здравоохранения, искала облачную площадку для размещения N3.Health. Благодаря этой платформе частные клиники могут интегрироваться с системой ЕГИСЗ МЗ РФ (Единая государственная информационная система в сфере здравоохранения) и обмениваться с ней данными.

Для размещения N3.Health требовалась инфраструктура с высоким уровнем и классом защищенности (УЗ-2 и К2). Несмотря на наличие экспертизы в построении ЦОД, на этапе проверки гипотезы создание собственной площадки показалось заказчику нецелесообразным. В итоге компания решила найти провайдера с облаком для УЗ-2 и К2.

Очевидно, что на этом этапе возникли сложности. Подходящие ЦОД либо не предоставлялись в аренду, либо не подходили из-за низкой производительности. Также «Нетрика Медицина» планировала аттестовать собственную ИС, поэтому сервисы IaaS, не имеющие соответствующего аттестата, не подходили.

По итогам знакомства с компанией и ее требованиями к облаку мы предоставили ИТ-специалистам «Нетрики Медицины» пробный период. После успешного тест-драйва виртуальных ресурсов проект N3.Health развернули в облаке #CloudMTS.

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

Технические специалисты компании клиента были изначально хорошо знакомы с архитектурой VMware, консолями управления, BaaS-решениями. Все они в нашем случае типовые, поэтому клиент построил свою ИС на базе нашего IaaS без привлечения специалистов из команды #CloudMTS или консалтеров со стороны.

Не бизнесом единым


Очевидно, что коммерческие клиенты активно используют облака. А готовы ли к этому госучреждения? Мы видим, что прогрессивные государственные компании и ведомства начинают все чаще смотреть в сторону услуг IaaS-провайдеров. Например, в прошлом году к нам «переехали» ИТ-системы МФЦ Ростова-на-Дону.

Заказчик искал облако для ГИС, где можно было бы разместить свою информационную систему, поэтому нуждался в ресурсах, аттестованных по требованиям К2 и УЗ-2. Решение #CloudMTS полностью соответствовало этим требованиям, поэтому по результатам конкурсной процедуры заказчик выбрал нас.

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

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

image-loader.svg

© Habrahabr.ru