Защита приложений и служб с помощью выделенного экземпляра узла для брокера запросов между клиентами и приложением или службой. Брокер проверяет и очищает запросы и может обеспечить дополнительный уровень безопасности и ограничить область атаки системы.
Контекст и проблема
Облачные службы предоставляют конечные точки, позволяющие клиентским приложениям вызывать их API. Код, используемый для реализации API-интерфейсов или выполнения нескольких задач, включая проверку подлинности, авторизацию, проверку параметров и некоторые или все запросы. Код API, скорее всего, будет получать доступ к хранилищу и другим службам от имени клиента.
Если злоумышленник компрометирует систему и получает доступ к среде размещения приложения, его механизмы безопасности и доступ к данным и другим службам предоставляются. В результате злоумышленник может получить неограниченный доступ к учетным данным, ключам хранилища, конфиденциальной информации и другим службам.
Решение
Одним из решений этой проблемы является разделение кода, реализующего общедоступные конечные точки, от кода, обрабатывающего запросы и доступ к хранилищу. Вы можете добиться разъединения с помощью фасада или выделенной задачи, которая взаимодействует с клиентами, а затем передает запрос (возможно, через несогласованный интерфейс) к узлам или задачам, обрабатывающим запрос. На этом рисунке представлен общий обзор этого шаблона.
Шаблон воротника можно использовать для защиты хранилища или его можно использовать в качестве более комплексного фасада для защиты всех функций приложения. Используя эту модель, важно учитывать следующее:
- Контролируемая проверка. Вратарь проверяет все запросы и отклоняет запросы, которые не соответствуют требованиям проверки.
- Ограничение риска и уязвимости. У привратника нет доступа к учетным данным или ключам, которые доверенный узел использует, чтобы обращаться к хранилищу и службам. Скомпрометировав привратник, злоумышленник не получит доступ к учетным данным или ключам.
- Обеспечение безопасности. Привратник работает в режиме ограниченных прав, а остальная часть приложения — в режиме полного доверия, необходимом для обеспечения доступа к хранилищу и службам. Даже в случае компрометации привратник не сможет обратиться к службам или данным приложения напрямую.
Этот шаблон действует как брандмауэр в классической сетевой топографии. Он позволяет вратарю проверять запросы и принимать решение о том, следует ли передавать запрос на доверенный узел, выполняющий необходимые задачи. Обычно, если привратник принимает решение передать запрос доверенному узлу, он предварительно проверяет и очищает содержимое запроса.
Проблемы и рекомендации
При принятии решения о реализации этого шаблона необходимо учитывать следующие моменты.
- Убедитесь, что доверенные узлы предоставляют только внутренние или защищенные конечные точки, используемые только привратником. У доверенных узлов не должно быть внешних конечных точек и (или) интерфейсов.
- Вратарь должен работать в ограниченном режиме привилегий, который обычно требует запуска шлюза и доверенного узла в отдельных размещенных службах или виртуальных машинах.
- Вратарь не должен выполнять обработку, связанную с приложением или службами, или получить доступ к любым данным. Его единственная функция — проверка и очистка запросов. Доверенным узлам может потребоваться выполнить дополнительную проверку запросов, но привратник должен выполнить основную проверку.
- Используйте безопасный канал связи (HTTPS, SSL или TLS) между шлюзом и доверенными узлами или задачами, где это возможно. Некоторые среды размещения не поддерживают HTTPS для внутренних конечных точек.
- Добавление дополнительного слоя для реализации шаблона вратаря, скорее всего, влияет на производительность из-за дополнительной обработки и сетевого взаимодействия.
- Экземпляр привратника может стать единой точкой отказа. Чтобы свести к минимуму влияние сбоя, рассмотрите возможность развертывания избыточных экземпляров и использования механизма автомасштабирования для обеспечения доступности емкости.
Когда следует использовать этот шаблон
Этот шаблон полезен для приложений, которые:
- обработка конфиденциальной информации
- предоставление служб, требующих высокой степени защиты от вредоносных атак
- выполнение критически важных операций, которые не могут быть нарушены.
- требуется, чтобы проверка запросов выполнялась отдельно от основных задач, а также для централизовать эту проверку, чтобы упростить обслуживание и администрирование.
Проектирование рабочей нагрузки
Архитектор должен оценить, как шаблон Gatekeeper можно использовать в проектировании рабочей нагрузки для решения целей и принципов, описанных в основных принципах Платформы Azure Well-Architected Framework. Например:
| Принцип | Как этот шаблон поддерживает цели основных компонентов |
|---|---|
| Решения по проектированию безопасности помогают обеспечить конфиденциальность, целостность и доступность данных и систем рабочей нагрузки. | Добавление шлюза в поток запросов позволяет централизовать функции безопасности, такие как брандмауэры веб-приложения, защита от атак DDoS, обнаружение ботов, обработка запросов, запуск проверки подлинности и проверки авторизации. - Сетевые элементы управления SE:06 - SE:10 Мониторинг и обнаружение угроз |
| Эффективность производительности помогает рабочей нагрузке эффективно соответствовать требованиям путем оптимизации масштабирования, данных, кода. | Этот шаблон заключается в том, как можно реализовать регулирование на уровне шлюза, а не реализовать проверки скорости на уровне узла. Состояние скорости координации между всеми узлами по сути не выполняется. - PE:03 Выбор служб |
Как и любое решение по проектированию, рассмотрите любые компромиссы по целям других столпов, которые могут быть представлены с этим шаблоном.
Пример
В сценарии, размещенном в облаке, этот шаблон можно реализовать, разобщая роль воротника или виртуальную машину от доверенных ролей и служб в приложении. Реализация может использовать внутреннюю конечную точку, очередь или хранилище в качестве промежуточного механизма обмена данными. На схеме представлен пример с использованием внутренней конечной точки.
Связанные ресурсы
Шаблон ключа камердинера также может использоваться при реализации шаблона привратника. При взаимодействии между шлюзом и доверенными ролями рекомендуется повысить безопасность с помощью ключей или маркеров, ограничивающих разрешения для доступа к ресурсам. Шаблон описывает использование маркера или ключа, предоставляющего клиентам ограниченный, прямой доступ к определенному ресурсу или службе.