Паттерн «сторож»

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

Контекст и проблема

Многие облачные службы предоставляют конечные точки, позволяющие клиентским приложениям вызывать СВОИ API через Интернет или другую недоверенную сеть. Код, реализующий API, инициирует или выполняет ряд задач, в том числе, но не ограничиваясь аутентификацией, авторизацией, проверкой параметров и частичной или полной обработкой запросов. Код API, скорее всего, будет получать доступ к хранилищу и другим службам от имени клиента.

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

Solution

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

На схеме показаны разделы клиента, шлюза, доверенного узла или главного ключа, служб и данных. Шлюз предоставляет клиентам доступ к конечным точкам, а затем проверяет и санитизирует запросы. Затем шлюз может быть отделён от доверенного узла или узлов. Доверенный узел получает доступ к службе и хранилищу.

Вы можете использовать шаблон Gatekeeper для защиты хранилища или использовать его в качестве более комплексного фасада для защиты всех функций приложения. Важные факторы:

• Контролируемая проверка: Вратарь проверяет все запросы и отклоняет запросы, которые не соответствуют требованиям проверки.

• Ограниченный риск и подверженность: Риски и подверженность снижаются, поскольку шлюз не получает доступ к учетным данным или ключам, которые доверенный узел использует для доступа к хранилищам и службам. Если контролирующий узел окажется скомпрометирован, злоумышленники не смогут получить доступ к этим учетным данным или ключам.

• Надлежащая безопасность: Gatekeeper работает с ограниченными привилегиями, а остальное приложение — в режиме полного доверия, необходимом для доступа к хранилищу и службам. Если контролирующий узел скомпрометирован, он не сможет получить прямой доступ к службам или данным приложения.

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

Проблемы и рекомендации

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

• Убедитесь, что доверенные хосты открывают доступ только к внутренним или защищённым конечным точкам доступа, к которым обращается только gatekeeper. Доверенные хосты не должны предоставлять какие-либо внешние конечные точки или интерфейсы.

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

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

• Используйте безопасный канал связи, например HTTPS, протокол SSL или TLS, между шлюзом и доверенными узлами или задачами, где это возможно. Некоторые среды размещения не поддерживают HTTPS для внутренних конечных точек.

• Добавление дополнительного слоя для реализации шаблона Gatekeeper, скорее всего, влияет на производительность из-за дополнительной обработки и сетевого взаимодействия.

• Привратник может быть одной точкой сбоя (SPoF). Чтобы свести к минимуму влияние сбоя, рассмотрите возможность развертывания избыточных экземпляров и использования механизма автомасштабирования для обеспечения емкости и поддержания доступности.

Когда следует использовать этот шаблон

Используйте этот шаблон, когда:

• Вы обрабатываете конфиденциальную информацию.

• Вы публикуете службы, которым требуется надежная защита от вредоносного трафика.

• Вы выполняете критически важные операции, не допускающие прямого доступа к серверным службам.

• Необходимо, чтобы проверка запросов и очистка были отделены от основной бизнес-обработки.

Этот шаблон может быть не подходит, если:

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

• Дополнительные сетевые переходы и задержка валидации нарушают строгие требования к задержке на всём пути передачи.

Проектирование рабочей нагрузки

Оцените, как использовать шаблон "Gatekeeper" при проектировании рабочей нагрузки, чтобы реализовать цели и принципы, рассматриваемые в компонентах Azure Well-Architected Framework. В следующей таблице приведены рекомендации по использованию этого шаблона для целей каждого компонента.

Столп	Как этот шаблон поддерживает цели основных компонентов
Решения по проектированию безопасности помогают обеспечить конфиденциальность, целостность и доступность данных и систем рабочей нагрузки.	Вратарь в потоке запросов помогает централизовать функции безопасности, такие как брандмауэры веб-приложения, защита от атак DDoS, обнаружение ботов, манипуляция с запросами, запуск проверки подлинности и проверки авторизации. - Сетевые элементы управления SE:06 - SE:10 Мониторинг и обнаружение угроз
Эффективность производительности помогает рабочей нагрузке эффективно соответствовать требованиям путем оптимизации масштабирования, данных и кода.	Этот шаблон можно использовать, чтобы реализовать ограничение частоты запросов на уровне шлюза, а не выполнять контроль частоты на уровне узла. Координация частоты состояний между всеми узлами по своей природе не отличается высокой производительностью. - PE:03 Выберите услуги

Если этот шаблон вводит компромиссы внутри столпа, рассмотрите их против целей других столпов.

Example

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

Пользователи подключаются к Шлюз приложений Azure, которая находится в виртуальной сети через общедоступный IP-адрес. Виртуальная сеть включает шлюз приложений, Azure API Management, частную конечную точку и три подсети. Стрелка указывает от Шлюза приложений к API Management, от API Management к частной конечной точке и от частной конечной точки к Служба приложений Azure. Azure Monitor расположен ниже Службы приложений.

Скачайте файл Visio для этой архитектуры.

В этой архитектуре Шлюз приложений Azure с Брандмауэр веб-приложений Azure выполняет роль внешнего шлюза безопасности. Он проверяет трафик, подключенный к Интернету, и применяет элементы управления безопасностью до достижения уровня API. Azure API Management — внутренний шлюз. Он применяет специфичные для API средства управления и пересылает только разрешенный трафик к закрытым внутренним бэкендам.

Например, Брандмауэр веб-приложений Azure может обнаруживать и блокировать SQL-инъекции и межсайтовый скриптинг (XSS), применять правила протокола и ограничения на размер запросов, а также фильтрацию ботов и фильтрацию на основе IP-адресов до того, как запросы достигнут API Management или закрытых внутренних серверных систем.

Когда вы используете API Management во внутреннем слое, он применяет политики к входящим запросам и исходящим ответам в конвейере шлюза. Дополнительные сведения о том, как управление API обрабатывает запросы и ответы, см. в политиках управления API. Сведения о параметрах политики, таких как проверка веб-маркера JSON (JWT), ограничение скорости, преобразование заголовка и формирование ответов, см. в справочнике по политике управления API.

Используйте управляемые удостоверения для ресурсов Azure последовательно для аутентификации между службами в этом процессе. Например, API Management может использовать политику «проверка подлинности с помощью управляемого удостоверения» для получения токенов Microsoft Entra при вызовах к серверной части без хранения секретов.

Серверная часть остается закрытой. Например, серверная часть может представлять собой приложение Служба приложений Azure, использующее частную конечную точку, чтобы доступ к приложению был возможен только в частном порядке.

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

• Azure Kubernetes Service (AKS), что обеспечивает более контроль над выбором контроллера входящего трафика, политиками Kubernetes, топологией сети и операциями кластера.

• Контейнеры приложений Azure, которая является бессерверной управляемой платформой контейнеров, которая предоставляет возможности ingress и уменьшает управление инфраструктурой.

В этих вариантах ingress может выполнять маршрутизацию по хосту или пути, завершать TLS и предоставлять доступ к службам, доступным только во внутренней сети. Конкретные возможности, такие как ограничения запросов и правила разрешения и запрета, зависят от выбранной реализации Ingress. Во всех случаях сохраняйте границы, задаваемые gatekeeper’ом: применяйте проверку и контроль соблюдения политик на входе и обеспечивайте доступ к внутренним службам только через этот путь gatekeeper’а.

Каждый слой в этой цепочке генерирует журналы событий и метрики, которые необходимо централизованно собирать. Брандмауэр веб-приложений Azure журналы диагностики записывают соответствующие и заблокированные правила для каждого запроса. Управление API выдает журналы шлюза, которые фиксируют длительность запроса, коды ответов и результаты политики. Серверные службы отправляют телеметрию на уровне приложения. Соберите эти журналы и метрики в Azure Monitor и перенаправьте их в рабочую область Log Analytics для унифицированных запросов. Стандартизируйте сквозную корреляцию запросов путем создания или пересылки идентификатора корреляции на границе и распространения его через службы управления API и внутренних служб (например, с помощью заголовков запросов и контекста распределенной трассировки), чтобы одна транзакция оставалась трассируемой по всем уровням. Используйте Microsoft Defender для облака, чтобы получать рекомендации по безопасности для всех компонентов Gatekeeper. Настройте оповещения об аномально высоком уровне блокировок в Брандмауэр веб-приложений Azure или о всплесках ошибок в API Management, чтобы выявлять угрозы до того, как они достигнут закрытых внутренних серверов.

Дальнейшие действия

При реализации этого шаблона может потребоваться следующее руководство.

• Брандмауэр веб-приложений Azure в шлюзе приложений
• Политики в управлении API
• Использование частных конечных точек для приложений службы App Service

Связанные ресурсы

Следующие шаблоны проектирования облака часто используются вместе с шаблоном Gatekeeper:

• Схема маршрутизации шлюза
• Схема разгрузки шлюза
• Шаблон федеративного удостоверения
• Шаблон ключа «Валет»