AI 시대 해킹 사고의 교훈, API 보안 체계를 다시 점검해야

[기고] 박현길 소프트프릭 연구소장

보안 사고 이후 가장 중요한 일은 드러난 취약점을 막는 데서 그치지 않고, 같은 문제가 반복되지 않도록 교훈을 얻는 것이다. 최근 국내 금융권에서 잇따른 해킹 사고도 이러한 관점에서 바라볼 필요가 있다. 개별 사고의 원인과 책임은 정확한 조사로 밝혀질 일이지만, 외부 업무지원 시스템이 주요 공격 경로로 거론됐다는 점은 금융권 전반이 되짚어볼 대목이다.

고객 거래 시스템을 엄격하게 보호하더라도 같은 데이터에 접근하는 다른 경로의 관리가 느슨하다면 정보는 유출될 수 있다. 디지털 금융 환경에서는 하나의 고객 데이터가 모바일 서비스와 내부 업무시스템, 외부 협력사 등 여러 경로를 통해 활용된다. 보호 범위도 이러한 연결 전체로 넓혀 잡을 때다.

AI를 활용한 공격 자동화는 이 과제를 더욱 시급하게 만든다. 개별 사고에서 AI가 어떤 역할을 했는지는 아직 구체적으로 밝혀지지 않았지만, 정보 수집과 취약점 탐색, 반복적인 공격 시도가 자동화될수록 기존의 관리 공백이 더 빠르고 넓게 악용될 수 있다. 정기 점검과 수작업만으로 대응하기 어려워지는 이유다.

모든 사고를 애플리케이션프로그래밍인터페이스(API) 취약점으로 설명할 수는 없다. 그러나 외부 업무 채널이 내부 시스템과 고객 데이터에 어떻게 접근하는지 살펴볼 때 API는 우선 점검 대상이다. 이번 사고들을 계기로 어떤 API가 운영되고 있으며 누가 어떤 권한으로 데이터를 이용하는지, 관리 체계 전반을 재정비할 때다.

첫 번째 교훈, 관리 밖의 연결부터 찾는다

외부 업무지원 시스템을 둘러싼 사고가 던지는 질문은 분명하다. 고객 데이터에 접근할 수 있는 모든 경로가 조직의 보안 관리 범위에 포함돼 있는가 하는 것이다.

API는 웹·모바일 서비스와 내부 업무시스템, 외부 협력사, AI 서비스를 연결한다. 서비스가 늘어나고 시스템이 복잡해지면 실제 운영 중인 API와 자산 목록 사이에 차이가 생기기 쉽다. 목록에 등록되지 않은 섀도우 API, 사용이 끝났는데도 운영 환경에 남아 있는 좀비 API, 오래된 시스템에서 계속 쓰이는 API가 관리 밖에 놓일 수 있다.

따라서 점검 대상을 알려진 API의 취약점으로 한정해서는 안 된다. 서비스 구성과 배포 정보, API 명세, 네트워크 트래픽을 교차해 실제 운영 자산을 파악하는 일이 먼저다. 트래픽만으로는 드물게 사용하는 기능이나 오래된 배포 경로를 놓칠 수 있기 때문이다.

발견한 API마다 담당 조직과 인증 방식, 접근 권한, 처리하는 데이터를 함께 기록해 둔다. 협력사가 이용하는 API에도 같은 기준을 적용하고, 서비스 변경과 폐기 시 관련 정보가 함께 갱신되는 구조도 필요하다. 이를 뒷받침하는 것이 개발·운영·보안 조직이 자산 정보와 관리 책임을 공유하는 API 거버넌스다.

보호 수준을 시스템의 이름으로 판단해서도 안 된다. 단순 조회 서비스나 영업지원 시스템이라도 민감한 고객정보를 대량으로 조회할 수 있다면 그만큼 높은 수준의 통제가 필요하다.

국가·공공 분야에서 추진하는 국가망보안체계(N2SF) 역시 업무와 정보의 중요도에 따라 보안 수준을 차등 적용하는 것을 기본 원칙으로 한다. 이러한 관점은 금융권에서도 참고할 만하다. API가 처리하는 데이터의 중요도와 접근 범위에 따라 적절한 보안 정책을 적용하고 관리해야 한다.

두 번째 교훈, 인증 이후의 권한까지 검증한다

고객 데이터로 이어지는 경로를 파악했다면 다음으로 따져볼 것은 접근 권한이다. 정상 계정을 이용한 요청이라고 해서 정상적인 데이터 이용까지 보장되는 것은 아니다.

예를 들어, 정상적으로 로그인한 사용자라도 API 요청에 담긴 고객 식별값을 변경해 다른 고객의 정보를 조회할 수 있다면 접근 권한 검증에 문제가 있는 것이다. 이처럼 개별 데이터에 대한 접근 권한을 제대로 검증하지 않는 문제가 BOLA(Broken Object Level Authorization), 즉 객체 단위 권한 검증 취약점이다.

로그인에 성공했다는 것과 특정 고객이나 계좌 정보를 조회할 권한이 있다는 것은 별개다. 서버는 요청마다 해당 기능을 사용할 권한과 요청한 데이터에 접근할 권한을 검증해야 한다. 응답에는 업무에 필요한 정보만 담고, 조회 범위와 변경 권한도 업무 목적에 맞게 제한하는 것이 기본이다.

이는 제로트러스트가 강조하는 지속적인 검증과 최소권한 원칙에도 부합한다. 내부에서 접속했거나 한 번 인증에 성공했다는 이유로 이후의 접근을 포괄적으로 허용해서는 안 된다. 사람과 시스템, 협력사 각각에 필요한 만큼의 권한을 부여하고, 업무가 바뀌거나 종료되면 권한도 조정하는 것이 원칙이다.

세 번째 교훈, 정상 요청 속 이상 행위를 읽는다

권한 검증과 짝을 이루는 것은 데이터 이용 흐름에 대한 관찰이다. 개별 요청은 정상이어도 일정 시간 동안의 호출을 모아 보면 다른 의미가 드러날 수 있다.

평소 소수의 고객정보만 조회하던 계정이 갑자기 많은 고객을 조회하거나, 식별값만 바꿔가며 반복적으로 데이터를 요청한다면 정상 업무인지 점검이 필요하다. 적은 양의 데이터를 장기간 수집하거나 여러 계정으로 나눠 조회하는 행위도 놓쳐서는 안 된다. 단순 호출 횟수 뿐 아니라 계정의 업무, 조회 대상과 범위, 호출 시간과 순서를 종합적으로 분석할 때 의미 있는 신호를 가려낼 수 있다.

서버 내부의 활동도 또 다른 단서가 된다. 취약점을 노린 요청 이후 예상하지 못한 프로그램이 실행되거나 새로운 외부 통신이 발생한다면 후속 공격을 의심할 수 있다. 서버 내부의 이상 행위를 확인하기 위해 프로세스 실행이나 네트워크 연결을 지속적으로 관찰하는 기술도 활용할 수 있다. 대표적으로 리눅스 환경에서는 eBPF를 이용한 런타임 보안 모니터링이 가능하다.

다만 애플리케이션이 권한 검증을 잘못해 다른 고객의 정보를 반환하는 경우에는 운영체제에서 정상적인 처리로 보일 수 있다. 업무 맥락을 이해하는 API 분석과 서버 내부의 이상 동작을 확인하는 런타임 관찰이 서로 보완하는 구조가 바람직하다. 사고의 교훈을 특정 탐지 기술의 도입으로만 좁혀서는 안 되는 이유다.

AI 도입에도 같은 원칙이 적용된다

기존 시스템에서 얻은 교훈은 새롭게 도입하는 AI 서비스에도 그대로 적용된다. AI 에이전트는 데이터를 조회하고 문서를 작성하며 여러 시스템을 연결해 업무를 수행한다. API와 도구를 연속적으로 호출하는 만큼, AI 에이전트 역시 권한을 부여하고 사용 내역을 추적해야 할 새로운 접근 주체다.

어떤 에이전트가 어떤 API와 데이터에 접근할 수 있는지, 조회와 변경 중 어떤 작업까지 수행할 수 있는지 명확히 정하는 것이 출발점이다. 직원의 권한 전체를 그대로 부여하기보다 업무에 필요한 범위로 제한하고, 중요한 데이터 변경이나 외부 전송에는 담당자의 승인 절차를 두는 것이 바람직하다.

프롬프트 인젝션처럼 AI의 판단을 왜곡하는 공격은 과도한 실행 권한과 결합할 때 피해가 커질 수 있다. 따라서 실행 권한의 검증을 AI 모델의 판단에 맡겨서는 안 된다. AI가 어떤 작업을 요청하든, 호출 주체와 대상 데이터, 허용된 작업 범위에 대한 최종 검증은 실제 업무 API의 몫이다.

AI 게이트웨이는 허용된 AI 서비스와 모델의 사용을 관리하고, 민감정보의 외부 전달을 제한하며, 이용 내역을 기록하는 통제 지점이 될 수 있다. 다만 게이트웨이를 통과했다는 사실이 업무 API의 접근 권한을 보장하지는 않는다. AI 이용 통제와 업무 시스템의 권한 검증이 맞물려 작동하는 구조가 필요하다.

AI를 활용한 방어와 자동 대응에도 기준이 필요하다. 이상 징후를 찾아 호출량 제한이나 추가 인증으로 연결할 수 있지만, 잘못된 판단은 정상적인 금융 서비스에 영향을 줄 수 있다. 조치의 범위와 업무 영향, 복구 가능성을 고려해 자동화 수준을 정하고, 영향이 큰 차단이나 권한 변경은 담당자가 판단하도록 하는 편이 현실적이다.

사고의 교훈을 일상적인 관리 체계로

사고 직후의 긴급 차단과 일제 점검은 필요한 조치다. 그러나 발견된 취약점을 고치는 데 그친다면 비슷한 문제는 다른 시스템과 API에서 다시 나타날 수 있다. 새로운 서비스가 배포되고 협력사가 바뀌며 AI 에이전트가 도입되는 과정에서 자산과 권한 정보는 계속 바뀐다.

따라서 점검 결과를 일회성 조치로 끝내지 않고 상시 관리 절차로 이어가는 것이 관건이다. API마다 책임 주체를 정하고, 배포와 변경 과정에서 권한 검증이 제대로 이뤄지는지 확인하며, 서비스가 종료되면 접근 경로를 폐쇄하고 관련 권한을 회수해야 한다. 사고에서 드러난 문제가 유사한 시스템에도 존재하는지 살피고, 개선 조치가 실제 운영에서 작동하는지까지 검토하는 과정도 빠질 수 없다.

이번 사고들을 특정 금융회사나 개별 시스템의 문제로만 바라봐서는 같은 일을 막기 어렵다. 각 조직이 자신의 환경에도 비슷한 빈틈이 없는지 돌아보고, 이를 지속적으로 발견하고 바로잡는 체계를 갖추는 계기로 삼아야 한다.

API는 웹과 모바일, 내부 업무시스템, 외부 협력사와 AI 서비스를 고객 데이터에 연결하는 핵심 보안 자산이다. 사고를 교훈으로 삼는다는 것은 이 연결을 빠짐없이 파악하고, 필요한 권한만 허용하며, 실제 이용 흐름을 꾸준히 들여다보도록 관리 방식을 바꾸는 일이다. AI 시대의 금융보안은 그 교훈을 일상적인 운영에 얼마나 충실히 반영하느냐에서 시작된다.

글. 박현길 소프트프릭 연구소장