4. 安全基线定义

4.1 什么是安全基线

安全基线（Security Baseline）是组织为信息系统、网络组件或服务定义的一组最低安全配置要求和合规规则。它描述了系统在“可接受的安全状态”下必须满足的条件集合，是安全审计、合规检查和自动化策略执行的基准参照点。

在云原生环境中，安全基线通常涵盖以下维度：

4.2 为什么需要流量安全基线

服务网格（如 Istio、Linkerd）将流量从应用代码中解耦，使流量管理、可观测性和安全策略可以集中定义。然而，这种灵活性也带来了新的风险——如果缺乏基线约束，网格内的流量拓扑可能变得混乱且不可控。

流量安全基线的必要性体现在以下四个方面：

1. 防止配置漂移： 在微服务规模增长时，手动配置容易遗漏或出错，基线提供自动化的合规校验。
2. 满足合规要求： 金融、医疗等行业要求所有服务间通信必须加密（如 PCI DSS、GDPR）。
3. 缩小攻击面： 未加密或未授权的流量路径可能被攻击者利用进行中间人攻击或横向移动。
4. 策略即代码： 将安全基线编码为 OPA 策略，可以在 Helm 部署时自动拦截违规配置。

4.3 常见基线违规场景

在服务网格流量拓扑中，以下三类违规场景最为常见，也是 Helm + OPA 策略需要重点拦截的目标：

4.3.1 非 TLS 流量

服务间使用明文 HTTP 而非 HTTPS 或 mTLS 通信。在服务网格中，即使启用了全局 mTLS，某些服务可能因为配置错误或兼容性原因退回到明文模式。

典型表现：

• DestinationRule 中 trafficPolicy.tls.mode 设置为 DISABLE 或 ISTIO_MUTUAL 未正确配置
• Service 注解 sidecar.istio.io/inject: "false" 导致 Sidecar 代理缺失
• PeerAuthentication 策略缺失或设置为 PERMISSIVE 模式

# 违规示例：DestinationRule 禁用了 TLS
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: my-service
spec:
  host: my-service.default.svc.cluster.local
  trafficPolicy:
    tls:
      mode: DISABLE  # 违规：明文传输

4.3.2 未授权访问

服务 A 可以访问服务 B 的敏感端点，但两者之间没有明确的授权策略。在零信任模型中，所有服务间调用都应经过显式授权。

典型表现：

• 缺少 AuthorizationPolicy 资源定义
• AuthorizationPolicy 的 action 设置为 ALLOW 但未指定 rules，导致允许所有流量
• 使用了过于宽泛的 source.principals 匹配（如 *）

# 违规示例：AuthorizationPolicy 允许所有来源
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-all
  namespace: default
spec:
  selector:
    matchLabels:
      app: sensitive-service
  action: ALLOW
  rules:
  - {}  # 违规：空规则允许所有请求

4.3.3 跨命名空间未授权访问

服务从命名空间 A 直接访问命名空间 B 中的服务，但未经过任何跨命名空间授权策略。这种场景在微服务拆分后尤为常见。

4.4 安全基线与 OPA 策略的映射关系

在 Helm + OPA 集成方案中，安全基线被编码为可执行的 Rego 策略。以下表格展示了基线要求到 OPA 策略的映射关系：