Firewall策略和ACL

1）目标和原则

• Least privilege：只允许必要的（显式allow, implicit deny）。
• Segmentation：隔离环境（prod/stage/dev）、tenant、关键路径（PCI/KMS/DB）。
• Egress控制：出站流量仅限于FQDN/IP列表和私有endpoint 'ami。
• Identity-aware （L7）：通过身份验证实体（SPIFFE/OIDC）而非仅通过IP做出决策。
• 基础架构作为代码：规则作为代码，评论/CI/CD，更改审核。

2）分类法： 在哪里和什么过滤器

2.1层和状态

L3/L4无状态：经典ACL（CIDR，协议，端口）。
L3/L4 stateful： security groups/NSG,跟踪连接。
L7-aware：proxy/WAF/mesh RBAC（方法，路径，JWT-claims，SNI）。
Inline vs out-of-band： inline faervol路由流量；乐队外部-分析/警报。

2.2个轮廓

Perimeter: edge/WAF/Anti-DDoS.

Core: transit hub / меж-VPC/VNet.

Workload: SG/NSG на VM/ENI/POD.

App-level: Envoy/Istio/NGINX policy, service-to-service mTLS.

3）云模型

AWS

Security Group (SG): stateful на ENI/instance/LB.

网络ACL （NACL）：子网无状态、规则顺序、双向条目。
AWS Network Firewall/GWLB：L7 检查/IDS。

建议： "SG是主要控制，NACL是粗粒围栏/垃圾清单。"

Azure

NSG（静态），ASG（按标签的应用程序组），Azure FW for L7/IDS，Private Endpoints。
建议：NSG on Sabnet+NIC,服务标签通过ASG。

GCP

VPC Firewall Rules（状态）、Hierarchical FW（组织/文件夹）、Cloud Armor （L7）、Private Service Connect。
建议：org-level guardrails+设计allow。

4）规则设计： 模式

4.1个基本套件

Deny all egress →通过FQDN/IP允许使用：批处理存储库，寄存器工件，第三方API（通过私有/固定输出）。
东西部最低限度：服务仅与必要的依赖项通信。
管理访问：通过MFA 的基础/JIT，会话记录。

4.2 Tagi和乐队

使用labels/tags代替IP： "env"、"service"、"tier"、"tenant"、"pci=true"。
更改标记时更新策略-无需手动编辑IP网格。

4.3生命周期

Propose → Evaluate （staging） → Enforce （prod）,带有干跑/命中日志。
过时：每个规则的TTL/所有者，自动反驳未使用的规则。

5） Kubernetes和服务-mesh

5.1 NetworkPolicy (L3/L4)

最低限度是"禁止除必要以外的所有内容"。

yaml apiVersion: networking. k8s. io/v1 kind: NetworkPolicy metadata: { name: deny-all, namespace: core }
spec:
podSelector: {}
policyTypes: ["Ingress","Egress"]
kind: NetworkPolicy metadata: { name: api-egress }
spec:
podSelector: { matchLabels: { app: api } }
egress:
- to:
- namespaceSelector: { matchLabels: { ns: db } }
ports: [{ protocol: TCP, port: 5432 }]
- to:
- ipBlock: { cidr: 10. 100. 0. 0/16 } # Private endpoints ports: [{ protocol: TCP, port: 443 }]

5.2 L7 RBAC в mesh (Istio/Envoy)

mTLS+JWT/claims/scopes/path授权。

yaml apiVersion: security. istio. io/v1 kind: AuthorizationPolicy metadata: { name: api-rbac }
spec:
selector: { matchLabels: { app: api } }
rules:
- from:
- source:
principals: ["spiffe://svc. payments"]
to:
- operation: { methods: ["POST"], paths: ["/v1/payouts"] }
when:
- key: request. headers[x-tenant]
values: ["eu-1","eu-2"]

6）Egress控制和私人外围

首选PrivateLink/Private Service Connect到PaaS/寄存器/存储。
其余的egress通过NAT/代理使用 allowlist FQDN和固定IP（用于第三方allowlist）。
阻止Pod/VM直接进入互联网；仅通过egress网关排除。

7） DNS和SNI意识规则

Split-horizo​​n：内部区域不会在外部突出。
FW/Proxy支持外出HTTPS（SNI allow）的FQDN/SNI。
对特定供应商域进行修补；监视他们的IP更改。

8） Logi,审计,可观察性

启用flow logs （VPC/VNet/NSG/NACL）,发送到SIEM。
通过日志中的"trace_id"与应用程序相关联。
度量标准：命中/错过规则，top-talkers，落差，流量不对称，"漏电"。
报告："未使用的规则"，"最广泛的权限"。

9）代码管理（IaC）和验证

Terraform/CloudFormation+模块化模板策略。
政策作为代码（OPA/Gatekeeper/Conftest）：禁止'0。0.0.0/0'，要求"描述/所有者/ttl"，禁止混合prod/dev。
CI：lint，statanalysis，可实现性模拟器（reachability analyzer），计划查看，授权同行审查。

10）可达性测试和混乱

来自不同子网/AZ/地区的合成样本：TCP/443，特定的DB/经纪端口。
临时deny检查DR路径：禁用依赖关系→必须运行retries/circuit/fallback。
MTU/MSS： 确保perimeters（尤其是IPsec/NAT-T）上没有碎片。

11）性能和可靠性

避免集中化瓶颈：水平缩放inline-FW （GWLB/scale sets）。
ECMP/AS-path/BGP用于在中心之间分配。
TLS检查配置文件：点击（昂贵）、单独存储密钥打印、遵守合规性。

12）configs示例（参数，缩写）

12.1 AWS SG: API → Postgres + S3 PrivateLink

hcl resource "aws_security_group" "api" {
name    = "sg-api"
description = "Ingress from ALB, egress to DB and PrivateLink"
vpc_id   = var. vpc_id

ingress { from_port=8080 to_port=8080 protocol="tcp" security_groups=[aws_security_group. alb. id] }
egress { from_port=5432 to_port=5432 protocol="tcp" security_groups=[aws_security_group. db. id] }
egress { from_port=443 to_port=443 protocol="tcp" prefix_list_ids=[aws_vpc_endpoint. s3. prefix_list_id] }
tags = { owner="team-api", env=var. env, ttl="2026-01-01" }
}

12.2 Azure NSG: deny-by-default + allow bastion

bash az network nsg rule create -g rg -n allow-bastion --nsg-name nsg-app \
--priority 100 --direction Inbound --access Allow --protocol Tcp \
--source-address-prefixes 10. 0. 0. 10 --source-port-ranges "" \
--destination-port-ranges 22 --destination-address-prefixes 10. 1. 0. 0/16

12.3 GCP hierarchical firewall: org-guardrail

yaml direction: INGRESS priority: 1000 action: deny enableLogging: true match:
layer4Configs: [{ ipProtocol: "all" }]
srcIpRanges: ["0. 0. 0. 0/0"]
targetResources: ["organizations/123456"]

12.4 Envoy RBAC (L7 allow)

yaml
- name: envoy. filters. http. rbac typed_config:
rules:
action: ALLOW policies:
payments-post:
permissions: [{ url_path: { path: "/v1/payouts", ignore_case: true } }]
principals: [{ authenticated: { principal_name: { exact: "spiffe://svc. payments" } } }]

13）反模式

`0.0.0.0/0 'in ingress/egress"暂时"→永远存在。
"雪花"（控制台中的手动编辑）没有代码或修订。
prod/stage/dev的通用SG/NSG；关键和非关键子网的溷合。
缺乏盲目控制和私人结局，→泄露钥匙/秘密。
忽视DNS/SNI：允许提供商IP-明天它改变并打开了整个范围。
没有flow logs和runbook's → forenzik是不可能的。

14） iGaming/财务细节 （PCI/监管）

PCI CDE在单独的VRF/细分市场中，没有Internet；通过mTLS和HMAC的私人连接/代理访问PSP/Logs。
数据驻留：PII/支付事件-在国内/地区；跨区域-仅聚合/匿名。
KMS/Vault/HSM：单独的子网/SG，只有证书短的mTLS客户端。
WORM审核：不变存储（对象锁）中的FW/flow逻辑,重构≥监管最小值。
合作伙伴（PSP/KYC）：FQDN allowlist，静态egress IP，跨提供商监视SLA。

15）准备就绪支票清单

• 单一分割模型（hub-and-spoke, VRF）, CIDR无交叉点。

[] Deny-by-default на egress;PaaS/存储的私有端。

• 工作负载的SG/NSG状态，NACL/路由过滤器-到子网/枢纽。

[] K8s: NetworkPolicy «deny-all», mesh mTLS + L7 RBAC.

• 代替IP的标签/组；每个规则的主人/TTL/描述。

[] IaC + Policy-as-Code;具有可实现性模拟的CI；强制性同行评审。

• Flow logs包括在内；dashbords top-talkers，drop-rates；"egress泄漏"上的差异。
• 用于管理员访问的Bastion/JIT；MFA;会议日记。
• Runbook'和：如何添加/删除规则，如何在事件中工作；定期修订"死"规则。
• 用于PCI/财务： CDE隔离、WORM审核、PSP/KYC的FQDN allow、静态egress IP。

16) TL;DR

跨层构建保护：SG/NSG静态在滑行道上,NACL/路线过滤器在子网上, L7 RBAC在mesh/代理上, WAF/edge在外围。默认情况下为deny-by-default，egress仅通过受控点或私人终止。将规则描述为代码,通过策略和可实现性模拟器对其进行验证,收集流日志。对于iGaming/financial，在PSP/KYC中添加PCI细分，WORM审核和严格的FQDN allow。