グローバルセキュリティポリシー¶
グローバルセキュリティポリシー では、特定の条件を確認するすべてのビューまたは一部のビューに対してすべてのユーザーや一部のユーザーに適用されるセキュリティ制限を定義できます。
グローバルポリシーは、ビューの制限 (行制限 および 列権限) よりも管理が容易です。これは、同じセキュリティポリシーを複数のビューに適用する場合、ポリシーを複数のビューに割り当てるのではなく、一度に定義できるからです。
グローバルポリシーは、多くの場合、「タグ」と一緒に使用されます。これは、ビューとその列に割り当てることができるラベルです。たとえば、特定のロールを持つユーザーだけが、「secret」タグのあるビューをクエリできるようにグローバルポリシーを定義できます。また、タグ「confidential」のある列をすべてマスクするグローバルポリシーも定義できます。
注釈
この機能は、 エンタープライズプラス サブスクリプションバンドルでのみ使用可能です。所有するバンドルを見つけるには、Design Studio または Administration Tool の [About] ダイアログを開きます。この詳細については、「 Denodo Platform - サブスクリプションバンドル 」のセクションを参照してください。
注釈
現在、Virtual DataPort のタグは、Data Catalog のタグに関連付けられていません。
タグの管理¶
Virtual DataPort のタグは、ビューとその列に割り当てるラベルで、以下の用途に使用できます。
複数のビューと列に適用されるグローバルセキュリティポリシーを定義します。
これは、Design Studio と Administration Tool のユーザーがビューの整理と参照を行うための、もう 1 つの方法です (他のツールでは使用できません)。
タグを管理するには、Administration Tool または Design Studio の左側のパネルにある [Tags] をクリックします。タグを展開すると、そのタグが設定されているエレメントが表示されます。このパネルから、タグの作成、編集、削除、およびビューとその列へのタグの割り当てを行うことができます。

タグの管理: [Tags] エクスプローラー¶
タグを作成するには、[File] メニュー > [New] > [Tag] をクリックします。タグの名前とその説明を入力します。

タグの管理: タグの作成¶
タグを変更するには、[Tags] ツリーでタグを探して開きます。このダイアログでは、以下の操作が可能です。
タグの名前を変更して、その説明を変更します。
ビューにタグを割り当てます。それには、[Tagged views] タブをクリックし、ツリーをクリックしてビューのリストを表示した後、ビューをパネル [Tagged views] にドラッグします。
列にタグを割り当てます。それには、[Tagged Columns] をクリックします。Design Studio でビューをドラッグし、ポップアップで、タグを付ける列を選択します。Administration Tool で列をドラッグします。
ビューまたは列からタグを削除するには、[Tagged views] または [Tagged Columns] に移動し、コンテキストメニューを使用します。

タグの管理: タグの割り当て (Web Design Studio)¶
タグの削除¶
タグを削除するには、タグを開き、[Drop] をクリックします。その際は、以下の点に注意してください。
このタグを使用するグローバルセキュリティポリシーも同様に削除されます 。これらのグローバルセキュリティポリシーを削除するには、ユーザーが必要な権限を持っていなければなりません。
このタグが割り当てられているビューからタグの割り当てが解除されます。
タグの管理およびタグの割り当てと割り当て解除に必要な権限¶
管理者は、以下の制限による影響を受けません。つまり、任意のタグの作成、変更、削除を行い、任意のビューにそのタグを割り当て、グローバルポリシーで使用できます。
タグの作成、その説明の変更、タグの削除を行うには、 manage_tags ロールが必要です。タグがビューまたはグローバルポリシーに割り当てられている場合、そのエレメントに対する特定の権限も必要です (以下を参照)。
ビューやビューの列へのタグの割り当ておよび割り当て解除を行うために必要な権限を以下に示します。
ユーザーは、ビューのデータベースの管理者です。
あるいは、ユーザーは assign_tags ロールと、ビューに対する「METADATA」権限を持ちます。
これらのルールは、ユーザーがビューの所有者である場合も適用されます。つまり、ビューの所有者は、ビューの作成と変更はできますが、そのビューのタグを変更することはできません。
グローバルポリシーで使用されるタグを削除する場合、グローバルポリシーも削除されるため、そのための権限も必要です。
グローバルセキュリティポリシー¶
グローバルセキュリティポリシー は、一般的なビジョンからのビューに対する権限の定義を表します。このタイプのエレメントでは、個々のビューやフィールドではなく、抽象的な概念に基づいて機能するビューに対する制限を作成できます。クエリを実行中のユーザーまたはそのロールに基づいて、 誰 に グローバルセキュリティポリシー* を適用するのかを指定できます。また、ユーザーセッションの属性に基づいて `誰が` 条件を指定するかを絞り込むこともできます。次に、タグを使用してポリシーが **どの エレメントに適用されるかを定義し、最後に、同じくタグを使用して表現される、適用される制限を指定します (必要に応じてオプションの条件を含む)。
例
例 1
顧客の住所のビューがあり、「developers」ロールを持つユーザーにこれらの列が表示されないようにします。それには、セマンティックを指定するためのタグをそのビューに追加します。

タグが割り当てられたビュー¶
「address」ビューに追加されたタグ:
「locations」タグの付いたビュー。
「location」タグの付いたフィールド「address」、「district」、「city_id」。
「zip_code」タグの付いたフィールド「postal_code」。
「phone_number」タグの付いたフィールド「phone」。
ここで、「developers」ロールを持つユーザーが、「locations」タグの付いたビューにアクセスする場合、「location」、「zip_code」、または「phone_number」のタグが付いたフィールドをマスクする必要があることを示す、グローバルセキュリティポリシーを作成します。

開発者のマスキングポリシーの例¶
これ以降は、「developers」ロールを持つユーザーが「locations」タグの付いたビューにアクセスすると、「location」、「zip_code」、または「phone_number」のタグの付いたフィールドに対してデータがマスクされて表示されます。

developers ロールを持つユーザー¶
例 2
「developers」ロールを持つユーザーに新しい制限を適用します。特定のゾーンにある場所の行だけを表示する必要があります。たとえば、 California と Florida の行だけを表示させたいとします。その場合は、その情報を含む列にタグを付け、必要な制限付きのグローバルセキュリティポリシーを作成する必要があります。

タグが割り当てられたビュー¶
以下を含む「address」ビューに追加されたタグを変更しました。
「zone」タグも付いたフィールド「district」。
ここで、「developers_filter_data」というグローバルセキュリティポリシーを作成します。このポリシーにより、「developers」ロールを持つユーザーが「locations」タグの付いたビューにアクセスする場合、「zone」が California または Florida であるという条件を満たす行のみが表示されます。

開発者の行のフィルタポリシーの例¶
注釈
条件はタグで表します。
これ以降は、「developers」ロールを持つユーザーが「locations」タグの付いたビューにアクセスすると、条件を満たす行だけが表示されます。また、最初の例で作成されたグローバルセキュリティポリシーにより、「location」、「zip_code」、「phone_number」のタグの付いたフィールドのデータはマスクされます。

developers ロールを持つユーザー¶
注釈
複数のグローバルセキュリティポリシーが適用されます。
例 3
支払いに関する情報を含むビューがあります。「developers」ロールを持つユーザーがこのビューを実行できないようにします。それには、ビューにタグを追加し、目的のロールに対して実行を 拒否する グローバルセキュリティポリシーを作成します。

タグが割り当てられたビュー¶
「payment」ビューに追加されたタグ:
「confidential」タグの付いたビュー。
ここで、「developers」ロールを持つユーザーが、「confidential」タグの付いたビューを実行できないことを示す、「developers_deny_views」という名前のグローバルセキュリティポリシーを作成します。

開発者の拒否ポリシーの例¶
これ以降、「developers」ロールを持つユーザーは、「confidential」タグの付いたビューにアクセスできません。

developers ロールを持つユーザー¶
グローバルセキュリティポリシーの管理¶
グローバルセキュリティポリシーを作成するには、[Administration] メニュー > [Semantics and governance] > [Global security policies] をクリックします。
このダイアログでは、すべてのポリシーを一度に有効または無効にすることができます。

グローバルセキュリティポリシー¶
グローバルセキュリティポリシーの作成¶
[New] をクリックしてグローバルセキュリティポリシーを作成し、以下の情報を入力します。

グローバルセキュリティポリシーの作成¶
Name: 新しいポリシーの名前。
Description: グローバルセキュリティポリシーの説明。
Enabled: 実行時にグローバルセキュリティポリシーを使用するかどうかを示します。これは、ポリシーを一時的に無効にする場合に便利です。
Audience: グローバルセキュリティポリシーを 誰 に適用するかを示します。オプションは以下のとおりです。
All: ポリシーは、すべてのユーザーに適用されます。生成された制限は、現在のユーザーおよびそのロールの制限と AND で結合されます。
Any role in list: 選択したロールのうち少なくとも 1 つを持つすべてのユーザーに適用されます。生成された制限は、グローバルセキュリティポリシーをトリガーしたロールの制限と AND で結合されます。
All roles in list: 選択したすべてのロールを持つすべてのユーザーに適用されます。生成された制限は、グローバルセキュリティポリシーをトリガーしたロールの制限と AND で結合されます。
Roles not in list: 選択したロールに存在しないロールを持つすべてのユーザーに適用されます。生成された制限は、グローバルセキュリティポリシーをトリガーしたロールの制限と AND で結合されます。
User not in list: 選択したリストにないすべてのユーザーに適用されます。生成された制限は、現在のユーザーの制限と AND で結合されます。
Any user in list: 選択したリストにあるすべてのユーザーに適用されます。生成された制限は、現在のユーザーの制限と AND で結合されます。
Attributes of the user's session: グローバルセキュリティポリシーが属性に依存する場合、指定された条件がチェックされます。これらの条件も検証されると、グローバルセキュリティポリシーが適用されます。
注釈
属性 accessInterface 、 clientIp 、 intermediateClientIp 、 userAgent はクライアントアプリケーションで上書きされる場合があるため、制御された環境のみでセキュリティ構成に使用してください。
注釈
セッション属性 userRoles を使用することで、ユーザーの有効なロールに基づいてグローバルセキュリティポリシーを適用できます。これにより、権限の管理の柔軟性が向上し、特定の要件に合わせてアクセス制御をカスタマイズする機能が改善されます。
Apply the policy to the audience that satisfies any of these conditions: 現在のセッションで、指定された属性条件のうち少なくとも 1 つが満たされる場合、すべてのユーザーに適用されます。
Apply the policy to the audience that satisfies all these conditions: 現在のセッションで、指定されたすべての属性条件が満たされる場合、すべてのユーザーに適用されます。
Apply the policy to the audience that fails to meet all these conditions: 現在のセッションで、指定された属性条件がいずれも満たされない場合、すべてのユーザーに適用されます。
Resource Manager で追加された変数は、ユーザーセッションの属性として使用することもできます。
注釈
管理者ユーザーおよびローカル管理者ユーザー (管理されているデータベースのビューである場合) は、グローバルセキュリティポリシーの影響を受けません。
Elements: グローバルセキュリティポリシーが どの エレメントに適用されるかを示します。エレメントは個別ではなく、タグで参照します。オプションは以下のとおりです。
All views: すべてのビューに適用されます。
Views tagged with any: リストの少なくとも 1 つのタグでタグ付けされたすべてのビューに適用されます。
Views tagged with all: リストのすべてのタグでタグ付けされたすべてのビューに適用されます。
Views not tagged with: リストの少なくとも 1 つのタグでタグ付けされていないすべてのビューに適用されます。
Columns tagged with any: リストの少なくとも 1 つのタグでタグ付けされた列を含むすべてのビューに適用されます。
Columns tagged with all: リストのすべてのタグでタグ付けされた列を含むすべてのビューに適用されます。
Columns not tagged with: リストの少なくとも 1 つのタグでタグ付けされていない列を含むすべてのビューに適用されます。
最後に、影響を受けるエレメントをデータベースのリストに制限できます。つまり、リストで指定されていないデータベースのエレメント (定義されている場合) は、グローバルセキュリティポリシーの影響を受けません。
Restrictions: これは、グローバルセキュリティポリシーがトリガーされたときに適用される制限です。オプションは以下のとおりです。
Deny execution: ビューにアクセスする際に権限エラーがスローされます。
Mask columns tagged with any of these tags: リストの少なくとも 1 つのタグでタグ付けされたビューのフィールドがマスクされます。条件はオプションです (タグの使用が可能)。
Mask columns tagged with all of these tags: リストのすべてのタグでタグ付けされたビューのフィールドがマスクされます。条件はオプションです (タグの使用が可能)。
Only show rows that fulfill condition: 返される行が条件を使用してフィルタされます。条件は必須です (タグの使用が可能)。
Custom view policy: カスタムビューポリシーが実行されます。開発者ガイドの「 カスタムポリシー 」のセクションで、カスタムポリシーの概要や開発方法について説明しています。
Deny execution if (any tag): リストのタグを少なくとも 1 つ含む列がある場合、ビューにアクセスする際に権限エラーが発生します。
Deny execution if (all tag): リストのタグをすべて含む列がある場合、ビューにアクセスする際に権限エラーが発生します。
Only show rows that fulfill condition if (any tag): 返される行は、リストのタグを少なくとも 1 つ含む列がある場合に、条件を使用してフィルタされます。この条件は必須です (タグの使用が可能)。
Only show rows that fulfill condition if (all tags): 返される行は、リストのタグをすべて含む列がある場合に、条件を使用してフィルタされます。この条件は必須です (タグの使用が可能)。
Condition: 制限が実行される場合に適用される条件です。ユーザーには、その条件を満たす行やデータが表示されます。これらは、[subselect] を使用する場合を除き、タグで表現されます。この場合、[subselect] は通常のクエリとして処理されます。
Operators for session attributes conditions:
以下の演算子を使用するよう指定出来ます。
=
等号演算は、指定された値とユーザーセッションの属性値の間で行われます。contains
条件は、指定された値がユーザーセッションの属性値に含まれる場合に満たされます。セッション属性に複数の値 (リスト) がある場合、指定された値が、少なくとも 1 つのセッション属性の値に含まれる場合、条件が満たされます。in
条件は、指定された値がユーザーセッションの属性値に等しい場合に満たされます。セッション属性に複数の値 (リスト) がある場合、指定された値が、少なくとも 1 つのセッション属性の値に等しい場合、条件が満たされます。like
条件は、指定されたパターン値がユーザーセッションの属性値と一致する場合に満たされます。セッション属性に複数の値 (リスト) がある場合、指定されたパターン値が、少なくとも 1 つのセッション属性の値と一致する場合、条件が満たされます。
ユーザーやロールによる制限との組み合わせ
グローバルセキュリティポリシーによって割り当てられた制限は、以下のように、グローバルセキュリティポリシーをトリガーした 対象者 のタイプに応じて、「 行制限 」で定義された制限と結合されます。
対象者のタイプ別:
すべて: グローバルセキュリティポリシーによる制限は、ユーザーとそのロールに定義された制限と AND で連結されます。
ロール 別: グローバルセキュリティポリシーによる制限は、グローバルセキュリティポリシーをトリガーしたロールに定義された制限と AND で連結されます。
ユーザー 別: グローバルセキュリティポリシーによる制限は、グローバルセキュリティポリシーをトリガーしたユーザーに定義された制限と AND で連結されます。
「行制限 」で定義されたマスキング制限がユーザーやロールにある場合、影響を受けるフィールドにはそのマスキング表現が使用されます。
たとえば、以下の例を考えます。
タグ「region」がある列のビュー「employees」。
行制限 があるロール「developers」は、ビュー「employees」で列「salary」の値を「-1」に置き換えます。
「marketing」ロールと「developers」ロール (つまり、「対象者 = リスト内の任意のロール) に適用され、値が「USA」の「region」タグが付いた行のみを返すグローバルセキュリティポリシー。
「developers」ロールを持つユーザーが Virtual DataPort に接続すると、該当のポリシーがトリガーされ、この現象が生じます。そのため、現在の実行に対する developers
ロールには、以下の制限があります。
列「salary」のマスキング (行制限 による)。
値が
USA
のregion
タグが付いた列をフィルタリング (グローバルセキュリティポリシーによる)。
たとえば、以下のビューがあるとします。
データベース base_views には、ビュー customer と payment が格納されています。
customer ビューには、
sensitive
タグの付いたemail
フィールドがあります。payment ビューには、
amounts
タグの付いたamount
フィールドがあります。データベース final_views には、以前のビューの上に作成されたビュー customer_payments が格納されています。
タグ sensitive
と amounts
でマスクされた列の可視性を、 finance と sales 以外のロールに制限するとします。
[Audience] で [Roles not in list] オプションを選択し、 finance と sales を値として追加します。また、タグ email
と amounts
でタグ付けされた列のマスキングを定義します。
このように、ユーザーが持っている ロール のうち、 finance や sales 以外のロールに対してマスキング制限が生成されます。

ロール「finance」や「sales」を持たないユーザーに適用されるグローバルセキュリティポリシー¶
ユーザー denodo_user にロール marketing があるとします。このユーザーとそのロールには、以下の権限があります。わかりやすいように、 EXECUTE
権限のみを示しています。
ロール/ユーザー |
データベース |
Execute |
---|---|---|
denodo_user |
base_views |
○ |
denodo_user |
final_views |
○ |
marketing |
base_views |
○ |
marketing |
final_views |
○ |
このユーザーは Virtual DataPort に接続し、ビュー final_views を実行します。作成されたグローバルセキュリティポリシーが適用されて制限が生成されますが、 データはマスクされません 。

「Roles not in list...」の対象者にはグローバルセキュリティポリシーの効果が及びません。¶
これはなぜでしょうか? ポリシーが適用され、制限が生成されましたが、グローバルセキュリティポリシーでは、ポリシーをトリガーする対象者に制限を生成しています。
この場合、[Audience] は [Roles not in list] で、ロールに finance と sales を指定しています。そのため、制限はそのリストにないロールに対して生成されています。この例で該当するのは marketing ロールです。
ポリシー適用後の制限を以下の表に示します。
ロール/ユーザー |
ビュー |
Execute |
制限 |
---|---|---|---|
denodo_user |
customer_payments |
○ |
× |
denodo_user |
customer |
○ |
× |
denodo_user |
payment |
○ |
× |
marketing |
customer_payments |
○ |
× |
marketing |
customer |
○ |
[email] フィールドをマスクする |
marketing |
payment |
○ |
[payment] フィールドをマスクする |
この表は、ユーザー denodo_user に直接付与された EXECUTE
権限があり、この対象者に制限が適用されないため、このユーザーがデータを見るのに十分な権限を持っていることを示しています。このため、 denodo_user は制限なしでデータを確認できます。
このグローバルセキュリティポリシーを予定どおりに機能させるには、権限を変更する必要があります。ユーザーの EXECUTE
権限を削除します。
ロール/ユーザー |
データベース |
Execute |
---|---|---|
denodo_user |
base_views |
× |
denodo_user |
final_views |
× |
marketing |
base_views |
○ |
marketing |
final_views |
○ |
その後、 denodo_user がビューを実行すると、ポリシーが再度適用され、ビューに対して EXECUTE
を付与するロールや直接権限がなくなります。このため、データはマスクされた状態になります。

「Roles not in list...」の対象者にはグローバルセキュリティポリシーの効果が及ぶようになります。¶
ロール/ユーザー |
ビュー |
Execute |
制限 |
---|---|---|---|
denodo_user |
customer_payments |
× |
× |
denodo_user |
customer |
× |
× |
denodo_user |
payment |
× |
× |
marketing |
customer_payments |
○ |
× |
marketing |
customer |
○ |
[email] フィールドをマスクする |
marketing |
payment |
○ |
[payment] フィールドをマスクする |
データベースのリストの指定
クエリが実行されると、Virtual DataPort ではシステムで作成されたグローバルセキュリティポリシーを適用するために、クエリツリーに存在するすべてのビューをチェックします。デフォルトでは、すべてのデータベースのビューがチェックされます。この動作は、ポリシー定義でデータベースのリストを選択して構成できます。このような場合、グローバルセキュリティポリシーは、選択されたデータベースに存在するビューにのみ適用されます。
たとえば、以下のビューがあるとします。
データベース base_views には、ビュー customer と payment が格納されています。
customer ビューには、
sensitive
タグの付いたemail
フィールドがあります。payment ビューには、
amounts
タグの付いたamount
フィールドがあります。データベース final_views には、以前のビューの上に作成されたビュー customer_payments が格納されています。
タグ sensitive
と amounts
でマスクされた列の可視性をロール marketing に制限するとします。marketing
ロールに影響を与えるグローバルセキュリティポリシーを作成し、 email
と amounts
のタグが付いた列をマスクします。
最後に、 final_views データベースのみにポリシーを適用するように選択します。

データベースで制限する marketing ロールのグローバルセキュリティポリシー¶
このポリシーでは、 marketing のユーザーが最終的な customer_payments ビューを実行すると、返される結果はマスクされません。
これは、グローバルセキュリティポリシーが final_views データベースのビューにのみ適用されるように定義されているためです。列にタグが付けられたビューがデータベース base_views にあるため、ポリシーはそのビューに影響を与えず、結果は制限なしで返されます。

データベース final_views で制限する marketing ユーザーの結果¶
ここで、データベース base_views をデータベースのリストに追加するポリシーを編集します。次に、 marketing のユーザーで再度実行します。この変更により、グローバルセキュリティポリシーは base_views データベースのビューにも適用されるため、ポリシーはタグ付きの列に対する制限を生成し、返される結果はマスクされます。

データベース final_views と base_views で制限する marketing ユーザーの結果¶
対象者に関する注意事項
グローバルセキュリティポリシーで使用されるロールが削除されると、グローバルセキュリティポリシーは無効となり、評価されません。
マスキングに関する注意事項
タグ付けされたフィールドは任意の Virtual DataPort タイプにすることができるため、一般的なタイプごとに異なるマスキングを構成できます。また、タイプに応じて選択される一連のマスキング式も組み込まれています。組み込みのカスタムマスキング式の詳細については、「 行制限 」を参照してください。
フィールドに複数のマスキング制限が定義されている場合、Virtual DataPort では、そのいずれか 1 つの式を使用し、条件 (ある場合) が AND
で連結されます。ただし、予期しない結果や曖昧さを避けるため、異なるマスキング定義を使用することはお勧めしません。
グローバルセキュリティポリシーでは、ビューやフィールドをタグで参照することを思い出してください。そのため、 カスタム マスキング式を定義する場合には、式を作成するタグを使用できます。Virtual DataPort では、式で使用されるタグによってタグ付けされたビューのフィールドを使用します。ただし、使用されるタグでタグ付けされたフィールドがない場合は、実行エラーが生じます。
たとえば、次のビューで 従業員 情報を返すとします。1 つの列がソーシャルセキュリティ番号になります。

ソーシャルセキュリティ番号付きのビュー¶
この列に最初の 3 つの数字だけが表示されるようにするための専用のマスキングを使用したいと思っています。それには、カスタムマスキング式を独自の形式で定義する必要があります。
まず、「ssn」というタグを作成し、このタグを social_security_number
フィールドに割り当てます。

ソーシャルセキュリティ番号が定義されたビューの定義¶
次に、「ssn」タグの付いた列をマスクするグローバルセキュリティポリシーを作成します。このデータは text 型なので、そのデータ型に合わせてマスキングを編集する必要があります。[Custom] を選択し、独自の式を使用する必要があります。
定義にはタグ「ssn」を使用する必要があります。実行時に、Virtual DataPort は、実行中のクエリで有効な実行可能式を作成するために、そのタグの付いたアクセス済みのビューのフィールドを使用します。

カスタムマスキング式の定義¶

カスタムマスキング式の定義¶
これで、グローバルセキュリティポリシーをトリガーするビューにアクセスするクエリをユーザーが実行すると、「ssn」タグの付いたフィールドがカスタム式を使用してマスクされます。

ソーシャルセキュリティ番号がマスクされたビュー¶
ワイルドカードタグ名を使用したカスタムマスキング式¶
Virtual Data Port では、ワイルドカードタグ名を使用して カスタムマスキング式 を定義できます。この特殊タグの名前は any_tag
です。
このようにしてグローバルセキュリティポリシーを適用すると、この特殊タグの名前は、マスキングする列の名前に置き換えられます。
この機能がない場合、適用するカスタムの カスタム マスキング式 ごとに異なるグローバルセキュリティポリシーを定義する必要があります。
例:
基本ビューがある状態で、ハッシュ化された特定の列の値を何らかのロールを持つユーザーが確認できるように、カスタムマスキング式を適用するとします。
ビューから取得した元のデータは次のとおりです。

グローバルセキュリティポリシー : ワイルドカードタグ名 - 元のビューデータ¶
まず、これまでと同じ方法でグローバルセキュリティポリシーを作成します。
[constraints] では、適用するタグの数を指定できます。この例では 1 としています。
テキストフィールドにのみポリシーを適用するので [Text masking] ドロップダウンで [Custom] を選択し、[Edit mask] をクリックします。

グローバルセキュリティポリシー : ワイルドカードタグ名 - 新しいグローバルセキュリティポリシー¶
式エディター で、[Field expression] テキスト領域に値として cast(hash(any_tag)) AS TEXT)
を入力します。

グローバルセキュリティポリシー : ワイルドカードタグ名 - 式エディター¶
グローバルセキュリティポリシーによるフィルタを通過した処理済みのフィールドごとに、 any_tag の値をセルの実際の値に置き換えるので、最終的な値は cast(hash(<cell_value>)) AS TEXT)
になります。

グローバルセキュリティポリシー: ワイルドカードタグ名 - 最終的なビューデータ¶
ワイルドカードを使用しない場合は、列ごとに 1 つのタグを作成して列に割り当て、そのタグを列の名前に置き換える方法で、それぞれに新しいグローバルセキュリティポリシーを作成する必要があります。そのための処理は以下のとおりです。
cast(hash(tag_plate)) AS TEXT)
cast(hash(tag_specific_field1)) AS TEXT)
cast(hash(tag_specific_field2)) AS TEXT)
権限¶
グローバルセキュリティポリシーの作成、編集、削除を行うことができるのは、管理者ユーザー、ローカル管理者、または manage_policies ロールを持つユーザーです。
ローカル管理者は、自身が管理するデータベースに限定されたグローバルセキュリティポリシーのみを管理および表示することができます。