

 Amazon Redshift 將不再支援從修補程式 198 開始建立新的 Python UDFs。現有 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 中定義要向聯合身分使用者授予的資料庫角色
<a name="redshift-iam-access-federated-db-roles"></a>

當您是組織的一分子時，您會有一組相關聯的角色。例如，你有你工作職能的角色，如*程式設計人員*和*管理員*。您的角色決定了您可以存取哪些應用程式和資料。大多數組織會使用身分提供者 (例如 Microsoft Active Directory) 將角色指派給使用者和群組。使用角色來控制資源存取的情況變多了，因為組織不必花太多時間管理個別使用者。

Amazon Redshift Serverless 最近引進了角色型存取控制功能。您可以使用資料庫角色來保護對於資料和物件 (例如結構描述或資料表) 的存取。或者，您也可以使用角色來定義一組提升的許可，例如針對系統監控或資料庫管理員來定義。但在向資料庫角色授予資源許可後，還要再進行一個步驟，那就是將使用者的角色從組織連線到資料庫角色。您可以透過執行 SQL 陳述式，在每個使用者初次登入時向其指派資料庫角色，但這需要大量工作。比較簡單的方法是定義要向其授予的資料庫角色，並將其傳遞至 Amazon Redshift Serverless。這麼做的好處是可以簡化初始登入程序。

您可以使用 `GetCredentials` 將角色傳遞至 Amazon Redshift Serverless。當使用者第一次登入 Amazon Redshift Serverless 資料庫時，系統會建立相關聯的資料庫使用者，並將其對應至相符的資料庫角色。本主題會詳細說明將角色傳遞至 Amazon Redshift Serverless 的機制。

傳遞資料庫角色有幾個主要的使用案例：
+ 當使用者透過第三方身分提供者 (一般皆已設定聯合功能) 來登入，並透過工作階段標籤傳遞角色時。
+ 當使用者透過 IAM 登入憑證來登入，並透過標籤索引鍵和值傳遞其角色時。

如需角色型存取控制的相關資訊，請參閱[角色型存取控制 (RBAC)](https://docs.aws.amazon.com/redshift/latest/dg/t_Roles.html)。

## 定義資料庫角色
<a name="redshift-iam-access-federated-db-roles-configuration"></a>

您必須先在資料庫中設定資料庫角色，並向其授予適當的資料庫資源許可，然後才能將角色傳遞至 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)。

## 定義要向聯合身分使用者授予之資料庫角色的使用案例
<a name="redshift-iam-access-federated-db-roles-use-cases"></a>

以下各節概述了將資料庫角色傳遞至 Amazon Redshift Serverless 可以簡化資料庫資源存取方式的幾個使用案例。

### 使用身分提供者來登入
<a name="redshift-iam-access-federated-db-roles-idp-principal"></a>

第一個使用案例假設您的組織在身分與存取管理服務中具有使用者身分。這項服務可以基於雲端 (例如 JumpCloud 或 Okta)，也可以基於內部部署 (如 Microsoft Active Directory)。目標是在使用者登入用戶端 (例如查詢編輯器 V2) 或使用 JDBC 用戶端時，自動將使用者得自身分提供者的角色對應至資料庫角色。若要進行這方面的設定，您必須先完成幾個組態任務。這些索引標籤包括以下項目：

1. 使用信任關係設定與身分提供者 (IdP) 的聯合整合。這是先決條件。當您完成設定時，身分提供者便會負責透過 SAML 聲明驗證使用者並提供登入憑證。如需詳細資訊，請參閱[將第三方 SAML 解決方案供應商與 整合 AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml_3rd-party.html)。您也可以在[將 Amazon Redshift 查詢編輯器 V2 的存取與 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/)或[將 Amazon Redshift 查詢編輯器 v2 的單一登入存取與 Okta 聯合](https://aws.amazon.com/blogs//big-data/federate-single-sign-on-access-to-amazon-redshift-query-editor-v2-with-okta/) 中找到更多資訊。

1. 使用者必須具有下列政策許可：
   + `GetCredentials` — 提供憑證以供臨時授權登入 Amazon Redshift Serverless。
   + `sts:AssumeRoleWithSAML` – 提供將企業身分存放區或目錄繫結至角色型 AWS 存取的機制。
   + `sts:TagSession` — 身分提供者主體上的標籤工作階段動作許可。

    在這種情況下，`AssumeRoleWithSAML` 會透過 SAML 驗證回應，針對已驗證過的使用者傳回一組安全憑證。此操作提供一種機制，可將身分存放區或目錄繫結至角色型 AWS 存取，而不需要使用者特定的登入資料。對於具有 `AssumeRoleWithSAML` 許可的使用者，身分提供者會負責管理用來傳遞角色資訊的 SAML 聲明。

   我們建議的最佳實務是，將許可政策連接到 IAM 角色，然後根據需要將其指派給使用者和群組。如需詳細資訊，請參閱 [Amazon Redshift 中的身分和存取管理](https://docs.aws.amazon.com/redshift/latest/mgmt/redshift-iam-authentication-access-control.html)。

1. 您可以 *role1:role2* 格式的冒號分隔角色值來設定 `RedshiftDbRoles` 標籤。例如 `manager:engineer`。這些項目可以從身分提供者中所設定的 session-tag 實作來擷取。SAML 驗證請求會以程式設計方式傳遞角色。如需傳遞工作階段標籤的相關資訊，請參閱[在 AWS STS中傳遞工作階段標籤](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html)。

   如果您傳遞的角色名稱不存在於資料庫中，系統會將其忽略。

在這個使用案例中，當使用者使用聯合身分登入時，系統會透過工作階段標籤的索引鍵和值在授權請求中傳遞其角色。緊接在授權之後，`GetCredentials` 便會將角色傳遞至資料庫。連線成功後，資料庫角色便會對應，而且使用者可以執行與其角色對應的資料庫任務。操作的基本部分是系統會在初始授權請求中向 `RedshiftDbRoles` 工作階段標籤指派角色。如需傳遞工作階段標籤的相關資訊，請參閱[使用 AssumeRoleWithSAML 傳遞工作階段標籤](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html#id_session-tags_adding-assume-role-saml)。

### 使用 IAM 憑證進行登入
<a name="redshift-iam-access-federated-db-roles-iam-creds"></a>

在第二個使用案例中，我們可以向使用者傳遞角色，讓其透過 IAM 憑證存取資料庫的用戶端應用程式。

1. 在此情況下登入的使用者必須獲派下列動作的政策許可：
   + `tag:GetResources` — 傳回與指定標籤相關聯的已標記資源。
   + `tag:GetTagKeys` — 傳回目前使用中的標籤索引鍵。

     我們建議的最佳實務是，將許可政策連接到 IAM 角色，然後根據需要將其指派給使用者和群組。如需詳細資訊，請參閱 [Amazon Redshift 中的身分和存取管理](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*。

當使用者登入時，系統會將其角色新增至授權請求並傳遞給資料庫。其會對應至現有的資料庫角色。

## 其他資源
<a name="redshift-iam-access-federated-db-roles-resources"></a>

如使用案例所述，您可以設定 IdP 和 AWS之間的信任關係。如需詳細資訊，請參閱[使用依賴方信任設定您的 SAML 2.0 IdP 並新增宣告](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml_relying-party.html)。