Intune アプリ保護ポリシーにより、organization のデータが安全に保たれるか、マネージド アプリに含まれているかが保証されます。 これらのポリシーを使用すると、モバイル デバイス上のアプリによるデータへのアクセス方法と共有方法を制御できます。 ポリシーによって、ユーザーが "企業" データにアクセスしたり、データを移動したりしようとするときにルールを適用できます。 また、ユーザーがアプリ内にいるときのアクションを禁止または監視することもできます。 Intune のマネージド アプリは、Intune がアプリ保護ポリシーを適用し、アプリを管理する保護されたアプリです。
Intune アプリ保護ポリシーには、いくつかの利点があります。 これらの利点には、デバイスの登録を必要とせずにモバイル デバイス上の企業データを保護することや、モバイル デバイス上のアプリがデータにアクセスして共有する方法を制御する方法が含まれます。
Microsoft Intune でアプリ保護ポリシーを使用する例を次に示します。
- モバイル デバイスで会社のメールにアクセスするために PIN または指紋を要求する
- ユーザーが企業データを個人用アプリにコピーして貼り付けないようにする
- 企業データへのアクセスを承認されたアプリのみに制限する
Intune MAM は、Microsoft 365 (Office) アプリなど、多くの生産性アプリを管理します。 一般使用が可能な Microsoft Intune の保護されたアプリの公式一覧を参照してください。
アプリ データを保護する方法
従業員は、個人用タスクと仕事用タスクの両方にモバイル デバイスを使用します。 従業員の生産性を確保しながら、データの損失を防ぎます。 これには、意図的なデータ損失と意図しないデータ損失の両方が含まれます。 また、管理されていないデバイスからアクセスされる企業データを保護します。
Intune のアプリ保護ポリシーはあらゆるモバイル デバイス管理 (MDM) ソリューションとの依存関係なしで使用できます。 この独立性により、デバイスをデバイス管理ソリューションに登録してもしなくても会社のデータを保護できます。 アプリ レベルのポリシーを実装することで、会社のリソースへのアクセスを制限し、データを IT 部門の管轄下に収めることができます。
注:
ポリシーが確実に適用されるようにするには、条件付きアクセスを Intune アプリ保護ポリシーと共に使用します。
デバイスでのアプリ保護ポリシー
次のデバイスで実行されるアプリのアプリ保護ポリシーを構成します:
Microsoft Intune に登録されているデバイス: このようなデバイスは通常、企業所有です。
Microsoft 以外のモバイル デバイス管理 (MDM) ソリューションに登録されている: 通常、これらのデバイスは企業所有です。
注:
モバイル アプリ管理ポリシーは、Microsoft 以外のモバイル アプリ管理またはセキュリティで保護されたコンテナー ソリューションと共に使用しないでください。
いずれのモバイル デバイス管理ソリューションにも登録されていないデバイス: これらのデバイスは、通常、Intune またはその他の MDM ソリューションで管理も登録もされていない社員所有のデバイスです。
重要
Microsoft 365 サービスに接続する Office モバイル アプリのモバイル アプリ管理ポリシーを作成します。 また、ハイブリッド先進認証が有効になっている iOS/iPadOS および Android 用 Outlook の Intune アプリ保護ポリシーを作成することで、Exchange オンプレミス メールボックスへのアクセスを保護します。 この機能を使用する前に、iOS/iPadOS および Android 用 Outlook の要件を満たしていることを確認します。 オンプレミスの Exchange または SharePoint サービスに接続する他のアプリは、アプリの保護ポリシーをサポートしていません。
アプリ保護ポリシーを使用する利点
アプリ保護ポリシーを使用することの重要な利点は次のとおりです。
アプリ レベルで会社のデータを保護します。 モバイル アプリ管理にはデバイス管理が必要ないため、管理対象デバイスと管理対象外デバイスの両方で企業データを保護します。 管理の中心がユーザー ID になり、デバイスを管理する必要がなくなります。
個人的なコンテキストでアプリを使用する場合、ユーザーの生産性は影響を受けず、ポリシーは適用されません。 Intune は、ポリシーを職場のコンテキストにのみ適用するため、個人データに触れることなく企業データを保護できます。
アプリ保護ポリシーにより、アプリ レイヤーの保護が確実に配置されます。 例:
- 仕事ではアプリを開くとき、PIN を要求する
- アプリ間のデータ共有を制御する
- 会社アプリのデータを個人ストレージの場所に保存することを禁止する
MAM を使用した MDM でデバイスを確実に保護します。 たとえば、デバイスにアクセスするために PIN を要求したり、マネージド アプリをデバイスにデプロイしたりします。 また、MDM ソリューションを使用してアプリをデバイスに展開し、アプリの管理をより細かく制御できるようにします。
アプリ保護ポリシーと共に MDM を使用すると、より多くの利点があり、企業はアプリ保護ポリシーを MDM の有無にかかわらず同時に使用できます。 たとえば、会社が支給した電話と自分の個人用タブレットの両方を使用している従業員を考えてみてください。 会社のスマートフォンは MDM に登録されたうえでアプリ保護ポリシーによって保護されます。 個人用デバイスは、アプリ保護ポリシーによってのみ保護されます。
デバイスの状態を設定せずに MAM ポリシーをユーザーに適用すると、ユーザーは BYOD (Bring Your Own Device) と 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 保護ポリシーのデータ保護フレームワーク
アプリ保護ポリシーで提供される選択肢により、組織は特定のニーズに合わせて保護を調整できます。 一部のユーザーにとっては、完全なシナリオを実装するために必要なポリシー設定が明確でない場合があります。 組織がモバイル クライアント エンドポイントのセキュリティ強化に優先順位を付けるのを支援するために、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 デバイスでは、アプリ保護ポリシーによってアプリ レベルで会社のデータを保護できます。 ただし、次のようないくつかの制約があることに注意してください。
- アプリがデバイスに展開されていません。 ユーザーは Microsoft Store からアプリを取得します。
- これらのデバイスでは、証明書プロファイルはプロビジョニングされていません。
- 会社の 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) アプリでアプリ保護ポリシーを使用する場合は、さらにいくつかの要件を知っておく必要があります。
重要
Android の Intune モバイル アプリケーション管理 (MAM) では、Microsoft 365 アプリに Microsoft Entra ID デバイスを登録する必要があります。 セキュリティを向上させるには、Android デバイスを Microsoft Entra ID に登録して、Microsoft 365 アプリの MAM ポリシーを引き続き受信する必要があります。
MAM ポリシーの対象となる Microsoft 365 アプリにアクセスすると、デバイスが Microsoft Entra ID にまだ登録されていない場合、ユーザーに認証を求めるメッセージが表示される場合があります。 ユーザーが Microsoft 365 MAM 対応アプリケーションにアクセスするには、認証と登録プロセスを完了する必要があります。
条件付きアクセス ポリシーまたは多要素認証が有効になっている場合、デバイスは既に登録されている必要があり、ユーザーは変更に気付くことはありません。
登録されているデバイスを確認するには、[Microsoft Entra 管理センター>デバイス>すべてのデバイス] レポートに移動し、OS でフィルター処理して、[登録済み] で並べ替えます。 関連情報については、「Microsoft Entra 管理センターを使用してデバイス ID を管理する」を参照してください。
Outlook モバイル アプリ
Outlook モバイル アプリを使用するための要件は次のとおりです。
ユーザーのデバイスに Outlook モバイル アプリがインストールされている必要があります。
ユーザーには、Microsoft 365 Exchange Online メールボックスと、Microsoft Entra アカウントにリンクされたライセンスが必要です。
注:
Outlook モバイル アプリは現在、ハイブリッド先進認証を備えた Microsoft Exchange Online および Exchange Server の Intune App Protection のみをサポートしており、Office 365 専用の Exchange はサポートしていません。
Word、Excel、PowerPoint
Word、Excel、PowerPoint アプリを使用するための要件は次のとおりです。
ユーザーは、Microsoft Entra アカウントにリンクされた Microsoft 365 Apps for business または enterprise のライセンスを持っている必要があります。 サブスクリプションには、モバイル デバイス上の 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 アプリ) を勤務先として考慮します。
Skype for Business
Skype for Business を使用するには、他にも要件があります。 Skype for Business のライセンス要件を参照してください。 Skype for Business (SfB) のハイブリッド構成とオンプレミス構成については、「それぞれ Microsoft Entra ID を使用した SfB とExchange のハイブリッド先進認証の一般提供と SfB オンプレミスの最新認証の移行」を参照してください。
アプリ保護グローバル ポリシー
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 アプリ内の個人用アカウント、他のアプリ内の個人用アカウント、または個人用アプリに転送できないようにすることができます。
アプリ保護ポリシーは複数管理対象アカウント (MMA) でサポートされています。これにより、ユーザーはサポートされているアプリ内に複数の職場または学校アカウントを追加できます。ポリシーはアカウントごとに個別に適用されます。
"個人用" コンテキストの例として、ユーザーが Word で新しい文書を開始するとします。これは個人用コンテキストと見なされるため、Intune アプリ保護ポリシーは適用されません。 ドキュメントが "企業" の 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 アプリでは、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 の入力を求めるメッセージを表示しません。 'Recheck the access requirements after (minutes)' 値が再度満たされると、プロンプトが再度表示されます。
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 プロンプトは、多くの場合、既定でアプリの起動に関連付けられています。 ユーザーが両方の 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 が許可されており、iOS 用 Intune SDK を統合するためにアプリケーション (WXP、Outlook、Viva Engage など) の参加が必要です。 これがないと、対象のアプリケーションにパスコード設定が適切に適用されません。 これは、iOS v. 7.1.12 用 Intune SDK でリリースされた機能です。
この機能をサポートし、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 とは別に処理されます。
そのため、同じ発行元 (または 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 回設定しなくてはならないことは問題ではなくなっていきます。
注:
たとえば、アプリ A が 7.1.12 (または 14.6.0) より前のバージョンでビルドされ、アプリ B が同じ発行元の 7.1.12 以降 (または 14.6.0) のバージョンでビルドされている場合、両方が iOS/iPadOS デバイスにインストールされている場合、ユーザーは A と B に対して個別に PIN を設定する必要があります。
SDK バージョン 7.1.9 (または 14.5.0) を持つアプリ C がデバイスにインストールされている場合、アプリ A と同じ PIN を共有します。
7.1.14 (または 14.6.2) でビルドされたアプリ D は、アプリ B と同じ PIN を共有します。
アプリ A とアプリ C がデバイスにインストールされている場合は、1 つの PIN を設定する必要があります。 アプリ B と D がデバイスにインストールされている場合も同様です。
アプリ データの暗号化
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 の選択的なワイプは、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 管理者は、Microsoft Edge を使用して Intune で管理されるアプリのすべての Web リンクを開くことを要求できます。
iOS デバイスでのアプリ保護のエクスペリエンス
デバイスの指紋 ID または Face ID
Intune アプリ保護ポリシーでは、アプリへのアクセスを制御して、Intune のライセンスがあるユーザーのみを許可することができます。 アプリへのアクセスを制御する方法の 1 つは、Apple の Touch ID または Face ID のいずれかをサポートされているデバイス上で要求することです。 Intune は、デバイスの生体認証データベースに変更がある場合、次の非アクティブ タイムアウト値に達したときに、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 は "企業" データがアプリの外部で共有される前に、データを暗号化します。 この暗号化動作を検証するには、マネージド アプリの外部で "corporate" ファイルを開きます。 ファイルは暗号化されていて、管理対象アプリの外部では開くことができないはずです。
ユニバーサル リンクのサポート
既定では、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 デバイスでのアプリ保護のエクスペリエンス
注:
アプリ保護ポリシーは、共有デバイス モードのない Intune マネージド Android Enterprise 専用デバイスではサポートされていません。 これらのデバイスでは、ユーザーに影響を及ぼさずにアプリ保護ポリシーのブロック ポリシーを有効にするには、ポータル サイトをインストールする必要があります。 アプリ保護ポリシーは、共有デバイス モードを使用する Intune マネージド Android Enterprise 専用デバイス、および共有デバイス モードを使用する AOSP ユーザーレス デバイスでサポートされます。 アプリ保護ポリシーは共有デバイス モードでサポートされますが、次のいずれかの設定が Android アプリ保護ポリシーで適用される場合は例外があります:
- アクセスに PIN を使用
- アクセスに職場または学校アカウントの資格情報を使用
このシナリオでは、ユーザーが PIN リセット フロー中にブロックされた場合、[アカウントの削除] ボタンを使用して自分自身のブロックを解除する必要があります。
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 デバイスでサポートされている内容に応じて、ユーザーが指紋認証または顔認証を使用できるようにします。 指紋以外のすべての生体認証の種類を認証に使用できるかどうかを構成します。 指紋認証と顔認証は、これらの生体認証の種類をサポートするように製造され、正しいバージョンの Android を実行しているデバイスでのみ使用できます。 指紋には Android 6 以降が必要です。また、Face Unlock には Android 10 以上が必要です。
ポータル サイト アプリと Intune アプリの保護
アプリ保護機能の多くはポータル サイト アプリに組み込まれています。 ポータル サイト アプリが常に必須ですが、デバイスの登録は必要ありません*。 モバイル アプリケーション管理 (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 サービスの "ラウンドトリップ" がバックエンドで開始され、デバイスに障害が発生した場合は非同期にユーザーに表示されます。 古いデータがある場合は、最後に報告された結果に応じてアクセスがブロックまたは許可されます。同様に、デバイスに障害が発生した場合は、構成証明の結果を特定するための Google Play サービスの "ラウンドトリップ" が開始され、非同期的にユーザーに表示されます。
Android デバイス対応の Intune アプリ保護ポリシーと Google のアプリの確認 API
Intune アプリ保護ポリシーは、管理者がユーザー デバイスに Android デバイス用の Google の Verify Apps API を介してシグナルを送信することを要求する機能を提供します。 この方法はデバイスごとに若干異なります。 一般的なプロセスでは、Google Play ストアに移動し、[ マイ アプリ] & [ゲーム] を選択し、最後のアプリ スキャンの結果を選択して、[Play Protect] メニューに移動します。 [端末をスキャンしてセキュリティ上の脅威を確認] のトグルが確実にオンになっているようにします。
Google の Play Integrity API
Intune は、Google の Play 整合性 API を使用して、登録されていないデバイスの既存のルート検出チェックを追加します。 Google は、Android アプリがルート化されたデバイスでアプリを実行したくない場合に採用できるように、この API セットを開発して管理しています。 たとえば、Android Pay アプリにはこれが組み込まれています。 Google は、発生するルート検出チェック全体を公開していませんが、これらの API はデバイスを root 化したユーザーを検出します。 そのようなユーザーのアクセスをブロックしたり、ポリシーが有効になっているアプリからそのようなユーザーの企業アカウントを消去したりできます。 基本的な整合性のチェックでは、デバイスの全体的な整合性がわかります。 ルート化されたデバイス、エミュレーター、仮想デバイス、改ざんの兆候があるデバイスは基本的な整合性のチェックで不合格になります。 基本的な整合性と認定デバイスのチェックでは、デバイスと Google のサービスとの互換性がわかります。 このチェックに合格できるのは、Google が認定する改造されていないデバイスのみです。 失敗するデバイスは次のとおりです。
- 基本的な整合性のチェックで不合格になるデバイス
- ブートローダーがロックされていないデバイス
- カスタム システム イメージ/ROM が含まれるデバイス
- 製造元が Google 認定を申請していない、または Google 認定に合格していないデバイス
- Android オープン ソース プログラムのソース ファイルから直接構築されたシステム イメージを含むデバイス
- ベータ版/開発者プレビューのシステム イメージを含むデバイス
技術的な詳細については、 Google の Play Integrity API に関する Google のドキュメントを参照してください。
整合性判定の再生設定と [ジェイルブレイク/ルート化されたデバイス] 設定
プレイの整合性判定では、少なくとも構成証明結果を決定するための "ラウンドトリップ" が実行される時間の間には、ユーザーがオンラインである必要があります。 ユーザーがオフラインの場合でも、IT 管理者は、 ジェイルブレイク/ルート化されたデバイス 設定から結果が適用されることを期待できます。 ただし、ユーザーがオフラインのままが長すぎると、 オフラインの猶予期間 の値が有効になり、そのタイマー値に達すると、ネットワーク アクセスが利用可能になるまで、職場または学校のデータへのすべてのアクセスがブロックされます。 両方の設定を有効にすると、ユーザー デバイスを正常に保つための階層的なアプローチが可能になります。これは、ユーザーがモバイルで職場や学校のデータにアクセスするときに重要です。
Google Play プロテクト API と Google Play 開発者サービス
Google Play プロテクト API を使用するアプリ保護ポリシー設定では、Google Play サービスが機能する必要があります。 Play 整合性判定とアプリの脅威スキャンの設定の両方で、Google が決定したバージョンの Google Play サービスを正しく機能させる必要があります。 これらの設定はセキュリティの領域に該当するため、ユーザーがこれらの設定のターゲットになり、適切なバージョンの Google Play サービスを満たしていない場合、または Google Play サービスにアクセスできない場合、ユーザーはブロックされます。
Windows デバイスのアプリ保護エクスペリエンス
ポリシー設定には、 データ保護 と 正常性チェックの 2 つのカテゴリがあります。 ポリシー管理アプリという用語は、アプリ保護ポリシーで構成されたアプリを指します。
データの保護
データ保護の設定は、組織のデータとコンテキストに影響します。 管理者は、組織保護のコンテキストとの間のデータの移動を制御できます。 組織コンテキストは、指定された組織アカウントによってアクセスされるドキュメント、サービス、サイトによって定義されます。 次のポリシー設定は、組織コンテキストに受信する外部データと組織コンテキストから送信される組織データを制御するのに役立ちます。
正常性チェック
正常性チェックでは、条件付き起動機能を構成できます。 これを行うには、アプリ保護ポリシーの正常性チェック条件を設定する必要があります。 [ 設定 ] を選択し、ユーザーが組織データにアクセスするために満たす必要がある 値 を入力します。 次に、ユーザーが条件を満たしていない場合に実行する アクション を選択します。 場合によっては、単一の設定に対して複数のアクションを構成できます。
次の手順
Microsoft Intune でアプリ保護ポリシーを作成および展開する方法