现在开始，内生安全到AI安全--第一步
图里堆叠了大量的 Anti-DDoS、NGFW、NIPS、物理 WAF、SSL 卸载、堡垒机、上网行为管理以及沙箱检测。这些外挂盒子的最大痛点在于：它们全是在网络边界或特定网段实施“外挂式”拦截，对业务系统内部的底层微观行为缺乏任何“自适应上下文可见性”。
第一步的任务，是在完全不改变现有网络拓扑（图中的办公网、核心网、业务网架构）的前提下，通过对现有 IT 资产、网络流量、系统内核以及应用行为实施“内核级下沉微观遥测”。这是从外挂防御走向内生免疫、最终向 AI 安全进化的绝对地基。没有全网标准化、高精度、具备业务上下文的清洁数据，后续任何微隔离、可信链甚至 AI 智能化大脑都将成为空中楼阁。
1. 资产与拓扑层面的纯技术改造：消除“影子资产”与建立原生拓扑可见性
在现有的传统网络结构中，运维通过漏洞扫描器、传统资产管理系统（基于 ICMP/SNMP 探测）来维护资产。这种方式存在致命的微观盲区：无法感知到 K8s 内部容器微服务的动态漂移，也无法感知到未备案的应用端口（影子资产）。
1.1 eBPF（Extended Berkeley Packet Filter）内核级探针在 Linux（EulerOS/CentOS/Ubuntu）主机的全量部署与配置
为了获取最底层的原生可见性，必须废除传统的用户态资产抓取脚本，全面在业务网的核心服务器、数据库服务器以及办公网的辅助系统（如图中的 AD 域控、DLP 服务器）底层部署基于 eBPF 的轻量级内核遥测探针（如基于 Cilium Tetragon 或 Tetragon 原生内核探针）。
1. 内核版本验证与编译环境准备
eBPF 探针要求 Linux 内核版本必须在 5.4 及以上（以支持 BTF - BPF Type Format），如果企业采用的是国产 EulerOS 2.x 或信创基础 OS，需先验证内核 BPF 编译选项。执行以下命令确保内核支持：
Bash
# 检查内核是否开启了 BPF 支持以及 BTF 开启情况
zcat /proc/config.gz | grep CONFIG_BPF
grep CONFIG_DEBUG_INFO_BTF /boot/config-$(uname -r)
若返回 CONFIG_DEBUG_INFO_BTF=y，则说明内核支持免头文件编译的 eBPF 运行。
2. 编写 eBPF 资产监听内核态代码（asset_tracker.bpf.c）
通过监听内核的 sys_enter_execve 和 sys_enter_bind 系统调用，实时捕捉任何新进程的启动和任意网络端口的绑定行为，从而做到无盲区资产感知：
C
#include <vmlinux.h>
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_core_read.h>
char LICENSE[] SEC("license") = "GPL";
// 定义传输给用户态的数据结构
struct asset_event {
u32 pid;
u32 ppid;
u32 uid;
char comm[16];
char filename[256];
u16 local_port;
};
struct {
__uint(type, BPF_MAP_TYPE_PERF_EVENT_ARRAY);
__uint(key_size, sizeof(u32));
__uint(value_size, sizeof(u32));
} asset_events SEC(".maps");
// 拦截系统绑定端口事件 (sys_enter_bind)
SEC("tracepoint/syscalls/sys_enter_bind")
int trace_sys_bind(struct trace_event_raw_sys_enter *ctx) {
struct sockaddr *addr;
addr = (struct sockaddr *)BPF_GD_ARG(ctx, 1); // 获取 bind 的第二个参数：sockaddr 结构体指针
struct asset_event event = {};
event.pid = bpf_get_current_pid_tgid() >> 32;
bpf_get_current_comm(&event.comm, sizeof(event.comm));
// 读取端口信息 (仅处理 IPv4)
u16 sin_port;
bpf_probe_read_kernel(&sin_port, sizeof(sin_port), &addr->sa_data[0]);
event.local_port = __bpf_ntohs(sin_port);
// 推送到用户态
bpf_perf_event_output(ctx, &asset_events, BPF_F_CURRENT_CPU, &event, sizeof(event));
return 0;
}
3. 探针编译与加载控制
使用 Clang/LLVM 将上述内核态代码编译为 BPF 字节码，并通过 tc 或 bpftool 工具常驻加载至内核空间：
Bash
clang -g -O2 -target bpf -D__TARGET_ARCH_x86 -c asset_tracker.bpf.c -o asset_tracker.bpf.o
# 利用 bpftool 将其加载并固定在内核 BPF 文件系统中，实现重启常驻
bpftool prog load asset_tracker.bpf.o /sys/fs/bpf/asset_tracker
bpftool map pin id $(bpftool prog show pinned /sys/fs/bpf/asset_tracker | awk -F: '/map_ids/ {print $2}' | awk '{print $1}') /sys/fs/bpf/asset_map
1.2 Windows 主机（Windows Server / 办公网 PC）Windows Filtering Platform (WFP) 资产调用监控技术
由于办公网包含大量 Windows Server（如 AD、DLP，见图左侧办公网区域），无法运行 Linux eBPF，必须在 Windows 内核层部署开发 WFP（Windows 过滤平台） 驱动程序，通过内核回调函数，在底层进行资产调用与网络绑定的微观可见性审计。
1. 开发 WFP 核心分流驱动（WfpAssetTracker.sys）
在驱动初始化（DriverEntry）时，注册 FWPM_LAYER_ALE_AUTH_LISTEN_V4（应用层强制引擎-监听层）回调，实时捕获任何 Windows 进程企图建立网络监听的行为：
C
NTSTATUS WfpRegisterCallouts(_In_ PDEVICE_OBJECT deviceObject) {
FWPM_CALLOUT mCallout = { 0 };
FWPS_CALLOUT sCallout = { 0 };
NTSTATUS status = STATUS_SUCCESS;
// 1. 设置内核回调函数指针
sCallout.classifyFn = WfpAssetClassifyCallback;
sCallout.notifyFn = WfpAssetNotifyCallback;
sCallout.flowDeleteFn = NULL;
sCallout.calloutKey = GUID_CALLOUT_ASSET_TRACKER;
sCallout.flags = 0;
status = FwpsCalloutRegister(deviceObject, &sCallout, &g_CalloutId);
if (!NT_SUCCESS(status)) return status;
// 2. 将 Callout 注册到 WFP 引擎的 ALE 监听层
mCallout.calloutKey = GUID_CALLOUT_ASSET_TRACKER;
mCallout.displayData.name = L"Asset Tracker Callout";
mCallout.applicableLayer = GUID_LYR_ALE_AUTH_LISTEN_V4;
status = FwpmCalloutAdd(g_EngineHandle, &mCallout, NULL, NULL);
return status;
}
// 核心分类回调函数
void WfpAssetClassifyCallback(
const FWPS_INCOMING_VALUES0* inFixedValues,
const FWPS_INCOMING_METADATA_VALUES0* inMetaValues,
void* layerData,
const void* classifyContext,
const FWPS_FILTER0* filter,
UINT64 flowContext,
FWPS_CLASSIFY_OUT0* classifyOut
) {
// 提取进程的 PID 和本地绑定端口
UINT32 pid = (UINT32)inMetaValues->processId;
UINT16 localPort = inFixedValues->incomingValue[FWPS_FIELD_ALE_AUTH_LISTEN_V4_IP_LOCAL_PORT].value.uint16;
// 将 PID 和 Port 发送给用户态守护进程进行资产测绘记录
WfpLogAssetEvent(pid, localPort);
// 不做拦截，仅做可见性审计
classifyOut->actionType = FWP_ACTION_CONTINUE;
}
2. 驱动签名与强制定向加载
在信创及高版本 Windows 运行环境中，驱动必须通过企业内部根证书进行测试签名（开启 TESTSIGNING）或者通过国产信创签名证书。使用 sc 命令将其固化为系统核心服务，确保开机在网络堆栈初始化前启动：
DOS
sc create WfpAssetTracker type= kernel start= boot binPath= "C:\Windows\System32\drivers\WfpAssetTracker.sys"
sc start WfpAssetTracker
2. 流量层面的纯技术改造：全加密网络流量的“全空时”无损解包与元数据提取
从图上看，核心网与业务网之间串联了 SSL 卸载设备（SSL），且当前的业务流量 99% 已经全面转向 TLS 1.3 / HTTP/3。传统的 NIPS、全流量监测/IDS（见右下角检测控制区）挂在交换机镜像口上，面对加密流量完全变成了睁眼瞎。
必须通过“内核空间密钥导出 + 硬件加速分布式流量解包”，实现对全网加密流量的微观可见性改造。
2.1 基于 eBPF uprobe 实时捕获 OpenSSL / BoringSSL / 国密 GMSSL 内存密钥
由于 TLS 1.3 引入了前向安全性（Forward Secrecy），传统的在物理 SSL 卸载盒子上导入服务器私钥的被动旁路监听方案彻底失效。我们必须通过内核 uprobe 技术，在业务主机内存中，当 OpenSSL 握手计算出 Master Secret 后，直接将其导出。
1. 寻找 OpenSSL 符号表中的核心密钥生成函数
在 Linux 主机上定位业务系统（如 Nginx、Java 应用、国密网关）所链接的 libssl.so 的符号表：
Bash
objdump -T /usr/lib64/libssl.so | grep SSL_CTX_set_keylog_callback
# 或者直接挂载 uprobe 到 ssl_log_master_secret 函数
2. 编写 eBPF uprobe 字节码（tls_key_extractor.c）
C
#include <uapi/linux/ptrace.h>
SEC("uprobe//usr/lib64/libssl.so:ssl_log_master_secret")
int probe_ssl_master_secret(struct pt_regs *ctx) {
void *ssl = (void *)PT_REGS_PARM1(ctx);
void *client_random = (void *)PT_REGS_PARM2(ctx);
void *master_key = (void *)PT_REGS_PARM3(ctx);
char keylog_line[128] = "CLIENT_RANDOM ";
char rand_hex[64];
char key_hex[96];
// 从内存空间中读取 Client Random (32字节)
bpf_probe_read_user(&rand_hex, 32, client_random);
// 从内存空间中读取 Master Key (48字节)
bpf_probe_read_user(&key_hex, 48, master_key);
// 格式化输出为标准的 NSS Key Log 格式，并推送到用户态
// 用户态守护进程将其追加写入到本地本地内存文件 /dev/shm/tls_keys.log
return 0;
}
2.2 交换机侧物理镜像流量与主机侧虚拟分布式抓包的架构融合
在网络层面，图中的“全流量监测/IDS”通常只能接收来自核心交换机的物理镜像端口（SPAN）流量。但在东向流量（VM 与 VM、容器与容器之间，不经过物理交换机）中存在盲区。
1. 主机侧：基于 eBPF XDP（eXpress Data Path）的高性能轻量化网络遥测
在每台宿主机（KVM 物理机）的网卡驱动层（XDP）挂载流量采样探针。XDP 运行在网卡驱动的最早期，网络报文甚至还没进入 Linux 协议栈（SKB 尚未建立），此时进行报文头和元数据提取，CPU 损耗接近于零。
C
SEC("xdp")
int xdp_flow_telemetry(struct xdp_md *ctx) {
void *data_end = (void *)(long)ctx->data_end;
void *data = (void *)(long)ctx->data;
struct ethhdr *eth = data;
if ((void *)(eth + 1) > data_end) return XDP_PASS;
if (eth->h_proto == __bpf_htons(ETH_P_IP)) {
struct iphdr *ip = (void *)(eth + 1);
if ((void *)(ip + 1) > data_end) return XDP_PASS;
// 提取 5 元组元数据：源IP、目的IP、协议
u32 src_ip = ip->saddr;
u32 dst_ip = ip->daddr;
u8 protocol = ip->protocol;
// 将基础 5 元组流信息实时打上时间戳，直接写入 BPF 环形缓冲区（Ring Buffer）
}
return XDP_PASS; // 保持原有流量继续转发，100% 零干扰业务
}
2. 解密集群侧：将镜像物理大流量与主机侧导出的动态密钥进行线速（Line-Rate）实时合流解包
在全流量监测/IDS 设备前端，部署开源高性能网络流量分析引擎 Zeek（Bro） 或 Suricata 集群。配置用户态分布式管道，将主机侧通过 eBPF 动态吐出的 /dev/shm/tls_keys.log 通过加密隧道（WireGuard）汇聚到 Zeek 集群的解密目录中。
配置 Zeek 的 tls-client-random 密钥跟踪加载模块：
代码段
# zeek_init 脚本中配置实时加载外部导出的 Keylog 动态解密
redef TLS::secret_log_file = "/var/log/remote_tls_keys.log";
event ssl_extension(c: connection, is_orig: bool, code: count, val: string) {
# 当检测到加密流时，Zeek 会自动匹配内存中的 client_random 进行线速实时解密
}
通过该改造，原图中原本无法审计的加密业务流量（Web 应用防火墙 WAF 之后的内网二次流、数据库审计之前的加密连接），在全流量监测引擎中被彻底还原为明文的明细应用层语义（HTTP Request Body、SQL 原始语句）。
3. 应用层与 API 维度的纯技术改造：融入底座的 RASP 运行时自防护感知构建
回到原图的业务网（右侧），针对 Web 业务，传统做法是在前端挂载物理 WAF。黑客利用语义混淆、多重 URL 编码或者混淆过的 SQL 盲注，可以轻易绕过物理 WAF 的正则规则。必须将安全可见性直接延伸到代码的运行时，构建 RASP（Runtime Application Self-Protection） 级别的微观感知。
3.1 Java 核心业务系统（如企业 ERP、中间件）底层 JVM Bytecode Instrumentation 改造
针对全网的 Java 业务系统，在 JVM 启动参数中强行注入一个自研的 SecurityAgent.jar，通过 Java 字节码插桩技术，在核心敏感类和方法（如数据库执行、系统命令调用、文件读取）的入口处死死卡住可见性边界。
1. 配置 JVM 启动参数强制下沉 Agent
修改所有业务系统的 Tomcat/SpringBoot 启动脚本或 K8s 容器编排文件：
Bash
export JAVA_OPTS="-javaagent:/opt/agent/SecurityAgent.jar -Drasp.config=/opt/agent/config.properties $JAVA_OPTS"
2. 开发底层字节码插桩重塑类（RaspClassTransformer.java）
利用 Byte Buddy 或 ASM 字节码操纵框架，动态拦截 java.lang.ProcessBuilder（执行系统命令）和 java.sql.Statement（数据库操作）的底层实现方法：
Java
import net.bytebuddy.agent.builder.AgentBuilder;
import net.bytebuddy.asm.Advice;
import net.bytebuddy.matcher.ElementMatchers;
public class RaspAgent {
public static void premain(String agentArgs, Instrumentation inst) {
new AgentBuilder.Default()
.type(ElementMatchers.nameExactly("java.lang.ProcessBuilder"))
.transform((builder, typeDescription, classLoader, module) ->
builder.method(ElementMatchers.named("start"))
.intercept(Advice.to(ProcessBuilderAdvice.class))
).installOn(inst);
}
}
// 编写切面通知类，提取最深层的上下文语义
public class ProcessBuilderAdvice {
@Advice.OnMethodEnter
public static void onEnter(@Advice.FieldValue("command") List<String> command) {
// 1. 此时黑客无论在外部如何做编码混淆，传进 JVM 底层的方法参数必须是真实的明文系统命令
String fullCommand = String.join(" ", command);
// 2. 提取当前线程的高精度上下文
String stackTrace = StackTraceUtil.captureCurrentStack();
String currentUser = System.getProperty("user.name");
// 3. 将这些极其珍贵的应用内生微观数据，通过异步日志环形队列（Disruptor）推送到本地的可见性汇聚层
RaspTelemetryLogger.logEvent("EXEC_CMD", fullCommand, stackTrace, currentUser);
}
}
3.2 信创国产化 PHP/Python 应用底层 C 语言级别扩展（Extensions）下沉监控
针对非 Java 应用，传统的物理 WAF 和 HIDS 同样难以感知应用层内部变量流向。必须在 PHP/Python 运行时引擎层开发底层 C 扩展。
以 PHP 信创环境为例，开发 sec_tracker.so 内核扩展，挂钩（Hook）全局执行函数指针 zend_execute_internal：
C
#include "php.h"
#include "zend_extensions.h"
// 保存原有的 zend_execute_internal 指针
void (*orig_execute_internal)(zend_execute_data *execute_data, zval *return_value);
void sec_execute_internal(zend_execute_data *execute_data, zval *return_value) {
zend_function *func = execute_data->func;
if (func->common.function_name && strcmp(ZSTR_VAL(func->common.function_name), "system") == 0) {
// 捕获 system() 函数执行时的最原始 C 语言级别入参
zval *args = ZEND_CALL_ARG(execute_data, 1);
if (Z_TYPE_P(args) == IS_STRING) {
char *cmd = Z_STRVAL_P(args);
// 实时上报明文应用命令变量
LogPhpCommandTelemetry(cmd);
}
}
// 恢复正常执行链路，100% 确保业务无感知、零中断
if (orig_execute_internal) {
orig_execute_internal(execute_data, return_value);
} else {
execute_internal(execute_data, return_value);
}
}
PHP_MINIT_FUNCTION(sec_tracker) {
orig_execute_internal = zend_execute_internal;
zend_execute_internal = sec_execute_internal; // 强行替换为安全审计函数指针
return SUCCESS;
}
通过将 RASP 能力无缝植入应用的生命周期内部，我们在第一步就实现了：黑客哪怕通过未知 0-day 漏洞进来了，他在应用层内部触发的任何内存变量异动、任何数据库查询，都无处遁形。
4. 身份与特权访问层面的纯技术改造：打通物理身份与网络/内核主体的“血脉关联”
看图中的左侧办公网和右下角的检测控制区，身份系统主要是 AD 域（Active Directory），而管理运维主要依赖堡垒机。但在传统安全架构中，身份系统和网络流/内核流是完全脱节的。
运维痛点： 全流量监测/IDS 发现了一个恶性的内网勒索横向移动行为，源 IP 是
192.168.10.45。运维去查资产表，只能查到这是一台普通的办公 PC，但根本不知道此刻是谁登录了这台设备、用什么域账号在操作。
必须将物理身份（AD/信创 LDAP）与系统内核进程属主（UID）、网络 Socket 属主进行动态血脉关联。
4.1 AD 域控与全网主机轻量级身份映射同步机制（Identity-Process Connector）
在办公网核心 AD 域控服务器上部署 Windows 核心安全事件日志（Security Event Log）流式监听 Agent。
1. 监听 4624（登录成功）事件
利用 Windows 的 EVT 架构，过滤并提取 TargetUserName（登录账号名）、IpAddress（客户端真实 IP）以及 TargetLogonId。
PowerShell
# 通过 PowerShell 流式监听域控 4624 登录事件并实时推送到集中映射缓存
$query = "*[System[EventID=4624] and EventData[Data[@Name='LogonType']='3']]" # 类型3：网络登录
Register-ObjectEvent -InputObject $(Get-WinEvent -FilterXml $query -MaxEvents 1) -EventName ...
2. 建立本地内存数据库（Redis / SHM 共享内存）高并发身份-网络映射表
在第一步的汇聚层，维护一张秒级过期的全局高动态身份映射基表：
| 物理源 IP | 登录域账号 | 登录时间戳 | 关联设备主机名 |
192.168.10.45 |
zhangsan_hr |
1716132000 |
DESKTOP-HR-01 |
192.168.20.12 |
admin_wang |
1716132005 |
SERVER-ERP-DB |
4.2 结合 Linux 内核审计（Auditd/eBPF）将进程绑定至绝对身份
在业务服务器和堡垒机侧，利用 eBPF 的 bpf_get_current_uid_gid() 内核辅助函数，把当前网络连接对应的 Linux 进程，往上追溯到其真正的物理操作人。
C
SEC("kprobe/sys_connect")
int trace_connect_identity(struct pt_regs *ctx) {
u64 uid_gid = bpf_get_current_uid_gid();
u32 uid = uid_gid; // 获取当前触发网络连接的 Linux 系统底层 UID
char comm[16];
bpf_get_current_comm(&comm, sizeof(comm));
// 根据系统的 /etc/passwd 映射或者堡垒机下发的环境变量身份标签
// 将该网络连接（源Port -> 目的IP:目的Port）与真实的自然人名字彻底焊死在一块
return 0;
}
完成这项技术改造后，全网的任何一笔流量、任何一次内核调用，不仅有 IP 和 MAC 地址，更被打上了【张三 - HR部门 - 权限级别Low】这样的高维度身份标签。这为后续第七步 AI 安全大脑进行多模态语义学习提供了无可替代的“人肉实体标签”。
5. 数据融合与管道层面的纯技术改造：全量标准化清洁数据中台（Data Fabric）构建
完成了上述四大维度的内核下沉改造后，全网每天会产生数百 GB 甚至数 TB 的高精度可见性遥测流（eBPF 资产日志、WFP 绑定事件、解密后的 Zeek 流量元数据、RASP 运行时变量流、身份映射流）。
传统的 SIEM / 日志审计大屏（见左下角安全审计区）面对这种海量高并发数据，由于采用传统的结构化数据库或遗留的单机版 Elasticsearch，必然发生写入雪崩、严重丢包和索引断裂。必须彻底废除遗留 SIEM，使用分布式架构重写全量标准化清洁数据中台。
5.1 构建基于高性能 Ring-Buffer 与 Apache Kafka 的无损高并发吞吐数据管道
在每台生成探针的主机上，eBPF 和 RASP 产生的数据通过零拷贝（Zero-Copy）的 BPF Ring Buffer 抛到用户态守护进程，直接无缝对接高性能流式传输组件 Vector，强制打上企业统一的高精度 RFC 3339 纳秒级时间戳，源源不断地压入本地部署的 Kafka 信创集群。
1. 规范所有端侧探针的数据输出为严格的云原生统一标准格式（OpenTelemetry / ECS 规范）
严禁各个安全探针乱写日志格式。下层上报的任何数据必须强行格式化为如下标准的 JSON Schema：
JSON
{
"@timestamp": "2026-05-19T23:11:59.000123456Z",
"telemetry.source": "ebpf_kernel",
"host.ip": "192.168.20.12",
"host.name": "EulerOS-ERP-DB01",
"user.domain_name": "admin_wang",
"process.pid": 4125,
"process.name": "java",
"process.executable": "/usr/bin/java",
"network.transport": "tcp",
"network.direction": "egress",
"network.source.port": 45218,
"network.destination.ip": "10.10.50.66",
"network.destination.port": 3306,
"event.category": "database_access",
"event.action": "sql_query",
"payload.cleartext": "SELECT credit_card_num FROM user_info WHERE id = 1"
}
2. Kafka 高吞吐主题分区（Partition）拓扑调优
针对安全大数据的海量、无序性，重新调整生产环境的 Kafka 集群物理拓扑参数，防止背压（Backpressure）导致端侧主机内存暴涨：
Bash
# 创建统一的安全遥测清洁数据主题，根据信创算力集群核数，配置 24 个物理分区，保持 3 副本高可用
kafka-topics.sh --create --bootstrap-server 192.168.30.5:9092 \
--topic enterprise-security-telemetry-clean \
--partitions 24 \
--replication-factor 3 \
--config compression.type=zstd \
--config retention.ms=2592000000 # 本地硬盘严格强制留存 30 天清洁原始数据
5.2 构建基于 ClickHouse 向量化列式存储的底层高性能可见性数仓
放弃传统的行式数据库，部署纯本地信创化的高性能列式存储数据库 ClickHouse 作为可见性大底座。ClickHouse 凭借强大的向量化执行引擎（SIMD），可以在极低的算力开销下，实现每秒数亿条数据的实时聚合和多维关联查询。
1. 设计支持海量并发安全遥测的高速合并树表结构（MergeTree）
SQL
CREATE DATABASE IF NOT EXISTS native_security_visibility;
CREATE TABLE native_security_visibility.telemetry_stream_local ON CLUSTER sharded_cluster
(
timestamp DateTime64(9, 'UTC'),
telemetry_source LowCardinality(String),
host_ip UInt32,
host_name LowCardinality(String),
user_domain LowCardinality(String),
process_pid UInt32,
process_name String,
dest_ip UInt32,
dest_port UInt16,
event_category LowCardinality(String),
payload String
)
ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/telemetry_stream_local', '{replica}')
PARTITION BY toYYYYMMDD(timestamp)
ORDER BY (event_category, telemetry_source, host_ip, timestamp)
SETTINGS index_granularity = 8192;
2. 配置无缝流式消费管道（Kafka Engine -> Materialized View -> MergeTree）
在 ClickHouse 内部建立物化视图，使其自动、实时地将 Kafka 管道内源源不断涌入的全网清洁数据吞入列式存储中，中间完全不经过任何应用层代码中转，效率达到物理极限：
SQL
-- 1. 建立 Kafka 引擎消费表
CREATE TABLE native_security_visibility.kafka_queue
(
json_data String
)
ENGINE = Kafka
SETTINGS kafka_bootstrap_servers = '192.168.30.5:9092',
kafka_topic_list = 'enterprise-security-telemetry-clean',
kafka_group_name = 'ch_consumers',
kafka_format = 'JSONAsString';
-- 2. 建立物化视图，动态解析并抽取 JSON 字段到最终物理表
CREATE MATERIALIZED VIEW native_security_visibility.mv_telemetry_consumer
TO native_security_visibility.telemetry_stream_local AS
SELECT
JSONExtractFloat(json_data, 'timestamp') AS timestamp,
JSONExtractString(json_data, 'telemetry.source') AS telemetry_source,
IPv4StringToNum(JSONExtractString(json_data, 'host.ip')) AS host_ip,
JSONExtractString(json_data, 'host.name') AS host_name,
JSONExtractString(json_data, 'user.domain_name') AS user_domain,
JSONExtractUInt(json_data, 'process.pid') AS process_pid,
JSONExtractString(json_data, 'process.name') AS process_name,
IPv4StringToNum(JSONExtractString(json_data, 'network.destination.ip')) AS dest_ip,
JSONExtractUInt(json_data, 'network.destination.port') AS dest_port,
JSONExtractString(json_data, 'event.category') AS event_category,
JSONExtractString(json_data, 'payload.cleartext') AS payload
FROM native_security_visibility.kafka_queue;
6. 第一步阶段性技术改造完工验证与微观指标判定
至此，“现在开始，内生安全到AI安全--第一步”的纯技术改造已全盘落地完毕。此时，回到我们眼前的企业拓扑图，整座大厦的底层已经发生了翻天覆地的变化。
运维桌上的安全大屏，不再是那些外挂盒子报上来的毫无关联、充满误报的“垃圾告警风暴”，而是可以通过一条
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
6
0- 0
已为社区贡献4条内容
所有评论(0)