Subdomain Isolationの有効化

Subdomain Isolationについて

Subdomain Isolationは、クロスサイトスクリプティングや関連するその他の脆弱性を緩和します。詳しくは、Wikipedia の「クロスサイトスクリプティング」をご覧く� さい。 your GitHub Enterprise Server instanceで Subdomain Isolation を有効にすることを強くお勧めします。

Subdomain Isolation が有効な� �合、GitHub Enterprise Server はいくつかのパスをサブドメインで置き換えます。 Subdomain Isolation を有効にした後は、ユーザーが提供した何らかのコンテンツに対する以前のパス (http(s)://HOSTNAME/raw/ など) にアクセスしようとすると、404 エラーが返される� �合があります。

Subdomain Isolationなしのパス	Subdomain Isolationされたパス
`http(s)://HOSTNAME/`	`http(s)://docker.HOSTNAME/`
`http(s)://HOSTNAME/_registry/npm/`	`https://npm.HOSTNAME/`
`http(s)://HOSTNAME/_registry/rubygems/`	`https://rubygems.HOSTNAME/`
`http(s)://HOSTNAME/_registry/maven/`	`https://maven.HOSTNAME/`
`http(s)://HOSTNAME/_registry/nuget/`	`https://nuget.HOSTNAME/`
`http(s)://HOSTNAME/assets/`	`http(s)://assets.HOSTNAME/`
`http(s)://HOSTNAME/avatars/`	`http(s)://avatars.HOSTNAME/`
`http(s)://HOSTNAME/codeload/`	`http(s)://codeload.HOSTNAME/`
`http(s)://HOSTNAME/gist/`	`http(s)://gist.HOSTNAME/`
`http(s)://HOSTNAME/media/`	`http(s)://media.HOSTNAME/`

前提条件

警告: Subdomain Isolation を無効化している� �合は、エンタープライズの GitHub Pages も無効化することをおすすめします。ユーザが提供するGitHub Pagesのコンテンツをその他のEnterpriseのデータから分離しておく方法はありません。詳細については、「エンタープライズで GitHub Pages を構成する」を参照してく� さい。

Subdomain Isolationを有効化する前に、新しいドメインに合わせてネットワークを設定しなければなりません。

有効なドメイン名を、IP アドレスではなくホスト名として指定します。詳しくは、「ホスト名の設定」をご覧く� さい。

警告: 初期セットアップ後に GitHub Enterprise Server のホスト名を変更しないでく� さい。ホスト名を変更すると、インスタンスの停止に及ぶ予想外の動作が生じます。

上記のサブドメインに対して、ワイルドカードのドメインネー� システ� (DNS) レコードまたは個々の DNS レコードをセットアップします。サブドメインごとに複数のレコードを作成する必要がないように、サーバーの IP アドレスを指す *.HOSTNAME の A レコードを作成することをお勧めします。
HOSTNAME とワイルドカードドメイン *.HOSTNAME の両方にサブジェクトの別名 (SAN) を使って、*.HOSTNAME に対するワイルドカードトランスポート層セキュリティ (TLS) 証明書を取得します。たとえば、ホスト名が github.octoinc.com の� �合は、共通名の値を *.github.octoinc.com に設定し、SAN の値を github.octoinc.com と *.github.octoinc.com の両方に設定して、証明書を取得します。
アプライアンスで TLS を有効にします。詳細については、「TLS の構成」を参照してく� さい。