Поделиться через

Параметры веб-сайта и безопасность для локальной среды 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 и из 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 и 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 отобразит приведенную ниже ошибку.

Ошибки сертификата в Edge.

Когда мастер настройки TFS создает самозаверяющие сертификаты для развертывания, он создает два сертификата: один из них помещается в хранилище доверенных корневых центров сертификации на сервере, а второй, подписанный первым, который помещается в личное хранилище на сервере и используется Azure DevOps Server. Такая настройка помогает снизить вероятность атак "злоумышленник в середине" и обеспечивает смену сертификата, используемого в привязке 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 развертывания, чтобы избежать значительных сбоев.