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

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

Группа параметров 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 Only предусматривает одну 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 отобразится следующая ошибка.

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

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

• С помощью модуля MMC сертификатов можно вручную экспортировать сертификат на сервере, а затем импортировать его на каждом клиенте.
• С помощью командлета PowerShell export-Certificate , доступного в операционных системах Windows 8 или Windows Server 2012 и более поздних версий, для экспорта сертификата. Import-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, чтобы избежать значительных нарушений.