主机安全

• AppArmor 的 MAC 机制与 profile 结构
• profile 的编写（rule 语法、attach 到可执行文件）
• 调试要点（enforce/audit/complain 模式、日志）

AppArmor 是一种基于 Linux 的强制访问控制（MAC）机制，通过 profile 为进程定义可访问的文件、网络、能力（capability）等资源规则，从而限制进程行为、缩小攻击面。profile 通过 profile <name> <path> 关联到特定可执行文件或其路径，进程启动时内核按 profile 的规则执行访问控制。编写 profile 时，常用 rule 声明文件访问（如 file、/path/** rw）、网络（network）、capability（capability net_raw）等；初次编写可用 aa-genprof 根据进程行为生成，或 aa-logprof 从日志生成规则。调试要点：使用 aa-status 查看加载的 profile 与 enforce/complain 状态，aa-enforce 与 aa-complain 切换强制执行与告警模式（complain 模式下只记录不拒绝，便于调试），通过 /var/log/kern.log 或 auditd 日志查看被拒绝的访问，据此修正规则后再切回 enforce。

AppArmor 的价值在于"针对进程的细粒度访问控制"，核心是 profile 的编写与调试。调试的关键是"complain 模式先行"——先用告警模式观察真实行为，再收紧为 enforce，避免直接 enforce 导致进程功能被破坏。这比功能复杂的 SELinux 更易上手，是 Linux 主机安全基线常用手段。

• IMA 的度量与验签机制
• 文件完整性校验（appraise）与度量（measure）
• 部署代价与局限（TPM、启动链路、性能）

Linux IMA（Integrity Measurement Architecture）是 Linux 内核的完整性度量架构，通过"度量（measure）"与"校验（appraise）"实现对文件完整性的保证。度量（IMA measure）在文件被访问时计算其哈希并记录到度量列表（IMA policy），可用于远程证明（结合 TPM 的 PCR 扩展）；校验（IMA appraise）在文件被使用前用内核中的签名或哈希校验其完整性，文件被篡改则拒绝执行/访问。可执行文件可通过 IMA 对 ELF 文件进行签名（IMA signatures）并在执行时验证，确保可执行文件未被篡改。部署代价主要体现在：需要 TPM 支持以形成可信启动链（配合 Secure Boot），需要配置 IMA policy（extend 到 PCR 的度量）、为需校验的文件签名、以及一定性能开销（hash 计算）。局限包括：只保护"已签名的文件"的完整性，无法防御恶意或合法但有害的程序；IMA 度量与校验依赖 TPM 与启动链路，配置复杂；对未纳入 policy 的文件不生效；且 IMA 本身不能阻止"恶意代码"运行，只能保证"代码未被篡改"。

IMA 的核心价值是"完整性保证"，即"文件是不是被改过"，而非"程序是否安全"。它服务于可信计算（Measured Boot、远程证明），但与"恶意行为检测"是不同维度。部署代价集中在对 TPM 依赖、签名管理与 policy 配置，局限在于范围有限（只保护可执行与配置文件）且无法防御恶意代码本身。

• setuid/setgid 提权路径与风险
• SafeSetID 的机制（限制 setuid 目标用户）
• 与 capabilities 机制的配合

传统 setuid/setgid 允许进程切换 UID/GID，是提权路径之一，若被滥用（如 setuid 到 root）会带来提权风险。SafeSetID 是内核提供的一项安全机制，通过 config 或 sysctl 限定进程可以 setuid/setgid 到哪些目标 UID/GID，从而限制提权路径：只有允许的目标用户才能被切换，非法目标被拒绝。它与 capabilities 机制配合：capabilities 定义了进程具备哪些特权操作（如 CAP_SETUID 允许设置 UID），而 SafeSetID 在 capabilities 之上进一步限制"允许设置到哪个 UID"——即使进程持有 CAP_SETUID，也只能切换到 SafeSetID 允许的目标 UID，从而细化提权控制。实践中常配合最小权限原则，减少进程持有的 capabilities，并限制 root 转换路径。

SafeSetID 是对 setuid/setgid 提权的"白名单"限制：capabilities 决定"能不能设 UID"，SafeSetID 决定"能设到谁"。二者配合能有效缩小提权面——即使进程被授予了设置 UID 的能力，也无法切换到未授权的目标用户。这是容器与主机安全中控制提权风险的重要机制。

• kernel lockdown 的机制与模式（integrity/confidentiality）
• 阻止模块加载与内核访问
• 安全价值与运维影响（加载模块受限、调试受限）

kernel lockdown 是 Linux 内核的一项安全机制，通过限制内核功能来阻止不可信代码与内核模块被加载。它有两个模式：integrity（完整性）模式，阻止会修改内核或绕过完整性检查的操作（如加载未签名模块、修改内核代码）；confidentiality（机密性）模式，在完整性基础上进一步阻止读取内核敏感信息（如 /dev/mem、/proc/kcore）。开启后，内核模块加载被限制为仅允许已签名/受信任的模块，CAP_SYS_ADMIN 等提权操作也被收窄，从而防止攻击者通过加载恶意模块或篡改内核提权。安全价值在于：即使攻击者获得 root 权限，也无法通过加载内核模块注入 rootkit 或篡改内核，这是纵深防御的重要一环。运维影响：开启后安装/加载内核模块会被阻止（需签名），内核调试工具（kprobe、kmem 读取）受限，依赖特定模块的驱动或内核功能可能不可用，因此需要评估业务对模块的依赖，并配合签名模块管理。

lockdown 的价值在于"限制 root 层的内核操作"，它把"root 权限"从"可加载任意内核代码"收窄为"只能加载受信任模块"，从而阻断内核级 rootkit。运维影响是它的代价——模块加载、调试与敏感内核访问被限制，需要平衡安全与业务可用性，通常配合签名模块与 kernel 更新策略使用。

• seccomp 与 seccomp-bpf 的机制
• 白名单策略（只允许必要 syscall）
• 兼容性权衡（破坏功能、默认策略、异常处理）

seccomp（secure computing）通过限制进程可以进行的系统调用缩小攻击面。seccomp-bpf 使用 BPF 过滤器对每个系统调用做决策，可定义为"允许（allow）、拒绝（errno/ENOSYS）、杀死（kill）"等动作。常见的做法是白名单策略：只允许进程运行所需的系统调用，其余一律拒绝或返回错误，从而让攻击者无法利用被禁用的 syscall 提权或逃逸。默认返回 ENOSYS 或 EACCES 可让程序试图用被禁 syscall 时优雅失败，而不是被杀。与兼容性权衡：白名单越严格，攻击面越小，但越容易破坏程序功能——若程序依赖被禁的 syscall（如某些高性能、调试、dirty 操作），会报错或崩溃。因此需先通过"审计/记录模式"（SCMP_ACT_LOG）观察程序实际使用的 syscall 集，生成白名单，再收紧为 enforce；对容器场景，可使用默认 seccomp profile（Docker/K8s 提供）并针对特殊程序做例外。本质上是在"攻击面"与"功能兼容"之间寻找平衡。

seccomp 的价值在于"最小系统调用面"：许多提权与逃逸攻击依赖特定 syscall，禁用后攻击面显著缩小。关键权衡是"白名单 vs 兼容性"——白名单策略需基于真实行为观察，用 LOG 模式先收集再收紧，避免 strict 导致功能破坏。这也是容器运行时默认 seccomp 的核心设计思路。

• auditd 的审计机制与规则配置
• 关键文件与系统调用审计规则
• 覆盖度与日志量的平衡（per-rule、排除、采样）

auditd 是 Linux 审计守护进程，通过内核审计子系统记录关键文件、系统调用与安全事件。审计规则通过 auditctl 或 /etc/audit/rules.d/ 配置，常见规则包括：文件监控（-w /etc/passwd -p wa -k key，监控文件写/属性变更）、系统调用监控（-a always,exit -F arch=... -S execve -k exec，记录命令执行）、身份/提权事件（-S setuid等）。设计规则时需兼顾覆盖度与日志量：覆盖关键安全点（passwd、sudoers、SSH、启动配置、关键配置目录、execve 等），但避免过度记录导致日志爆炸；可通过 -F 过滤条件（如按 uid、按目标文件）减少噪音，用 -x 排除项、设置日志 rotation 与容量限制，对高频但低价值事件采样或排除。关键事件（如提权、权限变更、关键文件修改）应重点记录并接入告警，普通事件则按需保留。

auditd 的核心是"规则设计"——要覆盖"哪些关键点"，又要控制"日志量"。好的设计是"关键点全覆盖 + 精细化过滤 + 日志容量管理"：用 -k 打标签便于检索，用 -F 条件过滤噪音，用 rotation 与容量限制防日志耗尽。审计结果的消费（告警、SIEM 集成）也决定了规则的价值。

• 告警分级（严重度、影响面）
• 误报标注（feedback、triage）
• 规则调优的闭环（规则→传播→复查→改进）

HIDS 告警运营的关键是建立"告警→处置→反馈→调优"的闭环。告警分级：根据告警的严重度（如提权、恶意进程、异常登录）与影响面（涉及主机数量、关键资产、数据敏感度）将告警分为不同级别（如 Critical/High/Medium/Low），不同级别对应不同的响应时限与处置人。误报标注：对每条告警进行研判（triage），标注为"真阳性/误报/需观察"，将误报与判定理由记录回传，形成真实的标注数据集。规则调优：基于标注数据识别高误报规则，进行调优（收紧阈值、增加上下文条件、按资产/场景细分），同时对漏报进行补充。整个闭环要求"告警必须被处置、判定必须被记录、规则必须被复盘"，最终达到告警量下降、准确率上升、处置效率提升。

HIDS 运营的核心是"闭环"而非"工具"：告警分级让响应有优先级，误报标注让规则有训练数据，规则调优让告警质量持续提升。若只"产生告警"而不做标注与调优，告警会越来越多且淹没真实威胁。因此闭环设计比个别规则更重要，是 HIDS 落地的前提。

• Boundary 的架构（controller、worker、target）
• 会话代理与鉴权授权
• 避免直接暴露端口（动态端口、身份访问）

HashiCorp Boundary 是一个基于身份的安全访问平台，通过"会话代理"实现对主机与服务的访问控制，避免直接暴露 SSH/RDP 等端口。其架构由 controller（控制面，负责鉴权与授权）、worker（代理面，负责建立会话通道）和 target（目标主机/服务）组成。用户访问时，先通过 controller 认证身份并授权，controller 根据授权策略生成会话，worker 在后端为目标动态建立临时端口/通道，用户通过该会话通道访问目标，而非直接打开主机端口。这样 SSH/RDP 端口不对外暴露，外部无法直接扫描到，访问受身份、MFA、授权策略控制，且可记录会话审计。Boundary 还支持动态凭据（boundary 管理的 SSH 密钥等）注入，进一步减少静态密钥暴露。

Boundary 的核心价值是"以身份为中心+会话级代理"：它把"网络可达性"转化为"身份授权后的短时会话"，从而隐藏目标端口、降低扫描面，并把访问与审计、MFA 绑定。与 VPN 相比，它不提供网络级连通，而是应用/会话级代理，更符合最小权限原则。

• 基于日志的暴力破解检测原理
• 动态封禁机制（iptables/firewalld）
• 误封与绕过风险的控制

fail2ban 与 SSHGuard 都是基于日志的暴力破解防护工具：它们监控 SSH 等服务的日志（如 auth.log），通过正则匹配失败登录尝试，当同一来源 IP 在一定时间内失败次数超过阈值时，触发封禁动作（如通过 iptables/firewalld/ufw 临时封禁该 IP）。封禁是动态的，可配置封禁时间（ban time）与自动解封。误封风险主要来自：合法用户多次输错密码、共享 IP/NAT 出口被误封、或代理 IP 被滥用。控制手段包括：合理设置阈值与封禁时长（避免过严）、白名单（allowlist）重要 IP、基于端口/服务区分、对封禁结果记录并人工复核。绕过风险包括：攻击者使用大量分散 IP（分布式暴力破解）、改变源 IP 或使用代理，或直接攻击前先清空日志。控制手段包括：与更广的威胁情报/分布式检测结合、限制登录尝试次数、启用 key 认证而非密码、以及配合 IP 信誉与 CAPTCHA 等。

fail2ban/SSHGuard 的核心是"基于日志的阈值封禁"，简单有效但有过期性（只针对已知来源）。风险在于误封（影响合法用户）与绕过（分布式/换 IP）。好的实践是"合理阈值 + 白名单 + 配合 key 认证/更广的检测"，而不是把封禁当作唯一防线。

• 隔离（网络隔离、保持现场）
• 取证（内存/磁盘/日志保全）
• 重建（root cause、加固、恢复）

主机入侵后的处置流程分为隔离、取证与重建三个阶段。隔离：在确认入侵后，先断开或限制该主机的网络连接（隔离出隔离网段、切断对外通信），防止横向扩散与攻击者继续利用，同时尽量保持现场不被破坏（避免立即重启/删除文件，以免丢失内存证据）。取证：在隔离环境中进行证据保全，优先采集内存（内存转储）、运行中的进程与网络连接、磁盘镜像、日志（auth.log、audit、shell history）、进程与计划任务，记录时间线与攻击迹象，交由专业取证分析（如 Volatility、Autopsy）。重建：在取证完成后，定位 root cause（入侵途径、漏洞、后门），清除后门与恶意软件，进行加固（补丁、改密码、收紧权限、清理运行后门），再重新部署干净的系统或从备份恢复，并更新监控告警以防止复发。

隔离、取证、重建三者顺序重要且相互依赖：隔离要"快"（先止血防扩散）但"不破坏现场"（为取证保留证据）；取证要"完整"（内存优先，因为重启即失）；重建要在"root cause 已知"后进行，否则会再次被入侵。这是一套标准的应急响应流程，配合审计与演练才能落地。

• agent 的资源占用与性能影响
• agent 的可用性（故障、自愈、升级失败）
• 升级管理（灰度、回滚、兼容性）

主机安全代理（agent）既是安全防护，也是运行在主机上的程序，其自身可用性与升级管理很重要。资源占用方面，需控制 agent 的 CPU/内存/网络开销，避免对业务造成影响，设定资源上限并监控。可用性方面，agent 需具备自愈能力（崩溃自动重启、对接守护进程），在网络/后端不可用时妥善降级（保护行为优先于报告），避免因 agent 故障导致主机裸奔或误封。升级管理方面，采用灰度发布（先小范围试点，再分批推广）、监控升级后的告警与兼容性、准备回滚机制（agent 升级失败自动回退到上一版本），并保证 agent 版本与后端/平台兼容，避免因升级导致防护失效。同时 agent 自身更新也要校验签名，防止被替换。

agent 的可用性决定安全防护的可靠性——一个"总是崩溃"或"自身被攻破"的 agent 等于没有防护。关键在资源控制、自愈降级、灰度升级与回滚，以及 agent 自身的完整性校验。这体现了"安全工具本身也要被安全与可靠地运维"。

• 基线扫描（发现偏离）
• 偏离修复（处置）
• 复测验收（确认、更新基线）

安全基线核查流程通过"扫描→修复→复测→更新"的闭环管理主机安全状态。基线扫描：按安全基线（如 CIS Benchmark、等保、企业自定义基线）对主机进行配置核查，检测偏离项，生成偏离清单并评级。偏离修复：对发现的偏离项进行分类处置，区分"必须修复"（如无权限配置、开放端口）与"可接受风险"（业务需要的例外），对必须项制定修复方案并实施。复测验收：修复后再次扫描（复测），确认偏离项已消除，并记录验收结果；对无法立即修复的项走例外申请与跟踪。基线版本更新：当环境、业务或合规要求变化时，更新基线版本（如新增安全项、调整阈值），重新执行扫描，确保基线始终与当前安全要求一致。整个闭环以"基线版本"为基准，通过扫描-修复-复测保证主机持续符合基线，通过版本更新保证基线本身的时效性。

基线核查的本质是"持续合规"而非"一次检查"：扫描发现偏离，修复消除偏离，复测确认修复，版本更新让基线跟上变化。闭环的关键是"偏离必须有处置、修复必须有复测、例外必须有跟踪"，避免"扫而不修、修而不验"。

• WireGuard 组网与最小暴露原理
• 与传统 VPN 的差异（网络级 vs 服务级、身份、密钥管理）
• 落地要点（身份认证、访问控制、跨网段）

Tailscale 基于 WireGuard 构建，通过控制平面（coordination server）管理节点身份与密钥，数据面则建立端到端的 WireGuard 加密隧道。它实现"最小网络暴露"的核心是：主机之间只建立按需的、加密的身份对身份隧道，不开放任何公网监听端口，也没有集中式的 VPN 网关暴露在公网。相比传统 VPN（如 OpenVPN/IPsec），Tailscale 的差异在于：它不提供"网络级连通"（把整个虚拟网段暴露给客户端），而是按身份将节点加入 tailnet，通过 ACL 精确控制"谁可以访问谁的哪个端口/服务"，实现服务级的最小暴露；同时自动处理 NAT 穿透、密钥自动轮换，并在设备上做身份认证（SSO、MFA、设备信任）。替代传统 VPN 的要点包括：用 ACL 收敛到最小权限、通过网络策略（如禁用直连、仅开放特定端口）减少暴露面、把访问与身份/审计绑定，从而在不降低体验的前提下避免把整个内网暴露给单个客户端。

传统 VPN 的问题是"一次连接、全内网可达"，一旦客户端被攻破，整个内网暴露。Tailscale 用"身份对身份、服务级 ACL"的方式把暴露面收敛到最小——只有被授权的节点与端口才可访问，且不暴露公网监听端口。这正是零信任"最小暴露"思想在组网层面的落地。

• SPA 单包授权的基本原理
• 端口隐藏与防火墙动态放行机制
• 适用场景与局限性

fwknop 实现单包授权（SPA，Single Packet Authorization）：客户端在真正连接 SSH 等端口前，先向目标发送一个加密并签名的单一数据包（SPA 包），其中包含客户端身份、时间戳、一次性随机数（nonce）与请求的端口信息。目标主机的 fwknop 服务器监听该包并验证签名、时间戳与 HMAC 防重放，验证通过后，通过 iptables/firewalld 动态放行该来源 IP 对目标端口的访问，之后客户端即可正常连接。由于 SPA 端口默认关闭（防火墙 DROP），端口在网络层不可见、不可扫描，攻击者无法探测到 SSH 等端口存在，从而隐藏服务。适用场景：对公网暴露的 SSH/管理端口做隐蔽，防止端口扫描与暴力破解，适合高安全要求的管理入口。局限性：SPA 依赖"带外"发送授权包（客户端需先发起 SPA 包再连接，需配套工具），不适用于所有客户端；保护的是"端口可见性"而非"服务本身"，若被授权后仍可能被已授权但被攻破的客户端滥用；SPA 包需要密钥与时间同步，部署复杂，且对 UDP 洞、NAT 等环境有适配要求。

fwknop 的价值在于"默认隐藏 + 动态放行"：端口平时不可见，只有通过验证的 SPA 包才触发临时放行。它把"端口暴露"转化为"身份验证"问题，但局限在于它只隐藏端口、不校验业务内容，且属于"隐蔽安全"，应作为纵深防御的一环而非唯一防线。

• osquery 的 SQL 化主机信息查询机制
• 常用表（进程、网络连接、文件、用户）
• 在安全巡检与取证中的应用

osquery 将操作系统信息抽象为关系型表（tables），通过 SQL 查询的方式获取主机状态。它把进程、网络连接、文件、用户、启动项、内核模块等系统信息映射为一张张表，例如 processes（进程）、process_open_sockets（进程网络连接）、file（文件）、users（用户）、crontab（计划任务）、listening_ports（监听端口）等，管理员可用标准 SQL 查询这些内容，实现跨主机的统一巡检与取证。在安全巡检中，可用 SQL 发现异常（如查询监听端口、可疑进程、特定文件的变更、启动项）；在取证中，可查询进程树、网络连接、文件访问历史等，快速定位可疑行为。配合 osquery 的监控（schedule）与远端编排（如 Fleet、Kolide 等 osquery 管理平台），可定期执行查询并上报结果，形成持续的主机安全可见性。

osquery 的价值在于用统一 SQL 语言把纷繁的主机状态变成可查询、可巡检、可溯源的数据，消除"每台机器手工查"的差异。它适合作为安全巡检与取证的数据底座，配合定时查询与集中管理，把"看不见"的主机行为变成"可查询、可告警"的对象。

• EDR 行为分析与未知威胁检测原理
• 与特征库杀软的差异
• 落地与误报控制

基于行为分析的 EDR（如 SentinelOne、CrowdStrike）通过持续监控主机上的进程行为、文件操作、网络连接、注册表/系统配置变更等，建立"行为基线"并识别可疑行为模式，从而检测未知威胁（0-day、无签名的新恶意软件）。它不依赖"是否匹配已知病毒特征"，而是分析"行为是否异常"——例如进程在短时间内进行大量文件加密、尝试提权、读取敏感文件、建立异常外连等，结合行为链/时间线关联，判定为恶意并触发隔离、回滚（rollback）等响应。与特征库杀软（signature-based）的差异在于：特征库杀软只能识别已入库的已知病毒（精确匹配哈希/特征串），对未知威胁无能为力，且需要频繁更新病毒库；EDR 通过行为分析能识别"从未见过但行为恶意"的威胁，但对正常业务中的"可疑行为"容易误报，需要基于上下文与误报调优。落地上，EDR 通常与 EDR 平台集中管理、配合威胁情报与 SIEM，并需控制误报率。

特征库杀软解决"已知威胁"，EDR 解决"未知威胁"：前者靠"见过"，后者靠"行为对错"。EDR 的核心是行为基线 + 行为关联 + 自动响应，能应对 0-day，但代价是误报与资源开销。两者常互补使用：杀软管已知，EDR 管未知。

• 商业杀毒/EDR 与自研 HIDS 的定位差异
• 两者的分工与互补
• 告警分级与处置闭环

商业杀毒/EDR 产品（如 SentinelOne、CrowdStrike、Symantec）定位是"通用、开箱即用的主机威胁防护"，覆盖已知病毒查杀、未知威胁行为分析、自动隔离与回滚，且有专业厂商持续维护特征库与威胁情报，适合作为基线防护；自研 HIDS 则定位"贴合自身业务与安全场景的深度监测"，可针对企业特有的中间件、配置、业务进程、合规基线做定制化检测与告警，灵活度更高，但维护成本高、威胁库更新需自建。两者分工互补：商业产品负责"通用威胁防护与自动响应"，自研 HIDS 负责"业务定制检测与合规基线"，可叠加部署。告警分级处置方面，应建立分级标准（如按严重度、影响面、是否提权、是否涉及关键资产分为 Critical/High/Medium/Low），对应不同响应时限与处置人；对每条告警进行研判（triage），标注真阳性/误报，联动安全运营（SOC）流程，形成"告警→研判→处置→反馈→规则调优"闭环。

商业产品与自研 HIDS 各有定位：商业产品"通用、权威、自动响应"，自研 HIDS"定制、贴合、可控"。两者叠加而非替代，形成"基线防护 + 业务定制"的纵深。告警分级处置的核心是让告警有优先级、有责任人、有闭环，避免"告警淹没"。

• 实时防护与按需扫描的配置
• 隔离处置策略
• 误报与性能影响的评估

防病毒软件主要提供三种能力：实时防护（on-access）、按需扫描（on-demand）与隔离处置。实时防护在文件被读取/执行时进行实时检测，配置时要选择合适的扫描范围（关键目录、可执行文件、邮件等）与防护级别，并确保对业务文件服务的干扰最小；按需扫描则定期（如每日/每周）对全盘或指定目录做精扫，配置扫描计划与资源限制，避免高峰占用。隔离处置方面，检测到威胁后默认动作是隔离（quarantine）而非直接删除，把可疑文件隔离后便于人工复核，并配置白名单/例外路径避免误杀。误报评估：误报指把正常文件/程序判为病毒，需通过白名单、例外规则、扫描排除项与人工复核管理，定期复盘误报以调整规则；性能影响评估：扫描会占用 CPU/IO，需监控扫描对业务性能的影响，通过错峰扫描、限制扫描资源、只扫描必要范围来平衡安全与性能。

防病毒配置的关键是"实时防护保安全、按需扫描控成本、隔离处置保可恢复"以及"误报与性能的平衡"。误报会破坏业务（误杀正常程序），性能开销会拖慢业务，因此要配置例外、错峰扫描并监控影响，实现"安全不打折、业务不受伤"。

• 零信任终端与设备信任的概念
• 主机准入的设备信任评估
• 落地要点（设备状态、身份、访问策略）

零信任终端（BeyondCorp 模型）的核心是"不再信任基于网络位置（内网/外网）的访问，而是基于设备与身份持续验证"，在主机准入中落地就是把"能连上网络即可访问"改为"设备必须满足信任条件才能访问资源"。落地要点包括：设备信任评估——采集设备状态（是否满足基线、补丁版本、是否被 EDR/防病毒保护、是否越狱/root、设备指纹）作为信任信号；身份认证——结合员工身份（SSO、MFA）与设备绑定；访问策略——基于"身份+设备+上下文"动态生成访问策略，只允许满足信任条件的设备访问对应资源，未达标设备被隔离或降级访问。同时通过持续监控（设备状态变化时重新评估）实现动态准入，配合资产管理与设备证书（如 mTLS、设备证书）确保设备可信。与传统"内网信任"相比，零信任准入把"位置"让位于"设备+身份"的持续验证。

BeyondCorp 的本质是"信任不再来自网络位置，而来自设备与身份"。主机准入的落地就是把设备信任（状态、补丁、防护、证书）与身份认证、动态访问策略结合，让"未受信任的设备"即使在内网也无法访问敏感资源，实现真正的零信任准入。