使用 Athena 查询向 Lake Formation 注册的数据时的注意事项和限制 - Amazon Athena
在某些情况下，对列没有数据权限的用户可以看到列元数据使用 Lake Formation 权限查看视图Lake Formation 精细访问控制和 Athena 工作组Amazon S3 中的 Athena 查询结果位置未向 Lake Formation 注册使用 Athena 工作组限制对查询历史记录的访问跨账户存取无法在 Athena 中查询向 Lake Formation 注册的 CSE-KMS Amazon S3向 Lake Formation 注册的分区数据位置必须在表子目录中Create Table As Select (CTAS) 查询需要 Amazon S3 写入权限默认数据库需要 DESCRIBE 权限
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

使用 Athena 查询向 Lake Formation 注册的数据时的注意事项和限制

使用 Athena 查询在 Lake Formation 中注册的数据时，请考虑以下因素。有关更多信息，请参阅《Amazon Lake Formation 开发人员指南》中的 Amazon Lake Formation的已知问题。

在某些情况下，使用 Avro 和自定义，未经授权的用户可以看到列元数据 SerDe

Lake Formation 列级授权可防止用户访问自己没有 Lake Formation 权限的列中的数据。但是，在某些情况下，用户可以访问描述表中所有列的元数据，包括他们对其中的数据没有权限的列。

当使用 Apache Avro 存储格式或使用自定义 Serializer/Deserializer (SerDe) 将列元数据存储在表的表属性中时，就会发生这种情况，其中表架构与定义一起在表属性中定义。 SerDe在将 Athena 与 Lake Formation 一起使用时，我们建议您查看向 Lake Formation 注册的表属性的内容，并在可能的情况下限制存储在表属性中的信息，以防止任何敏感元数据对用户可见。

使用 Lake Formation 权限查看视图

对于向 Lake Formation 注册的数据，Athena 用户只有在对 VIEW 所基于的表、列和源 Amazon S3 数据位置具有 Lake Formation 权限时，才能创建 VIEW。在 Athena 中创建 VIEW 后，Lake Formation 权限可以应用于 VIEW。列级权限不可用于 VIEW。对 VIEW 具有 Lake Formation 权限但对视图所基于的表和列没有权限的用户无法使用 VIEW 查询数据。但是，具有此权限组合的用户可以使用语句（如 DESCRIBE VIEW、SHOW CREATE VIEW 和 SHOW COLUMNS）查看 VIEW 元数据。因此，请确保对于每个 VIEW 的 Lake Formation 权限与基础表权限一致。表中定义的单元格筛选条件不适用于该表的 VIEW。资源链接名称必须与原始账户中的资源名称相同。在跨账户设置中使用视图时还存在其他限制。有关跨账户设置共享视图的权限的更多信息，请参阅 跨账户数据目录访问。

Lake Formation 精细访问控制和 Athena 工作组

同一 Athena 工作组中的用户可以查看由 Lake Formation 精细访问控制配置为可供工作组访问的数据。有关在 Lake Formation 中使用精细访问控制的更多信息，请参阅 Amazon 大数据博客中的使用 Amazon Lake Formation管理精细访问控制。

Amazon S3 中的 Athena 查询结果位置未向 Lake Formation 注册

Amazon S3 中针对 Athena 的查询结果位置无法向 Lake Formation 注册。Lake Formation 权限不限制对这些位置的访问。除非您限制访问权限，否则，如果 Athena 用户拥有数据的 Lake Formation 权限，则可以访问查询结果文件和元数据。为避免这种情况，我们建议您使用工作组指定查询结果的位置，并将工作组成员身份与 Lake Formation 权限对齐。然后，您可以使用 IAM 权限策略限制对查询结果位置的访问。有关查询结果的更多信息，请参阅 使用查询结果、最近查询和输出文件。

使用 Athena 工作组限制对查询历史记录的访问

Athena 查询历史记录显示已保存查询和完整查询字符串的列表。除非您使用工作组来分离查询历史记录的访问权限，否则即使 Athena 用户没有获得授权查询 Lake Formation 中的数据，仍可以查看对该数据运行的查询字符串，包括列名、选择条件等。我们建议您使用工作组来分隔查询历史记录，并将 Athena 工作组成员资格与 Lake Formation 权限对齐以限制访问。有关更多信息，请参阅使用工作组控制查询访问和成本。

跨账户数据目录访问

要访问其他账户中的数据目录，您可以使用 Athena 的跨账户 Amazon Glue 功能或在 Lake Formation 中设置跨账户访问。

Athena 跨账户数据目录访问

您可以使用 Athena 的跨账户 Amazon Glue 目录功能在您的账户中注册该目录。此功能仅在 Athena 引擎版本 2 及更高版本中可用，并且仅限于在账户之间使用同一区域时。有关更多信息，请参阅从另一个账户注册 Amazon Glue Data Catalog。

如果要共享的数据目录在中配置了资源策略 Amazon Glue，则必须将其更新为允许访问 Amazon Resource Access Manager 并向账户 B 授予使用账户 A 数据目录的权限，如下例所示。

{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Principal": {
            "Service": "ram.amazonaws.com"
        },
        "Action": "glue:ShareResource",
        "Resource": [
          "arn:aws:glue:<REGION>:<ACCOUNT-A>:table/*/*", 
          "arn:aws:glue:<REGION>:<ACCOUNT-A>:database/*", 
          "arn:aws:glue:<REGION>:<ACCOUNT-A>:catalog"
        ]
    }, 
    {
        "Effect": "Allow",
        "Principal": {
            "AWS": "arn:aws:iam::<ACCOUNT-B>:root"
        },
        "Action": "glue:*",
        "Resource": [
          "arn:aws:glue:<REGION>:<ACCOUNT-A>:table/*/*", 
          "arn:aws:glue:<REGION>:<ACCOUNT-A>:database/*", 
          "arn:aws:glue:<REGION>:<ACCOUNT-A>:catalog"
        ]
    }
    ]
}

有关更多信息，请参阅授予 Amazon Glue 数据目录跨账户访问权限。

在 Lake Formation 中设置跨账户访问权限

Amazon Lake Formation 允许您使用单个帐户管理中央数据目录。您可以使用此功能来对 Data Catalog 元数据和底层数据实施跨账户访问。例如，拥有者账户可以授予另一个（收件人）账户对于表的 SELECT 权限。

要在 Athena 查询编辑器中显示共享数据库或表，您可以在 Lake Formation 中创建资源链接来访问共享数据库或表。当 Lake Formation 中的收款人账户查询所有者表时，CloudTrail会将数据访问事件添加到收件人账户和所有者账户的日志中。

对于共享视图，请记住以下几点：

  • 查询在目标资源链接上运行，而不是在源表或视图上运行，然后系统会将输出共享到目标账户。

  • 仅共享视图是不够的。创建视图涉及的所有表都必须是跨账户共享的一部分。

  • 基于共享资源创建的资源链接的名称必须与拥有者账户中资源的名称相匹配。如果名称不匹配，则会显示错误消息，例如 “分析存储视图失败” awsdatacatalog。 my-lf-resource-link。 my-lf-view': 第 3:3 行：出现架构 s chema_name 不存在。

有关 Lake Formation 中跨账户访问的更多信息，请参阅《Amazon Lake Formation 开发人员指南》中的以下资源：

跨账户访问

资源链接在 Lake Formation 中的工作原理

跨账户 CloudTrail 日志

CSE-KMS 加密了在 Lake Formation 注册的 Amazon S3 地点

Athena 无法查询具有以下特征的开放表格式 (OTF) 表，例如 Apache Iceberg：

  • 这些表基于在 Lake Formation 中注册的 Amazon S3 数据位置。

  • Amazon S3 中的对象使用客户端加密 (CSE) 进行加密。

  • 加密使用 Amazon KMS 客户管理的密钥 (CSE_KMS)。

要查询使用CSE_KMS密钥加密的非 OTF 表），请在用于 CSE 加密的 Amazon KMS 密钥策略中添加以下块。<KMS_KEY_ARN>是加密数据的 Amazon KMS 密钥的 ARN。<IAM-ROLE-ARN>是在 Lake Formation 中注册 Amazon S3 位置的 IAM 角色的 ARN。

{
    "Sid": "Allow use of the key",
    "Effect": "Allow",
    "Principal": {
        "AWS": "*"
    },
    "Action": "kms:Decrypt",
    "Resource": "<KMS-KEY-ARN>",
    "Condition": {
        "ArnLike": {
            "aws:PrincipalArn": "<IAM-ROLE-ARN>"
        }
    }
}

向 Lake Formation 注册的分区数据位置必须在表子目录中

向 Lake Formation 注册的分区表必须在作为 Amazon S3 中该表的子目录的目录中具有分区数据。例如，可以向 Lake Formation 注册并使用 Athena 查询具有位置 s3://mydata/mytable 和分区 s3://mydata/mytable/dt=2019-07-11、s3://mydata/mytable/dt=2019-07-12 等的表。另一方面，无法向 Lake Formation 注册具有位置 s3://mydata/mytable 和分区（位于s3://mydata/dt=2019-07-11、s3://mydata/dt=2019-07-12 等等中）的表。因为这样的分区不是 s3://mydata/mytable 的子目录，它们也无法从 Athena 读取。

Create Table As Select (CTAS) 查询需要 Amazon S3 写入权限

Create Table As Statements (CTAS) 需要对表的 Amazon S3 位置进行写入访问。要对向 Lake Formation 注册的数据运行 CTAS 查询，Athena 用户除了具有相应的 Lake Formation 权限以读取数据位置以外，还必须具有写入表 Amazon S3 位置的 IAM 权限。有关更多信息，请参阅从查询结果创建表（CTAS）。

默认数据库需要 DESCRIBE 权限

对于 default 数据库，Lake Formation DESCRIBE 权限是必需的。以下示例 Amazon CLI 命令向 Amazon 账户datalake_user1中的用户授予default数据库DESCRIBE权限111122223333。

aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "DESCRIBE" --resource '{ "Database": {"Name":"default"}}

有关更多信息，请参阅《Amazon Lake Formation 开发人员指南》中的 Lake Formation 权限参考。