次の方法で共有

オンプレミスの Azure DevOps の Web サイト設定とセキュリティ

  • [アーティクル]

TFS 2017 | TFS 2015 | TFS 2013

バックグラウンド

多くのリリースでは、以前に Team Foundation Server (TFS) という名前のAzure DevOps Serverの既定の Web サイト設定は次のとおりです。

  • ポート 8080 のAzure DevOps Server Web サイトの 1 つの HTTP バインド。ホスト名または IP アドレスは指定されません。
  • フォーム http://machine-name:8080/tfsのパブリック URL (以前は通知 URL と呼ばれた) です。

これらの設定の主な利点は、設定が非常に簡単で、ほとんどのシナリオでエンド ユーザーにとって便利であるということです。 特に次の点に違いがあります。

  • HTTPS ではなく HTTP を使用すると、証明書を取得してインストールする必要がなくなります。
  • 80 ではなく 8080 を使用すると、同じコンピューター上の他のサイトとの競合の可能性を回避できます。
  • サイトの仮想ディレクトリとして "tfs" を使用すると、同じサーバー上の同じポートでAzure DevOps Serverやその他の Web サイトを簡単にホストできます。
  • パブリック URL で完全修飾ドメイン名 (FQDN) ではなくマシン名を使用すると、多くの入力が保存されます。
  • バインドにホスト名を指定しないと、ユーザーがサーバーに接続しようとしたときに、マシン名、FQDN、または IP アドレスを柔軟に接続できます。

ただし、これらの設定は既定ではセキュリティで保護されていません。 特に、HTTPS バインディングを使用しないことにより、IPSec などの他のソリューションを使用しない限り、Azure DevOps Serverとの間の通信は転送中に暗号化されません。 したがって、悪意のあるアクターが通信の内容を監視したり、変更したりする可能性があります。 これらの問題は、Azure DevOps Serverが企業のファイアウォールの内側のイントラネットにデプロイされている場合、Azure DevOps Serverインスタンスの大部分が存在するため、ある程度軽減されます。 ただし、これらのシナリオでも、Azure DevOps Serverとの間で送受信されるデータには、ソース コード、作業項目データ、その他の情報が含まれており、多くの場合、追加のセキュリティの恩恵を受ける可能性があります。

さらに、TFS 2017 では、ベアラー トークンをネットワーク経由で送信する新しい認証シナリオ (ビルド/リリース エージェント サービス アカウント認証、個人用アクセス トークン) が存在します。 これらのトークンが悪意のあるユーザーによって取得された場合は、そのトークンを使用して、自分が属するユーザーを偽装できます。

これらすべてのことを考えると、Azure DevOps Serverデプロイでの HTTPS バインディングの使用をより強く支持する時期が来たと判断しました。

設定グループ

TFS 2017 では、すべてのサーバー構成シナリオで Web サイト設定の構成オプションが表示されます。 いくつかの設定グループが用意されており、サイト バインド、仮想ディレクトリ、パブリック URL の組み合わせがバンドルされています。推奨され、最も一般的に使用されると考えられます。 これらの設定グループが適切でないシナリオでは、[サイト設定の編集] ダイアログを使用して設定を完全にカスタマイズできます。

既定の設定グループ

[既定の設定] グループには、以前のバージョンのAzure DevOps Serverで使用されていたのと同じ設定が含まれています。 上記のすべての理由から、これらの設定は引き続き新しいAzure DevOps Server展開の既定値です。 既存のデプロイでは、既存の設定を保持しようとします。これにより、多くの場合、既定の設定グループが選択されます。

リダイレクト設定グループを含む HTTPS と HTTP。

HTTPS と HTTP (リダイレクトあり) 設定グループは、次の 2 つのバインディングをプロビジョニングします。

  • ホスト名としてマシンの完全修飾ドメイン名 (FQDN) を持つポート 443 の 1 つの HTTPS バインド。
  • ポート 80 の 1 つの HTTP バインド。もう一度、マシンの FQDN をホスト名として使用します。

ポート 80 の HTTP バインディングは、エンド ユーザーにとって便利な方法としてのみ追加されます。リダイレクトは、すべてのトラフィックがポート 443 で HTTPS バインディングを使用するように構成されます。 この設定グループのパブリック URL は フォームです https://fully-qualified-domain-name. 既定では、この設定グループは新しい自己署名証明書をプロビジョニングし、HTTPS バインドに使用します。 通常、運用環境の TFS 展開に自己署名証明書を使用することはお勧めしません。 自己署名証明書を使用するのが適切な場合とその他のオプションの詳細については、以下の「証明書オプション」を参照してください。

HTTPS のみの設定グループは、ホスト名としてマシンの FQDN を使用して、ポート 443 に 1 つの HTTPS バインドをプロビジョニングします。 ここでも、この設定グループのパブリック URL は という形式 https://fully-qualified-domain-nameで、自己署名証明書は既定でプロビジョニングされます。

HTTP のみの設定グループは、ホスト名が指定されていないポート 80 で 1 つの HTTP バインディングをプロビジョニングします。 この設定グループのパブリック URL は フォームです http://machine-name.

HTTPS および HTTP (リダイレクトあり) 設定グループを使用する場合は、HTTP パブリック URL の使用は推奨されません。 ほとんどの最新のブラウザーでは、HTTP と HTTPS の混在コンテンツが既定で安全ではないと見なされ、空のページが表示される場合があります。 通常、既定のブラウザー設定をオーバーライドして安全でないコンテンツを許可することは可能ですが、これにより、有効期限が切れた SSL 証明書を使用してサイトを閲覧するのと同様のエクスペリエンスが発生します。

証明書のオプション

HTTPS バインディングと SSL/TLS 暗号化を使用した Web サイトの展開は、公開キー インフラストラクチャ (PKI) の広範なトピックと密接に関連しています。これは、さまざまなドキュメントが既に存在する豊富で興味深いトピックです。 ここでは、すべての複雑さについて説明するのではなく、Azure DevOps Serverデプロイ用に HTTPS バインドを構成するための高レベルのオプションに焦点を当てます。 多くの組織には証明書の展開に関する特定のポリシーがあるため、Azure DevOps Server展開に使用する証明書を決定する最初の手順は、多くの場合、organization レベルの情報テクノロジ グループと対話することです。

次のオプションがあります。

  • TFS 構成ウィザードで、展開で使用する自己署名証明書を生成できるようにします。
  • 内部証明機関からの証明書の取得。
  • 外部証明機関から証明書を取得する。

自己署名証明書

自己署名証明書は、プロビジョニングと使用が非常に簡単であるため、Azure DevOps Serverの試用版のデプロイに役立ちます。 Azure DevOps Serverの運用環境の展開には適していません。パブリック インターネットに公開されるAzure DevOps Server展開には使用しないことをお勧めします。 一般に、自己署名証明書は中間者攻撃の影響を受けやすくなります。 また、ルート証明書が各クライアント コンピューターにインストールされるまで証明書の警告とエラーが発生するため、ユーザーに問題が発生します。 たとえば、Edge ブラウザーには次のエラーが表示されます。

Edge の証明書エラー。

TFS 構成ウィザードによって展開用の自己署名証明書が生成されると、サーバー上の信頼されたルート証明機関ストアに配置される証明書と、サーバー上の個人用ストアに配置され、Azure DevOps Serverによって使用される 1 つ目の証明書が作成されます。 この方法で設定すると、中間者攻撃の可能性を軽減し、HTTPS バインディングで使用される証明書のローテーションを可能にします。また、上記のような証明書エラーを回避するために、すべてのクライアントに新しい証明書を配布する必要もありません。

これらの証明書の警告とエラーを回避するには、ルート証明書をエクスポートし、クライアント コンピューターにインストールします。 これを実現するには、次のようないくつかの方法があります。

  • 証明書 MMC スナップインを使用してサーバー上の 証明書を 手動でエクスポートし、各クライアントにインポートします。
  • 証明書をエクスポートするには、Windows 8/Windows Server 2012 以降のオペレーティング システムで使用できる Export-Certificate powershell コマンドレットを使用します。 その後、Import-Certificate を使用して各クライアントにインポートできます。
  • グループ ポリシーを使用してクライアントへの配布を自動化する。

内部および外部の証明機関

多くの大規模な組織には独自の公開キー インフラストラクチャがあり、独自の証明機関から証明書を発行できます。 通常、この場合、これらの機関の信頼されたルート証明書は既にクライアント コンピューターに配布されるため、Azure DevOps Server用に追加の証明書を配布する必要がなくなります。 organizationに独自の公開キー インフラストラクチャがある場合は、Azure DevOps Serverデプロイに適したオプションです。

その他のオプションが適切でない場合、または使用できない場合は、外部証明機関 (CA) から証明書を取得できます (通常はコストがかかります)。 証明書 署名要求の作成から始まるこのプロセスの手順は、ほとんどの CA Web サイトで確認できます。 重要な注意事項:

  • 証明書要求で指定された共通名が、パブリック URL に必要なホスト名 (たとえば、tfs.contoso.com) と一致していることを確認します。
  • [暗号化サービス プロバイダーのプロパティ] で、Microsoft RSA SChannel 暗号化プロバイダーとビット長 2048 以上を選択することをお勧めします。

パブリック URL の変更

また、既存のAzure DevOps Server展開をアップグレードする場合、パブリック URL を変更するとエンド ユーザーに影響を与えることにも注意してください。 引き続き HTTP から HTTPS バインドへの変換をお勧めしますが、Visual Studio クライアント接続を再確立する必要があります。古いブックマークは正しく解決されなくなります。 そのため、大きな中断を避けるために、この種の変更をAzure DevOps Server展開のユーザーと調整することが重要です。