GitHub Foundations #8 Domain 6: プライバシー・セキュリティ・管理 — 権限・2FA・Dependabot

Domain 6はGitHub Foundationsの中で境界の区別問題が最も多く出る領域です。リポジトリroleの5段階のどこから設定を変えられるのか、Dependabotの3機能はそれぞれ何をするのかのように、似て見えるもの同士の正確な境界を問います。覚えることが多く見えますが、すべては「誰が何をできるか」と「どの脅威をどの段階で防ぐか」という2つの質問に整理できます。

リポジトリの権限 — collaboratorとrole 5段階 #

個人アカウントのリポジトリでは、所有者がcollaboratorを招待してアクセスを付与します。Organizationのリポジトリは、より細分化されたrole 5段階で権限を分けます。この表がDomain 6の最頻出ポイントです。

境界を問う問題の判別基準は2か所です。コードをpushできる最初の段階はWriteで、セキュリティ設定やリポジトリ削除のような影響の大きい操作はAdmin専用です。Triageはコードに触れずIssueだけ整理する役割、MaintainはAdminから危険な操作を除いた役割と覚えておけば、シナリオ問題に対応できます。

Organization — owner・member・チーム #

Organizationレベルの権限は2層です。

• Organization role — ownerは組織の設定、メンバー管理、支払いまですべての権限を持ち、memberは組織に属するだけでリポジトリ権限は別途受け取ります。組織外の人に特定リポジトリだけを開くoutside collaboratorも区別の対象です。
• チーム（Team） — リポジトリ権限を人単位ではなくチーム単位で付与する入れ物です。チームの下に子チームを置くネスト構造をサポートし、親チームの権限が子チームに継承されます。PRのレビュアーにチームを指定したり、@org/team-nameでメンションしたりもできます。

組織全体のbase permissionは、すべてのメンバーがすべてのリポジトリに既定で持つ権限（None〜Write）です。最小権限の原則を問われたら、base permissionを低くしてチームで必要な分だけ付与する方向が答えです。

認証 — 2FA・PAT・SSH #

アカウントの保護とAPIアクセスの手段も試験範囲です。

• 2FA（2要素認証） — TOTP認証アプリ、セキュリティキー（WebAuthn）、GitHub Mobile承認、SMSをサポートします。GitHubは活動中のアカウントに2FAを義務化してきたので、「推奨事項」ではなく「要求事項」として覚えます。passkeyでパスワードなしにログインする方式もサポートされます。
• PAT（Personal Access Token） — パスワードの代わりに使うAPI・HTTPS認証トークンです。2種類の区別が出題ポイントです。classicはアカウント全体に及ぶ広いスコープを持ち、fine-grainedは対象リポジトリと権限を狭く指定し、有効期限が必須です。最小権限の観点での答えは常にfine-grainedです。
• SSHキー — HTTPSの代わりに鍵ペアで認証する通信方式です。公開鍵をアカウントに登録しておけば、clone・pushにパスワードが要りません。

branch protectionとrulesets #

共有ブランチをミスから守るサーバー側の仕組みです。mainのようなブランチに次を強制できます。

• PRなしの直接push禁止、承認レビューの最少人数
• 指定したステータスチェック（CI）の通過前はマージをブロック
• force pushとブランチ削除のブロック

同じ目的をより広い範囲（タグ、複数のブランチパターン、組織レベル）に適用する新しい形式がrulesetsです。試験レベルでは「ブランチを守るルールの仕組み」という共通の目的と、rulesetsがより新しい統合形式だという程度の区別で十分です。

セキュリティ機能の地図 — 何がどの脅威を防ぐか #

Domain 6でrole表の次によく出るのが、セキュリティ機能同士の境界です。各機能が何を監視対象にするかで区別します。

Dependabot 3機能の区別が特に定番です。alertsは警告、security updatesは脆弱性修正PR、version updatesは定期更新PRです。secret scanningとpush protectionは、事後検知と事前ブロックの関係です。push protectionが実務でどんな事故を防いでくれるのかは、Gitに秘密鍵をコミットしたとき — キーのローテーションとfilter-repoでの履歴整理で事故対応の手順とあわせて整理しました。

依存関係の現況そのものを見せるdependency graph、セキュリティ報告の窓口を案内するSECURITY.md、脆弱性を公表しパッチ版を知らせるsecurity advisoryまでが、この地図の残りのピースです。

audit logと検証済みコミット #

管理の領域からはさらに2つ出ます。

• Audit log — Organizationで誰がいつ何をしたか（メンバー招待、権限変更、リポジトリ削除など）を記録したイベントログです。組織のownerがセキュリティ事故の調査やコンプライアンス確認に使います。リポジトリの活動統計を見るInsightsと混同しないように区別しておきます。
• コミット署名（verified） — GPGやSSHキーでコミットに署名すると、GitHubがコミットの横にVerifiedバッジを表示します。コミットのauthor欄は任意に書けるため、署名はそのコミットが本当に鍵の所有者のものだと証明する手段です。

プライバシー — プロフィールとメール #

• プロフィールのコントリビューショングラフでprivateリポジトリの活動を表示するか選べ、Organizationのメンバーシップも公開・非公開を選べます。
• コミットに実際のメールアドレスを残したくない場合は、設定でKeep my email addresses privateをオンにして、GitHubが提供するnoreplyアドレスでコミットします。Web UIで作るコミットには自動で適用されます。

まとめ #

この記事の要点は3つです。

• リポジトリ権限はRead、Triage、Write、Maintain、Adminの5段階で、pushの境界はWrite、影響の大きい設定の境界はAdminです。
• 認証は2FA義務化が基本前提で、トークンは最小権限のfine-grained PATが推奨の答えです。
• セキュリティ機能は監視対象で区別します。依存関係はDependabot、秘密情報はsecret scanningとpush protection、コードのパターンはcode scanningです。

次回の「GitHub Foundations #9 Domain 7: GitHubコミュニティ + 試験のコツ」では、最後のドメインであるオープンソース・InnerSource・コミュニティ機能を整理し、試験直前に確認するコツもあわせて扱います。