根据云计算权威组织云安全联盟(CSA)对241位行业专家的最新调查，云计算资源配置错误是导致组织数据泄露的主要原因。那么造成这种风险的主要原因是什么?由于数据规模巨大，因此在云中管理身份及其权限极具挑战性。它 ...
|
那么造成这种风险的主要原因是什么?由于数据规模巨大，因此在云中管理身份及其权限极具挑战性。它不仅仅是人们的用户身份，还包括设备、应用程序和服务。由于这种复杂性，许多组织都会出错。 随着时间的推移，这个问题变得越来越严重，因为很多组织在没有建立有效分配和管理权限的能力的情况下扩展了他们的云计算规模。因此，用户和应用程序往往会积累远远超出技术和业务要求的权限，从而造成较大的权限差距。 例如，美国国防部的一个军事数据库于2017年对外泄露，这个数据库是美国中央司令部(CENTCOM)和太平洋司令部(PACOM)从社交媒体、新闻网站、论坛和其他公开网站上搜集的18亿条以上互联网帖子，而美国国防部这两个统一作战司令部负责美国在中东地区、亚洲和南太平洋地区的军事行动，它配置了三个AWS S3云存储桶，允许任何经过AWS全球认证的用户浏览和下载内容，而这种类型的AWS帐户可以通过免费注册获得。 关注权限 为了减轻与滥用云中身份有关的风险，组织正在尝试实施最小特权原则。在理想情况下，应将每个用户或应用程序限制为所需的确切权限。 从理论上讲，这个过程应该很简单。第一步是了解已为给定用户或应用程序分配了哪些权限。接下来，应该对实际使用的那些权限进行清点。两者的比较揭示了权限差距，即应保留哪些权限以及应修改或删除哪些权限。 这可以通过几种方式来完成。认为过多的权限可以删除或监视并发出警报。通过不断地重新检查环境并删除未使用的权限，组织可以随着时间的推移在云中获得最少的特权。 但是，在复杂的云计算环境中确定每个应用程序所需的精确权限所需的工作可能既费力又昂贵。 了解身份和访问管理(IAM)控件 以全球最流行的AWS云平台为例，该平台提供了可用的最精细身份和访问管理(IAM)系统之一。AWS IAM是一个功能强大的工具，使管理员可以安全地配置对AWS云计算资源的访问。身份和访问管理(IAM)控件拥有2,500多个权限(并且还在不断增加)，它使用户可以对在AWS云平台中的给定资源上执行哪些操作进行细粒度控制。 毫不奇怪，这种控制程度为开发人员和DevOps团队带来了相同(可能有人说更高)的复杂程度。 在AWS云平台中，其角色作为机器身份。需要授予特定于应用程序的权限，并将访问策略附加到相关角色。这些可以是由云计算服务提供商(CSP)创建的托管策略，也可以是由AWS云平台客户创建的内联策略。 担任角色 可以被分配多个访问策略或为多个应用程序服务的角色，使“最小权限”的旅程更具挑战性。 以下有几种情况说明了这一点。 (1)单个应用程序–单一角色：应用程序使用具有不同托管和内联策略的角色，授予访问Amazon ElastiCache、RDS、DynamoDB和S3服务的特权。如何知道实际使用了哪些权限?一旦完成，如何正确确定角色的大小?是否用内联策略替换托管策略?是否编辑现有的内联策略?是否制定自己的新政策? (2)两个应用程序–单一角色：两个不同的应用程序共享同一角色。假设这个角色具有对Amazon ElastiCache、RDS、DynamoDB和S3服务的访问权限。但是，当第一个应用程序使用RDS和ElastiCache服务时，第二个应用程序使用ElastiCache、DynamoDB和S3。因此，要获得最小权限，正确的操作将是角色拆分，而不是简单地调整角色大小。在这种情况下，作为第二步，将在角色拆分之后进行角色权限调整。 (3)当应用程序使用的角色没有任何敏感权限，但该角色具有承担其他更高特权角色的权限时，就会发生角色链接。如果权限更高的角色有权访问Amazon ElastiCache、RDS、DynamoDB和S3等各种服务，那么如何知道原始应用程序实际上正在使用哪些服务?以及如何在不中断其他可能同时使用第二个更高权限角色的应用程序的情况下限制应用程序的权限? 一种称为Access Advisor的AWS工具允许管理员调查给定角色访问的服务列表，并验证其使用方式。但是，只依靠Access Advisor并不能解决访问权限与解决许多策略决策所需的各个资源之间的问题。为此，有必要深入了解CloudTrail日志以及计算管理基础设施。 云中的最小权限 最后需要记住，只涉及原生AWS IAM访问控制。将访问权限映射到资源时，还需要考虑几个其他问题，其中包括间接访问或应用程序级别的访问。 正如人们所看到的，对于许多组织而言，在云中强制实施最小权限以最小化导致数据泄露或服务中断的访问风险可能是不可行的。通过使用软件来自动化监视、评估和对所有身份(用户、设备、应用程序等)的访问权限进行调整正确大小的新技术正在弥合这种治理鸿沟，以消除风险。 |
2016-12-30
2019-09-16
2016-12-23
2019-09-20
2019-12-26
回答
回答
回答
回答
回答
微信公众号
评论