금융권 7곳 해킹, 공격자가 업무지원 시스템을 노린 이유
은행 보안이라고 하면 보통 인터넷뱅킹과 모바일뱅킹을 먼저 떠올립니다. 그런데 9월 말부터 이어진 금융권 해킹에서 공격자가 들어간 곳은 그쪽이 아니었습니다. 대출모집인과 외주 인력이 쓰는 업무지원 시스템, 외부에 열려 있던 웹페이지였습니다.
9월 말부터 이어진 금융권 해킹
신한·KB국민·하나·BNK부산은행, 현대캐피탈, 예가람·웰컴저축은행까지 금융사 7곳에서 약 6만6천 명의 정보가 빠져나갔습니다. 예가람저축은행 약 4만 명, 신한은행 약 2만5700명이 가장 많고, 현대캐피탈은 대출모집인 146명, BNK부산은행은 외주 개발 직원 11명의 정보였습니다.
금융위원회는 10월 4일 전 금융업권 협회장과 피해 금융사 대표를 불러 긴급 점검회의를 열고, 약 500개 금융회사에 공격 IP와 보안 유의사항을 공유했습니다. 여러 금융사를 공격한 IP와 수법에서 공통점이 확인됐고, 공격자는 여러 나라의 IP를 바꿔 가며 반복해서 공격했다고 합니다. 금융위원장은 AI를 활용한 공격 가능성도 배제할 수 없다고 밝혔습니다.
왜 업무지원 시스템이 표적이 됐을까요?
이번 사고에서 가장 눈여겨볼 대목은 공격 대상입니다. 고객이 쓰는 핵심 거래 시스템은 수년 동안 보안 투자가 몰린 곳입니다. 반면 대출모집인 포털이나 외주 개발자용 페이지는 쓰는 사람이 적고, 만든 지 오래됐거나 관리 부서가 분명하지 않은 경우가 많습니다.
그렇다고 그 안의 정보까지 가벼운 것은 아닙니다. 신한은행에서 빠져나간 정보에는 이름과 휴대전화번호뿐 아니라 대출 신청과 금리 정보도 들어 있었습니다. 대출모집인이 일하려면 고객 정보를 봐야 하다 보니, 보안 투자가 적은 시스템에도 고객의 대출 정보가 그대로 쌓입니다.
AI 도구를 쓰면 이런 시스템을 찾는 데 드는 시간이 크게 줄어듭니다. 사람이 하나씩 찾아보던 때에는 이런 주변 시스템까지 다 확인하기 어려웠는데, 자동화 도구는 외부에 열린 페이지를 빠짐없이, 빠르게 확인합니다. 공격자들이 AI 에이전트로 여러 금융회사의 외부 시스템을 살피며 보안이 약한 곳을 찾았다는 보도도 나왔습니다. 공격하는 쪽의 비용이 내려가면, 중요도가 낮아 점검이 제때 이루어지지 않았던 시스템이 먼저 뚫립니다.
금융권 밖 기업은 어떨까요?
금융권만의 문제가 아닙니다. 다른 업종에도 이런 업무지원 시스템이 있습니다. 협력사 포털, 대리점 주문 시스템, 외주 인력용 계정, 테스트하다 그대로 둔 페이지는 대부분의 기업에 있습니다. 공공기관과 국방 분야도 대국민 서비스보다 내부 업무용, 협력 업체용 시스템이 훨씬 많습니다.
과학기술정보통신부도 24시간 비상대응체계를 가동하고, 정보보호최고책임자(CISO)를 신고한 기업 약 2만8천 곳에 보안점검 권고 메일을 보냈습니다. 금융권을 포함한 여러 업종에 같은 점검 요청이 간 셈입니다.
AI 에이전트를 업무에 쓰는 기업이라면 한 가지를 더 봐야 합니다. 에이전트 계정도 사람이 잘 들여다보지 않는 주변 계정이 되기 쉽습니다. 파일럿 때 편하게 권한을 많이 준 에이전트 계정이 그대로 남아 있다면, 그 계정도 공격자가 먼저 찾을 곳입니다.
지금 점검해 볼 것
- 외부에 열린 시스템 목록: 고객용 서비스 말고, 협력사·외주·대리점용으로 연 페이지와 계정을 전부 확인해야 합니다. 목록에 없는 시스템은 점검 대상에도 오르지 않습니다
- 외주·협력사 계정의 권한: 프로젝트가 끝난 외주 인력 계정이 살아 있는지, 맡은 업무보다 많은 권한을 갖고 있지 않은지 확인합니다
- 에이전트 계정의 권한: 에이전트가 어떤 시스템에 어떤 권한으로 연결돼 있는지, 작업이 끝나면 권한을 회수하는지 봅니다. 작업 단위로 권한을 나누는 방법은 AI 에이전트 권한 관리 글에서 따로 다뤘습니다
- 접속 기록: 같은 IP나 비슷한 패턴의 요청이 여러 시스템에 들어왔을 때 한곳에서 알아볼 수 있는지 확인합니다. 이번에도 당국은 여러 금융사를 공격한 IP와 수법의 공통점을 근거로 500여 곳에 경고를 공유했습니다
모든 시스템을 같은 수준으로 지킬 수는 없습니다. 다만 무엇이 외부에 열려 있는지 알아야 어디부터 점검할지도 정할 수 있습니다.
하이퍼이지의 접근
하이퍼이지가 Skein OS에 AI Agent를 연결할 때는 에이전트마다 신원을 따로 주고, 어떤 업무 대상을 읽고 쓸 수 있는지를 온톨로지 위에서 정합니다. 시스템 전체를 연결하는 대신 업무 단위로 권한을 주면, 계정 하나가 뚫렸을 때 생기는 피해도 그만큼 줄어듭니다. 에이전트가 무엇을 조회하고 바꿨는지는 사내 시스템에 기록으로 남깁니다.
이번 사고를 보면, 핵심 시스템에 보안 투자를 더 몰아주기보다 그동안 점검 순서에서 뒤로 밀려 있던 계정과 시스템부터 다시 살펴봐야 합니다.