[1편] 해킹 이후, 공격자는 어디까지 갈 수 있을까 — 내가 ACP를 직접 써보려는 이유

최근 보안 사고 뉴스를 보면서 자꾸 같은 질문을 하게 된다.

“공격자가 이미 내부에 들어왔다면, 우리는 무엇을 막을 수 있을까?”

취약점을 찾고 패치하고, 의심스러운 접속을 차단하는 일은 여전히 중요하다. 그런데 계정 하나가 탈취되거나 서버 한 대가 감염됐을 때, 그 피해가 어디까지 이어질지도 함께 생각해야 한다.

한 번의 침투가 다른 서버 접근과 대규모 데이터 유출로 연결되는 구조라면, 최초 침투를 탐지하는 것만으로는 충분하지 않기 때문이다.

나는 이 지점에서 접근 제어의 중요성이 더 커지고 있다고 생각한다. 그리고 그 문제를 직접 살펴보기 위해 QueryPie ACP 커뮤니티 버전을 사용해 보려고 한다.

침투 이후의 피해를 줄이려면

2026년 11월 5일 뉴스1의 「AI 해킹 속도 못 따라잡는다…“침투 이후 통제가 관건”」 기사는 이런 생각을 구체화하는 계기가 됐다.
뉴스1 기사 원문 읽기

기사에서는 AI가 공격에 필요한 시간과 비용을 줄이면서 방어자가 속도 경쟁만으로 대응하기 어려워지고 있다고 설명한다. 특히 눈에 들어온 대목은 침투 이후 공격자가 내부 시스템으로 이동하는 경로를 차단하고, 계정과 서비스의 권한을 업무에 필요한 범위와 기간으로 제한해야 한다는 제언이었다.

공격을 빨리 발견하는 능력과 함께, 발견하기 전까지 공격자가 할 수 있는 일을 줄여 놓는 설계가 필요하다는 뜻으로 읽혔다.

실제 사고에서 드러난 계정과 권한의 문제

실제로 침해사고 신고도 늘고 있다. 과학기술정보통신부와 한국인터넷진흥원이 발표한 보고서에 따르면, 2025년 침해사고 신고 건수는 2,383건으로 2024년 1,887건보다 26.3% 증가했다. 물론 신고 건수가 전체 공격 횟수를 의미하는 것은 아니다. 그래도 기업이 겪는 보안 사고의 부담이 커지고 있음을 보여주는 지표다.
관련 보도: 침해사고 신고 통계 관련 보도

최근 몇 년의 사례를 보면, 그 부담이 커지는 과정을 조금 더 구체적으로 이해할 수 있다.

SK텔레콤 사례 — 확보한 계정정보로 다른 서버까지

2025년 공개된 SK텔레콤 침해사고 최종 조사 결과에서는 공격자가 확보한 계정정보를 이용해 다른 서버로 접근한 과정이 드러났다. 정부 발표에 따르면 일부 서버에 다른 서버의 계정 ID와 비밀번호가 평문으로 저장돼 있었고, 공격자는 이러한 정보를 활용해 음성통화인증 관리서버 등에 접근하고 악성코드를 설치했다.

최초 침투 이후 내부에서 확보한 정보가 다음 시스템으로 이동하는 수단이 된 것이다. 조사에서는 로그가 남아 있지 않은 기간의 일부 정보 유출 여부를 확인할 수 없었다는 한계도 지적됐다. 접근 권한 관리와 기록 보존이 사고의 확산 방지뿐 아니라 피해 범위 확인에도 중요하다는 점을 보여준다.
정부 최종 조사 발표: SK텔레콤 침해사고 정부 최종 조사 발표

Snowflake 고객 환경 사례 — 정상 계정이 유출의 통로로

해외에서는 2024년 Snowflake 고객 환경을 겨냥한 데이터 탈취 사례가 있었다. Mandiant는 자신들이 조사한 사고에서 정보 탈취 악성코드로 유출된 고객 자격증명이 사용됐으며, 해당 계정에 다중인증(MFA)이 설정돼 있지 않았다고 설명했다.

공격자는 고객 계정으로 접속한 뒤 데이터베이스를 살펴보고 데이터를 추출했다. 이 사례의 핵심은 Snowflake 플랫폼 자체의 취약점 공격으로 단정할 수 없다는 데 있다. 탈취된 정상 계정이 데이터에 접근하는 통로가 됐다.
Mandiant 분석: Mandiant의 Snowflake 고객 환경 사고 분석

두 사건의 환경과 원인은 다르다. 그러나 내가 공통으로 주목한 것은 공격자가 계정이나 서버 하나를 확보한 다음, 어떤 권한으로 어디까지 접근할 수 있었는가라는 질문이다.

접속한 뒤 무엇을 할 수 있는지도 관리해야 한다

로그인에 성공했다고 해서 그 계정의 모든 행동이 안전한 것은 아니다. 정상 직원의 계정도 탈취될 수 있고, 정상적인 관리 도구도 공격에 사용될 수 있다. 업무용으로 허용한 데이터 조회가 대규모 유출의 출발점이 될 수도 있다.

그래서 접근 제어는 “접속을 허용할 것인가”에서 한 걸음 더 나아가야 한다고 생각한다.

접근 제어에서 확인해야 할 것은 누가 접속하는지, 어떤 자원에 접근할 수 있는지, 어떤 작업을 언제까지 수행할 수 있는지다. 개인별 계정과 추가 인증, 업무에 필요한 최소 권한, 권한 만료, 민감정보 보호, 접근·작업 이력이 함께 필요하다.

이 기준을 시스템마다 따로 관리하면 빠지는 곳이 생기기 쉽다. DB 권한은 회수했지만 서버 계정은 남아 있을 수 있고, 임시 작업을 위해 부여한 권한이 몇 달 뒤에도 유지될 수 있다. 사람이 늘고 시스템이 복잡해질수록 이런 예외를 일관되게 관리하는 일이 어려워진다.

내가 ACP, 즉 접근 제어 플랫폼이 필요하다고 생각하는 이유가 여기에 있다. 권한 부여와 회수, 작업 통제와 감사 기록을 실제 운영 과정에서 지속적으로 적용할 수 있어야 하기 때문이다.

QueryPie ACP로 살펴보고 싶은 것

이번에 살펴볼 제품은 QueryPie ACP다. 공식 커뮤니티 버전 설치 가이드는 데이터베이스, 서버, Kubernetes, MCP 접근 제어를 핵심 기능으로 소개한다. 제품 문서에는 DB 접근 요청과 승인, 접근 만료일 설정, 읽기 전용 권한, 민감정보 마스킹 같은 기능도 안내돼 있다.

예를 들어 장애 분석을 위해 운영 DB를 확인해야 하는 상황을 생각해 볼 수 있다. 이때 필요한 통제는 특정 작업에 필요한 조회 권한과 사용 기간을 정하는 것이다. 개인정보 원문이 필요하지 않다면 마스킹된 값으로 업무를 수행하도록 하고, 누가 어떤 작업을 했는지 확인할 수 있어야 한다.

그 계정이 탈취되더라도 공격자가 사용할 수 있는 권한의 범위와 시간이 제한된다면 피해를 줄일 여지가 생긴다. 물론 읽기 전용 권한도 민감한 데이터를 과도하게 조회할 수 있다면 유출 위험이 남는다. 실제로 볼 수 있는 데이터와 수행할 수 있는 작업을 점검해야 한다.

AI 에이전트에도 필요한 최소 권한

AI 에이전트가 업무에 참여하면 이 문제는 더 중요해진다. 사람을 대신해 정보를 조회하고 도구를 호출하는 에이전트에 광범위한 권한을 주면, 잘못된 지시나 악성 입력의 영향도 커질 수 있다.

앞서 뉴스1 기사 역시 AI 에이전트에 최소 권한을 부여하고, 결제·삭제·외부 전송 같은 주요 행동에는 사람의 승인을 두는 방향을 제시한다. 나도 에이전트가 사용할 수 있는 도구와 데이터, 실행 가능한 작업을 구분해서 관리해야 한다고 생각한다. QueryPie의 MCP 접근 제어가 이 요구를 어느 범위까지 지원하는지는 이후 실습에서 확인해 보고 싶은 부분이다.

접근 제어를 실제 운영에 적용한다는 것

다만 ACP의 효과는 실제 구성과 운영에 달려 있다.

사용자가 통제 지점을 거치지 않고 DB나 서버에 직접 접속할 수 있다면 정책을 우회할 경로가 남는다. 플랫폼에서 권한을 잘 설정했더라도 원본 시스템의 계정에 과도한 권한이 있거나, 서비스 계정의 비밀번호가 노출돼 있다면 별도의 위험이 생긴다.

따라서 접근 제어는 네트워크 접근 제한, 원본 시스템의 권한 관리, 자격증명 보호, 패치, 단말 탐지, 백업과 함께 설계해야 한다. 감사 로그도 저장하는 것에서 끝나지 않고 검토와 대응으로 이어져야 한다. 앞선 사고들을 특정 제품 하나로 막을 수 있었다고 말하기 어려운 이유다.

이런 조건까지 포함해서 실제로 확인해 보고 싶다.

커뮤니티 버전으로 직접 시작해 보려 한다

QueryPie ACP 커뮤니티 버전은 최대 5명의 활성 사용자를 지원하고, 발급일부터 1년간 유효한 라이선스로 사용할 수 있다. 작은 테스트 환경에서 관리자와 일반 사용자를 나누고 접근 통제의 차이를 살펴보기에 적합해 보인다.

첫 실습에서는 테스트 DB를 연결한 뒤 다음을 확인할 계획이다.

1. 권한이 없는 사용자의 접속은 차단되는가?

2. 접근 요청과 승인을 거쳐 필요한 권한만 받을 수 있는가?

3. 읽기 전용 사용자에게 변경 작업이 제한되는가?

4. 민감정보 마스킹과 접근 만료가 예상대로 적용되는가?

5. 허용된 작업과 차단된 작업은 어떤 기록으로 남는가?

아직 직접 검증한 결과는 없다. 앞으로 이 블로그에 설치 과정부터 설정의 어려움, 통제가 작동한 장면과 추가 조치가 필요했던 부분까지 기록하려고 한다.

내가 ACP를 살펴보는 출발점은 분명하다.

계정 하나나 서버 한 대가 침해됐을 때, 그 사고가 곧바로 조직 전체의 피해로 번지지 않도록 해야 한다.

그 목표를 현실의 운영 환경에서 구현하려면 누가, 어디에, 언제까지 접근하고 무엇을 할 수 있는지 통제할 수 있어야 한다. QueryPie ACP 커뮤니티 버전을 통해 그 통제가 실제로 어떻게 작동하는지 하나씩 확인해 보려 한다.

제품 기능 참고 문서

• QueryPie ACP 커뮤니티 버전 설치 가이드

• DB 접근 요청 사용 가이드

• 데이터 마스킹 관리자 가이드