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

Secure Private Accessにおける公開済みおよび未公開アプリのアプリケーションアクセス

• 公開済みWebアプリケーションおよび関連ドメインへのアクセス:
  • エンドユーザーが公開済みWebアプリに関連付けられているFQDNにアクセスする場合、そのユーザーに対して許可または制限付きで許可のアクションが明示的に設定されたアクセスポリシーがある場合にのみ、アクセスが許可されます。
    注:
    複数のアプリケーションが、完全に一致する同じアプリケーションURLドメインまたは関連ドメインを共有しないことをお勧めします。複数のアプリが同じアプリケーションURLドメインまたは関連ドメインを共有している場合、アクセスは正確なFQDNの一致とポリシーの優先順位に基づいて提供されます。詳細については、「アクセスポリシーの一致と優先順位付け」を参照してください。

  • 公開済みアプリと一致するアクセスポリシーがない場合、またはアプリがどのアクセスポリシーとも関連付けられていない場合、デフォルトでアプリへのアクセスは拒否されます。アクセスポリシーの詳細については、「アダプティブアクセスポリシーの構成と管理」を参照してください。
• 未公開の内部Webアプリケーションおよび外部インターネットURLへのアクセス:
  ゼロトラストを有効にするため、Secure Private Accessは、アプリケーションに関連付けられておらず、アプリケーション用にアクセスポリシーが構成されていない内部WebアプリケーションまたはイントラネットURLへのアクセスを拒否します。特定のユーザーへのアクセスを許可するには、イントラネットWebアプリケーション用にアクセスポリシーが構成されていることを確認してください。
  Secure Private Access内でアプリケーションとして構成されていないURLの場合、トラフィックはインターネットに直接流れます。
  • そのような場合、イントラネットWebアプリケーションURLドメインへのアクセスは直接ルーティングされるため、アクセスは拒否されます（ユーザーがすでにイントラネット内にいる場合を除く）。
  • 未公開のインターネットURLの場合、アクセスは、有効になっている場合は未承認アプリ用に構成されたルールに基づきます。デフォルトでは、このアクセスは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
   ウィキ	https://wiki.intranet.local	*.intranet.local

   ポリシー名	優先度	ユーザーと関連アプリ
   PolicyA	高	Eng-User5 (イントラネット)
   PolicyB	低	HR-User4 (ウィキ)

   もし 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	高	英語ユーザー5 (アプリ1)
   PolicyB	低	HR-ユーザー7 (アプリ2)

   ユーザー Eng-User5 が app.intranet.local にアクセスすると、App1 と App2 の両方が正確な FQDN マッチに基づいて一致するため、Eng-User5 ユーザーは PolicyA を介してアクセスできます。
   ただし、App1 が関連ドメインとして *.intranet.local を持っていた場合、app.intranet.local が PolicyB に正確に一致し、そのユーザー Eng-User5 はアクセス権を持たないため、Eng-User5 へのアクセスは拒否されていたでしょう。

アプリ構成のベストプラクティス