チーム、ロール、ユーザーを使用して、リポジトリへのアクセスを管理する
この学習パスウェイの最初のガイドを振り返ると、GitHub Enterprise Cloud (GHEC) の構造コンポーネントの基本的な階層構造をレイアウトしたことを思い出すでしょう。最上位には Enterprise アカウントがあり、その下には 1 つまたは複数の Organization があります。さらに、各 Organization の下には任意の数のチームがあり、そこにメンバーを割り当てることができます。チームとメンバー ロールはこの階層構造の最下位にあり、個々のメンバーの能力とアクセス権を最もきめ細かく制御します。
これらのコンポーネントを使用すると、GHEC の内部構造を最も忠実に反映させることができます。その仕組みと利用可能なオプションについて見てみましょう。
HelloFresh 社と Philips 社は、権限を自動化し、開発者を支援する優れた方法を手に入れることができました。
このガイドの学習内容
チームを使用してユーザーのグループに権限を付与し、コラボレーションやコミュニケーションを促進し、アクセス管理を簡素化する方法
Organization レベルで利用可能なデフォルト ロールと、そのロールによって付与される権限
リポジトリ レベルで利用可能なデフォルト ロール、そのロールによって付与される権限、およびカスタム リポジトリ ロールの作成方法
ユーザーを招待して Organization に割り当てる
コンテンツにアクセスするには、Organization へのアクセス権をユーザーに付与する必要があります。Enterprise Managed User (EMU) を使用している Enterprise ではユーザーを Organization に割り当てますが、EMU を使用していない Enterprise ではユーザーを Organization に招待します。
グループ クロスドメイン ID 管理システム (SCIM) (EMU) または Organization SCIM (非 EMU) のような自動化を使用して Organization のメンバーシップを管理できることから、Organization のユーザー メンバーシップを管理する場合はユーザーをチームに追加することをお勧めします。自動化によって Organization を管理すれば、ユーザーが退職した場合に、アクセス権とライセンスを削除するために手動でユーザーを削除する手間を省くことができます。必要な作業は、ユーザーが全ての割り当てから削除されているのを確認することだけです。割り当てから削除されれば、ユーザーは Organization から削除され、ライセンスは失効します (この Organization が、ユーザーが Enterprise 内で最後に所属した Organization である場合)。
当社では monorepo を採用しています。そのため、チームをアクセス制御に使うのではなく、コミュニケーションのメカニズムとして使っています。 何かフィードバックが欲しいときや、重要な修正を知らせるときなどには、開発者は通常、チームにタグ付けします。他の会社では送信者のみがタグ付けされたプルリクエストをよく見かけますが、当社ではわかりやすいように、プルリクエストに複数のチームのタグを付けます。そうすることで、チームは常に最新の情報を得ることができるため、チームに最新の情報を提供しようという意欲が高まります。
SCIM 以外のアクセス管理では、Organization のオーナーがユーザーを非 EMU Organization に直接招待できます。手動による招待は 7 日以内に承認されないと失効しますが、必要に応じて再送信またはキャンセルできます。手動で招待されたユーザーについては、退職時に手動で削除するか、削除するための独自の自動化を構築する必要があります。手動による招待にはデプロビジョニング プロセスが組み込まれていません。
チームを使用して権限を付与する
権限はチームと個人に付与できます。可能であれば、ID プロバイダー (IdP) グループとメンバーシップを同期できるチームを使用して権限を付与します。これらの権限の作成は、webhook と GitHub API を使用して自動化できます。
もはや開発者は IT チームが手動でアクセスを提供するのを待つ必要はありません。 Azure Active Directory のユーザーとグループを GitHub と同期し、Terraform を使用してリポジトリへのアクセス権を提供しています。例えば、ユーザーがリポジトリへのアクセス権が必要な場合、プルリクエストをすれば、残りは Infrastructure as Code の自動化によって処理されます。
Enterprise のロール
Enterprise の全てのユーザー アカウントは、Enterprise のメンバーになります。Enterprise レベルでは、2 つの管理ロールを割り当てることができます。それぞれがビジネス機能に対応しており、Enterprise 内で特定のタスクを実行する権限を提供します。
Enterprise のオーナー。Enterprise 全体の全ての設定にアクセスおよび管理でき、Enterprise が所有する全ての Organization のメンバーおよび外部コラボレーターを確認できます。
支払いマネージャー。Enterprise 内の支払い設定にのみアクセスして管理できます。
EMU を使用する Enterprise は、管理ロールを含む全ての新しい Enterprise メンバーをプロビジョニングし、IdP を通じて全ての変更と割り当てを行う必要があります。Enterprise のオーナーや Organization のオーナーであっても、GitHub を使用して Enterprise に新しいメンバーやオーナーを追加することはできません。
標準的な Enterprise の場合、管理ロールは GitHub.com で既存の Enterprise メンバーに割り当てることができ、新規メンバーはメールまたは GitHub アカウントのユーザー名で招待できます。管理ロールの招待を受け入れるには、管理者を含む全てのユーザーが GitHub.com アカウントでサインインする必要があります。
Organization のロール
メンバー
Organization メンバーは、Organization のデフォルトの非管理者ロールです。メンバーには、リポジトリやプロジェクト ボードを作成する権限など、多くの権限がデフォルトで付与されますが、これらの権限は Enterprise や Organization のポリシーによって変更できます。
Organization のオーナー
Organization のオーナーは、Organization 内の全てのリポジトリへの完全なアクセスと制御を含む、Organization に対する完全な管理アクセス権を持ちます。Organization のオーナーは損害を与える可能性のあるアクションや、機微性の高いアクションの権限を持つため、このロールは、ビジネス ニーズをサポートするために必要なユーザー数のみに制限してください。ただし、Organization のオーナーが取り込み中であったり、退職したり、アクセス権を失ったりした場合に備えて、各 Organization には常に複数の Organization のオーナーを用意しておいてください。Organization のオーナーは、Organization のオーナー ロールに他の Organization メンバーを昇格させることができます。
当社ではインナーソースを推進するために単一の GitHub Organization で運用しているため、リポジトリの権限の管理は各チームに任せており、Organization レベルでは何も強制していません。 もちろん、必要最小限のアクセス権のみを付与するという最小特権の原則に従うことも強く勧めています。IssueOps を使用してジャストインタイムのアクセス権を GitHub Organization 管理者に付与しているため、管理者が自分では気づかないうちに誤って変更してしまうことがなくなりました。
外部コラボレーター
外部コラボレーターは、1 つまたは複数の Organization リポジトリにアクセスできますが、Organization のメンバーではありません。通常は、コンサルタントや派遣社員がこの役割に割り当てられます。外部コラボレーターは GitHub アカウントやメール アドレスを使用して、リポジトリごとに直接招待されます。付与するアクセスのレベルは、外部コラボレーターを追加するリポジトリごとに選択できます。管理者は Enterprise または Organization のポリシーによってコラボレーターの招待を制限できます。
EMU を使用する Enterprise では、連携している IdP から全てのユーザーをプロビジョニングする必要があるため、外部コラボレーターを追加できません。
セキュリティ マネージャー
セキュリティ マネージャーは、Organization のオーナーが Organization 内の任意のチームに割り当てることができる Organization レベルのロールです。このロールを適用すると、Organization 全体のセキュリティ アラートと設定を管理する権限と、Organization 内の全てのリポジトリを読み取る権限がチームの全てのメンバーに付与されます。
Organization にセキュリティ チームがある場合は、セキュリティ マネージャー ロールを使用することによって、Organization に対する必要最小限のアクセス権をチームのメンバーに付与できます。セキュリティ情報を閲覧できる読み取り専用アクセスが必要な監査者などにも利用できます。
支払いマネージャー
支払いマネージャーは、特定の Organization の支払い情報と設定を表示および管理できるユーザーです。複数の Organization を持つ Enterprise で、一部のユーザーに Enterprise 全体の支払いマネージャー権限は付与しないが、特定の Organization レベルでのアクセス権を付与する場合に便利なオプションです。
GitHub App マネージャー
デフォルトでは、Organization が所有する GitHub App 登録の設定を管理できるのは Organization のオーナーのみです。Organization 所有の GitHub App 登録を管理できるユーザーを追加するには、オーナーがそのユーザーに GitHub App マネージャーの権限を付与します。
ユーザーを GitHub App マネージャーに指定すると、そのユーザーには一部または全ての GitHub App 登録の設定を管理するアクセス権を付与できますが、そのユーザーは Organization に GitHub App をインストールしたりアンインストールしたりすることはできません。
チームメンテナー
チームメンテナーのロールを持つユーザーは、チームのメンバーシップを管理したり、チーム名やアバターなどのチーム設定を行ったりできます。Organization のオーナーは、すでにチームのメンバーになっているユーザーにチームメンテナー ロールを割り当てることができます。
IdP グループを使用してメンバーシップの処理を自動化しているチームには、設計上、メンテナーはおらず、追加することもできません。なぜなら、チームのユーザー メンバーシップを手動で更新できないのであれば、メンテナーが行う作業の範囲は非常に限定なものになってしまうためです。Organization のオーナーは、必要に応じて IdP グループで管理するチームの設定を変更できます。
リポジトリのロールと権限
GitHub には、デフォルトで以下の 3 種類のリポジトリ権限が用意されています。
読み取り。Organization のメンバー全員がリポジトリを閲覧したり、クローンしたり、問題に参加したりできます。Enterprise でフォークが許可されている場合は、ユーザーもリポジトリをフォークできます。
書き込み。Organization の全てのメンバーがリポジトリにコードをプッシュできるようになります。必ずしもメンバーがデフォルト ブランチにプッシュしたり、自分の変更を承認したりできるわけではありません。適切に設定されたマージ設定制御は、メンバーがどのようにコードを変更できるかを制御します。
管理。Organization の全てのメンバーがリポジトリを管理できるようになります。これは、あまりにも許容範囲が広いため、デフォルトとして使用するべきではありません。
GitHub には読み取り、トリアージ、書き込み、維持、管理といったリポジトリのロールも用意されており、個人やチームに明示的に付与できます。トリアージと維持のロールは、通常、Enterprise よりもオープン ソース コミュニティでの利用に向いています。さらにロールが必要な場合は、後述のカスタム リポジトリ ロールを検討してください。
リポジトリ アクセスを監査・管理する
GitHub で管理する各リポジトリについて、リポジトリの可視性、ベースの可視性、直接アクセスの概要のほか、リポジトリにアクセスできる全てのチームやユーザーの詳細ビューを閲覧できます。このビューでは、チームや個々のユーザー別の検索やフィルタリング、新しいチームやユーザーの招待、リポジトリに対する各チームやユーザーの役割の変更、リポジトリへのアクセスの削除を行うことができます。
この概要では、リポジトリへのアクセスを監査したり、請負業者や従業員のオンボードまたはオフボードを行ったり、セキュリティ インシデントに効果的に対応したりできます。
ユーザーに付与された、リポジトリへのアクセスや権限が競合していると、リポジトリ アクセスのページに警告が表示されます。通常のチームまたは継承されたロールや権限では付与されないアクセスが、直接割り当てまたはカスタム ロールによってユーザーに付与された場合にアクセスの競合が発生することがあります。ユーザーが競合するアクセスを持っている場合、リポジトリ アクセス画面に警告アイコンが表示され、そのユーザーのユーザー リストの横に [ロールが混在しています] と表示されます。競合するアクセス権の原因を確認するには、警告アイコンにカーソルを合わせるか、[ロールが混在しています] インジケーターをクリックします。必ずしも競合するアクセス権を「修正」する必要はありません。この情報は、競合するアクセス権が原因となり、ユーザーが特定の権限を持つことに混乱が生じないようにするためのものです。
チームのメンバーシップや Organization の基本権限など、異なるルートで異なるレベルのアクセス権が与えられている場合、特定の権限ごとに最も高いアクセス権が優先されます。たとえば、「読み取り」を継承されたロールを使用するロールを Organization のオーナーが Organization のメンバーに与え、その後 Organization のオーナーが Organization の基本権限を「書き込み」に設定すると、このカスタム ロールはカスタム ロールに含まれる追加権限以外に書き込みアクセス権限を持つことになります。このように異なるレベルのアクセス権があると、前述のようにリポジトリ アクセスの概要に競合アクセスのフラグが表示させることがあります。
リポジトリのカスタム ロール
Organization ごとにリポジトリのカスタム ロールを最大 5 つ作成でき、リポジトリ レベルで付与する権限をより細かく制御できます。カスタム リポジトリのロールを作成する場合は、最初に読み取り、トリアージ、書き込み、維持、管理のデフォルト ロールから権限を継承します。その後、追加権限を割り当ててロールをカスタマイズします。
カスタム ロールが作成されたら、リポジトリの管理権限を持つユーザーなら誰でも、ロールをユーザーやチームに割り当てることができます。
次の項目: GitHub Enterprise Cloud でのプログラムによるアクセスおよび統合
GHEC を Enterprise のさまざまなシステムと統合するには、慎重かつ階層化されたアプローチが必要です。次回は、プログラムを使用して GitHub API にアクセスし、既存のシステムを簡単に統合するさまざまな方法について説明します。