本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# Amazon Keyspaces 基于身份的策略示例
默认情况下，IAM 用户和角色没有创建或修改 Amazon Keyspaces 资源的权限。他们也无法使用控制台、CQLSH 或 AWS API 执行任务。 AWS CLI IAM 管理员必须创建 IAM 策略，以便为用户和角色授予权限以对所需的指定资源执行特定的 API 操作。然后，管理员必须将这些策略附加到需要这些权限的 IAM 用户或组。
要了解如何使用这些示例 JSON 策略文档创建 IAM 基于身份的策略，请参阅《*IAM 用户指南*》中的[在 JSON 选项卡上创建策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor)。
**Topics**
+ [策略最佳实践](#security_iam_service-with-iam-policy-best-practices)
+ [使用 Amazon Keyspaces 控制台](#security_iam_id-based-policy-examples-console)
+ [允许用户查看他们自己的权限](#security_iam_id-based-policy-examples-view-own-permissions)
+ [访问 Amazon Keyspaces 表](#security_iam_id-based-policy-examples-access-one-table)
+ [基于标签的 Amazon Keyspaces 资源访问](#security_iam_id-based-policy-examples-tags)
## 策略最佳实践
基于身份的策略确定某个人是否可以创建、访问或删除您账户中的 Amazon Keyspaces 资源。这些操作可能会使 AWS 账户产生成本。创建或编辑基于身份的策略时，请遵循以下指南和建议：
+ **开始使用 AWS 托管策略并转向最低权限权限** — 要开始向用户和工作负载授予权限，请使用为许多常见用例授予权限的*AWS 托管策略*。它们在你的版本中可用 AWS 账户。我们建议您通过定义针对您的用例的 AWS 客户托管策略来进一步减少权限。有关更多信息，请参阅《IAM 用户指南》**中的 [AWS 托管策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)或[工作职能的AWS 托管策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)。
+ **应用最低权限**：在使用 IAM 策略设置权限时，请仅授予执行任务所需的权限。为此，您可以定义在特定条件下可以对特定资源执行的操作，也称为*最低权限许可*。有关使用 IAM 应用权限的更多信息，请参阅《IAM 用户指南》**中的 [IAM 中的策略和权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)。
+ **使用 IAM 策略中的条件进一步限制访问权限**：您可以向策略添加条件来限制对操作和资源的访问。例如，您可以编写策略条件来指定必须使用 SSL 发送所有请求。如果服务操作是通过特定的方式使用的，则也可以使用条件来授予对服务操作的访问权限 AWS 服务，例如 CloudFormation。有关更多信息，请参阅《IAM 用户指南》**中的 [IAM JSON 策略元素：条件](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)。
+ **使用 IAM Access Analyzer 验证您的 IAM 策略，以确保权限的安全性和功能性**：IAM Access Analyzer 会验证新策略和现有策略，以确保策略符合 IAM 策略语言（JSON）和 IAM 最佳实践。IAM Access Analyzer 提供 100 多项策略检查和可操作的建议，以帮助您制定安全且功能性强的策略。有关更多信息，请参阅《IAM 用户指南》**中的[使用 IAM Access Analyzer 验证策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html)。
+ **需要多重身份验证 (MFA**)-如果 AWS 账户您的场景需要 IAM 用户或根用户，请启用 MFA 以提高安全性。若要在调用 API 操作时需要 MFA，请将 MFA 条件添加到您的策略中。有关更多信息，请参阅《IAM 用户指南》**中的[使用 MFA 保护 API 访问](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)。
有关 IAM 中的最佳实操的更多信息，请参阅《IAM 用户指南》**中的 [IAM 中的安全最佳实践](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)。
## 使用 Amazon Keyspaces 控制台
Amazon Keyspaces 不要求您具备特定权限才能访问 Amazon Keyspaces 控制台。您至少需要具有只读权限才能列出和查看您的 Amazon Keyspaces 资源的详细信息。 AWS 账户如果您创建的基于身份的策略比所需的最低权限更严格，则无法为具有该策略的实体（IAM 用户或角色）正常运行控制台。
两个 AWS 托管策略可供实体使用 Amazon Keyspaces 控制台访问权限。
+ [AmazonKeyspacesReadOnlyAccess\$1v2](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonKeyspacesReadOnlyAccess_v2.html) — 此政策授予对 Amazon Keyspaces 的只读访问权限。
+ [AmazonKeyspacesFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonKeyspacesFullAccess.html)— 此政策授予使用 Amazon Keyspaces 的权限，并具有对所有功能的完全访问权限。
有关 Amazon Keyspaces 托管式策略的更多信息，请参阅 [AWS Amazon Keyspaces 的托管策略](security-iam-awsmanpol.md)。
## 允许用户查看他们自己的权限
该示例说明了您如何创建策略，以允许 IAM 用户查看附加到其用户身份的内联和托管式策略。此策略包括在控制台上或使用 AWS CLI 或 AWS API 以编程方式完成此操作的权限。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
## 访问 Amazon Keyspaces 表
**注意**
要访问 Amazon Keyspaces 中的用户密钥空间和表，您的 IAM 策略必须`cassandra:Select`包含对系统表的权限：
```
arn:${Partition}:cassandra:${Region}:${Account}:/keyspace/system*
```
这适用于以下场景：
AWS 管理控制台访问权限
SDK 资源操作`GetKeyspace`，例如`GetTable``ListKeyspaces`、和 `ListTables`
标准 Apache Cassandra 客户端驱动程序连接，因为驱动程序会在连接初始化期间自动读取系统表
系统表是只读的，无法修改。
以下是授予对 Amazon Keyspaces 系统表的只读（`SELECT`）访问权限的示例策略。对于所有示例，请将 Amazon 资源名称（ARN）中的区域和账户 ID 替换为您自己的区域和账户 ID。
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"cassandra:Select"
],
"Resource":[
"arn:aws:cassandra:us-east-1:111122223333:/keyspace/system*"
]
}
]
}
```
以下示例策略添加对键空间 `mykeyspace` 中的用户表 `mytable` 的只读访问权限。
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"cassandra:Select"
],
"Resource":[
"arn:aws:cassandra:us-east-1:111122223333:/keyspace/mykeyspace/table/mytable",
"arn:aws:cassandra:us-east-1:111122223333:/keyspace/system*"
]
}
]
}
```
以下示例策略分配了对用户表的 read/write 访问权限和对系统表的读取权限。
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"cassandra:Select",
"cassandra:Modify"
],
"Resource":[
"arn:aws:cassandra:us-east-1:111122223333:/keyspace/mykeyspace/table/mytable",
"arn:aws:cassandra:us-east-1:111122223333:/keyspace/system*"
]
}
]
}
```
以下示例策略允许用户在键空间 `mykeyspace` 中创建表。
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"cassandra:Create",
"cassandra:Select"
],
"Resource":[
"arn:aws:cassandra:us-east-1:111122223333:/keyspace/mykeyspace/*",
"arn:aws:cassandra:us-east-1:111122223333:/keyspace/system*"
]
}
]
}
```
以下示例策略分配了对系统表的读取权限，但限制了对用户表的`SELECT`（读取）和`MODIFY`（写入）访问权限。`mytable`
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cassandra:Select"
],
"Resource": [
"arn:aws:cassandra:us-east-1:111122223333:/keyspace/system*"
]
},
{
"Effect": "Deny",
"Action": [
"cassandra:Select",
"cassandra:Modify"
],
"Resource": [
"arn:aws:cassandra:us-east-1:111122223333:/keyspace/mykeyspace/table/mytable"
]
}
]
}
```
## 基于标签的 Amazon Keyspaces 资源访问
您可以在基于身份的策略中使用条件，以便基于标签控制对 Amazon Keyspaces 资源的访问。这些策略控制账户中键空间和表的可见性。请注意，与通过 Cassandra 驱动程序和开发者工具调用 Cassandra 查询语言 (CQL) API 相比，使用 AWS SDK 发出请求时，基于标签的系统表权限的行为有所不同。
+ 要在使用基于标签的访问权限时使用 AWS SDK 发出 `List` 和 `Get` 请求，调用者需要具有对系统表的读取权限。例如，需要 `Select` 操作权限才能通过 `GetTable` 操作从系统表读取数据。如果调用者对特定表只有基于标签的访问权限，则需要对系统表进行额外访问的操作将失败。
+ 为了与既定的 Cassandra 驱动程序行为兼容，当您通过 Cassandra 驱动程序和开发人员工具使用 Cassandra 查询语言 (CQL) API 调用对系统表执行操作时，系统不会强制实施基于标签的授权策略。
以下示例说明如何创建一个策略，该策略授予用户查看表的权限（如果表的 `Owner` 包含该用户的用户名的值）。在此示例中，您还授予对系统表的读取权限。
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"ReadOnlyAccessTaggedTables",
"Effect":"Allow",
"Action":"cassandra:Select",
"Resource":[
"arn:aws:cassandra:us-east-1:111122223333:/keyspace/mykeyspace/table/*",
"arn:aws:cassandra:us-east-1:111122223333:/keyspace/system*"
],
"Condition":{
"StringEquals":{
"aws:ResourceTag/Owner":"${aws:username}"
}
}
}
]
}
```
您可以将该策略附加到您账户中的 IAM 用户。如果一个名为 `richard-roe` 的用户尝试查看 Amazon Keyspaces 表，则您必须为该表添加 `Owner=richard-roe` 或 `owner=richard-roe` 标签。否则，他将被拒绝访问。条件标签键 `Owner` 匹配 `Owner` 和 `owner`，因为条件键名称不区分大小写。有关更多信息，请参阅*《IAM 用户指南》*中的 [IAM JSON 策略元素：条件](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)。
以下策略授予用户创建带有标签的表的权限（如果表的 `Owner` 包含该用户的用户名的值）。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "CreateTagTableUser",
"Effect": "Allow",
"Action": [
"cassandra:Create",
"cassandra:TagResource"
],
"Resource": "arn:aws:cassandra:us-east-1:111122223333:/keyspace/mykeyspace/table/*",
"Condition":{
"StringEquals":{
"aws:RequestTag/Owner":"${aws:username}"
}
}
}
]
}
```