AWS Infra系高级证书知识点整理(2)——安全、认证、监控与通知篇 | 硅基生物的培养皿

type

status

date

slug

summary

tags

category

icon

password

⚠️

本文写作于 2025 年 6 月，截止到写作时间点为止，AWS考试体系高级部分分为SAP、DOP、ANS、SCS四部分。

本文将整理笔者自身备考除了MLS之外的高级考试过程中错过的题的关键点以及知识漏洞，供大家参考复习。

本文内容的正确性与非过时性都经过了Gemeni核查，但我无力随时更新这个总结，随着AWS技术本身的演进，其中的一些说法难免会和事实出现偏差，阅读时请注意这一点。

📝 安全工具

KMS

<DOP> 加密跨账户共享AMI的方式是，1.在复制操作中指定KMS密钥，2.在源账户上修改密钥策略授权目标账户创建授权的权限，3.在目标账户中创建KMS授权，将权限委派给ASG相关角色

<DOP> 在将KMS授权给另一个账户使用时，先要修改源账户的KMS策略，然后修改目标账户的IAM权限使用这个KMS

<SCS> 具备S3:*权限并不足以访问加密的存储桶，必须有kms:Decrypt权限

<SCS> EC2访问KMS加密的S3文件，走的是443端口，需要配置443出站规则

<SCS> KMS策略中的加密上下文可以限制只有传递了正确的上下文API调用才能使用这个密钥，可以作为一种身份认证提高安全性

<SCS> KMS密钥授权用于生成临时访问权限，方便后续删除权限

<SCS> ECR存储库只能在创建时启动KMS加密，不能稍后添加加密

<SCS> 如果没有kms:CreateGrant权限，则无法启动EBS加密的EC2

<SCS> 如果使用KMS非对称加密，要意识到密钥删除后依旧可以使用公钥加密但是无法解密的风险

<SCS> AWS管理的密钥不能控制别名和按需随时轮换，客户管理密钥可以选择多久自动轮换一次（默认一年）

<SCS> KMS的客户管理密钥可以在其他Region使用，以保证加密文件跨区备份后依然可以解密

<SCS> AWS自带的默认密钥如aws/rds是无法被二次创建的

<SCS> 手动轮换KMS客户管理密钥是十分复杂的工作，最推荐自动轮换

<SCS> 当用户管理密钥泄露时，需要新建密钥并将别名指向新密钥，但是这会导致老数据无法解密，所以可以考虑重新加密等方法

<SCS> AWS托管的KMS密钥无法实现跨账户访问，需要使用客户管理密钥才可以

<SCS> KMS的默认密钥存储使用AWS托管的HSM，价格便宜，自定义密钥存储需要使用CloudHSM或AWS之外，价格贵不方便

<DOP> 使用AWS的KMS托管密钥加密构建好的项目后，在另一个AWS账号里是无法读取的，要么需要共享这个KMS给另一个账号，要么最好是创建用户管理的KMS密钥

GuardDuty

<SAP> 使用GuardDuty -> EventBridge -> SNS，可以在root用户被使用时发送通知（另一个选择是CloudTrail）

<DOP> 当GuardDuty检测到潜在威胁时，可以通过EventBridge触发Lambda函数，自动更新Network Firewall的规则，从而阻止相应的流量

<DOP> GuardDuty可以识别IAM访问密钥泄露事件

<DOP> 当比如IAM密钥泄露（给Github）时，可以用GuardDuty检测异常访问事件，通过EventBridge发出通知，GuardDuty本身不支持直接发送通知给SNS

<DOP> GuardDuty可以在EC2发生端口扫描的时候提供通知

<SCS> GuardDuty结果可以通过Firehose传递数据使用OpenSearch仪表盘可视化，QuickSight虽然也可以但似乎它倾向于用在BI场景

<SCS> GuradDuty的可信IP列表和威胁列表是配置在S3上的纯文本，S3文件可以跨账户访问

<SCS> GuardDuty可以扫描VPC流日志发现源自VPC内部的僵尸网络攻击，将IP地址通过Lambda写入DynamoDB并更新Network Firewall阻止出站流量来阻止这一攻击

<SCS> GuardDuty可以配置抑制规则或自动存档检测来减少误报

<SCS> 当S3存储桶被允许公开访问时，触发的GuardDuty发现是S3/BucketAnonymousAccessGranted

<SCS> 当IAM凭证被外部使用时，触发的GuardDuty发现是IAMUser/InstanceCredentialExfiltration

其他工具

<SCS> Audit Manager是收集合规性审计报告的工具，除了支持从AWS收集证据之外，也支持从本地机器收集、上传证据

<SCS> AWS Audit Manager提供的是持续审计功能，支持多种审计规则框架。它能够与其他AWS服务深度集成，实现自动化的数据采集和合规性评估。而AWS Artifact则是一个用于访问和管理合规性文档的门户，提供AWS的认证报告和相关合规性资料。

<ANS> CloudHSM并不能生成TLS证书，它只能用来生成密钥材料

<SCS> CloudHSM在VPC内运行，VPC外无法直接访问

<SCS> 使用Detective从GuardDuty调查事件，可以发现谁禁用了CloudTrail日志

<SCS> 启动Detective的条件是启动GuradDuty的48小时后

<SAP> AWS Firewall Manager，用于控制Organizations中多账号的防火墙设定，包括AWS WAF Classic、AWS Shield Advanced、VPC SG，前提是开启AWS Config。它也可以用于管理CloudFront等对外服务的安全策略，例如为CloudFront分发关联WAF Web ACL和Shield Advanced保护

<SAP> 自动化修复EC2/ECR/Lambda函数系统漏洞的架构是：SSM Agent->Inspector->SNS->Lambda->Run Command->修复EC2

<SCS> Inspector可以自动扫描组织内新AWS账户的ECR的脆弱性，并发送到Security Hub集中查看问题

<SCS> 可以通过Inspector的网络可达性规则包检测出想定范围以外的网络访问，了解网络层面的暴露情况

<SAP> 使用Secrets Manager RotationSchedule通过执行Lambda函数更新RDS的密码

<SCS> 在SG设置中，无法引用一个对等VPC中的SG，只能引用子网的CIDR

<SAP> Security Hub可以用于集中管理多账户的Config/GuardDuty/Inspector/Macie/SystemManager/FirewallManager/Health等诸多工具，形成一个统一的仪表盘，不论哪里出现问题，都会在EventBridge生成事件

<SCS> Security Hub侦测到的问题需要集成Event Bridge和Lambda函数修复

<SCS> Security Hub支持基于AWS最佳实践和互联网安全中心CIS基准的合规性检查，使用前提是开启Config记录所有资源

<SCS> Lambda函数可以配置仅允许部署被签名的代码，可以把代码打zip包后用Signer签名

<SCS> 撤销分配给开发人员的Signer签名配置文件，可以让其无法部署Lambda函数，以应对离职

📝 权限认证

IAM

<SAP> 在创建IAM用户时可以指定它的权限边界Policy，比如允许它访问EC2这个服务，那么如果这个角色的Policy里包含EC2之外的操作权限，这个权限将不会生效。权限边界机制通常用于创建一个用户将权限委派给组织外的人用的时候，它是一种防止派发的权限过大的自我保护机制。场景举例：希望给组织内部分IAM用户创建EC2、创建/绑定IAM角色的权限，但他们必须在启动机器时加上用户名TAG。为了满足这个需求，管理员可以把这些用户加到IAM组里，给IAM组Policy的condition里添加Creator:${aws:username}的条件，然后逐个给这些IAM用户添加权限边界Policy，仅允许EC2和IAM角色操作

<SAP> 当需要使用账户A控制账户B（包括C、D...）内的资源时，因为在SCP级别是无法控制IAM级别的Policy的，通常在账户B内制作Cross Account Access Role提供给A使用

<SAP> AssumeRoleWithWebIdentity针对的是Google、Facebook等第三方登录，如果想用本地机房的认证信息登录AWS控制台，需要使用SAML 2.0 IdP

<SAP> 想用谷歌账户管理用户时，可以用Identity Federation（身份联合）的方式实现，打通谷歌和AWS的IdP，在G Suite上配好IdP和用户的IAM Role的ARN，谷歌账户就可以SSO以临时用户的身份进入AWS了，同时权限被IAM Role管理，可以应对用户增删频繁的状况

<SAP> 为了防止混淆代理问题，需要在提供给第三方SaaS平台一个IAM角色的ARN（或者APP Key）时，同时给一个ExternalId（也就是Secret Key），这样即便角色ARN泄露，也不会导致恶意用户用你的ARN通过第三方SaaS平台访问你ID私密资源，在AWS中这个可以通过sts:AssumeRole的sts:ExternalId条件来实现

<SAP> IAM Access Analyzer可以通过分析CloudTrail日志的方式生成一个User或Role的最小Policy

<SCS> IAM Access Analyzer可以用来分析实际使用情况判断SCP是否满足最小权限原则

<SCS> IAM Access Analyzer可以当IAM Policy发生变化时自动触发检测，将违规的规则（比如允许S3公共访问）产生EventBridge事件

<SCS> 当删除一台MFA设备时可能会出现缺少权限错误，使用CLI删除设备

<SCS> AWS访问密钥泄露时的对策: 1.轮换受感染账户的所有访问密钥对， 2.从账户中删除任何可能未经授权的IAM用户、更改所有其他IAM用户密码

<SCS> 当IAM发生泄露时第一反应应该是禁用或删除用户，并且，能够使用角色获取临时授权的地方一律不建议用用户

<SCS> IAM存在角色链，即让一个用户承担一个角色，再以此角色的临时凭证承担另一个角色，这种链条最多传递一层，且最后被承担的角色必须设定承担它的角色为可信任实体

<SCS> IAM提供了用户凭证报告功能，当密钥泄露时可以查询登录状况

<SCS> root用户的PrincipelArn是arn:aws:iam::<account-id>:root

<SCS> 向OU添加SCP，确保Deny掉大部分用户的权限，只有添加了权限边界的用户才能创建角色，通过这种方式，可以将创建角色这一动作委派给特定范围的用户

<SCS> 当使用策略强制使用MFA时，为了让CLI能够操作，需要使用aws sts get-session-token创建临时会话，其中包括从MFA设备获取的--serial-number和--token-code

<SCS> 定义谁可以承担一个角色的策略，叫角色信任策略，定义角色可以做哪些操作的策略，叫角色权限策略。角色A想承担角色B，需要配置角色A的权限策略，和角色B的信任策略

<SCS> 应对企业用户激增来不及应对的推荐方法是使用外部IdP与IAM角色联合登录，这可以避免用户之间为了赶进度共享访问密钥的风险

<SCS> 提供IAM用户给外部人员使用时，最好添加权限边界，实现仅限用户使用EC2之类的限制，并且设定角色只能被特定角色承担

<SCS> 当IAM密钥泄露时，使用AWS Identity and Access Management访问分析器识别哪些资源暴露了访问凭证以及谁使用了它们，而不是仅使用凭证报告获取上次访问时间

Organization/SCP

<SAP> 当建立一个管理账户去控制其他账户时，最好的做法是让每个账户建立一个专用的OrganizationAccountAccessRole，让管理账户直接通过这个Role访问，而不是用STS的方式获取临时权限，后者虽然可行，但是是次优解

<SAP> AWS Organizations的整合账单功能只是一个预览界面，并不能控制是否能买RI

<SAP> 作成AWS Organizations时，可以启动所有机能，但不能只启动SSO机能

<SAP> SCP中的权限设定继承到IAM时，遵从的原则是【默认Deny < 明文Allow　< 明文Deny】，比如SCP里没有明确Allow一个S3权限，也没有允许FullAWSAccess，那就是默认Deny，即便IAM里设置允许访问S3也是不行的

<SCS> IAM策略无法添加给root用户，但是SCP策略可以限制root用户，而且使用SCP阻止对root的访问是最彻底的，只删除root的密钥不能阻止访问控制台

<SCS> 在没有FullAWSAccess的前提下，SCP如果只配置允许某特定角色执行某操作，意味着其他角色无法执行这个操作

<SCS> SCP策略不支持Principal元素，但支持Condition元素，包括 aws:PrincipalArn 或 aws:PrincipalOrgID

<SCS> 如果SCP没有显示允许或拒绝一个操作，那么IAM只要允许，就可以操作，否则被视为被IAM隐式拒绝

Cognito/AD/IAM Identity Center

<SAP> Web服务或APP进行用户管理时推荐使用Cognito，它相当于一个门面层，带有用户池和针对未注册用户的身份池，能方便地进行用户属性管理，短信/邮件认证，MFA认证，密码重置等功能，还能触发其他AWS服务（如Lambda），甚至对AWS资源进行权限控制，如果不使用，则这些东西都要自己开发。

<SCS> Cognito支持在用户注册时触发Lambda函数进行校验，来实现屏蔽特定国以外的用户的需求，同时配合WAF可以实现访问国限制

<SCS> Cognito托管了登录UI，可以结合Lambda@Edge逻辑添加到CF分配来进一步验证身份或作一些逻辑修改

<SAP> AWS Managed Microsoft AD是一个由AWS托管的AD系统，可以和各种AWS服务很好地集成，也可以和on-premise上的AD建立双向信任实现内容同步，性能高于AD Connector，它支持多AZ，也可以把本地AD同步到EC2上再设置信任，来避免VPN线路故障。

<SAP> AD Connector是一个针对on-premise中微软AD的代理，只是代理，没有信任关系，使用时要保证有VPN或直连线路。当内网用户/程序访问AWS服务时，用户先访问AWS上的一个登录界面，这个界面背后的AD Connector作为一个代理去请求本地微软AD获取账户信息，然后再去通过STS获取临时访问Token。

<DOP> SAML：主要用于身份验证和单点登录，解决用户在多个应用间的无缝访问问题。SCIM：主要用于用户身份信息的管理和同步，解决跨系统间用户信息的一致性问题。

<SAP> IAM Identity Center（Single Sign-On）用于使用其他账号系统的账号登陆AWS（如果有多个AWS账号，很推荐使用这种方式做登陆），比如其他家的AD等，和其他家AD关联后用户和组会被自动同步到IAM Identity Center，然后需要将合适的合适的权限集关联用户和账户

<SAP> IAM Identity Center是一个单点登录管理界面，允许使用AWS账号登陆其他AWS账号或者第三方服务或者支持SAML2.0的自己开发的APP，当登陆其他AWS账号时，可以通过assume一个角色的方式获取权限列表。

📝 监控通知

CloudTrail

<SAP> 虽然确实可以用CW Logs的Metric Filter针对CloudTrail扫出有问题的操作发SNS通知，但是不借助CW Logs的话CloudTrail本身不能干这件事，所以说在CloudTrail上定义Metric Filter是错的

<SAP> AWS Organizations直接整合了CloudTrail服务，可以直接在Organizations级别对所有账号开启CloudTrail，无需每个账号单独配置

<DOP> CloudTrail本身只能把日志写进S3或CloudWatch Logs，可以通过S3 Event（+Lambda）间接写出到其他地方

<DOP> CloudTrail的日志可以跟踪到资源的Region，可以用它跟踪在不被允许使用的Region上发生的操作

<SCS> 使用Config托管的规则触发修复，可以在检测到CloudTrail是否被禁用，在这种情况下可以在多个区域中进行修复来启用CloudTrail

<SCS> CloudTrail可以监控root用户的举动，触发EventBridge通过Lambda发送SNS消息

<SCS> CloudTrail默认只记录管理事件，默认记录不到S3的PutObjectAcl，如果需要，则需要开启数据事件捕获

<SCS> CloudTrail要想把日志写入S3，需要明确的S3桶权限，如果需要修改CloudTrail的写入，需要先改S3桶策略

<SCS> CloudTrail最多保存90天的日志，想保存更长时间的日志需要使用S3，90天内的日志可以直接通过控制台查询

<SCS> Orgnization的组织跟踪功能支持把所有账户的CloudTrail写入专用账户中的统一S3桶，为此，需要给每个账号的CloudTrail写入这个S3的桶策略权限

CloudWatch

<SAP> 将CW Logs的日志按照嵌入式指标格式写入的话更便于Insights分析

<DOP> CW Alarm报警时，动作配置可以直接触发EC2关机事件

<SAP> CloudWatch Synthetics是用于监控程序可用性的服务，它可以创建叫Canary的实体，可以模拟用户对应用程序执行的各种操作，例如登录、浏览网页、提交表单等。Canary会以规定的时间间隔执行这些操作，并监测应用程序的响应时间、可用性等指标，并发出报警

<SCS> 需要给EC2的角色添加CloudWatchAgentServerPolicy权限才能将程序日志推送给CW Logs (其中包含logs相关权限)

日志

<SAP> VPC Flow Logs不能记录应用层内容，比如User-Agent，如需记录这个级别的内容，可以用VPC Traffic Mirroring将一个ENI的流量传输到另一台EC2，再通过wireshark等抓包工具解析

<ANS> ALB只支持S3接收日志，不支持CW Logs

<ANS> 监控NAT流量的方法是在其eni上开启VPC流日志写入S3或CW Logs

<ANS> Network Firewall自带日志功能，无需整合CW Logs，日志通过Firehose发送

<ANS> Route53 Resolver的日志需要传送到CW Logs、S3或Firehose中

<ANS> WAF的日志要经过Firehose发送给S3，也可以直接发给S3，目录不同

<SCS> 负载均衡器日志只支持传输到S3，不支持传输到CW Logs

<SCS> CloudTrail可以直接接收多个Region里的日志到同一个S3当中，而无需多个Region里的S3，目录如下：AWSLogs/{account-id}/CloudTrail/{region}/{year}/{month}/{day}/{hour}/

<SCS> EKS默认不发送日志，要将EKS的日志写入CW，需要开启EKS控制平面的日志记录

<SCS> Security Lake用于集中管理各种日志，以S3为后台统一管理

<SCS> API Gateway的阶段日志会被写入CW Logs中