mTLS と SPIFFE：ワークロード間の相互認証

ネットワーク境界が守れなくなった前提

従来のセキュリティは「社内ネットワークの内側は信頼できる」という境界モデルに依存していました。ファイアウォールの内側に入れたサービスは、IP アドレスやネットワークセグメントだけで互いを信用します。しかしマイクロサービスとコンテナが大量に動き、IP が頻繁に入れ替わる環境では、ネットワーク位置は身元の証明にならなくなりました。あるポッドに侵入した攻撃者は、内部 IP からなら他サービスへ自由に横移動（ラテラルムーブメント）できてしまいます。

ゼロトラストは「ネットワークのどこにいるか」ではなく「暗号的に誰であるか」でアクセスを判断します。サービス間通信でこれを実現する中核技術が mTLS（相互 TLS） と、ワークロードに一貫した ID を与える SPIFFE です。前提となる TLS の基礎は /network/tls/ を参照してください。

mTLS：双方向の証明書検証

mTLS のハンドシェイクは、片方向 TLS に クライアント証明書の提示と検証 を加えたものです。サーバーが CertificateRequest を送り、クライアントが自分の証明書と、秘密鍵による署名（CertificateVerify）を返します。

->  ClientHello
<-  ServerHello / Certificate（サーバー証明書）
    CertificateRequest      （クライアント証明書を要求）
->  Certificate             （クライアント証明書チェーン）
    CertificateVerify       （クライアント秘密鍵による署名）
    Finished
<-  Finished

サーバーは受け取ったクライアント証明書について、(1) 信頼する CA で署名されているか、(2) 有効期限内か、(3) CertificateVerify の署名が証明書内の公開鍵で検証できるか、を確認します。署名検証が通ることで、相手が証明書に対応する 秘密鍵を実際に保持している ことが証明されます。証明書を盗み見るだけでは秘密鍵がなく、なりすませません。ハンドシェイクと署名検証の詳細は /network/tls13-handshake-internals/ を参照してください。

SPIFFE ID：ワークロードの普遍的な名前

mTLS には「証明書に何を書き、何を見て相手を識別するか」という命名規約が必要です。これを標準化するのが SPIFFE（Secure Production Identity Framework For Everyone） です。SPIFFE は各ワークロードに URI 形式の ID を与えます。

spiffe://example.org/ns/payment/sa/checkout
        └─ trust domain ─┘└──── path ────┘

trust domain（例 example.org）は ID の発行・信頼の単位で、組織やクラスタに対応します。path はその中での具体的なワークロード（名前空間・サービスアカウントなど）を表します。この SPIFFE ID は証明書の SAN（Subject Alternative Name）の URI フィールド に格納されます。検証側は証明書の Common Name や IP ではなく、この SAN URI を読んで相手のワークロードを識別します。IP やホスト名から ID を切り離すことで、ポッドが再スケジュールされて IP が変わっても ID は不変に保たれます。

SVID：SPIFFE ID を運ぶ短命の証明書

SPIFFE ID を実際に通信で使える形にしたものが SVID（SPIFFE Verifiable Identity Document） です。SVID には2つの形式があります。

X.509-SVID は前述のとおり SAN URI に SPIFFE ID を埋め、mTLS のクライアント／サーバー証明書として直接使えます。秘密鍵を持つことがハンドシェイクで証明されるため、証明書だけを盗んでも使えません。一方 JWT-SVID は秘密鍵保持の証明を伴わないため、トークン自体が盗まれると有効期限内は再利用されうる点に注意が必要です。

短命発行と自動ローテーション

SPIFFE の運用基盤である SPIRE は、SVID を 数分〜数時間という極端に短い有効期限 で発行します。これがゼロトラストの実効性を決める要点です。

SPIRE Server ── 発行・署名 ──> SPIRE Agent（各ノード）
                                   │ Workload API（Unix ソケット）
                                   ▼
                              ワークロードへ SVID を配布
                                   │
        有効期限の約半分が過ぎたら自動で新しい SVID を取得（ローテーション）

ワークロードは秘密鍵をディスクに長期保存せず、ノード上の SPIRE Agent から Workload API 経由で SVID を受け取ります。Agent は SVID の寿命が半分ほど過ぎた時点で次の SVID を先回りで取得し、無停止で差し替えます。これにより次の利点が生まれます。

• 漏洩の被害時間が短い：鍵が漏れても数分後には別の鍵に入れ替わり、古い鍵は失効する。失効リスト（CRL/OCSP）への依存を減らせる。失効の仕組みは /network/certificate-revocation/ を参照。
• 手作業の証明書管理が消える：有効期限切れによる障害や、手動更新のオペミスがなくなる。
• アテステーションで身元を裏取り：SPIRE Agent はワークロードに SVID を渡す前に、そのプロセスが本当に主張どおりの ID か（例 Kubernetes のサービスアカウント、AWS インスタンス ID など）を アテステーション で検証する。なりすましのワークロードには ID を発行しない。

サービスメッシュでの実装

実運用では、各サービスに mTLS と SVID 管理を直接実装するのではなく、サイドカープロキシ（Envoy など）が肩代わりするのが一般的です。アプリケーションは平文で隣のプロキシと話し、プロキシ同士が SVID を使って mTLS を張ります。

[App A] ─平文─> [Sidecar A] ══ mTLS（X.509-SVID）══> [Sidecar B] ─平文─> [App B]
                     ▲                                    ▲
                     └── SPIRE / メッシュ CA が SVID を供給・ローテーション

アプリのコードを変えずにメッシュ全体へ相互認証を導入でき、ポリシー（どの SPIFFE ID がどの ID を呼べるか）もプロキシ層で一元的に強制できます。身元の発行（SPIFFE/SVID）、相手検証（mTLS）、呼び出し可否（ポリシー）の3層が分離されているため、それぞれを独立に運用・監査できるのがこのアーキテクチャの強みです。ネットワーク位置を信頼の根拠から外し、暗号的な ID へ置き換える——これが mTLS と SPIFFE が実現するゼロトラストの本質です。