証明書のピン留めとは
証明書のピン留めは、セキュリティで保護されたセッションを確立するときに、認可または "ピン留め" された証明書のみが受け入れられるセキュリティ手法です。 別の証明書を使用してセキュリティで保護されたセッションを確立しようとすると、拒否されます。
証明書のピン留めの歴史
証明書のピン留めは、もともと中間者 (MITM) 攻撃を阻止する手段として考案されました。 証明書のピン留めは、2011 年に DigiNotar 証明機関 (CA) が侵害されたことで最初に知られるようになりました。このとき、攻撃者は Google を含むいくつかの有名な Web サイトのワイルドカード証明書を作成することができました。 Chrome は、Google の Web サイトの現在の証明書を "ピン留め" するように更新され、別の証明書が提示された場合は接続を拒否します。 攻撃者が CA を信用させて不正な証明書を発行する方法を見つけたとしても、Chrome によって無効と認識され、接続は拒否されます。
Chrome や Firefox などの Web ブラウザーは、この手法を実装する最初のアプリケーションでしたが、ユース ケースの範囲は急速に拡大しました。 モノのインターネット (IoT) デバイス、iOS および Android のモバイル アプリ、さまざまなソフトウェア アプリケーションのコレクションでは、中間者攻撃から保護するためにこの手法を使用し始めました。
数年間に渡って、証明書のピン留めは適切なセキュリティ プラクティスと見なされていました。 公開キー基盤 (PKI) の状況に対する監視は、パブリック CA の発行の実践に対する透明性が高まったことによって改善されました。
アプリケーションで証明書のピン留めに対処する方法
通常、アプリケーションには、認可された証明書または証明書のプロパティ (サブジェクト識別名、サムプリント、シリアル番号、公開キーなど) の一覧が含まれています。 アプリケーションは、個々のリーフ証明書またはエンド エンティティ証明書、下位 CA 証明書、またはルート CA 証明書に対してピン留めする場合があります。
アプリケーションで受け入れ可能な CA の一覧が明示的に指定されている場合は、証明機関が変更または期限切れになったときに、固定された証明書の更新が定期的に必要になる場合があります。 証明書のピン留めを検出するには、次の手順を実行することをお勧めします。
アプリケーション開発者の場合は、変更されるか、期限切れになる CA に関する次のいずれかの参照をソース コードで検索します。 一致がある場合は、不足している CA を含むようにアプリケーションを更新します。
- 証明書の拇印
- サブジェクト識別名
- 共通名
- シリアル番号
- 公開キー
- その他の証明書のプロパティ
カスタム クライアント アプリケーションが Azure API やその他の Azure サービスと統合されていて、証明書のピン留めを使用しているかどうかわからない場合は、アプリケーション ベンダーとチェックします。
証明書のピン留めに関する制限事項
証明書のピン留めの実践では、許容できない証明書のアジリティのコストを伴うため、広く議論されています。 特定の 1 つの実装 (HTTP 公開キーのピン留め (HPKP)) は、完全に非推奨になりました
証明書のピン留めを実行する方法については単一の Web 標準がないため、その使用状況を検出するための直接的なガイダンスを提供することはできません。 証明書のピン留めを行うことはお勧めしませんが、証明書のピン留めを使用する場合は、その実践によって生じる制限に注意する必要があります。
- ピン留めされた証明書をすぐに更新できるようにします。
- CA/Browser フォーラムのパブリック証明書の発行と管理に関するベースライン要件などの業界要件では、特定の状況で証明書を 24 時間以内にローテーションおよび取り消す必要があります。