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

# Tag-based 亚马逊海王星数据平面操作的访问控制
<a name="iam-data-tbac"></a>

Tag-based 访问控制 (TBAC) 允许您在 IAM 策略和服务控制策略 (SCP) 中使用 Amazon 资源标签和 IAM 委托人标签作为条件来控制对 Amazon Neptune 数据平面操作的访问权限。使用 TBAC，您可以强制只有标签与 Neptune 数据库集群上的标签匹配的委托人才能对该集群执行`neptune-db:*`操作，而无需在每个策略中列举特定的集群 Amazon 资源名称 (ARN)。

TBAC 建立在 Neptune 现有的安全模型基础上，对[基于操作的访问控制数据平面操作进行了补充。](iam-dp-actions.md)

## TBAC 如何融入海王星的安全层
<a name="iam-data-tbac-security-layers"></a>

Neptune 通过多种重叠的安全机制保护您的数据。TBAC 添加了一个基于属性的授权层，可与所有这些层一起使用：


**海王星安全层以及TBAC如何对其进行补充**  

| 层 | 机制 | Scope | 
| --- | --- | --- | 
| 网络隔离 | 虚拟私有云 (VPC)、安全组、VPC 终端节点 (PrivateLink) | 控制哪些主机可以到达 Neptune 端点 | 
| 加密 | 传输层安全 (TLS) 1.3 正在传输中； Amazon KMS-托管静态加密 | 保护数据机密性 | 
| IAM 身份验证 | Amazon 签名版本 4 (SigV4) 对 Neptune 数据端点的签名请求 | 对呼叫者进行身份验证 | 
| Action-based 访问控制 | neptune-db:动作（ReadDataViaQueryWriteDataViaQuery、等） | 控制委托人可以执行的操作 | 
| 条件键 | neptune-db:QueryLanguage，全局上下文密钥 | 为策略添加上下文限制 | 
| TBAC | aws:ResourceTag/${TagKey}评估依据 aws:PrincipalTag/${TagKey} | 根据主体和资源之间的标签对齐来限制访问权限 | 
| 基于管理标签的访问权限 | aws:ResourceTag，等等rds:cluster-tag，关于管理层面的行动 | 控制谁可以管理 Neptune 基础设施 | 

## 关键的 TBAC 概念
<a name="iam-data-tbac-concepts"></a>

主要标签  
附加到 IAM 用户、角色或联合会话委托人的标签。您可以通过 IAM 控制台或身份提供商 (IdP) 安全断言标记语言 (SAML) /OpenID Connect (OIDC) 属性映射进行设置。 Amazon CLI

资源标签  
使用标签附加到海王星数据库集群。`AddTagsToResource`它们传播到集群中的所有实例，用于数据平面策略评估。

条件关键变量  
+ `aws:PrincipalTag/{{TagKey}}`— 解析为调用主体上的标签值。
+ `aws:ResourceTag/{{TagKey}}`— 解析为目标海王星资源上的标签值。

支持的策略类型  
+ **IAM 身份政策 ** — 附加到用户、群组或角色。
+ **SCP ** — 应用于组织 Amazon 组织单位 (OU) 或账户级别来设置权限护栏。

## 使用 TBAC 的先决条件
<a name="iam-data-tbac-prerequisites"></a>

在使用 TBAC 进行 Neptune 数据平面操作之前，必须具备以下条件：

1. **海王星引擎版本 1.2.0.0 或更高版本 ** — 支持数据平面 TBAC 所必需。

1. **在 Neptune 数据库**集群上启用 IAM 身份验证。

1. **应用于 Neptune 数据库集群的标签 ** — 策略将评估的资源标签。

1. **应用于 IAM 委托人的标签 ** ——将与资源标签进行比较的主体标签。

## TBAC 政策模式
<a name="iam-data-tbac-patterns"></a>

以下模式显示了在海王星数据平面操作的 IAM 策略中使用 TBAC 的常用方法。

### 当主体和资源标签不匹配时拒绝访问
<a name="iam-data-tbac-pattern-deny-mismatch"></a>

这是最常见的 TBAC 模式。除非主体的标签与资源的标签相匹配，否则它拒绝所有海王星数据平面操作。您可以将其用作 SCP 进行组织范围的强制执行，也可以将其用作 IAM 策略进行定向控制。

```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNeptuneProjectMismatch",
      "Effect": "Deny",
      "Action": "neptune-db:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:ResourceTag/Project": "${aws:PrincipalTag/Project}"
        }
      }
    },
    {
      "Sid": "DenyNeptuneDepartmentMismatch",
      "Effect": "Deny",
      "Action": "neptune-db:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:ResourceTag/Department": "${aws:PrincipalTag/Department}"
        }
      }
    }
  ]
}
```

**工作原理：**每条语句对单个标签密钥使用单独的`StringNotEquals`条件。每个标签都会单独触发 “拒绝” ——如果资源的`Project`标签与主体的标签不匹配，则无论`Project`标签如何，访问都将被拒绝。`Department`这样可以确保标有的主体`Project=FraudDetection`只能访问也带有标签的海王星集群`Project=FraudDetection`，同样。`Department`

### 缺少所需资源标签时拒绝访问
<a name="iam-data-tbac-pattern-deny-missing"></a>

此模式可防止访问未正确标记的 Neptune 集群，从而确保所有集群都注册到 TBAC 方案中：

```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNeptuneMissingProjectTag",
      "Effect": "Deny",
      "Action": "neptune-db:*",
      "Resource": "*",
      "Condition": {
        "Null": {
          "aws:ResourceTag/Project": "true"
        }
      }
    },
    {
      "Sid": "DenyNeptuneMissingDepartmentTag",
      "Effect": "Deny",
      "Action": "neptune-db:*",
      "Resource": "*",
      "Condition": {
        "Null": {
          "aws:ResourceTag/Department": "true"
        }
      }
    }
  ]
}
```

**工作原理：**当资源上不存在指定的标签密钥时，`Null`条件的计算结果为真。这迫使所有海王星星团在任何主体都可以访问它们之前携带所需的分类标签。

### 将 TBAC 与基于操作的访问控制相结合
<a name="iam-data-tbac-pattern-combined-actions"></a>

TBAC 可以与特定`neptune-db:`操作相结合，以创建精细的标签感知策略：

```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowReadOnlyForMatchingTags",
      "Effect": "Allow",
      "Action": [
        "neptune-db:ReadDataViaQuery",
        "neptune-db:GetQueryStatus",
        "neptune-db:GetEngineStatus"
      ],
      "Resource": "arn:aws:neptune-db:*:*:*/*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Project": "${aws:PrincipalTag/Project}"
        }
      }
    }
  ]
}
```

### 使用 TBAC 进行查询语言限制
<a name="iam-data-tbac-pattern-query-language"></a>

将 TBAC 与`neptune-db:QueryLanguage`条件键结合使用，以限制主体可以访问的集群以及他们可以使用哪些查询语言：

```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowOpenCypherOnlyForMatchingProject",
      "Effect": "Allow",
      "Action": [
        "neptune-db:ReadDataViaQuery",
        "neptune-db:WriteDataViaQuery"
      ],
      "Resource": "arn:aws:neptune-db:*:*:*/*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Project": "${aws:PrincipalTag/Project}",
          "neptune-db:QueryLanguage": "OpenCypher"
        }
      }
    }
  ]
}
```

## 将 TBAC 与服务控制策略一起使用
<a name="iam-data-tbac-scps"></a>

SCP 是执行 TBAC 的理想之选，因为它们无需更改个人 IAM 策略即可跨整个组织单位 (OU) 或账户设置权限边界。

我们建议采用以下 SCP 策略：

1. 在 OU 级别应用一个 Deny-based SCP，`neptune-db:*`当标签不匹配时会屏蔽。

1. 应用第二条语句拒绝访问未标记的资源。

1. 您的个人账户可以保留其允许政策以执行特定`neptune-db:`操作，SCP 充当护栏。

```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNeptuneProjectMismatch",
      "Effect": "Deny",
      "Action": "neptune-db:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:ResourceTag/Project": "${aws:PrincipalTag/Project}"
        }
      }
    },
    {
      "Sid": "DenyNeptuneDepartmentMismatch",
      "Effect": "Deny",
      "Action": "neptune-db:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:ResourceTag/Department": "${aws:PrincipalTag/Department}"
        }
      }
    },
    {
      "Sid": "DenyNeptuneMissingProjectTag",
      "Effect": "Deny",
      "Action": "neptune-db:*",
      "Resource": "*",
      "Condition": {
        "Null": {
          "aws:ResourceTag/Project": "true"
        }
      }
    },
    {
      "Sid": "DenyNeptuneMissingDepartmentTag",
      "Effect": "Deny",
      "Action": "neptune-db:*",
      "Resource": "*",
      "Condition": {
        "Null": {
          "aws:ResourceTag/Department": "true"
        }
      }
    }
  ]
}
```

## 为海王星实现 TBAC
<a name="iam-data-tbac-implementation"></a>

### 第 1 步：定义您的标签分类
<a name="iam-data-tbac-step-taxonomy"></a>

选择代表组织边界的标签密钥。常见模式：


**标签分类法示例**  

| 标签键 | 用途 | 示例值 | 
| --- | --- | --- | 
| Project | 应用程序或工作负载标识符 | FraudDetection, RecommendationEngine | 
| Department | 业务单位或成本中心 | Engineering, Finance, Analytics | 
| Environment | 部署阶段 | production, staging, development | 
| Team | 拥有的球队 | graph-platform, data-science | 

### 第 2 步：标记您的 Neptune 数据库集群
<a name="iam-data-tbac-step-tag-clusters"></a>

使用 Amazon CLI 向您的 Neptune 数据库集群添加所需的分类标签：

```
aws neptune add-tags-to-resource \
  --resource-name arn:aws:rds:{{us-east-1}}:{{123456789012}}:cluster:{{my-neptune-cluster}} \
  --tags Key=Project,Value=FraudDetection Key=Department,Value=Engineering
```

### 第 3 步：标记您的 IAM 委托人
<a name="iam-data-tbac-step-tag-principals"></a>

使用标记 IAM 角色 Amazon CLI ，其密钥和值与 Neptune 集群上使用的密钥和值相同。对于 IAM 角色：

```
aws iam tag-role \
  --role-name {{NeptuneAppRole}} \
  --tags Key=Project,Value=FraudDetection Key=Department,Value=Engineering
```

对于联合用户，使用身份提供商的`aws:PrincipalTag`属性通过 SAML/OIDC 会话标签传递标签。

### 第 4 步：部署 TBAC 策略
<a name="iam-data-tbac-step-deploy"></a>

作为 SCP 附加，用于组织范围内的执法，或作为 IAM 策略进行定向控制。

### 第 5 步：保护标签完整性
<a name="iam-data-tbac-step-protect-tags"></a>

限制谁可以修改 Neptune 资源和 IAM 委托人的标签：

```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyTagModification",
      "Effect": "Deny",
      "Action": [
        "rds:AddTagsToResource",
        "rds:RemoveTagsFromResource"
      ],
      "Resource": "*",
      "Condition": {
        "ForAnyValue:StringEquals": {
          "aws:TagKeys": ["Project", "Department"]
        }
      }
    }
  ]
}
```

## TBAC 的重要注意事项
<a name="iam-data-tbac-considerations"></a>
+ **传播延迟 ** — IAM 策略的更改最多需要 10 分钟才能应用于 Neptune 资源。对集群标签的更改（添加、修改或删除标签）大约需要 5 分钟才能传播到数据平面策略评估。在更新活动集群上的标签时，请为这种延迟做好计划。
+ **Cluster-level 粒度 ** — 您可以在集群级别将标签应用于 Neptune 数据库集群。集群中的所有实例共享相同的策略评估。TBAC 不提供子图或 vertex/edge级别访问控制。
+ **需要 IAM 身份验证 ** — TBAC 仅在集群上启用 IAM 身份验证时适用。没有 IAM 身份验证的连接完全绕过这些策略。
+ **标签不变性 ** — 保护您的标记操作。如果委托人可以修改自己的标签或资源标签，则可以避开 TBAC 控制。使用 SCP 或权限边界限制`iam:TagRole`、`iam:TagUser``rds:AddTagsToResource`、和。`rds:RemoveTagsFromResource`
+ **空标签处理 **-如果委托人缺少策略引用的标签`${aws:PrincipalTag/{{Key}}}`，则变量将解析为空字符串。设计您的策略以应对这种情况（上面的 “缺失标签” 拒绝模式解决了资源标签的这个问题）。
+ **多个条件键 **-当多个条件键出现在同一个`Condition`块中时，将使用 AND 逻辑对它们进行求值。对于`StringNotEquals`，只有在*所有*指定条件同时为真时才会触发 “拒绝”。要拒绝*任何*单一标签不匹配，请对每个标签密钥使用单独的策略声明（如上面的模式所示）。

## 与现有海王星安全功能的关系
<a name="iam-data-tbac-relationship"></a>


**TBAC 如何补充现有的 Neptune 安全功能**  

| 现有功能 | 它控制什么 | TBAC 如何对其进行补充 | 
| --- | --- | --- | 
| VPC/安全组 | Network-level 访问端口 8182 | TBAC 在网络控制之上增加了身份感知授权 | 
| IAM 身份验证 (SigV4) | 验证来电者身份 | TBAC 使用经过身份验证的标签进行授权决策 | 
| Action-based 访问控制 | 委托人可以执行哪些操作 (read/write/delete/load) | TBAC 根据标签对齐添加主体可以瞄准哪些集群 | 
| neptune-db:QueryLanguage 条件键 | 允许使用哪些查询语言（Gremlin、OpenCypher、SPARQL） | 可以在同一政策声明中与 TBAC 结合使用 | 
| 基于管理标签的访问权限（rds:\*操作） | 谁可以管理海王星基础设施 | TBAC 将相同的基于标签的模式扩展到数据平面 () 操作 neptune-db:\* | 
| Amazon KMS 加密 | 静态数据机密性 | Orthogonal—TBAC 控制授权，而不是加密 |