免费咨询
SECURITY QUICK CHECK

发现公开配置的薄弱点，并梳理接下来应确认的风险。

从域名的公开信息中，快速确认 HTTPS、DNS、安全响应头等基本配置。此外，还用易懂的图示梳理仅凭公开配置无法发现的凭据、令牌、云、终端与备份风险。

此检查是仅使用公开信息的非侵入式简易确认。不进行内部渗透测试、密码尝试、端口扫描或应用程序的详细漏洞诊断。

免费检查域名 咨询安全改进
以公开信息为主进行确认 无需输入密码或机密信息 无入侵或暴力破解尝试 结果并非安全保证，而是改进的起点
零信任设计

不再默认"内网即安全"——零信任的防护方式

对外可见的入口状态可通过本次简易诊断确认。再往里，则由"零信任"来防护——无论在公司、云端还是在家，每次访问都验证用户与设备。

  • 身份与多因素认证

    以 Microsoft Entra 强化身份验证。摆脱仅靠密码，通过多因素认证与条件访问阻止非法登录。

  • 设备健康状态

    只信任公司掌握并管理的设备。检查系统更新与反恶意软件状态，阻断来自高风险设备的访问。

  • 最小权限与可视化

    只授予每个人所需的范围。记录并可视化谁访问了什么，以便快速发现异常。

即使生成式 AI 与外部集成（MCP、API）不断增加，因为靠"验证"而非网络边界来防护，扩展时也不易出现新的缺口。

咨询零信任设计

攻击者盯上的不只是密码

认证成功后签发的 Cookie 与访问令牌、应用与 CI/CD 持有的机密、云工作负载的身份、认证平台的签名密钥，都会成为攻击目标。因此，除了入口认证，还需从整体思考「凭据存在于何处、可能从何处被带走」。

点击图片可放大查看

混入 URL 与日志

若在 URL 中包含访问令牌，会残留在浏览器历史、Referer、代理、APM、访问日志等处。

应用／API 服务器被入侵

服务器一旦被入侵，可能从内存、缓存、数据库、配置文件等处获取令牌与机密。

CI/CD 与源代码管理

API 密钥、密码、令牌可能被误记录到环境变量、构建日志、配置文件与源代码中。

凭据并非只存在于一处。在 URL、浏览器、服务器、云、开发流水线与终端等各处，都需要「不暴露、不残留、不扩散」的设计。

按攻击路径分类的详细解说

我们将典型攻击整理为五个类别。每张图片均可点击或轻触放大。

认证与会话

钓鱼／中继型攻击

通过伪造邮件或链接，将用户诱导至伪造登录页面。中继服务器可介于用户与正规服务之间，将账号、密码乃至 MFA 操作转发给正规服务。

查看攻击流程与对策
攻击流程

一旦在正规服务上登录成功，攻击者即可获取由此产生的会话 Cookie 或令牌，重用已登录状态。

可能的影响

即使已部署 MFA，部分方式仍会受中继型钓鱼影响，已登录会话可能被劫持。

优先对策
  • 让管理员与重要用户迁移到通行密钥／FIDO2
  • 禁用旧式认证
  • 应用条件访问
  • 要求合规或受管终端
  • 监控可疑登录与会话
  • 准备会话吊销流程
Quick Check 可发现的范围

公开信息无法确认邮件或登录页面的内容。仅可确认 HTTPS、HSTS 是否存在等部分基本设置。

Quick Check 无法发现的范围

无法确认 MFA 方式、条件访问、会话保护以及抗钓鱼认证的部署情况。

注意 请勿认为仅靠 FIDO2 就能防住所有攻击。终端本身被入侵，或登录后的会话窃取，需要其他防御。

认证平台与签名密钥被入侵

攻击者侵入认证平台、签名密钥、证书、密钥管理服务器或管理员账户。

查看攻击流程与对策
攻击流程

获取或滥用签名私钥后，可生成看似由真实认证平台签发的 JWT 与令牌，访问 API、业务应用与云资源。

可能的影响

签名密钥是认证信任的基石。一旦被入侵，无需窃取密码即可伪造看似合法的令牌。

优先对策
  • 用 HSM 或 Managed HSM 保护高价值签名密钥
  • 分离控制面与数据面权限
  • 分离认证平台管理、密钥管理与审计职责
  • 用 PIM/JIT 将管理权限临时化
  • 定期轮换密钥
  • 准备密钥吊销、证书更新、令牌失效的应急流程
  • 不要将生产密钥带入开发环境
Quick Check 可发现的范围

认证平台与密钥管理状况无法从公开信息确认。

Quick Check 无法发现的范围

无法确认签名密钥的保护方式（如 HSM）、职责分离、密钥轮换、审计日志与应急吊销流程。

注意 仅靠 HSM 无法防住所有管理员账户被入侵或密钥滥用。请结合职责分离与监控。

Web 应用与日志

XSS 与恶意浏览器扩展

若恶意 JavaScript 混入 Web 应用并执行，可能读取 localStorage、sessionStorage、屏幕输入及可读 Cookie，并发送到外部。

查看攻击流程与对策
攻击流程

用户安装的恶意扩展也可能访问页面内容、表单信息、Cookie 与令牌。

可能的影响

可能从已登录用户处带走认证令牌与输入信息，导致冒充或信息泄露。

优先对策
  • 不要禁用 Razor 自动编码
  • 不要随意使用 Html.Raw
  • 避免 innerHTML 与 document.write
  • 如需允许 HTML，使用可信的清洗器
  • 以 nonce 或 hash 方式配置 CSP
  • 为 Cookie 设置 HttpOnly、Secure 与合适的 SameSite
  • 不要随意将认证令牌存入 localStorage
  • 企业终端对浏览器扩展采用白名单制
Quick Check 可发现的范围

可确认 Content-Security-Policy 与 X-Content-Type-Options 响应头是否存在（纵深防御的一部分）。

Quick Check 无法发现的范围

无法确认是否实际存在 XSS、Cookie 属性（HttpOnly / Secure / SameSite）、令牌存储位置以及扩展管理情况。

注意 CSP 很重要，但不要将其作为 XSS 防御的核心。基础是输入校验、按输出场景编码、使用安全的 DOM API。HttpOnly Cookie 并不能修复 XSS 本身。

机密信息混入 URL 与日志

若在登录后的 URL 中包含 access_token 等机密，可能残留在浏览器历史、Referer、反向代理、APM 与 Web 服务器访问日志中。

查看攻击流程与对策
攻击流程

日志中残留的令牌、授权码、会话 ID 与用户标识可能被查看、转发并滥用。

可能的影响

URL 会被许多系统记录。即便是 POST 请求体，也可能被 APM 或调试日志记录，因此并非「POST 就一定安全」。

优先对策
  • 不要在 URL 中放入机密
  • 记录日志前对令牌与 Cookie 做脱敏
  • 检查 APM、代理、WAF 与访问日志设置
  • 设置 Referrer-Policy
  • 使用短生命周期令牌
  • 不要将不必要的查询串发送到分析平台
Quick Check 可发现的范围

URL 设计与日志内容无法从外部确认。仅可确认基本安全响应头是否存在。

Quick Check 无法发现的范围

无法确认 URL 中是否混入机密、日志脱敏情况、APM 与代理配置以及 Referrer-Policy 的具体内容。

云与服务器

应用／API 服务器被入侵

攻击者利用漏洞、配置缺陷或非法访问侵入应用或 API 服务器，并探查其内部。

查看攻击流程与对策
攻击流程

从进程内存、缓存、数据库、环境变量、配置文件、临时文件与日志中获取令牌、Cookie、API 密钥与连接串，进而入侵其他系统。

可能的影响

应用正常使用的凭据也会暴露给攻击者，因此不仅要「不让入侵」，还需设计为即便被入侵也不暴露机密、不扩大权限、并能检测数据外带。

优先对策
  • 不要将机密直接保存在源代码或配置文件中
  • 使用 Azure Key Vault 等机密管理平台
  • 用 Managed Identity 减少固定凭据
  • 分离应用、数据库与管理面
  • 实施最小权限 RBAC
  • 部署 EDR、日志监控与异常检测
  • 准备被入侵时的机密轮换流程
Quick Check 可发现的范围

服务器内部状态无法从公开信息确认。仅可确认对外公开的 HTTPS 与部分响应头。

Quick Check 无法发现的范围

无法确认机密管理方式、权限设计、补丁应用、EDR 与监控部署以及工作负载隔离。

云工作负载被入侵与 Managed Identity 滥用

攻击者侵入 Web 应用、VM、App Service 或容器，访问内部元数据服务或认证端点。

查看攻击流程与对策
攻击流程

获取分配给工作负载的 Managed Identity 等临时访问令牌，冒充应用访问 Azure 资源。

可能的影响

Managed Identity 本身是有效机制，但若工作负载被入侵且该身份被赋予过多权限，攻击者也能获得同样的权限。

优先对策
  • 对 Managed Identity 也应用最小权限
  • 不要随意授予订阅级 Contributor
  • 不要在无关的多个工作负载间共享同一身份
  • 不要让外部输入驱动任意外发 URL
  • 使用 URL 白名单并校验解析后的 IP
  • 拒绝私有、回环与链路本地目标
  • 对重定向目标也重新校验
  • 考虑网络隔离与 Private Endpoint
Quick Check 可发现的范围

云内部的权限与网络设计无法从公开信息确认。

Quick Check 无法发现的范围

无法确认 Managed Identity 权限设计、SSRF 防御、网络隔离以及元数据服务保护情况。

注意 不要仅用简单的字符串检查来实现 SSRF 防御。需要校验解析后的 IP，并在每次重定向时重新校验。

持续评估整个云的漏洞与攻击路径

在生成式 AI 与攻击自动化使「发现漏洞到发起攻击」的时间缩短的背景下，用 Microsoft Defender for Cloud 持续评估云安全态势的理念。

查看攻击流程与对策
攻击流程

对资产、配置与漏洞进行持续评估，掌握暴露在互联网的资产，进行贯穿身份、网络与数据的攻击路径分析，并管理含 Azure、AWS、GCP 的多云。

可能的影响

不是以相同优先级修复所有问题，而是结合暴露面、权限、漏洞、数据重要性与真实攻击路径来排定优先级。

优先对策
  • 盘点资产与已连接环境
  • 确认 Defender for Cloud 覆盖范围
  • 为安全建议指定负责人与期限
  • 依攻击路径优先处理高风险项
  • 定期检查互联网暴露资产
  • 记录例外、豁免与未处理原因
  • 在管理层、信息部门与开发间共享进展
Quick Check 可发现的范围

此简易检查仅能发现部分公开资产（如 HTTPS、DNS）。

Quick Check 无法发现的范围

无法确认云配置的全面评估、攻击路径分析、Defender 覆盖范围与优先级排定。

注意 产品功能与名称可能更新，请以 Microsoft Learn 最新信息为准进行确认。

终端与管理员

使用终端的恶意软件

展示已登录业务应用或云服务的终端被恶意软件入侵的过程。

查看攻击流程与对策
攻击流程

从被入侵的终端可能窃取浏览器保存的账号密码、运行进程内存、Cookie 与令牌、缓存与临时文件、屏幕与输入信息。

可能的影响

即便认证很强，若用于登录的终端本身被入侵，登录后的凭据仍可能被窃取。对于重要操作或管理员工作，需将终端安全作为认证条件的一部分。

优先对策
  • 部署 EDR 并检查是否有终端未纳管
  • 应用攻击面缩减规则
  • 通过条件访问要求受管／合规终端
  • 削减本地管理员权限
  • 实施应用程序控制
  • 使用管理员专用终端（PAW／SAW）
  • 准备感染终端隔离与令牌吊销流程
Quick Check 可发现的范围

终端状态完全无法从公开信息确认。

Quick Check 无法发现的范围

无法确认 EDR 部署、终端合规、条件访问、本地管理员权限与应用控制情况。

恢复与备份

遭入侵后仍可恢复的不可变备份

将来自 Azure 与本地环境的备份保存到受保护区域，并由中央 Immutable Vault 在保留期内使其不可删除、不可篡改。

查看攻击流程与对策
攻击流程

即便攻击者或被入侵的管理员试图删除备份、删除恢复点、缩短保留期或停用保护，纵深防御也会保护这些关键操作。

可能的影响

在勒索软件防护中，不仅要保护生产数据，还需保护备份本身免受攻击者与被入侵管理员的破坏。

优先对策
  • 在受支持的保管库上启用不可变性
  • 运行稳定后考虑 Locked 状态
  • 启用软删除
  • 配置 Resource Guard 与多用户授权（MUA）
  • 分离备份管理员与安全管理员
  • 将 Resource Guard 置于独立订阅或独立租户
  • 定期执行恢复测试
  • 依业务需求设定 RPO、RTO 与保留期
Quick Check 可发现的范围

备份与恢复设计无法从公开信息确认。

Quick Check 无法发现的范围

无法确认保管库设置、不可变性、软删除、MUA、职责分离与恢复测试情况。

注意 该图为概念图。并非所有 Azure 数据库或本地产品只要开启设置就能以相同方式受保护。可用功能因受支持的工作负载、保管库类型、区域与方式而异，需在实际环境中确认。

不知从何入手时，用五个阶段来梳理

无需一次性处理所有问题。思路是按「影响大且易被利用」的顺序逐步整改。

  1. STEP 1 保护对外公开的入口

    • 全站 HTTPS 与 HTTP→HTTPS 跳转
    • 管理 TLS 证书有效期
    • 添加 HSTS 等基本安全标头
    • 关闭不必要的公开端口与管理后台

  2. STEP 2 强化认证与账户

    • 抗钓鱼的多因素认证
    • 条件访问兼顾终端、位置与风险
    • 以 PIM/JIT 最小化管理员权限
    • 清理离职者与无用账户

  3. STEP 3 重新审视应用与数据的处理方式

    • 校验输入并转义输出（防 XSS）
    • 不将机密留在 URL 与日志中
    • 用 Key Vault 等管理密钥
    • 以最小权限对接 API 与服务

  4. STEP 4 持续监控云与终端

    • 持续评估云态势并掌握暴露资产
    • 部署 EDR 与终端合规
    • 日志聚合与异常检测
    • 完善事件响应流程

  5. STEP 5 即便遭入侵也能恢复的准备

    • 抗篡改、抗删除的不可变备份
    • 分离备份管理员与生产管理员
    • 定期恢复测试
    • 依业务需求设定 RPO/RTO 与保留期

此顺序仅为梳理的参考。真实优先级取决于暴露范围、所处理数据的重要性与业务影响。

把检查结果转化为实际改进计划

简易检查只是起点。之后，我们会结合您的环境与运维，一起梳理具体的改进内容。

Web 发布配置审查

  • 检查 HTTPS、TLS 与安全标头
  • 确认跳转与 Cookie 属性
  • 梳理不必要的公开资产
  • 明确改进内容并排定优先级

Entra ID 与认证审查

  • 设计 MFA 与条件访问
  • 审视管理员权限与 PIM/JIT
  • 梳理来宾与外部协作权限
  • 制定登录风险应对方针

Azure 与多云审查

  • 持续评估云态势的思路
  • 掌握暴露资产与攻击路径
  • 审视权限、网络与数据保护
  • 排定优先级的改进路线图

应用与开发流程审查

  • 设计输入校验与输出转义
  • 密钥管理与配置信息处理
  • 检查依赖与供应链
  • 将安全嵌入开发流程

勒索软件与恢复设计

  • 设计不可变备份
  • 备份治理与职责分离
  • 恢复测试与恢复流程
  • 设定 RPO/RTO 与保留策略
就检查结果咨询 预约 30 分钟安全咨询

审查内容会依环境与规模调整。请先告诉我们现状与关心的问题。

简易检查可确认的范围

此检查可确认的内容

以下仅显示当前后端实现实际确认的项目。

  • 是否通过 HTTPS 公开
  • TLS 证书有效期
  • 主要安全响应头（HSTS / CSP / X-Content-Type-Options / X-Frame-Options）是否存在
  • 从 HTTP 到 HTTPS 的跳转
  • DNS 公开记录（A / AAAA）
  • 邮件认证公开设置（SPF / DMARC）

仅凭此检查无法确认的内容

  • 应用内部的授权缺陷
  • SQL 注入或 XSS 的实测
  • Entra ID 或条件访问的配置
  • Cookie 与令牌的存储方式
  • 源代码或 CI/CD 中的机密信息
  • 服务器内存或缓存中的信息
  • Managed Identity 的权限设计
  • 使用终端的恶意软件感染
  • 签名密钥与证书的管理状况
  • 备份的抗删除能力
  • 内部网络或管理界面的配置

确认公开配置只是「入口」。对于重要系统，需要将应用、身份、云、终端与备份组合起来评估。

先确认已公开的配置

从网站外部可确认的配置中，隐藏着防御攻击的重要线索。但公开配置没有问题，并不等于整个系统是安全的。

以 example.com 的格式输入 无需输入 http://、https:// 或路径 请输入贵司拥有或有权确认的域名

常见问题

仅凭这个简易检查就能说我们的安全没问题吗？

不能。此诊断仅检查域名的公开入口部分（HTTPS、DNS、邮件认证等），不涵盖认证平台、云配置、终端、内部系统与备份。它并非安全保证，请将其视为发现问题的第一步。

我输入的域名会被保存吗？

本工具不会将您输入的域名持久保存到数据库等。它仅为诊断临时连接目标域名并显示结果。结果页面的 URL 中也不包含该域名。

可以检查非本公司管理的域名吗？

本工具在公开信息范围内进行外部检查，但原则上请对您拥有或获授权的域名使用。它并非用于对他人域名进行过度探测或攻击性行为。

显示「无问题」的项目今后也安全吗？

这只是当时的外部检查结果。证书到期、配置变更与新漏洞都会改变状况。请以定期复查与持续监控运维为前提。

页面上的图示与产品名称可以直接套用到本公司吗？

图示为传达思路的概念图。实际可用的功能与设置取决于工作负载、许可、区域与配置。采用前请以最新官方信息并在自身环境中确认。

如果想咨询改进，应从何入手？

请先告诉我们本页的简易检查结果与您的顾虑。我们会结合您的现状，一起梳理应从发布设置、认证、云、应用还是恢复入手。欢迎通过咨询表单或预约咨询与我们联系。