開発を外部に委託している会社に「いま御社のリポジトリに、誰がアクセスできますか」と聞くと、たいてい答えが返ってきません。調べれば分かる、という状態ではあります。ただ、その場で答えられないということは、変化に気づける状態ではないということでもあります。
実際に一覧を出してみると、常駐が終わった会社のアカウントが残っている、退職した人が個人アカウントのまま入っている、誰の依頼で付与したのか分からない権限がある、といったものが出てきます。悪意の話ではなく、ほとんどが外し忘れです。
外し忘れが起きるのは、付与が画面操作だからです。依頼はチャットで来て、担当者がブラウザを開いて、認証して、画面を操作して終わる。記録はチャットのスレッドにしか残りません。半年後にそのスレッドを掘り返す人はいません。
「ポチポチ」の何が問題なのか
先日、GitHub の権限管理を Terraform に移した実例が公開されていました。動機として挙げられていたのは、新しいメンバーが入るたび、チーム構成が変わるたびに Slack のワークフローで依頼が流れてきて、その都度ブラウザを開いて画面を操作する——という運用のしんどさです。
しんどさは入口の話で、実務で効いてくるのはその先にある3つです。
現在の状態を一箇所で見られない。 Organization のメンバー一覧、チームの所属、リポジトリごとの権限は別々の画面にあります。全体像は、人の頭の中にしかありません。
変更の理由が残らない。 「なぜこの人に書き込み権限があるのか」に答えられるのは、付与した本人だけです。その本人が異動すると、誰も外せなくなります。外していいか分からないものは、残ります。
棚卸しが目視になる。 定期的に確認する運用を作っても、比較対象が前回の目視結果なので、差分ではなく全件を見ることになります。続きません。
コードに載せると、依頼がプルリクエストになる
Terraform の GitHub プロバイダを使うと、Organization のメンバーシップ、チーム、チームの所属、リポジトリへのチームの割り当てといった単位を設定ファイルとして持てます。
運用の形が変わるのはここです。権限の依頼が「チャットのメッセージ」から「プルリクエスト」になります。
- 誰が、誰に、どの権限を、いつ付けたのかがコミット履歴に残る
- 承認がレビューという形で明示的になる
- 現在の状態がファイルとして読める（棚卸しが差分の確認になる）
- 契約終了時は、該当する記述を消したプルリクエストを出せば終わる
最後の1点が、外部に委託している会社にとっていちばん効きます。オフボーディングが「思い出して外す作業」ではなく「差分の適用」になります。Google Workspace 側のアカウント停止手順を整備している会社でも、コードホスティング側だけが手作業のまま残っているケースは珍しくありません。
全部を載せようとすると失敗する
最初から Organization のすべてをコード化しようとすると、たいてい途中で止まります。実際の事例でも「すべてを管理するわけではない」と明言されています。
載せる価値が高いのは、変更が頻繁で、記録が必要なものです。
| 対象 | 最初に載せるか | 理由 |
|---|---|---|
| Organization のメンバー | 載せる | 入退社・契約開始終了で最も動く |
| チームとその所属 | 載せる | 権限の実体はここに集まる |
| チームへのリポジトリ割り当て | 載せる | 「誰が何を触れるか」の核心 |
| ブランチ保護のルール | 状況次第 | 変更頻度が低く、先に載せる必要は薄い |
| リポジトリそのものの作成 | 急がない | 作成より権限のほうが事故が多い |
順序を守ると、最初の1週間で効果が出ます。逆に、リポジトリ本体の設定から入ると、既存の細かい差異を取り込む作業で消耗します。
実際に詰まるところ
導入を検討するなら、先に知っておいたほうがよい点が4つあります。
既存のリソースの取り込み。 現状はすでに存在するので、まず現在の状態をコード側に引き当てる作業が要ります。ここが初回のコストの大半です。人数が多いほど時間がかかるので、対象をメンバーとチームに絞る判断が効いてきます。
招待中のユーザーの扱い。 招待を送ったが承諾されていない状態は、メンバーとしては未確定です。適用のたびに差分として現れることがあり、運用ルールを決めておかないと毎回のノイズになります。
個人アカウントとの結びつき。 GitHub のアカウントは個人に紐づきます。社員名簿とアカウント名の対応表がどこにも無いと、コード上の記述を見ても誰のことか分かりません。この対応表を先に作るほうが、実は効きます。
適用に使う権限の置き場所。 適用を実行するための資格情報と、現在の状態を記録するファイルの保管場所には、Organization を操作できる強い権限が集まります。ここが個人のPCにあると、開発端末が侵入経路になったときの被害範囲が跳ね上がります。CI 上で実行し、資格情報は秘密情報として管理する形が前提です。
なお、インフラ全体を宣言的に管理する話と同じ道具を使いますが、権限管理のほうは対象が小さく、効果が出るまでが短い領域です。インフラのコード化が進んでいない会社でも、ここだけ先に始められます。
発注する側が確認できること
自社に開発チームがない場合でも、委託先に聞ける質問があります。
「弊社のリポジトリにアクセスできる人の一覧を、いま出せますか」。出せるなら、次は「その一覧はどこで管理されていますか」。答えが「GitHub の画面です」であれば、契約が終わったときに外れる保証はどこにもありません。契約終了から30日後に、もう一度同じ一覧を出してもらうとはっきりします。
次にやること
自社の Organization で、直近1年に権限を付与した回数を数えてください。10回を超えているなら、画面操作のままでは記録が追えない規模です。
まずはメンバーとチームの所属だけをコードに載せて、次の依頼からプルリクエストで受ける。ここまでで、棚卸しは差分の確認になります。
開発体制の権限設計、委託先を含めたアクセス管理、契約終了時のオフボーディング手順の整備については、グリームハブの開発・AI・自動化のご相談で承っています。体制と委託先の数によって適切な範囲が変わるため、お問い合わせからご相談ください。
