暗号化の世界の変化: 2020 年の TLS 展開
オンラインプライバシーは、もはや単に詮索好きな目から遠ざかることだけではありません。 ウェブ上の暗号化はプライバシーの保護に重要な役割を果たしており、常に変化しています。
かつてはログイン ページやチェックアウト ページ専用でしたが、トランスポート層セキュリティ (TLS) などの暗号化プロトコルは、エンドポイントを認証して機密通信する方法を提供することから、最近では注目を集めています。 過去 2 年間で、TLS 標準も更新されました。 ブラウザはまもなく、TLS 1.0 や 1.1 などのプロトコルの古くて弱い実装をブロックするようになります。 現在でも広く使用されている安全でないプロトコルをロックダウンするための新しいプロトコルも導入されています。
企業が対応に苦労する可能性があることは容易に想像できます。 たとえば、昨年初め、セキュリティ研究者は、新興のドメインネームシステム暗号化プロトコルである DNS-over-HTTPS (DoH) を利用した初めてのマルウェア サンプルを発見しました。
TLS の状況は以前とは異なり、組織は Web サイトがその存続期間中安全に展開され、維持されるように、最新の開発状況を常に把握しておく必要があります。
変化に対応する
大半の企業は、新しい TLS アップデートがもたらすメリットを理解しており、変化に対して受け入れやすい姿勢を見せています。 たとえば、 F5 Labs の最新の TLS テレメトリ レポートによると、Alexa の上位 100 万サイトのうちほぼ 3 分の 1 が TLS 1.3 接続を受け入れていることがわかりました。 多くの点で、それはビジネス上理にかなっています。 人気の高い Web ブラウザのほとんどはすでにこの新しい標準をサポートしており、セキュリティとパフォーマンスの面でさまざまなメリットをもたらします。
ただし、最新の TLS を採用することは、まだすべてのユーザーにとって選択肢ではありません。
このような場合、企業は RSA キー交換を提供する暗号スイートを削除して、RSA キー交換を完全に無効にすることを検討する必要があります。 F5 の調査によると、セキュリティ研究者が依然として RSA を攻撃する方法を模索しているにもかかわらず、世界で最も人気のある Web サイトの 3 分の 1 以上が依然として RSA を優先暗号化アルゴリズムとして採用していることがわかりました。 これには、TLS サーバーの秘密鍵を使用して RSA 復号化および署名操作を実行できる 19 年前の ROBOT 脆弱性が含まれます。 F5 Labs の調査によると、世界のトップサイトのうち 2% 強が依然としてこの脆弱性に対して脆弱である可能性があります。
他のソフトウェアと同様に、セキュリティ研究者は TLS ライブラリの脆弱性を頻繁に発見します。 このため、Web サーバー、ロード バランサー、またはアプリケーション配信コントローラーの TLS スタックが更新されたときに通知を受け取るようにするのは、組織の責任となります。 迅速なパッチ適用のためのポリシーも重要です。
また、どの証明機関 (CA) でも、Web 上のあらゆるドメインの証明書を作成できることにも留意することが重要です。 このため、よく知られた信頼できる CA 2 つまたは 3 つにのみ許可を制限するのが賢明です。 これは、DNS 証明機関認証 (CAA) レコードを作成することによって実現できます。 さらに、HTTP Strict Transport Security (HSTS) ヘッダーを Web アプリに適用すると、ブラウザーは HTTPS 経由でのみサイトを安全に読み込もうとするため、セキュリティがさらに強化されます。 これは、安全でないページを強制的に読み込み、攻撃者がネットワーク トラフィックを盗聴、書き換え、リダイレクトできるようにするネットワーク攻撃を防ぐのに役立つ重要な手順です。
DNS CAA レコードは有効なドメインの証明書の誤発行を防ぐために作成されましたが、詐欺師が mybank.com などの既存のドメインの証明書を作成しようとすることはほとんどありません。 代わりに、サブドメインとしてブランド名「mybank」を使用して、mybank.attacker.com などの所有ドメインの証明書を作成します。
幸いなことに、CA によって証明書が作成されるたびに、その証明書はグローバルに分散されたデータベース (証明書の透明性ログ) に記録されます。 CT ログを監視することは、ドメインまたはブランドが脅威アクターによって偽装されているときに警告を受ける便利な方法です。
HTTPS があらゆる場所で利用されるようになったため、管理すべき暗号、キー、証明書も増えています。 DevOps 方法論の採用の増加と相まって、変更と展開の速度が継続的に増加していることを意味します。
セキュリティ ツールとテストが自動化ツールチェーンに統合されるのと同様に、HTTPS の構成も統合される必要があります。 これは、デジタル証明書の組織的な作成を検討し、最小キー長や暗号スイートなどの標準を定義する内部ポリシーを策定することを意味します。 この種の自動化は、有効期限が切れそうな証明書にも役立ち、サービスが中断される前に証明書を自動的に更新します。
TLS セキュリティギャップに注意
残念ながら、TLS が正しく導入されている場合でも、プライバシーとセキュリティのギャップは依然として多く存在します。 DNS-over-HTTPS (DoH) などのプロトコルは、これらのギャップを埋めるために登場しており、Web ユーザーのプライバシーを向上させる一方で、企業のセキュリティ チームが悪意のあるトラフィックを識別してブロックすることを困難にする可能性があります。 場合によっては、企業ネットワークの DoH を無効にしたり、ユーザー向けに内部 DoH サービスを展開したりする必要があります。 これらのサービスは Web プロキシと連携して、不要なトラフィックをフィルタリングするのに役立ちます。
結局のところ、世界最高の TLS 展開であっても、クライアント側のマルウェアによって悪意のあるコードが挿入されたり、サードパーティのスクリプトによって侵害されたりするのを防ぐことはできません。 そのため、HTTPS の限界と、どのようなギャップが存在するかを理解することは常に推奨されます。
確かなことは、暗号化は常に進化しているということです。 キーの長さは増加し、証明書は自動化され、政府は制限を課し、新しいプロトコルが登場しています。 この絶え間ない変化が、多くの組織とその顧客に新たなレベルのリスクをもたらします。 TLS の導入が不十分だと、ハッカー、規制当局、サイバーセキュリティ保険会社に見過ごされることなく、組織のインフラストラクチャの残りの部分について深刻な疑問が生じる可能性があります。