Web および SaaS アプリケーション構成のベストプラクティス

公開アプリと非公開アプリへのアプリケーションアクセスは、Secure Private Access サービス内で設定されているアプリケーションとアクセスポリシーによって異なります。

公開アプリと未公開アプリへのSecure Private Access 内のアプリケーションアクセス

• 公開されている Web アプリケーションおよび関連ドメインへのアクセス:

  • 公開されているウェブアプリに関連付けられた FQDN にエンドユーザーがアクセスする場合、アクセスポリシーがユーザーの [許可] または [ 制限付き許可 ] アクションで明示的に設定されている場合のみ、 アクセスが許可されます 。

    注:

    完全に一致させるには、複数のアプリケーションで同じアプリケーション URL ドメインまたは関連ドメインを共有しないことをお勧めします。複数のアプリが同じアプリケーション URL ドメインまたは関連ドメインを共有している場合、完全な FQDN の一致とポリシーの優先順位に基づいてアクセスが提供されます。詳細については、「 アクセスポリシーの照合と優先順位付け」を参照してください。

  • 公開アプリと一致するアクセスポリシーがない場合、またはアプリがどのアクセスポリシーにも関連付けられていない場合、アプリへのアクセスはデフォルトで拒否されます。アクセスポリシーについて詳しくは、「アクセスポリシー」を参照してください。

• 未公開の内部 Web アプリケーションおよび外部インターネット URL へのアクセス:

  ゼロトラストを有効にするために、Secure Private Accessは、アプリケーションに関連付けられておらず、アプリケーションにアクセスポリシーが設定されていない内部WebアプリケーションまたはイントラネットURLへのアクセスを拒否します。特定のユーザーにアクセスを許可するには、イントラネット Web アプリケーション用にアクセスポリシーが設定されていることを確認してください。

  Secure Private Access 内のアプリケーションとして設定されていない URL の場合、トラフィックはインターネットに直接流れます。

  • このような場合、イントラネット Web アプリケーション URL ドメインへのアクセスは直接ルーティングされるため、アクセスは拒否されます (ユーザーが既にイントラネット内にいる場合を除く)。
  • 未公開のインターネット URL では、許可されていないアプリに設定されているルール (有効になっている場合) に基づいてアクセスが行われます。デフォルトでは、このアクセスはSecure Private Access 内で許可されています。詳しくは、「 認可されていないWebサイトのルール設定」を参照してください。

アクセスポリシーの照合と優先順位付け

Secure Private Accessは、アクセスするアプリケーションを照合する際に次のことを行います：

1. アクセス先のドメインをアプリケーションURLのドメインまたは関連ドメインと照合して、完全に一致させます。

2. 完全な FQDN と一致するように設定されたSecure Private Access アプリケーションが見つかると、Secure Private Access はそのアプリケーションに設定されたすべてのポリシーを評価します。

   • ポリシーは、ユーザーコンテキストが一致するまで優先順位で評価されます。アクション (許可/拒否) は、優先度順に一致する最初のポリシーに従って適用されます。
   • 一致するポリシーがない場合、アクセスはデフォルトで拒否されます。

3. 完全な FQDN 一致が見つからない場合、Secure Private Access は最も長い一致 (ワイルドカードの一致など) に基づいてドメインを照合し、アプリケーションと対応するポリシーを検索します。

   例 1: 以下のアプリとポリシーの設定を考えてみましょう。

   アプリケーション	アプリケーション URL	関連ドメイン
   イントラネット	https://app.intranet.local	*.cdn.com
   Wiki	https://wiki.intranet.local	*.intranet.local

   ポリシー名	優先度	ユーザーおよび関連アプリ
   PolicyA	High	Eng-User5 (Intranet)
   PolicyB	Low	HR-User4 (Wiki)

   HR-User4がapp.intranet.localにアクセスすると 、次のことが起こります：

   1. Secure Private Accessはすべてのポリシーを検索して、アクセス対象のドメインと完全に一致するものを探します。この場合、app.intranet.local。
   2. Secure Private AccessはPolicyAを検索し、条件が一致するかどうかを確認します。
   3. 条件が一致しないため、Secure Private Accessはここで停止し、ワイルドカードの一致の確認は続行されません。PolicyBが一致していて（app.intranet.localはWikiアプリの関連ドメイン*.intranet.localでは一致するため）、アクセスが許可されていたとしても、続行されません。
   4. そのため HR-User4のWiki アプリへのアクセスは拒否されます。

   例 2: 同じドメインが複数のアプリケーションで使用されている以下のアプリとポリシー構成を考えてみます。

   アプリケーション	アプリケーション URL	関連ドメイン
   App1	xyz.com	app.intranet.local
   App2	app.intranet.local	-

   ポリシー名	優先度	ユーザーおよび関連アプリ
   PolicyA	High	Eng-User5 (App1)
   PolicyB	Low	HR-User7 (App2)

   Eng-User5ユーザーがapp.intranet.localにアクセスすると 、App1とApp2の両方がFQDNの完全一致に基づいて一致するため、Eng-User5ユーザーはPolicyAを介してアクセスできます。

   ただし、App1に代わりに関連ドメインとして*.intranet.localがある場合、app.intranet.localがPolicyBに完全に一致することになるため、ユーザーEng-User5にはアクセスできないため 、Eng-User5へのアクセスは拒否されます。

アプリ設定のベストプラクティス

IDP ドメインには独自のアプリケーションが必要です

IDP ドメインを関連ドメインとしてイントラネットアプリの設定に追加する代わりに、次の方法をお勧めします：

• すべての IDP ドメイン用に個別のアプリケーションを作成します。
• IDP 認証ページへのアクセスを必要とするすべてのユーザーがアクセスできるようにするポリシーを作成し、そのポリシーを最優先にします。
• ワークスペースで列挙されないように、このアプリをアプリ構成から非表示にします（［アプリケーションアイコンをユーザーに表示しない ］オプションを選択）。詳しくは、「 アプリケーション詳細の設定」を参照してください。

注:

このアプリ構成では、IDP 認証ページへのアクセスのみが有効になります。個々のアプリケーションへのさらなるアクセスは、やはり個々のアプリケーション構成とそれぞれのアクセスポリシーによって異なります。

設定例：

1. すべての一般的な FQDN を独自のアプリに設定し、必要に応じてグループ化してください。

   たとえば、Azure ADをIdPとして使用するアプリがいくつかあり、login.microsoftonline.comおよびその他の関連ドメイン（*.msauth.net）を設定する必要がある場合は、次の操作を行います：

   • https://login.microsoftonline.comをアプリケーションURLとして、*.login.microsoftonline.comおよび*.msauth.netを関連ドメインとして、1 つの共通アプリケーションを作成します。
2. アプリの設定時に [ ユーザーにアプリケーションアイコンを表示しない ] オプションを選択します。詳細については、「 アプリケーション詳細の設定」を参照してください。
3. 共通アプリケーションのアクセスポリシーを作成し、すべてのユーザーがアクセスできるようにします。詳細については、「 アクセスポリシーの設定。
4. アクセスポリシーに最高の優先順位を割り当てます。詳細については、「 優先順位」を参照してください。
5. 診断ログを確認して、FQDN がアプリと一致していること、およびポリシーが期待どおりに適用されていることを確認します。

同じ関連ドメインを複数のアプリケーションの一部にすることはできません

関連ドメインはアプリ固有のものでなければなりません。構成が競合すると、アプリへのアクセスに問題が生じる可能性があります。複数のアプリが同じ FQDN またはワイルドカード FQDN のバリエーションを使用して構成されている場合、次の問題が発生する可能性があります：

• Web サイトの読み込みが停止するか、空白のページが表示されることがあります。
• URL にアクセスすると、ブロックされたアクセスページが表示されることがあります 。
• ログインページが読み込まれない可能性があります。

そのため、1 つのアプリ内で独自の関連ドメインを設定することをおすすめします。

正しくない設定例:

• 例:複数のアプリケーションにわたる関連ドメインの複製

  両方とも Okta (example.okta.com) にアクセスする必要があるアプリが 2 つあるとします：

  アプリ	アプリケーション URL ドメイン	関連ドメイン
  App1	https://code.example.net	example.okta.com
  App2	https://info.example.net	example.okta.com

  ポリシー名	優先度	ユーザーおよび関連アプリ
  HR へのアプリ 1 の拒否	High	HRのユーザーグループ App1
  全員に App1 へのアクセス権を付与	中	ユーザーグループ「すべてのユーザー」へのアクセスを有効にする (App1)
  全員に App2 へのアクセス権を付与	Low	App2へのユーザーグループ「Everyone」へのアクセスを有効にする

  設定に関する問題: すべてのユーザーにApp2へのアクセスを許可することが目的でしたが、ユーザーグループHRはApp2にアクセスできません。ユーザーグループHRはOktaにリダイレクトされますが、App1（これもApp2と同じ関連ドメイン example.okta.com ）へのアクセスを拒否した最初のポリシーに基づいてスタックします。

  このシナリオは、OktaなどのIDプロバイダーでは非常に一般的ですが、共通の関連ドメインを持つ他の緊密に統合されたアプリでも発生する可能性があります。ポリシーの照合と優先順位付けの詳細については、「 アクセスポリシーの照合と優先順位付け」を参照してください。

  上記の構成に関する推奨事項:

  1. example.okta.com を関連ドメインとしてすべてのアプリから削除します。
  2. Okta専用の新しいアプリを作成します（アプリケーションURLはhttps://example.okta.comで、関連ドメインは*.okta.comです）。
  3. このアプリをワークスペースから非表示にします。
  4. ポリシーに最優先度を割り当てて、競合を排除します。

  ベスト・プラクティス:

  • アプリの関連ドメインは、別のアプリの関連ドメインと重複してはいけません。
  • このような場合は、共有関連ドメインに対応する新しい公開アプリを作成し、それに応じてアクセスを設定する必要があります。
  • 管理者は、この共有関連ドメインを実際のアプリとしてWorkspaceに表示する必要があるかどうかを評価する必要があります。
  • アプリをWorkspaceに表示してはならない場合は、アプリの公開時に、［ アプリケーションアイコンをユーザーに表示しない ］オプションを選択して、そのアプリをWorkspaceから非表示にします。

ディープリンク URL

ディープリンク URL の場合、イントラネットアプリケーションの URL ドメインを関連ドメインとして追加する必要があります：

例：

イントラネットアプリではURLがhttps://example.okta.com/deep-link-app-1をメインアプリケーションURLドメインとして設定されており、関連ドメインにはイントラネットアプリケーション URL ドメイン（つまり*.issues.example.net）が設定されています。

この場合は、URLhttps://example.okta.comを使用して別にIDプロバイダーアプリを作成し、次に関連ドメインを*.example.okta.comとして作成します。