Microsoft セキュリティ、これをやってください！～実践ベストプラクティス

Posted at 2026-10-10

はじめに

2026年9月下旬以降、国内でもサイバー攻撃による被害が相次いで報道されています。

その侵入経路は、ネットワーク機器の脆弱性を突くものや、フィッシングメールなど、さまざまです。
また今後は、利用者自身だけでなく、AI エージェントが外部のコンテンツやサービスへアクセスすることによって生じる、新たな攻撃経路についても考慮する必要があります。

セキュリティ対策は、一度構築したら終わりではありません。
攻撃手法やサービスの変化に合わせて、継続的に見直し、アップデートしていく必要があります。

私自身も、昨年からパスキーやゼロトラストに関する検証・発信を続けながら、自分の環境にも取り入れてきました。

これまで勉強会で使用してきた教材やブログなどもありますので、この機会に、それらを整理しながら、今から取り組んでおきたいセキュリティ対策を順を追って紹介していきたいと思います。

本記事で紹介する内容は、私自身が実際に検証し、運用面まで考慮して取り入れてきたものです。

この記事が、皆さまの組織や個人の情報資産を守るために、今一度セキュリティ対策を見直すきっかけになれば幸いです。

お知らせ
2026/9/26 に、パスキー、ブレイクグラス、PIM までを実際に導入する勉強会を開催しました。

この勉強会で使用したテキストは、参加者限定で提供しています。

今後、同様の勉強会を開催することも検討しています。
ご興味がありましたら、ご相談ください。

Microsoft Entra ID を触って学ぶセキュリティ実践ハンズオン in Tokyo
https://yonayona.connpass.com/event/396158/

自己紹介

私のことをご存じ無い方は、以下のスライドを参照してみてください。
既に知っている人、個人には興味が無い人は、次の章へ SKIP！

Azure Travelers in 広島の旅：計画したわけじゃない。振り返ると一本の道だった by @carol0226

セキュリティに関する 2025年度の活動内容を以下にまとめてあります。

FY25 Microsoft Security に関する登壇・技術発信まとめ
https://qiita.com/carol0226/items/a1297091c0635f86d1ca

本記事の概要

まずは、フィッシング耐性のある認証としてパスキーの導入から始めることを推奨しています。
そのうえで、アクセス制御、特権管理、メール、ネットワーク、検知・対応へと、セキュリティ対策を一つずつ積み重ねていけるように私が推奨する順番に案内しています。

1．フィッシング耐性のある認証（Passkey）
2．アクセス制御（Conditional Access）
3．緊急アクセス（Break Glass）
4．最小特権（PIM）
5．認証フローの保護（Device Code Flow）
6．メール・コラボレーションの保護（Safe Links / Safe Attachments）
7．ネットワークのZero Trust化（Global Secure Access）
8．検知・調査・対応 (Microsoft Defender)

上記に挙げた中で、１章の Passkey については、組織の管理者のみならず、個人の方にも推奨しています。
あらゆる認証を、パスワードを使わない方式（パスワードレス）へ移行し、セキュリティを高めてください。

その他の章は、主に組織の管理者向けの内容になっていますが、そうでなくても、セキュリティ知識を深められる内容になっています。セキュリティ初学者の方も、本記事を参考に、検証用の Microsoft Entra 環境を使って学んでいただければと思います。

1. フィッシング耐性のある認証（Passkey）

まず最初に取り組みたいのが、認証そのものをフィッシングに強くすることです。

パスワードや SMS、ワンタイムパスコードなどは、利用者を偽のサインイン画面へ誘導し、認証情報を入力させるフィッシング攻撃の対象になる可能性があります。

そこで利用したいのが、パスキーです。

パスキーは FIDO 標準に基づき、公開鍵暗号を利用して認証します。認証情報は登録した Web サイトやアプリに結び付けられるため、偽のサイトへ認証情報を渡してしまう従来型のフィッシング攻撃に対して強いという特徴があります。

Microsoft Entra ID でも、パスキー（FIDO2）は「フィッシングに強い認証」として位置付けられており、FIDO2 セキュリティキーは「フィッシング耐性 MFA 強度」を満たす認証方法の一つです。

そのため本記事では、セキュリティ対策の最初のステップとして、まずパスキーの導入から始めます。

一方で、「パスキーは強い」という話はよく聞くものの、実際に導入しようとすると、

まず何を用意すればよいのか
どのアカウントからパスキーへ移行すればよいのか
デバイスバインドパスキーと同期パスキーをどう使い分ければよいのか
パスキーに対応していないサービスはどうすればよいのか

...といった、実際の導入・移行方法で悩むことがあります。

本章では、私自身が企業へのパスキー導入支援を行ってきた経験や、Microsoft のイベントなどで登壇しながら最新情報を追ってきた経験をもとに、私がお勧めするパスキーの導入方法を順番に紹介していきます。 ``

1-1. FIDO2 セキュリティキー（物理パスキー）を手配する

FIDO2 に準拠したセキュリティキーを入手してください。
一番無難（おすすめ）なのは、YubiKey です。その他のメーカーの FIDO2 セキュリティキーでも構いませんが、製品によって対応する接続方式や機能などが異なります。どれを選べばよいか迷う場合、初めて導入するのであれば、私は YubiKey をお勧めします。

YubiKey のタイプもさまざまありますが、以下の私の記事を参考に、どのキーにするのかを決めてください。

私のイチオシは、YubiKey Bio（指紋認証タイプ）です。

YubiKey には指でタッチする箇所がありますが、通常の YubiKey のタッチ部分は指紋センサーではありません。 FIDO2 のユーザー確認には PIN を使用します。

一方、YubiKey Bio は指紋センサーを搭載しており、指紋によるユーザー確認ができます。

Yubikey まとめ（利用可否検証あり）
https://qiita.com/carol0226/items/1e28bdc3acc4c7814da2

Apple Account で物理セキュリティキーによる保護を有効にする場合
FIDO セキュリティキーが２本必要です。
YubiKey Bio は高額なので、 YubiKey Bio x 1本、 YubiKey 5C x 1本のような組み合わせがコストバランスが良いと思います。

Apple Account 以外についても各サービスの要件を確認し、まずは少なくとも1本、物理パスキーを用意しておくことをお勧めします。

デバイスバインドパスキー (Device-bound）と同期パスキー (Synced）の違いについては、以下の私の記事を参照してください。

パスキー認証の現在地－Microsoft Ignite 2025 解説
https://qiita.com/carol0226/items/bbd4db426d1145684550

1-2. ４つの優先順位でパスキーを導入していく

続いて、パスキーの導入戦略について ①～④ の考え方を示しています。

① 認証の大元は、デバイスバインドパスキーにする
② Windows OS や Microsoft サービスをパスワードレスにする
③ SaaS サービスもパスキーにする
④ パスキー非対応なサービスの対処方法

① 認証の大元は、デバイスバインドパスキーにする

認証の要となる Microsoft Entra ID、Microsoft アカウント、Apple Account、Google Account については、本記事では FIDO2 セキュリティキーによる保護をお勧めします。

同期パスキーもフィッシング耐性を持つ強力な認証方法ですが、認証基盤となるアカウントについては、同期パスキーだけに依存せず、FIDO2 セキュリティキーなどのデバイスバインドパスキーも用意しておく、というのが本記事での考え方です。

ポイント
同期パスキーもフィッシング耐性を持つ強力な認証方法です。

一方で、認証基盤となるアカウントについては、端末間で同期される認証情報だけに依存せず、FIDO2 セキュリティキーなどのデバイスバインドされた認証手段も用意しておくことをお勧めします。

特に Apple Account や Google Account は、同期パスキーを管理する基盤として利用することもあります。

そこで本記事では、こうした「認証の大元」となるアカウント自体を FIDO2 セキュリティキーで強固に保護しておき、その上で同期パスキーの利便性も活用していく、という考え方を取ります。

以下の SBI証券の記事でも、Apple や Google のアカウントを保護する重要性について注意喚起されています。

SBI 証券：GoogleやApple等のアカウント情報を窃取するフィッシング詐欺にご注意ください
https://site1.sbisec.co.jp/ETGate/?_ControlID=WPLETmgR001Control&_PageID=WPLETmgR001Mdtl30&_ActionID=DefaultAID&_DataStoreID=DSWPLETmgR001Control&OutSide=on&getFlg=on&burl=search_home&cat1=home&cat2=info&dir=info&file=home_info261002_phishing.html

各認証基盤の保護方法

Microsoft Entra ID をパスキーで保護
https://qiita.com/carol0226/items/8586291079d941f62f7b
Microsoft Account をパスキーで保護
https://support.microsoft.com/ja-jp/security/sign-in-to-your-account-with-a-security-key?wt.mc_id=MVP_407731
Apple Account をセキュリティキーで保護
https://support.apple.com/ja-jp/guide/iphone/iph5acc5b28c/ios
※ Apple Account のセキュリティキーは、パスワードを置き換えるものではなく、2ファクタ認証を強化するために利用します。
Google Account をパスキーで保護
https://www.google.com/account/about/passkeys/

まとめ：① 認証の大元は、デバイスバインドパスキーにする
同期パスキーの便利さは活用しつつ、その大元となるアカウントは FIDO2 セキュリティキーでもしっかり保護しておきましょう。

まず「大元」をしっかり守ってから、同期パスキーを便利に使っていく、という考え方です。

② Windows OS や Microsoft サービスをパスワードレスにする

認証の大元をしっかり保護したら、次は普段利用する Windows OS や Microsoft サービスもパスキー化していきましょう。

Windows の構成によって利用できる方法が異なりますが、この図の組み合わせで認証をパスキー化できます。

ポイント
パスキーを導入しただけでは、従来のパスワード認証が残っている場合があります。

せっかくパスキーを導入するのであれば、弱い認証方法に戻れないようにすることも考えていきましょう。つまり、「パスキーを追加する」だけではなく、完全パスワードレスを目指します。

Windows へのサインインも、構成に応じてパスワードレス化できます。

非ドメイン構成の場合（個人など）
前章でパスキー化した Microsoft アカウントを使い、Windows Hello でパスワードレス化しましょう。
Microsoft Support: Go passwordless in Windows
https://support.microsoft.com/en-us/windows/security/go-passwordless-in-windows?wt.mc_id=MVP_407731
　
Active Directory ドメイン環境の場合
以下の私の記事を参照してください。
オンプレドメインの初回ログオンから完全パスワードレスの運用 (物理 PC 対応版)
https://qiita.com/carol0226/items/bb985634fde0a5445310

参考
「非ドメイン・個人・Active Directory」など、Entra ID と連携していない Windows デバイスの場合でも、以下の方法で Entra ID の認証をパスキー相当にすることが可能です。

Windows デバイスを Entra のパスキーにする方法
https://qiita.com/carol0226/items/394d6a795be116853771

Microsoft Entra Join 環境の場合
以下の私の記事を参照してください。
FIDO2 セキュリティキーで Windows にサインインする（Entra Join 編）
https://qiita.com/carol0226/items/3933199bfd512e31f060

なお、Microsoft Entra Join 環境では、Web Sign-in を利用するという方法もあります。

Web Sign-in を利用すると、Web ベースの認証方法を Windows のサインインにも利用できます。たとえば、Microsoft Authenticator を利用したパスワードレスサインインにも対応しています。

※ Web Sign-in には Windows のバージョン、Microsoft Entra Join、インターネット接続などの要件があります。また、Microsoft Entra hybrid join / Active Directory ドメインでは利用できません。詳細は以下の公開情報を確認してください。

公開情報：Windows の Web サインイン
https://learn.microsoft.com/ja-jp/windows/security/identity-protection/web-sign-in?wt.mc_id=MVP_407731

まとめ：② Windows OS や Microsoft サービスをパスワードレスにする
パスキーを追加するだけで終わらず、できるところからパスワードを使わない環境にしていきましょう。

せっかくパスキーを導入するのであれば、完全パスワードレスを目指す、というのが私のお勧めです。

③ SaaS サービスもパスキーにする

Microsoft のサービスをパスキー化したら、次は普段利用している SaaS サービスもパスキーにしていきましょう。

パスキーに対応するサービスも増えてきています。普段利用しているサービスがパスキーに対応しているのであれば、できるところからパスキーに切り替えていくことをお勧めします。

注意
Microsoft Authenticator のパスキーは、Microsoft Entra ID の認証で利用するためのものです。

Microsoft Authenticator を、一般的な SaaS サービスのパスキーを保存する「汎用的なパスキープロバイダー」として利用できるわけではないので注意してください。

SaaS サービスをパスキー化する場合は、そのサービスがどのパスキープロバイダーに対応しているのかを事前に確認しておきましょう。

パスキーは、利用するサービスだけでなく、どの認証器（パスキープロバイダー）にパスキーを保存するのかによっても使い勝手が変わります。

以下の私の記事では、「認証器 × デバイス × サービス」のさまざまな組み合わせを実機で検証しています。パスキーをどこに保存するのかを決める際の参考にしてみてください。

パスキー認証の挙動を実機で検証する ― 認証器 × デバイス × サービスの組み合わせ実例集
https://qiita.com/carol0226/items/0367bb7b1bb9fd2413b8

まとめ：③ SaaS サービスもパスキーにする
Microsoft だけをパスキーにして終わりではなく、普段利用している SaaS サービスも、対応しているものからパスキーに切り替えていきましょう。

その際は、サービスとパスキープロバイダーの組み合わせも確認しておく、というのがポイントです。

④ パスキー非対応なサービスの対処方法

残念ながら、すべてのサービスがパスキーに対応しているわけではありません。

パスキーに対応していないサービスについては、iCloud キーチェーン、Google Password Manager、Microsoft Password Manager などのパスワード管理ツールを活用します。

パスワードを自分で考えて使い回すのではなく、サービスごとに異なる、十分に長くランダムなパスワードをパスワードマネージャーで生成・管理することをお勧めします。

また、3rd Party 製のパスワードマネージャーを活用する方法もあります。
例えば、以下のような製品があります。

1Password
Bitwarden
Keeper
RoboForm
PassLogic

ポイント
パスワードマネージャーは多くの認証情報をまとめて管理することになるため、パスワードマネージャー自体のアカウントもしっかり保護することが重要です。

利用するパスワードマネージャーがパスキーに対応している場合は、そのアカウント自体もパスキーでしっかり保護しておきましょう。

企業では、パスワードマネージャーを組織で導入して、パスキーに対応していないサービスのパスワードを管理する方法もあります。

以下の私の記事では、RoboForm Business を Microsoft Entra ID と連携させ、組織で利用する構成について紹介しています。

RoboForm x Entra ID で SSO を構成したときのメモ
https://qiita.com/carol0226/items/1aca8db77f1a22523134

同じようにパスワードレス化を目指す組織でも、残ってしまうパスワードをどのように管理するのかは課題になります。

以下の記事では、企業でパスワードマネージャーを導入する考え方が紹介されています。私も、この考え方に同意しています。

パスワードレスを目指す組織が、なぜパスワードマネージャーを導入したのか🤔
https://qiita.com/akihiro_suto/items/386444bc6b67ec96c62b

パスワードマネージャーは必要か? そしてなぜKeeperか?
https://qiita.com/ishiayaya/items/24f5f9d8fed28339671f

１章：パスキーのまとめ
いかがだったでしょうか？

組織の管理者は、利用者がパスワードを使用する場面を積極的に減らし、可能なところからフィッシング耐性のある認証へ移行していきましょう。

そして、どうしてもパスワードが残ってしまうサービスについては、パスワードマネージャーを活用し、安全に管理していきましょう。

パスワードに依存する場面を減らすことで、フィッシングや意図しない操作による認証情報の窃取リスクを低減することにつながります。

2. アクセス制御（Conditional Access）

1 章では、パスキーを利用して認証そのものをフィッシングに強くしました。

しかし、認証を強化するだけでは十分ではありません。正しい利用者として認証できたとしても、「どのデバイスから」「どの場所・ネットワークから」「どのような条件で」アクセスしているのかによって、アクセスを許可するかどうかを判断する必要があります。

そこで、Microsoft Entra の条件付きアクセスを利用します。

ポイント
パスキーによって「本人であること」を強固に確認し、Conditional Access によって「どのような条件でアクセスを許可するのか」を制御します。

認証を強くするだけで終わらせず、アクセスする際の条件まで制御することが重要です。

私の環境でも、パスキーだけでなく、条件付きアクセスを組み合わせて利用しています。

条件付きアクセスを初めて構成する場合の考え方や設定については、以下の記事で紹介しています。

セキュリティの既定値群と条件付きアクセスの初回利用について
https://qiita.com/carol0226/items/51a70a561b78af567972

なお、無理に条件付きアクセスへ移行する必要はありません

セキュリティの既定値群を利用することでも、Microsoft が提供する基本的なセキュリティ保護を適用できます。

条件付きアクセスは、より柔軟できめ細かなアクセス制御が可能になる一方、適切な設計や運用が必要です。

セキュリティの既定値群から条件付きアクセスへ移行する際に、これまで有効だった保護を適切に再構成できていなければ、かえってセキュリティレベルを下げてしまう可能性もあります。

条件付きアクセスの設計・運用に不安がある場合は、無理に移行せず、セキュリティの既定値群を利用し続けるという判断も必要です。

続いて、認証強度を利用してフィッシング耐性のある認証を要求するなど、条件付きアクセスをさらに進化させていきましょう。

FIDO2 & Entra 完全パスワードレスのための条件付きアクセス
https://qiita.com/carol0226/items/a3e914b3968cb7c38a63

さらに、組織で利用する FIDO2 セキュリティキー自体を制限することもできます。

企業では、自社で検証・承認したセキュリティキーだけを利用させたい場合もあります。 Microsoft Entra では、AAGUID を使用して、特定の FIDO2 セキュリティキーのみを登録できるように制限できます。

以下の記事では、その設定方法を紹介しています。

Microsoft Entraで特定製品の FIDO2 セキュリティキーのみを許可する
https://qiita.com/carol0226/items/4d26717594c2b11126b4

２章：アクセス制御のまとめ
いかがだったでしょうか？

パスキーによって認証そのものを強固にしても、それだけですべてのアクセスを安全にできるわけではありません。

条件付きアクセスを活用して、利用するデバイスや場所、認証方法などの条件に応じて、アクセスを適切に制御していきましょう。

また、組織の要件に応じて、利用できる認証方法や FIDO2 セキュリティキーについても適切に管理していくことが重要です。

パスキーを導入して終わりではなく、条件付きアクセスと組み合わせることで、アクセスできる条件についても段階的に強化していきましょう。

3. 緊急アクセス（Break Glass）

条件付きアクセスなどによってアクセス制御を強化していく一方で、設定ミスや障害などによって、通常の管理者アカウントでサインインできなくなる事態にも備えておく必要があります。

そこで用意しておくのが、緊急アクセス用のアカウント（Break Glass）です。

通常の管理業務には使用せず、通常の管理者アカウントでは対応できない緊急時に利用するための管理経路として準備しておきます。

ポイント
セキュリティを強化するほど、「強固に守ること」だけでなく、「万が一のときに管理経路を失わないこと」も重要になります。

記事ではこの順番で紹介していますが、実際に設定する際は、条件付きアクセスのポリシーを有効化したり、このあとの章で紹介する PIM を導入したりする前に、まず Break Glass を構成しておくことをお勧めします。

Break Glass の考え方や具体的な構成方法については、以下の記事で紹介しています。

緊急アクセス用管理アカウント (Break glass) 入門：基本構成からセオリー外の追加構成まで解説
https://qiita.com/carol0226/items/bbd69bdc907a48f0e67f

３章：緊急アクセスのまとめ
普段の管理者アカウントを強固に保護する一方で、万が一のときに戻れる管理経路も用意しておきましょう。

Break Glass は、アカウントを作って終わりではありません。緊急時に利用できることを定期的に確認し、利用された際に気付けるよう、監視もしておくことが重要です。

まず「戻れる手段」を用意してから、アクセス制御や管理者権限の制限を進めていく、というのが私のお勧めです。

4. 最小特権（PIM）

PIM（Privileged Identity Management）を利用することで、通常の管理者アカウントに特権を常時持たせるのではなく、必要なときに、必要な権限を、必要な時間だけ有効化する運用ができます。

これにより、管理者アカウントが侵害された場合にも、常に特権を保持している状態と比較して、被害の拡大リスクを低減できます。

私自身も検証用テナントでは、管理操作が必要なときに PIM を使って権限を有効化しています。

また、PIM の利用に問題が発生した場合にも管理経路を失わないよう、私は前章の Break Glass を構成してから PIM を導入することをお勧めします。

情シス全員がグローバル管理者になっていませんか？～ Microsoft Entra PIM で始める特権管理
https://qiita.com/carol0226/items/5b42b547f102fa8a17a4

本記事では、緊急時の管理経路を確保してから特権管理を進めるため、「Break Glass → PIM」の順に紹介しています。

最小特権、PIM、緊急アクセスアカウントについての Microsoft の推奨事項は、以下の公式情報も参考にしてください。

Microsoft 公式のベストプラクティス
Microsoft は、Microsoft Entra ロールの管理において、最小特権の原則を適用し、PIM を使用して必要なときに必要な期間だけ権限を有効化する、Just-In-Time のアクセスを推奨しています。

また、グローバル管理者の数を必要最小限に抑える一方で、緊急時に備えてクラウド専用の緊急アクセスアカウントを用意することも推奨しています。

公開情報：Microsoft Entra ロールのベストプラクティス
https://learn.microsoft.com/ja-jp/entra/identity/role-based-access-control/best-practices?wt.mc_id=MVP_407731

４章：最小特権のまとめ
管理操作をするからといって、常に強い権限を持っておく必要はありません。

必要なときに、必要な権限を、必要な時間だけ有効化する、というのが私のお勧めです。

まず Break Glass で緊急時の管理経路を確保し、その上で普段の管理業務を PIM に切り替えていきましょう。

5．認証フローの保護（Device Code Flow）

１章で、パスキーの導入を紹介しました。
ところが、パスキーを導入したからと言って、それで万全ではありません。

この章では、認証フローを悪用した攻撃の一例として、デバイスコードフローを悪用した攻撃と、その対策について紹介します。

ここで重要なのは、パスキーそのものが破られるわけではない、という点です。

正規のサインイン画面でパスキーを使って認証していても、攻撃者が開始した認証フローを利用者が完了させてしまうことで、被害につながる可能性があります。

対策としては、まずサインインログでデバイスコードフローの利用状況を確認します。

利用していない場合は条件付きアクセスでブロックし、必要な場合も、利用を許可する対象を限定していきましょう。業務への影響を確認してから適用することが重要です。

攻撃の仕組みや具体的な対策、検証方法については、以下の私の記事で紹介しています。

パスキーでも被害に遭うデバイスコードフロー攻撃とは？～ Entra ID での防御と検証方法を解説
https://qiita.com/carol0226/items/c9cccdd64e71a731a58d

上記の記事内で、私が LT で説明した際の動画も含まれているので、参照してみてください。

５章：認証フローの保護のまとめ
パスキーを導入したからといって、すべての攻撃を防げるわけではありません。

強い認証方法を使うだけでなく、その認証がどのようなフローで利用されるのかについても確認し、不要な認証フローは制限していきましょう。

今回紹介した攻撃は、あくまでも一例です。パスキーを導入して終わりではなく、攻撃手法の変化に合わせて、防御策も継続的に見直していくことが重要です。

6．メール・コラボレーションの保護（Safe Links / Safe Attachments）

ここまでは、認証やアクセス、管理者権限を保護する方法を紹介しました。続いて、攻撃の入口となるメールやコラボレーションツールも保護していきましょう。

2026年7月1日から、Microsoft Defender for Office 365 Plan 1 が Office 365 E3 / Microsoft 365 E3 に含まれるようになりました。なお、各テナントへの機能展開は段階的に行われるため、利用環境での提供状況も確認してください。

Safe Links は、メールや Microsoft Teams などに含まれる URL を保護する機能です。リンクをクリックした際に URL を確認し、悪意のある URL と判定された場合には、警告画面などによって危険なサイトへのアクセスを抑止します。

また、Safe Attachments も併せて利用することをお勧めします。添付ファイルを安全な検査環境で分析し、悪意のあるファイルから利用者を保護します。

パスキーを導入していても、利用者が悪意のあるリンクを開いたり、危険なファイルを受け取ったりすること自体を防げるわけではありません。

Safe Links / Safe Attachments を組み合わせることで、認証の保護に加えて、リンクや添付ファイルからの攻撃に対する防御層を追加できます。

構成方法の一つとして、Microsoft が推奨設定をまとめた「事前設定されたセキュリティポリシー」を利用できます。 Standard / Strict のポリシーには、Safe Links / Safe Attachments などの保護が含まれています。

公開情報：クラウド組織の事前設定されたセキュリティポリシー
https://learn.microsoft.com/ja-jp/defender-office-365/preset-security-policies?wt.mc_id=MVP_407731#use-the-microsoft-defender-portal-to-assign-standard-and-strict-preset-security-policies-to-users

Safe Links の動作例
以下のメールでは、本文に表示されている URL は元のままです。

一方、ハイパーリンクのコピーでリンク先を確認すると、Safe Links の URL に書き換えられていることが分かります。

このように書き換えられたリンクをクリックすると、Safe Links によるクリック時の確認を経て、問題が検出されなければ元のサイトへ移動します。悪意のある URL と判定された場合には、警告画面などが表示されます。

safelinks へのリンクになっている

https://<地域>.safelinks.protection.outlook.com/?url=<元のURL>&data=<省略>&sdata=<省略>

※これはURLが書き換えられる場合の動作例です。設定や利用アプリによっては、URLを書き換えずに保護する場合もあります。

６章：メール・コラボレーションの保護のまとめ
認証を強固にするだけでなく、攻撃の入口となるリンクや添付ファイルも保護していきましょう。

Safe Links / Safe Attachments を組み合わせて、危険なサイトへのアクセスや悪意のあるファイルによる被害のリスクを低減することが重要です。

7．ネットワークのZero Trust化（Global Secure Access）

ここまで、認証やアクセス制御、メールなどの保護を紹介しました。続いて、ネットワークへのアクセスにも Zero Trust の考え方を広げていきましょう。

以下の Qiita ストックリストに、私が Global Secure Access（GSA）について検証し、投稿してきた記事をまとめています。

Microsoft Entra Global Secure Access (GSA) ストックリスト
https://qiita.com/carol0226/stocks/878e7bbc57b301e0deac

Microsoft Entra Private Access は、社内システムなどのプライベートリソースへのアクセスを保護する機能です。

VPN 装置をインターネットへ公開する構成とは異なり、プライベートネットワーク内のコネクタからのアウトバウンド接続を利用してアクセスを提供します。条件付きアクセスと組み合わせることで、アプリケーションごとにアクセスを制御する ZTNA ベースの構成へ移行できます。

一方、Microsoft Entra Internet Access は、インターネットへのアクセスを保護する Secure Web Gateway（SWG）です。

Web カテゴリや接続先に応じたアクセス制御に加え、生成 AI に送信するプロンプトの保護など、さまざまな機能を利用できます。

私は、Microsoft 365 へのアクセスについても Global Secure Access を経由するように構成し、さらに条件付きアクセスの準拠ネットワークを利用しています。

これにより、ID やデバイスが正しいだけではなく、自組織の Global Secure Access を経由していることもアクセス条件として要求できます。

私としては、Microsoft 365 テナントの前にもう一枚 ネットワーク的な防護壁 が追加されたことが実感でき、安心感が増しています。

GSA 経由のみで Microsoft 365 / SaaS を許可する設計とそのメリット
https://qiita.com/carol0226/items/d19375d8666b5d0b3862

Global Secure Access のライセンスについて
必要なライセンスは、利用する機能や現在の契約によって異なります。

必要なライセンスの詳細については、以下の私の記事の「2. GSA の利用に必要なライセンス」を参考にしてください。

Microsoft Entra Global Secure Access の全体像（2章：2. GSA の利用に必要なライセンス）
https://qiita.com/carol0226/items/29cba6c32a22893a1349#2-gsa-の利用に必要なライセンス

７章：ネットワークの Zero Trust 化のまとめ
認証やデバイスだけでなく、「どの経路でアクセスしているのか」も保護の対象として考えていきましょう。

Global Secure Access と条件付きアクセスを組み合わせることで、自組織の管理する通信経路をアクセス条件に加えることができます。

すべてを一度に置き換えるのではなく、Microsoft 365、インターネット、プライベートリソースなど、組織の要件に合わせて段階的に導入していくことをお勧めします。

8. 検知・調査・対応 (Microsoft Defender)

ここまでは、攻撃を受けにくくするための対策を中心に紹介してきました。

しかし、どれだけ対策を重ねても、すべての攻撃や侵害を100%防げるとは限りません。
そこで次に考えたいのが、「侵入されることも想定した」検知・調査・対応です。

Microsoft では、Microsoft Defender というセキュリティ製品群が提供されています。

Microsoft Defender XDR では、エンドポイント、ID、メール、クラウドアプリなど、複数の領域から得られた情報を組み合わせて脅威を検知し、調査・対応につなげることができます。

ここまで紹介してきた「侵入させないための対策」に加えて、「脅威が発生したとしても、早期に検知して被害の拡大を抑える」という防御も考えていきましょう。

Microsoft Defender の各サービスについては、以下の記事にまとめています。

Microsoft Defender 関連サービスについて整理してみた
https://qiita.com/carol0226/items/8b13a5c4ac3267fa45c4

※利用できる機能や連携範囲は、ライセンスや構成によって異なります

８章：検知・調査・対応のまとめ
攻撃を防ぐ対策に加えて、侵害が発生した場合にも早期に気付き、被害の拡大を抑えられるように備えておきましょう。

Microsoft Defender の活用とともに、アラートの確認、調査、対応を行う運用体制も整えていくことをお勧めします。

まとめ

ここまで、私自身が実際に検証・導入してきたセキュリティ対策を紹介しました。

重要なのは、どれか一つの製品や機能を導入すれば安全になる、ということではありません。

パスキーで、認証そのものをフィッシングに強くする。
条件付きアクセスで、認証後のアクセスを制御する。
Break Glassで、緊急時にも管理経路を失わないようにする。
PIMで、特権を必要な時だけ利用する。
Device Code Flowなど、悪用され得る認証フローにも対策する。
Safe Links / Safe Attachmentsで、利用者が脅威に触れる可能性を減らす。
Global Secure Accessで、ネットワークにもZero Trustの考え方を適用する。
Microsoft Defenderで、それでも発生する脅威を検知・調査し、対応する。

このように、防御を一枚ずつ重ねていくことが重要だと考えています。

そして、それでも「完璧」にはなりません。

攻撃手法はこれからも変化していきます。
だからこそセキュリティ対策も、一度構築して終わりではなく、継続して見直し、アップデートしていく必要があります。

この記事が、皆さまの環境をもう一度見直すきっかけになれば幸いです。

おまけ：Microsoft 365 E5 から E7 へ移行すべきか？

本記事で紹介した対策を導入する際は、現在の契約と、利用したい機能に合わせてライセンスを検討しましょう。

Microsoft 365 E5 への機能追加と E7 への移行を比較した記事も書いていますので、参考にしてください。

Microsoft 365 E5 から E7 へ移行すべき？～ Copilot との価格差から考えるライセンス選び
https://qiita.com/carol0226/items/525ec37aea28cb4420f0

参考情報：Microsoft 公式のベストプラクティス

本記事では、私自身が実際に検証・導入している構成を中心に紹介しました。

Microsoft Entra ID のセキュリティ設計について、さらに詳しく検討したい場合には、Microsoft が公開している以下のベストプラクティスも参考にしてください。