Архитектура и решения безопасности в облаке часть 2

В первой части статьи мы обсудили стоп-факторы, которые блокировали возможность встраивания методологии CI/CD в процесс облачной разработки, а также способы, которыми они были устранены. Возможность безопасного и прозрачного управления Группами Безопасности командами разработки и используемые решения для осуществления контролей ИБ из библиотеки безопасности.

В этой статье я расскажу вам про новые системы, которые нам удалось внедрить и использовать, тем самым повысив уровень безопасности и отказоустойчивости облака.

При увеличении количества каталогов и миграции продуктивных систем возникла потребность в отказоустойчивом и контролируемом доступе в интернет. Изначально доступ в интернет на сервисах осуществлялся через сервис NAT в интернет, это не отвечало политике информационной безопасности компании, но в тот момент мы приняли этот риск и стали искать решение которое бы устроило информационную безопасность, бизнес и команды разработки.

Первым решением было использовать web-прокси сервер Squid для контролируемого доступа в интернет. Было развернуто 2 сервера в разных зонах доступности с идентичной конфигурацией, а трафик на них направлялся через сервис облака NLB.  Решение изначально планировалось, как временное и эксплуатировалось в течении года. Схема решала проблему с самым частым запросом для тестовых сервисов – доступ к внешним серверам обновлений.

Шло время, и в облако стали подтягиваться продуктивные сервисы, которые требовали связи с внешними сервисами без ограничения протокола, SQUID для это задачи не подходил, а Группы Безопасности, к большому сожалению, не поддерживают FQDN. Поэтому для доступа в интернет было решено использовать межсетевые экраны. При использовании межсетевых экранов мы столкнулись с следующей проблемой, невозможность настройки балансировки на L2 уровне в том числе использования протокола VRRP. Это значило невозможность реализации отказоустойчивой схемы с балансировкой трафика.

Нам очень помогли коллеги из Яндекс Облака, они подготовили для нас комплексное решение по отказоустойчивому доступу в интернет на основе проекта из библиотеки архитектурных решений Яндекс Облака yc-route-switcher.

Решение работает следующим образом. Функция проверки состояния каждую минуту обходит статусы, получаемые healthcheck’ом специально выделенного порта хостов в группе балансировки закреплённой за NLB, которая включает в себя адреса интерфейсов межсетевого экрана.

Далее следующие действия повторяются по событиям:

1. Если primary-хост(first-rt) недоступен, то в очередь сообщений передаётся запрос на изменение закреплённой таблицы маршрутизации, чтобы стандартный маршрут шлюза указывал на secondary-хост(second-rt), который в обычном состоянии является primary-хостом для другой сети.

2. Если таблица маршрутизации указывает на secondary-хост, но primary-хост доступен, функция отправляет запрос на изменение её стандартного маршрута на primary-хост, восстанавливая исходное состояние, при этом хосты, закрепленные за secondary-хостом, не изменяют свой стандартный маршрут.

Функция переключения маршрута срабатывает при наличии сообщений в очереди, вызывая переключение таблицы маршрутизации. Среднее время реакции на сбой у такого решения — 1 минута.

Внедрение данного решения не обошлось без ошибок. При увеличении количества подсетей возникла проблема, когда при переключении таблиц маршрутизации, схема не возвращалась к обычному состоянию, так как часть таблиц маршрутизации не переключалось из-за ошибки в логике работы Cloud Functions и решения. В итоге после нескольких итераций проблема была решена и решение заработало, как и задумывалось.

Внедрение yc-route-switcher позволило:

• снизить риск отказа одиночного межсетевого экрана и отказа зоны доступности в Яндекс Облаке

• осуществлять публикацию равнозначных конфигураций посредством менеджмент-центра

Что реализовать не удалось:

• автоматическую балансировку нагрузки в связи с отсутствием возможности синхронизации и реализации VRRP

• публикацию сервисов в интернет через межсетевые экраны, в связи с невозможностью назначения нескольких публичных адресов на сетевой интерфейс

C увеличением количества каталогов, увеличилось и количество пользователей облака, и у команды безопасности возникла необходимость внедрения SSO-аутентификации. Изначально пользователи работали через Yandex.Passport аккаунты. Это несло риски в связи с несвоевременным отзывом доступа к облаку, контролей для этого процесса попросту не было.

После совместных обсуждений с командой инфраструктуры мы решили использовать ADFS-аутентификацию в облаке.

Процесс аутентификации через SSO ADFS:

1. Пользователь открывает в браузере ссылку для входа в консоль.

2. Если это первая аутентификация пользователя, то консоль отправляет его на сервер ADFS для прохождения аутентификации. Если пользователь уже проходил аутентификацию, то информация об этом сохранена в cookie его браузера. Если время жизни cookie не истекло, то консоль управления сразу аутентифицирует пользователя и отправляет на главную страницу. Время жизни cookie указывается при создании федерации. Если время жизни cookie истекло, то консоль отправляет пользователя на сервер ADFS для повторной аутентификации.

3. Сервер ADFS показывает пользователю страницу аутентификации. Например, просит ввести логин и пароль.

4. Пользователь вводит на сервере ADFS данные, необходимые для аутентификации.

5. Пользователь подтверждает вход через двухфакторную аутентификацию.

6. В случае успешной аутентификации сервер ADFS отправляет браузер пользователя назад на страницу для входа в консоль управления.

7. Консоль управления спрашивает IAM, добавлен ли такой пользователь в облако. Если да, то консоль управления аутентифицирует пользователя и отправляет на главную страницу.

Так, как ADFS на тот момент ещё не была внедрена в компании, команда безопасности совместно с инфраструктурной командой запустили процесс её внедрения. После проверок на уязвимости и тестирования ADFS, была организована федерация с Яндекс Облаком в интерфейсе Организаций, которые на тот момент вышли в полный доступ. Процесс перехода был осуществлен в течении месяца и включал в себя уведомление пользователей с подтверждением актуальности предоставленных доступов. Параллельно с переходом на новую схему аутентификации мной был проведен аудит доступа в облако в ходе которого были отозваны неиспользуемые доступы.

Для повышения уровня безопасности авторизации возникла необходимость подключения механизма двухфакторной аутентификации для доступа к облаку. К большому сожалению в Яндекс Облаке отсутствует сервис двухфакторной аутентификации для использования с SSO-провайдерами, когда как для Yandex.Passport аккаунтов используется стандартная двухфакторная аутентификация, при условии включения её пользователем.  В итоге мы подключили внешнего провайдера для двухфакторной аутентификации с различными методами 2FA.

Подключение SSO-аутентификации позволило получить следующие контроли:

• настраиваемая продолжительность сессии авторизации

• использование пользователями IAM-токенов федерации с настраиваемым сроком жизни вместо OAuth-токенов Yandex.Passport с сроком жизни 1 год

• если вы используете IdM-решения или другие варианты автоматизации, то при увольнении работника учетная запись будет автоматически заблокирована, и пользователь уже не получит доступ к облаку

• пользователя легче идентифицировать, отпала необходимость ведения списков сопоставления почты и конкретного пользователя

• использование своего провайдера двухфакторной аутентификации, как стороннего, так и кастомного on-premise совместимого с используемой SSO решения

Итоги:

• Развернули отказоустойчивую и удобно-конфигурируемую посредством terraform и менеджмент-сервера, схему доступа в интернет с возможностью разделения нагрузки по подсетям.

• Получили контроли за учетными записями пользователей в облаке и минимизацию рисков не отозванных прав на критические сервисы.