随着组织越来越多地采用现代数据湖仓（lakehouse）架构，如 Apache Iceberg lakehouses，他们享受着其灵活性、可扩展性和性能改进带来的诸多好处。然而，这些优势也带来了有关数据安全和治理的新挑战。

本章深入探讨了保护和治理 Apache Iceberg 表的多方面内容。Apache Iceberg 主要作为一个定义数据集元数据的标准，本身并没有内置安全功能，除了某些表属性用于选择文件加密类型。保护你的 Apache Iceberg 表主要由用于处理表的存储层、访问层和计算层来实现。

在这一旅程中，您将发现三种关键角度来保护您的数据湖仓：

保护数据文件
通过语义层进行安全和治理
在目录级别进行安全和治理

组织必须采用综合方法来有效保护和治理其 Apache Iceberg 表。通过研究这三个角度------保护数据文件、通过语义层实施安全和治理，以及确保目录级别的安全，您将能很好地应对现代数据湖仓中数据保护的复杂性。让我们一起踏上这段旅程，强化您的数据资产，充分发挥 Apache Iceberg 的潜力。

请记住，治理和安全是非常深入的主题，已经有多本书专门探讨这些内容。本章将介绍一些使用工具保护 Apache Iceberg 表的示例，并不旨在提供工具或方法的详尽列表。

保护数据文件

在每个数据湖仓的核心是大量的数据文件。保护这些文件是防止未经授权访问和数据泄露的第一道防线。本节探讨了各种工具和最佳实践，以确保 Apache Iceberg 表中底层数据文件的安全，包括加密、访问控制、数据屏蔽和审计。

在存储级别保护数据文件是至关重要的，因为这些文件构成了数据基础设施的基石。在网络威胁不断加剧的时代，组织必须加强数据保护，以应对多种漏洞的威胁。从外部威胁（如黑客攻击和数据泄露）到内部风险（如数据泄露和未经授权的访问），潜在的陷阱很多。通过主动应对这些漏洞，组织可以确保数据的完整性、机密性和可用性，确保遵守数据保护法规，并增强客户信任。在本节中，我们将探讨各种存储平台及其不同的安全选项，以保护您的数据文件，为您提供做出适合您组织需求的安全措施决策所需的工具和知识。

保护文件：最佳实践

无论选择哪种存储平台，保护 Apache Iceberg 表的数据文件都需要遵循基本原则和最佳实践，以确保全面的数据保护。以下是一些需要考虑的总体原则和最佳实践：

最低权限访问：仅将数据文件的访问权限授予完成特定任务所需的个人和过程。授予完成这些任务所需的最低权限级别。
静态和传输中的加密：强制对数据文件在静态和传输中进行加密。利用存储平台提供的加密机制来保护数据的完整性和机密性。
强身份验证和身份管理：实施强大的身份和访问管理实践。利用多因素身份验证（MFA）和强密码策略来验证用户身份。
审计跟踪和日志记录：启用存储平台提供的审计和日志记录功能。维护全面的审计跟踪，以监控和调查对数据文件的访问和更改。
数据保留和处置策略：定义数据保留和处置策略，以管理数据文件的生命周期。安全删除或存档不再需要的文件，以减少风险暴露。
持续监控：实施持续监控和警报系统，以实时检测和响应安全事件。

在 Apache Iceberg 表的文件级别安全方面，有优缺点需要考虑。优点包括精细的控制，可以为单个数据文件设置精确的权限和加密设置，支持静态数据加密，确保敏感信息的安全，以及严格的数据隔离，最小化未经授权的访问风险。然而，缺点包括管理文件级别安全的复杂性，特别是随着文件数量的增加，还可能缺乏抽象层，无法向终端用户和工具提供统一和简化的数据视图。最后，随着数据湖仓规模的扩大，管理权限的可扩展性可能成为挑战，可能导致错误和效率低下。

Hadoop 分布式文件系统

在 Hadoop 分布式文件系统 (HDFS) 上存储 Apache Iceberg 表的数据文件时，需要采取综合措施来保护数据，确保数据的机密性和完整性。以下是关键组件：

访问控制列表 (ACLs) ：HDFS 中的访问控制列表允许您对 Iceberg 数据湖仓中的特定文件和目录进行细粒度的访问控制。通过 ACLs，您可以精确定义单个用户或组的权限，超越标准的读、写和执行权限。这种细粒度的控制确保只有授权人员可以访问敏感数据，最小化未经授权的访问或数据泄露的风险。
bash 复制代码
```
# 为特定用户设置 ACL 以授予读写访问权限
hdfs dfs -setfacl -m user:username:rwx /path/to/your/file_or_directory

# 为特定组授予读权限
hdfs dfs -setfacl -m group:groupname:r-x /path/to/your/file_or_directory
```
加密：对静态数据进行加密是保护数据文件的关键。HDFS 提供了强大的加密选项，包括透明数据加密 (TDE) 和加密区。TDE 在磁盘上加密数据块，即使物理存储介质被破坏，数据也无法读取。加密区允许您指定需要加密的特定目录或文件，从而将加密集中在最关键的数据上。
bash 复制代码
```
# 为 HDFS 启用透明数据加密 (TDE)
hdfs crypto -createZone -keyName myEncryptionKey -path /path/to/encryption/zone
```
权限：HDFS 采用类似于传统文件系统的权限系统，使您能够系统地管理数据文件的访问。通过 chmod 和 chown 等命令，您可以为用户和组分配特定权限，决定谁可以读取、写入或执行文件和目录。正确配置权限可以确保只有合适的个人或过程可以访问数据，从而减少数据滥用的风险。
bash 复制代码
```
# 更改文件或目录的所有者
hdfs dfs -chown newowner:newgroup /path/to/your/file_or_directory

# 更改权限以授予所有者读写执行权限
hdfs dfs -chmod 700 /path/to/your/file_or_directory
```

通过强调 ACLs 以实现精确的访问控制、加密以保证数据机密性和权限以进行结构化的访问管理，您可以根据特定需求定制这些强大的安全措施，增强数据湖仓的防御能力。通过这种多方面的安全方法，确保您的数据保持机密且防篡改，增强数据资产的完整性和可信度。

Amazon Simple Storage Service

在 Amazon Web Services (AWS) 上保护 Apache Iceberg 表的数据文件，涉及使用 Amazon Simple Storage Service (Amazon S3) 提供的各种安全功能。本节将指导您如何使用一些最重要的文件级别安全功能，这些功能通常围绕加密和控制对文件的访问展开。

加密

Amazon S3 提供了三种服务器端加密 (SSE) 选项来保护静态数据。选择最适合您安全需求的一种。
- SSE-S3 (SSE with S3-managed keys) ：这是一种简单的选择，适用于大多数使用场景。Amazon S3 自动管理加密密钥。使用以下代码通过 AWS CLI 启用 SSE-S3：
  css 复制代码
```
aws s3api put-bucket-encryption --bucket YOUR_BUCKET_NAME --server-side-encryption-configuration '{"Rules": [{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm": "AES256"}}]}'
```
- SSE-KMS (SSE with the AWS Key Management Service) ：此选项利用 AWS Key Management Service (KMS) 进行高级密钥管理，适用于涉及法规遵从性或严格企业安全策略的场景。使用以下 AWS CLI 命令启用 SSE-KMS：
  css 复制代码
```
aws s3api put-bucket-encryption --bucket YOUR_BUCKET_NAME --server-side-encryption-configuration '{"Rules": [{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm": "aws:kms", "KMSMasterKeyID": "YOUR_KMS_KEY_ID"}}]}'
```
- SSE-C (SSE with customer-provided keys) ：SSE-C 提供了最高级别的控制。您提供加密密钥用于数据加密和解密，Amazon S3 无法访问或存储密钥。使用以下 AWS CLI 命令启用 SSE-C：
  css 复制代码
```
aws s3api put-bucket-encryption --bucket YOUR_BUCKET_NAME --server-side-encryption-configuration '{"Rules": [{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm": "AES256"}}], "CustomerAlgorithm": "AES256"}'
```
要为 AWS S3 上的 Apache Iceberg 表配置服务器端加密，可以使用以下表配置属性（这些是 Iceberg 表设置，而不是 AWS 设置）：
- 属性：s3.sse.type
  - 默认值：none
  - 说明：指定要使用的 SSE 类型。可以选择 none、S3、KMS 或 custom。
- 属性：s3.sse.key
  - 默认值：aws/s3（对于 KMS 类型），否则为空
  - 说明：对于 KMS 类型，此属性应设置为 KMS 密钥 ID 或 Amazon 资源名称 (ARN)。对于其他类型，如 custom，您可以提供自定义的 base-64 AES-256 对称密钥。
- 属性：s3.sse.md5
  - 默认值：null
  - 说明：当 SSE 类型设置为 custom 时，此属性应设置为对称密钥的 base-64 MD5 摘要，以确保数据完整性。

存储桶策略

要使用 Amazon S3 存储桶策略在存储桶级别控制访问，请执行以下步骤：

使用 JSON 格式创建存储桶策略，指定访问规则。
使用 AWS 管理控制台或 AWS CLI 将策略附加到您的 S3 存储桶。

以下是允许仅特定 IP 地址访问的策略示例：

json 复制代码

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowSpecificIP",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::YOUR_BUCKET_NAME/*",
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": "YOUR_IP_ADDRESS"
                }
            }
        }
    ]
}

使用 AWS 管理控制台或 AWS CLI 将此策略附加到您的 S3 存储桶：

vbnet 复制代码

aws s3api put-bucket-policy --bucket YOUR_BUCKET_NAME --policy '{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowSpecificIP",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::YOUR_BUCKET_NAME/*",
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": "YOUR_IP_ADDRESS"
                }
            }
        }
    ]
}'

身份和访问管理 (IAM)

使用 AWS 身份和访问管理 (IAM) 创建和管理用户角色和权限以访问您的 S3 资源，请执行以下步骤：
- 根据组织需求创建 IAM 用户、角色或组。
- 定义指定用户可以访问的操作和资源的策略（例如，s3，s3）。
- 将策略附加到 IAM 用户、角色或组，以授予他们访问特定 S3 存储桶或对象的权限。
IAM 策略可以非常精细，允许对操作和资源进行精确控制。

以下是将 IAM 策略附加到特定 IAM 用户的 CLI 命令示例，允许他们读取 (s3

) 和写入 (s3) 特定 S3 存储桶：
css 复制代码
```
aws iam put-user-policy --user-name YOUR_IAM_USER_NAME --policy-name S3AccessPolicy --policy-document '{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::YOUR_BUCKET_NAME/*"
    }
  ]
}'
```
在此示例中，您可以使用 AWS CLI 命令 aws iam put-user-policy 将策略附加到特定的 IAM 用户。通过指定 --policy-name 选项，您可以为策略提供一个名称，以适合您的需求。关键部分是 --policy-document，其中定义了使用 JSON 策略文档的权限。在此特定案例中，该策略授予 IAM 用户执行 s3:GetObject（读取）和 s3:PutObject（写入）操作的权限，适用于位于指定 S3 存储桶内的对象。通过运行此命令，您授予 IAM 用户读取和写入指定 S3 存储桶内对象的权限。请务必用实际的用户名和存储桶名称替换占位符。
对象 ACLs

配置 S3 存储桶中单个数据文件或目录的对象 ACLs 以设置精细的权限。本节提供了如何使用该功能的详细信息。

使用 AWS 管理控制台登录 AWS 管理控制台并导航到 S3 服务。接下来，点击包含��配置 ACL 的对象的存储桶。要定位特定对象，点击其名称或导航目录结构。一旦找到对象，选择它以访问其属性并进行必要的 ACL 配置。

也可以使用 AWS CLI 访问对象的属性。打开终端或命令提示符：
css 复制代码
```
aws s3api put-object-acl --bucket your-bucket-name --key path/to/your-object --acl private --grant-read id="YOUR_IAM_USER_ID"
```
在这个场景中，您可以使用 AWS CLI 命令 aws s3api put-object-acl 调整存储在 AWS S3 存储桶中的对象 ACL。通过指定 --bucket your-bucket-name，您表明对象所在的 S3 存储桶的名称。参数 --key path/to/your-object 表示您希望修改的对象在存储桶内的确切路径。设置 --acl private 可确保 ACL 配置为私有，从而默认仅限所有者访问该对象。通过使用 --grant-read id="YOUR_IAM_USER_ID"，您可以授予指定 IAM 用户读取权限，需用其唯一的 IAM 用户 ID 或 ARN 替换占位符 "YOUR_IAM_USER_ID"。

通过运行此命令，您可以限制访问特定对象，只允许具有提供 ID 的 IAM 用户读取它。您可以根据需要调整该示例以授予不同的权限或指定不同的 IAM 实体。

管理大规模对象 ACLs 可能会变得复杂，特别是当处理众多对象和不同的访问需求时。确保拥有良好定义和文档化的访问控制策略，以避免意外权限和潜在的安全风险。还需考虑使用 IAM 角色和 ACL 的优缺点。

Azure 数据湖存储

在 Azure 数据湖存储 (ADLS) 中保护 Apache Iceberg 表的数据文件，涉及利用各种安全功能，主要围绕加密和控制对文件的访问。本节讨论如何利用这些安全功能。

ADLS 加密

保护 ADLS 中的数据文件涉及对静态数据进行加密，您可以选择默认加密或客户管理的密钥以增强安全性。以下是启用客户管理密钥 (CMEK) 的详细步骤，包括相关的 CLI 命令。

使用 Azure 门户、Azure CLI 或 Azure PowerShell 创建 Azure 密钥保管库：
css 复制代码
```
az keyvault create --name YourKeyVaultName --resource-group YourResourceGroup --location YourLocation
```
用适当的值替换 YourKeyVaultName、YourResourceGroup 和 YourLocation。然后，您可以在密钥保管库中生成加密密钥或导入现有密钥：
css 复制代码
```
az keyvault key create --vault-name YourKeyVaultName --name YourKeyName --kty RSA
```
用适当的值替换 YourKeyVaultName 和 YourKeyName。现在，确保 Azure ADLS 帐户或计划使用的服务主体具有访问 Azure 密钥保管库中的密钥所需的权限。

使用 Azure 门户或 Azure CLI 将 ADLS 帐户与 Azure 密钥保管库链接：
css 复制代码
```
az storage account update --name YourStorageAccountName --resource-group YourResourceGroup --assign-identity [system] --keyvault YourKeyVaultName
```
用适当的值替换 YourStorageAccountName、YourResourceGroup 和 YourKeyVaultName。要维护安全性，只有授权人员应访问 Azure 密钥保管库以进行密钥管理。使用 Azure 门户、Azure CLI 或 Azure PowerShell 配置访问策略，在密钥保管库中添加访问策略，授予适当的权限：
css 复制代码
```
az keyvault set-policy --name YourKeyVaultName --resource-group YourResourceGroup --spn YourServicePrincipalName --key-permissions get list
```
用适当的值替换 YourKeyVaultName、YourResourceGroup 和 YourServicePrincipalName，并指定所需的权限。
基于角色的访问控制 (RBAC)

Azure 中的基于角色的访问控制 (RBAC) 允许您定义和管理谁可以对 ADLS 资源执行操作。以下是详细步骤以及相关的 Azure CLI 命令，用于在 Azure 中实施 RBAC 以用于 ADLS。

使用 Azure 门户、Azure CLI 或 Azure PowerShell 创建 ADLS 帐户：
css 复制代码
```
az dls account create --name YourADLSAccountName --resource-group YourResourceGroup --location YourLocation --tier TierName --encryption-type ServiceManaged
```
用适当的值替换 YourADLSAccountName、YourResourceGroup、YourLocation 和 TierName。Azure 提供适用于 ADLS 资源的预定义角色，如"存储 Blob 数据贡献者"。不过，您也可以根据组织需求创建具有特定权限的自定义角色。

使用 Azure CLI 列出 ADLS 的现有内置角色：
bash 复制代码
```
az role definition list --resource-type Microsoft.DataLakeStore/accounts
```
如果预定义角色不符合您的需求，可以创建自定义角色。定义自定义角色所需的权限：
lua 复制代码
```
az role definition create --role-definition CustomRoleDefinition.json
```
将 CustomRoleDefinition.json 替换为包含自定义角色定义的 JSON 文件。一旦定义了适当的角色，您可以将其分配给用户、组或服务主体，以控制对 ADLS 资源的访问。

使用 Azure CLI 将预定义角色分配给用户、组或服务主体：
bash 复制代码
```
az role assignment create --assignee YourPrincipalName --role "Storage Blob Data Contributor" --scope /subscriptions/YourSubscriptionId/resourceGroups/YourResourceGroup/providers/Microsoft.DataLakeStore/accounts/YourADLSAccountName
```
用适当的值替换 YourPrincipalName、YourSubscriptionId、YourResourceGroup 和 YourADLSAccountName。如果创建了自定义角色，请使用类似命令将其分配。如果需要撤销访问，可以删除角色分配：
bash 复制代码
```
az role assignment delete --assignee YourPrincipalName --role "Storage Blob Data Contributor" --scope /subscriptions/YourSubscriptionId/resourceGroups/YourResourceGroup/providers/Microsoft.DataLakeStore/accounts/YourADLSAccountName
```
访问控制列表 (ACLs)

ADLS 中的 ACLs 提供对单个用户、组或服务主体在目录和文件级别的访问权限的细粒度控制。以下是配置 ADLS 中 ACLs 的详细步骤，包括相关的 Azure CLI 命令。

使用 Azure 门户或 Azure CLI 访问您的 ADLS 帐户。登录 Azure 门户并导航到您的 ADLS 帐户。打开终端或命令提示符：
```
az login
```
使用以下 Azure CLI 命令设置默认订阅（如果尚未设置）：
sql 复制代码
```
az account set --subscription YourSubscriptionName
```
使用 Azure 门户的用户界面浏览并选择所需的目录或文件，定义 ACLs 的访问权限。使用 Azure CLI 为特定目录或文件设置 ACLs：
bash 复制代码
```
az dls fs access set --account YourADLSAccountName --path /your/directory/path --acl-spec "user::rwx,group::r--,other::---"
```
这里是设置文件 ACL 的 Azure CLI 命令：
bash 复制代码
```
az dls fs access set --account YourADLSAccountName --path /your/file/path --acl-spec "user::rw-,group::r--,other::---"
```

Google Cloud Storage

Google Cloud Storage (GCS) 提供的安全功能包括加密、身份和访问管理、存储桶策略和对象 ACLs。本节提供了如何使用这些安全功能的步骤和 CLI 命令。

静态和传输中的加密

GCS 自动使用 SSE 和 Google 管理的密钥对静态数据进行加密。为了增加控制，可以选择客户管理的加密密钥 (CMEK)，您负责管理加密密钥。首先，创建一个云 KMS 密钥环和密钥：
css 复制代码
```
gcloud kms keyrings create your-keyring --location global
gcloud kms keys create your-key --location global --keyring your-keyring --purpose encryption
```
现在，将 CMEK 分配给存储桶：
bash 复制代码
```
gsutil kms authorize -k projects/your-project/locations/global/keyRings/your-keyring/cryptoKeys/your-key
gsutil defacl set private gs://your-bucket-name
```
GCS 确保在传输过程中使用行业标准协议（如 HTTPS）对数据进行加密。
身份和访问管理

Google 云身份和访问管理 (IAM) 允许您控制谁可以访问 GCS 资源并定义他们可以执行的操作。IAM 角色用于分配细粒度的访问控制。以下是创建服务账户并授予其必要权限的代码：
sql 复制代码
```
gcloud iam service-accounts create your-service-account
gcloud projects add-iam-policy-binding your-project --member serviceAccount:your-service-account@your-project.iam.gserviceaccount.com --role roles/storage.objectAdmin
```
使用以下代码作为服务账户进行身份验证以访问 GCS：
ini 复制代码
```
gcloud auth activate-service-account --key-file=your-service-account-key.json
```
存储桶策略

GCS 允许您使用存储桶策略配置存储桶级别的访问控制，这些策略允许您根据 IP 地址、请求者或条件设置访问规则。首先，定义一个 JSON 存储桶策略，指定访问规则：
perl 复制代码
```
{
  "bindings": [
    {
      "role": "roles/storage.objectViewer",
      "members": ["user-email@example.com"]
    }
  ]
}
```
然后将存储桶策略应用于您的存储桶：
arduino 复制代码
```
gsutil iam set your-policy.json gs://your-bucket-name
```
对象 ACLs

GCS 支持桶内单个对象的 ACLs，允许您指定谁可以读取、写入或删除特定对象。使用以下代码配置特定对象的 ACL：
scss 复制代码
```
gsutil acl ch -u user-email@example.com:READ gs://your-bucket-name/your-object
```

通过遵循这些步骤并使用提供的 CLI 命令，您可以有效利用 GCS 对象存储的安全功能，保护 Apache Iceberg 表的数据文件，确保机密性、完整性和受控访问，以满足组织的安全需求。

在语义层进行安全和治理

语义层是您数据湖仓的虚拟抽象层，提供了底层数据的结构化和面向业务的视图。它充当了翻译层，让用户和应用程序可以以直观且对其有意义的方式与数据进行交互，而无需理解数据存储或架构的复杂性。这个层次通过集中控制数据访问、定义细粒度权限和应用数据掩码和转换规则来实现治理和安全。它简化了数据管理，确保数据一致性、质量和符合组织政策，同时屏蔽了用户的底层数据复杂性。语义层使组织能够有效地管理和保护其数据湖仓。

语义层通过预计算聚合指标（例如Dremio的聚合反射）提高了数据的可用性。让我们看看一些可能与Apache Iceberg表一起使用的语义层解决方案。

语义层最佳实践

设计良好且安全的语义层是数据湖仓环境中有效数据治理的基石。在设计这样的层次时，请考虑以下最佳实践：

了解您的数据

首先，深入了解您的数据湖仓中的数据源。识别数据类型、数据所有者和敏感级别。这些信息将为您的数据治理和安全决策提供依据。语义层平台将使您能够对数据进行标签和标记，以帮助明确这些分类。

定义明确的访问控制政策

制定全面的访问控制政策，定义谁可以访问哪些数据以及他们可以执行的操作。使用基于角色的访问控制 (RBAC) 和基于属性的访问控制 (ABAC)，确保只有授权用户可以访问敏感数据。

实施数据掩码

数据掩码可以保护敏感数据。实施掩码规则，确保当未经授权的用户访问数据时，敏感信息被混淆。考虑对诸如个人身份信息 (PII) 等敏感属性进行列级掩码。

维护数据血缘

跟踪语义层内的数据流向。数据血缘有助于理解数据是如何被转换和消费的，这对于确保数据质量和合规性至关重要。

文档化所有内容

维护详细的文档，记录您的数据治理和安全政策、访问控制、目录和血缘。文档对于透明度、合规性和故障排除至关重要。

在语义层级别保护您的Apache Iceberg表时，需要考虑优缺点。积极方面，这一层提供了对数据的统一访问，作为查询的一致入口点，使得标准化数据治理和安全政策成为可能。此外，它还提供数据抽象，简化了终端用户和工具的数据视图，从而方便查询和分析。然而，缺点包括当仅依赖于语义层时可能会成为单点故障，影响查询的可用性。

Dremio

Dremio 语义层为在数据湖仓环境中管理、监控和保护数据提供了强大的解决方案。Dremio 提供了多种功能来治理和保护数据湖仓。

虚拟数据集的数据血缘

Dremio 的语义层允许您创建抽象底层数据复杂性的虚拟数据集。它提供了清晰直观的数据血缘可视化方式，帮助用户理解不同虚拟数据集如何从原始数据派生。这种血缘跟踪对于审计、合规性和理解数据转换历史非常有价值。

内置 wiki 文档

语义层包括内置的 wiki 功能，使得文档化目录、虚拟数据集和文件夹变得容易。文档对于数据治理至关重要，它帮助用户理解数据语义、业务逻辑和数据源信息。通过 Dremio 的 wiki，您可以在数据旁边创建和维护丰富的文档，确保清晰性和透明度。

基于角色、列和行的访问规则

Dremio 的语义层使您能够对数据实施细粒度的访问控制。您可以在多个层次上定义访问规则。

基于角色的访问控制

在 RBAC 层，您可以创建表示不同用户类别的角色。例如，您可以创建角色 analyst、manager 和 admin：

ini 复制代码

CREATE ROLE analyst;
CREATE ROLE manager;
CREATE ROLE admin;

您还可以指定哪些角色应该访问特定数据集或虚拟数据集：

vbnet 复制代码

GRANT SELECT ON VDS_sales_data TO analyst;
GRANT SELECT, UPDATE ON VDS_employee_data TO manager;

并且您可以将个人用户或组映射到定义的角色：

css 复制代码

GRANT analyst TO user1;
GRANT manager TO user2;

通过 RBAC，只有属于授权角色的用户才能与数据集进行交互。例如：

user1，被分配了 analyst 角色，可以访问 VDS_sales_data。
user2，被分配了 manager 角色，可以访问和更新 VDS_employee_data。

基于列的访问控制

基于列的访问控制允许在不同条件成立时掩盖特定列的内容，例如用户具有特定角色。这可以用来帮助隐藏不应访问的敏感 PII，但其他列可以用于分析。在 Dremio 中，这些控制是通过应用用户定义函数 (UDF) 来实现的，这些函数测试某些条件并返回用户应看到的内容：

sql 复制代码

-- 创建 mask_salary UDF
CREATE FUNCTION mask_salary(salary VARCHAR)
RETURNS VARCHAR
RETURN SELECT CASE 
    WHEN query_user()='user@example.com' OR is_member('HR') THEN salary
    ELSE 'XXX-XX'
END;

-- 使用列掩码策略创建 employee_salaries 表
CREATE TABLE employee_salaries (
    id INT,
    salary VARCHAR MASKING POLICY mask_salary (salary),
    department VARCHAR
);

基于行的访问控制

基于行的访问控制允许在不同条件成立时掩盖特定行的内容，例如用户具有特定角色。这可以用来隐藏那些不应访问的记录，但其他行可以用于分析。在 Dremio 中，这些控制是通过应用 UDF 来实现的，这些 UDF 测试某些条件并返回用户应看到的内容：

sql 复制代码

-- 创建 restrict_region UDF
CREATE FUNCTION restrict_region(region VARCHAR)
RETURNS BOOLEAN
RETURN SELECT CASE 
    WHEN query_user()='user@example.com' OR is_member('HR') THEN true
    WHEN region = 'North' THEN true
    ELSE false
END;

-- 使用行访问策略创建 regional_employee_data 表
CREATE TABLE regional_employee_data (
    id INT,
    role VARCHAR,
    department VARCHAR,
    salary FLOAT,
    region VARCHAR,
    ROW ACCESS POLICY restrict_region(region)
);

通过利用这些访问控制机制，您可以确保数据的访问、转换和呈现符合组织的安全和治理政策。

Trino

Trino，前身为 PrestoSQL，是一个开源的分布式 SQL 查询引擎，旨在对各种数据源进行高性能数据处理。Trino 能够通过对您的联邦数据源创建逻辑视图层，控制对这些视图的访问，从而实现语义层。

创建视图时有两种安全模式可供选择：DEFINER 和 INVOKER。

DEFINER

在此安全模式下，视图中引用的表使用视图所有者（创建者或定义者）的权限进行访问。此模式允许您限制对底层表的访问，即使执行查询的用户可能没有直接访问这些表的权限。

INVOKER

在此安全模式下创建视图时，视图中引用的表使用执行查询的用户（调用者）的权限进行访问。在此模式下，视图本质上充当存储的查询。它提供了一种确保对底层数据访问由运行查询的用户确定的方法。

无论选择哪种安全模式，您始终可以在视图中使用 current_user 函数来识别执行查询的用户。这使您可以在视图中实现行级过滤或其他访问限制。

Trino 提供 RBAC 作为其安全模型的关键组件。RBAC 使组织能够通过分配角色给用户并授予这些角色特定权限来管理和控制数据访问。这确保只有授权用户才能对数据执行特定操作，有助于实施数据安全并符合组织政策。

要开始使用 Trino 的 RBAC，您需要创建角色。角色本质上是可以分配给用户或其他角色的命名组。使用 CREATE ROLE 命令创建角色：

ini 复制代码

CREATE ROLE analyst;
CREATE ROLE data_scientist;

在上述示例中，我们创建了两个角色：analyst 和 data_scientist。

创建角色后，您可以使用 GRANT 命令将其分配给用户或其他角色。这允许您定义谁属于哪个角色：

sql 复制代码

GRANT analyst TO USER alice;
GRANT data_scientist TO USER bob;

在这里，我们将 analyst 角色分配给用户 alice，将 data_scientist 角色分配给用户 bob。

Trino 中的角色可以与特定权限相关联，定义用户在这些角色中可以执行的操作。您可以使用 GRANT 命令将权限授予角色，控制表、模式或其他对象上的操作：

vbnet 复制代码

GRANT SELECT ON orders TO analyst;
GRANT INSERT, SELECT ON customer_data TO data_scientist;

在这个示例中，我们授予 analyst 角色在 orders 表上执行 SELECT 查询的权限，并授予 data_scientist 角色在 customer_data 表上执行 INSERT 和 SELECT 操作的权限。

您还可以使用 REVOKE 命令从角色中移除权限或从用户中撤销角色：

sql 复制代码

REVOKE SELECT ON orders FROM analyst;
REVOKE data_scientist FROM USER bob;

这些命令允许您根据需要细化和修改访问控制。

Trino 还允许您指定角色管理员，拥有授予或撤销角色的权限。您可以在创建角色时使用 WITH ADMIN 子句或在授予角色时使用 GRANTED BY 子句：

sql 复制代码

CREATE ROLE admin WITH ADMIN USER admin_user;
GRANT admin TO USER alice GRANTED BY admin_user;

在这个示例中，admin_user 被指定为 admin 角色的角色管理员，admin_user 可以将 admin 角色授予 alice。

RBACs 对于控制组织内的敏感数据访问非常有价值。通过仔细定义角色及其关联的权限，您可以确保只有授权用户才能访问关键信息。

Trino 的 RBACs 提供了一种管理数据访问的方法，使其更容易实施安全策略并在组织内满足合规要求。

在目录级别进行安全和治理

您的数据目录是数据湖仓架构的核心，管理元数据并使查询执行更高效。本节探讨了如何保护和治理Apache Iceberg目录，以便您可以保持对数据资产的控制。

一些Apache Iceberg目录不仅仅跟踪您的Iceberg元数据，还提供了强大的安全功能，可以有效地保护您的Iceberg表。这些安全功能在数据湖仓环境中增强了数据保护和访问控制。

这些安全功能特别有价值的一点是它们在不同查询引擎之间的可移植性。这意味着您在Iceberg目录中定义的安全策略和访问控制可以在各种查询引擎中一致地执行，确保无论如何查询和分析数据，数据安全层都是统一的。这种可移植性简化了安全策略的管理，并在在查询引擎之间转换或在数据生态系统中集成多个工具时最大限度地减少安全漏洞的风险。让我们来看看一些Apache Iceberg目录可能具有的安全功能。

在目录级别保护您的Apache Iceberg表时，有一些优点和缺点需要考虑。积极方面，目录提供了集中化的元数据管理，使得一致的治理政策和基于元数据的安全措施的执行成为可能。此外，它们在该层级支持细粒度的访问控制，赋予对谁可以访问和操作表和数据库的全面权限。此外，目录抽象了底层文件结构，简化了用户和工具的数据访问。然而，缺点包括对目录元数据和访问控制的依赖，这意味着任何目录问题都可能影响数据访问。此外，根据所选择的解决方案，在目录级别管理复杂的访问控制策略可能是一个挑战。随着目录的增长，处理权限和元数据可能变得更加复杂，影响可扩展性。

Nessie

Nessie的元数据授权功能在为您的Apache Iceberg数据湖仓创建可移植治理和安全性方面至关重要。虽然Nessie主要管理元数据，但它提供了一个强大的授权层来控制对这些元数据的访问。需要注意的是，Nessie不直接存储数据，而是管理数据位置和元数据。因此，其授权层主要集中在控制对这些元数据的访问，确保只有授权用户或角色才能与存储在Nessie中的元数据进行交互。

Nessie的授权范围集中在控制对参考（分支和标签）和元数据路径的访问。用户和角色可以获得针对各种参考操作（如查看、创建和分配哈希或删除参考）的特定权限。同样，访问控制也适用于路径，允许在特定参考内执行诸如创建、删除和更新实体内容等操作。

访问历史数据是Nessie的关键功能，允许用户查看不同时间点的数据。然而，需要注意的是，Nessie的授权主要覆盖元数据，应该有额外的安全措施来防止未经授权的对存储在数据湖中的数据的访问。例如，敏感数据应该从表中删除或掩码，并且对数据文件本身应实施适当的访问控制。

Nessie的访问控制模型围绕参考和路径设计，允许对元数据操作进行细粒度控制。用户可以使用公共表达式语言（CEL）表达式定义授权规则，提供了在指定访问控制条件时的灵活性。这些规则定义在application.properties文件中，并与特定操作、角色、参考和路径相关联。例如，可以创建规则来根据各种条件（包括角色和参考名称）授予或拒绝查看、创建、删除或更新参考和实体的权限。

以下是通过application.properties管理对Nessie分支的权限的一些示例代码。

在此示例代码中，具有analyst和viewer角色的用户可以查看（列出）分支和标签：

ini 复制代码

nessie.server.authorization.rules.allow_branch_listing=op=='VIEW_REFERENCE' &&
role in ['analyst', 'viewer']

这里，具有data_admin角色的用户可以创建与正则表达式模式.*prod.*匹配的分支。这允许他们创建名称包含"prod"的分支：

ini 复制代码

nessie.server.authorization.rules.allow_branch_creation=op=='CREATE_REFERENCE' &&
role=='data_admin' && ref.matches('.*prod.*')

在这个代码中，具有data_admin和super_admin角色的用户可以删除分支和标签：

ini 复制代码

nessie.server.authorization.rules.allow_branch_deletion=op=='DELETE_REFERENCE' &&
role in ['data_admin', 'super_admin']

以下代码中，��有analyst和viewer角色的用户可以读取以'data/'开头的路径的实体值：

lua 复制代码

nessie.server.authorization.rules.allow_reading_entity_value=op=='READ_ENTITY_VALUE' &&
role in ['analyst', 'viewer'] && path.startsWith('data/')

这里，具有data_admin角色的用户可以更新或删除路径为'data/sensitive'的实体：

ini 复制代码

nessie.server.authorization.rules.allow_updating_specific_entity=op in ['UPDATE_ENTITY', 'DELETE_ENTITY'] &&
role=='data_admin' && path=='data/sensitive'

总之，Nessie的元数据授权功能通过控制对元数据的访问，为您的Apache Iceberg数据湖仓提供了关键的治理和安全层。通过定义和执行授权规则，组织可以确保只有授权用户和角色可以与元数据进行交互，从而有助于维护数据的完整性和安全性。然而，除了Nessie的元数据授权之外，还需要更广泛的数据湖安全措施来保护存储在湖仓中的实际数据。

Tabular

Tabular是一个云原生的无头数据仓库（一个解耦于任何特定查询引擎或计算的存储管理层）和自动化平台，提供了一个统一的解决方案来管理使用Apache Iceberg表的分析数据。它是Apache Iceberg数据存储和目录的集中中心，重点在于多功能性和效率。Tabular具有一个旨在管理和保护平台资源访问的访问控制框架。我们将概述其关键要素。

Tabular采用RBAC模型，访问权限分配给角色，然后角色分配给个人或其他角色。

角色和权限

角色是授予访问权限的实体，可以分配给个人和其他角色。权限则定义了对资源的访问级别，包括LIST、SELECT、UPDATE等。用户根据其角色获得累积的权限。Tabular系统定义了三个内置角色，可用于定义访问权限：

ORG_ADMIN（组织管理员）

负责监督组织级别的操作，包括重命名和删除组织，管理SECURITY_ADMIN角色内的用户，以及访问使用和计费信息。

SECURITY_ADMIN

管理全局资源授权并创建、监视和管理用户和角色。此角色隐含地拥有MANAGE GRANTS安全权限。

EVERYONE

自动授予组织中的所有个人和角色。此角色在资源上携带固有权限，通常在不需要显式访问控制时使用。

用户可以定义其他角色，而无需特殊权限。这些角色可以装备特定权限以调节资源访问。

AWS Glue 和 Lake Formation

AWS Glue目录允许管理您在AWS上的数据湖仓的元数据。除了其元数据管理功能，AWS Glue目录还通过AWS Lake Formation服务提供强大的安全功能，使组织能够治理和保护其数据湖。

Lake Formation的基于标签的访问控制（TBAC）

AWS Lake Formation的TBAC功能是一种有价值的特性，允许您根据关联的标签控制对存储在AWS Glue数据目录中的表和数据的访问。通过TBAC，您可以使用标签对数据集进行分类并限制访问，从而实施细粒度的访问控制策略。以下是如何使用Lake Formation的TBAC来控制对AWS Glue目录中的表的访问。

使用标签定义数据类别

首先，通过将标签分配给AWS Glue数据目录中的表或其他元数据对象来对数据资源进行分类。标签可以代表各种数据属性，例如敏感级别、数据所有者或项目名称。例如，您可以将一个表标记为"Confidential"，"Finance"或"ProjectA"。

要为表分配标签，您可以使用AWS Glue控制台、AWS CLI或AWS SDK。以下是使用AWS CLI的示例：

css 复制代码

aws glue update-table --database-name mydatabase --table-input '{
    "Name": "mytable",
    "Parameters": {
        "TAGS": {
            "sensitivity": "Confidential",
            "project": "ProjectA"
        }
    }
}'

使用TBAC定义数据访问策略

标记表后，您可以使用AWS Lake Formation基于这些标签定义数据访问策略。访问策略指定了哪些用户或组被允许或拒绝访问基于资源关联的标签的表。

例如，您可以创建一个策略，允许仅"ProjectA-Team"IAM组的成员读取标记为"ProjectA"的表：

json 复制代码

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "lakeformation:GetDataAccess",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "glue:ResourceTag/project": "ProjectA"
                }
            },
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:group/ProjectA-Team"
            }
        }
    ]
}

您可以使用AWS Lake Formation控制台、AWS CLI或AWS SDK创建这样的策略。

将策略应用于数据集

定义访问策略后，您可以将它们应用于AWS Glue数据目录中的数据集。这些策略与特定标签相关联，因此具有匹配标签的表继承这些策略。

AWS Lake Formation将根据这些策略和标签评估访问请求。匹配策略的用户或组将被授予相应表的访问权限，而其他用户将被拒绝访问。

监控和审计访问

AWS Lake Formation提供工具来监控和审计对您的数据资源的访问。您可以使用AWS CloudTrail捕获与数据访问相关的API调用，从而审查谁访问了您的数据以及执行了哪些操作。

定期审核和修改策略

随着时间的推移，您的数据访问需求可能会发生变化。AWS Lake Formation允许您根据需要轻松修改和更新您的访问策略和标签。您可以调整您的策略以适应新的数据类别或访问需求。

与其他AWS服务集成

AWS Lake Formation与其他AWS服务（例如AWS IAM和AWS KMS）无缝集成，为您的数据湖提供额外的安全和加密选项。

通过在AWS Lake Formation中实施TBAC，您可以根据数据资源关联的标签强制执行严格的数据访问控制。此方法确保只有授权用户和组可以访问敏感数据，帮助您在组织中维护数据安全和合规性。

其他安全和治理的考虑事项

在数据湖仓中保护和治理Apache Iceberg表可以在不同的层级进行，每个层级都有其优缺点。这里，我们将探讨在文件存储层级、语义层级和目录层级集中进行安全和治理的优缺点。

当决定将Apache Iceberg表的安全和治理工作重点放在哪个层级时，考虑以下因素：

使用场景

不同的使用场景可能受益于不同层级的安全和治理。例如，高度敏感的数据可能需要目录级别的控制，而敏感性较低的数据可以依赖语义层。

可扩展性

考虑数据湖仓的可扩展性。随着数据的增长，在文件存储层级管理权限和治理策略可能变得更加困难。

性能

评估组织的性能需求。语义层可以优化查询性能，但可能会引入一些开销。

数据抽象

考虑如何抽象和简化终端用户和工具的数据访问。

运营开销

评估每个层级的治理和安全相关的运营开销。

冗余和故障切换

考虑冗余和故障切换机制，以确保可用性和可靠性。

结论

在数据湖仓中保护和治理Apache Iceberg表没有一种万能的方法。选择专注于文件存储层级、语义层级或目录层级应该与组织的具体需求、使用场景和优先级相一致。在许多情况下，结合这些层级可能是实现全面安全和治理的最有效方法。

在第13章，我们将探讨如何将现有数据迁移到Apache Iceberg表中。

Apache Iceberg湖仓的数据治理和安全

保护数据文件

保护文件：最佳实践

Hadoop 分布式文件系统

Amazon Simple Storage Service

Azure 数据湖存储

Google Cloud Storage

在语义层进行安全和治理

语义层最佳实践

了解您的数据

定义明确的访问控制政策

实施数据掩码

维护数据血缘

文档化所有内容

Dremio

虚拟数据集的数据血缘

内置 wiki 文档

基于角色、列和行的访问规则

基于角色的访问控制

基于列的访问控制

基于行的访问控制

Trino

DEFINER

INVOKER

在目录级别进行安全和治理

Nessie

Tabular

角色和权限

ORG_ADMIN（组织管理员）

SECURITY_ADMIN

EVERYONE

AWS Glue 和 Lake Formation

Lake Formation的基于标签的访问控制（TBAC）

使用标签定义数据类别

使用TBAC定义数据访问策略

将策略应用于数据集

监控和审计访问

定期审核和修改策略

与其他AWS服务集成

其他安全和治理的考虑事项

使用场景

可扩展性

性能

数据抽象

运营开销

冗余和故障切换

结论