Office アドインのプライバシーとセキュリティ

プロセス セキュリティ

Office アドインは、アドインのランタイム環境、複数層のアクセス許可モデル、およびパフォーマンス ガバナーによって保護されます。 このフレームワークは、次の方法でユーザーのエクスペリエンスを保護します。

• Office クライアント アプリケーションの UI フレームへのアクセスは管理されます。

• Office クライアント アプリケーションの UI スレッドへの間接アクセスのみが許可されます。

• モーダル操作は許可されません。たとえば、JavaScript alert、、 confirmメソッドの呼び出し prompt はモーダルであるため許可されません。

さらに、ランタイム フレームワークには、Office アドインがユーザーの環境に損害を与えないようにするために、次の利点があります。

• アドインが実行されるプロセスを分離します。

• .dll や .exe の置き換えも、ActiveX コンポーネントも必要ありません。

• アドインのインストールとアンインストールが容易になります。

また、Office アドインによるメモリ、CPU、およびネットワーク リソースの使用が管理可能になり、良好なパフォーマンスと信頼性が確保されます。

注:

一部のシナリオでは、アドインのさまざまな機能が別々のランタイムで実行されます。 わかりやすくするために、この記事では単数形の "ランタイム" を使用します。詳細については、「 Office アドインのランタイム」を参照してください。

以降のセクションでは、Windows ベースのデバイス、Mac OS X デバイス、および Web ブラウザーでの Office クライアントでのアドインの実行をランタイム アーキテクチャがサポートする方法について簡単に説明します。

Windows および OS X のデバイス用のクライアント

Windows 上の Excel や Outlook on Windows や Mac などのデスクトップおよびタブレット デバイスでサポートされているクライアントでは、アドインのライフサイクルを管理し、アドインとクライアント アプリケーション間の相互運用性を有効にする、インプロセス コンポーネントである Office アドイン ランタイムを統合することで Office アドインがサポートされます。 アドイン Web ページ自体はプロセス外でホストされます。 図 1 に示すように、Windows デスクトップまたはタブレット デバイスでは、アドイン Web ページはインターネット エクスプローラーまたは Microsoft Edge コントロール内でホストされ、セキュリティとパフォーマンスの分離を提供するアドイン ランタイム プロセス内でホストされます。

Windows デスクトップでは、制限付きサイト ゾーンに対してインターネット エクスプローラーの保護モードを有効にする必要があります。 これは通常、既定で有効にされています。 無効になっている場合、アドインを起動しようとするとエラーが発生します。

図 1. Windows ベースのデスクトップおよびタブレットのクライアントにおける Office アドインのランタイム環境

次の図に示すように、Mac OS X デスクトップでは、アドイン Web ページはサンドボックス化された WebKit ランタイム ホスト プロセス内でホストされ、同様のレベルのセキュリティとパフォーマンス保護を提供するのに役立ちます。

図 2. Mac OS X クライアントの Office アドイン ランタイム環境

Office アドイン ランタイムは、プロセス間通信、JavaScript API 呼び出しとイベントの固有形式への変換、および UI リモート処理サポートを管理し、アドインがドキュメント内や作業ウィンドウ内、あるいは電子メール メッセージ、会議出席依頼、予定の隣に表示されるようにします。

Web クライアント

サポートされている Web クライアントでは、Office アドインは HTML5 サンドボックス属性を使用して実行される iframe でホストされます。 ActiveX コンポーネントや Web クライアントのメイン ページでのナビゲーションは許可されていません。 Office アドインのサポートは、JavaScript API for Office の統合によって Web クライアント内で有効になっています。 デスクトップ クライアント アプリケーションの場合と同様、JavaScript API はアドインのライフサイクルや、アドインと Web クライアントの間の相互運用性を管理します。 この相互運用性は、特別なクロスフレーム ポスト メッセージ通信インフラストラクチャを使用して実現されています。 Web クライアントとの対話には、デスクトップ クライアント上で使用されるのと同じ JavaScript ライブラリ (Office.js) を使用できます。 次の図は、ブラウザーで実行されている Office のアドインをサポートするインフラストラクチャと、それらをサポートするために必要な関連コンポーネント (Web クライアント、 iframe、Office アドイン ランタイム、JavaScript API for Office) を示しています。

図 3. Office Web クライアント内で Office アドインをサポートするインフラストラクチャ

AppSource でのアドインの整合性

Office アドインは、AppSource で公開することで利用可能にできます。 AppSource では、アドインの整合性を維持するために、次のメジャーが適用されます。

• Office アドインのホスト サーバーでは、通信に必ず Secure Socket Layer (SSL) を使用する必要があります。

• 開発者はアドインを提出する際に、ID の証明、契約上の合意、および法規制に準拠したプライバシー ポリシーを提供する必要があります。

• 使用可能なアドインに対するユーザーレビュー システムをサポートしてコミュニティの自己管理を促します。

オプションの接続エクスペリエンス

エンド ユーザーと IT 管理者は、Office のデスクトップ クライアントとモバイル クライアントでオプションの接続エクスペリエンスを オフにすることができます。 Office アドインの場合、[ オプションの接続エクスペリエンス ] 設定を無効にした場合の影響は、ユーザーがこれらのクライアントを介してアドインや Microsoft 365 および Copilot ストアにアクセスできなくなったということです。 ただし、必須またはビジネスクリティカルと見なされる特定の Microsoft アドインと、organizationの IT 管理者が一元展開を通じてデプロイしたアドインは引き続き使用できます。 また、アドインと Microsoft 365 および Copilot ストアは、設定の状態に関係なく、Outlook on the webで引き続き使用できます。

Outlook 固有の動作の詳細については、「 Outlook アドインのプライバシー、アクセス許可、セキュリティ」を参照してください。

IT 管理者が Office での接続エクスペリエンスの使用を無効にした場合、アドインには、オプションの接続エクスペリエンスのみをオフにするのと同じ効果があることに注意してください。

エンド ユーザーのプライバシー問題への対応

ここでは、Office アドイン プラットフォームから提供される保護を顧客 (エンド ユーザー) の視点から説明し、ユーザーの期待に応える方法とユーザーの個人情報 (PII) を安全に取り扱う方法に関するガイドラインを提供します。

エンド ユーザーの認知

Office アドインは、ブラウザー コントロールまたは iframe 内で実行する Web テクノロジを使用して構築されています。 そのため、アドインの使用は、インターネットまたはイントラネット上で Web サイトを閲覧することと似ています。 アドインは、organizationの外部 (AppSource からアドインを取得した場合) または内部 (Exchange Server アドイン カタログ、SharePoint アプリ カタログ、またはorganizationのネットワーク上のファイル共有からアドインを取得した場合) にすることができます。 アドインはネットワークへのアクセスが制限されますが、ほとんどのアドインは作業中のドキュメントやメール アイテムの読み書きができます。 ユーザーや管理者がアドインをインストールまたは起動する前に、アドイン プラットフォームによって特定の制約が課されます。 ただし、拡張性モデルと同様に、未知のアドインの起動は慎重に行う必要があります。

注:

ユーザーは、アドインが初めて読み込まれると、ドメインを信頼するように求めるセキュリティ プロンプトが表示される場合があります。 これは、アドインのドメイン ホストが Exchange オンプレミスまたはOffice Online Serverのドメインの外部にある場合に発生します。

アドイン プラットフォームは、エンド ユーザーのプライバシーに関する問題に次の方法で対処します。

• コンテンツ アドイン、Outlook アドイン、または作業ウィンドウ アドインをホストする Web サーバーとやり取りされるデータ、およびアドインとそれが使用する Web サービス間の通信は、Secure Socket Layer (SSL) プロトコルを使用して暗号化する必要があります。

• ユーザーが AppSource からアドインをインストールする前に、そのアドインのプライバシー ポリシーと要件を表示できます。 さらに、ユーザーのメールボックスと対話する Outlook アドインは、必要な特定のアクセス許可を表示します。ユーザーは、Outlook アドインをインストールする前に、使用条件、要求されたアクセス許可、プライバシー ポリシーを確認できます。

• ドキュメントを共有する場合、ユーザーはそのドキュメントに挿入されているアドインまたはそのドキュメントに関連付けられているアドインも共有することになります。 ユーザーが以前に使用したことがないアドインを含むドキュメントを開いた場合、Office クライアント アプリケーションは、ドキュメントでアドインを実行するためのアクセス許可をユーザーに付与するように求めます。 組織環境では、Office クライアント アプリケーションによって、ドキュメントが外部ソースから送信されたかどうかをユーザーに求めるメッセージも表示されます。

• ユーザーは、AppSource へのアクセスを有効または無効にすることができます。 コンテンツ アドインと作業ウィンドウ アドインの場合、ユーザーはホスト Office クライアントのセキュリティ センターから信頼されたアドインとカタログへのアクセスを管理します (ファイル>オプション>セキュリティ センターのセキュリティ センター>設定>信頼できるアドイン カタログから開きます)。 Outlook では、アドインを管理するためのアクセスは、ユーザーの Outlook クライアントによって異なります。

  • Outlook on Windows または Mac でアドインを管理する方法については、「Outlook 用 Office アドインを入手する」を参照してください。
  • Outlook on the webで、リボンから [アドインの取得] を選択します。 詳細については、「Outlook on the webでのアドインの使用」を参照してください。

  管理者は、 管理センターを使用して AppSource へのアクセスを管理することもできます。

• アドイン プラットフォームの設計により、次の方法でエンド ユーザーにセキュリティとパフォーマンスが提供されます。

  • Office アドインは、Office クライアント アプリケーションとは別のアドイン ランタイム環境でホストされる Web ブラウザー コントロールで実行されます。 この設計により、クライアント アプリケーションからのセキュリティとパフォーマンスの両方の分離が提供されます。

  • アドインは Web ブラウザー コントロール下で動作するため、ブラウザーで動作する通常の Web ページとほぼ同じ処理を実行できますが、同時に、ドメイン分離のための同一生成元ポリシーとセキュリティ ゾーンを遵守するように制限されます。

Outlook アドイン固有のリソース使用量監視機能により、Outlook アドインはセキュリティとパフォーマンスの追加の機能を提供します。 詳細については、「Outlook アドインに関するプライバシー、アクセス許可、セキュリティ」を参照してください。

PII の取り扱いに関する開発ガイドライン

Office アドインの開発者向けの特定の PII 保護ガイドラインを次に示します。

• Settings オブジェクトは、コンテンツ アドインまたは作業ウィンドウ アドインに関する設定やセッション間の状態データの永続化に使用できますが、Settings オブジェクトにはパスワードやその他の機密性の高い PII を保存しないでください。 Settings オブジェクトのデータはエンド ユーザーには表示されませんが、すぐにアクセスできるドキュメントのファイル形式の一部として格納されます。 アドインの PII の使用を制限し、アドインに必要な PII はユーザー保護リソースとしてアドインをホストするサーバーに保存する必要があります。

• 一部のアプリケーションを使用すると PII が公開されてしまう可能性があります。 ユーザーの ID、所在、アクセス時間、およびその他の資格情報に関するデータが安全に保存されていて、アドインの他のユーザーが使用できないことを確認してください。

• アドインが AppSource で入手可能な場合は、AppSource の HTTPS 要件によって Web サーバーとクライアント コンピューターまたはデバイスとの間で転送される PII が保護されます。 ただし、データを他のサーバーに再転送する場合は、これと同レベルの保護が適用されることを確認してください。

• ユーザーの PII を保存する場合は、その事実を公開し、ユーザーがそれを検査して削除できる方法を提供します。 アドインを AppSource に送信する場合は、収集するデータとその用途をプライバシーに関する声明の中で説明できます。

開発者によるアクセス許可の選択とセキュリティ手法

Office アドインのセキュリティ モデルをサポートするための以下の一般的なガイドラインを踏まえたうえで、アドインの種類ごとの詳細について調べます。

アクセス許可の選択

アドイン プラットフォームは、その機能で必要なユーザー データへのアクセス レベルを宣言する、アドインが使用するアクセス許可のモデルを提供します。 それぞれのアクセス許可レベルは、アドインがその機能で使用することが許可されている JavaScript API for Office のサブセットに対応しています。 たとえば、コンテンツアドインと作業ウィンドウ アドインに対する WriteDocument アクセス許可を使用すると、 Document.setSelectedDataAsync メソッドにアクセスできます。これにより、アドインはユーザーのドキュメントに書き込めますが、ドキュメントからデータを読み取るためのメソッドへのアクセスは許可されません。 このアクセス許可レベルは、ユーザーのドキュメントにデータを挿入するためにユーザーが照会できるアドインなど、ドキュメントに書き込みのみを行う必要があるアドインに適しています。

ベスト プラクティスとして、最小特権の原則に基づいてアクセス許可を要求します。 つまり、アドインが正しく機能するために必要な最小限の API サブセットにのみアクセスする許可を要求します。 たとえば、ユーザーのドキュメントのデータさえ読み込めばアドインが正しく機能する場合、ReadDocument 以外のアクセス許可を要求しません。 (ただし、要求したアクセス許可が不十分な場合は、アドイン プラットフォームによってアドインによる一部の API の使用がブロックされ、ランタイム エラーが発生する可能性があることに注意してください)。

次の例に示すように、アドインのマニフェストでアクセス許可を指定すれば、エンド ユーザーは、アドインを初めてインストールまたはアクティブにする前に、アドインの要求されたアクセス許可レベルを確認できます。 さらに、 ReadWriteMailbox アクセス許可を要求する Outlook アドインには、明示的な管理者特権が必要です。

次の例は、作業ウィンドウ アドインがマニフェストで ReadDocument アクセス許可を指定する方法を示しています。 アクセス許可に注目できるようにマニフェスト内の他の要素は省略しています。

<?xml version="1.0" encoding="utf-8"?>
<OfficeApp xmlns="http://schemas.microsoft.com/office/appforoffice/1.0"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
           xmlns:ver="http://schemas.microsoft.com/office/appforoffice/1.0"
           xsi:type="TaskPaneApp">

... <!-- To keep permissions as the focus, not displaying other elements. -->
  <Permissions>ReadDocument</Permissions>
...
</OfficeApp>

作業ウィンドウ アドインとコンテンツ アドインのアクセス許可の詳細については、「アドインでの API 使用についてアクセス許可を要求する」を参照してください。

Outlook アドインのアクセス許可の詳細については、次のトピックを参照してください。

• Outlook アドインに関するプライバシー、アクセス許可、セキュリティ

• Outlook アドインのアクセス許可を理解する

同一生成元ポリシー

Office アドインは Web ブラウザー コントロールで実行される Web ページであるため、ブラウザーによって適用される同じ配信元ポリシーに従う必要があります。 既定では、あるドメイン内の Web ページでは、ホストされているドメイン以外の別のドメインに 対して XmlHttpRequest Web サービスを呼び出すことはできません。

この制限を克服する 1 つの方法は、JSON/P を使用することです。別のドメインでホストされているスクリプトを指す src 属性を持つスクリプト タグを含めることによって、Web サービスのプロキシを提供します。 プログラムによってスクリプト タグを作成し、src 属性を指す URL を動的に作成し、URI クエリ パラメーターを使用してパラメーターを URL に渡すことができます。 Web サービス プロバイダーは、特定の URL で JavaScript コードを作成してホストし、URI クエリ パラメーターに応じて異なるスクリプトを返します。 これらのスクリプトが挿入先で実行され、想定どおりに機能します。

Outlook アドインでの JSON/P の例を次に示します。

// Dynamically create an HTML SCRIPT element that obtains the details for the specified video.
function loadVideoDetails(videoIndex) {
    // Dynamically create a new HTML SCRIPT element in the webpage.
    const script = document.createElement("script");
    // Specify the URL to retrieve the indicated video from a feed of a current list of videos,
    // as the value of the src attribute of the SCRIPT element. 
    script.setAttribute("src", "https://gdata.youtube.com/feeds/api/videos/" + 
        videos[videoIndex].Id + "?alt=json-in-script&callback=videoDetailsLoaded");
    // Insert the SCRIPT element at the end of the HEAD section.
    document.getElementsByTagName('head')[0].appendChild(script);
}

Exchange と SharePoint は、クロス ドメイン アクセスを可能にするためにクライアント側のプロキシを提供します。 一般に、イントラネット上の同一生成元ポリシーは、インターネット上のポリシーほど厳密ではありません。 詳細については、「同一生成元ポリシー第 1 部: ピーク禁止」および「Office アドインにおける同一生成元ポリシーの制限事項に対応する」を参照してください。

悪意のあるクロスサイト スクリプティングを回避するヒント

悪意のあるアクターは、アドイン内のドキュメントまたはフィールドを介して悪意のあるスクリプトを入力することで、アドインの配信元を攻撃する可能性があります。 開発者は、ドメイン内で悪意のあるユーザーの JavaScript が実行されないようにユーザー入力を処理する必要があります。 ドキュメントまたはメール メッセージから、またはアドインのフィールドを使用してユーザー入力を処理するために従う良い方法を次に示します。

• 可能であれば、DOM プロパティの innerHTML ではなく、innerText および textContent プロパティを使用します。 インターネット エクスプローラーと Firefox クロスブラウザーのサポートについては、次の手順を実行します。

   var text = x.innerText || x.textContent
  

  innerText と textContent の違いについては、「Node.textContent」を参照してください。 一般的なブラウザー間での DOM の互換性の詳細については、「W3C DOM 互換性」を参照してください。

• innerHTML を使用する必要がある場合は、innerHTML に渡す前に、ユーザーの入力に悪意のあるコンテンツが含まれていないことを確認してください。 innerHTML を安全に使用する方法とその例については、innerHTML プロパティを参照してください。

• jQuery を使用している場合は、.html() メソッドの代わりに .text() メソッドを使用してください。

• toStaticHTML メソッドを使用して、ユーザーの入力から動的な HTML 要素と属性を削除したうえで、innerHTML に入力を渡してください。

• encodeURIComponent または encodeURI 関数を使用して、参照元 URL またはユーザーの入力を含む URL として使用できるようにテキストをエンコードしてください。

• より安全に使用できる Web ソリューションを作成するためのその他のベスト プラクティスについては、「セキュリティで保護されたアドインを開発する」を参照してください。

「クリックジャック」を防止するためのヒント

Office アドインは、Office クライアント アプリケーションを使用してブラウザーで実行するときに iframe でレンダリングされるため、次のヒントを使用して 、クリックジャッキング のリスクを最小限に抑えます。これは、ハッカーがユーザーをだまして機密情報を明らかにするために使用する手法です。

まず、アドインが実行できる機密性の高いアクションを特定します。 これには、未承認のユーザーが悪用できる、財務トランザクションの開始や機密データの公開などのアクションが含まれます。 たとえば、アドインが支払いをユーザー定義の受信者に送信できる場合があります。

2 番目に、機密性の高いアクションでは、アドインがアクションを実行する前に、ユーザーに確認を求める必要があります。 この確認では、アクションの影響を詳細に示す必要があります。 また、「許可しない」と書かれた特定のボタンを選択するか、確認を無視することで、必要に応じてユーザーがアクションを止める方法も詳細に示す必要があります。

第 3 に、脅威アクターが確認を非表示またはマスクできないようにするには、アドインのコンテキストの外部 (つまり、HTML ダイアログ ボックスではなく) に表示する必要があります。

確認を取得する方法の例を次に示します。

• 確認のリンクが含まれている電子メールをユーザーに送信します。

• ユーザーがアドインで入力できる確認コードが含まれているテキスト メッセージをユーザーに送信します。

• iframe に対応していないページについて、新しいブラウザー ウィンドウで確認ダイアログを開きます。 これは通常、ログイン ページで使用するパターンです。 新しいダイアログを作成するには、ダイアログ API を使用します。

また、ユーザーへの連絡に使用するアドレスが、脅威アクターによって提供されていないことを確認します。 たとえば、支払いの確認には、承認されたユーザーのアカウントに関するファイル内のアドレスを使用します。

その他のセキュリティ手法

開発者は、次のセキュリティ プラクティスにも注意する必要があります。

• ActiveX コントロールはアドイン プラットフォームのクロス プラットフォームの特性をサポートしていないため、開発者は Office アドインで ActiveX コントロールを使用しないでください。

• コンテンツアドインと作業ウィンドウ アドインは、ブラウザーが既定で使用するのと同じ SSL 設定を前提としており、ほとんどのコンテンツを SSL によってのみ配信できます。 Outlook アドインは、すべてのコンテンツが SSL で提供されている必要があります。 開発者は、 <アドイン マニフェストの SourceLocation> 要素で HTTPS を使用する URL を指定して、アドインの HTML ファイルの場所を識別する必要があります。

  アドインが HTTP を使用してコンテンツを配信しないようにするには、アドインをテストするときに、コントロール パネルの [インターネット オプション]で次の設定が選択され、テスト シナリオにセキュリティ警告が表示されないようにする必要があります。

  • インターネット ゾーンのセキュリティ設定 [混合コンテンツの表示] が [プロンプト] に設定されていることを確認します。 これを行うには 、[インターネット オプション] で次を選択します。 [セキュリティ ] タブで、 インターネット ゾーンを選択し、[ カスタム レベル] を選択し、[スクロール] を選択して [ 混合コンテンツの表示] を探し、[まだ選択されていない場合は プロンプト ] を選択します。

  • [インターネット オプション] ダイアログ ボックスの [詳細設定] タブで、[保護付き/保護なしのサイト間を移動する場合に警告する] が選択されていることを確認します。

• アドインで CPU コアやメモリ リソースが過剰に使用され、クライアント コンピューターでサービス拒否が発生しないように、アドイン プラットフォームにはリソース使用量の上限が設けられています。 開発者はテストの一環として、アドイン プラットフォームがリソース使用量の上限を超えていないかどうかを確認する必要があります。

• 開発者はアドインを発行する前に、アドイン ファイルで公開される個人を識別できる情報が保護されていることを確認する必要があります。

• 開発者は、Microsoft などの API やサービス (Bing、Google、Facebookなど) にアクセスするために使用するキーをアドインの HTML ページに直接埋め込むべきではありません。 代わりに、カスタム Web サービスを作成するか、キーを安全な Web ストレージの他の形態で保存して、キー値をアドインに渡すために呼び出すことができるようにする必要があります。

• 開発者は、AppSource にアドインを送信するときに、次の操作を行う必要があります。

  • SSL をサポートする Web サーバーで、提出するアドインをホストする。
  • 法規制に準拠したプライバシー ポリシーを記載した声明を作成する。
  • アドインの提出時に契約合意書に署名する。

Outlook アドインの開発者は、リソース使用量のルール以外に、アクティブ化ルールの指定と JavaScript API の使用に関する制限についてもアドインが遵守していることを確認する必要があります。 詳細については、「Outlook アドインのアクティブ化と JavaScript API に関する制限事項」を参照してください。

IT 管理者による制御

企業の設定では、IT 管理者は、AppSource とプライベート カタログへのアクセスの有効化または無効化に対して最終的な権限を持ちます。

Office 設定の管理と適用はグループ ポリシー設定で行われます。 これらは、Office カスタマイズ ツールと共に Office 展開ツールを介して構成できます。

設定名	説明
セキュリティで保護されていないアドインとカタログの許可	セキュリティで保護されていない Office アドインを実行できます。これは、Web ページまたはカタログの場所が SSL で保護されていない (https://) Office アドインであり、ユーザーのインターネット ゾーンに存在しません。
Web アドインのブロック	ユーザーが Web テクノロジを使用する Office アドインを実行できないようにすることができます。
Office ストアのブロック	ユーザーが AppSource から提供される Office アドインを取得または実行できないようにすることができます。

関連項目

• アドインでの API 使用についてアクセス許可を要求する
• Outlook アドインに関するプライバシー、アクセス許可、セキュリティ
• Outlook アドインのアクセス許可を理解する
• Outlook アドインのアクティブ化と JavaScript API の制限
• Office アドインにおける同一生成元ポリシーの制限への対処
• 同一生成元ポリシー
• 同一生成元ポリシー パート 1:ピーク禁止
• JavaScript の同一生成元ポリシー
• IE 保護モード
• Microsoft 365 アプリのプライバシー コントロール