Security Command Center 延迟时间概览

>

本页面概述了在启用该服务后发生的 Security Command Center 激活过程。它旨在解答常见问题:

  • 为组织启用 Security Command Center 后会发生什么情况?
  • 为什么首次扫描开始之前会有延迟?
  • 首次扫描和持续扫描预计需要多少运行时间?
  • 更改资源和设置对性能有何影响?

概览

大多数 Security Command Center 客户在初始配置或启用方面不会遇到明显的延迟。大约 99% 的用户在启用服务后的四个小时内便可上手使用。虽然这些数字代表典型用户体验,但某些因素可能会导致启用过程需要更长的时间。有时,特别是对于项目数量超过 10 万个的组织而言,启用和初始扫描可能需要长达 24 小时或更长时间才能完成。下面讨论的各种因素可能会在开始扫描、处理设置更改以及扫描运行时中引入延迟时间。

拓扑

下图简要介绍了初始配置和启用过程。

Security Command Center 初始配置图示(点击可放大)
Security Command Center 初始配置图示(点击可放大)

初始配置延迟时间

在开始扫描之前,Security Command Center 会从 Google Cloud 中发现属于您的组织的资源并将其编入索引。已编入索引的服务包括 App Engine、BigQuery、Cloud SQL、Cloud Storage、Compute Engine、Identity and Access Management 和 Google Kubernetes Engine。在执行此初始配置流程期间,我们会执行两个关键步骤。

资源扫描

Security Command Center 执行初始资源扫描,以识别项目、文件夹、文件、集群、身份和访问权限政策、注册的用户和其他资源的总数、位置和状态。此过程通常在几分钟内完成。

API 激活

发现资源时,Security Command Center 启用运行 Security Health Analytics、Event Threat Detection、Container Threat Detection 和 Web Security Scanner 所需的 Google Cloud 部分。部分检测服务需要在受保护的项目上启用特定的 API 才能正常运行。API 激活是指遍历您选择进行扫描的项目并自动启用这些 API 的过程。

组织中的项目数量基本上决定了初始配置和启用流程的时间长度。由于必须逐一为项目激活 API,因此 API 激活是最耗时的任务,尤其是项目数量超过 10 万个的组织。

跨项目启用服务所需的时间是线性增长的。这表示在项目数量 3 万个的组织中启用服务和安全设置需要花费的时间是项目数量 1.5 万个的组织的两倍。

对于最大的组织以外的所有组织,初始配置和启用应在 4 小时内完成。

发现

设置 Security Command Center 时,您需要决定要启用哪些内置和集成服务,并选择 Google Cloud 资源以针对威胁和漏洞进行分析或扫描。为项目激活 API 时,选定的服务将开始扫描。这些扫描的持续时间还取决于组织中的项目数量。

初始扫描完成后,内置服务即可提供发现结果。服务会遇到延迟,如下所述。

  • Container Threat Detection 具有以下延迟时间:
    • 新初始配置的组织的激活延迟时间(最多 3.5 小时)。
    • 新创建的集群的激活延迟时间(最多 30 分钟)。
    • 已激活的集群中的威胁检测延迟时间(几分钟)。
  • Event Threat Detection 激活会在几秒内完成,当 Security Command Center 中提供发现结果时,检测延迟时间通常低于 15 分钟(从写入日志后开始算起)。
  • Security Health Analytics 扫描大约会在服务启用一小时后开始。第一次 Security Health Analytics 扫描可能需要长达 12 小时才能完成。之后,大多数检测会根据资源配置更改实时运行(如需详细了解例外情况,请参阅 Security Health Analytics 检测延迟时间
  • 在启用服务之后,Web Security Scanner 扫描可能需要长达 24 小时才能启动,并在首次扫描后每周运行。

初步发现结果

在初始扫描过程中,但在初始配置流程完成之前,您可能会在 Security Command Center 信息中心内看到一些发现结果。

初步发现结果准确且可作为行动依据,但并不全面。不推荐您在前 24 小时内使用这些发现结果进行合规性评估。

后续扫描

在组织内部所做的更改(例如添加新文件夹和项目以及移动资源)通常不会显著影响资源发现时间或扫描的运行时。但是,某些扫描按设置时间表进行,这些时间表决定了 Security Command Center 检测更改的速度。

  • Web Security Scanner:每周运行一次,在初始扫描的同一天运行。由于 Web Security Scanner 每周运行一次,因此它不会实时检测组织变化。如果您移动资源或更改应用,则可能长达一周都检测不到更改。您可以运行按需扫描,以在定时运行的扫描之间检查新资源或更改过的资源。
  • Event Threat Detection/Container Threat Detection:这些服务在启用后便会实时运行,并立即在已启用项目中检测新资源或更改过的资源(例如集群、存储分区或日志)。
  • Security Health Analytics:该服务在启用后便会实时运行,且在几分钟后便会检测新资源或更改过的资源(但以下所列的检测除外)。

Security Health Analytics 检测延迟时间

Security Health Analytics 检测会在服务启用时一次性运行,或者在相关资源的配置更改时实时逐一运行。启用 Security Health Analytics 后,任何相关的资源配置更改都会近乎实时地(10 分钟内,但通常更快)生成更新的配置错误发现结果。

某些 Security Health Analytics 检测器不支持实时扫描模式,例如,针对资源配置外部的信息运行检测。下表中所列的这些检测会定期运行,并在 12 小时内识别配置错误。如需详细了解 Security Health Analytics 检测器,请参阅漏洞和发现结果

不支持实时扫描模式的 Security Health Analytics 检测
API_KEY_EXISTS
API_KEY_NOT_ROTATED
API_KEY_APIS_UNRESTRICTED
API_KEY_APPS_UNRESTRICTED
COMPUTE_PROJECT_WIDE_SSH_KEYS_ALLOWED
COMPUTE_SERIAL_PORTS_ENABLED
DISK_CSEK_DISABLED
FULL_API_ACCESS
MFA_NOT_ENFORCED(以前称为 2SV_NOT_ENFORCED)
OS_LOGIN_DISABLED
PUBLIC_IP_ADDRESS
SSH_PASSWORD_ENABLED
SQL_NO_ROOT_PASSWORD
SQL_WEAK_ROOT_PASSWORD
WEAK_SSH_PASSWORD

后续步骤