不管你说什么我都是

去年3月(如果你忘了，这是2019年，感觉不是很久以前了吗？)，我们开放了源码地图，这是我们的Python工具，将技术资产和它们之间的关系整合到一个图形数据库中。

使用图形帮助我们以一种非常强大的方式可视化和推理安全问题。其中一个问题是理解云权限关系：我们需要一个问题的答案：“谁有权读写我的敏感数据资源？”

Lyft是一家AWS商店，AWS的访问控制机制被称为IAM。它确定哪些主体(例如，用户、组和角色)可以对哪些资源(例如，存储桶、计算实例等)执行哪些操作。IAM功能强大、高度可定制，可以跨账户边界工作。IAM很容易配置不正确，这里的错误会使攻击者很容易在您的环境中四处移动并执行恶意操作。

AWS角色、用户和组都附加了策略，这些策略决定了允许他们对一组定义的资源执行或不执行的操作。IAM可能会变得非常复杂：您可以指定高级子句，如NotAction(确定资源不能做什么)或NotResource(确定此语句不适用于哪些资源)。此外，您可以使用*字符将策略应用于与给定文本字符串匹配的对象。主体的最终访问权限由映射到该主体的所有策略语句确定。

作为一个鼓舞人心的例子，我们希望快速了解哪些主体在我们的环境中拥有根权限或“类似根”权限。这样的IAM策略允许它附加到的所有主体具有等同的超级用户权限，因为它允许在任何资源上执行任何操作：

地图学使用Neo4j图形数据库，因此我们可以使用以下查询来搜索以下原则：

匹配(stat:AWSPolicyStatement)--(pol:AWSPolicy)--(principal:AWSPrincipal)WHERE STAT.EFECT="；ALLOW"；ANY(x IN stat.resource WHERE x="；*"；)和ANY(x IN stat.action WHERE x="；*"；)返回*。

如果您查看查询的时间足够长，就会发现这是有意义的：我们查找附加到AWSPolicy节点的PolicyStatement，这些节点附加到AWSPrincipals，其中*既设置为Resource又设置为Action。

结果可能如下所示。如果你自己试一试，如果你不指望任何校长享有高度特权，你可能会遇到一个令人不快的惊喜：

我们有数据很好，但要回答这个问题，需要记住IAM政策评估的所有规则是很麻烦的。如果我们能够简单地问“谁有权从我的存储桶中读取数据”，这将为我们节省大量时间。或“谁有权在我的DynamoDB表上运行查询？”

资源权限关系：使用图表评估主体脱机访问的结果。

有了图表中的所有这些数据，在今年4月初，我们认为离线评估IAM策略是个好主意，这样我们就可以确定给定主体的最终访问权限(对于熟悉Windows安全的人来说，这个计算可能会让您想起RSOP)。我们将此功能称为资源权限关系。

如上所述，我们的计划是让地图绘制自动将AWS主体映射到他们可以访问的资源！这些映射将在PERMISSION_Relationship s.yaml文件中指定，您可以在此处阅读如何进行配置。为了理解它的工作原理，我们将向您介绍上图中的can_read示例：

制图将搜索所有允许S3：GetObject权限的AWSPolicyStatement节点，并查找附加到这些语句的所有AWSPrincipal节点。制图还会验证是否没有其他AWSPolicyStatement节点拒绝S3：GetObject权限。

然后，地图绘制将搜索当前AWS帐户中的所有S3Bucket节点(因为上面将ResourceType指定为S3Bucket)，并从AWSPrincipal到S3Bucket绘制一条标记为Can_Read的图形边。

总之，我们采用了路径(：AWSPrincipal)-->；(：AWSPolicy)-->；(：AWSPolicyStatement{effect："；Allow"；，资源："；S3&34；，操作："；S3：GetObject"；})，根据S3Bucket节点对其进行评估，并将其简化为绘制从主体到S3存储桶的边，如下所示：(：AWSPrincipal)-[：Can_Read]->；(：S3Bucket)。问题是“这个校长被允许做什么？”以及“谁有权访问我的资源？”现在可以按比例查询，因为它们是预先计算并存储在图表中的。

让我们验证一下谁对敏感的S3存储桶拥有读或写权限：

由于已经计算了组扩展，因此这是可以访问敏感S3存储桶的角色和用户的结果集。目前只评估基于身份的策略，我们计划在未来的更新中添加资源策略。

查找个人用户有权访问也很简单，因为地图会同步Okta身份数据：

您还可以查询整个图表上的聚合数据。例如，您的组织中谁可以访问最多数量的S3存储桶？

在开发时，我们知道还有其他与IAM打交道的伟大开源项目，比如Policy Universal和CloudSplaining，但我们还不知道有什么项目能以我们想要的方式进行离线评估。我们发现，与我们的想法最接近的项目是NCC Group的PMapper(太棒了！)，但是PMapper专注于返回单个查询答案，并不能像地图绘制那样生成完整的、可探索的图片。在地图学本身拥有这一逻辑还有更多的好处，我们将在下一个场景中讨论这一点。

您可能已经注意到，在上一节中关于S3存储桶和DynamoDB表，我们只包括了3个RPR，您可能想知道为什么我们没有为所有主体和所有资源执行此策略扩展逻辑，以便图表尽可能完整。这是不可行的，因为AWS有很多内置的IAM策略，这些策略甚至可能不适用于您环境中的任何主体。对所有内容运行此计算都是浪费的，因此我们选择在默认的permission_relationship s.yaml文件中包含一些样例RPR，并允许您根据需要对其进行定制。您可以复制下一节中描述的流程来执行此操作。

最近，我们有一项任务是监控对AWS RedShift实例具有管理员访问权限的IAM主体。这是对Permisse_relationship s.yaml文件的6行简单更改(您可以在此处看到PR)：

此简短配置在图表中搜索允许上述四种操作(redShift：*、redShift：CreateClusterUser等)中任何一种的策略语句。然后，我们会找出当前帐户中的哪些AWS主体附加到这些声明中。最后，我们在(：AWSPrincipal)-[：CAN_ADMINISTER]->；(：RedshiftCluster).形式的当前帐户中绘制一个从每个主体到所有RedShitClusters节点的链接

我们在这里的基本原理是，如果一个身份能够在RedShift集群上执行这四个操作中的任何一个，那么我们将其视为所谓的“RedShift管理员”，并且我们希望从该身份到该集群绘制一个关系，以便我们可以快速地查询它们。

结果如下所示，下面的黄色AWSGroup附加了redShift：*操作，这允许它在所有RedShift集群上执行任何操作。

您可以绘制自己的资源权限关系，方法是将我们的示例复制到您自己的YAML文件中，并在地图命令行界面的--permission-relationship-file参数中指定其绝对路径。

我们已经建立了从AWS主体到敏感红移资源的映射，但正如上面我们的相关工作部分所提到的，这仍然与PMapper的功能略有重复。为什么要把这个融入制图学呢？

现在我们已经丰富了图表中的IAM数据，我们可以使用地图的漂移检测功能，在RedShift管理员列表发生变化时通过松弛警报通知我们，我们应该调查该列表发生变化的原因。如果有兴趣的话，我们会在未来的一篇博文中介绍漂移探测的细节(一旦我们从我们想要构建的其他奇妙想法中脱颖而出)，但作为一个预告片，结果看起来是这样的：

在我们作为开源项目的头一年半时间里，我们已经在几个安全会议上分享了地图绘制，但这是我们第一次在Lyft Engineering博客上发布关于它的博客。理解IAM权限的问题很适合于基于图形的解决方案，而我们只是触及了计划的皮毛。

我们有很多想法来设计一个更可靠的数据同步，加快同步过程，让我们的插件框架对新手更加友好，让数据对更多的人有用。除了提供数据，我们对使用图表进行攻击性和防御性自动化操作感到兴奋：想象一下，有一支机器人大军在你的环境中运行，使用图表作为地图，并修复它发现的所有安全问题。有很多可能性可以充分利用这个想法，我们期待着与开源信息安全社区一起构建这个平台。

我们希望您能发现这篇文章内容丰富，并希望您受到启发，在https://github.com/lyft/cartography.上查看我们的工具

如果您有问题或想联系我们，请在Lyft OSS Slack上的#制图频道或在我们每月的公共社区会议上打个招呼。

加入我们的行列，构建开源工具来大规模解决安全问题；Lyft Security正在招聘！