MDMマネージドiOSデバイスのネイティブアプリとSafariに対してOkta Device Trustを強制適用する

Okta Device Trust for iOSは、アンマネージドiOSデバイスがブラウザーやネイティブアプリを通してエンタープライズサービスにアクセスすることを防止します。

The image illustrates how Okta Device Trust is enforced for Native apps and Safari on MDM-managed iOS devices.

前提条件

OktaがサポートするiOSバージョンを実行するiOSデバイス
MDMプロバイダーのサポート：
- 最小：マネージドアプリの構成をサポートする任意のモバイルデバイス管理（MDM）プロバイダー
- 推奨：（1）マネージドアプリの構成、および（2）エンドユーザーがインストールしたOkta Mobileアプリインスタンスをマネージドアプリに変換する機能をサポートするMDMプロバイダー
アプリ：
- 任意のiOS SAMLまたはWS-Fedクラウドアプリ
- MDMプロバイダーが管理するiOS向けOkta Mobile 5.12.0以降

開始する前に

Boxへのアクセスを保護する：Boxアプリへのアクセスを保護するには、Box for EMMを使用することをお勧めします。Box for EMMではなくこのOkta Device Trustソリューションを使用するには、Boxサポートに連絡してBoxテナント用のSafari View Controller（SVC）を有効にするよう依頼する必要があります。
Device TrustとOkta Mobile Connectが共に有効になっている場合：Okta Mobile Connect（OMC）が有効で、Device Trustによって保護されているアプリにエンドユーザーがアクセスしようとすると、アプリにDevice Trustサインオンポリシールールが設定されている場合、Device Trust認証フローが実行されます。それ以外では、OMCフローに従います。
信頼（Trust）またはNot trusted（非信頼）条件でのサインオンポリシールール：信頼（Trust）または非信頼（Not trusted）条件で構成されたアプリのサインオンポリシールールを処理する場合、Oktaは通常のルール処理を一時停止し、Okta Mobileを使用してデバイスが信頼できるかどうかを評価します。Oktaによってデバイスが非信頼と評価された場合、以下のいずれかが行われます。
- 非信頼デバイスを拒否するようにサインオンポリシールールを構成した場合、ユーザーはMDMプロバイダーへ登録するように求められます。
- 非信頼デバイスを使用するユーザーにMFAチャレンジを与えるようにサインオンポリシールールを構成した場合、そのユーザーにMFAチャンレンジが提示されます。
エンドユーザーがアプリサインインページにリダイレクトされないことがある：Device Trustソリューションが有効になっている場合、エンドユーザーがOkta連携認証GmailまたはSalesforceアカウントにサインインした後そのアカウントを削除すると、アプリのサインインページではなくOktaホームページにリダイレクトされます。
Oktaがパスワードレス認証をサポートするのはOffice 365アプリのみ（Okta Mobileがインストールされていることが前提）：他のすべてのアプリでは、資格情報を入力するためのOktaサインインページがエンドユーザーに表示されます。ユーザーはその後、Okta MobileでDevice Trustステータスを評価することが求められます。デバイスが信頼されている（MDMに登録されている）場合、エンドユーザーはアプリにアクセスできますOkta Mobileがデバイスを信頼できないと評価した場合、次のいずれかが発生します。
- 非信頼デバイスを拒否するようにサインオンポリシールールを構成した場合、該当するデバイスを使用するユーザーはMDMプロバイダーへ登録するように求められます。
- 非信頼デバイスを使用するユーザーにMFAチャレンジを提示するようにサインオンポリシールールを設定した場合、該当するユーザーにはMFAチャレンジが提示されます。
SVC対応アプリでWebベースのMDMの登録が失敗する：Webベースの登録をサポートするMDMプロバイダー（MobileIronなど）と統合されているお客様の場合、エンドユーザーがSafari View Controller対応ネイティブアプリ（SVC）にアクセスしようとすると、このDevice Trustソリューションで発生するように設計された自動登録フローが失敗します。これは、SVCアプリが、MDM登録の完了に必要なデバイスの設定（Settings）ページを開く動作をサポートしていないためです。アプリにSafariを開くボタンがあれば、エンドユーザーはそのボタンをタップしてMDM登録を完了できます。

エンドユーザーがユニバーサルリンクを不注意で無効にし、Device Trustで保護されたアプリにアクセスできなくなる場合がある：Okta Mobileがデバイスにインストールされている場合に、エンドユーザーが画面の右上（通常パンくずリストが配置されている場所）をタップすると、Okta Mobileがすでにインストールされているにもかかわらず再度インストールするように求められます。これは、画面のその部分をタップすると、Okta Mobileを開くように構成されているユニバーサルリンクを不慮に無効にするからです。ユーザーがそのアプリに対して認証されるためには、Okta Mobileセッションが必要です。そのエンドユーザーに以下の回避策を取ることでOkta Mobileを開くようにアドバイスします。

メモ（Notes）アプリを開きます。
次のURLを含む新しいメモを作成します：https://login.okta.com/auth/oktamobile
完了（Done）をクリックします。これは、このURLをハイパーリンクにするために必要です。
リンクhttps://login.okta.com/auth/oktamobileを長押しします。

このDevice TrustソリューションでOkta連携認証MDMアプリケーションを保護する：Oktaでは、非信頼 - 拒否（Not Trusted - Deny）アプリサインオンポリシーをOkta連携認証MDMアプリケーションに適用しないよう推奨しています。適用した場合、新規ユーザーがデバイスをMDMアプリケーションに登録できなくなり、その他のDevice Trustで保護されたアプリにアクセスすることができなくなります。
Device Trustによって保護されたアプリは、Okta End-User Dashboardにロック済みとして表示されます。次の条件下でDevice Trustによって保護されたアプリの横に、ロックアイコンが表示されます。
- エンドユーザーがデスクトップまたはモバイルのブラウザー（Okta Mobile以外）でダッシュボードにアクセスした。
- OrgでDevice Trustが有効になっている。
- デバイスが信頼されていない。
- エンドユーザーがダッシュボードからDevice Trustで保護されたアプリにアクセスしようとした。

手順

ステップ1. orgのグローバルのDevice Trustの設定を有効化する

Admin Consoleでセキュリティ（Security） > Device Trust に移動します。
Device Trust Device Trust（Edit）（iOS向けDevice Trust）］セクションで、［Edit（編集）］をクリックします。
iOSを有効化（Enable iOS ）Device Trust を選択します。

MDMプロバイダーに対応するオプションを選択します。

MDM	オプション
Workspace ONE UEM （旧称AirWatch）	信頼の確立元：VMware 統合タイプ（［Integration type）］：Oktaクライアントベース（Workspace ONE UEM）
Microsoft Intune	信頼の確立元（［Trust is established by）］：Microsoft Intune
MobileIron	信頼の確立元（［Trust is established by）］：MobileIron
上記以外	信頼の確立元（［Trust is established by）］：その他統合タイプ（［Integration type）］：Oktaクライアントベース注: 重要：SAMLベース・オプションは選択しないでください。このDevice Trustソリューションには適用されません。

次へ（Next）をクリックします。
フィールドの横にあるコピーアイコンをクリックして、提供された秘密鍵（Secret Key）をクリップボードにコピーします。この秘密鍵（Secret Key）は、手順2で説明するように、後でMDMプロバイダーのアプリ構成に入力します。

注:
提供された秘密鍵の値がOktaに表示されるのはこの時だけなので、メモしておいてください。［ Reset （Secret Key）iOSの秘密鍵をリセット（iOSSecret Key）］をクリックして新しい秘密鍵（Reset iOSSecret Key）を生成する場合は、ご使用のMDM構成も新しいキーで更新してください。
モバイルデバイス管理プロバイダー（Mobile device management provider）フィールドでMDMプロバイダーの名前を追加または変更します。このフィールドの内容は、エンドユーザーがデバイスを登録したときに表示されます。
登録リンク（Enrollment link）フィールドに、未登録のデバイスがあるエンドユーザーをリダイレクトするためのWebアドレスを入力します。たとえば、これらのユーザーを登録手順が記載されたページや選択したMDMの登録ページにリダイレクトすることができます（MDMプロバイダーがWebベースの登録をサポートしている場合）。
保存（Save）をクリックします。
ステップ2に進みます。

ステップ2. OktaをサードパーティMDMプロバイダーに統合する

推奨MDM機能

最低限、MDMはマネージドアプリの構成をサポートしている必要があります。最良の結果が得られるよう、以下の機能を持つMDMと統合することをお勧めします。

Okta Mobileをマネージドアプリとして設定する
選択したMDMにエンドユーザーが登録したときに、エンドユーザーのデバイスにサイレントかつ自動的にインストールされるようにOkta Mobileを設定する
エンドユーザーがインストールしたOkta Mobileアプリのインスタンスをマネージドアプリに変換するようMDMを設定する
マネージドアプリの構成を使用してキーと値のペアを構成する

ベストなエンドユーザーエクスペリエンスを提供

エンドユーザーのiOSデバイスがMDMプロバイダーにすでに登録されていて、Okta MobileがMDMプロバイダーのアプリストアを通じてデバイスにサイレントにインストールされている場合、管理対象の企業リソースにアクセスする際のエクスペリエンスが向上します。Okta Mobileがまだインストールされていない場合、エンドユーザーはMDMアプリストアからインストールするよう案内されます。Okta Mobileがインストールされているが、まだMDMプロバイダーによって管理されていない場合、エンドユーザーはDevice Trustで保護されたアプリにアクセスする前に、アプリ管理プロセスを通して手順が示されます。

Okta Mobileを管理し、まだインストールされていない場合はエンドユーザーのデバイスにインストールするようにMDMプロバイダーを構成します。
それぞれのドキュメントに記載されているように、MDMプロバイダーのマネージドアプリ構成を通じてキーと値のペアを構成します。
- キー（［Key）］：（Key:）ドメイン
- 値（［Value）］：（Value:）Okta orgのURLを入力します
- キー（［Key）］：（Key:）managementHint
- 値（Value）（Value:）：ステップ1（Secret Key）で保存した秘密鍵（Secret Key）の値を使用します。
  注：キーと値のペアでは大文字と小文字が区別されます。
例：MDMがXMLを必要とする場合、次のようなXML形式を使用します。
```
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" http://www.apple.com/DTDs/PropertyList-1.0.dtd>
<plist version="1.0">
<dict>
<key>Domain</key>
<string>https://"Your domain".okta.com</string>
<key>managementHint</key>
<string>"secret key goes here"</string>
</dict>
</plist>
```
ステップ3に進みます。

ステップ3. Oktaでアプリサインオンポリシールールを構成する

アプリサインオンポリシールールについて

アプリサインオンルール（［App Sign On Rule）］ダイアログボックス内のすべてのクライアントオプションはデフォルトで事前選択されています。アプリへのアクセスを詳細設定するには、以下を反映させるルールを作成します。

対象となるユーザー、または対象者が属するグループ
対象者がネットワークに接続しているか、接続していないか、定義されたネットワークゾーンに属しているか
対象者のデバイスで実行されているクライアントのタイプ（Office 365アプリのみ）
対象者のモバイルまたはデスクトップデバイスのプラットフォーム
対象者のデバイスが信頼されているかどうか

サインオンポリシールールへの許可リストによるアプローチ

アプリへのアクセスを許可するシナリオをサポートする1つまたは複数の許可ルールを作成し、これらのルールに最高優先度を割り当てます。
ステップ1で作成した許可シナリオに一致しないユーザーに適用するキャッチオール拒否ルールを作成します。キャッチオール拒否ルールに、デフォルトルールのすぐ上の最低優先度を割り当てます。ここで説明した許可リストアプローチでは、デフォルトルールは事実上キャッチオール拒否ルールで否定されるため、これに達することはありません。

注:

アプリサインオンポリシールールの作成についての重要なセキュリティ情報は、「アプリのサインオンポリシーについて」を参照してください。

手順

Device Trust：この例は、Office 365へのアクセスを管理するためのDevice Trustルールを示しています。他のアプリでは、ユーザーのクライアントが次のいずれかに該当する場合（If the user's client is any of these）セクションは表示されません。

Admin Consoleでアプリケーション（Applications） > アプリケーション（Applications）に進み、Device Trustで保護するSAMLまたはWS対応アプリをクリックします。
サインオン（Sign On）タブをクリックします。
下にスクロールしてサインオンポリシー（Sign On Policy）に移動し、ルールを追加（Add Rule）をクリックします。
次の例をガイドとして使用して、1つ以上のルールを構成します。

この例では、WebブラウザーおよびModern Authクライアントへのアクセスを許可してすべてのアクセスにMFAを要求し、非信頼iOSデバイスへのアクセスは拒否するアプリサインオンポリシーを作成する手順を示します。

ルール例1：Webブラウザーまたはモダン認証、iOS、信頼できる、アクセスを許可 + MFA

ルールの記述名を入力します。
ユーザー（PEOPLE）で、ルールを個人のみに適用するか、個人とグループに適用するかを指定します。このオプションは、この例で作成するすべてのルールで同じにする必要があります。
ロケーション（LOCATION）で、ルールを適用するユーザーのロケーションを指定します。このオプションは、この例で作成するすべてのルールで同じにする必要があります。
クライアント（CLIENT）で、次の設定を構成します。
Webブラウザー（Web browser）を選択します。

Modern Authクライアント（Modern Auth client）を選択します。

Exchange ActiveSyncクライアント（Exchange ActiveSync client）を選択解除します。

モバイル（Mobile）

iOS を選択します。

Android を選択解除します。

他のモバイル（Other mobile）を選択解除します。

デスクトップ

Windows を選択解除します。

macOS を選択解除します。

他のデスクトップ（Other desktop）を選択解除します。
Device Trust（DEVICE TRUST）で以下を構成します。
Device Trust セクションの信頼（Trusted）と非信頼（Not trusted）オプションは、クライアント（Client）セクションの以下のオプションがどれも選択されていない場合にのみ選択可能です。
- Exchange ActiveSyncまたはレガシー認証クライアント（Exchange ActiveSync or Legacy Auth client）
- Other mobile (for example, BlackBerry)（他のモバイル（BlackBerryなど））
- Other desktop (for example, Linux)（他のデスクトップ（Linuxなど））
すべて（Any）を選択解除します。

信頼（Trusted）を選択します。

非信頼（［Not trusted）］を選択解除します。
アクセス（Access）を構成します。
許可（Allowed）を選択します。

要素をプロンプト（Prompt for factor）を選択します。
保存（Save）をクリックします。
ルール2を作成します。

ルール例2：Webブラウザーまたはモダン認証、iOSを除くすべてのプラットフォーム、任意の信頼、アクセスを許可+ MFA

ルールの記述名を入力します。
ユーザー（PEOPLE）で、ルール1（Rule 1）で選択したものと同じユーザーオプションを選択します。このオプションは、この例で作成するすべてのルールで同じにする必要があります。
ロケーション（LOCATION）で、ルール1（Rule 1）で選択したものと同じ［Location（ロケーション）］オプションを選択します。このオプションは、この例で作成するすべてのルールで同じにする必要があります。
クライアント（CLIENT）で、次の設定を構成します。
Webブラウザー（Web browser）を選択します。

Modern Authクライアント（Modern Auth client）を選択します。

Exchange ActiveSyncクライアント（Exchange ActiveSync client）を選択解除します。

モバイル（Mobile）

iOS を選択解除します。

Android を選択します。

他のモバイル（Other mobile）を選択します。

デスクトップ

Windows を選択します。

macOS を選択します。

他のデスクトップ（Other desktop）を選択します。
Device Trust（DEVICE TRUST）で以下を構成します。
Device Trust セクションの信頼（Trusted）と非信頼（Not trusted）オプションは、クライアント（Client）セクションの以下のオプションがどれも選択されていない場合にのみ選択可能です。
- Exchange ActiveSyncまたはレガシー認証クライアント（Exchange ActiveSync or Legacy Auth client）
- Other mobile (for example, BlackBerry)（他のモバイル（BlackBerryなど））
- Other desktop (for example, Linux)（他のデスクトップ（Linuxなど））
すべて（Any）を選択します。

信頼（Trusted）を選択解除します。

非信頼（Not trusted）を選択解除します。
アクセス（Access）を構成します。
許可（Allowed）を選択します。

要素をプロンプト（Prompt for factor）を選択します。
保存（Save）をクリックします。
ルール3を作成します。

ルール例3：Webブラウザーまたはモダン認証、iOS、信頼できない、アクセスを拒否

ルールの記述名を入力します。
ユーザー（PEOPLE）で、ルール1（Rule 1）で選択したものと同じユーザーオプションを選択します。このオプションは、この例で作成するすべてのルールで同じにする必要があります。
ロケーション（LOCATION）で、ルール1（Rule 1）で選択したものと同じ［Location（ロケーション）］オプションを選択します。このオプションは、この例で作成するすべてのルールで同じにする必要があります。
クライアント（CLIENT）で、次の設定を構成します。
Webブラウザー（Web browser）を選択します。

Modern Authクライアント（Modern Auth client）を選択します。

Exchange ActiveSyncクライアント（Exchange ActiveSync client）を選択解除します。

モバイル（Mobile）

iOS を選択します。

Android（Androd）を選択解除します。

他のモバイル（Other mobile）を選択解除します。

デスクトップ

Windows を選択解除します。

macOS を選択解除します。

他のデスクトップ（Other desktop）を選択解除します。
Device Trust（DEVICE TRUST）で以下を構成します。
Device Trust セクションの信頼（Trusted）と非信頼（Not trusted）オプションは、クライアント（Client）セクションの以下のオプションがどれも選択されていない場合にのみ選択可能です。
- Exchange ActiveSyncまたはレガシー認証クライアント（Exchange ActiveSync or Legacy Auth client）
- Other mobile (for example, BlackBerry)（他のモバイル（BlackBerryなど））
- Other desktop (for example, Linux)（他のデスクトップ（Linuxなど））
すべて（Any）を選択解除します。

信頼（Trusted）を選択解除します。

非信頼（Not trusted）を選択します。
アクセス（Access）を構成します。
拒否（Denied）を選択します。
保存（Save）をクリックします。

例：Rule 4 – Any client type; All platforms; Any Trust; Deny access

ルールの記述名を入力します。
ユーザー（PEOPLE）で、ルール1（Rule 1）で選択したものと同じユーザーオプションを選択します。このオプションは、この例で作成するすべてのルールで同じにする必要があります。
ロケーション（LOCATION）で、ルール1（Rule 1）で選択したものと同じ［Location（ロケーション）］オプションを選択します。このオプションは、この例で作成するすべてのルールで同じにする必要があります。
クライアント（CLIENT）で、次の設定を構成します。
Webブラウザー（Web browser）を選択します。

Modern Authクライアント（Modern Auth client）を選択します。

Exchange ActiveSyncクライアント（Exchange ActiveSync client）を選択します。

モバイル（Mobile）

iOS を選択します。

Android を選択します。

他のモバイル（Other mobile）を選択します。

デスクトップ

Windows を選択します。

macOS を選択します。

他のデスクトップ（Other desktop）を選択します。
Device Trust（DEVICE TRUST）で以下を構成します。
Device Trust セクションの信頼（Trusted）と非信頼（Not trusted）オプションは、クライアント（Client）セクションの以下のオプションがどれも選択されていない場合にのみ選択可能です。
- Exchange ActiveSyncまたはレガシー認証クライアント（Exchange ActiveSync or Legacy Auth client）
- Other mobile (for example, BlackBerry)（他のモバイル（BlackBerryなど））
- Other desktop (for example, Linux)（他のデスクトップ（Linuxなど））
すべて（Any）を選択します。

信頼（Trusted）を選択解除します。

非信頼（Not trusted）を選択解除します。
アクセス（Access）を構成します。
拒否（Denied）を選択します。
保存（Save）をクリックします。

Rule 5: Default sign on rule – Any client, All platforms; Any Trust; Allow access

デフォルトサインオンルールは作成済みであり、編集できません。この例では、デフォルトルールがルール4により実質的に無効化されているため、デフォルトルールに到達することはありません。

既知の問題

IntuneがMDMプロバイダーである場合、このDevice Trustソリューションを使用するときO365はサポートされていない - Microsoft IntuneがMDMプロバイダーで、Oktaに連携認証されている場合、Not Trusted --> Deny（非信頼 --> 拒否）アプリ認証ポリシーをOkta連携認証済みO365アプリに適用すると、アンマネージドiOSデバイスを使用するエンドユーザーはデバイスをIntuneに登録できなくなります。これは、O365アプリ認証ポリシーがIntuneにも適用されるためです。Oktaはこの問題を調査中です。それまでの間、Microsoft Intune MAMを使用してO365アプリへのアクセスを管理し、このOkta Device Trustソリューションは他の機密性の高いアプリへのアクセスを管理するために使用することをお勧めします。