Аналитика и комментарии
Инновации в традиционных решениях для ЦОДов
Став постоянным автором журнала NBJ, я, конечно, обращаю внимание на то, как формулируются темы в тематическом плане на год, и в первую очередь, как они меняются. Если еще недавно риторика поставщиков, имманентная тематике ЦОДов, вращалась вокруг тезиса о том, насколько уникальными должны быть предназначенные для них решения, а риторика эксплуатирующих организаций – насколько можно доверять незрелым решениям, то сегодня мы уже видим в тематическом плане «Инновации в традиционных решениях для ЦОДов». Это очень хорошо, поскольку говорит о том, что работа с ЦОДами теряет налет романтики, а наши решения становятся традиционными и, возможно, даже нуждающимися в инновациях.
Следствием того, что ЦОДы перестают быть новой технологией, становится переход от поиска «решения для ЦОДа» к решению конкретных задач. Эту тенденцию мы наблюдаем в наших повседневных работах с заказчиками. Это тоже очень хорошо, потому что прагматический подход к защите точно эффективнее романтического. Следующий этап, которого мы с нетерпением ждем, должен быть шагом на новый виток спирали, вроде бы обратно к «ЦОДам под ключ», но уже через проектирование (а где нужно – перепроектирование) систем сразу с учетом всех необходимых свойств и задач. Мы к этому этапу готовы.
Вместе с тем, поддерживая стремление комплектовать систему так, как требуют задачи владельца, а не так, как придумал разработчик, мы построили свои решения таким образом, чтобы их можно было комбинировать в том числе и с решениями других разработчиков, что сегодня тоже является заметным трендом.
Применение отдельных инструментов является обоснованной мерой, а не разведением «зоопарка» в двух случаях.
1. Необходимость использовать что-то конкретное. Например, в организации используются определенные карты системы контроля и управления доступом (СКУД) и есть желание использовать их же как единый персональный идентификатор сотрудника еще и для входа в информационную систему [1].
2. Отсутствие нужного инструмента среди функций уже имеющихся в системе средств защиты. Например, некоторые средства защиты систем виртуализации не включают в себя средств доверенной загрузки для ESXi-серверов, и их надо выбирать и приобретать отдельно. А ни в одном из известных решений сегодня не предусмотрено инструментария для контроля вычислительной среды на компьютерах, с которых пользователи работают с виртуальными машинами (ВМ), эта задача должна решаться отдельно, о ее важности и возможных решениях мы не раз писали в своих статьях [2, 3 и др.], предлагая различные варианты. Однако если первый пример относится к особенностям решения того или иного разработчика, то второй имеет объективную природу – клиентские устройства являются внешними по отношению к виртуальной инфраструктуре.
Но есть еще один компонент, оказывающий крайне существенное влияние на функционирование виртуальной инфраструктуры (речь пойдет о виртуализации VMware), являясь по отношению к ней внешним. Это автоматизированное рабочее место (АРМ) управления vCenter – АРМ администратора виртуальной инфраструктуры (АРМ АВИ). Люди довольно
редко работают непосредственно на vCenter, даже если он представляет собой физическую, а не виртуальную машину. Поэтому в системе возникает внешний управляющий элемент. Это элемент, который системой (в том числе и системой защиты от несанкционированного доступа) не контролируется, но оказывает на нее управляющее воздействие.
В нашем средстве защиты виртуализации VMware – «Аккорд-В.» [4] – задача разграничения доступа к средствам управления виртуальной инфраструктуры (ВИ) решена на уровне предоставления или запрета доступа к средствам управления, при этом наличие средств разграничения доступа «Аккорд» [5] на АРМ АВИ необходимо контролировать оргмерами.
Из желания детализировать эту функциональность и перейти от организационного подхода к техническому и вырос другой наш продукт – «Сегмент-В.» [6], для которого vCenter является внутренним элементом по отношению к ВИ, а АРМ АВИ – внешним и через который проходят все запросы к vCenter c любого АРМ АВИ.
Важно, что «Сегмент-В.» – это не часть «Аккорд-В.», и, даже если по какой-то причине получилось так, что в системе уже установлено другое средство контроля запуска виртуальных машин, установить и использовать в ней «Сегмент-В.» возможно и целесообразно.
СПИСОК ЛИТЕРАТУРЫ:
1. Конявская С. В. Интеграция СЗИ, СКУД и видеонаблюдения, или кто отвечает за костюм? // Национальный банковский журнал. М., 2015. No 12. С. 74.
2. Мозолина Н. В. С каких клиентов подключаться к VDI: вопрос, на который уже есть ответ // Information Security / Информационная безопасность. М., 2017. No 3. С. 39.
3. Конявская С. В. Клиентские компьютеры для работы с виртуальными и облачными инфраструктурами: новые российские разработки // Connect No 4, 2017. С. 112-113.
4. http://accord.ru/accord-v.html