一、堡垒机是所有运维入口的单点风险先讲一个容易被忽略的事实堡垒机把一个组织所有被管设备的信任收敛到了一个登录框上。一家中型企业服务器几百台、网络设备几十台、数据库十几套按理说攻击面应该很大。但现实中运维人员并不直接登录这些设备而是先登录堡垒机再由堡垒机代填凭据、跳转访问。从攻击者的视角看这反而是个好消息——他不需要破解几百台主机只需要拿下一台堡垒机上的一个账号就等于拿到了几百台主机的钥匙。很多团队在百度搜索堡垒机双因素方案时真正想确认的其实不是要不要做而是做了之后会不会把运维堵死、出问题怎么回退。这个担心是合理的本文的重点也就放在工程对接和逃生设计上。1.1 单点口令的脆弱性数据说话行业公开的泄露事件分析里有一个反复被验证的结论约 81% 的数据泄露与弱口令或凭证盗用相关。而双因素认证的引入可以把账户被盗的风险下降约 99.2%。这两个数字放在一起看结论很清楚——口令从来不是够不够复杂的问题而是单一因子是否足够的问题。口令失效的场景堡垒机上一个都不会少撞库运维人员常年在各类技术站点注册口令复用率高爆破堡垒机如果对公网或办公网开放弱口令爆破是低成本攻击钓鱼仿冒的堡垒机登录页一次就能拿到真实口令终端失陷运维本机的浏览器密码、内存里的凭据被窃取内部共享一个运维账号多人知道口令口头传播。1.2 单因素堡垒机被拿下的完整路径把攻击链画出来你会发现每一步都不需要高深技术[第一步 信息收集] 公开渠道获取运维人员姓名/工号/邮箱 从历史泄露库匹配口令习惯 扫描定位堡垒机登录入口公网或办公网可达 │ ▼ [第二步 获取口令] 撞库复用 / 弱口令爆破 / 仿冒登录页钓鱼 / 运维终端木马记录键盘 / 内部人员直接持有 │ ▼ [第三步 登录堡垒机] ←── 只有口令无第二因子此处无拦截 成功进入运维门户看到全部被管资产列表 │ ▼ [第四步 横向移动] 堡垒机内保存的免密登录私钥 密码代填功能暴露的主机口令 会话录制文件里可能残留的明文输入 │ ▼ [第五步 控制被管设备] 服务器 / 网络设备 / 数据库 全线可达 │ ▼ [第六步 持久化与清理] 植入后门、新增账号、篡改审计、擦除操作日志这条链上第三步是唯一的、也是成本最低的阻断点。前两步你拦不住口令总会以各种方式泄露后三步一旦发生损失已经不可逆。所以在堡垒机上叠加双因素不是锦上添花而是把唯一的闸门焊死。1.3 一个常见误区堡垒机已经录屏审计了还要双因素吗要。审计解决的是事后能查清谁干的双因素解决的是事前不让不该进的人进来。这是两个完全不同的控制点。而且从合规角度看等保 2.0 三级对身份鉴别的要求是采用两种或两种以上组合的鉴别技术堡垒机作为运维入口恰恰是测评时必查的高风险点。审计日志再全也补不上身份鉴别这一项的分数。二、双因素接入堡垒机的三种对接方式不少工程师在百度搜索堡垒机双因素对接时真正想确认的是对接方式到底有几种、各自要改多少东西。这三种方式基本覆盖了市面上所有堡垒机产品的可行路径。先给总览。三种方式的本质区别是第二因子在认证链路的哪个位置被校验。对接方式第二因子校验位置改造量时序适用条件主要风险RADIUS 协议对接堡垒机把认证请求转发给统一认证平台由平台完成口令加动态口令校验小堡垒机侧配置 RADIUS 即可两段式挑战应答堡垒机支持标准 RADIUS 客户端绝大多数支持UDP 不可靠、共享密钥管理LDAP 或 API 联动堡垒机保留口令校验第二因子通过目录查询或接口调用单独校验中可能需要堡垒机厂商配合串行两次校验堡垒机支持外部认证接口或可二次开发逻辑绕过口令对了就放行风险代理插件式二次校验在堡垒机与目标主机之间串联一层会话建立后追加挑战大需改动网络路径或部署代理会话内二次校验堡垒机完全封闭、无法配置外部认证时的兜底部署复杂、故障域扩大选型时有个很实用的判断顺序先试 RADIUS不行再谈 APIAPI 也不行才上代理插件。原因是 RADIUS 是堡垒机行业事实标准几乎所有产品都支持配置成本低、回滚容易而代理插件是侵入式方案一旦出问题影响的是整条运维链路。三、方式一RADIUS 协议对接3.1 协议基础先把这几个字段搞清楚RADIUS 是 AAA认证、授权、计费协议认证默认用 UDP 1812计费用 UDP 1813。对接堡垒机时堡垒机是NAS网络接入服务器统一认证平台是RADIUS 服务器。必知字段User-Name登录用户名User-Password口令用共享密钥加请求认证字做异或混淆PAP 方式NAS-IP-Address/NAS-Identifier客户端标识服务器端靠它识别是哪台堡垒机State挑战应答的会话关联标识两段式认证全靠它Reply-Message回显给用户的提示文本比如请输入动态口令Message-Authenticator防篡改校验涉及挑战应答时强烈建议开启。3.2 两种提交模式选错了体验会很差模式 A拼接式一次性提交用户在堡垒机密码框里输入口令动态口令如MyPass123456RADIUS 服务器端按规则拆分分别校验。优点一次交互时序简单兼容性最好缺点依赖堡垒机不做长度截断、不转义特殊字符拆分规则复杂时容易误判用户体验要记忆拼接顺序。模式 B挑战应答式两段式先提交口令服务器返回Access-Challenge堡垒机弹出第二个输入框用户输入动态口令后再次提交。优点体验清晰符合输完密码再输验证码的直觉支持推送确认、扫码等交互型因子缺点要求堡垒机支持挑战应答流程对超时和重传敏感。3.3 两段式完整时序运维人员 堡垒机(NAS) 统一认证平台(RADIUS) 令牌/OTP服务 │ │ │ │ │ 1. 输入用户名口令 │ │ │ │─────────────────────│ │ │ │ │ 2. Access-Request │ │ │ │ User-Name / User-Password│ │ │ │ NAS-IP-Address / State(空) │ │ │───────────────────────────│ │ │ │ │ 3. 校验口令 查用户绑定│ │ │ │───────────────────────│ │ │ │───────────────────────│ │ │ │ 用户已绑定TOTP │ │ │ 4. Access-Challenge │ │ │ │ Reply-Message请输入动态口令 │ │ │ State会话标识 │ │ │ │───────────────────────────│ │ │ 5. 弹出第二个输入框 │ │ │ │─────────────────────│ │ │ │ 6. 输入6位动态口令 │ │ │ │─────────────────────│ 7. Access-Request(第二次) │ │ │ │ User-PasswordOTP │ │ │ │ State同一会话标识 │ │ │ │───────────────────────────│ │ │ │ │ 8. 校验 State 有效性 │ │ │ │ 校验 OTP 时间窗 │ │ │ 9. Access-Accept │ │ │ │ 下发授权属性(用户组/时限) │ │ │ │───────────────────────────│ │ │ 10. 登录成功进入运维门户 │ │ │─────────────────────│ │ │ │ │ 11. Accounting-Request(Start) │ │ │───────────────────────────│ │关键在第 8 步服务器必须通过State把两次请求关联成同一次认证会话并限制State的有效期和单次使用。否则攻击者可以直接构造第二次请求跳过口令校验只猜 OTP安全强度反而退化成单因子。3.4 配置示例堡垒机侧以通用配置项表述具体字段名随产品略有差异认证方式 RADIUS 主认证服务器地址 统一认证平台地址 认证端口 1812 计费端口 1813 共享密钥 32位以上随机字符串 NAS 标识 bastion-prod-01 认证协议 PAP挑战应答必需 超时时间 5 秒 重传次数 2 挑战超时 60 秒 备用认证服务器 备用平台地址 故障转移策略 主不可用时切备用全部不可用时走逃生策略统一认证平台侧概念化配置radius client bastion-prod-01 { nas-ip-address 堡垒机地址 nas-identifier bastion-prod-01 shared-secret 与堡垒机侧完全一致 require-message-authenticator yes auth-port 1812 acct-port 1813 } policy bastion-mfa { match nas-identifier bastion-prod-01 primary-auth password # 第一因子静态口令 secondary-auth totp # 第二因子动态口令 challenge-mode two-step # 两段式挑战应答 state-ttl 60s # 挑战会话有效期 state-once yes # State 单次有效 otp-window 1 # 时间窗 ±1 个步长(30秒) max-attempt 5 # 连续失败次数 lockout-duration 900s # 锁定时长 source-ip-policy allow-list # 源地址策略 fallback emergency-code # 逃生策略 }这段配置里每一行都有工程含义下一节逐个展开。四、方式二LDAP 或 API 联动4.1 适用条件当堡垒机不支持标准 RADIUS或者厂商提供的 RADIUS 客户端实现有缺陷比如不支持挑战应答、不支持State就要考虑这条路。典型场景堡垒机只支持 LDAP 作为外部认证源堡垒机提供认证后钩子或二次认证接口可调用外部 HTTP 接口堡垒机是自建或开源的可以做二次开发。4.2 时序运维人员 堡垒机 目录服务 统一认证平台 │ │ │ │ │ 用户名口令 │ │ │ │─────────────│ │ │ │ │ 1. LDAP Bind │ │ │ │─────────────────│ │ │ │ 2. Bind 成功 │ │ │ │─────────────────│ │ │ │ 3. 调用二次认证接口(带用户名/来源地址)│ │ │──────────────────────────────────────│ │ │ 4. 下发挑战(推送/扫码/OTP输入框) │ │ │──────────────────────────────────────│ │ 5. 完成第二因子确认 │ │─────────────────────────────────────────────────────│ │ │ 6. 校验结果通过 │ │ │──────────────────────────────────────│ │ 7. 登录成功 │ │ │ │─────────────│ │ │4.3 最大的风险逻辑绕过这种方式最容易出现的问题是堡垒机在收到接口调用异常时默认放行。接口超时、网络抖动、平台重启如果堡垒机的兜底逻辑写成接口失败则放行攻击者只要打挂认证接口就能绕过第二因子。因此必须在设计上明确两条接口调用失败时默认拒绝或只允许走受控的逃生通道不允许静默放行校验结果必须由平台签名堡垒机侧验签避免本地伪造响应。以安当ASP为例其对外提供标准认证接口与目录服务能力的组合可以在堡垒机做 LDAP 绑定之后以接口方式追加第二因子同时支持对结果做签名保护规避上面这个绕过风险。五、方式三代理插件式二次校验5.1 什么时候才需要它只有在堡垒机完全封闭、既不支持 RADIUS 也无法二次开发时才考虑这一方案。它的思路是不改堡垒机改链路。两种落地形态串联代理在堡垒机与目标主机之间插入一个校验网关运维会话建立后网关向用户发起二次挑战校验通过才放行协议流量终端侧插件在运维人员本机部署插件与堡垒机会话建立时联动弹出二次校验窗口。5.2 时序串联代理运维人员 → 堡垒机 → [校验网关] → 目标主机 │ │ │ 会话建立后拦截 │ │ │ 推送挑战到用户手机/令牌 │──────────┘ │ 用户完成确认 │ └──→ 网关放行协议流量 → 目标主机5.3 代价故障域扩大网关挂了整条运维链路全断必须有旁路部署复杂要改网络路径、要考虑主备、要考虑会话保持加密协议穿透难遇到端到端加密的协议代理层可能看不到明文只能做连接级放行而非命令级控制。结论这是兜底方案不是首选。六、关键配置项详解这一节是本文最实用的部分逐项讲清楚配置背后的工程考虑。很多项目在百度搜索RADIUS配置时能查到字段含义但很少有人讲这些字段在堡垒机场景下该怎么取值而恰恰是取值决定了上线后是平稳还是事故。6.1 共享密钥共享密钥是 RADIUS 通信的唯一信任基础用于混淆口令字段和计算Message-Authenticator。要求长度不少于 16 位建议 32 位以上随机字符串每台 NAS 使用独立密钥不要全网共用一个定期轮换如半年一次轮换时采用新旧并存过渡避免一次性切换导致全量认证失败禁止在配置文件中明文硬编码后提交到代码仓库应使用密钥管理组件托管两侧密钥必须完全一致包括大小写和首尾空格——这是最高发的配置错误。6.2 NAS 标识NAS-IP-Address和NAS-Identifier用于服务器识别客户端身份也是做策略匹配的依据。常见坑堡垒机有多网卡发出的源地址和配置的NAS-IP-Address不一致导致服务器不认识这个客户端直接丢弃请求主备堡垒机用了相同标识导致策略混用、审计分不清来源服务器侧策略按标识匹配新增堡垒机忘了加策略认证全部被拒。建议每台堡垒机一个唯一标识命名带环境信息如bastion-prod-01、bastion-dr-01服务器端按标识绑定策略与源地址白名单。6.3 Challenge 超时挑战超时指的是服务器发出Access-Challenge后等待用户第二次提交的最长时间。取值要平衡两端太短10 秒以内用户还没掏出手机就被判失败投诉激增太长5 分钟以上攻击者有充足时间做中间人转发把挑战实时转给用户骗取动态口令。推荐取值30 到 60 秒。同时配合挑战会话单次有效和同一用户并发挑战数限制把重放窗口压到最小。另外要注意堡垒机侧的State保持能力。有些堡垒机在弹出第二个输入框时不会回传State导致服务器无法关联两次请求——这种情况下只能退回拼接式提交。6.4 失败锁定失败锁定策略要分层设计不能只看总数层级策略建议值单用户连续失败 N 次锁定 M 分钟N5M15 分钟单源地址单位时间失败次数超限封禁5 分钟内 30 次全局失败率突增触发告警失败率 30% 持续 5 分钟挑战会话单个 State 校验失败次数3 次即作废特别提醒锁定策略本身会成为攻击面。攻击者拿到用户名列表后可以批量触发锁定把所有运维账号锁死制造运维中断。所以要做可信源地址豁免和管理员带外解锁流程并且锁定事件必须进告警。6.5 源地址策略RADIUS 是无连接协议服务器端必须靠源地址做第一道过滤只允许堡垒机的出口地址访问 1812 端口其余一律丢弃如果堡垒机经过地址转换要确认服务器看到的是哪个地址白名单填转换后的地址跨机房、跨专线的场景源地址可能会变建议同时绑定NAS-Identifier做双重校验传输层用 IPSec 或专线保护避免共享密钥和口令字段在传输路径上被嗅探。七、回退与逃生通道设计这是很多团队最容易忽略、但上线后一定会用到的一环。7.1 原则逃生通道必须更强而不是更弱错误的做法双因素服务挂了就临时把认证降级为纯口令。这等于给攻击者留了一个打挂认证服务即可单因子登录的后门。正确的做法逃生通道的验证强度不低于原路径只是验证方式不同。7.2 四种可用的逃生机制机制一应急一次性口令Break-glass Code为每名运维人员预先生成一组离线应急码单码单次使用打印封存。认证平台整体不可用时堡垒机本地校验应急码放行。要点应急码必须离线可验、必须单次失效、必须记录使用事件并强告警。机制二带外审批放行运维人员提交申请由两名管理员通过带外渠道电话、专用审批终端确认后由平台生成一个有时限的放行令牌。要点双人确认、时限控制在 30 分钟到 2 小时、全程留痕。机制三本地应急账号加物理管控在堡垒机本地保留一个应急账号口令拆分成两段由两人分别保管存于保险柜。使用时需两人同时在场。要点口令定期更换、使用后立即改密、每次使用必须复盘。机制四RADIUS 备机自动切换这不算逃生通道而应作为常规高可用设计主备两台认证平台堡垒机配置主备地址主不可用时自动切换。只有主备全挂才走上面三种机制。7.3 逃生通道的治理要求逃生通道的使用必须有独立审计且告警直达安全负责人不能只进日志应急码的生成、分发、封存、回收要有台账每季度至少演练一次逃生流程验证可用性和时效性逃生通道的触发条件要写成明确的技术判据如连续 3 次认证请求全部超时且主备均不可达不能靠管理员拍脑袋。八、灰度切量与回滚方案8.1 灰度维度双因素上线不要一次性全量按下面三个维度交叉推进按人群先选 3 到 5 名配合度高的运维骨干试用再扩到整个运维组最后覆盖外包和临时人员按资产先对非生产环境堡垒机生效再切生产只读账号最后切生产特权账号按时间先在工作日白天开启夜间和节假日保留宽松策略跑顺后取消时间例外。8.2 推荐切量节奏阶段覆盖范围观察周期通过标准试点3 到 5 名骨干3 个工作日无阻断性体验问题小批量运维组 20%1 周认证成功率 99.5%半量运维组 50%1 周工单量环比持平全量全部运维人员2 周无超时告警、无集中投诉收紧取消时间例外—应急演练通过8.3 回滚设计回滚能力要在上线前就准备好而不是出事后现想开关化认证策略集中配置支持按用户组、按堡垒机一键切回单因子切换生效时间控制在 1 分钟内配置版本化每次策略变更留版本号可一键回退到上一版本保留并行期灰度期间堡垒机同时保留本地口令认证能力双因素失败时可临时走本地认证仅限灰度期全量后必须关闭回滚判据明确例如认证成功率低于 98% 持续 10 分钟或累计阻断工单超过 5 单即触发自动回滚不需要层层审批。最容易踩的坑是全量后仍长期保留并行口令通道导致双因素形同虚设。正确的做法是设定明确的关闭时间点并纳入上线验收项。九、常见故障排查清单9.1 认证超时现象用户输入凭据后转圈十几秒最后提示认证失败或超时。排查顺序在堡垒机侧用radtest类工具直连认证平台确认协议层是否通检查防火墙是否放行 UDP 1812注意 UDP 是无连接的telnet测端口无效检查认证平台负载CPU 或线程池打满会显著拉长响应检查后端账号源目录服务、数据库的查询耗时慢查询是隐藏元凶确认超时时间与重传次数的乘积超时 5 秒重传 2 次最坏情况要等 15 秒才判定失败堡垒机侧若自身超时设得更短就会出现平台还没回堡垒机已经放弃。9.2 时钟漂移现象动态口令总是不对但手机令牌显示的码看起来没问题。根因基于时间的动态口令依赖两端时钟一致。服务器与令牌偏差超过一个时间步长通常 30 秒就会校验失败。处理认证平台必须与权威时间源同步并监控偏移量超过 5 秒告警平台侧开启时间窗容错前后各 1 个步长但不要开太大窗越大被重放的风险越高支持令牌漂移自动校准用户连续两次用相邻时间窗的码成功认证平台自动记录偏移量移动端令牌要提示用户检查手机系统时间是否被手动修改过。9.3 共享密钥不一致现象认证平台侧日志显示报文校验失败或直接无任何日志堡垒机侧提示认证服务器无响应。关键点共享密钥不一致时RADIUS 服务器会静默丢弃报文不会返回Access-Reject。这个行为特征可以作为快速判据——如果服务器侧完全无日志八成是密钥或客户端标识不对。排查逐字符比对两侧密钥特别注意首尾空格、换行符、大小写检查特殊字符是否被配置文件转义如#、、\检查是否有一侧做了密钥自动补齐或截断确认修改密钥后两侧服务都重启或重载了配置。9.4 UDP 丢包现象认证时好时坏成功率在 90% 到 99% 之间波动日志里有重传记录。排查与优化用长时间抓包统计丢包率重点看跨越网段和经过地址转换的路径检查中间防火墙的 UDP 会话表是否被打满或开启了过于激进的 UDP 限速检查认证平台网卡是否有丢包统计、缓冲区是否溢出增大重传次数要谨慎重传会放大丢包时的拥塞更好的做法是缩短单次超时3 秒加一次重传对稳定性要求极高的场景考虑改用 TCP 承载的 RADIUS 或切换到 TCP 类认证协议。9.5 扩展清单现象优先排查全部用户认证失败共享密钥、NAS 标识、源地址白名单部分用户认证失败用户未绑定令牌、账号被锁定、用户名大小写第一次通过第二次失败State 未回传、挑战超时过短、OTP 时间窗认证通过但无权限授权属性未下发、用户组映射错误计费记录缺失1813 端口未放行、计费开关未开启偶发失败无规律UDP 丢包、平台负载、后端目录慢查询十、选型与实施建议最后给一份可执行的落地建议按顺序做先盘资产把所有堡垒机列出来标注型号、版本、支持的外部认证方式这一步决定后续走哪条对接路线确认账号源堡垒机上的运维账号是否与他人事系统、目录服务一致账号不一致会导致令牌绑定对不上人这是最常见的返工点选对接方式优先 RADIUS其次 LDAP 或接口联动最后才考虑代理插件设计逃生在功能测试之前就把逃生通道和灰度方案定下来并写进上线方案先测非生产在测试环境堡垒机上完整跑一遍正常、失败、超时、平台宕机四类场景灰度切量按第八节的节奏推进不要跳步收紧并行通道全量后关闭本地口令旁路并验收纳入审计所有认证事件、逃生事件、策略变更事件统一上报日志平台定期演练每季度演练一次平台宕机与令牌丢失场景验证回退链路覆盖外包账号外包和临时运维账号往往是最薄弱环节不能只覆盖正式员工。以安当ASP为例其 RADIUS 模块与多因素认证模块是同一平台内的能力堡垒机侧只需完成标准的 RADIUS 客户端配置第二因子的策略、锁定、逃生、审计都在平台侧统一配置不需要为堡垒机单独维护一套认证逻辑这也是一体化方案在多入口场景下运维成本更低的原因。十一、合规与上线检查清单上线前逐项打勾堡垒机清单与版本台账已建立外部认证能力已确认运维账号与人事、目录服务完成对齐无孤儿账号每名运维人员已完成第二因子绑定绑定率 100%共享密钥长度达标、一机一密、非明文存储NAS 标识唯一服务器端按标识绑定策略与源地址白名单挑战超时、失败锁定、源地址策略已配置并验证挑战会话单次有效、并发挑战数受限接口或协议调用失败时默认拒绝无静默放行逻辑应急一次性口令已生成、封存、登记台账带外审批流程已定义双人确认已落实主备认证平台已部署主备切换已实测灰度切量计划与回滚判据已书面化全量后关闭本地口令旁路的时点已明确认证日志、逃生事件、策略变更已接入统一日志平台时钟同步监控已上线偏移超阈值告警等保 2.0 要求的双因素证明材料已归档十二、FAQQ1堡垒机自带动态口令功能还需要接统一认证平台吗自带功能能解决单点问题但会带来新的孤岛令牌在堡垒机侧单独管理和邮箱、远程接入、业务系统的第二因子各管各的运维人员要绑好几次离职回收也要逐个系统操作。接统一平台的核心价值是一份身份、一套令牌、一处回收同时认证事件能进统一审计。Q2RADIUS 用 UDP 不可靠生产环境能接受吗可以但要做好设计。UDP 的问题主要是丢包和不可达感知慢。通过缩短单次超时、限制重传次数、部署主备平台、监控丢包率生产环境稳定运行是常见做法。若链路质量确实差再考虑 TCP 承载方案。Q3挑战应答式和拼接式怎么选优先挑战应答式体验清晰且安全性更好能防口令与动态口令被一次性截获后重放。只有当堡垒机明确不支持挑战应答时才退回拼接式并在服务器端把拆分规则写严格避免误判。Q4认证平台整体宕机运维完全进不去了吗不应该。按第七节设计逃生通道主备切换是第一道应急一次性口令、带外审批、本地应急账号是第二道。关键是提前生成、提前演练而不是等出事再临时开放口令登录。Q5动态口令时间窗开多大合适默认前后各 1 个步长30 秒即可。开到 2 个以上会显著增加重放窗口收益却很小——真正时钟漂移严重的终端应该修时钟而不是靠放宽窗口掩盖。Q6外包人员流动快令牌怎么管把令牌绑定纳入入场和离场流程入场时凭工单绑定离场时凭工单解绑回收。硬件令牌要物理回收手机令牌要在平台侧远程注销种子。同时给外包账号设置更短的授权有效期到期自动失效。Q7双因素上线后运维效率会下降多少正常情况每人每天多花几秒钟。真正影响效率的是异常场景令牌没电、手机没信号、账号被误锁。这些要靠充分的灰度、清晰的报错提示和快速的解锁流程来解决而不是靠降低安全强度。方案参考安当ASP是上海安当技术推出的企业级统一身份认证平台在堡垒机双因素场景中可作为对接侧的工程参考RADIUS 认证模块作为标准 RADIUS 服务器端支持挑战应答两段式流程、State会话关联、按 NAS 标识匹配策略可与主流堡垒机产品对接多因素认证能力支持动态口令、手机令牌、硬件令牌、推送确认、国密 USBKey、指纹与掌纹等多种第二因子按堡垒机场景灵活组合协议栈支持 SAML 2.0、OAuth 2.0、OIDC、LDAP、RADIUS、FIDO2、WebAuthn堡垒机之外的其他入口也能纳入同一套认证体系国密与合规原生支持国密 SM2、SM3 算法满足等保 2.0 三级关于双因素身份鉴别的要求信创适配已完成麒麟、统信、鲲鹏、龙芯等国产操作系统与 CPU 的适配认证运维配套提供共享账号治理、操作系统登录加固、密码代填等模块可与堡垒机场景形成入口加固加凭据管控的闭环。如需进一步评估建议按本文第二节的对接方式对比表先确认堡垒机的外部认证能力再确定技术路线并启动试点。
