Как стать автором
Обновить
171.78
MWS
Больше, чем облако

АРМ Администратора Облака для ПДн и ГИС: комплайнс, защита, удобство

Время на прочтение12 мин
Количество просмотров2.6K
Виртуальные инфраструктуры и различные облачные сервисы администрируются через консоли управления. Очевидно, что аттестованные облака в этом вопросе ничем не отличаются от обычных. В таких решениях доступ к интерфейсам управления выполняется с выделенного рабочего места, которое обычно называется АРМ Администратора. Такой АРМ создается как на стороне провайдера, так и на стороне клиента облака. С его помощью создаются виртуальные машины, настраивается сетевая инфраструктура между ними и выполняются другие административные задачи.

Очевидно, что любой АРМ Администратора находится вне облака и его требуется защищать. С одной стороны, такая защита должна соответствовать требованиям регуляторов. С другой, сегодня наши клиенты видят управление стильным, модным и молодежным гибким, мобильным и простым. Под катом я расскажу, как мы совмещаем все это в #CloudMTS.



Управление инфраструктурой аттестованного облака для ГИС и ПДн


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

Мы как провайдер управляем Облаком 152-ФЗ с АРМов, расположенных в трех локациях. Там находятся техподдержка клиентов и технические специалисты #CloudMTS. Локации этих АРМов указываются в аттестате, в нашем случае это Москва, Нижний Новгород и Новосибирск. Очевидно, что клиент управлять своей частью облака должен со своего АРМ Администратора.
При этом варианты управления облаком могут в значительной мере отличаться. На наш взгляд, можно выделить три таких способа.

Делегирование доступа

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

Традиционный подход

Значительная часть клиентов работает по достаточно традиционной схеме: создаются ВМ, настраиваются правила сетевого доступа, задачи резервного копирования и выполняются другие подобные действия. Затем эти ВМ живут достаточно статично, так же, как это происходит в традиционной инфраструктуре. При этом непосредственно АРМ Администратора используется нечасто. Во все остальное время он остается незадействованным, и клиент считает его ненужным простаивающим. С другой стороны, у клиента может случиться форс-мажор и возникнуть внезапная потребность внести изменения в инфраструктуру. И тут с долго незадействованным АРМ Администратора могут возникнуть проблемы. Поэтому при таком подходе важно время от времени проверять работоспособность АРМа.

Управление посредством API

Ряд клиентов нетрадиционного подхода сегодня начинают автоматизировать задачи администрирования, например, посредством API. VMware и многие другие вендоры предлагают такие возможности. Подобный режим работы предполагает более активное взаимодействие с интерфейсами управления и требует постоянного подключения к ним… В этом случае стандартные действия по развертыванию ВМ, их включению и выключению, задачи бэкапа и прочие действия выполняются не администраторам вручную, а через скрипты, исполненные со стороны автоматизированной консоли АРМ Администратора. Такие решения часто применяются при использовании систем работы с контейнерами или при работе с Lambda и serverless-архитектурой.

Очевидно, что такой современный подход полностью конфликтует с традиционным, где АРМ Администратора задействуется от случая к случаю, инфраструктура создается единожды, живет достаточно статично, а изменения вносятся редко. Соответственно, управление через API может потребовать других СЗИ на АРМ Администратора.

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

Необходимые и достаточные СЗИ для АРМ Администратора


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



Рассмотрим подробно АРМ Администратора — внимание на пункты 6, 7 и 11, 12. Очевидно, средства защиты АРМ, как и сами рабочие места, лежат уже за пределами облака. Их можно поделить на два типа в соответствии с описанием нормативных требований (о самих требованиях мы поговорим ниже):

  • комплексное сертифицированное средство защиты АРМ Администратора;
  • сертифицированное криптографическое средство защиты каналов передачи данных.

Сам по себе АРМ Администратора — достаточно простое решение. Де-факто это компьютер, установленный в контролируемом помещении, доступ к которому регламентирован с точки зрения политик безопасности компании. С этого рабочего места осуществляется доступ к консолям управления. В традиционном подходе, описанном выше, для всех действий достаточно браузера, логина и пароля.

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

Автоматизированным рабочим местом администратора, вписанным в аттестат облака, занимается провайдер. Однако обеспечить защиту АРМ Администратора в локации клиента и за пределами облака провайдер не может. Построить и защитить свой АРМ клиент должен самостоятельно. Безусловно, провайдер должен обеспечить клиенту все необходимые условия для управления облаком, поэтому заказчик получает все, что ему потребуется для решения этой задачи.

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

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

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


Так как наше облако предназначено для работы с ПДн и ГИС, при проектировании АРМ Администратора мы учитываем требования 17 и 21 приказов ФСТЭК. Соответственно, задачу построения АРМ Администратора мы решаем, исходя из положений этих нормативных документов.

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

21 приказом ФСТЭК определены состав и содержание мер по обеспечению безопасности персональных данных. В них входят:

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

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

Средства защиты от несанкционированного доступа


Как мы уже говорили выше, одно из основных средств защиты, которые клиент должен рассмотреть на АРМ Администратора — это СЗИ от НСД, то есть различные программные и программно-аппаратные продукты для защиты от несанкционированного доступа.

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

Среди основных игроков рынка сертифицированных СЗИ от НСД можно выделить:

  • СЗИ от НСД Secret Net, Secret Net Studio и ПАК «Соболь» («Код Безопасности»)
  • СЗИ от НСД Dallas Lock (компания «Конфидент»)
  • СЗИ от НСД «Аккорд» (компания ОКБ САПР)
  • СЗИ от НСД «Блокхост-сеть К» и «Блокхост-АМДЗ» («Газинформсервис»)

Практически вся палитра средств представлена в этом обзоре.

По типу исполнения СЗИ от НСД бывают программными и программно-аппаратными. К последним относятся комплексы, где помимо специального программного обеспечения для разграничения доступа к ресурсам в составе комплекса есть аппаратный модуль — средство доверенной загрузки.

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

Среди наших клиентов бытует мнение, что отечественные регуляторы навязывают использование таких средств защиты, однако это не совсем верная точка зрения. Подобные решения от НСД есть и за рубежом. Да, там нет привычного для нас рынка СЗИ от НСД, и такие решения носят другое название. Для защиты информации на удаленных АРМ Администратора применяются решения классов Information-Centric Endpoint Protection и Endpoint Protection Platforms. Gartner определяет класс решений Information-Centric Endpoint Protection как решения, обеспечивающие защиту конфиденциальной информации на конечных точках на уровне данных и системы. Эта категория включает решения с различными механизмами защиты — управление правами пользователей, контроль подключаемых устройств, контроль целостности информации и доверенная загрузка, шифрование данных.

Средство защиты каналов передачи данных: VPN-клиент


Вернемся к минимально необходимому средству защиты, без которого клиент не сможет подключиться к интерфейсу управления — VPN-клиент. С его помощью обеспечивается защита каналов передачи данных от АРМ Администратора до интерфейсов управления. В своем облаке мы используем сертифицированное криптографическое решение для защиты каналов передачи данных — С-Терра Клиент. Его же и предоставляем нашим клиентам в рамках сервисного контракта.

VPN-клиент С-Терра поставляется в рамках сервиса IaaS 152-ФЗ преднастроенным, то есть в формате готового программного пакета с включенным в его состав ключевым материалом. Получив от нас собранный дистрибутив, клиент облака должен установить его на своем АРМ Администратора. Установка VPN-клиента требует административных полномочий и должна выполняться администратором клиента.

Как я сказал выше, в традиционном подходе АРМ Администратора может использоваться редко (исключительно для периодического выполнения административных задач), а вот в случае с управлением по API наоборот предполагается интенсивное взаимодействие с консолями управления.

Увы, иногда пользователи облака относятся к задаче построения АРМа формально: один раз построил, все настроил и забыл. Поэтому на рабочих местах администраторов встречаются такие «артефакты», как устаревшие ОС или сторонний софт, конфликтующий с VPN-клиентом. Нередко из-за этого могут возникнуть трудности при эксплуатации решения — например, когда необходимо срочно подключиться к консолям управления и что-то исправить или изменить.
В традиционном подходе клиент выполняет задачи управления с помощью vCloud Director. Компании, которые автоматизируют решение административных задач с помощью скриптов, обращаются к нему по API. Соответственно, АРМ Администратора должен поддерживать работу с этими скриптами. В ряде случаев такие скрипты запускаются не на Windows-платформе, поэтому некоторым клиентам требуются решения под Linux.

Конечно, сегодня большинство компаний используют ОС Windows, поэтому мы традиционно предоставляем VPN-клиент для Windows. Если компании по требованиям импортозамещения уходят от Windows и используют различные Linux-решения, мы готовы предложить им С-Терра Клиент А для Astra Linux. Как правило, он востребован у тех, кто по каким-то причинам не может использовать Windows, и вместо этого работает на Astra Linux.

К сожалению, VPN-клиент С-Терра есть не для всех версий Linux из доступных на рынке, так как сертифицикация продукта под каждую ОС — сложная и затратная для вендора задача. Однако, на наш взгляд, список поддерживаемых ОС широк и в него укладывается большинство клиентов. Сегодня мы используем две актуальных версии VPN-клиента С-Терра — 4.2 и 4.3. Использование версии 4.2 с действующими сертификатами ФСБ до 15.11.2022 дают возможность поддержать Windows 7 (x32, x64), которая устарела и не поддерживается до сих пор популярна у ряда наших клиентов. Для остальных случаев мы предлагаем С-Терра Клиент 4.3, который поддерживает все актуальные ОС Windows. Версии 4.2 и 4.3 совместимы между собой. Со слов техподдержки С-Терра, недавно была успешно протестирована техническая совместимость версии 4.3 с Windows 11 и Windows Server 2022, и в обозримом будущем это добавится в формуляр.

Список поддерживаемых ОС:


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

Альтернативы VPN-клиента


Некоторые наши клиенты готовы пойти на компромиссы и хотели бы организовать АРМ Администратора с использованием нестандартных для этого сценария ОС: например, MacOS или Android. Увы, решить задачу сертифицированного СКЗИ при всем этом зоопарке разнообразии попросту не представляется возможным.

Но с недавнего времени выход из этой ситуации есть — использовать аппаратный VPN-клиент.



Это компактный гаджет программно-аппаратный комплекс (ПАК), который ничем не уступает по функционалу стандартному VPN-клиенту. Он осуществляет защиту и фильтрацию трафика и предназначен для тех случаев, когда ОС или платформа в целом не позволяют установить VPN-клиент.

Работает С-Терра Юнит на платформе архитектуры MIPS, разработанных на базе процессора MediaTek MT7620 (32 бита) под управлением адаптированной ОС OpenWRT. На устройстве доступны интерфейсы LAN (помечен белым) и WAN (помечен красным) типа 100Base-T, встроен Wi-Fi (802.11 b/g/n). Также С-Терра Юнит оснащен USB-интерфейсами (USB-A и microUSB 2.0) для питания от внешнего источника и подключения внешних устройств, например, USB-модемов 3G / 4G.

Некоторые наши заказчики не готовы рассматривать VPN-клиенты в виде ПАКов из-за проблематичности работы с ними. На наш взгляд, С-Терра Юнит — исключение из этих правил. И я хочу рассказать почему.



С-Терра Юнит представляет из себя небольшую коробочку размером 80 х 45 х 22 мм и считается самым маленьким криптошлюзом из всех представленных на российском рынке. Производительность решения — до 10 Мбит/с, чего более чем достаточно для доступа к консолям управления и взаимодействия с ними. На С-Терра Юнит установлено OpenWRT, благодаря чему настройка устройства достаточно проста и логична.

В жизни он выглядит так:



При этом гаджет С-Терра Юнит имеет сертификаты ФСБ на СКЗИ КС1, КС2 — это полноценное сертифицированное решение для криптографической защиты информации. И на подходе, со слов вендора, сертификат КС3. Оно также сертифицировано ФСТЭК по требованиям типа «А» класса 4 для межсетевых экранов и 4-го уровня доверия и внесено в реестр российских программ для ЭВМ. С-Терра Юнит добавлен Единый в реестр российских программ для ЭВМ и баз данных на основании Приказа Минкомсвязи №272 от 09.06.2020, а также внесен в реестр Минпромторга (Единый реестр российской радиоэлектронной продукции).

Все знают, что «угон» административных учеток — серьезная боль для администраторов, ИТ- и ИБ-менеджеров. Для тех клиентов, кто боится утратить доступ с потерей С-Терра Юнит, мы можем порекомендовать использовать токены для дополнительной защиты ключевого материала. Работает С-Терра Юнит с Рутокен Lite, Рутокен ЭЦП/ЭЦП 2.0, Рутокен ЭЦП Flash, Рутокен 2151, а также USB-накопителями в качестве ключевых носителей.

С-Терра Юнит удобно использовать в различных мобильных сценариях, включая те случаи, когда интернет не всегда доступен. ПАК имеет 2 Ethernet-интерфейса, может подключаться по Wi-Fi, а также совместим с 4G модемами HUAWEI E3372 и ZTE MF833T. При этом есть возможность реализовать отказоустойчивость с работой через двух независимых провайдеров, как показано на картинке.



Настройка выполняется с помощью веб-интерфейса — процесс не сложнее, чем в случае с обычным домашним роутером.


В удаленных сценариях всегда что-то может пойти не так, поэтому крайне важна возможность диагностики состояния устройства. Хотя у С-Терра Юнит нет экрана, зато есть несколько индикаторов. Различная цветовая индикация обозначает то или иное состояние от момента загрузки до успешного создания защищенного VPN-соединения.



С-Терра Юнит позволяет получить функциональность, эквивалентную VPN-клиенту, о котором я рассказывал выше, и полное соответствие необходимым нормативным требованиям. А возможность подключения 4G/3G-модема позволяет решить проблему подключения к интернету практически из любой локации.

На наш взгляд, если у вас нет возможности рассматривать классические VPN-клиенты, С-Терра Юнит — подходящая альтернатива. Приобрести само устройство можно непосредственно у вендора или его партнеров. В рамках этой статьи мы описали только основное, если вы решили выбрать С-Терра Юнит, рекомендуем ознакомиться с полным обзором решения здесь.

Мы рассмотрели комплексный подход к защите при построении АРМ Администратора. Если вы клиент облака 152-ФЗ или аналогичных аттестованных сервисов, надеемся, что наш опыт окажется полезен и позволит организовать АРМ Администратора в любых условиях, а использование VPN-клиента не станет для вас непреодолимой задачей благодаря описанным нами максимально гибких подходам. Предлагаю в комментариях поделиться вашим опытом создания АРМ Администратора.

Теги:
Хабы:
Всего голосов 3: ↑2 и ↓1+2
Комментарии0

Публикации

Информация

Сайт
mws.ru
Дата регистрации
Дата основания
Численность
501–1 000 человек
Местоположение
Россия