ワークロードアイデンティティとmTLSによる認証

なぜサービス間認証にパスワードを使ってはいけないのか

マイクロサービスは互いを呼び合いますが、そのとき「呼んでいる相手は本当に注文サービスか、なりすましか」をどう確かめるかが問題になります。素朴な解は共有シークレットや長命の API キーを配ることですが、これは破綻します。鍵は環境変数や設定ファイルやイメージに焼かれて漏れ、漏れても長命ゆえに気づかず使われ続け、ローテーションは手作業で滞り、誰がどの鍵を持つかの管理も崩れます。さらに根本的な誤りとして、多くのシステムはネットワーク到達性をそのまま信頼してしまいます——「同じ VPC にいるから正当」という前提は、内部へ一歩侵入されれば横展開（lateral movement）を許す、ゼロトラストの真逆の発想です（/devops/microservices/）。

ワークロードアイデンティティはこの構図を反転させます。各サービスに暗号的に証明可能な「身元（identity）」を与え、通信のたびに双方がその身元を証明し合う。共有シークレットを配るのではなく、サービスごとに固有の鍵と、それを裏づける短命証明書を自動で発行・更新する。本記事は、SPIFFE が定める身元の表現、SVID と X.509、mTLS による相互認証の手順、そして短命証明書のローテーションと信頼ドメインの原理を解きほぐします。

SPIFFE：身元を表現する標準

身元を暗号で扱う前に、まず「身元とは何の名前か」を決めねばなりません。SPIFFE（Secure Production Identity Framework For Everyone）は、ワークロードの名前を SPIFFE ID という URI 形式で定めます。

spiffe://<trust-domain>/<workload-path>

例:
spiffe://example.org/ns/payments/sa/checkout
└─スキーム─┘ └信頼ドメイン┘ └─ワークロード固有のパス─┘

ポイントは二段構造です。<trust-domain>（信頼ドメイン）は、一つの信頼の根（ルート鍵）を共有する管理境界を表します。同じ信頼ドメインに属するワークロードは、共通のルートに署名された証明書を相互に検証できます。<workload-path> はその境界内で個々のワークロード（名前空間、サービスアカウント、サービス名などの組み合わせ）を一意に識別します。重要なのは、この ID がネットワーク的な位置（IP やポート）と独立している点です。Pod が再スケジュールされ IP が変わっても、ワークロードの身元は不変であり続けます。

SVID：身元を運ぶ証明書

SPIFFE ID は名前にすぎません。それを暗号的に検証可能な形で持ち運ぶ器が **SVID（SPIFFE Verifiable Identity Document）**です。SVID には二系統あります。

mTLS の主役は X.509-SVID です。通常のサーバー証明書が DNS 名を CN/SAN に載せるのに対し、X.509-SVID は SAN の URI 型フィールドに SPIFFE ID を一つだけ載せます。検証側は証明書チェーンを信頼ルートまで辿って正物だと確かめたうえで、SAN の URI を読み取り「相手は spiffe://example.org/ns/payments/sa/checkout だ」と確定できます。つまり証明書は「公開鍵」と「その鍵を持つ者の SPIFFE ID」を、信頼ルートの署名で不可分に束ねた構造物です。秘密鍵を持つ者だけがその身元を名乗れる——これが暗号的身元の核です。

JWT-SVID は、TLS を張れない経路（L7 ロードバランサや API ゲートウェイをまたぐ場合など）でアプリ層トークンとして使われますが、bearer トークンである以上、転送途中で盗まれれば誰でも提示できます。だから JWT-SVID は短命（数分〜十数分）にし、用途も限定するのが原則です。

mTLS：双方向の相互認証

通常の TLS（片方向）は、サーバーだけが証明書を出し、クライアントは「相手が正しいサーバーか」を確かめます。**mTLS（mutual TLS）**は加えて、サーバーがクライアントに証明書を要求し、クライアントも自分の身元を証明します。サービス間通信ではどちらも「呼ぶ側」「呼ばれる側」になりうるため、双方向の証明が要るのです。ハンドシェイクで両者が確かめることは次の通りです。

mTLSハンドシェイクで双方が検証する3点:

(1) 証明書チェーンが信頼ルート（trust bundle）に到達するか
    → 相手の証明書が、自分の信頼ドメインのルートで
      署名された正物だと確認

(2) 相手が対応する秘密鍵を本当に持っているか
    → TLSの鍵交換/署名で、秘密鍵の所有を暗号的に実証
      （証明書のコピーだけでは成立しない）

(3) SAN中のSPIFFE IDが期待した相手か
    → チェーンが有効でも「誰か」は別問題。
      認可ポリシーは(3)のID名に対して評価する

ここで (1)(2) と (3) を分けて理解することが決定的です。(1)(2) は「この証明書は本物で、相手は対応鍵の正当な保持者だ」を保証しますが、それは「相手が信頼ドメインの一員だ」までしか言っていません。同じ信頼ドメイン内の別サービスもまた有効な証明書を持つからです。「呼んでよい相手か」を決めるのは (3) の SPIFFE ID に対する認可です。たとえば「checkout からの呼び出しだけ受ける」というポリシーは、ハンドシェイクで得た相手の SPIFFE ID と照合して初めて効きます。認証（誰か）と認可（何を許すか）を混同しないことが、mTLS 設計の肝です。

短命証明書とローテーション

ワークロードアイデンティティが長命 API キーより優れる最大の理由は、証明書を短命（数分〜数時間）にできることです。なぜ短命が効くのかは、失効の仕組みから理解できます。

伝統的な PKI では、漏れた証明書を無効化するために CRL（証明書失効リスト）や OCSP で「この証明書はもう無効」と全検証側へ伝えます。しかしこの失効伝播は遅く、可用性の弱点にもなります（OCSP レスポンダが落ちると検証が止まる）。短命証明書はこの問題を有効期限そのもので解く——証明書が数分で自然失効するなら、漏洩しても攻撃者が使える窓は数分しかなく、わざわざ失効リストへ載せて全世界へ周知する必要が薄れます。鍵漏洩の被害窓 = 証明書の残存寿命、という関係です。

これを人手でやるのは不可能なので、エージェントが全工程を自動化します。SPIFFE の実装（SPIRE など）では、各ノードのエージェントが次を回します。

ローテーションのループ（ワークロードは関与しない）:

1. エージェントが秘密鍵を生成（鍵はワークロードのローカルに留め、配らない）
2. CSR（証明書署名要求）を発行サーバー（CA）へ送る
3. CAがワークロードの正当性を確認しSVIDに署名して返す
4. エージェントがSVIDをワークロードへ供給（API/ファイル/メモリ）
5. 残存寿命が一定割合（例: 半分）を切ったら1へ戻り更新
   ＝古い証明書が失効する前に新しい証明書へ無停止で差し替え

設計の妙は、ワークロードのプロセスは鍵やローテーションを一切意識しない点です。秘密鍵はワークロードのローカルで生成・保持され、ネットワークを流れません（CSR で外へ出るのは公開鍵だけ）。更新は寿命が尽きる前に前倒しで行い、新旧証明書の有効期間を重ねることで、切り替えの瞬間も通信が途切れません。サービスメッシュではこの SVID をサイドカープロキシが受け取り、アプリのコードを変えずに mTLS を透過的にかけます（/devops/service-mesh/、/devops/service-mesh-sidecar-internals/）。

信頼ドメインとフェデレーション

信頼ドメインは「一つのルート鍵（trust bundle）を共有する境界」でした。同一信頼ドメイン内なら、各ワークロードは共通ルートで相手の SVID を検証できます。では別組織・別ドメインのサービスと mTLS したいときはどうするか。素朴に互いのルートを全面信頼すると、相手ドメインの全ワークロードを信用することになり境界が崩れます。

解は フェデレーションです。ドメイン A は、ドメイン B の trust bundle（公開鍵の束）だけを取り込み、「spiffe://b.example/... の相手は B のルートで検証する」と限定して受け入れます。秘密鍵は決して共有せず、検証に要る公開のルート情報だけを交換する。これにより、各ドメインは自分のルートを単独で管理（ローテーション・失効）しつつ、相手ドメインの特定の SPIFFE ID に対してだけ認可を開けます。境界を保ったまま相互運用するのがフェデレーションの要点で、ここでも認可は IP ではなく SPIFFE ID 名に対して書きます。

まとめ

• ワークロードアイデンティティは、サービスに暗号的に証明可能な身元を与える仕組み。共有シークレットや長命 API キーを配らず、ネットワーク到達性を信頼しない（ゼロトラスト）。
• SPIFFE ID（spiffe://信頼ドメイン/パス）は IP と独立した安定した名前で、SVID（X.509 か JWT）がそれを暗号的に運ぶ。mTLS では X.509-SVID の SAN に SPIFFE ID を載せる。
• mTLS は双方向で証明書を提示し合い、(1) チェーンが信頼ルートに届くか、(2) 秘密鍵の所有、(3) SPIFFE ID が期待した相手か、を検証する。(1)(2) は「正規の一員」まで、認可は (3) の ID 名に対して書く。
• 短命証明書はエージェントが鍵生成・CSR・署名・配布・更新を自動で回し、失効リストへの依存を下げ被害窓を縮める。最初の身元はアテステーション（ノード／ワークロード）で与え、その強さが全体の信頼の上限を決める。
• 信頼ドメインは共通ルートの境界で、別ドメインとは秘密鍵を共有せず trust bundle だけ交換するフェデレーションで、境界を保ったまま特定の SPIFFE ID に認可を開く。