外注担当者のリポジトリ接続：公開経路か VPN 経路か

限定プロジェクトのために、外注担当者には非公開リポジトリが一つ必要です。依頼は「リポジトリを公開にしてほしい」か「VPN 接続を渡してほしい」のどちらかで届きます。どちらの答えも本当の問いを飛ばしています。リポジトリの認可とネットワークの入口は別の層であり、重要な権限は、その人がその一つのリポジトリを読むか push できるようにする権限です。どちらの束に含まれるそれ以外はすべて余分なリスクです。まず認可の層を設計し、そのあとで必要最小限のネットワーク経路を決めます。

例を示すと具体的になります。外部の開発者は一人、リポジトリは一つ、本番ホストなし、管理画面なしです。入口を比較する間は、この範囲を固定します。

二つの入口、二つの異なる境界

公開到達可能なリポジトリサービスでも、HTTPS または SSH の認証とアプリケーションの認可は働きます。公開到達可能であることは、匿名で読めることを意味しません。代償は、維持し、監視し、修正し続ける必要があるリスナーです。

VPN の入口はそのリスナーを公開経路の外に置けますが、広い VPN アカウントは無関係なサービスまで露出させかねません。残った公開ホスト名、SSH リスナー、忘れていたアドレスファミリーは、あると思っていた VPN だけの境界を崩します。だから VPN だけの設計には、ファイアウォール規則だけでなくリスナーの棚卸しが必要です。

比較するのは許可された経路であり、ラベルではありません。いずれの場合も、アプリケーションの認証と通常のサーバー識別の検証は維持します。

リポジトリのロールが権限の単位

外注担当者には個人の識別子を与え、作業を完了できる最小のロールを付けます。閲覧、push、保守、管理はそれぞれ別のロールであり、すべての社内プロジェクトを許すグループは、一つのリポジトリへのアクセスとは同じではありません。グループ名が一つのロールに対応すると決めつけず、基盤上の実際のロール名を確認します。

作業に本当に必要な操作をすべて列挙します。ブラウザー経由のアクセスと Git の転送では、資格情報やリスナーが異なる場合があります。自動ビルド、パッケージのダウンロード、webhook は、それぞれ独自の受け渡し経路を持つ別の識別子として動かせますし、ノート PC の VPN はそれらをつなぎません。

リポジトリの中身を守ることは別の作業です。入口を変えても、履歴にすでにある秘密は消えず、認可された複製は制限されず、貢献者の端末は守られません。

人より長く生きる資格情報

退職者は、リポジトリの接続とネットワークの接続が再び分かれる場所です。リポジトリの認可と VPN の権利をそれぞれの所有者の手順で外し、そのあと個人トークン、SSH 鍵、自動化の資格情報、有効なセッションを確認します。配備鍵は典型的な生き残りです。人が組織を離れたあとも、設定された読み取りや書き込みのアクセスが残ります。メンバー一覧からの削除は、退職処理の完了ではありません。

作業が終わる前に、所有者と目的ごとに機械の資格情報を棚卸しします。一週間のビルド用に作ったトークンが、存在理由を誰も書いていなければ、プロジェクトを一年長く生き延びられます。

操作・拒否・退職処理を検証する

引き渡しの前に三つを試します。許可されたリポジトリ操作が成功すること、無関係なリポジトリが拒否されること、退職した識別子が失敗することです。VPN だけの設計なら、以前の直接の公開経路がその操作をもう実行できないことを確認します。

コードとレビューの記録は残しますが、忘れられたアクセスを復旧計画にしてはいけません。識別子、ロール、有効期限の書かれた一覧が、次の外注依頼を繰り返せる手順にします。