タグ別アーカイブ: ゼロトラスト

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

本当のSDPよ立ち上がれ! ~ Will the real SDP please stand up?

本ブログは、Optiv Security Inc.が公開している “Will the real SDP please stand up?” の日本語版になります。本ブログは、著者およびOptiv Security Inc.の許可を得て翻訳し、公開するものです。本ブログの内容と原文の間で相違があった場合には、原文が優先されます。


本当のSDPよ立ち上がれ!

原文: 2019年7月10日
日本語版: 2019年7月23日

Software Defined Perimeter(SDP)という用語は、ゼロトラスト(Zero Trust)モデルで安全なアクセスを提供するための新たなアジャイルな方法として最近普及してきています。SDPは、クラウドセキュリティアライアンス(CSA)によって定義された要件で、VPN /ファイアウォール/ NACの組み合わせよりも効果的で安全な方法でリモートアクセス機能を提供します。

ただし、SDPはアーキテクチャ的に異なる点があるため、多少新たな考え方が必要です。SDPは、データプレーンとコントロールプレーンを分離するネットワークの概念に基づいて作られています。これは、認証コンポーネントを拡張したポリシー決定ポイント(PDP)とポリシー実行ポイント(PEP)モデルになります。SDPの認証プロセスにおいては、「コントローラ(Controller)」はアクセスを認証するためのポリシー決定ポイントであり、「ゲートウエイ(Gateway)」はサービスへのアクセスに許可または拒否を与えるポイントになります。ゲートウェイから分離されたPDPトラフィックを使用することで、ハイブリッドクラウド環境全体でユーザーが同時にアクセスを許可される集中型のポリシーモデルと認証をサポートしているため、この機能は他のアプローチとの大きな違いになります。接続が確立され、ゲートウェイがユーザーに対して識別されると、ゲートウェイは、コントローラからの変更を定期的に確認しながら、デバイスの状態(device posture)や定義された条件に基づいてリアルタイムで決定を行うというハイブリッドな役割を果たします。これにより、コントローラが停止した場合の可用性が向上するだけでなく、障害ゾーンの分離とコントーラ/ゲートウェイのスケールアウトによりパフォーマンスも向上します。

SDPモデルは包括的で、アーキテクチャ的に異なる点があるため、従来のアクセスメカニズムやトンネリングには依存しません。つまり、SDPに加えてVPNやファイアウォールを必要とするものがあるとすれば、パフォーマンス、セキュリティ、アジリティに制限をかけるようなものであり、今日のリモートアクセスやハイブリッドクラウドにおけるワークロードの要求を満たさない可能性があります。

通信前の認証

SDPのもう1つのユニークな要素はSingle Packet Authorization(SPA)です。これは、すべてのネットワークセッションの最初のパケットで暗号化認証を要求し、許可されたクライアントだけがネットワークにアクセスできるようにします。

もともと2007年に作成されたSPAは、最初のネットワークパケットを暗号検証することで、DDoSに対する認証メカニズムを提供します。また、許可されたデバイスのみにサービスが公開されるため、エクスプロイトに対する保護も提供します。SPAで開始されていないTCPストリームはSDPによってドロップされ、コントローラまたはゲートウェイによって処理されることはないため、DDoSの影響を軽減します。SPAは、なりすまし防止や不正なデバイスによる保護されたリソースへのアクセスの防止など、DDoS防止以外の追加のセキュリティ対策を提供します。これにより、ユーザー名とパスワードが危険にさらされた場合に、資格情報を再利用する攻撃から保護されます。

SDPはどのくらい強力ですか?

2014年2月、CSAはSoftware Defined Perimeter ハッカソンのスポンサーとして、Black HatとDEFCONにSDPセキュリティを破ろうと挑戦する人のため環境を提供しました。世界全体で100億パケットを突破しましたが、攻撃は成功せず、賞品は求められませんでした。これは、SDPアプローチの長所をよく示しています。

私たちは、CSAのSDPワーキンググループに深く参加し、SDPソリューションをまとめることを経験しているSDP分野のリーダーです。ForresterとGartnerの業界調査の専門家が、今後数年間で安全なアクセス環境を大きく変えるであろうと予測しているゼロトラスト・ジャーニーにご参加ください。

原文 “Will the real SDP please stand up?” は、こちらを参照してください。