[Виртуализация, Облачные вычисления] Лицом к разработчикам: модернизировать частное облако
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Сложно ли создать виртуальную машину (ВМ) в облаке? Не сложнее, чем заварить чай. Но когда речь идет о большой корпорации, то даже такое простое действие может оказаться мучительно долгим. Мало создать виртуалку, нужно еще по всем регламентам получить необходимые доступы для работы. Знакомая боль каждого разработчика? В одном крупном банке эта процедура занимала от нескольких часов до нескольких дней. А поскольку подобных операций в месяц было сотни, легко представить масштабы этой поглощающей трудозатраты схемы. Чтобы покончить с этим, мы модернизировали частное облако банка и автоматизировали не только процесс создания ВМ, но и смежные операции.
Задача №1. Облако с подключением к Интернету
Частное облако банк создал силами внутренней ИТ-команды для отдельно взятого сегмента сети. Со временем руководство оценило его пользу и было решено распространить концепцию частного облака на другие среды и сегменты банка. Для этого понадобилось больше специалистов и крепкая экспертиза по частным облакам. Поэтому модернизацию облака доверили нашей команде.
Основным стримом этого проекта стало создание виртуальных машин в дополнительном сегменте информационной безопасности — в демилитаризованной зоне (DMZ). Именно здесь сервисы банка интегрируются с внешними системами, находящимися за пределами банковской инфраструктуры.
Но у этой медали была и обратная сторона. Сервисы из DMZ были доступны «снаружи» и это влекло за собой целый набор рисков ИБ. В первую очередь, это угроза взлома систем, последующее расширение поля атаки в DMZ, а затем и проникновение в инфраструктуру банка. Чтобы минимизировать часть этих рисков, мы предложили использовать дополнительное средство защиты — решение по микросегментации.
Защита микросегментацией
Классическая сегментация выстраивает защищенные рубежи на границах сетей при помощи межсетевого экрана. При микросегментации каждую отдельную ВМ можно выделить в персональный изолированный сегмент.
Это усиливает безопасность всей системы. Даже если злоумышленники взломают один сервер DMZ, распространить атаку по сети им будет крайне сложно — внутри сети им предстоит проломить множество «запертых дверей». Персональный межсетевой экран каждой ВМ содержит свои правила в ее отношении, которые определяют право на вход и выход. Микросегментацию мы обеспечили с помощью VMware NSX-T Distributed Firewall. Этот продукт централизованно создает правила межсетевого экранирования для ВМ и распространяет их по инфраструктуре виртуализации. Не важно какая гостевая ОС используется, правило применяется на уровне подключения виртуалок к сети.
Задача N2. В поисках скорости и удобства
Развернуть виртуалку? Легко! Пара кликов и готово. Но дальше возникает множество вопросов: как получить доступ с этой ВМ к другой или системе? Или из другой системы обратно к ВМ?
Например, в банке после заказа ВМ на облачном портале нужно было открыть портал техподдержки и завести заявку на предоставление необходимых доступов. Ошибка в заявке оборачивалась звонками и перепиской для исправления ситуации. При этом у ВМ может быть 10-15-20 доступов и отработка каждого занимала время. Дьявольский процесс.
Кроме того, отдельной заботы требовала «уборка» следов жизнедеятельности удаленных виртуалок. После их удаления на межсетевом экране оставались тысячи правил доступа, нагружая оборудование. Это и лишняя нагрузка, и дыры в безопасности.
Поступать так с правилами в облаке нельзя. Это неудобно и небезопасно.
Задача №2. В поисках скорости и удобства
Чтобы свести к минимуму сроки предоставления доступов к ВМ и сделать удобным управление ими, мы разработали услугу управления сетевым доступом для ВМ.
Пользователь на уровне виртуалки в контекстном меню выбирает пункт для создания правила доступа, а после в открывшейся форме указывает параметры — откуда, куда, типы протоколов, номера портов. После заполнения и отправки формы автоматически создаются необходимые заявки в системе технической поддержки пользователей на базе HP Service Manager. Они поступают ответственным за согласование того или иного доступа и, если доступы одобрены, — специалистам, которые выполняют часть операций, пока не автоматизированных.
После того как стадия бизнес-процесса с вовлечением специалистов отработала, начинается та часть услуги, которая автоматически создаёт правила на межсетевых экранах.
Как финальный аккорд пользователь видит на портале успешно выполненный запрос. Это значит, что правило создано и с ним можно работать — просмотреть, изменить, удалить.
Финальный счет пользы
По сути мы модернизировали небольшие аспекты работы частного облака, но банк получил заметный эффект. Пользователи теперь получают сетевые доступы только через портал, не имея напрямую дело с Service Desk. Обязательные поля формы, их валидация на корректность вводимых данных, преднастроенные списки, дополнительные данные — все это помогает сформировать точный запрос на доступ, который с высокой долей вероятности будет рассмотрен и не завернут сотрудниками ИБ из-за ошибок ввода. Виртуалки перестали быть черными ящиками — с ними можно работать дальше, внося изменения на портале.
В итоге сегодня ИТ-специалисты банка имеют в своем распоряжении более удобный инструмент для получения доступов, а в процесс вовлечены только те люди, без которых пока точно не обойтись. В сумме по трудозатратам это освобождение от ежедневной полной загрузки как минимум 1 человека, а также десятки сэкономленных часов для пользователей. Автоматизация создания правил сделала возможным внедрить решение по микросегментации, которое не создает нагрузки на сотрудников банка.
И наконец «правило доступа» стало учётной единицей облака. То есть сейчас облако хранит информацию о правилах для всех ВМ и подчищает их при удалении виртуалок.
Скоро плюсы модернизации распространились и на все облако банка. Автоматизация процесса создания ВМ и микросегментация шагнули за пределы DMZ и захватили остальные сегменты. А это повысило безопасность облака в целом.
Реализованное решение интересно еще и тем, что оно позволяет банку ускорить процессы разработки, приближая его по этому критерию к модели ИТ-компаний. Ведь когда речь идет о мобильных приложениях, порталах, клиентские сервисах, любая крупная компания сегодня стремится стать «фабрикой» по выпуску цифровых продуктов. В этом смысле банки практически играют наравне с сильнейшими ИТ-компаниями, не отставая в создании новых приложений. И хорошо, когда возможности ИТ-инфраструктуры, построенной по модели частного облака, позволяют выделить необходимые для этого ресурсы за несколько минут и максимально безопасно.
Авторы:
Вячеслав Медведев, начальник отдела облачных вычислений «Инфосистемы Джет»,
Илья Куйкин, ведущий инженер отдела облачных вычислений «Инфосистемы Джет»
===========
Источник:
habr.com
===========
Похожие новости:
- [Open source, Виртуализация, Visual Studio, C, Разработка под Windows] Вторая жизнь Virtual Floppy Drive
- [Виртуализация, Разработка на Raspberry Pi, Гаджеты] Гипервизор Xen портировали на Raspberry Pi 4
- [Виртуализация, Серверная оптимизация, Серверное администрирование] Как победить фиолетовый экран смерти VMware?
- [IT-инфраструктура, Виртуализация, Kubernetes] VMware представит vSphere 7 U1 с Kubernetes
- [Open source, Интернет вещей, Облачные сервисы, Разработка для интернета вещей] Знакомство с Node-RED и потоковое программирование в Yandex IoT Core
- [Тестирование IT-систем, Виртуализация, Разработка под Linux] Автоматизация системных тестов на базе QEMU (Часть 2/2)
- [Open source, Openshift, Виртуализация, Учебный процесс в IT] Шпаргалка по Ansible k8s, практичный учебник по awk, а также 4 причины использовать Jamstack при веб-разработке
- [Виртуализация, DevOps, Облачные сервисы, Kubernetes] Пять промахов при развертывании первого приложения на Kubernetes (перевод)
- [Визуализация данных, Конференции, Облачные вычисления, Облачные сервисы] Yandex Scale 2020: обсуждаем главные запуски и события в прямом эфире
- [Тестирование IT-систем, Виртуализация, Разработка под Linux] Автоматизация системных тестов на базе QEMU (Часть 1/2)
Теги для поиска: #_virtualizatsija (Виртуализация), #_oblachnye_vychislenija (Облачные вычисления), #_oblako (облако), #_virtualnye_mashiny (виртуальные машины), #_blog_kompanii_infosistemy_dzhet (
Блог компании Инфосистемы Джет
), #_virtualizatsija (
Виртуализация
), #_oblachnye_vychislenija (
Облачные вычисления
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 25-Ноя 19:54
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Сложно ли создать виртуальную машину (ВМ) в облаке? Не сложнее, чем заварить чай. Но когда речь идет о большой корпорации, то даже такое простое действие может оказаться мучительно долгим. Мало создать виртуалку, нужно еще по всем регламентам получить необходимые доступы для работы. Знакомая боль каждого разработчика? В одном крупном банке эта процедура занимала от нескольких часов до нескольких дней. А поскольку подобных операций в месяц было сотни, легко представить масштабы этой поглощающей трудозатраты схемы. Чтобы покончить с этим, мы модернизировали частное облако банка и автоматизировали не только процесс создания ВМ, но и смежные операции.  Задача №1. Облако с подключением к Интернету Частное облако банк создал силами внутренней ИТ-команды для отдельно взятого сегмента сети. Со временем руководство оценило его пользу и было решено распространить концепцию частного облака на другие среды и сегменты банка. Для этого понадобилось больше специалистов и крепкая экспертиза по частным облакам. Поэтому модернизацию облака доверили нашей команде. Основным стримом этого проекта стало создание виртуальных машин в дополнительном сегменте информационной безопасности — в демилитаризованной зоне (DMZ). Именно здесь сервисы банка интегрируются с внешними системами, находящимися за пределами банковской инфраструктуры. Но у этой медали была и обратная сторона. Сервисы из DMZ были доступны «снаружи» и это влекло за собой целый набор рисков ИБ. В первую очередь, это угроза взлома систем, последующее расширение поля атаки в DMZ, а затем и проникновение в инфраструктуру банка. Чтобы минимизировать часть этих рисков, мы предложили использовать дополнительное средство защиты — решение по микросегментации. Защита микросегментацией Классическая сегментация выстраивает защищенные рубежи на границах сетей при помощи межсетевого экрана. При микросегментации каждую отдельную ВМ можно выделить в персональный изолированный сегмент.  Это усиливает безопасность всей системы. Даже если злоумышленники взломают один сервер DMZ, распространить атаку по сети им будет крайне сложно — внутри сети им предстоит проломить множество «запертых дверей». Персональный межсетевой экран каждой ВМ содержит свои правила в ее отношении, которые определяют право на вход и выход. Микросегментацию мы обеспечили с помощью VMware NSX-T Distributed Firewall. Этот продукт централизованно создает правила межсетевого экранирования для ВМ и распространяет их по инфраструктуре виртуализации. Не важно какая гостевая ОС используется, правило применяется на уровне подключения виртуалок к сети. Задача N2. В поисках скорости и удобства Развернуть виртуалку? Легко! Пара кликов и готово. Но дальше возникает множество вопросов: как получить доступ с этой ВМ к другой или системе? Или из другой системы обратно к ВМ? Например, в банке после заказа ВМ на облачном портале нужно было открыть портал техподдержки и завести заявку на предоставление необходимых доступов. Ошибка в заявке оборачивалась звонками и перепиской для исправления ситуации. При этом у ВМ может быть 10-15-20 доступов и отработка каждого занимала время. Дьявольский процесс. Кроме того, отдельной заботы требовала «уборка» следов жизнедеятельности удаленных виртуалок. После их удаления на межсетевом экране оставались тысячи правил доступа, нагружая оборудование. Это и лишняя нагрузка, и дыры в безопасности. Поступать так с правилами в облаке нельзя. Это неудобно и небезопасно. Задача №2. В поисках скорости и удобства Чтобы свести к минимуму сроки предоставления доступов к ВМ и сделать удобным управление ими, мы разработали услугу управления сетевым доступом для ВМ. Пользователь на уровне виртуалки в контекстном меню выбирает пункт для создания правила доступа, а после в открывшейся форме указывает параметры — откуда, куда, типы протоколов, номера портов. После заполнения и отправки формы автоматически создаются необходимые заявки в системе технической поддержки пользователей на базе HP Service Manager. Они поступают ответственным за согласование того или иного доступа и, если доступы одобрены, — специалистам, которые выполняют часть операций, пока не автоматизированных. После того как стадия бизнес-процесса с вовлечением специалистов отработала, начинается та часть услуги, которая автоматически создаёт правила на межсетевых экранах. Как финальный аккорд пользователь видит на портале успешно выполненный запрос. Это значит, что правило создано и с ним можно работать — просмотреть, изменить, удалить.  Финальный счет пользы По сути мы модернизировали небольшие аспекты работы частного облака, но банк получил заметный эффект. Пользователи теперь получают сетевые доступы только через портал, не имея напрямую дело с Service Desk. Обязательные поля формы, их валидация на корректность вводимых данных, преднастроенные списки, дополнительные данные — все это помогает сформировать точный запрос на доступ, который с высокой долей вероятности будет рассмотрен и не завернут сотрудниками ИБ из-за ошибок ввода. Виртуалки перестали быть черными ящиками — с ними можно работать дальше, внося изменения на портале. В итоге сегодня ИТ-специалисты банка имеют в своем распоряжении более удобный инструмент для получения доступов, а в процесс вовлечены только те люди, без которых пока точно не обойтись. В сумме по трудозатратам это освобождение от ежедневной полной загрузки как минимум 1 человека, а также десятки сэкономленных часов для пользователей. Автоматизация создания правил сделала возможным внедрить решение по микросегментации, которое не создает нагрузки на сотрудников банка. И наконец «правило доступа» стало учётной единицей облака. То есть сейчас облако хранит информацию о правилах для всех ВМ и подчищает их при удалении виртуалок. Скоро плюсы модернизации распространились и на все облако банка. Автоматизация процесса создания ВМ и микросегментация шагнули за пределы DMZ и захватили остальные сегменты. А это повысило безопасность облака в целом. Реализованное решение интересно еще и тем, что оно позволяет банку ускорить процессы разработки, приближая его по этому критерию к модели ИТ-компаний. Ведь когда речь идет о мобильных приложениях, порталах, клиентские сервисах, любая крупная компания сегодня стремится стать «фабрикой» по выпуску цифровых продуктов. В этом смысле банки практически играют наравне с сильнейшими ИТ-компаниями, не отставая в создании новых приложений. И хорошо, когда возможности ИТ-инфраструктуры, построенной по модели частного облака, позволяют выделить необходимые для этого ресурсы за несколько минут и максимально безопасно. Авторы: Вячеслав Медведев, начальник отдела облачных вычислений «Инфосистемы Джет», Илья Куйкин, ведущий инженер отдела облачных вычислений «Инфосистемы Джет» =========== Источник: habr.com =========== Похожие новости:
Блог компании Инфосистемы Джет ), #_virtualizatsija ( Виртуализация ), #_oblachnye_vychislenija ( Облачные вычисления ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 25-Ноя 19:54
Часовой пояс: UTC + 5