[FEAT] 제로트러스트 보안 아키텍처 구축

[KoungQ]

배경

credito는 신용대출 신청, 심사, 실행, 상환, 연체 전환까지의 여신 흐름을 다루는 금융 도메인 시스템이다. 이 구조에서는 고객 정보, 계좌 정보, 대출 상태, 운영자 권한, 배치 실행 권한까지 모두 보안 통제 대상이 된다.

이번 상위 이슈의 목적은 Docker Compose 기반 멀티서비스 환경에서 제로트러스트 보안 기본선을 구축하는 것이다.
핵심 원칙은 다음과 같다.

• 외부 요청은 gateway-service를 통해서만 진입한다.
• 내부 서비스는 Docker internal network에 있더라도 자동으로 신뢰하지 않는다.
• 사용자 요청은 JWT로 검증한다.
• 서비스 간 호출은 mTLS + service-token을 함께 검증한다.
• 고객과 운영자는 인증 영역과 권한 체계를 분리한다.
• 감사로그, 마스킹, 멱등성 검증을 기본 보안 기능으로 포함한다.

이 이슈는 전체 보안 아키텍처를 묶는 상위 에픽이며, 실제 구현은 하위 이슈 단위로 나누어 진행한다.

작업 내용

• Docker Compose 기준 보안 아키텍처와 네트워크 분리 정책을 확정한다.
• gateway-service를 외부 단일 진입점으로 추가한다.
• Keycloak 기반 고객/운영자/서비스 계정 구조를 도입한다.
• 각 서비스에 Resource Server 기반 JWT 검증 구조를 적용한다.
• 내부 서비스 간 mTLS + service-token 검증 구조를 적용한다.
• common 모듈에 보안 공통 컴포넌트를 추가한다.
• 서비스별 보안 책임을 각 도메인 서비스 내부에 구현한다.
• 통합 테스트로 인증, 인가, 내부 호출, 직접 접근 차단, 감사로그, 멱등성을 검증한다.

서브 이슈

• gateway-service 추가 및 외부 단일 진입점 구성
• Docker Compose 네트워크 분리 및 포트 노출 정책 적용
• Keycloak 도입 및 realm/client 기본 구성
• 운영자 MFA 및 업무 권한 Role 모델 구성
• 전 서비스 Resource Server 보안 기본선 적용
• common 모듈 보안 공통 컴포넌트 추가
• Gateway Trace ID 전파, Rate Limit, 감사로그 기본선 구성
• 내부 서비스 간 mTLS 인증서 발급 및 TrustStore/KeyStore 구성
• client_credentials 기반 service-token 발급 및 검증 구현
• customer-service 보안 책임 구현
• account-service 보안 책임 구현
• lending-service 및 batch-service 보안 책임 구현
• 보안 통합 테스트 및 실패 시나리오 검증

완료 조건

• 외부 요청이 gateway-service를 통해서만 진입한다.
• gateway-service, keycloak 외 서비스는 외부 포트를 직접 공개하지 않는다.
• 고객/운영자/서비스 계정이 Keycloak에서 분리되어 관리된다.
• 각 서비스가 사용자 JWT를 직접 검증한다.
• 내부 서비스 호출이 mTLS + service-token 없이는 허용되지 않는다.
• 서비스별 보안 책임이 각 도메인 서비스 내부에 반영된다.
• 감사로그, 마스킹, 멱등성 검증의 공통 기반이 마련된다.
• 주요 정상/실패 시나리오가 통합 테스트로 검증된다.

제외 범위

• Kubernetes
• Istio, Linkerd 등 서비스 메시
• 인증서 자동 로테이션
• Vault, KMS, HSM 연동
• SIEM 연동
• 고객 MFA 강제 적용
• 고급 정책 엔진(ABAC/OPA) 도입