> > CAA が持つセキュリティ上の利点

RSSフィード

CAA が持つセキュリティ上の利点

190449881.jpg2017 年 9 月 に定められた新しい業界標準で、すべての認証局(CA)に対し、CAA(Certificate Authority Authorization)レコードの確認が義務化されました。
この措置は、ウェブサイト管理者からすれば、自分のサイトを証明書の不正発行から守る追加の保護策となるだけでなく、組織の証明書ポリシーを徹底する技術的手段にもなります。

CAA の概要

CAA レコードを設定することで、自サイトの証明書発行を、どの CA に対して許可するのかをコントロールできます。これで、ウェブ PKI の大きな問題点のひとつに対処できます。その問題とは、CA をどれかひとつでも悪用すれば、あらゆるウェブサイトのセキュリティを侵害できるという問題です。一般的に、ひとつのサイトで利用する CA の数は、ごく少数です。したがって、世界中の CA(各種のプラットフォームで、およそ 100 の信頼できる CA が存在しています)に自サイトの証明書を発行する許可を与える必要はありません。

証明書の要求を受けた場合、CA は最初に対象のウェブサイトの CAA レコードを照会してからでなければ、証明書の検証または発行を行えません。CAA レコードは新しくできた一種の DNS レコードで設定は任意ですが、ウェブサイトの DNS レコードに加えて CAA レコードも設定しておくと保護の強化に役立ちます。2017 年 9 月、CA が証明書を発行する際の条件として、CAA レコードの確認を必須とする業界標準が新たに制定されました。

2017 年は、CAA を利用するサイトが大幅に増えました。世界の大規模サイトがどのような SSL 構成を行っているかを分析している SSL Pulse の調べによれば、CAA を利用するサイトの数は、2017 年 9 月から 11 月で 2 倍、2017 年の年間でみると 10 倍以上に増えています。増加率こそ高いものの、CAA を利用しているウェブサイトの数はわずか数千にすぎず、いまだにセキュリティ対策としては珍しい部類です。

ウェブサイトは CAA を使わなければならないものと思われている場合が多いようですが、これは誤解です。誤解の原因は、CAA の基本的な仕組みが混乱を招きやすいことです。デフォルトでは、CAA レコードを使っていないウェブサイトの場合、どの CA でも証明書を発行できます。

CAA レコードを使うと、証明書の発行を許可する認証局の一覧を、ホワイトリストの形で制限することになります。CAA に関心がないなら、何も変更する必要はありません。CAA レコードの登録がなければ、すべての CA が自分のドメインに対する証明書を発行できます。

ポリシーの徹底

CAA の役割はセキュリティ対策にとどまりません。自分のドメイン用に証明書を発行する権限を持つ CA を制限してリスクを低減する以外に、証明書に関する企業ポリシーを徹底するのにも役立ちます。

企業の多くが、証明書の購入と要求、展開に関わる社内ポリシーの徹底に苦心しています。複数の事業所または独立性の高い部門を有する大規模な組織は特に苦労が多いようです。CAA は、証明書ポリシーの順守を徹底するための技術的手段として利用できます。

たとえば、エンジニアリング部門のだれかが自社ドメインで新たなサービスを設定したとしましょう。しかしながら、エンジニアリング部門が証明書を要求したとしても、承認されていない CA の利用は制限されます。また、許可されていない証明書の発行要求を CA が受けた場合に、その旨の通知を CA から受けるための報告用 URL または E メールアドレスを任意で設定できます。

CAA の展開

CAA は新しいセキュリティ施策のひとつで、ウェブサイトの SSL 構成や証明書ポリシーの強化に貢献します。現状では CAA を使ったことがない管理者が多いと思われますので、展開の手順を以下にまとめました。CAA 比較的導入が容易で、HTTP Strict Transport Security(HSTS)や HTTP Public Key Pinning(HPKP)などと比べれば、設定や運用上のミスは非常に起きにくい仕組みです。

CAA の利用には、ある技術的前提条件があります。マネージド DNS を使用している場合、CAA は新しい DNS リソースレコードですので、プロバイダーも CAA をサポート可能でなければなりません。Cloudflare、Dyn、Route 53 を含め、主要プロバイダーの多くは CAA をサポートしています。主要プロバイダーによる CAA のサポート状況については、SSL Mate が一覧にまとめています

以下に CAA の展開を計画するにあたってのガイドラインを示します。また、CAA を展開するとウェブサイトのセキュリティや組織のポリシーにどのような利点があるかについても概要をまとめました。

  1. まずは組織の証明書ポリシーを参考に作業を開始します。承認している CA がある場合は、それらを一覧表にまとめ、CAA レコードに入力します。組織に証明書ポリシーがない場合は、少なくとも組織で普段よく使われている CA がどれかを調べましょう。承認する CA の一覧を修正する必要性が生じた場合など、CAA レコードは随時更新(または削除)できます。変更は DNS の TTL に従って反映されます。

  2. DNS の CAA レコードを作成します。ポリシーは、CA を 1 つあるいは少数のみに制限する方法もありますし、多数のプロバイダーを組織で使える柔軟な設定も可能です。CAA ポリシーで 10 の CA を許可したとしても、以前よりは大幅な制限です。DigiCert のみにウェブサイトの証明書の発行を許可する CAA レコードの例を下記に示します。

    yourdomain.com.     CAA 0 issue "digicert.com"

    このレコードは、ドメイン配下の全サブドメインに適用されます。 CA を追加したい場合は、CA ごとに新しい行を作成します。末尾に記述するホスト名で CA を指定しますが、このホスト名は各 CA が明示的に決めています。ホスト名は CA のホームページと同じとは限りませんので、CA のマニュアル等を確認して適切な構文で記述してください。SSLMate では、この作業を効率的に行える無償の CAA レコード生成ツールを配布しています。なお、サブドメインに異なる CAA レコードを設定して柔軟性を高めることもできます。CAA レコードは、要求の最上位ラベルから、DNS ツリー内で階層を追って確認が行われます。たとえば、"sub.domain.com" 用の証明書を要求した場合、CA は最初にサブドメインのレコードを確認し、サブドメインレベルでレコードが存在しない場合には、続いてルートドメインでレコードを確認します。CNAME については、親ドメインが最後に確認されます。

  3. 設定後は、証明書要求に応じてドメインの CAA レコードが確認されて、(上記の設定例では)DigiCert 以外の CA は証明書の発行を拒否しなければなりません。2017 年 9 月 8 日現在、CA/B Forum は全 CA に対し CAA レコードに従うことを義務付けています。この義務は、無償の証明書やクラウドサービスプロバイダーによって提供される証明書を含め、すべてのトラステッド(信頼されている) CA に適用されます。CA がレコードに従わずに証明書を発行する行為は不正にあたり、制裁または信頼が解除される対象となる可能性があります。

  4. 以上で自分のドメインに対する証明書の不正発行リスクは減りました。反対の立場からみると、ハッキングを試みようとする攻撃者は CAA レコードで指定されている CA しか使えませんので、攻撃手段が削がれることになります。利用している CA のアカウント管理方法次第では、仮に攻撃者が自分のウェブサーバーに侵入しても、証明書を入手不能にできます。たとえば、CAA ポリシーで DigiCert のみが自分のサイトの証明書を発行できるように設定している場合、攻撃者には OV / EV 認証手続きを完了させる手だてがありません。従業員や不正ユーザーも同様の制限を受けるため、組織内の証明書ポリシー違反を減らせます。将来的には、認証方式などのさらに細かい制御を CAA で行えるような拡張が導入される可能性があります。
    特定の CA で認証または発行の手続きに脆弱性が存在するようなシナリオの場合、自分のドメインが影響を受ける可能性は低くなります。CAA が 2016 年に義務付けられていたなら、Web PKI 関係で最も重大とされた不正発行の多くは防げていたはずです。

ただ、CAA にも限界はあります。CA が悪意のある挙動をとるような(アンダーグラウンドな活動に走ってしまった、あるいは攻撃者の侵入を許してしまった)場合は、単純に CAA レコードの記述を無視して証明書を発行するケースが考えられます。また、DNS に侵入されてしまうと、個々のウェブサイトはやはり危険にさらされます。攻撃者が DNS 設定を改ざんできるなら CAA レコードの削除も可能なわけで、結果的にすべての CA に対してサイトの証明書の発行を許可する設定に変更できてしまいます。DNS レコードのスプーフィング(なりすまし)でも上記の目的を同様に達成できますが、これを実行に移せるのは極めて高い能力を有する攻撃者だけです。

最後にひとこと。CAA で対処できるのは、トラステッド CA から発行された証明書を使用する場合に限られます。社内のイントラネットのように、ローカルのルート証明書がデバイス上で信頼されているシナリオを扱うようにはできていません。このようなローカルのルートは、パブリックのルートプログラムによる管理下にないことから、CAAポリシーの制限を受けることなく証明書を発行できます。これを利用すれば、ローカルネット上でウェブサイト宛のトラフィックを傍受または監視ができてしまいます。

この記事は、米国 DigiCert の許諾の下 DigiCert Blog の投稿記事を翻訳したものです。
オリジナル記事はこちら: The Security Benefits of CAA - [2017 年 11 月 8 日投稿]