Skip to main content

Enterprise Server 3.15 は、現在リリース候補として使用できます。

システムの概要

GitHub Enterprise Server のシステム内部、機能、セキュリティについて詳しく説明します。

GitHub Enterprise Server について

GitHub Enterprise Server は、GitHub プラットフォームのセルフホステッド バージョンです。 GitHub は、自己完結型の仮想アプライアンスとして GitHub Enterprise Server を配布します。 仮想マシンをプロビジョニングしてアプライアンスをインストールすると、インスタンスはカスタム アプリケーション スタックを使って Linux オペレーティング システムを実行します。 詳しくは、「GitHub Enterprise Server について」を参照してください。

ストレージ アーキテクチャ

GitHub Enterprise Server には 2 つのストレージ ボリュームが必要です。1 つは "ルート ファイルシステム" パス (/) にマウントされ、もう 1 つは "ユーザー ファイルシステム" パス (/data/user) にマウントされます。 このアーキテクチャは、動作するソフトウェアの環境を永続的なアプリケーションデータから分離することによって、アップグレード、ロールバック、リカバリの手続きをシンプルにします。

ルートファイルシステムは、配布されているマシンイメージに含まれています。 ルート ファイルシステムにはベースのオペレーティング システムと GitHub Enterprise Server アプリケーション環境が含まれています。 ルートファイルシステムは、一過性のものとして扱われなければなりません。 ルート ファイルシステム上にあるデータは、すべて将来の GitHub Enterprise Server リリースへのアップグレード時に置き換えられます。

ルート ストレージ ボリュームは、同じサイズの 2 つのパーティションに分割されます。 パーティションの 1 つがルート ファイルシステム (/) としてマウントされます。 もう 1 つのパーティションは、必要に応じて簡単にロールバックできるように、アップグレードとアップグレードのロールバック中にのみ /mnt/upgrade としてマウントされます。 たとえば、 400 GB のルート ボリュームが割り当てられている場合、200 GB がルート ファイルシステムに割り当てられ、200 GB がアップグレードやロールバック用に予約されます。

3.14 以降の新規インストールでは、ルート ストレージ ボリュームは 4 つのパーティションに分割されます。 サポートされているブート モード (BIOS と UEFI) 用の小さなパーティションが 2 つあり、他の 2 つの同じサイズのパーティションは GitHub Enterprise Server プライマリ用であり、アップグレードとロールバック用です。

ルート ファイルシステムには、次の情報を格納するファイルが含まれています。 このリストは全てを網羅しているわけではありません。

  • カスタムの証明機関 (CA) 証明書 (/usr/local/share/ca-certificates*)
  • カスタムのネットワーク設定
  • カスタムのファイアウォール設定
  • レプリケーションの状態

ユーザー ファイルシステムには、次の構成とデータを格納するファイルが含まれています。 このリストは全てを網羅しているわけではありません。

  • Git リポジトリ
  • データベース
  • インデックスの検索
  • GitHub Pages サイトで公開されたコンテンツ
  • Git Large File Storage からの大きなファイル
  • pre-receive フック環境

展開トポロジ

既定では、GitHub Enterprise Server はスタンドアロン インスタンスとして実行されます。 デプロイに別のトポロジを使うことで、GitHub Enterprise Server の信頼性とパフォーマンスを向上させることができます。

  • システムまたはネットワークの障害の影響を軽減するために、パッシブ レプリカ インスタンスをデプロイできます。 プライマリ インスタンスに影響する障害が発生した場合は、レプリカ インスタンスに手動でフェールオーバーできます。 詳しくは、「High Availability設定について」を参照してください。
  • 複数のアクティブ レプリカを構成して、プライマリ インスタンスから地理的に離れている開発者のパフォーマンスを向上させることができます。 詳しくは、「Geo-replicationについて」を参照してください。
  • 数万人の開発者がいる一部の企業は、垂直方向ではなく水平方向にスケーリングするクラスター構成の恩恵を受ける場合があります。 詳しくは、「クラスタリングについて」を参照してください。

データのリテンションとデータセンターの冗長性

警告: GitHub Enterprise Server を運用環境で使う前に、バックアップとディザスター リカバリー計画を設定しておくことを強くおすすめします。

GitHub Enterprise Server には、GitHub Enterprise Server Backup Utilities でのオンラインおよび増分バックアップのサポートが含まれています。 インクリメンタルスナップショットは、オフサイトや地理的に離れたストレージのために長距離を経てセキュアなネットワークリンク(SSH管理ポート)経由で取ることができます。 スナップショットは、プライマリ データセンターにおける災害時の復旧において、新たにプロビジョニングされたインスタンスにネットワーク経由で復元できます。

ネットワーク バックアップに加えて、インスタンスがオフラインになっているかメンテナンス モードになっている間の、ユーザー ストレージ ボリュームの AWS (EBS) や VMware のディスク スナップショットがサポートされています。 サービスレベルの要求が定期的なオフラインメンテナンスを許せるものであれば、定期的なボリュームのスナップショットは、GitHub Enterprise Server Backup Utilitiesのネットワークバックアップの低コストで複雑さの低い代替になります。

詳しくは、「インスタンスでのバックアップの構成」を参照してください。

セキュリティ

GitHub Enterprise Server は、ユーザーのインフラストラクチャ上で実行され、ファイアウォール、ネットワーク ポリシー、IAM、監視、VPN など、ユーザーが定義するアクセスとセキュリティの制御によって管理されます。 GitHub Enterprise Server は、規制コンプライアンスの対象となる企業で使うのに適しており、パブリック クラウドのソフトウェア開発プラットフォームから発生する問題を回避するのに役立ちます。

GitHub Enterprise Server には、追加のセキュリティ機能も含まれています。

オペレーティングシステム、ソフトウェア、パッチ

GitHub Enterprise Server は、必要なアプリケーションとサービスのみを備えた、カスタマイズされた Linux を実行します。 GitHub は、標準的な製品リリース サイクルの一環として、インスタンスのコア オペレーティング システムに対するパッチを配布します。 パッチは、GitHub Enterprise Server の機能、安定性、重大でないセキュリティ問題に対処するものです。 また、GitHub は、必要に応じて標準的なリリース サイクル外でも重要なセキュリティ パッチを提供します。

GitHub Enterprise Server はアプライアンスとして提供され、オペレーティング システム パッケージの多くは通常の Ubuntu ディストリビューションと比較して変更されます。 この理由 (オペレーティング システムのアップグレードを含む) では、基になるオペレーティング システムの変更はサポートされていません。これは、GitHub Enterprise Server ライセンスおよびサポート契約のセクション 11.3 免責に準拠しています。

現在、GitHub Enterprise Server のベース オペレーティング システムは Ubuntu 20 (Focal Fossa) です。

定期的なパッチ更新プログラムは、GitHub Enterprise Server リリース ページでリリースされ、リリース ノート ページで詳しい情報が提供されます。 これらのパッチには、通常、エンジニアリング チームによってテストと、品質の承認が行われた後に、アップストリーム ベンダーとプロジェクトのセキュリティ パッチが含まれます。 アップストリームの更新プログラムがリリースされた時点から、次の GitHub Enterprise Server パッチ リリースでテストおよびバンドルされるまでに、わずかな時間の遅延が発生する可能性があります。

ネットワークのセキュリティ

GitHub Enterprise Server の内部ファイアウォールにより、インスタンスのサービスへのネットワーク アクセスが制限されます。 アプライアンスが機能するために必要なサービスだけが、ネットワークを通じて利用できます。 詳しくは、「ネットワーク ポート」を参照してください。

アプリケーションのセキュリティ

GitHub のアプリケーション セキュリティ チームは、GitHub Enterprise Server も含めた GitHub 製品に対する脆弱性評価、侵入テスト、コード レビューにフルタイムで重点的に取り組んでいます。 また、GitHub は、GitHub 製品の特定時点におけるセキュリティ評価を行うために、外部セキュリティ企業と契約しています。

外部サービスおよびサポートへのアクセス

GitHub Enterprise Server は、お客様のネットワークから外部サービスへのエグレス アクセスなしで運用できます。 また、メール配信、外部モニタリング、およびログ転送のため、外部サービスとのインテグレーションを有効にすることも可能です。 詳しくは、「通知のためのメール設定」、「外部モニタリングのセットアップ」、「ログの転送」をご覧ください。

トラブルシューティングデータを手動で収集し、GitHub Support に送信できます。 詳しくは、「GitHub Support へのデータの提供」を参照してください。

暗号化通信

GitHub は、GitHub Enterprise Server がお客様の社内ファイアウォールの背後で動作するように設計しています。 回線を介した通信を保護するため、Transport Layer Security (TLS) を有効化するようお勧めします。 GitHub Enterprise Server は、HTTP トラフィックに対して、2048 ビット以上の商用 TLS 証明書をサポートしています。 詳しくは、「TLSの設定」を参照してください。

既定では、Git によるリポジトリへのアクセスと管理の両方の目的で、インスタンスによって Secure Shell (SSH) アクセスも提供されます。 詳細については、「SSH について」および「管理シェル (SSH) にアクセスする」を参照してください。

お使いの GitHub Enterprise Server インスタンス に対して SAML 認証を構成する場合は、インスタンスと SAML IdP の間で暗号化されたアサーションを有効にすることができます。 詳しくは、「Enterprise IAM での SAML の使用」を参照してください。

ユーザおよびアクセス権限

GitHub Enterprise Server には 3 種類のアカウントがあります。

  • admin Linux ユーザー アカウントは、ファイルシステムやデータベースへの直接的なアクセスを含め、基になるオペレーティング システムに対して制御されたアクセスを行うことができます。 このアカウントには、少数の信頼できる管理者がアクセスできるようにすべきで、SSH を介してアクセスできます。 詳しくは、「管理シェル (SSH) にアクセスする」を参照してください。
  • インスタンスの Web アプリケーション内のユーザー アカウントは、自らのデータと、他のユーザーや Organization が明示的に許可したあらゆるデータへのフル アクセスができます。
  • インスタンスの Web アプリケーション内のサイト管理者は、高レベルの Web アプリケーションおよびインスタンスの設定、ユーザーおよび Organization のアカウント設定、リポジトリ データを管理できるユーザー アカウントです。

GitHub Enterprise Server のユーザーのアクセス許可について詳しくは、「GitHub 上のアクセス権限」を参照してください。

認証

GitHub Enterprise Server には、4 つの認証方式が提供されています。

  • SSH 公開鍵認証は、Git によるリポジトリへのアクセスと、管理シェルアクセスの両方を提供します。 詳細については、「SSH について」および「管理シェル (SSH) にアクセスする」を参照してください。
  • HTTP クッキーを用いたユーザ名とパスワードによる認証では、ウェブアプリケーションのアクセスおよびセッションの管理、そして任意で 2 要素認証 (2FA) を提供します。 詳しくは、「ビルトイン認証の設定」を参照してください。
  • LDAP サービス、SAML アイデンティティプロバイダ (IdP)、またはその他互換性のあるサービスを用いた外部 LDAP、SAML、および CAS 認証は、ウェブアプリケーションへのアクセスを提供します。 詳しくは、「Enterprise IAM での SAML の使用」を参照してください。
  • OAuth および personal access token は、外部クライアントとサービスの両方に対して、Git リポジトリデータおよび API へのアクセスを提供します。 詳しくは、「個人用アクセス トークンを管理する」を参照してください。

監査およびアクセスのログ取得

GitHub Enterprise Server では、従来型オペレーティング システムおよびアプリケーションの両方のログが保存されます。 また、詳しい監査およびセキュリティのログもアプリケーションで記録され、GitHub Enterprise Server で永続的に保存されます。 syslog-ng プロトコルを介して、両方の種類のログをリアルタイムで複数の宛先に転送できます。 詳細については、「企業の監査ログについて」および「ログの転送」を参照してください。

アクセスログと監査ログには、以下のような情報が含まれています。

アクセス ログ

  • ブラウザと API アクセスの両方の、ウェブサーバーの完全なログ
  • Git、HTTPS、および SSH プロトコルを介した、リポジトリデータへのアクセスの完全なログ
  • HTTPS および SSH を介した、管理アクセスのログ

監査ログ

  • ユーザのログイン、パスワードのリセット、2 要素認証のリクエスト、メール設定の変更、ならびに許可されたアプリケーションおよび API への変更
  • ユーザアカウントやリポジトリのアンロックなどの、サイト管理者のアクション
  • リポジトリのプッシュイベント、アクセス許可、移譲、および名前の変更
  • チームの作成および破棄を含む、Organization のメンバーシップ変更

GitHub Enterprise Server のオープンソース依存性

インスタンスのバージョンの GitHub Enterprise Server における依存関係の完全な一覧は、それぞれのプロジェクトのライセンスと合わせて http(s)://HOSTNAME/site/credits で見ることができます。

依存関係と関連するメタデータの完全な一覧と合わせて、tarball 群がインスタンス上にあります。

  • すべてのプラットフォームに共通する依存関係の場合は、/usr/local/share/enterprise/dependencies-<GHE version>-base.tar.gz を参照してください。
  • 固有のプラットフォームの依存関係の場合は、/usr/local/share/enterprise/dependencies-<GHE version>-<platform>.tar.gz を参照してください。

依存関係とメタデータの完全な一覧と共に、Tarball も https://enterprise.github.com/releases/<version>/download.html で入手できます。

参考資料