簡(jiǎn)介面向云架構(gòu)師、安全工程師及DevOps人員AWS云上安全最佳實(shí)踐PDF系統(tǒng)梳理了云上安全的核心實(shí)施路徑。內(nèi)容圍繞身份與訪問(wèn)管理IAM、數(shù)據(jù)保護(hù)、網(wǎng)絡(luò)安全和基礎(chǔ)設(shè)施安全四大模塊展開(kāi)涵蓋最小權(quán)限策略、MFA多因素認(rèn)證、KMS密鑰統(tǒng)一管理、VPC隔離與安全組配置、AWS WAF應(yīng)用防護(hù)、GuardDuty威脅檢測(cè)等關(guān)鍵技術(shù)。文檔同時(shí)引入AWS CAF云安全架構(gòu)與五大安全能力框架從自動(dòng)化識(shí)別、保護(hù)、監(jiān)控到合規(guī)聯(lián)動(dòng)闡述零信任模型在AWS環(huán)境中的落地方法。資源為單份PDF文件大小15.34MB內(nèi)容源自AWS官方安全實(shí)踐講解結(jié)構(gòu)完整、層級(jí)清晰適合企業(yè)上云安全規(guī)劃、安全基線建設(shè)或AWS認(rèn)證備考時(shí)對(duì)照參考目前已有794人學(xué)習(xí)下載。整份文檔覆蓋從賬號(hào)集中管理、縱深防御到事件自動(dòng)響應(yīng)與驗(yàn)證的完整安全閉環(huán)可幫助讀者快速建立AWS云上安全的全局認(rèn)知并作為日常運(yùn)維與架構(gòu)設(shè)計(jì)的實(shí)用檢查清單。1. 云上安全不是買(mǎi)服務(wù)五層自動(dòng)化才是AWS安全最佳實(shí)踐的骨架這份《AWS云上安全最佳實(shí)踐.pdf》我拆了兩遍第一遍覺(jué)得全是服務(wù)名詞和架構(gòu)圖第二遍才看懂它真正想說(shuō)的是什么網(wǎng)絡(luò)安全和AWS安全在云上不是某一個(gè)產(chǎn)品能兜底的而是把身份、網(wǎng)絡(luò)、數(shù)據(jù)、檢測(cè)、響應(yīng)串成一條自動(dòng)化鏈路。文檔里反復(fù)強(qiáng)調(diào)的五層能力——識(shí)別、保護(hù)、監(jiān)控、合規(guī)、聯(lián)動(dòng)——說(shuō)白了就是讓安全策略從“人盯著控制臺(tái)”變成“系統(tǒng)自己發(fā)現(xiàn)、自己處置、自己驗(yàn)證”。適合兩類(lèi)人一類(lèi)是把業(yè)務(wù)遷到云上但安全基線還停留在物理機(jī)房思維的運(yùn)維另一類(lèi)是剛接手云賬號(hào)、想理順多賬戶權(quán)限和日志管線的安全工程師。2. 身份與賬號(hào)治理先鎖死IAM最小權(quán)限再談數(shù)據(jù)加密2.1 為什么身份層是第一道閘門(mén)文檔把“賬號(hào)集中 自動(dòng)最小權(quán)限”排在五大安全基礎(chǔ)的第一位這個(gè)排序不是隨意的。云上所有操作最終都落在API調(diào)用上而API調(diào)用靠身份令牌鑒權(quán)。如果身份層失控后面VPC再深、WAF再?gòu)?qiáng)攻擊者只需要一把高權(quán)限密鑰就能繞過(guò)去。所以拆這份PDF時(shí)我把身份治理當(dāng)作最先落地的模塊而不是先折騰數(shù)據(jù)加密。在AWS里root賬戶相當(dāng)于物理機(jī)房的超級(jí)管理員它的Access Key擁有所有權(quán)限且不受IAM策略限制。文檔的TOP10策略里第一條就是“遷移到開(kāi)發(fā)周期中驗(yàn)證IAM”建議創(chuàng)建獨(dú)立的IAM用戶和管理組root只用于極少數(shù)的賬戶管理操作并且強(qiáng)制啟用MFA。同時(shí)用AWS Organizations把多個(gè)賬號(hào)納入統(tǒng)一組織由管理賬號(hào)下發(fā)策略避免每個(gè)賬號(hào)各自為政。這樣做的直接收益是某條業(yè)務(wù)線賬號(hào)即使被攻破攻擊者也只能在權(quán)限邊界內(nèi)活動(dòng)沒(méi)法橫向移動(dòng)到其他賬號(hào)。2.2 一份可以抄的權(quán)限邊界JSON文檔提了兩個(gè)關(guān)鍵概念權(quán)限邊界Permission Boundary和最小授權(quán)。權(quán)限邊界不是策略本身而是給角色或用戶劃的一個(gè)“最高天花板”。即使附加了管理策略也不能越過(guò)邊界里Allow的范圍。下面這個(gè)JSON是我按文檔思路整理的一份權(quán)限邊界適合給新入職的開(kāi)發(fā)者角色用{ Version: 2012-10-17, Statement: [ { Sid: AllowServiceLimited, Effect: Allow, Action: [ ec2:DescribeInstances, s3:GetObject, s3:ListBucket, logs:DescribeLogGroups ], Resource: * }, { Sid: DenyDataDestructive, Effect: Deny, Action: [ s3:DeleteBucket, s3:DeleteObject, rds:DeleteDBInstance, ec2:TerminateInstances ], Resource: * } ] }邏輯說(shuō)明Allow段只放“讀”和“查詢(xún)”類(lèi)操作Deny段把破壞性操作全部禁掉兩者疊加的效果是——這個(gè)角色還能跑常規(guī)運(yùn)維查看但永遠(yuǎn)無(wú)法刪除生產(chǎn)資源。參數(shù)說(shuō)明里有兩個(gè)關(guān)鍵點(diǎn)Action列表要按業(yè)務(wù)實(shí)際需要的API收斂別圖省事寫(xiě)s3:*Deny優(yōu)先級(jí)高于Allow所以即使有人給這個(gè)角色附加了管理員策略破壞性操作依然被邊界攔住。2.3 落地步驟從root到最小權(quán)限的七步按文檔的“最小授權(quán)、邊界授權(quán)”方針我建議新賬號(hào)按下面這個(gè)順序做每步都能驗(yàn)證創(chuàng)建IAM管理組附加AdministratorAccess臨時(shí)策略創(chuàng)建管理員IAM用戶并啟用MFA然后用管理員用戶登錄控制臺(tái)。刪除root賬戶的Access Keyroot只保留控制臺(tái)登錄且開(kāi)啟MFA。這一步能阻斷大量利用root密鑰發(fā)起的惡意調(diào)用。為每個(gè)業(yè)務(wù)團(tuán)隊(duì)創(chuàng)建自定義策略只包含他們實(shí)際調(diào)用的API。不要給普通開(kāi)發(fā)者附加AdministratorAccess。為所有IAM角色啟用權(quán)限邊界把2.2節(jié)的JSON掛到角色上確保后續(xù)新增策略也不會(huì)突破邊界。用AWS Single Sign-OnIAM Identity Center接管多云賬戶登錄避免員工在多個(gè)賬號(hào)里各建一套IAM用戶。開(kāi)啟IAM Access Analyzer它會(huì)持續(xù)分析哪些策略被外部實(shí)體使用提示你收緊過(guò)度開(kāi)放的策略。按季度定期審計(jì)導(dǎo)出所有用戶和角色的LastUsedDate連續(xù)90天未使用的密鑰直接禁用。這套流程做完身份層的基線就立住了。文檔里提的“自動(dòng)最小權(quán)限”不是靠人肉寫(xiě)策略而是靠權(quán)限邊界和定期審計(jì)把“最小”變成持續(xù)狀態(tài)。3. 網(wǎng)絡(luò)縱深防御與WAFVPC隔離、安全組與CSRF規(guī)則實(shí)戰(zhàn)3.1 VPC分層與網(wǎng)絡(luò)邊界文檔把VPC縱深防御放在“保護(hù)”層核心思想是不要把資源平鋪在一個(gè)大網(wǎng)段里而是按業(yè)務(wù)和暴露面拆成多層的子網(wǎng)。常見(jiàn)的做法是把Web節(jié)點(diǎn)放在公有子網(wǎng)應(yīng)用和數(shù)據(jù)庫(kù)放在私有子網(wǎng)流量必須經(jīng)過(guò)NAT或負(fù)載均衡器才能進(jìn)來(lái)。安全組和網(wǎng)絡(luò)ACL的區(qū)別值得記牢維度安全組網(wǎng)絡(luò)ACL層級(jí)實(shí)例級(jí)別子網(wǎng)級(jí)別支持規(guī)則僅AllowAllow和Deny狀態(tài)有狀態(tài)無(wú)狀態(tài)默認(rèn)規(guī)則拒絕所有入站允許所有入站/出站適用場(chǎng)景精細(xì)控制單臺(tái)實(shí)例子網(wǎng)統(tǒng)一邊界防護(hù)排錯(cuò)時(shí)最容易翻車(chē)的一點(diǎn)是網(wǎng)絡(luò)ACL是無(wú)狀態(tài)的出站響應(yīng)流量也要顯式Allow。我遇到過(guò)配置了ACL入站放行80端口但忘放出站臨時(shí)端口結(jié)果頁(yè)面一直超時(shí)的情況。這類(lèi)問(wèn)題在安全組里不會(huì)出現(xiàn)因?yàn)榘踩M會(huì)自動(dòng)跟蹤連接狀態(tài)。所以我的習(xí)慣是安全組管實(shí)例粒度的策略ACL只做子網(wǎng)級(jí)粗暴兜底不做精細(xì)規(guī)則。3.2 WAF規(guī)則實(shí)戰(zhàn)從托管規(guī)則到自定義CSRF防護(hù)文檔的Demo部分給了一段WAF V2規(guī)則JSON目標(biāo)是防CSRF跨站請(qǐng)求偽造核心邏輯用一句話概括當(dāng)請(qǐng)求頭里的x-csrf-token字段為空且URI命中/form.php時(shí)直接Block。我按文檔原意整理成了可直接調(diào)用的模板{ Name: A-matchCSRF, Priority: 4, Statement: { AndStatement: { Statements: [ { NotStatement: { Statement: { RegexPatternSetReferenceStatement: { ARN: arn:aws:wafv2:${REGION}:${ACCOUNT_ID}:regional/regexpatternset/csrf/${PATTERN_ID}, FieldToMatch: { SingleHeader: { Name: x-csrf-token } }, TextTransformations: [ { Priority: 0, Type: URL_DECODE } ] } } } }, { OrStatement: { Statements: [ { ByteMatchStatement: { SearchString: /form.php, FieldToMatch: { UriPath: {} }, TextTransformations: [ { Priority: 0, Type: NONE } ], PositionalConstraint: STARTS_WITH } }, { ByteMatchStatement: { SearchString: /form.php, FieldToMatch: { UriPath: {} }, TextTransformations: [ { Priority: 0, Type: NONE } ], PositionalConstraint: EXACTLY } } ] } } ] } }, Action: { Block: {} }, VisibilityConfig: { SampledRequestsEnabled: true, CloudWatchMetricsEnabled: true, MetricName: A-matchCSRF } }邏輯說(shuō)明這個(gè)規(guī)則用了三層嵌套。最外層AndStatement要求兩個(gè)條件同時(shí)滿足第一個(gè)條件用NotStatement套R(shí)egexPatternSetReferenceStatement含義是請(qǐng)求頭x-csrf-token的值不匹配預(yù)設(shè)的合法令牌正則第二個(gè)條件用OrStatement匹配URI路徑是/form.php開(kāi)頭或完全等于/form.php。兩者都成立才觸發(fā)Block動(dòng)作。參數(shù)說(shuō)明里要改三處REGION、ACCOUNT_ID、PATTERN_ID分別是WAF所在區(qū)域的代碼、你的賬號(hào)ID、正則表達(dá)式集的ID。更新規(guī)則時(shí)文檔明確提醒“通過(guò)JSON文檔調(diào)用單個(gè)API來(lái)創(chuàng)建或更新規(guī)則”不要手動(dòng)在控制臺(tái)重新點(diǎn)選否則容易漏掉嵌套條件。Priority: 4表示規(guī)則優(yōu)先級(jí)數(shù)字越小越先執(zhí)行。SampledRequestsEnabled開(kāi)啟后控制臺(tái)會(huì)采樣展示被該規(guī)則匹配的請(qǐng)求這是后續(xù)排查誤殺的關(guān)鍵證據(jù)。3.3 WAF監(jiān)控與告警閾值文檔專(zhuān)門(mén)強(qiáng)調(diào)了WAF的監(jiān)控可視化用CloudWatch看Web ACL中規(guī)則活動(dòng)的指標(biāo)基于預(yù)定義閾值設(shè)置告警。我一般給每條自定義規(guī)則配兩個(gè)告警一是BlockedRequests在5分鐘內(nèi)超過(guò)50次可能有人在掃漏洞二是AllowedRequests突然掉到正常值的一半以下大概率是規(guī)則誤殺。這兩個(gè)告警能覆蓋“攻進(jìn)來(lái)了”和“規(guī)則太嚴(yán)”兩個(gè)方向。4. 檢測(cè)、監(jiān)控與自動(dòng)響應(yīng)CloudTrail、GuardDuty、Config的閉環(huán)打法4.1 日志鏈路集中歸檔與不可篡改文檔的Layer 3是“云安全監(jiān)控自動(dòng)化”Layer 4是“合規(guī)自動(dòng)化”。實(shí)現(xiàn)這兩層的地基是日志。CloudTrail記錄所有API調(diào)用Config記錄資源狀態(tài)變更兩者產(chǎn)生的JSON日志如果散落在各賬號(hào)事后審計(jì)基本等于大海撈針。文檔給出的方案是集中日志架構(gòu)用AWS Organizations把所有賬號(hào)的CloudTrail和Config日志投遞到同一個(gè)日志歸檔賬號(hào)的S3桶里。存儲(chǔ)桶要開(kāi)啟版本控制和訪問(wèn)日志并設(shè)置生命周期策略把180天前的日志轉(zhuǎn)冷存取。這里有個(gè)容易被忽略的點(diǎn)S3桶策略要限制只能由組織內(nèi)的服務(wù)賬號(hào)寫(xiě)入否則日志可能被篡改。文檔里提到“強(qiáng)制匹配策略”的驗(yàn)證思路我的落地做法是給日志桶加一條基于條件的策略只允許源賬號(hào)ID列表里的角色執(zhí)行s3:PutObject。4.2 GuardDuty發(fā)現(xiàn)惡意行為后如何自動(dòng)響應(yīng)GuardDuty本身只負(fù)責(zé)檢測(cè)不負(fù)責(zé)處置。文檔的“事件自動(dòng)響應(yīng) 自動(dòng)驗(yàn)證”對(duì)應(yīng)的是檢測(cè)到問(wèn)題后要有人或系統(tǒng)接管。我的做法是GuardDuty發(fā)現(xiàn)UnauthorizedAccess:EC2/TorRelay或Recon:EC2/PortProbe后通過(guò)CloudWatch Events觸發(fā)Lambda把受害EC2實(shí)例的Security Group入站規(guī)則臨時(shí)清空并打上隔離標(biāo)簽同時(shí)發(fā)SNS通知運(yùn)維群。下面這段Python代碼是Lambda的骨架import boto3 import os ec2 boto3.client(ec2) sns boto3.client(sns) def lambda_handler(event, context): instance_id event[detail][resource][instanceDetails][instanceId] sg_id os.environ[ISOLATION_SG_ID] ec2.modify_instance_attribute( InstanceIdinstance_id, Groups[sg_id] ) sns.publish( TopicArnos.environ[SNS_TOPIC_ARN], SubjectGuardDuty Auto Isolation, MessageInstance {} has been isolated..format(instance_id) )邏輯說(shuō)明事件源是GuardDuty的發(fā)現(xiàn)事件detail.resource.instanceDetails.instanceId字段是受害實(shí)例ID。modify_instance_attribute把實(shí)例的安全組換成隔離安全組隔離組入站全部拒絕只保留運(yùn)維用的Session Manager通道。ISOLATION_SG_ID和SNS_TOPIC_ARN通過(guò)環(huán)境變量注入避免密鑰寫(xiě)死在代碼里。參數(shù)說(shuō)明里最需要關(guān)注的是隔離安全組的選擇。不要復(fù)用某個(gè)業(yè)務(wù)的既有安全組要單獨(dú)建一個(gè)“空安全組”只放行來(lái)自?xún)?nèi)部運(yùn)維CIDR的SSH和RDP。另外Lambda的執(zhí)行角色要限制為只允許ec2:ModifyInstanceAttribute和sns:Publish兩個(gè)動(dòng)作權(quán)限越小Lambda本身被攻破時(shí)的破壞面越小。4.3 合規(guī)校驗(yàn)Security Hub與Config規(guī)則的自動(dòng)化驗(yàn)證文檔強(qiáng)調(diào)“自動(dòng)合規(guī)審計(jì)驗(yàn)證能力”落到服務(wù)上是Security Hub聚合GuardDuty、Inspector、Macie等服務(wù)的發(fā)現(xiàn)項(xiàng)并用AWS Config規(guī)則做持續(xù)校驗(yàn)。我常用的做法是啟用一批核心Config托管規(guī)則s3-bucket-ssl-requests-only、iam-user-mfa-enabled、ec2-security-group-open-to-world其中最后一條能直接掃出所有對(duì)0.0.0.0/0放行的安全組配合SNS在24小時(shí)內(nèi)通知整改。Security Hub的聚合價(jià)值在于一個(gè)控制臺(tái)看全賬號(hào)的合規(guī)狀態(tài)。注意它的檢查項(xiàng)有“地區(qū)性”問(wèn)題如果多個(gè)賬號(hào)分屬不同區(qū)域需要在每個(gè)區(qū)域都啟用Security Hub并在管理賬號(hào)開(kāi)啟跨區(qū)域聚合否則控制臺(tái)看到的檢查結(jié)果不完整。5. 云上安全落地避坑賬號(hào)、權(quán)限、日志與規(guī)則的血淚經(jīng)驗(yàn)5.1 賬號(hào)與權(quán)限的坑坑一root賬戶的Access Key長(zhǎng)期存在。 現(xiàn)象云上成本異常飆升審計(jì)發(fā)現(xiàn)某臺(tái)被植入挖礦程序的EC2是用root密鑰起動(dòng)的。 原因早期圖省事用root的Access Key配置CLI沒(méi)有建獨(dú)立IAM用戶。 解決立即刪除root密鑰創(chuàng)建管理員IAM用戶并啟用MFA同時(shí)檢查現(xiàn)有IAM用戶里是否有人通過(guò)內(nèi)聯(lián)策略繞過(guò)了權(quán)限邊界?？佣呗岳锍霈F(xiàn)大量“*”通配符。 現(xiàn)象安全組被惡意修改多個(gè)生產(chǎn)實(shí)例被終止。 原因給角色附加了s3:*、ec2:*這類(lèi)通配策略攻擊者拿到臨時(shí)憑證后可以橫向破壞。 解決用ses:SendEmail代替ses:*用帶Resource限制的條件策略收斂范圍再配合權(quán)限邊界兜底。文檔的TOP10策略里那條“減少硬編碼的密鑰”也是同一個(gè)思路。5.2 網(wǎng)絡(luò)與日志的坑坑三安全組復(fù)制粘貼教程里的0.0.0.0/0。 現(xiàn)象漏洞掃描發(fā)現(xiàn)數(shù)據(jù)庫(kù)端口暴露在公網(wǎng)。 原因新人對(duì)CIDR不敏感直接照抄了教程里最常見(jiàn)的放行寫(xiě)法。 解決配置安全組時(shí)源地址優(yōu)先選擇另一個(gè)安全組ID而不是IP段必須用公網(wǎng)訪問(wèn)時(shí)把CIDR收斂到辦公網(wǎng)出口IP段。坑四CloudTrail只在一個(gè)區(qū)域開(kāi)啟。 現(xiàn)象某個(gè)海外區(qū)域的API操作查不到記錄上級(jí)要求追蹤時(shí)拿不出日志。 原因默認(rèn)只開(kāi)了當(dāng)前區(qū)域遺忘其他區(qū)域。 解決開(kāi)組織級(jí)CloudTrail并勾選“應(yīng)用到所有區(qū)域”日志投遞到集中日志桶。特別注意Include global service events要打開(kāi)否則IAM等全局服務(wù)的操作不會(huì)被記錄。坑五WAF規(guī)則上線后沒(méi)有看采樣請(qǐng)求。 現(xiàn)象線上業(yè)務(wù)大面積報(bào)錯(cuò)部分用戶無(wú)法提交表單。 原因CSRF規(guī)則的正則表達(dá)式集配置過(guò)嚴(yán)把合法請(qǐng)求也當(dāng)成無(wú)token處理。 解決上線前先把規(guī)則動(dòng)作設(shè)為Count運(yùn)行24小時(shí)觀察SampledRequests里被計(jì)數(shù)的請(qǐng)求確認(rèn)沒(méi)有正常流量后再改成Block。文檔里那句“強(qiáng)制匹配策略-A-matchcsrf-步驟”強(qiáng)調(diào)的就是拿JSON批量更新規(guī)則而不是手動(dòng)在控制臺(tái)逐條重建這樣可以快速回滾。6. 進(jìn)階驗(yàn)證把Landing Zone安全基線代碼化再親手攻一次自己6.1 用Landing Zone把安全基線變成模板文檔的TOP10架構(gòu)里L(fēng)anding Zone自動(dòng)化部署安全架構(gòu)排在第六位。它的作用不是“搭好一套環(huán)境”而是把前面章節(jié)提到的身份策略、日志投遞、網(wǎng)絡(luò)基線全部變成可重復(fù)部署的模板。落地時(shí)用AWS Control Tower創(chuàng)建多賬戶環(huán)境啟用CloudTrail和Config的集中日志歸檔用Service Catalog給業(yè)務(wù)賬號(hào)提供合規(guī)的VPC和IAM基線模板。下面是創(chuàng)建基線StackSet的一個(gè)CLI示例aws cloudformation create-stack-set \ --stack-set-name security-baseline \ --template-body file://security-baseline.yaml \ --permission-model SERVICE_MANAGED \ --auto-deployment Enabledtrue,RetainStacksOnAccountRemovalfalse邏輯說(shuō)明SERVICE_MANAGED表示由Organizations自動(dòng)決定向哪些賬號(hào)部署新加入的賬號(hào)也會(huì)自動(dòng)應(yīng)用這套基線。RetainStacksOnAccountRemovalfalse保證賬號(hào)被移除時(shí)基線隨之清理避免遺留安全組或IAM角色。6.2 驗(yàn)證方法給自己做一次攻擊演練基線代碼化之后必須驗(yàn)證它真的生效。我的習(xí)慣是每月做一次“自攻演練”用一個(gè)沒(méi)有權(quán)限的臨時(shí)角色調(diào)用s3:DeleteObject確認(rèn)返回AccessDenied。手動(dòng)修改一個(gè)測(cè)試安全組添加一條0.0.0.0/0入站規(guī)則等待15分鐘確認(rèn)Config把它標(biāo)記為NON_COMPLIANT。觸發(fā)一條測(cè)試用的GuardDuty發(fā)現(xiàn)確認(rèn)Lambda隔離流程在3分鐘內(nèi)完成。這套演練做完才能說(shuō)安全基線不是紙面基線。有一次我自測(cè)時(shí)發(fā)現(xiàn)Config規(guī)則評(píng)估結(jié)果遲遲不更新查了半天才發(fā)現(xiàn)規(guī)則觸發(fā)頻率是24小時(shí)測(cè)試環(huán)境改完規(guī)則得等一天。從那以后凡是新建Config規(guī)則我第一件事就是把觸發(fā)頻率改成TriggerOnConfigurationChange再手動(dòng)StartEvaluation確認(rèn)結(jié)果同步。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取