Вход Регистрация
 
Мы в социальных сетях

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

02 марта 2018

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

A A A

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

Летний Интеллектуальный Кубок NBJ 29 мая 2018г.

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