两年前，也就是2018年11月，AWS公布了新的条件密钥aws：prinalTag和aws：RequestTag，并开始推动基于属性的访问控制(ABAC)概念。这篇文章将描述这是什么，实施这一战略的困难，以及AWS需要做些什么才能让客户成功地使用这一概念。
AWS安全的一个长期问题是，如果您在一个AWS帐户中有两个项目，通常无法确保某些主体(即那里的用户和角色)只能与一个项目的资源交互，而不能与另一个项目的资源交互。为了实现最低权限策略，您需要隔离每个主体只能对某些资源执行的操作，以确保它们不会影响其他项目或从其他项目中导出数据。
许多客户被迫采用的解决方案是将他们的项目隔离到单独的AWS帐户中，但这并不总是理想的。例如，随着帐户的增长，很难采用现有帐户并将资源移动到另一个帐户。因此，AWS开始专注于标记资源并通过标记限制访问。随着时间的推移，许多特权开始能够使用条件键aws：ResourceTag，这样您就可以限制谁可以与现有资源交互。但是，如果您希望主体创建新资源，但限制他们可以使用的标记，这样他们就不能使用另一个项目的标记创建资源，那该怎么办呢？为此，AWS发布了AWS：RequestTag。
如果您有许多主体和项目，并且不想为每个主体和项目创建单独的IAM策略，该怎么办？您需要一个可以应用于所有主体的策略，即“仅与与您拥有的相同标记匹配的资源交互”或“您只能与您创建的资源交互”的公共请求。为了实现这一概念，AWS发布了aws：prinalTag，因此您现在可以使用以下条件：
基于属性的访问控制(ABAC)是一种基于属性定义权限的授权策略，在AWS中属性意味着标签。关于这一概念，最好的两个资源是Brigid Johnson的Re：Inforce Talk Scale Permission Management in AWS w/Attribute-Based Access Control，以及Michael Chan的博客文章Working Backward：从IAM策略和主体标记到AWS资源的标准化名称和标记。
人们在使用ABAC时遇到的第一个问题是，并不是所有的资源都支持标签。在那些支持的资源中，并不是所有的资源都支持IAM条件来限制这些标签。在支持创建的资源中，并不是所有的资源都支持标记，因此您只能限制对现有资源的标记访问，而不对资源进行标记。让我们来了解一下AWS今天的覆盖范围。使用来自议会的IAM数据(只是将AWS文档拼凑到一个json文件中)，我们发现有869个权限包含单词create，我们可以假定这些权限是授予创建资源权限的权限。
$cat议会/iam_finition.json|jq'；.[]|.prefix as$prefix|.Priviles[]|.Privilica as$privilege|select($privilege|ascii_downcase|contains("；create"；))|$prefix+"；："；+$privilege'；|SORT|uniq|wc-l 869。
接下来，我们将查找允许RequestTag条件键的所有权限：
$cat议会/iam_finition.json|jq'；.[]|.prefix as$prefix|.Priviles[]|.Privilica as$privilege|select($privilege|ascii_downcase|contains("；create"；)).resource_types[].condition_keys[]|select(.|ascii_downcase|contains("；requesttag"；))|$prefix+"；："；+$privilege'；|SORT|uniq|wc-l381。
我们发现，在AWS上创建资源的869个权限中，有381个(43%)允许您对新资源进行标记，并限制对其使用的标记。此搜索确实缺少用于创建资源的某些权限，但不包括单词create，例如允许您创建EC2的ec2：RunInstances和允许您创建子域的route53：ChangeResourceRecordSets。它还忽略了AWS具有两个创建资源的权限的情况，即一个权限用于创建带标记的资源，另一个权限不带标记，例如CloudFront：CreateDistribution和CloudFront：CreateDistributionWithTags。然而，43%似乎大致正确。
有人可能会试图争辩说，更广泛使用的资源确实支持在创建和限制那些标记时使用标记，但有些流行的资源并不支持。例如，以下权限都无法限制CREATE上的标签：lambda：CreateFunction、DynamoDB：CreateTable、KMS：CreateKey、Logs：CreateLogGroup、S3：CreateBucket、SQS：CreateQueue"；、IAM：CreateRole。
作为一种技巧，对于不支持在创建时使用标记的资源，您可以使用与标记类似的方式使用资源的名称，但这很尴尬。
在给定AWS账户中的资源的情况下，没有多少可用的工具可以告诉您谁都有权访问它。一些工具(例如。Awspx)会告诉您谁拥有某些特权，但他们不了解条件等细节。例如，他们可以告诉您谁拥有secsmanager：CreateSecret，但不会告诉您谁可以使用标签foo创建秘密。
我通过试图理解更多IAM逻辑的access_check命令在CloudMapper中构建了一些功能。它对条件有一定的了解，也会考虑IAM边界，但是它不理解资源上的现有标记，并且缺乏很多其他功能。对于某些问题，它的答案将比其他工具更正确，但在许多情况下仍然是不正确的。项目PMapper中还包含一些额外的逻辑。
有一个名为SimulatePrincalPolicy的API可用于了解谁有权访问资源，但它缺少许多您期望的功能。例如，您可以将主体的ARN、资源的ARN和要检查的关联权限传递给它，但如果有任何条件，则还必须包括检查时应使用的条件值。这意味着您必须找出资源的标记和资源策略，然后将其传递给此调用。
因此，例如，假设我们有一个主体，它只能对已使用值为foo的项目键进行标记的秘密调用Secretsmanager：GetSecretValue，并且我们有一个带有该标记的秘密。为了检查我们的主体是否可以访问此密码，我们可以运行以下命令：
AWS IAM模拟-主体-策略\--策略-源-ARN ARN：AWS：IAM：：123456789012：用户/测试用户\--操作名称秘密管理器：获取秘密值\--资源-ARNS arn:aws:secretsmanager:us-east-1:123456789012:secret:test-abcdef\--上下文条目ContextKeyName=secretsmanager:ResourceTag/project，上下文键值=foo，上下文键值=字符串。
请注意，在最后一行中，我必须告诉它我希望它检查的资源的标记值。策略模拟器不会为您计算出这一点。因此，如果您要尝试自动执行此操作，则必须执行Describe调用，知道在响应中的什么位置查找标记值，以及如何使用此值格式化对SimulatePrincalPolicy的调用。此外，如果IAM策略具有用于其他权限的不相关的条件键，则您也必须为这些权限提供上下文键。接下来，您必须提供资源策略(如果存在)、IAM边界(如果存在)以及可能的其他数据。
Zelkova是AWS于2017年发布的针对IAM策略的自动化推理解决方案，可供私人测试版使用。当我和人们谈论了解谁有权访问什么的问题时，这个项目经常被那些不熟悉它的确切功能的人作为一个可能的选择。不幸的是，Zelkova是一个引擎，你仍然需要弄清楚它的输入。它可以回答一些与IAM相关的问题，但是对于我们了解谁有权访问哪些内容的目标而言，它与IAM：SimulatePrincialPolicy具有相同的限制。
AWS组织的一项称为标记策略的功能本应帮助强制执行标记，但它受到严重限制，因为它只能在使用定义的标记键时强制执行可能使用的标签值。这意味着您不能强制标记资源。只有当有人试图用某个键标记资源时，才能强制要求该值是定义的集合中的一个。为了强制在组织中实际使用标记，您必须按照此处所述使用SCP。
此外，标签策略并不涵盖支持标签的所有资源。支持的资源列表在此处。支持标签但不受标签策略支持的资源的一个示例是S3对象。
AWS需要扩展此功能的功能，以支持强制使用标签密钥，因为其当前形式没有什么价值。
人们经常处理多个项目，但是无法使用具有多个标记值的键来标记主体。例如，假设您有两个项目，foo和bar，并且您希望允许一个人只处理foo，并且他们创建的所有资源都应该有一个值为foo的Project标记，同样，您还有一个人应该只处理bar项目。AWS已经展示了如何创建可应用于两个人的单一IAM策略，您只需确保将项目标签应用到委托人，以定义他们可以处理的项目。
现在假设这些员工中的一个需要同时处理这两个项目。不能同时使用foo和bar标记主体。一种解决方案是让人员根据他们从事的项目承担不同的IAM角色。另一种选择是为此人创建自定义IAM策略，该策略对他们可以处理的项目进行硬编码，从而停止在这些项目上使用主体标签。这两个选择似乎都不理想。
AWS有一个可传递标签的概念，当实体在不同角色之间承担时，这些标签将跟随在实体后面，这可以帮助审计会话。它们有用于创建会话的可传递标记，但没有用于其他资源的可传递标记。如果可以将此概念应用于它们创建的任何资源，这样EC2和其他资源在创建时就会以某种方式自动标记，而无需用户指定这些标记，那就太好了。因此，如果用户是foo项目的一部分，他们创建的所有资源都会自动标记为foo的一部分。
AWS以外的其他人也写到了ABAC的限制和困难，触及了他们遇到的其他问题：
伊恩·麦凯(Ian McKay)所著的“ABAC的早期日子”描述了他发现的一个bug，他可以在那里标记资源，尽管他没有这样做的特权。
不要使用标签来管理AWS中的权限，作者Rowan Udell指出了标签的可用性问题。
创建正确的IAM策略来实施标记是困难的。由于IAM的限制，有些目标是不可能的，有些目标是尴尬的。各种资源类型的限制并不是恒定的，这些差异增加了复杂性。在某些情况下，可以基于标记定义权限，但不是所有情况下都可以，因此在尝试采用此策略时要小心。AWS缺乏全公司范围的指导和标准化，这经常让客户感到沮丧。
具有相对简单解决方案的AWS上最大的问题之一是了解环境的工具，例如谁有权访问哪些资源。我希望AWS能够增加在这方面的投资，例如通过改进SimulatePrincalPolicy API来自动计算出呼叫中涉及的条件。在他们这样做之前，或者其他人这样做之前，尝试基于标签定义权限将是不必要的困难，出于各种原因，您安全边界的最佳策略将继续是使用单独的AWS帐户。
如果您有兴趣了解更多关于AWS安全的知识，我提供培训，包括远程培训！