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/)を参照してください。
# Amazon Redshift Serverless のフェデレーションユーザーに付与するデータベースロールの定義
組織に所属しているときは、関連するロール群があります。例えば、*プログラマー*や*マネージャー*など、職務に応じたロールがあります。ロールによって、どのアプリケーションやデータにアクセスできるかが決まります。ほとんどの組織では、Microsoft Active Directory などの ID プロバイダーを使用して、ユーザーやグループにロールを割り当てています。組織は個々のユーザーに対してそれほど多くの管理を行う必要がないため、リソースアクセスを制御するためのロールの使用は増えてきました。
最近、Amazon Redshift Serverless にロールベースのアクセスコントロールが導入されました。データベースロールを使用すると、スキーマまたはテーブルなどのデータおよびオブジェクトへのアクセスを保護することができます。または、ロールを使用して、システムモニタリングやデータベース管理者などの、一連の上位権限を定義することもできます。ただし、データベースロールにリソース権限を付与したあとは、組織内のユーザーのロールをデータベースロールに結び付ける、別の手順があります。SQL ステートメントを実行することにより、初回サインイン時に各ユーザーをデータベースロールに割り当てることができますが、手間がかかります。より簡単な方法は、付与するデータベースロールを定義して Amazon Redshift Serverless に渡すことです。これには最初のサインインプロセスを簡略化できるという利点があります。
ロールは `GetCredentials` を使用して Amazon Redshift Serverless に渡すことができます。ユーザーが Amazon Redshift Serverless データベースに初めてサインインすると、関連するデータベースユーザーが作成され、一致するデータベースロールにマッピングされます。このトピックでは、Amazon Redshift Serverless ロールを渡すメカニズムについて詳しく説明します。
データベースロールを渡すには、次のようないくつかの主なユースケースがあります。
+ ユーザーがサードパーティーの ID プロバイダー (通常はフェデレーションを設定済み) を介してサインインし、セッションタグを使用してロールを渡します。
+ ユーザーが IAM サインイン認証情報を使用してサインインし、タグキーおよび値を使用してそれらのロールを渡します。
ロールベースのアクセスコントロールの詳細については、「[ロールベースのアクセスコントロール (RBAC)](https://docs.aws.amazon.com/redshift/latest/dg/t_Roles.html)」を参照してください。
## データベースロールの定義
Amazon Redshift Serverless にロールを渡すには、データベースにデータベースロールを設定し、データベースリソースに適切な権限を付与する必要があります。例えば、簡単なシナリオでは、*sales* という名前のデータベースロールを作成し、そのロールに売上データを含むクエリテーブルへのアクセス権を付与できます。データベースロールを作成して権限を付与する方法の詳細については、「[CREATE ROLE](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_ROLE.html)」と「[GRANT](https://docs.aws.amazon.com/redshift/latest/dg/r_GRANT.html)」を参照してください。
## フェデレーションユーザーに付与するデータベースロールを定義するユースケース
これらのセクションでは、データベースロールを Amazon Redshift Serverless に渡すことでデータベースリソースへのアクセスを簡素化する、いくつかのユースケースについて概説します。
### ID プロバイダーを使用したサインイン
最初のユースケースでは、組織が ID およびアクセス管理サービスのユーザー ID を持っていると仮定しています。このサービスは、JumpCloud や Okta などのクラウドベースでも、Microsoft Active Directory などのオンプレミスでもかまいません。目的は、ユーザーがクエリエディタ V2 などのクライアントにサインインするとき、または JDBC クライアントでサインインするときに、ID プロバイダーからデータベースロールにユーザーのロールを自動的にマッピングすることです。これを設定するには、いくつかの設定タスクを完了する必要があります。これには以下が含まれます。
1. 信頼関係を使用して ID プロバイダー (IdP) とのフェデレーション統合を設定します。これは必須条件です。これを設定すると、ID プロバイダーが SAML アサーションによるユーザー認証とサインイン認証情報の提供を行います。詳細については、「[サードパーティーの SAML ソリューションプロバイダーと AWS の統合](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml_3rd-party.html)」を参照してください。また、「[Federate access to Amazon Redshift query editor V2 with Active Directory Federation Services (AD FS)](https://aws.amazon.com/blogs//big-data/federate-access-to-amazon-redshift-query-editor-v2-with-active-directory-federation-services-ad-fs-part-3/)(Active Directory フェデレーションサービス (AD FS) を使用して Amazon Redshift クエリエディタ v2 へのアクセスをフェデレーションする)」または「[Federate single sign-on access to Amazon Redshift query editor v2 with Okta](https://aws.amazon.com/blogs//big-data/federate-single-sign-on-access-to-amazon-redshift-query-editor-v2-with-okta/) (Okta を使用して Amazon Redshift クエリエディタ v2 へのシングルサインオンアクセスをフェデレーションする)」を参照してください。
1. ユーザーは、次のポリシー許可を持っている必要があります。
+ `GetCredentials` – Amazon Redshift Serverless へのログインを一時的に認可するための認証情報を提供します。
+ `sts:AssumeRoleWithSAML` — エンタープライズ ID ストアまたはディレクトリをロールベースの AWS アクセスに結び付けるメカニズムを提供します。
+ `sts:TagSession` — ID プロバイダープリンシパルでの、タグセッションアクションへの権限。
この場合、`AssumeRoleWithSAML` は SAML 認証レスポンスによって認証されたユーザーのセキュリティ認証情報のセットを返します。この操作により、ユーザー固有の認証情報なしで、ID ストアまたはディレクトリをロールベースの AWS アクセスに結び付けるメカニズムが提供されます。`AssumeRoleWithSAML` への権限を持つユーザーの場合、ロール情報の受け渡しに使用される SAML アサーションの管理は ID プロバイダーが行います。
ベストプラクティスとして、アクセス許可ポリシーを IAM ロールにアタッチし、それを必要に応じてユーザーやグループに割り当てることをお勧めします。詳細については、「[Amazon Redshift での Identity and Access Management](https://docs.aws.amazon.com/redshift/latest/mgmt/redshift-iam-authentication-access-control.html)」を参照してください。
1. タグ `RedshiftDbRoles` は、*role1:role2* の形式で、コロンで区切られたロール値を使用して設定します。例えば、`manager:engineer`。これらは、ご使用の ID プロバイダーで設定されたセッションタグ実装から取得できます。SAML 認証リクエストはロールをプログラムで渡します。セッションタグの受け渡しについては、「[AWS STS でのセッションタグの引き渡し](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html)」を参照してください。
データベースに存在しないロール名を渡した場合、そのロール名は無視されます。
このユースケースでは、ユーザーがフェデレーション ID を使用してサインインすると、そのロールはセッションタグのキーと値を介した承認リクエストで渡されます。そして、承認後、`GetCredentials` はロールをデータベースに渡します。接続に成功すると、データベースロールがマッピングされ、ユーザーは自分のロールに対応するデータベースタスクを実行することができます。操作の重要な部分は、最初の承認リクエストで `RedshiftDbRoles` セッションタグにロールが割り当てられることです。詳細については、「[AssumeRoleWithSAML を使用したセッションタグの受け渡し](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html#id_session-tags_adding-assume-role-saml)」を参照してください。
### IAM 認証情報を使ったサインイン
2 つ目のユースケースでは、ロールをユーザーに渡すことにより、ユーザーは IAM 認証情報を使用してデータベースクライアントアプリケーションにアクセスできます。
1. この場合、サインインするユーザーには、以下のアクションを行うためのポリシー権限が割り当てられている必要があります。
+ `tag:GetResources` - 指定されたタグに関連付けられているタグ付きリソースを返します。
+ `tag:GetTagKeys`— 現在使用中のタグキーを返します。
ベストプラクティスとして、アクセス許可ポリシーを IAM ロールにアタッチし、それを必要に応じてユーザーやグループに割り当てることをお勧めします。詳細については、「[Amazon Redshift での Identity and Access Management](https://docs.aws.amazon.com/redshift/latest/mgmt/redshift-iam-authentication-access-control.html)」を参照してください。
1. Amazon Redshift Serverless などのデータベースサービスにアクセスするには、アクセス許可も必要です。
1. このユースケースでは、AWS Identity and Access Management でロールのタグ値を設定します。**[タグの編集]** を選択して、ロールを含むタグ値文字列を持つ *RedShiftDBroles* という名前のタグキーを作成できます。例えば、*manager:engineer* です。
ユーザーがログインすると、そのロールが承認リクエストに追加され、データベースに渡されます。ロールは既存のデータベースロールにマッピングされます。
## その他のリソース
ユースケースで述べたように、IdP と AWS との信頼関係を設定できます。詳細については、「[証明書利用者の信頼およびクレームの追加によって SAML 2.0 IdP を設定する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml_relying-party.html)」を参照してください。