アプリ保護ポリシーの概要

  • [アーティクル]

Intune アプリ保護ポリシー (APP) は、organizationのデータが安全であるか、マネージド アプリに含まれていることを保証するルールです。 これらのポリシーを使用すると、モバイル デバイス上のアプリでデータにアクセスして共有する方法を制御できます。 ポリシーの例としては、ユーザーが "企業" データへのアクセスまたは移動を試みた場合や、アプリ内で禁止または監視されている一連の操作を試みた場合に適用されるルールがあります。 Intune のマネージド アプリは、Intune アプリ保護ポリシーが適用され、Intune によって管理される 保護された アプリです。

Intune アプリ保護ポリシーを使用すると、デバイスの登録を必要とせずにモバイル デバイス上の企業データを保護したり、モバイル デバイス上のアプリによるデータのアクセスと共有方法を制御したりするなど、いくつかの 利点 があります。

Microsoft Intuneでアプリ保護ポリシーを使用する例を次に示します。

  • モバイル デバイスで会社のメールにアクセスするために PIN または指紋を要求する
  • ユーザーが会社のデータをコピーして個人用アプリに貼り付けないようにする
  • 承認されたアプリのみに企業データへのアクセスを制限する

Microsoft 365 (Office) アプリなどの多くの生産性アプリは、Intune MAM を使用して管理できます。 一般使用が可能な Microsoft Intune の保護されたアプリの公式一覧を参照してください。

アプリ データを保護する方法

従業員は、個人用タスクと仕事用タスクの両方にモバイル デバイスを使用します。 従業員の生産性を確保しながら、意図的および意図的でないデータ損失を防ぎたいはずです。 また、自分が管理していないデバイスからアクセスする会社のデータも保護する必要があります。

Intune のアプリ保護ポリシーはあらゆるモバイル デバイス管理 (MDM) ソリューションとの依存関係なしで使用できます。 この独立性により、デバイスをデバイス管理ソリューションに登録してもしなくても会社のデータを保護できます。 アプリレベル ポリシーを実装するだけで、会社のリソースへのアクセスを制限し、データを IT 部門の管理範囲内に保つことができます。

デバイスでのアプリ保護ポリシー

アプリ保護ポリシーは、次のようなデバイスで実行されているアプリ向けに構成できます。

  • Microsoft Intune に登録されているデバイス: このようなデバイスは通常、企業所有です。

  • サード パーティのモバイル デバイス管理 (MDM) ソリューションに登録されています。 通常、これらのデバイスは企業所有です。

    注:

    モバイル アプリ管理ポリシーを、サード パーティのモバイル アプリ管理ソリューションやセキュア コンテナー ソリューションとともに使用しないでください。

  • いずれのモバイル デバイス管理ソリューションにも登録されていないデバイス: これらのデバイスは、通常、Intune またはその他の MDM ソリューションで管理も登録もされていない社員所有のデバイスです。

重要

Microsoft 365 サービスに接続する Office モバイル アプリ向けのモバイル アプリ管理ポリシーを作成することができます。 ハイブリッドの最新認証に対応する iOS/iPadOS および Android 用の Outlook のために Intune アプリ保護ポリシーを作成することで、Exchange オンプレミス メールボックスへのアクセスも保護できます。 この機能を使用する前に、iOS/iPadOS および Android 用 Outlook の要件を満たしていることを確認します。 アプリ保護ポリシーは、オンプレミス Exchange サービスや SharePoint サービスに接続する他のアプリではサポートされていません。

アプリ保護ポリシーを利用した場合のメリット

アプリ保護ポリシーを利用した場合の重要なメリットとして、以下が挙げられます。

  • アプリ レベルで会社のデータを保護します。 モバイル アプリ管理にはデバイス管理が必要ないため、マネージド デバイスとアンマネージド デバイスの両方で会社データを保護することができます。 管理の中心がユーザー ID になり、デバイスを管理する必要がなくなります。

  • エンド ユーザーの生産性に影響を与えることがなく、個人のコンテキストでアプリが使用される場合にはポリシーは適用されません。 ポリシーは仕事のコンテキストでのみ適用されるため、個人データに影響を与えることなく会社データを保護することが可能になります。

  • アプリ保護ポリシーにより、アプリレイヤーの保護が確実に実施されます。 たとえば、次のようなことが可能です。

    • 仕事ではアプリを開くとき、PIN を要求する
    • アプリ間のデータ共有を制御する
    • 会社アプリのデータを個人ストレージの場所に保存することを禁止する

  • MAM だけでなく MDM を使用することで、確実にデバイスを保護できます。 たとえば、デバイスへのアクセスに PIN を要求したり、デバイスに管理対象のアプリを展開したりすることができます。 また、MDM ソリューションを介してデバイスにアプリを展開することにより、アプリ管理をより制御できるようになります。

MDM をアプリ保護ポリシーと共に使用することで、MDM ありのアプリ保護ポリシーと MDM なしのアプリ保護ポリシーを社内で同時に使用できるという、新たなメリットが得られます。 たとえば、会社で支給されたスマートフォンと自分のタブレットの両方を使用する社員がいるとします。 会社のスマートフォンは MDM に登録されたうえでアプリ保護ポリシーによって保護されますが、個人のデバイスはアプリ保護ポリシーのみで保護されます。

デバイスの状態を設定せず、ユーザーに MAM ポリシーを適用する場合、ユーザーは、BYOD デバイスと Intune マネージド デバイスの両方で MAM ポリシーを取得します。 管理されている状態に基づいて、MAM ポリシーを適用することもできます。 したがって、アプリ保護ポリシーを作成する場合、[すべてのアプリの種類を対象にする] の横の [いいえ] を選択します。 次に以下のいずれかを実行します。

  • Intune マネージド デバイスに制限が緩い MAM ポリシーを適用し、MDM が登録されていないデバイスにより制限の厳しい MAM ポリシーを適用します。
  • 登録解除されたデバイスのみに MAM ポリシーを適用します。

アプリ保護ポリシーでサポートされているプラットフォーム

Intune には、アプリを実行するデバイスに必要なアプリを取得できるように、さまざまな機能が用意されています。 詳細については、「App management capabilities by platform (プラットフォーム別のアプリ管理機能)」を参照してください。

Intune アプリ保護ポリシーのプラットフォーム サポートは、Android および iOS/iPadOS デバイス向けの Office モバイル アプリケーションのプラットフォーム サポートと連携しています。 詳細については、Office システム要件の「モバイル アプリ」セクションを参照してください。

プレビュー: さらに、Windows デバイスのアプリ保護ポリシーを作成することもできます。 詳細については、「Windows デバイスのアプリ保護エクスペリエンス」を参照してください。

重要

Android でアプリ保護ポリシーを受信するには、デバイスに Intune ポータル サイトが必要です。

APP 保護ポリシーのデータ保護フレームワーク

アプリ保護ポリシー (APP) で利用できる選択肢を使用することで、組織は固有のニーズに合わせて保護を調整できます。 場合によっては、完全なシナリオを実装するためにどのポリシー設定が必要であるかが明確ではないことがあります。 組織がモバイル クライアント エンドポイントのセキュリティ強化を優先できるよう、Microsoft では、iOS および Android モバイル アプリ管理のための APP データ保護フレームワークの分類を導入しました。

APP データ保護フレームワークは 3 つの異なる構成レベルに編成されており、各レベルは前のレベルを基に構築されています。

  • エンタープライズ基本データ保護 (レベル 1) では、アプリが PIN で保護され、暗号化されており、選択的ワイプ操作を実行できるようにします。 Android デバイスの場合、このレベルでは Android デバイスの構成証明を検証します。 これは、Exchange Online メールボックス ポリシーに類似したデータ保護制御を提供し、IT 部門およびユーザー集団に APP を経験させる、エントリ レベルの構成です。
  • エンタープライズ拡張データ保護 (レベル 2) では、APP データ漏えい防止メカニズムと OS の最小要件が導入されています。 この構成は、職場または学校のデータにアクセスするほとんどのモバイル ユーザーに適用されます。
  • エンタープライズ高度データ保護 (レベル 3) では、高度なデータ保護メカニズム、強化された PIN の構成、および APP Mobile Threat Defense が導入されています。 この構成は、危険度の高いデータにアクセスするユーザーに適しています。

各構成レベルおよび、最低限保護する必要のあるアプリに関する具体的な推奨事項については、「アプリ保護ポリシーを使用するデータ保護フレームワーク」を参照してください。

アプリ保護ポリシーでアプリのデータを保護するしくみ

アプリ保護ポリシーのないアプリ

アプリが制限なしで使用されている場合、会社データと個人データが混在する可能性があります。 会社データが個人の記憶域に保存されたり、管理範囲外のアプリに転送されたりして、データ損失を招くことがあります。 次の図の矢印は企業アプリと個人アプリの間のデータ移動やストレージの場所へのデータ移動を示しており、データ移動は制限されていません。

ポリシーが定められていないアプリ間のデータ移動の概念図

アプリ保護ポリシー (APP) によるデータ保護

アプリ保護ポリシーを使用して、デバイスのローカル ストレージに会社のデータが保存されることを禁止できます (下の画像を参照)。 また、アプリ保護ポリシーで保護されていない他のアプリへのデータ移動を制限できます。 アプリ保護ポリシー設定には以下のようなものがあります。

  • 組織データのコピーを保存する、切り取り、コピー、貼り付けを制限するなどのデータ再配置ポリシー。
  • アクセスの際にシンプルな PIN を要求する、脱獄されたデバイスまたは root 化されたデバイスで管理対象アプリが実行されることを禁止するなど、アクセス ポリシー設定。

ポリシーによって保護されている会社のデータを示す概念図

MDM ソリューションによって管理されるデバイス上での APP によるデータ保護

下の図は、MDM とアプリ保護ポリシーの連携によって提供される保護層を示しています。

BYOD デバイスでアプリ保護ポリシーが機能するしくみを示す画像

MDM ソリューションでは、次のことを行うと値が追加されます。

  • デバイスを登録する
  • アプリをデバイスに展開する
  • 継続的なデバイスのポリシー準拠と管理を提供する

アプリ保護ポリシーでは、次のことを行うと値が追加されます。

  • コンシューマー アプリやサービスに会社データがリークしないように保護を支援する
  • "名前を付けて保存"、"クリップボード"、PIN などの制限をクライアント アプリに適用する
  • デバイスからアプリを削除せずに、必要時にアプリから会社データをワイプする

登録のないデバイスに対する APP によるデータ保護

以下の図は、MDM がない場合にアプリ レベルでデータ保護ポリシーが機能するしくみを示しています。

登録のないデバイス (非マネージド デバイス) 上でアプリ保護ポリシーが機能するしくみを示した画像

MDM ソリューションに登録されていない BYOD デバイスでは、アプリ保護ポリシーによってアプリ レベルで会社のデータを保護できます。 ただし、次のようないくつかの制約があることに注意してください。

  • アプリをデバイスに展開することはできません。 アプリはエンドユーザーがストアから入手する必要があります。
  • これらのデバイスで証明書プロファイルをプロビジョニングすることはできません。
  • 会社が Wi-Fi や VPN の設定をこれらのデバイスにプロビジョニングすることはできません。

アプリ保護ポリシーで管理できるアプリ

Intune SDK と統合されているアプリや Intune App Wrapping Tool によってラップされているすべてのアプリは、Intune アプリ保護ポリシーを使用して管理できます。 これらのツールを使用して構築されている一般使用が可能な Microsoft Intune による保護アプリの公式一覧を参照してください。

Intune SDK 開発チームは、ネイティブの Android、iOS/iPadOS (Obj-C、Swift)、Xamarin、および Xamarin.Forms プラットフォームを使ってビルドされたアプリに対するサポートを、積極的にテストして管理しています。 一部のお客様は、Intune SDK とその他のプラットフォーム (React Native や NativeScript など) の統合に成功されていますが、Microsoft では、サポートされているプラットフォーム以外を使うアプリ開発者に向けた明示的なガイダンスやプラグインは提供されません。

アプリ保護ポリシーを使用するためのエンドユーザーの要件

次の一覧に、Intune マネージド アプリ上でアプリ保護ポリシーを使用するためのエンドユーザーの要件を示します。

  • エンド ユーザーには、Microsoft Entra アカウントが必要です。 Microsoft Entra IDで Intune ユーザーを作成する方法については、「ユーザーの追加と Intune への管理アクセス許可の付与」を参照してください。

  • エンド ユーザーには、Microsoft Entra アカウントに割り当てられているMicrosoft Intuneのライセンスが必要です。 Intune ライセンスをエンドユーザーに割り当てる方法については、「Intune のライセンスを管理する」を参照してください。

  • エンド ユーザーは、アプリ保護ポリシーの対象となるセキュリティ グループに属している必要があります。 同じアプリ保護ポリシーは、使用している特定のアプリを対象にしている必要があります。 アプリ保護ポリシーは、Microsoft Intune管理センターで作成および展開できます。 セキュリティ グループは現在のところ、Microsoft 365 管理センターで作成できます。

  • エンド ユーザーは、Microsoft Entra アカウントを使用してアプリにサインインする必要があります。

Microsoft 365 (Office) アプリのアプリ保護ポリシー

Microsoft 365 (Office) アプリでアプリ保護 ポリシーを使用する場合に注意する必要がある追加の要件がいくつかあります。

Outlook モバイル アプリ

Outlook モバイル アプリを使用するための追加要件には、以下が含まれます。

  • エンドユーザーが、Outlook モバイル アプリをデバイスにインストールしている必要があります。

  • エンド ユーザーには、Microsoft 365 Exchange Online メールボックスとライセンスがMicrosoft Entra アカウントにリンクされている必要があります。

    注:

    現段階では、Outlook モバイル アプリは Microsoft Exchange Online とハイブリッド先進認証を使用する Exchange Server のみをサポートし、Office 365 専用の Exchange はサポートされていません。

Word、Excel、PowerPoint

Word、Excel、PowerPoint アプリを使用するための追加要件には、以下が含まれます。

  • エンド ユーザーは、Microsoft Entra アカウントにリンクされたMicrosoft 365 Apps for businessまたはエンタープライズのライセンスを持っている必要があります。 サブスクリプションには、モバイル デバイスの Office アプリが含まれている必要があります。また、OneDrive for Business のクラウド ストレージ アカウントを含めることも可能です。 Microsoft 365 ライセンスは、Microsoft 365 管理センターで割り当てることができます。こちらの手順に従ってください。

  • エンド ユーザーは、[組織データのコピーを保存] アプリケーション保護ポリシー設定の機能として、詳細保存を使用して管理対象の場所を構成しておく必要があります。 たとえば、管理対象の場所が OneDrive の場合、OneDrive アプリは、エンド ユーザーの Word アプリ、Excel アプリ、または PowerPoint アプリ内で構成される必要があります。

  • 管理対象の場所が OneDrive の場合、アプリは、エンド ユーザーに展開されているアプリの保護ポリシーの対象となる必要があります。

    注:

    現段階では、Office モバイル アプリは SharePoint Online のみをサポートし、オンプレミスの SharePoint はサポートされていません。

Office に必要な管理される場所

Office には、管理される場所 (OneDrive など) が必要です。 Intune では、アプリ内のすべてのデータが "企業" または "個人用" のいずれかとしてマークされます。 勤務地から送信されたデータは "企業" データと見なされます。 Office アプリについては、Intune では電子メール (Exchange) またはクラウド ストレージ (OneDrive for Business アカウントを使用した OneDrive アプリ) が勤務地と見なされます。

Skype for Business

Skype for Business を使用するためには、追加要件があります。 Skype for Business のライセンス要件を参照してください。 Skype for Business (SfB) ハイブリッド構成とオンプレミス構成については、「Hybrid Modern Auth for SfB」および「Exchange は GA と Modern Auth for SfB OnPrem with Microsoft Entra ID」を参照してください。

アプリ保護グローバル ポリシー

OneDrive 管理者が admin.onedrive.com にアクセスし、[デバイス アクセ]スを選択するとき、クライアント アプリの OneDrive と SharePoint にモバイル アプリケーション管理コントロールを設定できます。

OneDrive 管理コンソールで利用可能になった設定により、グローバル ポリシーという名称の特別な Intune アプリ保護ポリシーが構成されます。 このグローバル ポリシーはテナント内のすべてのユーザーに適用され、ポリシーの対象を制御する手段はありません。

iOS/iPadOS 用および Android 用の OneDrive アプリと SharePoint アプリを有効にすると、既定により、選択された設定でそのアプリが保護されます。 IT 担当者は、Microsoft Intune管理センターでこのポリシーを編集して、より多くのターゲット アプリを追加したり、ポリシー設定を変更したりできます。

既定では、グローバル ポリシーはテナントごとに 1 つだけとなります。 ただし、推奨されませんが、Intune Graph API を使用し、テナントごとにグローバル ポリシーを追加で作成することは可能です。 グローバル ポリシーを追加で作成することが推奨されないのは、そのようなポリシーを実装するとトラブルシューティングが複雑になる可能性があるためです。

グローバル ポリシーはテナントのすべてのユーザーに適用されますが、標準 Intune アプリ保護ポリシーによってオーバーライドされます。

注:

OneDrive 管理センターのポリシー設定はもう更新されていません。 代わりにMicrosoft Intuneを使用できます。 詳細については、「OneDrive および SharePoint モバイル アプリの機能へのアクセスを制御する」を参照してください。

アプリ保護機能

複数の ID

複数 ID のサポートを利用すると、アプリでは複数の対象ユーザーをサポートできます。 これらの対象ユーザーは、"企業" ユーザーと "個人" ユーザーの両方です。 職場と学校のアカウントは "企業" 対象ユーザーによって使用されますが、個人アカウントは Microsoft 365 (Office) ユーザーなどのコンシューマー対象ユーザーに使用されます。 複数 ID をサポートするアプリは、一般向けにリリースすることができます。その際、アプリ保護ポリシーは、アプリが職場および学校 ("企業") のコンテキストで使用されている場合にのみ適用されます。 複数 ID をサポートする場合、Intune SDK を利用して、アプリにサインインしている職場または学校のアカウントにのみアプリ保護ポリシーが適用されます。 個人用アカウントでアプリにサインインした場合、データは管理されません。 アプリ保護ポリシーを使用すると、職場または学校アカウントのデータを、複数 ID アプリ内の個人用アカウント、他のアプリ内の個人用アカウント、または個人用アプリに転送できないようにすることができます。

重要

アプリがマルチ ID をサポートするかどうかに関係なく、Intune アプリ保護ポリシーを適用できるのは単一の "企業" ID のみです。

"個人" のコンテキストの例としては、Word で新規ドキュメントに着手するユーザーがいるとした場合、これは個人のコンテキストと見なされるため、Intune App Protection ポリシーは適用されません。 ドキュメントが "企業" の OneDrive アカウントに保存されると、それは "企業" のコンテキストと見なされ、Intune App Protection ポリシーが適用されます。

職場または "企業" のコンテキストに関する次の例を考えてみましょう。

  • あるユーザーが、職場アカウントを使用して OneDrive アプリを起動します。 仕事のコンテキストである場合、個人ストレージの場所にファイルを移動することができません。 後で、個人のアカウントで OneDrive を使用するとき、個人の OneDrive から制限なしでデータをコピーしたり、移動したりできます。
  • あるユーザーが、Outlook アプリでメールの下書きを始めます。 件名またはメッセージ本文が入力されると、ユーザーは差出人アドレスを職場コンテキストから個人用コンテキストに切り替えることができなくなります。件名とメッセージ本文はアプリ保護ポリシーによって保護されているためです。

注:

Outlook では、"個人" と "企業" 両方の電子メールが組み合わさった電子メール表示になっています。 この場合、Outlook アプリでは、起動時に Intune PIN の入力が求められます。

重要

Edge は "企業" のコンテキスト内にありますが、ユーザーは OneDrive の "企業" のコンテキスト ファイルを不明な個人のクラウド ストレージの場所に意図的に移動できます。 これを回避するには、制限された Web サイトを管理する方法に関する記事を参照して、許可またはブロックされたサイトのリストを Edge 用に構成します。

Intune アプリの PIN

暗証番号 (PIN) は、アプリケーションで適切なユーザーが組織のデータにアクセスしていることを確認するために使用されるパスコードです。

PIN の入力要求
Intune では、ユーザーが "企業" データにアクセスしようとした場合にアプリの PIN が要求されます。 Word、Excel、PowerPoint などの複数 ID アプリでは、"企業" のドキュメントやファイルを開こうとすると、ユーザーは PIN の入力を求められます。 Intune App Wrapping Tool を使用して管理されている基幹業務アプリなど、単一 ID のアプリでは、起動時に PIN の入力が求められます。アプリ内のユーザーのエクスペリエンスが常に "企業向け" であることが Intune SDK によって把握されるためです。

PIN プロンプト、または会社の資格情報プロンプト、頻度
IT 管理者は、Intune アプリ保護ポリシー設定を定義し、Microsoft Intune管理センターで (分) 後にアクセス要件を再確認できます。 この設定では、デバイスで、アクセス要件がチェックされ、アプリケーションの PIN 画面、あるいは会社の資格情報プロンプトが再度表示されるまでの時間を指定します。 ただし、PIN に関する以下の内容は重要であり、ユーザーが入力を求められる頻度に影響を与えます。

  • 使いやすさの向上のために、同じ公開元のアプリで PIN が共有されます:
    iOS/iPadOS では、1 つのアプリの PIN が、同じ発行元のすべてのアプリ間で共有されます。 たとえば、すべての Microsoft アプリで同じ PIN を共有します。 Android では、アプリの PIN はすべてのアプリで共有されます。
  • デバイス再起動後の [(分数) 後に、アクセス要件を再確認する] の動作:
    タイマーは非アクティブな時間の分数を追跡し、Intune アプリの PIN、あるいは会社の資格情報プロンプトを次に表示するタイミングを決定します。 iOS/iPadOS では、タイマーはデバイスの再起動による影響を受けません。 そのため、デバイスの再起動は、Intune PIN (または会社の資格情報) ポリシーの対象となる iOS/iPadOS アプリに対してユーザーが非アクティブになっている分数に影響しません。 Android では、タイマーはデバイスの再起動時にリセットされます。 そのため、Intune PIN (あるいは会社の資格情報) ポリシーを使用する Android アプリは、[(分数) 後に、アクセス要件を再確認する] の設定値に関係なく、デバイスの再起動後にアプリの PIN、あるいは会社の資格情報プロンプトを要求する場合があります。
  • PIN に関連付けられたタイマーのローリングという性質:
    PIN を入力してアプリ (アプリ A) にアクセスし、その後、そのアプリがデバイス上のフォアグラウンド (メイン入力フォーカス) を離れると、その PIN のタイマーがリセットされます。 タイマーがリセットされるため、この PIN を共有するアプリ (アプリ B) では、PIN の入力は求められません。 "(分数) 後にアクセス要件を再確認する" の値がもう一度満たされると、再度プロンプトが表示されます。

iOS/iPadOS デバイスの場合、発行元が異なるアプリ間で PIN を共有する場合でも、メイン入力フォーカスではないアプリに対して、[(分数) 後にアクセス要件を再確認する] の値が再び満たされると、プロンプトが再表示されます。 そこで、たとえば、ユーザーに発行元 X からのアプリ A と発行元 Y からのアプリ B があるとき、それら 2 つのアプリで同じ PIN が共有されているとします。 ユーザーのフォーカスがアプリ A (前景) にあり、アプリ B は最小化されています。 [(分数) 後にアクセス要件を再確認する] 値が満たされ、ユーザーがアプリ B に切り替えると、PIN が必要になります。

注:

ユーザーのアクセス要件の確認頻度をあげるために (PIN のプロンプト)、特に頻繁に使用するアプリにおいて、"(分数) 後にアクセス要件を再確認する" の設定値を下げることをお勧めします。

Outlook および OneDrive 用の組み込みアプリの PIN
Intune PIN は、非アクティブ状態をベースとするタイマー ([(分数) 後に、アクセス要件を再確認する] の値) を基にして機能します。 そのため、Intune PIN プロンプトは、既定でアプリの起動に関連付けられていることが多い Outlook および OneDrive 用の組み込みのアプリ PIN プロンプトとは独立して表示されます。 ユーザーに両方の PIN プロンプトが同時に表示される場合、Intune PIN が優先される動作が予想されます。

Intune PIN のセキュリティ
PIN は、アプリで適切なユーザーのみが組織のデータにアクセスできるようにするためのものです。 そのため、エンドユーザーが Intune アプリの PIN を設定またはリセットするには、職場または学校のアカウントを使用してサインインする必要があります。 この認証は、セキュリティで保護されたトークン交換を介してMicrosoft Entra IDによって処理され、Intune SDK に対して透過的ではありません。 セキュリティの観点からは、職場または学校のデータを保護する最も効果的な方法は暗号化です。 暗号化はアプリの PIN とは関係しませんが、独自のアプリ保護ポリシーと関係があります。

ブルート フォース攻撃からの保護と Intune PIN
IT 管理者は、アプリの PIN ポリシーの一環として、アプリがロックされるまでにユーザーが PIN の認証を試みることのできる最大回数を設定できます。 試行回数に達すると、Intune SDK によってアプリ内の "企業" データをワイプできます。

Intune PIN と選択的ワイプ
iOS/iPadOS では、アプリ レベルの PIN 情報が、同じ発行元のアプリ (すべてのファースト パーティの Microsoft アプリなど) 間で共有されるキーチェーンに格納されます。 この PIN 情報は、エンド ユーザー アカウントにも関連付けられます。 1 つのアプリの選択的ワイプは、別のアプリには影響しません。

たとえば、Outlook に対して、サインインしているユーザー用に設定された PIN は、共有キーチェーンに格納されます。 ユーザーが OneDrive (これも発行元は Microsoft です) にサインインすると、Outlook と同じ PIN が表示されます。同じ共有キーチェーンが使われているためです。 Outlook からサインアウトしたり、Outlook でユーザー データをワイプしたりしても、Intune SDK によってそのキーチェーンがクリアされることはありせん。OneDrive で引き続きその PIN が使用されている可能性があるためです。 このため、選択的ワイプによって PIN を含むその共有キーチェーンがクリアされることはありません。 このような動作は、発行元のアプリがデバイス上に 1 つしか存在しない場合でも変わりません。

PIN は同じ発行元のアプリ間で共有されるため、単一のアプリに対してワイプが行われた場合に、Intune SDK では同じ発行元の他のアプリがデバイス上に存在するかどうかが把握されません。 そのため、Intune SDK ではその PIN がクリアされません。他のアプリでも使用される可能性があるためです。 その発行元の最後のアプリが、何らかの OS のクリーンアップの一環として最終的に削除されたときに、そのアプリの PIN がワイプされることが予想されます。

一部のデバイスで PIN がワイプされていることを確認した場合、おそらく次のような状況が発生します。PIN は ID に関連付けられているため、ワイプ後にユーザーが別のアカウントでサインインしていた場合は、新しい PIN を入力するように求められます。 ただし、そのユーザーが前から存在していたアカウントでサインインした場合は、既にキーチェーンに格納されている PIN を使ってサインインすることができます。

同じ発行元のアプリ上で PIN を 2 回設定するか
MAM (iOS/iPadOS 上) では、現在、アプリケーションレベルの PIN と英数字と特殊文字 ("パスコード" と呼ばれます) を使用できます。これには、アプリケーション (WXP、Outlook、Managed Browser、Viva Engage) の参加が必要で、Intune SDK for iOS が統合されます。 これを行わないと、パスコードの設定が対象のアプリケーションに正しく適用されません。 これは、Intune SDK for iOS v. 7.1.12 でリリースされた機能です。

この機能をサポートし、iOS/iPadOS 用 Intune SDK の以前のバージョンとの下位互換性を確保するために、7.1.12 以降の PIN は (数値のものもパスコードも) すべて、以前のバージョンの SDK で使用された数値からなる PIN とは別に扱われます。 もう 1 つの変更点は、Intune SDK for iOS v 14.6.0 で導入され、14.6.0 以上のすべての PIN が以前のバージョンの SDK の PIN とは別に処理されます。

そのため公開元が同じで、7.1.12 よりも前のバージョンと後のバージョン (または 14.6.0 よりも前のバージョンと後のバージョン) の iOS 用 Intune SDK を使用するアプリケーションが、1 つのデバイス上に "両方とも" ある場合、PIN を 2 つ設定する必要があります。 (各アプリの) 2 つの PIN には、いかなる関連性もありません (つまり、アプリに適用されるアプリ保護ポリシーに従う必要があるということです)。 そのため、アプリ A と B に対して、(PIN に関して) 同じポリシーを適用できる場合に "のみ"、ユーザーは同じ PIN を 2 回設定できます。

これは、Intune モバイル アプリの管理が有効になっている iOS/iPadOS アプリケーション上の PIN に固有の動作です。 時間の経過とともに、新しいバージョンの iOS/iPadOS 用 Intune SDK が採用されていくと、同じ発行元のアプリに 1 つの PIN を 2 回設定しなくてはならないことは問題ではなくなっていきます。 例については、以下の注記をご覧ください。

注:

たとえば、アプリの発行元が同じで、アプリ A が 7.1.12 (または 14.6.0) よりも前のバージョンでビルドされ、アプリ B が 7.1.12 (または 14.6.0) 以上のバージョンでビルドされていて、A と B の両方が 1 つの iOS/iPadOS デバイスにインストールされている場合、エンド ユーザーは A と B に個別の PIN を設定する必要があります。

SDK バージョン 7.1.9 (または 14.5.0) を持つアプリ C がデバイスにインストールされている場合、アプリ A と同じ PIN が共有されます。

7.1.14 (または 14.6.2) でビルドされたアプリ D は、アプリ B と同じ PIN を共有します。

1 つのデバイスに アプリ A とアプリ C だけがインストールされている場合、設定する必要がある PIN は 1 つです。 1 つのデバイスに アプリ B とアプリ D だけがインストールされている場合も同様です。

アプリ データの暗号化

IT 管理者は、アプリ データの暗号化を必須にするアプリ保護ポリシーを展開できます。 ポリシーの一環として、IT 管理者はコンテンツがいつ暗号化されるかを指定することもできます。

Intune データ暗号化の処理方法
暗号化のアプリ保護ポリシー設定の詳細については、Android アプリ保護ポリシーの設定と iOS/iPadOS アプリ保護ポリシーの設定に関する各記事を参照してください。

暗号化されたデータ
IT 管理者のアプリ保護ポリシーに従い、"企業" データとしてマークされたデータのみが暗号化されます。 勤務地から送信されたデータは "企業" データと見なされます。 Office アプリの場合、Intune では、以下をビジネスの場所と見なします。

  • 電子メール (Exchange)
  • クラウド ストレージ (OneDrive for Business アカウントを利用する OneDrive アプリ)

Intune アプリ ラッピング ツールによって管理された基幹業務アプリでは、すべてのアプリ データが "企業" と見なされます。

選択的ワイプ

リモートでデータをワイプする
Intune では、3 つの異なる方法でアプリ データをワイプできます。

  • 完全なデバイスのワイプ
  • MDM の選択的なワイプ
  • MAM の選択的なワイプ

MDM のリモート ワイプの詳細については、ワイプまたはインベントリからの削除を使用してデバイスを削除する方法に関するページを参照してください。 MAM を使用した選択的なワイプの詳細については、インベントリからの削除アクションに関するページとアプリから会社のデータのみをワイプする方法に関するページを参照してください。

完全なデバイスのワイプでは、デバイスを出荷時の既定の設定に戻すことにより、すべてのユーザー データと設定がデバイスから削除されます。 デバイスは Intune から削除されません。

注:

完全なデバイスのワイプおよび MDM の選択的なワイプは、Intune モバイル デバイス管理 (MDM) に登録済みのデバイス上でのみ行うことができます。

MDM の選択的なワイプ
会社データの削除については、デバイスの削除 - インベントリからの削除に関するページを参照してください。

MAM の選択的なワイプ
MAM の選択的ワイプは、単にアプリから業務用アプリのデータを削除します。 要求は Intune を使用して開始されます。 ワイプ要求を開始する方法については、アプリから企業データのみをワイプする方法に関するページを参照してください。

選択的なワイプが開始された時点でユーザーがアプリを使用している場合は、Intune SDK によって Intune MAM サービスからの選択的ワイプの要求が 30 分ごとにチェックされます。 ユーザーがアプリを初めて起動し職場または学校のアカウントを使ってサインインした場合も、選択的ワイプがチェックされます。

オンプレミス (on-prem) サービスが Intune の保護対象アプリと連携しない場合
Intune アプリ保護は、アプリケーションと Intune SDK の間で一貫性を保つためにユーザーの ID に依存しています。 これを保証する唯一の方法は、最新の認証を使用することです。 アプリをオンプレミス構成と連携させるシナリオはありますが、一貫性がなく保証されていません。

マネージド アプリから Web リンクを開く安全な方法
IT 管理者は、Intune で簡単に管理可能な Web ブラウザーである Microsoft Edge のアプリ保護ポリシーを展開および設定することができます。 IT 管理者は、Intune 管理対象アプリ内のすべての Web リンクが Managed Browser を使用して開かれるように指定することができます。

iOS デバイスでのアプリ保護のエクスペリエンス

デバイスの指紋 ID または Face ID

Intune アプリ保護ポリシーでは、アプリへのアクセスを制御して、Intune のライセンスがあるユーザーのみを許可することができます。 アプリへのアクセスを制御する方法の 1 つは、Apple の Touch ID または Face ID のいずれかをサポートされているデバイス上で要求することです。 Intune は、デバイスの生体認証データベースに何らかの変更が加えられると、次に非アクティブ状態のタイムアウト値に達したときにユーザーに PIN の入力を求めるように実装されています。 フィンガープリントや顔の追加や削除も、生体認証データの変更に含まれます。 Intune ユーザーが PIN を設定していない場合は、Intune PIN を設定するよう求められます。

このプロセスの目的は、アプリ内にある組織のデータを、アプリ レベルで安全に保護し続けることです。 この機能は iOS/iPadOS でのみ使用可能で、iOS/iPadOS 用 Intune SDK のバージョン 9.0.1 以降を統合するアプリケーションの参加が必要です。 SDK の統合は、対象のアプリケーション上で動作を適用するために必要です。 この統合は、ローリング方式で行われ、特定のアプリケーション チームに依存します。 参加するアプリには、WXP、Outlook、マネージド ブラウザー、Viva Engageなどがあります。

iOS 共有拡張機能

データ転送ポリシーで [マネージド アプリのみ] または [アプリなし] に設定されている場合であっても、iOS/iPadOS 共有拡張機能を使用すると、アンマネージド アプリ内の職場または学校のデータを開くことができます。 Intune アプリ保護ポリシーは、デバイスを管理することなく iOS/iPadOS 共有拡張機能を制御することはできません。 したがって、Intune は "企業" データがアプリの外部で共有される前に、データを暗号化します。 マネージド アプリの外部で "企業" ファイルを開いてみると、この暗号化の動作を確認できます。 ファイルは暗号化されていて、管理対象アプリの外部では開くことができないはずです。

既定では、Intune アプリ保護ポリシーによって、承認されていないアプリケーション コンテンツへのアクセスが禁止されています。 iOS/iPadOS には、ユニバーサル リンクを使用して特定のコンテンツまたはアプリケーションを開く機能があります。

ユーザーがアプリのユニバーサル リンクを無効にするには、Safari でアクセスし、[新規タブで開く] または [開く] を選択します。 Intune アプリ保護ポリシーでユニバーサル リンクを使用するには、ユニバーサル リンクを再度有効にすることが重要です。 エンド ユーザーは、対応するリンクを長押しした後 、Safari で<アプリ名> で開く必要があります。 これにより、追加の保護されたアプリすべてに対して、すべてのユニバーサル リンクをデバイス上の保護されたアプリケーションにルーティングするよう求められます。

同じアプリとユーザーのセットに対する複数の Intune アプリ保護アクセスの設定

エンドユーザー デバイスが会社のアカウントから対象のアプリにアクセスしようとすると、アクセスに関する Intune アプリ保護ポリシーが所定の順序で適用されます。 通常、優先順位は、ワイプ、ブロック、無視できる警告となります。 たとえば、特定のユーザーまたはアプリに適用可能な場合、ユーザーのアクセスをブロックする最小の iOS/iPadOS オペレーティング システム設定の後、iOS/iPadOS バージョンを更新するようユーザーに警告する最小の iOS/iPadOS オペレーティング システム設定が適用されます。 したがって、IT 管理者が最小の iOS オペレーティング システムを 11.0.0.0 に構成し、最小の iOS オペレーティング システム (警告のみ) を 11.1.0.0 に構成した状態で、アプリにアクセスしようとしているデバイスが iOS 10 にあった場合、エンド ユーザーは最小の iOS オペレーティング システム バージョンに対するより制限の厳しい設定に基づいてブロックされ、その結果、アクセスがブロックされます。

さまざまな種類の設定が処理される場合、優先順位は、Intune SDK のバージョン要件、アプリのバージョン要件、iOS/iPadOS オペレーティング システムのバージョン要件の順になります。 その後、同じ順序ですべての種類の設定の警告が確認されます。 ブロックが重要である場合は、Intune 製品チームのガイダンスのみに従って、Intune SDK のバージョン要件を構成することをお勧めします。

Android デバイスでのアプリ保護のエクスペリエンス

注:

アプリ保護 ポリシー (APP) は、共有デバイス モードのない Intune マネージド Android Enterprise 専用デバイスではサポートされていません。 これらのデバイスでは、APP ブロック ポリシーをユーザーに影響を与えずに有効にするには、ポータル サイトインストールが必要です。 アプリ保護 ポリシーは、共有デバイス モードの Intune マネージド Android Enterprise 専用デバイスと、共有デバイス モードを利用する AOSP ユーザーレス デバイスでサポートされます。

Microsoft Teams Android デバイス

Microsoft Teams Android デバイスの Teams アプリは APP をサポートしていません (ポータル サイト アプリを通じてポリシーを受け取りません)。 これは、アプリ保護ポリシー設定が Microsoft Teams Android デバイスの Teams に適用されないことを意味します。 これらのデバイスに対してアプリ保護ポリシーを構成している場合は、Teams デバイス ユーザーのグループを作成し、関連するアプリ保護ポリシーからそのグループを除外することを検討してください。 また、Intune 登録ポリシー、条件付きアクセス ポリシー、Intune コンプライアンス ポリシーを、サポートされている設定に変更することを検討してください。 既存のポリシーを変更できない場合は、[デバイス フィルター]を構成 (除外) する必要があります。 各設定を既存の条件付きアクセス構成と Intune コンプライアンス ポリシーに照らして確認し、サポートされていない設定があるかどうかを確認します。 関連情報については、「Microsoft Teams Rooms デバイスと Teams Android デバイスでサポートされている条件付きアクセスポリシーとIntune デバイス コンプライアンス ポリシー」を参照してください。 Microsoft Teams Roomsに関連する情報については、「条件付きアクセスとMicrosoft Teams RoomsのIntuneコンプライアンス」を参照してください。

デバイスの生体認証

生体認証をサポートする Android デバイスの場合、Android デバイスでサポートされている内容に応じて、エンド ユーザーが指紋または Face Unlock を使用できるようにすることができます。 認証に指紋以外のすべての種類の生体認証を使用できるようにするかどうかを構成できます。 指紋および Face Unlock は、これらの生体認証の種類をサポートするように製造され、正しいバージョンの Android を実行しているデバイスでのみ使用できます。 指紋には Android 6 以降が必要です。また、Face Unlock には Android 10 以上が必要です。

ポータル サイト アプリと Intune アプリの保護

アプリ保護機能の多くはポータル サイト アプリに組み込まれています。 デバイスの登録が不要な場合でも、ポータル サイト アプリは常に必要です。 モバイル アプリケーション管理 (MAM-WE) の場合、エンド ユーザーはデバイスにポータル サイト アプリをインストールするだけでかまいません。

同じアプリとユーザーのセットに対する複数の Intune アプリ保護アクセスの設定

エンドユーザー デバイスが会社のアカウントから対象のアプリにアクセスしようとすると、アクセスに関する Intune アプリ保護ポリシーが所定の順序で適用されます。 一般に、ブロックが優先され、次に無視できる警告が表示されます。 たとえば、特定のユーザー/アプリに適用可能な場合、ユーザーのアクセスをブロックする最小の Android パッチ バージョン設定の後、パッチ アップグレードを実行するようユーザーに警告する最小の Android パッチ バージョン設定が適用されます。 したがって、IT 管理者が最小の Android パッチ バージョンを 2018-03-01 に構成し、最小の Android パッチ バージョン (警告のみ) を 2018-02-01 に構成した状態で、アプリにアクセスしようとしているデバイスがパッチ バージョン 2018-01-01 にあった場合、エンド ユーザーは最小の Android パッチ バージョンに対するより制限の厳しい設定に基づいてブロックされ、その結果、アクセスがブロックされます。

さまざまな種類の設定を処理する場合は、アプリのバージョン要件が優先され、Android オペレーティング システムのバージョン要件と Android パッチ バージョンの要件が続きます。 次に、すべての種類の設定に対して同じ順序で警告がチェックされます。

Android デバイスの Intune アプリ保護ポリシーと Google Play のデバイス整合性チェック

Intune アプリ保護ポリシーは、管理者がエンド ユーザー デバイスに Android デバイス用の Google Play のデバイス整合性チェックを渡す必要がある機能を提供します。 Google Play サービスに関する新しい決定は、Intune サービスによって決められた間隔で IT 管理者に報告されます。 サービス呼び出しの頻度は負荷に基づいて調整されます。そのため、この値は内部で保守管理され、構成できません。 Google デバイスの整合性設定に対して構成された IT 管理者のアクションは、条件付き起動時に Intune サービスに最後に報告された結果に基づいて実行されます。 データがない場合、他の条件付き起動チェックで不合格にならなければアクセスが許可されます。構成証明結果を決定するための Google Play Service の "ラウンドトリップ" がバックエンドで開始し、デバイスが不合格の場合、ユーザーに非同期で指示が求められます。 データが古い場合、最後に報告された結果に基づいてアクセスが拒否または許可されます。同様に、構成証明結果を決定するための Google Play Service の "ラウンドトリップ" が開始し、デバイスが不合格の場合、ユーザーに非同期で指示が求められます。

Android デバイス対応の Intune アプリ保護ポリシーと Google のアプリの確認 API

Intune App Protection ポリシーでは、Google の Android デバイス向けアプリの確認 API 経由で信号を送信することをエンドユーザー デバイスに要求する機能を管理者に提供しています。 この方法はデバイスごとに若干異なります。 一般的なプロセスでは、Google Play ストアに移動し、[ マイ アプリ & ゲーム] をクリックし、最後のアプリ スキャンの結果をクリックすると、[保護の再生] メニューに移動します。 [端末をスキャンしてセキュリティ上の脅威を確認] のトグルが確実にオンになっているようにします。

Google の Play Integrity API

Intune では、Google の Play Integrity API を利用して、登録されていないデバイスの既存のルート検出チェックに追加します。 Google は、ルート化されたデバイスでアプリを実行させない場合に採用するよう、Android アプリ向けにこの API セットを開発し、保守管理しています。 Android Pay アプリなどでこれを組み込んでいます。 Google は行われるルート検出チェックの全体を公表しませんが、デバイスをルート化しているユーザーを検出することがこのような API に期待されます。 そのようなユーザーのアクセスをブロックしたり、ポリシーが有効になっているアプリからそのようなユーザーの企業アカウントを消去したりできます。 基本的な整合性のチェックでは、デバイスの全体的な整合性がわかります。 ルート化されたデバイス、エミュレーター、仮想デバイス、改ざんの兆候があるデバイスは基本的な整合性のチェックで不合格になります。 基本的な整合性と認定デバイスのチェックでは、デバイスと Google のサービスとの互換性がわかります。 Google に認められた、改造されていないデバイスのみがこのチェックに合格します。 不合格になるデバイス:

  • 基本的な整合性のチェックで不合格になるデバイス
  • ブートローダーがロックされていないデバイス
  • カスタム システム イメージ/ROM が含まれるデバイス
  • メーカーが Google 認定に申し込まなかった、あるいは合格しなかったデバイス
  • Android オープン ソース プログラムのソース ファイルから直接構築されたシステム イメージを含むデバイス
  • ベータ版/開発者プレビューのシステム イメージを含むデバイス

技術的な詳細については、 Google の Play Integrity API に関する Google のドキュメントを参照してください。

整合性判定設定と "脱獄/ルート化されたデバイス" 設定を再生する

プレイ整合性の判定では、少なくとも構成証明の結果を決定するための "ラウンドトリップ" が実行される期間は、エンド ユーザーがオンラインである必要があります。 エンド ユーザーがオフラインになっている場合でも、IT 管理者は引き続き [脱獄またはルート化されたデバイス] 設定からの結果の適用を期待できます。 しかし、エンド ユーザーがオフラインになっている時間が長すぎると、[オフラインの猶予期間] の値が作動し、タイマー値に到達すると、ネットワーク アクセスが利用できるようになるまで、職場または学校のデータへのアクセスがすべて遮断されます。 両方の設定をオンにすると、階層的な手法でエンド ユーザー デバイスの正常性が維持されます。これは、エンドユーザーがモバイル端末上で職場または学校のデータにアクセスする場合に重要です。

Google Play プロテクト API と Google Play 開発者サービス

Google Play プロテクトの API を活用するアプリ保護ポリシー設定を利用するには、Google Play 開発者サービスが機能する必要があります。 Play 整合性判定とアプリの脅威スキャンの両方の設定では、Google が決定したバージョンの Google Play Services が正しく機能する必要があります。 これらはセキュリティの領域に属する設定であるため、エンド ユーザーはこれらの設定の対象となっているとき、Google Play 開発者サービスのバージョンが適切でない、あるいは Google Play 開発者サービスにアクセスできない場合はブロックされます。

プレビュー: Windows デバイスのアプリ保護 エクスペリエンス

ポリシー設定には、 データ保護 と 正常性チェックの 2 つのカテゴリがあります。 ポリシーで管理されるアプリという用語は、アプリ保護ポリシーで構成されているアプリを指します。

データの保護

[データ保護] 設定は、組織のデータとコンテキストに影響します。 管理者は、組織保護のコンテキストとの間でデータの移動を制御できます。 組織コンテキストは、指定した組織アカウントからアクセスされるドキュメント、サービス、サイトによって定義されます。 次のポリシー設定は、組織コンテキストに受信した外部データと、組織コンテキストから送信された組織データを制御するのに役立ちます。

正常性チェック

正常性チェックを使用すると、条件付き起動機能を構成できます。 これを行うには、アプリ保護ポリシーの正常性チェック条件を設定する必要があります。 [ 設定] を選択し、組織データにアクセスするためにユーザーが満たす必要がある 値 を入力します。 次に、ユーザーが条件を満たしていない場合に実行する アクション を選択します。 場合によっては、単一の設定に対して複数のアクションを構成できます。

次の手順

Microsoft Intune でアプリ保護ポリシーを作成および展開する方法

Microsoft Intune で利用可能な Android アプリ保護ポリシー設定

Microsoft Intune で利用可能な iOS/iPadOS アプリ保護ポリシー設定