Redshift のアクセス制御とデータ共有

のデータには、とは別に、データベースの中の権限 (ユーザー、ロール、GRANT) がかかります。さらに、とで「同じテーブルを見ても、人によって見える行と値が違う」状態を作れます。 DEA では、データベースのユーザー・グループ・ロールへの権限の付与、機密データの見せ分け、による他のクラスター・アカウントへの提供が問われます。

Point

RBAC = Role-Based Access Control の略で、Redshift ではデータベースのロールに権限をまとめて付ける方式です。
RLS = Row-Level Security (行レベルセキュリティ) の略です。
DDM = Dynamic Data Masking (動的データマスキング) の略で、保存された値を変えずにクエリの結果だけを隠します。
Datashare は、データ共有で他のクラスターへ渡す「共有の単位」です。
和訳
- Producer: 提供者
- Consumer: 利用者
- Weblio英和辞書「consumer」

概要

へのアクセスは2段階で制御します。 1段目はで、クラスターやワークグループへの接続、Redshift Data の呼び出しを許可します。2段目はデータベースの中の権限で、スキーマ・テーブル・列・行への操作を許可します。

見るポイント	代表的な判断
職務ごとにまとめて権限を付けたいか	データベースのロール (RBAC) に権限を付け、ユーザーにロールを付与します。
見せる行を利用者で変えたいか	のポリシーを使います。
列の値を隠したり一部だけ見せたりしたいか	のポリシーを使います。
別のクラスターやアカウントへ最新のデータを渡したいか	データ共有を使い、コピーしません。

主要技術

①認証: データベースユーザーと IAM

方式	内容	判断ポイント
データベースユーザーとパスワード	`CREATE USER` で作り、パスワードで接続します。	パスワードはで管理し、ローテーションします。
による	IAM の権限で一時的なデータベースの認証情報を取得して接続します。	パスワードを配布せずに済みます。ユーザーを自動作成し、グループに入れることもできます。の・ODBC ドライバーは IAM での接続に対応しており、既存のツールのまま使えます。
との統合	社員の ID でサインインし、ID プロバイダーのグループを Redshift のロールに対応させます。	人のアクセスを一元管理し、Quick (旧 ) などからも同じ ID で接続できます。
Redshift Data	の API で SQL を実行します。認証はシークレットの ARN か一時的な認証情報で行います。	やから、接続 (ドライバーや接続プール) を管理せずに SQL を実行できます。

②ユーザー・グループ・ロールと GRANT ⚠️ 頻出

単位	内容
ユーザー	接続する主体です。
グループ	ユーザーの集まりです。グループに権限を付けると、所属するユーザー全員に効きます (従来からの方式)。
ロール (RBAC)	権限の集まりです。ユーザーや他のロールに付与でき、入れ子にできます。オブジェクトへの権限に加え、システムの権限 (ユーザーの作成、テーブルの所有権の変更など) も含められます。
システム定義のロール	`sys:dba`、`sys:secadmin`、`sys:operator`、`sys:monitor` などがあり、職務ごとの管理権限をスーパーユーザーなしで渡せます。

CREATE ROLE sales_analyst;
GRANT USAGE ON SCHEMA sales TO ROLE sales_analyst;
GRANT SELECT ON ALL TABLES IN SCHEMA sales TO ROLE sales_analyst;
-- 列レベルの権限: 指定した列だけ読める
GRANT SELECT (order_id, amount, region) ON sales.orders TO ROLE sales_analyst;
GRANT ROLE sales_analyst TO alice;
-- 今後作られるテーブルにも同じ権限を付ける
ALTER DEFAULT PRIVILEGES IN SCHEMA sales GRANT SELECT ON TABLES TO ROLE sales_analyst;

押さえること	内容
スキーマの `USAGE`	テーブルへの `SELECT` があっても、スキーマの `USAGE` がないと参照できません。
既定の権限	`ALTER DEFAULT PRIVILEGES` を設定しないと、新しく作ったテーブルには権限が付きません。既定の権限は「指定したユーザーがこれから作るオブジェクト」に効きます。`FOR USER` を省くと実行した本人が作るものだけが対象なので、のユーザーが作るテーブルなら `FOR USER etl_user` を指定します (他のユーザーの分を指定できるのはスーパーユーザーなどです)。既存のテーブルには効きません。
スコープ付きの権限	`GRANT SELECT FOR TABLES IN SCHEMA sales TO ROLE sales_analyst` のように書くと、作成者を問わず、スキーマの現在と今後のテーブルすべてに権限が付きます。付与先はユーザーかロールです。
列レベルの権限	`GRANT SELECT (列, ...)` で、読める列を限定できます。
	スーパーユーザーを日常の作業に使わず、職務ごとのロールとシステム定義のロールで分けます。

③行レベルセキュリティ (RLS)

RLS ポリシーは、「この利用者にはどの行を返すか」を条件式で決めます。クエリを書く側が WHERE 句を足さなくても、ポリシーが自動で効きます。

CREATE RLS POLICY policy_own_rows
WITH (sales_rep VARCHAR(64))
USING (sales_rep = current_user);   -- 自分が担当する行だけ返す
ATTACH RLS POLICY policy_own_rows ON sales.orders TO ROLE sales_analyst;
ALTER TABLE sales.orders ROW LEVEL SECURITY ON;

押さえること	内容
有効化	テーブルで `ROW LEVEL SECURITY ON` にしてから効きます。
付け先	ポリシーはロールやユーザーに付けます。
性能	ポリシーが別の表 (対応表) を参照すると、その表も読むため遅くなります。単純な条件にします。
列の権限との関係	列レベルの GRANT で見える列を絞り、RLS で見える行を絞る、という組み合わせにします。

地域の担当者に地域の行だけを見せる場合は、利用者と地域の対応表を参照する条件を書きます。ただし対応表の参照は性能に影響します。

④動的データマスキング (DDM) ⚠️ 頻出

DDM は、保存されている値は変えずに、クエリの結果に出る値を利用者ごとに隠します。

機能	内容
マスキングポリシー	列の値をどう変えるか (全部を伏せる、末尾4桁だけ残す、ハッシュ化する) を式で定義します。・の UDF でも書けます。
付け先と優先度	ポリシーをテーブルの列に、ロール・ユーザー・PUBLIC 向けに付けます。複数のポリシーが当たる場合は優先度 (PRIORITY) で決まります。
条件付きマスキング	他の列の値に応じてマスクするか決めます (セルの単位の制御)。
ハッシュ化	ハッシュ化した値なら、元の値を見せずに結合や集計のキーとして使えます。

CREATE MASKING POLICY mask_card
WITH (card_no VARCHAR(16))
USING ('XXXXXXXXXXXX' || SUBSTRING(card_no, 13, 4));
ATTACH MASKING POLICY mask_card ON payments(card_no) TO PUBLIC;
ATTACH MASKING POLICY unmask_card ON payments(card_no) TO ROLE fraud_team PRIORITY 10;

unmask_card は値をそのまま返すポリシーの例です。一般の利用者には末尾4桁だけ、不正対策チームには元の値を見せます。

手段	元データ	見せ分け	向いている場面
列レベルの GRANT	変えない	列ごと見える・見えない	列そのものを見せなくてよい場合
	変えない	同じ列で、人により値の見え方が違う	一部の値 (末尾4桁など) は見せたい場合
ロード前のマスキング ( で変換)	変える	全員が同じマスク済みの値	元の値をに置くこと自体を避けたい場合

データ共有は、提供側 (プロデューサー) のクラスターのデータを、利用側 (コンシューマー) のクラスターやワークグループからコピーせずに読めるようにする機能です。提供側がデータを更新すると、利用側はすぐに最新のデータをトランザクションの一貫性を保って読めます。

項目	内容
共有の単位	データベース、スキーマ、テーブル、ビュー (を含む)、の UDF を datashare に追加します。
範囲	同じアカウント、別アカウント、別へ共有できます。プロビジョンドクラスターと Serverless の間でも共有できます。
対応する種類	RA3 ノードのプロビジョンドクラスターと Serverless が対象です。
別アカウントへの共有の手順	提供側で datashare を作って相手のアカウントを追加し、提供側のアカウントで承認 (authorize) し、利用側のアカウントで関連付け (associate) します。
暗号化	アカウントをまたぐ共有では、提供側と利用側の両方が暗号化されている必要があります (同じキーである必要はありません)。
費用	利用側はクエリの計算と、リージョンをまたぐ場合のデータ転送の費用を払います。提供側はストレージの費用を払います。
書き込み	提供側が `INSERT` や `CREATE` などの書き込み権限を datashare に付けた場合に限り、利用側から書き込めます (マルチウェアハウスの書き込み)。
利用側の権限	利用側では datashare からデータベースを作り、自分のユーザーやロールに改めて権限を付与します。

の重い処理を提供側のクラスターで行い、用のクラスターやワークグループへ共有すると、ワークロードを分離しつつデータの複製を避けられます。

⑥監査のためのログ

ログ	内容	出力先
接続ログ	認証の試行、接続と切断	または Logs
ユーザーログ	ユーザーの作成・変更・削除	S3 または CloudWatch Logs
ユーザーアクティビティログ	実行されたクエリ (有効化の設定が必要)	S3 または CloudWatch Logs
	クラスターの作成や設定変更などの操作	CloudTrail

「誰がどのを実行したか」はの監査ログ、「誰がクラスターの設定を変えたか」は CloudTrail で調べます。

監査ログは既定では無効です。有効にすると接続ログとユーザーログが出力されますが、ユーザーアクティビティログは、さらにパラメータグループの enable_user_activity_logging を true にしないと記録されません (既定は false)。 S3 に出力する場合、の暗号化は (AES-256) だけが使え、S3 Object Lock を有効にしたバケットには出力できません。Redshift Serverless の監査ログは CloudWatch Logs にだけ出力できます。

試験対策

のセキュリティの問題では、「接続できるか ()」と「何が見えるか (データベースの権限)」を分けて考えます。次に、隠したいのが「行」か「列」か「値の一部」かで、RLS、列レベルの GRANT、DDM を選び分けます。

①判断マトリクス

問題文のキーワード	選ぶもの	理由
職務ごとに権限をまとめ、ユーザーへ付与したい	`CREATE ROLE` と `GRANT ROLE` (RBAC)	ロールは入れ子にでき、システムの権限も含められます。
スーパーユーザーを使わずに管理作業を分担したい	システム定義のロール (`sys:dba` など)	必要な管理権限だけを渡せます。
新しく作るテーブルにも自動で権限を付けたい	`ALTER DEFAULT PRIVILEGES`	既定の権限を設定します。
特定の列を一部のユーザーに見せない	列レベルの GRANT	読める列を限定します。
地域の担当者に自地域の行だけ見せる	(RLS)	クエリを変えずに行を絞ります。
カード番号の末尾4桁だけ見せたい	(DDM)	保存値を変えずに結果だけ隠します。
一部のチームだけ元の値を見る	DDM のポリシーを複数付け、優先度で制御	ロールごとに見え方を変えます。
とのワークロードを分け、データの複製を避けたい	データ共有 (同じアカウント)	コピーせず最新のデータを読めます。
別アカウントの部署に最新のデータを使わせたい	データ共有 (、承認と関連付け)	両方を暗号化しておく必要があります。
データを外部の顧客へ有償で提供したい	の datashare	購読した顧客が直接クエリできます。
共有データの権限をで一元管理したい	Lake Formation で管理する datashare	と同じ方式で権限を管理します。
誰がどのを実行したか記録したい	監査ログのユーザーアクティビティログ	クエリの履歴を残します。

②よくある誤答

のポリシーでテーブルの行や列を絞れると考えること。データベースの中の権限は GRANT、RLS、DDM で制御します。
DDM が保存された値を書き換えると考えること。クエリの結果だけを変えます。
データ共有をのコピーと考えること。コピーせず、最新のデータを読みます。
DC2 など古いノードでもデータ共有が使えると考えること。RA3 と Serverless が対象です。
データ共有の計算の費用を提供側が払うと考えること。クエリを実行する利用側が払います。