テナント構成の設計
Microsoft Entra IDでの構成は、各テナント内で行われます。 構成設定は、セキュリティ ポリシーとアクセス ポリシーを制御します。 セキュリティポリシーとアクセス ポリシーを文書化して、必要に応じてテナント間の一貫性を確保します。
テナント間の構成の整合性
中央管理チームがある大規模な EDU 環境では、ほとんどの構成がテナント間で一貫していることを確認します。
管理を簡素化し、中央 IT チームの効率を高めます。
問題の特定とトラブルシューティングを容易にします。
テナント間でのソフトウェアの開発、テスト、デプロイを容易にします。
テナント間のユーザー エクスペリエンスをより一貫性があり直感的なものにします。
あるテナントから別のテナントにユーザーを移行するプロセスを簡単にします。
テナント構成を中央の IT チームによって標準管理し、テナント固有の IT チームによって調整できるポリシーを作成します。 テナント固有の管理チームが柔軟性を持つ必要がある領域には、次のようなものがあります。
外部パートナーがテナントにアクセスできるようにする。 organizationには、他のテナントへのアクセスのみを許可するポリシーがある場合があります。特定のリージョンには、Microsoft Entra B2B コラボレーション許可リストへのリージョン固有のベンダーが必要な場合があります。
必要なアクセス ポリシーを調整する (たとえば、マネージド デバイスがテナントまたはリージョン固有のセキュリティ要件を満たすか、マネージド デバイスの可用性を考慮する必要があります)。
新しい機能 (たとえば、学校のディレクターがその学校のスタッフの特定の IT タスクをカバーできるように My Staff を試している地域) をパイロットします。
外部 ID を構成する
外部 ID は、EDU organization内の他のテナントからのユーザーなど、Microsoft Entra テナントの外部からのユーザーを表します。 複数のテナントにまたがる大規模な EDU organizationでは、Microsoft Entra企業間 (B2B) コラボレーションを使用して、それらのテナント間でアクセスを提供できます。 Microsoft Entra B2B を使用すると、organizationのアプリケーションとサービスを別のorganizationのゲストと安全に共有しながら、独自のデータを制御できます。
外部コラボレーションを制御する
外部コラボレーション設定を使用すると、organization内のさまざまな種類のユーザーに対してゲストの招待をオンまたはオフにすることができます。 ゲストの招待を許可するロールを割り当てることで、個々のユーザーに招待を委任することもできます。 外部コラボレーション設定は、Microsoft Entra IDの下のMicrosoft Entra 管理センターで管理されます。
ゲストをグローバル アドレス一覧に表示できるようにする
グローバル アドレス一覧 (GAL) には、次のいずれかの方法でゲスト (外部ユーザー) を表示できます。
Microsoft Entra B2B を使用してユーザーをゲストとして招待する (推奨)
GAL 同期の使用 (推奨されません)
注:
GAL 同期では、ユーザー アカウントは作成されません。 むしろ、作成される各連絡先は、テナント内のオブジェクト制限に対してカウントされるオブジェクトです。
セキュリティ ポリシーとアクセス ポリシー
ID 関連の攻撃が非常に普及している場合、セキュリティの管理は困難になる可能性があります。 セキュリティの既定値とアクセス ポリシーにより、パスワード スプレー、再生、フィッシングなどの攻撃からorganizationを保護しやすくなります。
セキュリティの既定値
セキュリティの既定値では、お客様自身の ID セキュリティ ストーリーを管理する準備ができるまで、お客様のorganizationに代わって管理するセキュリティで保護された設定が提供されます。 セキュリティの既定値が有効になっている場合は、次の事前構成済みのポリシー設定でorganizationを保護するのに役立ちます。
すべてのユーザーに Azure Multi-Factor Authentication への登録を要求する
管理者に多要素認証の実行を要求する
レガシ認証プロトコルのブロック
ユーザーが必要に応じて多要素認証を実行することを要求する
Azure portalへのアクセスなどの特権アクティビティの保護
セキュリティの既定値を有効にすることをお勧めします。organizationでセキュリティ体制を強化する必要があり、堅牢なセキュリティを構成していない場合です。 Microsoft Entra ID P1 または P2 ライセンスを持つorganizationであり、現在条件付きアクセス ポリシーを使用して組織のポリシーを適用している場合、セキュリティの既定値はおそらく適切ではありません。
次の図に示すように、Azure portalでセキュリティの既定値を有効にします。
IT およびスタッフ向けのマネージド デバイス
テナント内のリソースを保護するには、保護レベルが不明なデバイスによるアクセスを禁止します。 ユーザーがorganizationによって管理されているデバイスを使用してのみリソースにアクセスできるように、デバイス管理ソリューションを実装します。
Microsoft Entra IDでは、管理対象と見なされるデバイスの最小要件は、Microsoft Entra IDに登録されている場合です。 管理者は、Microsoft Entra IDで次の種類のデバイス管理を実装することを選択できます。
ハイブリッド ドメイン参加済み。 organizationが所有し、オンプレミスの Active DirectoryとMicrosoft Entra IDの両方に参加しているデバイス。 通常、デバイスはorganizationによって購入および管理され、System Center Configuration Managerによって管理されます。
Microsoft Entraドメイン参加済み。 organizationによって所有され、organizationのMicrosoft Entra テナントに参加しているデバイス。 通常、デバイスは、organizationによって購入および管理され、Microsoft Entra IDに参加し、Microsoft Intuneなどのサービスによって管理されます。
Microsoft Entra登録されています。 会社のリソースにアクセスするために使用される、organizationまたは個人用デバイスが所有するデバイス。 通常、会社のリソースにアクセスするために使用される個人用デバイス。 組織は、デバイスを Mobile デバイス管理 (MDM) 経由で登録するか、登録なしで Mobile Application Management (MAM) を通じて適用してリソースにアクセスすることを要求する場合があります。 この機能は、Microsoft Intuneなどのサービスによって提供できます。
詳細については、「 統合方法を選択する」を参照してください。
セキュリティをさらに強化するために、IT およびスタッフ向けにMicrosoft Entra条件付きアクセス ポリシーを作成することもお勧めします。 条件付きアクセスでは、アクセスを許可する 1 つのポリシーを作成できます。
選択したクラウド アプリに。
選択したユーザーとグループの場合。
マネージド デバイスを要求する。
管理者に MFA を使用する
昇格されたアクセス許可が割り当てられたアカウントは、攻撃者にとって重要なターゲットです。 特権アカウントの侵害のリスクを最小限に抑えるには、 Azure Multi-Factor Authentication (MFA) などの強力な認証資格情報を使用して、昇格されたアクセス許可を持つすべてのアカウントをプロビジョニングします。
少なくとも、次の管理ロールに MFA を要求する条件付きアクセス ポリシーを作成 することをお勧めします。
課金管理者
条件付きアクセス管理者
Exchange 管理者
グローバル管理者
ヘルプデスク (パスワード) 管理者
セキュリティ管理者
SharePoint 管理者
ユーザー管理者
ユーザーが利用できる多要素認証方法がある場合は、学生レコードなどの機密情報にアクセスできるユーザーに対して MFA を適用します。
リスク ポリシー
Microsoft Entra IDを使用すると、管理者は特定の種類のリスクから保護するポリシーを作成できます。
サインイン リスク。 特定の認証要求が ID 所有者によって承認されていない確率。
ユーザー リスク。 ギブ ID またはアカウントが侵害される確率。
サインイン リスク ポリシーとユーザー リスク ポリシーは、環境内のリスク検出への対応を自動化し、ユーザーがリスクを自己修復できるようにします。
Microsoft 365 A5 ライセンス (または P2 ライセンスMicrosoft Entra ID) を持つ教育機関は、Microsoft Entra ID 保護を使用してアカウントをセキュリティで保護できます。 サインイン リスクベースの条件付きアクセス ポリシーとユーザー リスクベースの条件付きアクセス ポリシーを作成することもできます。
リスクの 高いユーザー がサインイン後にパスワードを変更する必要がある場合は、ユーザー リスク ポリシーを構成します。
ベスト プラクティス
条件付きアクセス ポリシーを定義して、ID セキュリティ体制を適用し、サインイン リスクとユーザー リスクを最小限に抑えます。 これには、マネージド デバイスと予期される場所を介してのみアクセスを有効にする MFA コントロールとデバイス ベースのコントロールが含まれている必要があります。
すべてのアプリケーションに明示的な条件付きアクセス ポリシーが適用されている必要があります。
同じ要件を持つ複数のアプリに適用することで、条件付きアクセス ポリシーの数を最小限に抑えます。
緊急 アクセス アカウント を設定して中断を計画し、偶発的なロックアウトの影響を軽減します。
レポート専用モードで条件付きアクセス ポリシーを構成します。
個々の環境の条件付きアクセス ポリシーに関する一般的なガイダンスについては、「CA のベスト プラクティスとMicrosoft Entra運用ガイド」をチェックします。
アプリの登録
アプリケーション ギャラリーへのアプリケーションの追加や、アプリケーション プロキシを使用するようにアプリケーションを構成するなどのタスクを実行できるのは、管理者特権のアクセス許可を持つユーザーのみです。 ただし、既定では、ディレクトリ内のすべてのユーザーがアプリケーション およびサービス プリンシパル オブジェクトを登録できます。 また、ユーザーの同意を通じてorganizationデータにアクセスできるアプリケーションを決定することもできます。
特権のないアカウントがテナントにアプリケーション およびサービス プリンシパル オブジェクトを作成できないように、 ユーザーの同意を無効 にすることをお勧めします。 代わりに 、アプリケーション管理者、アプリケーション開発者、クラウド アプリケーション管理者ロールなどのチーム メンバーアプリケーション管理ロールを委任 します。 ロールを使用すると、organizationのセキュリティチームと ID チームとの同意に関する意思決定プロセスが一元化されます。
アプリ統合
可能であれば、Microsoft Entra アプリケーション ギャラリーを使用してサポートされている SaaS アプリケーションを統合します。このギャラリーでは、Microsoft Entra IDで動作する事前構成済みのアプリを見つけることができます。 アプリケーションが Microsoft Entra アプリケーション ギャラリーで使用できない場合は、一覧にないアプリケーションをMicrosoft Entra 管理センターに追加できます。
ハイブリッド環境では、Microsoft Entra アプリケーション プロキシを使用して、レガシ アプリケーションへのセキュリティで保護されたリモート アクセスを有効にすることができます。 アプリケーション プロキシを使用すると、ユーザーは自分のMicrosoft Entra アカウントを使用して、VPN なしでオンプレミスの Web アプリにアクセスできます。
または、次のいずれかのサード パーティ製アプリケーション配信またはネットワーク ソリューションを現在使用している場合は、レガシ アプリへのアクセスをセキュリティで保護することもできます。
テナント のセキュリティを設計する
上記の推奨事項に加えて、Microsoft Entra 管理センターで次の設定を構成して、テナントをさらにロックダウンすることもお勧めします。
ユーザー設定
| 設定 | 値 | 理由 |
|---|---|---|
| 管理ポータル | ||
| 管理ポータルへのアクセスMicrosoft Entra制限する | はい | この設定により、特権のないアカウントがAzure portalの [Microsoft Entra ID] セクションにアクセスできなくなります。 |
| LinkedIn アカウント接続 | 不要 | ビジネス上の必要性なし |
| アプリの登録 | ||
| ユーザーはアプリケーションを登録できます | 不要 | 教育機関向け Microsoft では、特権のないアカウントを禁止して、テナントにアプリケーション とサービス プリンシパル オブジェクトを作成することをお勧めします。 代わりに、アプリケーション管理者、アプリケーション開発者、クラウド アプリケーション管理者ロールなどのアプリケーション管理ロールにチーム メンバーを明示的に割り当てます。 |
外部 ID の設定
| 設定 | 値 | 理由 | |
|---|---|---|---|
| 同じorganizationからのテナントのみを許可する | |||
| ゲストのアクセス許可が制限されています | 不要 | ゲストは、よく知られているテナントから来ます。 | |
| 管理者と、ゲストの招待元ロールのユーザーが招待できる | はい | ゲスト招待は、招待が指定されたドメインにのみ許可されている場合に委任できます。 | |
| メンバーは招待できます。ゲストは招待できます | 不要 | ゲスト招待者ロールを持つ特定の管理者または管理者/ユーザーのみがゲストを招待できるようにすることで、テナントに招待されるユーザーをより詳細に制御できます。 | |
| ゲストの電子メール ワンタイム パスコードを有効にする (プレビュー) | いいえ | ゲストは、よく知られているテナントから来ます。 | |
| ユーザー フローを使用してゲスト セルフサービス サインアップを有効にする (プレビュー) | いいえ | 招待は指定されたドメインにのみ許可され、ユーザー アカウントは他のテナントのアカウントMicrosoft Entraされます。 | |
| コラボレーションの制限 – 指定したドメインへの招待のみを許可する | 最も制限の厳しい | Microsoft では、B2B コラボレーション機能を使用してテナント間のアクセスを提供する複数のテナントを持つ大規模な組織に対して、この設定をお勧めします。 コラボレーション設定を [指定したドメインへの招待のみを許可する (最も制限が厳しい)] に設定すると、organizationの一部であるすべてのドメインが許可リストに含まれます。これにより、他のドメインへの招待が自動的に拒否されます。 または、学校が他の組織とパートナーシップを結ぶ場合は、許可リストに追加することで、それらの組織のみに招待を制限できます。 |
|
| 独自のorganizationの外部でのコラボレーションを許可する | |||
| ゲストのアクセス許可が制限されています | はい | ゲストは、独自のorganizationの外部から取得できます。この設定では、ユーザー、グループ、またはその他のディレクトリ オブジェクトの列挙などの特定のディレクトリ タスクから制限されます。 | |
| 管理者と、ゲストの招待元ロールのユーザーが招待できる | 不要 | 任意のドメインへの招待の送信を許可するようにコラボレーション制限が設定されている場合は、委任された管理者のグループで招待を制御しておくことをお勧めします。 | |
| メンバーは招待できます。ゲストは招待できます | いいえ | ゲスト招待者ロールを持つ特定の管理者または管理者/ユーザーのみがゲストを招待できるようにすることで、テナントに招待されるユーザーをより詳細に制御できます。 | |
| ゲストの電子メール ワンタイム パスコードを有効にする (プレビュー) | はい | OTP は、ユーザーを自分のorganizationの外部から招待する場合に推奨されます。 | |
| ユーザー フローを使用してゲスト セルフサービス サインを有効にする (プレビュー) | 不要 | ゲストがセルフサービスでテナントにサインアップできるようにすることよりも、招待を制御することをお勧めします。 | |
| コラボレーションの制限 – 任意のドメインへの招待の送信を許可する | 最も包括的 | パートナー、外部コンサルタント、その他の教育機関などと共同作業する場合など、他の複数のテナントと共同作業する必要がある場合に推奨される設定。 |
ユーザー機能のプレビュー設定
| 設定 | 値 | 理由 |
|---|---|---|
| ユーザーはプレビュー機能を使用してマイ アプリ | None/Selected/All | 設定は、ポータルとその機能の使用と必要性マイ アプリ応じて異なります。 マイ アプリ ポータルを使用して、organizationのクラウドベースアプリへのアクセスをスタッフまたは学生を含むすべてのユーザーに提供することを検討できます。 |
| ユーザーは、統合されたセキュリティ情報登録エクスペリエンスを使用できます | すべて | セキュリティ情報の登録をセキュリティで保護するために、パスワードレス資格情報や条件付きアクセスなどの強化された認証方法を使用することをお勧めします。 |
| 管理者はマイ スタッフにアクセスできます | None/Selected/All | 設定は、使用と個人用スタッフの必要性によって異なります。 個人用スタッフを使用して、一般的なヘルプデスク タスクをスタッフに委任することを検討できます。 マイ スタッフを使用すると、学校のディレクターなどの権限を委任して、スタッフメンバーが自分のMicrosoft Entra アカウントに確実にアクセスできるようにする権限を委任できます。 中央のヘルプデスクに依存する代わりに、組織は、パスワードのリセットや電話番号の変更などの一般的なタスク (学校のディレクターなど) を委任できます。 マイ スタッフを使用すると、自分のアカウントにアクセスできないユーザーは、ヘルプデスクや IT スタッフが不要な選択だけでアクセスを回復できます。 |
グループ管理の設定
| 設定 | 値 | 理由 | |
|---|---|---|---|
| セルフサービスによるグループの管理 | |||
| 所有者は、アクセス パネルでグループ メンバーシップ要求を管理できます | 不要 | EDU テナント内のグループには、構造化および管理する必要がある機密性の高いリソース アクセス (学生情報へのアクセスなど) が含まれる場合があります。 これらのシナリオでは、ユーザーが開始する管理は推奨されません | |
| アクセス パネルのグループ機能にアクセスするユーザー機能を制限します。 管理者 (グローバル、グループ、ユーザー 管理) は、この設定の値に関係なくアクセスできます | はい | EDU テナント内のグループには、構造化および管理する必要がある機密性の高いリソース アクセス (学生情報へのアクセスなど) が含まれる場合があります。 これらのシナリオでは、ユーザーが開始する管理は推奨されません | |
| セキュリティ グループ | |||
| ユーザーは Azure portal でセキュリティ グループを作成できます | 不要 | EDU テナント内のグループには、構造化および管理する必要がある機密性の高いリソース アクセス (学生情報へのアクセスなど) が含まれる場合があります。 これらのシナリオでは、ユーザーが開始する管理は推奨されません | |
| Azure portal でグループ所有者としてメンバーを割り当てることができる所有者 | なし | EDU テナント内のグループには、構造化および管理する必要がある機密性の高いリソース アクセス (学生情報へのアクセスなど) が含まれる場合があります。 これらのシナリオでは、ユーザーが開始する管理は推奨されません | |
| Office 365 グループ | |||
| ユーザーは Azure portal でOffice 365 グループを作成できます | 不要 | EDU テナント内のグループには、構造化および管理する必要がある機密性の高いリソース アクセス (学生情報へのアクセスなど) が含まれる場合があります。 これらのシナリオでは、ユーザーが開始する管理は推奨されません | |
| Azure portal でグループ所有者としてメンバーを割り当てることができる所有者 | なし | EDU テナント内のグループには、構造化および管理する必要がある機密性の高いリソース アクセス (学生情報へのアクセスなど) が含まれる場合があります。 これらのシナリオでは、ユーザーが開始する管理は推奨されません |
エンタープライズ アプリケーションの設定
| 設定 | 値 | 理由 | |
|---|---|---|---|
| エンタープライズ アプリケーション | |||
| ユーザーは、自分の代わりに会社のデータにアクセスするアプリに同意できます | 不要 | 同意を必要とするアプリケーションは、同意要求ワークフローを使用して、確立された所有権を持つ定義済みのプロセス管理確認する必要があります | |
| ユーザーは、所有するグループの会社データにアクセスするアプリに同意できます | いいえ | 同意を必要とするアプリケーションは、同意要求ワークフローを使用して、確立された所有権を持つ定義済みのプロセス管理確認する必要があります | |
| ユーザーはギャラリー アプリを自分のアクセス パネルに追加できます | いいえ | EDU テナント内のグループには、構造化および管理する必要がある機密性の高いリソース アクセス (学生情報へのアクセスなど) が含まれる場合があります。 これらのシナリオでは、ユーザーが開始する管理は推奨されません | |
| 同意要求の管理 (プレビュー) | |||
| ユーザーは、同意できないアプリに対して管理者の同意を要求できます | いいえ | この設定を有効にすると、テナント内のすべてのユーザーが同意を要求できるようになり、管理者に多数の同意要求が送信される可能性があります。 管理者が要求を管理できない場合や管理したくない場合は、ユーザーが混乱する可能性があります。 | |
| 管理者の同意要求を確認するユーザーを選択する | 該当なし | 同意要求機能管理有効になっている場合にのみ適用されます | |
| 選択したユーザーは、要求の電子メール通知を受け取ります | 該当なし | 同意要求機能管理有効になっている場合にのみ適用されます | |
| 選択したユーザーは、要求の有効期限のリマインダーを受け取ります | 該当なし | 同意要求機能管理有効になっている場合にのみ適用されます | |
| 同意要求の有効期限が切れる (日数) | 該当なし | 同意要求機能管理有効になっている場合にのみ適用されます | |
| Office 365設定 | |||
| ユーザーは、Office 365 ポータルでのみOffice 365アプリを表示できます | 不要 | ポータルマイ アプリ使用する場合、アプリをマイ アプリに表示する場合は、この設定Office 365 [いいえ] に設定する必要があります。 マイ アプリ ポータルの概要アプリ/access-panel-deployment-plan |
ID ガバナンス設定
アクセス パッケージを介して追加された外部ユーザーのライフサイクルを管理するには、最後のアクセス パッケージの割り当てが失われた場合の動作を指定します。
| 設定 | 値 | 理由 |
|---|---|---|
| 外部ユーザーがこのディレクトリにサインインできないようにブロックする | はい | 外部ユーザーがアクセス パッケージへの最後の割り当てを失った場合は、ブロックしてから、テナントから削除する必要があります。 |
| 外部ユーザーを削除する | はい | 外部ユーザーがアクセス パッケージへの最後の割り当てを失った場合は、ブロックしてから、テナントから削除する必要があります。 |
| このディレクトリから外部ユーザーを削除するまでの日数 | 30 | 外部ユーザーがアクセス パッケージへの最後の割り当てを失った場合は、ブロックし、テナントから削除する必要があります |
パスワード リセット設定
| 設定 | 値 | 理由 | |
|---|---|---|---|
| Properties | |||
| セルフサービス パスワード リセットが有効 | ユーザーを選択します | テキストに携帯電話を使用でき、Microsoft Authenticator アプリをインストールして設定できるすべてのユーザーには、セルフサービス パスワード リセットをお勧めします。 | |
| 認証方法 | |||
| リセットに必要なメソッドの数 | 2 | 2 つの方法は、使いやすさとセキュリティのバランスを取ります。 | |
| ユーザーが使用できるメソッド | モバイル アプリ通知、モバイル アプリ コード、電子メール、携帯電話 (SMS のみ) | Mobile App には、最新かつ安全な暗号化方法が用意されています。 その後、電子メールまたは SMS を別のオプションとして使用できます。 EDU テナントのアカウントにパスワードレス認証方法をデプロイすることを強くお勧めします。 これにより、ユーザー エクスペリエンスが向上します。 |
|
| 登録 | |||
| サインイン時にユーザーに登録を要求しますか? | はい | この値を使用すると、アカウントは最初のサインイン時に SSPR への登録を提供するために中断されます。 これにより、一貫性のあるベースラインでアカウントをオンボードできます。 | |
| ユーザーが認証情報の再確認を求められるまでの日数 | 180 | ||
| 通知 | |||
| パスワードリセットをユーザーに通知しますか? | はい | 通知により、この機密性の高い資格情報管理操作が可視化されます。 | |
| 他の管理者がパスワードをリセットしたときに、すべての管理者に通知しますか? | はい | 通知により、この機密性の高い資格情報管理操作が可視化されます。 |
セキュリティの設定
| 設定 | 値 | 理由 | |
|---|---|---|---|
| 認証方法ポリシー | |||
| FIDO2 セキュリティ キー | はい – ユーザーの選択 | ||
| Microsoft Authenticator パスワードレス サインイン | はい – ユーザーの選択 | ||
| テキスト メッセージ | 不要 | 電話番号は、この機能を使用する必要があるすべてのユーザーに割り当てる必要があります。 この機能に強力なユース ケースがない場合、電話番号を追加するオーバーヘッドは保証されません。 |