変更要約: 構造化ブロックで全面改稿（図・コールアウト・要点・ミニクイズ）
4.1権限管理とアカウント保護
安全な運用の土台となる「適切な権限」と「強い認証」を学びます。リポジトリのロールと最小権限、Team による付与、可視性（Public/Private/Internal）、そして 2FA・PAT・SSH によるアカウント保護を押さえます。
安全な運用は「適切な権限」と「強い認証」から始まります。誰に何をどこまで許すか、そして自分のアカウントをどう守るか ── この2つを押さえることが、チームと自分を守る第一歩です。
4.1.1ロールと最小権限
リポジトリのロールは Read < Triage < Write < Maintain < Admin の順に強くなります。各利用者には業務に必要な最小限だけを与える 最小権限の原則（least privilege）に従い、過剰な権限を避けましょう。
Organization では、権限は個人ではなく Team（チーム）単位で付与するのが推奨です。Team は入れ子にでき、子チームは親の権限を継承します。base permissions は組織メンバー全員への既定アクセスレベルを定め、組織メンバーでない協力者は 外部協力者（outside collaborator）としてリポジトリ単位で招待します。
4.1.2可視性
- Public：インターネット上の誰でも閲覧可能。
- Private：許可されたユーザーのみ。
- Internal：同じ Enterprise のメンバーに公開（社内オープンソース＝InnerSource に向く）。
リポジトリを公開（Public）する前には、秘密情報や個人情報が含まれていないか必ず確認しましょう。一度公開した内容は、誰かに見られたりコピーされたりした可能性が残ります。
4.1.3アカウント保護
- 二要素認証（2FA） を有効にする。特にフィッシング耐性の高いパスキー/セキュリティキーが推奨。Organization 設定で全メンバーに 2FA を必須化できる。
- Git 操作の認証には、権限・期限・対象を絞れる fine-grained な Personal Access Token（PAT） や SSH 鍵を使い、パスワードの直接利用や共有は避ける。
- 秘密情報はコードに含めず、漏洩した場合は速やかにローテーション（無効化＋再発行）する。
ロールの強さの順 Read < Triage < Write < Maintain < Admin、最小権限の原則、可視性 Public/Private/Internal、2FA・PAT・SSH は頻出です。Organization では権限を Team 単位で付与する点も押さえましょう。
4.1.4この節のまとめ
- ロールは Read < Triage < Write < Maintain < Admin。最小権限で過剰付与を避け、Org では Team 単位で付与
- 可視性は Public / Private / Internal。公開前に秘密情報・個人情報を確認
- アカウント保護は 2FA（パスキー推奨）/ fine-grained PAT・SSH / 秘密のローテーション
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. リポジトリのロールを権限の弱い順に並べたものはどれですか？
Q2. 誰でも閲覧できる可視性はどれですか？
Q3. Git 操作の認証として推奨されないものはどれですか？