mTLS と双方向認証

mTLS は、TLS 接続において双方向の認証を行います。一般的な証明書モードでは、クライアントがサーバーを認証し、サーバーもクライアントの証明書および秘密鍵の所持証明を要求・検証します。これにより接続が検証されたエンティティに関連付けられますが、そのエンティティがどのテナントを読み取れるか、どの API を呼び出せるかについては、自動的に決定されません。

注文サービスが支払いサービス呼び出すケースを想定します。mTLS は呼び出し元が信頼された注文ワークロードであることを確認できますが、引き落としや返金を実行する許可があるかどうかは、支払いサービスの認可ポリシーによって決定されます。同じ CA からのテストサービスだからといって、本番環境の支払い権限が付与されるべきではありません。

ハンドシェイク：証明書、署名、鍵の確認は相互に補完する

TLS 1.3 の完全な証明書認証ハンドシェイクでは、サーバーは CertificateRequest を送信し、クライアントが適切な証明書を持っている場合は Certificate、CertificateVerify、Finished を送信します。証明書は発行者が認めたアイデンティティを表し、CertificateVerify は秘密鍵の所持証明を今回のハンドシェイクにバインドし、Finished はハンドシェイクの鍵と履歴を確認します。

クライアントが適切な証明書を見つけられない場合、空の certificate_list を返し、CertificateVerify は送信されません。サーバーはポリシーに応じて匿名で続行するか、certificate_required で中止することができます。mTLS を要求するエントリポイントは、匿名パスが拒否されることを確実にする必要があり、CertificateRequest が送信されたかどうかだけを見てはいけません。

certificate_authorities は証明書の選択を示唆するもので、これを省略しても任意の CA を信頼する意味にはなりません。TLS 1.3 では、この拡張機能が出現する際にはリスト自体に非空の長さの要件があります。拡張機能がないことと、空のリストをエンコードすることは別問題です。signature_algorithms、oid_filters などもそれぞれ定義されており、「certificate_extensions に SPIFFE OID を記載する」という一般的なフローは存在しません。RFC 9846：クライアント認証

TLS 1.3 には、ネゴシエーション後にサポートされる post-handshake authentication もあります。その実装と上位プロトコルのサポートは確認が必要であり、ある HTTP パスにアクセスする際にいつでも一時的に認証を追加できると仮定してはいけません。実務では、まずエントリポイントで接続全体でクライアントのアイデンティティが要求されるかどうかを明確にし、ルーティングと認可を設計する必要があります。

検証完了後、認可可能なアイデンティティをどのように取得するか

チェーン検証は、発行者の関係、時間、用途などの条件を確認する役割を担います。アイデンティティマッピングは、約束されたフィールドに従って principal を取得する役割を担います。サーバーのアイデンティティには通常 DNS SAN が使用され、クライアントには URI SAN、特別に登録された証明書マッピング、または他のアプリケーションの約束事が使用されることがあります。最初の CN 文字列を無作為にシステム全体の一意なアイデンティティとして使用しないでください。

spiffe://prod.example/ns/orders/sa/api を例に挙げると、これを明確に許可されたエンティティとして使用し、それが charge を実行できるかどうかを決定できます。同じパスが spiffe://staging.example/... 下にある場合、それは異なるアイデンティティです。文字列内に orders が含まれている、または prod.example がプレフィックスとして付いているだけでは不十分です。

認証と認可の失敗は個別に記録する必要があります。未知の発行者、不適切な証明書の用途、アイデンティティのマッピング不能は異なる問題です。認証されたエンティティに返金権限がない場合は、認可の拒否です。これにより、「TLS は成功したが HTTP 403」という状況を説明でき、一律に証明書を再発行する必要はありません。

教育戦略：デフォルト拒否、アクションごとの認可

以下の関数の入力は、実際の検証レイヤーによって生成される必要があります。この関数はクライアントが自己申告した HTTP ヘッダーを読み取らず、X.509 や完全な SPIFFE パースも実装しません。認証結果が後のポリシーにどのように関与するかを示すだけです。

from dataclasses import dataclass

@dataclass(frozen=True)
class Peer:
    authenticated: bool
    identity: str | None

RULES = {
    'spiffe://prod.example/ns/orders/sa/api': {'charge'},
    'spiffe://prod.example/ns/finance/sa/worker': {'refund'},
}

def allow(peer, action, tenant, permitted_tenants):
    return (peer.authenticated
            and peer.identity in RULES
            and action in RULES[peer.identity]
            and tenant in permitted_tenants.get(peer.identity, set()))

orders = 'spiffe://prod.example/ns/orders/sa/api'
tenants = {orders: {'tenant-a'}}
assert allow(Peer(True, orders), 'charge', 'tenant-a', tenants)
assert not allow(Peer(True, orders), 'refund', 'tenant-a', tenants)
assert not allow(Peer(True, orders), 'charge', 'tenant-b', tenants)
assert not allow(Peer(False, orders), 'charge', 'tenant-a', tenants)
assert not allow(Peer(True, orders.replace('prod.', 'staging.')), 'charge', 'tenant-a', tenants)
assert not allow(Peer(True, orders + '/extra'), 'charge', 'tenant-a', tenants)
assert not allow(Peer(True, None), 'charge', 'tenant-a', tenants)
print('エンティティ、アクション、テナント、未認証拒否ブランチが通過した')

ワークロードのアイデンティティとユーザーのアイデンティティも分離する必要があります。注文サービスがユーザーに代わって操作を開始する場合、mTLS が証明するのは注文サービスです。ユーザー、テナント、委任範囲については、信頼できるリクエストコンテキストまたはトークンが必要であり、サービスがそのユーザーに代わってそのアクションを実行する権限があるかどうかを確認する必要があります。

信頼はどこから来るのか：プライベート CA は一般的だが、唯一の方法ではない

独自またはホスティングされたプライベート CA の構築は、サービスアイデンティティの名前付け、発行条件、信頼範囲を制御しやすくします。クライアント認証の信頼ストアは用途を限定すべきであり、利便性のために公共のブラウザルート配下の任意の適格なクライアント証明書をそのまま受け入れるべきではありません。

mTLS は、組織がオフラインのルート CA を自分で運用することを要求するものではありません。例えば、OAuth の mTLS クライアント認証は、PKI メソッドを定義すると同時に、登録材料に基づく self_signed_tls_client_auth も定義しています。後者は、事前にバインドされたクライアントの公開鍵材料を信頼するものであり、「自己署名証明書を何でも受け入れる」わけではありません。RFC 8705：クライアント認証

発行システムにも、初期のアイデンティティ根拠が必要です。新しいインスタンスは、「私は payments です」と提出するだけで支払いアイデンティティを取得することはできません。プラットフォームの証拠、ワークロード登録、およびポリシーによって、認証関係を設定する必要があります。証明書の発行自動化は資格情報の配信を解決しますが、初期の信頼できるアイデンティティの問題を空中分解することはできません。

SPIFFE：アイデンティティ仕様、資格情報、および配信インターフェース

X.509-SVID には、SPIFFE ID を格納するための URI SAN が正確に 1 つ含まれている必要があります。他のタイプの SAN を持つことができますが、CN にフォールバックすることはできず、複数の URI から 1 つを選択することもできません。エンド証明書は、CA フラグ、KU、およびアイデンティティパスなどの制約を受け、SPIFFE アイデンティティを検証するには、対応する trust domain の信頼材料を使用する必要があります。X.509-SVID 仕様

SVID は「証明書の内容に秘密鍵が含まれている」わけではありません。証明書は公開オブジェクトであり、Workload API は対応する秘密鍵を別の材料として配信できます。短期ローテーションは全体の設計の一部ですが、「デフォルトで 1 時間」という SPIFFE の永続的な統一規定として記述してはいけません。複数のインスタンスがサービスレベルのアイデンティティを共有することもでき、それは同じ秘密鍵を共有することを要求するものではありません。SPIFFE Concepts

プロキシの境界：証明書のアイデンティティは TLS 終了を自動的に通過しない

ゲートウェイが A の mTLS を終了し、B に対して 2 番目の mTLS を確立する場合、B が直接認証する TLS 対手はゲートウェイ G です。B が元の呼び出し元 A のアイデンティティを必要とする場合、ゲートウェイからバックエンドへの信頼できる伝達約束事を定義し、バックエンドが合格したエントリからのみその約束事を受け入れるように制限する必要があります。

X-Forwarded-Client-Cert を例に挙げると、これは構成可能なプロキシヘッダーです。エントリポイントは外部の偽造値をクリーンアップまたは上書きし、検証済みの接続に基づいてコンテンツを生成する必要があります。バックエンドは、ソース、伝達ルール、および必要なフィールドを検証する必要があります。PEM または Subject テキストをヘッダーに配置しても、A が 2 番目の TLS の CertificateVerify に関与することにはなりません。Envoy：XFCC

TLS passthrough を使用する場合、バックエンドは元のハンドシェイクを直接完了しますが、ゲートウェイは通常、暗号化された HTTP パスを同時に読み取って通常のレイヤー 7 ルーティングを行うことはできません。終了型か透過型かを選択するのは、どのレイヤーがアイデンティティとビジネス情報を見る必要があるかによります。

バックエンドが認証するのは元の呼び出し元か、それともゲートウェイか？

終了モードでは、元のエンティティが信頼できる場合でも、B の直接の TLS 対手は依然としてゲートウェイです。伝達条件のいずれかが破綻した場合、orders を信頼できる元のエンティティとして継続することはできません。透過モードでは、A と B が直接ハンドシェイクを行います。アクションを refund に変更しても、依然として認可拒否されます。

Service Mesh：暗号化のカバレッジと権限ポリシーは別々に考える

Mesh はプロキシが証明書配信と相互認証を引き受けることができますが、実際のカバレッジは、トラフィックがデータプレーンに入るかどうか、ワークロードが管理対象かどうか、およびポートポリシーによって異なります。Sidecar はデプロイメント方法の一つに過ぎず、すべての mesh を Pod ごとに sidecar があるものとして描画してはいけません。

例えば、Istio では PeerAuthentication が受信側の mTLS 要件を制御し、AuthorizationPolicy がアクセス認可を制御します。PERMISSIVE は平文と mTLS の両方と互換性を持たせることができ、「自動 mTLS を有効にする」というだけですべてのエントリが平文を拒否していると推論してはいけません。ambient などのモードにも独自の能力制約があります。Istio セキュリティ概念、PeerAuthentication

プロキシ間で暗号化されていても、アプリケーションがローカルプロキシ間で必ず TLS を使用するわけではありません。評価時には、実際の終了点、プロセス分離、およびバイパス可能なエントリを描画する必要があり、コンソールに表示される緑色のロックだけでエンドツーエンドのアイデンティティ境界を判断してはいけません。

ローテーション：古い証明書、古い接続、および復元チケットは 3 つの状態

教育用デプロイメントのエンド証明書が有効期間 2 時間、毎時ローテーションすると仮定します。10:00 に発行された新しい証明書は 11:00 に置き換えられますが、10:30 に確立された長期間の接続がすぐに再認証されることを意味しません。証明書の期限切れは、通常、アプリケーションの書き込みのたびにチェーン検証を自動的にトリガーすることはありません。接続寿命の制限、アクティブな切断、または再認可が必要かどうかは、明確なポリシーが必要です。

ルートまたは中間 CA のローテーションには、重複信頼を採用できます。まず新旧のアンカーを含むバンドルを配布し、受信側がすでに読み込んだことを確認してから、新しい発行チェーンに切り替え、最後に古い資格情報が終了し、他の関連状態の処理が完了した後、古い信頼を削除します。発行者だけを先に切り替えると、まだ更新されていないクライアントはすぐに相互運用性を失います。

セッション復元は、前の認証コンテキストを継承して証明書を送信しない場合があります。あるアイデンティティを無効にする場合、新しいハンドシェイクの検証だけでなく、既存の接続、復元チケット、および認可キャッシュも考慮する必要があります。短い有効期間は、一部の暴露ウィンドウを短縮するだけです。システムが mTLS を使用しているからといって、0-RTT を今回のクライアント証明書認証が完了した通常のリクエストとして扱うことはできません。

API Key、アクセストークンとの連携方法

OAuth の証明書にバインドされたトークンでは、証明書のダイジェストをトークンに関連付ける。リソースサーバーは、現在の mTLS 証明書がそのバインドに一致するかを確認し、盗まれたトークンだけでの悪用を難しくする。これは、通信相手の認証とリクエストの認可を連携させる例である。「JWT を使っているから mTLS の確認は不要」として検証を省略してはならない。RFC 8705：証明書にバインドされたアクセストークン

接続の再利用、署名アルゴリズム、トークン検証キャッシュ、およびリクエスト規模に依存しない、固定のオーバーヘッドランキングは存在しません。また、API Key をゼロトラストと本質的に互換性がないと見なすこともできません。重要なのは、アイデンティティを明確にし、最小権限を適用し、継続的にポリシーを実行することです。

引き続き参照

• 証明書と PKI：名前、信頼パス、発行および失効。
• TLS 1.3 ハンドシェイク：認証メッセージ、復元および early data。
• リバースプロキシとロードバランシング：終了点とプロキシ転送。