Okta VerifyがTLS接続を固定することでアイデンティティを保護する理由
このブログはこちらの英語ブログ（2024年10月2日公開）の機械翻訳です。
公開鍵固定とは？
通常、クライアントアプリケーションとサーバー間のトラフィックは、公開鍵基盤（PKI）に依存しています。このメカニズムはほとんどのインターネットトラフィックには十分ですが、Okta Secure Identity Commitmentでは、国家レベルの攻撃者も含めた高度で持続的な標的型攻撃を考慮する必要があります。
Oktaは、Okta Verifyを含むすべてのサービス間の通信のベースラインとして、PKIとTLSを使用しています。しかし、高度な攻撃シナリオでは、Oktaの管理外の公開証明書が侵害され、デバイスのオペレーティングシステムによって受け入れられたり、そのデバイスのユーザーによって明示的に信頼されたりする可能性があります。このような場合、攻撃者は、中間者攻撃（AiTM）によって、Okta VerifyとOktaのサーバーサイドエンドポイント間のトラフィックを検査および操作することができ、これにより、後で説明するいくつかの問題が発生します。
公開鍵固定は、クライアントアプリケーションが要求する証明書のみを許可リストに追加し、それ以外をすべてブロックする方法です。つまり、公開認証局が侵害された場合（Digicertなど）でも、当社のクライアントアプリケーションはそれらの証明書を受け入れません。代わりに、攻撃者はOktaが社内で保持する秘密鍵を盗まなければ、当社のサーバーを偽装できません。
攻撃例：偽のWiFiまたはVPN
ユーザーがカフェで作業していると想像してください。 そのカフェの別の客が、WiFiパイナップルをバックパックに入れています。 このデバイスは、そのカフェのWiFiを偽装し、巧妙な戦術の1つとして、高い信号強度を偽装して接続を積極的に乗っ取る可能性があります。
デバイスが WiFiネットワークに接続すると、DNSやプロキシ設定などのネットワーク設定を取得し、それによって、すべてのトラフィックを適切な宛先に送信する前に、そのデバイス自身にルーティングすることができます。第三者のSSL証明書（または承認済みプロファイル）を盗用すれば、HTTPS トラフィックでさえも警告なしに暗号化を解除することができます。
これが実行されると、OpenID Connect などのフローはトラフィックの再ルーティングに対して脆弱になり、アクセストークンが盗まれたり、別のURLに設定されたりする可能性があります。
上記のフローでは、次のシーケンスが発生します。
- Okta Verifyは、プロトコルの仕様で要求されている組織のopenid-configuration設定に接続しようと試みます。
- トラフィックは攻撃者のインフラストラクチャに再ルーティングされます。
- 攻撃者のインフラストラクチャから返される値は、主要なパラメータを変更します。
- keys_uriを攻撃者のkeysエンドポイントに変更します。これにより、攻撃者はJWTを送信できるようになり、正当な秘密鍵がなくても検証を通過できるようになります。
- token_endpoint などのエンドポイントを変更し、標準で定義されたトークン交換フローが攻撃者のインフラストラクチャにルーティングされるようにします（その後、傍受することができます）。
- この時点で、攻撃者は攻撃の対象領域を大幅に拡大し、フィッシングと組み合わせることでアカウント乗っ取りにつながる可能性があります。
ピンニングによる保護
TLS接続のピンニングには、主に「信頼性」、「完全性」、「プライバシー」という3つの目的があります。
真正性
Oktaのクライアントアプリケーションは、改ざん防止機能と焼付けされた公開鍵とともに展開されます。Oktaのインフラストラクチャは秘密鍵を保持しているため、焼付けされた鍵を使用してサーバーの身元を確認します。つまり、Okta Verifyはフィッシングサイトやその他の攻撃者が管理するインフラストラクチャに接続するように欺くことはできません。
完全性
クライアントとサーバー間で転送されるデータのほとんどは、すでに検証可能な構造（JSON Web Tokenなど）にカプセル化されていますが、これらの構造を検証するために必要なエンドポイント（例：`/oauth2/v1/keys`）はそうでない場合があります。キーピニングにより、クライアントが不正に操作されたキーセットを受け入れることを防止し、誤設定やフィッシング攻撃など、攻撃対象領域の拡大につながる可能性を排除します。
プライバシー
Oktaは個人識別情報（PII）の使用を最小限に抑えるよう努めていますが、Okta Verify Device Assuranceの性質上、組織のセキュリティを向上させるために、デバイスとそれに関連する詳細なシグナルの識別が成功する必要があります。第三者がこのデータを読み取ると、攻撃やデータ収集に使用するために、ユーザーとデバイスの情報を収集する可能性があります。
ピン留めが有効になっている場合の攻撃の例
ピン留めを有効にすると、Okta Verifyは、データ送受信の前にTLSハンドシェイク中のTLS接続を検査します。その後、クライアントは接続を切断し、Okta以外のインフラストラクチャが転送中のデータを読み取りまたは変更する可能性を直ちに排除します。
この保護は、Okta FastPassの緩和策を表しており、ハードウェアキー/WebAuthnなどの他のフィッシング耐性のあるauthenticatorsでは達成できないものです。これらのauthenticatorsは、ブラウザの（ピン留めされていない）PKI + TLSの実装に依存しており、署名鍵をインターネット上で送信します。
短所
Oktaのピン留めの主な短所は、運用上の複雑さです。しかし、お客様により安全な環境を提供するため、弊社は喜んでこの追加作業を引き受けます。
ネットワーク境界内のすべてのトラフィックを検査するポリシーを定めている組織もあります。Okta Verifyのトラフィックが検査ルールに含まれている場合、攻撃者がトラフィックの検査や変更を行った場合と同様に、自社のネットワーク接続がブロックされます。
上記の理由により、Okta Verifyとインフラストラクチャ間のトラフィックの検査を許可すると、お客様が上記の攻撃シナリオにさらされることになります。ネットワークのトラフィックを検査する必要がある場合は、検査ルールからOktaのインフラストラクチャを許可リストに追加できます。ブラウザとOktaインフラストラクチャ間のログイントラフィックを検査する必要がある組織は、カスタムドメインを使用して、Okta Verifyに影響を与えることなく、そのドメインへのトラフィックを検査できます。
弊社ではこの分野を注視しており、セキュリティと運用性の向上につながる代替案があれば、積極的に検討したいと考えています。そのような代替案が採用された場合でも、セキュリティレベルは現状と同程度か、それ以上であることを保証します。
Oktaは、セキュリティを最優先することを約束しています。Oktaとお客様を守るため、Okta Verifyを世界で最も安全なauthenticatorにするべく、日々努力しています。キーピニングはOkta Verifyのセキュリティ全体において重要な要素であり、今後もお客様の安全を確保するために全力を尽くします。
以上の内容は、原文（英語）の機械翻訳であり、原文と内容に差異がある場合は、原文が優先されます。