認証とモノレポは同じ問題を解いている: 信頼を細かく設計する技術

なぜ認証の話に、パッケージ管理が登場するのか

システムの安全性を壊すのは、必ずしも悪意のある攻撃者ではありません。むしろ頻繁に起きるのは、正しい人や正しいコードに、正しい範囲を超えた権限や依存関係を与えてしまうことです。

ここで一見、遠く離れた二つの技術を考えてみます。一つは、Kerberos version 5に代表されるユーザ認証です。もう一つは、pnpmを使ったモノレポ管理です。前者は「誰がサービスを利用してよいか」を扱い、後者は「どのパッケージが、どのコードやライブラリに依存してよいか」を扱います。

表面だけを見れば、認証はセキュリティの問題であり、モノレポは開発効率の問題です。しかし深いところでは、両者は同じ問いに答えようとしています。

複雑なシステムの中で、誰に、何を、どの範囲まで信頼するのか。

この問いを見落とすと、認証は単なるログイン画面になり、パッケージ管理は単なるインストール手段になります。反対に、この問いを中心に置くと、認証と開発基盤はどちらも「信頼を細かく分割し、必要な場所でだけ再利用する仕組み」として見えてきます。

Kerberosが教える、信頼は持ち運ぶものではなく発行するもの

Kerberosの重要な発想は、ユーザが各サービスにパスワードを直接渡すのではなく、認証済みであることを示すチケットを利用する点にあります。ユーザは認証サーバに対して自分を証明し、その後、目的のサービスを利用するための証明を受け取ります。

この構造には、実務上きわめて重要な意味があります。サービスごとにパスワードを保存したり、毎回同じ秘密情報を送信したりする必要がありません。認証の根拠を一度確立し、その根拠から、用途ごとに限定されたアクセス権を発行するからです。

たとえば、社内の図書館システムを考えてみましょう。利用者が一度身分証を確認されたからといって、書庫、会計室、管理者用端末のすべてに自由に入れる必要はありません。受付で身分を確認した後、閲覧室に入るための札、資料を借りるための札、管理区域に入るための札を別々に渡すほうが安全です。それぞれの札には用途と有効期限があります。

ここで大事なのは、認証と認可を混同しないことです。認証は「あなたは誰か」を確認します。認可は「あなたは何をしてよいか」を決めます。Kerberos的な設計は、身元の確認を一度で済ませながら、サービスへのアクセスを細かく分ける発想を促します。

この考え方を一般化すると、次の三つの原則になります。

1. 秘密情報を、必要以上の場所に複製しない
2. 一つの身元確認から、目的別の権限を発行する
3. 権限には対象、期限、利用目的を持たせる

これはユーザ認証だけの原則ではありません。ソフトウェアの依存関係にも、そのまま適用できます。

pnpmとモノレポが教える、依存関係は共有しながら隔離するもの

モノレポでは、複数のアプリケーションやライブラリを一つのリポジトリで管理します。コードをまとめることで、変更の追跡、レビュー、テスト、バージョン管理を一体化しやすくなります。しかし、すべてを一つの巨大な依存関係として扱うと、別の問題が起きます。

あるパッケージが使っているライブラリを、別のパッケージがあたかも自分の依存関係であるかのように利用する。あるサービスだけに必要なツールが、リポジトリ全体から見える。開発者の手元では動くのに、独立してビルドすると失敗する。この状態は、依存関係の境界が曖昧になった結果です。

pnpmを使ったモノレポ管理が便利なのは、パッケージを効率的に共有しながら、各パッケージの依存関係を比較的明確に管理できる点にあります。共有はする。しかし、何でもどこからでも使える状態にはしない。この「共有と隔離の同時実現」が、設計上の核心です。

ここにKerberosとの意外な類似があります。Kerberosは、ユーザの認証情報を各サービスに無制限に配るのではなく、必要なサービス向けのチケットを発行します。pnpmのモノレポは、依存ライブラリを重複して保存する代わりに効率よく共有しながら、各パッケージが宣言した依存関係を基準に利用範囲を制御します。

どちらも、次のような二つの失敗を避けようとしています。

• 完全な複製: すべての場所に秘密やライブラリをコピーする
• 完全な共有: 一つの場所に集約し、誰でも暗黙に利用できるようにする

完全な複製は、更新漏れや漏洩箇所の増加を招きます。完全な共有は、境界を消し、意図しない利用を許します。優れた設計は、その中間にある「管理された共有」を選びます。

依存関係の幽霊は、認証の過剰権限と同じ顔をしている

開発現場では、依存関係に関する小さな便利さが、長期的な複雑性を生むことがあります。たとえば、パッケージAがライブラリXを直接宣言していないのに、別のパッケージが導入したXを使ってしまうケースです。現在の構成では動作しても、依存元が変わった瞬間に壊れます。

これは、認証における過剰権限とよく似ています。ある社員が自分の業務に必要なシステムだけでなく、たまたま同じグループに所属しているという理由で、不要な管理画面まで閲覧できる状態を考えてください。本人は悪意を持っていないかもしれません。それでも、事故が起きたときの影響範囲は広がります。

ソフトウェアでは、この問題を依存関係の幽霊と呼べるでしょう。コード上では明示されていないのに、環境全体の偶然の配置によって利用できてしまう依存関係です。幽霊は、見えている間は便利ですが、構成が変わると突然消え、再現性を奪います。

認証にも同じ種類の幽霊があります。個人の権限として明示されていないのに、古いグループ所属、共有アカウント、長期間有効な認証情報によってアクセスできてしまう権限です。どちらも共通しているのは、利用可能であることと、利用を許可されていることを混同している点です。

この混同を防ぐには、システムの中で「見えるもの」と「使ってよいもの」を分離しなければなりません。パッケージが見つかるから使うのではなく、依存関係として宣言されているから使う。ユーザが接続できるから操作するのではなく、目的のサービスに対する権限が発行されているから操作する。この差は小さく見えて、保守性と安全性を大きく変えます。

信頼を設計する四つの境界

認証とモノレポを同じ視点で設計するために、信頼を四つの境界に分けて考えると便利です。

1. 身元の境界

誰が操作しているのか、どのパッケージが要求しているのかを明確にします。人間であればユーザアカウント、ソフトウェアであればパッケージ名やワークスペースの単位が基礎になります。

身元が曖昧なままでは、問題が起きても責任範囲を特定できません。「チーム全体が使える」「リポジトリ内なら使える」という表現は便利ですが、監査の観点では粗すぎます。

2. 目的の境界

同じ身元でも、目的が変われば必要な権限は変わります。閲覧と更新、ビルドとデプロイ、テストと本番操作は分けるべきです。

パッケージでも、実行時に必要な依存関係と、開発時だけ必要な依存関係を分ける必要があります。目的を混ぜると、不要な権限やライブラリが本番環境まで流れ込みます。

3. 時間の境界

権限や依存関係を永続化しすぎないことも重要です。期限のないアクセス権は、退職や異動、構成変更の後にも残り続けます。常に最新の依存関係を無制限に取得する設定も、再現性を損ないます。

Kerberosのチケットが時間的な有効性を持つように、運用上の権限には更新や失効の仕組みが必要です。依存関係も、バージョンを固定し、変更を意図的な更新として扱うことで、時間の境界を作れます。

4. 変更の境界

誰が、何を、どの単位で変更できるかを明確にします。モノレポは一つの場所で管理できるからこそ、変更の影響範囲が広くなりがちです。認証設定も、一つの変更で多数のサービスに影響します。

したがって、集中管理は集中変更を意味してはいけません。共通設定を持ちながら、パッケージ単位やサービス単位でレビューとテストを行う必要があります。共有された基盤ほど、変更の入口を細かく設計しなければなりません。

実務で使える、信頼の最小単位という考え方

この視点を現場に導入する際の合言葉は、信頼の最小単位です。ユーザ、サービス、パッケージ、依存関係を、できるだけ小さな単位で識別し、その単位ごとに必要なアクセスを定義します。

たとえば、モノレポ内に注文処理、請求処理、管理画面の三つのパッケージがあるとします。注文処理が請求処理の内部実装まで直接参照すると、コードの境界が崩れます。代わりに、請求に必要な操作だけを公開する小さなインターフェースを用意すれば、依存関係の目的が明確になります。

同様に、ユーザが請求データを閲覧できることと、請求設定を変更できることを分けます。認証済みという事実を、すべての操作に対する許可へ拡大解釈しないことが大切です。

この設計は、最初は手間に見えます。直接参照したほうが早く、広い権限を与えたほうが設定は簡単です。しかし、その短期的な簡便さは、将来の変更コストとして請求されます。境界が明示されていれば変更は局所化され、境界が曖昧なら、修正のたびに全体を確認することになります。

Key Takeaways

1. 認証と依存関係を、同じ「信頼の設計」として見る。ユーザだけでなく、パッケージやサービスにも身元、目的、期限、変更範囲を設定する。
2. 利用可能と利用許可を区別する。暗黙に見える依存関係や、偶然残っている権限を、明示的な宣言とレビューの対象にする。
3. 共有と隔離を対立させない。共通基盤やライブラリは効率よく共有しつつ、利用単位と公開インターフェースは小さく保つ。
4. 長期的な権限と依存関係を減らす。認証情報には期限と失効を設け、依存ライブラリはバージョンと更新手順を管理する。
5. 境界をテストする。単にビルドが成功するかだけでなく、各パッケージが宣言外の依存関係を使っていないか、各ユーザが不要な操作を実行できないかを確認する。

認証は、人間をシステムに入れるための門番です。モノレポの依存関係管理は、コードを別のコードに接続するための門番です。どちらも、すべてを疑って閉じることが目的ではありません。必要な信頼だけを、追跡可能な形で通すことが目的です。

複雑な組織や大規模なコードベースでは、信頼をゼロにすることはできません。必要なのは、信頼を一括で与えないことです。ユーザには目的別の権限を、サービスには限定されたチケットを、パッケージには明示された依存関係を与える。その細かな判断の積み重ねが、障害の影響範囲と変更の不確実性を小さくします。

結局のところ、強いシステムとは、誰も信頼しないシステムではありません。信頼を分解し、期限を設け、必要な場所にだけ届けられるシステムです。Kerberosの認証チケットとpnpmのモノレポ管理は、別々の技術に見えながら、私たちに同じ原則を教えています。共有するなら、境界を設計せよ。便利にするなら、何が許可されたのかを明示せよ。