AWS redshift: Add usage notes for the Redshift DEBUG permission
Summary
Adds a new 'Usage notes for granting the DEBUG permission' section (plus a TOC entry) explaining that DEBUG applies only to databases with federated permissions, that it unredacts secure-logging records for FGAC-protected data, who can grant/revoke it (superuser or database owner), supported grantee forms (global identity, IdC group, account admins), and restrictions such as no GRANT to PUBLIC/local users, no inclusion in GRANT ALL, prospective-only effect, and per-database requirement in cross-database joins.
Security assessment
The new section documents an authorization control over audit/secure-logging data: by default Redshift redacts sensitive values in system log records for FGAC-protected federated databases, and DEBUG explicitly re-exposes those values. The changed rule line shows deliberate scoping to prevent broad exposure (no PUBLIC/local grantees, superuser-only grants, per-database grants), which is security-hardening guidance for protecting consumer/producer data and log confidentiality, but it documents a feature rather than fixing a specific vulnerability.
Evidence
+ * You can't grant DEBUG to PUBLIC, to a local user, or to a local group.
Diff
diff --git a/redshift/latest/dg/r_GRANT-usage-notes.md b/redshift/latest/dg/r_GRANT-usage-notes.md index 0e6f04d48..fd0e01fb3 100644 --- a//redshift/latest/dg/r_GRANT-usage-notes.md +++ b//redshift/latest/dg/r_GRANT-usage-notes.md @@ -7 +7 @@ -Usage notes for column-level access controlUsage notes for granting the ASSUMEROLE permissionUsage notes for granting machine learning permissions +Usage notes for column-level access controlUsage notes for granting the ASSUMEROLE permissionUsage notes for granting machine learning permissionsUsage notes for granting the DEBUG permission @@ -158,0 +159,36 @@ Granting the `EXECUTE` permission related to an ML function will fail if there i +## Usage notes for granting the DEBUG permission + +The DEBUG permission applies to databases in Amazon Redshift warehouses with [federated permissions](https://docs.aws.amazon.com/redshift/latest/dg/federated-permissions.html) that use fine-grained access control (FGAC). By default, when a query accesses FGAC-protected data in such a database, Amazon Redshift redacts sensitive values in the system log table records that are generated for that query. This protects the producer's data from the consumer. Granting DEBUG allows specified entities to see those log records without redaction. For the list of redacted fields and more information about secure logging, see [Secure logging](https://docs.aws.amazon.com/redshift/latest/mgmt/db-auditing-secure-logging.html) in the _Amazon Redshift Management Guide_. + +Only a superuser or the database owner can grant or revoke DEBUG. You can grant DEBUG only on a database in an Amazon Redshift warehouse with federated permissions, not on a local database or a database created from an AWS Lake Formation or AWS Glue Data Catalog catalog. + +DEBUG supports the following forms: + + * **Granting to a global identity.** Use `TO `<prefix>:<name>``, where the prefix identifies the identity provider (for example, `IAM` for an IAM user, `IAMR` for an IAM role, or the IdC (AWS IAM Identity Center) namespace prefix for an IdC user). Only the specified identity can see the unredacted records that were generated by its own queries. No other user, including a superuser, can see them. + + * **Granting to an IdC group.** Use `TO ROLE `<idc_prefix>:<group_name>``, where the prefix identifies the IdC (AWS IAM Identity Center) instance. Each member of the group can see the unredacted records that were generated by its own queries. + + * **Granting to account administrators.** Use `TO ADMINS OF ACCOUNT '`account_id`'`. All superusers (at the time of log access) on the specified consumer account can see the unredacted records. Records authorized this way are also unredacted when Amazon Redshift exports system table data to Amazon S3 Tables. You can specify only the same account that owns the producer. + + + + +The following usage notes apply to the DEBUG permission: + + * DEBUG isn't included in GRANT ALL ON DATABASE. You must grant it explicitly. + + * You can grant DEBUG on only one database per statement, and you can't combine it with other permissions in the same statement. + + * You can't grant DEBUG to PUBLIC, to a local user, or to a local group. + + * DEBUG is prospective only. Granting DEBUG affects only log records generated after the grant. Revoking DEBUG affects only records generated after the revoke; records generated while DEBUG was active remain visible for the lifetime of the log. + + * If you deregister the cluster or namespace from AWS Glue Data Catalog, existing DEBUG grants are retained but have no effect, because the warehouse no longer uses federated permissions. You don't need to revoke them. If you register the cluster or namespace again, the grants take effect again. DEBUG grants are removed only when the database is dropped. For more information, see [Deregister from AWS Glue Data Catalog](./federated-permisisons-offboarding-deregister-catalog.html). + + * When a query joins multiple databases with federated permissions, you must grant DEBUG on every such database that contributes FGAC-protected data to the query. Otherwise, the records remain redacted. + + * When you grant DEBUG to an IAM role, a local superuser that assumes that role (`SET SESSION AUTHORIZATION`) by using [ALTER USER SET GLOBAL IDENTITY](https://docs.aws.amazon.com/redshift/latest/dg/federated-permissions-onboarding.html#federated-permissions-onboarding-alter-set-global-identity) can see the role's unredacted records. IAM users and IdC users can't be impersonated in this way. + + + +