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

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

Tag-based 访问控制 (TBAC) 允许您使用 Amazon 资源标签和 IAM 委托人标签作为 IAM 策略和服务控制策略 (SCP) 中的条件来控制对 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 添加了一个基于属性的授权层，该层与所有授权层并驾齐驱：


**Neptune 安全层以及 TBAC 如何补充它们**  

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

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

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

资源标签  
使用附加到 Neptune 数据库集群的标签。`AddTagsToResource`它们会传播到集群中的所有实例，以进行数据平面策略评估。

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

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

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

在将 TBAC 与 Neptune 数据平面操作配合使用之前，必须具备以下条件：

1. Nep@@ **tune 引擎版本 1.2.0.0 或更高版本** — 需要支持数据平面 TBAC。

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

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

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

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

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

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

这是最常见的 TBAC 模式。除非主体的标签与资源的标签匹配，否则它会拒绝所有 Neptune 数据平面操作。您可以将其作为 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`只能访问也被标记的 Neptune 集群`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`条件的计算结果为 true。这会迫使所有 Neptune 集群携带所需的分类标签，然后任何主体才能访问它们。

### 将 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"
        }
      }
    }
  ]
}
```

## 为 Neptune 实现 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>

使用使用与您的 Neptune 集群相同的密钥和值来标记 IAM 角色。 Amazon CLI 对于 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`，只有当*所有*指定条件同时为真时，才会触发 “拒绝”。要拒绝*任何*单个标签不匹配，请对每个标签密钥使用单独的策略声明（如上面的模式所示）。

## 与现有 Neptune 安全功能的关系
<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:\*操作） | 谁能管理 Neptune 基础架构 | TBAC 将相同的基于标签的模式扩展到数据平面 () 操作 neptune-db:\* | 
| Amazon KMS 加密 | 静态数据机密性 | 正交 — TBAC 控制授权，而不是加密 |