1. ログインと、アプリへのアクセス許可は別の確認

ログインは、利用する本人であることを確かめる手続きです。一方、OAuthによる同意は、アプリに一定の情報へのアクセスや操作を許可する手続きです。アプリがパスワードを知らなくても、許可された範囲でメールやファイルを扱える場合があります。

Microsoftの説明では、正規のサービスの同意画面を通じて、悪意のあるアプリへ権限を渡してしまうことがあります。ログイン先の確認に加えて、「どのアプリに、何を許可するか」を確認してください。

IPAの相談事例では、社員のアカウントから大量のメール送信が確認され、付与されていたアプリへのOAuth同意が悪用された可能性が示されています。相談時点では、侵入経路と情報漏えいの有無は調査中でした。この事例から、同意があるだけで悪用と決めたり、不審な送信があれば必ず漏えいしたと結論付けたりはできません。

2. 「許可する」を押す前に確認すること

利用者は次の項目を、同意画面と社内の導入記録で照合します。メールに「社内承認済み」と書かれていても、それだけを確認の根拠にせず、社内で決めた窓口へ確かめます。

確認すること 判断のために確かめる内容
アプリと発行元 利用する予定の製品・提供元と一致するか。表示名やアイコンだけで判断していないか
要求する権限 何の情報を読めるか、書き換えられるか、送信できるか。今回の用途に必要か
許可する範囲 自分の情報か、組織の情報にも関わるか。説明を理解できない権限がないか
社内の承認 誰が、どの用途・権限で利用を認めたか。既存の承認から権限が増えていないか

発行元の確認済み表示は判断材料の一つです。必要な権限か、社内で承認されているかの確認を省略できる保証ではありません。発行元が未確認の場合や、必要性が分からない権限を求められた場合は、同意せず管理者へ渡してください。

読み取りと送信は異なる操作です。たとえば閲覧のために使うつもりのアプリが送信権限を求めたら、理由を確かめる必要があります。ただし、理由が分からないだけで悪意のあるアプリとは断定しません。

AIサービスへ入力してよい情報や、操作を任せる範囲は顧客情報をAIに入力する前の確認で扱っています。ここでは、連携するアプリに渡すアクセス許可に絞って確認します。

3. 身に覚えのない送信に気付いたら、まず管理者へ連絡

利用者は追加の同意や不審な案内に沿った操作を止め、社内で決めた連絡先へ知らせてください。メールに記載された窓口だけに頼らず、普段から使っている連絡経路を使います。管理者がいなければ、契約しているITの保守先へ連絡し、事故調査まで対応できるかを確認します。

連絡では、気付いた日時、対象のアカウント、送信を確認した状況、心当たりのあるアプリ名と同意したおおよその日時を伝えます。「送信が確認された」「自分では送っていない」「原因は未確認」を分けると、調べる対象を絞りやすくなります。

記録は社内の指定された保管先で扱い、パスワードや認証コードを送らないでください。実メール、宛先、ログには非公開情報が含まれます。公開の相談欄や未承認のAIサービスへ貼り付けず、詳しい資料の渡し方を管理者に確認します。

不審なメールの文面をどう確認待ちにするかは、架空メールを使った検証ラボを参照できます。ただし、文面の分類でアプリの同意やアカウントの状態を調査したことにはなりません。

4. 管理者は、同意・利用・メール側の記録を照合する

以下は管理者へ依頼する確認項目です。画面を順に操作する手順ではありません。実際の調査方法と必要な権限は、Microsoftの同意付与の調査資料などの現行版で確認します。

確認先 照合する内容
アプリの同意・アクセス許可 アプリID、発行元、付与された権限、同意した日時と対象者。社内の導入記録との一致
Microsoft Entra IDの監査ログ・サインインログ 同意や設定変更、不審な利用の日時と接続元。アプリへの同意の時点と利用開始の関係
Exchange Onlineの監査ログ・メッセージトレース 送信の状況と、メールデータへのアクセスの痕跡。調査対象の期間・アカウント
メールボックスの設定 身に覚えのない転送先や受信トレイルールなどの変更

不審な送信を止める対応と、過去に何が起きたかの調査は並行して進めます。Microsoftのメールアカウント対応資料や同意付与の調査資料を基に、管理者がアカウントのアクセス制限、問題のあるアプリの無効化や同意の取り消しなどを判断します。パスワード変更だけでアプリへの同意も取り消せたと考えず、付与された権限への対処も確認してください。

送信の記録だけでは、受信メールやファイルが取得されたかまでは判断できません。MailItemsAccessedの公式資料は、メールデータへのアクセスを調べる監査記録を説明しています。ただし、利用できるログや保持期間は契約・設定などの条件に左右されます。記録がない範囲は「未確認」と残し、痕跡が見つからないことを漏えいがなかった証明にしないでください。

5. 再開の判断と、今後の同意ルールを分けて残す

管理者・責任者は、対象のアプリと利用者、実施した制限、調査できた期間、分かった事実、未確認の範囲を整理します。利用を再開する条件と判断者も記録し、原因が未確認のまま「対応済み」の一言で閉じないようにします。

そのうえで、ユーザーの同意設定に関する公式資料を参照し、任意のアプリへ同意できる範囲、発行元と許可する権限の条件、管理者が承認する運用を見直します。組織全体の設定変更は正規の業務連携にも影響するため、利用中のアプリと担当者を確認してから行います。

日常の管理では、アプリ・用途・管理者・承認した権限を一緒に残しておくと、異常時に導入記録と照合できます。担当交代や連携の保守は業務ツールの権限・保守・引き継ぎへ進んでください。