等保测评三级针对容器的测评要求

随着容器技术的广泛应用，企业通过容器化部署实现了应用快速交付与资源高效利用。然而，容器环境的安全性问题也日益凸显。等保测评三级作为我国网络安全等级保护制度的核心标准，对容器环境提出了明确的合规要求。本文将从身份认证、访问控制、数据保护、日志审计等维度，系统解析等保测评三级对容器的测评要求，并提供可落地的安全配置建议。

一、身份认证与访问控制：构建容器环境的第一道防线

1.1 容器主机与镜像仓库的身份认证

等保测评三级要求容器主机必须启用强身份认证机制，禁止使用默认账户或弱密码。例如，Linux容器主机应配置SSH密钥认证，禁用root用户直接登录；镜像仓库（如Harbor、Nexus）需集成LDAP或OAuth2.0协议，实现用户身份的集中管理。以Harbor为例，其配置文件harbor.yml中需明确指定认证模式：

auth_mode: ldap  # 或oauth2
ldap:
  url: ldap://ldap.example.com
  base_dn: dc=example,dc=com
  uid: uid
  filter: (objectClass=person)

1.2 容器间的细粒度访问控制

容器间通信需遵循最小权限原则。Kubernetes网络策略（NetworkPolicy）可通过标签选择器限制Pod间的访问。例如，仅允许前端Pod访问后端API服务：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: frontend-allow-backend
spec:
  podSelector:
    matchLabels:
      app: frontend
  policyTypes:
  - Egress
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: backend
    ports:
    - protocol: TCP
      port: 8080

1.3 动态权限管理：基于角色的访问控制（RBAC）

Kubernetes RBAC需结合企业组织架构，定义角色（Role）与角色绑定（RoleBinding）。例如，开发人员仅拥有部署到测试环境的权限：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: test
  name: developer-role
rules:
- apiGroups: [""]
  resources: ["pods", "deployments"]
  verbs: ["get", "list", "create", "update"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-binding
  namespace: test
subjects:
- kind: User
  name: dev@example.com
roleRef:
  kind: Role
  name: developer-role
  apiGroup: rbac.authorization.k8s.io

二、数据保护：确保容器存储与传输安全

2.1 容器镜像的签名与验证

镜像签名需使用GPG或Notary等工具，防止镜像被篡改。以Docker为例，签名流程如下：

# 生成GPG密钥
gpg --full-generate-key
# 导出公钥
gpg --export --armor > pubkey.gpg
# 签名镜像
cosign sign --key gpg://private-key.asc example/image:v1
# 验证镜像
cosign verify --key gpg://pubkey.gpg example/image:v1

2.2 敏感数据的加密存储

容器内敏感数据（如数据库密码、API密钥）需通过Secret管理，并启用加密存储。Kubernetes Secret默认以Base64编码存储，需结合加密提供程序（如KMS）实现加密：

apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
data:
  username: <Base64编码的用户名>
  password: <Base64编码的密码>

2.3 传输层安全（TLS）配置

容器间通信需强制使用TLS 1.2及以上版本。Nginx Ingress Controller配置示例：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: secure-ingress
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
spec:
  tls:
  - hosts:
    - example.com
    secretName: tls-secret
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: backend-service
            port:
              number: 8080

三、日志审计与监控：实现容器环境的可追溯性

3.1 容器运行日志的集中收集

需部署日志收集系统（如Fluentd、Filebeat），将容器日志发送至ELK或Splunk等分析平台。Fluentd配置示例：

<source>
  @type forward
  port 24224
</source>
<match **>
  @type elasticsearch
  host "elasticsearch.example.com"
  port 9200
  index_name "container-logs"
</match>

3.2 审计日志的完整性与不可篡改性

Kubernetes审计日志需配置为Metadata或Request级别，并存储至只读存储卷：

apiVersion: v1
kind: ConfigMap
metadata:
  name: audit-policy
data:
  audit-policy.yaml: |
    apiVersion: audit.k8s.io/v1
    kind: Policy
    rules:
    - level: Metadata
      resources:
      - group: ""
        resources: ["pods"]

3.3 异常行为的实时检测

需部署安全信息与事件管理（SIEM）系统，结合规则引擎（如Sigma）检测容器逃逸、端口扫描等攻击行为。例如，检测/tmp/kworker进程的Sigma规则：

title: Container Escape Detection
status: experimental
logsource:
  category: process_creation
  product: linux
detection:
  selection:
    Image: "/tmp/kworker"
  condition: selection
fields:
  - CommandLine
  - ParentCommandLine
falsepositives:
  - Legitimate administrative activity
level: critical

四、实施路径与建议

1. 差距分析：对照等保测评三级要求，梳理容器环境的合规差距，优先修复高风险项（如弱口令、未加密存储）。
2. 工具选型：选择支持等保合规的容器安全产品（如Aqua Security、Sysdig），避免自行开发导致覆盖不全。
3. 持续优化：定期进行渗透测试与红队演练，验证容器环境的安全性，并根据结果调整安全策略。

容器环境的安全合规是等保测评三级的重点领域。企业需从身份认证、数据保护、日志审计等维度构建纵深防御体系，并结合自动化工具实现持续监控与改进。通过本文的解析，开发者与企业用户可更清晰地理解等保要求，并落地可操作的安全方案。