Skip to main content

このバージョンの GitHub Enterprise はこの日付をもって終了となりました: 2023-01-18. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise にアップグレードします。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせく� さい

システ� の概要

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

GitHub Enterprise Server について

GitHub Enterprise Server は、エンタープライズ内のソフトウェア開発用のセルフホステッド プラットフォー� です。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 としてマウントされます。 たとえば、200 GB のルート ボリュー� が割り当てられている� �合は、ルート ファイルシステ� に 100 GB が割り当てられ、アップグレードとロールバックのために 100 GB が予約されます。

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

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

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

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

展開トポロジ

GitHub Enterprise Server は、高可用性ペアなど、さまざまなトポロジで展開できます。 詳しい情� �については、「GitHub Enterprise Server について」を参照してく� さい。

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

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

現在、GitHub Enterprise Server のベース オペレーティング システ� は Debian 9 (Stretch) であり、Debian 長期サポート プログラ� でサポートを受けています。 Stretch の Debian LTS 期間が終了する前に、新しいベース オペレーティング システ� に移行する予定があります。

定期的なパッチ更新プログラ� は、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 には 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 認証は、ウェブアプリケーションへのアクセスを提供します。 詳細については、エンタープライズの IAM の管理に関するページを参照してく� さい。
  • OAuth および個人アクセストークンは、外部クライアントとサービスの両方に対して、Git リポジトリデータおよび API へのアクセスを提供します。 詳細については、個人アクセス トークンの作成に関する記事を参照してく� さい。

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

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

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

アクセス ログ

  • ブラウザと 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 で入手できます。

参考資料