多くの企業がAIで業務改善を進める一方で、攻撃者もAIを使って、攻撃の手口をより巧妙にしていることをご存じでしょうか？ 今回は、身近なメールを入口に、皆さんのMicrosoft 365アカウントとAzureの環境をどう守るか、一緒に考えてみましょう。
自分なら見分けられると思っていませんか
フィッシングメールは、以前から使われている攻撃手法の一つです。皆さんの会社でも、定期的にセキュリティ研修や標的型メール訓練がありますよね。「日本語が不自然」「件名に誤字がある」「自分には関係のない内容」。そんなフィッシングメールなら、すぐに気づける方も多いと思います。怪しいリンクを開かずに報告する、という習慣も身についているのではないでしょうか。
では、丁寧な日本語で、しかも昨日の自分の行動にぴったり合うメールが届いたらどうでしょう。いつもの判断だけで、同じように見分けられるでしょうか。
昨日行ったお店なら信じてしまいませんか
たとえば、取引先との食事の後に、FacebookやXへ「さくら亭で楽しい時間を過ごしました」と投稿したとします。翌日、そのお店を名乗るアンケートメールが届きました。
「昨日はご来店ありがとうございました。アンケートにご協力いただいた方へ、次回使えるクーポンをご案内します。」
「確かに昨日行ったお店だし、また利用したい。少しくらいなら回答しようかな」。そう思うのは自然ですよね。ところが、そのメールは公開投稿を見た攻撃者が、お店を装って送ったものかもしれません。ここでは、攻撃者が別途メールアドレスも把握している状況を想定しています。投稿だけでメールアドレスや人間関係のすべてが分かる、という意味ではありません。
リンク先が見慣れたログイン画面に似ていると、そのまま会社のIDとパスワードを入力してしまうことがあります。偽サイトが入力内容を受け取れば、その情報は攻撃者に渡ります。画面にエラーが出ても、情報が渡っていないとは限りません。
生成AIはあなたが信じてしまいそうなメール作りにも使われます
生成AIは、自然な敬語を使った文章を作るだけでなく、集めた情報の整理や要約にも使えます。攻撃者がSNSの公開投稿や会社の公開情報を集めれば、訪問先や仕事、関心のある話題を手がかりに、その人が反応しそうな依頼文を作りやすくなります。特定の相手を調べて狙う攻撃は以前からありましたが、AIがその作業を支援することで、利用者が本物だと思い込みやすいメールを作りやすくなるのです。
もちろん、AIが非公開の情報まで自動的に知るわけではありません。それでも、本名、勤務先、店名、日時などの公開情報は、「自分のことを知っている」と感じさせる材料になります。文章が自然で、自分の行動と合っている。それだけで信用しないことが大切です。
では、どこを確認すればよいのでしょうか。まず意識したい三つのポイントをご紹介します。
文章の自然さだけでなく求められる操作を確認しましょう
アンケートへの回答に会社のアカウントは必要でしょうか
飲食店への感想を送るために、会社のMicrosoft 365アカウントでのログインを求められたら、いったん止まりましょう。「メールを読む」「ファイルへアクセスする」といったアプリの許可まで求められた場合も同じです。依頼の目的と、要求される操作がつながっているかを確認します。
心当たりと送信者の確認は分けて考えましょう
店名や訪問日が合っていても、本物のお店から届いたという証明にはなりません。表示名だけでなく送信元アドレスやリンク先を確認します。ただし、正規サービスや乗っ取られたアカウントが使われることもあります。「ドメインが正しいから安全」とも言い切れません。
メールの外から確かめる習慣をつけましょう
迷ったらメール内のリンクや電話番号を使わず、普段使っている公式アプリ、ブックマーク、手元の連絡先から確認してください。社内の依頼なら、既知の担当者とのTeamsチャットや社内の連絡先一覧を使います。期限や特典を理由に、確認を省かないことが大切です。
また、身に覚えのない認証通知を承認したり、メールで指定されたコードを認証画面に入力したりしないでください。SNSでは公開範囲を見直し、取引先名やその場の行動をどこまで公開するかも考えてみましょう。
見抜けなくても被害が出にくい仕組みを作りましょう
利用者の注意に加えて、不審なメールが届きにくくなる対策と、不正アクセスを防ぐ対策を組み合わせましょう。ここからは、Microsoft 365とAzureで確認したい設定をご紹介します。
まずはメールの入口を確認します
Exchange Onlineの迷惑メール・マルウェア・なりすまし対策を確認し、業務上不要な許可設定が増えていないか見直します。自社ドメインのSPF・DKIM・DMARCも整備しましょう。ただし、これらは主に送信元の認証を助ける仕組みで、似た別ドメインや侵害済みアカウントからのメールをすべて防ぐものではありません。
Microsoft Defender for Office 365では、なりすまし対策に加えて、Safe Linksによるリンクの検査、Safe Attachmentsによる添付ファイルの検査を利用できます。Safe Linksはクリック時にもURLを検査します。対象ユーザーやポリシーの適用範囲、警告を無視して進める設定になっていないかまで確認したいですね。
フィルターですべての攻撃を止められるわけではありません。Outlookの報告機能や社内窓口を案内し、自然な日本語のメールも含めた訓練を続けましょう。「間違って開いたら怒られる」より、「迷ったらすぐ相談できる」運用が、早い対応につながります。
MFAは方式まで確認しましょう
Microsoft 365とAzureへのサインインを担うMicrosoft Entra IDでは、多要素認証（MFA）を利用します。さらに確認したいのが、その方式です。SMSの確認コードやプッシュ通知によるMFAと、フィッシング耐性のあるMFAでは、攻撃への強さが異なります。
FIDO2セキュリティキーやWindows Hello for Businessなどを検討し、条件付きアクセスの「認証強度」で、対象のアプリへのアクセス時にフィッシング耐性のあるMFAを要求します。利用できる状態にするだけでなく、必要な場面で必須にするところまでがポイントです。
これは、偽サイトへの文字入力そのものを止める機能ではありません。パスワードが漏れても、それだけで保護対象のリソースへアクセスされないようにする対策です。認証方法の登録・復旧手順も含めて整備してください。
正規の認証画面やアプリの許可を悪用する手口にも備えましょう
正規の認証画面であっても、攻撃者の認証要求を承認させられる手口があります。業務で使っていないデバイスコードフローは、利用状況を調べてから条件付きアクセスで制限します。必要な機器がある場合は、用途に合わせて例外を絞ります。アプリへのユーザー同意も見直し、許可する権限を限定し、必要な申請は管理者が確認する運用にします。
条件付きアクセスは、レポート専用モードや小さな対象グループで影響を確認し、緊急時のアクセス手段を確保してから適用しましょう。
Azureの被害を広げないためにできること
「Microsoft 365のアカウントが狙われたのに、なぜAzureも関係するの？」と思う方もいるかもしれません。同じMicrosoft Entra IDのユーザーにAzureの操作権限があれば、その権限も狙われる可能性があります。ただし、アカウントが侵害されたからといって、Azureの全データへ自動的にアクセスできるわけではありません。付与された権限やトークンの対象、アクセス制御によって影響は変わります。
普段の仕事に必要な権限だけを付与しましょう
Azure RBACで、担当業務に必要なロールと範囲に絞ります。日常のメール閲覧用アカウントと管理用アカウントを分け、管理用アカウントで一般のメールやWebを閲覧しない運用も進めましょう。PIM（Privileged Identity Management）を使えば、必要な時間だけ管理権限を有効化する運用ができます。
異常の確認と対応を担当する人を決めましょう
Microsoft Entraのサインインログ、監査ログ、Azureのアクティビティログを確認できるようにし、誰がアラートを確認し、誰がアカウントを止めるかまで決めておきます。Microsoft Entra ID Protectionでは、リスクの検出・調査と、リスクに応じたアクセス制御を検討できます。ログを保存するだけで終わらせないことが大切です。
入力してしまったら気づいた時点で連絡してください
操作を止めて、メール、アクセスした時刻、入力した情報の種類、認証要求やアプリへのアクセス許可を承認したかを社内窓口へ伝えましょう。パスワードの文字列そのものを報告メールに書く必要はありません。「被害が出たか分からない」段階でも、遠慮なく連絡してください。
管理者は必要に応じてサインインを制限し、安全な経路でのパスワード変更、セッションの失効、不審な認証方法・アプリの許可・メール転送ルールの確認を進めます。Azureの権限変更や操作履歴も調べます。パスワードを変えただけで対応を終えず、アクセスが継続していないか確認しましょう。
自分の環境で最初に確認してみませんか
まずは「誰にどのメール保護が適用されているか」「MFAはどの方式か」「普段のアカウントに管理権限が付いていないか」を確認してみてください。不審な依頼に気づく力に加えて、立ち止まって確かめる習慣と、見逃しても被害を抑える設定を、チームで整えていきましょう。次回は、Microsoft Entra IDの具体的な設定を紹介します。
執筆者プロフィール
くもぐもねこ W・J | Azure エンジニア
- Azureを中心に、インフラ、AI、セキュリティ領域の技術支援に従事しています。
- Microsoft Azure、データ・ セキュリティなどの技術情報について、実際の検証結果や導入・運用で得た知見を交えながら、お客様の課題解決に役立つ情報を発信しています。