Amazon Redshift フェデレーテッドアクセス許可でマルチウェアハウスのデータガバナンスを簡素化する

本記事は 2026 年 1 月 5 日に公開された「Simplify multi-warehouse data governance with Amazon Redshift federated permissions」を翻訳したものです。

最新のデータアーキテクチャでは、ワークロードの分離、コスト最適化、パフォーマンスのスケーリングを実現するために、マルチウェアハウス構成がますます採用されています。Amazon Redshift フェデレーテッドアクセス許可は、複数の Redshift ウェアハウス間でのアクセス許可管理を簡素化します。

フェデレーテッドアクセス許可を使用すると、Redshift ウェアハウスの名前空間を AWS Glue Data Catalog に登録し、アカウント内のウェアハウス全体にまたがる統合カタログを作成できます。登録された名前空間はすべてのウェアハウスに自動的にマウントされ、手動設定なしでデータを検出できます。AWS Identity and Access Management (IAM) または AWS IAM Identity Center (IDC) を通じてグローバルアイデンティティを指定し、使い慣れた Redshift SQL コマンドでデータベースオブジェクトに対するアクセス許可を定義できます。アクセス許可はウェアハウスデータと一緒に保存され、どのウェアハウスがクエリを実行しても一貫して適用されます。Redshift 環境全体で統一されたセキュアなアクセス制御モデルが提供されます。

本記事では、データアクセス許可を一度定義するだけで、AWS アカウント内のウェアハウス全体に自動的に適用する方法を紹介します。各ウェアハウスでセキュリティポリシーを再作成する必要がなくなります。

Amazon Redshift フェデレーテッドアクセス許可の主な機能

Amazon Redshift のフェデレーテッドアクセス許可には、以下の主な機能があります。

グローバルアイデンティティ統合 – フェデレーテッドアクセス許可は IAM と IAM Identity Center を使用して、登録されたすべてのウェアハウスでシングルサインオン (SSO) を提供します。ユーザーは既存の ID プロバイダー (IdP) を通じて一度認証するだけで、接続先のウェアハウスに関係なく、グローバルアイデンティティに基づいた一貫したアクセスが可能になります。各ウェアハウスで個別のユーザーアカウントを作成・管理する必要がなくなり、管理負担が軽減され、使いやすさが向上します。
自動マウント機能を備えた統合カタログ – フェデレーテッドアクセス許可を使用して Redshift 名前空間を Data Catalog に登録すると、アカウント内のすべてのウェアハウスで自動的に表示されるようになります。Amazon Redshift Query Editor v2 や任意の SQL クライアントを使用するアナリストは、手動でカタログを設定することなく、登録されたウェアハウス全体のテーブルを検出してクエリできます。自動マウント機能により、データの検出が簡素化され、クロスウェアハウス分析が可能になります。
一貫したきめ細かなアクセス制御 – Amazon Redshift フェデレーテッドアクセス許可を使用してウェアハウスで定義された行レベルセキュリティ (RLS) ポリシー、動的データマスキング (DDM) ポリシー、列レベルセキュリティ (CLS) は、コンシューマーウェアハウスからデータがクエリされる際に自動的に適用されます。AWS リージョンに基づく行フィルタリング、SSN やクレジットカード番号などの機密列に対するロールベースのマスキング、時間ベースのアクセス制限などの高度なアクセス制御を、ウェアハウス全体で確実に適用できます。
SQL ベースのアクセス許可管理 – フェデレーテッドアクセス許可は、使い慣れた Redshift SQL 構文でアクセス許可を管理します。CREATE RLS POLICY で RLS ポリシーを作成し、ATTACH RLS POLICY でテーブルとロールにアタッチし、CREATE MASKING POLICY でマスキングポリシーを定義し、標準の GRANT ステートメントでアクセス許可を付与します。SQL インターフェースにより、Infrastructure as Code (IaC) アプローチが可能になり、データベース管理者は既存のスキルを活用でき、IAM または IAM Identity Center 認証を使用する既存の ETL や自動化ワークフローと自然に統合できます。

フェデレーテッドアクセス許可を使用したマルチウェアハウスアーキテクチャ

Amazon Redshift のフェデレーテッドアクセス許可を使用したマルチウェアハウスアーキテクチャは、複数の独立したコンピューティングリソースが統一されたガバナンスの下で共有データを操作するデータメッシュアプローチを表しています。次の図は、Data Catalog を使用した Redshift フェデレーテッドアクセス許可のセットアッププロセスを示しています。

プロセスは以下のステップで構成されます。

各 Redshift ウェアハウス (1, 2…N) を Data Catalog に登録します。ウェアハウスの登録については、オンボーディングドキュメントを参照してください。
Redshift ウェアハウスを Data Catalog に登録すると、ウェアハウス間でデータをクエリできるようになります。登録されたカタログはアカウント内のすべてのウェアハウスに自動的にマウントされ、Query Editor v2 のデータベースエクスプローラーや Amazon Redshift に接続された SQL クライアントに表示されます。登録されたカタログ内のテーブルをクエリするには、3 部構成の命名規則 database@catalog_name.schema_name.table_name を使用します。
クロスカタログクエリを実行すると、Amazon Redshift はグローバルアイデンティティ (IAM ロールまたは IAM Identity Center ユーザー) をリモートウェアハウスに伝播します。リモートウェアハウスのカタログインスタンスは、クエリ対象のテーブルに定義された権限付与ときめ細かなアクセス制御ポリシーに対してアクセス許可を検証します。必要なアクセス許可がある場合、テーブルメタデータと適用可能な RLS、DDM、CLS ポリシーがコンシューマーウェアハウスに返されます。ローカルウェアハウスのコンピューティングインスタンスは、セキュリティポリシーをクエリ実行プランに統合し、Redshift Managed Storage (RMS) に対してクエリを実行します。

リモートデータに対するきめ細かなアクセス制御の適用は、フェデレーテッドアクセス許可の重要な差別化要因です。従来の Redshift データ共有では、共有テーブルに対する RLS や DDM ポリシーはサポートされていません。フェデレーテッドアクセス許可を使用すると、リモートウェアハウスで定義されたセキュリティポリシーは、どのコンシューマーウェアハウスからデータがクエリされても自動的に適用されます。ウェアハウス間でセキュリティポリシーを複製することなく、データガバナンス要件への準拠をサポートします。

マルチウェアハウスアーキテクチャは、ガバナンスの複雑さを増すことなく水平方向にスケールします。アカウントに新しいウェアハウスを追加してフェデレーテッドアクセス許可に登録すると、手動設定なしで適切なアクセス許可モデルを自動的に継承します。新しいウェアハウスに接続するアナリストは、メッシュ全体でアクセス権のあるすべてのデータベースをすぐに確認でき、すべてのセキュリティポリシーが自動的に適用されます。N 個のウェアハウス間でアクセス許可を管理する N の 2 乗問題が解消され、N 個の個別設定から単一の統一ガバナンスモデルへと管理負担が軽減されます。

クエリのライフサイクル

次の図は、Redshift Warehouse 1 でのユーザークエリがフェデレーテッドアクセス許可を使用して Redshift Warehouse N のオブジェクトにアクセスする際のステップバイステップのフローを示しています。

注意: アクセス許可の詳細がローカルキャッシュで利用可能な場合、ステップ 2、3、4 はスキップされます。

ワークフローは以下のステップで構成されます。

ユーザーが Redshift Warehouse 1 に接続し、Federated Catalog N のテーブルをクエリします。
Redshift Warehouse 1 が Data Catalog の GetTable API を呼び出します。リクエストにはユーザーのトークンが含まれます。
リクエストが Redshift Warehouse N にルーティングされます。
Redshift Warehouse N がユーザーのアクセス許可を検証します。認可されている場合、テーブルメタデータと RLS ポリシー、DDM ルール、CLS 設定などのセキュリティポリシーの詳細が返されます。
Redshift Warehouse 1 がクエリプランにセキュリティポリシーを適用し、Redshift がデータを最適化された形式で保存する Redshift Managed Storage (RMS) に対してクエリを実行します。
結果がユーザーに返されます。

ソリューションの概要

本記事の例では、データウェアハウスで RLS と DDM ポリシーを定義し、別のデータウェアハウスからクエリする際にポリシーが適用されることを確認する方法を示します。

クレジットカードデータを含むテーブルを作成し、RLS と DDM ポリシーを適用して、非管理者ユーザーに対してコンシューマーカードのデータを制限し、クレジットカードの値をマスクします。ポリシーはすべてのデータウェアハウスで一貫して適用され、非管理者ユーザーがテーブルをクエリする際にクレジットカードの詳細がマスクされます。

前提条件

以下の IAM ロールを作成します。

AmazonRedshiftFullAccess ポリシーを持つ Admin ロールを作成し、sys:superuser または sys:secadmin ロールアクセスを付与します。
AmazonRedshiftQueryEditorV2ReadSharing ポリシーを持つ Readonly ロールを作成します。
2 つの Redshift データウェアハウスを作成し、AWS Glue Data Catalog (GDC) にデータウェアハウスを登録します。

テーブルの作成とデータのロード

以下の手順を実行して、credit_card テーブルを作成し、サンプルデータをロードします。

IAM Admin ロールを使用して最初の Redshift データウェアハウス 1 に接続します。

credit_cards テーブルを作成します。

-- Create table
CREATE TABLE credit_cards (
  customer_id INT,
  credit_card varchar(16),
  card_type varchar(10)
);

サンプルデータを挿入します。

-- Insert sample data
INSERT INTO credit_cards
VALUES
  (100, '4532993817514842', 'consumer'),
  (100, '4716002041425888', 'corporate'),
  (102, '5243112427642649', 'consumer'),
  (102, '6011720771834675', 'consumer'),
  (102, '6011378662059710', 'corporate'),
  (103, '373611968625635', 'consumer');

RLS と DDM ポリシーの適用

以下の手順を実行して、RLS と DDM ポリシーを作成し適用します。

コンシューマーカードタイプのみをフィルタリングする RLS ポリシーを作成します。

-- Create RLS policy
CREATE RLS POLICY consumer_cards
WITH (card_type VARCHAR(10))
USING (card_type = 'consumer');

クレジットカードをマスクする DDM ポリシーを作成します。

-- Create masking policy
CREATE MASKING POLICY mask_credit_card_full
WITH (credit_card VARCHAR(256))
USING ('000000XXXX0000'::TEXT);

RLS と DDM ポリシーを ReadOnly ロールにアタッチします。

-- Attach RLS and DDM policies to ReadOnly role
ATTACH RLS POLICY consumer_cards 
ON credit_cards 
TO "IAMR:ReadOnly";

ATTACH MASKING POLICY mask_credit_card_full
ON credit_cards(credit_card)
TO "IAMR:ReadOnly";

テーブルで行レベルセキュリティを有効にします。
```
ALTER TABLE credit_cards ROW LEVEL SECURITY ON;
```
Readonly ロールにテーブルの SELECT 権限を付与します。
```
GRANT SELECT ON credit_cards TO "IAMR:ReadOnly";
```

読み取り専用ユーザーとしてデータウェアハウス 2 に接続する

データウェアハウス 2 で以下の手順を実行してデータをクエリします。

読み取り専用ユーザーとしてデータウェアハウス 2 に接続し、外部データベースを展開します。次のスクリーンショットは、Query Editor V2 を使用した例を示しています。
カタログを展開すると、データウェアハウス 1 の credit_cards テーブルが表示されます。
以下の SQL を実行してテーブルをクエリします。以下の SQL の rs-demo-dw1 を、データウェアハウス 1 を登録する際に指定したカタログ名に置き換えてください。
```
-- SQL to query credit cards table in data warehouse1. 
SELECT * FROM "dev@rs-demo-dw1"."public"."credit_cards";
```
出力には、カードの詳細がマスクされた consumer タイプのクレジットカードのみが表示されます。データウェアハウス 1 で IAMR:ReadOnly ユーザーに適用された RLS と DDM ポリシーは、別のデータウェアハウスからテーブルをクエリした場合でも適用されます。

次のスクリーンショットは出力例を示しています。

監査のために、SHOW コマンドを実行して、ロールに対してテーブルに適用されているポリシーを確認できます。

-- Show all RLS policies in the database.
SHOW RLS POLICIES FROM DATABASE "dev@rs-demo-dw1";
-- Show all masking policies in the database.
SHOW MASKING POLICIES FROM DATABASE "dev@rs-demo-dw1";

上記の例は、フェデレーテッドアクセス許可の有用性を示しています。ウェアハウスで一度定義されたセキュリティポリシーは、ウェアハウス全体で自動的に適用され、ポリシー定義を複製することなくコンプライアンスを維持できます。

考慮事項

フェデレーテッドアクセス許可を使用する際は、以下の点に注意してください。

Amazon Redshift フェデレーテッドアクセス許可は、同じアカウントとリージョン内のデータウェアハウスに適用されます。
IAM ユーザーとロール、または IAM Identity Center を通じて統合された IdP からの SSO 認証情報を使用して、Redshift データウェアハウスに接続できます。
ローカルユーザーは、フェデレーテッドアクセス許可を活用するためにグローバルアイデンティティを引き受けることができます。
Amazon Redshift フェデレーテッドアクセス許可は、Amazon Redshift が利用可能なリージョンで追加料金なしで利用できます。既存の Amazon Redshift コンピューティングと Data Catalog の使用量に対してのみ料金が発生します。
詳細については、Amazon Redshift フェデレーテッドアクセス許可を使用する際の考慮事項を参照してください。

クリーンアップ

今後の料金が発生しないように、作成したリソース (Redshift データウェアハウスと IAM ロールを含む) を削除してください。

まとめ

Amazon Redshift フェデレーテッドアクセス許可は、マルチウェアハウスのデータガバナンスを合理化された自動プロセスに変換します。複数の Redshift ウェアハウスを運用している組織にとって、フェデレーテッドアクセス許可は管理時間を削減し、一貫したセキュリティ適用をサポートすることで、すぐにメリットを得られます。使い慣れた SQL インターフェースと既存の Redshift アクセス許可との下位互換性により、チームが新しいガバナンスモデルを学習することなく迅速に導入できます。

IAM と IAM Identity Center との統合により、SSO 機能を備えたエンタープライズグレードの ID 管理が提供され、登録されたカタログの自動マウントにより、データの検出とクロスウェアハウス分析が簡素化されます。現在 Amazon Redshift ローカルアクセス許可を使用している場合は、「ユーザー管理を AWS IAM Identity Center に移行して Amazon Redshift 認証をモダナイズする」で説明されているツールを参照してください。

詳細と開始方法については、Amazon Redshift フェデレーテッドアクセス許可のドキュメントを参照してください。