보안 지식그래프 데이터 모델링 구축 SPARQL로 묻고 Neo4j로 분석

🛡️ 정책을 ‘추론 가능하게’ 만들기: OWL·Reasoner·그래프DB 적용 전략

🧭 Vocabulary → Policy → Detection: 온톨로지 기반 보안 운영 체계

📚 조직의 공통 언어 만들기: Vocabulary Ontology 실전 설계와 활용

핵심 흐름 전체 큰 그림 한 장으로 보기

1. OWL 파일

• “의미(semantic)와 관계(relationship), 제약(constraint)”을 표준 형식으로 정의하는 온톨로지 파일

2. Protégé(프로테지)

• OWL을 GUI로 설계/편집/검증(Reasoner) 하는 대표 툴

3. Vocabulary Ontology

• 조직이 공통으로 쓰는 “용어의 의미와 관계”를 표준화하는 뼈대
• (정책/탐지/자동화가 흔들리지 않게 만드는 기준어)

4. SPARQL(스파클)

• RDF/OWL 기반의 그래프 지식을 질의/분석하는 표준 쿼리 언어
• “관계 패턴 매칭”이 핵심

5. GraphDB/Neo4j로 표현·서치·분석

• 위 개념들을 더 “운영 친화적인 그래프DB”로 옮겨서
  • 표현(모델링) → 검색(패턴 질의) → 분석(커뮤니티/중심성/경로/유사도) 까지 수행

OWL 파일: “지식/정책의 설계도”

1. OWL의 역할(핵심)

OWL은 단순 데이터가 아니라,

• Class(개념): User, Host, Asset, Event, Vulnerability…
• Property(관계/속성): hasRole, canAccess, hasIPAddress…
• Restriction(제약): “반드시”, “오직”, “최대/최소 개수” 같은 규칙
• Reasoning(추론): 상속/동치/모순을 자동으로 판단

을 통해 기계가 이해/추론 가능한 ‘의미 모델’을 담습니다.

2. 보안 관점 핵심 메시지

• OWL은 “문서”가 아니라 정책/논리 정의물
• 무결성 훼손 = 정책 왜곡/탐지 누락/과다 허용으로 직결 가능

보안 점검 포인트(OWL 자체)

• 변경 이력 관리(Git), 해시/서명으로 무결성 관리
• 수동 편집 금지(툴 기반 + 리뷰)
• 외부 Import(다른 ontology 참조) 신뢰성 검증

Protégé: OWL을 제대로 다루는 표준 작업대

1. Protégé가 하는 일

• OWL/RDF를 시각적으로 설계
• Classes/Properties/Individuals(인스턴스) 관리
• Reasoner(HermiT/Pellet/ELK 등)로 논리 검증/자동 분류

2. 기본 사용 흐름(실무형)

1. Ontology 생성(IRI 설정)
2. Classes 설계(상속 구조)
3. Object/Data Properties 정의(Domain/Range 포함)
4. Restriction 설정(정책/제약)
5. Reasoner 실행(모순/충돌/추론 결과 확인)
6. 저장(.owl)

3. 내부에 제시할 가이드(Protégé 운영)

• “Protégé는 편집기가 아니라 검증 도구”
• 운영 반영 전 필수
  • Reasoner 실행 결과 “충돌 0”
  • 변경 영향도(상속/관계/제약 변화) 확인
  • 리뷰/승인 프로세스(정책 변경과 동일 레벨)

Vocabulary Ontology: 조직의 “공통 언어”

1. 왜 중요한가

같은 단어가 시스템마다 다른 의미로 쓰이면,

• 탐지/분석 기준이 흔들리고,
• 데이터 통합 시 오해석이 생기며,
• 정책 자동화가 깨집니다.

Vocabulary Ontology는

• “User, Asset, Event, Role…” 같은 용어의 정의
• 용어 간 관계(접근, 소유, 발생, 영향)
• 최소한의 제약(의미적 범위)

을 만들어 해석을 통일합니다.

2. Vocabulary vs (Full) Ontology

• Vocabulary: “용어를 정의하고 연결하는 최소 단위”
• Ontology: “그 위에 더 강한 제약/정책/추론까지 확장한 모델”

실무적으로는 권장 구조가 있습니다.

• Vocabulary Ontology: 의미 정의(기준)
• Policy Ontology: 규칙/제약(운영 정책)
• Detection Ontology(또는 Rule Layer): 탐지 룰/패턴

즉, 의미(기준)와 규칙(정책/탐지)을 분리하면 운영이 쉬워집니다.

3. 보안 관점 점검 체크

• 중복 용어(동일 의미 다른 이름) 존재 여부
• 같은 용어의 정의가 문서/시스템마다 다른지
• 관계 방향(누가 누구에 접근?) 일관성
• Vocabulary 변경 시 SPARQL/룰/분석 로직 영향도 평가

SPARQL: 그래프 지식(온톨로지)을 “질문”하는 언어

1. SPARQL의 본질

RDF/OWL은 트리플로 저장됩니다.

• (주어) - (관계) - (객체)

SPARQL은 이를 패턴 매칭으로 찾습니다.

2. 기본 문법 예시

1) 관계 조회(가장 기본)

SELECT ?user ?role
WHERE {
  ?user :hasRole ?role .
}

2) 특정 클래스의 인스턴스 조회

SELECT ?u
WHERE {
  ?u rdf:type :User .
}

3) 다단계 관계 탐색(그래프 쿼리 핵심)

SELECT ?user ?server
WHERE {
  ?user :hasRole :Admin .
  ?user :canAccess ?server .
  ?server rdf:type :Server .
}

4) 점수/조건 필터링

SELECT ?event
WHERE {
  ?event :riskScore ?score .
  FILTER (?score >= 80)
}

3. Reasoner + SPARQL이 중요한 이유

Reasoner 실행 후에는

• 상속(Admin ⊆ User)
• 동치/추론 결과
  가 반영된 상태로 SPARQL을 질의하게 되어,
  정책 검증(논리적 충돌 탐지) 정확도가 크게 올라갑니다.

4. 보안 활용 시나리오

• “외부 사용자가 내부 서버 접근 가능한 경로 존재?”
• “MFA 없는 접근이 가능한 자산/사용자 조합 존재?”
• “위험 점수 높은 이벤트가 특정 자산군에 집중?”

GraphDB/Neo4j: “표현 + 검색 + 분석”을 운영 친화적으로

1. 왜 Neo4j가 연결되는가

OWL/RDF는 표준 의미 모델에 강점이 있고,
Neo4j는 운영 환경에서

• 빠른 패턴 탐색
• 시각화/탐색 편의
• 그래프 분석(커뮤니티/경로/중심성)
• (환경에 따라) 벡터 유사도 검색 등 확장
  이 수월합니다.

즉,

• “의미 모델링(OWL)”을 기반으로
• “운영 분석(Neo4j)”로 이어지는 구조가 자주 나옵니다.

2. Neo4j 모델링(표현) 실무 가이드

• 노드: User, Host, IP, Process, Asset, Ticket, Vulnerability…
• 관계: LOGON, CONNECT, SPAWN, OWNS, AFFECTS, INDICATES…
• 속성: ts, src_ip, dst_port, hash, riskScore, cmdline…

예)

• (User)-[:LOGON {ts, method}]->(Host)
• (Host)-[:CONNECT {dst_port, proto, ts}]->(IP)
• (Process)-[:SPAWNED]->(Process)

300x250

핵심 포인트
“로그 1건을 그대로 넣는 저장소”가 아니라,
엔티티를 분리하고 관계로 연결할수록 탐지/분석이 강해집니다.

3. Cypher로 검색

• 패턴 매칭 기반
  • 1~2 hop: 단순 관계
  • 3 hop 이상: 침투 경로/횡적이동/연쇄 관계 탐지

예)

MATCH (u:User {id:$uid})-[r:LOGON]->(h:Host)
RETURN h.name, r.ts, r.method
ORDER BY r.ts DESC
LIMIT 50;

4. 그래프 분석

대표 축

• 커뮤니티 탐지: 비정상 집단/그룹화
• 중심성: 허브 계정/핵심 서버
• 경로 분석: lateral movement 후보 경로
• (옵션) 유사도 기반 군집화: 유사 cmdline/URL/사건 텍스트

5. 보안 운영 관점 점검 포인트(Neo4j/GraphDB)

• 데이터 무결성/중복 방지
  • 유일성 제약(예: userId, hostId, ip)
• 변경관리
  • 쿼리(Cypher/SPARQL)는 탐지 룰과 동일하게 취급
  • 리뷰/테스트/배포 승인 흐름 필요
• 민감정보 관리
  • Full-text/Vector 검색을 하게 되면 텍스트에 개인정보/자격증명 흔적이 섞일 수 있음
  • 마스킹/토큰화/접근권한/로그 감사 정책 필요
• 성능/비용 통제
  • 대규모 그래프 분석은 배치화/스케줄링/결과 캐시(속성 저장) 권장

실무 적용 추천 순서

조직에서 “온톨로지 + 그래프DB”를 보안 실무로 연결하려면, 현실적으로 아래 순서가 가장 안정적입니다.

1. Vocabulary Ontology 먼저

• 용어/관계 정의를 “합의”하고 표준화(가장 중요)

2. Protégé로 OWL 모델을 관리

• 변경관리/Reasoner 검증 체계 확립

3. SPARQL로 질의 패턴을 룰화

• 정책 검증/탐지 룰의 논리 기반 마련

4. 운영 분석이 필요하면 Neo4j로 확장

• 엔티티-관계 중심 적재
• Cypher 기반 탐색 + 그래프 분석 적용

보안팀용 “내부 배포 체크리스트” (요약본)

1. OWL/Vocabulary

• 용어 정의(의미) 문서와 OWL 일치
• 외부 Import 출처 검증
• 변경 이력 + 무결성(서명/해시) 확보

2. Protégé 운영

• 운영 반영 전 Reasoner 오류 0
• Restriction 변경 영향도 평가
• 리뷰/승인/배포 절차 존재

3. SPARQL/Cypher(룰/쿼리)

• 쿼리는 “탐지 룰”로 관리(형상/승인/테스트)
• 권한/접근통제(쿼리 실행 주체 제한)
• 결과 기반 자동조치 시 휴먼 게이트/안전장치

4. GraphDB(Neo4j)

• 유일성 제약/중복 방지
• 민감정보 마스킹/토큰화 정책
• 분석 작업의 성능/비용 통제(배치/캐시)