제로트러스트를 여신 시스템에 가져오면 무엇이 달라질까

앞 글에서는 금융권 망분리 규제가 최근 어떻게 바뀌고 있는지, 그리고 왜 제로트러스트가 같이 언급되는지 정리했다.
이번에는 그 배경 설명을 반복하기보다, 제로트러스트를 실제 금융 시스템 설계 문제로 가져오면 무엇이 달라지는지에 집중해보려고 한다.

관심사는 단순하다.

제로트러스트를 적용한다는 말을, 여신 시스템에서는 어떻게 현실적인 설계 기준으로 바꿔야 할까?

제로트러스트는 기술 하나가 아니라 판단 기준에 가깝다

제로트러스트를 이야기할 때 종종 특정 솔루션 이름처럼 들릴 때가 있다.
하지만 실제로는 기술 하나보다 설계 기준에 더 가깝다.

핵심은 네트워크 위치로 신뢰를 판단하지 않는 것이다.

• 내부망이라고 자동으로 신뢰하지 않는다
• 한 번 인증됐다고 모든 접근을 허용하지 않는다
• 접근 이후에도 계속 확인한다

이걸 시스템 설계 관점으로 바꾸면 결국 이런 질문으로 이어진다.

• 이 요청은 누가 보냈는가
• 무엇에 접근하려는가
• 왜 이 작업이 필요한가
• 지금 이 권한까지 열어줘도 되는가

이 질문이 중요해지는 순간, 제로트러스트는 더 이상 보안팀의 문구가 아니라 애플리케이션 설계 규칙이 된다.

여신 시스템에서는 왜 이게 더 중요할까

여신 시스템은 다루는 데이터도 민감하고, 기능의 결과도 무겁다.

• 고객 정보
• 계좌 정보
• 대출 신청 정보
• 상환 이력
• 연체 상태

여기에 더해 실제로 고객 자산과 신용 상태에 영향을 주는 기능이 있다.

• 대출 심사
• 승인
• 실행
• 상환
• 연체 전환

이런 시스템에서는 "로그인한 사용자다" 정도로는 부족하다.
정말 중요한 건 그 다음부터다.

로그인만으로는 설명되지 않는 질문들

여신 시스템에서 요청 하나를 처리할 때는 보통 이런 질문이 같이 붙는다.

• 요청자가 해당 고객 본인인가
• 이 계좌를 조회하거나 조작할 권한이 있는가
• 현재 대출 상태에서 이 작업이 가능한가
• 운영자라면 이 단계까지 접근 가능한 역할인가
• 같은 요청이 이미 처리된 적은 없는가
• 나중에 누가 무엇을 했는지 추적할 수 있는가

즉 보안은 로그인 성공 여부보다, 각 요청을 어디까지 허용할지 세밀하게 판단하는 과정에 더 가깝다.

이 지점에서 제로트러스트는 실제 설계 원칙으로 내려온다.

제로트러스트 관점에서 보면 보안 책임이 더 잘게 나뉜다

이걸 여신 시스템에 적용해보면 보안 책임이 여러 층으로 나뉜다.

1. 사용자 인증

먼저 누가 들어왔는지는 확인해야 한다.
고객인지 운영자인지, 어떤 역할을 가진 운영자인지 구분이 필요하다.

2. 권한 확인

인증이 됐다고 모든 기능을 허용하면 안 된다.
예를 들어 운영자도 심사 담당자, 승인 담당자, 배치 운영자처럼 권한이 다를 수 있다.

3. 소유권과 대상 검증

고객이 로그인했다고 해서 모든 계좌와 대출 건에 접근할 수 있는 건 아니다.
해당 고객의 리소스가 맞는지, 해당 대출 건에 접근 가능한 주체인지 다시 확인해야 한다.

4. 상태 검증

대출 실행, 상환, 연체 전환 같은 기능은 현재 상태가 맞을 때만 수행돼야 한다.
이건 인증 서버가 아니라 도메인 서비스가 직접 판단해야 한다.

5. 감사 가능성

누가 어떤 요청을 보냈고, 어떤 결과가 나왔는지 남아야 한다.
금융 시스템에서는 나중에 설명 가능한 기록이 매우 중요하다.

6. 중복 요청 방지

같은 실행 요청이나 상환 요청이 두 번 들어오면 큰 문제가 된다.
그래서 멱등성도 보안 통제와 무관한 기능이 아니라, 사고를 줄이는 장치로 봐야 한다.

내부 서비스 호출도 검증 대상이 된다

제로트러스트를 여신 시스템에 적용할 때 생각보다 중요한 건 내부 서비스 호출이다.

마이크로서비스 구조에서는 이런 호출이 자연스럽다.

• lending-service -> account-service
• lending-service -> customer-service
• batch-service -> lending-service

예전 감각으로는 "같은 시스템 안의 서비스니까 믿어도 되지 않나?"라고 생각할 수 있다.
그런데 이걸 그대로 두면 서비스는 나뉘어 있어도 신뢰 경계는 하나로 남는다.

실제로 봐야 하는 건 이런 것들이다.

• 어떤 서비스가 호출했는가
• 어떤 권한으로 호출했는가
• 어떤 내부 API를 부를 수 있는가
• 어떤 데이터 범위까지 허용할 것인가

이걸 내부망이라는 이유로 생략하면, 한 서비스가 침해됐을 때 다른 서비스로 피해가 빠르게 번질 수 있다.

그래서 아키텍처 판단도 바뀐다

이걸 정리하다 보니 자연스럽게 몇 가지 판단이 따라왔다.

• 외부 요청은 단일 진입점으로 받는 편이 낫다
• 고객 계정과 운영자 계정은 분리하는 게 맞다
• 운영자 쪽은 MFA까지 고려해야 한다
• 각 서비스는 gateway를 통과했다고 해서 안심하면 안 된다
• 내부 서비스 호출도 별도 신원과 권한 검증이 필요하다
• 감사로그와 멱등성은 나중에 붙이는 부가 기능이 아니라 처음부터 봐야 하는 통제다

이런 판단은 다 결국 같은 방향을 가리킨다.

"내부라서 믿는다"보다 "이 요청이 왜 허용돼야 하는지 설명할 수 있어야 한다"는 쪽이다.

결국 남는 건 역할 분리다

여기까지 오면 자연스럽게 두 가지 책임이 나뉜다.

인증 서버가 맡을 책임

• 로그인
• 토큰 발급
• 계정 관리
• 역할 관리
• 운영자 MFA

서비스가 직접 맡을 책임

• 고객 본인 여부 확인
• 계좌 소유권 확인
• 대출 상태 전이 검증
• 내부 서비스 호출 권한 확인
• 감사로그 기록
• 멱등성 검증

즉 제로트러스트는 인증 서버 하나를 붙이는 문제로 끝나지 않는다.
오히려 무슨 책임을 밖으로 빼고, 무슨 책임은 끝까지 서비스 안에 남길 것인지를 더 분명하게 만든다.

정리

금융권에서 제로트러스트가 중요해지고 있다는 말은, 단순히 네트워크 보안을 더 엄격하게 하자는 뜻이 아니다.
여신 시스템 기준으로 보면 그건 결국 요청 하나를 처리할 때 어디까지를 검증해야 하는지 다시 정의하는 문제에 가깝다.

고객 인증, 운영자 권한, 계좌 소유권, 대출 상태, 내부 서비스 호출, 감사로그, 멱등성 같은 것들이 따로 떨어진 얘기가 아니라 한 흐름으로 연결된다.

이번에 정리하면서 제일 크게 남은 건 이거였다.

제로트러스트는 내부망을 의심하자는 말이라기보다, 중요한 요청일수록 신뢰의 근거를 더 촘촘하게 확인하자는 쪽에 가깝다.

다음 글에서는 이 흐름 안에서 왜 Keycloak 같은 인증 서버를 두는 쪽으로 판단했는지, 그리고 인증 책임과 도메인 판단 책임을 어떻게 나누려고 했는지 이어서 정리해보려고 한다.