Благодаря росту популярности облачных сервисов угроза сетевых атак на инфраструктуру приложений стала куда серьезнее, так как серверы не защищены методами периметровой защиты. Здесь полезно обратить внимание на гибкую технологию программно-определяемого периметра (Software-Defined Perimeter, SDP), в которой мы попробуем разобраться.
Введение
SDP впервые была представлена в 2013 году, ее первоначальной целью является противодействие сетевым атакам, направленным на инфраструктуру приложений. Изначально было принято решение с чистого листа подойти к вопросу противодействия кибератакам, нужен был эффективный и экономически выгодный метод. Авторы решения определили для себя три ключевых элемента для достижения своей цели.
Прежде всего, нужна была модель безопасности, которая бы идентифицировала пользователей, их устройства и роль, прежде чем предоставлять доступ к защищенным системам. Во-вторых, нужна была криптографическая проверка. В-третьих, используемые протоколы должны быть проверенными средствами контроля безопасности.
Идеальным подходом разработчики посчитали основанную на контрольном канале архитектуру с использованием стандартных компонентов: SAML, PKI, и общий TLS. Таким образом, в декабре 2013 года был опубликован документ, описывающий концепцию SDP, авторы хотели посмотреть, вызовет ли новая инициатива интерес.
Оказалось, что концепт действительно нашел отклик, именно поэтому в апреле 2014 года была выпущена спецификация SDP Version 1. Изначально проект описывал хост, который передавал бы устройство и идентификатор пользователя контроллеру через общее TLS-соединение. Контроллер, в свою очередь, подключается к центру сертификации для проверки идентификатора пользователя.
После этого контроллер обеспечит одно или несколько TLS-соединений между первоначальным хостом и принимающими сторонами.
Модель безопасности
Чтобы решить проблему сетевых атак на инфраструктуру приложений SDP-команда разработала подход, который объединяет в себе аутентификацию устройства, доступ на основе идентификации и динамически создаваемые возможности подключения. Интеграция этих трех компонентов — довольно свежая идея.
Помимо этого, специалисты показали, что модель безопасности SDP останавливает все формы кибератак, включая: DDoS, Man-in-the-Middle, Server Query (OWASP10) и даже Advanced Persistent Threat (APT).
SDP Версия 1
Первые коммерческие продукты SDP реализовывали концепцию как оверлейную сеть для корпоративных приложений, например, защита экземпляров облачных серверов от целевых атак. SDP-хост стал в этом случае клиентом, а принимающий хост стал шлюзом.
Рисунок 1. Первая версия SDP
SDP-клиент
Клиент SDP обрабатывает широкий спектр функций от проверки устройства и идентификации пользователя до маршрутизации приложений «белого списка» (локальных) в авторизованные защищенные приложения (удаленные). Клиент настроен на работу в режиме реального времени, это гарантирует, что общий TLS VPN подключается только к службам, к которым пользователь имеет доступ.
Для организаций SDP-клиент становится точкой принудительного применения политик, поскольку контроль доступа осуществляется только после того, как устройство пользователя и его идентификатор были криптографически проверены.
Контроллер SDP
SDP-контроллер функционирует в качестве некого посредника между клиентом SDP и бекенд-системами безопасности (например, центром сертификации и сервером аутентификации). После идентификации SDP-клиента и разрешенных служб контроллер SDP настраивает как клиент SDP, так и шлюз в режиме реального времени для обеспечения общего TLS-соединения.
Шлюз SDP
SDP-шлюз представляет собой точку завершения общего TLS-соединения. Обычно его разворачивают как можно ближе к защищаемому приложению. Шлюз SDP предоставляется с IP-адресом и сертификатами клиента SDP после идентификации устройства и авторизации пользователя.
Работая совместно, эти три компонента SDP обеспечивают ряд уникальных свойств безопасности:
- Сокрытие информации. Никакой DNS-информации, никаких видимых портов инфраструктуры приложений.
- Предварительная аутентификация. Идентификатор устройства проверяется до предоставления возможности подключения. Этот ID определяется через токен MFA, встроенный в настройку TCP или TLS.
- Предварительная авторизация. Пользователям предоставляется доступ только к серверам приложений, которые подходят для их роли. Система идентификации использует SAML для информирования SDP-контроллера о привилегиях хостов.
- Доступ к уровню приложений. Пользователям предоставляется только доступ на уровне приложения. Кроме того, SDP обычно заносит в белый список приложения на устройстве пользователя.
- Растяжимость. SDP построен на проверенных, основанных на стандартах компонентах, таких как сертификаты TLS, SAML и X.509. Стандартизованная технология гарантирует, что SDP может взаимодействовать с другими системами безопасности, такими как шифрование данных или системы удаленной аттестации.
Выводы
Предварительная аутентификация в сочетании с предварительной авторизацией создает сети, скрытые от неизвестных хостов. При этом обеспечивается доступ для авторизованных пользователей. Ключевым аспектом SDP является тот факт, что предварительная аутентификация и предварительная авторизация происходят до того, как будет инициировано соединение TCP между пользователем и защищенным приложением.
Более того, пользователя разрешен доступ только к авторизованным приложениям. Это помогает устранить угрозу «бокового перемещения» от скомпрометированных устройств.
