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

TFS 2017 |TFS 2015 |TFS 2013

背景

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

  • ホスト名も IP アドレスも指定Azure DevOps Server、ポート 8080 上の Web サイトに対する単一の HTTP バインディング。
  • 形式のパブリック URL (以前は通知 URL と呼ばばしい)。 http://machine-name:8080/tfs

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

  • 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 の組み合わせがまとめられ、最も一般的に使用されるようになります。 これらの設定グループのいずれも適切でないシナリオでは、[サイト設定の編集] ダイアログボックスを使用して設定を完全にカスタマイズできます。

Default setting group

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

HTTPS and HTTP with redirect setting group

HTTPS および HTTP (リダイレクト) 設定グループには、次の2つのバインドが用意されています。

  • ホスト名としてコンピューターの完全修飾ドメイン名 (FQDN) を使用した、ポート443の1つの HTTPS バインディング。
  • ホスト名としてコンピューターの FQDN を使用して、ポート80の1つの HTTP バインディング。

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

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

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

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

証明書のオプション

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

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

  • 展開で使用する自己署名証明書を TFS 構成ウィザードで生成することを許可します。
  • 内部証明機関から証明書を取得する。
  • 外部証明機関から証明書を取得する。

自己署名証明書

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

Certificate errors in Edge

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

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

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

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

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

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

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

パブリック URL の変更

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