在隔离网络和断开连接的环境中部署 Elastic

作者：来自 Elastic Chaison Griffin

Elastic 在隔离网络和断开连接的网络中部署时，可以完全正常运行。

摘要

• Elastic 隔离网络部署包括 自托管部署 、Elastic Cloud Enterprise（ECE） 和 Elastic Cloud for Kubernetes（ECK）。

• Elastic 支持在本地托管所有必需组件，以确保 Security 、EDR 、搜索 、可观测性以及其他功能在离线环境中完全正常运行。

• Elastic 可以轻松配置内部或私有的 Certificate Authority（证书颁发机构） ，以确保所有通信都通过 TLS 进行安全保护。

政府机构和军事组织通常运行自己的私有、安全网络。其中许多网络是断开连接和隔离网络，这意味着它们无法访问公共互联网。这通常会限制它们可以使用的产品和服务，尤其是在越来越多工具仅托管于云端的情况下。

这种情况不仅存在于公共部门。金融、医疗和研究领域的企业也越来越多地将资源完全托管在与外界隔离的环境中，以确保最高级别的安全性。

无论出于何种原因，Elastic 都为 Elasticsearch Platform 提供完整的离线能力，包括我们的搜索、Security 和可观测性解决方案。

在本文中，我们将介绍 Elastic 为隔离网络架构和服务提供的选项，并提供有关如何处理证书要求和信任管理的分步指导。

部署方式

Elastic 支持多种部署模型，以满足不同的运营和安全需求。这些模型大致可以分为 SaaS 和非 SaaS 部署。

在本文中，我们将重点介绍非 SaaS 部署模型，这些模型支持 Elastic 在隔离网络或断开连接的环境中运行。

• 自托管部署

  • 在虚拟机（VM）或裸机上手动安装和运行

• Elastic Cloud on Kubernetes（ECK）

  • 用于管理 Elasticsearch、Kibana、Fleet 以及相关组件的 Kubernetes 原生 operator

• Elastic Cloud Enterprise（ECE）

  • 用于管理多个 Elastic 部署的企业级编排平台

这些部署模型可以用于：

• 本地数据中心

• 公有云或政府云环境，包括 GovCloud

• 具有有限或间歇连接能力的可部署环境或战术套件

• 船舶、潜艇或飞机等环境

Elastic 在隔离网络环境中

Elastic 在断开连接和隔离网络环境中可以完全正常运行。在已托管所需支持服务的前提下，所有功能都与连接互联网的部署方式相同。

Elastic 支持客户镜像或本地部署所有外部依赖，从而消除运行时对互联网的需求。

可以本地托管的核心服务

• Elastic Package Registry

  • 集成、agent 策略以及 Fleet 管理内容所需

• Elastic Maps Service

  • 提供地图瓦片和地理空间资源

• Elastic Endpoint Artifact Repository

  • 为 Elastic Defend 提供恶意软件防护资源

• Machine learning

  • 支持异常检测、推理以及其他 machine learning 功能

• 大型语言模型（LLM）

  • 使用本地托管的模型支持 AI 驱动的搜索和 Security 工作流

Elastic 隔离网络架构

大多数 Elastic 支持服务都以容器化应用的形式提供。这些容器可以部署在 Kubernetes 中，也可以使用 docker 或 podman 在本地虚拟机（VM）上运行。

网络和访问注意事项

• 服务通常部署在反向代理之后（例如 NGINX 或 Apache）

• 反向代理通常用于：

  • SSL/TLS 终止

  • 集中式访问控制

  • 简化 DNS 和路由配置

TLS 证书和信任管理

在断开连接的环境中运行通常需要使用自签名证书或由内部 Certificate Authority（CA）签发的证书。

Elastic 支持多种方法，以确保客户端与 Elastic 服务（例如 Elasticsearch、Kibana 和 Fleet）之间的通信安全。

如果组织使用内部 CA，则需要：

• 使用该 CA 为所有 Elastic 服务签发 TLS 证书

• 将 CA 证书分发到：

  • 主机操作系统

  • 工作站

  • 容器信任存储

这样可以无需额外配置即可进行原生信任验证。

推荐方式：Elastic 内部 CA

Elastic 自带内部 CA，用于在 Elastic Stack 中配置 HTTPS。

默认情况下，该 CA 已经完成配置，并会在 Elasticsearch 初始设置过程中签发所使用的证书。

建议使用 Elastic CA 为其他组件（例如 Kibana 和 Fleet）生成所需证书。

备用方式：受信任机构 CA

如果组织拥有自己的受信任机构 CA，可以使用 elasticsearch-certutil 命令生成 CSR，用于为 Elasticsearch 和 Kibana配置 HTTPS。

从 Fleet 配置 CA 信任

并非始终可以将 CA 证书分发到所有 endpoint。

在这些情况下，Elastic 也提供了在 Fleet 策略中定义 CA 信任信息的方式，用于 Elastic Agent 通信。

在 Fleet 中，对于 Elasticsearch output，有两种方式可以配置 TLS 证书详细信息，使所有 Agent 都能够验证 Elasticsearch 节点的证书：

1. Elasticsearch CA trusted fingerprint

2. 高级 YAML 配置

在 Fleet 中配置证书设置的优势在于，所有 Agent 都会信任 Elasticsearch 证书，无论 endpoint 是否已经将对应的 CA 添加到本地信任存储中。

选项 1：Elasticsearch CA trusted fingerprint

使用以下命令获取 CA 的 fingerprint：

openssl x509 -fingerprint -sha256 -in config/certs/http_ca.crt

如果你有中间证书，建议使用顶层根 CA。

如果证书 fingerprint 在握手过程中出现在证书链的任何位置，则握手会正常继续。

选项 2：高级 YAML 配置

对于高级设置，你有多种方式可以指定应该使用哪个 CA。

有关配置 CA 信任时允许使用的选项，请参考 Fleet output settings 和 Fleet secure connections 页面，了解配置 CA 信任时支持的详细选项。(elastic.co)

证书架构注意事项

每个 Elastic 组件都需要自己的 TLS 证书，包括：

• Elasticsearch

• Kibana

• Fleet Server

即使服务部署在反向代理或负载均衡器之后，这一要求仍然适用。

Elastic 强制采用这种模型，以：

• 保护传输中的数据

• 确保服务之间的安全通信

• 支持不依赖外部代理或负载均衡器的部署方式

在隔离网络和断开连接环境中运行 Elastic 的下一步

由于 Elastic 在隔离网络和断开连接环境中可以完全正常运行，组织可以在连接网络和非连接网络中部署相同的搜索、Security 和可观测性平台。

因此，组织可以：

• 降低运营复杂性

• 减少工具数量过多带来的管理负担

• 在不同环境中保持一致的工作流、检测规则和分析能力

通过支持安全的本地优先架构，同时不牺牲功能，Elastic 为任务关键型和受监管环境提供了独特优势。

要进一步了解 Elastic 在这些受限环境中可以为你的组织提供哪些能力，请联系我们的团队。

本文中描述的任何功能或特性的发布以及发布时间均由 Elastic 自行决定。任何当前尚未提供的功能或特性可能不会按计划交付，甚至可能不会交付。

原文：Elastic is fully operational in air-gapped and disconnected networks | Elastic Blog