Параметры веб-сайтов и безопасность для локальной службы 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-адресе сохраняется множество типов.
  • Если не указать имя узла в привязке, это позволит обеспечить гибкость в подключении, имени компьютера, FQDN или 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 развертываний, предоставляемых в общедоступном Интернете. Как правило, самозаверяющие сертификаты уязвимы для атак типа "злоумышленник в середине". Они также вызывают проблемы для пользователей, так как они будут вызывать предупреждения и ошибки сертификатов, пока их корневые сертификаты не будут установлены на каждом клиентском компьютере. Например, в браузере ребра отобразится следующая ошибка.

Certificate errors in Edge

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

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

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

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

Многие крупные организации имеют собственную инфраструктуру открытых ключей и могут выдавать сертификаты из собственных центров сертификации. Как правило, если это так, доверенные корневые сертификаты для этих центров будут уже распространяться на клиентские компьютеры, что позволяет избежать необходимости распределять дополнительные сертификаты для 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ного развертывания, чтобы избежать значительного перерыва в работе.