データ共有の共有
データ共有は、異なる Amazon Redshift のプロビジョニングされたクラスター間またはサーバーレスワークグループでデータを共有する場合にのみ必要です。同じクラスター内で、他のデータベース内のオブジェクトに対して必要なアクセス許可を持っている限り、単純な 3 つの部分からなる表記 database.schema.table を使用して別のデータベースにクエリを実行できます。
Amazon Redshift でのデータ共有に対する許可の管理
プロデューサークラスターの管理者は、共有するデータセットの制御を保持します。新しいオブジェクトをデータ共有に追加したり、データ共有から削除したりできます。複数のコンシューマークラスター、AWSアカウント、または AWS リージョンに対して、データ共有へのアクセス権をまとめて付与または取り消すこともできます。許可が失効すると、コンシューマークラスターは直ちに共有オブジェクトへのアクセス権を失い、それらのオブジェクトは、SVV_DATASHARES の INBUND データ共有の一覧に表示されなくなります。
次の例では、データ共有 salesshare を作成し、スキーマ public を追加して、テーブル public.tickit_sales_redshift を salesshare に追加します。これは、指定したクラスター名前空間に対して salesshare の使用許可も付与します。
CREATE DATASHARE salesshare; ALTER DATASHARE salesshare ADD SCHEMA public; ALTER DATASHARE salesshare ADD TABLE public.tickit_sales_redshift; GRANT USAGE ON DATASHARE salesshare TO NAMESPACE '13b8833d-17c6-4f16-8fe4-1a018f5ed00d';
CREATE DATASHARE の場合、スーパーユーザーとデータベース所有者はデータ共有を作成できます。詳細については、「CREATE DATASHARE」を参照してください。ALTER DATASHARE の場合、追加または削除するデータ共有オブジェクトに対して必要な許可を持つデータ共有の所有者は、データ共有を変更できます。詳細については、ALTER DATASHAREを参照してください。
プロデューサー管理者として、データ共有を削除すると、コンシューマークラスターに一覧表示されなくなります。削除されたデータ共有からコンシューマークラスター上に作成されたデータベースとスキーマリファレンスは、オブジェクトなしで引き続き存在します。コンシューマークラスターの管理者は、これらのデータベースを手動で削除する必要があります。
コンシューマー側では、コンシューマークラスター管理者は、データ共有からデータベースを作成することによって、共有データにアクセスする必要があるユーザーとロールを決定できます。データベースの作成時に選択したオプションに応じて、データベースへのアクセスを次のように制御できます。データ共有からデータセットを作成する方法の詳細については、「CREATE DATABASE」を参照してください。
WITH PERMISSIONS 句を使用せずにデータベースを作成する
管理者は、データベースレベルまたはスキーマレベルでアクセスを制御できます。スキーマレベルでアクセスを制御するには、管理者はデータ共有から作成された Amazon Redshift データベースから外部スキーマを作成する必要があります。
以下の例では、データベースレベルおよびスキーマレベルで、共有されたテーブルにアクセスする許可を付与します。
GRANT USAGE ON DATABASE sales_db TO Bob; CREATE EXTERNAL SCHEMA sales_schema FROM REDSHIFT DATABASE sales_db SCHEMA 'public'; GRANT USAGE ON SCHEMA sales_schema TO ROLE Analyst_role;
アクセスをさらに制限するために、共有オブジェクトの上にビューを作成し、必要なデータのみを公開することができます。その後、これらのビューを使用して、ユーザーとロールへのアクセスを許可できます。
ユーザーがデータベースまたはスキーマへのアクセスを許可されると、そのデータベースまたはスキーマ内のすべての共有オブジェクトにアクセスできるようになります。
WITH PERMISSIONS 句を使用してデータベースを作成する
データベースまたはスキーマの使用権限を付与すると、管理者は、ローカルのデータベースまたはスキーマでアクセス許可を付与するのと同じアクセス許可付与プロセスを使用してアクセス制御を追加できます。個別のオブジェクトのアクセス許可がないと、ユーザーは、USAGE アクセス許可を付与された後でも、データ共有データベースまたはスキーマ内のオブジェクトにアクセスできません。
以下の例では、データベースレベルで、共有されたテーブルにアクセスする許可を付与します。
GRANT USAGE ON DATABASE sales_db TO Bob; GRANT USAGE FOR SCHEMAS IN DATABASE sales_db TO Bob; GRANT SELECT ON sales_db.public.tickit_sales_redshift TO Bob;
データベースまたはスキーマへのアクセス許可が付与された後でも、アクセスを認めるデータベースまたはスキーマ内のすべてのオブジェクトについての関連アクセス許可をユーザーに付与する必要があります。
WITH PERMISSIONS を使用する詳細な共有設定 (プレビュー)
クラスターまたはサーバーレスワークグループによるデータ共有のクエリの有効化
このステップでは、データ共有がアカウント内の別のクラスターまたは Amazon Redshift Serverless 名前空間から送信されているか、別のアカウントから送信され、使用している名前空間に関連付けられていることを前提としています。
コンシューマーデータベースの管理者は、データ共有からデータベースを作成できます。
CREATE DATABASE my_ds_db [WITH PERMISSIONS] FROM DATASHARE my_datashare OF NAMESPACE 'abc123def';WITH PERMISSIONS を使用してデータベースを作成すると、データ共有オブジェクトに対する詳細なアクセス許可をさまざまなユーザーやロールに付与できます。これを行わないと、データ共有データベースの USAGE アクセス許可を付与されたすべてのユーザーとロールに、データ共有データベース内のすべてのオブジェクトに対するすべてのアクセス許可が付与されます。
以下では、Redshift データベースユーザーまたはロールにアクセス許可を付与する方法を示しています。これらのステートメントにローカルデータベースを接続できません。GRANT ステートメントの実行前にデータ共有データベースで USE コマンドを実行すると、これらのステートメントは実行できません。
GRANT USAGE ON DATABASE my_ds_db TO ROLE data_eng; GRANT CREATE, USAGE ON SCHEMA my_ds_db.my_shared_schema TO ROLE data_eng; GRANT ALL ON ALL TABLES IN SCHEMA my_ds_db.my_shared_schema TO ROLE data_eng; GRANT USAGE ON DATABASE my_ds_db TO bi_user; GRANT USAGE ON SCHEMA my_ds_db.my_shared_schema TO bi_user; GRANT SELECT ON my_ds_db.my_shared_schema.table1 TO bi_user;
Amazon Redshift データ共有でのビューの使用
プロデューサークラスターは、通常ビュー、遅延バインディングビュー、マテリアライズドビューを共有できます。通常ビューまたは遅延バインディングビューを共有する場合、ベーステーブルを共有する必要はありません。以下のテーブルは、データ共有でビューがどのようにサポートされるかを示しています。
| ビュー名 | このビューをデータ共有に追加できますか? | コンシューマーは、クラスター全体のデータ共有オブジェクトに対してこのビューを作成できますか? |
|---|---|---|
| 通常ビュー | はい | いいえ |
| 遅延バインドビュー | はい | はい |
| マテリアライズドビュー | はい | はい。ただし、完全に更新した場合に限ります |
次のクエリは、データ共有でサポートされている通常のビューの出力を示しています。定期的なビューの定義については、「CREATE VIEW」を参照してください。
SELECT * FROM tickit_db.public.myevent_regular_vw ORDER BY eventid LIMIT 5; eventid | eventname ----------+------------- 3835 | LeAnn Rimes 3967 | LeAnn Rimes 4856 | LeAnn Rimes 4948 | LeAnn Rimes 5131 | LeAnn Rimes
次のクエリは、データ共有でサポートされている遅延バインディングビューの出力を示しています。遅延バインドビューの定義については、「CREATE VIEW」 を参照してください。
SELECT * FROM tickit_db.public.event_lbv ORDER BY eventid LIMIT 5; eventid | venueid | catid | dateid | eventname | starttime --------+---------+-------+--------+------------------------------+--------------------- 1 | 305 | 8 | 1851 | Gotterdammerung | 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
次のクエリは、データ共有でサポートされているマテリアライズドビューの出力を示しています。マテリアライズドビューの定義については、「CREATE MATERIALIZED VIEW」を参照してください。
SELECT * FROM tickit_db.public.tickets_mv; catgroup | qtysold ----------+--------- Concerts | 195444 Shows | 149905
プロデューサークラスター内のすべてのテナントで共通テーブルを維持できます。tenant_id (account_id または namespace_id) などのディメンション列でフィルタリングされたデータのサブセットをコンシューマークラスターと共有することもできます。これを行うには、これらの ID 列 (current_aws_account = tenant_id など) にフィルターを使用して、ベーステーブルにビューを定義できます。コンシューマー側では、ビューをクエリすると、アカウントに適格な行のみが表示されます。これを行うには、Amazon Redshift コンテキスト関数 current_aws_account および current_namespace を使用できます。
次のクエリは、現在の Amazon Redshift クラスターが存在するアカウントの ID を返します。Amazon Redshift に接続している場合は、このクエリを実行できます。
select current_user, current_aws_account; current_user | current_aws_account -------------+-------------------- dwuser | 111111111111 (1row)
次のクエリは、現在の Amazon Redshift クラスターの名前空間を返します。データベースに接続している場合は、このクエリを実行できます。
select current_user, current_namespace; current_user | current_namespace -------------+-------------------------------------- dwuser | 86b5169f-01dc-4a6f-9fbb-e2e24359e9a8 (1 row)
データ共有内のマテリアライズドビューの増分更新
Amazon Redshift は、ベーステーブルが共有されている場合、コンシューマーデータ共有におけるマテリアライズドビューの増分更新をサポートします。増分更新は、Amazon Redshift が前回の更新後に発生したベーステーブルの変更を特定し、マテリアライズドビューの対応するレコードのみを更新する操作です。この動作の詳細については、「CREATE MATERIALIZED VIEW」を参照してください。
IAM ポリシーを使用したデータ共有 API オペレーションへのアクセスの管理
データ共有 API 操作へのアクセスを制御するには、IAM アクションベースのポリシーを使用します。IAM ポリシーの管理方法については、IAM ユーザーガイド の IAM ポリシーの管理を参照してください。
データ共有 API オペレーションを使用するために必要な許可については、「Amazon Redshift 管理ガイド」の「データ共有 API オペレーションを使用するために必要な許可」を参照してください。
クロスアカウントデータ共有をより安全にするためには、API オペレーションの AuthorizeDataShare および DeauthorizeDataShare で条件付きキー ConsumerIdentifier が使用できます。これを利用することで、どの AWS アカウント が 2 つの API オペレーションを呼び出すことができるのかを明示的に制御できます。
自身のアカウント以外のコンシューマーに対して、データ共有の承認を拒否したり承認を解除したりできます。これを行うには、IAM ポリシー内で AWS アカウント の数を指定します。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Deny", "Action": [ "redshift:AuthorizeDataShare", "redshift:DeauthorizeDataShare" ], "Resource": "*", "Condition": { "StringNotEquals": { "redshift:ConsumerIdentifier": "555555555555" } } } ] }
DataShareArn testshare2 でプロデューサーを許可して、IAM ポリシーの AWS アカウント番号が 111122223333 のコンシューマーと明示的に共有することができます。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "redshift:AuthorizeDataShare", "redshift:DeauthorizeDataShare" ], "Resource": "arn:aws:redshift:us-east-1:666666666666:datashare:af06285e-8a45-4ee9-b598-648c218c8ff1/testshare2", "Condition": { "StringEquals": { "redshift:ConsumerIdentifier": "111122223333" } } } ] }
