Office 365 のセキュリティ対策設定をどのようにしていけばよいかわからない管理者のために、Microsoft UK の Consulting Services が作成した「Office 365 UK Blueprint -Secure Configuration Alignment」の日本語抄訳を作成しました。

1. テクニカルガイド
Office 365 UK Blueprint - セキュリティで保護された構成の設定
英国政府のために作成
第 2 版最終版
2021 年 4 月 9 日
英国マイクロソフトコンサルティングサービス
日本語版 1.0
2022 年 8 月 25 日
日本マイクロソフト株式会社パブリックセクター事業本部文教営業統括本部

2. 本ドキュメントは英国マイクロソフト コンサルティングサービスが、英国政府向けに作成した「Office 365
UK Blueprint - Secure Configuration Alignment 」の抄訳です。
教育機関用ライセンスを購入できる組織は、Microsoft 365 E3 → A3、E5 → A5 と置き換えてお読みくださ
い。
マイクロソフトは、本書において、明示または黙示を問わず、いかなる保証もいたしません。
適用されるすべての著作権法を遵守することは、ユーザーの責任です。 マイクロソフトの書面による明示的
な許諾がない限り、著作権に基づく権利を制限することなく、本書のいかなる部分も、いかなる形式または手
段 (電子的、機械的、複写、記録、その他) で、あるいはいかなる目的においても、複製、検索システムへの保
存または導入、転送してはならないものとします。マイクロソフトは、本書の主題を対象とする特許、特許出
願、商標、著作権、またはその他の知的財産権を有している場合があります。 マイクロソフトの書面による
ライセンス契約において明示的に規定されている場合を除き、当社が本書を提供することによって、これらの
特許権、商標権、著作権、またはその他の知的財産権に対するライセンスをお客様に供与するものではありま
せん。
本書に他社の製品に関する記述がある場合、それはお客様の便宜のためにのみ提供されるものです。 このよ
うな言及は、マイクロソフトによる推奨またはサポートと見なされるべきではありません。 マイクロソフト
はその正確性を保証することはできませんし、製品は時間の経過とともに変更される可能性があります。ま
た、これらの説明は、完全なカバーではなく、理解を助けるための簡単なハイライトとして意図されていま
す。これらの製品に関する信頼できる説明については、それぞれのメーカーにお問い合わせください。
©2021 Microsoft Corporation. すべての著作権はマイクロソフトに帰属します。マイクロソフトの明示的な
許可なく、これらの資料を使用または配布することは、固く禁じられています。
Microsoft および Windows は、米国 Microsoft Corporation の米国およびその他の国における登録商標また
は商標です。本書に記載されている会社名、製品名は、各社の商標または登録商標である可能性があります。

3. 目次
1 本ドキュメントの概要 1
2 本ドキュメントの特徴 5
3 特権管理 7
3.1 Better な構成からはじめる . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.1 Azure AD の特権 ID 管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.2 Azure AD Identity Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 緊急アクセスまたは Break Glass アカウント . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3 クラウドを使用したクラウドサービスの管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4 Good な構成の設定 20
4.1 アイデンティティ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1.1 OAuth アプリの管理者同意の設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1.2 認証方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1.3 推奨される認証方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1.4 条件付きアクセス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1.5 アカウントポリシー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2 Microsoft 365 サービスの構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.1 Microsoft 365 の監査ログの取得 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.2 セキュリティスコアーのレビュー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.3 データ損失防止（DLP）の設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.4 Office 365 Cloud App Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.5 Exchange online . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.6 Microsoft Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.7 SharePoint Online . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
i

4. 4.2.8 OneDrive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5 Better な構成の設定 50
5.1 アイデンティティ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.1.1 Azure AD Identity Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.1.2 ユーザーアカウントに不審な動きがないかを監視する . . . . . . . . . . . . . . . . . . . . 55
5.1.3 Azure AD Privileged Identity Management (PIM) . . . . . . . . . . . . . . . . . . . . 55
5.1.4 特権的な役割のアクセスレビューのスケジュール . . . . . . . . . . . . . . . . . . . . . . 56
5.1.5 Azure AD のエンタイトルメント管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.2 Office 365 のサービス設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.2.1 Office 365 Advanced Threat Protection の安全な添付ファイル機能を設定する . . . . . . 57
5.2.2 Office 365 Advanced Threat Protection のセーフリンク機能を設定する . . . . . . . . . 58
5.2.3 Microsoft Information Protection（ラベル付け/可視化マーキング） . . . . . . . . . . . 58
5.2.4 攻撃のシミュレーションを実行する . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.2.5 Microsoft Defender for Office を Azure Sentinel に接続する . . . . . . . . . . . . . . . 59
5.2.6 Microsoft Store for Business での買い物を許可しない . . . . . . . . . . . . . . . . . . . 60
5.2.7 SharePoint と OneDrive のアイドル セッション タイムアウトをオンにする . . . . . . . 60
5.2.8 新しいファイルを機密ファイルとしてマークするをデフォルトでオンにする . . . . . . . . 60
6 Best な構成の設定 62
6.1 アイデンティティ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.2 Office 365 サービスの設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.2.1 Customer Lockbox の有効化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.2.2 インサイダリスクの管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.2.3 Endpoint データ損失防止 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.2.4 Microsoft Cloud App Security でクラウドアプリからのデータ損失を防ぐ . . . . . . . . . 65
6.2.5 秘密度ラベルによるコンテンツへのアクセス制限 . . . . . . . . . . . . . . . . . . . . . . 67
ii

5. 7 インシデントの対応 67
7.1 緊急対策 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
iii

6. 1 本ドキュメントの概要
Microsoft は安全なクラウド サービスを提供しており、その構成状態について、ISO 27000*1
規格群や
NIST 80053 などの米国標準技術局 (NIST) が発行するガイドラインなど、多数の第三者検証による認証を受
けています。
この文書は、英国政府の部局が義務を果たし、サービス内に存在する機能と能力を活用するのに役立つ方法
で Office 365 を構成することを支援する必要性から生まれました。 英国政府、産業界における幅広い経験に
基づき、National Cyber Security Centre (NCSC) と Microsoft がそれぞれの Web サイトで公開している
既存の「ベストプラクティス」を大いに活用しています。
注意事項
このガイダンスは、
「NCSC と Microsoft のガイダンスに従ったので、これ以上何もする必要はな
い」ということを示唆するためのものではありません。 むしろ、本書で説明する対策は、特定のセキュ
リティ対策が推奨される理由を読者が理解し、構成ガイダンスへのリンクを提供することで、組織が
Office 365 の機能をどのように設定すれば、Office 365 テナントの共通基準が達成されたことを確認で
きるようにすることを目的としています。
Blueprint は以下の主要なセクションで構成されています。
• 特権管理
– 特権管理は、Office 365 構成にどのアライメント (Good、Better、Best) が選択されているかに関
係なく考慮する必要があります。
– 特権ユーザーおよび管理タスクを実行するために使用されるデバイスの推奨最小構成を形成し
ます。
– 特権管理コントロールの推奨されるすべての構成タスクを満たすには、Microsoft 365 E3 と
*1 Office 365 の ISO27001 の証明書は 監査レポート をご確認ください。
1

7. Microsoft 365 E5 セキュリティライセンスが必要です。また、Microsoft 365 E5 ライセンスが利
用可能な組織にも適用されます。
– オンプレミス コンポーネントに対するすべての依存関係を削除します。
– ゼロトラストセキュリティの原則に基づいて構築します。
• Good な構成の設定
– すべての組織が満たすべき最低レベルの構成を構築できます。
– Microsoft 365 E3 ライセンスで利用可能です。
– 簡単な設定作業で実装可能です。
– Exchange Online と SharePoint Online で MFA と制限付きセッション制御を備えた条件付きア
クセスを使用します。
– 最も残存リスクが高いです。
• Better な構成の設定
– 組織が目指すべき構成レベルを構築できます。
– Microsoft 365 Security and Compliance パッケージ コンポーネントまたは Microsoft 365 E3 と
Microsoft 365 E5 Security の組み合わせで利用可能です。
– より複雑な設定作業が必要になる場合があります。
– 条件付きアクセスを使用して管理対象 PC、Mac、またはモバイル デバイスを要求する適用は、
Office クライアント アプリケーションを使用して Office 365 サービスにアクセスするために使用
されます。
– Microsoft Cloud App Security を使用したユーザーポリシー、セッションコントロールの柔軟で
きめ細かい制御が可能です。
– Good 構成より残存リスクは低いです。
• Best な構成の設定
– 利用可能な最も完全な保護機能を構築できます。
– Microsoft 365 E3 with Microsoft 365 E5 Security と Microsoft 365 E5 Compliance または
Microsoft 365 E5 で利用可能です。
– Microsoft Cloud App Security を使用したユーザー ポリシー、セッション制御の柔軟できめ細か
2

8. い制御を行います。
– Microsoft Cloud App Security を使用したユーザーポリシー、セッションコントロールの柔軟で
きめ細かい制御が可能です。
– 多くの場合、より複雑な構成タスクが必要であり、機能間の統合も必要です。
– Good や Better パターンと比較して、最もリスクの低いアプローチです。
重要
多くの中央省庁や脅威の高い組織では、Office 365 環境を適切に保護し、インシデント発生時に調査を
行うために、望ましいセキュリティの姿勢は ”Better” からはじめるべきでしょう。
この取り組みを支援するためにこのドキュメントでは、組織が Office 365 テナントを構成および運用すると
きに考慮する必要がある推奨されるセキュリティ構成制御をアドバイスするために開発されました。
「Good
な構成の設定」
、
「Better な構成の設定」
、
「Best な構成の設定」 の各セクションには、次の領域に関するガ
イダンスが含まれています。
• アイデンティティ
Office 365 サービスに対する認証に使用されるアイデンティティの保護方法を説明した推奨設定につい
て解説します。
• Office 365 サービスの構成
サービスをセキュリティで保護するための特定の設定を記述する Office 365 環境の推奨設定により、
組織の Office 365 テナントのセキュリティ体制が向上します。
このガイダンスは特に指定がない限り、すべての Office 365 サービスに適用されます。 これにより、
Microsoft 365 グループや Teams などの新しい機能と、 Exchange や SharePoint などのオンプレミスサー
ビスをより直接的に置き換えるコンポーネントを最大限に活用できるようになります。
本ドキュメントでは、図 1 の「Good な構成の設定」
、
「Better な構成の設定」
、
「Best な構成の設定」 に
記載されている機能は、このドキュメントで説明されているパターンのどれを使用すべきかを組織が判断でき
3

9. るように設計されています。例えば、組織が Microsoft 365 Security and Compliance Pack (SCP) または
Microsoft 365 E3 と E5 Security ライセンスを持っている場合、
「Better な設定」 で設定される項目は、よ
り残留リスクを低くするために使用するべきです。
図 1: 各構成の設定項目一覧
4

10. 2 本ドキュメントの特徴
本ドキュメントのデザインを構成するコンポーネントを図 2 に示します。
図 2: Office 365 のコンポーネント図
本ドキュメントでは、特権アクセスと、管理対象デバイスが Microsoft Office 365 サービスの企業データに
アクセスできるようにする要件を満たすと識別された 4 つの主要な構成パターンについて説明します。
• 管理された Android または iOS デバイス上の Office 365 アプリ
• 管理対象 PC または Mac での Office 365 Web アプリへのアクセス
• 管理対象 PC または Mac での Office 365 デスクトップ クライアントアプリケーションへのアクセス
• PC または Mac から Windows 仮想デスクトップ上で使用する Office 365 デスクトップ クライアント
5

11. 必要条件
以下に示すのは、本ドキュメントが想定している前提条件です。
1. この Blueprint は、Office 365 サービスへの接続に使用されるエンドユーザーデバイスが、モバイルデ
バイスおよび PC デバイスに関する NCSC のプラットフォーム固有のガイダンスに従って設定されて
いることを前提としています。
2. 管理対象モバイルデバイスで承認されたアプリのみを許可します。
3. 管理対象 PC または Mac が Web アプリケーションまたはデスクトップクライアントアプリケーショ
ンを使用してアクセスすることのみを許可します。
4. Office 365 サービスにアクセスするには、MFA と準拠またはハイブリッドの Azure AD 参加済みデバ
イスが必要です。
重要
本ドキュメントではデバイスが個人管理されていない Bring Your Own Device (BYOD) である場合
に利用できる設定については、意図的に説明しておりません。Microsoft Intune で管理対象デバイスと
して使用できるコントロール、または Microsoft Intune と Configuration Manager の共同管理対象デ
バイスとして使用できる設定に焦点を当てています。
BYOD については、
「How to have secure remote working with a BYOD policy」 を参照してくださ
い。
6

12. 3 特権管理
特権アクセスはすべての組織でセキュリティの最優先事項である必要があり、Microsoft は最近、
「特権ア
クセスのセキュリティ保護に関するガイダンス」を更新し、オンプレミス環境だけでなく、オンプレミス、
Azure 、サードパーティのクラウドプロバイダーなど、エンタープライズ IT 組織がワークロードとそれらが
ホストされているインフラストラクチャを管理およびサポートする、より複雑なハイブリッド環境を含めまし
た。 特権アクセス用の PC を実装するための構成タスクの詳細については、
「特権アクセスの展開」を参照し
てください。
国立サイバーセキュリティセンター (NCSC) も安全な管理慣行に関するガイダンスを公開しており、2019
年 5 月に「セキュリティアーキテクチャのアンチパターン」が公開され、最初のアンチパターンは「管理者の
ためのブラウズアップ」でした。
整合性が重要なコンピュータシステム（個人データや決済を扱うデジタルサービスから産業用制御システ
ムまで）では、システムの管理・運用に使用されたデバイスに信頼性がなければ、そのシステムの整合性
に信頼性を持つことはできません。Bastion ホストやジャンプボックスを使用することで信頼できない
デバイスから管理者が作業を行える良い方法であるという一般的な誤解が存在します。残念ながらそれ
は間違いなのです。
2020 年 9 月、NCSC は「安全なシステム管理に関する追加ガイダンス」を発表し、その中でも特に次のよ
うに呼びかけています。
• システム管理インターフェースへのアクセスに使用するデバイスは、信頼できるものでなければなりま
せん。
• これらの専用管理デバイスは、特権アクセス ワークステーション (PAW) と呼ばれることがよくあり
ます。クラウドサービスを管理するときは、これらを使用することをお勧めします。
• 管理用インターフェイスへの接続を許可する場合、そのデバイスを信頼できるようにする必要がありま
す。 これにより、攻撃者が正当なシステム管理ではなく、デバイスを使用してシステムにアクセスす
る可能性が低くなります。
7

13. また、これらの管理作業を行うためのアカウントは、電子メールやウェブ閲覧などの生産性向上に使用
するアカウントとは別にすることが重要です。
「Microsoft, Separate accounts for admins」 と NCSC の
「Systems Administration Architectures」 は、管理者は以下のように推奨しています。
管理と通常のユーザーアクティビティ用に別々のユーザーアカウントを用意してください。 通常のビジ
ネス活動に管理アカウントを使用しないでください。 これにより、特権アカウントの露出が減り、侵害
のリスクが軽減されます。
次の表 (P.10∼P.15) は特権管理のために導入されることが予想される設定の一覧です。詳細については、
次のセクションで説明します。
特権アクセスのセキュリティは他のすべてのセキュリティ保証の基盤なり、特権アカウントを制御する攻撃
者が他のすべてのセキュリティ保証を損なう可能性があるため非常に重要です。 リスクの観点から見ると、
特権アクセスの喪失は影響の大きいイベントであり発生する可能性が高く、業界全体で非常に多くのインシデ
ントが発生しています。
特権アクセスを保護することで未許可のアクセス経路を完全に封鎖し、保護され厳重に監視される一部の認
可されたアクセス経路を残すことにつながります。
これらのユーザーの侵害は組織に重大な悪影響を及ぼす可能性が高いです。 特権ユーザーは組織内のビジ
ネスクリティカルな資産にアクセスできるため、攻撃者がそのアカウントを侵害した場合多くのインシデント
において大きな影響を及ぼします。
重要な影響を及ぼすすべての管理者が、管理作業用に別のアカウントを持つようにします（電子メール、
Web ブラウジング、およびその他の生産性作業に使用するアカウントとは異なる）
。 これらの管理用アカウ
ントでは、Office 365 の電子メールなどの生産性ツールをブロックします（ライセンスを削除する）
。 可能
であれば、任意の Web ブラウジングをブロックし（プロキシおよび/またはアプリケーション制御を使用）
、
Azure ポータルおよび管理タスクに必要なその他のサイトへのブラウジングは例外的に許可します。
フィッシングと Web ブラウザー攻撃は、管理者アカウントを含むアカウントを侵害する最も一般的な攻撃
方法です。 攻撃者は、人為的なランサムウェア攻撃や標的型データ窃盗の際に、特権アクセスセキュリティの
弱点を頻繁に悪用します。 特権アクセス権限を持つアカウントと PC は、攻撃者にとって非常に魅力的です。
なぜならこれらのターゲットによって、企業内のビジネス資産に迅速に幅広くアクセスできるようになり、多
8

14. くの場合迅速かつ重大なビジネスインパクトを与えることができるからです。
これらの攻撃手法は当初、標的型データ窃盗攻撃で使用され有名ブランドの多くの有名な侵害をもたらしま
した（そして多くの報告されていない事件もあります）
。 最近では、これらのテクニックはランサムウェア攻
撃者にも採用され、業界を問わず意図的に事業運営を妨害する、収益性の高い人為的なランサムウェア攻撃の
爆発的な増加に拍車をかけています。
設定内容 手順
Microsoft 365 の管理者アカウント 管理者ユーザー専用のアカウントを作成
を分離する ・Azure AD でマスター、つまりクラウドのみの ID です。
・多要素認証を使用して認証されます。
・Azure AD 条件付きアクセスによってセキュリティで保護され
ています。
・ Azure で管理された PC を使用する場合のみアクセス可能で
す。
オンプレミスのアカウントに Microsoft 365 の管理者権限を持
たせてはいけません。
詳細については、
「Microsoft 365 の管理者ロールの概要」と
「Azure AD の Microsoft 365 用のロール」を参照してください。
Microsoft 365 から特権管理 PC を
管理する
Azure AD join と Microsoft Intune などのクラウドベースのモ
バイルデバイス管理（MDM）を使用することで、オンプレミス
のデバイス管理インフラへの依存を無くすことができます。この
ような依存関係は、デバイスとセキュリティの制御を危険にさら
す可能性があります。
特権管理 PC の利点や導入方法については、
「特権アクセスデバ
イス」と「特権アクセス実装」を参照してください。
9

15. 設定内容 手順
オ ン プ レ ミ ス の ア カ ウ ン ト に Mi-
crosoft 365 への昇格権限がないこと
を確認します。
一部のアカウントは、NTLM、LDAP、または Kerberos 認証を
必要とするオンプレミス・アプリケーションにアクセスします。
オ ン プ レ ミ ス の ア カ ウ ン ト に Mi-
crosoft 365 への昇格権限がないこと
・これらのアカウントは、組織のオンプレミス ID インフラスト
ラクチャに存在する必要があります。
を確認します。 ・サービスアカウントを含むこれらのアカウントが、特権的なク
ラウドのロールまたはグループに含まれていないことを確認しま
す。
・これらのアカウントに対する変更が、クラウド環境の整合性に
影響を及ぼさないようにする。
オンプレミスの特権的なソフトウェアは、Microsoft 365 の特
権的なアカウントやロールに影響を与えることができないように
する必要があります。
オンプレミスのアカウントに Microsoft 365 の特権ロールを割
り当ててはいけない理由については、
「オンプレミスの攻撃から
Microsoft 365 を守る」を参照してください。
認 証 に Azure AD を Identity
Provider として使用する。
オンプレミスの認証情報への依存をなくすために。 Azure AD
を特権アカウントのアイデンティティ プロバイダーとして使用
する理由の詳細については、
「オンプレミスの攻撃から Microsoft
365 を保護する」を参照してください。
多要素認証やパスワードレス方式に
よる強力な認証制御を常に使用する。
Windows Hello、FIDO、Microsoft Authenticator、Azure AD
の多要素認証など。
強力な認証が必要な理由については、
「特権アクセスアカウント」
と「Azure AD 特権ユーザーの MFA、パスワードレス」を有効
にして要求するを参照してください。
10

16. 設定内容 手順
緊急アクセス用アカウントを使用する 緊緊急時に管理者アクセスを取得するためのメカニズムがあるこ
とを確認します。まれに、通常の管理アクセス手段がすべて使用
できないという極端な状況が発生することがあります。
これらのアカウントは、ID 保護、MFA、または条件付きアクセ
ス ポリシーの対象にならず、Azure AD 特権 ID 管理のグローバ
ル管理者ロールに永続的に割り当てる必要があります。
これらのアカウントが必要な理由と設定方法については、
「§3.2
緊急アクセスまたは Break Glass アカウント」をご参照くださ
い。
特権ユーザーに対するゼロトラスト
セキュリティアプローチの実装
Azure AD の条件付きアクセスは、特権ユーザーのアイデンティ
ティ、ネットワークの場所、およびリスクシグナルに基づいて、
アクセスを許可または拒否する決定、および追加の強制手段の適
用を行うための制御を提供します。
条件付きアクセスは、ゼロトラストセキュリティアプローチを実
装するためのメカニズムとして使用されます。
Azure AD の条件付きアクセスは、特権ユーザーアカウントに
MFA を実装するための推奨方法です。
管理対象/準拠デバイスへのアクセス
の制御
ログオン時の Azure AD 条件付きアクセスを使用して、使用して
いるデバイスに基づいてユーザーが持つアプリケーション アク
セスを決定し、必要に応じて追加のコントロールを適用する必要
があります。
詳細については、
「§3.1.2 Azure AD Identity Protection」を参
照してください。
11

17. 設定内容 手順
レガシー認証プロトコルの使用禁止 レガシー認証プロトコルは、認証方法としてユーザー名とパス
ワードのみをサポートします。これにより、攻撃者はパスワード
スプレー攻撃などを実行する機会を得ることができます。
また、レガシー認証プロトコルは、Azure AD MFA を使用する
ことができません。
「特権ユーザーアカウントのレガシー認証プロトコルをブロック
する」を参照してください。
パスワードの有効期限を設定しない。 定期的なパスワードの変更を強制することは、パスワードの選択
ミスにつながることが実証されています。
Azure AD Password Protection control (Better カテゴリに含
まれる) と組み合わせると、パスワードの複雑性や有効期限を強
制する必要性が大幅に軽減することができます。
過去 30 日間使用されていないアカウ
ントを無効にする
アカウント、特に特権的な役割を果たすアカウントは、アクティ
ブなままにしておくべきではありません。
詳細は「4.1.5.2 過去 30 日間に使用されていないアカウントを無
効にする」を参照してください。
専用アカウントを使用して管理業務を
行う
インターネット閲覧や電子メールに使用するアカウントと同じア
カウントを使用して特権的なタスクを実行しないこと。
アカウントを分けることで、フィッシングなどの攻撃が成功し、
特権的なアイデンティティが侵害される可能性が低くなります。
12

18. 設定内容 手順
Microsoft 365 グローバル管理者ロー
ルのメンバーシップを設定する。
グローバル管理者の数を最小レベルに抑えることは、最小特権管
理モデルの重要な部分です。
グローバル閲覧者の役割を使用すると、管理者はグローバル管理
者の役割に昇格することなく、Office 365 のポリシーと構成の設
定を確認できます。
詳細については「重大な影響の管理者の数を最小限に抑える」を、
Azure AD ロールの詳細については、
「Azure AD の Microsoft
365 のロール」を参照してください。
グローバルでない管理者ロールを使用
する
グローバル管理者の数を減らすために、ロールベースのアクセス
モデルを実装することは、最小権限管理モデルの重要な部分で
す。管理モデルの重要な部分です。例えば、Azure AD ロール、
SharePoint 管理者、Exchange 管理者、および Teams 管理者の
ロールを使用します。
Azure AD のロールの詳細については、
「Azure AD における
Microsoft 365 のロール」を参照してください。
Office 365 サービスのより詳細なロー
ルベースのアクセス制御 (RBAC) モ
デルを開発する
最小特権管理モデルの一部として、Azure AD で特権の低い組み
込みロールを使用するか、管理者がタスクを実行するために必要
な特権のみを付与するアプリケーション固有のロールを開発しま
す。
13

19. 設定内容 手順
すべてのグローバル管理者に MFA を
適用する
すべてのグローバル管理者メンバーに MFA の使用を強制する
と、ユーザー名とパスワードのみが使用されている場合よりアカ
ウントが侵害されるリスクが軽減されます。
この制御を実装するために、Azure AD Conditional Access を使
用することが推奨されます。
Azure AD 特権ユーザーの MFA パスワードレスを有効にして
要求します。パスワードレスの詳細については、
「パスワードレ
スの展開」を参照してください。
特権ロールへの常設アクセスの削減す
る
Azure AD 特権 ID 管理を実装して、Azure AD および Office
365 の特権ロールへの常設アクセスを削除します。
詳細については、
「セクション 3.1.1 Azure AD 特権 ID 管理」を
参照してください。
3.1 Better な構成からはじめる
特権管理者は、特権 ID およびデバイスに適切かつ適切なレベルの保護を提供するために、
「Better 構成パ
ターン」からはじめる必要があります。 そのためには、Microsoft 365 E5 Security および Microsoft 365 E5
ライセンスが最低限必要であり、これによって組織は Microsoft Defender for Endpoint を利用できるように
なり、検出および対応機能を備えた脅威保護機能を強化することができます。
図 3: Threat Protection のライフサイクル
14

20. 1. 脅威を可能な限り防ぐ。
2. 迅速に検知し、対応する。
3. 学習したことを継続的に適用する。
3.1.1 Azure AD の特権 ID 管理
特権 ID について考慮すべき重要な点は、漏洩したアカウントが特権的な役割で操作できる可能性を最小化
する必要があることです。特権 ID に永続的な「常時」アクセスを提供することは避けてください。
永続的な特権は攻撃者にダメージを与えるためにアカウントを使用できる時間を増やすことになり、ビジネ
スリスクを増大させます。 一時的な特権の付与により、アカウントを標的とする攻撃者は、管理者が既にア
カウントを使用している限られた時間内で作業を行うか、特権の昇格を行わせることになります (これにより、
検出されて環境から削除される可能性が高くなります)。
Azure AD Privileged Identity Management (PIM) は、アカウント権限の最小化を支援することにより、
アカウント権限の最小化を支援します。
• 管理ロールに割り当てられたユーザーを特定して管理します。
• 削除する必要がある未使用または過剰な特権ロールについて理解します。
• 特権ロールが多要素認証によって保護されていることを確認するためのルールを確立します。
• 特権ロールが特権タスクを実行するのに十分な期間だけ付与されるようにするルールを確立します。
Azure AD PIM を有効にし、管理ロールが割り当てられているユーザーを表示し、それらのロールの不要
なアカウントを削除します。 残りの特権ユーザーについては、永続的なユーザーから資格のあるユーザーに
移行します。 最後に、特権的なロールにアクセスする必要がある場合に、必要な変更管理を行いながら安全
にアクセスできるように、適切なポリシーを確立します。
詳細は、
「常時アクセス不可／ Just in Time 権限」
、
「Azure AD Privileged Identity Management の有効
化」を参照してください。
15

21. 3.1.2 Azure AD Identity Protection
Office 365 の管理に使用される特権アカウントの保護は非常に重要です。これらのユーザーには追跡可能な
通常の行動パターンがあり、この規範から外れた場合、サインインだけを許可するのは危険です。
Identity Protection は、組織が 3 つの重要なタスクを達成できるようにする推奨ツールです。
• ID ベースのリスクの検出と修復を自動化します。
• ポータルのデータを使用してリスクを調査します。
• さらなる分析のためにサードパーティのユーティリティにリスク検出データをエクスポートします。
Azure AD ID 保護ポリシーは、既定のポリシーを使用して適用するのではなく、条件付きアクセス ポリ
シーを使用することをお勧めします。
サインインリスクは、特定の認証要求が ID 所有者によって承認されていない可能性を表します。特権ユー
ザーの場合、次のリンクで説明されているサインイン リスクベースの条件付きアクセスポリシーは、MFA を
実行するのではなくブロックするように構成することをお勧めします。
「条件付きアクセス: サインインリスクベースの条件付きアクセス」
ユーザーリスクに基づく条件付きアクセスは、研究者、法執行機関、マイクロソフトの様々なセキュリティ
チーム、およびその他の信頼できるソースとの協力の一環として収集されたデータを使用して、流出したユー
ザー名とパスワードのペアを検出します。 特権を持つユーザーに対しては、次のリンクで説明されているユー
ザーリスクに基づく条件付きアクセスポリシーを、パスワードのリセットではなく、ブロックに設定すること
をお勧めします。
詳細については「条件付きアクセス: ユーザー リスクベースの条件付きアクセス」をご参照ください。
3.2 緊急アクセスまたは Break Glass アカウント
管理者としてサインインできない、または他のユーザーのアカウントをアクティブにできないために、誤っ
て Azure Active Directory（Azure AD）組織からロックアウトされることを防ぐことが重要です。 組織内
に 2 つ以上の緊急アクセスアカウントを作成することで、誤って管理者権限を削除した場合の影響を緩和する
ことができます。
16

22. 緊急アクセスアカウントは非常に高い権限を持ち、特定の個人に割り当てられることはありません。 緊急
アクセスアカウントは、通常の管理者アカウントを使用できない緊急事態や「Break Glass」シナリオに限定
される。 緊急アクセスアカウントの使用は、絶対に必要な時だけに制限するという目標を維持することをお
勧めします。
詳細は「緊急アクセスアカウント」を参照し、
「Azure AD の緊急アクセス管理アカウントの管理の手順」に
従って、セキュリティ運用でこれらのアカウントを慎重に監視することをお勧めします。
3.3 クラウドを使用したクラウドサービスの管理
2020 年に発生した 「SolarWinds の侵害」を受け、Microsoft はブログ記事「オンプレミスの攻撃から
Microsoft 365 を保護する」を公開し、組織のオンプレミスインフラで習得した管理アカウントやデバイスを
使用して Microsoft 365 を管理すると、オンプレミスインフラの侵害が発生した場合にクラウドサービスに伝
播するリスクがあると強調しました。
オンプレミスのインフラを Microsoft 365 に接続するハイブリッド展開では、組織はしばしば重要な認証と
ディレクトリオブジェクトの状態管理の決定をオンプレミスのコンポーネントに委ねることがあります。 残
念ながら、オンプレミス環境が侵害された場合、これらの信頼関係は攻撃者が Microsoft 365 環境を侵害する
チャンスとなります。
2 つの主要な脅威ベクトルは、フェデレーションの信頼関係とアカウントの同期です。 どちらのベクトル
も攻撃者にクラウドへの管理アクセス権を付与することができます。
• SAML 認証などのフェデレーションによる信頼関係は、オンプレミスのアイデンティティ インフラ
ストラクチャを経由して Microsoft 365 に認証するために使用されます。 SAML トークン署名証明書
が侵害された場合、その証明書を持つ誰もが、クラウド内の任意のユーザーになりすますことができる
フェデレーションが発生します。 Microsoft 365 への認証では可能な限りフェデレーションの信頼関係
を無効にすることをお勧めします。
• アカウントの同期は、Microsoft 365 の管理者権限を持つ特権ユーザー (資格情報を含む) やグループを
変更するために使用することができます。 同期されたオブジェクトが、直接、または信頼されたロール
やグループに含まれることによって、Microsoft 365 のユーザーを超える権限を保持していないことを
17

23. 確認することをお勧めします。 これらのオブジェクトが、信頼されたクラウドのロールまたはグルー
プに直接またはネストされた割り当てを持っていないことを確認します。
上記のような脅威のベクトルに対処するため、マイクロソフトは、組織が図 4 に示される原則に従うことを
推奨しています。
図 4: クラウド認証の原則
1. Microsoft 365 管理者アカウントを完全に分離します。それらは、次のようになります。
• Azure AD でマスターされていること。
• 多要素認証が利用されていること。
• Azure AD の条件付きアクセスによってい保護されていること。
• Azure AD が管理する PC を使用してのみアクセスできること。
これらの管理者アカウントは、
使用制限付きアカウントです。オンプレミスのアカウントで Microsoft
365 の管理者権限を持つべきではありません。
詳細については、
「Microsoft 365 の管理者ロールの概要」または「Azure AD における Microsoft 365
のロール」を参照してください。
18

24. 2. Microsoft 365 からデバイスを管理する
Azure AD join とクラウドベースのモバイルデバイス管理 (MDM) を使用して、オンプレミスのデバ
イス管理インフラストラクチャへの依存を排除します。 これらの依存はデバイスとセキュリティの制
御を危険にさらす可能性があります。
3. オンプレミスアカウントが Microsoft 365 に対して昇格した特権を持っていないことを確認する
一部のアカウントは、NTLM、LDAP、または Kerberos 認証を必要とするオンプレミスのアプリケー
ションにアクセスします。
• これらのアカウントは、組織のオンプレミス ID インフラストラクチャに含まれている必要があり
ます。
• サービスアカウントを含むこれらのアカウントが、特権的なクラウドのロールまたはグループに含
まれていないことを確認します。
• これらのアカウントに対する変更が、クラウド環境の整合性に影響を及ぼさないようにします。
オンプレミスの特権的なソフトウェアが、Microsoft 365 の特権的なアカウントやロールに影響を与
えることができないようにすること。
4. Azure AD 認証方式を使用して、オンプレミスの認証情報への依存をなくす
Windows Hello、FIDO、Microsoft Authenticator、Azure AD の多要素認証など、常に強力な認証を
使用するようにします。
5. 緊急アクセスアカウントを使用して、緊急時に管理者アクセスを取得するメカニズムを確保する
まれに、通常の管理者アクセス手段をすべて使用できない極端な状況が発生することがあります。 詳
しくは「緊急アクセス用管理者アカウントの管理」を参照してください。
19

25. 4 Good な構成の設定
このセクションでは、Microsoft 365 E3 ライセンスを購入した組織に推奨されるセキュリティ制御につい
て説明します。
組織は、Office 365 テナントのセキュリティを確保するために、可能な限り多くのセキュリティ制御を構成
する必要があります。 組織が推奨されるセキュリティ制御を実装しないことを選択した場合、
• 残留リスクが組織的に許容できるかどうかを判断する必要があります。
• 組織のコンプライアンス義務を果たすことができます。
• 補償または緩和措置を組織のリスク登録簿に記載する必要があります。
セキュリティ制御 作業
Microsoft 365 Audit のログが有効に
なっていることを確認する。
Microsoft 365 Compliance Center を使用して、Audit logging
が有効になっていることを確認します。
詳細は「§4.2.1 Microsoft 365 の監査ログの取得」 をご参照くだ
さい。
すべてのユーザーに対してメールボッ
クス監査を有効にする。
Exchange Online のメールボックス監査が有効になっていること
を確認します。
O365 E3 ライセンスのメールボックスを Security and Compli-
ance Center で検索できるように手動で有効にします。
詳細は「§4.2.5.1 メールボックスの監査」をご参照ください。
マイクロソフト セキュア・スコアサー
ビスの利用
現在のセキュアスコアを見直し、記録し、改善策をメモし、それ
を実施することによる組織への価値を評価します。
セキュリティで保護されたスコアの月次レビューをスケジュール
して、スコアの変更と新しいメジャーを監視します。
詳細は「§4.2.2 セキュアスコアのレビュー 」をご参照ください。
20

26. セキュリティ制御 作業
Office 365 のクラウド認証モデルを実
装する。
Azure Active Directory をプライマリ認証メカニズムとして構成
します。
詳細は「§4.1.2.1 クラウド認証」をご参照ください。
OAuth アプリの管理者同意の設定を
する。
Azure Active Directory のアプリケーションに対するユーザーの
同意を、
「ユーザーの同意を許可しない」に設定します。
詳細は「§4.1.1 OAuth のアプリの管理者権限を設定する」を参
照してください。
すべてのユーザーで多要素認証を有
効。
すべてのユーザーに対して Azure AD MFA を有効にします。
にする 詳細は「§4.1.4.1 すべてのユーザーに対する Azure AD MFA の
有効化」を参照してください。
ID を中心とした条件付アクセスの包
括的なアプローチを実施する。
Office 365 サービスへの認証のために、Azure AD で条件付きア
クセスポリシーを計画し、実装します。
詳細は「§4.1.4 条件付きアクセス」をご参照ください。
管理対象/準拠デバイスへのアクセス
の制御
管理対象/準拠デバイスへのアクセスを制御する Azure AD 条件
付きアクセス ポリシーを構成して、Office 365 サービスにアクセ
スするために管理対象デバイスの使用を要求します。
詳細は「§4.1.4.2 管理対象/準拠デバイスへのアクセスの制御」を
ご参照ください。
レガシー認証プロトコルの使用を禁止
します。
レガシー認証方式の使用をブロックするように Azure AD を設
定します。
詳細は「§4.1.4.3 レガシー認証方式をブロックする」をご参照く
ださい。
21

27. セキュリティ制御 作業
パスワードの有効期限を設定しない。 Azure AD のパスワード有効期限ポリシーを設定し、ユーザーの
パスワードを期限切れにしないようにします。
詳細は「§4.1.5.1 パスワードを期限切れにしない」をご参照くだ
さい。
過去 30 日間に使用されていないアカ
ウントを無効化する。
非アクティブなユーザーアカウントのレポートをスケジュール
し、アカウントを無効にします。
詳細は「§4.1.5.2 過去 30 日間に使用されなかったアカウントの
無効化」をご参照ください。
専用アカウントを使用して管理タスク
を実行する。
管理ロールを実行するための専用の Azure AD ユーザーアカウン
トを作成し、使用します。
詳細は「§3.3 クラウドを使用したクラウドサービスの管理」をご
参照してください。
Microsoft 365 グローバル管理者ロー
ルのメンバーを構成する。
Azure AD グローバル管理者ロールからすべてのユーザー アカ
ウントを削除します。ただし、ブレーク グラス アカウントと、こ
のレベルでプラットフォームをサポートするために必要な最小限
の数の管理者アカウントを除きます。
詳細は「§3.3 クラウドを使用したクラウドサービスの管理」をご
参照ください。
グローバル管理者以外のアカウントを
使用して Office 365 の管理タスクを実
グローバル管理者ロール以外のロールを利用して、Office 365 管
理者へのアクセスを委譲します。
行する。 詳細は「§3.3 クラウドを使用したクラウドサービスの管理」をご
参照してください。
22

28. セキュリティ制御 作業
Azure AD にブレイクグラスアカウン
トを設定する。
条件付きアクセスおよび MFA ポリシーから除外される Azure
AD のグローバル管理者ユーザーアカウント 2 つを作成し、維持
します。 これらのアカウントの詳細は保存され、プラットフォー
ムへの緊急アクセスにのみ使用されます。
詳細は「§3.2 緊急アクセスまたは Breack Glass アカウント」を
ご参照してください。
すべてのグローバル管理者に MFA を
適用する。
グローバル管理者ロールを持つ ID の認証時に Azure MFA を要
求するように Azure AD 条件付きアクセス ポリシーを構成しま
す。
詳細は「§4.1.4 条件付きアクセス」をご参照ください。
転送ブロックのクライアントルールを
有効化する。
Exchange Online Protection で外部への電子メールの自動転送
をブロックします。
詳細は「§4.2.5.2 個人用電子メールへの電子メール転送の防止」
をご参照ください。
匿名でのカレンダー共有を許可しな
い。
Microsoft 365 の管理センターで、
「招待メールによるカレンダー
へのアクセスを誰でも許可する」オプションを無効にします。
詳細は「§4.2.5.3 匿名でのカレンダー共有を禁止する」をご参照
ください。
ランサムウェア用のトランスポート
ルールを構成する。
この制御は、Microsoft 365 E5 Security または Microsoft
365 E5 Full ライセンスを購入していない組織のみに適用され
ます。
Exchange Online のトランスポートルールを設定して、ランサム
ウェアがよく使用する添付ファイル付きの電子メールをブロック
します。
詳細は「§4.2.5.4 ランサムウェアの転送ルール」をご参照くださ
い。
23

29. セキュリティ制御 作業
テナントでのマルウェア対策を設定す
る。
この制御は、以下の組織にのみ適用されます。Microsoft 365
E5 Security または Microsoft 365 E5 Full ライセンスを購
入していない組織のみ適用されます
Exchange Online Protection を構成して、一般的な添付ファイ
ルの種類をブロックします。
詳細は「§4.2.5.5 テナントにおけるマルウェア対策」をご参照く
ださい。
外部からのメールフローを保護する。 Exchange Online で SPF、DKIM、DMARC を使用するように
設定することで、メールのなりすましを減らすことができます。
NCSC Mail Check サービスにサインアップしてください。
詳細は「§4.2.5.6 セキュリティで保護された外部メールのフロー」
をご参照ください。
Exchange Online で基本認証を無効に
する。
レガシー認証プロトコルをブロックする認証ポリシーを作成し、
すべてのユーザーに適用します。
詳細は「§4.2.5.10 Exchange Online でベーシック認証を無効に
する」をご参照ください。
Microsoft Teams の外部アクセス (フ
ェデレーション) の禁止
この制御は、Microsoft Teams を使用して他の組織とコラボ
レーションするリスクを許容できないと考える組織や、特定のド
メインとのコラボレーションをブロックしたい場合にのみ適用さ
れます。
Microsoft Teams Admin Center で、許可リストモデルを使用し
て外部アクセスを構成します。
詳細は「§4.2.6.1 外部からのアクセス (フェデレーション)」をご
参照ください。
24

30. セキュリティ制御 作業
SharePoint ユーザーが新規および SharePoint の外部共有を設定します。
既存のゲストを招待して共有できるよ
うにする。
詳細は「§4.2.7.1 外部との共有」をご参照ください。
サイトの分類。 SharePoint のサイト分類を有効にします。
詳細は「§4.2.7.6 サイトの分類を有効にする」をご参照ください。
共有 - デフォルトのリンクの種類。 SharePoint Online 管理センターの共有ポリシーで、
「これらの
リンクはこの日数以内に期限切れにすること」を設定します。
Microsoft Teams のゲストアクセス この制御は、Microsoft Teams を使用して他の組織とコラボ
レーションするリスクを容認できないと考える組織に適用されま
す。
Microsoft Teams の管理センターでゲストアクセスを許可しま
す。
Azure 外部コラボレーション設定を構成します。
・ゲストユーザーのアクセスは、自分のディレクトリオブジェク
トのプロパティとメンバーシップに制限されます（最も制限的で
す）
。
・特定の管理者ロールに割り当てられたユーザーのみがゲスト
ユーザーを招待できるようにする。
・指定したドメインにのみ招待を許可する（最も制限的な設定）
。
・許可されたドメインの一覧。
詳細は「§4.2.6.2 ゲストアクセスについて」をご参照ください。
共有 - デフォルトのリンクの種類。 SharePoint Online 管理センターの共有ポリシーで、
「これらの
リンクはこの日数以内に期限切れにすること」を設定します。
詳細は「§4.2.7.1 外部共有」をご参照ください。
25

31. セキュリティ制御 作業
共有 - ゲストは、共有の招待状を送信
したのと同じアカウントでサインイン
する必要があります。
有効にする ゲストは、共有の招待を送信するのと同じアカウント
でサインインする必要があります。
詳細は「§4.2.7.1 外部共有」をご参照ください。
共有 - ゲストが所有していないアイテ
ムの共有を許可しないようにする。
「ゲストが所有していないアイテムの共有を許可する」設定を無
効にします。
詳細は「§4.2.7.1 外部共有」をご参照ください。
SharePoint のカスタムスクリプトを
ブロックする。
SharePoint でカスタムのスクリプトを使用できないようにしま
す。
詳細は「§4.2.7.3 カスタムスクリプトをブロックする」をご参照
ください。
データ損失防止（DLP）を設定する。 お客様の組織で、特定の種類のデータが組織外に流出しない
ようにする必要がある場合 の場合、Office 365 Data Loss
Prevention の使用をご検討ください。
Microsoft 365 Compliance ポータルで、機密情報の種類を定義
し、DLP ポリシーを設定します。
詳細は「§4.2.3 データ損失防止（DLP）の設定」をご参照くださ
い。
26

32. セキュリティ制御 作業
Office 365 Cloud App Security を有
効にする。
この制御ルは、以下の組織にのみ適用されます。Microsoft 365
E5 Security または Microsoft 365 E5 Full ライセンスを購
入していない組織のみ適用されます。
Office 365 を Microsoft Cloud App Security サービスに接続し
ます。
Office 365 Cloud App Security を使用して、疑わしいユーザー
活動を調査します。
詳細は「§4.2.4 Office 365 Cloud App Security」をご参照くださ
い。
データアクセスに関するアプリケー
ションの同意。
ユーザーに代わってサードパーティアプリケーションがデータに
アクセスするためのすべてのリクエストは、管理者によって承認
されなければなりません。
詳細は「§4.2.6.5 アプリの許可ポリシー」をご参照ください。
4.1 アイデンティティ
今日の組織は通常、オンプレミスとクラウドでホストされたアプリケーションを混在して使用する必要があ
ります。 ユーザーは、オンプレミスとクラウドの両方で、これらのアプリケーションにアクセスする必要が
あります。オンプレミスとクラウドの両方でユーザーを管理することは、困難なシナリオを伴います。
マイクロソフトの Active Directory と Azure Active Directory サービスは、オンプレミスとクラウドベー
スの機能を兼ね備えています。 これらのソリューションは、場所を問わず、すべてのリソースに対する認証と
認可のために共通のユーザー ID を作成します。 これは、ハイブリッドアイデンティティと呼ばれています。
オンプレミスの Active Directory からアイデンティティを同期させることは、セキュリティ面だけでなく、
使いやすさにおいても利点があります。 アカウントの数が減れば、複数のディレクトリでパスワードが再利
用される可能性が低くなります。
Office 365 サブスクリプションのセキュリティ侵害は、情報の採取やフィッシング攻撃など、通常、オンプ
27

33. レミスの Active Directory アカウントの認証情報を侵害し、Azure AD の管理ロールを持つアカウントを制
御する技術を使用することで行われます。 特権アカウントを保護する方法に関する推奨事項については、上
記の 「§3 特権管理」を参照してください。
クラウドにおけるセキュリティは、お客様とマイクロソフトとのパートナーシップで成り立っています。
• マイクロソフトのクラウドサービスは、信頼とセキュリティの基盤の上に構築されています。 マイク
ロソフトのクラウドサービスは、お客様のデータとアプリケーションを保護するために、セキュリティ
コントロールと機能を提供します。
• お客様のデータとアイデンティティそれらを保護する責任、お客様のオンプレミスのリソースのセキュ
リティおよびお客様が管理するクラウドコンポーネントのセキュリティはお客様が所有するものです。
オンプレミスの侵害から Office 365 を保護するための詳細については「Protecting Microsoft 365 from
on-premises attacks」をご参照ください。
4.1.1 OAuth アプリの管理者同意の設定
アプリケーションを Microsoft ID プラットフォームと統合し、ユーザーが職場や学校のアカウントでサイ
ンインして組織のデータにアクセスできるようにすれば、リッチなデータ駆動型エクスペリエンスを提供する
ことができます。
アプリケーションが組織のデータにアクセスする前に、ユーザーはアプリケーションにアクセス許可を与え
る必要があります。 異なるパーミッションは、異なるレベルのアクセスを可能にします。 デフォルトでは、
管理者の同意が不要なアクセス権については、すべてのユーザーがアプリケーションに同意することが許可さ
れています。 例えば、デフォルトでは、ユーザーは自分のメールボックスへのアクセスをアプリケーション
に許可することに同意できますが、組織内のすべてのファイルへの読み取りと書き込みへの自由なアクセスを
アプリケーションに許可することに同意することはできません。
安全な組織のために、データへのアクセスのリクエストはすべて管理者によって承認される必要がありま
す。これは、
「ユーザーがアプリケーションに同意する方法を構成する」で説明する設定を使用して構成する
ことができます。
最適な構成は図 5 のとおりです。
28

34. 図 5: OAuth アプリの管理者同意のための最適な構成
4.1.2 認証方法
Azure AD ハイブリッド ID ソリューションを ID プラットフォームとする場合、認証はクラウドアクセ
スを保護するための基盤となります。 正しい認証方法を選択することは、Azure AD ハイブリッド ID ソ
リューションをセットアップする上で重要な決定となります。 選択した認証方法を実装するには、Azure AD
Connect を使用し、クラウド内の既存のユーザーをプロビジョニングします。
4.1.2.1 クラウド認証について
この認証方法を用いて、Azure AD はユーザーのサインインプロセスを処理します。 シームレスなシング
ルサインオン（SSO）と組み合わせることで、ユーザーは認証情報を再入力することなく、クラウドアプリ
ケーションにサインインすることができます。 クラウド認証では、2 つのオプションから選択することができ
ます。
29

35. • Azure AD のパスワードハッシュの同期
Azure AD でオンプレミスのディレクトリオブジェクトの認証を有効にする最もシンプルな方法です。
ユーザーは、追加のインフラストラクチャを展開することなく、オンプレミスで使用しているのと同じ
ユーザー名とパスワードを使用することができます。 Azure AD の一部のプレミアム機能（Identity
Protection など）では、どの認証方法を選択しても、パスワードハッシュの同期が必要です。Azure
AD では、パスワードが平文で保存されたり、可逆アルゴリズムで暗号化されたりすることはありませ
ん。 実際のパスワードハッシュ同期のプロセスについては、
「Azure AD Connect 同期を使用したパス
ワード ハッシュ同期の実装」をご参照ください。
• Azure AD パススルー認証
1 台または複数のオンプレミスサーバー上で動作するソフトウェアエージェントを使用して、Azure
AD 認証サービスの簡単なパスワード検証を提供します。 サーバーは、
お客様のオンプレミスの Active
Directory で直接ユーザーを検証するため、クラウド上でパスワードの検証が行われることはありませ
ん。 オンプレミスのユーザーアカウントの状態、パスワードポリシー、サインイン時間を即座に強制
する必要がある企業では、この認証方式を利用することが考えられます。 実際のパススルー認証プロ
セスの詳細については、
「Azure Active Directory パススルー認証によるユーザー サインイン」をご参
照ください。
4.1.2.2 フェデレーション認証について
この認証方法を選択すると、
Azure AD は、
オンプレミスの Active Directory Federation Services
（ADFS）
など、信頼できる別の認証システムに認証プロセスを引き渡し、ユーザーのパスワードを検証します。
Office 365 への認証方法として統合認証を無効にし、代わりに Password Hash Sync（PHS）を使用するこ
とが推奨されます。 これは、オンプレミスの AD ドメインサービスや ADFS のインフラが、脅威者に頻繁に
狙われ、侵害されているためで、特に SolarWinds の侵害など、
「侵害されたオンプレミス環境からの主要な
脅威ベクトル」としてよく知られた攻撃方法となっています。 また、ADFS や他のフェデレーション・サー
ビスの保守と可用性を考慮することも重要です。これは、Office 365 や他のクラウドサービスに接続する能力
に影響を与えるからです。
30

36. 詳細については「オンプレミスの攻撃から Microsoft 365 を保護する」をご参照ください。
4.1.2.3 意思決定のためのダイアグラム
図 6 に意思決定のダイアグラムを示します。組織に適したクラウド認証モデルを決定するのにお役立てく
ださい。
図 6: 認証を決めるための意思決定ダイアグラム
4.1.3 推奨される認証方法
Azure Active Directory は、広範な監視とセキュリティのインフラストラクチャの恩恵を受けています。世
界中のトラフィックを見渡す機械学習と人間のインテリジェンスを使用すると、攻撃を迅速に検出し、ほぼリ
アルタイムで再構成することができます。このことを考慮し、Azure AD パスワード ハッシュ同期を Office
365 サービスの認証方法として展開することをお勧めします。 Azure AD パスワード ハッシュ同期の詳細に
ついては、
「Azure AD Connect 同期によるパスワード ハッシュ同期の実装」を参照してください。
31

37. 4.1.4 条件付きアクセス
条件付きアクセスは、
、新しい ID 駆動型コントロール プレーンの中核をなすものです。 条件付きアクセス
はシグナルをまとめ、決定を下し、組織的なポリシーを実施するために使用される機能です。条件付きアクセ
スは、提供されたシグナルに基づいてアプリケーションへのアクセスを許可または拒否し、ユーザーがアクセ
スできるものについてアプリケーションがきめ細かな承認決定を下せるようにする、粒度の粗い承認エンジン
と考えてください。
図 7: 条件付アクセス決定ベースの権限付与
条件付きアクセスポリシーの最も単純なものは、ユーザーがリソースにアクセスしたい場合、あるアクショ
ンを完了しなければならない、という if-then (もし何なら何をする) ステートメントです。 例えば、給与計
算担当者が自分の Mac から電子メールにアクセスしたい場合 また、MacOS 用の Outlook クライアントや
Mac のネイティブメールクライアントではなく、Outlook Web Access のみを使用することができます。
条件付きアクセス ポリシーを使用することで、必要なときに適切なアクセス制御を適用して組織の安全を
確保し、不要なときにユーザーの邪魔にならないようにすることができます。
重要
条件付きアクセスポリシーは 1 要素認証が完了した後に適用されます。 条件付きアクセスは、サービ
ス妨害（DoS）攻撃などのシナリオに対する組織の最初の防御線として意図されていませんが、これら
のイベントからのシグナルを使用してアクセスを判断できます。
32

38. 図 8: 条件付きアクセスの構成要素とフロー
4.1.4.1 すべてのユーザーに対して Azure AD MFA を有効化する
多要素認証 (MFA) は、条件付きアクセス サインイン イベント中に、追加の形式の ID を求めるプロンプ
トがユーザーに求められるプロセスです。
Azure AD の多要素認証は、次の認証方法を 2 つ以上要求することによって機能します。
• あなたが知っているもの 通常はパスワード。
• あなたが持っているもの 例えば電話やハードウェアキーのような、簡単に複製できない信頼できるデ
バイス。
• 指紋や顔スキャンなどの生体認 証第二の認証手段を必要とする場合、この追加要素は攻撃者が簡単に
入手したり、複製したりすることができないため、セキュリティが強化されます。
Azure AD MFA for all を有効にすると、ユーザーは Azure AD MFA サービスに登録し、必要に応じて追
加の認証形式を要求するために条件付きアクセスによって呼び出すことができる詳細を提供することが要求さ
れるようになります。 現在、Azure AD MFA のユーザーごとの登録を使用している組織では、CA ベースの
登録アプローチに切り替えることが推奨されます。
詳細については「動作のしくみ: Azure AD Multi-Factor Authentication」をご参照ください。
33

39. 備考
Azure AD MFA の登録は、Azure AD Self-Service Password reset と組み合わされるようになりまし
た。詳細は「Azure Active Directory での統合されたセキュリティ情報の登録の概要」をご参照くださ
い。
4.1.4.2 管理対象/準拠デバイスへのアクセスの制御
管理対象デバイスとは、組織的な管理方法が適用されているデバイスのことです。 このコントロールは、
GPO または SCCM ポリシーを使用した Hybrid AD に参加したデバイス、またはコンプライアンスステー
タスを提供する MDM 登録されたデバイスになります。
Office 365 へのアクセスは、管理されたデバイスのみに許可することを推奨します。このシナリオで条件付
きアクセスを構成する方法の詳細については、
「管理対象デバイスの必要性」をご参照ください。
Microsoft Intune Endpoint Management サービスだけでなく、少数のサードパーティー MDM サービス
でもデバイスコンプライアンスを報告できます。詳細については、
「Microsoft Intune のデバイスコンプライ
アンスパートナー」を参照してください。
管理されていないデバイスによる Office 365 サービスへのアクセスを許可する必要がある場合は、
「BYOD
ポリシーで安全なリモートワークを実現する方法」ガイダンスをご参照ください。
4.1.4.3 レガシーな認証方式をブロックする
多要素認証を有効にするには、ユーザ名とパスワードのみを使用するレガシー認証もブロックする必要があ
ります。 POP、SMTP、IMAP、MAPI などのレガシー認証プロトコルは MFA を実施できないため、敵対
者がパスワードスプレー攻撃や同様の攻撃を行う際の入口になってしまうからです。NCSC は、ブログポスト
に「Defending against password spraying attacks（パスワードスプレー攻撃に対する防御）」を公開してい
ます。
条件付きアクセスは、レガシー認証のクライアントにのみ適用されるポリシーを設定し、ブロックするアク
ションを取ることで、組織全体にわたってレガシー認証をブロックする最も簡単な方法です。
34

40. 詳細は「条件付きアクセスで Azure AD へのレガシ認証アクセスをブロックする」をご参照ください。
レガシー認証のブロックは推奨される方法ですが、ワークロードによっては、レガシー認証の使用をブロッ
クできるまで、レガシー認証を使用する必要がある場合があります。 レガシー認証を使用しているユーザー
やアプリケーションを特定する方法と、レガシー認証を使用しないようにする方法の詳細については、レガ
シー認証のブロックを参照してください。 条件付きアクセスポリシーは、ユーザーのグループを対象とする
ことができるため、可能であれば、これらのユーザーに対して条件付きアクセスを使用してレガシー認証のブ
ロックを実施し、レガシー認証プロトコルを必要としないユーザーが特定されたら、条件付きアクセスポリ
シーにそれらを追加することを忘れないでください。
重要
1 つまたは 2 つのデバイス/ユーザーがレガシー認証 (SMTP) を使用する必要があるからといって、残
りのユーザーを条件付きアクセスで保護できないわけではありません。
4.1.5 アカウントポリシー
4.1.5.1 パスワードの有効期限を設定しない
パスワードの有効期限に関するポリシーは、ユーザーを互いに密接に関連する連続した単語や数字で構成さ
れた非常に予測可能なパスワードに誘導するため、良いことよりも害を及ぼすケースが多いです（つまり、次
のパスワードは前のパスワードに基づいて予測することができるのです）
。パスワードの変更は、サイバー犯
罪者がクレデンシャルを侵害するとすぐに使用するため、封じ込める効果はありません。
NCSC は、組織の安全性を維持するための「パスワード戦略に関するガイダンス」を発行しています。
パスワードポリシーの詳細については、以下の記事「組織のパスワード有効期限ポリシーを設定する」や
「Microsoft Password Guidance」を参照してください。
パスワードへの依存を減らすために、パスワードレスアプローチに移行することを検討してください。
35

41. 4.1.5.2 過去 30 日間に使用されていないアカウントを無効にする
従業員が退職する際、ユーザーアカウントが削除されるとは限りません。 セキュリティ上の脅威となるた
め、組織はこれらの古いユーザーアカウントを検出し、無効化する必要があります。
Azure AD にログオンしていないユーザーアカウントを検出するには、Microsoft Graph API を使用して
検出できます。クエリーの詳細については「Azure AD で非アクティブなユーザーアカウントを管理する方
法」をご参照ください。
非稼働アカウントを特定できたらその有効性を確認し、可能であれば適切な方法で無効化すべきです。
4.2 Microsoft 365 サービスの構成
4.2.1 Microsoft 365 の監査ログの取得
監査ログは、Microsoft 365 エンタープライズ組織では既定で有効になっています。 コンプライアンスセン
ターの監査ログ検索をオンにすると、組織のユーザーと管理者の活動が監査ログに記録され、ユーザーに割り
当てられたライセンスに応じて 90 日間、最大で 1 年間保持されます。
詳細は「監査ログ検索のオンとオフを切り替える」をご参照ください。
4.2.2 セキュリティスコアーのレビュー
セキュア・スコアを定期的に見直すことで、企業はセキュリティ態勢の変化を監視し、新しい対策が利用可
能になったときに再評価を行うことができます。
Microsoft セキュリティ スコアは、組織のセキュリティ姿勢を測定するもので、数値が高いほど、より多く
の改善措置がとられていることを示します。詳細は、
「Microsoft セキュリティー スコア」をご確認ください。
• 組織のセキュリティ体制の現在の状態を報告する。
• 検出可能性、可視性、ガイダンス、および制御を提供することにより、セキュリティ体制を改善します。
• このガイダンスで説明されているセキュリティ対策の多くは、セキュリティ スコアに含まれています。
しかし、構成制御を行わない場合のリスクを理解することは不可欠であり、単に「数字によるセキュリ
ティ」の演習を行うだけでは、Microsoft 365 の実装を安全にするために必要な重要な要素に対処でき
36

42. ないため、セキュリティガイダンスの唯一の情報源として セキュリティ スコア に頼ることはお勧めで
きません。
4.2.3 データ損失防止（DLP）の設定
Microsoft 365 のデータ損失防止 (DLP) ポリシーは、Exchange、SharePoint、OneDrive、Teams におけ
る外部および内部での共有アクティビティを監査するためのルールのパッケージです。 DLP ポリシーは、
誤って機密情報を共有してしまったり、共有してはいけない情報であることをユーザーが認識していない場合
などに、偶発的な共有を防止することができます。
DLP は、定義済みまたはカスタムの「機密情報タイプ（SIT）
」を使用して、組織にとってプライベートと
見なされる情報を定義し識別します。 SIT は DLP ポリシーの基礎として使用され、望ましくない量の機密
コンテンツを共有しようとした場合、監査、通知、ブロックなどのアクションが適用され、オプションでユー
ザーが理由を付けて上書きすることもできます。
特定の機密情報タイプが組織から外部に出るのを防ぐ必要がある組織は、そのデータ タイプに対して DLP
を構成することをお勧めします。
設定に関する詳細については、
「Exchange Online でのデータ損失防止」を、定義済みの機密情報タイプに
関する情報については、
「機密情報の種類のエンティティ定義」をご参照ください。
4.2.4 Office 365 Cloud App Security
Microsoft Defender for Cloud Apps は、シャドー IT を発見し、Office 365 全体で脅威保護を提供し、ど
のアプリがデータにアクセスする許可を持つかを制御することができます。
Office 365 Cloud App Security は、 Microsoft Defender for Cloud Apps サービスで提供される機能のサ
ブセットであり、そのため共通の管理ポータルを使用してアクセスおよび設定できます。
詳細は「Office 365 を Microsoft Defender for Cloud Apps に接続する」をご参照ください。
Microsoft Defender for Cloud Apps に Office 365 を接続するとユーザーの行動を調査し、ポリシーを適
用して Office 365 でのユーザーの行動を制御することができます。詳細については「チュートリアル: 危険性
の高いユーザーを調査する」をご参照ください。
詳細については「Microsoft Defender for Cloud Apps の概要」
、
「Microsoft Defender for Cloud Apps と
37

43. Office 365 Cloud App Security の違いは何ですか」をご参照ください。
4.2.5 Exchange online
4.2.5.1 メールボックスの監査
2019 年 1 月より、すべての組織でメールボックス監査ロギングがデフォルトで有効になりました。 これに
より、メールボックスの所有者、委任者、管理者が行った特定の操作が自動的に記録され、メールボックス監
査ログで検索すると、対応するメールボックス監査記録が表示されるようになります。
すべてのメールボックスでメールボックス監査がオンになっていることを確認し、監査されたアクションの
リストを表示するには、
「既定によるメールボックス監査の有効化がオンになっていることを確認する」を参
照してください。
デフォルトでは、Office 365 E5 ユーザーのイベントのみが、Security Compliance Center または Office
365 Management Activity API 経由の監査ログの検索が可能です。
Office 365 E3 のライセンスを持つメールボックスは、Security Compliance Center または Office 365
Management Activity API 経由で監査ログの検索を手動で有効にするか、別の検索方法を使用することがで
きます。有効化の詳細については、
「メールボックスの監査の More information」をご参照ください。
4.2.5.2 個人用メールへのメール転送を禁止する
クライアント作成のルール (ユーザーのメールボックスから外部の電子メール アドレスに電子メールを自
動転送する) は、今日の脅威アクターによって使用されるデータ流出方法としてますます一般的になっていま
す。 この制御は、予期しないデータ損失につながる可能性のある外部電子メールアドレスへの自動転送ルー
ルをユーザーが構成できないようにする場合にも関連します。
Exchange 管理センターのメールフローレポートには、あなたの組織から外部ドメインの受信者に自動的に
転送されるメッセージの情報を表示する、自動転送メッセージレポートがあります。このレポートは、メール
ボックス転送の事例を探すために使用できます。レポートの詳細については、
「新しい EAC の自動転送メッ
セージレポート」をご参照ください。
外部電子メールの転送制御は、Exchange Online Protection（EOP）のアンチスパム設定を使用して、自
動転送をオフ - 転送が無効になるように設定する送信スパムフィルターポリシーを作成することをお勧めし
38

44. ます。
外部転送の設定方法の詳細については「Microsoft 365 で外部メールの自動転送を制御する」をご参照くだ
さい。
4.2.5.3 匿名でのカレンダー共有を禁止する
匿名の予定表の共有は、テナントで無効にする必要があります。この機能により、ユーザーは自分のカレン
ダーの全詳細を外部の認証されていないユーザーと共有できます。 攻撃者は、攻撃を開始する前に、お客様
の組織について学習する（偵察する）ことに時間をかけるのが一般的です。 公開されたカレンダーは、攻撃
者が組織の関係を理解し、特定のユーザーが出張中であるなど、攻撃を受けやすいタイミングを判断するため
に役立ちます。
詳細については「Office 365 管理センターを使用して予定表の共有を有効にする」をご参照ください。
4.2.5.4 ランサムウェア対策のための転送ルール
Microsoft Defender for Office 365 を購入していない、または使用する権利がない組織には、この制
御を推奨します。 Microsoft Defender for Office 365 を使用している場合、この制御を実施する必要はあり
ません。
Exchange Online のメールフロールールを使って、ランサムウェアによく使われる添付ファイル付きのメー
ルをブロックすることができます。
一般的な実行可能ファイルの拡張子は次のとおりです。: ade, adp, ani, bas, bat, chm, cmd, com,
cpl, crt, hlp, ht, hta, inf, ins, isp, job, js, jse, lnk, mda, mdb, mde, mdz, msc, msi, msp,
mst, pcd, reg, scr, sct, shs, url, vb, vbe, vbs, wsc, wsf, wsh, exe, pif
マクロを含む Office ファイルの拡張子は次のとおりです。：doc, xls, docm, xlsm, pptm
以下のルールを実装する前に、ファイルタイプのリストを確認し、リストにあるファイルタイプのいずれか
が許可される有効なビジネス上の理由がないことを確認することが重要です。 個人またはビジネスユニット
が、一般的なランサムウェアの種類のリストにあるファイルを受信する正当なビジネス上の理由がある場合、
より詳細なルールを作成して、これらのユーザーがこれらのファイルを受信することを許可し、組織全体が危
険にさらされるのを防ぐことができるようにします。
39

45. Exchange Online では、複数のメールフロールールを作成および管理することができます。例えば、実行
ファイルをブロックするための個別のルールを作成し、マクロを含む Office 文書についてユーザーに警告す
るための別のルールを作成することができます。
詳細については「EAC を使用してメール フロー ルールを作成する」をご参照ください。
4.2.5.5 テナントにおけるマルウェア対策
Microsoft Defender for Office 365 を購入していない、または使用する権利がない組織には、この制
御を推奨します。 Microsoft Defender for Office 365 を使用している場合、この制御を実施する必要はあり
ません。
Office 365 のマルウェア対策は、Exchange Online Protection によって提供され、デフォルトでオンに
なっています。
デフォルトのポリシーを編集し、Common Attachment Filter をオンに設定することをお勧めします。
ポリシーの編集方法の詳細については「EOP のマルウェア対策ポリシーを構成する」をご参照ください。
4.2.5.6 セキュリティで保護された外部メールのフロー
以下のセクションでは、
Sender Policy Framework、
DomainKeys Identified Mail、
Domain-based Message
Authentication, Reporting, and Conformance を使用した電子メールフローの安全性に関する推奨設定につ
いて説明します。
NCSC は、アンチスプーフィングを含む電子メールの設定に関するガイダンスを
https://www.ncsc.gov.uk/collection/email-security-and-anti-spoofing で提供しています。
Mail Transfer Agent Strict Transport Security (MTA-STS) は、あなたの組織にメールを送信するサービ
スに、あなたのドメインが TLS (Transport Layer Security) 1.2 以上に対応していることを知らせるための
プロトコルです。詳細については「Using the Mail Transfer Agent Strict Transport Security (MTA-STS)
protocol in your organisation」をご参照ください。
組織間の TLS の強制に関する政府のガイダンスの更新版はこちらです。
https://www.gov.uk/guidance/securing-government-email
これは MTA-STS が利用できるようになるまで必要です。組織間の TLS を設定する方法の詳細については
40

46. 「パートナー組織とのセキュアなメールフローを実現するコネクターの設定」をご参照ください。
NCSC は、電子メールセキュリティのコンプライアンスを評価するための「Mail Check Service」を
https://www.ncsc.gov.uk/information/mailcheck で提供しています。
4.2.5.7 Office 365 カスタムドメインのスプーフィングを防止する Sender Policy
Framework の設定
メールにカスタムドメイン (contoso.com など) を使用する場合、Office 365 では、なりすましを防ぐため
に、送信者ポリシー フレームワーク (SPF) TXT レコードを DNS レコードに追加する必要があります。
SPF は、
ユーザーに代わってメールを送信できるメール サーバーを識別します。 SPF を DKIM、
DMARC、
および Office 365 でサポートされているその他のテクノロジと組み合わせて使用するとなりすましやフィッ
シングの防止に役立ちます。
SPF は、DNS で使用される TXT レコードとして追加され、どのメールサーバーがカスタムドメインの代
理としてメールを送信できるかを識別します。 受信側のメールシステムは、SPF TXT レコードを参照して、
カスタムドメインからのメッセージが承認されたメッセージングサーバーから送信されたものかどうかを判断
します。詳細については「SPF を設定して、スプーフィングを防止する」をご参照ください。
4.2.5.8 Office 365 カスタムドメインの DKIM を設定する
SPF に加えて、組織は Office 365 で DomainKeys Identified Mail (DKIM) を使用して、カスタム ドメ
インから送信されたメッセージを送信先のメール システムが信頼できるようにすることも推奨されます。
ドメインの DKIM の設定方法については「DKIM を使用して、カスタム ドメインから送信される送信電
子メールを検証する」をご参照ください。
4.2.5.9 Office 365 でメールを検証する DMARC を設定する
DMARC（Domain-based Message Authentication, Reporting, and Conformance） は、Sender Policy
Framework（SPF）および DomainKeys Identified Mail（DKIM）と連携し、メールの送信者を認証して、
送信先のメールシステムがお客様のドメインから送信されたメッセージを確実に信頼できるようにするもので
す。 DMARC を SPF と DKIM とともに実装することで、なりすましやフィッシングメールに対するさら
41

47. なる保護が可能になります。 DMARC は、SPF または DKIM のチェックに失敗したお客様のドメインから
送信されたメッセージの処理方法を、受信側のメールシステムが決定するのを支援します。
DMARC を設定するには「DMARC を使用してメールを検証する」をご参照ください。
4.2.5.10 Exchange Online でベーシック認証を無効にする
「§4.1.4.3 レガシー認証のブロックする」で述べたように、条件付きアクセスでレガシー認証を無効にする
ことが強く推奨されます。
レガシー認証は、ユーザーに認証ポリシーを割り当てることによって Exchange Online サービスレベルで
無効化することもできることに留意してください。 ポリシーでは、ベーシック認証がブロックされるクライ
アントプロトコルを定義し、ポリシーをすべてのユーザーに割り当てることで、指定されたプロトコルに対す
るベーシック認証の要求をブロックします。
組織は、
「認証ポリシーを作成する」の手順を使用して、認証ポリシーを作成することをお勧めします。デ
フォルトでは、オプションなしで認証ポリシーを作成すると、すべての基本認証方式がブロックされます。認
証ポリシーを作成したら、
「認証ポリシーをユーザーに割り当てる」の手順で、すべてのユーザーに割り当て
る必要があります。
認証ポリシーの詳細については「Exchange Online で基本認証を無効にする」をご参照ください。
4.2.6 Microsoft Teams
以下の制御は、Microsoft Teams 固有のものです。
4.2.6.1 外部からのアクセス（フェデレーション）
Microsoft Teams のデフォルトでは、Teams ユーザーはすべての外部組織の Teams ユーザーと通信する
ことができます。Microsoft Teams では、管理者が Teams を使用している他の外部組織との通信を、許可リ
ストまたはブロックリストモデルで制御できます。
ブロックリストモデルを選択した場合、ブロックリストに追加された組織以外のすべての外部 Teams 組織
と通信することが可能になります。
組織が「許可リスト」モデルを選択した場合、許可リストに追加されたチーム組織とのみ通信が可能になり
42

48. ます。
ほとんどの組織では、この外部からの通信は許容される状態であり、望ましくないドメインが見つかった場
合にのみ、そのドメインからの通信を阻止するためにブロックリストに追加することができます。
しかし、組織では、特に許可された外部ドメインのみに通信を制限したり、個々のドメインの通信をブロッ
クしたりすることができます。この場合、組織は許可リストモデルを使用して、リストされたドメインのみに
通信を制限する必要があります。
Microsoft Teams 管理センターで、許可リストモデルを使用して外部アクセスを設定することをお勧めし
ます。
Microsoft Teams の外部アクセスの設定については「Microsoft Teams で外部の会議とチャットを管理す
る」をご参照ください。
4.2.6.2 ゲストアクセスについて
Teams のゲストアクセスは、組織のメンバーではない人が、Teams プラットフォームの一部である特定の
チーム、ドキュメント、チャンネル、リソース、チャット、アプリケーションにアクセスすることを可能にし
ます。
Microsoft Teams では、デフォルトで Guest ユーザーを許可しています。
Teams のゲストアクセスを許可すると、データ損失のリスクが高まるように見えますが、ゲストユーザー
はサービスの正規ユーザーと同じ監査とコンプライアンスの保護下で操作されます。
組織では、ゲストアカウントの使用を許可することが推奨されます。ゲストアカウントは、自分自身のディ
レクトリオブジェクトのパーミッションとメンバーシップに制限されるべきです。ゲスト招待は、特定の管理
者ロールからのみ送信されます。
Teams のゲストアクセス設定を変更する方法の詳細については「Teams のゲスト アクセスの設定」をご参
照ください。
Teams のゲストアクセスの詳細については「Microsoft Teams でのゲスト アクセス」をご参照ください。
組織は Guest アクセスを管理するより堅牢なアプローチを提供するために、Azure AD エンタイトルメン
ト管理に精通し、実装することによって、全体的なアイデンティティガバナンス能力を強化することが強く推
奨されます。エンタイトルメント管理では、組織は、指定した他の組織のユーザーがアクセスパッケージを自
43

49. 己要求できるようにするポリシーを定義することができます。アクセスパッケージは、承認が必要かどうか、
およびアクセスの有効期限を指定します。詳細は「Azure AD のエンタイトルメント管理で外部ユーザーのア
クセスを管理する」をご参照ください。
4.2.6.3 ミーティングポリシーについて
ゲストによる会議での制御を制限するために、グローバルな会議ポリシーに次の変更を加えることをお勧め
します。詳細は「Teams での会議ポリシーを管理する」をご参照ください。
1.「匿名の人に会議を開始させる」を無効にする。これにより、参加者はプレゼンターが入場するまでロ
ビーに配置されます。
2.「会議の司会者権限を持つロール」を「組織内の全員、ただしユーザーはオーバーライドできる」に変
更します。これにより、会議中に明示的にプレゼンターの権利が与えられない限り、ゲストが参加者を
ミュートする機能やその他のインタラクティブな機能を持つことができなくなります。
3.「会議の司会者権限を持つロール」を「組織内の全員、ただしユーザーはオーバーライドできる」に変
更します。これにより、会議中に明示的にプレゼンターの権利が与えられない限り、ゲストが参加者を
ミュートする機能やその他のインタラクティブな機能を持つことができなくなります。
4.2.6.4 無許可のクラウドファイルストレージを制御する
Teams の「ファイル」タブで、許可されていないファイル共有やクラウドファイルストレージの使用を防
ぐために、組織で承認されていないサードパーティのクラウドストレージプロバイダーへのアクセスをブロッ
クすることをお勧めします。 これは、組織全体の設定の［ファイル］セクションで設定されます。詳しくは
「Teams の管理と監視」をご参照ください。
4.2.6.5 アプリの許可ポリシー
組織では、アプリ許可ポリシーを使用して、組織内の Microsoft Teams ユーザーが利用できるアプリを制
御できます。
サードパーティアプリの使用は、許可リストで管理することをお勧めします。 組織は、許可するサードパー
44