Сложно ли создать виртуальную машину (ВМ) в облаке? Не сложнее, чем заварить чай. Но когда речь идет о большой корпорации, то даже такое простое действие может оказаться мучительно долгим. Мало создать виртуалку, нужно еще по всем регламентам получить необходимые доступы для работы. Знакомая боль каждого разработчика? В одном крупном банке эта процедура занимала от нескольких часов до нескольких дней. А поскольку подобных операций в месяц было сотни, легко представить масштабы этой поглощающей трудозатраты схемы. Чтобы покончить с этим, мы модернизировали частное облако банка и автоматизировали не только процесс создания ВМ, но и смежные операции.
Частное облако банк создал силами внутренней ИТ-команды для отдельно взятого сегмента сети. Со временем руководство оценило его пользу и было решено распространить концепцию частного облака на другие среды и сегменты банка. Для этого понадобилось больше специалистов и крепкая экспертиза по частным облакам. Поэтому модернизацию облака доверили нашей команде.
Основным стримом этого проекта стало создание виртуальных машин в дополнительном сегменте информационной безопасности — в демилитаризованной зоне (DMZ). Именно здесь сервисы банка интегрируются с внешними системами, находящимися за пределами банковской инфраструктуры.
Но у этой медали была и обратная сторона. Сервисы из DMZ были доступны «снаружи» и это влекло за собой целый набор рисков ИБ. В первую очередь, это угроза взлома систем, последующее расширение поля атаки в DMZ, а затем и проникновение в инфраструктуру банка. Чтобы минимизировать часть этих рисков, мы предложили использовать дополнительное средство защиты — решение по микросегментации.
Классическая сегментация выстраивает защищенные рубежи на границах сетей при помощи межсетевого экрана. При микросегментации каждую отдельную ВМ можно выделить в персональный изолированный сегмент.
Это усиливает безопасность всей системы. Даже если злоумышленники взломают один сервер DMZ, распространить атаку по сети им будет крайне сложно — внутри сети им предстоит проломить множество «запертых дверей». Персональный межсетевой экран каждой ВМ содержит свои правила в ее отношении, которые определяют право на вход и выход. Микросегментацию мы обеспечили с помощью VMware NSX-T Distributed Firewall. Этот продукт централизованно создает правила межсетевого экранирования для ВМ и распространяет их по инфраструктуре виртуализации. Не важно какая гостевая ОС используется, правило применяется на уровне подключения виртуалок к сети.
Развернуть виртуалку? Легко! Пара кликов и готово. Но дальше возникает множество вопросов: как получить доступ с этой ВМ к другой или системе? Или из другой системы обратно к ВМ?
Например, в банке после заказа ВМ на облачном портале нужно было открыть портал техподдержки и завести заявку на предоставление необходимых доступов. Ошибка в заявке оборачивалась звонками и перепиской для исправления ситуации. При этом у ВМ может быть 10-15-20 доступов и отработка каждого занимала время. Дьявольский процесс.
Кроме того, отдельной заботы требовала «уборка» следов жизнедеятельности удаленных виртуалок. После их удаления на межсетевом экране оставались тысячи правил доступа, нагружая оборудование. Это и лишняя нагрузка, и дыры в безопасности.
Поступать так с правилами в облаке нельзя. Это неудобно и небезопасно.
Чтобы свести к минимуму сроки предоставления доступов к ВМ и сделать удобным управление ими, мы разработали услугу управления сетевым доступом для ВМ.
Пользователь на уровне виртуалки в контекстном меню выбирает пункт для создания правила доступа, а после в открывшейся форме указывает параметры — откуда, куда, типы протоколов, номера портов. После заполнения и отправки формы автоматически создаются необходимые заявки в системе технической поддержки пользователей на базе HP Service Manager. Они поступают ответственным за согласование того или иного доступа и, если доступы одобрены, — специалистам, которые выполняют часть операций, пока не автоматизированных.
После того как стадия бизнес-процесса с вовлечением специалистов отработала, начинается та часть услуги, которая автоматически создаёт правила на межсетевых экранах.
Как финальный аккорд пользователь видит на портале успешно выполненный запрос. Это значит, что правило создано и с ним можно работать — просмотреть, изменить, удалить.
По сути мы модернизировали небольшие аспекты работы частного облака, но банк получил заметный эффект. Пользователи теперь получают сетевые доступы только через портал, не имея напрямую дело с Service Desk. Обязательные поля формы, их валидация на корректность вводимых данных, преднастроенные списки, дополнительные данные — все это помогает сформировать точный запрос на доступ, который с высокой долей вероятности будет рассмотрен и не завернут сотрудниками ИБ из-за ошибок ввода. Виртуалки перестали быть черными ящиками — с ними можно работать дальше, внося изменения на портале.
В итоге сегодня ИТ-специалисты банка имеют в своем распоряжении более удобный инструмент для получения доступов, а в процесс вовлечены только те люди, без которых пока точно не обойтись. В сумме по трудозатратам это освобождение от ежедневной полной загрузки как минимум 1 человека, а также десятки сэкономленных часов для пользователей. Автоматизация создания правил сделала возможным внедрить решение по микросегментации, которое не создает нагрузки на сотрудников банка.
И наконец «правило доступа» стало учётной единицей облака. То есть сейчас облако хранит информацию о правилах для всех ВМ и подчищает их при удалении виртуалок.
Скоро плюсы модернизации распространились и на все облако банка. Автоматизация процесса создания ВМ и микросегментация шагнули за пределы DMZ и захватили остальные сегменты. А это повысило безопасность облака в целом.
Реализованное решение интересно еще и тем, что оно позволяет банку ускорить процессы разработки, приближая его по этому критерию к модели ИТ-компаний. Ведь когда речь идет о мобильных приложениях, порталах, клиентские сервисах, любая крупная компания сегодня стремится стать «фабрикой» по выпуску цифровых продуктов. В этом смысле банки практически играют наравне с сильнейшими ИТ-компаниями, не отставая в создании новых приложений. И хорошо, когда возможности ИТ-инфраструктуры, построенной по модели частного облака, позволяют выделить необходимые для этого ресурсы за несколько минут и максимально безопасно.
Авторы:
Вячеслав Медведев, начальник отдела облачных вычислений «Инфосистемы Джет»,
Илья Куйкин, ведущий инженер отдела облачных вычислений «Инфосистемы Джет»
Задача №1. Облако с подключением к Интернету
Частное облако банк создал силами внутренней ИТ-команды для отдельно взятого сегмента сети. Со временем руководство оценило его пользу и было решено распространить концепцию частного облака на другие среды и сегменты банка. Для этого понадобилось больше специалистов и крепкая экспертиза по частным облакам. Поэтому модернизацию облака доверили нашей команде.
Основным стримом этого проекта стало создание виртуальных машин в дополнительном сегменте информационной безопасности — в демилитаризованной зоне (DMZ). Именно здесь сервисы банка интегрируются с внешними системами, находящимися за пределами банковской инфраструктуры.
Но у этой медали была и обратная сторона. Сервисы из DMZ были доступны «снаружи» и это влекло за собой целый набор рисков ИБ. В первую очередь, это угроза взлома систем, последующее расширение поля атаки в DMZ, а затем и проникновение в инфраструктуру банка. Чтобы минимизировать часть этих рисков, мы предложили использовать дополнительное средство защиты — решение по микросегментации.
Защита микросегментацией
Классическая сегментация выстраивает защищенные рубежи на границах сетей при помощи межсетевого экрана. При микросегментации каждую отдельную ВМ можно выделить в персональный изолированный сегмент.
Это усиливает безопасность всей системы. Даже если злоумышленники взломают один сервер DMZ, распространить атаку по сети им будет крайне сложно — внутри сети им предстоит проломить множество «запертых дверей». Персональный межсетевой экран каждой ВМ содержит свои правила в ее отношении, которые определяют право на вход и выход. Микросегментацию мы обеспечили с помощью VMware NSX-T Distributed Firewall. Этот продукт централизованно создает правила межсетевого экранирования для ВМ и распространяет их по инфраструктуре виртуализации. Не важно какая гостевая ОС используется, правило применяется на уровне подключения виртуалок к сети.
Задача N2. В поисках скорости и удобства
Развернуть виртуалку? Легко! Пара кликов и готово. Но дальше возникает множество вопросов: как получить доступ с этой ВМ к другой или системе? Или из другой системы обратно к ВМ?
Например, в банке после заказа ВМ на облачном портале нужно было открыть портал техподдержки и завести заявку на предоставление необходимых доступов. Ошибка в заявке оборачивалась звонками и перепиской для исправления ситуации. При этом у ВМ может быть 10-15-20 доступов и отработка каждого занимала время. Дьявольский процесс.
Кроме того, отдельной заботы требовала «уборка» следов жизнедеятельности удаленных виртуалок. После их удаления на межсетевом экране оставались тысячи правил доступа, нагружая оборудование. Это и лишняя нагрузка, и дыры в безопасности.
Поступать так с правилами в облаке нельзя. Это неудобно и небезопасно.
Чтобы свести к минимуму сроки предоставления доступов к ВМ и сделать удобным управление ими, мы разработали услугу управления сетевым доступом для ВМ.
Пользователь на уровне виртуалки в контекстном меню выбирает пункт для создания правила доступа, а после в открывшейся форме указывает параметры — откуда, куда, типы протоколов, номера портов. После заполнения и отправки формы автоматически создаются необходимые заявки в системе технической поддержки пользователей на базе HP Service Manager. Они поступают ответственным за согласование того или иного доступа и, если доступы одобрены, — специалистам, которые выполняют часть операций, пока не автоматизированных.
После того как стадия бизнес-процесса с вовлечением специалистов отработала, начинается та часть услуги, которая автоматически создаёт правила на межсетевых экранах.
Как финальный аккорд пользователь видит на портале успешно выполненный запрос. Это значит, что правило создано и с ним можно работать — просмотреть, изменить, удалить.
Финальный счет пользы
По сути мы модернизировали небольшие аспекты работы частного облака, но банк получил заметный эффект. Пользователи теперь получают сетевые доступы только через портал, не имея напрямую дело с Service Desk. Обязательные поля формы, их валидация на корректность вводимых данных, преднастроенные списки, дополнительные данные — все это помогает сформировать точный запрос на доступ, который с высокой долей вероятности будет рассмотрен и не завернут сотрудниками ИБ из-за ошибок ввода. Виртуалки перестали быть черными ящиками — с ними можно работать дальше, внося изменения на портале.
В итоге сегодня ИТ-специалисты банка имеют в своем распоряжении более удобный инструмент для получения доступов, а в процесс вовлечены только те люди, без которых пока точно не обойтись. В сумме по трудозатратам это освобождение от ежедневной полной загрузки как минимум 1 человека, а также десятки сэкономленных часов для пользователей. Автоматизация создания правил сделала возможным внедрить решение по микросегментации, которое не создает нагрузки на сотрудников банка.
И наконец «правило доступа» стало учётной единицей облака. То есть сейчас облако хранит информацию о правилах для всех ВМ и подчищает их при удалении виртуалок.
Скоро плюсы модернизации распространились и на все облако банка. Автоматизация процесса создания ВМ и микросегментация шагнули за пределы DMZ и захватили остальные сегменты. А это повысило безопасность облака в целом.
Реализованное решение интересно еще и тем, что оно позволяет банку ускорить процессы разработки, приближая его по этому критерию к модели ИТ-компаний. Ведь когда речь идет о мобильных приложениях, порталах, клиентские сервисах, любая крупная компания сегодня стремится стать «фабрикой» по выпуску цифровых продуктов. В этом смысле банки практически играют наравне с сильнейшими ИТ-компаниями, не отставая в создании новых приложений. И хорошо, когда возможности ИТ-инфраструктуры, построенной по модели частного облака, позволяют выделить необходимые для этого ресурсы за несколько минут и максимально безопасно.
Авторы:
Вячеслав Медведев, начальник отдела облачных вычислений «Инфосистемы Джет»,
Илья Куйкин, ведущий инженер отдела облачных вычислений «Инфосистемы Джет»
