Log4Shellとゼロトラスト

本ブログは、CSA本部のブログを著者の許可を得て翻訳したものです。本ブログの内容とCSA本部のブログとに相違があった場合には、CSA本部のブログの内容が優先されます。

Log4Shellとゼロトラスト

このブログは、Appgateのこちらの記事を元にしています。
著者:Jason Garbis、Appgate

Log4Shellの脆弱性が発覚してからわずか数週間しか経っていませんが(関連する問題はまだいくつか残っています)、世界中のセキュリティチームは、診断、検証、更新、コミュニケーションのために奔走しています。一歩下がって振り返るにはまだ少し早いかもしれませんが、私はいくつかの考えをコミュニティと共有したいと思います。

Log4Shellは、悪用が容易であるだけでなく、一般的に攻撃対象がすべてのユーザーに利用可能であり、非常に陰湿な脆弱性です。多くの場合、そのユーザーは認証前の状態です。場合によっては、悪意ある者がウェブサイトのログインページから直接攻撃を仕掛けて成功させることも可能です。さらに、このエクスプロイトは、通常、信頼されたゾーンの企業ネットワーク上で動作するロギングサーバー自身によって実行されます。ロギングサーバーは、インターネット上の悪意のあるサイトにアウトバウンドのリクエストを行い、悪意のあるコードを取得し、ローカルで実行します。

この種の脆弱性に対しては、ゼロトラストセキュリティとその中心的な考え方である最小権限の原則を実施することの重要性を示しています。それは、不必要にインターネットにさらされているアプリケーションがあまりにも多いからです。ZTNA(Zero Trust Network Access)技術を使用すると、ユーザーがアクセスを許可され認証されない限り、すべてのリソースを見えなくし、攻撃対象を減らすことができます。

Log4Shellは、認証のみのセキュリティではあまりにも弱すぎることを示す好例で、悪意のあるアクターにログイン画面を見せるだけでも悪用されてしまいます。ゼロトラストの最小権限の原則は、プライベートなアプリケーションがネットワーク上に隠れていることを保証し、悪用される可能性を最小限にします。

もちろん、会社のWebサイトのように、公開しなければならないアプリケーションやWebサイトもあります。しかし、企業はセキュリティの考え方を変えることで、顧客専用のWebアプリケーションに対しては、実際の顧客にしかアクセスできないようにすることを検討すべきです。

例えば、ビジネス向けの出荷・物流サービスを提供している企業であれば、顧客のログインページをあらゆる攻撃者に公開する理由はありません。ゼロトラスト方式を採用すれば、正当なお客様だけがログインを試みることができ、攻撃者がログインサイトを悪用することを防ぐことができます。このような安全性の高いアクセス方法をお客様に要求することは、合理的であるだけでなく、お客様に対するビジネスのセールスポイントにもなり得ます。

一般に公開する必要のあるサーバーやサイトについては、組織はゼロトラストの原則である最小権限モデルを適用しなければなりません。これらのサーバーは、広い範囲の社内ネットワークにアクセスできないようにする必要があります。すべてのアクセスはデフォルトでは拒否され、定義されたポリシーに基づいて明示的に許可されたアクセスのみが許可されなければなりません。このモデルは、インターネットへのアウトバウンドアクセスにも適用する必要があります。

企業は、ネットワーク上で稼働しているリソースだけでなく、それらのリソースが何にアクセスすることを許可されているのかを明確に把握し、明確に定義されたゼロトラストポリシーによってアクセスを許可する必要があります。これは、内部のサーバー間のアクセスについても、正当かつ合理的な要件です。セキュリティチームは、必要なアクセスを許可するためのポリシーを文書化し設定する責任をITチームやアプリケーションチームに負わせなければなりません。また、セキュリティチームは、それ以外のすべてのアクセスを制限する責任も負わなければなりません。

管理者からサーバーへのアクセス(アップデートや設定変更など)には、ITサービスマネジメント(ITSM)のビジネスプロセスに基づいてアクセスを制御するゼロトラストシステムを用いて、定義されたメンテナンスウィンドウを使用すべきです。さらに進んだ組織では、サーバーをペットではなく家畜のように扱うDevOpsのアプローチを検討する必要があります。つまり、サーバーのアップグレードやメンテナンスは行わず、マスターイメージを更新して新しいサーバーをデプロイすることになります。

サーバーからインターネットへのアクセスの場合、ほとんどのサーバーは任意のインターネットサイトにアクセスする正当な必要性はなく、むしろアクセスを許可することはセキュリティ上の弱点となります。組織は、このようなアクセスをブロックするか、許可された厳格なサイトに制限する必要があります。DNSやNTPなどのコアネットワークやインフラサービスは、企業が管理する内部システムに限定する必要があります。

Log4Shellはまた、ソフトウェアサプライチェーンのセキュリティと完全性に関するもっともな疑問を提起していますが、これについては別のブログ記事で取り上げます。ソフトウェアをどの程度信頼しているかにかかわらず、「侵害を想定する」というゼロトラストの原則に基づいて運用する必要があります。オープンソース、ベンダーから提供されたソフトウェア、または独自に作成したソフトウェアが危険にさらされていると想定する場合、最低限、ソフトウェアのインバウンドとアウトバウンドを制限し、すべてのアクセスがポリシーによって明示的に制御されていることを確認し、実際の動作を記録して監視する必要があります。

今日のリモートワークの世界における複雑な脅威の状況、脆弱性が発生する頻度、ハイブリッド環境の複雑さ、デバイスの急増を考慮すると、多くの企業や政府機関は、ゼロトラストへの移行に急速に乗り出しています。ZTNAソリューションは、以下の方法で移行をスムーズに行うことができます:

  • 例えば、SPA(Single Packet Authorization)を使用して、ポートを積極的に隠蔽し、インターネットに接続されたサーバーを権限のないユーザーから見えないようにします。
  • デバイスとユーザーのリスクへの対応:きめ細かなZTNAポリシーは、限られたリスクに基づいてユーザーデバイスに適切な権限を調整し付与することができます。
  • サーバーやユーザーデバイスとの間のトラフィックを制御します。多くのZTNAソリューションは、「アップルール」(例えば、ユーザーのモバイルデバイスがデータベースにアクセスする必要がある場合など)として知られる、リソースのやり取りに対するユーザー/デバイスのポリシーを必要とするユースケースでうまく機能します。しかし、「ダウンルール」、つまりサーバー、サービス、リソースから「下方向」のユーザーデバイスとのやりとりを扱うこともサポートされるべきです(例:リモートデスクトップのサポートやエンドポイントプロテクションの集中管理プラットフォーム)。この両方をサポートするZTNAプラットフォームを見てください。
  •  幅広いITおよびセキュリティエコシステムの統合をサポートします。ZTNAは、脅威インテリジェンスツール、SIEM(Security Incident and Event Management)ソリューション、EDR(Endpoint Detection and Response)プラットフォーム、ITSMソリューションなどと統合する必要があります。
  • エンタープライズスケールとスピードでの運用。多くの組織は単一のユースケースからスタートしますが、最終的には、ZTNAソリューションは、組織全体のアクセスコントロールの全負荷に対応できなければならず、また、ネットワークやクラウドエコシステム全体のすべてのアプリケーションを含む、拡大するフットプリント内の負荷レベルの増加にも対応できなければなりません。

この数週間は、情報セキュリティに携わる多くの人々にとって困難な時期でした。あなたが実務者であれば、その献身的な努力に感謝します。もしあなたが組織のビジネスサイドにいるのであれば、企業を守るために夜も週末も働いているセキュリティチームやネットワークチームに、どうか辛抱強く対応していただきたいと思います。

Log4Shellは、これまでに見たことのない最悪の脆弱性であり、セキュリティに対するゼロトラストアプローチの必要性とその価値を明確に示しています。この事件をきっかけにして、ゼロトラストへの移行を始めたり、加速させたりしてください。無駄にする時間はありません。ゼロトラストの原則とアプローチは、明らかに優れたセキュリティを提供することが証明されており、あなたには組織をより良い場所へと導く責任があります。今こそ、始める時です。

Log4Shellとゼロトラスト」への1件のフィードバック

  1. 諸角昌宏

    クラウドサービスを含めてアプリケーションがインターネットから直接アクセスできる環境であることが問題であり、これを解消することが重要である。仮にアプリケーションに脆弱性があったとしても、接続できる人が正当なユーザだけであれば、セキュリティ侵害はほぼ防げる。
    では、なぜインターネットから直接アクセスできることが問題かというと、正当な人にも悪意のある人にも、アクセスするための口が常に開いている、いわゆるリクエスト/レスポンス型のアーキテクチャが持つ脆弱性である。
    これを解決するためには、default-DENYを実装することで、アプリケーションにアクセスするための口は常に閉じておき、アクセスが許可された人に対してだけ口を開けるという仕組みが必要。これが、今までの「接続」してから「認証」という流れを、「認証」してから「接続」という流れに変えることである。
    そのためには、ゼロトラストネットワークやSDPを実装することが重要である。

    返信

諸角昌宏 へ返信する コメントをキャンセル

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

*