相互TLSはローカルAIサービス間の信頼をどのように変えるのか?

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

相互TLSは、アプリケーションデータが接続を通過する前に、両方のエンドポイントが証明書の身元を証明することを求めることで、ローカルサービスの信頼モデルを変えます。

通常のTLSでは、RAGクライアントは意図したモデルサーバーに接続したことを検証できますが、サーバーはLAN上の任意のクライアントを受け入れてしまう可能性があります。mTLSでは、クライアントも証明書を提示し、秘密鍵を保有していることを証明します。双方が信頼チェーンを検証し、上位レベルの認可によって許可されるAPI操作が決まる前に、認証済みの暗号化チャネルを確立します。

TLSハンドシェイク中に双方のピアを認証する

サーバーは通常のTLSと同様に証明書を提示し、その後クライアント証明書を要求します。各ピアは、発行者、有効期間、名前またはサービスID、鍵の用途、そして相手のエンドポイントが対応する秘密鍵を保有していることの証明を検証します。

双方向サービス認証の解説では、相互認証によって信頼されていないマイクロサービスを遮断しながら、傍受や改ざんから通信を暗号化する仕組みが説明されています。ハンドシェイクによって、ID検証はアプリケーションのプロンプトやAPIペイロードより下位の層で行われます。この違いは、後の家庭内テストでも確認できます。

チャネルが正常に確立されたことは、信頼されたルートが認識するピアIDを証明します。しかし、呼び出し元のサービスが特定のモデル、ドキュメントセット、またはツールを使用する権限を持つことまでは示しません。自動化を進める前に、この中間結果を検証可能な状態に保つ必要があります。

ネットワーク上の場所に代わり、信頼ルートが接続許可の判定基準になる

サービスはもはや、送信元IP、ホスト名、またはプライベートサブネットへの所属を、IDの主な証明として依存しません。設定された認証局につながる証明書を受け入れ、認証済みのサブジェクトをサービスプリンシパルに関連付けます。

証明書の信頼チェーンに関する詳しいガイドでは、認証局を信頼することは、その認証局が署名したIDを信頼することを意味すると説明されています。そのため、ルートの配布、名前制約、発行ポリシー、更新は、家庭内AIの信頼境界の一部になります。この境界は、現実的な運用条件下で個別に測定する必要があります。

このモデルは、ID名が安定しており、デバッグ中に証明書検証を無効化しない場合に限り、変動するコンテナアドレスや分割されたネットワークにも対応できます。複数のソースが限られたコンテキストを奪い合う状況では、その実際の影響が現れます。

認可とライフサイクル管理で信頼の判定を完結させる

ハンドシェイク後、サーバーは証明書のIDを、許可されたメソッド、リソース、レート、ユーザー委任に関連付けます。自動発行と自動ローテーションによって有効期間を短く保ち、失効処理やポリシーの削除によって、廃止されたサービスからの新たなセッションを停止します。

mTLSによるID証明の最新の概要では、双方向のID証明と、それに続くアプリケーション認可が分けて説明されています。これにより、暗号化と認証を完全な権限管理と取り違えることを防げます。最終インターフェースでは、この依存関係を明示したままにする必要があります。

失敗の境界となるのは、クライアント証明書の共有や、権限が広すぎる発行認証局です。複数のサービスが同じ秘密鍵を保有している場合、mTLSはその認証情報を認証できますが、実際にリクエストを開始したプロセスを区別できません。そのため、結果を元の証拠と照合する必要があります。

チャネルと、その上位にある認可を検証する

サービスの各ペアについて、クライアントID、サーバーID、信頼ルート、証明書の有効期間、ホスト名またはSPIFFEの検証、鍵の保護、許可されたAPI、リソース範囲、ローテーション経路、失敗ログを記録します。この違いは、後の家庭内テストでも確認できます。

結果をサービス認可ポリシーと関連付けます。未知の発行者、誤ったサービス名、期限切れの証明書、コピーされたクライアントキー、証明書の欠落、証明書は有効だが禁止されたメソッド、アクティブな接続中のローテーションを試します。自動化を進める前に、この中間結果を検証可能な状態に保つ必要があります。

自動化されたライフサイクル管理と、ハンドシェイク後の明示的な認可を組み合わせたうえで、mTLSを導入します。IDの失敗によって接続が停止し、有効だが認可されていないピアには決定論的なアプリケーション拒否が返されれば合格です。この境界は、現実的な運用条件下で個別に測定する必要があります。

テック&AIハブ

もっと読む

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.