26A03b

Young-Kyoo Kim·2026년 4월 3일

Context/ABAC 기반 접근 통제 타당성 검토

현재 구성 분석

도구	역할	ABAC 기여도
Wazuh	SIEM/EDR, 로그 수집·분석	간접적 (이벤트 탐지)
CrowdStrike Falcon	EDR/XDR, 엔드포인트 보호	제한적 (디바이스 컨텍스트)
Kubescape	K8s 보안 스캔/정책	K8s 범위 내 RBAC 강화

결론: 타당하나 도구 갭이 있음

세 도구 모두 탐지·모니터링 중심이라, AD/SSO 위에 진정한 ABAC/컨텍스트 통제를 구현하려면 Policy Engine + PEP(Policy Enforcement Point) 레이어가 별도로 필요합니다.

아키텍처 관점의 갭

[현재]
사용자 → AD/SSO(인증) → 리소스 접근
                          ↑ Wazuh/Falcon은 사후 탐지만

[목표]
사용자 → AD/SSO → [ABAC Policy Engine] → 리소스
                    ↑ 여기가 비어 있음
                    (디바이스 상태 + 위치 + 시간 + 역할 + 리소스 속성)

추가 권장 도구

🔐 Policy Engine / ABAC 핵심

1. Open Policy Agent (OPA)

업계 표준 ABAC 정책 엔진
Rego 언어로 사용자 속성 + 리소스 속성 + 환경 컨텍스트 조합 정책 작성
K8s(Gatekeeper), API Gateway, Envoy 등 어디에나 삽입 가능
Wazuh/Falcon의 컨텍스트를 정책 input으로 활용 가능

2. Styra DAS (OPA 상용 관리 플랫폼)

OPA를 엔터프라이즈 수준으로 중앙 관리
정책 버전 관리, 감사 로그, 대시보드 제공

🛡️ Zero Trust / 컨텍스트 인식 접근 통제

3. HashiCorp Boundary

세션별 동적 자격증명 + 컨텍스트 기반 접근
AD/SSO와 직접 연동, 접근 시점의 ID·디바이스·위치 검증

4. Pomerium / Teleport

BeyondCorp 모델의 오픈소스 프록시
요청마다 사용자 + 디바이스 상태 + 네트워크 재평가
Falcon의 Zero Trust Assessment 점수를 컨텍스트로 수신 가능

☸️ K8s 특화 (Kubescape 보완)

5. Kyverno

K8s 네이티브 정책 엔진 (OPA보다 간단한 YAML 문법)
Pod의 레이블/어노테이션 기반 ABAC, Admission Control
Kubescape 스캔 결과를 정책 기준으로 활용

통합 권장 아키텍처

AD/SSO (Entra ID / Okta)
    │
    ▼
[Pomerium / Teleport]  ← 디바이스 신뢰도 (Falcon ZTA 점수)
    │                  ← 위치/시간/네트워크 컨텍스트
    ▼
[OPA / Styra DAS]      ← 중앙 ABAC 정책 평가
    │                  ← Wazuh 이벤트 → 실시간 리스크 점수 반영
    ▼
리소스 (API / K8s / DB / 인프라)
    │
    ▼
[Kubescape + Kyverno]  ← K8s 레이어 ABAC 집행

핵심 판단

항목	평가
현재 구성의 탐지 역량	✅ 충분
진정한 ABAC 집행 역량	❌ OPA/Kyverno 없이는 부족
Falcon → 컨텍스트 소스 활용	✅ ZTA 점수를 OPA input으로 사용 가능
Wazuh → 실시간 리스크 반영	⚠️ 연동 커스텀 작업 필요
전체 방향성	✅ 타당함, OPA + Pomerium/Teleport 추가 권장

가장 현실적인 첫 단계는 OPA(Gatekeeper) + Kyverno로 K8s 레이어부터 ABAC를 구현하고, 이후 Pomerium으로 외부 접근 통제를 확장하는 순서를 추천합니다.

===

Kyverno 필요성 & Best Practice 재정리

Kyverno vs OPA Gatekeeper — 결론부터

둘 다 K8s Admission Control이라 중복입니다. OPA Gatekeeper만으로 충분합니다.

기능	OPA Gatekeeper	Kyverno
Admission Control (검증)	✅	✅
정책 변이(Mutation)	⚠️ 복잡	✅ 쉬움
리소스 자동 생성(Generate)	❌	✅
이미지 서명 검증	❌	✅
문법 난이도	Rego (어려움)	YAML (쉬움)

OPA 선택 이유: 이미 구축 중이고, K8s 외 API Gateway·Envoy·서비스메시까지 범용 정책 엔진으로 확장 가능. Kyverno는 K8s 전용이라 장기적으로 OPA가 더 넓게 커버합니다.

단, 이미지 서명 검증이 필요하면 Kyverno만 추가하거나, Sigstore/Cosign 단독 도입으로 대체 가능.

Best Practice 스택 재정리

┌─────────────────────────────────────────────┐
│           Identity / AuthN Layer            │
│         AD + SSO (Entra ID / Okta)          │  ← 현재 보유
└──────────────────────┬──────────────────────┘
                       │
┌──────────────────────▼──────────────────────┐
│        Zero Trust Proxy (컨텍스트 검증)       │
│              Pomerium or Teleport           │  ← 신규 추가 권장
│  사용자 + 디바이스 + 위치 + 시간 → 매 요청 재평가 │
└──────────────────────┬──────────────────────┘
                       │
┌──────────────────────▼──────────────────────┐
│         ABAC Policy Engine (정책 집행)        │
│                OPA + Gatekeeper             │  ← 구축 중
│     Falcon ZTA 점수 + Wazuh 리스크 → input   │
└──────────────────────┬──────────────────────┘
                       │
          ┌────────────┴────────────┐
          │                        │
┌─────────▼────────┐    ┌──────────▼──────────┐
│  K8s Workload    │    │  Non-K8s 리소스      │
│  Kubescape(스캔) │    │  HashiCorp Vault     │  ← 권장
│  Gatekeeper(집행)│    │  (동적 자격증명)      │
└─────────┬────────┘    └──────────┬──────────┘
          └────────────┬────────────┘
                       │
┌──────────────────────▼──────────────────────┐
│            Detection & Response             │
│         Wazuh (SIEM) + Falcon (EDR)         │  ← 현재 보유
└─────────────────────────────────────────────┘

최종 도구 목록

레이어	도구	상태
인증	AD/SSO	✅ 보유
디바이스 신뢰	CrowdStrike Falcon	✅ 보유
Zero Trust Proxy	Pomerium 또는 Teleport	🔲 추가 필요
ABAC 정책 엔진	OPA + Gatekeeper	🔨 구축 중
K8s 보안 스캔	Kubescape	✅ 보유
동적 자격증명	HashiCorp Vault	🔲 추가 권장
SIEM/탐지	Wazuh	✅ 보유
Kyverno	중복	❌ 불필요

Pomerium vs Teleport 선택 기준:

웹앱/API 접근 통제 중심 → Pomerium
SSH/K8s/DB 인프라 접근 중심 → Teleport

===

맞습니다. Pomerium/Teleport는 인증 결과를 받아서 프록시하는 역할이라, MFA 자체를 발급·관리하진 않아요.

MFA 레이어 구조

[MFA 발급/검증]          [컨텍스트 평가]        [접근 집행]
Okta / Entra ID   →    Pomerium/Teleport  →   OPA/리소스
(여기서 MFA 처리)        (신뢰 여부 판단)

실질적으로 필요한 구성

기능	담당 도구
MFA 발급 (TOTP/Push/FIDO2)	Okta / Entra ID MFA
하드웨어 키 (최강 수준)	YubiKey + FIDO2/WebAuthn
디바이스 인증서 기반 MFA	Entra ID + Intune (디바이스 등록)
특권계정 MFA 강화	CyberArk PAM 또는 BeyondTrust
SSO + Adaptive MFA	Okta + Okta ThreatInsight

Adaptive MFA가 핵심입니다

단순 MFA보다 컨텍스트 기반 Adaptive MFA가 ABAC 전략과 일치해요.

로그인 시도
    │
    ├─ 정상 컨텍스트 (알려진 디바이스 + 위치)  → MFA 스킵 또는 간소화
    ├─ 의심 컨텍스트 (새 위치 + 시간 이상)     → Push MFA 요구
    └─ 고위험 (Falcon 이상 탐지 + 해외 IP)    → 접근 차단 + 재인증

Okta ThreatInsight 또는 Entra ID 조건부 액세스가 이 역할을 담당
Falcon의 디바이스 리스크 점수를 Okta/Entra에 신호로 전달 가능

현실적인 추가 권장

현재 AD/SSO 기반이면:

Entra ID P2 (조건부 액세스 + MFA) — Microsoft 스택이면 가장 자연스러운 선택
YubiKey — 특권계정 및 관리자에 한해 하드웨어 MFA 추가
Okta 사용 중이면 Okta Verify + FastPass (FIDO2 기반 Passwordless까지 가능)

===

Pomerium vs Teleport 주요 기능

Pomerium — 웹앱/API 접근 프록시

"모든 요청을 신뢰하지 않고 매번 재검증"하는 BeyondCorp 모델

기능	내용
Identity-Aware Proxy	요청마다 사용자 ID + 컨텍스트 재검증
SSO 통합	Okta, Entra ID, Google 등 모든 OIDC/SAML 연동
정책 기반 접근	URL 단위로 `누가, 어디서, 언제` 접근 가능한지 정의
헤더 주입	인증된 사용자 정보를 앱에 헤더로 전달 (앱 자체 인증 불필요)
TCP 터널링	HTTP 외 DB, SSH도 프록시 가능

주 사용처: 내부 웹앱, 대시보드, API 게이트웨이, Kubernetes 대시보드

Teleport — 인프라 접근 제어 플랫폼

SSH/K8s/DB 등 인프라 리소스에 대한 Zero Trust 접근

기능	내용
SSH 접근 제어	키 관리 없이 SSO 기반 SSH, 세션 녹화
Kubernetes 접근	kubectl 명령 단위 감사 로그, 역할 기반 접근
DB 접근	PostgreSQL/MySQL/MongoDB 등 직접 접근 통제
세션 녹화/재생	모든 세션 영상+텍스트 기록, 감사 증적
Just-in-Time 접근	필요할 때만 임시 권한 부여 후 자동 회수
디바이스 신뢰	등록된 디바이스만 접근 허용

주 사용처: 서버 SSH, K8s 클러스터, 운영 DB, 인프라 관리

한 줄 정리

Pomerium  = 웹/API 앞단 게이트키퍼
Teleport  = 인프라(SSH·K8s·DB) 접근 통제탑

둘을 같이 쓰는 것이 Best Practice입니다.
웹앱은 Pomerium, 인프라는 Teleport로 레이어를 나누면 전체 접근 경로가 커버됩니다.

===

두 가지를 하나의 페이지로 만들겠습니다 — 아키텍처 다이어그램 + 탭별 모의 감사 증빙 자료.6개 탭으로 구성한 문서입니다.

① 아키텍처 — 현재 구성(Keycloak+AD+OPA+Polaris)에 Pomerium/Teleport, Vault를 어디에 끼워넣는지 레이어별로 표시

② OPA 정책 결정 로그 — ALLOW/DENY 이벤트, Rego 정책 샘플 포함

③ Keycloak 인증 로그 — 로그인/실패/잠금 이벤트, JWT 클레임 + OPA input 매핑

④ Polaris 스캔 리포트 — 워크로드별 보안 점수, DANGER/WARN 항목, 조치 권고

⑤ ABAC 접근 이력 — 컨텍스트(업무시간, MFA, 디바이스신뢰도) 포함 결정 JSON

⑥ 세션 감사 로그 — kubectl exec / SSH / DB 접근 이력, 특권 명령 이력

감사 제출용으로 쓰려면 실제 로그 데이터로 교체하고 문서번호/날짜/담당팀명만 수정하면 됩니다.

===

전체를 깔끔하게 다시 만들겠습니다.전면 재작성했습니다. 변경 사항은 두 가지입니다.

탭 오류 수정 — event.target 방식에서 이벤트 위임(delegation) 방식으로 바꿔 모든 탭이 정상 작동하도록 했습니다.

디자인 변경 — 흰 배경 + 라이트 그레이 서피스 + IBM Plex 폰트로 미니멀하게 정리했고, 형광색 대신 녹색/빨강/파랑/노랑 모두 차분한 머티드 톤으로 교체했습니다.

===

결론부터

웹 접근은 설계한 것으로 충분합니다. 다만 JDBC는 Pomerium으로 안 됩니다.

웹 접근 — 충분한 이유

현재 AD에 부서+계층 정보만 있어도 ABAC로 의미 있는 통제가 가능합니다.

사용 가능한 컨텍스트 속성:
  user.department     = "Engineering/Platform"
  user.dept_level     = 2  (계층 깊이)
  context.network     = "internal" / "external"
  context.time        = 업무시간 여부
  resource.path       = 접근 URL 패턴

Keycloak → Pomerium → OPA 흐름으로 이 속성들을 조합하면 부서별 URL 접근 통제, 외부망 접근 시 추가 제한 등은 충분히 구현됩니다. AD 속성이 빈약한 건 나중에 Keycloak에서 커스텀 클레임을 추가하는 식으로 점진적으로 보완 가능합니다.

JDBC는 별도로 봐야 합니다

JDBC 접근은 HTTP가 아니라 TCP 레이어라 Pomerium이 제대로 처리하지 못합니다.

접근 유형	Pomerium	Teleport	비고
웹앱 / REST API	✅ 적합	△ 가능하나 과함	Pomerium으로 충분
JDBC (DBeaver 등 사람이 직접)	❌ 미지원	✅ DB Service	Teleport 필요
앱 → DB (서비스계정)	❌	❌	Vault가 담당
터미널 / SSH	—	✅	기존 전용툴로 이미 해결

그래서 실제로 필요한 구성

웹 접근       → Pomerium  (설계대로)
JDBC (사람)   → Teleport DB Service만 부분 도입
앱→DB         → HashiCorp Vault (동적 자격증명)
터미널        → 기존 전용 보안툴 유지

Teleport를 전부 도입할 필요는 없고, Teleport Database Service 기능만 쓰는 것도 가능합니다. 단, JDBC 접근 대상이 내부 개발자 몇 명뿐이고 기존 전용 보안툴이 DB 접근도 커버한다면 Teleport 없이 Vault만으로도 정리됩니다. 전용 보안툴이 DB 접근까지 포함하는지 확인이 먼저입니다.

Young-Kyoo Kim

engineer

이전 포스트

26A03a

다음 포스트