[Field Report] 금융권 보안 심사, 'Pass'를 결정짓는 아키텍트의 보안 체크리스트
금융권 프로젝트의 종착역은 기능 구현이 아닌 보안 심사다. 금융보안원이나 내부 보안 통제 조직의 가이드라인은 엄격하며, 이를 통과하지 못하면 오픈 자체가 불가능하다. 17년 차 AA(Application Architect)로서 이커머스와 금융권 프로젝트를 수행하며 체득한, 실무 중심의 보안 심사 대응 팩트 체크리스트를 공개한다.
1. 코드 레벨: 정적 분석(SAST) 및 취약점 제거
가장 기본이 되는 단계다. Veracode나 Fortify 같은 도구를 통해 도출된 리포트에서 'Critical' 항목이 하나라도 있으면 심사는 중단된다.
입력값 검증 (In-place Validation): SQL Injection, XSS 방지는 기본이다. 모든 컨트롤러 진입점에 유효성 검사 로직이 있는지 확인한다.
하드코딩된 자격 증명 제거: 소스 코드 내에 DB 패스워드나 API Key가 평문으로 노출되는 것은 치명적이다.
Solution:
Jasypt를 이용한 프로퍼티 암호화나Vault같은 외부 설정 관리 도구 사용이 강제된다.안전하지 않은 암호화 알고리즘: SHA-1, MD5 등은 배제하고 SHA-256 이상의 해시 함수와 AES-256 이상의 대칭키 알고리즘을 사용해야 한다.
2. 인프라 및 네트워크: 논리적 격리와 통제
금융권 아키텍처의 핵심은 망 분리와 접근 제어다.
망 분리 준수: 인터넷망(DMZ), 서비스망(Was), 데이터망(DB) 간의 엄격한 격리를 확인한다.
Inbound/Outbound 제어: 80/443 포트 외의 불필요한 포트는 모두 차단하며, 특히 내부에서 외부로 나가는(Outbound) 트래픽은 화이트리스트 기반으로 관리해야 한다.
개인정보 암호화: DB 내 개인정보(이름, 연락처, 계좌번호 등)는 반드시 암호화되어야 하며, 이를 조회하는 화면에서는 마스킹 처리가 필수다.
3. 인증 및 권한 관리 (IAM)
사용자가 누구인지, 그리고 무엇을 할 수 있는지를 완벽하게 증명해야 한다.
세션 관리: 중복 로그인 방지, 세션 타임아웃(보통 10~30분) 설정이 적절한가?
권한 오남용 방지: 관리자 페이지에 대한 접근은 특정 IP 대역으로 제한되는가?
비밀번호 정책: 최소 길이, 특수문자 조합, 변경 주기(90일) 등이 금융감독원 권고안을 따르고 있는가?
4. 실전 대응을 위한 핵심 체크리스트 (Summary)
| 분류 | 점검 항목 | 비고 |
| 로그 | 개인정보 및 비밀번호 평문 로그 출력 여부 | 가장 빈번한 결함 |
| 데이터 | DB 구간 암호화 및 유휴 데이터(Data-at-Rest) 암호화 | 보안성 검토 필수 항목 |
| 인증 | 중요 거래 시 2차 인증(2FA) 적용 여부 | 이체, 정보변경 등 |
| 통신 | 전 구간 HTTPS(TLS 1.2 이상) 적용 및 취약한 cipher suite 제거 | 외부 연동 시 필수 |
| 오픈 소스 | 라이브러리 취약점(CVE) 점검 | Log4shell 등 이슈 대응 확인 |
5. 아키텍트의 결론: 보안은 '기능'이 아니라 '품질'이다
보안 심사 대응을 프로젝트 막바지에 시작하면 반드시 일정이 밀린다. 설계 단계부터 Security by Design을 적용해야 한다. 특히 금융권 클라우드 전환 프로젝트라면, CSP(Azure/AWS 등)가 제공하는 보안 그룹 설정과 금융보안원의 가이드라인 사이의 간극을 메우는 것이 AA의 핵심 역량이다.
댓글
댓글 쓰기