Microsoft 365 のオンプレミス インフラストラクチャによって生み出されるリスクの軽減

Microsoft 365 のオンプレミス インフラストラクチャによって生み出されるリスクの軽減

最初の部分 このシリーズでは、オンプレミスのインフラストラクチャが Microsoft 365 のセキュリティに与えるリスクと、TEC (専門家会議) 2021 の話に基づいてこれらのリスクを軽減する方法について、マイクロソフトのプラミラ パドマナバンとマイケル エッピングからの 2 つのアドバイスを検討しました。オンプレミス攻撃からマイクロソフト 365 を保護する."私は、北米の大規模な組織と協力して、現実に何がうまくいくか、何を実装するのにもっと努力が必要なのかについて、私の視点を付け加えました。

Microsoft 365 をオンプレミスの脆弱性から保護するための最後の 3 つのガイドラインについて説明します。

ハイブリッド ユーザーが Azure アクティブ ディレクトリで管理者権限を持つことを許可しない

この推奨事項は、最初の記事の “Microsoft 365 管理者を分離する" と密接に関連していると考えています。ハイブリッド Azure AD ユーザーに Microsoft 365 テナントの管理者権限を付与しないでください。簡単に言えば、アカウントが侵害されることは決して良いことはありませんが、攻撃者がオンプレミスのアカウントを侵害する可能性がある場合、そのアカウントがクラウドで管理権限を持たない場合、その「ブラスト半径」は減少します。

これは原則的には簡単に思えますが、実際にはこの原則に違反している例が数多く見られました。いくつかの例について説明しましょう。

まず、Azure AD に同期するように構成されたオンプレミスで使用されるサービス アカウントを検出することは珍しくありません。 Azure AD 接続.このアカウントには、Microsoft 365 で管理者の役割が付与されます。

この根拠は、通常、オンプレミスアプリケーションが Microsoft 365 に対するユーザー権利を必要としていることを示しています。サービス アカウントのパスワードは、特権アクセス管理システムを通じて既に管理されていました。1つが行う場合、なぜ複数のアカウントと複数のパスワードを追跡するのですか?

もちろん、これがポイントです。この便利なディレクトリ間のアカウントの分離は、セキュリティ体制を向上させ、オンプレミスアカウントの悪用によってクラウドの脆弱性を引き起こさないためです。

別の例: ハイブリッド ユーザーと特権の分離を維持することも困難な場合があります。ライアン・ハウスクネヒト・アット・スペクターオプス 細部 管理サービス プリンシパルの “通常のアカウント" による所有権を使用して、そのアカウントに付与された特権を利用できる、興味深い攻撃パスです。

要約すると、所有者は、サービス プリンシパル (基本的にはアプリケーション固有のパスワード) の共有シークレットを作成できます。また、サービス プリンシパルは管理ポータルにログインできませんが、多くの PowerShell コマンドレットで使用できます。アカウントがサービス プリンシパルを所有している場合、そのアカウントには実質的に同じ権限がサービス プリンシパルに付与されます。

私の経験では、ハイブリッドアカウントと管理特権の間で厳密な分離を維持するには、常に警戒が必要です。これは、単一のプロセスでも、静的なポリシーのセットでもありませんが、ディレクトリ間の複雑な関係を継続的に再評価します。

Azure AD 認証ポリシーと条件付きアクセス ポリシーを使用する

Microsoft Ignite 2018 (およびおそらくそれより長い) 以来、マイクロソフトは、ハイブリッド ユーザーのパスワード ハッシュ同期を優先して、Active Directory フェデレーション サービス (ADFS) またはパススルー認証の使用から Microsoft 365 のお客様を遠ざけています。パドマナバンとエッピングは、このドラムビートを続け、正当な理由があります。

パスワード ハッシュ同期を使用する場合、Azure AD Connect はオンプレミスで設定されたパスワードを同期します。 アクティブ ディレクトリ ユーザーをハイブリッド クラウド ユーザーに対して実行します。そのハイブリッド クラウド アカウントに対する認証は、Azure AD によって処理されます。Active Directory ユーザーと同じパスワードを持ちますが、認証プロセス中に Active Directory にアクセスすることはありません。

これを ADFS またはパススルー認証とは対照的にします。技術的な実装は異なりますが、結局は両方とも直接認証のために Active Directory ドメイン コントローラを利用します。

Azure AD 認証を排他的に活用することには、多くの利点があります。ユーザーは、Active Directory の停止が発生した場合でも、クラウド アプリケーションに対して認証を行うことができます。 条件付きアクセス ポリシー 特にフェデレーション アプリケーションでは、より幅広く機能します。クラウドのみのユーザーとハイブリッド ユーザーは、同じポリシーと認証フローを使用します。

しかし、最も重要なことは、この推奨事項は、Azure AD がヴルネーラを信頼できる可能性を取り除くことだけです。認証用のオンプレミスコンポーネントを作成します。これがどのように行うのです。 ノーベリウム 攻撃が起こった。Azure AD が信頼していたオンプレミスの ADFS サーバーが侵害され、クラウド アプリケーションの信頼されたアクセス トークンを生成するために使用されました。

逸話的に、私はアドバイスのこのポイントが広く実装されているのを見ます。大規模な組織でも、ADFS やパススルーよりもパスワード ハッシュ同期を使用する方がはるかに一般的です。そして、私が一緒に働いているほとんどの組織は、少なくとも Azure AD プレミアム P1 を購入しました。この記事では、このライセンス レベルでは、条件付きアクセス ポリシーなど、すべてのユーザーに対してクラウド ネイティブ認証を使用する利点の多くが得られます。

ログの収集と分析

パドマナバンとエッピングの最後のアドバイスは、ログを収集する「ブロックとタックル」の仕事を無視しないことです。この推奨事項は明らかに思えるかもしれませんが、Microsoft 365 コンプライアンス センターでいくつかのアラートを設定して、それを良いと呼ぶだけでなく、このことを強調しています。Microsoft 365 統合監査ログで定期的に発生するイベントを確認することは非常に重要ですが、ハイブリッド ディレクトリでは、Active Directory 監査ログとエンドポイント デバイスからのログを収集することも重要です。

パドマナバンとエッピングによると、組織は必要な限り長くログを保持する必要があります。これは、ログ データを SIEM (セキュリティ情報およびイベント管理) リポジトリにエクスポートする必要があることを意味する可能性があります。実際には、ログ収集は、一緒に作業する組織間で、しばしば同時に、いくつかの異なる方法で実装されています。Microsoft Sentinel や Splunk などの製品は、ほぼすべての種類のログ データを大規模に受け入れ、ログ データを検索して分析し、必要な限りそのデータを保持できます。

しかし、このアプローチには課題があります。SIEM システムの課金は通常、消費するストレージに基づいているため、データを長期間保持するのに非常にコストがかかる可能性があります。しかし、おそらくさらに困難なのは、ログから洞察を作成するために必要な専門知識です。これらのイベントには非常に多くの異なるイベントが含まれているため、収集された監査ログ データを利用するには、多くの場合、高額なコストがかかる専用の専門知識が必要です。

また、組織が取る別のアプローチは、Quest のオンデマンド監査など、特定の監査ソース用に事前に構成されたプラットフォームに特化した製品を使用することです。このような製品を使用したインサイトへのパスは、通常、組み込みの正規化と事前構築されたクエリとビジュアライゼーションにより短くなります。また、これらの製品は一般に使用されるストレージによってライセンス供与されないので、コストはより予測可能です。

当然のことながら、これらの製品のトレードオフもあります。プラットフォームに焦点を当てた監査製品は、限られたデータ ソースセット用に設計されているので、通常はベンダーが新しいデータ ソースを追加する必要があります。また、これらの製品が Azure AD、アクティブ ディレクトリ、およびエンド ポイント デバイスを処理できるのも珍しいことです。

結論

パドマナバンとエッピングのプレゼンテーションは非常に洞察力があり、彼らのアドバイスは私が組織も向かっている場所に並んでいます。繰り返しますが、私は強くお勧めします 元のプレゼンテーションを表示する.私は、この道のすべてのステップをナビゲートするために組織と協力する人として、私の視点を通じて何らかの価値を提供できたことを願っています。




未分類

Posted by admin