Skip to content

非公式本サイトは非公式の日本語ドキュメントであり、Cloudflare 公式サイトではありません。最新情報はdevelopers.cloudflare.comをご確認ください。

ベストプラクティス

最終更新 Markdown で表示Agent セットアップ

スケーラブルな Access アプリケーションとポリシーを作るためのベストプラクティスを学びます。

再利用できるポリシーコンポーネントを作る

重複するルールを含むポリシーが多数ある場合は、ルールグループを作成し、複数のポリシーから参照することを推奨します。たとえば、「コーポレートユーザー」用のルールグループを定義し、デバイスポスチャチェックと特定のメールアドレスの両方を含めることができます。あるいは「開発者」だけを定義し、ID プロバイダー内のグループを参照することもできます。

ドメイン構造を定義する

Access アプリケーションには、柔軟で強力なドメイン構造の機能があります。ドメイン構造は、過度に緩くも厳しくもなく、アプリケーションのセキュリティ目標を達成できるものにしてください。本番向けのアプリケーションを設計する前に、アプリケーションパスのドキュメントを確認し、パス定義の仕組みとワイルドカードの使い方を理解してください。

1 つのアプリケーションに複数ドメインを指定する

社内向け Web アプリケーション、とくに自社開発のものを中心にしたワークフローでは、複数の内部サービスへの依存が課題になることがよくあります。また、SPA(シングルページアプリケーション)が原因で、クライアントレスアクセスの導入が難しくなる場合もあります。たとえば、アプリケーションに iFrame や埋め込みシステムがあり、別の内部アドレスや外部アドレスに依存していることがあります。

内部サービスがこの形で動いている場合は、1 つの Access アプリケーションに複数のトップレベルドメインを指定することを推奨します。一方、複数ドメインを使う目的がポリシー作成の簡素化なら、アプリケーションごとに 1 つのプライマリドメインを決め、残りは Terraform やほかの Infrastructure as Code(IaC)サービスで自動化することを推奨します。

役に立ちましたか?