🪴 X·Eden

博客

    零信任访问与统一运维平台建设

    2026年1月19日25分钟阅读

    项目类型: 未来方向类 | 展示对现代化 IT 架构的理解与实践 所属公司: 河南九州通医药有限公司 项目时间: 2025 年 3 月 - 2025 年 6 月（4 个月） 项目角色: 本地技术执行负责人（集团统一架构，省公司落地实施）

    一句话项目概述

    在集团 ” 智能运维治理体系 “（统一认证、监控、告警、日志、审计）战略框架下，负责省公司计算资源的本地化接入与落地实施，实现账号自动化生命周期管理、全链路零信任访问、实时运维审计，纳管率 100%，为现代化 IT 治理奠定基础。

    项目背景 (Situation)

    集团战略背景

    数字化转型的必然要求：

    • 集团推进全面的数字化转型，IT 治理从 ” 分散管理 ” 转向 ” 集中管控 ”
    • 发起 ” 智能运维治理体系 ” 治理项目：统一认证、统一监控、统一告警、统一日志、统一审计
    • 目标：打破数据孤岛，建立全集团统一的 IT 运维视图

    零信任安全理念：

    • 传统的 ” 边界安全 ” 模式已不适应混合云、远程办公的趋势
    • 集团引入零信任（Zero Trust） 安全理念：” 永不信任，持续验证 ”
    • 核心：以身份（Identity） 为中心，而非网络位置

    本地环境现状

    身份孤岛问题：

    • 本地计算资源使用孤立账号（Local Admin/Root）
    • 未与集团 HR 系统联动，人员离职后账号清理滞后
    • 存在 ” 幽灵账号 ” 隐患，构成安全风险

    监控分散问题：

    • 监控、告警、日志分散在本地，各自为政
    • 集团无法穿透监管本地资源状态
    • 缺乏全局安全态势感知

    运维效率低下：

    • 运维人员需要记住多套账号密码
    • 缺乏统一的运维入口
    • 操作审计不完整，无法满足合规要求

    项目目标 (Task)

    核心 KPI

    1. 统一认证: 实现 AD 账号与 HR 状态100% 实时同步
    2. 零信任接入: 全省计算资源接入集团统一堡垒机，实现零信任访问
    3. 全量纳管: 纳管率100%，覆盖 Windows/Linux 全栈
    4. 审计闭环: 构建 “HR 身份源→AD 认证→资源授权→实名审计 ” 的完整治理闭环

    个人职责边界

    • 负责集团统一架构在省公司的本地化落地
    • 协调本地资源接入集团统一平台
    • 解决技术对接中的兼容性和配置问题
    • 培训本地运维人员使用新的运维模式

    关键行动 (Action)

    阶段一：理解集团统一架构

    集团架构设计（先进理念学习）

    1. 以身份为中心的零信任架构

    flowchart TD
    A[HR系统（唯一身份源）] -->|自动同步| B[AD域（身份管理）]
    B -->|认证| C[JumpServer堡垒机（零信任网关）]
    C -->|SSH CA短期证书| D[计算资源（服务器/虚拟机）]
    D -->|操作日志| E[ELK日志平台（集中审计）]

    核心理念：

    • 单一身份源（Single Source of Truth）: HR 系统是唯一的人员信息来源
    • 自动化生命周期: 入职自动创建账号，离职自动禁用
    • 最小权限原则: 按需授权，用完即收回
    • 全程审计: 所有操作可追溯到具体自然人

    2. SSH CA 零信任访问机制

    传统 SSH 访问的问题：

    • 静态密码或公钥，容易泄露
    • 公钥分散在各个服务器，管理困难
    • 无法实现 ” 用完即废 ”

    SSH CA 机制（集团部署）：

    工作流程：
1. 运维人员通过JumpServer登录（AD账号认证）
2. JumpServer向SSH CA申请短期证书（有效期1小时）
3. 用证书访问目标服务器（无需密码或公钥）
4. 证书过期自动失效，实现"一次一密"

    优势：

    • 无需在目标服务器管理公钥
    • 证书短期有效，降低泄露风险
    • 全程可审计，知道谁在什么时间访问了哪台服务器

    阶段二：统一认证体系落地实施

    1. HR 系统与 AD 的自动同步

    集团方案：

    • 集团已搭建 HR→AD 的同步连接器
    • 我们负责确保本地 AD 与集团 AD 的信任关系正常

    本地执行工作：

    • 验证本地 AD 域与集团 AD 林的双向信任关系
    • 测试人员信息同步的及时性和准确性
    • 处理同步异常（如重名、编码问题）

    同步策略：

    HR状态变化 → AD账号操作
入职 → 自动创建AD账号，分配默认权限
转岗 → 自动调整部门和权限
离职 → 自动禁用账号（不删除，保留审计记录）
复职 → 自动重新启用账号

    2. Windows 主机全量加域

    目标：所有 Windows 服务器/虚拟机加入 AD 域

    执行策略：

    • 分批加域，先非核心后核心
    • 加域前备份系统状态，确保可回退
    • 加域后验证业务系统正常运行

    配置标准化：

    • 通过GPO（组策略） 统一下发安全配置
    • 强制使用域账号登录，禁用本地管理员账号
    • 配置账号锁定策略、密码策略

    3. Linux 主机对接 AD

    技术方案：

    • 使用**SSSD (System Security Services Daemon)**对接 AD
    • 或使用Realmd + Winbind方案

    配置步骤：

    # 1. 安装必要软件包
yum install sssd realmd oddjob oddjob-mkhomedir adcli samba-common
 
# 2. 加入AD域
realm join --user=admin@DOMAIN.COM
 
# 3. 配置SSSD
vi /etc/sssd/sssd.conf
# 配置认证方式、缓存策略等
 
# 4. 启用服务
systemctl enable sssd
systemctl start sssd
 
# 5. 测试
id user@domain.com  # 能查询到AD账号信息说明成功

    批量部署：

    • 使用Ansible Playbook批量配置
    • 编写配置模板，参数化处理
    • 验证脚本确保配置正确性

    阶段三：零信任堡垒机接入

    1. JumpServer 部署与配置（集团已建）

    集团已搭建统一的 JumpServer 堡垒机平台，我们负责：

    • 将本地资产信息录入 JumpServer
    • 配置资产的访问权限（哪些人可以访问哪些资产）
    • 测试通过 JumpServer 访问本地资产

    资产录入：

    资产信息包括：
- 主机名、IP地址、操作系统
- 资产归属（部门、责任人）
- 管理协议（SSH/RDP）
- 资产标签（生产/测试，核心/非核心）

    2. SSH CA 信任锚点配置

    原理：

    • 每台 Linux 服务器需要信任 SSH CA 的公钥
    • 这样 SSH CA 签发的证书才能被服务器接受

    集团方案：

    • 集团已生成 SSH CA 密钥对
    • 我们负责将 CA 公钥配置到本地所有 Linux 服务器

    批量配置（使用 Ansible）：

    # ansible playbook示例
- name: Configure SSH CA trust
  hosts: all_linux_servers
  tasks:
    - name: Copy CA public key
      copy:
        src: ssh_ca.pub
        dest: /etc/ssh/ca.pub
 
    - name: Configure sshd to trust CA
      lineinfile:
        path: /etc/ssh/sshd_config
        line: "TrustedUserCAKeys /etc/ssh/ca.pub"
 
    - name: Restart sshd
      service:
        name: sshd
        state: restarted

    3. 强制废除本地账号

    政策推行：

    • 禁止使用本地 root 账号直接登录
    • 强制通过 JumpServer + AD 账号访问
    • 违规使用本地账号纳入安全事件

    技术实现：

    # 禁用root远程登录
vi /etc/ssh/sshd_config
PermitRootLogin no
 
# 仅允许通过堡垒机IP访问
# 配置防火墙规则，只允许JumpServer IP段的SSH连接

    阶段四：统一监控、告警、日志接入

    1. 统一监控接入（Zabbix/Prometheus）

    集团平台：

    • 集团已搭建统一的 Zabbix/Prometheus 监控平台
    • 我们负责本地 Agent 的部署和配置

    本地执行：

    • 统一下发 Zabbix Agent/Node Exporter
    • 清洗监控指标口径（CPU/内存/磁盘等）
    • 配置告警模板和阈值

    标准化监控项：

    基础监控：CPU、内存、磁盘、网络流量
服务监控：进程存活、端口监听、服务响应时间
应用监控：JVM堆内存、数据库连接池、消息队列

    2. 统一告警路由（基于身份）

    智能告警路由：

    • 利用 AD 中的资产归属属性
    • 将告警精准路由至责任人
    • 拒绝 ” 告警广播 ”

    告警升级机制：

    告警处理流程：
1. 告警发送给资产责任人
2. 30分钟未处理 → 升级给责任人上级
3. 1小时未处理 → 升级给部门经理
4. 关键告警（P0级）→ 同时通知多人

    3. 统一日志采集（ELK）

    日志类型：

    • 系统日志: /var/log/messages, /var/log/secure
    • 应用日志: 应用程序的运行日志
    • 审计日志: sudo 操作、配置变更

    采集配置：

    # filebeat配置示例
filebeat.inputs:
  - type: log
    paths:
      - /var/log/secure # SSH登录日志
      - /var/log/audit/audit.log # 审计日志
    fields:
      server_name: ${HOSTNAME}
      environment: production
 
output.elasticsearch:
  hosts: ["elk-cluster.company.com:9200"]

    实名审计实现：

    日志关联链：
1. 用户user@domain.com通过JumpServer登录
2. 使用sudo执行命令
3. 日志记录：user@domain.com在2025-03-15 14:30执行了"systemctl restart nginx"
4. 可追溯到具体自然人

    阶段五：知识转移与持续运营

    1. 培训本地运维团队

    培训内容：

    • 如何通过 JumpServer 访问服务器（而不是直接 SSH）
    • 如何在统一监控平台查看告警
    • 如何在 ELK 平台检索日志
    • 常见问题排查（如 SSH CA 证书过期）

    编写操作手册：

    • 《统一运维平台使用手册》
    • 《常见问题 FAQ》
    • 《应急响应流程》

    2. 持续改进机制

    定期检查：

    • 每周检查账号同步状态
    • 每月检查资产纳管率
    • 每季度检查日志完整性

    问题反馈通道：

    • 建立与集团平台团队的沟通机制
    • 反馈本地化过程中的问题和改进建议

    量化成果 (Result)

    核心成果

    1. 身份治理闭环:

      • 实现账号自动化生命周期管理
      • 彻底根除离职人员权限残留风险
      • AD 账号与 HR 状态实时同步率100%

    2. 零信任访问落地:

      • 全省计算资源接入集团统一堡垒机
      • 实现基于 SSH CA 的零信任访问
      • 强制废除本地管理员账号

    3. 全量资源纳管:

      • 纳管率100%，覆盖 Windows/Linux 全栈
      • 打破数据孤岛，集团可实时穿透监管本地资源状态

    4. 审计合规达标:

      • 构建 “HR 身份源→AD 认证→资源授权→实名审计 ” 完整闭环
      • 所有操作可追溯到具体自然人
      • 满足集团内控审计要求

    个人价值体现

    • 现代化架构理解: 深入理解零信任、身份治理等现代化 IT 治理理念
    • 执行落地能力: 将集团统一架构成功落地到本地环境
    • 跨团队协作: 与集团平台团队、本地业务团队高效协作
    • 前瞻性视野: 为未来云原生、DevOps 转型奠定基础

    技术栈清单

    类别具体技术
    身份与认证Active Directory (多林信任), LDAP, Kerberos, SSSD/Realmd
    零信任JumpServer 堡垒机, SSH CA (Certificate Authority)
    自动化Ansible (Playbook), PowerShell, Shell Scripting
    监控Zabbix, Prometheus, Node Exporter, Grafana
    日志ELK Stack (Elasticsearch, Logstash, Kibana), Filebeat, Winlogbeat
    安全GPO (组策略), 防火墙规则, 审计策略

    面试准备：常见问题与应对

    Q1: 你在这个项目中具体做了什么？

    回答要点：

    ” 这是集团发起的 ’ 智能运维治理体系 ’ 治理项目，集团已经搭建了统一的架构平台，我作为本地技术执行负责人，负责在省公司落地实施。主要工作包括：第一，统一认证落地，包括 Windows 加域、Linux 对接 AD；第二，零信任堡垒机接入，配置 SSH CA 信任锚点；第三，统一监控、告警、日志的 Agent 部署和配置；第四，培训本地运维团队使用新的运维模式。最终实现了资源 100% 纳管，账号自动化生命周期管理。“

    Q2: 什么是零信任？为什么要做零信任？

    回答要点：

    ” 零信任的核心理念是 ’ 永不信任，持续验证 ‘。传统的边界安全模式假设内网是安全的，只要进了内网就可以访问所有资源。但现在有混合云、远程办公，边界已经模糊了。零信任以身份为中心，不管你在哪里，都需要验证身份和权限。我们通过 SSH CA 实现的零信任访问，运维人员每次登录都要通过堡垒机认证，拿到短期证书，证书过期后自动失效，实现 ’ 一次一密 ‘，降低了密码泄露的风险。“

    Q3: SSH CA 和传统的公钥认证有什么区别？

    回答要点：

    ” 传统公钥认证的问题是：第一，公钥分散在各个服务器的 authorized_keys 文件里，管理困难；第二，公钥是长期有效的，一旦泄露风险很大；第三，人员离职后需要逐台服务器删除公钥，容易遗漏。SSH CA 机制解决了这些问题：第一，只需要在服务器上配置一次 CA 公钥，后续不用管理；第二，证书是短期有效的（比如 1 小时），大大降低了泄露风险；第三，人员离职后禁用 AD 账号即可，无需逐台删除。“

    Q4: 统一认证有什么好处？

    回答要点：

    ” 统一认证的核心价值是 ’ 一个账号走天下 ‘。对运维人员来说，不用记住多套账号密码，体验更好；对管理者来说，可以集中管理权限，人员离职后一次禁用即可，不会有遗漏；对审计来说，所有操作都能追溯到具体的自然人，满足合规要求。另外，统一认证也是零信任、自动化运维的基础，是现代化 IT 治理的必然选择。“

    Q5: 这个项目对你未来的职业发展有什么帮助？

    回答要点：

    ” 这个项目让我接触到了现代化 IT 治理的理念和实践。零信任、身份治理、自动化运维、全链路审计，这些都是未来的趋势。我深刻理解了 ’ 以身份为中心 ’ 的安全架构，这对我学习云原生、DevOps、SRE 都有很大帮助。比如 Kubernetes 的 RBAC 权限管理、Service Mesh 的身份认证，底层逻辑都是相通的。这个项目为我未来的职业发展打开了一扇窗。“

    可能的追问点与应对策略

    追问 1: ” 如果 AD 域控挂了怎么办？”

    准备答案：

    • 高可用设计：AD 域控是主备模式，一台挂了另一台顶上
    • 本地缓存：SSSD 有本地缓存机制，短期内 AD 不可用也能登录
    • 应急账号：保留一个本地 emergency 账号，仅在极端情况下使用
    • 快速恢复：定期备份 AD，确保能快速恢复

    追问 2: “SSH CA 的私钥如何保护？”

    准备答案：

    • CA 私钥由集团安全团队管理，存放在 HSM（硬件安全模块）中
    • 只有授权的管理员才能操作 CA
    • CA 签发证书的过程有完整的审计日志
    • 定期轮换 CA 密钥，降低长期使用的风险

    追问 3: ” 如果业务系统不支持 AD 认证怎么办？”

    准备答案：

    • 优先推动改造：与应用开发团队沟通，优先支持 AD 认证
    • 应用层代理：如果应用不支持，可以在前面加一层认证代理
    • 账号映射：建立 AD 账号与应用账号的映射关系
    • 过渡方案：老旧系统可能需要保留独立账号，但要严格管理

    追问 4: ” 日志量很大，ELK 存储压力怎么办？”

    准备答案：

    • 热温冷分层：热数据（最近 7 天）高性能存储，温数据（7-30 天）普通存储，冷数据（30 天以上）归档
    • 日志过滤：不是所有日志都需要采集，过滤掉无价值的日志
    • 压缩和索引优化：使用压缩算法，优化索引策略
    • 这是集团层面的问题，我们主要负责本地采集和上报

    项目亮点提炼（电梯演讲版 -30 秒）

    ” 在集团 ’ 智能运维治理体系 ’ 治理项目中，我负责省公司的本地化落地。通过 Windows 加域、Linux 对接 AD，实现了统一认证；通过 JumpServer 和 SSH CA，实现了零信任访问；通过统一监控和日志采集，打破了数据孤岛。最终资源纳管率 100%，构建了 ‘HR 身份源→AD 认证→资源授权→实名审计 ’ 的完整闭环。这个项目让我深入理解了现代化 IT 治理理念，为未来的云原生转型奠定了基础。“

    适用场景

    推荐在以下情况使用此项目：

    • ✅ 应聘安全、运维、SRE、DevOps等岗位
    • ✅ 岗位 JD 提到零信任、身份治理、云原生安全
    • ✅ 面试官关注现代化 IT 架构和前瞻性思维
    • ✅ 大型企业/集团公司（有类似的治理需求）
    • ✅ 想展示对未来趋势的理解

    不推荐在以下情况使用：

    • ❌ 小型创业公司（规模太小，没有这种需求）
    • ❌ 纯开发岗位（与开发关系不大）
    • ❌ 传统运维岗位（可能觉得太超前）

    未来方向的衔接

    这个项目是通往现代化 IT 架构的重要一步：

    从传统运维到云原生的演进

    当前阶段：统一身份 + 零信任堡垒机
    ↓
下一步：容器化 + Kubernetes
    ↓ (身份认证机制迁移)
Service Mesh + mTLS（双向TLS认证）
    ↓
云原生零信任（Istio + SPIFFE/SPIRE）

    与云原生技术的关联

    身份治理：

    • 当前：AD 域账号管理
    • 云原生：Kubernetes RBAC + Service Account

    零信任访问：

    • 当前：SSH CA + JumpServer
    • 云原生：Service Mesh + mTLS + 服务身份（SPIFFE）

    全链路审计：

    • 当前：ELK 日志采集
    • 云原生：分布式追踪（Jaeger/Zipkin）+ 审计日志

    面试时可以这样说

    ” 这个项目让我意识到，无论是虚拟机还是容器，无论是传统数据中心还是云原生，底层的治理逻辑是相通的：都需要身份管理、权限控制、全链路审计。我现在正在学习 Kubernetes 和 Service Mesh，发现很多概念是相通的。比如 Kubernetes 的 RBAC 本质上也是基于身份的权限控制，Service Mesh 的 mTLS 本质上也是零信任。我的这个项目经验可以很好地迁移到云原生领域。“

    现代化 IT 治理的理解

    通过这个项目，展示了对现代化 IT 治理的深刻理解：

    1. 以身份为中心:

    • 不再是 ” 在哪里 “（网络位置），而是 ” 是谁 “（身份）
    • 身份是安全的基石

    2. 自动化驱动:

    • 账号生命周期自动化
    • 权限变更自动化
    • 减少人工操作，降低错误率

    3. 全程可观测:

    • 统一监控、告警、日志
    • 全链路追踪
    • 数据驱动决策

    4. 持续验证:

    • 不是 ” 一次登录，永久信任 ”
    • 而是 ” 持续验证，最小权限 ”
    • SSH CA 短期证书就是这个理念的体现

    面试时可以说：

    ” 这个项目不仅是技术实施，更是理念转变。它让我理解了现代化 IT 治理的核心：身份、自动化、可观测、持续验证。这些理念不仅适用于当前的基础设施，也适用于未来的云原生、微服务架构。我相信这种思维方式会伴随我整个职业生涯。”

    关系图谱