Недавно я столкнулся со сценарием, который хотел потратить на написание. Представьте, что вам нужно развернуть новое веб-приложение в Microsoft Azure. Однако есть некоторые дополнительные требования -

  • Приложение должно требовать проверки подлинности Azure Active Directory.
  • Веб-приложение не должно быть доступно напрямую через общедоступный Интернет.
  • Конечный пользователь должен иметь возможность подключиться к веб-приложению с помощью общедоступной записи DNS, чтобы он чувствовал, что это подлинный опыт.

Соображения

Есть несколько способов, которыми это может быть достигнуто, но это может привести к некоторой сложности. Некоторые из них включают -

  • Разверните приложение на какой-либо серверной вычислительной машине. Варианты могут включать виртуальные машины, масштабируемые наборы виртуальных машин, службу Azure Kubernetes, службу приложений Azure и многое другое. Для простоты и возможности сосредоточиться на нашем приложении мы выберем службу приложений Azure, которая представляет собой вариант на основе платформы как услуги (PaaS).
  • Это означает, что мы можем больше сосредоточиться на нашем приложении, чем на управлении его инфраструктурой. Службы приложений поставляются с рядом функций, которые будут полезны при прочтении этой статьи.
  • Развертывание шлюза приложений для прослушивания общедоступного IP-адреса –
  • В прозрачной архитектуре. Под этим я подразумеваю, что шлюз приложений привязан к определенной записи CNAME, которую серверная служба приложений также прослушивает. Это снижает сложность при попытке понять, какие имена хостов куда пересылаются, избегая каких-либо сложностей правил перезаписи. Это может быть прослушиватель с одним или несколькими сайтами (подробнее об этом позже).
  • Где Шлюз приложений прослушивает другое имя узла. Затем с помощью Шлюза приложений отправьте настраиваемые имена узлов в серверную часть, чтобы служба приложений понимала, к какому экземпляру приложения следует перенаправить запрос. Кроме того, используйте правила перезаписи Шлюза приложений, чтобы обеспечить отправку соответствующего redirect_uri на серверную часть.
  • Хотя это кажется простым в объяснении, за этим стоит довольно много сложностей.
  • Поскольку мы говорим об аутентификации, скорее всего, на компьютере создается файл cookie для токена пользователя. К какому домену это привязано в данном случае? Как убедиться, что redirect_uri правильно настроен?
  • Лично я предпочитаю подход KISS (Keep It Simple Stupid) для удовлетворения требований.
  • В обоих описанных выше сценариях мы могли бы использовать функцию ограничения доступа к сети службы приложений, чтобы разрешить трафик только с общедоступного IP-адреса шлюза приложений.
  • Если бы первоначальное требование было сосредоточено на подходе к частной DNS, это значительно изменило бы область применения подхода. Это может потребовать некоторого обсуждения в отдельном сообщении в блоге. А пока давайте сосредоточимся на приложении, которое будет доступно через общедоступный Интернет через шлюз приложений и требует авторизации (AuthZ).
  • Мы также предполагаем, что внедрение аутентификации в код приложения невозможно. Однако это может открыть для нас дополнительную гибкость (т.е. дополнительный контроль). Итак, для этого конкретного сценария мы будем использовать функцию Easy Auth службы приложений Azure.

Но сначала спасибо

Будучи прагматиком и желая рассказать о процессе решения этой проблемы, я хочу продемонстрировать решение, которое удовлетворяет требованиям самым простым способом, поэтому у нас довольно плотный объем работы. Прежде чем мы углубимся в это, я хочу обратиться к паре коллег — Бену Гимблетту и Мэтту Фортунке, которые блестяще позволили мне поделиться с ними идеями при решении задачи. Некоторые идеи, которыми мы поделились в этом посте (например, потенциальная сложность файлов cookie и работа с соответствующим комментарием к хосту/маршрутизации выше), основаны на их замечательном предыдущем опыте. Еще раз большое спасибо вам обоим.

Настройка службы приложений

Теперь перейдем к делу — защита службы приложений с помощью Easy Auth за общедоступным шлюзом приложений. Давайте сначала развернём приложение. Перейдите на портал Azure и создайте новую службу приложений (и план службы приложений, если необходимо). В любом случае лучше всего выполнить их пробный запуск в среде разработки, которая полностью отделена от любой производственной инфраструктуры, чтобы сначала проверить концепцию.

Настройка простой аутентификации

Давайте сначала выполним требование аутентификации. Мы продолжим и будем использовать встроенные возможности аутентификации и авторизации (которые я обычно буду называть Easy Auth в этом посте). Перейдите к экземпляру службы приложений. В левой части блейда у вас будет меню для настройки экземпляра службы приложений. Найдите параметр для аутентификации.

Примечание. Вы можете увидеть два варианта: Аутентификация и Аутентификация (классическая). Оба относятся к интерфейсу Easy Auth, но представляют собой разные интерфейсы пользовательского интерфейса. Для этого сообщения в блоге я буду использовать вариант аутентификации, а не аутентификацию (классическая).

Создайте нового поставщика удостоверений —

  • Поставщик удостоверений: Microsoft
  • Тип регистрации приложения. Создайте новую регистрацию приложения (если у вас еще нет регистрации приложения в клиенте Azure Active Directory).
  • Для этого шага вам потребуется соответствующий доступ для создания приложения в клиенте Azure Active Directory. Если у вас нет соответствующего доступа, вам нужно будет использовать один из «существующих» вариантов и попросить кого-то создать приложение от вашего имени.
  • Имя: cwc-secured-app
  • Я просто указал то же имя, что и Служба приложений. Тем не менее, вы захотите, чтобы это было чем-то репрезентативным для приложения. Это будет отображаться для ваших пользователей при первом входе в приложение.
  • Поддерживаемые типы учетных записей: Текущий арендатор — Один арендатор
  • В зависимости от вашего сценария выберите то, что подходит. У нас не было особых требований к пользователям за пределами нашего арендатора, поэтому мы оставим этот параметр по умолчанию.
  • Аутентификация: Требовать аутентификацию
  • Это позволит нам выполнить первоначальное требование, которое мы изложили.
  • Запросы, не прошедшие проверку подлинности: HTTP 302 Found redirect: рекомендуется для веб-сайтов
  • Мы оставим это по умолчанию. Однако есть и другие варианты, включая HTTP 401 или HTTP 403.
  • Хранилище токенов: мы оставим это значение по умолчанию (включено).

Совет. Во всплывающей подсказке Azure для хранилища токенов поясняется следующее:

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

Само веб-приложение будет готовым интерфейсом службы приложений Azure. Таким образом, само приложение не требует специального доступа к Microsoft Graph. Однако, если вам нужно выполнить некоторые функции (например, вы делаете вызовы Microsoft Graph непосредственно из кода вашего веб-приложения, а не вызываете какие-либо внешние API), вы можете выбрать разрешения здесь. Еще раз, мы оставим это по умолчанию.

Здорово. Мы должны увидеть, что параметры аутентификации и поставщик удостоверений теперь успешно настроены, как показано на снимке экрана ниже.

Давайте сначала убедимся, что все работает правильно, перейдя по URL-адресу azurewebsites.net нашей службы приложений. Если все хорошо, нам будет предложено выбрать учетную запись пользователя для аутентификации.

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

Опять же, все в порядке — теперь вы должны увидеть экран службы приложений по умолчанию (если, конечно, вы не развернули другое приложение за это время!).

Настройка пользовательского домена в службе приложений

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

Однако есть один шаг, который мы хотим сделать в первую очередь. Помните, что мы хотим, чтобы Шлюз приложений действовал прозрачно перед веб-приложением? Что ж, для этого мы хотим убедиться, что служба приложений прослушивает соответствующее имя хоста. Для этого нам сначала нужно сопоставить личный домен со службой приложений и проверить домен. Нам не обязательно сопоставлять фактический домен, поскольку есть метод, который мы можем использовать для подтверждения достоверности. Этот подход объясняется здесь, с использованием записи TXT и asuid.subdomain. Вы увидите, что я имею в виду через мгновение!

Перейдите к пункту меню «Пользовательские домены» вашего экземпляра службы приложений. Нажмите «Добавить личный домен» и введите домен, который вы хотите использовать.

Вы заметите, что в лезвии есть два предмета —

  • Доступность имени хоста — это проверка того, было ли уже сопоставлено имя хоста в Службе приложений. Вы сможете сопоставить имя хоста только с одним развертыванием службы приложений.
  • Владение доменом. Как я уже упоминал ранее, это можно сделать несколькими способами. Нам не нужно сопоставлять запись CNAME, если только мы не хотим указывать здесь домен и напрямую направлять трафик. Поскольку мы просто хотим подтвердить право собственности, чтобы разрешить привязку, мы можем использовать запись TXT.

У меня есть cloudwithchris.com в качестве общедоступной зоны Azure DNS. Итак, давайте добавим туда соответствующую запись TXT.

Поскольку я планирую использовать субдомен cwc-secured-app.cloudwithchris.com, мне потребуется добавить запись TXT с именем asuid.cwc-secured-app со значением проверки, отображаемым в службе приложений.

Вернувшись к нашему экземпляру службы приложений и снова пройдя этап проверки, вы должны заметить, что оба этапа (доступность имени хоста и владение доменом) теперь пройдены. Если нет, возможно, вам придется подождать, пока служба приложений не обнаружит новую запись TXT. Когда все будет готово, нажмите Добавить личный домен.

Совет. Если вы хотите направлять трафик непосредственно в службу приложений, вам потребуется обновить запись CNAME, чтобы она указывала на имя хоста {mywebappname}.azurewebsites.net службы приложений. Учитывая, что в этом сценарии трафик должен идти к шлюзу приложений, позже мы направим его на шлюз приложений.

Настройка SSL для службы приложений

На данный момент у нас есть дополнительное имя узла (пользовательский домен), привязанное к экземпляру службы приложений. Это означает, что когда наш трафик попадает в службу приложений, все запросы, содержащие имя хоста cwc-secured-app.cloudwithchris.com, будут направляться в соответствующий экземпляр службы приложений.

Но теперь у нас есть предупреждение на портале. You have custom domains that are not secured and will cause browser warnings/errors when accessed over https. Click on "Add binding" to secure your custom domains. Если мы хотим сделать сайт доступным по протоколу HTTP, а не HTTPS, тогда этот личный домен будет работать нормально. Однако, учитывая, что наши требования сосредоточены на защите приложения, для нас имеет смысл обратиться к предупреждению SSL здесь.

В стороне — сертификаты, управляемые службой приложений

Есть хорошие новости! Если вы были в курсе Объявлений о сборке Microsoft за последнюю неделю. Управляемые сертификаты службы приложений теперь общедоступны. Это означает, что мы можем бесплатно получить SSL-сертификат для нашей службы приложений.

Чтобы начать процесс, перейдите к настройкам TLS/SSL в меню слева и перейдите на вкладку Сертификаты закрытого ключа (.pfx). Вы должны увидеть вариант Создать управляемый сертификат службы приложений.

Вы заметите, что когда мы пытаемся зарегистрировать сертификаты, управляемые службой приложений, нам сообщается, что мы не имеем права, поскольку запись CNAME не сопоставлена ​​с соответствующим доменом. Конечно, мы могли бы сопоставить запись CNAME с azurewebsites.net, чтобы при необходимости получить бесплатный SSL-сертификат.

После добавления записи CNAME cwc-secured-app, указывающей на cwc-secured-app.azurewebsites.net, вы можете видеть, что я запустил процесс создания сертификата.

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

Вам нужно будет вернуться в меню «Пользовательские домены» и добавить привязку между собственным доменом и вновь созданным SSL-сертификатом.

Совет. Далее в этом посте нам потребуется использовать сертификат со Шлюзом приложений. Бесплатный управляемый сертификат службы приложений нельзя экспортировать (как описано здесь), поэтому вам понадобится сертификат SSL, созданный в другом месте, чтобы принимать трафик HTTPS через Шлюз приложений. Я обычно использовал ZeroSSL в прошлом, поскольку они предоставляют недолговечные сертификаты бесплатно. Конечно, доступно много вариантов, хотя у вас уже может быть SSL-сертификат! Я не планирую вдаваться в подробности в этом посте, поэтому оставлю это как отдельное упражнение для вас.

Альтернативные варианты

Вы не ограничены только использованием управляемого сертификата App Service. Однако, поскольку это так ново, я хотел убедиться, что я упомянул его в этом сообщении в блоге. Для внешнего интерфейса Шлюза приложений я фактически использую сертификат, созданный с помощью ZeroSSL. Возможно, у вас уже есть SSL-сертификат или поставщик, которым вы обычно пользуетесь. Вы также можете использовать эти сертификаты в службе приложений. Дополнительные сведения о доступных вариантах см. в Документах Azure.

URI перенаправления в регистрации приложения Azure Active Directory

На данный момент это, конечно, означает, что вы можете перейти к HTTP-версии вашего личного домена в веб-браузере. Давайте сделаем это, чтобы проверить процесс аутентификации, прежде чем мы добавим Шлюз приложений в микс.

Вы должны увидеть приглашение выбрать свою учетную запись без каких-либо проблем. Однако после редиректа — вы столкнетесь с ошибкой. О-о.

К счастью, ошибка очень наглядна и имеет смысл. Изначально мы настроили поставщика удостоверений на перенаправление на cwc-secured-app.azurewebsites.net. Однако мы не заходили с этого URL. Мы зашли с имени хоста cwc-secured-app.cloudwithchris.com, поэтому Azure AD зафиксирует это из нашего запроса и попытается перенаправить нас туда. Приложение не имеет URI перенаправления на этот пользовательский домен (заканчивающийся cloudwithchris.com), поэтому мы сталкиваемся с ошибкой, которую только что наблюдали.

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

Давайте вернемся к пункту меню «Аутентификация» в нашем экземпляре службы приложений. Рядом с поставщиком удостоверений Майкрософт, который вы настроили ранее, вы должны увидеть ссылку в скобках, которая является регистрацией приложения Azure Active Directory. Нажмите на эту ссылку. Теперь вы должны быть в представлении регистрации приложений в Azure Active Directory. Перейдите к пункту меню «Аутентификация». Вы должны перейти к представлению «Регистрация приложения» в Azure Active Directory, которое выглядит примерно так, как показано ниже.

На скриншоте выше вы заметите, что я добавил дополнительный URI перенаправления. Это URI перенаправления с использованием нового пользовательского домена, который я настроил. Учитывая, что мы не будем использовать URI azurewebsites.net, мы могли бы рассмотреть возможность удаления URI azurewebsites.net из списка. На самом деле это то, что я сделал после снимка экрана, чтобы убедиться, что аутентификация исходит только от нашего пользовательского доменного маршрута и в противном случае выдает ошибку.

Совет. Для удобства чтения я добавил https://cwc-secured-app.cloudwithchris.com/.auth/login/aad/callback URI перенаправления. Обратите внимание, что нам по-прежнему требуется путь /.auth/login/aad/callback после домена, как указано Easy Auth в потоке аутентификации.

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

Совет. Разумно использовать методический подход. Составьте себе упорядоченный список задач и следуйте ему. Если подумать, это то, что делает Infrastructure as Code.

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

Создайте шлюз приложений

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

На первом этапе создания шлюза приложений нам нужно выбрать группу ресурсов, предоставить шлюзу имя, регион развертывания, уровень и т. д.

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

Совет. Ознакомьтесь с Документами Azure для получения дополнительных рекомендаций по рекомендуемым конфигурациям сети.

Шлюз приложений — внешние интерфейсы

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

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

Для частного IP-адреса — если вы настраиваете шлюз приложений с номером SKU Standard_v2, вы должны выбрать «да» для Use a specific private IP address. Если вы выбрали другой SKU, вы можете выбрать «Нет». В этом случае первый доступный адрес выбранной подсети будет назначен динамически. Я назначил частный IP-адрес 172.16.0.4, который является первым доступным IP-адресом в моей подсети.

Совет. Если вы не знали, в каждой подсети зарезервировано 5 IP-адресов. Подробности об этом можно узнать здесь.

Шлюз приложений — серверные части

Переходим к шагу 3, бэкенды. У нас может быть много серверных пулов, к которым мы хотим направлять (например, если у нас есть шлюз приложений, выступающий в качестве прослушивателя для нескольких сайтов). Сначала нам нужно Добавить серверный пул.

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

Дайте вашему серверному пулу имя. Выберите Службы приложений в раскрывающемся списке Тип цели. Наконец, выберите службу приложений, которую вы создали ранее, в качестве целевого приложения.

Шлюз приложений — правила маршрутизации

На этом этапе у вас появится экран с четкой диаграммой, показывающей, какие компоненты Шлюза приложений вы уже настроили. У вас есть пара внешних IP-адресов (1 общедоступный, 1 частный) и внутренний пул. Теперь нам нужно создать правило маршрутизации, чтобы объединить все это. Нажмите на создание правила маршрутизации.

Правила маршрутизации состоят из двух частей. Вы сопоставляете слушателя (вещь, которая прослушивает порт и IP-адрес по определенным критериям) с целью бэкэнда (т. е. в какой пул бэкэнда вы отправляете трафик, используя какую форму настроек/проверок HTTP для проверки работоспособности бэкэнда).

Напоминаем, что если вы планируете принимать трафик HTTPS через Шлюз приложений, вам потребуется сертификат SSL. Вы не можете экспортировать сертификат, управляемый службой приложений, для использования в другом месте. Ранее в сообщении я упоминал, что обычно использую ZeroSSL для создания краткосрочных SSL-сертификатов для своей демонстрационной среды. Для производственной среды вам нужно будет продолжить и оценить варианты (хотя, вероятно, у вас уже есть сертификат SSL или предпочитаемый поставщик, если это так).

Настройка прослушивателя для правила маршрутизации

Дайте вашему правилу имя, а затем сделайте то же самое для своего слушателя. Мы будем прослушивать общедоступный IP-адрес с использованием протокола HTTPS (что означает, что мы будем прослушивать порт 443). Я загрузил свой сертификат PFX и указал имя сертификата и пароль, чтобы шлюз приложений мог использовать этот сертификат. Наконец, я решил использовать многосайтовый прослушиватель.

Совет. На портале Azure поясняется следующее:

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

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

Настройка бэкэнд-цели для правила маршрутизации

Теперь перейдем ко второй части нашего правила маршрутизации, к серверной части. Сначала мы выберем бэкэнд-пул, который мы создали ранее, в моем случае secure-app-backend.

Мы еще не создали настройки HTTP для внутреннего пула, поэтому давайте создадим их. Параметры HTTP определяют номер порта и протокол, используемые для отправки трафика в серверные пулы. Их также можно использовать, чтобы определить, должны ли сеансы пользователей храниться на одном сервере, используя привязку сеансов на основе файлов cookie; независимо от того, хотите ли вы изящно удалить участников серверного пула с помощью сброса соединений или хотите использовать настраиваемые проверки работоспособности (например, если вы хотите указать собственные интервалы времени ожидания, переопределить имена хостов/пути для проверки или коды успешного ответа).

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

Шлюз приложений — заключительные этапы создания

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

Теперь о моменте истины. Давайте переназначим запись CNAME, которую мы настроили ранее, чтобы она указывала на наш шлюз приложений, а не на экземпляр службы приложений.

Совет. У вас есть несколько вариантов. Вы можете использовать запись A и сопоставить ее с IP-адресом шлюза приложений. В качестве альтернативы вы можете перейти к общедоступному IP-адресу и установить метку имени DNS (как описано здесь), чтобы вы могли просто переназначить существующую запись CNAME, которая у вас есть. Это именно то, что я собираюсь сделать. Я дал своему IP-адресу метку DNS-имени cwc-gateway. Поскольку он развернут в Северной Европе, это делает общий DNS cwc-gateway.northeurope.cloudapp.azure.com. Я укажу свою запись CNAME cwc-secured-app для cloudwithchris.com вместо cwc-secured-app.azurewebsites.net.

Шлюз приложений — настраиваемые проверки работоспособности

После обновления записей DNS перейдите в свой личный домен и взгляните на свое приложение во всей его красе! Или нет… Ой-ой. Вероятно, вы только что получили ответ HTTP 502 (неверный шлюз) от шлюза приложений.

На самом деле, это снова разрешимо (и логическая точка, которую мы достигли). Шлюз приложений отправляет проверку работоспособности на серверную часть (экземпляр службы приложений), чтобы определить, все ли в порядке. Помните, мы настроили Easy Auth для нашего экземпляра службы приложений? Зонд работоспособности, скорее всего, получил HTTP-ответ, который, по его мнению, не был успешным. По умолчанию ответ HTTP(S) с кодом состояния 200–399 считается работоспособным.

Поскольку Easy Auth применяется ко всему сайту (а не к странице за страницей или разделу за разделом), все конечные точки, скорее всего, будут отвечать с одним и тем же кодом состояния. Это означает, что мы, скорее всего, не сможем создать пользовательскую страницу конечной точки работоспособности, не требующую аутентификации. Поскольку этот пост в блоге стал довольно длинным, мы воспользуемся быстрым (хотя некоторые могут назвать его грязным) исправлением. Мы свяжем пользовательскую проверку работоспособности с нашими настройками HTTP в Шлюзе приложений.

Сначала создайте зонд работоспособности, который напоминает стандартные настройки зонда работоспособности —

  • Название: защищенное-приложение-здоровье-переопределения
  • Это отображаемое имя, которое больше нигде не используется, поэтому назовите его так, как считаете нужным.
  • Протокол: HTTPS
  • Поскольку мы настроили HTTPS на серверной части (экземпляр службы приложений), давайте удостоверимся, что мы тестируем это с помощью нашей проверки работоспособности.
  • Хост. Введите имя хоста вашего личного домена.
  • Это имя хоста, которое будет отправлено в запросе к вашей службе приложений. Это поле исчезнет, ​​если для параметра Выбрать имя хоста из настроек серверной части установлено значение Да.
  • Выберите имя хоста из настроек серверной части: Нет
  • Я предпочитаю быть явным в этой конфигурации, чтобы избежать сомнений. Поскольку мы направляемся в службу приложений, я хочу быть уверен, что домен azurewebsites.net не будет обнаружен нашей проверкой работоспособности. Вместо этого я переопределяю имя хоста в этой проверке работоспособности с помощью пользовательского домена, который мы настроили.
  • Путь: /
  • В реальной реализации я надеюсь увидеть использование шаблона мониторинга работоспособности конечной точки. Тем не менее, мы просто попытаемся исследовать корень сайта для целей этого поста.
  • Использовать условия проверки соответствия: Нет
  • Это позволит убедиться, что мы пока используем условия зонда по умолчанию.

После завершения нажмите Проверить внизу. Через несколько секунд я получаю сообщение об ошибке — Получен неверный код состояния: 401 в HTTP-ответе внутреннего сервера. В соответствии с конфигурацией зонда работоспособности допустимым кодом состояния является 200–399. Либо измените конфигурацию зонда, либо устраните внутренние проблемы. Подробнее.

Это делает его намного яснее, мы видим, что нам нужно включить 401 в качестве действительного кода ответа. Справедливости ради, в контексте этого приложения код состояния 401 (Unauthorized) означает, что приложение действительно запущено.

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

Перейдите к настройкам проверки работоспособности, установите для Use probe matching conditions значение «да» и добавьте 401 в список для HTTP response status codes to match (200–399 401 — это то, как я установил его для своей конфигурации, как показано на следующем снимке экрана). Проверьте датчик еще раз. На этот раз он должен успешно вернуться. Наконец, нажмите кнопку «Добавить» в нижней части экрана, чтобы связать пользовательскую проверку работоспособности с настройками HTTP, которые вы настроили ранее.

Подтвердите, что поток аутентификации работает через Шлюз приложений

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

Ограничение трафика к экземпляру службы приложений

Да, мы почти подошли к требованиям! Теперь нам просто нужно убедиться, что трафик не может напрямую попасть в экземпляр службы приложений и что он должен проходить через шлюз приложений. Для этого мы будем использовать Ограничения доступа к службе приложений и ограничим доступ только с общедоступного IP-адреса шлюза приложений.

Сначала перейдите к шлюзу приложений и запишите используемый общедоступный IP-адрес. После завершения перейдите к экземпляру службы приложений на портале Azure и выберите Сеть. Перейдите к ограничениям доступа.

Совет. Для этого сообщения в блоге я использую вариант Networking (preview). Я предпочитаю визуальный/диаграммный характер этого пользовательского интерфейса и считаю его гораздо более интуитивным. Не стесняйтесь использовать любой вариант, который вы предпочитаете.

Прежде чем применять какие-либо ограничения, перейдите к исходному URL-адресу своего экземпляра службы приложений (оканчивающемуся на azurewebsites.net). Вы должны заметить, что он по-прежнему общедоступен и доступен… пока.

На странице ограничений доступа вы должны увидеть две вкладки —

  • Один для nameofyourapp.azurewebsites.net (фактическое веб-приложение, которое вы развернули).
  • Один для nameofyourapp.scm.azurewebsites.net (конечная точка, используемая для управления консолью Kudu или используемая для публикации вашего приложения с помощью веб-развертывания).

Мы будем ограничивать тот, без scm в названии, чтобы не ограничивать какие-либо административные действия для песочницы/развертывания kudu. Конечно, при необходимости мы могли бы ограничить и конечную точку scm, но это выходит за рамки наших первоначальных требований.

Мы продолжим и создадим правило ограничения доступа следующим образом:

  • Имя: AppGatewayOnly
  • Действие: Разрешить
  • Приоритет: 100 (хотя на самом деле это не имеет значения, если мы не начнем добавлять больше правил. Правила оцениваются в порядке приоритета от низкого к высокому).
  • Описание: Разрешить обмен данными только Шлюзу приложений
  • Тип: IPv4
  • Блок IP-адреса Введите здесь IP-адрес шлюза приложений

После этого нажмите «Добавить правило».

После завершения вы должны заметить, что правило «Запретить все» было автоматически создано с очень высоким номером приоритета (это означает, что это правило обрабатывается последним).

Совет. Помните, что эти правила обрабатываются от меньших чисел к большим). Другими словами, если IP-адрес совпадает с IP-адресом нашего Шлюза приложений, трафик разрешен. В противном случае в нем отказано.

Теперь еще раз — перейдите к исходному URL-адресу вашего экземпляра службы приложений (тот, который заканчивается на azurewebsites.net). Вы должны заметить, что он больше не доступен. Вместо этого мы получаем Error 403 — Forbidden.

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

Итак, поехали! Благодаря этому мы смогли выполнить наши требования -

  • Приложение должно требовать проверки подлинности Azure Active Directory.
  • Это достигается с помощью Easy Auth в службе приложений
  • Веб-приложение не должно быть доступно напрямую через общедоступный Интернет.
  • Это достигается за счет использования ограничений доступа к службе приложений, чтобы разрешить трафик только из шлюза приложений..
  • Конечный пользователь должен иметь возможность подключиться к веб-приложению с помощью общедоступной записи DNS, чтобы он чувствовал, что это подлинный опыт.
  • Это достигается путем привязки личного домена к службе приложений, чтобы мы могли прозрачно передавать имя хоста из нашего многосайтового прослушивателя Шлюза приложений во внутренний экземпляр службы приложений.
  • Это снижает сложность необходимости использования правил перезаписи и т.п. и делает решение простым и управляемым.
  • Мы используем управляемый сертификат службы приложений, чтобы включить HTTPS в службе приложений.
  • Мы используем SSL-сертификат, созданный в другом месте (в моем случае, из ZeroSSL) в Шлюзе приложений, чтобы включить HTTPS-трафик.

Совет. Мы не можем экспортировать управляемый сертификат службы приложений для использования в другом месте (как задокументировано), например. в шлюзе приложений. Однако мы могли бы использовать SSL-сертификат, созданный и в другом месте службы приложений. Я воспользовался этой записью в блоге как возможностью продемонстрировать преимущества сертификатов, управляемых службой приложений.**

Это оказалось более длинное сообщение в блоге, чем я ожидал, но было весело писать. Я надеюсь, что это было полезно. Я хотел бы услышать ваши комментарии! Есть ли у вас какие-либо дополнительные мысли о том, как вы могли бы подойти к требованиям? Есть ли области, к которым вы бы подошли по-другому? Дайте мне знать в Твиттере, @reddobowen. Было ли это полезно? Вы бы предпочли использовать это как серию отдельных сообщений в блоге, а не как один длинный пост?

На этом спасибо за чтение. До следующего поста в блоге, пока!