戰(zhàn)：深度解析安全組（Security Groups）與網(wǎng)絡(luò) ACL（NACL）)
教程文檔DevOps【免費(fèi)下載鏈接】aws-devops-zero-to-heroAWS zero to hero repo for devops engineers to learn AWS in 30 Days. This repo includes projects, presentations, interview questions and real time examples.項(xiàng)目地址https://gitcode.com/GitHub_Trending/aw/aws-devops-zero-to-hero點(diǎn)擊查看免費(fèi)下載導(dǎo)讀本文圍繞 aws-devops-zero-to-hero 倉庫的 day-5 文檔 展開系統(tǒng)講解 AWS 網(wǎng)絡(luò)中兩大核心安全組件——安全組Security Groups與網(wǎng)絡(luò)訪問控制列表Network Access Control ListsNACL的工作原理、配置規(guī)則與適用邊界。讀完本文你將掌握如何在實(shí)例級與子網(wǎng)級分別構(gòu)建流量過濾策略能正確區(qū)分有狀態(tài)與無狀態(tài)防火墻的行為差異并結(jié)合倉庫中的 Terraform 代碼與面試題場景獨(dú)立設(shè)計(jì)具備縱深防御defense-in-depth的 VPC 安全架構(gòu)。一、為什么需要安全組與 NACLVPC 網(wǎng)絡(luò)安全的層次結(jié)構(gòu)AWS 通過虛擬私有云VPC為用戶提供隔離的虛擬網(wǎng)絡(luò)環(huán)境。正如 day-4 文檔 所描述的VPC 允許你像經(jīng)營本地數(shù)據(jù)中心一樣運(yùn)營云上網(wǎng)絡(luò)并在此基礎(chǔ)上通過路由表、網(wǎng)關(guān)、安全組、NACL、VPC Flow Logs等組件實(shí)現(xiàn)精細(xì)的流量控制與訪問管理。在安全層面AWS 采用多層縱深防御的設(shè)計(jì)思路子網(wǎng)邊界由 NACL 在子網(wǎng)入口/出口處進(jìn)行無狀態(tài)過濾實(shí)例邊界由安全組在 EC2 實(shí)例及其網(wǎng)絡(luò)接口上執(zhí)行有狀態(tài)的虛擬防火墻規(guī)則應(yīng)用與賬號層配合 IAM 權(quán)限、加密等手段進(jìn)一步收斂攻擊面。安全組與 NACL 是這兩層防御中最核心的組件兩者共同工作才能既控制流量能否進(jìn)入某個子網(wǎng)又控制流量能否到達(dá)某臺具體實(shí)例。二、安全組Security Groups實(shí)例級的虛擬防火墻2.1 核心概念與工作原理安全組本質(zhì)上是為 Amazon EC2 實(shí)例虛擬服務(wù)器提供實(shí)例級別防護(hù)的虛擬防火墻其工作方式如下內(nèi)容繼承自 day-5 文檔控制粒度在實(shí)例層面控制入站inbound與出站outbound流量通過允許或拒絕特定協(xié)議、端口和 IP 地址來放行或攔截流量。關(guān)聯(lián)方式每臺 EC2 實(shí)例可關(guān)聯(lián)一個或多個安全組每個安全組由一組入站規(guī)則和一組出站規(guī)則組成。規(guī)則方向入站規(guī)則決定允許哪些流量到達(dá)實(shí)例出站規(guī)則決定允許哪些流量離開實(shí)例。匹配來源可以使用 IP 地址、CIDR 網(wǎng)段、安全組 ID 或 DNS 名稱來指定流量的來源source或目的地destination。評估位置在實(shí)例層面運(yùn)行規(guī)則在流量到達(dá)實(shí)例之前完成評估。有狀態(tài)stateful這是安全組最重要的特性之一——若入站規(guī)則放行了某條流量則對應(yīng)的出站回包會自動被允許反之亦然。你無需為回包單獨(dú)編寫反向規(guī)則。即時生效安全組規(guī)則的修改立即生效無需等待傳播非常適合快速響應(yīng)安全事件或調(diào)整訪問策略。2.2 默認(rèn)行為安全組遵循默認(rèn)全拒、顯式放行原則默認(rèn)情況下安全組拒絕所有入站流量除非顯式添加允許規(guī)則默認(rèn)允許所有出站流量除非顯式收緊同一安全組內(nèi)的實(shí)例之間默認(rèn)也不互相放行需顯式配置。2.3 倉庫中的安全組實(shí)戰(zhàn)代碼Terraform 示例在倉庫的 day-24/main.tf 中展示了一個完整的aws_security_group資源配置它同時開放了 HTTP 與 SSH 入站并放行全部出站流量resource aws_security_group webSg { name web vpc_id aws_vpc.myvpc.id ingress { description HTTP from VPC from_port 80 to_port 80 protocol tcp cidr_blocks [0.0.0.0/0] } ingress { description SSH from_port 22 to_port 22 protocol tcp cidr_blocks [0.0.0.0/0] } egress { from_port 0 to_port 0 protocol -1 cidr_blocks [0.0.0.0/0] } tags { Name Web-sg } }這段代碼體現(xiàn)了安全組規(guī)則的四個關(guān)鍵參數(shù)參數(shù)含義示例值說明from_port/to_port允許的端口范圍80–80表示僅放行 HTTP寫成0–0表示不限制端口protocol協(xié)議類型tcp表示 TCP-1表示所有協(xié)議常用于 egresscidr_blocks來源/目的網(wǎng)段0.0.0.0/0表示任意來源生產(chǎn)環(huán)境建議收斂為特定 IP 或 VPC 網(wǎng)段description規(guī)則用途說明便于運(yùn)維審計(jì)與團(tuán)隊(duì)協(xié)作進(jìn)一步看該安全組隨后被綁定到兩臺 Web 服務(wù)器day-24/main.tf#L78-L92以及應(yīng)用負(fù)載均衡器 ALBday-24/main.tf#L95-L106resource aws_instance webserver1 { ami ami-0261755bbcb8c4a84 instance_type t2.micro vpc_security_group_ids [aws_security_group.webSg.id] subnet_id aws_subnet.sub1.id user_data base64encode(file(userdata.sh)) }這里使用了vpc_security_group_ids屬性將安全組掛載到實(shí)例上——印證了每臺 EC2 實(shí)例可以關(guān)聯(lián)一個或多個安全組這一核心概念。同時 ALB 也復(fù)用同一個安全組security_groups [aws_security_group.webSg.id]說明安全組可以跨多種資源復(fù)用包括實(shí)例、負(fù)載均衡器、Lambda 等掛載了彈性網(wǎng)絡(luò)接口ENI的資源。2.4 生產(chǎn)環(huán)境中的安全組最佳實(shí)踐用安全組 ID 作為來源實(shí)現(xiàn)實(shí)例間互相放行例如 Web 層放行來自 App 層安全組的 8080 端口比寫死 IP 更靈活、更安全SSH22 端口入站不要開放給0.0.0.0/0應(yīng)限制為公司出口 IP 或使用堡壘機(jī)bastion host遵循最小權(quán)限原則只開放業(yè)務(wù)真正需要的端口將安全組按分層命名如web-sg、app-sg、db-sg便于理解流量流向。三、網(wǎng)絡(luò)訪問控制列表NACL子網(wǎng)級的無狀態(tài)過濾器3.1 核心概念與工作原理NACL 是 AWS 提供的第二層網(wǎng)絡(luò)防護(hù)運(yùn)行在子網(wǎng)邊界上。其工作方式如下內(nèi)容繼承自 day-5 文檔防護(hù)位置在子網(wǎng)層面充當(dāng)無狀態(tài)的入站/出站流量過濾器工作在子網(wǎng)邊界。關(guān)聯(lián)關(guān)系與安全組不同NACL綁定子網(wǎng)——每個子網(wǎng)只能關(guān)聯(lián)一個NACL但多個子網(wǎng)可以共享同一個 NACL。規(guī)則編號NACL 由一組按升序編號的規(guī)則組成流量按規(guī)則號從低到高依次匹配最先匹配到編號最小且命中的規(guī)則決定放行還是拒絕。規(guī)則要素每條規(guī)則包含規(guī)則編號rule number、協(xié)議、規(guī)則動作allow 或 deny、源/目的 IP 地址范圍、端口范圍以及 ICMP 類型。支持顯式拒絕NACL 規(guī)則既可以 allow 也可以deny這是與安全組只能 allow的重要區(qū)別。無狀態(tài)stateless如果入站規(guī)則放行了某條流量對應(yīng)的出站回包必須由單獨(dú)的出站規(guī)則顯式放行系統(tǒng)不會自動處理回包方向。生效延遲NACL 規(guī)則的修改可能需要一些時間才能傳播到該子網(wǎng)關(guān)聯(lián)的所有資源上。3.2 默認(rèn) NACL 行為AWS 為每個 VPC 創(chuàng)建默認(rèn) NACL它允許所有入站與出站流量自定義 NACL 默認(rèn)拒絕所有入站與出站流量需要顯式添加放行規(guī)則默認(rèn) NACL 與默認(rèn)安全組的策略方向正好相反配置時務(wù)必留意。3.3 無狀態(tài)帶來的配置陷阱由于 NACL 是無狀態(tài)的一個經(jīng)典的配置是若子網(wǎng)內(nèi)實(shí)例需要對外發(fā)起 HTTP 請求除了出站規(guī)則放行80目的端口外還必須添加一條入站規(guī)則放行1024-65535等臨時端口ephemeral ports以接收對端返回的數(shù)據(jù)包。類似地實(shí)例對外的 SSH 會話也需要同時配置入站22與出站臨時端口放行規(guī)則。下表是一個典型的 Web 子網(wǎng) NACL 規(guī)則設(shè)計(jì)示例規(guī)則編號方向類型協(xié)議端口范圍源/目的 IP動作100入站HTTPTCP800.0.0.0/0ALLOW110入站HTTPSTCP4430.0.0.0/0ALLOW120入站SSHTCP22辦公網(wǎng)段ALLOW*入站全部ALL全部0.0.0.0/0DENY兜底100出站HTTPTCP800.0.0.0/0ALLOW110出站臨時端口TCP1024-655350.0.0.0/0ALLOW*出站全部ALL全部0.0.0.0/0DENY兜底規(guī)則號以*結(jié)尾的為默認(rèn)兜底規(guī)則無法修改、無法刪除它匹配所有未被編號規(guī)則命中的流量。在設(shè)計(jì)時應(yīng)為每類放行規(guī)則預(yù)留足夠的編號間隔如 10、20、30……方便后續(xù)插入新規(guī)則而無需整體重排。四、安全組 vs NACL一張表看清核心差異結(jié)合 day-5 文檔 與倉庫 day-8 面試問答 中的論述兩者的核心差異可歸納如下對比維度安全組Security GroupNACL作用層級實(shí)例級ENI子網(wǎng)級關(guān)聯(lián)對象一個實(shí)例可關(guān)聯(lián)多個安全組一個子網(wǎng)只能關(guān)聯(lián)一個 NACL多個子網(wǎng)可共享狀態(tài)性有狀態(tài)stateful自動放行回包無狀態(tài)stateless入站/出站規(guī)則需分別配置規(guī)則動作僅 allow默認(rèn)拒絕全部入站支持 allow 與 deny 顯式拒絕規(guī)則匹配全部規(guī)則統(tǒng)一評估無優(yōu)先級按規(guī)則號從小到大順序匹配首個命中的規(guī)則生效生效時間修改立即生效修改可能需要時間傳播來源指定IP、CIDR、安全組 ID、DNS 名稱IP 與 CIDR 網(wǎng)段默認(rèn)出站默認(rèn)允許全部出站默認(rèn)拒絕全部出站一句話記憶安全組是實(shí)例門口的智能門衛(wèi)記住誰進(jìn)來就放誰出去NACL 是子網(wǎng)海關(guān)的無狀態(tài)安檢進(jìn)出的每一包都要單獨(dú)過一遍規(guī)則。五、實(shí)戰(zhàn)場景兩層防護(hù)如何協(xié)同工作5.1 面向場景的組合式安全架構(gòu)在 day-8 面試問答 中給出了一個典型的安全架構(gòu)設(shè)計(jì)思路在設(shè)計(jì)安全架構(gòu)時我會在子網(wǎng)層面配置 NACL基于源/目的 IP、端口和協(xié)議強(qiáng)制執(zhí)行出入流量限制NACL 是無狀態(tài)的可在子網(wǎng)邊界提供額外一道防線。在實(shí)例層面則利用安全組控制出入流量安全組是有狀態(tài)的通過精心定義的規(guī)則按應(yīng)用安全需求放行或拒絕流量。將 NACL 與安全組結(jié)合可以在網(wǎng)絡(luò)層與實(shí)例層同時獲得細(xì)粒度的安全控制為敏感應(yīng)用提供縱深防御。這一設(shè)計(jì)對應(yīng)了經(jīng)典的 Web 三層架構(gòu)公共子網(wǎng)Public Subnet部署負(fù)載均衡器如倉庫 day-24/main.tf 中的 ALB對外暴露 80/443私有子網(wǎng)Private Subnet部署應(yīng)用服務(wù)器僅接受來自負(fù)載均衡器安全組的流量數(shù)據(jù)層數(shù)據(jù)庫僅對應(yīng)用層開放特定端口。在該架構(gòu)中NACL 負(fù)責(zé)在子網(wǎng)邊界攔截大范圍攻擊流量如全端口掃描、來自異常網(wǎng)段的訪問安全組則在實(shí)例層面對具體端口、來源做精細(xì)化管控。即便 NACL 配置失誤漏放安全組仍可兜底反之亦然——這正是縱深防御的價值所在。5.2 倉庫中的完整 VPC 安全落地參考倉庫 day-24/main.tf 提供了一個可運(yùn)行的端到端示例創(chuàng)建 VPCCIDR10.0.0.0/24、10.0.1.0/24兩個子網(wǎng)、互聯(lián)網(wǎng)網(wǎng)關(guān)、路由表與安全組并將兩臺 Web 服務(wù)器與一個 ALB 掛到同一安全組下。你可以參照該文件通過terraform init terraform apply在測試賬號中實(shí)際驗(yàn)證安全組放行 80/22 → 實(shí)例對外可訪問的完整鏈路對應(yīng) provider.tf 與 variables.tf 提供基礎(chǔ)設(shè)施配置入口。六、常見誤區(qū)與運(yùn)維排查要點(diǎn)誤區(qū)一以為 NACL 修改立即生效。實(shí)際上 NACL 規(guī)則的傳播存在延遲變更后請稍候并驗(yàn)證不能像安全組那樣即時反饋。誤區(qū)二NACL 放行入站后以為回包自動放行。無狀態(tài)特性要求出站方向單獨(dú)配置否則會出現(xiàn)能發(fā)請求、收不到響應(yīng)的詭異現(xiàn)象。誤區(qū)三只配安全組不配 NACL。安全組無法對其他實(shí)例也共享的該子網(wǎng)內(nèi)流量進(jìn)行邊界攔截也無法做顯式 deny兩者應(yīng)組合使用。排查工具遇到連通性問題時可結(jié)合 VPC Flow Logs 確認(rèn)流量是在 NACL 層還是安全組層被丟棄同時核對規(guī)則匹配順序NACL 按編號、安全組為全量評估。七、總結(jié)安全組與 NACL 是 AWS 網(wǎng)絡(luò)安全的基石安全組實(shí)例級、有狀態(tài)、僅 allow、即時生效——適合精細(xì)化控制單臺/多臺資源的訪問NACL子網(wǎng)級、無狀態(tài)、可顯式 deny、按編號順序匹配——適合在子網(wǎng)邊界建立第一道粗粒度防線。在 aws-devops-zero-to-hero 倉庫中day-5 文檔 給出了兩者的完整理論框架day-24/main.tf 提供了安全組的真實(shí) Terraform 落地代碼day-8 面試問答 則補(bǔ)充了二者的對比思路與架構(gòu)設(shè)計(jì)用例。將三份材料結(jié)合閱讀你便能在理論—代碼—面試三個維度上完整掌握 AWS 雙層網(wǎng)絡(luò)防御體系的實(shí)戰(zhàn)技能。贊分享教程文檔DevOps【免費(fèi)下載鏈接】aws-devops-zero-to-heroAWS zero to hero repo for devops engineers to learn AWS in 30 Days. This repo includes projects, presentations, interview questions and real time examples.項(xiàng)目地址https://gitcode.com/GitHub_Trending/aw/aws-devops-zero-to-hero點(diǎn)擊查看免費(fèi)下載相關(guān)推薦DevOps面試實(shí)戰(zhàn)aws-devops-zero-to-hero場景題解析DevOps面試實(shí)戰(zhàn)aws devops zero to hero場景題解析 引言掌握AWS DevOps場景面試的要點(diǎn)與解決方案 你是否在DevOps面試教程文檔DevOpsDevOps配置管理aws-devops-zero-to-hero Ansible實(shí)戰(zhàn)DevOps配置管理aws devops zero to hero Ansible實(shí)戰(zhàn) 一、配置管理的痛點(diǎn)與Ansible解決方案 你是否正面臨這些配置管理困教程文檔DevOpsAWS無服務(wù)器架構(gòu)aws-devops-zero-to-hero Lambda實(shí)戰(zhàn)AWS無服務(wù)器架構(gòu)aws devops zero to hero Lambda實(shí)戰(zhàn) 引言你還在為服務(wù)器運(yùn)維煩惱嗎 在云計(jì)算時代服務(wù)器管理、容量規(guī)劃和運(yùn)維教程文檔DevOps上一篇system-design-notes 終極28章速查表系統(tǒng)設(shè)計(jì)面試高頻題目完整索引清單下一篇15分鐘搞定黑蘋果OpCore Simplify智能配置工具終極指南創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 AWS DevOps Zero to Hero 實(shí)戰(zhàn)：深度解析安全組（Security Groups）與網(wǎng)絡(luò) ACL（NACL）
教程文檔DevOps【免費(fèi)下載鏈接】aws-devops-zero-to-heroAWS zero to hero repo for devops engineers to learn AWS in 30 Days. This repo includes projects, presentations, interview questions and real time examples.項(xiàng)目地址https://gitcode.com/GitHub_Trending/aw/aws-devops-zero-to-hero點(diǎn)擊查看免費(fèi)下載導(dǎo)讀本文圍繞 aws-devops-zero-to-hero 倉庫的 day-5 文檔 展開系統(tǒng)講解 AWS 網(wǎng)絡(luò)中兩大核心安全組件——安全組Security Groups與網(wǎng)絡(luò)訪問控制列表Network Access Control ListsNACL的工作原理、配置規(guī)則與適用邊界。讀完本文你將掌握如何在實(shí)例級與子網(wǎng)級分別構(gòu)建流量過濾策略能正確區(qū)分有狀態(tài)與無狀態(tài)防火墻的行為差異并結(jié)合倉庫中的 Terraform 代碼與面試題場景獨(dú)立設(shè)計(jì)具備縱深防御defense-in-depth的 VPC 安全架構(gòu)。一、為什么需要安全組與 NACLVPC 網(wǎng)絡(luò)安全的層次結(jié)構(gòu)AWS 通過虛擬私有云VPC為用戶提供隔離的虛擬網(wǎng)絡(luò)環(huán)境。正如 day-4 文檔 所描述的VPC 允許你像經(jīng)營本地數(shù)據(jù)中心一樣運(yùn)營云上網(wǎng)絡(luò)并在此基礎(chǔ)上通過路由表、網(wǎng)關(guān)、安全組、NACL、VPC Flow Logs等組件實(shí)現(xiàn)精細(xì)的流量控制與訪問管理。在安全層面AWS 采用多層縱深防御的設(shè)計(jì)思路子網(wǎng)邊界由 NACL 在子網(wǎng)入口/出口處進(jìn)行無狀態(tài)過濾實(shí)例邊界由安全組在 EC2 實(shí)例及其網(wǎng)絡(luò)接口上執(zhí)行有狀態(tài)的虛擬防火墻規(guī)則應(yīng)用與賬號層配合 IAM 權(quán)限、加密等手段進(jìn)一步收斂攻擊面。安全組與 NACL 是這兩層防御中最核心的組件兩者共同工作才能既控制流量能否進(jìn)入某個子網(wǎng)又控制流量能否到達(dá)某臺具體實(shí)例。二、安全組Security Groups實(shí)例級的虛擬防火墻2.1 核心概念與工作原理安全組本質(zhì)上是為 Amazon EC2 實(shí)例虛擬服務(wù)器提供實(shí)例級別防護(hù)的虛擬防火墻其工作方式如下內(nèi)容繼承自 day-5 文檔控制粒度在實(shí)例層面控制入站inbound與出站outbound流量通過允許或拒絕特定協(xié)議、端口和 IP 地址來放行或攔截流量。關(guān)聯(lián)方式每臺 EC2 實(shí)例可關(guān)聯(lián)一個或多個安全組每個安全組由一組入站規(guī)則和一組出站規(guī)則組成。規(guī)則方向入站規(guī)則決定允許哪些流量到達(dá)實(shí)例出站規(guī)則決定允許哪些流量離開實(shí)例。匹配來源可以使用 IP 地址、CIDR 網(wǎng)段、安全組 ID 或 DNS 名稱來指定流量的來源source或目的地destination。評估位置在實(shí)例層面運(yùn)行規(guī)則在流量到達(dá)實(shí)例之前完成評估。有狀態(tài)stateful這是安全組最重要的特性之一——若入站規(guī)則放行了某條流量則對應(yīng)的出站回包會自動被允許反之亦然。你無需為回包單獨(dú)編寫反向規(guī)則。即時生效安全組規(guī)則的修改立即生效無需等待傳播非常適合快速響應(yīng)安全事件或調(diào)整訪問策略。2.2 默認(rèn)行為安全組遵循默認(rèn)全拒、顯式放行原則默認(rèn)情況下安全組拒絕所有入站流量除非顯式添加允許規(guī)則默認(rèn)允許所有出站流量除非顯式收緊同一安全組內(nèi)的實(shí)例之間默認(rèn)也不互相放行需顯式配置。2.3 倉庫中的安全組實(shí)戰(zhàn)代碼Terraform 示例在倉庫的 day-24/main.tf 中展示了一個完整的aws_security_group資源配置它同時開放了 HTTP 與 SSH 入站并放行全部出站流量resource aws_security_group webSg { name web vpc_id aws_vpc.myvpc.id ingress { description HTTP from VPC from_port 80 to_port 80 protocol tcp cidr_blocks [0.0.0.0/0] } ingress { description SSH from_port 22 to_port 22 protocol tcp cidr_blocks [0.0.0.0/0] } egress { from_port 0 to_port 0 protocol -1 cidr_blocks [0.0.0.0/0] } tags { Name Web-sg } }這段代碼體現(xiàn)了安全組規(guī)則的四個關(guān)鍵參數(shù)參數(shù)含義示例值說明from_port/to_port允許的端口范圍80–80表示僅放行 HTTP寫成0–0表示不限制端口protocol協(xié)議類型tcp表示 TCP-1表示所有協(xié)議常用于 egresscidr_blocks來源/目的網(wǎng)段0.0.0.0/0表示任意來源生產(chǎn)環(huán)境建議收斂為特定 IP 或 VPC 網(wǎng)段description規(guī)則用途說明便于運(yùn)維審計(jì)與團(tuán)隊(duì)協(xié)作進(jìn)一步看該安全組隨后被綁定到兩臺 Web 服務(wù)器day-24/main.tf#L78-L92以及應(yīng)用負(fù)載均衡器 ALBday-24/main.tf#L95-L106resource aws_instance webserver1 { ami ami-0261755bbcb8c4a84 instance_type t2.micro vpc_security_group_ids [aws_security_group.webSg.id] subnet_id aws_subnet.sub1.id user_data base64encode(file(userdata.sh)) }這里使用了vpc_security_group_ids屬性將安全組掛載到實(shí)例上——印證了每臺 EC2 實(shí)例可以關(guān)聯(lián)一個或多個安全組這一核心概念。同時 ALB 也復(fù)用同一個安全組security_groups [aws_security_group.webSg.id]說明安全組可以跨多種資源復(fù)用包括實(shí)例、負(fù)載均衡器、Lambda 等掛載了彈性網(wǎng)絡(luò)接口ENI的資源。2.4 生產(chǎn)環(huán)境中的安全組最佳實(shí)踐用安全組 ID 作為來源實(shí)現(xiàn)實(shí)例間互相放行例如 Web 層放行來自 App 層安全組的 8080 端口比寫死 IP 更靈活、更安全SSH22 端口入站不要開放給0.0.0.0/0應(yīng)限制為公司出口 IP 或使用堡壘機(jī)bastion host遵循最小權(quán)限原則只開放業(yè)務(wù)真正需要的端口將安全組按分層命名如web-sg、app-sg、db-sg便于理解流量流向。三、網(wǎng)絡(luò)訪問控制列表NACL子網(wǎng)級的無狀態(tài)過濾器3.1 核心概念與工作原理NACL 是 AWS 提供的第二層網(wǎng)絡(luò)防護(hù)運(yùn)行在子網(wǎng)邊界上。其工作方式如下內(nèi)容繼承自 day-5 文檔防護(hù)位置在子網(wǎng)層面充當(dāng)無狀態(tài)的入站/出站流量過濾器工作在子網(wǎng)邊界。關(guān)聯(lián)關(guān)系與安全組不同NACL綁定子網(wǎng)——每個子網(wǎng)只能關(guān)聯(lián)一個NACL但多個子網(wǎng)可以共享同一個 NACL。規(guī)則編號NACL 由一組按升序編號的規(guī)則組成流量按規(guī)則號從低到高依次匹配最先匹配到編號最小且命中的規(guī)則決定放行還是拒絕。規(guī)則要素每條規(guī)則包含規(guī)則編號rule number、協(xié)議、規(guī)則動作allow 或 deny、源/目的 IP 地址范圍、端口范圍以及 ICMP 類型。支持顯式拒絕NACL 規(guī)則既可以 allow 也可以deny這是與安全組只能 allow的重要區(qū)別。無狀態(tài)stateless如果入站規(guī)則放行了某條流量對應(yīng)的出站回包必須由單獨(dú)的出站規(guī)則顯式放行系統(tǒng)不會自動處理回包方向。生效延遲NACL 規(guī)則的修改可能需要一些時間才能傳播到該子網(wǎng)關(guān)聯(lián)的所有資源上。3.2 默認(rèn) NACL 行為AWS 為每個 VPC 創(chuàng)建默認(rèn) NACL它允許所有入站與出站流量自定義 NACL 默認(rèn)拒絕所有入站與出站流量需要顯式添加放行規(guī)則默認(rèn) NACL 與默認(rèn)安全組的策略方向正好相反配置時務(wù)必留意。3.3 無狀態(tài)帶來的配置陷阱由于 NACL 是無狀態(tài)的一個經(jīng)典的配置是若子網(wǎng)內(nèi)實(shí)例需要對外發(fā)起 HTTP 請求除了出站規(guī)則放行80目的端口外還必須添加一條入站規(guī)則放行1024-65535等臨時端口ephemeral ports以接收對端返回的數(shù)據(jù)包。類似地實(shí)例對外的 SSH 會話也需要同時配置入站22與出站臨時端口放行規(guī)則。下表是一個典型的 Web 子網(wǎng) NACL 規(guī)則設(shè)計(jì)示例規(guī)則編號方向類型協(xié)議端口范圍源/目的 IP動作100入站HTTPTCP800.0.0.0/0ALLOW110入站HTTPSTCP4430.0.0.0/0ALLOW120入站SSHTCP22辦公網(wǎng)段ALLOW*入站全部ALL全部0.0.0.0/0DENY兜底100出站HTTPTCP800.0.0.0/0ALLOW110出站臨時端口TCP1024-655350.0.0.0/0ALLOW*出站全部ALL全部0.0.0.0/0DENY兜底規(guī)則號以*結(jié)尾的為默認(rèn)兜底規(guī)則無法修改、無法刪除它匹配所有未被編號規(guī)則命中的流量。在設(shè)計(jì)時應(yīng)為每類放行規(guī)則預(yù)留足夠的編號間隔如 10、20、30……方便后續(xù)插入新規(guī)則而無需整體重排。四、安全組 vs NACL一張表看清核心差異結(jié)合 day-5 文檔 與倉庫 day-8 面試問答 中的論述兩者的核心差異可歸納如下對比維度安全組Security GroupNACL作用層級實(shí)例級ENI子網(wǎng)級關(guān)聯(lián)對象一個實(shí)例可關(guān)聯(lián)多個安全組一個子網(wǎng)只能關(guān)聯(lián)一個 NACL多個子網(wǎng)可共享狀態(tài)性有狀態(tài)stateful自動放行回包無狀態(tài)stateless入站/出站規(guī)則需分別配置規(guī)則動作僅 allow默認(rèn)拒絕全部入站支持 allow 與 deny 顯式拒絕規(guī)則匹配全部規(guī)則統(tǒng)一評估無優(yōu)先級按規(guī)則號從小到大順序匹配首個命中的規(guī)則生效生效時間修改立即生效修改可能需要時間傳播來源指定IP、CIDR、安全組 ID、DNS 名稱IP 與 CIDR 網(wǎng)段默認(rèn)出站默認(rèn)允許全部出站默認(rèn)拒絕全部出站一句話記憶安全組是實(shí)例門口的智能門衛(wèi)記住誰進(jìn)來就放誰出去NACL 是子網(wǎng)海關(guān)的無狀態(tài)安檢進(jìn)出的每一包都要單獨(dú)過一遍規(guī)則。五、實(shí)戰(zhàn)場景兩層防護(hù)如何協(xié)同工作5.1 面向場景的組合式安全架構(gòu)在 day-8 面試問答 中給出了一個典型的安全架構(gòu)設(shè)計(jì)思路在設(shè)計(jì)安全架構(gòu)時我會在子網(wǎng)層面配置 NACL基于源/目的 IP、端口和協(xié)議強(qiáng)制執(zhí)行出入流量限制NACL 是無狀態(tài)的可在子網(wǎng)邊界提供額外一道防線。在實(shí)例層面則利用安全組控制出入流量安全組是有狀態(tài)的通過精心定義的規(guī)則按應(yīng)用安全需求放行或拒絕流量。將 NACL 與安全組結(jié)合可以在網(wǎng)絡(luò)層與實(shí)例層同時獲得細(xì)粒度的安全控制為敏感應(yīng)用提供縱深防御。這一設(shè)計(jì)對應(yīng)了經(jīng)典的 Web 三層架構(gòu)公共子網(wǎng)Public Subnet部署負(fù)載均衡器如倉庫 day-24/main.tf 中的 ALB對外暴露 80/443私有子網(wǎng)Private Subnet部署應(yīng)用服務(wù)器僅接受來自負(fù)載均衡器安全組的流量數(shù)據(jù)層數(shù)據(jù)庫僅對應(yīng)用層開放特定端口。在該架構(gòu)中NACL 負(fù)責(zé)在子網(wǎng)邊界攔截大范圍攻擊流量如全端口掃描、來自異常網(wǎng)段的訪問安全組則在實(shí)例層面對具體端口、來源做精細(xì)化管控。即便 NACL 配置失誤漏放安全組仍可兜底反之亦然——這正是縱深防御的價值所在。5.2 倉庫中的完整 VPC 安全落地參考倉庫 day-24/main.tf 提供了一個可運(yùn)行的端到端示例創(chuàng)建 VPCCIDR10.0.0.0/24、10.0.1.0/24兩個子網(wǎng)、互聯(lián)網(wǎng)網(wǎng)關(guān)、路由表與安全組并將兩臺 Web 服務(wù)器與一個 ALB 掛到同一安全組下。你可以參照該文件通過terraform init terraform apply在測試賬號中實(shí)際驗(yàn)證安全組放行 80/22 → 實(shí)例對外可訪問的完整鏈路對應(yīng) provider.tf 與 variables.tf 提供基礎(chǔ)設(shè)施配置入口。六、常見誤區(qū)與運(yùn)維排查要點(diǎn)誤區(qū)一以為 NACL 修改立即生效。實(shí)際上 NACL 規(guī)則的傳播存在延遲變更后請稍候并驗(yàn)證不能像安全組那樣即時反饋。誤區(qū)二NACL 放行入站后以為回包自動放行。無狀態(tài)特性要求出站方向單獨(dú)配置否則會出現(xiàn)能發(fā)請求、收不到響應(yīng)的詭異現(xiàn)象。誤區(qū)三只配安全組不配 NACL。安全組無法對其他實(shí)例也共享的該子網(wǎng)內(nèi)流量進(jìn)行邊界攔截也無法做顯式 deny兩者應(yīng)組合使用。排查工具遇到連通性問題時可結(jié)合 VPC Flow Logs 確認(rèn)流量是在 NACL 層還是安全組層被丟棄同時核對規(guī)則匹配順序NACL 按編號、安全組為全量評估。七、總結(jié)安全組與 NACL 是 AWS 網(wǎng)絡(luò)安全的基石安全組實(shí)例級、有狀態(tài)、僅 allow、即時生效——適合精細(xì)化控制單臺/多臺資源的訪問NACL子網(wǎng)級、無狀態(tài)、可顯式 deny、按編號順序匹配——適合在子網(wǎng)邊界建立第一道粗粒度防線。在 aws-devops-zero-to-hero 倉庫中day-5 文檔 給出了兩者的完整理論框架day-24/main.tf 提供了安全組的真實(shí) Terraform 落地代碼day-8 面試問答 則補(bǔ)充了二者的對比思路與架構(gòu)設(shè)計(jì)用例。將三份材料結(jié)合閱讀你便能在理論—代碼—面試三個維度上完整掌握 AWS 雙層網(wǎng)絡(luò)防御體系的實(shí)戰(zhàn)技能。贊分享教程文檔DevOps【免費(fèi)下載鏈接】aws-devops-zero-to-heroAWS zero to hero repo for devops engineers to learn AWS in 30 Days. This repo includes projects, presentations, interview questions and real time examples.項(xiàng)目地址https://gitcode.com/GitHub_Trending/aw/aws-devops-zero-to-hero點(diǎn)擊查看免費(fèi)下載相關(guān)推薦DevOps面試實(shí)戰(zhàn)aws-devops-zero-to-hero場景題解析DevOps面試實(shí)戰(zhàn)aws devops zero to hero場景題解析 引言掌握AWS DevOps場景面試的要點(diǎn)與解決方案 你是否在DevOps面試教程文檔DevOpsDevOps配置管理aws-devops-zero-to-hero Ansible實(shí)戰(zhàn)DevOps配置管理aws devops zero to hero Ansible實(shí)戰(zhàn) 一、配置管理的痛點(diǎn)與Ansible解決方案 你是否正面臨這些配置管理困教程文檔DevOpsAWS無服務(wù)器架構(gòu)aws-devops-zero-to-hero Lambda實(shí)戰(zhàn)AWS無服務(wù)器架構(gòu)aws devops zero to hero Lambda實(shí)戰(zhàn) 引言你還在為服務(wù)器運(yùn)維煩惱嗎 在云計(jì)算時代服務(wù)器管理、容量規(guī)劃和運(yùn)維教程文檔DevOps上一篇system-design-notes 終極28章速查表系統(tǒng)設(shè)計(jì)面試高頻題目完整索引清單下一篇15分鐘搞定黑蘋果OpCore Simplify智能配置工具終極指南創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考