MDMマネージドiOSデバイスのネイティブアプリとSafariに対してOkta Device Trustを強制適用する
Okta Device Trust for iOSは、アンマネージドiOSデバイスがブラウザーやネイティブアプリを通してエンタープライズサービスにアクセスすることを防止します。
前提条件
- 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(非信頼)条件でのサインオンポリシールール — 信頼または非信頼条件で構成されたアプリのサインオンポリシールールを処理する場合、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(Oktaエンドユーザーダッシュボード)にロック済みとして表示されます。次の条件下でDevice Trustによって保護されたアプリの横に、ロックアイコンが表示されます。
- エンドユーザーがデスクトップまたはモバイルのブラウザー(Okta Mobile以外)でダッシュボードにアクセスした。
- OrgでDevice Trustが有効になっている。
- デバイスが信頼されていない。
- エンドユーザーがダッシュボードからDevice Trustで保護されたアプリにアクセスしようとした。
手順
ステップ1. OrgのグローバルDevice Trust設定を有効にする
- Admin Consoleで、 に移動します。
- [iOS Device Trust]セクションで、[Edit(編集)]をクリックします。
- [Enable iOS Device Trust(iOS Device Trustを有効にする)]を選択します。
- MDMプロバイダーに対応するオプションを選択します。
MDM オプション Workspace ONE UEM (旧称AirWatch)
- [Trust is established by(信頼の確立元)]: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プロバイダーのアプリ構成に入力します。
提供される秘密鍵の値をメモします。この値が表示されるのはこの時のみです。[Reset iOSSecret Key(iOS秘密鍵をリセット)]ボタンをクリックして新しいSecret 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(キー)]:ドメイン
- [Value(値)]:Okta orgのURLを入力します
- [Key(キー)]:managementHint
- [Value(値)]:ステップ1で保存した[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で作成した許可シナリオに一致しないユーザーに適用するキャッチオール拒否ルールを作成します。キャッチオール拒否ルールに、デフォルトルールのすぐ上の最低優先度を割り当てます。ここで説明した許可リストのアプローチでは、デフォルトルールは事実上キャッチオール拒否ルールで否定されるため、これに達することはありません。
アプリサインオンポリシールールの作成に関する重要なセキュリティ情報については、「アプリのサインオンポリシー」を参照してください。
手順
注:この例は、Office 365へのアクセスを管理するためのDevice Trustルールを示しています。他のアプリでは、[If the user's client is any of these(ユーザーのクライアントが次のいずれかに該当する場合)]セクションは表示されません。
- Admin Consoleで に進み、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 browser(Webブラウザー)]を選択します。
[Modern Auth client(Modern Authクライアント)]を選択します。
[Exchange ActiveSync client(Exchange ActiveSyncクライアント)]を選択解除します。
モバイル
[iOS]を選択します。
[Android]を選択解除します。
[Other mobile(他のモバイル)]を選択解除します。
デスクトップ
[Windows]を選択解除します。
[macOS]を選択解除します。
[Other desktop(他のデスクトップ)]を選択解除します。
- [Device Trust]で以下を構成します。
[Device Trust] セクションの[Trusted(信頼)]と[Not trusted(非信頼)]オプションは、[Client(クライアント)]セクションの以下のオプションがどれも選択されていない場合にのみ選択可能です。
- [Exchange ActiveSync or Legacy Auth client(Exchange ActiveSyncまたはレガシー認証クライアント)]
- [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(ユーザー)]で、[Rule 1(ルール1)]で選択したものと同じユーザーオプションを選択します。このオプションは、この例で作成するすべてのルールで同じにする必要があります。
- [LOCATION(ロケーション)]で、[Rule 1(ルール1)]で選択したものと同じ[Location(ロケーション)]オプションを選択します。このオプションは、この例で作成するすべてのルールで同じにする必要があります。
- [CLIENT(クライアント)]で、次の設定を構成します。
[Web browser(Webブラウザー)]を選択します。
[Modern Auth client(Modern Authクライアント)]を選択します。
[Exchange ActiveSync client(Exchange ActiveSyncクライアント)]を選択解除します。
モバイル
[iOS]を選択解除します。
[Android]を選択します。
[Other mobile(他のモバイル)]を選択します。
デスクトップ
[Windows]を選択します。
[macOS]を選択します。
[Other desktop(他のデスクトップ)]を選択します。
- [Device Trust]で以下を構成します。
[Device Trust] セクションの[Trusted(信頼)]と[Not trusted(非信頼)]オプションは、[Client(クライアント)]セクションの以下のオプションがどれも選択されていない場合にのみ選択可能です。
- [Exchange ActiveSync or Legacy Auth client(Exchange ActiveSyncまたはレガシー認証クライアント)]
- [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(ユーザー)]で、[Rule 1(ルール1)]で選択したものと同じユーザーオプションを選択します。このオプションは、この例で作成するすべてのルールで同じにする必要があります。
- [LOCATION(ロケーション)]で、[Rule 1(ルール1)]で選択したものと同じ[Location(ロケーション)]オプションを選択します。このオプションは、この例で作成するすべてのルールで同じにする必要があります。
- [CLIENT(クライアント)]で、次の設定を構成します。
[Web browser(Webブラウザー)]を選択します。
[Modern Auth client(Modern Authクライアント)]を選択します。
[Exchange ActiveSync client(Exchange ActiveSyncクライアント)]を選択解除します。
モバイル
[iOS]を選択します。
[Android]を選択解除します。
[Other mobile(他のモバイル)]を選択解除します。
デスクトップ
[Windows]を選択解除します。
[macOS]を選択解除します。
[Other desktop(他のデスクトップ)]を選択解除します。
- [Device Trust]で以下を構成します。
[Device Trust] セクションの[Trusted(信頼)]と[Not trusted(非信頼)]オプションは、[Client(クライアント)]セクションの以下のオプションがどれも選択されていない場合にのみ選択可能です。
- [Exchange ActiveSync or Legacy Auth client(Exchange ActiveSyncまたはレガシー認証クライアント)]
- [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(ユーザー)]で、[Rule 1(ルール1)]で選択したものと同じユーザーオプションを選択します。このオプションは、この例で作成するすべてのルールで同じにする必要があります。
- [LOCATION(ロケーション)]で、[Rule 1(ルール1)]で選択したものと同じ[Location(ロケーション)]オプションを選択します。このオプションは、この例で作成するすべてのルールで同じにする必要があります。
- [CLIENT(クライアント)]で、次の設定を構成します。
[Web browser(Webブラウザー)]を選択します。
[Modern Auth client(Modern Authクライアント)]を選択します。
[Exchange ActiveSync client(Exchange ActiveSyncクライアント)]を選択します。
モバイル
[iOS]を選択します。
[Android]を選択します。
[Other mobile(他のモバイル)]を選択します。
デスクトップ
[Windows]を選択します。
[macOS]を選択します。
[Other desktop(他のデスクトップ)]を選択します。
- [Device Trust]で以下を構成します。
[Device Trust] セクションの[Trusted(信頼)]と[Not trusted(非信頼)]オプションは、[Client(クライアント)]セクションの以下のオプションがどれも選択されていない場合にのみ選択可能です。
- [Exchange ActiveSync or Legacy Auth client(Exchange ActiveSyncまたはレガシー認証クライアント)]
- [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ソリューションは他の機密性の高いアプリへのアクセスを管理するために使用することをお勧めします。