搭建企业私有镜像仓库，很多人第一步就直奔Docker Registry或者Harbor，结果在公网暴露测试时直接被扫描器抓走镜像，或者在内部被横向移动攻击。真正的问题从来不是“怎么搭”，而是“怎么安全地搭”。基于Debian 12，我们要做的是一套从系统内核参数到应用层访问控制都覆盖到的纵深防御体系，而不是简单套个HTTPS就完事。

先看系统层面的加固。Debian 12默认的AppArmor和iptables规则对容器场景不够用，必须主动调整。安装完系统后，第一时间锁定内核网络参数，尤其是针对SYN Flood和IP欺骗的防御。编辑/etc/sysctl.d/99-security.conf，写入以下内容：

net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.default.secure_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0

这些参数直接关闭了ICMP重定向、源路由等可能被利用的网络特性，同时开启SYN Cookie防止半连接攻击。执行sysctl -p使其立即生效。这只是第一层，接下来必须用iptables构建严格的出入站规则。企业私有仓库通常只需要对内部网段开放，默认策略应该是DROP所有入站，只放行特定来源的HTTPS端口。假设仓库服务器IP为192.168.10.50，内部网段为192.168.0.0/16，规则如下：

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp -s 192.168.0.0/16 --dport 443 -j ACCEPT
iptables -A INPUT -p tcp -s 192.168.0.0/16 --dport 22 -j ACCEPT

注意SSH端口同样限制在内网段，彻底杜绝公网暴力破解。如果运维需要从外部访问，必须通过堡垒机或VPN，但这不在本文讨论范围内。规则保存使用iptables-persistent包，确保重启不丢失。

镜像仓库选型与安全基线

Docker Registry够轻量，但企业场景下缺少权限控制和镜像扫描，所以更推荐Harbor。Harbor自带漏洞扫描器Trivy、内容信任公证人Notary以及基于项目的RBAC，这些是私有仓库安全的基础设施。在Debian 12上部署Harbor，不要用默认的HTTP模式，哪怕内网环境也强制HTTPS。证书可以用内部CA签发，但必须严格管理CA私钥。生成自签名证书的命令如下：

openssl genrsa -out ca.key 4096
openssl req -x509 -new -nodes -sha512 -days 3650 -key ca.key -out ca.crt -subj "/CN=Internal-CA"
openssl genrsa -out harbor.key 4096
openssl req -new -sha512 -key harbor.key -out harbor.csr -subj "/CN=harbor.internal.local"
openssl x509 -req -in harbor.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out harbor.crt -days 3650 -sha512

把ca.crt分发到所有需要访问仓库的客户端Docker证书目录，路径为/etc/docker/certs.d/harbor.internal.local/ca.crt，这样Docker守护进程才能信任内部CA。Harbor安装采用离线包方式，从官方GitHub下载后，修改harbor.yml配置文件，核心安全参数包括：hostname必须与证书CN一致；https端口绑定443；harbor_admin_password使用强密码且首次登录后立即修改；database密码、redis密码全部替换为随机生成的高强度字符串；最关键的是，把clair或trivy的漏洞扫描更新地址改为内部镜像源，避免扫描器主动外联暴露仓库存在。

镜像签名与内容信任

即使HTTPS加密了传输，也无法防止镜像在推送后被篡改或替换。Docker Content Trust基于Notary实现镜像签名，确保从构建到部署全链路完整性。在Harbor中启用内容信任后，只有经过签名的镜像才能被拉取。配置步骤：首先在Harbor项目管理中勾选“启用内容信任”；然后在推送镜像的CI/CD流水线中设置环境变量DOCKER_CONTENT_TRUST=1，并在推送前用仓库私钥签名。私钥的保管是核心，建议存储在硬件安全模块或至少是加密的离线介质中，绝不能放在CI服务器明文目录下。

对于高安全需求的企业，还可以结合Cosign进行无密钥签名，利用OIDC身份提供商实现短期密钥签名，避免长期私钥泄露风险。不过Cosign需要额外部署Fulcio和Rekor，复杂度较高，初期可先用Notary过渡。

访问控制与网络隔离

Harbor的RBAC粒度到项目级别，但实际安全策略必须延伸到网络层。即使内网，也不应该让所有网段都能访问仓库。利用Debian 12的iptables按源IP做第一道过滤，Harbor内部再按项目划分角色。例如：生产环境镜像项目只允许CI/CD服务器的IP拉取，开发环境项目只允许开发网段。这种双层控制能有效防止开发人员误拉生产镜像或越权推送。

另外，Harbor的数据库PostgreSQL默认监听在localhost，但配置文件中有可能被改成0.0.0.0，务必检查harbor.yml中相关配置，确保数据库和Redis只绑定127.0.0.1。如果必须远程管理数据库，使用SSH隧道转发，绝不直接暴露端口。

镜像漏洞扫描与阻断

Harbor集成的Trivy扫描器默认在镜像推送时自动触发，但默认策略是“允许通过”，这意味着即使发现高危漏洞，镜像依然可以被拉取。必须修改为“阻止拉取”，在项目配置的漏洞扫描策略中，将严重级别设置为“阻止”，并勾选“阻止包含CVE的镜像被拉取”。这样任何存在已知高危漏洞的镜像都会被自动隔离。

Trivy的漏洞库需要定期更新，但直接访问公网漏洞源可能泄露内部资产信息。解决方案是搭建内部漏洞库镜像代理，或者使用离线更新包。Trivy支持--skip-update参数配合本地缓存，可以在安全机器上下载漏洞库后同步到仓库服务器，彻底切断外联。

审计日志与异常检测

所有镜像拉取、推送、删除操作都会被Harbor记录在数据库中，但默认日志保留时间有限且没有告警机制。需要配置日志转发到内部SIEM系统，例如ELK或Wazuh。Harbor支持将日志输出到syslog，在harbor.yml中设置log_rotate_count和log_rotate_size控制本地轮转，同时修改core组件的日志驱动为syslog。Debian 12自带的rsyslog可以配置转发规则，将特定tag的日志发送到集中日志服务器。

异常检测规则至少包含：非工作时间的大量镜像拉取、同一IP短时间内多次认证失败、从非CI网段发起的推送操作。这些规则在SIEM中配置，一旦触发立即通知安全团队。很多镜像泄露事件事后追溯才发现，攻击者早在数周前就通过盗取的凭证持续拖取镜像。

存储加密与备份

镜像层以文件形式存储在Harbor宿主机磁盘上，如果硬盘被盗或报废时未妥善销毁，数据就会泄露。Debian 12支持LUKS全盘加密，在安装系统时就应该启用。对于已上线的服务器，可以用cryptsetup对镜像存储目录单独加密。但注意加密会带来性能损耗，建议在存储节点使用自加密硬盘，或至少在备份到外部介质时强制加密。

备份策略不仅要备份镜像文件，还要备份Harbor的数据库和配置文件。使用pg_dump导出PostgreSQL数据库，配合rsync同步镜像存储目录到加密的备份服务器。备份数据本身也要用GPG加密，命令示例：

pg_dump -U postgres registry > harbor_db.sql
tar czf - /data/harbor | gpg --symmetric --cipher-algo AES256 -o harbor_backup.tar.gz.gpg

解密时需要输入密码，密码通过企业密码库管理，不与备份文件存放在一起。

客户端安全配置

服务器端再安全，客户端配置不当也会前功尽弃。所有访问私有仓库的Docker守护进程必须配置--insecure-registry的反面，即严格验证证书。在/etc/docker/daemon.json中添加：

{
  "registry-mirrors": [],
  "insecure-registries": [],
  "log-driver": "syslog",
  "log-opts": {
    "tag": "docker"
  }
}

明确清空insecure-registries数组，防止有人误添加。同时将Docker日志也输出到syslog，统一审计。对于Kubernetes集群，containerd的配置同样需要指定证书路径，在config.toml中配置：

[plugins."io.containerd.grpc.v1.cri".registry.configs."harbor.internal.local".tls]
  ca_file = "/etc/docker/certs.d/harbor.internal.local/ca.crt"

确保容器运行时也走加密通道并验证服务器身份。

定期安全评估

部署完成不是终点。每月至少执行一次针对仓库服务器的漏洞扫描，使用OpenVAS或Nessus从内网角度探测。同时检查Harbor自身是否有新版本发布，尤其是安全补丁。Harbor的升级相对平滑，但升级前务必在测试环境验证，特别是数据库迁移脚本。另外，定期审查用户权限，清理离职人员账号，轮换服务账号密码，这些基础运维动作往往是安全防线中最薄弱的环节。

私有镜像仓库的安全不是单一产品能解决的，它需要从系统层、网络层、应用层到客户端形成闭环。Debian 12的稳定性和长期支持为底层提供了可靠基础，但真正的安全水位取决于策略执行的严格程度和持续运营的投入。把每一项配置都落到实处，比追逐最新的安全概念更有价值。