Amazon SCS-C02: 網路與 VPC 安全 — 學習指南

By Laurynas Brazys · 25 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

屬於 AWS Security Specialty SCS-C02 — 學習指南. 使用經過驗證的解答練習： Amazon 考試中心, 或參加限時模擬考試： ExamRoll.io.

VPC 端點與端點政策

VPC 端點能將流向 AWS 服務的流量保留在 AWS 網路上，繞過公用網際網路、NAT 閘道和網際網路閘道。VPC 端點有兩種結構上不同的類型，混淆這兩者是最常見的設計錯誤之一。

閘道端點 (Gateway endpoint) 僅適用於 Amazon S3 和 DynamoDB。它們是路由表中的項目——您將端點與路由表關聯，目的地為該服務字首清單 (例如在 us-east-1 中 S3 的 pl-63a5400a) 的流量會被靜默地重新路由到該端點。它們不需任何費用，且無法從其所附加的 VPC 外部存取。

介面端點 (Interface endpoint) (由 AWS PrivateLink 提供支援) 是放置在您子網路中、帶有私有 IP 位址的 ENI。除了 S3 和 DynamoDB 以外的所有服務都需要使用介面端點——例如 Secrets Manager、KMS、STS、SSM、CloudWatch Logs、ECR API/DKR 以及數百種其他服務。如果一個位於私有子網路中且沒有 NAT 閘道的 EC2 執行個體需要從 Secrets Manager 執行 GetSecretValue，閘道端點將無濟於事；您必須建立一個 com.amazonaws.<region>.secretsmanager 介面端點並啟用私有 DNS，這樣標準的服務主機名稱才能解析到該端點的私有 IP。

端點政策限制可以透過端點做什麼，這與呼叫端的 IAM 政策無關。用於防止資料外洩的兩個最重要的條件金鑰是 aws:PrincipalOrgID (發出呼叫的身分必須屬於您的 Organization) 和 aws:ResourceOrgID (正在存取的 S3 儲存貯體、KMS 金鑰等資源必須屬於您的 Organization)。同時應用這兩者可以封鎖典型的資料外洩路徑：一個被入侵的執行個體，雖然擁有合法的 S3 權限，但當它試圖寫入您組織外部、由攻擊者控制的儲存貯體時——即使其憑證對 S3 仍然有效，端點也會拒絕轉發該請求。

{
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",
    "Action": "s3:*",
    "Resource": "*",
    "Condition": {
      "StringEquals": {
        "aws:PrincipalOrgID": "o-abc123",
        "aws:ResourceOrgID":  "o-abc123"
      }
    }
  }]
}

預設的端點政策是完全允許 ("Action":"*" on "Resource":"*")，這就是為什麼一個僅有閘道端點和最低權限 IAM 的子網路，仍然可能被濫用於資料外洩——除非您收緊端點政策本身。

混合式連線：VPN 與 Direct Connect

Site-to-Site VPN 在虛擬私有閘道 (或 Transit Gateway) 和客戶閘道裝置之間建立兩個 IPsec 通道。它佈建快速、預設加密，並且會經過公用網際網路——因此吞吐量和延遲取決於您的 ISP 路徑。

AWS Direct Connect 透過一個 Direct Connect 位置佈建一條專用的實體線路。它提供可預測的低延遲和高且一致的頻寬 (1/10/100 Gbps)，這對於頻繁通訊的本地資料庫流量至關重要。Direct Connect 在第 3 層本身並未加密；其訊框在私有光纖上運行。對於既需要低延遲又需要 IPsec 的工作負載，標準的解決方案是 Direct Connect 加上一個運行在公用 VIF 上的 Site-to-Site VPN (或是在較新的 DX 連接埠上使用帶有 MACsec 的 Transit Gateway)。單獨使用 VPN 也是主要 Direct Connect 連結的建議加密備援方案，可在線路故障時提供彈性。

• 僅 Direct Connect： 低延遲、私有，但在 IP 層未加密。
• 僅 VPN： 加密、部署快速，但有網際網路路徑的延遲和抖動。
• Direct Connect + VPN： 低延遲且 IPsec 加密；也是標準的 HA 模式。

安全群組、NACL、DHCP 與來源/目的地檢查

安全群組是具狀態性的：如果您允許一個傳入的請求，其回應會自動被允許傳出。它們只支援允許規則，並且是針對每個 ENI 進行評估。

Network ACL (NACL) 是無狀態的，並在子網路邊界運作。每個流量都需要兩條規則——一條用於初始方向，另一條用於短暫連接埠範圍 (Linux 通常為 32768–60999，Windows 為 49152–65535，而 NLB/ELB 使用 1024–65535) 上的回傳流量。一個允許傳入 TCP 443 但忘記允許傳出 TCP 1024–65535 的 NACL 會靜默地中斷 TLS。ICMP 不是 TCP/UDP：回傳的 “echo reply” 封包必須明確允許，而路徑 MTU 探索 (Path MTU Discovery) 依賴於 ICMP 類型 3 代碼 4，這個很容易被不小心丟棄。NACL 規則也按數字順序評估，第一個符合的規則即生效，並在結尾有隱含的拒絕規則。

DHCP 選項集控制 VPC 在執行個體開機時提供給它們的內容：domain-name-servers、domain-name、NTP 伺服器、NetBIOS。用自訂的本地解析器取代預設的 AmazonProvidedDNS 可能是合法的，但會帶來實際的安全後果。像 GuardDuty 這類的服務，其基於 DNS 的發現項目 (例如「加密貨幣」和「C&C 網域」偵測) 是來自於經過 Route 53 Resolver 的查詢。一旦您將執行個體指向第三方 DNS 伺服器，GuardDuty 就再也看不到這些查詢，那些發現項目類型也會隨之消失——這是一種很容易不小心讓偵測功能失效的方式。

來源/目的地檢查是一個 ENI 屬性，它會丟棄任何來源或目的地 IP 與該 ENI 不符的封包。這個預設值對於一般的執行個體是正確的，但會中斷任何負責轉發流量的設備——例如 NAT 執行個體、虛擬防火牆 (Palo Alto、Fortinet、Check Point)、傳輸路由器、VPN 集中器。對於這些設備的 ENI，請停用此檢查：

aws ec2 modify-instance-attribute \
  --instance-id i-0abc123 \
  --no-source-dest-check

VPC 對等連線、RAM 共享 VPC 與 NAT 設計

VPC 對等連線是一種一對一、非遞移性的第三層連結。如果 A 與 B 對等，B 與 C 對等，A 無法連到 C——您必須直接建立 A–C 的對等連線，或使用 Transit Gateway。雙方的路由表都必須包含指向對等 CIDR 的路由，而安全群組只能在同一 Region 內參考對等方的安全群組 ID。

透過 AWS Resource Access Manager (RAM) 實現的共享 VPC，可讓一個網路帳戶擁有 VPC，並將個別子網路分享給參與者帳戶。參與者可在共享子網路中啟動資源，但無法修改 VPC、路由表或端點——擁有者保有連線政策的控制權。這通常比對等連接多個 VPC 更便宜、更簡單。

若要讓私有子網路能存取對外網際網路，請為每個可用區域部署一個 NAT gateway，並將每個私有子網路的路由指向其所在 AZ 的 NAT。單一 NAT gateway 會造成跨 AZ 的相依性，並成為擴展性與可用性的瓶頸。當您的工作負載呼叫需要將您的輸出 IP 加入白名單的第三方（例如支付處理商）時，您註冊的就是 NAT gateway 的 Elastic IP。由於 Auto Scaling group 後方的所有執行個體都透過該固定的 EIP 輸出，因此即使群組擴展，來源 IP 也不會改變。將 EC2 執行個體和 RDS 資料庫放在私有子網路中，並僅在 ALB 上終止 HTTP/HTTPS 流量，即可完成此模式。

Route 53 Resolver：轉送與查詢日誌

Route 53 Resolver（每個 VPC 中的 .2 位址）是混合式 DNS 的樞紐。輸出解析器端點會透過條件式轉送規則，將指定的網域名稱從 AWS 轉送到本地 DNS 伺服器——例如，讓 corp.example.internal 能對您的 Active Directory 進行解析。輸入解析器端點則反向操作，在您的 VPC 中提供一個私有 IP 給本地主機，讓它們可以查詢以解析 *.eu-west-1.compute.internal 和私有託管區域。

解析器查詢日誌會將 VPC 中發出的每個 DNS 查詢寫入 CloudWatch Logs、S3 或 Kinesis Firehose。這是調查可疑資料外洩或濫用的權威記錄，它能輔助 GuardDuty，但不能取代它。請記住，如果 DHCP 選項集將執行個體重新導向到非 Amazon 的解析器，那麼查詢日誌和 GuardDuty 的 DNS 發現結果都會失效，因為查詢從未觸及 Route 53 Resolver。

實務問題：使用案例情境

情境： Meridian Financial 採用多帳戶 AWS 環境，並設有中樞輻射式 (hub-and-spoke) 網路：一個透過 RAM 共享的共享服務 VPC，託管了中央 NAT Gateway、Route 53 Resolver 端點和 Transit Gateway 附件，而多個應用程式 VPC 則與 Transit Gateway 對等或連接。本地資料中心透過 Direct Connect 連接，並以 VPN 作為容錯移轉，團隊則依賴集中式的 DHCP 選項集和共享的解析器端點來進行混合式 DNS 解析。

挑戰： 最近一次事件顯示，由於輻射 VPC 將流量路由到共享的 NAT 而非 VPC 端點，導致敏感的 S3 物件可透過公用網際網路存取；內部區域的 DNS 查詢洩漏到公用解析器；以及一台被當作臨時路由器（來源/目的地檢查已停用）的 EC2 促成了橫向移動。

建議方法：

1. 在共享服務 VPC 中部署用於 S3 和 DynamoDB 的閘道 VPC 端點，以及用於 Secrets Manager 和 KMS 的介面端點 (AWS PrivateLink)，並附加明確的端點政策，將存取限制在指定的儲存貯體和服務主體。
2. 重新設計 NAT，讓應用程式子網路使用 VPC 端點存取 AWS API 和 S3；僅保留 NAT Gateway 用於真正的網際網路輸出，並搭配嚴格的輸出安全群組和傳送到 CloudWatch/S3 的 Flow Logs。
3. 在所有 EC2 執行個體上重新啟用來源/目的地檢查，已記錄的路由設備除外；將路由功能移至 Transit Gateway 附件或受管 NAT 執行個體，並強制執行路由表的最小權限原則。
4. 將安全群組和子網路 NACL 收緊為預設拒絕的態勢，並透過 AWS Organizations SCPs 和 AWS Config 規則應用集中式的 IAM+SG 基準。
5. 透過部署 Route 53 Resolver 輸入/輸出端點來強化混合式 DNS，設定條件式轉送和 DNS Firewall 規則，啟用解析器查詢日誌記錄到 CloudWatch Logs，並使用 DHCP 選項集強制所有透過 RAM 共享的 VPC 使用內部解析器。

理由： 此方法透過使用帶有端點政策的 VPC 端點，移除了不必要的網際網路輸出；透過 Transit Gateway/Direct Connect 集中化並控制路由；恢復了執行個體層級的保護；並利用 Resolver 端點和日誌記錄防止 DNS 洩漏——這與 AWS 的網路和深度防禦最佳實踐相符。

VPC 端點與端點政策

VPC 端點讓 VPC 內的工作負載能夠存取 AWS 服務的 API，而無需經過公開網際網路或 NAT 閘道。它有兩種架構類型，選擇錯誤是造成流量路由錯誤的常見原因。

• 閘道端點 (Gateway endpoints)： 僅用於 Amazon S3 和 DynamoDB。它們在路由表中被實作為一個目標 (一個指向 vpce-xxxxxxxx 的字首清單 pl-xxxxxxxx)。這個過程不會建立 ENI，也不需要變更 DNS，並且沒有每小時的費用。

• 介面端點 (Interface endpoints / PrivateLink)： 用於 KMS、SQS、SNS、Secrets Manager、STS、EC2 API 及大多數其他服務。它們會在您選擇的子網路內部署帶有私有 IP 的 ENI，並按小時及每 GB 流量計費。

對於一個跨帳戶的批次作業，其中帳戶 B 的 EC2 執行個體需要讀取帳戶 A 中、由帳戶 A 的 KMS 金鑰加密的 S3 儲存貯體，正確的設計是為 S3 建立一個閘道端點，並為 KMS 建立一個介面端點。閘道端點讓 s3:GetObject、s3:PutObject、s3:PutObjectAcl 和 s3:ListBucket 等操作不經過網際網路；介面端點則對 kms:Decrypt、kms:Encrypt 和 kms:GenerateDataKey 達到同樣效果。由於 KMS 金鑰的 ARN 使用標準的 kms.<region>.amazonaws.com 主機名稱，介面端點必須啟用私有 DNS (Private DNS enabled)，這樣 SDK 未經修改的主機名稱請求才能解析到端點 ENI 的 IP，而不是公開的 KMS 服務。若沒有啟用私有 DNS (或者 VPC 層級的 DNS 主機名稱和 DNS 解析功能沒有同時啟用)，客戶端仍然會連到公開端點——因此，「無需變更程式碼」這個要求隱含地需要啟用私有 DNS。

端點政策是第二層獨立的授權機制。雖然預設存在一個寬鬆的政策，但若要針對特定的儲存貯體和金鑰進行強化，可以參考如下設定：

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",
    "Action": ["s3:GetObject","s3:PutObject","s3:PutObjectAcl","s3:ListBucket"],
    "Resource": ["arn:aws:s3:::acct-a-bucket","arn:aws:s3:::acct-a-bucket/*"]
  }]
}

僅僅建立端點是不夠的。有兩種常見的失敗模式：(1) 端點已存在，但私有子網路的路由表沒有指向 S3 字首清單的條目，導致流量仍然透過 NAT 閘道出去；(2) 端點政策遺漏了某個動作 (如 s3:PutObjectAcl) 或指定的儲存貯體 ARN 不正確，導致那些原本 IAM 會允許的呼叫被靜默地阻擋。儲存貯體政策和端點政策都必須允許該請求——它們之間是交集 (intersected) 關係，而非聯集 (unioned)。

安全群組、NACL 與快速隔離

安全群組和 NACL 在不同層級解決了部分重疊的問題，而考試經常要求您在事件應對情境中對兩者做出選擇。

• 安全群組 (Security groups)： 有狀態的 (Stateful)，在 ENI 層級進行評估。回程流量會自動被允許。只有允許規則。非常適合用於主機層級的政策 (例如「Web 層可以存取應用層的 8080 連接埠」)。

• 網路 ACL (Network ACLs)： 無狀態的 (Stateless)，在子網路邊界進行評估。同時存在允許和拒絕規則，並按規則編號順序處理。非常適合用於粗略的、整個子網路範圍的封鎖——特別是當需要封鎖一個 IP 範圍或關閉某個子網路中所有執行個體的特定連接埠時。

當惡意軟體爆發，迫使您必須阻擋多個執行個體對外連到一組 C&C (中繼站) IP 的 TCP/2905 連線時，NACL 的拒絕規則是正確的工具。安全群組無法表達「拒絕」，且需要逐一列舉並修改每個受影響 ENI 所參考的安全群組。而一個位於子網路層級、規則編號較小 (例如 90) 的 NACL 拒絕規則，可以立即涵蓋該子網路中的所有執行個體，同時不影響由後續允許規則評估的其他無關流量。

因為 NACL 是無狀態的，請記得雙向都需要規則。阻擋 2905 連接埠的出向流量不需要設定入向規則，但如果您也想拒絕入向的回應，就必須新增一條入向規則——同時，必須存在針對臨時連接埠 (1024–65535) 的入向允許規則，以讓合法的回程流量通過。

NAT 閘道、路由與可用區獨立性

NAT 閘道是可用區級 (zonal) 的資源。標準的模式是每個可用區 (AZ) 配置一個 NAT 閘道，並讓每個私有子網路的路由表將 0.0.0.0/0 的流量指向位於相同 AZ 的 NAT 閘道：

PrivateRouteTable-AZ-a:  0.0.0.0/0 -> nat-aaaa (in subnet public-az-a)
PrivateRouteTable-AZ-b:  0.0.0.0/0 -> nat-bbbb (in subnet public-az-b)
PrivateRouteTable-AZ-c:  0.0.0.0/0 -> nat-cccc (in subnet public-az-c)

跨 AZ 共享單一 NAT 閘道看似更便宜，但會引發兩個問題：每個封包都會產生跨可用區的資料傳輸費用，以及一個硬性的可用性依賴——如果該 AZ 發生故障，所有私有子網路都會失去對外連網的能力。當與 Transit Gateway 的流量檢測結合使用時，這種每個可用區一個 NAT 的模式也能避免非對稱回傳的異常情況 (詳見下文)。

使用 VPC 流程日誌進行調查

流程日誌 (Flow Logs) 可以在 VPC、子網路或 ENI 層級擷取 5-tuple 中繼資料 (來源/目的 IP、連接埠、協定、動作 ACCEPT/REJECT、位元組、封包)。要找出那些向 C&C 主機發出 TCP/2905 信標的執行個體，請在 VPC 上啟用流程日誌，將流量類型設定為 REJECT (因為 NACL 現在會丟棄這些流量)，然後在 CloudWatch Logs Insights 或 Athena 中進行查詢：

SELECT srcaddr, dstaddr, dstport, action, COUNT(*) AS hits
FROM vpc_flow_logs
WHERE dstport = 2905 AND action = 'REJECT'
GROUP BY srcaddr, dstaddr, dstport, action
ORDER BY hits DESC;

srcaddr 欄位能以最少的力氣揭露受感染執行個體的 IP——無需進行封包擷取，也無需安裝主機代理程式。選擇 “ALL” 流量類型也可以，但會產生更多資料和成本；如果只選擇 “ACCEPT”，則會完全錯過被丟棄的嘗試，而這正是您需要看到的資訊。

PrivateLink、Transit Gateway 與 Network Firewall

PrivateLink 將 interface-endpoint 模型擴展到您自己的服務：提供者 VPC 在 VPC 端點服務後面公開一個 NLB，而消費者則建立 interface endpoint 來存取它，無需 VPC peering 或路由共享。它是單向的，並完全隱藏提供者的 CIDR。

Transit Gateway (TGW) 是實現多對多 VPC 和地端連線的樞紐 (hub)。一個常見的模式是建立一個集中式檢測 VPC，在其中運行 AWS Network Firewall 或第三方設備，並透過 TGW 路由表將 spoke-to-spoke 流量導向此檢測 VPC。在預設的 TGW 行為下，這種設計會失效，因為 TGW 會在不同 AZ 的附件 ENI 之間對流量進行雜湊處理，導致回程路徑可能會進入與去程路徑不同的 AZ。狀態式防火牆會丟棄它們從未見過 SYN 的中途封包。

需要同時進行兩項修正。首先，在檢測 VPC 的 TGW 附件上啟用 Appliance Mode；這會將每個雙向流量固定到同一個 AZ ENI，以確保去程和回程路徑都經過同一個防火牆端點。其次，設定 TGW 路由表，讓 spoke 附件將流量傳送到檢測 VPC 附件，並在檢測 VPC 上使用一個獨立的檢測後路由表，將流量送回正確的 spoke。若省略其中任何一項——無論是只啟用 appliance mode 而未設定路由表，或是只設定路由表而未啟用 appliance mode——都會導致非對稱丟包問題依然存在。

Network Firewall 本身使用與 Suricata 相容的規則，並依賴對稱路由來維持流量狀態；將其與檢測 VPC 和 spoke VPC 上的 Flow Logs 結合使用，可以提供所需的鑑識軌跡，以證明哪個 spoke 發起了會話，以及防火牆是允許還是丟棄了該會話。

實務問題：使用案例情境

情境： Meridian Financial 營運一個多帳戶的 AWS 環境，其生產環境 VPC 橫跨 us-east-1 的三個可用區域 (Availability Zones)，並透過一個 AWS Transit Gateway 連接到一個中央安全 VPC。他們在每個 AZ 中使用 NAT Gateway 處理出口流量，使用 S3 Gateway Endpoints 和 Interface Endpoints (PrivateLink) 連接合作夥伴的 SaaS，並採用一個集中式的 AWS Network Firewall，同時搭配 Security Groups 和 NACL；VPC Flow Logs 則串流到 CloudWatch 進行監控。

挑戰： 一個生產環境的 EC2 執行個體被懷疑有橫向移動和資料外洩的企圖，試圖連到一個外部 IP 和 S3。Meridian 需要在不中斷其他關鍵業務 VPC 的情況下，跨 AZ 快速進行圍堵。

建議方法：

1. 立即隔離受感染的執行個體，將其 Security Groups 替換為一個拒絕所有出站/入站流量的限制性「隔離」SG，並為該執行個體加上標籤，以便透過 Systems Manager 進行自動化修復；同時，在子網路層級套用 Network ACL 規則，以阻擋對可疑外部 IP 範圍的出口流量。
2. 在 Transit Gateway 上隔離該 VPC，方法是移除或更改受影響 VPC 的 TGW 路由表附件，將其指向一個隔離用的 TGW 路由表（黑洞或無路由到其他附件），以阻止對其他 VPC 的橫向移動。
3. 更新 TGW/路由表項目，將剩餘的 VPC 出口流量重新導向到集中式的 AWS Network Firewall，以強制進行檢測並阻擋已知的惡意目的地；同時透過在每個 AZ 保留 NAT Gateway 來維持 AZ 的獨立性，以實現具備彈性且經過檢測的出口流量。
4. 強化資料平面的控制，在 S3/DynamoDB Gateway Endpoints 上套用限制性的 VPC Endpoint 政策，拒絕來自未經批准的 principal 的 Put/Get 操作，並確保內部 API 使用 Interface Endpoints (PrivateLink) 以避免經過網際網路路徑。
5. 使用 VPC Flow Logs 搭配 CloudWatch Logs Insights 和 AWS CloudTrail 進行鑑識分析，然後進行修復（重新映像、輪換金鑰），並在驗證後才重新引入該執行個體；透過 AWS Firewall Manager/AWS Config 強制執行規則。

基本原理： 這個順序在主機和網路層級提供了快速、最小權限的圍堵，透過 Network Firewall 和 Transit Gateway 路由進行集中式檢測以最小化爆炸半徑，透過每個 AZ 的 NAT 來保持 AZ 的彈性，並使用 VPC Flow Logs 進行可究責的調查——這一切都符合 AWS 的深度防禦最佳實踐。

← 資料保護與 S3 · 所有領域 · 邊緣與應用程式安全 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →

瀏覽 Amazon →