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