4편. 금융권 Hadoop 보안 아키텍처 – 계정·권한·감사·데이터 보호 실전 가이드

 

4편. 금융권 Hadoop 보안 아키텍처 – 계정·권한·감사·데이터 보호 실전 가이드

금융권에서 Hadoop 플랫폼을 운영할 때 가장 까다로운 영역이 보안 아키텍처다.
일반 기업과 달리 금융권은 전사보안정책, 망분리, 접근통제, 감사, 로그 보관, 개인정보 보호법, 전자금융감독규정까지 고려해야 한다.

이번 글에서는 실제 은행 Hadoop 구축·운영 경험을 기반으로,
“금융권에서 반드시 갖춰야 하는 Hadoop 보안 아키텍처”를 실전 중심으로 정리했다.

---

🧩 1. 금융권 Hadoop 보안 요구사항 정리

금융권 보안 정책은 보통 다음 항목을 기본 요구한다.

✅ 1) 사용자 계정 관리

• 계정은 AD/LDAP 기반의 단일계정(Single Account) 사용
• 모든 계정은 실명 기반
• 공용계정 금지
• 90일 비밀번호 정책, 계정 잠김 기준 등 적용

✅ 2) 권한 관리

• 최소권한 원칙(Least Privilege)
• 서비스 계정(Service Account)과 사용자 계정 분리
• 개발/운영/보안 역할 기반 RBAC 적용
• Hadoop Directory(HDFS) 권한 모델 적용
• Hive Table 권한, Ranger 정책 적용

✅ 3) 데이터 보안

• 개인정보(P) 등급 분류: P1~P3
• P등급 데이터는 컬럼 암호화 또는 마스킹
• 로그에 개인정보 포함 금지
• HDFS 암호화 Zone 설정(EZ)

✅ 4) 접근·감사·로그

• 모든 명령어(hdfs dfs, hive, spark-submit) 감사 기록
• Web UI 접근 기록 남기기
• 행위기반 알림: Hive 조회 과다, 파일 다운로드 과다
• 감사 로그 5년 보관(은행 정책 기준)

---

🔐 2. 금융권 Hadoop 보안 아키텍처 구성도

[ AD/LDAP ] ------> Ranger (정책 저장소)
                      | 권한·정책
                      v
        +-----------------------------------------+
        |               Hadoop Cluster             |
        |------------------------------------------|
        | HDFS | YARN | Hive | Spark | Presto      |
        |------------------------------------------|
        | Audit Log  | Ranger Plugin | Knox Gateway|
        +------------------------------------------+
               | 감사 로그
               v
         SIEM / 통합보안관제 (ES, Splunk)

구성 핵심:

• Ranger: 권한 통제/Hive-HDFS-Kafka 접근 권한 정책
• Knox: 외부 접속 게이트웨이
• AD/LDAP: 인증(SSO) 및 계정 관리
• Audit Log → SIEM: 모든 접근 행위는 관제센터로 전달

---

🧱 3. 계정/권한 모델링 – 실전 구성

📌 3-1. 역할 기반 RBAC 정의

은행에서는 보통 다음 5가지 RBAC을 사용한다.

역할 설명 예시 권한

Data Engineer	배치 개발·운영	HDFS read/write, Spark submit
Data Scientist	분석·ML	Hive read, sandbox 접근
Platform Operator	플랫폼 운영	Yarn 관리, 서비스 계정 관리
Security Officer	보안·감사	정책 조회, 감사 로그
Service Account	배치·파이프라인 자동화	특정 디렉토리 쓰기만 가능

---

🔒 4. Ranger 기반 권한 정책 운영 팁

📌 실전 운영 정책 예시

1. HDFS 정책
   • /data/raw/<팀>: 팀 별 read/write
   • /data/model: DataEngineer만 write
   • /data/personal: 접근 롤 whitelist
2. Hive 정책
   • PII 포함 테이블: DataScientist read-only
   • 운영 테이블: Service Account만 query 가능
   • Masking 적용: 전화번호 → 010-****-****
3. Spark Submit 정책
   • 특정 Queue는 특정 조직만 submit 가능

---

🛡️ 5. 망분리 환경에서 Hadoop 운영 주의점

금융권에서는 Hadoop도 보통 **업무망(내부망)**에 위치하며
인터넷망으로 분리되어 있다.

주요 문제점:

• 파이썬·OS 패키지 설치 어려움
• 오픈소스 버전 업데이트 지연
• 외부 라이브러리 사용 제한
• 모델 다운로드 불가(LLM 환경과 동일 문제)

해결 경험:

• 내부 아카이브 서버 운영
• 민감도 없는 패키지는 보안심의 절차 사용
• 업무망→인터넷망 업로드 프록시 구축

---

🧨 6. 감사·로그 체계 구축 (은행 실무 기준)

필수 감사 항목

• HDFS file read/write
• Hive query 실행 기록
• Spark job 실행
• Knox 접근
• Ranger 정책 변경
• 관리자 계정 sudo 사용
• 개인정보 데이터 접근 기록

로그 전송 패턴

Hadoop Audit Log → Logstash → Elasticsearch → 시각화(Kibana)
                        ↘
                         ↘--> 보안관제(SIEM)

---

🧪 7. 금융권에서 필수인 데이터 보호

✔ HDFS Encryption Zone 적용

• EZ 적용 후 하위 디렉터리는 자동 암호화
• 개인정보 디렉터리에 EZ 필수

✔ Hive 컬럼 암호화

• AES256 기반 KMS 적용
• 민감 데이터는 Query 수행 시 복호화

✔ Masking

• 전화번호 / 이름 / 계좌번호는 정책 기반 Masking

---

🧰 8. 실제 장애/이슈 사례 (은행 운영 경험)

1) Ranger 정책 충돌

• 사용자 그룹 정책 > 개별 정책 우선 적용
• 정책 충돌로 Hive 접근 실패 사례 잦음
• 해결: 정책 우선순위 명확하게 관리

2) Knox 세션 타임아웃으로 Spark Job 제출 실패

• Knox가 중간에서 인증 토큰 만료
• 해결: Timeout을 Spark job TTL보다 길게 설정

3) 감사 로그 누락

• HiveServer2 Failover 시 설정 누락
• 해결: 보안 구성 자동화 스크립트로 표준화

---

💡 실전 Tip 3개

Tip 1. 권한 정책은 “허용 기반”이 아니라 “차단 기반”이 안정적이다.

허용 정책 기반으로 만들면 신규 프로젝트가 생길 때마다 퍼미션 폭주 발생.
은행은 “모든 차단 → 필요한 것만 허용” 방식이 훨씬 안전하다.

Tip 2. Ranger 정책 적용 전 반드시 Shadow 테스트를 수행하라.

실제 반영 전 “정책이 적용된다면 어떤 접근이 막히는지” 미리 테스트해야 한다.

Tip 3. 감사 로그는 1차 Hadoop, 2차 SIEM으로 이중화하라.

Hadoop 클러스터 장애 시 감사 기록까지 유실되면 금융감독원 점검에 문제된다.

---

📌 다음 편 예고 (5편)

5편. Hadoop 운영 자동화 – 스크립트·Job Template·배포 체계 표준화

 

🟦 금융권 하둡(Hadoop) 아키텍처 시리즈 (전 10편)

1. 1편 — 금융권은 왜 하둡을 쓰는가: 도입 배경과 진화
2. 2편 — 하둡 구성도: HDFS·YARN·Hive·Spark 운영 흐름
3. 3편 — 운영 자동화 스크립트 모음 (금융권 표준)
4. 4편 — 하둡 보안 아키텍처: 계정·권한·감사·데이터 보호 (현재 글)
5. 5편 — Job Template·배포 체계 표준화
6. 6편 — Hadoop + Kafka 실시간 분석 아키텍처
7. 7편 — 클러스터 운영 체계: 폐쇄망·보안·권한 관리
8. 8편 — Sqoop·Oozie·Spark Batch 적재 파이프라인
9. 9편 — 실사용 ①: 신용평가 / 여신 리스크 모델링
10. 10편 — 실사용 ②: FDS 이상거래탐지 로그 분석