GitHub Enterprise Cloud ユーザーのアクセス モデルを選択する
GitHub Enterprise Cloud (GHEC) は 2 つの異なるユーザーアクセスモデルをサポートしています。どちらも、同様に優れた機能へのアクセスと容易なホスティングが可能ですが、それぞれ異なる種類のワークフローとセキュリティ ガードレールを強化するように設計されています。
最初の Enterprise アカウント の作成でビジネス ニーズに最適なほうを選択する必要があるため、その両方を理解することが重要です。この後確認するように、それぞれのモデルは相互に代替できない、異なるユーザー アカウントを使用しています。後に一方からもう一方に切り替えることは困難で、ユーザー履歴を移行するには移行ツールと追加プロセスの両方が必要となります。
GHEC の導入プロセスを合理的にしたいと考えています。では、ニーズに適したモデルを最初から選択できるように、それぞれのアクセス モデルのメリットとデメリットを確認していきましょう。その中で、Philips が標準ユーザーを使用すると決めた要因、Travelport が EMU を選んだ理由も紹介します。
このガイドの学習内容
GHEC で使用できる 2 種類のユーザー モデル: Enterprise Managed User (EMU) および標準
それぞれのモデルを使用した場合のトレードオフ
ビジネス要件に最適なモデルを選択する方法のガイダンス
標準 GHEC モデル (独自のアカウントを使用する)
標準モデルは GitHub.com の公開されたオープン ソースのパーツとの接続を重視しています。名前が示すとおり、ユーザーは自身の個人用アカウントを使用して私用携帯、ノートパソコン、またはその他のデバイスを使用するのとほぼ同じ形で作業できます。ユーザーがアカウントを所有し、アカウントはユーザーの Organization への参加、コントリビューション、Organization からの離脱、GitHub コミュニティへの参加に追随します。これは企業での雇用期間または特定のプロジェクトでの作業期間に限定されません。
Enterprise とその Organization はこのようなアカウントを関連付け、SAML ID を使用して非公開リソースへのアクセスを認証します。その後、サポートされている ID プロバイダー (IdP) と GitHub の設定で、クロスドメイン ID 管理システム (SCIM) を使用し、関連付けられた社内の ID 関係を使用してこのような保護されたリソースへのアクセスを自動的に付与または削除します。
また、標準モデルは、特定のリポジトリのみに対する一定の権限を持つ外部コラボレーターとして、そのリポジトリに外部ユーザーを追加できます。このような個人的な GitHub アカウントを使用する外部ユーザーは、通常のメンバーには必要となる SAML 認証が免除されます。
標準モデルを使用する際にはいくつかのトレードオフもあります。企業はユーザー名の形式、メール アドレス、表示名などのアカウント関連の要件を強制または標準化できません。つまり、従業員は企業の共通形式のユーザー名ではなく、自分で選んだ GitHub ユーザー名を使用します。これは組織に参加するより何年も前に選んだものである可能性があります。企業はこのモデルのメンバーおよびコラボレーター ユーザーの、ポリシー関連の動作のみを管理できます。その場合も、管理できるのは Enterprise アカウントとその Organization のコンテキスト内で発生した動作のみとなります。ユーザーが自身のアカウント、または企業の Organization またはリポジトリ以外のコンテキストで行ったことは、企業の管理対象外です。
標準モデルは、ポリシーによって明示的に無効になっていない限り、同じ企業の Organization 内でホストされているプライベート リポジトリおよびパブリック リポジトリの両方を許容します。この柔軟性がオープン ソース貢献への鍵となります。しかし、プライベートとパブリックの明確な境界を保つため、ユーザーによるパブリック リポジトリのホストを許可しないことを選ぶ企業もあります。
次の条件の一部または全てを満たす場合は、標準モデルが適している可能性があります。
日常業務の一環として、開発者が GitHub の公開されたオープン ソース コミュニティとシームレスに接する必要がある。
外部コラボレーターを SAML 認証要件の対象とせず、一元的な IdP ディレクトリの一部とする必要なく、リポジトリに簡単に追加できるようにする必要がある。
パブリック リポジトリや、GitHub Gist、公開された Pages や GitHub Discussions などの類似機能を多用している。
外部とできるだけ簡単に協力できるようにするため、GitHub Enterprise 標準ユーザーを使用することを選択しました。 EMU の使用も検討しましたが、オープン ソースも当社にとって重要なものでもあり、開発者はオープン ソース活動のために個別のアカウントを使用する必要がありました。
Enterprise Managed User (EMU) モデル
Enterprise Managed User (EMU) モデルは、企業の IdP が提供する標準化された作業アカウントを企業が一元的に管理することを重視します。EMU モデルは企業が所有する、Enterprise アカウントの範囲内でのみ動作する仕事専用の GitHub アカウントを使用します。
ユーザーが企業に入社し、GHEC へのアクセスを付与されると、企業の Enterprise アカウントでのみ動作し、表示される EMU 作業アカウントが提供されます。ユーザーが企業を退社するか、GHEC へのアクセスを失うと、この EMU 作業アカウントも停止されます。このアカウントの認証やプロビジョニングを含む全ライフサイクルは、Microsoft Entra ID (旧 Azure Active Directory または Azure AD)、Okta、または PingFederate といったサポートされている IdP によって管理されます。企業はユーザー名の形式、メール アドレス、表示名などの EMU アカウントの情報を標準化でき、透明性と報告が改善されます。作業アカウントの IdP アカウントがサポートする厳格な要件があるため、外部コラボレーターは標準ユーザー モデルと同じ方法では招待できません。ゲストを含む全てのユーザーが IdP ディレクトリ プロビジョニングを使用して参加する必要があります。
EMU モデルを使用すると、標準化が強化されるだけでなく、GitHub.com のパブリック リポジトリに誤ってプッシュするなど、非公開コンテンツの公開に対するガードレールを追加します。EMU Enterprise が パブリック リポジトリの作成を防止するのみでなく、EMU ユーザーは Enterprise アカウント外部のリポジトリの問題やプルリクエストのプッシュ、星付け、作成などの書き込みタイプのアクションを実行できなくなります。EMU ユーザーは GitHub.com のパブリック リポジトリを表示、クローンできる完全な読み取りアクセスを持ちます。EMU アカウントはオープン ソースへの書き込みタイプのアクティビティには使用できないため、このようなガードレールの追加によるトレードオフは企業とオープン ソースが厳格に分断されることです。
次の条件の一部または全てを満たす場合は、EMU モデルが適している可能性があります。
セキュリティ要件が、オープン ソースとのつながりよりも公開された GitHub.com コミュニティと企業のコンテンツの分離を優先している。
EMU モデルがお使いの IdP (Microsoft Entra ID、Okta、PingFederate) をサポートしており、Enterprise のコンテキストでのみ使用する専用の作業アカウントとして、ユーザーの GitHub アカウントを一元的に標準化および管理する必要がある。
特定のリポジトリに IdP 外のコラボレーターを直接追加できなくても問題なく (またはすべきでなく)、代わりにこのようなユーザーを IdP ディレクトリの通常アカウントまたはゲスト アカウントとしてプロビジョニングする。
パブリック リポジトリや、GitHub Gist、公開された Pages や GitHub Discussions などの公開機能を必要としていない。
開発者が日常業務の一環としてオープン ソース コードを定期的に作成、保守する場合は、標準ユーザー モデルが最適な可能性があります。一方、開発者のアカウントを完全に管理し、オープン ソース コミュニティと企業のコードを厳重に分離する必要がある場合は、EMU ユーザー モデルのほうが適しています。
非公開にしたのは数年前ですが、旅行向けの革新的な技術をマーケティングし始めたところ、当社のプラットフォームに対するサイバー攻撃が四半期あたり 16 億件から 2,000 億件近くまで急増しました。そのため、EMU ユーザー モデルを選んだのは、セキュリティが大きな要因でした。
当社ではセキュリティのレフトシフトを望んでいたため、GHEC と EMU を選びました。GHEC では Microsoft Entra ID と同期して、1,600 人のユーザーのオンボーディング、オフボーディング、権限を自動化できるのが理由です。 これらのユーザーには、開発者だけでなく、運用チームやアクセスを必要とするその他の利用者もいます。その全てを ID 管理プロバイダーから直接管理できることは非常に重要でした。当社には 60 以上の Organization 全体で 8,000 以上のリポジトリがあるため、260 のチームを使用して、厳しいセキュリティ要件を満たしながら、インナーソースを促進するために必要なきめ細かな権限を提供しています。
次の内容: GitHub Enterprise Cloud で Organization を使用するための戦略
このラーニング パスの最初のステップでは、GHEC の構造的コンポーネントについて学び、Organization を 1 つに限定して管理オーバーヘッドを削減することをお勧めしました。しかし、全てのシナリオに適しているわけではないと GitHub は理解しています。大規模企業および特定のビジネス要件を持つ企業には、複数の Organization を設定する必要がある可能性があります。次のステップでは関連する考慮事項を確認し、Enterprise アカウント内で複数の Organization を使用する方法をいくつかご紹介します。