標準的なTLS接続はトラフィックを暗号化しますが、ほとんどのシナリオでクライアントが実際に誰であるかを証明しません。パスワード、APIキー、IP許可リスト、トークンベースの制御はセキュリティ層を追加しますが、共有、漏洩、コピー、または誤ったコンテキストでの使用が可能です。mTLSはそれとは対照的に、クライアントが秘密鍵を保持していることを検証し、接続レベルでより強力なアイデンティティシグナルを生成します。
B2B API、決済フロー、医療データ共有、IoTデバイストラフィック、管理インターフェースアクセスにおいて、この違いは重要です。すべてのパートナー、デバイス、管理者が独自の証明書を持って到着し、証明書の有効期間、CAチェーン、CN、フィンガープリント、検証結果がすべて監査可能です。ただし、各アプリケーションがその情報を独立して解析することを要求すると運用の複雑さが増します。
従来のmTLSデプロイメントでは、CAバンドル管理、検証モード選択、エラーコード、証明書フィールドの抽出とアプリケーションへの転送が断片化した懸念事項です。ある環境では証明書が必須で、別の環境は移行中にoptionalモードが必要です。レガシーCAチェーン、テスト証明書、パートナー移行はすべて厳格な検証と制御された許容のバランスを必要とします。
正しいアプローチはmTLSをサービスプロファイルとして管理することです。検証モード、CAファイル、CAエラー戦略、証明書フィールドのバックエンドへの転送、AAM条件付きアクセスポリシーはすべて同じモデルに存在する必要があります。
TR7 TLS / mTLSクライアント証明書認証はこのモデルを提供します：クライアント証明書を接続レベルの制御から引き上げ、バックエンドサービスとアクセスポリシー両方に使用可能なアイデンティティオブジェクトへと変えます。
TR7はmTLS検証を、サービスごとの検証モード、CA管理、証明書フィールド転送、AAMアクセスポリシーと単一の一貫したモデルで適用します。
none、optional、requiredモードにより、各サービスが独自のmTLSポリシーを適用できます。証明書を必須にする、移行中はoptionalに保つ、特定のサービスでは無効化する、のいずれかが選択できます。
検証コード、SHA1フィンガープリント、CN、追加の証明書フィールドをHTTPヘッダーにマッピングできます。バックエンドは証明書自体を解析せずに直接アイデンティティ情報を読み取ります。
証明書ヘッダーはpresent、verified、verify、sha1、cnなどのフィールドに解析できます。検証が失敗した場合でも、証明書データを制御された方法でログに記録し決定エンジンに渡すことができます。
CA検証エラーを完全に拒否する、移行中にまとめて許容する、または特定のエラーコードに対してのみ緩和するかを選択できます。これによりステージング、パートナー移行、本番ポリシーが同じmTLSモデルで共存できます。
TLS / mTLSクライアント証明書認証は、クライアント証明書をエッジで検証、解析、ログに記録し、バックエンドと共有します。
TR7はクライアント証明書認証の動作を各サービスに対して独立して管理します。noneモードでは証明書は要求されません。optionalモードでは提示された場合に証明書が解析され、なければ接続を継続できます。requiredモードでは証明書のない接続はすべて拒否されます。この構造により本番での厳格なセキュリティ、ステージングでの柔軟性、移行中の段階的ロールアウトが実現します。同じプラットフォーム上の異なるサービスが異なるmTLS要件を強制できます。
TR7はサービスごとのCAファイルに対してクライアント証明書を検証できます。1つのサービスにパートナーAのCAチェーン、別のサービスにパートナーBのチェーンを使用できます。この分離により異なるビジネスパートナーやデバイスグループを、単一のグローバルCAリストに依存せずに同じADC上で分離して管理できます。
TR7はx-ssl-verifyなどのヘッダーを介してクライアント証明書の検証ステータスをバックエンドに配信できます。検証成功、証明書なし、特定の検証失敗がアプリケーションに見えます。バックエンドはTLSスタックや証明書解析を処理せずに接続のmTLSステータスに基づいて決定できます。
TR7はクライアント証明書からCommon NameとSHA1フィンガープリントを抽出し、ヘッダーとしてバックエンドに転送できます。CNはパートナー、デバイス、ユーザー、サービスの識別子として機能します。SHA1フィンガープリントは許可リスト、監査、マッチング、高速失効シナリオの実用的なキーを提供します。
caErrorStrategyによりCA検証失敗への異なる対応が可能です。ignoreAllは一時的なデバッグや移行シナリオですべてのCAエラーを許容できます。manualIgnoreListは特定の検証エラーコードにのみ許容を限定します。本番ではこの柔軟性を無効化してゼロ許容を強制できます。このモデルは厳格なセキュリティと現実的な移行ニーズのバランスを制御された形で実現します。
TR7は受信クライアントから証明書を要求するだけでなく、バックエンドサービスへの接続時にクライアント証明書を提示することもできます。バックエンド向けの接続は検証必須、CAファイル、ADCクライアント証明書で設定できます。これによりクライアントからTR7、TR7からバックエンドの両方のレグで独立したTLS信頼ポリシーが実現します。
クライアント証明書は強力なアイデンティティシグナルですが、アクセス決定全体を単独で担う必要はありません。TR7は証明書データをAAM条件付きアクセスポリシーの1つの入力として使用できます。証明書、IPアドレス、デバイスポスチャー、ユーザーグループ、時刻、MFAステータスをすべて合わせて評価できます。mTLSはより広いゼロトラストアクセス決定の1つのコンポーネントになります。
証明書検証が成功しても、リクエストが自動的に安全になるわけではありません — コンテンツと量の制御が引き続き適用されます。TR7はmTLSアイデンティティ層をWAAP、DDoS、ボット行動分析と並行して実行します。mTLSがクライアントが誰であるかを確立し、WAAPがリクエストが何をしているかを評価し、DDoS層がトラフィック量を評価します。3つの制御はすべて同じサービスの前で同時に適用できます。
optionalモードでは、証明書を提示するパートナーはmTLSアイデンティティで処理され、証明書移行がまだ完了していないクライアントは代替認証メカニズムにフォールオーバーできます。このパターンにより大規模なB2B移行をすべてのパートナーを同日にmTLSに強制することなく安全にロールアウトできます。移行完了後、サービスをrequiredモードに移行できます。
mTLS接続では、証明書サブジェクト、発行者、有効期間、検証結果、フィンガープリントなどのフィールドをログに記録できます。SIEMでは、どのパートナーがどの証明書でどのサービスにアクセスしたかが明確になります。期限切れ、自己署名、発行者の失敗などのイベントを個別に分析できます。これらのレコードはコンプライアンス、インシデント調査、パートナー監査に対して強力な監査証跡を生成します。
mTLS操作はエンドツーエンドでカバーされます：バインド動作、検証コード、ヘッダーベースの証明書検出、フィンガープリント正規化、CAファイルのスコープ設定、SNI/Host検証。
検証のnone、optional、required動作はサービスのエントリポイントで設定されます。requiredモードでは証明書を提示しないクライアント接続は拒否されます。optionalモードでは証明書が提示された場合に解析され、なければリクエストが代替ポリシーフローに継続できます。
証明書の検証結果は数値エラーコードで表現できます。ゼロは検証成功を表し、他の値は発行者が見つからない、証明書の有効期限切れ、証明書がまだ有効でない、自己署名証明書などの状態を示します。この値はヘッダーとしてバックエンドに転送できます。
x-ssl-verifyが空または証明書が使用されていないことを示す場合、クライアントは証明書を提示しなかったとして扱われます。値が0の場合は証明書が正常に検証されています。他の値の場合、証明書データは存在するかもしれませんが検証が失敗しています — これはログとポリシー決定で個別に処理できます。
フィンガープリント値は大文字小文字混在やコロン区切り形式で届くことがあります。TR7は比較と許可リスト操作が一貫して機能するよう値を正規化します。同じ証明書が形式の違いにより異なるアイデンティティとして扱われることはありません。
各サービスは独自のCAバンドルを使用でき、パートナー、デバイスグループ、内部サービス全体でトラストルートを分離できます。CA変更はサービスへの影響を考慮して計画し、監査する必要があります。
mTLSを使用するサービスでは、証明書検証に加えてSNIとHost検証を有効化できます。証明書、SNI、Hostを合わせて評価することで、リクエストのアイデンティティ、ターゲットドメイン、HTTPルーティングの意図がすべて組み合わせて検証されます。このモデルはドメインフロンティング的な悪用のリスクを低下させます。
各パートナーは一意のクライアント証明書でAPIに接続します。TR7はCNとSHA1フィンガープリント値をログに記録し、バックエンドに転送し、パートナーごとの監査とレート制限の決定をより容易にします。
各デバイスは工場でロードされた一意の証明書を使用してTR7に接続できます。デバイスシリアル番号はCNフィールドに含まれ、フィンガープリント許可リストにより失効とアクセス制限のフローがより迅速に管理できます。
医療機関は提供者システムとのデータ共有時にmTLSを使用して接続レベルで認証できます。証明書が期限切れになるか検証が失敗すると、手動介入なしでアクセスが自動的に遮断されます。
システム管理者はクライアント証明書を使用してTR7管理インターフェースに接続できます。AAMを通じたMFAとデバイスポスチャーと組み合わせると、特定のラップトップ、特定の証明書、検証済みの管理者アイデンティティがすべて確認されます。
エッジでクライアント証明書を検証し、バックエンドに転送し、AAMポリシーと組み合わせます。お客様のサービスでライブセットアップをご案内します。