1.2アクセスと権限の管理

認証で「誰か」を確かめたら、次は「何にアクセスでき・何ができるか」＝認可を統制します。GitHub は 階層的なロール（Enterprise → 組織 → リポジトリ/チーム）でアクセスを管理し、最小権限 の原則に沿って必要な範囲だけ与えます。

1.2.1組織とリポジトリのロール

組織ロール には、組織全体を統制する オーナー（owner）、一般の メンバー、そして特定の管理権限を切り出した security manager などがあります。リポジトリロール は、各リポジトリへのアクセスレベルで、Read / Triage / Write / Maintain / Admin の段階があり、加えて カスタムリポジトリロール で権限を細かく定義できます。チームにロールを割り当て、個人ではなく チーム単位 で権限を管理すると、退職/異動に強く監査しやすくなります。原則は「役割に必要な最小限のロール」を与えることです。

1.2.2Enterprise チーム

チーム は、メンバーをまとめてリポジトリへのアクセスやレビュー担当を割り当てる単位です。Enterprise チーム は、複数の組織にまたがってメンバーシップやアクセスを管理できる上位のチーム概念で、大規模な Enterprise で横断的なグループ管理に使います。チームは ネスト（親子） でき、親チームの権限を子チームが継承します。IdP の チーム同期（前節）と組み合わせると、グループ管理を IdP に一元化できます。

1.2.3アクセス監査とポリシー・ルールセット

誰がどのアクセス権を持つかは 定期的に監査 します——過剰な権限や不要になったアクセスを見つけ、最小権限に保ちます。監査ログ で「誰が・いつ・何を」変更したかを追跡できます。組織/Enterprise の ポリシー で、メンバーができること（リポジトリ作成、可視性、フォーク、Actions 利用など）を統制し、ルールセット で ブランチ保護や必須レビュー、必須ステータスチェック などを 強制 します。ロール・ポリシー・ルールセットを組み合わせ、一貫したアクセスとガードレールを敷きます。

1.2.4この節のまとめ

• リポジトリロール＝Read/Triage/Write/Maintain/Admin＋カスタムロール。権限はチーム単位で（最小権限）
• 組織ロール＝オーナー/メンバー/security manager。Enterprise チームは複数組織横断、ネストで継承
• アクセスは定期監査＋監査ログ、ポリシーでメンバー権限を統制
• ルールセットでブランチ保護/必須レビュー/必須チェックを強制（ポリシーとは別レイヤー）