Outlook アドインのセキュリティ承認｜情シスが審査するときの観点リスト

Microsoft 365の普及に伴い、Outlookの機能を拡張する「アドイン」の利用ニーズが急増しています。しかし、利便性の裏側で、アドインがメール本文や連絡先、予定表などの機密データにアクセスする権限を求めてくるため、情シス担当者にとってはその「承認基準」の策定が急務となっています。

本記事では、IT実務者の視点から、Outlookアドインをセキュリティ審査する際の具体的なチェックリストと、Microsoft Entra ID（旧Azure AD）を用いた統制手法、そして運用フローの構築までを詳説します。

Outlook アドインのセキュリティ審査が重要な理由

なぜOutlookアドインの導入には慎重な審査が必要なのでしょうか。それは、アドインが現代のサイバー攻撃における「新たな侵入経路」になり得るからです。

メールデータは「機密情報の塊」である

メールには、顧客の個人情報、未発表のプロジェクト資料、インサイダー情報、さらには他SaaSのパスワードリセット通知など、企業における最重要データが集約されています。アドインに「すべてのメールの読み取り」権限を許可することは、これらすべてのデータへのアクセスキーを外部ベンダーに預けることと同義です。

API経由のデータ流出リスク

モダンなOutlookアドインは、Microsoft Graph APIを介してデータにアクセスします。一度ユーザーが「承諾」ボタンを押すと、ユーザー自身の認証情報を介さずにバックエンドでデータを取得し続けることが可能なケースもあります。万が一アドインの開発元がサイバー攻撃を受けた場合、自社のメールデータが二次的に流出するリスクを考慮しなければなりません。

こうしたツール導入時のセキュリティリスク管理は、アドインに限った話ではありません。例えば、多くのSaaSを導入している企業では、退職者のアカウント削除漏れが深刻なリスクとなります。
SaaS増えすぎ問題と退職者のアカウント削除漏れを防ぐ実務で解説しているような、ID管理（IdP）を軸とした統制の考え方が、アドイン管理においても重要になります。

情シスがチェックすべき「5つの審査観点リスト」

アドインの利用申請を受けた際、情シス担当者が最低限確認すべき項目をリスト化しました。

1. 権限スコープ（Scopes）の最小限原則

そのアドインが要求している権限は、提供される機能に対して過剰ではないかを確認します。

• Mail.Read: 全メールの読み取り。非常に強い権限です。
• Mail.Send: ユーザーに代わってメールを送信。なりすましメールのリスクがあります。
• Calendars.Read: 予定表の閲覧。会議出席者や場所が漏洩します。

機能が「添付ファイルの自動保存」であれば「Mail.Read」は妥当ですが、単なる「署名テンプレートの挿入」で「Mail.ReadWrite」を求めてくる場合は、その必要性を開発元に問うべきです。

2. データのライフサイクルと保存先

アドインが読み取ったデータが「どこで処理され、どこに保存されるか」を公式ドキュメント（Privacy PolicyやSecurity Whitepaper）で確認します。

• クライアントサイド処理: ブラウザやOutlookアプリ内でのみ処理され、外部送信されない（比較的安全）。
• サーバーサイド処理: 開発元のサーバーへデータが転送され、そこで処理・保存される（高リスク、保管期間と場所の確認が必要）。

3. 開発ベンダーの信頼性と準拠法

Microsoft AppSource（公式ストア）に掲載されていることは一つの目安ですが、十分ではありません。以下の点をチェックします。

• ISMS（ISO27001）やPマークを保持しているか。
• SOC2レポートを提供可能か。
• 日本国内のベンダーか、あるいはGDPR等の厳格な法規制下にある国のベンダーか。

4. 認証・認可の仕組み

アドイン独自のログイン機能がある場合、Microsoft Entra IDによるシングルサインオン（SSO）に対応しているかが重要です。独自のID/パスワード管理を強いるアドインは、IDガバナンスの観点から推奨されません。

5. マニフェストファイルの検証

アドインの設定ファイルである「Manifest（XML形式）」を確認できる場合は、SourceLocationを確認します。通信先ドメインが、信頼できる公式ドメインに限定されているかを確認するためです。

Outlook アドインの種類とセキュリティ特性の比較

Outlookアドインには、大きく分けて「レガシーな形式」と「モダンな形式」が存在します。情シスとしては、セキュリティ管理の観点からモダンな形式への移行を推奨すべきです。

COM/VSTOアドインは、端末のローカルリソースにフルアクセスできるため、脆弱性があった際の影響範囲が甚大です。現在、MicrosoftはOffice JSベースのアドインを推奨しています。社内のDXを推進する上でも、OSやデバイスを問わずに動作するモダンなアーキテクチャの選定が不可欠です。例えば、Excelと紙の限界を突破する業務DXガイドでも触れているように、プラットフォームに依存しないWeb技術の活用が、運用負荷とセキュリティを両立する鍵となります。

実務で使える「アドイン導入承認フロー」の構築手順

情シスが「NO」と言うだけの部門にならないためには、標準化された承認プロセスが必要です。

ステップ1：ユーザーからの利用申請受付

以下の項目を含むヒアリングシート（Microsoft Forms等で作成）を用意します。

• アドイン名およびAppSourceのURL
• 利用目的（どのような課題を解決するか）
• 対象ユーザー（特定部署のみか、全社か）
• 代替ツールの有無

ステップ2：Microsoft Entra ID での権限確認

管理者は、Microsoft 365 管理センターの「統合アプリ」または「設定 > アドイン」から、対象アドインが求めるアクセス許可を確認します。
特に「管理者の同意」が必要な権限が含まれている場合、その承認が全ユーザーに影響を与えるため、慎重に確認します。

ステップ3：サンドボックス環境での動作・通信検証

本番環境に適用する前に、テスト用のアカウントで実際にアドインを動作させます。
Fiddlerやブラウザの開発者ツール（F12）を使用し、外部の不審なドメインと通信していないか、メールの内容が意図せず外部にポストされていないかをモニタリングします。

ステップ4：管理センターからの「一括配布」設定

承認が下りたら、ユーザー各自にインストールさせるのではなく、管理者側で「一括配布」を行います。

1. Microsoft 365 管理センター > 設定 > 統合アプリ
2. 「アプリを取得」から対象アドインを選択
3. 「構成」にて、特定のグループ（例：営業部のみ）に限定して割り当て
4. 「デプロイ」を完了。最大24時間以内にユーザーのOutlookに表示されます

この際、情シスが手作業で全アカウントを管理するのは限界があります。特に中堅企業以上では、ID連携の実践ガイドで紹介しているような、セキュアな名寄せや属性ベースのアクセス制御（ABAC）の考え方を取り入れると、部署異動に伴うアドイン権限の自動剥奪などがスムーズになります。

よくあるエラーとトラブルシューティング

アドイン運用中によく発生するトラブルと、その解決策をまとめました。

「アドインを起動できません」の原因と対策

ユーザーからこの申告があった場合、多くはブラウザ（Outlook Web版）のキャッシュか、IE11/レガシーEdgeのコンポーネントが影響しています。
現在、Microsoft 365アドインはEdge（WebView2）を使用します。端末に「Microsoft Edge WebView2 ランタイム」がインストールされているか確認してください。

管理者によってアドインがブロックされている場合の表示

「お客様の組織のポリシーにより、このアドインは利用できません」と表示される場合、Exchange Onlineの「役割割り当てポリシー」でMy Marketplace Appsがオフになっている可能性があります。
特定のユーザーにだけインストール権限を与えたい場合は、このポリシーをカスタマイズする必要があります。

継続的なセキュリティ統制のための棚卸し実務

一度承認したアドインも、放置すれば脆弱性の温床となります。半年に一度は「統合アプリ」のリストを確認し、以下の基準で棚卸しを実施してください。

• 最終更新日: 開発元が1年以上アップデートを停止しているものは、セキュリティリスクが高いと判断し、利用停止を検討する。
• 利用実態: 管理センターのレポートから、ほとんど使われていないアドインを特定し、配布対象を縮小または削除する。
• 権限の変更: アドインのアップデートに伴い、要求される権限が増えていないか再チェックする。

Outlookアドインの承認は、単なる「ツールの許可」ではなく、「企業の重要データへのアクセス許可」です。本記事のリストを活用し、利便性とセキュリティが両立したITインフラを構築してください。