随着云计算和远程办公的普及，传统的”城堡护城河”式网络边界防御模型日益暴露其局限性。攻击者一旦突破边界，便可在内网中横向移动、肆意妄为。堡垒机和零信任架构分别从运维审计和架构设计两个维度，为企业提供了更精细化的安全管控能力。本文将详细介绍堡垒机的核心功能与 JumpServer 部署实战，以及零信任架构的原理和实施路径。
堡垒机概念与核心功能
什么是堡垒机
堡垒机（Bastion Host），也称为跳板机（Jump Server），是部署在安全区域与被管理区域之间的专用安全设备。所有运维人员必须先登录堡垒机，再通过堡垒机访问后端服务器、数据库、网络设备等。堡垒机充当了运维操作的”统一入口”和”安全闸门”。
核心功能
身份认证与访问控制：支持多因素认证（MFA）、LDAP/AD 集成、SSO 单点登录。基于角色的访问控制（RBAC）确保每个运维人员只能访问被授权的资产。
会话审计与录像：堡垒机对所有运维操作进行实时录像和记录，包括 SSH 命令、RDP 操作、数据库查询等。这些审计记录是事后追溯和合规审查的重要依据。
权限管控：支持命令过滤（黑白名单），可以禁止执行高危命令（如 rm -rf、shutdown）。支持时间窗口控制，仅在规定时间段内允许访问。
资产管理：统一管理所有 IT 资产，包括服务器、数据库、Kubernetes 集群、网络设备等。支持自动发现和动态资产管理。
堡垒机部署架构
┌──────────────┐
│ 运维人员 │
└──────┬───────┘
│ MFA认证
┌──────▼───────┐
│ 堡垒机 │ ← 审计录像、权限管控
└──────┬───────┘
┌───────────────┼───────────────┐
┌──────▼──────┐ ┌──────▼──────┐ ┌──────▼──────┐
│ Linux 服务器 │ │ Windows 服务器│ │ 数据库/网络设备│
└─────────────┘ └─────────────┘ └─────────────┘JumpServer 开源堡垒机部署
JumpServer 是全球首款完全开源的堡垒机，使用 Python 和 Go 开发，支持 SSH、RDP、VNC、数据库（MySQL/PostgreSQL/Redis/MongoDB）、Kubernetes 等多种协议和资产类型。
Docker 快速部署
# 系统要求：CPU 2核+, 内存 4GB+, 磁盘 50GB+
# 支持 Linux (CentOS 7+, Ubuntu 18.04+)
# 安装 Docker 和 Docker Compose
curl -fsSL https://get.docker.com | bash
sudo systemctl enable docker && sudo systemctl start docker
# 安装 Docker Compose
sudo curl -L "https://github.com/docker/compose/releases/latest/download/docker-compose-$(uname -s)-$(uname -m)" \
-o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose使用官方一键安装脚本
# 下载安装脚本
curl -sSL https://resource.fit2cloud.com/jumpserver/jumpserver/releases/latest/download/quick_start.sh | bash
# 或手动方式
git clone --depth=1 https://github.com/jumpserver/installer.git /opt/jumpserver-installer
cd /opt/jumpserver-installer
# 修改配置
cat config-example.txtDocker Compose 手动部署
# /opt/jumpserver/docker-compose.yml
version: '3'
services:
mysql:
image: mysql:8.0
container_name: jms_mysql
restart: always
environment:
MYSQL_ROOT_PASSWORD: "JumpServer@2025"
MYSQL_DATABASE: jumpserver
MYSQL_USER: jumpserver
MYSQL_PASSWORD: "JmsDB@2025"
volumes:
- mysql_data:/var/lib/mysql
networks:
- jms_net
healthcheck:
test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
interval: 10s
timeout: 5s
retries: 3
redis:
image: redis:7-alpine
container_name: jms_redis
restart: always
command: redis-server --requirepass "JmsRedis@2025"
volumes:
- redis_data:/data
networks:
- jms_net
core:
image: jumpserver/jms_core:latest
container_name: jms_core
restart: always
environment:
SECRET_KEY: "your-secret-key-min-50-chars-long-change-this-to-random-string"
BOOTSTRAP_TOKEN: "your-bootstrap-token-change-this"
DB_ENGINE: mysql
DB_HOST: mysql
DB_PORT: 3306
DB_NAME: jumpserver
DB_USER: jumpserver
DB_PASSWORD: "JmsDB@2025"
REDIS_HOST: redis
REDIS_PORT: 6379
REDIS_PASSWORD: "JmsRedis@2025"
LOG_LEVEL: INFO
volumes:
- core_data:/opt/jumpserver/data
depends_on:
mysql:
condition: service_healthy
redis:
condition: service_started
networks:
- jms_net
koko:
image: jumpserver/jms_koko:latest
container_name: jms_koko
restart: always
environment:
CORE_HOST: http://core:8080
BOOTSTRAP_TOKEN: "your-bootstrap-token-change-this"
ports:
- "2222:2222" # SSH 端口
depends_on:
- core
networks:
- jms_net
lion:
image: jumpserver/jms_lion:latest
container_name: jms_lion
restart: always
environment:
CORE_HOST: http://core:8080
BOOTSTRAP_TOKEN: "your-bootstrap-token-change-this"
depends_on:
- core
networks:
- jms_net
web:
image: jumpserver/jms_web:latest
container_name: jms_web
restart: always
ports:
- "80:80"
- "443:443"
depends_on:
- core
- koko
- lion
volumes:
- core_data:/opt/jumpserver/data
networks:
- jms_net
volumes:
mysql_data:
redis_data:
core_data:
networks:
jms_net:
driver: bridge启动和管理
# 启动所有服务
cd /opt/jumpserver
docker-compose up -d
# 查看服务状态
docker-compose ps
# 查看核心服务日志
docker-compose logs -f core
# 停止服务
docker-compose down
# 更新版本
docker-compose pull
docker-compose up -d初始化配置
# 访问 Web 界面：http://your-server-ip
# 默认管理员账号：admin
# 默认密码：admin（首次登录强制修改）
# 通过 SSH 连接堡垒机
ssh -p 2222 admin@your-server-ip安全加固配置
# 1. 修改默认端口
# 在 docker-compose.yml 中修改端口映射
ports:
- "8443:443" # HTTPS
- "2222:2222" # SSH
# 2. 配置 HTTPS（Nginx 反向代理）
# /etc/nginx/conf.d/jumpserver.conf
server {
listen 443 ssl http2;
server_name jumpserver.example.com;
ssl_certificate /etc/nginx/ssl/jumpserver.crt;
ssl_certificate_key /etc/nginx/ssl/jumpserver.key;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
location / {
proxy_pass http://127.0.0.1:80;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
# WebSocket 支持
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
}
# 3. 配置 MFA（在 Web 界面）
# 系统设置 → 安全设置 → 启用 MFA 二次认证
# 4. 配置命令过滤（在 Web 界面）
# 资产管理 → 命令过滤 → 新建规则
# 示例：禁止执行的命令
# rm -rf /
# shutdown
# reboot
# init 0
# mkfs
# dd if=
# format零信任架构原理
传统模型的困境
传统网络安全采用”边界防御”模型：通过防火墙、VPN 划分内外网，默认信任内网流量。然而这种模型存在严重缺陷：
- 一旦边界被突破，攻击者可在内网自由移动
- 内部威胁（恶意员工、被控设备）无法有效防范
- 云计算和远程办公模糊了网络边界
- VPN 接入后即拥有广泛的内网访问权限
零信任核心原则
零信任（Zero Trust）的核心理念是**“永不信任，始终验证”（Never Trust, Always Verify）**。不基于网络位置授予信任，每次访问请求都必须经过严格的身份验证、设备健康检查和权限评估。
核心原则包括：
- 显式验证：每次访问请求都要验证用户身份、设备状态、位置、行为等多维度信息
- 最小权限：使用 JIT（Just-In-Time）和 JEA（Just-Enough-Access）策略，只授予完成任务所需的最小权限
- 假设被入侵：设计系统时假设网络已被入侵，最小化爆炸半径（Blast Radius），实施微隔离和端到端加密
BeyondCorp 模型
BeyondCorp 是 Google 提出的零信任实现方案，也是业界最早的大规模零信任实践。其核心思想是：
- 废除 VPN：员工无论在公司内网还是咖啡厅，访问企业资源的方式完全相同
- 设备信任评估：每台设备都需要登记在设备清单中，通过安全状态评估才能获得访问权限
- 身份感知代理：所有请求经过 Identity-Aware Proxy（IAP），基于用户身份和设备状态做出访问决策
- 动态访问控制：访问权限不是静态的，而是根据实时风险评估动态调整
SDP（Software Defined Perimeter）架构
SDP（软件定义边界）是零信任架构的一种技术实现，由 CSA（云安全联盟）提出：
┌─────────────────┐
│ SDP 控制器 │
│ (身份认证&策略) │
└────────┬────────┘
│
┌──────────────┼──────────────┐
│ │ │
┌──────▼─────┐ ┌─────▼──────┐ ┌────▼───────┐
│ SDP 发起主机 │ │ SDP 网关 1 │ │ SDP 网关 2 │
│ (客户端) │ │ (应用代理) │ │ (应用代理) │
└────────────┘ └────────────┘ └────────────┘SDP 的工作流程：
- SDP 发起主机（客户端）向 SDP 控制器发起认证请求
- 控制器验证身份、检查设备状态、评估安全策略
- 认证通过后，控制器向客户端下发可访问的服务列表和连接信息
- 客户端与 SDP 网关建立加密隧道，访问授权的应用
- 未经认证的用户甚至无法发现服务的存在（“暗网”概念）
零信任关键组件
身份认证（Identity）
身份是零信任架构的基石。所有访问决策都基于经过验证的身份。
# 身份认证架构示例
identity_provider:
type: "OIDC" # OpenID Connect
provider: "Keycloak" # 身份提供商
features:
- multi_factor_auth: true # MFA 多因素认证
- sso: true # 单点登录
- conditional_access: true # 条件访问
- risk_based_auth: true # 基于风险的认证
mfa_methods:
- totp: true # 时间一次性密码（Google Authenticator）
- webauthn: true # FIDO2 硬件密钥
- push_notification: true # 推送通知
- sms: false # 短信验证（不推荐，易被SIM Swap）配置 Keycloak 作为身份提供商（Docker 部署）：
# 部署 Keycloak
docker run -d --name keycloak \
-p 8443:8443 \
-e KEYCLOAK_ADMIN=admin \
-e KEYCLOAK_ADMIN_PASSWORD="SecureAdmin@2025" \
-e KC_HTTPS_CERTIFICATE_FILE=/opt/keycloak/conf/cert.pem \
-e KC_HTTPS_CERTIFICATE_KEY_FILE=/opt/keycloak/conf/key.pem \
-v /opt/keycloak/certs:/opt/keycloak/conf \
quay.io/keycloak/keycloak:latest \
start设备信任（Device Trust）
仅验证用户身份不够，还需要确认设备的安全状态：
# 设备信任评估策略
device_trust_policy:
required_checks:
- os_updated: true # 操作系统是否最新
- disk_encrypted: true # 磁盘是否加密
- firewall_enabled: true # 防火墙是否开启
- antivirus_running: true # 杀毒软件是否运行
- screen_lock_enabled: true # 屏幕锁定是否启用
- jailbreak_detection: true # 越狱/Root 检测
trust_levels:
high:
- all_checks_passed: true
- managed_device: true # 企业管控设备
- access: "full"
medium:
- critical_checks_passed: true
- access: "limited" # 仅允许低敏感度应用
low:
- access: "restricted" # 仅允许只读访问
untrusted:
- access: "denied"微隔离（Micro-Segmentation）
微隔离将网络划分为最小粒度的安全域，控制工作负载之间的通信。
# Kubernetes NetworkPolicy 实现微隔离
# 默认拒绝所有入站流量
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
namespace: production
spec:
podSelector: {}
policyTypes:
- Ingress
---
# 仅允许前端访问后端 API
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-frontend-to-api
namespace: production
spec:
podSelector:
matchLabels:
app: backend-api
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
app: frontend
ports:
- protocol: TCP
port: 8080
---
# 仅允许后端 API 访问数据库
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-api-to-database
namespace: production
spec:
podSelector:
matchLabels:
app: database
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
app: backend-api
ports:
- protocol: TCP
port: 5432零信任实施路径
零信任不是一个产品，而是一种安全理念和架构转型。建议按以下路径分阶段实施：
第一阶段：身份统一与强认证
# 1. 部署统一身份平台（如 Keycloak）
# 2. 集成企业现有 AD/LDAP
# 3. 全面启用 MFA
# 4. 实施 SSO 单点登录
# 示例：配置 Nginx 集成 OAuth2 Proxy
docker run -d --name oauth2-proxy \
-p 4180:4180 \
quay.io/oauth2-proxy/oauth2-proxy:latest \
--provider=keycloak-oidc \
--client-id=my-app \
--client-secret=my-secret \
--redirect-url=https://app.example.com/oauth2/callback \
--oidc-issuer-url=https://keycloak.example.com/realms/myrealm \
--email-domain=example.com \
--cookie-secret=random-cookie-secret \
--upstream=http://backend:8080第二阶段：设备管理与网络分段
- 部署 MDM（移动设备管理）/ UEM（统一终端管理）
- 实施设备合规检查
- 建立网络微隔离策略
- 部署堡垒机管控运维通道
第三阶段：应用层零信任
- 部署 Identity-Aware Proxy（如 Pomerium、Cloudflare Access）
- 应用级访问控制，替代 VPN
- API 安全网关
- 端到端加密
# Pomerium 零信任代理部署示例
docker run -d --name pomerium \
-p 443:443 \
-v /etc/pomerium:/pomerium \
pomerium/pomerium:latest# /etc/pomerium/config.yaml
authenticate_service_url: https://auth.example.com
identity_provider: oidc
identity_provider_url: https://keycloak.example.com/realms/myrealm
identity_provider_client_id: pomerium
identity_provider_client_secret: pomerium-secret
routes:
- from: https://app.example.com
to: http://backend-app:8080
policy:
- allow:
or:
- email:
is: admin@example.com
- groups:
has: engineering
tls_downstream_client_ca_file: /pomerium/ca.crt
- from: https://grafana.example.com
to: http://grafana:3000
policy:
- allow:
and:
- groups:
has: devops
- device:
is:
is_managed: true第四阶段：持续监控与自适应
- 部署 SIEM/SOAR 平台
- 用户和实体行为分析（UEBA）
- 动态风险评估和自适应策略
- 自动化威胁响应
安全建议与最佳实践
- 从关键资产开始：不要试图一步到位。优先保护最关键的应用和数据，逐步扩展零信任覆盖范围。
- 身份是核心：投资建设统一身份平台，确保所有访问都基于经过验证的身份。MFA 不是可选项，而是必选项。
- 最小权限严格执行：实施 RBAC/ABAC，定期审查权限分配，及时回收不必要的权限。
- 全面日志审计：记录所有访问行为，包括堡垒机操作录像、API 调用日志、数据访问日志等。
- 持续验证：不仅在登录时验证，还要在会话期间持续评估风险。异常行为触发重新认证。
- 加密一切：不仅加密南北向流量，也要加密东西向（内网）流量。mTLS 是微服务间通信的最佳实践。
- 自动化运维：利用 Infrastructure as Code 和策略即代码（Policy as Code），实现安全策略的版本化和自动化部署。
- 员工培训：零信任的落地离不开全员安全意识的提升，定期开展安全培训和演练。
总结
堡垒机和零信任架构代表了网络安全从”边界防御”向”内生安全”的演进方向。堡垒机通过统一运维入口、会话审计和权限管控，解决了运维安全的痛点。JumpServer 作为成熟的开源方案，通过 Docker 可以快速部署一套功能完善的堡垒机系统。零信任架构则从根本上重新定义了信任模型，通过身份验证、设备信任、微隔离和持续评估构建了更安全的访问体系。两者并不矛盾，堡垒机是零信任架构在运维场景的具体落地组件。在推进零信任转型的过程中，应结合企业实际情况分阶段实施，以身份为核心，以数据保护为目标，持续迭代和优化安全策略。