SQL부터 Kubernetes까지, QueryPie로 완성하는 통합 접근제어와 감사

• ISMS·PCI·GDPR 대응을 위한 QueryPie 커뮤니티 에디션 실전 가이드
• 중소기업을 위한 무료 보안 플랫폼, QueryPie 커뮤니티 버전
• QueryPie 커뮤니티 에디션 활용 SQL·서버·Kubernetes·Web 통합 보안 접근제어

한눈에 요약

• 대상/목적: 중소기업·스타트업 등 보안 인프라 접근성이 낮은 조직을 위해, 최대 5인이 사용할 수 있는 운영 가능한 무료 배포판.
• 범위: DB(데이터베이스), 서버(SSH 등), Kubernetes, 내부 웹앱/관리콘솔까지 단일 포털에서 계정·권한·승인·감사를 일원화.
• 핵심 가치: JIT(Just-in-Time) 승인, RBAC, 데이터 마스킹, 세션 녹화/쿼리 로깅, 감사 리포트로 ISMS·PCI-DSS·GDPR 대응력 강화.
• AI 시대 대응: 사내 AI 모델·에이전트 접근 제어·감사(예: MCP 연계)로 AI 데이터 유출·권한 남용 리스크를 감소.

아키텍처 개요 (보안 흐름 중심)

• 관리 포털(Control Plane): 사용자·그룹·역할(RBAC)·승인 워크플로우·감사 리포트 관리.
• 연결 방식
  1. 프록시/게이트웨이형: DB/웹/SSH/K8s 트래픽을 중앙에서 중계·정책 적용·감사.
  2. 경량 에이전트형: 특정 환경에 설치하여 로컬 네트워크 안에서 정책/감사를 수집·전달.
• 인증 연동: SSO(SAML/OIDC, 기업 IdP) + MFA 권장, 그룹 맵핑으로 역할 자동 부여.
• 승인 흐름: 사용자가 접근 요청 → 검토/승인 → 제한시간 JIT 권한 부여 → 자동 회수.
• 감사/포렌식: DB 쿼리/Export, SSH 명령·세션 녹화, K8s API 호출, 웹 조작(로그·스크린샷) 등 행위 단위 추적.

기능 상세 (모듈별)

1. DB 접근 제어(DAC)

• 세분화 권한: 스키마/테이블/컬럼/뷰 단위 RBAC, 읽기·쓰기·Export 분리.
• 데이터 마스킹: 주민번호/이메일/전화번호 등 민감 필드를 실시간 마스킹(정규식/룰 커스텀).
• 쿼리/Export 워크플로우: 대량 내보내기, 고위험 쿼리는 사전 승인 필수.
• 감사성 강화: 쿼리 로그, Export 이력, 요청-승인-집행 전과정 타임라인.

300x250

마스킹 예시(정규식 룰 아이디어)

• 이메일: (^.).*(@.*$) → \1***\2 → h***@example.com
• 휴대전화: (\d{3})\d{3,4}(\d{4}) → \1****\2 → 010****1234

2. 서버 접근 제어(SAC)

• 자격증명 비노출: 사용자는 포털에서 클릭으로 SSH 세션 시작(키/패스워드 직접 보지 않음).
• 세션 녹화·재생: 명령어/입출력/파일전송 추적, 사후 포렌식 용이.
• 긴급(브레이크글라스): 사고·야간 장애 시 시간 제한 루트권한 부여 → 사후 승인/사유 기록.

 

운영자 세션 예시

# 포털에서 '운영서버-01' JIT 요청 승인 후 자동 오픈된 SSH
# (로컬에서는 별도 비밀키/비번 불필요)
sudo systemctl restart myservice
journalctl -u myservice -n 200

3. Kubernetes 접근 제어(KAC)

• kubeconfig 발급/회수: 사용자 요청 후 네임스페이스/리소스 범위 제한된 kubeconfig 부여.
• API 호출 감사: kubectl·클라이언트(Lens 등) 호출 이력 추적.
• RBAC/네임스페이스 분리: 팀·서비스 단위 격리.

 

K8s RBAC 예시(최소권한 Role)

# team-a 네임스페이스에서 파드 읽기 전용
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: team-a-readonly
  namespace: team-a
rules:
- apiGroups: [""]
  resources: ["pods","pods/log"]
  verbs: ["get","list","watch"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: team-a-rb
  namespace: team-a
subjects:
- kind: User
  name: alice@example.com
roleRef:
  kind: Role
  name: team-a-readonly
  apiGroup: rbac.authorization.k8s.io

사용자 셀프 체크

export KUBECONFIG=/path/to/issued.kubeconfig
kubectl auth can-i get pods -n team-a
kubectl get pods -n team-a

4. Web 접근 제어(WAC)

• 내부 어드민/사내 웹앱 보호: 로그인·화면 조작·파일 업/다운 활동 타임라인/스크린샷.
• 행위 통제: 대량 다운로드·설정 변경 등 고위험 액션 승인 요구 가능.
• 감사 리포트: 계정 도용/내부자 위협 탐지에 유리.

5. 통합 워크플로우·알림

• SSO(SAML/OIDC): IdP 그룹 ↔ 역할 매핑으로 접근 통일.
• Slack/이메일 승인: 요청이 오면 담당자가 DM/메일에서 승인/반려.
• JIT 자동 회수: 승인된 권한은 시간 만료 시 자동 철회.

설치·도입(현업형 빠른 시작)

1. 사전 준비 체크리스트

• 호스트 서버: Linux x86_64, 컨테이너 런타임(Docker/podman 등), 4vCPU/16GB RAM 이상 권장.
• 도메인/TLS: portal.company.com 할당, HTTPS 강제.
• 네트워크: 포털(80/443)과 내부 자산(DB/SSH/K8s/Web) 연결 경로 방화벽 허용.
• IdP/SSO: SAML/OIDC 메타데이터 준비(ACS URL, Entity ID 등).
• 알림: Slack 워크스페이스/이메일(SMTP) 준비.
• 규정: 로그 보존주기, 마스킹 범주, Export 승인 기준, 브레이크글라스 SOP.

2. 설치(예시 절차)

# 1) 루트/관리자 권한으로 설치 스크립트 실행 (공식 가이드의 URL 사용)
bash <(curl -fsSL <설치_스크립트_URL>)

# 2) 브라우저로 접속
https://portal.company.com

# 3) 초기 관리자 비밀번호 즉시 변경, MFA 활성화
# 4) 라이선스(커뮤니티 에디션) 등록

3. 초기 구성 순서(권장)

1. SSO 연동: SAML/OIDC 설정 → 테스트 로그인 → 그룹 ↔ 역할 매핑.
2. 조직/그룹 정리: 팀·직무 기준 역할 설계(Dev, Ops, DBA, Auditor 등).
3. 자산 연결: DB·서버·K8s·웹 리소스 등록(태그/소유팀 메타데이터 포함).
4. 워크플로우: Export·루트권한·프로덕션 접근은 승인 필수로 설정.
5. 정책/마스킹: PII·결제·계정정보 등 민감 필드 룰 정의.
6. 리허설: 샘플 사용자 2~3명으로 요청→승인→접속→감사 리포트까지 E2E 점검.

보안 점검 포인트

1. 계정/인증

• SSO 강제 + MFA 필수: 로컬 계정은 비상용 최소화, 주기적 점검.
• JIT 원칙: 상시 관리자 권한 금지, 필요 시 승인받아 시간 제한 부여.
• 접근 재검토(Recertification): 분기/반기 단위 역할·권한 검토.

2. 권한/정책

• 최소권한: DB는 스키마/컬럼/뷰 기준, K8s는 네임스페이스/리소스 기준.
• 마스킹: 운영DB는 기본 마스킹 상태가 디폴트. 필요 시 사유·기간 제한 해제 요청.
• Export 통제: CSV/Excel/덤프는 승인·워터마킹·암호화 권장.

3. 감사/포렌식

• 세션 녹화/쿼리 로그/K8s API 로그/웹 활동 스냅샷을 단일 타임라인으로 결합.
• 보존/암호화: 규정(예: 1~3년)에 맞게 저장·암호화, 무결성 해시(감사용).
• SIEM 연계: Wazuh/Elastic/Chronicle 등으로 알림·탐지 룰 운영.

 

SIEM 전송 포맷 예시(JSON)

{
  "ts": "2025-08-25T15:10:11Z",
  "user": "alice@example.com",
  "resource": "prod-db-01",
  "action": "SQL_EXPORT",
  "status": "APPROVED",
  "request_id": "REQ-20250825-00123",
  "ip": "10.20.30.40",
  "tags": ["prod","finance"],
  "justification": "월마감 보고서 추출",
  "ttl_minutes": 30
}

4. 브레이크글라스(긴급) 통제

• 원칙: 승인권자 2인(또는 온콜) 중 1인 이상 동의 + 최대 1~2시간 권한.
• 사후: 활동 리포트 자동 배포(Slack/이메일) + 근거 문서화.

활용 시나리오(현업형)

1. 개발/BI 데이터 접근
   • 개발·분석 인력은 마스킹된 뷰에만 기본 접근.
   • 운영 데이터 Export는 사전 승인 + 워터마크 파일로 제공.
   • 예시: 마케팅팀이 이메일/전화번호를 요청하면 해시 또는 마스킹된 식별자로 대체 제공.
2. 운영장애 대응(서버/네트워크)
   • 온콜 엔지니어가 SAC로 접속 요청 → JIT 루트 60분 → 세션 녹화 자동 저장.
   • 사후 리포트를 채널에 공유해 변경 추적과 지식 축적 병행.
3. 멀티테넌트 K8s(호스팅/플랫폼팀)
   • 팀별 네임스페이스 발급, kubeconfig 만료시간 내 자동 회수.
   • kubectl auth can-i 교육으로 셀프 검증 습관화.
4. 내부 웹 관리콘솔 보호
   • 관리자 화면의 로그인/설정/다운로드를 스크린샷+이벤트 로그로 기록.
   • 고위험 액션(계정 비활성화, 대량 Export)은 무조건 승인.
5. AI/에이전트 거버넌스
   • 사내 AI/에이전트가 DB·API에 접근할 때 전용 역할/토큰을 발급하고 감사 추적.
   • MCP 연계 시 툴 권한·데이터 경계를 중앙에서 관리, 만료·회수 자동화.

규제 맵핑(간단 가이드)

• ISMS: 접근통제, 사용자 인증, 계정 관리, 로그·감사(세션/쿼리/K8s/Web), 개인정보 최소조회(마스킹), 변경관리(브레이크글라스 사후기록).
• PCI-DSS: Req.7(권한 최소화), Req.8(인증·MFA), Req.10(감사로그), Req.12(정책/절차).
• GDPR: 최소수집·목적제한, 접근권한 통제, 가명화/마스킹, 처리기록·감사 가능성.

PoC/도입 로드맵

1. 1주차: 설치·TLS·SSO·Slack/메일 연동, 샘플 리소스(Dev DB 1, SSH 서버 1, K8s 1, 내부 웹 1) 연결.
2. 2주차: 역할·마스킹·승인 워크플로우 설계, E2E 테스트(요청→승인→접속→감사).
3. 3~4주차: 운영팀·DBA·개발팀 대상 파일럿, KPI(무자격 접근 차단율, 승인 MTTR, 감사정합성, Export 통제율) 측정 → 튜닝.

운영 한계·주의점·팁

• 사용자 수 제한: 커뮤니티는 5인 범위. 운영 시 역할/그룹을 잘 설계해 효율화.
• 네트워크: 포털↔자산 간 경로/방화벽·프록시 고려, 사설망일 경우 중계 호스트/리버스 프록시 설계.
• 로컬 계정 최소화: SSO 강제, 로컬은 비상용·만료 정책.
• 백업/DR: 포털 메타데이터·감사로그 백업 주기화, 스냅샷/오브젝트 스토리지 병행.
• 개인정보 보호: 마스킹 기본값을 “강함”으로, 해제는 사유·기간 제한과 결재 필수.
• 긴급 권한 남용 방지: TTL(예: 30~60분), 2인 승인 또는 온콜 승인, 사후리포트 자동 배포.

예시/명령어·설정 모음

1. 설치/초기화(템플릿)

# 설치 (공식 가이드 스크립트 URL 사용)
bash <(curl -fsSL <설치_스크립트_URL>)

# 첫 접속
https://portal.company.com

# 관리자 보안
# - 기본 비밀번호 즉시 변경
# - MFA 활성화
# - SSO(SAML/OIDC) 연결

2. DB 마스킹 룰(아이디어)

-- 예: 마스킹 뷰
CREATE VIEW v_customer_masked AS
SELECT
  id,
  CONCAT(SUBSTR(email,1,1),'***',SUBSTR(email,INSTR(email,'@'))) AS email_masked,
  CONCAT(SUBSTR(phone,1,3),'****',SUBSTR(phone,-4)) AS phone_masked,
  created_at
FROM customer;

3. Kubernetes 최소권한(재확인)

export KUBECONFIG=/path/to/issued.kubeconfig
kubectl auth can-i get pods -n team-a     # yes
kubectl auth can-i delete deploy -n team-a # no

4. 승인 자동화(메시지 예시)

[접근 요청] 사용자: alice@example.com
리소스: prod-db-01 (Export)
사유: 월마감 보고서 추출
기간: 30분
승인/반려: 여기서 선택

5. 브레이크글라스 SOP(요지)

• 요청 → 온콜 승인(최대 60분) → 작업 → 세션/로그 자동 수집 → 사후 24시간 내 검토·리포트.

권장 템플릿(예시)

1. 역할 세트
   • Dev-ReadMasked(DB), Dev-K8s-NS-Readonly, Ops-SSH-Std, Ops-K8s-NS-Admin, DBA-Priv, Auditor-ViewOnly.
2. 워크플로우 규칙
   • Prod-DB Export, Prod-SSH Root, K8s ClusterAdmin, Web Admin HighRisk는 승인 필수.
3. 마스킹 대상
   • PII(이메일, 휴대폰, 주소), 결제, 계정·세션·토큰, 민감 로그 필드.
4. KPI
   • JIT 승인 MTTR ≤ 15분, Export 승인률 100%, 무승인 고위험 0건, 감사로그 누락 0건.