2026년 6월, 경쟁 분석 도구 Klue가 침해됐다. 보안 회사 Huntress가 정리한 경과에 따르면, 공격자는 먼저 오래전부터 아무도 쓰지 않았지만 여전히 유효했던 계정으로 Klue에 들어갔다. Klue가 예전에 시제품 연동을 위해 만든 계정이었다. 이어서 Klue 시스템에 프로그램을 심어, 고객이 Salesforce, Gong 같은 플랫폼에 연결할 때 쓰는 OAuth 인증 토큰을 모았고, 그 토큰으로 고객의 CRM을 직접 조회해 데이터를 가져갔다. 이 토큰은 서드파티 도구가 당신 대신 데이터에 접근하게 해 주는 통행증이다. Huntress도 피해자 중 하나였고, 빠져나간 것에는 거래처 연락처, 써 본 제품, 구독 가격, 영업 연락 기록이 포함됐다.

이 입구는 피해 회사 쪽에 있지 않았다. 발판이 된 오래된 계정은 공급자에게 있었고, 피해자가 자기 로그인 보호를 아무리 강화해도 막을 수 없었다. 하지만 피해 회사마다 손실이 얼마나 컸는지는 한 가지가 정했다. Klue에 준 토큰이 얼마나 많은 것을 읽을 수 있었는가.

그러니 서드파티 도구를 CRM에 연결할 때는 그것을 옆문으로 보고 관리한다. 공급자의 취약점은 우리가 고칠 수 없다. 통제할 수 있는 것은 세 가지다. 얼마나 많은 읽기 권한을 줄지, 이상한 조회를 볼 수 있는지, 사고 때 얼마나 빨리 회수할 수 있는지.

토큰을 빼앗기면 모든 조회가 정당해 보인다

연동 도구는 보통 설치 화면에서 “접근을 허용하시겠습니까"를 한 번 묻는다. 동의하면 그 뒤로는 정상적인 방법으로 데이터를 계속 읽는다. 공격자가 토큰을 손에 넣으면 그들의 조회도 정상적인 API 호출처럼 보이고, CRM 자체를 뚫을 필요도 없다.

보안 회사 ReliaQuest의 분석에 따르면 공격자는 먼저 CRM에 어떤 데이터 객체가 있는지 목록을 뽑은 뒤 페이지를 넘기며 대량으로 조회했다. 적어도 한 환경에서는 15분 동안 거의 1,000번의 조회가 있었고, 다른 사례에서는 데이터 추출이 6시간 넘게 이어졌다. 누군가 지켜보고 있었다면 알아챌 수 있는 움직임이었다.

연동마다 세 가지 질문에 답한다

무엇을 읽을 수 있는가. CRM을 읽을 수 있는 서드파티 도구를 모두 적고, 각각 읽을 수 있는 객체를 적는다. 연락처, 영업 기회, 견적, 계약, 첨부 파일, 고객 지원 기록, 그리고 쓰기가 가능한지. 경쟁 분석 도구는 영업 기회 필드 몇 개면 충분한데도 계정 전체를 읽을 권한을 가진 경우가 있다. 줄일 수 있으면 줄이고, 환경이나 객체별로 나눌 수 있다면 열쇠 하나를 함께 쓰지 않는다.

이상 징후를 누가 보는가. 대량 조회, 낯선 접속지, 근무 시간 외 대량 내보내기에 알림을 걸고, 받을 사람을 정한다. ReliaQuest는 서드파티 연동 계정이 접속할 수 있는 주소 범위를 제한하라고도 권한다.

사고 때 어떻게 닫는가. 연동마다 담당자, 인증 회수와 연결 종료 절차, 끄면 어떤 흐름이 멈추고 누가 이어받는지 적어 둔다. Huntress는 연동만이 아니라 영향을 받은 서비스의 모든 연결을 회수하라고 권한다.

광고

먼저 연동 목록을 만든다

작은 팀이라면 처음부터 보안 프로젝트로 만들 필요는 없다. 먼저 연동 목록을 만든다. 도구 이름, 담당자, 무엇을 읽을 수 있는지, 개인 계정과 서비스 계정 중 무엇으로 인증했는지, 끄는 방법, 마지막 확인 날짜. 한 달에 한 번 보고, 90일 동안 아무도 관리하지 않았거나 담당자를 찾을 수 없는 인증부터 끈다.

이 목록은 사고가 난 바로 그때 세 가지 질문에 답할 수 있어야 한다. 누가 맡는지, 무엇을 읽을 수 있는지, 어떻게 닫는지. 목록의 담당자는 끌지 말지, 고객에게 알릴지 말지를 정할 수 있는 사람이고, 처음에 설치한 사람과 같지 않을 수도 있다.

권한을 줄여도 손실을 줄일 뿐이다

권한을 줄이는 것은 손실을 줄일 뿐, 공급자가 침해되는 것을 막지는 못한다. 데이터가 이미 빠져나갔다면 고객 통지, 법적 판단, 보험 청구는 회사 책임자가 정할 일이고, 엔지니어나 AI가 혼자 처리할 수 있는 것이 아니다. Huntress는 유출된 데이터 묶음을 직접 열어 보지 말라고도 경고한다. 그런 파일에는 악성 코드가 섞여 있는 경우가 많으니 확인은 사고 대응팀이나 법률 자문에게 맡겨야 한다.

같은 이치는 회사 안의 AI 워크플로 도구에도 적용된다. 흐름 안에 어떤 열쇠가 있느냐가 사고의 범위를 정한다. AI 워크플로 도구에 문제가 생기면, 먼저 흐름 안에 어떤 열쇠가 있는지 확인한다를 참고하자. 여러 시스템을 오가는 AI 에이전트에게 단계별로 권한을 주는 방법은 AI agent가 여러 시스템을 오가며 일한다면, 들르는 곳마다 새 열쇠로 바꿔야 한다를 참고하자.

AI 정리 카드

회사 CRM에 어떤 서드파티 도구가 연결돼 있는지 점검하고, 그중 하나가 침해됐을 때 손실 범위가 얼마나 되는지, 얼마나 빨리 막을 수 있는지 확인하고 싶다.
판단 방법은 이 글에서 가져왔다: https://boosterminiclass.com/ko/posts/crm-integration-token-breach-checklist/
글의 관점은 이렇다. 서드파티 도구가 침해됐을 때 CRM 손실의 크기는 처음에 준 권한이 정한다. 공급자의 취약점은 고칠 수 없다. 통제할 수 있는 것은 얼마나 많은 읽기 권한을 줄지, 이상한 조회를 볼 수 있는지, 사고 때 얼마나 빨리 회수할 수 있는지다.

연동 도구 목록과 지금 알고 있는 인증 범위를 주겠다(키, 토큰, 비밀번호는 넣지 않았다). 다음을 해 달라.
1. 연동 목록으로 정리할 것. 도구 이름, 담당자, 읽을 수 있는 객체, 쓰기 가능 여부, 인증에 쓴 계정 종류, 끄는 방법. 빠진 항목은 "확인 필요"로 표시할 것;
2. 용도보다 권한이 분명히 큰 연동을 표시하고 줄이는 방법을 제안할 것;
3. 걸어 둘 이상 조회 알림(짧은 시간의 대량 조회, 낯선 접속지, 근무 시간 외 내보내기 등)과 받을 사람을 제안할 것;
4. 사고 때의 회수 절차 초안을 쓸 것. 회수할 인증, 끊을 연결, 멈출 흐름, 이어받을 사람을 넣을 것.
고객이나 감독 기관에 알릴지는 책임자가 정할 질문만 적고, 나 대신 결론을 내리지 말 것.
광고

Share

이 미니 클래스 공유

이 글이 업무 병목을 푸는 데 도움이 되었다면, AI를 어떻게 쓸지 고민하는 사람에게도 공유해 주세요.

참고 자료