証明書ピンニングは、クライアントがセキュアセッションを確立する際に認可された、または ピン留めされた証明書のみを受け入れるセキュリティ技術です。 クライアントは別の証明書を使って安全なセッションを確立しようとする試みを拒否します。
証明書のピン留め履歴
セキュリティコミュニティはもともと、中間者攻撃(MITM)を防ぐ手段として証明書ピンニングを考案しました。 証明書ピンニングは、2011年にDigiNotar認証局（CA）が侵害を受け、攻撃者がGoogleを含む複数の著名なWebサイト向けのワイルドカード証明書を作成した事件をきっかけに、広く注目されるようになりました。 GoogleはChromeを更新し、Googleのウェブサイトの現在の証明書をピン留めし、異なる証明書を示す接続は拒否するようにしました。 たとえ攻撃者がCAに偽の証明書を発行させたとしても、Chromeはそれを無効と認識し、接続を拒否します。
Chrome や Firefox などの Web ブラウザーは、この手法を実装する最初のアプリケーションの 1 つでしたが、ユース ケースの範囲は急速に拡大しました。 モノのインターネット(IoT)デバイス、iOSやAndroidのモバイルアプリ、そしてさまざまなソフトウェアアプリケーションが、中間者攻撃に対抗するためにこの手法を使い始めました。
何年もの間、証明書ピンニングは優れたセキュリティ対策とされていました。 公開鍵インフラ(PKI)の監督が強化され、公に信頼されているCAの発行実務に対する透明性が向上します。
アプリケーションで証明書のピン留めに対処する方法
通常、アプリケーションには、サブジェクト識別名、拇印、シリアル番号、公開キーなど、承認された証明書または証明書のプロパティの一覧が含まれます。 アプリケーションは、個々のリーフ証明書またはエンド エンティティ証明書、下位 CA 証明書、またはルート CA 証明書に対してピン留めする場合があります。
申請書に受け入れ可能なCAのリストが明示的に指定されている場合、証明書局が変更または期限切れになる際に、ピン留めされた証明書を定期的に更新する必要があるかもしれません。 証明書のピンピングを検出するには、以下の手順を踏みます:
アプリケーション開発者の場合は、変更または期限切れの CA に関する次のいずれかの参照をソース コードで検索します。 一致がある場合は、不足している CA を含むようにアプリケーションを更新します。
- 証明書の拇印
- サブジェクト識別名
- 共通名
- シリアル番号
- 公開キー
- その他の証明書のプロパティ
カスタム クライアント アプリケーションが Azure API やその他の Azure サービスと統合されていて、証明書のピン留めを使用しているかどうかわからない場合は、アプリケーション ベンダーに確認してください。
証明書のピン留めの制限事項
証明書ピンニングは、証明書の更新や差し替えの柔軟性を損なうという許容できないコストを伴うため、広く異論があります。 特定の実装の一つであるHTTP公開鍵ピニング(HPKP)は完全に非推奨となっています。
アプリケーションが証明書のピンニングをどのように実行するかを定義している単一のウェブ標準はないため、Microsoftはその使用状況を検出するための直接的な指針を提供していません。 Microsoftは証明書ピンニングを推奨していませんが、この方法を使う場合の制限があることを認識してください。
- ピン留めされた証明書が短期間で更新を受けられるようにしてください。
- 業界の要件、 例えばCA/ブラウザフォーラムの Publicly-Trusted 証明書発行および管理基準要件などでは、特定の状況下では証明書のローテーションと取り消しが最短24時間以内に求められています。
