在云中，保护身份和工作负载是最重要和最复杂的。AWS客户安全漏洞清单有助于我们从公开披露的事件中吸取教训，但到目前为止，关于安全机制的使用情况，没有多少具体数据可以帮助我们预防这些事件。在本报告中，我们从使用Datadog的云安全管理的600多个组织和数千个AWS账户的样本中研究了真实世界数据。
为了阐明2022年AWS安全的安全状况，我们分析了安全最佳实践的实施趋势，并仔细研究了导致安全漏洞最常见原因的各种类型的错误配置。特别是，我们将看到管理静态、长期凭据的一些主要挑战；及早发现和修复不安全违约的重要性；以及AWS身份和访问管理（IAM）的复杂性如何可能导致组织无意中公开敏感资源。继续阅读，了解有关AWS云安全在现实环境中的状态的更多信息。
事实1
IAM用户在大规模安全管理方面面临挑战
AWS身份和访问管理（IAM）用户可以通过设置允许访问AWS控制台的密码或允许对AWS API进行身份验证的长期访问密钥来对人类进行身份验证。访问密钥也经常用于验证工作负载。
因为访问密钥是不会过期的静态凭据，所以它们被广泛认为是高度敏感的，是AWS安全漏洞的主要原因。2022年GitGuardian的一项研究发现，平均每10000个Git提交了84个AWS访问密钥。访问密钥经常被泄露（例如，在日志、构建输出、堆栈跟踪中），并被TeamTNT等攻击组作为攻击目标。
特别是，我们发现：
- 40%的IAM用户在过去90天内未使用其凭据（访问密钥或控制台密码），影响了70%的组织。
- 40%的组织至少有一个IAM用户具有AWS控制台访问权限，但未启用多因素身份验证（MFA），占所有IAM用户的10%。如果没有MFA的额外保护，这些用户特别容易受到凭证填充和暴力攻击。
此外，在具有活动访问密钥的IAM用户中：
- 25%的IAM用户拥有一个有效的访问密钥，该密钥已超过一年，并且在过去30天内没有使用过。这种特征组合通常对应于未使用且应删除的IAM用户。
- 75%的IAM用户拥有超过90天的活动访问密钥。旋转IAM访问密钥非常具有挑战性，尤其是在规模上。
这些数据突出表明，当员工离开公司或应用程序退役时，很难正确管理IAM凭据。此外，它还强调了当有其他更安全的替代方案可用时，不使用IAM用户对人员和工作负载进行身份验证的重要性，例如AWS IAM Identity Center（以前的AWS SSO）用于人员，EC2实例角色或Lambda执行角色用于应用程序。
事实2
IAM根用户凭据使用率低，但仍然存在风险
创建AWS帐户时，将自动配置根用户。此用户具有无限的管理权限。特别是，它可以下载任何敏感数据，甚至可以完全删除整个AWS帐户。为了降低风险，最好的做法是首先避免为根用户创建任何访问密钥。
然而，我们发现：
- 大约10%的组织拥有活动的根用户访问密钥。这占所有AWS账户的3%。其中一些钥匙的使用年限可达13年。
- 在进行这项研究之前的30天内，25%的组织使用过root用户凭据。
root用户凭据的使用并不总是自动发出红旗。在高度特定的情况下需要这些凭据，例如更改AWS帐户设置。然而，维护活动根用户访问密钥的开销是一个巨大的风险，因为长期的静态凭据往往会在源代码、配置文件、日志或堆栈跟踪中泄漏，并导致许多AWS客户安全漏洞的记录。泄露的根用户凭据可能会特别成问题，因为它们授予对整个帐户的无限制访问权限。
事实3
AWS IAM的复杂性导致公开资源
当使用诸如Amazon Simple Queue Service（SQS）、Amazon简单通知服务（SNS）或Amazon S3等服务时，组织通常通过使用附加到资源本身的基于资源的IAM策略来配置跨帐户访问。
我们发现：
- 18%的使用SQS的组织至少有一个公开队列，允许任何人接收或向这些队列发布消息。
- 15%的使用SNS的组织至少有一个公开主题，允许任何人对这些主题执行敏感操作（例如，检索或发布通知）。
- 36%的使用S3的组织至少有一个公开的存储桶，占所有S3存储桶的2%。
我们认为这可以归因于创建仅授予所需权限的AWS IAM策略的复杂性。在涉及多个团队、应用程序和临时资源的复杂环境中，创建授予最少权限、粒度权限的安全IAM策略可能很困难。在遇到过多“拒绝访问”错误后，团队可能会发现创建限制性较小的IAM策略更方便，以避免工作流程的瓶颈。
这个问题非常普遍，以至于社区成员开发了Repokid和Policy Sentry等工具来解决各种与IAM相关的痛点。尽管这些工具可以提供帮助，但它们也突显了在不阻塞工作流的情况下，制定授予必要权限的IAM策略并在这些需求发生变化时使其保持最新的持续挑战。
事实4
默认情况下，实例元数据服务V2（IMDSv2）未强制执行，从而使EC2实例处于风险之中
服务器端请求伪造（SSRF）是一个应用程序级漏洞，多年来一直被攻击者频繁利用。在AWS中，这种类型的漏洞允许攻击者欺骗应用程序调用EC2实例元数据服务（IMDS），以便成功获取绑定到实例角色的凭据。然后，攻击者可以使用这些凭据根据AWS API进行身份验证或访问AWS控制台。
这项技术已被用于几起备受瞩目的事件中，例如Capital One漏洞，甚至被美国政府点名叫出。参议员罗恩·怀登（Ron Wyden）在给AWS的一封信中表示：“一些网络安全专家公开猜测，Capital One黑客利用了服务器端请求伪造（SSRF）漏洞，多年来，专家们一直在警告这一漏洞。据亚马逊所知，SSRF攻击是否被用来获取Capital一的客户数据？”
2019年，AWS发布了EC2 IMDS（IMDSv2）的版本2，以帮助缓解此漏洞。然而，我们发现绝大多数EC2实例（93%）没有强制使用IMDSv2。总体而言，95%使用EC2的组织至少有一个易受攻击的实例。
我们认为，这可以归因于缺乏安全的违约。除非明确配置为强制执行版本2，否则新创建的EC2实例仍然允许使用IMDS的版本1，使它们容易受到SSRF攻击。
事实5
至少40%的组织使用多个AWS帐户
在AWS中采用多帐户策略对于限制受损应用程序或用户帐户的爆炸半径以及其他好处至关重要。然而，一些早期组织可能会选择使用一个AWS帐户，以减少创建和管理多个帐户的开销。AWS组织等服务旨在通过集中帐户管理和自动创建新的AWS帐户（例如，将基础设施用作代码）来帮助解决这一问题。
我们的数据显示，至少41%的组织在AWS中采用了多客户策略。
6%的组织通过使用超过10个AWS帐户来大量实施多帐户策略。此外，0.6%的长尾用户使用了100多个AWS帐户，其中一些组织拥有数千个AWS账户。
这些数字应被解释为下限，因为使用Datadog的组织可能不会监控其所有AWS帐户，例如用于测试或开发目的的帐户。
方法论
调查结果基于2022年9月收集的数据。
人口
在本报告中，我们分析了600多个使用Datadog的云安全管理和AWS集成来监控其环境的组织的AWS安全态势。虽然所呈现的结果有偏见，因为数据来自我们的客户群，但这些组织在地理、行业、规模和云之旅的成熟度方面存在很大差异。因此，我们相信它们能够准确地代表全球使用AWS的组织。
数据集
这项研究是针对一个匿名数据集进行的，该数据集不包含个人身份信息或敏感信息，如资源名称或标签。
SQS队列和SNS主题
我们将可公开访问的SQS队列或SNS主题定义为具有基于资源的策略的队列或主题，该策略允许主体“*”执行操作，并且没有进一步限制操作授权上下文的条件语句。
S3桶
我们将可公开访问的S3存储桶定义为至少符合以下条件之一的存储桶：
- Bucket策略至少有一个语句允许在没有条件的情况下对Bucket执行操作
- Bucket ACL授予“经过身份验证的用户”完全控制权
- Bucket ACL授予所有用户完全控制权
IAM用户和多因素身份验证（MFA）
我们将“具有未启用MFA的AWS控制台访问权限的IAM用户”定义为（a）已创建AWS控制台密码且（b）未注册MFA设备的IAM。
详细数据
DESCRIPTION |
METRIC VALUE |
RATIO COMPUTED OVER |
|---|---|---|
| Organizations with more than 1 AWS account | 41 % | All organizations |
| Organizations with more than 10 AWS accounts | 5 % | All organizations |
| IAM users with inactive credentials (console password or access key active, and not used in the past 90 days) | 39 % | All organizations |
| Organizations with at least 1 IAM user with inactive credentials | 70 % | All organizations |
| IAM users with an access key older than 1 year that has not been used in the past 30 days | 25 % | All IAM users |
| IAM users with at least 1 active access key older than 90 days | 60 % | All IAM users |
| IAM users with at least 1 active access key older than 90 days | 76 % | IAM users with at least 1 active access key |
| Organizations with at least 1 IAM user with console access and no MFA device enrolled | 40 % | All organizations |
| IAM users with console access and no MFA device enrolled | 11 % | All IAM users |
| Organizations with at least 1 active root user access key | 9 % | All organizations |
| AWS accounts with at least 1 active root user access key | 3 % | All AWS accounts |
| Organizations having used root user credentials in the last 30 days (access key or console password) | 23 % | All organizations |
| EC2 instances not enforcing usage of the IMDSv2 | 93 % | All EC2 instances |
| Organizations with at least 1 EC2 instance not enforcing usage of the IMDSv2 | 95 % | Organizations with at least 1 EC2 instance |
| Organizations with at least 1 publicly readable S3 bucket | 36 % | Organizations with at least 1 S3 bucket |
| Publicly accessible S3 buckets | 36 % | Organizations with at least 1 S3 bucket |
| Organizations with publicly exposed SNS topics | 15 % | Organizations with at least 1 SNS topic |
| Organizations with publicly exposed SQS queues | 18 % | Organizations with at least 1 SQS queue |
本文：https://www.datadoghq.com/state-of-aws-security/
- 登录 发表评论