Вход Регистрация
 

Аналитика и комментарии

02 марта 2018

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

Став постоянным автором журнала 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

5. http://accord.ru/accord3264k.html

6. http://accord.ru/segment-v.html

Всего проголосовало: 0

0.0

текст Светлана Конявская, к.ф.н., заместитель генерального директора ОКБ САПР

Комментировать могут только зарегистрированные пользователи

Мы в сетевых сообществах: 

Голосование

Чем вы считаете биткоин?

Загрузка результатов голосования. Пожалуйста подождите...
Все голосования

Календарь мероприятий

Май, 2018
««
«
Сегодня
»
»»
Пн Вт Ср Чт Пт Сб Вс
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31
Ближайшие мероприятия

Видео

Весенний Интеллектуальный Кубок 2018 года

Весенний Интеллектуальный кубок 2018 года прошел в трех номинациях "Самый интеллектуальный банк", "Самая интеллектуальная компания в финансовом секторе" и "Самая интеллектуальная компания в сфере...

Яндекс.Метрика