신한·국민·하나·부산은행까지…해커가 노린 곳은 인터넷뱅킹이 아니었다

안녕하세요. 레드펜소프트입니다.

은행 해킹이라는 말을 들으면 인터넷뱅킹이나 모바일뱅킹처럼 고객이 직접 사용하는 금융거래 시스템을 먼저 떠올리게 됩니다. 많은 금융회사도 이러한 핵심 시스템에 높은 수준의 보안 장치를 적용하고 있습니다.

그런데 최근 금융권에서 잇따라 확인된 개인정보 유출 사고는 조금 다른 곳에서 시작됐습니다. 공격 대상은 인터넷뱅킹의 중심 서버가 아니라 임직원, 대출모집인과 외주 인력 등이 사용하는 업무지원 시스템이었습니다.

핵심 시스템을 둘러싼 주변 업무 환경이 새로운 공격 경로가 된 것입니다. 이번 사고는 기업이 어디까지를 중요한 보안 자산으로 관리해야 하는지 다시 묻게 합니다.

여러 금융회사의 업무 시스템에서 확인된 정보 유출

신한은행을 시작으로 KB국민은행, 하나은행, BNK부산은행과 예가람저축은행 등에서 개인정보 유출 사고가 잇따라 확인됐습니다.

신한은행에서는 대출모집인이 고객의 대출 현황을 확인할 때 사용하는 간편조회 서비스가 공격을 받았습니다. KB국민은행은 직원용 모바일 업무지원시스템에서 외부 침해가 발생했으며 하나은행에서는 영업지원시스템에 비정상적인 접근이 이뤄졌습니다.

BNK부산은행에서도 내부 직원용 모바일 영업지원시스템을 대상으로 한 취약점 공격으로 외주 개발 인력의 개인정보가 유출됐습니다. 예가람저축은행은 개인정보가 포함된 서버에 신원 미상의 해커가 접근한 정황을 확인했습니다.

각 사고가 동일한 공격자나 같은 공격 방식에 의해 발생했는지는 아직 확인되지 않았습니다. AI 에이전트가 공격에 활용됐을 가능성도 거론되고 있지만 구체적인 공격 방식은 추가 조사가 필요한 단계입니다.

현재 분명하게 확인되는 공통점은 고객이 이용하는 핵심 금융거래 시스템보다 외부에서 접근할 수 있는 업무지원 시스템과 서비스에서 사고가 발생했다는 점 입니다.

해커는 가장 강한 문보다 관리가 느슨한 출입구를 찾습니다

기업의 핵심 시스템에는 보통 엄격한 인증과 접근통제, 집중적인 보안 모니터링이 적용됩니다. 반면 내부 업무를 지원하기 위해 만들어진 시스템은 상대적으로 관심에서 벗어나기 쉽습니다.

직원용 모바일 시스템, 협력사 포털, 외주 개발 환경, 대출모집인 전용 서비스처럼 이용자가 제한된 시스템도 외부 네트워크에 연결돼 있다면 공격 대상이 될 수 있습니다.

처음에는 작은 업무를 위해 만들어진 서비스였더라도 시간이 지나면 기능이 추가되고 더 많은 데이터와 연결됩니다. 운영 기간이 길어지는 동안 사용하지 않는 기능이나 오래된 라이브러리, 패치되지 않은 소프트웨어가 남을 수도 있습니다.

보안 담당자가 이러한 시스템의 존재와 구성요소를 정확히 알지 못하면 새로운 취약점이 공개돼도 어느 자산이 영향을 받는지 바로 확인하기 어렵습니다. 결국 공격자는 가장 중요한 시스템을 정면으로 돌파하기보다 연결돼 있지만 상대적으로 관리가 느슨한 경로를 찾게 됩니다.

보안의 출발점은 ‘무엇이 연결돼 있는가’를 아는 것입니다

이번 사고 이후 금융당국은 금융회사에 외부로 노출된 전산시스템과 서비스 전반을 점검하도록 요청했습니다. 인증 절차가 빠져 있거나 부족하게 적용된 경로가 있는지 확인하고 불필요한 정보 노출과 비인가 접근 경로를 차단하는 조치도 강조했습니다.

이러한 점검을 제대로 수행하려면 먼저 조직이 보유한 자산을 알아야 합니다.

어떤 업무 시스템이 외부에 연결돼 있는지, 각 시스템에는 어떤 소프트웨어와 오픈소스 구성요소가 포함돼 있는지, 현재 사용 중인 버전은 무엇인지 확인할 수 있어야 합니다. 외부에서 공급받거나 반입한 소프트웨어도 같은 기준으로 살펴봐야 합니다.

하지만 기업의 소프트웨어 정보는 개발·보안·운영 조직에 나뉘어 관리되는 경우가 많습니다. 개발 조직은 소스 코드와 의존성을 관리하고 보안 조직은 취약점 정보를 확인하며 운영 조직은 서버와 프로세스를 관리합니다. 이 정보가 서로 연결되지 않으면 전체 공격 표면을 파악하기 어렵습니다.

SBOM이 필요한 이유

SBOM은 소프트웨어에 포함된 구성요소와 버전, 의존관계 등을 기록한 소프트웨어 구성요소 명세서입니다.

SBOM이 있으면 특정 오픈소스나 라이브러리에서 취약점이 발견됐을 때 해당 구성요소가 어느 소프트웨어에 포함돼 있는지 확인할 수 있습니다. 영향을 받는 시스템을 찾는 시간을 줄이고 패치와 업데이트가 필요한 대상을 판단하는 데도 활용할 수 있습니다.

다만 SBOM 파일을 한 번 생성하는 것만으로는 충분하지 않습니다. 소프트웨어는 계속 변경되고 배포 환경도 달라지기 때문입니다. 개발 과정에서 확인한 구성요소가 실제 서버에 그대로 배포됐는지, 이후 다른 패키지가 추가되지는 않았는지 지속적으로 살펴봐야 합니다.

외부에서 반입한 소프트웨어의 실제 구성과 제출된 SBOM이 일치하는지도 확인할 필요가 있습니다. SBOM은 제출용 문서가 아니라 개발·반입·운영 과정에서 계속 갱신하고 활용해야 하는 보안 정보입니다.

설치된 소프트웨어와 실행되는 소프트웨어는 다를 수 있습니다

운영 서버에 설치된 소프트웨어를 파악하는 것도 중요하지만 보안 대응 순위를 정하려면 실제 실행 상태까지 확인해야 합니다.

같은 취약점이 발견되더라도 외부와 연결된 업무 시스템에서 실행 중인 구성요소와 현재 사용되지 않는 구성요소의 위험은 같지 않을 수 있습니다. 실제로 어떤 서비스와 프로세스가 작동하고 있으며 어느 네트워크에 노출돼 있는지를 함께 살펴봐야 합니다.

또한 현재 실행되지 않는 소프트웨어도 방치된 채 서버에 남아 있다면 잠재적인 공격 표면이 될 수 있습니다. 설치 자산과 실행 자산을 함께 확인해야 불필요한 소프트웨어를 제거하고 실제 위협에 가까운 대상을 먼저 조치할 수 있습니다.

취약점의 개수만 확인하는 방식에서 벗어나 어떤 자산에 영향을 주는지, 실제 실행 중인지, 외부에 노출돼 있는지를 기준으로 대응 순서를 정해야 하는 이유입니다.

개발·반입·운영을 하나의 보안 흐름으로 연결해야 합니다

최근의 금융권 사고가 소프트웨어 공급망 공격으로 확인된 것은 아닙니다. 외부 소프트웨어나 업데이트 경로가 공격에 이용됐다고 단정할 근거도 아직 없습니다.

그럼에도 이번 사고는 공급망 보안과 맞닿아 있는 중요한 질문을 던집니다.

우리 조직은 핵심 시스템뿐 아니라 그 주변에서 작동하는 모든 소프트웨어를 파악하고 있는가?

금융회사처럼 수많은 업무 시스템과 외부 협력 환경을 운영하는 조직에서는 개발 단계의 점검만으로 전체 위험을 관리하기 어렵습니다. 외부에서 들어오는 소프트웨어를 검증하고 운영 환경에 배포된 자산과 실제 실행되는 프로세스를 확인하는 과정이 함께 필요합니다.

이 정보가 하나의 흐름으로 연결돼야 취약점이 발견됐을 때 영향받는 자산과 담당자를 빠르게 찾고 조치 결과까지 지속해서 관리할 수 있습니다.

레드펜소프트 XSCAN이 지원하는 전 주기 공급망 보안

레드펜소프트는 개발·반입·운영 전 과정에서 소프트웨어 구성요소와 위험을 확인하고 관리할 수 있도록 지원합니다.

XSCAN Supply Chain은 소스 코드와 바이너리, SBOM 분석을 통해 자체 개발 소프트웨어와 외부에서 반입하는 소프트웨어의 구성요소 및 취약점을 확인합니다. 소스 코드가 제공되지 않는 소프트웨어도 바이너리 분석을 통해 구성요소를 살펴볼 수 있습니다.

XSCAN Server Runtime은 서버에 배포된 소프트웨어와 실제 실행되는 서비스·프로세스를 분석합니다. 설치된 자산의 현황을 파악하는 동시에 운영 환경의 실제 공격 표면을 확인해 우선 대응할 대상을 판단할 수 있도록 돕습니다.

XSCAN Secure Asset은 개발·반입·운영 전 주기의 소프트웨어 자산과 위험 정보를 연결해 하나의 거버넌스 환경에서 관리할 수 있도록 지원합니다. 분리된 정보를 통합해 취약점 탐지부터 영향 자산 확인, 위험 평가, 담당자 지정과 조치 완료까지 이어지는 관리 체계를 마련할 수 있습니다.

핵심 시스템 밖까지 살펴봐야 할 때입니다

이번 금융권 개인정보 유출 사고는 보안 수준이 높은 산업에서도 관리 범위 밖의 시스템이 공격 경로가 될 수 있다는 사실을 보여줬습니다.

핵심 시스템을 안전하게 보호하는 일은 여전히 중요합니다. 여기에 직원과 협력사가 사용하는 업무 시스템, 외부 접속 서비스, 오래전에 구축된 서버와 방치된 소프트웨어까지 보안 관리 범위에 포함해야 합니다.

공격자는 기업이 가장 중요하게 생각하는 곳만 노리지 않습니다. 연결돼 있으면서도 충분히 관리되지 않는 곳을 찾습니다.

기업이 무엇을 보유하고 있는지 파악하고 소프트웨어 구성요소와 변경 이력을 확인하며 운영 환경에서 실제 실행되는 위험을 살펴보는 체계가 필요한 이유입니다.

이제는 핵심 시스템만 지키는 보안을 넘어 개발·반입·운영 전 과정의 소프트웨어를 지속적으로 확인하고 관리하는 보안으로 나아가야 합니다.