Поделиться
Как масштабировать частное облако на весь бизнес и не навредить ИБ
Банки создают у себя облака, чтобы наладить быстрый запуск новых сервисов. Но этого оказывается недостаточно. Облачные возможности спотыкаются о сложившиеся процессы и ограничения, и чуда быстрой разработки не происходит. Иногда выход — в автоматизации процессов. Практика показывает, что в подобных случаях даже незначительная оптимизация способна дать колоссальный эффект и оказать заметное влияние на бизнес.
По данным аналитического центра НАФИ, сегодня цифровыми банковскими сервисами пользуются уже 56% россиян, тогда как в 2018 г. этот показатель не превышал 30%. Для молодого поколения цифровой банкинг вообще является определяющим фактором — веб- и мобильными приложениями пользуется 75% населения в возрасте до 24 лет. Неудивительно, что на цифровом поле среди банков развернулось настоящее сражение. Финансовые организации становятся фабриками по выпуску digital-сервисов для своих клиентов, постоянно совершенствуя мобильные и веб-приложения.
На этом пути банки являются лидерами в покорении облачных технологий. Но их использование только создает почву для получения преимуществ. Нужны дополнительные усилия, чтобы они «проросли» — например, по изменению бизнес-процессов. К счастью, часто даже небольшая оптимизация способна положительно повлиять на процесс в целом. Так было и в российском банке из топ-10, в котором при наличии частного облака выделение доступов для виртуальных машин занимало от пары часов до нескольких дней. Современным требованиям к time-to-market он не отвечал. Частное облако в банке создавалось только для одного сегмента сети, и это ограничивало сферу его применимости. Но сама практика использования приватного облака оценивалась позитивно, поэтому было решено масштабировать его на всю инфраструктуру, в том числе и на демилитаризованную зону (DMZ) с доступом в интернет. Чтобы увеличить скорость выделения ресурсов для разработки и повысить безопасность облака в целом, команда «Инфосистемы Джет» модернизировала его.
Оборона микросегментами
В DMZ-зоне банковские системы взаимодействовали с публичными сервисами. Там же разработчики создавали виртуальные машины, имеющие доступ к интернету. Риски информационной безопасности в DMZ-зоне всегда повышены. Неудивительно, что ИБ-службы строго контролируют доступ из нее к внутренним ресурсам.
«Решением этой проблемы стало внедрение распределенного межсетевого экрана VMware NSX-T. За счет встроенных средств микросегментации такой МСЭ изолировал каждую виртуальную машину в отдельную микросеть со своими правилами и политиками доступа, — рассказывает Вячеслав Медведев, начальник отдела облачных вычислений «Инфосистемы Джет». — Правила ИБ в банке распространились на всю облачную инфраструктуру, а доступы своевременно закрывались, когда пользователи отключали ВМ».
Доступы на лету
Масштабирование облака на всю инфраструктуру банка влекло за собой серьезные изменения. Главным образом банку нужно было автоматизировать процессы выделения ресурсов. До старта модернизации доступ к сетевым объектам для виртуальных машин выделялся сотрудниками техподдержки вручную. На обработку каждого запроса, которых в месяц насчитывалось несколько сотен, уходило много времени, ошибки при формировании заявок приводили к их отклонению. Разработчики жаловались на сроки и непрозрачность, а техподдержка — на высокую нагрузку.
Разорвать этот порочный круг помогла интеграция средств управления на едином портале самообслуживания и возможность пользователям самостоятельно заказывать необходимые ресурсы. Для нового сегмента DMZ удалось полностью автоматизировать процесс рассмотрения заявок. По запросу пользователя распределенный МСЭ предоставляет нужный доступ за секунды. Точно также, после завершения работы ВМ, VMware NSX-T позволяет удалить все открытые ранее порты, оставляя сеть максимально защищенной.
На основе правил внутренней службы безопасности в банке была автоматизирована выдача разрешений для доступа внутри облака. В результате разработчики получают нужный доступ за секунды. Если необходимо получить доступ во внутреннюю сеть банка, то автоматически заводится заявка на службу ИБ и сетевых специалистов, содержащая всю необходимую информацию для открытия доступа. Запрошенные доступы пользователь видит на портале и может ими управлять. Когда сервер, к которому запрошен доступ, прекращает свое существование, связанные с ним доступы закрываются автоматически.
«Мы разделили вопросы — если доступ касается облака, то офицеру ИБ достаточно согласовать заявку, и доступ предоставится автоматически. А если доступ требуется во внутренний сегмент сети, с портала самообслуживания запрос уходит сетевому инженеру. Для этой задачи мы создали форму, где пользователь вводит требуемые параметры (порты, протоколы, сети). Данные автоматически передаются в виде заявки в ITSM-систему. Облако же контролирует согласование заявки, автоматически создает необходимые доступы и отображает пользователю перечень заказанных доступов, — объясняет Вячеслав Медведев. — В результате с администраторов спала огромная нагрузка по рутинным проверкам запросов, большая часть доступов создается автоматически, и разработчики за минуты получают нужные ресурсы».
Большой эффект маленького апгрейда
Небольшие улучшения работы частного облака оказались эффективны. Время ожидания выделения ресурсов уменьшилось в разы. В банке признают, что это изменение действительно ускорило time-to-market для новых сервисов, а также помогло создать условия для agile-разработки с привлечением внутренних и внешних команд.
«В итоге модернизации банк еще на один шаг приблизился к трансформации в цифровую компанию, которая способна максимально быстро создавать новые ценности для клиентов и партнеров. Цикл разработки сократился на несколько дней за счет оперативного доступа к ресурсам. Мы добились упрощения процесса для пользователей и заодно снижения ежедневной нагрузки ИТ-команды банка. И все это без усложнения сложившихся процессов и с предсказуемым уровнем рисков и полным контролем над сетевой безопасностью», — заключает Вячеслав Медведев.
Короткая ссылка
