Linux 인프라 지식 그래프(Knowledge Graph) 온톨로지 아키텍처 설계

리눅스 서버의 설정, 프로세스, 포트, 서비스 상태, 계정, 네트워크, 패키지, 보안설정 등을 지속적으로 수집하고 이를 “온톨로지(Ontology)” 형태로 구성하면 단순 모니터링을 넘어 다음과 같은 수준까지 확장할 수 있습니다.

• 자산 관계 기반 분석
• 공격 경로 추적
• 구성 드리프트(Configuration Drift) 탐지
• 이상행위 탐지
• 보안 영향도 분석
• CMDB + 보안지식그래프(Security Knowledge Graph)
• AI 기반 질의/추론(RAG + Graph)

특히 보안 운영 조직에서는 단순 “수집”보다도

• 어떤 관계를 정의할 것인가
• 어떤 개체(Entity)를 기준으로 모델링할 것인가
• 어떤 변경을 추적할 것인가

가 핵심입니다.

300x250

아래와 같이 단계별로 접근하면 실무적으로 매우 효과적입니다.

전체 구조 개요

가장 추천되는 구조는 다음과 같습니다.

[Linux Server]
   ├─ Agent (osquery / wazuh / telegraf / custom)
   ├─ Script Collector
   └─ Event Stream

          ↓

[Collector/API/Kafka]

          ↓

[Normalizer]

          ↓

[Ontology / Knowledge Graph]
   ├─ Neo4j
   ├─ JanusGraph
   ├─ ArangoDB
   ├─ Elasticsearch + Graph
   └─ RDF Triple Store

          ↓

[Analysis]
   ├─ Security Analytics
   ├─ AI/RAG
   ├─ Attack Path
   ├─ Drift Detection
   └─ Visualization

실무적으로 아래 정도를 추천합니다.

시스템 기본정보

수집 대상

• hostname
• fqdn
• ip
• kernel version
• distro
• uptime
• timezone
• virtualization
• cloud metadata

예시

hostnamectl
uname -a
cat /etc/os-release
ip addr
uptime

프로세스 정보

핵심 이유

프로세스는 가장 중요한 “행위 객체”입니다.

프로세스를 기준으로

• 포트
• 파일
• 사용자
• 네트워크
• 권한
• 실행경로

등이 모두 연결됩니다.

수집 예시

ps -ef

또는

ps -eo pid,ppid,user,group,cmd,%cpu,%mem,lstart

중요한 필드

필드	설명
pid	프로세스 식별
ppid	부모 관계
exe	실행파일
cwd	작업디렉토리
user	실행 사용자
capabilities	권한
start_time	시작시간

포트 / 소켓

수집

ss -tunlp

또는

lsof -i -P -n

핵심 관계

Process -> LISTENS_ON -> Port
Port -> BOUND_TO -> IP

서비스(systemd)

systemctl list-units --type=service

systemctl show nginx

중요 이유

서비스 단위는 운영 기준 객체입니다.

• 서비스 상태
• 자동시작
• dependency
• restart 정책

등을 추적 가능.

계정 / 권한

수집

cat /etc/passwd
cat /etc/group
sudo -l
lastlog

관계

User -> MEMBER_OF -> Group
User -> RUNS -> Process
User -> HAS_SUDO -> Policy

네트워크

수집

ip route
iptables-save
nft list ruleset

중요 관계

Server -> CONNECTS_TO -> Server
Process -> CONNECTS_TO -> RemoteIP
FirewallRule -> ALLOWS -> Port

패키지

Debian

dpkg -l

RHEL

rpm -qa

관계

Package -> PROVIDES -> Binary
Package -> HAS_CVE -> Vulnerability

파일/설정

핵심 대상

• /etc
• systemd
• sshd_config
• sudoers
• nginx.conf
• kube config
• cron
• authorized_keys

해시 기반 추적

sha256sum

온톨로지 모델링 핵심

여기가 가장 중요합니다.

엔티티(Entity)

추천 엔티티

Entity	설명
Host	서버
Process	프로세스
User	사용자
Port	포트
Service	서비스
Package	패키지
File	파일
Connection	네트워크 연결
Vulnerability	취약점
Policy	정책

관계(Relationship)

예시

Host RUNS Process
Process LISTENS_ON Port
Process CONNECTS_TO IP
User OWNS File
Service STARTS Process
Package INSTALLS Binary
Binary EXECUTES Process

실제 그래프 예시

[Host:web01]
   ├── RUNS → [Process:nginx]
   │              ├── LISTENS_ON → [Port:443]
   │              ├── EXECUTES → [/usr/sbin/nginx]
   │              └── CONNECTS_TO → [Redis]
   │
   └── HAS_USER → [www-data]

가장 추천 (실무형)

osquery + Neo4j

가장 강력합니다.

장점

• SQL 기반 수집
• 프로세스/포트/패키지 강력
• 확장 쉬움
• 스케줄링 가능

osquery 예시

포트+프로세스 관계

SELECT
  p.pid,
  p.name,
  s.local_port,
  s.remote_address
FROM processes p
JOIN process_open_sockets s
ON p.pid = s.pid;

보안 운영형

Wazuh + Elasticsearch + Graph

장점

• 이미 보안관제 친화적
• SCA 가능
• FIM 가능
• 정책기반 분석 가능

단점

• 온톨로지 자체는 약함

→ Graph 확장 필요.

대규모 지식그래프형

Neo4j

가장 추천.

이유

보안 관계 표현에 매우 적합.

예시

MATCH (p:Process)-[:LISTENS_ON]->(port:Port)
WHERE port.number = 22
RETURN p

RDF/OWL 기반

Apache Jena

Stardog

시맨틱 웹/정식 온톨로지 필요시.

하지만 운영 난이도 높음.

추천하는 데이터 모델

Host 중심 모델

Host
 ├─ Process
 ├─ User
 ├─ Service
 ├─ Port
 ├─ File
 └─ Package

Time-Series 분리

매우 중요합니다.

정적 데이터와 동적 데이터를 분리해야 합니다.

유형	저장소
현재 상태	Graph
시계열	Elasticsearch
이벤트	Kafka
변경이력	Object Storage

보안 관점 핵심 포인트

Drift Detection

예시

• 갑자기 SSH 포트 변경
• 신규 프로세스 등장
• sudo 권한 추가
• 비인가 서비스 실행

공격 경로 분석

예시

Nginx
 → Redis
 → Local Socket
 → Root Process

Living Off The Land 탐지

관계 기반 분석 가능.

bash
 → curl
 → python
 → nc

Shadow IT 탐지

예시

• 비인가 docker
• 비인가 nodejs
• 임의 reverse proxy

AI + Ontology 활용

여기가 앞으로 매우 중요합니다.

자연어 질의

예시

"외부와 연결된 root 프로세스 보여줘"

→ Graph Query 자동 변환.

RAG 기반 보안 분석

Host
 + Process
 + CVE
 + Config
 + Traffic

통합 기반 분석 가능.

추천 실전 아키텍처

개인적으로 가장 추천하는 구조

osquery
   ↓
Kafka
   ↓
Normalizer
   ↓
Neo4j
   ↓
LLM/RAG

보조

Wazuh
Elasticsearch
Prometheus
Grafana

수집 자동화 추천

osquery schedule

{
  "schedule": {
    "processes": {
      "query": "SELECT * FROM processes;",
      "interval": 300
    }
  }
}

변경 감지

SELECT * FROM listening_ports;

변화 발생시

• Kafka 전송
• Slack
• SIEM
• Graph Update

추천 구현 단계

1단계

기본 Host/Process/Port 수집

추천

• osquery
• Elasticsearch

2단계

관계형 모델링

추천

• Neo4j

3단계

보안 이벤트 연계

추천

• Wazuh
• Sigma
• Detection Rule

4단계

AI 질의/분석

추천

• LangChain
• GraphRAG
• MCP Agent

개인적으로 추천하는 방향

사용자 환경 기준으로는 아래 조합이 특히 강력합니다.

osquery
+ Wazuh
+ Kafka
+ Neo4j
+ Elasticsearch
+ n8n
+ AI Agent

이 구조면

• 서버 상태 수집
• 관계 분석
• 정책 위반 탐지
• 자동 대응
• AI 질의
• 공격 경로 분석

까지 모두 가능합니다.