【드래곤 스포츠】 보증업체놀이터추천홍보 : 프로그램제작판매제작의뢰 : 스포츠분석 : 무료스포츠중계tv : 섹시bj움짤 : 뉴스 : 안구정화

로그인

글쓰기

[IT뉴스]운영 점검만으론 '사후약방문'…금융 SI 보안, 발주서·대가부터 바꿔야

온카뱅크관리자

2026-10-08 14:17:26

<div id="layerTranslateNotice" style="display:none;"></div> [IT서비스가 만든 해킹 빈틈 ㊦] 구축 따로, 점검 따로인 금융 SI 구조 
 <div class="article_view" data-translation-body="true" data-tiara-layer="article_body" data-tiara-action-name="본문이미지확대_클릭"> 
 <section dmcf-sid="tuUIJe5Tly">
 <figure class="figure_frm origin_fig" contents-hash="1f4c729d3528b2c764238dd6a70bd3d4d5ed8e538b7201b810243fc72d5baaa9" dmcf-pid="F7uCid1ylT" dmcf-ptype="figure">
 <img class="thumb_g_article" data-org-src="https://t1.daumcdn.net/news/202610/08/552796-pzfp7fF/20261008140721106qcux.jpg" data-org-width="600" dmcf-mid="1C0seMXShW" dmcf-mtype="image" height="auto" src="https://img1.daumcdn.net/thumb/R658x0.q70/?fname=https://t1.daumcdn.net/news/202610/08/552796-pzfp7fF/20261008140721106qcux.jpg" width="658">
 </figure>
 [디지털데일리 박재현기자] 은행권 연쇄 해킹 이후 금융권 보안 대책이 운영 중인 시스템 점검에 집중되고 있다. 외부 노출 자산을 찾아내고 접근통제와 탐지 체계를 다시 점검하는 조치다. 하지만 정기 평가에서 만점을 받고 취약점 조치까지 마친 시스템도 이번 공격을 막지 못했다.
 IT서비스 업계는 운영 단계 점검만으로는 땜질식 처방에 그칠 수 있다고 본다. 구축 검수는 기능 작동 여부를 확인하고, 법정 점검은 운영에 들어간 시스템을 연 1회 점검한다. 개발 단계의 권한 검증은 어느 단계의 확인 항목으로도 명확히 정해져 있지 않다. 정확한 사고 원인은 조사가 진행 중이지만, 일각에서는 금융사가 발주서와 사업 대가에 보안 과업을 명시해야 한다는 주장이 나오고 있다.
 ◆ 만점 받고도 뚫렸다…검수는 기능만, 점검은 운영 이후
 앞서 신한은행은 개인신용정보 보호 실태 점검에서 6년 연속 만점을 받았다. 한국인터넷진흥원(KISA)에 공시된 정보보호 현황에 따르면, 2024년에는 금융감독원 요청으로 본인인증서비스 인증 우회 취약점을 점검하고 조치했다. 그럼에도 이번 사고에서 대출모집인 조회 서비스의 본인확인이 우회됐다.
 통상 금융 시스템은 설계하고 구축하는 주체와 점검하는 주체가 다르다. 금융사는 사업을 발주하고 IT서비스 기업이 경쟁 끝에 사업을 수주, 수행한다. 개발이 끝나면 금융사가 검수를 거쳐 시스템을 넘겨받고, 이후 운영은 금융사 IT 조직이나 운영(SM) 사업자가 맡는다.
 법정 취약점 분석·평가는 이와 별도로 금융보안원이나 정보보호 전문서비스 기업 등이 수행하고, 그 결과를 금융위원회에 보고한다.
 단계마다 확인하는 항목도 다르다. 구축 단계 검수는 계약서에 적힌 기능이 제대로 작동하는지를 본다. 법정 점검은 운영 중인 시스템의 취약점을 본다. 요청자가 해당 데이터를 조회할 권한이 있는지 서버가 확인하도록 설계하는 작업은 개발 단계에서 이뤄져야 하지만, 어느 단계의 확인 항목으로도 명확히 정해져 있지 않다. 권한 검증 누락은 시스템이 운영에 들어간 뒤에야 점검에서 발견된다. 이때는 이미 운영 중인 시스템을 고쳐야 해 수정 부담도 커진다.
 운영 단계 점검은 범위와 주기에도 한계가 있다. 일정 규모 이상 금융사는 전자금융감독규정에 따라 전자금융기반시설의 취약점을 연 1회 이상 분석·평가해야 한다. 점검 범위는 금융사가 파악한 자산 목록에 따라 정해져, 목록에 오르지 않은 API는 대상에서 빠지기 쉽다. API는 수시로 새로 열리는 만큼 점검 주기 사이에 배포된 API는 다음 점검 전까지 검증 없이 운영될 수 있다. 금융위원회는 이번 긴급 점검에서 외부 노출 자산 식별을 첫 항목으로 올렸다.
 실제 구축 단계 검수에는 보안 테스트가 거의 포함되지 않는다. API 기업의 한 관계자는 크리덴셜 스터핑, 다른 고객 번호 조회, 파라미터 변조, 대량 조회 등을 기본 검증 항목으로 꼽으며 "검증 단계에서 보안 테스팅 요소는 대부분 배제돼 있다"고 말했다. 검수가 기능 동작 확인에 그치면 권한 검증 누락 같은 결함은 그대로 운영 시스템에 넘어간다.
 사고 이후 나온 정부 권고도 개발·검수 단계 항목에 집중됐다. KISA는 웹·API 요청마다 서버에서 이용 권한을 검증하고, 사용자 번호 등을 바꿨을 때 다른 사람의 정보가 조회되지 않는지 확인하라고 권고했다. 소스코드와 코드 저장소에 비밀번호나 접근키가 노출되지 않았는지 점검하라는 내용도 담겼다. 모두 시스템을 짓는 과정에서 확인할 수 있는 항목이다.
 IT서비스 업계는 이 같은 보안 검수 누락의 원인으로 현행 발주 구조를 지목한다. 한 IT서비스 업계 관계자는 “SI 사업 검수 단계에서 보안 테스팅이 누락되는 핵심 원인은 발주처의 요구사항 정의서(RFP)에 해당 과업이 구체적으로 명시되지 않기 때문”이라고 지적했다.
 이어 그는 “IT서비스 기업은 계약된 기능의 구현과 기한 준수에 집중할 수밖에 없어, 별도 예산이 배정되지 않은 보안 검증을 원가 부담을 안고 자체 수행하기는 현실적으로 어렵다”며 "더욱이 전사적인 통합 인증 체계가 부재한 기존 인프라 환경에서 개별 사업 수주사가 전체 시스템 아키텍처를 아우르는 보안 로직을 임의로 설계하고 적용하는 것은 계약 범위를 벗어나는 일"이라고 설명했다.
 ◆ 대책은 운영 점검에 쏠려…발주서·사업 대가부터 바꿔야
 현재 사고 이후 나온 초동 조치는 운영 단계 점검에 집중돼 있다. 금융위원회는 긴급 점검회의에서 외부에 노출된 IT 자산 식별, 인증·접근통제 점검, 침해 탐지체계 재점검을 지시했다. 이미 공유된 공격 IP와 수법이 탐지·차단 체계에 반영됐는지도 확인하도록 했다. 모두 운영 중인 시스템을 대상으로 하는 조치다. 시스템을 짓는 단계의 발주 요건과 검수 기준, 사업 대가는 점검 항목에 들어 있지 않다.
 운영 단계 보완만으로는 한계가 존재한다. 예가람저축은행은 지난달 18일부터 열흘간 침입 시도를 받았고, 28일 오후부터 고객 정보가 유출됐지만 이를 인지한 것은 이틀 뒤였다. 이에 대해 API 기업 관계자는 "누구나 AI나 자동화 도구 하나만 있으면 전 세계 수많은 IP로 공격할 수 있다"고 말했다.
 업계는 API 게이트웨이에서 IP 대신 호출자 신원을 대조하는 방식을 대안으로 꼽는다. 다만 게이트웨이는 모든 요청에 공통 정책을 적용하는 수준에 그치고 요청자가 특정 고객의 정보를 조회할 권한이 있는지는 애플리케이션이 판단하게끔 해야 한다. 또한 이러한 기능은 설계 단계에서 적용돼야 한다.
 현재 설계 단계의 보안 요건을 정하는 주체는 발주 금융사다. 금융사가 요구사항 정의서와 계약서에 권한 검증과 보안 테스트를 과업으로 명시하지 않으면, 수행사는 계약된 기능에 맞춰 시스템을 짓는다. 법적 책임도 금융사에 있다. 개인정보보호법은 개인정보 처리 업무를 위탁할 때 문서로 계약하고 수탁자를 교육·감독하도록 규정하고, 수탁자가 법을 위반해 손해가 생기면 수탁자를 위탁자의 소속 직원으로 본다.
 외주 구조가 복잡할수록 금융사가 계약으로 정해야 할 범위도 넓어진다. 금융 SI는 IT서비스 기업이 수주한 뒤 협력사와 인력 공급 업체를 거친 프리랜서가 개발에 투입된다. 금융사가 직접 계약을 맺는 곳은 수행사뿐이기에 보안 요건이 계약서에 없으면 하위 단계에서는 이행 여부를 확인할 방법이 없다.
 이번 공격을 막은 우리은행도 앞서 외주 개발업체를 통해 고객정보가 유출되는 사고를 겪었고, 금감원으로부터 위탁업체 관리 실태 점검을 요구받은 바 있다.
 문제는 보안 과업을 계약서에 넣으려면 그만큼의 비용이 사업비에 잡혀야 한다는 점이다. 공공 SW 사업은 한국소프트웨어산업협회(KOSA)의 SW사업 대가산정 가이드를 기준으로 개발비를 산정한다. KOSA는 발주처의 비기능 요구사항이 개발비에 반영되지 않는다는 지적에 따라 2018년 개정에서 보정계수에 보안성을 넣었다. 민간 금융 발주는 이 가이드를 따를 의무가 없다. 보안 설계와 검증 공수를 사업비에 넣을지는 발주 금융사가 정하고, 이를 정하는 기준도 따로 없다.
 금융권 차세대·AI 사업이 이어지면서 보안 과업을 발주에 반영해야 할 범위도 넓어지고 있다. 금융당국은 2024년 망분리 개선 로드맵을 발표하고 생성형 AI와 서비스형 소프트웨어(SaaS) 활용을 허용했다. 은행들은 차세대 시스템 교체와 AI 에이전트 도입을 추진하고 있다. 삼성SDS는 금융권 첫 전사 AI 에이전트 구축 사업인 우리은행 ‘AI 에이전트 뱅킹' 사업을 수행하고 있고, LG CNS는 NH농협은행 차세대 사업을 수행 중이다. 외부 서비스와 AI 에이전트가 연결될수록 권한 검증이 필요한 API도 늘어난다.
 이에 IT서비스 업계는 발주 요건부터 바뀌어야 한다고 본다. IT서비스 기업 관계자는 "향후 금융권 차세대 및 운영 사업 발주 시, 시스템 설계 초기 단계부터 보안 책임 소재와 검증 범위가 계약서상에 명확히 규정되는 방향으로 사업 요건이 강화돼야 한다"고 주장했다.
 이어 "망분리 규제 완화와 AI 에이전트 도입으로 외부 연계 API가 급증함에 따라, 특정 보안 장비에 의존하던 방식에서 벗어나 애플리케이션 자체에 제로 트러스트 기반의 권한 통제 로직을 구현하는 것이 필수 과업이 될 수밖에 없다"며 "이를 위해 발주처 역시 단순 기능 구현을 넘어 보안 아키텍처 설계와 상세 검증에 소요되는 적정 예산과 기간을 사업 대가 산정 기준에 공식적으로 반영해야 한다"고 덧붙였다.
 금융사들이 당국에 보고할 자체 점검 결과는 운영 중인 시스템의 취약점을 드러내는 데 그친다. 차세대 사업과 AI 에이전트 구축이 이어지는 만큼 요구사항 정의서와 검수 기준, 사업 대가에 보안 과업을 명시하는 일이 대책에 함께 담겨야 한다.
 </section> 
 </div> 
 Copyright © 디지털데일리. All rights reserved. 무단 전재 및 재배포 금지.

댓글 총 0개

이번주 포인트랭킹

매주 일요일 밤 0시에 랭킹을 초기화합니다.

14,000상품권
23,000상품권
32,000상품권

업체홍보/구인 더보기

놀이터홍보 더보기

지식/노하우 더보기

판매의뢰 더보기

포토 더보기