【ITニュース解説】Your Wildcard SSL Setup is a Security Nightmare (And You Don't Even Know It)

この記事では、ワイルドカードSSL証明書の設定が、知らないうちにセキュリティ上の大きなリスクを生み出している可能性について解説する。

ワイルドカード証明書は、*.yourapp.com のように、特定のドメインのすべてのサブドメインに対して有効なSSL証明書のことだ。これを使うことで、サブドメインごとに証明書を用意する手間が省ける。しかし、設定方法によっては、非常に危険な状態を招くことがある。

多くの人が、ワイルドカード証明書の設定方法を検索し、最初に見つかったチュートリアルに従って、certbot などのツールを使用しているだろう。その際、DNS認証を行うために、CloudflareなどのDNSプロバイダのAPIトークンを使用することが一般的だ。問題は、このAPIトークンに与える権限にある。

通常、certbot は、ドメインの所有者であることを確認するために、DNSレコードに特定のTXTレコードを追加する必要がある。そのため、APIトークンには、Zone:DNS:Edit のような、DNSゾーンを編集する権限を与えることになる。しかし、この権限は、TXTレコードの追加だけでなく、DNSゾーン内のすべてのレコードを削除、変更、または作成できる権限を含んでいる。

つまり、APIトークンが漏洩した場合、攻撃者は、すべてのDNSレコードを削除したり、ドメインを別のサーバーにリダイレクトしたり、メールを傍受したり、サブドメインを乗っ取ったりすることが可能になる。これは、企業のオンラインプレゼンス全体を破壊する可能性を秘めている。

APIトークンの漏洩経路はいくつか考えられる。例えば、設定ファイルが誤って公開リポジトリにコミットされたり、従業員が意図的に情報を漏洩させたり、サーバーが攻撃を受けてクレデンシャルファイルが盗まれたりする可能性がある。また、サプライチェーン攻撃によって、certbot のプラグインやACMEライブラリに悪意のあるコードが埋め込まれ、APIトークンが外部に送信される可能性も否定できない。

「最小権限の原則」に従って、Route53などの別のAWSアカウントを使用しても、根本的な問題は解決しない。アプリケーションは依然として完全なDNSアクセス権を持っているため、複雑さが増すだけで、セキュリティリスクは残る。

では、どうすれば良いのか？

解決策1：DNS委任による検証

ACME検証専用の別のDNSゾーンを作成する。例えば、メインのDNSゾーン example.com に対して、_acme-challenge.example.com のCNAMEレコードを作成し、_acme-challenge.acme.example.com を指すように設定する。そして、certbot には、acme.example.com ゾーンへのアクセス権のみを与える。これにより、APIトークンが漏洩しても、攻撃者はメインのドメインに影響を与えることができなくなる。

解決策2：DNS検証のプロキシ

ACME検証用のTXTレコードの更新のみを許可するプロキシサービスを構築または使用する。このプロキシは、リクエストされたドメインが _acme-challenge. で始まること、および値が有効なACMEチャレンジであることを検証する必要がある。検証に成功した場合のみ、実際のDNSクレデンシャルを使用してDNSレコードを更新する。

解決策3：適切なサービスの使用

最初からこの問題を考慮して設計されたサービスを使用する。これらのサービスは、完全なDNSアクセス権を与えることなく、DNS検証をプロキシする。

今すぐできることとして、以下の項目を確認することを推奨する。

• DNSトークンの権限を監査し、実際に何ができるのかを確認する。
• DNS委任を実装して、ACMEチャレンジを分離する。
• クレデンシャルをローテーションし、既に漏洩していることを前提に対処する。
• プロバイダがサポートしている場合は、有効期間の短いトークンを使用する。
• DNSの変更を監視し、変更があった場合にアラートを受け取るように設定する。
• ワイルドカード証明書が本当に必要かどうかを検討する。

ワイルドカード証明書の設定は、便利である一方で、セキュリティ上の大きなリスクを伴う可能性がある。この記事で紹介した対策を講じることで、リスクを軽減し、安全なインフラストラクチャを構築できる。