поиск по сайту
Инновации в традиционных решениях для ЦОДов

Инновации в традиционных решениях для ЦОДов

Конявская С. В.

Став постоянным автором журнала НБЖ, я, конечно, обращаю внимание на то, как формулируются темы в тематическом плане на год, и в первую очередь, как они меняются. Если еще недавно риторика поставщиков, имманентная тематике ЦОДов, вращалась вокруг тезиса о том, насколько уникальными должны быть предназначенные для них решения, а риторика эксплуатирующих организаций – насколько можно доверять незрелым решениям, то сегодня мы уже видим в тематическом плане «Инновации в традиционных решениях для ЦОДов». Это очень хорошо, поскольку говорит о том, что работа с ЦОДами теряет налет романтики, а наши решения становятся традиционными, и даже нуждающимися, возможно, в инновациях.

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

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

Применение отдельных инструментов является обоснованной мерой, а не разведением «зоопарка» в двух случаях.

  1. Необходимость использовать что-то конкретное. Например, в организации используются определенные карты СКУД и есть желание использовать их же как единый персональный идентификатор сотрудника еще и для входа в информационную систему [1].
  2. Отсутствие нужного инструмента среди функций уже имеющихся в системе средств защиты. Например, некоторые средства защиты систем виртуализации не включают в себя средств доверенной загрузки для ESXi-серверов, и их надо выбирать и приобретать отдельно. А ни в одном из известных решений сегодня не предусмотрено инструментария для контроля вычислительной среды на компьютерах, с которых пользователи работают с виртуальными машинами (ВМ), эта задача должна решаться отдельно, о ее важности и возможных решениях мы не раз писали в своих статьях [2, 3 и др.], предлагая различные варианты решения. Однако, если первый пример относится к особенностям решения того или иного разработчика, то второй имеет объективную природу – клиентские устройства являются внешними по отношению к виртуальной инфраструктуре.

Но есть еще один компонент, оказывающий крайне существенное влияние на функционирование виртуальной инфраструктуры (речь пойдет о виртуализации VMware), являясь по отношению к ней внешним. Это АРМ управления vCenter – АРМ администратора виртуальной инфраструктуры (АРМ АВИ). Люди довольно редко работают непосредственно на vCenter, даже если он представляет собой физическую, а не виртуальную машину. Поэтому в системе возникает внешний управляющий элемент. Элемент, который системой (в том числе и системой защиты от НСД) не контролируется, но оказывает на нее управляющее воздействие.

В нашем средстве защиты виртуализации VMware – «Аккорд-В.» [4] – задача разграничения доступа к средствам управления ВИ решена на уровне предоставления или запрета доступа к средствам управления, при этом наличие средств разграничения доступа «Аккорд» [5] на АРМ АВИ необходимо контролировать орг.мерами.

Из желания детализировать эту функциональность и перейти от организационного подхода к техническому и вырос другой наш продукт – «Сегмент-В.» [6], для которого vCenter является внутренним элементом по отношению к ВИ, а АРМ АВИ внешним, и через который проходят все запросы к vCenter c любого АРМ АВИ.

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

СПИСОК ЛИТЕРАТУРЫ:

  1. Конявская С. В. Интеграция СЗИ, СКУД и видеонаблюдения, или кто отвечает за костюм? // Национальный банковский журнал. М., 2015. № 12. С. 74.
  2. Мозолина Н. В. С каких клиентов подключаться к VDI: вопрос, на который уже есть ответ // Information Security/Информационная безопасность. М., 2017. № 3. С. 39.
  3. Конявская С. В. Клиентские компьютеры для работы с виртуальным и облачными инфраструктурами: новые российские разработки // Connect №4, 2017. С. 112–113.
  4. ПАК Аккорд-В.
  5. ПАК Аккорд-Win32 К и ПАК Аккорд-Win64 К
  6. ПАК «СЕГМЕНТ-В.»