Amazon Redshift は、パッチ 198 以降、新しい Python UDF の作成をサポートしなくなります。既存の Python UDF は、2026 年 6 月 30 日まで引き続き機能します。詳細については、[ブログ記事](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)を参照してください。
# データベースセキュリティ
データベースセキュリティは、各データベースオブジェクトに対するアクセス権限を付与するユーザーを制御することによって管理します。ユーザーにはロールまたはグループを割り当てることができ、ユーザー、ロール、またはグループに付与するアクセス許可によって、アクセスできるデータベースオブジェクトが決まります。
**Topics**
+ [Amazon Redshift セキュリティの概要](c_security-overview.md)
+ [データベースユーザーのデフォルトのアクセス許可](r_Privileges.md)
+ [superuser](r_superusers.md)
+ [ユーザー](r_Users.md)
+ [グループ](r_Groups.md)
+ [スキーマ](r_Schemas_and_tables.md)
+ [ロールベースのアクセスコントロール (RBAC)](t_Roles.md)
+ [行レベルのセキュリティ](t_rls.md)
+ [メタデータセキュリティ](t_metadata_security.md)
+ [動的データマスキング](t_ddm.md)
+ [スコープ設定アクセス許可](t_scoped-permissions.md)
データベースオブジェクトに対するアクセス権限は、ユーザーまたはロールに付与したアクセス許可に応じて異なります。データベースセキュリティの機能方法について、以下のガイドラインにまとめてあります。
+ デフォルトでは、オブジェクト所有者のみにアクセス許可が付与されます。
+ Amazon Redshift データベースユーザーは、データベースに接続できる名前付きユーザーです。ユーザーへのアクセス許可の付与には、明示的方法 (アカウントに直接割り当てる) と、暗黙的方法 (アクセス許可を付与するグループのメンバーにする) の 2 つがあります。
+ グループとはユーザーが集合したものであり、これにアクセス許可を一括して割り当てることで、セキュリティの管理を合理的に行えます。
+ スキーマは、データベーステーブルおよびその他のデータベースオブジェクトの集合です。スキーマは、ファイルシステムディレクトリに似ていますが、ネストできない点が異なります。ユーザーには、単一のスキーマまたは複数のスキーマに対するアクセス権限を付与できます。
さらに、Amazon Redshift は以下の機能を採用しているため、どのユーザーがどのデータベースオブジェクトにアクセスできるかをより細かく制御できます。
+ ロールベースのアクセスコントロール (RBAC) により、アクセス許可をロールに割り当て、ロールをユーザーに適用できるため、大規模なユーザーグループのアクセス許可を制御できます。グループとは異なり、ロールは他のロールからアクセス許可を継承できます。
行レベルセキュリティ (RLS) により、選択した行へのアクセスを制限するポリシーを定義して、それらのポリシーをユーザーまたはグループに適用できます。
動的データマスキング (DDM) は、クエリランタイムにデータを変換することでデータをさらに保護するため、ユーザーは機密情報を公開することなくデータにアクセスできます。
セキュリティ実装の例については、「[ユーザーおよびグループのアクセス権限の管理例](t_user_group_examples.md)」を参照してください。
データ保護の詳細については、「*Amazon Redshift 管理ガイド*」の「[Amazon Redshift のセキュリティ](https://docs.aws.amazon.com/redshift/latest/mgmt/iam-redshift-user-mgmt.html)」を参照してください。
# Amazon Redshift セキュリティの概要
Amazon Redshift データベースのセキュリティは、他の種類の セキュリティとは異なります。Amazon Redshift には、このセクションで説明しているデータベースセキュリティに加えて、以下のセキュリティ管理といった特徴が用意されています。
+ **サインイン認証情報** – Amazon Redshift の AWS マネジメントコンソールへのアクセスは、AWS アカウントのアクセス許可によって管理されます。詳細については、「[サインイン認証情報](https://docs.aws.amazon.com/general/latest/gr/aws-security-credentials.html)」を参照してください。
+ **アクセス管理** — 特定の Amazon Redshift リソースへのアクセスを管理するには、AWS Identity and Access Management (IAM) アカウントを定義します。詳細については、[Amazon Redshift のリソースに対するアクセスの制御](https://docs.aws.amazon.com/redshift/latest/mgmt/iam-redshift-user-mgmt.html)を参照してください。
+ **クラスターセキュリティグループ** – 他のユーザーに Amazon Redshift クラスターへのインバウンドアクセス権を付与するには、クラスターセキュリティグループを定義し、それをクラスターに関連付けます。詳細については、「[Amazon Redshift クラスターセキュリティグループ](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-security-groups.html)」を参照してください。
+ **VPC** – 仮想ネットワーク環境を使用してクラスターへのアクセスを保護するには、Amazon Virtual Private Cloud (VPC) でクラスターを起動します。詳細については、「[Virtual Private Cloud (VPC) でクラスターを管理する](https://docs.aws.amazon.com/redshift/latest/mgmt/managing-clusters-vpc.html)」を参照してください。
+ **クラスターの暗号化** – ユーザーが作成したすべてのテーブル内のデータを暗号化するには、クラスターの起動時に、そのクラスターの暗号化を有効にします。詳細については、「[Amazon Redshift クラスター](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html)」を参照してください。
+ **SSL 接続** – SQL クライアントとクラスター間の接続を暗号化するには、Secure Sockets Layer (SSL) 暗号化を使用します。詳細については、「[SSL を使用してクラスターに接続する](https://docs.aws.amazon.com/redshift/latest/mgmt/connecting-ssl-support.html)」を参照してください。
+ **ロードデータ暗号化** – テーブルロードデータファイルを Amazon S3 にアップロードするときに暗号化するには、サーバー側の暗号化またはクライアント側の暗号化を使用できます。サーバー側で暗号化されたデータからロードする場合、Amazon S3 が透過的に復号を処理します。クライアント側で暗号化されたデータからロードする場合、Amazon Redshift の COPY コマンドによって、テーブルをロードするときにデータが復号されます。詳細については、「[Amazon S3 への暗号化されたデータのアップロード](t_uploading-encrypted-data.md)」を参照してください。
+ **転送中のデータ** – AWS クラウド内で転送されるデータを保護するために、Amazon Redshift では、COPY、UNLOAD、バックアップ、および復元オペレーションを実行する際、ハードウェアでアクセラレートされた SSL を使用して、Amazon S3 または Amazon DynamoDB と通信します。
+ **列レベルのアクセスコントロール** – Amazon Redshift でデータに対して列レベルのアクセスを制御するには、ビューベースのアクセスコントロールを実装したり、別のシステムを使用したりせずに、列レベルの許可ステートメントや revoke ステートメントを使用します。
+ **行レベルのセキュリティ制御** — Amazon Redshift のデータに対して行レベルのセキュリティ制御を行うには、ポリシーで定義された行へのアクセスを制限するポリシーを作成してロールまたはユーザーにアタッチします。
# データベースユーザーのデフォルトのアクセス許可
データベースオブジェクトを作成したユーザーは、その所有者になります。デフォルトでは、スーパーユーザーまたはオブジェクトの所有者のみが、そのオブジェクトに対するクエリや変更を実行でき、またアクセス許可を付与できます。ユーザーがオブジェクトを使用するには、そのユーザー、またはそのユーザーが属するグループに、必要なアクセス許可を付与する必要があります。データベースのスーパーユーザーは、そのデータベースの所有者と同じアクセス許可を持ちます。
Amazon Redshift でサポートされるアクセス許可は、SELECT、INSERT、UPDATE、DELETE、REFERENCES、CREATE、TEMPORARY、および USAGE です。異なるタイプのオブジェクトには、それぞれ異なるアクセス許可が関連付けられます。Amazon Redshift でサポートされるデータベースオブジェクトのアクセス許可については、[GRANT](r_GRANT.md) コマンドを参照してください。
オブジェクトを変更または破棄する許可を持つのは、所有者のみです。
デフォルトでは、データベースの PUBLIC スキーマに対して、すべてのユーザーが CREATE と USAGE のアクセス許可を持ちます。データベースの PUBLIC スキーマ内に、オブジェクトをユーザーが作成することを禁止するには、REVOKE コマンドを使用して、そのアクセス許可を削除します。
以前付与したアクセス許可を取り消す場合は、[REVOKE](r_REVOKE.md) コマンドを使用します。オブジェクト所有者が持つ (DROP、GRANT、REVOKE などの) アクセス許可は暗黙的であり、付与したり取り消したりすることはできません。オブジェクトの所有者は、自身が持つ通常の (例えば、テーブルを所有者自身と他のユーザーに対して読み取り専用にするなどの) アクセス許可を取り消すことができます。スーパーユーザーは、GRANT コマンドであるか REVOKE コマンドであるかを問わず、すべてのアクセス許可を保持します。
# スーパーユーザー
すべてのデータベースについて、データベースのスーパーユーザーは、そのデータベースの所有者と同様のアクセス許可を保持します。
クラスターの起動時に作成する*管理者*ユーザーと呼ばれるユーザーは、スーパーユーザーです。
スーパーユーザーを作成できるのは、スーパーユーザーのみです。
Amazon Redshift のシステムテーブルおよびシステムビューは、スーパーユーザーのみが表示できるか、すべてのユーザーが表示できます。「スーパーユーザーが表示できるビュー」として指定されているシステムテーブルおよびシステムビューを照会できるのは、スーパーユーザーのみです。詳細については、「[SYS モニタリングビュー](serverless_views-monitoring.md)」を参照してください。
スーパーユーザーは、すべてのカタログテーブルを表示できます。詳細については、「[システムカタログテーブル](c_intro_catalog_views.md)」を参照してください。
データベーススーパーユーザーは、すべての許可チェックをバイパスします。スーパーユーザーは、GRANT コマンドであるか REVOKE コマンドであるかを問わず、すべてのアクセス許可を保持します。スーパーユーザーロールを使用するときには、注意が必要です。ほとんどの作業をスーパーユーザー以外のロールで行うことをお勧めします。より制限の厳しい権限を持つ管理者ロールを作成できます。ロールの作成の詳細については、「[ロールベースのアクセスコントロール (RBAC)](t_Roles.md)」を参照してください。
新しいデータベーススーパーユーザーを作成するには、スーパーユーザーとしてデータベースにログオンし、CREATEUSER のアクセス許可を使用して、CREATE USER コマンドまたは ALTER USER コマンドを実行します。
```
CREATE USER adminuser CREATEUSER PASSWORD '1234Admin';
ALTER USER adminuser CREATEUSER;
```
スーパーユーザーを作成、変更、または削除するには、ユーザーの管理と同じコマンドを使用します。詳細については、「[ユーザーの作成、変更、および削除](r_Users-creatingaltering-and-deleting-users.md)」を参照してください。
# ユーザー
データベースユーザーの作成および管理は、Amazon Redshift SQL コマンドの CREATE USER および ALTER USER により行えます。また、Amazon Redshift での JDBC または ODBC 用カスタムドライバーを使用すると、SQL クライアントを設定できます。これらのドライバーは、データベースのログオンプロセスの一部として、データベースユーザーや仮パスワードを作成するプロセスを実行します。
ドライバーは AWS Identity and Access Management (IAM) 認証に基づいてデータベースユーザーを認証します。既に AWS の外部でユーザー ID を管理している場合、Security Assertion Markup Language (SAML) 2.0 に準拠した ID プロバイダー (IdP) を使用して、Amazon Redshift リソースへのアクセスを管理できます。IAM ロールを使用して IdP と AWS の設定を行い、フェデレーションユーザーが一時データベース認証情報を生成して、Amazon Redshift データベースにログオンすることを許可します。詳細については、「[IAM 認証を使用したデータベースユーザー認証情報の生成](https://docs.aws.amazon.com/redshift/latest/mgmt/generating-user-credentials.html)」を参照してください。
Amazon Redshift ユーザーを作成および削除できるのは、データベーススーパーユーザーのみです。Amazon Redshift にログオンしようとするユーザーに対しては、認証が行われます。ユーザーは、データベースやデータベースオブジェクト (例えばテーブルなど) を所有できます。また、これらのオブジェクトに対するアクセス許可を、他のユーザーやグループおよびスキーマに付与することで、各オブジェクトにアクセスできるユーザーを管理します。CREATE DATABASE 権限を持つユーザーは、データベースを作成し、それらのデータベースに許可を付与できます。スーパーユーザーは、すべてのデータベースに対し、データベース所有者と同じアクセス許可を保持します。
# ユーザーの作成、変更、および削除
データベースユーザーは、データウェアハウスクラスター全体にわたって (データベースごとではなく) グローバルです。
+ ユーザーを作成するには、[CREATE USER](r_CREATE_USER.md) コマンドを使用します。
+ スーパーユーザーを作成するには、CREATEUSER オプションを指定しながら [CREATE USER](r_CREATE_USER.md) コマンドを使用します。
+ 既存のユーザーを削除するには、[DROP USER](r_DROP_USER.md) コマンドを使用します。
+ ユーザーを変更する (例: パスワードを変更する) には、[ALTER USER](r_ALTER_USER.md) コマンドを使用します。
+ ユーザーのリストを表示するには、PG\$1USER カタログテーブルに対しクエリを実行します。
```
select * from pg_user;
usename | usesysid | usecreatedb | usesuper | usecatupd | passwd | valuntil | useconfig
------------+----------+-------------+----------+-----------+----------+----------+-----------
rdsdb | 1 | t | t | t | ******** | |
masteruser | 100 | t | t | f | ******** | |
dwuser | 101 | f | f | f | ******** | |
simpleuser | 102 | f | f | f | ******** | |
poweruser | 103 | f | t | f | ******** | |
dbuser | 104 | t | f | f | ******** | |
(6 rows)
```
# グループ
グループとは、そこで関連付けられている任意のアクセス許可が付与されているユーザーの集合を言います。グループを使用してアクセス許可を割り当てることができます。例えば、営業、管理、サポートなど、さまざまなグループを作成して、各グループ内のユーザーに、その業務に必要なデータへの適切なアクセス権限を付与できます。アクセス許可はグループレベルで付与または取り消すことができ、その変更は (スーパーユーザーを除く) グループのすべてのメンバーに適用されます。
すべてのユーザーグループを表示するには、次のように PG\$1GROUP システムカタログテーブルを照会します。
```
select * from pg_group;
```
例えば、すべてのデータベースユーザーをグループ別に一覧表示するには、次の SQL を実行します。
```
SELECT u.usesysid
,g.groname
,u.usename
FROM pg_user u
LEFT JOIN pg_group g ON u.usesysid = ANY (g.grolist)
```
# グループの作成、変更、および削除
グループの作成、変更、削除ができるのは、スーパーユーザーだけです。
以下のアクションを実行できます。
+ グループを作成するには、[CREATE GROUP](r_CREATE_GROUP.md) コマンドを使用します。
+ ユーザーを既存のグループに追加するには、または既存のグループから削除するには、[ALTER GROUP](r_ALTER_GROUP.md) コマンドを使用します。
+ グループを削除するには、[DROP GROUP](r_DROP_GROUP.md) コマンドを使用します。このコマンドはグループのみを削除し、そのメンバーユーザーは削除しません。
# ユーザーおよびグループのアクセス権限の管理例
この例では、ユーザーグループとユーザーを作成した上で、ウェブアプリケーションクライアントに接続する Amazon Redshift データベースへのさまざまなアクセス許可を付与しています。この例では、3 つのユーザーグループが想定されています。ウェブアプリケーションの一般ユーザー、ウェブアプリケーションのパワーユーザー、およびウェブ開発者の 3 グループです。
グループからユーザーを削除する方法については、「[ALTER GROUP](r_ALTER_GROUP.md)」を参照してください。
1. ユーザーを割り当てるグループを作成します。以下の一連のコマンドで、3 つのユーザーグループを作成します。
```
create group webappusers;
create group webpowerusers;
create group webdevusers;
```
1. 複数のデータベースユーザーを作成し、それぞれに異なるアクセス許可を付与した上で、グループに追加します。
1. つのユーザーを作成し、それらを WEBAPPUSERS グループに追加します。
```
create user webappuser1 password 'webAppuser1pass'
in group webappusers;
create user webappuser2 password 'webAppuser2pass'
in group webappusers;
```
1. ウェブデベロッパーユーザーを作成して WEBDEVUSERS グループに追加します。
```
create user webdevuser1 password 'webDevuser2pass'
in group webdevusers;
```
1. スーパーユーザーを作成します。このユーザーには、他のユーザーを作成できる管理権限が与えられます。
```
create user webappadmin password 'webAppadminpass1'
createuser;
```
1. スキーマを作成し、ウェブアプリケーションで使用されるデータベーステーブルに関連付けてから、そのスキーマに対するアクセス権限をさまざまなユーザーグループに付与します。
1. WEBAPP スキーマを作成します。
```
create schema webapp;
```
1. WEBAPPUSERS グループに USAGE のアクセス許可を付与します。
```
grant usage on schema webapp to group webappusers;
```
1. WEBPOWERUSERS グループに USAGE のアクセス許可を付与します。
```
grant usage on schema webapp to group webpowerusers;
```
1. WEBDEVUSERS グループに ALL のアクセス許可を付与します。
```
grant all on schema webapp to group webdevusers;
```
これで、基本的なユーザーおよびグループがセットアップされました。ユーザーおよびグループを変更できるようになりました。
1. 例えば、次のコマンドは、WEBAPPUSER1 の search\$1path パラメータを変更します。
```
alter user webappuser1 set search_path to webapp, public;
```
SEARCH\$1PATH は、スキーマが指定されていない簡潔な名前でデータベースオブジェクト (テーブルや関数など) が参照されたときにスキーマを検索する順序を指定します。
1. また、グループを作成した後で、ユーザーをグループに追加することもできます。例えば、次のように WEBAPPUSER2 を WEBPOWERUSERS グループに追加します。
```
alter group webpowerusers add user webappuser2;
```
# スキーマ
データベースには、1 つ以上の名前付きスキーマが含まれています。データベース内の各スキーマには、テーブルや、その他の種類の名前付きオブジェクトが含まれています。デフォルトでは、データベースに、PUBLIC という名前の 1 つのスキーマが含まれています。スキーマを使用すると、共通の名前でデータベースオブジェクトをグループ化できます。スキーマは、ファイルシステムディレクトリに似ていますが、ネストできない点が異なります。
同じデータベース内の異なるスキーマ内で同一のデータベースオブジェクト名を使用でき、競合は生じません。例えば、MY\$1SCHEMA と YOUR\$1SCHEMA の両方に、MYTABLE という名前のテーブルを含めることができます。必要なアクセス許可が付与されたユーザーであれば、データベース内の複数のスキーマにわたりオブジェクトにアクセスできます。
デフォルトでは、オブジェクトは、データベースの検索パスに含まれる最初のスキーマ内に作成されます。詳細については、このセクションで後述する「[検索パス](#c_Search_path)」を参照してください。
スキーマは、組織において、またマルチユーザー環境での並行処理問題において以下のように有用です。
+ 多数のデベロッパーが相互に妨害せずに同じデータベース内で作業できる。
+ データベースオブジェクトの論理グループを編成して、より管理しやすくする。
+ アプリケーションで使用されるオブジェクトを専用のスキーマに入れる機能をアプリケーションに追加する。これにより、それらのオブジェクトの名前と、別のアプリケーションで使用されるオブジェクトの名前とが競合しなくなる。
## 検索パス
検索パスは search\$1path パラメータで定義します。このパラメータに、スキーマ名をカンマで区切ってリストします。検索パスは、オブジェクト (テーブルや関数など) がスキーマ修飾子なしの簡潔な名前で参照されたときにスキーマを検索する順序を指定します。
ターゲットスキーマを指定せずにオブジェクトを作成した場合は、検索パスにリストされている最初のスキーマにオブジェクトが追加されます。同じ名前の複数のオブジェクトが異なるスキーマ内に存在する場合、スキーマが指定されていないオブジェクト名は、その名前のオブジェクトを含む検索パス内の最初のスキーマを参照します。
現行セッションのデフォルトスキーマを変更するには、[SET](r_SET.md) コマンドを使用します。
詳細については、「設定リファレンス」の「[search\$1path](r_search_path.md)」の説明を参照してください。
# スキーマの作成、変更、および削除
あらゆるユーザーがスキーマを作成でき、所有するスキーマを変更または削除できます。
以下のアクションを実行できます。
+ スキーマを作成するには、[CREATE SCHEMA](r_CREATE_SCHEMA.md) コマンドを使用します。
+ スキーマの所有者を変更するには、[ALTER SCHEMA](r_ALTER_SCHEMA.md) コマンドを使用します。
+ スキーマおよびそのオブジェクトを削除するには、[DROP SCHEMA](r_DROP_SCHEMA.md) コマンドを使用します。
+ スキーマ内にテーブルを作成するには、*schema\$1name.table\$1name* という形式でテーブルを作成します。
すべてのスキーマのリストを表示するには、PG\$1NAMESPACE システムカタログテーブルをクエリします。
```
select * from pg_namespace;
```
スキーマに属するテーブルのリストを表示するには、PG\$1TABLE\$1DEF システムカタログテーブルをクエリします。たとえば、次のクエリは PG\$1CATALOG スキーマのテーブルのリストを返します。
```
select distinct(tablename) from pg_table_def
where schemaname = 'pg_catalog';
```
# スキーマベースのアクセス許可。
スキーマベースのアクセス許可は、スキーマ所有者により以下のように決定されます。
+ デフォルトでは、データベースの PUBLIC スキーマに対して、すべてのユーザーが CREATE と USAGE のアクセス許可を持ちます。データベースの PUBLIC スキーマ内に、オブジェクトをユーザーが作成することを禁止するには、[REVOKE](r_REVOKE.md) コマンドを使用して、そのアクセス許可を削除します。
+ オブジェクトの所有者により USAGE のアクセス許可が付与されたユーザーでない限り、ユーザーは、自らが所有していないスキーマに含まれるオブジェクトにアクセスできません。
+ 別のユーザーが作成したスキーマに対する CREATE のアクセス許可が付与されたユーザーは、そのスキーマ内にオブジェクトを作成できます。
# ロールベースのアクセスコントロール (RBAC)
ロールベースのアクセスコントロール (RBAC) を使用して、Amazon Redshift でのデータベース許可を管理することで、Amazon Redshift 内のセキュリティに関する許可の管理を簡略化できます。ユーザーが実行できる操作を、広範な、または詳細なレベルの両方で制御することで、機密データへのアクセスを保護できます。また、通常はスーパーユーザーに制限されるタスクへのユーザーによるアクセスを制御することもできます。異なるロールに異なるアクセス許可を割り当て、それらを異なるユーザーに割り当てることで、ユーザーアクセスをより細かく制御できます。
ロールが割り当てられたユーザーは、そのロールが指定し承認したタスクのみ実行できます。例えば、CREATE TABLE および DROP TABLE 許可を持つロールが割り当てられたユーザーについては、これらのタスクの実行のみが承認されます。作業で必要とするデータに対する各ユーザーアクセスを制御するには、セキュリティに関するさまざまなレベルの許可を、それぞれのユーザーに付与します。
RBAC では、対象となるオブジェクトのタイプに関係なく、ロールの要件に基づいて、最小許可の原則をユーザーに適用します。アクセス許可の付与と取り消しはロールレベルで実行され、個々のデータベースオブジェクトにおいてアクセス許可を更新する必要はありません。
RBAC では、スーパーユーザーのアクセスが必要となるコマンドを実行するための、アクセス許可を持つロールを作成できます。これらの許可を含むロールで承認されているのであれば、ユーザーはこの種類のコマンドを実行できます。同様に、特定のコマンドへのアクセスを制限するロールを作成し、その中で承認されたスーパーユーザーまたはユーザーのいずれかに対して、ロールを割り当てることもできます。
Amazon Redshift RBAC の仕組みについては、以下の動画をご覧ください。
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/IhHQ7mZ-tp4)
# ロール階層
*ロール*とは、ユーザーまたは別のロールに割り当てることができるアクセス許可の集合です。ロールには、システムまたはデータベースへのアクセス許可を割り当てることができます。ユーザーは、割り当てられたロールのアクセス許可を継承します。
RBAC では、ネストされたロールをユーザーに付与できます。ロールは、ユーザーとロールの両方に付与することが可能です。ユーザーにロールを付与すると、このロールに含まれるすべてのアクセス許可が、そのユーザーに対し承認されます。ユーザーにロール r1 を付与するとすれば、r1 が持つ権限がそのユーザーでも承認されます。このユーザーには r1 からのアクセス許可が与えられると同時に、すでに保持していた既存の許可も維持されます。
あるロール (r1) を別のロール (r2) に付与する場合、r1 のすべてのアクセス許可が r2 においても承認されます。さらに、r2 を別のロール (r3) に付与すると、r3 には r1 と r2 の許可を組み合わせた許可が付与されます。このロール階層では、r1 からの許可が r2 に継承されています。Amazon Redshift は、アクセス許可とともに各ロールの認可を伝播します。r1 を r2 に付与し、r2 を r3 に付与すると、3 つのロールのすべてのアクセス許可が r3 において承認されます。したがって、ユーザーに r3 を付与することで、このユーザーには 3 つのロールからのすべてのアクセス許可が付与されます。
Amazon Redshift では、ロールの認可サイクルを作成することはできません。ロールの認可サイクルは、ネストされたロールがロール階層で前の段階にあるロールに割り当てられる場合に発生します。例えば、ここで r3 を r1 に割り当てる場合がこれに相当します。IAM ロールを作成し、ロールの割り当てを管理する方法の詳細については「[RBAC でのロールの管理](r_roles-managing.md)」を参照してください。
# ロールの割り当て
CREATE ROLE のアクセス許可を持つスーパーユーザーおよび通常のユーザーは、CREATE ROLE ステートメントを使用してロールを作成できます。スーパーユーザーとロールの管理者は、GRANT ROLE ステートメントを使用して、他のユーザーにロールを付与できます。これらのユーザー (管理者) は、REVOKE ROLE ステートメントを使用して他のユーザーが持つロールを取り消したり、DROP ROLE ステートメントを使用してロールを削除したりできます。ロール管理者には、ロール所有者と ADMIN OPTION のアクセス許可を持つロールを付与されたユーザーが含まれます。
ロールの付与と取り消しを行えるのは、スーパーユーザーまたはロールの管理者のみです。1 つまたは複数のロールやユーザーに対して、1 つ以上のロールを付与または取り消すことができます。GRANT ROLE ステートメントで WITH ADMIN OPTION オプションを使用して、付与されたすべてのロールの管理オプションを、その付与のすべての対象者に提供します。
Amazon Redshift は、複数のロールの付与や、複数のユーザーを付与の対象にすることを含め、ロール割り当てのさまざまな組み合わせをサポートしています。WITH ADMIN オプションは、ユーザーにのみ適用され、ロールには適用されません。同様に、付与の対象者からロールと管理としての承認を削除するには、WITH ADMIN OPTION オプションを指定しながら REVOKE ROLE ステートメントを実行します。ADMIN OPTION を指定した場合には、管理としての承認のみがロールから取り消されます。
次の例では、`sample_role2` ロールでの管理としての承認を `user2` から取り消しています。
```
REVOKE ADMIN OPTION FOR sample_role2 FROM user2;
```
IAM ロールを作成し、ロールの割り当てを管理する方法の詳細については「[RBAC でのロールの管理](r_roles-managing.md)」を参照してください。
# Amazon Redshift でのシステム定義のロール
Amazon Redshift には、特定のアクセス許可が定義されたシステム定義のロールがいくつか用意されています。システム固有のロールには `sys:` がプレフィックスされます。適切なアクセス権を持つユーザーのみが、システム定義のロールを変更したり、カスタムなシステム定義のロールを作成したりできます。カスタムなシステム定義のロールでは、`sys:` のプレフィックスを使用することはできません。
次の表に、ロールとそのアクセス許可を一覧でまとめています。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/r_roles-default.html)
## データ共有のためのシステム定義のロールとユーザー
Amazon Redshift は、データ共有とデータ共有コンシューマーに対応する内部使用を目的としたロールとユーザーを作成します。各内部ロール名とユーザー名には、予約された名前空間プレフィックス `ds:` が付いています。それには以下の形式があります。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/r_roles-default.html)
データ共有ロールは、データ共有ごとに作成されます。このロールは、データ共有に現在付与されているすべてのアクセス許可を保持しています。データ共有ユーザーは、データ共有コンシューマーごとに作成されます。このユーザーには、単一のデータ共有ロールへのアクセス許可が付与されます。複数のデータ共有に追加されたコンシューマーでは、データ共有ごとにデータ共有ユーザーが作成されます。
データ共有が適切に機能するには、このようなユーザーとロールが必要です。これらのユーザーとロールは変更または削除することはできません。また、顧客が実行するタスクにアクセスしたり、使用したりすることはできません。このような場合、無視しても問題ありません。データ共有の詳細については、「[Amazon Redshift でのクラスター間のデータの共有](https://docs.aws.amazon.com/redshift/latest/dg/datashare-overview.html)」を参照してください。
**注記**
`ds:` プレフィックスを使用してユーザー定義のロールまたはユーザーを作成することはできません。
# RBAC でのシステムへのアクセス許可
以下は、ロールに対して付与または取り消すことができるシステムへのアクセス許可の一覧です。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/r_roles-system-privileges.html)
# データベースオブジェクトへのアクセス許可
システムへのアクセス許可とは別に、Amazon Redshift には、データベースオブジェクトへのアクセス許可が含まれており、アクセスのオプションを定義できます。この定義には、テーブルとビューからのデータの読み取り、データの書き込み、テーブルの作成、テーブルの削除など各機能のオプションが含まれます。詳細については、「[GRANT](r_GRANT.md)」を参照してください。
RBAC を使用すると、システムへのアクセス許可による場合と同様に、データベースオブジェクトへのアクセス許可をロールに割り当てることができます。その後、このロールをユーザーに割り当て、そのユーザーでシステムへのアクセスを認可し、データベースへのアクセスを認可できます。
# RBAC での ALTER DEFAULT PRIVILEGES
指定したユーザーによって今後作成されるオブジェクトに対して、デフォルトで適用するアクセス許可のセットを定義するには、ALTER DEFAULT PRIVILEGES ステートメントを使用します。デフォルトでは、ユーザーは自分のデフォルトのアクセス許可のみ変更できます。RBAC では、ロールに対してデフォルトのアクセス許可を設定できます。詳細については、[ALTER DEFAULT PRIVILEGES](r_ALTER_DEFAULT_PRIVILEGES.md) コマンドを参照してください。
RBAC を使用すると、システムへのアクセス許可と同様に、データベースオブジェクトのアクセス許可をロールに割り当てることができます。その上で、ロールをユーザーに割り当てたり、システムおよび (あるいは) データベースに対するアクセスを許可したりできます。
# RBAC でのロールの使用に関する考慮事項
RBAC データを使用する際には、以下の点を考慮してください。
+ Amazon Redshift では、ロール認証のサイクルは使用できません。r1 を r2 に付与した後に、r2 を r1 に付与することはできません。
+ RBAC は、ネイティブの Amazon Redshift オブジェクトと Amazon Redshift Spectrum テーブルの両方で使用できます。
+ Amazon Redshift の管理者は、RBAC を有効にして使用開始するために、クラスターを最新のメンテナンスパッチにアップグレードします。
+ ロールを作成できるのは、スーパーユーザーと、システムへのアクセス許可 CREATE ROLE を持つユーザーのみです。
+ スーパーユーザーとロールの管理者のみが、ロールを変更または削除できます。
+ ロール名をユーザー名と同じにすることはできません。
+ ロール名に「:/\$1n」などの無効な文字を含めることはできません。
+ ロール名に、PUBLIC などの予約語を使用することはできません。
+ ロール名は、デフォルトロールの予約済みプレフィックス `sys:` で始めることはできません。
+ RESTRICT パラメータを持ち、さらに別のロールに付与されているロールは削除できません。デフォルトの設定は RESTRICT です。削除しようとしたロールが別のロールを継承している場合、Amazon Redshift はエラーをスローします。
+ ロールに対する管理者としてのアクセス許可を持たないユーザーは、ロールを付与または取り消すことはできません。
+ RBAC は、システムテーブルおよびビューでは完全にはサポートされていません。システムテーブルおよびビューの RBAC アクセス許可は、アップグレード、ダウングレード、またはサイズ変更の際に保持されません。[Amazon Redshift でのシステム定義のロールデータ共有のためのシステム定義のロールとユーザー](r_roles-default.md) を使用して、システムテーブルおよびビューのアクセス許可を管理することをお勧めします。システムテーブルの詳細については、「[システムテーブルとビューのリファレンス](cm_chap_system-tables.md)」を参照してください。
# RBAC でのロールの管理
以下のコマンドを使用して、以下の操作を実行します。
+ ロールを作成するには、[CREATE ROLE](r_CREATE_ROLE.md) コマンドを使用します。
+ ロールの名前を変更したり、ロールの所有者を変更するには、[ALTER ROLE](r_ALTER_ROLE.md)コマンドを使用します。
+ ロールを削除するには、[DROP ROLE](r_DROP_ROLE.md) コマンドを使用します。
+ ユーザーにロールを付与するには、[GRANT](r_GRANT.md) コマンドを使用します。
+ ユーザーからロールを取り消すには、[REVOKE](r_REVOKE.md) コマンドを使用します。
+ ロールにシステムへのアクセス許可を付与するには、[GRANT](r_GRANT.md) コマンドを使用します。
+ ロールからシステムへのアクセス許可を取り消すには、[REVOKE](r_REVOKE.md) コマンドを使用します。
クラスターまたはワークグループ内のロールのリストを表示するには、「[SVV\$1ROLES](r_SVV_ROLES.md)」を参照してください。
# チュートリアル: RBAC でのロールの作成とクエリ
RBAC では、スーパーユーザーのアクセスが必要となるコマンドを実行するための、アクセス許可を持つロールを作成できます。これらの許可を含むロールで承認されているのであれば、ユーザーはこの種類のコマンドを実行できます。
このチュートリアルでは、作成するデータベースでアクセス許可を管理するのにロールベースのアクセスコントロール (RBAC) を使用できます。次に、データベースに接続し、2 つの異なるロールからデータベースにクエリを実行して RBAC の機能をテストします。
データベースをクエリするために作成して使用する 2 つのロールは `sales_ro` と `sales_rw` です。`sales_ro` ロールを作成し、`sales_ro` ロールを持つユーザーとしてデータをクエリします。`sales_ro` ユーザーは SELECT コマンドのみを使用でき、UPDATE コマンドは使用できません。そのため、`sales_rw` ロールを作成し、`sales_rw` ロールを持つユーザーとしてデータをクエリします。`sales_rw` ユーザーは SELECT コマンドと UPDATE コマンドは使用できます。
また、特定のコマンドへのアクセスを制限するロールを作成し、スーパーユーザーまたはユーザーのいずれかに対して、ロールを割り当てることもできます。
**タスク**
+ [前提条件](#tutorial-rbac-prereqs)
+ [ステップ 1: 管理者ユーザーを作成する](#tutorial-rbac-step1)
+ [ステップ 2: スキーマをセットアップする](#tutorial-rbac-step2)
+ [ステップ 3: 読み取り専用ユーザーを作成する](#tutorial-rbac-step3)
+ [ステップ 4: 読み取り専用ユーザーとしてデータをクエリする](#tutorial-rbac-step4)
+ [ステップ 5: 読み取り/書き込みユーザーを作成する](#tutorial-rbac-step5)
+ [ステップ 6: 継承された読み取り専用ロールのあるユーザーとしてデータをクエリする](#tutorial-rbac-step6)
+ [ステップ 7: 読み取り/書き込みロールに更新および挿入アクセス許可を付与する](#tutorial-rbac-step7)
+ [ステップ 8: 読み取り/書き込みユーザーとしてデータをクエリする](#tutorial-rbac-step8)
+ [ステップ 9: 管理者ユーザーとしてデータベース内のテーブルを分析してバキュームする](#tutorial-rbac-step9)
+ [ステップ 10: 読み取り/書き込みユーザーとしてテーブルを切り捨てる](#tutorial-rbac-step10)
+ [RBAC のシステム関数 (オプション)](#tutorial-rbac-system-functions)
+ [RBAC のシステムビュー (オプション)](#tutorial-rbac-system-views)
+ [RBAC で行レベルセキュリティを使用する (オプション)](#tutorial-rbac-rls)
## 前提条件
+ TICKIT サンプルデータベースがロードされた Amazon Redshift クラスターまたはサーバーレスワークグループを作成します。サーバーレスワークグループを作成するには、「[Redshift Serverless データウェアハウスの使用を開始](https://docs.aws.amazon.com/redshift/latest/gsg/new-user-serverless.html)」を参照してください。クラスターを作成するには、「[Amazon Redshift クラスターのサンプルを作成する](https://docs.aws.amazon.com/redshift/latest/gsg/rs-gsg-launch-sample-cluster.html)」を参照してください。TICKIT サンプルデータの詳細については、「[サンプルデータベース](c_sampledb.md)」を参照してください。
+ スーパーユーザーまたはロール管理者のアクセス許可を持つユーザーへのアクセスがあります。ロールの付与または取り消しを行えるのは、スーパーユーザーまたはロールの管理者のみです。RBAC に必要なアクセス許可の詳細については、「[RBAC でのシステムへのアクセス許可](r_roles-system-privileges.md)」を参照してください。
+ 「[RBAC でのロールの使用に関する考慮事項](r_role-usage-notes.md)」を確認します。
## ステップ 1: 管理者ユーザーを作成する
このチュートリアル用にセットアップするには、データベース管理者ロールを作成し、このステップでデータベース管理者ユーザーに割り当てます。データベース管理者はスーパーユーザーまたはロール管理者として作成する必要があります。
Amazon Redshift [クエリエディタ v2](https://docs.aws.amazon.com/redshift/latest/mgmt/query-editor-v2-using.html) のすべてのクエリを実行します。
1. 管理者ロール db\$1admin を作成するには、次の例を使用します。
```
CREATE ROLE db_admin;
```
1. 次の例を使用して、dbadmin という名前のデータベースユーザーを作成します。
```
CREATE USER dbadmin PASSWORD 'Test12345';
```
1. sys:dba という名前のシステム定義ロールを db\$1admin ロールに付与するには、次の例を使用します。sys:dba ロールが付与されると、dbadmin ユーザーはスキーマとテーブルを作成できます。詳細については、「[Amazon Redshift でのシステム定義のロールデータ共有のためのシステム定義のロールとユーザー](r_roles-default.md)」を参照してください。
## ステップ 2: スキーマをセットアップする
このステップでは、データベース管理者としてデータベースに接続します。次に、2 つのスキーマを作成し、それらにデータを追加します。
1. クエリエディタ v2 を使用して dbadmin ユーザーとして dev データベースに接続します。データベースへの接続の詳細については、「[クエリエディタ v2 の操作](https://docs.aws.amazon.com/redshift/latest/mgmt/query-editor-v2-using.html)」を参照してください。
1. セールスおよびマーケティングのデータベーススキーマを作成するには、次の例を使用します。
```
CREATE SCHEMA sales;
CREATE SCHEMA marketing;
```
1. セールススキーマのテーブルに値を作成して挿入するには、次の例を使用します。
```
CREATE TABLE sales.cat(
catid smallint,
catgroup varchar(10),
catname varchar(10),
catdesc varchar(50)
);
INSERT INTO sales.cat(SELECT * FROM category);
CREATE TABLE sales.dates(
dateid smallint,
caldate date,
day char(3),
week smallint,
month char(5),
qtr char(5),
year smallint,
holiday boolean
);
INSERT INTO sales.dates(SELECT * FROM date);
CREATE TABLE sales.events(
eventid integer,
venueid smallint,
catid smallint,
dateid smallint,
eventname varchar(200),
starttime timestamp
);
INSERT INTO sales.events(SELECT * FROM event);
CREATE TABLE sales.sale(
salesid integer,
listid integer,
sellerid integer,
buyerid integer,
eventid integer,
dateid smallint,
qtysold smallint,
pricepaid decimal(8,2),
commission decimal(8,2),
saletime timestamp
);
INSERT INTO sales.sale(SELECT * FROM sales);
```
1. マーケティングスキーマのテーブルに値を作成して挿入するには、次の例を使用します。
```
CREATE TABLE marketing.cat(
catid smallint,
catgroup varchar(10),
catname varchar(10),
catdesc varchar(50)
);
INSERT INTO marketing.cat(SELECT * FROM category);
CREATE TABLE marketing.dates(
dateid smallint,
caldate date,
day char(3),
week smallint,
month char(5),
qtr char(5),
year smallint,
holiday boolean
);
INSERT INTO marketing.dates(SELECT * FROM date);
CREATE TABLE marketing.events(
eventid integer,
venueid smallint,
catid smallint,
dateid smallint,
eventname varchar(200),
starttime timestamp
);
INSERT INTO marketing.events(SELECT * FROM event);
CREATE TABLE marketing.sale(
marketingid integer,
listid integer,
sellerid integer,
buyerid integer,
eventid integer,
dateid smallint,
qtysold smallint,
pricepaid decimal(8,2),
commission decimal(8,2),
saletime timestamp
);
INSERT INTO marketing.sale(SELECT * FROM marketing);
```
## ステップ 3: 読み取り専用ユーザーを作成する
このステップでは、読み取り専用ロールとその読み取り専用ロールのセールスアナリストユーザーを作成します。セールスアナリストがコミッションが最も高かったイベントを検索するという割り当てられたタスクを実行するには、セールススキーマのテーブルへの読み取り専用アクセスのみが必要です。
1. dbadmin ユーザーとしてデータベースに接続します。
1. sales\$1ro ロールを作成するには、次の例を使用します。
```
CREATE ROLE sales_ro;
```
1. セールスアナリストユーザーを作成するには、次の例を使用します。
```
CREATE USER salesanalyst PASSWORD 'Test12345';
```
1. sales\$1ro ロールに、セールススキーマのオブジェクトの使用と選択のアクセス許可を付与するには、次の例を使用します。
```
GRANT USAGE ON SCHEMA sales TO ROLE sales_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA sales TO ROLE sales_ro;
```
1. セールスアナリストユーザーに sales\$1ro ロールを付与するには、次の例を使用します。
```
GRANT ROLE sales_ro TO salesanalyst;
```
## ステップ 4: 読み取り専用ユーザーとしてデータをクエリする
このステップでは、セールスアナリストユーザーがセールススキーマからデータをクエリします。次に、セールスアナリストユーザーはテーブルの更新とマーケティングスキーマのテーブルの読み取りを試みます。
1. セールスアナリストユーザーとしてデータベースに接続します。
1. 最もコミッションが高い 10 件のセールスを検索するには、次の例を使用します。
```
SET SEARCH_PATH TO sales;
SELECT DISTINCT events.dateid, sale.commission, cat.catname
FROM sale, events, dates, cat
WHERE events.dateid=dates.dateid AND events.dateid=sale.dateid AND events.catid = cat.catid
ORDER BY 2 DESC LIMIT 10;
+--------+------------+----------+
| dateid | commission | catname |
+--------+------------+----------+
| 1880 | 1893.6 | Pop |
| 1880 | 1893.6 | Opera |
| 1880 | 1893.6 | Plays |
| 1880 | 1893.6 | Musicals |
| 1861 | 1500 | Plays |
| 2003 | 1500 | Pop |
| 1861 | 1500 | Opera |
| 2003 | 1500 | Plays |
| 1861 | 1500 | Musicals |
| 1861 | 1500 | Pop |
+--------+------------+----------+
```
1. セールススキーマでイベントテーブルから 10 件のイベントを選択するには、次の例を使用します。
```
SELECT * FROM sales.events LIMIT 10;
+---------+---------+-------+--------+--------------------+---------------------+
| eventid | venueid | catid | dateid | eventname | starttime |
+---------+---------+-------+--------+--------------------+---------------------+
| 4836 | 73 | 9 | 1871 | Soulfest | 2008-02-14 19:30:00 |
| 5739 | 41 | 9 | 1871 | Fab Faux | 2008-02-14 19:30:00 |
| 627 | 229 | 6 | 1872 | High Society | 2008-02-15 14:00:00 |
| 2563 | 246 | 7 | 1872 | Hamlet | 2008-02-15 20:00:00 |
| 7703 | 78 | 9 | 1872 | Feist | 2008-02-15 14:00:00 |
| 7903 | 90 | 9 | 1872 | Little Big Town | 2008-02-15 19:30:00 |
| 7925 | 101 | 9 | 1872 | Spoon | 2008-02-15 19:00:00 |
| 8113 | 17 | 9 | 1872 | Santana | 2008-02-15 15:00:00 |
| 463 | 303 | 8 | 1873 | Tristan und Isolde | 2008-02-16 19:00:00 |
| 613 | 236 | 6 | 1873 | Pal Joey | 2008-02-16 15:00:00 |
+---------+---------+-------+--------+--------------------+---------------------+
```
1. eventid 1 のイベント名を更新するには、次の例を実行します。この例では、セールスアナリストユーザーはセールススキーマのイベントテーブルに対する SELECT アクセス許可しか持っていないため、「アクセス許可が拒否されました」というエラーが発生します。イベントテーブルを更新するには、sales\$1ro ロールに UPDATE 権限を付与する必要があります。テーブルを更新するアクセス許可の付与の詳細については、「[GRANT](r_GRANT.md) の UPDATE パラメータ」を参照してください。UPDATE コマンドの詳細については、「[UPDATE](r_UPDATE.md)」を参照してください。
```
UPDATE sales.events
SET eventname = 'Comment event'
WHERE eventid = 1;
ERROR: permission denied for relation events
```
1. マーケティングスキーマでイベントテーブルからすべてを選択するには、次の例を使用します。この例では、セールスアナリストユーザーはセールススキーマのイベントテーブルに対する SELECT アクセス許可しか持っていないため、「アクセス許可が拒否されました」というエラーが発生します。マーケティングスキーマのイベントテーブルからデータを選択するには、マーケティングスキーマのイベントテーブルに対する SELECT アクセス許可を sales\$1ro ロールに付与する必要があります。
```
SELECT * FROM marketing.events;
ERROR: permission denied for schema marketing
```
## ステップ 5: 読み取り/書き込みユーザーを作成する
このステップでは、セールススキーマのデータ処理のための抽出、変換、ロード (ETL) パイプラインの構築を担当するセールスエンジニアに読み取り専用アクセスが与えられますが、タスクを実行するための読み取り/書き込みアクセスが後に付与されます。
1. dbadmin ユーザーとしてデータベースに接続します。
1. セールススキーマで sales\$1rw ロールを作成するには、次の例を使用します。
```
CREATE ROLE sales_rw;
```
1. セールスエンジニアユーザーを作成するには、次の例を使用します。
```
CREATE USER salesengineer PASSWORD 'Test12345';
```
1. sales\$1ro ロールを割り当てることで、sales\$1rw ロールにセールススキーマのオブジェクトの使用と選択のアクセス許可を付与するには、次の例を使用します。Amazon Redshift でロールがアクセス許可を継承する方法の詳細については、「[ロール階層](t_role_hierarchy.md)」を参照してください。
```
GRANT ROLE sales_ro TO ROLE sales_rw;
```
1. セールスエンジニアユーザーに sales\$1rw ロールを付与するには、次の例を使用します。
```
GRANT ROLE sales_rw TO salesengineer;
```
## ステップ 6: 継承された読み取り専用ロールのあるユーザーとしてデータをクエリする
このステップでは、セールスエンジニアユーザーが読み取りアクセス許可が付与される前にイベントテーブルを更新しようとします。
1. セールスエンジニアユーザーとしてデータベースに接続します。
1. セールスエンジニアユーザーは、セールススキーマのイベントテーブルからデータを正常に読み取ることができます。セールススキーマでイベントテーブルから eventid 1 のイベントを選択するには、次の例を使用します。
```
SELECT * FROM sales.events where eventid=1;
+---------+---------+-------+--------+-----------------+---------------------+
| eventid | venueid | catid | dateid | eventname | starttime |
+---------+---------+-------+--------+-----------------+---------------------+
| 1 | 305 | 8 | 1851 | Gotterdammerung | 2008-01-25 14:30:00 |
+---------+---------+-------+--------+-----------------+---------------------+
```
1. マーケティングスキーマでイベントテーブルからすべてを選択するには、次の例を使用します。セールスエンジニアユーザーにはマーケティングスキーマのテーブルに対するアクセス許可がないため、このクエリは結果としてアクセス許可拒否エラーになります。マーケティングスキーマのイベントテーブルからデータを選択するには、マーケティングスキーマのイベントテーブルに対する SELECT アクセス許可を sales\$1rw ロールに付与する必要があります。
```
SELECT * FROM marketing.events;
ERROR: permission denied for schema marketing
```
1. eventid 1 のイベント名を更新するには、次の例を実行します。この例では、セールスエンジニアユーザーにはセールススキーマのイベントテーブルに対する選択アクセス許可しかないため、アクセス許可拒否エラーが発生します。イベントテーブルを更新するには、sales\$1rw ロールに UPDATE のアクセス許可を付与する必要があります。
```
UPDATE sales.events
SET eventname = 'Comment event'
WHERE eventid = 1;
ERROR: permission denied for relation events
```
## ステップ 7: 読み取り/書き込みロールに更新および挿入アクセス許可を付与する
sales\$1rw ロールに対するアクセス許可を更新して挿入します。
1. dbadmin ユーザーとしてデータベースに接続します。
1. sales\$1rw ロールに UPDATE、INSERT、DELETE アクセス許可を付与するには、次の例を使用します。
```
GRANT UPDATE, INSERT, ON ALL TABLES IN SCHEMA sales TO role sales_rw;
```
## ステップ 8: 読み取り/書き込みユーザーとしてデータをクエリする
このステップでは、各自のロールに挿入アクセス許可と更新アクセス許可が付与された後に、セールスエンジニアがテーブルを正常に更新します。次に、セールスエンジニアはイベントテーブルの分析とバキュームを試みますが、失敗します。
1. セールスエンジニアユーザーとしてデータベースに接続します。
1. eventid 1 のイベント名を更新するには、次の例を実行します。
```
UPDATE sales.events
SET eventname = 'Comment event'
WHERE eventid = 1;
```
1. 前のクエリで行った変更を表示するには、次の例を使用してセールススキーマでイベントテーブルから eventid 1 のイベントを選択します。
```
SELECT * FROM sales.events WHERE eventid=1;
+---------+---------+-------+--------+---------------+---------------------+
| eventid | venueid | catid | dateid | eventname | starttime |
+---------+---------+-------+--------+---------------+---------------------+
| 1 | 305 | 8 | 1851 | Comment event | 2008-01-25 14:30:00 |
+---------+---------+-------+--------+---------------+---------------------+
```
1. セールススキーマで更新されたイベントテーブルを分析するには、次の例を使用します。この例では、セールスエンジニアユーザーに必要なアクセス許可がなく、セールススキーマのイベントテーブルの所有者でもないため、アクセス許可拒否エラーが発生します。イベントテーブルを分析するには、GRANT コマンドを使用して ANALYZE のアクセス許可を sales\$1rw ロールに付与する必要があります。ANALYZE コマンドの詳細については、「[ANALYZE](r_ANALYZE.md)」を参照してください。
```
ANALYZE sales.events;
ERROR: skipping "events" --- only table or database owner can analyze
```
1. 更新されたイベントテーブルをバキュームするには、次の例を使用します。この例では、セールスエンジニアユーザーに必要なアクセス許可がなく、セールススキーマのイベントテーブルの所有者でもないため、アクセス許可拒否エラーが発生します。イベントテーブルをバキュームするには、GRANT コマンドを使用して VACUUM のアクセス許可を sales\$1rw ロールに付与する必要があります。VACUUM コマンドの詳細については、「[VACUUM](r_VACUUM_command.md)」を参照してください。
```
VACUUM sales.events;
ERROR: skipping "events" --- only table or database owner can vacuum it
```
## ステップ 9: 管理者ユーザーとしてデータベース内のテーブルを分析してバキュームする
このステップでは、dbadmin ユーザーがすべてのテーブルを分析してバキュームします。ユーザーにはこのデータベースに対する管理者アクセス許可があるため、これらのコマンドを実行できます。
1. dbadmin ユーザーとしてデータベースに接続します。
1. セールススキーマでイベントテーブルを分析するには、次の例を使用します。
```
ANALYZE sales.events;
```
1. セールススキーマでイベントテーブルをバキュームするには、次の例を使用します。
```
VACUUM sales.events;
```
1. マーケティングスキーマでイベントテーブルを分析するには、次の例を使用します。
```
ANALYZE marketing.events;
```
1. マーケティングスキーマでイベントテーブルをバキュームするには、次の例を使用します。
```
VACUUM marketing.events;
```
## ステップ 10: 読み取り/書き込みユーザーとしてテーブルを切り捨てる
このステップでは、セールスエンジニアユーザーがセールススキーマのイベントテーブルを切り捨てようとしますが、dbadmin ユーザーから切り捨てアクセス許可が付与された場合にのみ成功します。
1. セールスエンジニアユーザーとしてデータベースに接続します。
1. セールススキーマのイベントテーブルからすべての行を削除するには、次の例を使用します。この例では、セールスエンジニアユーザーに必要なアクセス許可がなく、セールススキーマのイベントテーブルの所有者でもないため、エラーが発生します。イベントテーブルを切り捨てるには、GRANT コマンドを使用して TRUNCATE のアクセス許可を sales\$1rw ロールに付与する必要があります。TRUNCATE コマンドの詳細については、「[TRUNCATE](r_TRUNCATE.md)」を参照してください。
```
TRUNCATE sales.events;
ERROR: must be owner of relation events
```
1. dbadmin ユーザーとしてデータベースに接続します。
1. テーブル切り捨て特権を sales\$1rw ロールを付与するには、次の例を使用します。
```
GRANT TRUNCATE TABLE TO role sales_rw;
```
1. クエリエディタ v2 を使用してセールスエンジニアユーザーとしてデータベースに接続します。
1. セールススキーマでイベントテーブルから 10 件のイベントを読み取るには、次の例を使用します。
```
SELECT * FROM sales.events ORDER BY eventid LIMIT 10;
+---------+---------+-------+--------+-----------------------------+---------------------+
| eventid | venueid | catid | dateid | eventname | starttime |
+---------+---------+-------+--------+-----------------------------+---------------------+
| 1 | 305 | 8 | 1851 | Comment event | 2008-01-25 14:30:00 |
| 2 | 306 | 8 | 2114 | Boris Godunov | 2008-10-15 20:00:00 |
| 3 | 302 | 8 | 1935 | Salome | 2008-04-19 14:30:00 |
| 4 | 309 | 8 | 2090 | La Cenerentola (Cinderella) | 2008-09-21 14:30:00 |
| 5 | 302 | 8 | 1982 | Il Trovatore | 2008-06-05 19:00:00 |
| 6 | 308 | 8 | 2109 | L Elisir d Amore | 2008-10-10 19:30:00 |
| 7 | 309 | 8 | 1891 | Doctor Atomic | 2008-03-06 14:00:00 |
| 8 | 302 | 8 | 1832 | The Magic Flute | 2008-01-06 20:00:00 |
| 9 | 308 | 8 | 2087 | The Fly | 2008-09-18 19:30:00 |
| 10 | 305 | 8 | 2079 | Rigoletto | 2008-09-10 15:00:00 |
+---------+---------+-------+--------+-----------------------------+---------------------+
```
1. セールススキーマでイベントテーブルを切り捨てるには、次の例を使用します。
```
TRUNCATE sales.events;
```
1. セールススキーマで更新されたイベントテーブルからデータを読み取るには、次の例を使用します。
```
SELECT * FROM sales.events ORDER BY eventid LIMIT 10;
+---------+---------+-------+--------+-----------------------------+---------------------+
| eventid | venueid | catid | dateid | eventname | starttime |
+---------+---------+-------+--------+-----------------------------+---------------------+
```
### マーケティングスキーマに対して読み取り専用ロールおよび読み取り/書き込みロールを作成する (オプション)
このステップでは、マーケティングスキーマに対して読み取り専用ロールおよび読み取り/書き込みロールを作成します。
1. dbadmin ユーザーとしてデータベースに接続します。
1. マーケティングスキーマの読み取り専用ロールと読み取り/書き込みロールを作成するには、次の例を使用します。
```
CREATE ROLE marketing_ro;
CREATE ROLE marketing_rw;
GRANT USAGE ON SCHEMA marketing TO ROLE marketing_ro, ROLE marketing_rw;
GRANT SELECT ON ALL TABLES IN SCHEMA marketing TO ROLE marketing_ro;
GRANT ROLE marketing_ro TO ROLE marketing_rw;
GRANT INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA marketing TO ROLE marketing_rw;
CREATE USER marketinganalyst PASSWORD 'Test12345';
CREATE USER marketingengineer PASSWORD 'Test12345';
GRANT ROLE marketing_ro TO marketinganalyst;
GRANT ROLE marketing_rw TO marketingengineer;
```
## RBAC のシステム関数 (オプション)
Amazon Redshift には、追加のグループまたは role\$1is\$1member\$1of ロールおよび user\$1is\$1member\$1of ロールのユーザーメンバーシップおよびロールメンバーシップに関する情報を提供します。これらの関数は、スーパーユーザーと一般ユーザーが利用できます。スーパーユーザーはすべてのロールメンバーシップを確認できます。一般ユーザーは、アクセスが付与されているロールのメンバーシップのみを確認できます。
role\$1is\$1member\$1of 関数を使用するには
1. セールスエンジニアユーザーとしてデータベースに接続します。
1. sales\$1rw ロールが sales\$1ro ロールのメンバーかどうかを確認するには、次の例を使用します。
```
SELECT role_is_member_of('sales_rw', 'sales_ro');
+-------------------+
| role_is_member_of |
+-------------------+
| true |
+-------------------+
```
1. sales\$1ro ロールが sales\$1rw ロールのメンバーかどうかを確認するには、次の例を使用します。
```
SELECT role_is_member_of('sales_ro', 'sales_rw');
+-------------------+
| role_is_member_of |
+-------------------+
| false |
+-------------------+
```
user\$1is\$1member\$1of 関数を使用するには
1. セールスエンジニアユーザーとしてデータベースに接続します。
1. 次の例では、セールスアナリストユーザーのユーザーメンバーシップを確認しようとしています。セールスエンジニアはセールスアナリストへのアクセスがないため、このクエリはエラーになります。このコマンドを正常に実行するには、セールスアナリストユーザーとしてデータベースに接続し、例を使用します。
```
SELECT user_is_member_of('salesanalyst', 'sales_ro');
ERROR
```
1. スーパーユーザーとしてデータベースに接続します。
1. スーパーユーザーとして接続しているときにセールスアナリストユーザーのメンバーシップを確認するには、次の例を使用します。
```
SELECT user_is_member_of('salesanalyst', 'sales_ro');
+-------------------+
| user_is_member_of |
+-------------------+
| true |
+-------------------+
```
1. dbadmin ユーザーとしてデータベースに接続します。
1. セールスエンジニアのメンバーシップを確認するには、次の例を使用します。
```
SELECT user_is_member_of('salesengineer', 'sales_ro');
+-------------------+
| user_is_member_of |
+-------------------+
| true |
+-------------------+
SELECT user_is_member_of('salesengineer', 'marketing_ro');
+-------------------+
| user_is_member_of |
+-------------------+
| false |
+-------------------+
SELECT user_is_member_of('marketinganalyst', 'sales_ro');
+-------------------+
| user_is_member_of |
+-------------------+
| false |
+-------------------+
```
## RBAC のシステムビュー (オプション)
ロール、ユーザーへのロールの割り当て、ロール階層、およびロールによるデータベースオブジェクトの特権を表示するには、Amazon Redshift のシステムビューを使用します。これらのビューは、スーパーユーザーと一般ユーザーが利用できます。スーパーユーザーはすべてのロールの詳細を確認できます。一般ユーザーは、アクセスが付与されているロールの詳細のみを確認できます。
1. クラスターで明示的にロールが付与されたユーザーの一覧を表示するには、次の例を使用します。
```
SELECT * FROM svv_user_grants;
```
1. クラスターで明示的にロールが付与されたロールの一覧を表示するには、次の例を使用します。
```
SELECT * FROM svv_role_grants;
```
システムビューの全リストについては、「[SVV メタデータビュー](svv_views.md)」を参照してください。
## RBAC で行レベルセキュリティを使用する (オプション)
機密データに対するきめ細かなアクセス制御を行うには、行レベルセキュリティ (RLS) を使用します。RLS の詳細については、「[行レベルのセキュリティ](t_rls.md)」を参照してください。
このセクションでは、、メジャーリーグベースボールの `catdesc` 値を持つ `cat` テーブル内の行のみを表示する `salesengineer` アクセス許可をユーザーに付与する RLS ポリシーを作成します。次に、`salesengineer` ユーザーとしてデータベースにクエリを実行します。
1. `salesengineer` ユーザーとしてデータベースに接続します。
1. `cat` テーブルの最初の 5 エントリを表示するには、次の例を使用します。
```
SELECT *
FROM sales.cat
ORDER BY catid ASC
LIMIT 5;
+-------+----------+---------+---------------------------------+
| catid | catgroup | catname | catdesc |
+-------+----------+---------+---------------------------------+
| 1 | Sports | MLB | Major League Baseball |
| 2 | Sports | NHL | National Hockey League |
| 3 | Sports | NFL | National Football League |
| 4 | Sports | NBA | National Basketball Association |
| 5 | Sports | MLS | Major League Soccer |
+-------+----------+---------+---------------------------------+
```
1. `dbadmin` ユーザーとしてデータベースに接続します。
1. `cat` テーブル内の `catdesc` 列の RLS ポリシーを作成するには、次の例を使用します。
```
CREATE RLS POLICY policy_mlb_engineer
WITH (catdesc VARCHAR(50))
USING (catdesc = 'Major League Baseball');
```
1. RLS ポリシーを `sales_rw` ロールにアタッチするには、次の例を使用します。
```
ATTACH RLS POLICY policy_mlb_engineer ON sales.cat TO ROLE sales_rw;
```
1. RLS を有効にするようにテーブルを変更するには、次の例を使用します。
```
ALTER TABLE sales.cat ROW LEVEL SECURITY ON;
```
1. `salesengineer` ユーザーとしてデータベースに接続します。
1. `cat` テーブルの最初の 5 エントリを表示するには、次の例を使用します。`catdesc` 列が `Major League Baseball` のときのみエントリが表示されることに注意してください。
```
SELECT *
FROM sales.cat
ORDER BY catid ASC
LIMIT 5;
+-------+----------+---------+-----------------------+
| catid | catgroup | catname | catdesc |
+-------+----------+---------+-----------------------+
| 1 | Sports | MLB | Major League Baseball |
+-------+----------+---------+-----------------------+
```
1. `salesanalyst` ユーザーとしてデータベースに接続します。
1. `cat` テーブルの最初の 5 エントリを表示するには、次の例を使用します。デフォルトのすべて拒否ポリシーが適用されているため、エントリは表示されないことに注意してください。
```
SELECT *
FROM sales.cat
ORDER BY catid ASC
LIMIT 5;
+-------+----------+---------+-----------------------+
| catid | catgroup | catname | catdesc |
+-------+----------+---------+-----------------------+
```
1. `dbadmin` ユーザーとしてデータベースに接続します。
1. IGNORE RLS アクセス許可を `sales_ro` ロールに付与するには、次の例を使用します。これにより、`salesanalyst` ユーザーは `sales_ro` ロールのメンバーであるため、RLS ポリシーを無視するアクセス許可が付与されます。
```
GRANT IGNORE RLS TO ROLE sales_ro;
```
1. `salesanalyst` ユーザーとしてデータベースに接続します。
1. `cat` テーブルの最初の 5 エントリを表示するには、次の例を使用します。
```
SELECT *
FROM sales.cat
ORDER BY catid ASC
LIMIT 5;
+-------+----------+---------+---------------------------------+
| catid | catgroup | catname | catdesc |
+-------+----------+---------+---------------------------------+
| 1 | Sports | MLB | Major League Baseball |
| 2 | Sports | NHL | National Hockey League |
| 3 | Sports | NFL | National Football League |
| 4 | Sports | NBA | National Basketball Association |
| 5 | Sports | MLS | Major League Soccer |
+-------+----------+---------+---------------------------------+
```
1. `dbadmin` ユーザーとしてデータベースに接続します。
1. `sales_ro` ロールから IGNORE RLS アクセス許可を取り消すには、次の例を使用してください。
```
REVOKE IGNORE RLS FROM ROLE sales_ro;
```
1. `salesanalyst` ユーザーとしてデータベースに接続します。
1. `cat` テーブルの最初の 5 エントリを表示するには、次の例を使用します。デフォルトのすべて拒否ポリシーが適用されているため、エントリは表示されないことに注意してください。
```
SELECT *
FROM sales.cat
ORDER BY catid ASC
LIMIT 5;
+-------+----------+---------+-----------------------+
| catid | catgroup | catname | catdesc |
+-------+----------+---------+-----------------------+
```
1. `dbadmin` ユーザーとしてデータベースに接続します。
1. RLS ポリシーを `cat` テーブルから切り離すには、次の例を使用します。
```
DETACH RLS POLICY policy_mlb_engineer ON cat FROM ROLE sales_rw;
```
1. `salesanalyst` ユーザーとしてデータベースに接続します。
1. `cat` テーブルの最初の 5 エントリを表示するには、次の例を使用します。デフォルトのすべて拒否ポリシーが適用されているため、エントリは表示されないことに注意してください。
```
SELECT *
FROM sales.cat
ORDER BY catid ASC
LIMIT 5;
+-------+----------+---------+---------------------------------+
| catid | catgroup | catname | catdesc |
+-------+----------+---------+---------------------------------+
| 1 | Sports | MLB | Major League Baseball |
| 2 | Sports | NHL | National Hockey League |
| 3 | Sports | NFL | National Football League |
| 4 | Sports | NBA | National Basketball Association |
| 5 | Sports | MLS | Major League Soccer |
+-------+----------+---------+---------------------------------+
```
1. `dbadmin` ユーザーとしてデータベースに接続します。
1. RLS ポリシーをドロップするには、次の例を使用します。
```
DROP RLS POLICY policy_mlb_engineer;
```
1. RLS を削除するには、次の例を使用します。
```
ALTER TABLE cat ROW LEVEL SECURITY OFF;
```
## 関連トピック
RBAC の詳細については、次のドキュメントを参照してください。
+ [ロール階層](t_role_hierarchy.md)
+ [ロールの割り当て](t_role_assignment.md)
+ [データベースオブジェクトへのアクセス許可](r_roles-database-privileges.md)
+ [RBAC での ALTER DEFAULT PRIVILEGES](r_roles-alter-default-privileges.md)
# 行レベルのセキュリティ
Amazon Redshift で行レベルセキュリティ (RLS) を使用すると、機密データに対するきめ細かなアクセス制御を行うことができます。データベースオブジェクトレベルで定義されたセキュリティポリシーに基づいて、スキーマまたはテーブル内の特定のデータレコードにアクセスできるユーザーまたはロールを選択できます。列のサブセットに対する許可をユーザーに付与できる列レベルのセキュリティに加えて、RLS ポリシーを使用して表示されている列の特定の行に対するアクセスをさらに制限します。行レベルのセキュリティの詳細については、「[列レベルのアクセスコントロールの使用上の注意](r_GRANT-usage-notes.md#r_GRANT-usage-notes-clp)」を参照してください。
テーブルに RLS ポリシーを実行するとき、ユーザーがクエリを実行したときに返される結果セットを制限できます。
RLS ポリシーを作成するとき、Amazon Redshift がクエリのテーブル内にある既存の行を返すかどうか決定する式を指定できます。アクセスを制限する RLS ポリシーを作成することで、クエリにさらなる条件を追加または外在化する必要がなくなります。
RLS ポリシーを作成するとき、単純なポリシーを作成して、ポリシーの複雑なステートメントを避けることをお勧めします。RLS ポリシーを定義するとき、ポリシーに基づくポリシー定義で過度なテーブル結合を使用しないでください。
ポリシーがルックアップテーブルを参照するとき、ポリシーが存在するテーブルに加え、Amazon Redshift は追加のテーブルをスキャンします。RLS ポリシーがアタッチされているユーザーと、ポリシーがアタッチされていないユーザーでは、同じクエリのパフォーマンスに違いが発生します。
# SQL ステートメントで RLS ポリシーの使用
SQL ステートメントで RLS ポリシーを使用するとき、Amazon Redshift は次のルールを適用します。
+ Amazon Redshift は、デフォルトで SELECT、UPDATE、DELETE ステートメントに RLS ポリシーを適用します。
+ SELECT と UNLOAD の場合、Amazon Redshift は定義されたポリシーに従って行をフィルタリングします。
+ UPDATE の場合、Amazon Redshift は表示されている行のみを更新します。ポリシーがテーブルの行のサブセットを制限している場合、更新することはできません。
+ DELETE の場合、表示されている行のみを削除できます。ポリシーがテーブル内の行のサブセットを制限している場合、削除することはできません。TRUNCATE の場合でも、テーブルを切り捨てることができます。
+ CREATE TABLE LIKE の場合、LIKE オプションで作成されたテーブルはソーステーブルから許可設定を継承しません。同様に、ターゲットテーブルはソーステーブルから RLS ポリシーを継承しません。
# ユーザーごとに複数ポリシーの組み合わせ
Amazon Redshift の RLS は、ユーザーとオブジェクトごとに複数ポリシーのアタッチをサポートしています。1 人のユーザーに対して複数ポリシーが定義されていると、Amazon Redshift は、テーブル上の RLS CONJUNCTION TYPE に応じて、AND 構文または OR 構文ですべてのポリシーを適用します。設定タイプの詳細については、「[ALTER TABLE](r_ALTER_TABLE.md)」を参照してください。
テーブルの複数ポリシーをお客様に関連付けることができます。複数のポリシーが直接お客様にアタッチされているか、複数のロールに属していて、ロールに異なるポリシーがアタッチされています。
複数のポリシーで特定の関係の行アクセスを制限する必要がある場合、関係の RLS CONJUNCTION TYPE を AND に設定できます。次の例を考えます。Alice は、指定されたポリシーで「キャットネーム」が「NBA」になっているスポーツイベントしか見ることができません。
```
-- Create an analyst role and grant it to a user named Alice.
CREATE ROLE analyst;
CREATE USER alice WITH PASSWORD 'Name_is_alice_1';
GRANT ROLE analyst TO alice;
-- Create an RLS policy that only lets the user see sports.
CREATE RLS POLICY policy_sports
WITH (catgroup VARCHAR(10))
USING (catgroup = 'Sports');
-- Create an RLS policy that only lets the user see NBA.
CREATE RLS POLICY policy_nba
WITH (catname VARCHAR(10))
USING (catname = 'NBA');
-- Attach both to the analyst role.
ATTACH RLS POLICY policy_sports ON category TO ROLE analyst;
ATTACH RLS POLICY policy_nba ON category TO ROLE analyst;
-- Activate RLS on the category table with AND CONJUNCTION TYPE.
ALTER TABLE category ROW LEVEL SECURITY ON CONJUNCTION TYPE AND;
-- Change session to Alice.
SET SESSION AUTHORIZATION alice;
-- Select all from the category table.
SELECT catgroup, catname
FROM category;
catgroup | catname
---------+---------
Sports | NBA
(1 row)
```
複数のポリシーによって、ユーザーが特定の関係で、より多くの行を表示できるようにする必要がある場合、ユーザーはそのリレーションの RLS CONJUNCTION TYPE を OR に設定できます。次の例を考えます。Alice は、指定されたポリシーに従って「コンサート」と「スポーツ」しか表示できません。
```
-- Create an analyst role and grant it to a user named Alice.
CREATE ROLE analyst;
CREATE USER alice WITH PASSWORD 'Name_is_alice_1';
GRANT ROLE analyst TO alice;
-- Create an RLS policy that only lets the user see concerts.
CREATE RLS POLICY policy_concerts
WITH (catgroup VARCHAR(10))
USING (catgroup = 'Concerts');
-- Create an RLS policy that only lets the user see sports.
CREATE RLS POLICY policy_sports
WITH (catgroup VARCHAR(10))
USING (catgroup = 'Sports');
-- Attach both to the analyst role.
ATTACH RLS POLICY policy_concerts ON category TO ROLE analyst;
ATTACH RLS POLICY policy_sports ON category TO ROLE analyst;
-- Activate RLS on the category table with OR CONJUNCTION TYPE.
ALTER TABLE category ROW LEVEL SECURITY ON CONJUNCTION TYPE OR;
-- Change session to Alice.
SET SESSION AUTHORIZATION alice;
-- Select all from the category table.
SELECT catgroup, count(*)
FROM category
GROUP BY catgroup ORDER BY catgroup;
catgroup | count
---------+-------
Concerts | 3
Sports | 5
(2 rows)
```
# RLS ポリシーの所有権と管理
スーパーユーザー、セキュリティ管理者、sys:secadmin ロールを持つユーザーのいずれかに該当する場合は、RLS ポリシーを作成、修正、アタッチ、デタッチできます。RLS ポリシーは、テーブル、ビュー、遅延バインディングビュー (LBV)、マテリアライズドビュー (MV) にアタッチできます。オブジェクトレベルでは、テーブルのスキーマ定義を修正せずに行レベルのセキュリティをオンまたはオフに切り替えることができます。
行レベルのセキュリティを開始するには、次の SQL ステートメントを使用できます。
+ ALTER TABLE ステートメントを使用して、テーブル、ビュー、遅延バインディングビューに対する RLS のオンまたはオフを切り替えます。詳細については、「[ALTER TABLE](r_ALTER_TABLE.md)」を参照してください。
+ ALTER MATERIALIZED VIEW ステートメントを使用して、マテリアライズドビュー (MV) に対する RLS のオンまたはオフを切り替えます。詳細については、「[ALTER MATERIALIZED VIEW](r_ALTER_MATERIALIZED_VIEW.md)」を参照してください。
+ CREATE RLS POLICY ステートメントを使用し、1 つ以上のテーブルのセキュリティポリシーを作成して、ポリシーに 1 つ以上のユーザーまたはロールを指定します。
詳細については、「[CREATE RLS POLICY](r_CREATE_RLS_POLICY.md)」を参照してください。
+ ALTER RLS POLICY ステートメントを使用して、ポリシー定義の変更など、ポリシーを変更します。同じポリシーを複数のテーブルまたはビューに使用できます。
詳細については、「[RLS ポリシーの変更](r_ALTER_RLS_POLICY.md)」を参照してください。
+ ATTACH RLS POLICY ステートメントを使用して、1 つ以上の関係、1 つ以上のユーザー、ロールのいずれかにポリシーをアタッチします。
詳細については、「[ATTACH RLS POLICY](r_ATTACH_RLS_POLICY.md)」を参照してください。
+ DETACH RLS POLICY ステートメントを使用して、1 つ以上の関係、1 つ以上のユーザー、ロールのいずれかからポリシーをデタッチします。
詳細については、「[DETACH RLS POLICY](r_DETACH_RLS_POLICY.md)」を参照してください。
+ DROP RLS POLICY ステートメントを使用して、ポリシーを削除します。
詳細については、「[DROP RLS POLICY](r_DROP_RLS_POLICY.md)」を参照してください。
+ GRANT と REVOKE ステートメントを使用して、ルックアップテーブルを参照する RLS ポリシーの SELECT 許可を明示的に付与と取り消しを行います。詳細については、「[GRANT](r_GRANT.md)」および「[REVOKE](r_REVOKE.md)」を参照してください。
作成されたポリシーをモニタリングするため、sys:secadmin は [SVV\$1RLS\$1POLICY](r_SVV_RLS_POLICY.md) と [SVV\$1RLS\$1ATTACHED\$1POLICY](r_SVV_RLS_ATTACHED_POLICY.md) を確認できます。
RLS で保護された関係のリストを表示するため、sys:secadmin は [SVV\$1RLS\$1RELATION](r_SVV_RLS_RELATION.md) を確認できます。
RLS で保護された関係を参照するクエリの RLS ポリシーの適用を追跡するため、スーパーユーザー、sys:operator、ACCESS SYSTEM TABLE のシステム許可を持つ任意のユーザーのいずれかは [SVV\$1RLS\$1APPLIED\$1POLICY](r_SVV_RLS_APPLIED_POLICY.md) を確認できます。sys:secadmin はデフォルトでこれらの許可が付与されていないことに注意してください。
RLS で保護された関係へのフルアクセスをユーザーに許可するには、IGNORE RLS アクセス許可を付与します。スーパーユーザーまたは sys:secadmin には、IGNORE RLS が自動的に付与されます。詳細については、「[GRANT](r_GRANT.md)」を参照してください。
RLS 関連のクエリをトラブルシューティングするために EXPLAIN プランのクエリの RLS ポリシーフィルタを説明するには、EXPLAIN RLS 許可を任意のユーザーに付与できます。詳細については、「[GRANT](r_GRANT.md)」および「[EXPLAIN](r_EXPLAIN.md)」を参照してください。
# ポリシーに依存するオブジェクトと原則
アプリケーションにセキュリティを提供し、ポリシーオブジェクトが古くなったり、無効になったりすることを防止するため、Amazon Redshift は RLS ポリシーによって参照されるオブジェクトの削除や変更を許可していません。
以下のものは、Amazon Redshift が RLS ポリシー用にトラッキングするスキーマオブジェクトの従属関係を一覧表示します。
+ ターゲットテーブルのスキーマオブジェクトの従属関係をトラッキングするとき、Amazon Redshift は次のルールに従います。
+ ターゲットテーブルを削除するとき、Amazon Redshift は関係、ユーザー、ロール、パブリックからポリシーをデタッチします。
+ ターゲットテーブル名の名前を変更しても、アタッチされたポリシーには影響しません。
+ 最初にポリシーを削除またはデタッチしない限り、ポリシー定義内で参照対象のターゲットテーブルの列を削除することはできません。これは、CASCADE オプションが指定されている場合にも当てはまります。ターゲットテーブルの他の列を削除できます。
+ ターゲットテーブルの参照列の名前を変更することはできません。参照列の名前を変更するには、まずポリシーをデタッチします。これは、CASCADE オプションが指定されている場合にも当てはまります。
+ CASCADE オプションを指定しても、参照列のタイプを変更できません。
+ ルックアップテーブルのスキーマオブジェクトの依存をトラッキングするとき、Amazon Redshift は次のルールに従います。
+ ルックアップテーブルは削除できません。ルックアップテーブルを削除するには、まずルックアップテーブルが参照対象のポリシーを削除します。
+ ルックアップテーブルの名前を変更することはできません。ルックアップテーブルの名前を変更するには、まずルックアップテーブルが参照対象のポリシーを削除します。これは、CASCADE オプションが指定されている場合にも当てはまります。
+ ポリシー定義で使用されているルックアップテーブルの列は削除できません。ポリシー定義で使用されているルックアップテーブルの列を削除するには、まずルックアップテーブルが参照対象のポリシーを削除します。これは、ALTER TABLE DROP COLUMN ステートメントで CASCADE オプションが指定されているときにも適用されます。ルックアップテーブルの他の列を削除できます。
+ ルックアップテーブルの参照列の名前を変更することはできません。参照列の名前を変更するには、まずルックアップテーブルの参照対象となるポリシーを削除します。これは、CASCADE オプションが指定されている場合にも当てはまります。
+ 参照列のタイプを変更することはできません。
+ ユーザーまたはロールを削除すると、Amazon Redshift はそのユーザーまたはロールにアタッチされているすべてのポリシーを自動的にデタッチします。
+ DROP SCHEMA ステートメントで CASCADE オプションを使用するとき、Amazon Redshift はスキーマの関係も削除します。削除されたスキーマの関係に依存する他のスキーマの関係もすべて削除します。ポリシーのルックアップテーブルである関係の場合、Amazon Redshift は DROP SCHEMA DDL に失敗します。DROP SCHEMA ステートメントによって削除された関係の場合、Amazon Redshift はそれらの関係にアタッチされているすべてのポリシーをデタッチします。
+ ルックアップ関数 (ポリシー定義内で参照される関数) は、ポリシーも削除する場合に限り、削除できます。これは、CASCADE オプションが指定されている場合にも当てはまります。
+ ポリシーがテーブルにアタッチされると、Amazon Redshift はこのテーブルが別のポリシーのルックアップテーブルであるかどうか確認します。この場合、Amazon Redshift はこのテーブルにポリシーのアタッチを許可しません。
+ RLS ポリシーの作成時に、Amazon Redshift はこのテーブルが他の RLS ポリシーのターゲットテーブルであるかどうか確認します。この場合、Amazon Redshift はこのテーブルにポリシーの作成を許可しません。
## 例
次の例では、スキーマの依存がどのようにトラッキングされるかについて示しています。
```
-- The CREATE and ATTACH policy statements for `policy_events` references some
-- target and lookup tables.
-- Target tables are tickit_event_redshift and target_schema.target_event_table.
-- Lookup table is tickit_sales_redshift.
-- Policy `policy_events` has following dependencies:
-- table tickit_sales_redshift column eventid, qtysold
-- table tickit_event_redshift column eventid
-- table target_event_table column eventid
-- schema public and target_schema
CREATE RLS POLICY policy_events
WITH (eventid INTEGER)
USING (
eventid IN (SELECT eventid FROM tickit_sales_redshift WHERE qtysold <3)
);
ATTACH RLS POLICY policy_events ON tickit_event_redshift TO ROLE analyst;
ATTACH RLS POLICY policy_events ON target_schema.target_event_table TO ROLE consumer;
```
# RLS ポリシーを使用する際の考慮事項と制限事項
## 考慮事項
RLS ポリシーを操作する際の考慮事項は次のとおりです。
+ Amazon Redshift は、RLS ポリシーを SELECT、UPDATE、DELETE ステートメントに適用します。
+ Amazon Redshift は、RLS ポリシーを INSERT、COPY、ALTER TABLE APPEND ステートメントに適用しません。
+ RLS ポリシーは、テーブル、ビュー、遅延バインディングビュー (LBV)、マテリアライズドビュー (MV) にアタッチできます。
+ 行レベルのセキュリティは、列レベルのセキュリティと連携してデータを保護します。
+ ソース関係で RLS がオンになっているとき、Amazon Redshift は、スーパーユーザー、IGNORE RLS のシステムアクセス許可を明示的に付与されたユーザー、sys:secadmin ロールに対して ALTER TABLE APPEND ステートメントをサポートします。この場合、ALTER TABLE APPEND ステートメントを実行して、既存のソーステーブルからデータを移動することにより、ターゲットテーブルに行を追加できます。Amazon Redshift は、すべてのタプルをソース関係からターゲット関係に移動します。ターゲット関係の RLS ステータスは、ALTER TABLE APPEND ステートメントには影響しません。
+ 他のデータウェアハウスシステムからの移行を容易にするには、変数名と値を指定することにより、接続用にカスタマイズされたセッションコンテキスト変数を設定と取得できます。
次の例では、行レベルセキュリティ (RLS) ポリシーのセッションコンテキスト変数を設定します。
```
-- Set a customized context variable.
SELECT set_config(‘app.category’, ‘Concerts’, FALSE);
-- Create a RLS policy using current_setting() to get the value of a customized context variable.
CREATE RLS POLICY policy_categories
WITH (catgroup VARCHAR(10))
USING (catgroup = current_setting('app.category', FALSE));
-- Set correct roles and attach the policy on the target table to one or more roles.
ATTACH RLS POLICY policy_categories ON tickit_category_redshift TO ROLE analyst, ROLE dbadmin;
```
カスタマイズされたセッションコンテキスト変数の設定と取得の詳細については、「[SET](r_SET.md)」、「[SET\$1CONFIG](r_SET_CONFIG.md)」、「[SHOW](r_SHOW.md)」、「[CURRENT\$1SETTING](r_CURRENT_SETTING.md)」、「[RESET](r_RESET.md)」を参照してください。サーバー設定変更全般の詳細については、「[サーバー設定の変更](cm_chap_ConfigurationRef.md#t_Modifying_the_default_settings)」を参照してください。
**重要**
RLS ポリシー内でセッションコンテキスト変数を使用する場合、セキュリティポリシーはポリシーを呼び出すユーザーまたはロールに依存します。RLS ポリシーでセッションコンテキスト変数を使用する場合は、セキュリティの脆弱性を避けるように注意してください。
+ DECLARE と FETCH の間、または後続の FETCH ステートメントの間に SET SESSION AUTHORIZATION を使用してセッションユーザーを変更しても、DECLARE 時のユーザーポリシーに基づいて既に準備されているプランは更新されません。RLS で保護されたテーブルでカーソルを使用する場合は、セッションユーザーを変更しないでください。
+ ビューオブジェクト内のベースオブジェクトが RLS で保護されている場合、クエリを実行しているユーザーにアタッチされたポリシーがそれぞれのベースオブジェクトに適用されます。これは、ビュー所有者の権限がビューベースオブジェクトと照合されるオブジェクトレベルのアクセス許可チェックとは異なります。クエリの RLS で保護されたリレーションは、EXPLAIN プランの出力で確認できます。
+ ユーザー定義関数 (UDF) がユーザーに関連付けられたリレーションの RLS ポリシーで参照される場合、リレーションをクエリするには UDF に対する EXECUTE 権限が必要です。
+ 行レベルのセキュリティは、クエリの最適化を制限する可能性があります。RLS で保護されたビューを大きなデータセットにデプロイする前に、クエリのパフォーマンスを慎重に評価することをお勧めします。
+ 遅延バインディングビューに適用される行レベルのセキュリティポリシーは、フェデレーションテーブルにプッシュされる可能性があります。これらの RLS ポリシーは、外部の処理エンジンログに表示される場合があります。
## 制限事項
RLS ポリシーを操作する場合の制限事項は次のとおりです。
+ RLS ポリシーは、外部テーブルやその他のいくつかの関係タイプにはアタッチできません。詳細については、「[ATTACH RLS POLICY](r_ATTACH_RLS_POLICY.md)」を参照してください。
+ Amazon Redshift は、複雑な結合を持つルックアップを備える特定の RLS ポリシーの SELECT ステートメントをサポートしていますが、UPDATE または DELETE ステートメントはサポートしていません。UPDATE または DELETE ステートメントの場合、Amazon Redshift は次のエラーを返します。
```
ERROR: One of the RLS policies on target relation is not supported in UPDATE/DELETE.
```
+ ユーザー定義関数 (UDF) がユーザーに関連付けられたリレーションの RLS ポリシーで参照される場合は常に、リレーションをクエリするには UDF に対する EXECUTE 権限が必要です。
+ 相関サブクエリはサポートされていません。Amazon Redshift は次のエラーを返します。
```
ERROR: RLS policy could not be rewritten.
```
+ Amazon Redshift は RLS とのデータの共有をサポートしていません。リレーションでデータ共有の RLS がオフになっていない場合、クエリはコンシューマークラスターで失敗し、次のエラーが表示されます。
```
RLS-protected relation "rls_protected_table" cannot be accessed via datasharing query.
```
パラメータ ROW LEVEL SECURITY OFF FOR DATASHARES を指定して ALTER TABLE コマンドを使用すると、データ共有の RLS をオフにできます。ALTER TABLE を使用して RLS を有効または無効にする方法の詳細については、「[ALTER TABLE](r_ALTER_TABLE.md)」を参照してください。
+ クロスデータベースクエリでは、Amazon Redshift は RLS で保護されたリレーションへの読み取りをブロックします。IGNORE RLS 権限を持つユーザーは、クロスデータベースクエリを使用して保護されたリレーションにアクセスできます。IGNORE RLS 権限のないユーザーが、クロスデータベースクエリを通じて RLS で保護されたリレーションにアクセスすると、次のエラーが表示されます。
```
RLS-protected relation "rls_protected_table" cannot be accessed via cross-database query.
```
+ ALTER RLS POLICY では、USING (using\$1predicate\$1exp) 句を使用する、RLS ポリシーの変更のみがサポートされています。ALTER RLS POLICY を実行しているときに WITH 句を使用して RLS ポリシーを変更することはできません。
+ 以下の設定オプションのいずれかの値がセッションのデフォルト値と一致しない場合、行レベルのセキュリティが有効になっているリレーションをクエリすることはできません。
+ `enable_case_sensitive_super_attribute`
+ `enable_case_sensitive_identifier`
+ `downcase_delimited_identifier`
行レベルのセキュリティをオンにしてリレーションをクエリしようとして、「RLS で保護されたリレーションは、大文字と小文字の区別がデフォルト値と異なるため、セッションレベルの設定をサポートしていません」というメッセージが表示される場合は、セッションの設定オプションをリセットすることを検討してください。
+ プロビジョニングされたクラスターまたはサーバーレス名前空間に行レベルのセキュリティポリシーが適用されている場合、以下のコマンドは標準ユーザーにはブロックされます。
```
ALTER SET enable_case_sensitive_super_attribute/enable_case_sensitive_identifier/downcase_delimited_identifier
```
RLS ポリシーを作成するときは、ポリシー作成時のセッションの設定オプションの設定と一致するように、標準ユーザーのデフォルトの設定オプション設定を変更することをお勧めします。スーパーユーザーと ALTER USER 権限を持つユーザーは、パラメータグループ設定または ALTER USER コマンドを使用して、この操作を行うことができます。パラメータグループの詳細については、「*Amazon Redshift 管理ガイド*」の「[Amazon Redshift パラメータグループ](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-parameter-groups.html)」を参照してください。ALTER USER コマンドの詳細については、「[ALTER USER](r_ALTER_USER.md)」を参照してください。
+ 行レベルのセキュリティポリシーが設定されたビューや遅延バインディングビューは、通常のユーザーが [CREATE VIEW](r_CREATE_VIEW.md) コマンドを使用して置き換えることはできません。ビューまたは LBV を RLS ポリシーに置き換えるには、まず、それらにアタッチされている RLS ポリシーをすべてデタッチし、ビューまたは LBV を置き換えてから、ポリシーを再アタッチします。スーパーユーザーと、`sys:secadmin permission` を持っているユーザーは、ポリシーをデタッチしなくても、RLS ポリシーが設定されたビューまたは LBV で CREATE VIEW を使用できます。
+ 行レベルのセキュリティポリシーが設定されているビューは、システムテーブルやシステムビューを参照できません。
+ 通常のビューが参照する遅延バインディングビューは RLS 保護ができません。
+ RLS 保護がなされた関係と、データレイクからのネストされたデータには、同じクエリではアクセスできません。
# RLS パフォーマンスのベストプラクティス
RLS で保護されているテーブルで Amazon Redshift のパフォーマンスを向上させるためのベストプラクティスは次のとおりです。
## 演算子と関数の安全性
RLS で保護されたテーブルを照合するとき、特定の演算子または関数を使用すると、パフォーマンスが低下する可能性があります。Amazon Redshift は、RLS で保護されたテーブルを照合するうえで、演算子と関数を安全または安全でないものとして分類します。関数または演算子は、入力内容に応じて観察可能な副作用がない場合、RLS に安全なものとして分類されます。特に、RLS に安全な関数または演算子は、次のいずれに該当することはできません。
+ エラーメッセージの有無にかかわらず、入力値または入力値に依存する値を出力。
+ 入力値に依存する失敗またはエラーを返答。
RLS に対して安全ではない演算子には、次のものが含まれます。
+ 算術演算子 - \$1、-、/、\$1、%。
+ テキスト演算子 - LIKE と SIMILAR TO。
+ 演算子の投入。
+ UDF。
次の SELECT ステートメントを使用して、演算子と関数の安全性を確認します。
```
SELECT proname, proc_is_rls_safe(oid) FROM pg_proc;
```
Amazon Redshift は、RLS で保護されたテーブルにクエリを計画する際に、RLS に安全ではない演算子と関数を含むユーザー述語の評価順序に制限を課します。RLS に安全ではない演算子または関数を参照するクエリは、RLS で保護されたテーブルを照合する際にパフォーマンス低下に影響する可能性があります。Amazon Redshift が RLS に安全ではない述語をベーステーブルスキャンにプッシュダウンしてソートキーを活用できない場合、パフォーマンスが大幅に低下する可能性があります。パフォーマンスを向上させるには、ソートキーを活用する RLS に安全ではない述語を使用するクエリは避けてください。Amazon Redshift が演算子と関数をプッシュダウンできることを確認するには、EXPLAIN ステートメントをシステムアクセス許可の EXPLAIN RLS と組み合わせて使用できます。
## 結果のキャッシュ
クエリの実行時間を短縮してシステムパフォーマンスを向上させるため、Amazon Redshift では、リーダーノード上のメモリで特定タイプのクエリ結果がキャッシュされます。
保護されていないテーブルのすべての条件が満たされて、かつ次の条件がすべて満たされた場合、Amazon Redshift は RLS で保護されたテーブルをスキャンする新しいクエリに対してキャッシュ結果を適用します。
+ ポリシーのテーブルまたはビューは修正されていません。
+ ポリシーは、実行するたびに評価する必要がある関数 (GETDATE または CURRENT\$1USER など) を使用しません。
パフォーマンスを向上させるには、上記の条件を満たさないポリシー述語の使用を避けてください。
Amazon Redshift での結果キャッシュの詳細については、「[結果のキャッシュ](c_challenges_achieving_high_performance_queries.md#result-caching)」を参照してください。
## 複雑なポリシー
パフォーマンスを向上させるには、複数のテーブルを結合するサブクエリを持つ複雑なポリシーの使用を避けてください。
# 行レベルのセキュリティのエンドツーエンドの例
以下の内容は、スーパーユーザーが一部のユーザーとロールを作成する方法を示すエンドツーエンドの例です。次に、secadmin ロールを持つユーザーが RLS ポリシーを作成、アタッチ、デタッチ、削除します。この例では、チケットサンプルデータベースを使用します。詳細については、「*Amazon Redshift 入門ガイド*」の「[Amazon S3 から Amazon Redshift データをロードする](https://docs.aws.amazon.com/redshift/latest/gsg/rs-gsg-create-sample-db.html)」を参照してください。
```
-- Create users and roles referenced in the policy statements.
CREATE ROLE analyst;
CREATE ROLE consumer;
CREATE ROLE dbadmin;
CREATE ROLE auditor;
CREATE USER bob WITH PASSWORD 'Name_is_bob_1';
CREATE USER alice WITH PASSWORD 'Name_is_alice_1';
CREATE USER joe WITH PASSWORD 'Name_is_joe_1';
CREATE USER molly WITH PASSWORD 'Name_is_molly_1';
CREATE USER bruce WITH PASSWORD 'Name_is_bruce_1';
GRANT ROLE sys:secadmin TO bob;
GRANT ROLE analyst TO alice;
GRANT ROLE consumer TO joe;
GRANT ROLE dbadmin TO molly;
GRANT ROLE auditor TO bruce;
GRANT ALL ON TABLE tickit_category_redshift TO PUBLIC;
GRANT ALL ON TABLE tickit_sales_redshift TO PUBLIC;
GRANT ALL ON TABLE tickit_event_redshift TO PUBLIC;
-- Create table and schema referenced in the policy statements.
CREATE SCHEMA target_schema;
GRANT ALL ON SCHEMA target_schema TO PUBLIC;
CREATE TABLE target_schema.target_event_table (LIKE tickit_event_redshift);
GRANT ALL ON TABLE target_schema.target_event_table TO PUBLIC;
-- Change session to analyst alice.
SET SESSION AUTHORIZATION alice;
-- Check the tuples visible to analyst alice.
-- Should contain all 3 categories.
SELECT catgroup, count(*)
FROM tickit_category_redshift
GROUP BY catgroup ORDER BY catgroup;
-- Change session to security administrator bob.
SET SESSION AUTHORIZATION bob;
CREATE RLS POLICY policy_concerts
WITH (catgroup VARCHAR(10))
USING (catgroup = 'Concerts');
SELECT poldb, polname, polalias, polatts, polqual, polenabled, polmodifiedby FROM svv_rls_policy WHERE poldb = CURRENT_DATABASE();
ATTACH RLS POLICY policy_concerts ON tickit_category_redshift TO ROLE analyst, ROLE dbadmin;
ALTER TABLE tickit_category_redshift ROW LEVEL SECURITY ON;
SELECT * FROM svv_rls_attached_policy;
-- Change session to analyst alice.
SET SESSION AUTHORIZATION alice;
-- Check that tuples with only `Concert` category will be visible to analyst alice.
SELECT catgroup, count(*)
FROM tickit_category_redshift
GROUP BY catgroup ORDER BY catgroup;
-- Change session to consumer joe.
SET SESSION AUTHORIZATION joe;
-- Although the policy is attached to a different role, no tuples will be
-- visible to consumer joe because the default deny all policy is applied.
SELECT catgroup, count(*)
FROM tickit_category_redshift
GROUP BY catgroup ORDER BY catgroup;
-- Change session to dbadmin molly.
SET SESSION AUTHORIZATION molly;
-- Check that tuples with only `Concert` category will be visible to dbadmin molly.
SELECT catgroup, count(*)
FROM tickit_category_redshift
GROUP BY catgroup ORDER BY catgroup;
-- Check that EXPLAIN output contains RLS SecureScan to prevent disclosure of
-- sensitive information such as RLS filters.
EXPLAIN SELECT catgroup, count(*) FROM tickit_category_redshift GROUP BY catgroup ORDER BY catgroup;
-- Change session to security administrator bob.
SET SESSION AUTHORIZATION bob;
-- Grant IGNORE RLS permission so that RLS policies do not get applicable to role dbadmin.
GRANT IGNORE RLS TO ROLE dbadmin;
-- Grant EXPLAIN RLS permission so that anyone in role auditor can view complete EXPLAIN output.
GRANT EXPLAIN RLS TO ROLE auditor;
-- Change session to dbadmin molly.
SET SESSION AUTHORIZATION molly;
-- Check that all tuples are visible to dbadmin molly because `IGNORE RLS` is granted to role dbadmin.
SELECT catgroup, count(*)
FROM tickit_category_redshift
GROUP BY catgroup ORDER BY catgroup;
-- Change session to auditor bruce.
SET SESSION AUTHORIZATION bruce;
-- Check explain plan is visible to auditor bruce because `EXPLAIN RLS` is granted to role auditor.
EXPLAIN SELECT catgroup, count(*) FROM tickit_category_redshift GROUP BY catgroup ORDER BY catgroup;
-- Change session to security administrator bob.
SET SESSION AUTHORIZATION bob;
DETACH RLS POLICY policy_concerts ON tickit_category_redshift FROM ROLE analyst, ROLE dbadmin;
-- Change session to analyst alice.
SET SESSION AUTHORIZATION alice;
-- Check that no tuples are visible to analyst alice.
-- Although the policy is detached, no tuples will be visible to analyst alice
-- because of default deny all policy is applied if the table has RLS on.
SELECT catgroup, count(*)
FROM tickit_category_redshift
GROUP BY catgroup ORDER BY catgroup;
-- Change session to security administrator bob.
SET SESSION AUTHORIZATION bob;
CREATE RLS POLICY policy_events
WITH (eventid INTEGER) AS ev
USING (
ev.eventid IN (SELECT eventid FROM tickit_sales_redshift WHERE qtysold <3)
);
ATTACH RLS POLICY policy_events ON tickit_event_redshift TO ROLE analyst;
ATTACH RLS POLICY policy_events ON target_schema.target_event_table TO ROLE consumer;
RESET SESSION AUTHORIZATION;
-- Can not cannot alter type of dependent column.
ALTER TABLE target_schema.target_event_table ALTER COLUMN eventid TYPE float;
ALTER TABLE tickit_event_redshift ALTER COLUMN eventid TYPE float;
ALTER TABLE tickit_sales_redshift ALTER COLUMN eventid TYPE float;
ALTER TABLE tickit_sales_redshift ALTER COLUMN qtysold TYPE float;
-- Can not cannot rename dependent column.
ALTER TABLE target_schema.target_event_table RENAME COLUMN eventid TO renamed_eventid;
ALTER TABLE tickit_event_redshift RENAME COLUMN eventid TO renamed_eventid;
ALTER TABLE tickit_sales_redshift RENAME COLUMN eventid TO renamed_eventid;
ALTER TABLE tickit_sales_redshift RENAME COLUMN qtysold TO renamed_qtysold;
-- Can not drop dependent column.
ALTER TABLE target_schema.target_event_table DROP COLUMN eventid CASCADE;
ALTER TABLE tickit_event_redshift DROP COLUMN eventid CASCADE;
ALTER TABLE tickit_sales_redshift DROP COLUMN eventid CASCADE;
ALTER TABLE tickit_sales_redshift DROP COLUMN qtysold CASCADE;
-- Can not drop lookup table.
DROP TABLE tickit_sales_redshift CASCADE;
-- Change session to security administrator bob.
SET SESSION AUTHORIZATION bob;
DROP RLS POLICY policy_concerts;
DROP RLS POLICY IF EXISTS policy_events;
ALTER TABLE tickit_category_redshift ROW LEVEL SECURITY OFF;
RESET SESSION AUTHORIZATION;
-- Drop users and roles.
DROP USER bob;
DROP USER alice;
DROP USER joe;
DROP USER molly;
DROP USER bruce;
DROP ROLE analyst;
DROP ROLE consumer;
DROP ROLE auditor FORCE;
DROP ROLE dbadmin FORCE;
```
# メタデータセキュリティ
Amazon Redshift の行レベルのセキュリティと同様に、メタデータセキュリティではメタデータをよりきめ細かく制御できます。プロビジョニングされたクラスターまたはサーバーレスワークグループでメタデータセキュリティが有効になっている場合、ユーザーは、表示アクセス権のあるオブジェクトのメタデータを表示できます。メタデータセキュリティにより、必要に応じて可視性を分離できます。例えば、1 つのデータウェアハウスを使用してすべてのデータストレージを一元化できます。ただし、複数のセクターのデータを保存すると、セキュリティ管理が難しくなる可能性があります。メタデータセキュリティを有効にすると、可視性を設定できます。あるセクターのユーザーにはオブジェクトの可視性を高め、別のセクターのユーザーには表示アクセスを制限することができます。メタデータセキュリティは、スキーマ、テーブル、ビュー、マテリアライズドビュー、ストアドプロシージャ、ユーザー定義機能、および機械学習モデルなどのすべてのオブジェクトタイプをサポートしています。
ユーザーは、次の状況でオブジェクトのメタデータを表示できます。
+ オブジェクトへのアクセスがユーザーに許可されている場合。
+ ユーザーが所属するグループまたはロールにオブジェクトアクセスが付与されている場合。
+ オブジェクトが公開されている場合。
+ ユーザーがデータベースオブジェクトの所有者である場合。
メタデータセキュリティを有効にするには、[ALTER SYSTEM](https://docs.aws.amazon.com/redshift/latest/dg/r_ALTER_SYSTEM.html) コマンドを使用します。ALTER SYSTEM コマンドをメタデータセキュリティで使用する方法の構文は次のとおりです。
```
ALTER SYSTEM SET metadata_security=[true|t|on|false|f|off];
```
メタデータセキュリティを有効にすると、必要なアクセス許可を持つすべてのユーザーが、アクセス権を持つオブジェクトの関連メタデータを表示できます。特定のユーザーだけがメタデータセキュリティを表示できるようにするには、`ACCESS CATALOG` アクセス許可をロールに付与し、そのロールをそのユーザーに割り当てます。ロールを使用してセキュリティコントロールを改善する方法の詳細については、「[ロールベースのアクセスコントロール](https://docs.aws.amazon.com/redshift/latest/dg/t_Roles.html)」を参照してください。
次の例は、ロールに `ACCESS CATALOG` アクセス許可を付与し、そのロールをユーザーに割り当てる方法を示しています。アクセス許可の付与の詳細については、[GRANT](https://docs.aws.amazon.com/redshift/latest/dg/r_GRANT.html) コマンドを参照してください。
```
CREATE ROLE sample_metadata_viewer;
GRANT ACCESS CATALOG TO ROLE sample_metadata_viewer;
GRANT ROLE sample_metadata_viewer to salesadmin;
```
すでに定義されているロールを使用する場合は、[システム定義ロール](https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html) `operator`、`secadmin`、`dba`、および `superuser` のすべてに、オブジェクトメタデータを表示するために必要なアクセス許可が付与されます。デフォルトでは、スーパーユーザーはカタログ全体を表示できます。
```
GRANT ROLE operator to sample_user;
```
ロールを使用してメタデータセキュリティをコントロールしている場合、ロールベースのアクセスコントロールに付属するすべてのシステムビューと機能にアクセスできます。例えば、[SVV\$1ROLES](https://docs.aws.amazon.com/redshift/latest/dg/r_SVV_ROLES.html) ビューをクエリして、すべてのロールを表示できます。ユーザーがロールまたはグループのメンバーかどうかを確認するには、[USER\$1IS\$1MEMBER\$1OF](https://docs.aws.amazon.com/redshift/latest/dg/r_USER_IS_MEMBER_OF.html) 関数を使用します。SVV ビューの完全なリストについては、「[SVV メタデータビュー](https://docs.aws.amazon.com/redshift/latest/dg/svv_views.html)」を参照してください。システム情報関数の一覧については、「[システム情報関数](https://docs.aws.amazon.com/redshift/latest/dg/r_System_information_functions.html)」を参照してください。
# 動的データマスキング
**注記**
Amazon Redshift は、データカタログビューに対して行われたクエリに関する情報をログに記録する際に、特定のシステムテーブル列を自動的にマスクして、機密性の高いメタデータの公開を防ぎます。詳細については、「*Amazon Redshift 管理ガイド*」の「[Secure logging](https://docs.aws.amazon.com/redshift/latest/mgmt/db-auditing-secure-logging.html)」を参照してください。
Amazon Redshift の動的データマスキング (DDM) を使用すると、データウェアハウス内の機密データを保護できます。Amazon Redshift が機密データをクエリ時にユーザーに表示する方法を、データベースで変換せずに操作できます。特定のユーザーまたはロールにカスタムの難読化ルールを適用するマスキングポリシーを通じて、データへのアクセスを制御します。これにより、基になるデータを変更したり、SQL クエリを編集したりすることなく、プライバシー要件の変更に対応できます。
動的データマスキングポリシーは、特定の形式に一致するデータを隠したり、難読化したり、仮名化したりします。テーブルにアタッチされると、その 1 つ以上の列にマスキング式が適用されます。さらにマスキングポリシーを変更して、特定のユーザーのみに適用したり、[ロールベースのアクセスコントロール (RBAC)](t_Roles.md) で作成できるユーザー定義のロールにのみ適用したりできます。さらに、マスキングポリシーを作成するときに条件列を使用してセルレベルで DDM を適用できます。条件付きマスキングの詳細については、「[条件付き動的データマスキング](t_ddm-conditional.md)」を参照してください。
難読化レベルの異なる複数のマスキングポリシーをテーブル内の同じ列に適用し、それらを異なるロールに割り当てることができます。1 つの列に異なるポリシーが異なるロールに適用されている場合に競合が発生しないように、アプリケーションごとに優先順位を設定できます。これにより、特定のユーザーまたはロールがどのデータにアクセスできるかを制御できます。DDM ポリシーでは、SQL や Python で記述されたユーザー定義関数、または AWS Lambda を使用して、データを部分的または完全に編集したり、データをハッシュしたりできます。ハッシュを使用してデータをマスキングすることで、機密情報にアクセスせずに、このデータに結合を適用できます。
# 動的データマスキングポリシーを管理するための SQL コマンド
次のアクションを実行して、動的データマスキングポリシーの作成、アタッチ、デタッチ、削除を行うことができます。
+ DDM ポリシーを作成するには、[CREATE MASKING POLICY](r_CREATE_MASKING_POLICY.md) コマンドを使用します。
以下は、SHA-2 ハッシュ関数を使用してマスキングポリシーを作成する例です。
```
CREATE MASKING POLICY hash_credit
WITH (credit_card varchar(256))
USING (sha2(credit_card + 'testSalt', 256));
```
+ 既存の DDM ポリシーを変更するには、[ALTER MASKING POLICY](r_ALTER_MASKING_POLICY.md) コマンドを使用します。
次に示すのは、既存のマスキングポリシーを変更する例です。
```
ALTER MASKING POLICY hash_credit
USING (sha2(credit_card + 'otherTestSalt', 256));
```
+ DDM ポリシーをテーブルで 1 つ以上のユーザーまたはロールにアタッチするには、[ATTACH MASKING POLICY](r_ATTACH_MASKING_POLICY.md) コマンドを実行します。
次に示すのは、マスキングポリシーを列とロールのペアにアタッチする例です。
```
ATTACH MASKING POLICY hash_credit
ON credit_cards (credit_card)
TO ROLE science_role
PRIORITY 30;
```
PRIORITY 句は、同じ列に複数のポリシーがアタッチされている場合に、どのマスキングポリシーをユーザーセッションに適用するかを決定します。例えば、前の例のユーザーが、同じクレジットカード列に優先度が 20 の別のマスキングポリシーをアタッチしている場合、science\$1role のポリシーが適用されます。優先度が 30 と高いためです。
+ DDM ポリシーをテーブルで 1 つ以上のユーザーまたはロールからデタッチするには、[DETACH MASKING POLICY](r_DETACH_MASKING_POLICY.md) コマンドを実行します。
以下は、列/ロールペアからマスキングポリシーをデタッチする例です。
```
DETACH MASKING POLICY hash_credit
ON credit_cards(credit_card)
FROM ROLE science_role;
```
+ DDM ポリシーをすべてのデータベースから削除するには、[DROP MASKING POLICY](r_DROP_MASKING_POLICY.md) コマンドを使用します。
以下は、すべてのデータベースからマスキングポリシーを削除する例です。
```
DROP MASKING POLICY hash_credit;
```
# 動的データマスキングポリシー階層
複数のマスキングポリシーをアタッチする場合は、以下を考慮します。
+ 複数のマスキングポリシーを 1 つの列にアタッチできます。
+ 複数のマスキングポリシーがクエリに適用される場合、それぞれの列にアタッチされている最も優先度の高いポリシーが適用されます。次の例を考えます。
```
ATTACH MASKING POLICY partial_hash
ON credit_cards(address, credit_card)
TO ROLE analytics_role
PRIORITY 20;
ATTACH MASKING POLICY full_hash
ON credit_cards(credit_card, ssn)
TO ROLE auditor_role
PRIORITY 30;
SELECT address, credit_card, ssn
FROM credit_cards;
```
SELECT ステートメントを実行すると、分析と監査の両方のロールを持つユーザーには、`partial_hash` マスキングポリシーが適用されたアドレス列が表示されます。クレジットカード列では `full_hash` ポリシーの優先度が高いため、`full_hash` マスキングポリシーが適用されたクレジットカード列と SSN 列が表示されます。
+ マスキングポリシーをアタッチするときに優先度を指定しない場合、デフォルトの優先度は 0 です。
+ 同じ列に 2 つのポリシーを同じ優先度でアタッチすることはできません。
+ ユーザーと列、またはロールと列の同じ組み合わせに 2 つのポリシーをアタッチすることはできません。
+ 同じユーザーまたはロールにアタッチされているときに、同じ SUPER パスに複数のマスキングポリシーが適用される場合、最も優先順位の高いアタッチメントのみが有効になります。次に挙げるサンプルを参考にしてください。
最初の例は、同じパスに 2 つのマスキングポリシーがアタッチされ、優先順位の高いポリシーが有効になっていることを示しています。
```
ATTACH MASKING POLICY hide_name
ON employees(col_person.name)
TO PUBLIC
PRIORITY 20;
ATTACH MASKING POLICY hide_last_name
ON employees(col_person.name.last)
TO PUBLIC
PRIORITY 30;
--Only the hide_last_name policy takes effect.
SELECT employees.col_person.name FROM employees;
```
2 つ目の例は、同じ SUPER オブジェクト内の異なるパスに 2 つのマスキングポリシーがアタッチされているため、ポリシー間で競合が発生していないことを示しています。両方のアタッチメントが同時に適用されます。
```
ATTACH MASKING POLICY hide_first_name
ON employees(col_person.name.first)
TO PUBLIC
PRIORITY 20;
ATTACH MASKING POLICY hide_last_name
ON employees(col_person.name.last)
TO PUBLIC
PRIORITY 20;
--Both col_person.name.first and col_person.name.last are masked.
SELECT employees.col_person.name FROM employees;
```
特定のユーザーと列またはロールと列の組み合わせにどのマスキングポリシーが適用されるかを確認するには、[https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html](https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html) ロールを持つユーザーが、[SVV\$1ATTACHED\$1MASKING\$1POLICY](r_SVV_ATTACHED_MASKING_POLICY.md) システムビューで列/ロールまたは列/ユーザーのペアを検索できます。詳細については、「[動的データマスキングのシステムビュー](r_ddm-svv.md)」を参照してください。
# SUPER データタイプパスでの動的データマスキングの使用
Amazon Redshift は、SUPER タイプ列のパスへの動的データマスキングポリシーのアタッチをサポートしています。SUPER データ型の詳細については、[Amazon Redshift の半構造化データ](super-overview.md)を参照してください。
SUPER タイプ列のパスにマスキングポリシーをアタッチするときは、次の点を考慮します。
+ マスキングポリシーを列のパスにアタッチする場合、その列を SUPER データタイプとして定義する必要があります。マスキングポリシーは SUPER パスの*スカラー*値にのみ適用できます。複雑な構造や配列にはマスキングポリシーを適用できません。
+ SUPER パスが競合しない限り、1 つの SUPER 列の複数のスカラー値に異なるマスキングポリシーを適用できます。例えば、スーパーパス `a.b` と `a.b.c` が競合するのは、それらが同じパス上にあるときに、`a.b` が `a.b.c` の親になっているためです。スーパーパス `a.b.c` と `a.b.d` は競合しません。
+ Amazon Redshift で、マスキングポリシーがアタッチするパスがデータに存在して、想定されるタイプであることを確認するには、ユーザーのクエリランタイム時にポリシーが適用される必要があります。例えば、INT 値を含む SUPER パスに TEXT 値をマスキングするマスキングポリシーをアタッチすると、Amazon Redshift はパスで値のタイプをキャストしようとします。
このような状況では、ランタイム時の Amazon Redshift の動作は、SUPER オブジェクトをクエリするための設定によって異なってきます。デフォルトでは、Amazon Redshift は lax モードになっており、指定した SUPER パスに関して欠落したパスや無効なキャストを `NULL` として解決します。SUPER 関連の設定の詳細については、「[SUPER 設定](super-configurations.md)」を参照してください。
+ SUPER はスキーマレスタイプです。つまり、Amazon Redshift は特定の SUPER パスに値が存在することを確認できません。存在しない SUPER パスにマスキングポリシーをアタッチし、Amazon Redshift が lax モードの場合、Amazon Redshift はパスを `NULL` 値に解決します。SUPER 列のパスにマスキングポリシーをアタッチするときは、SUPER オブジェクトの予想される形式と、それらに予期しない属性が含まれる可能性を考慮することをお勧めします。SUPER 列に予期しないスキーマがあると思われる場合は、マスキングポリシーを SUPER 列に直接アタッチすることを検討します。SUPER タイプ情報関数を使用して属性とタイプをチェックしたり、`OBJECT_TRANSFORM` を使用して値をマスクしたりできます。SUPER タイプ情報関数の詳細については、「[SUPER 型の情報関数](c_Type_Info_Functions.md)」を参照してください。
## 例
**SUPER パスにマスキングポリシーをアタッチする**
次の例では、1 列の複数の SUPER タイプパスに複数のマスキングポリシーをアタッチします。
```
CREATE TABLE employees (
col_person SUPER
);
INSERT INTO employees
VALUES
(
json_parse('
{
"name": {
"first": "John",
"last": "Doe"
},
"age": 25,
"ssn": "111-22-3333",
"company": "Company Inc."
}
')
),
(
json_parse('
{
"name": {
"first": "Jane",
"last": "Appleseed"
},
"age": 34,
"ssn": "444-55-7777",
"company": "Organization Org."
}
')
)
;
GRANT ALL ON ALL TABLES IN SCHEMA "public" TO PUBLIC;
-- Create the masking policies.
-- This policy converts the given name to all uppercase letters.
CREATE MASKING POLICY mask_first_name
WITH(first_name TEXT)
USING ( UPPER(first_name) );
-- This policy replaces the given name with the fixed string 'XXXX'.
CREATE MASKING POLICY mask_last_name
WITH(last_name TEXT)
USING ( 'XXXX'::TEXT );
-- This policy rounds down the given age to the nearest 10.
CREATE MASKING POLICY mask_age
WITH(age INT)
USING ( (FLOOR(age::FLOAT / 10) * 10)::INT );
-- This policy converts the first five digits of the given SSN to 'XXX-XX'.
CREATE MASKING POLICY mask_ssn
WITH(ssn TEXT)
USING ( 'XXX-XX-'::TEXT || SUBSTRING(ssn::TEXT FROM 8 FOR 4) );
-- Attach the masking policies to the employees table.
ATTACH MASKING POLICY mask_first_name
ON employees(col_person.name.first)
TO PUBLIC;
ATTACH MASKING POLICY mask_last_name
ON employees(col_person.name.last)
TO PUBLIC;
ATTACH MASKING POLICY mask_age
ON employees(col_person.age)
TO PUBLIC;
ATTACH MASKING POLICY mask_ssn
ON employees(col_person.ssn)
TO PUBLIC;
-- Verify that your masking policies are attached.
SELECT
policy_name,
TABLE_NAME,
priority,
input_columns,
output_columns
FROM
svv_attached_masking_policy;
policy_name | table_name | priority | input_columns | output_columns
-----------------+------------+----------+-----------------------------------+-----------------------------------
mask_age | employees | 0 | ["col_person.\"age\""] | ["col_person.\"age\""]
mask_first_name | employees | 0 | ["col_person.\"name\".\"first\""] | ["col_person.\"name\".\"first\""]
mask_last_name | employees | 0 | ["col_person.\"name\".\"last\""] | ["col_person.\"name\".\"last\""]
mask_ssn | employees | 0 | ["col_person.\"ssn\""] | ["col_person.\"ssn\""]
(4 rows)
-- Observe the masking policies taking effect.
SELECT col_person FROM employees ORDER BY col_person.age;
-- This result is formatted for ease of reading.
col_person
--------------------------------
{
"name": {
"first": "JOHN",
"last": "XXXX"
},
"age": 20,
"ssn": "XXX-XX-3333",
"company": "Company Inc."
}
{
"name": {
"first": "JANE",
"last": "XXXX"
},
"age": 30,
"ssn": "XXX-XX-7777",
"company": "Organization Org."
}
```
SUPER パスに無効なマスキングポリシーをアタッチする例を以下に示します。
```
-- This attachment fails because there is already a policy
-- with equal priority attached to employees.name.last, which is
-- on the same SUPER path as employees.name.
ATTACH MASKING POLICY mask_ssn
ON employees(col_person.name)
TO PUBLIC;
ERROR: DDM policy "mask_last_name" is already attached on relation "employees" column "col_person."name"."last"" with same priority
-- Create a masking policy that masks DATETIME objects.
CREATE MASKING POLICY mask_date
WITH(INPUT DATETIME)
USING ( INPUT );
-- This attachment fails because SUPER type columns can't contain DATETIME objects.
ATTACH MASKING POLICY mask_date
ON employees(col_person.company)
TO PUBLIC;
ERROR: cannot attach masking policy for output of type "timestamp without time zone" to column "col_person."company"" of type "super
```
次に示すのは、存在しないスーパーパスにマスキングポリシーをアタッチする例です。デフォルトでは、Amazon Redshift は `NULL` へのパスを解決します。
```
ATTACH MASKING POLICY mask_first_name
ON employees(col_person.not_exists)
TO PUBLIC;
SELECT col_person FROM employees LIMIT 1;
-- This result is formatted for ease of reading.
col_person
-----------------------------------
{
"name": {
"first": "JOHN",
"last": "XXXX"
},
"age": 20,
"ssn": "XXX-XX-3333",
"company": "Company Inc.",
"not_exists": null
}
```
# 条件付き動的データマスキング
マスキング式に条件式を含むマスキングポリシーを作成することで、セルレベルでデータをマスクできます。例えば、その行の別の列の値に応じて、値に異なるマスクを適用するマスキングポリシーを作成できます。
以下は、条件付きデータマスキングを使用して、詐欺に巻き込まれたクレジットカード番号を部分的に編集し、他のすべてのクレジットカード番号を完全に隠すマスキングポリシーを作成してアタッチする例です。この例を実行するには、スーパーユーザーであるか、[https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html](https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html) ロールを持っている必要があります。
```
--Create an analyst role.
CREATE ROLE analyst;
--Create a credit card table. The table contains an is_fraud boolean column,
--which is TRUE if the credit card number in that row was involved in a fraudulent transaction.
CREATE TABLE credit_cards (id INT, is_fraud BOOLEAN, credit_card_number VARCHAR(16));
--Create a function that partially redacts credit card numbers.
CREATE FUNCTION REDACT_CREDIT_CARD (credit_card VARCHAR(16))
RETURNS VARCHAR(16) IMMUTABLE
AS $$
import re
regexp = re.compile("^([0-9]{6})[0-9]{5,6}([0-9]{4})")
match = regexp.search(credit_card)
if match != None:
first = match.group(1)
last = match.group(2)
else:
first = "000000"
last = "0000"
return "{}XXXXX{}".format(first, last)
$$ LANGUAGE plpythonu;
--Create a masking policy that partially redacts credit card numbers if the is_fraud value for that row is TRUE,
--and otherwise blanks out the credit card number completely.
CREATE MASKING POLICY card_number_conditional_mask
WITH (fraudulent BOOLEAN, pan varchar(16))
USING (CASE WHEN fraudulent THEN REDACT_CREDIT_CARD(pan)
ELSE Null
END);
--Attach the masking policy to the credit_cards/analyst table/role pair.
ATTACH MASKING POLICY card_number_conditional_mask ON credit_cards (credit_card_number)
USING (is_fraud, credit_card_number)
TO ROLE analyst PRIORITY 100;
```
# 動的データマスキングのシステムビュー
スーパーユーザー、`sys:operator` ロールを持つユーザー、ACCESS SYSTEM TABLE アクセス許可を持つユーザーは、次の DDM 関連のシステムビューにアクセスできます。
+ [SVV\$1MASKING\$1POLICY](r_SVV_MASKING_POLICY.md)
SVV\$1MASKING\$1POLICY では、クラスターまたはワークグループで作成されたすべてのマスキングポリシーを表示できます。
+ [SVV\$1ATTACHED\$1MASKING\$1POLICY](r_SVV_ATTACHED_MASKING_POLICY.md)
SVV\$1ATTACHED\$1MASKING\$1POLICY では、現在接続されているデータベースにポリシーがアタッチされているすべてのリレーションとユーザーまたはロールを表示できます。
+ [SYS\$1APPLIED\$1MASKING\$1POLICY\$1LOG](SYS_APPLIED_MASKING_POLICY_LOG.md)
SYS\$1APPLIED\$1MASKING\$1POLICY\$1LOG では、DDM で保護されたリレーションを参照するクエリに対するマスキングポリシーの適用をトレースできます。
以下に、システムビューを使用して確認できる情報の例を示します。
```
--Select all policies associated with specific users, as opposed to roles
SELECT policy_name,
schema_name,
table_name,
grantee
FROM svv_attached_masking_policy
WHERE grantee_type = 'user';
--Select all policies attached to a specific user
SELECT policy_name,
schema_name,
table_name,
grantee
FROM svv_attached_masking_policy
WHERE grantee = 'target_grantee_name'
--Select all policies attached to a given table
SELECT policy_name,
schema_name,
table_name,
grantee
FROM svv_attached_masking_policy
WHERE table_name = 'target_table_name'
AND schema_name = 'target_schema_name';
--Select the highest priority policy attachment for a given role
SELECT samp.policy_name,
samp.priority,
samp.grantee,
smp.policy_expression
FROM svv_masking_policy AS smp
JOIN svv_attached_masking_policy AS samp
ON samp.policy_name = smp.policy_name
WHERE
samp.grantee_type = 'role' AND
samp.policy_name = mask_get_policy_for_role_on_column(
'target_schema_name',
'target_table_name',
'target_column_name',
'target_role_name')
ORDER BY samp.priority desc
LIMIT 1;
--See which policy a specific user will see on a specific column in a given relation
SELECT samp.policy_name,
samp.priority,
samp.grantee,
smp.policy_expression
FROM svv_masking_policy AS smp
JOIN svv_attached_masking_policy AS samp
ON samp.policy_name = smp.policy_name
WHERE
samp.grantee_type = 'role' AND
samp.policy_name = mask_get_policy_for_user_on_column(
'target_schema_name',
'target_table_name',
'target_column_name',
'target_user_name')
ORDER BY samp.priority desc;
--Select all policies attached to a given relation.
SELECT policy_name,
schema_name,
relation_name,
database_name
FROM sys_applied_masking_policy_log
WHERE relation_name = 'relation_name'
AND schema_name = 'schema_name';
```
# 動的なデータマスキングを使用する際の考慮事項
動的なデータマスキングを使用する場合は、以下を考慮してください。
+ ビューなど、テーブルから作成されたオブジェクトをクエリすると、オブジェクトを作成したユーザーのポリシーではなく、クエリを実行するユーザーのマスキングポリシーに基づいて結果が表示されます。例えば、アナリストロールを持つユーザーが secadmin によって作成されたビューをクエリすると、アナリストロールにアタッチされたマスキングポリシーを使用して結果が表示されます。
+ EXPLAIN コマンドによって機密性の高いマスキングポリシーフィルターが公開されるのを防ぐために、SYS\$1EXPLAIN \$1DDM のアクセス許可を持つユーザーのみが EXPLAIN 出力に適用されたマスキングポリシーを確認できます。デフォルトでは、ユーザーには SYS\$1EXPLAIN\$1DDM のアクセス許可がありません。
ロールにアクセス許可を付与するための構文は、次のとおりです。
```
GRANT EXPLAIN MASKING TO ROLE rolename
```
EXPLAIN コマンドの詳細については、「[EXPLAIN](r_EXPLAIN.md)」を参照してください。
+ ロールが異なるユーザーには、使用したフィルター条件または結合条件に基づいて異なる結果が表示されます。例えば、特定の列値を使用するテーブルで SELECT コマンドを実行する際、コマンドを実行するユーザーにその列を難読化するマスキングポリシーが適用されている場合、失敗します。
+ DDM ポリシーは、前提となる操作や述語よりも先に適用する必要があります。マスキングポリシーには以下が含まれる場合があります。
+ 値を NULL に変換するなどの低コストの定数演算
+ HMAC ハッシュなどの中コストのオペレーション
+ 外部の Lambda ユーザー定義関数への呼び出しなどの高コストの操作
そのため、可能な限り、単純なマスキング式を使用することをお勧めします。
+ 行レベルのセキュリティポリシーを持つロールには DDM ポリシーを使用できますが、RLS ポリシーは DDM の前に適用されることに注意してください。動的データマスキング式は、RLS で保護された行を読み取ることができません。RLS の詳細については、「[行レベルのセキュリティ](t_rls.md)」を参照してください。
+ [COPY](r_COPY.md) コマンドを使用してパーケットから保護されているターゲットテーブルにコピーするときには、COPY ステートメントで列を明示的に指定する必要があります。COPY による列のマッピングの詳細については、「[列のマッピングオプション](copy-parameters-column-mapping.md)」を参照してください。
+ DDM ポリシーは、次の関係にアタッチできません。
+ システムテーブルとカタログ
+ 外部テーブル
+ データ共有テーブル
+ データベース間の関係
+ 一時テーブル
+ 相関クエリ
+ DDM ポリシーにはルックアップテーブルを含めることができます。USING 句にはルックアップテーブルを含めることができます。以下の関係タイプはルックアップテーブルとして使用できません。
+ システムテーブルとカタログ
+ 外部テーブル
+ データ共有テーブル
+ ビュー、マテリアライズドビュー、遅延バインディングビュー
+ データベース間の関係
+ 一時テーブル
+ 相関クエリ
次に示すのは、マスキングポリシーをルックアップテーブルにアタッチする例です。
```
--Create a masking policy referencing a lookup table
CREATE MASKING POLICY lookup_mask_credit_card WITH (credit_card TEXT) USING (
CASE
WHEN
credit_card IN (SELECT credit_card_lookup FROM credit_cards_lookup)
THEN '000000XXXX0000'
ELSE REDACT_CREDIT_CARD(credit_card)
END
);
--Provides access to the lookup table via a policy attached to a role
GRANT SELECT ON TABLE credit_cards_lookup TO MASKING POLICY lookup_mask_credit_card;
```
+ ターゲット列のタイプとサイズと互換性のない出力を生成するようなマスキングポリシーをアタッチすることはできません。例えば、12 文字の文字列を VARCHAR(10) 列に出力するマスキングポリシーをアタッチすることはできません。Amazon Redshift では、次の例外がサポートされます。
+ 入力タイプ INTN のマスキングポリシーは、M < N であればサイズ INTM のポリシーにアタッチできます。例えば、BIGINT (INT8) 入力ポリシーを smallint (INT4) 列にアタッチできます。
+ 入力タイプが NUMERIC または DECIMAL のマスキングポリシーは、常に FLOAT 列にアタッチできます。
+ DDM ポリシーは、データ共有では使用できません。データ共有のデータプロデューサーがデータ共有内のテーブルに DDM ポリシーをアタッチすると、テーブルをクエリしようとしているデータコンシューマーのユーザーはテーブルにアクセスできなくなります。リレーションをデータ共有に追加しようとすると、プロデューサー側のクラスターまたは名前空間で失敗し、次のエラーが発生します。
```
or a relation dependent on it is protected by a masking policy and cannot be added to a datashare
```
プロデューサー側でリレーションにマスキングポリシーをアタッチし、そのリレーションが既にデータ共有に含まれている場合、コンシューマー側でそのリレーションに対してクエリを実行しようとすると失敗し、次のエラーが発生します。
```
cross-cluster query of the masked relation is not supported.
```
データ共有の DDM は、ALTER TABLE コマンドで MASKING OFF FOR DATASHARES パラメータを使用してオフにできます。詳細については、「[ALTER TABLE](r_ALTER_TABLE.md)」を参照してください。
+ 以下の設定オプションのいずれかの値がセッションのデフォルト値と一致しない場合、DDM ポリシーがアタッチされているリレーションをクエリすることはできません。
+ `enable_case_sensitive_super_attribute`
+ `enable_case_sensitive_identifier`
+ `downcase_delimited_identifier`
DDM ポリシーがアタッチされているリレーションをクエリしようとして、「DDM で保護されたリレーションは、大文字と小文字の区別がデフォルト値と異なるため、セッションレベルの設定をサポートしていません」というメッセージが表示される場合は、セッションの設定オプションをリセットすることを検討してください。
+ プロビジョニングされたクラスターまたはサーバーレス名前空間にデータマスキングポリシーが適用されている場合、以下のコマンドは標準ユーザーにはブロックされます。
```
ALTER SET enable_case_sensitive_super_attribute/enable_case_sensitive_identifier/downcase_delimited_identifier
```
DDM ポリシーを作成するときは、ポリシー作成時のセッションの設定オプション設定と一致するように、標準ユーザーのデフォルト設定オプション設定を変更することをお勧めします。スーパーユーザーと ALTER USER 権限を持つユーザーは、パラメータグループ設定または ALTER USER コマンドを使用して、この操作を行うことができます。パラメータグループの詳細については、「*Amazon Redshift 管理ガイド*」の「[Amazon Redshift パラメータグループ](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-parameter-groups.html)」を参照してください。ALTER USER コマンドの詳細については、「[ALTER USER](r_ALTER_USER.md)」を参照してください。
+ DDM ポリシーがアタッチされたビューや遅延バインディングビューは、通常のユーザーが [CREATE VIEW](r_CREATE_VIEW.md) コマンドを使用して置き換えることはできません。ビューまたは LBV を DDM ポリシーに置き換えるには、まず、それらにアタッチされている DDM ポリシーをすべてデタッチし、ビューまたは LBV を置き換えてから、ポリシーを再アタッチします。スーパーユーザーと `sys:secadmin` アクセス許可を持っているユーザーは、ポリシーをデタッチすることなく、DDM ポリシーが設定されたビューまたは LBV で CREATE VIEW を使用できます。
+ DDM ポリシーがアタッチされたビューは、システムテーブルとビューを参照できません。遅延バインディングビューは、システムテーブルとビューを参照できます。
+ DDM ポリシーがアタッチされた遅延バインディングビューは、JSON ドキュメントなどのデータレイク内のネストされたデータを参照できません。
+ 遅延バインディングビューがいずれかのビューから参照されている場合、その遅延バインディングビューには DDM ポリシーをアタッチできません。
+ 遅延バインディングビューにアタッチされた DDM ポリシーは、列名でアタッチされます。クエリ時に、Amazon Redshift は、遅延バインディングビューにアタッチされたすべてのマスキングポリシーが正常に適用されていること、および遅延バインディングビューの出力列タイプがアタッチされたマスキングポリシーのタイプと一致することを検証します。検証が失敗した場合、Amazon Redshift はクエリのエラーを返します。
+ DDM ポリシーの作成する際に、カスタマイズされたセッションコンテキスト変数を使用できます。次の例では、セッションコンテキスト変数を設定します。
```
-- Set a customized context variable.
SELECT set_config('app.city', 'XXXX', FALSE);
-- Create a MASKING policy using current_setting() to get the value of a customized context variable.
CREATE MASKING POLICY city_mask
WITH (city VARCHAR(30))
USING (current_setting('app.city')::VARCHAR(30));
-- Attach the policy on the target table to one or more roles.
ATTACH MASKING POLICY city_mask
ON tickit_users_redshift(city)
TO ROLE analyst, ROLE dbadmin;
```
カスタマイズされたセッションコンテキスト変数の設定と取得の詳細については、「[SET](r_SET.md)」、「[SET\$1CONFIG](r_SET_CONFIG.md)」、「[SHOW](r_SHOW.md)」、「[CURRENT\$1SETTING](r_CURRENT_SETTING.md)」、「[RESET](r_RESET.md)」を参照してください。サーバー設定変更全般の詳細については、「[サーバー設定の変更](cm_chap_ConfigurationRef.md#t_Modifying_the_default_settings)」を参照してください。
**重要**
DDM ポリシー内でセッションコンテキスト変数を使用する場合、セキュリティポリシーは、ポリシーを呼び出すユーザーまたはロールに依存します。DDM ポリシーでセッションコンテキスト変数を使用する場合は、セキュリティの脆弱性を避けるように注意してください。
# 動的データマスキングのエンドツーエンドの例
次の内容は、マスキングポリシーを作成して列にアタッチする方法を示すエンドツーエンドの例です。これらのポリシーにより、ユーザーは各自のロールに割り当てられているポリシーの難読化の度合いに応じて、列にアクセスしてさまざまな値を確認できます。この例を実行するには、スーパーユーザーであるか、[https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html](https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html) ロールを持っている必要があります。
## マスキングポリシーの作成
まず、テーブルを作成し、クレジットカードの値を入力します。
```
--create the table
CREATE TABLE credit_cards (
customer_id INT,
credit_card TEXT
);
--populate the table with sample values
INSERT INTO credit_cards
VALUES
(100, '4532993817514842'),
(100, '4716002041425888'),
(102, '5243112427642649'),
(102, '6011720771834675'),
(102, '6011378662059710'),
(103, '373611968625635')
;
--run GRANT to grant permission to use the SELECT statement on the table
GRANT SELECT ON credit_cards TO PUBLIC;
--create two users
CREATE USER regular_user WITH PASSWORD '1234Test!';
CREATE USER analytics_user WITH PASSWORD '1234Test!';
--create the analytics_role role and grant it to analytics_user
--regular_user does not have a role
CREATE ROLE analytics_role;
GRANT ROLE analytics_role TO analytics_user;
```
次に、分析ロールに適用するマスキングポリシーを作成します。
```
--create a masking policy that fully masks the credit card number
CREATE MASKING POLICY mask_credit_card_full
WITH (credit_card VARCHAR(256))
USING ('000000XXXX0000'::TEXT);
--create a user-defined function that partially obfuscates credit card data
CREATE FUNCTION REDACT_CREDIT_CARD (credit_card TEXT)
RETURNS TEXT IMMUTABLE
AS $$
import re
regexp = re.compile("^([0-9]{6})[0-9]{5,6}([0-9]{4})")
match = regexp.search(credit_card)
if match != None:
first = match.group(1)
last = match.group(2)
else:
first = "000000"
last = "0000"
return "{}XXXXX{}".format(first, last)
$$ LANGUAGE plpythonu;
--create a masking policy that applies the REDACT_CREDIT_CARD function
CREATE MASKING POLICY mask_credit_card_partial
WITH (credit_card VARCHAR(256))
USING (REDACT_CREDIT_CARD(credit_card));
--confirm the masking policies using the associated system views
SELECT * FROM svv_masking_policy;
SELECT * FROM svv_attached_masking_policy;
```
## マスキングポリシーをアタッチする
マスキングポリシーをクレジットカードテーブルにアタッチします。
```
--attach mask_credit_card_full to the credit card table as the default policy
--all users will see this masking policy unless a higher priority masking policy is attached to them or their role
ATTACH MASKING POLICY mask_credit_card_full
ON credit_cards(credit_card)
TO PUBLIC;
--attach mask_credit_card_partial to the analytics role
--users with the analytics role can see partial credit card information
ATTACH MASKING POLICY mask_credit_card_partial
ON credit_cards(credit_card)
TO ROLE analytics_role
PRIORITY 10;
--confirm the masking policies are applied to the table and role in the associated system view
SELECT * FROM svv_attached_masking_policy;
--confirm the full masking policy is in place for normal users by selecting from the credit card table as regular_user
SET SESSION AUTHORIZATION regular_user;
SELECT * FROM credit_cards;
--confirm the partial masking policy is in place for users with the analytics role by selecting from the credit card table as analytics_user
SET SESSION AUTHORIZATION analytics_user;
SELECT * FROM credit_cards;
```
## マスキングポリシーの変更
次のセクションでは、動的データマスキングポリシーを変更する方法について説明します。
```
--reset session authorization to the default
RESET SESSION AUTHORIZATION;
--alter the mask_credit_card_full policy
ALTER MASKING POLICY mask_credit_card_full
USING ('00000000000000'::TEXT);
--confirm the full masking policy is in place after altering the policy, and that results are altered from '000000XXXX0000' to '00000000000000'
SELECT * FROM credit_cards;
```
## マスキングポリシーのデタッチとドロップ
次のセクションでは、テーブルからすべての動的データマスキングポリシーを削除して、マスキングポリシーをデタッチおよびドロップする方法を示します。
```
--reset session authorization to the default
RESET SESSION AUTHORIZATION;
--detach both masking policies from the credit_cards table
DETACH MASKING POLICY mask_credit_card_full
ON credit_cards(credit_card)
FROM PUBLIC;
DETACH MASKING POLICY mask_credit_card_partial
ON credit_cards(credit_card)
FROM ROLE analytics_role;
--drop both masking policies
DROP MASKING POLICY mask_credit_card_full;
DROP MASKING POLICY mask_credit_card_partial;
```
# スコープ設定アクセス許可
スコープ設定アクセス許可を使用すると、データベースまたはスキーマ内の特定タイプのすべてのオブジェクトに対するアクセス許可をユーザーまたはロールに付与できます。スコープ設定アクセス許可を持つユーザーやロールは、データベースまたはスキーマ内の現在および将来のすべてのオブジェクトに対して指定されたアクセス許可を持ちます。
データベースレベルのスコープ付きアクセス許可の範囲は、[SVV\$1DATABASE\$1PRIVILEGES](r_SVV_DATABASE_PRIVILEGES.md) で確認できます。スキーマレベルのスコープ付きアクセス許可の範囲は、[SVV\$1SCHEMA\$1PRIVILEGES](r_SVV_SCHEMA_PRIVILEGES.md) で確認できます。
スコープ設定アクセス許可の適用について詳しくは、「[GRANT](r_GRANT.md)」と「[REVOKE](r_REVOKE.md)」を参照してください。
# スコープ設定アクセス許可の使用に関する考慮事項
スコープ設定アクセス許可を使用する場合は、次の事項を考慮します。
+ スコープ設定アクセス許可を使用して、データベーススコープまたはスキーマスコープへのアクセス許可を、指定したユーザーまたはロールに対して付与したり、取り消したりすることができます。
+ スコープ設定アクセス許可をユーザーグループに付与することはできません。
+ スコープ設定アクセス許可の付与または取り消しによって、スコープ内の現在および今後のすべてのオブジェクトに対するアクセス許可が変更されます。
+ スコープ設定アクセス許可とオブジェクトレベルのアクセス許可は互いに無関係に動作します。例えば、次の両方の場合、ユーザーはテーブルに対するアクセス許可を保持します。
+ テーブル schema1.table1 に対する SELECT と schema1 に対する SELECT スコープ設定アクセス許可をユーザーに付与します。次に、スキーマ schema1 内のすべてのテーブルに対する SELECT を取り消します。ユーザーは schema1.table1 に対する SELECT を保持します。
+ テーブル schema1.table1 に対する SELECT と schema1 に対する SELECT スコープ設定アクセス許可をユーザーに付与します。次に、schema1.table1 に対する SELECT を取り消します。ユーザーは schema1.table1 に対する SELECT を保持します。
+ スコープ設定アクセス許可の付与または取り消すのためには、次の条件のうち 1 つを満たす必要があります。
+ スーパーユーザー。
+ そのアクセス許可の GRANT OPTION を持つユーザー。GRANT OPTION の詳細については、[GRANT](r_GRANT.md) の WITH GRANT OPTION パラメータを参照してください。
+ スコープ設定アクセス許可は、接続されているデータベースのオブジェクト、またはデータ共有からインポートされたデータベースに対してのみ付与または取り消しができます。
+ スコープ設定アクセス許可を使用して、データ共有から作成した共有データベースに対するデフォルトのアクセス許可を設定できます。共有データベースに対するスコープ設定アクセス許可を付与されたコンシューマー側のデータ共有ユーザーは、プロデューサー側のデータ共有に新しく追加されたオブジェクトに対してそのアクセス許可を自動的に取得します。
+ プロデューサーは、スキーマ内のオブジェクトに対するスコープ設定アクセス許可をデータ共有に付与できます。(プレビュー)