| Oracle® Fusion Middleware Oracle Entitlements Server管理者ガイド 11g リリース1 (11.1.1) B65044-01 |
|
 前 |
 次 |
ポリシーには、特定の保護リソースへのアクセスをリクエスト側に付与する、または特定のロールに割り当てるために満たす必要のある条件を指定します。この章では、ポリシーを構成する要素であるOracle Entitlements Serverのポリシー・モデルの概要と、その要素のポリシー・ストアでの構成について説明します。この章には次の項目があります。
Oracle Entitlements Serverでは次のタイプのポリシーの作成がサポートされます。参照先の項には、ポリシー・タイプに関する詳細がその使用法とともに含まれています。
認可ポリシーは組織のリソースへのアクセスを制御するルールを定義します。2.1.1項「認可ポリシーについて」を参照してください。
ロール・マッピング・ポリシーには、プリンシパル・ユーザーへのロール・メンバーシップの付与または拒否を制御するルールを定義します。2.1.2項「ロールの割当てとロール・マッピング・ポリシーについて」
認可ポリシーは、リクエストしているユーザーのプロファイルに基づき特定のリソースへのアクセス権を付与または拒否するために作成されます。高いレベルから、認可ポリシーは、結果(付与または拒否)、プリンシパル(リクエストしているユーザー)、ターゲット・リソース、リソースに許可されたアクション、およびオプションの条件間の関係を定義します。認可ポリシーは、リクエストのパラメータがポリシーに指定したものと一致した場合に、アクセスのリクエストに適用できます。次の認可ポリシーの定義を考えてみます。
GRANT the SupportManagerEast role MODIFY access to the Incidents servlet if the request is made from an IP address of 229.188.21.21
この認可ポリシーでは、SupportManagerEastロールのメンバーであるユーザーに、インシデント・サーブレットへの変更目的のアクセス権を付与します。このポリシーには、IPアドレス229.188.21.21からのリクエストに限られるという条件による制約もあります。したがって、リクエストのパラメータがポリシーのパラメータと一致し(SupportManagerEastロールのメンバーがインシデント・サーブレットを変更する)、リクエストがIPアドレス229.188.21.21から出された場合、リクエストは許可されます。リクエストのパラメータがポリシーのパラメータと一致した(SupportManagerEastロールのメンバーがインシデント・サーブレットを変更する)が、リクエストがIPアドレス229.188.21.21から出されていない場合、リクエストは無視されます。次の用語と値のリストは、ポリシー定義から抽出されたもので、認可ポリシーのコンポーネントを構成します。
結果: 付与
アクション: 変更
ターゲット・リソース: インシデント・サーブレット
プリンシパル: SupportManagerEastロールのメンバー
条件: IPアドレス229.188.21.21
図2-1に、このポリシーのコンポーネントの、Oracle Entitlements Server認可ポリシー・オブジェクトへのマップ方法を示します。
認可ポリシーの作成、更新および削除方法の詳細は、4.5.5項「認可ポリシーの管理」を参照してください。
アプリケーション・ロールはユーザー・グループおよびロールの集合です。エンタープライズ・ユーザー、グループまたはアイデンティティ・ストアの外部ロール、またはポリシー・ストアの別のアプリケーション・ロールに割り当てることができます(アプリケーション・ロールを別のアプリケーション・ロールに割り当てることで、アプリケーション・ロールの階層を構築できます)。アプリケーション・ロールは次のいずれかの方法でユーザーに割り当てることができます。
ロールの特定のユーザー・メンバーシップに静的に付与。
ロール・メンバーシップを動的に割り当てるのに使用されるロール・マッピング・ポリシーのアプリケーション・ロールを参照。
ロール・マッピング・ポリシーにより、ロール・メンバーシップをユーザーに動的に割り当てる(GRANT)か、またはロール・メンバーシップをユーザーから動的に失効する(DENY)ことができます。次のロール・マッピング・ポリシーの定義を考えてみます。
GRANT the Employee group application role SupportManageEast if the request is made from an IP address of 229.188.21.21
このポリシーでは、SupportManagerEastアプリケーション・ロールをグループEmployeeのメンバーであるユーザーに付与します。このポリシーには、IPアドレス229.188.21.21からのリクエストに限られるという条件による制約があります。したがって、リクエストのパラメータがロール・マッピング・ポリシーのパラメータと一致し(リクエストしているユーザーはEmployeeグループのメンバーである)、リクエストがIPアドレス229.188.21.21から出された場合、アプリケーション・ロールは付与されます。リクエストが定義されたIPアドレスからではない場合、ロール・マッピング・ポリシーは無視されます。次の用語と値が、このロール・マッピング・ポリシー定義に適用されます。
結果: 付与
アプリケーション・ロール: SupportManagerEast
プリンシパル: Employeeグループのメンバー
条件: IPアドレス229.188.21.21
図2-2に、このポリシーのコンポーネントの、Oracle Entitlements Serverロール・マッピング・ポリシー・オブジェクトへのマップ方法を示します。
ロール・マッピング・ポリシーを使用して、特定のユーザーがアプリケーション・ロールに割り当てられるのを防ぐこともできます。次のロール・マッピング・ポリシーの定義を考えてみます。
DENY the Customers group application role GoldCircle if the account balance is less then $10,000
このポリシーでは、GoldCircleアプリケーション・ロールのCustomersグループのメンバーへの付与は、その口座残高が$10,000に満たない場合は拒否されます。ロール・マッピング・ポリシーの作成、更新および削除方法の詳細は、4.5.7項「ロール・マッピング・ポリシーの管理」を参照してください。
Oracle Entitlements Serverランタイム評価中に、次のことが行われます。
サブジェクトに基づき、次を実行することでアプリケーション・ロールのリストが決定されます。
ユーザーの静的ロール・メンバーシップを取得します。
すべての適用できるロール・マッピング・ポリシーをGRANTの結果で評価し、それを事前に決定されたロールのリストに追加します。
すべての適用できるロール・マッピング・ポリシーをDENYの結果で評価し、それを事前に決定されたロールのリストから削除します。
サブジェクトと取得したアプリケーション・ロールのリストに基づき、認可ポリシーのリストが評価されて、権限受領者、ターゲットの一致と条件に基づいて適用できるポリシーを見つけます(リソースで許可されるアクションは認可ポリシーで定義されます)。
最終的な認可決定は、アルゴリズムを組み合わせた“拒否のオーバーライド”に基づいており、コールしたアプリケーションに返されます。
1.4項「Oracle Entitlements Serverの認可ポリシーの処理方法」にはこの処理についての詳細が含まれています。
この項で定義されているポリシー・オブジェクトは、認可ポリシー・マネージャ管理コンソールを使用して作成、プロビジョニングおよび管理できます。
ポリシー・ストアは、すべてのOracle Entitlements Serverポリシー・オブジェクト(アプリケーション、リソースおよびさまざまなロール・タイプが含まれますがこれに限定されません)が保存される場所です。ポリシー・ストアはリレーショナル・データベース(推奨)またはLDAPベース・ディレクトリのどちらでもかまいません。詳細は、3.2.3項「ポリシー・ストアへのアクセス」を参照してください。
アプリケーションはロール、ポリシー、リソース定義、およびその他のポリシー・オブジェクト(実際には、特定のアプリケーションへのセキュア・アクセスを定義する必要のあるすべてのオブジェクト)を管理するための高レベルのコンテナです。アプリケーションは、配置済の1つのソフトウェア・アプリケーション、配置済のソフトウェア・アプリケーションのセット、またはソフトウェア・アプリケーションのコンポーネント(Enterprise Java Beanなど)に対応します。Oracle Entitlements Serverにより複数のアプリケーションを管理することができます。詳細は、4.5.1項「アプリケーションの管理」を参照してください。
アプリケーション・ロールとはユーザー、グループ、および他のアプリケーション・ロールのコレクションであり、エンタープライズ・ユーザー、グループ、アイデンティティ・ストアの外部ロール、またはポリシー・ストアの他のアプリケーション・ロールに割り当てることができます。たとえば、アプリケーション・ロールを作成するときに、あるターゲット・リソースへアクセスするために必要なすべての権限をそのロールに付与することができます。さらに、そのロールのメンバーシップをユーザーに付与することで、ユーザーに静的に割り当てることができます。あるいは、ロール・マッピング・ポリシーでロールを参照することで、ポリシー自体で付与または拒否される権限がポリシーのプリンシパルに付与され、動的に割り当てることもできます。1つのターゲット・アプリケーションが複数の異なるロールを持ち、よりきめの細かいアクセスのために、それぞれのロールに異なる権限のセットを割り当てることが可能です。
アプリケーション・ロールは、外部ロールに多対多でマッピングできます。たとえば、グループemployee (LDAPベースのアイデンティティ・ストアに保存)はアプリケーション・ロールcustomersupport member (1つのアプリケーションに定義)とアプリケーション・ロールIT member (別にアプリケーションに定義)にマップできます。詳細は、4.5.6項「ロール・カタログのアプリケーション・ロールの管理」を参照してください。
|
注意: Oracle Entitlements Server管理コンソールのロール・カタログ・ノードのアプリケーション・ロールを検索します。詳細は、第5章「セキュリティ・オブジェクトの問合せ」を参照してください。 |
外部ロールとは、LDAPサーバーまたはデータベースなどの外部アイデンティティ・ストアで定義されているユーザーおよびグループのコレクションです。外部ロールという用語は、エンタープライズ・ロールまたはエンタープライズ・グループと同義で使用されることもあり、通常はアイデンティティ・ストア内のLDAPグループとして実装されます。外部ロールのポリシーへの追加の詳細は、4.5.5.1項「認可ポリシーの作成」を参照してください。
|
注意: Oracle Entitlements Server内では、外部ロールおよびユーザーは読取り専用で表示できます。これらはOracle Identity Managerなどの別のツールで管理されます。詳細は、『Oracle Fusion Middleware Oracle Identity Managerシステム管理者ガイド』を参照してください。 |
プリンシパルとは、ポリシー内で定義されたアクセス権が付与されるアイデンティティです。プリンシパルには、ユーザー、外部ロールまたはアプリケーション・ロールを指定できます。ほとんどの場合、アプリケーション・ロールを指定します。プリンシパルのポリシーへの追加の詳細は、4.5.5.1項「認可ポリシーの作成」を参照してください。
認可ポリシーは、保護されたリソース上でエンティティ(権限受領者、プリンシパルまたはコード・ソース)に許可される権限のセット(Webページの表示やレポートの変更など)を指定するポリシーです。つまり、保護されたリソース上で誰が何を実行できるかを指定します。詳細は、4.5.5項「認可ポリシーの管理」を参照してください。
|
注意: Oracle Entitlements Server管理コンソールのデフォルトのポリシー・ドメイン(または該当する場合はカスタムのポリシー・ドメイン)のノードで認可ポリシーを検索します。詳細は、第5章「セキュリティ・オブジェクトの問合せ」を参照してください。 |
ロール・マッピング・ポリシーにはどのユーザーまたは外部ロールが認可ポリシーにマップされているかを定義します。ロール・マッピング・ポリシーは、少なくとも、どのサブジェクト(ユーザーおよび外部ロール)が適用可能なロールに割り当てられるかを定義するように作成されます。条件が含まれることもあります。詳細は、4.5.7項「ロール・マッピング・ポリシーの管理」を参照してください。
|
注意: Oracle Entitlements Server管理コンソールのロール・カタログ・ノードでロール・マッピング・ポリシーを検索します。詳細は、第5章「セキュリティ・オブジェクトの問合せ」を参照してください。 |
リソース・タイプは、保護されたオブジェクトのタイプを表します。共通の特徴を共有する保護されたソフトウェア・アプリケーション・コンポーネントは、特定のリソース・タイプで表すことができます。たとえば、ページのセットを1つのリソース・タイプで表し、銀行口座を別のリソース・タイプで表すことができます。リソース・タイプでは、リソース属性と、保護されたコンポーネントに適用できる有効なアクションを定義します。認可ポリシーで定義されたリソースにソフトウェア・アプリケーションによって渡されたリソースの照合方法も定義します。詳細は、4.5.2項「リソース・タイプの管理」を参照してください。
リソースは保護されたコンポーネントまたはオブジェクトであり、これに対してアクセス権が付与または拒否されます。リソースは、認可ポリシーで保護できるアプリケーション・コンポーネントまたはビジネス・オブジェクトを表します。アプリケーションの実行時にリソース名が渡され、プリンシパルが認可されたアクセスかどうかを決定するためにアクセス定義がチェックされます。リソースには関連付けられたリソース･タイプが必要です。詳細は、4.5.3項「リソースの管理」を参照してください。
ポリシー・ドメインは、リソース、資格および認可ポリシーの管理を促進するパーティションとして機能できるアプリケーション・オブジェクトの下のコンテナです。ポリシー・ドメインは管理者の権限を特定のリソース、資格、認可ポリシーのサブセットに限定できるオプションの管理構造体です。ポリシー・ドメインはランタイム・ポリシー評価時には無効です。複数のポリシー・ドメインを作成し、階層化できます。デフォルト・ポリシー・ドメインをその作成時に各アプリケーションに追加できます。詳細は、9.4「委任するポリシー・ドメインの使用」を参照してください。
資格(権限セットとも呼ばれます)は、リソースの小さなセット、およびタスクを実行するために必要な関連アクションを表します。ビジネス機能を実行するために必要な、タイプが異なる可能性がある関連リソースをグループ化します。資格は、複数のプリンシパルに付与できるアクセス権の再利用可能なコレクションです。詳細は、4.5.4項「資格の管理」を参照してください。
属性は、ポリシーの条件で使用できるデータ、またはポリシー決定により義務として返すことができるデータを表します。これは、名前、値として使用するデータの型、および値が1つのみかそれとも複数かによって定義されます。属性値は保護アプリケーションにより認可リクエストの一部として渡されるか、Oracle Entitlements Serverにより取得することができます。関数は、ポリシーの条件評価の一部として起動できるカスタム・コードを表し、戻り値は条件の評価に影響します。詳細は、4.5.9項「属性および関数を拡張として管理」を参照してください。
条件とは1つまたは複数の制約のことで、ポリシーが認可決定に含まれるには、trueと評価される必要があります。条件をポリシーに追加することはオプションで、使用すると保護リソースへのアクセスがさらに制限されます。一般的に、条件は何らかのユーザー、リソースまたはシステム属性の値をテストするブール式から構成されます。個々の条件はAND、OR、NOTといった論理演算子を使用して結合できます。条件は、日付、時間、時間範囲、曜日などに基づく制約を定義できます。詳細は、4.6項「条件ビルダーの使用」を参照してください。
義務には認可決定と一緒に返される追加の情報を指定します。使用すると、義務にはポリシー実行コンポーネントへの追加の要件を設定できるほか、単に有用な情報を含めることができます。たとえば、アクセスのリクエストが拒否された理由を義務として返すことができます。義務のポリシーへの追加の詳細は、4.5.5.1項「認可ポリシーの作成」を参照してください。
ロール・カテゴリはアプリケーション・ロールに関連付けることのできるオプションのタグで、検索に使用できます。ロール・カテゴリを使用すると、管理者はロールを任意のフラット・コレクションに編成できます。これはランタイム・ポリシー評価時には無効です。詳細は、4.5.8項「ロール・カテゴリの管理」を参照してください。
Oracle Entitlements Serverはポリシー管理とポリシー決定ロジックを組織のリソースから外部化する機能を提供します。組織のリソースへのアクセスを、それらにアクセスできるユーザー、グループおよびロールを指定するポリシーを実装することで保護します。リソースには、アプリケーション・ソフトウェア・コンポーネント(URL、Enterprise JavaBeans、JavaServer Pages)またはエンタープライズ・ビジネス・オブジェクト(顧客の口座、患者のレコード)があります。このユースケースでは、ポリシー・モデルを使用してAcme Investment Bankにより提供される金融サービスを保護する方法について考えてみます。これは階層型リソースの概念に基づきます。リソースはツリーに編成され、親要素から継承します。
このユースケースでは、次の条件が適用されます。
顧客は家族口座を開くことができ、その口座の所有者とみなされます。
顧客は家族メンバー用の子口座を開き、各メンバーに対し振替限度額を設定できます。振替限度額は顧客自身の振替限度額よりも低い必要があります。
各口座には、口座担当者としての役目を果たし、口座に振替限度額を設定する銀行員がいます。
サマリー・レポートと口座担当者レポートの両方が各家族口座に関連付けられます。
図2-3に、保護リソースをビジネス・オブジェクトとソフトウェア・コンポーネントに編成することによる金融サービスのシナリオを示します。Paulは口座担当者で、管理する口座の振替限度額を$100,000を設定できる銀行員です。Paulは口座の所有者であるBobの家族口座を管理します。この口座の振替限度額は$10,000です。Bobは自分の家族口座と、振替を行わないMary用に作成した子口座を管理します。これらの口座はビジネス・オブジェクトとみなされ、そのように保護されます。
口座所有者のBobには家族口座用に生成されたサマリー・レポートへのアクセス権があります。口座担当者のPaulにはBobのサマリー・レポートと自分の口座管理レポートへのアクセス権があります。子口座の名義人のMaryにはレポートへのアクセス権はありません。これらのレポートはJavaServerページとして生成され、ソフトウェア・コンポーネントとみなされて、そのように保護されます。
指定したユーザーに対し、金融サービスの口座(ビジネス・オブジェクト)または口座レポート(ソフトウェア・コンポーネント)へのアクセスのリクエストでは、次の質問に基づき、決定が生成されます。
このユーザーは口座の名義人、口座の所有者または口座担当者ですか。
このユーザーはこの口座から資金の振替ができますか(ロール、振替限度額、取引時間による)。
このユーザーはどのレポートにアクセスできますか。
最初の2つの質問はビジネス・オブジェクトを保護するために作成されたポリシーを使用して決定できますが、最後の質問はソフトウェア・コンポーネントを保護するために作成されたポリシーを使用して決定できます。次の各項では、ポリシーを概念化する方法について説明します。
図2-3「ソフトウェア・コンポーネントとビジネス・オブジェクトのユースケース」のAccount Reportsノードは、レポーティング・アプリケーションを表しています。Summary.jspおよびDetailed.jspはソフトウェア・コンポーネントです。これらのソフトウェア・コンポーネントを保護するためにポリシーをモデル化する方法を決定するときに、選択するオプションがいくつかあります。1つのオプションは、グループ・メンバーシップを使用することで上位ノードのレポーティング・アプリケーションに認可ポリシーを設定します。次の例で、リソースとそれにアクセスできるユーザーのグループに名前を付けることで、アクセス権を明示的に付与する方法を示します。
GRANT the BankManagers group access to the AccountReports node
このトップダウンの認可ポリシーでは、Account Reportsノードへのアクセス権をBankManagersグループのユーザーに付与します。これらのリソースは階層化されているので、許可されたグループの全員がサマリーおよび詳細レポートにアクセスできます。しかしこのアクセスはシステム・ベースまたは属性ベースの条件を使用して制約されることがあります。たとえば、時間に基づく、または特定のユーザー、グループまたはリソース属性に基づく条件を追加することで、さらにアクセスが制限されます。次の例で、時間ベースの条件によりレポートへのアクセスが通常の営業時間に制限される方法を示します。
GRANT the BankManagers group access to the AccountReports node IF the request is made between 09:00 and 17:00
もう1つのオプションでは、グループではなくロールとしてプリンシパルを定義することでトップダウンの認可ポリシーを設定できます。１つのロールはユーザーまたはグループから構成されます(アプリケーション・ロールはそれが構成されたアプリケーションに特有であるのに対し、LDAPロールはエンタープライズ全体で付与されます)。
|
注意: 2.1項「Oracle Entitlements Serverポリシーについて」で説明したように、ユーザーはメンバーシップまたはロール・マッピング・ポリシーを使用してロールに割り当てることができます。 |
次の例では、リソースに明示的に名前が付けられ、アクセス権は定義済みのロールに割り当てられているユーザーに暗黙的に付与されます。
GRANT access to AccountReports node if user has BankManagers role
BankManagersロールをレポーティング・アプリケーションにアクセスしているユーザーに(BankManagersグループのメンバーであれば)動的に割り当てることもできます(次に例示)。
GRANT BankManagers role to members of BankManagers group FOR access to AccountReports node
以前の認可ポリシーを定義するもう１つの方法は、グループ・メンバーシップではなくユーザー属性値に基づきロールを割り当てることです(規模の大きい企業では、グループ・メンバーシップではなく属性に基づきユーザーを割り当てることが通常はより効率的です)。次の例では、ユーザーのプロファイルのUserType属性の値がBankManagerである場合に、BankManagersロールを、リクエストしているユーザーに割り当てます。
GRANT BankManagers role to anyone defined by UserType 'BankManager' FOR access to the AccountReports node
前の例では、上位ノードのレポーティング・アプリケーションからレポートまで範囲とする認可ポリシーを示していますが、認可ポリシーは特定のレポート・ノードに対して定義することもできます。次の例では、Summary.jspレポートへのアクセス権をBankManagersおよびAccountOwnersロールのすべての割当先に付与します。追加の条件は、アクセスをリクエストしているプリンシパルが、レポートの関連アカウントにリストされている必要があることです。
GRANT Summary.jsp access to all members of BankManagers and AccountOwners role IF the requesting assignee is listed as OWNER or MANAGER on specified account
もう1つの例は、Detailed.jspレポートへのアクセスが、BankManagerロールに割り当てられたユーザーに付与できる方法を示しています。
GRANT Detailed.jsp access to all assignees of BankManagers role
前の例は、認可ポリシーが特定のアプリケーション・ソフトウェア・コンポーネントにモデル化できる方法を示しています。実際の企業でのシナリオでは、各アプリケーションに数十または数百のリソースが含まれる場合があるので、それぞれに対して認可ポリシーを作成するのは現実的ではない可能性があります。リソース属性の概念は、このアプリケーション・ソフトウェア・コンポーネント・リソースと関連する認可ポリシーの急増に対処するために、Oracle Entitlements Serverにより実装されました。
リソースと属性を関連付けることで、属性の値に基づきアクセス権を付与することができます。たとえば、filetypeはHTMLページ、イメージまたはPDFを定義するのに使用するリソース属性です。if filetype=pdfとして条件を定義することで、リソースに関連付けられたすべてのPDFファイルへのアクセス権を付与することができます。次の例ではリソース属性を使用します。これにより、リクエストされているレポート・タイプが特定のユーザー･プロファイルのUserReportType属性の値と一致している場合にのみアクセス権が付与されるにもかかわらず、BankManagersおよびAccountOwnersロールに割り当てられたユーザーはすべてのレポートにアクセスできます。
GRANT users assigned BankManagers or AccountOwners roles
access to AccountReports
IF requested ReportType matches UserReportType attribute value
in user profile
このポリシーでは、アクセスがリソース属性値とユーザー属性値の一致に基づいて制約されるにもかかわらず、BankManagersおよびAccountOwnersにすべてのレポートへのアクセス権が付与されます。この方法の利点は、リソースがアプリケーションに追加されたり削除されたりしても、アクセスを管理するポリシーを変更する必要がないことにあります。リソースが変更されても、アプリケーションに付属するReportTypeリソース属性によるアクセスの管理は継続します。
ビジネス・オブジェクトを保護するために認可ポリシーをモデル化する方法を決定するときに、選択するオプションがいくつかあります。この銀行シナリオでは、ビジネス・オブジェクトは銀行口座です。図2-3「ソフトウェア・コンポーネントとビジネス・オブジェクトのユースケース」は、銀行口座の構造を表しています。
各銀行口座に、担当者、所有者、および名義人を、特定の権限のセット(または 資格)に割り当てられた各スコープとともに持たせることができます。そのため、ユーザーが銀行口座で実行できることを評価しているポリシーが基づくのは、リソースではなくユーザーの属性です。次の例では誰でも振替は可能ですが、リクエストされた口座の所有者としてそのユーザーが定義され、振替金額がユーザーに定義された制限額よりも少ないか同じである場合にのみ、その権限が付与されます。
GRANT anyone transfer privileges only IF the user is listed as OWNER on specified account AND transfer amount is equal to or less than the transfer limit
ユーザーの資格を取得する別のオプションがあります。振替のリクエストと振替限度額を比較するのでなく、Oracle Entitlements Serverでは評価の出力として振替限度額を返すことができます。このシナリオでは、ユーザーが口座にアクセスできるかどうかは検証されますが、振替金額が義務としてコール元に返されます(Javaオブジェクト内で)。ここでは、振替金額が振替限度額内であるかどうかの検証はアプリケーションに任されています。次の例で、このモデルを説明します。
GRANT anyone transfer privileges only IF the user is listed as OWNER on specified account THEN RETURN transfer limit to calling application
銀行口座が個別のリソース・インスタンスに対応するモデルを使用することもできますが、ポリシーの急増(口座ごとに1つ)が生じ、管理が難しくなります。たとえば、Acme Investment Bankに100,000口座がある場合、振替を管理するだけで少なくとも100,000ポリシーが必要になります。義務の追加の詳細は、4.5.5項「認可ポリシーの管理」を参照してください。
