금융권 ‘보안 구멍’으로 지목된 외부 업무시스템, 보안업계 진단은?

최근 금융권에서 직원·대출모집인용 외부 업무지원 시스템을 통한 고객정보 유출 사례가 잇따라 확인되면서, 보안업계에서는 외부 접속 관리 체계를 강화해야 한다는 진단이 나온다. 외부에 노출된 업무시스템을 빠짐없이 파악하고 접근 권한을 관리하는 동시에, 상시 점검과 전문가의 모의해킹을 병행해야 한다는 것이다.

신한은행은 대출모집인용 조회서비스, KB국민은행은 직원용 모바일 업무지원시스템, 하나은행은 영업지원시스템(ODS)에서 각각 고객정보가 유출됐다. 금융위원회는 지난 14일 발표한 금융권 전반의 보안점검 결과에서 대외 시스템의 인증·인가 누락과 다중인증 미도입 등을 주요 미흡사항으로 꼽았다.

19일 열린 국회 정무위원회의 금융감독원 국정감사에서도 외부 접속 관리 문제가 거론됐다. 한민수 더불어민주당 의원은 정보 유출이 발생한 은행들의 인증·접근통제 미흡을 지적하며 우리은행·NH농협은행과 비교했다. 두 은행은 유사한 공격 시도를 받았지만 정보 유출은 확인되지 않았다. 우리은행은 지정된 영업지원시스템(ODS) 태블릿과 원(WON)인증서 기반 스마트폰 인증으로 접속을 통제했다. NH농협은행은 대출모집인용 별도 외부 지원시스템을 운영하지 않았다.

외부 노출 자산 파악하고, 계정·접근권한 관리해야

이번 사고와 관련해 보안업계가 먼저 짚은 부분은 외부에 노출된 업무시스템의 식별과 관리 문제다.

공격표면관리(ASM) 솔루션을 만드는 보안 기업 AI스페라의 강병탁 대표는 “금융사는 핵심 금융시스템에 대해서는 엄격한 보안 관리 체계를 갖추고 있지만, 대출모집인이나 협력업체 등이 사용하는 외부 업무시스템은 상대적으로 관리가 소홀한 경우가 많다”고 짚었다.

그는 “금융사의 규모가 커질수록 계열사와 협력업체가 운영하는 웹서비스를 포함해 외부 노출 시스템이 수백개에 이를 수 있다”며 “이에 일부 시스템은 보안 담당자의 관리 대상에서 빠지거나 별도의 개발·운영 주체가 관리하면서 본사와 동일한 수준의 보안 점검을 받지 못한다”고 설명했다.

강 대표는 이에 “외부에서 접근할 수 있는 시스템뿐 아니라 원래 공개해서는 안 되는 내부 업무시스템이 인터넷에 노출돼 있는지도 확인해야 한다”고 조언했다. 개발·테스트용 서버나 협력업체 전용 시스템이 관리자의 인지 없이 외부에 공개되는 경우도 있어 ASM 솔루션을 통한 지속적인 점검이 필요하다는 것이다.

다만 ASM만으로 모든 보안 결함을 발견할 수는 없다. 그는 “로그인 이후 사용자별 접근 권한을 제대로 검증하지 않는 문제는 일반적인 ASM만으로 발견하기 어렵다”며 “이러한 결함은 개발 단계의 시큐어코딩과 소스코드 점검, 운영 중 모의해킹 등을 통해 별도로 확인해야 한다”고 말했다.

외부 업무시스템에 접속하는 사용자 계정과 접근권한 관리도 중요하다. 아이덴티티 보안 전문기업 세일포인트는 외부 인력의 계정을 수동으로 관리할 경우 계약 종료 이후에도 권한이 남아 있는 ‘고아 계정’이 발생할 수 있다고 지적했다. 업무가 변경된 뒤에도 이전 권한을 회수하지 않아 불필요한 접근 권한이 누적되는 문제도 발생할 수 있다는 설명이다.

세일포인트 관계자는 “직원·협력업체 담당자의 업무 변경이나 계약 종료에 맞춰 접근 권한을 자동으로 변경·회수하고, 사용자별 권한이 적절한지 정기적으로 검토해야 한다”며 “특정 업무시스템에 접근할 권한을 부여했더라도, 시스템 내부에서 수행하는 작업에는 별도의 권한 검증이 필요하다”고 강조했다.

이러한 권한 검증 기능은 소프트웨어 개발 단계부터 제대로 구현해야 한다.

애플리케이션 보안 기업 스패로우의 윤종원 CTO는 “사용자 신원을 확인하는 인증은 개발 도구에서 공통으로 처리하는 경우가 많지만, 특정 정보에 접근할 권한이 있는지 판단하는 ‘인가’는 업무에 따라 개발자가 직접 구현해야 한다”고 설명했다. 이 과정에서 권한 검증이 누락되거나 잘못 적용될 수 있다는 것이다.

그는 “외부에서 변경할 수 있는 요청값이 권한 확인 없이 데이터베이스 조회에 사용되는 경로를 소스코드 분석으로 찾아낼 수 있다”고 설명했다. 이어 “시스템마다 권한 검증 방식이 달라 기본적인 점검만으로는 결함을 놓칠 수 있다”며 “이에 조직별 권한 검증 방식을 소스코드 분석 규칙에 반영하고 개발·수정 과정에서 지속적으로 점검해야 한다고 강조했다”고 강조했다.

API 요청마다 권한 확인…취약점은 상시 검증

실제 업무시스템에서 고객정보를 조회할 때도 사용자별 접근 권한을 검증해야 한다. 특히 업무시스템과 고객 데이터를 연결하는 애플리케이션 프로그래밍 인터페이스(API)의 접근통제가 중요하다.

API 보안 전문기업 소프트프릭의 박현길 연구소장은 “금융권에서 발생한 모든 사고가 API 취약점 때문이라고 볼 수는 없지만, 외부 업무시스템이 내부 시스템과 고객 데이터에 접근하는 경로를 점검할 때 API를 우선 살펴볼 필요가 있다”고 진단했다.

그는 “인증에 성공했다는 것과 고객정보를 조회할 권한이 있다는 것은 별개의 문제”라고 설명했다. 예를 들어 대출모집인이 정상적으로 로그인했더라도 자신이 담당하는 고객의 정보만 조회할 수 있어야 한다. 그러나 고객번호나 계약번호를 변경해 다른 고객의 정보까지 조회할 수 있다면 ‘객체 단위 권한 검증 취약점(BOLA)’에 해당할 수 있다.

박 소장은 이러한 문제를 예방하려면 업무시스템이 API 요청마다 실제 데이터 접근 권한을 확인해야 한다고 강조했다. API 게이트웨이는 사용자 인증과 공통 접근정책, 호출량 제한 등을 담당하지만, 개별 고객정보에 대한 최종 권한 검증은 업무시스템에서 수행해야 한다는 설명이다.

정상 계정으로 비정상적인 정보 조회를 반복하는 행위도 점검해야 한다. 박 소장은 “고객번호를 바꿔가며 반복적으로 정보를 조회하는 행위는 개별 API 요청만으로 탐지하기 어렵다”며 “이에 일정 시간 동안의 호출 횟수와 조회 대상, 데이터양 등을 분석하고, 필요하면 API 게이트웨이나 웹방화벽(WAF)과 연동해 추가 인증이나 호출 제한·차단으로 대응해야 한다”고 조언했다.

금융권의 모의해킹 실효성을 높여야 한다는 진단도 나온다. 점검 주기와 방식을 개선하고, 발견된 취약점에 대한 후속 조치도 강화해야 한다는 것이다. 금융감독원이 박상혁 더불어민주당 의원실에 제출한 자료에 따르면, 국내 20개 은행은 2022년부터 올해 8월까지 481차례 모의해킹을 실시해 취약점 4777건을 발견했다. 이 가운데 109건은 지난 8월 기준 보완을 완료하지 못했다.

금융위도 최근 금융회사의 취약점 점검·평가 제도를 강화하겠다고 밝혔다. 현행 규정에 따라 금융회사는 연 1회, 외부 홈페이지는 연 2회 취약점 점검·평가를 해야 한다. 금융위는 대형 금융회사부터 점검 주기를 연 2회 이상으로 확대하고 중요한 외부 접점을 필수 점검 대상에 포함하는 방안을 추진한다는 계획이다.

오펜시브 보안 전문기업 스틸리언의 보안 전문가는 “공격자는 (금융사 입장에서) 가장 중요한 시스템이 아니라 가장 적은 비용으로 뚫리는 경로를 찾는다”고 짚었다. 이어 “인터넷뱅킹이나 계정계 같은 핵심 서비스는 오랜 기간 투자와 점검이 집중되어 공격 비용이 높다”며 “반면 직원·협력업체용 시스템이나 외부 조회서비스는 보안 수준이 상대적으로 낮으면서도 내부 데이터와 인증 체계에 연결되어 있어, 공격 대상이 되기 쉽다”고 설명했다.

그는 “조회서비스는 적은 인증 정보만으로 개인정보를 반환하는 구조가 많다는 점도 취약한 부분”이라며 “여기서 발생하는 권한 검증 누락이나 식별자 대입 문제는 업무 로직의 결함이어서 자동 스캐너로는 잘 드러나지 않는다”고 지적했다.

이어 “외부 자산 식별과 인증·세션 검증을 우선하고, 자동화된 상시 점검과 전문가의 모의해킹을 병행할 필요가 있다”며 “정기 점검은 정해진 범위를 정해진 시점에 확인하는 방식으로, 점검 사이에 발생하는 취약점에도 대응 방안이 필요하다”고 강조했다. 아울러 “넓은 범위의 반복 검증은 자동화된 상시 체계가 맡고, 전문가는 업무의 특성과 공격 시나리오를 깊이 있게 검증하는 방향으로 역할이 나뉘어야 한다”고 덧붙였다.

글. 바이라인네트워크
<곽중희 기자>god8889@byline.network