Параметры веб-сайта и безопасность для Azure DevOps локальной среде

  • Статья

| TFS 2017 | TFS 2015 TFS 2013

История

Для многих выпусков параметры веб-сайта по умолчанию для Azure DevOps Server, ранее названные Team Foundation Server (TFS), были:

  • Одна привязка HTTP для веб-сайта Azure DevOps Server на порте 8080 без указанного имени узла или IP-адреса.
  • Общедоступный URL-адрес (ранее называемый URL-адресом уведомления) формы http://machine-name:8080/tfs.

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

  • Использование ПРОТОКОЛА HTTP, а не HTTPS позволяет избежать необходимости получения и установки сертификатов.
  • Использование 8080 вместо 80 позволяет избежать потенциальных конфликтов с другими сайтами на том же компьютере.
  • Использование tfs в качестве виртуального каталога сайта упрощает размещение Azure DevOps Server и других веб-сайтов на том же порту на том же сервере.
  • Использование имени компьютера, а не полного доменного имени (FQDN) в общедоступном URL-адресе позволяет сэкономить много текста.
  • Если имя узла в привязке не указано, это обеспечивает гибкость при подключении : имя компьютера, полное доменное имя или IP-адрес будут работать, когда пользователи пытаются подключиться к своим серверам.

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

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

Учитывая все это, мы решили, что пришло время более решительно отстаивать использование привязок HTTPS в Azure DevOps Server развертываниях.

Группы параметров

В TFS 2017 представлены параметры конфигурации веб-сайта во всех сценариях конфигурации сервера. Предоставляются несколько групп параметров, которые объединяют сочетания привязок сайтов, виртуальных каталогов и общедоступных URL-адресов, которые мы рекомендуем и считаем, будут наиболее часто использоваться. В сценариях, где ни одна из этих групп параметров не подходит, параметры можно полностью настроить с помощью диалогового окна "Изменить сайт Параметры".

Default setting group

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

HTTPS and HTTP with redirect setting group.

Группа параметров HTTPS и HTTP (с перенаправлением) подготавливает две привязки:

  • Одна привязка HTTPS через порт 443 с полным доменным именем (FQDN) компьютера в качестве имени узла.
  • Одна привязка HTTP через порт 80 снова с полным доменным именем компьютера в качестве имени узла.

Привязка HTTP через порт 80 добавляется только в качестве удобства для конечных пользователей . Перенаправление настроено таким образом, чтобы весь трафик в конечном итоге использовал привязку HTTPS через порт 443. Общедоступный URL-адрес для этой группы параметров имеет форму https://fully-qualified-domain-name. По умолчанию эта группа параметров подготавливает новые самозаверяющие сертификаты и использует их для привязки HTTPS. Как правило, не рекомендуется использовать самозаверяющий сертификат для рабочих развертываний TFS. Дополнительные сведения об использовании самозаверяемых сертификатов и других доступных параметрах см. в разделе "Параметры сертификата" ниже.

Группа параметров HTTPS подготавливает одну привязку HTTPS через порт 443 с полным доменным именем компьютера в качестве имени узла. Опять же, общедоступный URL-адрес для этой группы параметров имеет форму https://fully-qualified-domain-name, и самозаверяющий сертификат будет подготовлен по умолчанию.

Группа параметров HTTP подготавливает одну привязку HTTP через порт 80 без указанного имени узла. Общедоступный URL-адрес для этой группы параметров имеет форму http://machine-name.

При использовании группы параметров HTTPS и HTTP (с перенаправлением) не рекомендуется использовать общедоступный URL-адрес HTTP. Большинство современных браузеров считают небезопасное содержимое HTTP и HTTPS по умолчанию и может отображать пустые страницы. Хотя обычно можно переопределить параметры браузера по умолчанию и разрешить небезопасное содержимое, это приведет к просмотру сайта с истекшим сроком действия SSL-сертификата.

Варианты использования сертификата

Развертывание веб-сайтов с помощью привязок HTTPS и шифрования SSL/TLS тесно связано с более широкой темой инфраструктуры открытых ключей (PKI), которая представляет собой обширную и интересную тему, для которой уже существует широкий спектр документации. Мы не будем пытаться охватить всю сложность здесь, а сосредоточиться на высокоуровневых параметрах настройки привязок HTTPS для Azure DevOps Server развертываний. Многие организации имеют определенные политики по развертыванию сертификатов, поэтому первый шаг в принятии решения о том, какой сертификат следует использовать для развертывания Azure DevOps Server, часто связан с группой информационных технологий уровня организации.

Возможны следующие значения.

  • Разрешение мастеру настройки TFS создавать самозаверяющие сертификаты для использования развертыванием.
  • Получение сертификата из внутреннего центра сертификации.
  • Получение сертификата из внешнего центра сертификации.

Самозаверяющие сертификаты

Самозаверяющий сертификат полезен для пробных развертываний Azure DevOps Server, так как они очень просты в подготовке и использовании. Они менее подходят для рабочих развертываний Azure DevOps Server, и мы не рекомендуем их использовать для Azure DevOps Server развертываний, предоставляемых общедоступному Интернету. Как правило, самозаверяющий сертификат подвержен атакам типа "злоумышленник в середине". Они также вызывают проблемы для пользователей, так как они будут вызывать предупреждения и ошибки сертификатов до тех пор, пока их корневые сертификаты не будут установлены на каждом клиентском компьютере. Например, в браузере Edge отобразится следующая ошибка.

Certificate errors in Edge.

Когда мастер настройки TFS создает самозаверяющие сертификаты для развертывания, он создаст два — один из них, который помещается в хранилище доверенных корневых центров сертификации на сервере, а второй , подписанный первым, который помещается в личное хранилище на сервере и используется Azure DevOps Server. Настройка действий таким образом помогает снизить вероятность атак "злоумышленник в середине" и позволяет сменить сертификат, используемый в привязке HTTPS, без необходимости распространять новый сертификат для всех клиентов, чтобы избежать ошибок сертификата, как показано выше.

Чтобы избежать таких предупреждений и ошибок сертификата, можно экспортировать корневой сертификат и установить его на клиентских компьютерах. Это можно сделать несколькими способами, в том числе:

  • С помощью оснастки MMC "Сертификаты" можно вручную экспортировать сертификат на сервере, а затем импортировать его на каждый клиент.
  • С помощью командлета PowerShell export-Certificate, доступного в Windows 8/ Windows Server 2012 и более поздних операционных системах, для экспорта сертификата. Затем импорт сертификата можно использовать для импорта на каждом клиенте.
  • Использование групповая политика для автоматизации распространения для клиентов.

Внутренние и внешние центры сертификации

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

Если другие параметры не подходят или недоступны, сертификаты могут быть получены (как правило, по стоимости) из внешнего центра сертификации (ЦС). Инструкции по этому процессу, который начинается с создания запроса на подпись сертификата, можно найти на большинстве веб-сайтов ЦС. Некоторые важные примечания.

  • Убедитесь, что общее имя, указанное в запросе сертификата, совпадает с именем узла, которое вы хотите указать в общедоступном URL-адресе, например, tfs.contoso.com.
  • В свойствах поставщика служб шифрования рекомендуется выбрать поставщик шифрования Microsoft RSA SChannel и длину 2048 или больше.

Изменение общедоступного URL-адреса

Следует также отметить, что при обновлении существующего развертывания Azure DevOps Server изменение общедоступного URL-адреса повлияет на конечных пользователей. Хотя мы по-прежнему рекомендуем преобразовывать привязки HTTP в HTTPS, Visual Studio клиентские подключения должны быть восстановлены, старые закладки больше не будут разрешаться должным образом и т. д. Поэтому важно координировать такие изменения с пользователями Azure DevOps Server развертывания, чтобы избежать значительных нарушений.