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

Intune アプリ保護ポリシーを使用すると、organizationのデータが安全なままであるか、マネージド アプリに含まれる状態が維持されます。 これらのポリシーを使用すると、モバイル デバイス上のアプリでデータにアクセスして共有する方法を制御できます。 ポリシーは、ユーザーが "企業" データにアクセスまたは移動しようとしたときにルールを適用できます。 また、ユーザーがアプリ内にいるときのアクションを禁止または監視することもできます。 Intune のマネージド アプリは、Intune がアプリ保護ポリシーを適用し、アプリを管理する 保護された アプリです。

Intune アプリ保護ポリシーには、いくつかの 利点があります。 これらの利点には、デバイスの登録を必要とせずにモバイル デバイス上の企業データを保護し、モバイル デバイス上のアプリによってデータにアクセスおよび共有する方法を制御することが含まれます。

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

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

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

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

従業員は、個人用タスクと仕事用タスクの両方にモバイル デバイスを使用します。 従業員の生産性を高めながら、データの損失を防ぎます。 これには、意図的なデータ損失と意図しないデータ損失の両方が含まれます。 また、ユーザーが管理していないデバイスからアクセスする会社のデータも保護します。

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

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

次のデバイスで実行されるアプリのアプリ保護ポリシーを構成します。

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

• Microsoft Mobile 以外のデバイス管理 (MDM) ソリューションに登録されています。 通常、これらのデバイスは企業所有です。

  注:

  Microsoft 以外のモバイル アプリ管理またはセキュリティで保護されたコンテナー ソリューションでは、モバイル アプリ管理ポリシーを使用しないでください。

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

アプリ保護ポリシーを使用する利点

アプリ保護ポリシーを使用する重要な利点は次のとおりです。

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

• ユーザーの生産性は影響を受けず、個人のコンテキストでアプリを使用する場合、ポリシーは適用されません。 Intune では、仕事のコンテキストでのみポリシーが適用されます。これにより、個人データに触れることなく会社のデータを保護できます。

• アプリ保護ポリシーでは、アプリ層の保護が確実に適用されます。 例:

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

• MAM を使用した MDM では、デバイスが確実に保護されます。 たとえば、デバイスにアクセスしたり、マネージド アプリをデバイスに展開したりするには、PIN が必要です。 また、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 デバイスのアプリ保護エクスペリエンス」を参照してください。

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

アプリ保護ポリシーで使用できる選択肢により、組織は特定のニーズに合わせて保護を調整できます。 一部の場合、完全なシナリオを実装するために必要なポリシー設定が明らかでない場合があります。 組織がモバイル クライアント エンドポイントのセキュリティ強化に優先順位を付けるために、Microsoft では、iOS および Android モバイル アプリ管理用のアプリ保護ポリシーデータ保護フレームワークの分類が導入されています。

アプリ保護ポリシーのデータ保護フレームワークは、次の 3 つの異なる構成レベルに編成され、各レベルは前のレベルから構築されます。

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

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

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

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

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

アプリ保護ポリシー (APP) を使ったデータ保護

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

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

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

次の図は、MDM とアプリ保護 ポリシーが一緒に提供する保護のレイヤーを示しています。

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) プラットフォームを使用して構築されたアプリのテストとサポートを積極的に行います。 一部のお客様は、Intune SDK と React Native や NativeScript などの他のプラットフォームとの統合に成功していますが、サポートされているプラットフォーム以外のものを使用するアプリ開発者には明示的なガイダンスやプラグインは提供されません。

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

次の一覧は、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の Intune App Protection のみがサポートされており、Office 365 Dedicated での Exchange はサポートされていません。

Word、Excel、PowerPoint

Word、Excel、PowerPoint アプリを使用するための要件は次のとおりです。

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

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

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

  注:

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

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

Office には管理された場所 (つまり OneDrive) が必要です。 Intune は、アプリ内のすべてのデータを "企業" または "個人用" としてマークします。データは、ビジネス上の場所から発信される場合、"企業" と見なされます。 Microsoft 365 アプリの場合、Intune では、メール (Exchange) またはクラウド ストレージ (OneDrive アプリと職場または学校アカウント用の OneDrive アプリ) がビジネスの場所と見なされます。

Skype for Business

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

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

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

OneDrive 管理 コンソールで使用できる設定は、グローバル ポリシーと呼ばれる特別な Intune アプリ保護ポリシーを構成します。 このグローバル ポリシーはテナント内のすべてのユーザーに適用され、ポリシーの対象を制御する手段はありません。

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

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

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

アプリ保護機能

複数の ID

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

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

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

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

Intune アプリの PIN

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

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

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

• 使いやすさの向上のために、同じ公開元のアプリで PIN が共有されます:
  iOS/iPadOS では、1 つのアプリ PIN が 同じアプリ発行元のすべてのアプリ間で共有されます。 たとえば、すべての Microsoft アプリで同じ PIN を共有します。 Android では、1 つのアプリ 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 が必要です。

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 でユーザー データをワイプしたりする場合、OneDrive では引き続きその PIN が使用される可能性があるため、Intune SDK はそのキーチェーンをクリアしません。 このため、選択的ワイプでは、PIN を含む共有キーチェーンはクリアされません。 このような動作は、発行元のアプリがデバイス上に 1 つしか存在しない場合でも変わりません。

PIN は同じ発行元のアプリ間で共有されるため、ワイプが 1 つのアプリに移動した場合、Intune SDK は、同じ発行元のデバイス上に他のアプリがあるかどうかはわかりません。 そのため、Intune SDK は PIN をクリアしません。これは、他のアプリで引き続き使用される可能性があるためです。 予想されるのは、その発行元からの最後のアプリが最終的に OS クリーンアップの一部として削除されると、アプリ PIN がワイプされるということです。

一部のデバイスで PIN がワイプされているのを確認すると、次の動作が発生する可能性があります。PIN は ID に関連付けられているため、ワイプ後にユーザーが別のアカウントでサインインすると、新しい PIN を入力するように求められます。 ただし、以前に既存のアカウントでサインインする場合は、キーチェーンに格納されている PIN を使用してサインインできます。

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

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

そのため、デバイスに、同じ発行元 (または 14.6.0 より前のバージョンと 14.6.0 以降のバージョン) から 7.1.12 以降の 7.1.12 より前の iOS バージョンの Intune SDK を使用するアプリケーションがある場合は、2 つの PIN を設定する必要があります。 (アプリごとに) 2 つの PIN は関係ありません (つまり、アプリに適用されるアプリ保護ポリシーに従う必要があります)。 そのため、アプリ A と B に同じポリシーが適用されている場合 (PIN に関して)、ユーザーは同じ PIN を 2 回設定する可能性があります。

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

アプリ データの暗号化

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

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

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

• 電子メール (Exchange)
• クラウド ストレージ (職場または学校アカウント用の OneDrive を使用した OneDrive アプリ)

Intune App Wrapping Toolによって管理される基幹業務アプリの場合、すべてのアプリ データは "企業" と見なされます。

選択的ワイプ

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

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

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

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

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 で Open in<app name を実行する必要があります。 これにより、すべてのユニバーサル リンクをデバイス上の保護されたアプリケーションにルーティングするように保護されたアプリに求めるメッセージが表示されます。

同じアプリとユーザーのセットに対する複数の 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 デバイスでのアプリ保護のエクスペリエンス

Microsoft Teams Android デバイス

Microsoft Teams Android デバイス上の Teams アプリは、アプリ保護ポリシーをサポートしていません (ポータル サイト アプリを介してポリシーを受け取りません)。 つまり、アプリ保護ポリシー設定は、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 を使用できるようにします。 指紋以外のすべての生体認証タイプを認証に使用できるかどうかを構成します。 指紋と顔のロック解除は、これらの生体認証の種類をサポートするために製造されたデバイスでのみ使用でき、正しいバージョンの Android を実行しています。 指紋には Android 6 以降が必要です。また、Face Unlock には Android 10 以上が必要です。

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

アプリ保護機能の多くはポータル サイト アプリに組み込まれています。 ポータル サイト アプリが常に必要な場合でも、デバイス登録は必要ありません* 。 Mobile Application Management (MAM) の場合、ユーザーはデバイスにポータル サイト アプリをインストールする必要があります。

同じアプリとユーザーのセットに対する複数の 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 サービス "ラウンドトリップ" が開始され、デバイスが失敗した場合にユーザーに非同期的にプロンプトが表示されます。

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 Protect API を使用するアプリ保護ポリシー設定では、Google Play Services を機能させる必要があります。 Play 整合性判定とアプリの脅威スキャンの両方の設定では、Google が決定したバージョンの Google Play Services が正しく機能する必要があります。 これらの設定はセキュリティの領域に含まれるため、これらの設定を対象にしていて、適切なバージョンの Google Play サービスを満たしていない場合、または Google Play サービスにアクセスできない場合、ユーザーはブロックされます。

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

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

データの保護

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

正常性チェック

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

次の手順

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

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

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