ID インフラストラクチャをセキュリティ保護する 5 つのステップ

  • [アーティクル]

このドキュメントをご覧になっているお客様は、セキュリティの重要性を認識なさっていると思います。 おそらく、既に組織をセキュリティで保護する責任を負っていらっしゃるでしょう。 セキュリティの重要性を他の人に理解してもらう必要がある場合は、最新の Microsoft デジタル防御レポートを読むようご案内ください。

このドキュメントは、Microsoft Entra ID の機能を使用してセキュリティ体制を強化するのに役立ちます。その強化のために、サイバー攻撃への組織の防御を改善する 5 ステップのチェックリストを使用します。

このチェックリストは、重要な推奨アクションを迅速に展開して、組織を直ちに保護するうえで役に立ちます。ここでは、以下の方法について説明されています。

  • 資格情報を強化する
  • 攻撃の対象となる領域を減らす
  • 脅威への対応を自動化する
  • クラウド インテリジェンスを利用する
  • エンドユーザー セルフサービスを有効にする

Note

このドキュメントの推奨事項の多くは、Microsoft Entra ID を ID プロバイダーとして使用するよう構成されたアプリケーションにのみ適用されます。 シングル サインオンを使用するようアプリを構成すると、資格情報ポリシーや脅威の検出、監査、ログの記録などの機能がこれらのアプリケーションに追加されるという様々な利点があります。 「Microsoft Entra アプリケーション管理」は、これらのすべての推奨事項の基盤となります。

このドキュメントの推奨事項は、Microsoft Entra テナントの ID セキュリティ構成の自動化された評価である ID セキュリティ スコアと一致しています。 組織は Microsoft Entra 管理センターの [ID セキュリティ スコア] ページを使用して、現在のセキュリティ構成におけるギャップを探し、セキュリティに関する最新の Microsoft のベスト プラクティスに従うようにすることができます。 セキュリティ スコア ページで各推奨事項を実装するとスコアが上がり、進行状況を追跡することができ、さらに他の似た規模の組織と実装を比較するのに役立ちます。

Azure portal window showing Identity Secure Score and some recommendations.

Note

ここで推奨されている機能の一部はすべてのお客様にご利用いただけますが、Microsoft Entra ID P1 または P2 のサブスクリプションが必要なものもあります。 詳細については、「Microsoft Entra の価格」と「Microsoft Entra 展開チェックリスト」を参照してください。

作業を開始する前に、次のことを行います。MFA で特権アカウントを保護します

このチェックリストを読み始める前に、読んでいる間にセキュリティが侵害されないようにしてください。 Microsoft Entra では、1 日に 5,000 万回のパスワード攻撃が観察されていますが、多要素認証 (MFA) などの強力な認証を使用しているのは、ユーザーの 20 % と、グローバル管理者の 30% のみです。 これらの統計は、2021 年 8 月のデータに基づいています。 Microsoft Entra ID では、管理者などの特権ロールを持つユーザーが、環境の他の部分の構築と管理に対する信頼の根幹になります。 セキュリティ侵害の影響を最小限に抑えるため、次のことを実装します。

特権アカウントを制御している攻撃者は、重大な損害を受ける可能性があるため、 続行する前にこれらのアカウントを保護することが重要です。 Microsoft Entra セキュリティの既定値群または条件付きアクセスを使用して、組織内のすべての管理者に対して Microsoft Entra 多要素認証 (MFA) を有効にし、それを必須とします。 これは重要なことです。

準備はできたでしょうか。 それでは、チェックリストの確認に入りましょう。

ステップ 1: 資格情報を強化する

同意フィッシングや人間以外のIDに対する攻撃など、他のタイプの攻撃も登場していますが、ユーザーIDに対するパスワード ベースの攻撃は、依然としてID漏洩の最も一般的な方法です。 敵対者が巧妙に作るスピアー フィッシングやパスワード スプレー攻撃は、まだ多要素認証 (MFA) を実装していない組織、またはこの一般的な手口に対して他の保護手段を実装していない組織に対して成功し続けています。

組織として、ID がどこでも MFA で検証され、保護されるようにする必要があります。 2020年には、FBI IC3 で、被害の苦情が上位の犯罪類型として、フィッシングが挙げられています。 前年と比較して報告数が2倍になりました。 フィッシングは、企業と個人の双方にとって大きな脅威であり、昨年最も損害を与えた攻撃の多くでクレデンシャル フィッシングが利用されました。 Microsoft Entra 多要素認証 (MFA) を使用すると、第 2 の認証形式を使用するもう 1 つのセキュリティ層が提供されることになるので、データやアプリケーションへのアクセスを保護できます。 組織は、条件付きアクセスを使用して多要素認証を有効化し、ソリューションを組織の特定のニーズに適合させることができます。 この展開ガイドを参照して、Microsoft Entra 多要素認証を計画、実装、ロールアウトする方法を確認してください。

組織で強力な認証が使用されるようにする

基本レベルの ID セキュリティを簡単に有効にするには、Microsoft Entra セキュリティの既定値群によりワンクリックでの有効化を使用できます。 セキュリティの既定値群では、テナント内のすべてのユーザーに Microsoft Entra 多要素認証が適用され、テナント全体でレガシ プロトコルからのサインインがブロックされます。

組織が Microsoft Entra ID P1 または P2 のライセンスを持っている場合は、条件付きアクセスに関する分析情報とレポート ブックを使用して、構成と適用範囲のギャップを検出することもできます。 これらの推奨事項から、新しい条件付きアクセス テンプレートの経験を利用してポリシーを作成することで、このギャップを簡単に閉じることができます。 条件付きアクセス テンプレートは、Microsoft が推奨するベストプラクティスに沿って新しいポリシーを簡単に展開できるように設計されており、ID とデバイスを保護するための一般的なポリシーを簡単に展開できます。

攻撃されやすいパスワードを禁止して、従来の複雑さと有効期限にのルールを無効にする。

多くの組織では、従来の複雑さとパスワードの有効期限ルールを使用しています。 Microsoft の調査 および ネットワーク検査システムのガイダンス によると、これらのポリシーは推測されやすいパスワードをユーザーが選択する原因となります。 簡単に推測できるパスワードをユーザーが設定できないように、Microsoft Entra のパスワード保護 (攻撃者の最新の行動を利用して、禁止するパスワードを動的に決める機能) を使用することをお勧めします。 この機能はユーザーがクラウドで作成されるときは常に有効ですが、ハイブリッド組織も Windows Server Active Directory 用の Microsoft Entra パスワード保護を展開するときに使用できるようになっています。 また、有効期限ポリシーを削除することをお勧めします。 サイバー犯罪者はほとんどの場合、資格情報を侵害するとすぐに使用するため、パスワード変更に抑制効果はありません。 組織のパスワードの有効期限ポリシーを設定するには、次の記事を参照してください。

資格情報の漏洩から保護し、障害に対する回復力を高める

Microsoft Entra ID でオンプレミス ディレクトリ オブジェクトのクラウド認証を有効にするための最も単純で推奨される方法は、パスワード ハッシュ同期 (PHS) を有効にすることです。 組織がパススルー認証またはフェデレーションによるハイブリッド ID ソリューションを使用する場合、次の 2 つの理由から、パスワード ハッシュ同期を有効にする必要があります。

  • Microsoft Entra ID の資格情報が漏洩したユーザー レポートは、公開されているユーザー名とパスワードのペアについて警告をします。 驚くほど大量のパスワードが、後にセキュリティ侵害されるサードパーティ サイトでのパスワードの再利用、フィッシング、マルウェアによって漏洩しています。 Microsoft は、漏洩した資格情報を多数発見しており、それらがお客様の組織の資格情報に一致する場合に、このレポートでお客様に報告します。ただし、そのためには、パスワード ハッシュの同期を有効にしておくか、クラウド専用 ID を所有している必要があります。
  • ランサムウェア攻撃など、オンプレミスで障害が発生した場合、パスワード ハッシュ同期を使用するクラウド認証に切り替えることができます。このバックアップの認証方法により、ユーザーは Microsoft Entra ID による認証が構成されたアプリ (Microsoft 365 など) へのアクセスを継続できます。 この場合、IT スタッフはオンプレミスの停止が解決されるまで、シャドーITや個人のメール アカウントに頼ってデータを共有する必要はありません。

パスワードがクリア テキストで保存されたり、Microsoft Entra ID の復元可能なアルゴリズムで暗号化されたりすることはありません。 パスワードハッシュ同期の実際のプロセスの詳細については、「 パスワードハッシュ同期のしくみの詳細な説明」を参照してください。

AD FS エクストラネットのスマート ロックアウトを実装する

スマート ロックアウトは、組織のユーザーのパスワードを推測したり、ブルート フォース方法を使用して侵入しようとする悪意のあるユーザーのロックアウトを支援します。 スマート ロックアウトは、有効なユーザーからのサインインを認識し、攻撃者や他の不明なソースからのユーザーとは異なる方法で処理できます。 攻撃者はロックアウトされる一方、組織のユーザーは自分のアカウントへのアクセスを継続できるため、生産性を落とすことはありません。 Microsoft Entra ID で直接認証されるようアプリケーションを構成している組織は、Microsoft Entra スマート ロックアウトを利用できます。 AD FS 2016 と AD FS 2019 を使用したフェデレーション デプロイでは、AD FS エクストラネット ロックアウトとエクストラネット スマート ロックアウトを使用して同様の効果を実現できます。

ステップ 2: 攻撃の対象となる領域を減らす

漏洩したパスワードが広まりやすいことを考えると、組織において攻撃の対象となる領域を最小化することが重要です。 安全性が低い旧式のプロトコルの使用を無効にし、アクセス エントリ ポイントを制限し、クラウド認証に移行し、リソースへの管理アクセスをより細かく制御し、ゼロの信頼セキュリティの原則を採用します。

クラウド認証を使用する

資格情報は、主要な攻撃ベクトルです。 このブログの実習では、クラウド認証を使用し、MFA をデプロイし、パスワードレス認証方法を使用することで、攻撃対象領域を減らせます。 Windows Hello for Business、Microsoft Authenticator アプリまたは FIDO を使用する電話サインインなど、パスワードレスのメソッドをデプロイできます。

レガシ認証をブロックする

Microsoft Entra ID による認証と会社データへのアクセスに、独自の古い方法がアプリで使用されている場合、組織には別のリスクが生じます。 レガシ認証が使用されているアプリは、POP3 クライアント、IMAP4 クライアント、SMTP クライアントなどです。 レガシ認証アプリはユーザーの代わりに認証を行うので、Microsoft Entra ID による高度なセキュリティ評価の実行が妨げられます。 代わりとなる最新の認証では、多要素認証と条件付きアクセスがサポートされているので、セキュリティ リスクを抑えられます。

次の方法が推奨されます。

  1. Microsoft Entra サインイン ログと Log Analytics ブックを使用して、組織内のレガシ認証を検出します。
  2. 最新の認証を使用するよう SharePoint Online と Exchange Online を設定する。
  3. Microsoft Entra ID P1 または P2 のライセンスがある場合は、条件付きアクセスポリシーを使用してレガシ認証をブロックします。 Microsoft Entra ID Free レベルの場合は、Microsoft Entra セキュリティの既定値群を使用します。
  4. AD FS を使用している場合はレガシ認証をブロックする。
  5. Exchange Server 2019 でのレガシ認証をブロックします。
  6. Exchange Online でのレガシ認証を無効にします。

詳細については、「Microsoft Entra ID でレガシ認証プロトコルをブロックする」を参照してください。

無効な認証エントリ ポイントをブロックする

明示的な検証の原則を使用すると、侵害されたユーザーの資格情報が発生した場合の影響を軽減する必要があります。 環境内のアプリごとに有効なユース ケースを検討して、どのグループ、ネットワーク、デバイスなどの要素が承認されるかを判断し、残りをブロックします。 Microsoft Entra の条件付きアクセスでは、定義した特定の条件に基づいて、承認されたユーザーがどのようにアプリとリソースにアクセスするかを制御できます。

クラウド アプリとユーザー アクションに条件付きアクセスを使用する方法の詳細については、「条件付きアクセス クラウド アプリ、アクション、および認証コンテキスト」を参照してください。

管理者ロールの確認と管理

もう1つのゼロの信頼関係は、セキュリティが侵害されたアカウントが特権ロールで動作する可能性を最小限に抑える必要があることです。 この制御は、ID に最小限の特権を割り当てることによって実現できます。 Microsoft Entra ロールを初めて使用する場合は、この記事を参照すると Microsoft Entra ロールを理解するのに役立ちます。

Microsoft Entra ID の特権ロールは、オンプレミスの環境から分離するためにクラウドのみのアカウントにする必要があります。また、資格情報を格納するためにオンプレミスのパスワード保管庫を使用しないでください。

特権アクセス管理を実装する

Privileged Identity Management (PIM) によって、時間ベースおよび承認ベースのロールのアクティブ化が提供され、重要なリソースに対する過剰、不要、または誤用であるアクセス許可のリスクが軽減されます。 これらのリソースには、Microsoft Entra ID、Azure、および Microsoft 365 や Microsoft Intune などのその他の Microsoft Online Services 内のリソースが含まれます。

Microsoft Entra Privileged Identity Management (PIM) は、以下をサポートしており、アカウントの特権を最小限に抑えるのに役立ちます。

  • 管理者ロールに割り当てられたユーザーを特定して管理する。
  • 削除すべき未使用の特権ロールまたは余計な特権ロールを把握する。
  • 多要素認証によって特権ロールが保護されるようルールを確立する。
  • 特権タスクを完了するのに十分な期間のみ特権ロールが付与されるようルールを確立する。

Microsoft Entra PIM を有効にして管理者ロールが割り当てられたユーザーを表示し、それらのロールの不必要なアカウントを削除します。 残りの特権ユーザーを永続から候補に変更します。 最後に、適切な変更制御により、これらの特権ロールにアクセスできる必要がある場合に安全にアクセスできるよう、適切なポリシーを確立します。

Microsoft Entra の組み込みロールとカスタム ロールは、Azure リソースのロールベースのアクセス制御システム (Azure ロール) と同様の概念で動作します。 [この 2 つのロールベースのアクセス制御システムの違い](../../role-based-access-control/rbac-and-directory-admin-roles.md)は次のとおりです。

  • Microsoft Entra ロールでは、Microsoft Graph API を使用して、ユーザー、グループ、アプリケーションなどの Microsoft Entra リソースへのアクセスを制御します
  • Azure ロールでは、Azure Resource Management を使用して、仮想マシンやストレージなどの Azure リソースへのアクセスを制御します

どちらのシステムにも、同様に使用されるロールの定義とロールの割り当ての概念が含まれています。 ただし、Microsoft Entra ロールのアクセス許可を Azure カスタム ロールで使用することはできません。その逆も同様です。 特権アカウントのプロセスを展開する一環として、自分自身をロックアウトしてしまった場合でも Microsoft Entra ID にアクセスできるよう、少なくとも 2 つの緊急アカウントを作成するベスト プラクティスに従ってください。

詳細については、「Privileged Identity Management のデプロイを計画する」および「特権アクセスのセキュリティ保護」を参照してください。

さまざまな Microsoft Entra アプリケーションの同意エクスペリエンス、アクセス許可と同意の種類、それらが組織のセキュリティ方針に与える意味を理解することが重要です。 ユーザーが自分で同意することを許可すると、Microsoft 365、Azure、その他のサービスと統合する便利なアプリケーションを簡単に入手できますが、慎重に使用し、監視しないとリスクが発生する可能性があります。

Microsoft では、エンドユーザーの同意を制限して、検証された発行元からのアプリに対してのみユーザーに同意を許可すること、および選択したアクセス許可のみを許可することをお勧めします。 エンド ユーザーの同意を無効にした場合でも、以前の同意の許可は有効ですが、それより後のすべての同意操作は管理者が実行する必要があります。 制限された場合、ユーザーは、統合された管理者の同意要求ワークフローまたは独自のサポート プロセスを通して管理者の同意を要求できます。 エンドユーザーの同意を制限する前に、推奨事項を使用して、組織におけるこの変更を計画してください。 すべてのユーザーにアクセスを許可するアプリケーションについては、すべてのユーザーの代わりに同意を与え、個人としてまだ同意していないユーザーがアプリにアクセスできるようにすることを検討してください。 シナリオによってはアプリケーションを利用できるユーザーを限定する場合、アプリケーション割り当てと条件付きアクセスを利用し、特定のアプリへのユーザー アクセスを制限してください。

ユーザーの抵抗を減らし、サポート量を最小限に抑えるため、また、ユーザーが Microsoft Entra 以外の資格情報でアプリケーションに新規登録することを防ぐため、ユーザーが新しいアプリケーションに関する管理者承認を要求できるようにしてください。 同意操作を規制したら、管理者はアプリを監視し、定期的にアクセス許可に同意します。

詳細については、記事「Microsoft Entra 同意フレームワーク」を参照してください。

ステップ 3: 脅威への対応を自動化する

Microsoft Entra ID には、検出と対応に時間差が生じないよう、攻撃を自動的に遮断する多数の機能が備わっています。 犯罪者が環境に侵入するために使える時間を減らせれば、コストとリスクを抑えることができます。 実行できる具体的な手順は以下のとおりです。

詳細については、記事「方法: リスク ポリシーを構成して有効にする」を参照してください。

サインイン リスク ポリシーを実装する

サインイン リスクは、特定の認証要求が ID 所有者によって承認されていない可能性があることを表します。 サインイン リスクベースのポリシーは、特定のユーザーまたはグループに対するリスク レベルを評価する条件付きアクセス ポリシーにサインインリスク条件を追加することによって実装できます。 リスク レベル (高/中/低) に基づいて、アクセスをブロックしたり、多要素認証を適用したりするよう、ポリシーを構成できます。 リスクが中以上のサインインには多要素認証を適用することをお勧めします。

Conditional Access policy requiring MFA for medium and high risk sign-ins.

ユーザーのリスク セキュリティ ポリシーを実装する

ユーザー リスクは、ユーザーの ID がセキュリティ侵害された確率を示すもので、ユーザーの ID に関連付けられているユーザー リスク検出に基づいて計算されます。 ユーザーリスクベースのポリシーは、リスクレベルを特定のユーザーに評価する条件付きアクセスポリシーにユーザーリスク条件を追加することによって実装できます。 低、中、高のリスクレベルに基づいて、アクセスをブロックしたり、多要素認証を使用する安全なパスワード変更を要求したりするよう、ポリシーを構成できます。 Microsoft は、リスクの高いユーザーについて、安全なパスワードへの変更を要求することをお勧めします。

Conditional Access policy requiring password change for high risk users.

ユーザーのリスク検出に含まれるのは、ユーザーの資格情報がサイバー犯罪者によって漏洩した資格情報と一致するかどうかを確認することです。 最適に機能させるには、パスワード ハッシュ同期を Microsoft Entra Connect 同期と共に実装することが重要です。

Microsoft Defender XDR を Microsoft Entra ID Protection と統合する

ID 保護で、可能な限り高いリスク検出を実行できるようにするには、可能な限り多くのシグナルを取得する必要があります。 したがって、Microsoft Defender XDR サービスの完全なスイートを統合することが重要です。

  • Microsoft Defender for Endpoint
  • Microsoft Defender for Office 365
  • Microsoft Defender for Identity
  • Microsoft Defender for Cloud Apps

次の短いビデオでは、Microsoft Threat Protection と異なるドメインを統合することの重要性について詳しく説明します。

監視とアラートの設定

疑わしい動作を検出するには、ログの監視と監査が重要です。 Azure portal には、Microsoft Entra ログを Microsoft Sentinel、Azure Monitor、その他の SIEM ツールなどの他のツールと統合するための方法がいくつかあります。 詳細については、「Microsoft Entra セキュリティ オペレーション ガイド」を参照してください。

ステップ 4: クラウド インテリジェンスを利用する

セキュリティ関連イベントの監査とログ、および関連する警告は、効率的な保護戦略に欠かせない構成要素です。 セキュリティのログやレポートは、疑わしいアクティビティの電子記録となり、外部からネットワークへの侵入または内部からの攻撃が試みられたこと、または成功したことを示すパターンを検出するために役立ちます。 監査機能を使うと、ユーザー アクティビティの監視、規制へのコンプライアンスの文書化、フォレンジック分析の実行などが可能になります。 警告によってセキュリティ イベントが通知されます。 Azure Monitor または SIEM ツールにエクスポートして、Microsoft Entra ID のサインイン ログと監査ログの両方に対してログ保持ポリシーが設定されていることを確認します。

Microsoft Entra ID を監視する

Microsoft Azure のサービスや機能が提供する構成可能なセキュリティ監査およびログのオプションは、セキュリティ ポリシーやセキュリティ メカニズムのギャップを識別してセキュリティ侵害を防止するための対策を講じるうえで役立ちます。 Azure のログと監査を使用できるほか、Microsoft Entra 管理センターの監査アクティビティ レポートを使用できます。 ユーザー アカウント、特権アカウント、アプリ、デバイスの監視の詳細については、「Microsoft Entra セキュリティ オペレーション ガイド」を参照してください。

ハイブリッド環境で Microsoft Entra Connect Health を監視する

Microsoft Entra Connect Health を使用して AD FS を監視すると、潜在的な問題に関するより優れた分析情報と、AD FS インフラストラクチャへの攻撃の可視性が得られます。 ADFS のサインインを表示して、監視の詳細を確認できるようになりました。 Microsoft Entra Connect Health では、詳細、解決手順、関連ドキュメントへのリンクが含まれた警告のほか、認証トラフィックに関するいくつかのメトリックの利用状況分析、パフォーマンスの監視、レポートが提供されます。 お使いの環境の基準を特定し、変更があった場合にアラートを通知するために役立つ、 ADFS の危険な IP ブック を利用します。 すべてのハイブリッド インフラストラクチャは、階層0の資産として監視する必要があります。 これらの資産の詳細な監視ガイダンスについては、「 インフラストラクチャのセキュリティ運用ガイド」を参照してください。

Monitor Microsoft Entra ID の保護イベントを監視する

Microsoft Entra ID Identity Protection で提供される 2 つの重要なレポートを、毎日監視する必要があります。

  1. リスクの高いサインイン レポートでは、調査する必要があるユーザー サインイン アクティビティが明らかになります。正当な所有者がサインインを実行していない可能性があります。
  2. リスクの高いユーザー レポートでは、侵害された可能性があるユーザー アカウントが明らかになります。たとえば、リークが検出された資格情報や、あり得ない移動イベントが発生する別の場所からサインインしたユーザーなどです。

Overview charts of activity in Identity Protection in the Azure portal.

監査アプリと同意されたアクセス許可

だまされたユーザーが侵害された Web サイトやアプリに移動することで、それらがユーザーのプロファイル情報やメールなどのユーザー データにアクセスできるようになる可能性があります。 悪意のあるアクターは、受け取った同意されたアクセス許可を使用して、メールボックスの内容を暗号化し、メールボックス データを回復するための身代金を要求できます。 ユーザーによって付与されたアクセスを許可を管理者は確認および監査する必要があります。 ユーザーによって付与されたアクセス許可を監査するだけでなく、プレミアム環境で危険または望ましくない OAuth アプリケーションを検索する こともできます。

ステップ 5: エンドユーザー セルフサービスを有効にする

できるだけセキュリティと生産性のバランスをとる必要があります。 セキュリティの基盤を構築するという考え方でアプローチし、警戒を緩めないままユーザーに権限を与えることで、組織の手間を省くことができます。

セルフサービス パスワード リセットを実装する

Microsoft Entra ID の セルフサービス パスワード リセット (SSPR) では、IT 管理者は簡単に、ユーザーがヘルプ デスクや管理者の手を借りずにパスワードやアカウントのリセットまたはロック解除を行えるようにできます。 このシステムには、ユーザーがいつパスワードをリセットしたかを追跡する詳細なレポートと、誤用または悪用について警告する通知が用意されています。

セルフサービス グループとアプリケーションのアクセスを実装する

Microsoft Entra ID を使用すると、セキュリティ グループ、Microsoft 365 グループ、アプリケーション ロール、アクセス パッケージ カタログを使用して、管理者以外のユーザーがリソースへのアクセスを管理できます。 セルフサービス グループ管理を使用すると、グループ所有者は、管理者ロールを割り当てられることなく、自分のグループを管理できます。 ユーザーは、自身の依頼の処理に管理者に頼らずに Microsoft 365 グループを作成および管理することもでき、未使用のグループも自動的に期限切れになります。 Microsoft Entra エンタイトルメント管理を使用すると、包括的なアクセス要求ワークフローと自動有効期限を使用して委任と可視化をさらに高めることができます。 管理者以外のユーザーが所有するグループ、Teams、アプリケーション、および SharePoint Online サイト用に独自のアクセス パッケージを構成する機能を、それらのユーザーに委任することができます。これには、従業員のマネージャーやビジネス パートナー スポンサーの承認者としての構成など、アクセスを承認する必要があるユーザー用のカスタム ポリシーを使用します。

Microsoft Entra アクセス レビューを実装する

Microsoft Entra アクセス レビューでは、アクセス パッケージとグループ メンバーシップ、エンタープライズ アプリケーションへのアクセス、特権ロールの割り当てを管理して、セキュリティ標準を確実に維持できます。 ユーザー自身、リソース所有者、その他のレビュー担当者による通常の監視によって、ユーザーが必要なくなったアクセスを長期間にわたって保持しないですみます。

自動ユーザー プロビジョニングを実装する

プロビジョニングとプロビジョニング解除は、複数のシステム間でデジタル ID の一貫性を確保するプロセスです。 一般に、これらのプロセスは ID ライフサイクル管理の一環として適用されます。

プロビジョニングは、特定の条件に基づいて、対象のシステムに ID を作成するプロセスです。 プロビジョニング解除は、条件を満たさなくなった ID を対象のシステムから削除するプロセスです。 同期は、ソース オブジェクトとターゲット オブジェクトがほぼ一致するように、プロビジョニングされたオブジェクトを最新の状態に維持するプロセスです。

プロビジョニングの自動化に関して、Microsoft Entra ID には現在 3 つの領域が用意されています。 以下のとおりです:

詳細については、「Microsoft Entra ID でのプロビジョニングの概要」を参照してださい。

まとめ

ID インフラストラクチャのセキュリティについては多数の側面があります。しかし、この 5 ステップのチェックリストを利用すれば、セキュリティで保護されたより安全な ID インフラストラクチャをすばやく実現できます。

  • 資格情報を強化する
  • 攻撃の対象となる領域を減らす
  • 脅威への対応を自動化する
  • クラウド インテリジェンスを利用する
  • エンドユーザー セルフサービスを有効にする

Microsoft は、お客様がセキュリティの重要性を認識していることを理解しています。ぜひ、このドキュメントを、組織のセキュリティ体制を強化するためのロードマップとしてお役立てください。

次のステップ

推奨事項の計画と展開にサポートが必要な場合は、「Microsoft Entra ID プロジェクト展開プラン」をヘルプとして参照してください。

これらの手順を完全に修了したら、Microsoft の ID セキュリティ スコアを使用します。これにより、最新のベスト プラクティスとセキュリティ上の脅威について常に把握し続けることができます。