BI 도구 하나가 뚫리면, 연결된 데이터도 위험해진다

Metabase가 보안 업데이트를 긴급 공지했다.

Metabase는 2026년 8월 6일, Metabase Cloud가 알려지지 않은 0-day 보안 취약점을 이용한 공격을 받았다고 밝혔다. 취약점은 Metabase 1.58 이상 버전에 영향을 미쳤다. 회사는 공격에 사용된 엔드포인트를 즉시 차단했고, 취약점을 빠르게 식별해 패치했다고 설명했다.

Metabase Cloud 고객의 인스턴스는 이미 업그레이드와 패치가 완료됐다.

문제는 self-hosted Metabase 사용자다. 자체적으로 Metabase를 운영하는 조직은 여전히 취약할 수 있다. Metabase는 해당 사용자들에게 즉시 최신 point release로 업그레이드하라고 권고했다. 임시 조치로는 /api/session/reset_password 엔드포인트를 차단하라고 안내했다.

이번 사고는 단순한 웹 애플리케이션 취약점이 아니다.

Metabase는 비즈니스 인텔리전스, 즉 BI 도구다. 기업이 여러 데이터베이스를 연결해 대시보드와 리포트, 쿼리, 시각화를 만드는 데 쓴다. 영업, 재무, 고객지원, 제품, 운영, 마케팅, 경영진이 데이터를 쉽게 조회하도록 돕는 도구다.

하지만 바로 그 이유 때문에 위험하다.

BI 도구는 데이터를 직접 만들지는 않지만, 데이터를 볼 수 있는 권한을 모은다. 여러 데이터베이스의 연결 정보와 자격 증명을 저장하고, 사용자가 손쉽게 데이터를 조회할 수 있도록 한다. 따라서 BI 도구가 침해되면 단순히 대시보드 몇 개가 유출되는 데 그치지 않는다. 연결된 데이터베이스 전체로 공격 범위가 넓어질 수 있다.

Metabase가 이번 공지에서 밝힌 위험도 바로 이 지점이다.

공격자는 Metabase 인스턴스에 접근한 뒤 Metabase 애플리케이션 데이터베이스에 임의 SQL을 주입할 수 있었다. 이를 통해 인스턴스 관리자 권한을 얻을 수 있고, 이후 애플리케이션 설정을 변경하거나, 연결된 데이터베이스의 저장 자격 증명을 훔치거나, 그 연결을 통해 접근 가능한 데이터를 읽고 내보낼 수 있었다.

BI 도구가 데이터의 창문에서 데이터의 통로로 바뀌는 순간이다.

Framework 고객 안내문이 보여준 현실 피해

이번 사고는 Framework 고객 안내문을 통해 현실 피해 가능성이 더 선명하게 드러났다.

Framework는 고객에게 보낸 안내문에서 자사의 비즈니스 인텔리전스 데이터베이스 제공자인 Metabase에서 데이터 침해가 발생했고, 그 결과 공격자가 고객 이름, 이메일 주소, 전화번호, 주소에 접근했다고 밝혔다. 안내문은 해당 고객 정보가 침해된 데이터베이스 안에 있었으며, 주문정보나 결제정보는 포함되지 않았다고 설명했다.

Framework는 외부 데이터베이스 벤더에 데이터를 저장하는 방법론을 검토하고 개선하고 있다고 했다. 또한 관련 규제가 존재하는 각 지역의 규제기관에 통지하는 절차도 진행 중이라고 밝혔다. 대부분 지역에서는 이름, 이메일 주소, 전화번호, 주소 침해만으로는 통지가 요구되지 않을 수 있지만, 고객이 상황을 인지하고 필요한 조치를 할 수 있도록 안내 메일을 보낸다고 설명했다.

이 안내문은 Metabase 사고의 성격을 이해하는 데 중요하다.

침해된 것은 Metabase라는 도구다. 그러나 피해 안내를 받은 것은 Framework 고객이다. 즉 데이터 분석 도구의 보안 사고가 실제 기업 고객정보 유출로 이어진 것이다.

여기서 중요한 질문이 나온다.

기업은 BI 도구에 어떤 고객정보를 넣고 있는가.
해당 도구는 외부 벤더가 운영하는가, 자체 호스팅인가.
연결된 데이터베이스 자격 증명은 어떻게 저장되는가.
BI 도구 계정이 침해됐을 때 어떤 데이터까지 볼 수 있는가.
고객정보와 결제정보, 주문정보는 분리되어 있는가.
침해 발생 시 어떤 고객에게 통지해야 하는가.

BI 도구는 편리하다.

하지만 편리한 만큼 데이터 경계가 흐려진다.

Metabase는 어떤 도구인가

Metabase는 기업과 개발팀이 데이터베이스를 연결해 대시보드와 리포트를 만들 수 있게 해주는 오픈소스 기반 BI 도구다.

사용자는 SQL을 직접 쓰거나, 시각적 인터페이스를 통해 데이터를 조회한다. 제품 지표, 매출 현황, 고객 행동, 주문 데이터, 마케팅 성과, 운영 상태 등을 대시보드로 만들 수 있다. 스타트업과 기술 기업, 데이터팀이 비교적 쉽게 도입할 수 있어 널리 사용된다.

Metabase의 장점은 접근성이다.

전문 데이터 분석가가 아니어도 데이터를 볼 수 있다. 여러 부서가 하나의 대시보드를 공유할 수 있다. 데이터베이스에 직접 접속하지 않아도 Metabase를 통해 필요한 정보를 조회할 수 있다.

하지만 보안 관점에서 이 장점은 동시에 위험이다.

Metabase는 여러 데이터베이스의 중간에 선다. 사용자는 Metabase에 로그인해 다양한 데이터를 조회한다. 관리자는 데이터베이스 연결 정보를 저장한다. 권한 설정이 잘못되거나 취약점이 악용되면, 공격자는 Metabase를 통해 연결된 데이터에 접근할 수 있다.

즉 Metabase는 데이터의 허브다.

허브가 뚫리면 연결된 선들이 모두 위험해진다.

취약점의 위험: 관리자 권한과 저장 자격 증명

Metabase 공지에서 가장 중요한 부분은 공격 이후 가능한 행동이다.

공격자는 취약한 인스턴스에 접근한 뒤 Metabase 애플리케이션 데이터베이스에 임의 SQL을 주입할 수 있었다. 이는 공격자에게 관리자 권한을 줄 수 있다.

관리자 권한은 단순 UI 권한이 아니다.

Metabase 관리자는 연결된 데이터베이스 설정을 볼 수 있고, 사용자를 관리하고, 대시보드와 질문, 쿼리 기록을 확인할 수 있다. 설정에 따라 저장된 데이터베이스 자격 증명에 접근하거나 이를 이용해 연결된 데이터베이스를 조회할 수 있다.

Metabase는 공격자가 애플리케이션 구성을 변경하고, 연결된 데이터베이스의 저장 자격 증명을 훔치고, 그 연결을 통해 접근 가능한 모든 데이터를 읽고 내보내는 것이 가능하다고 설명했다.

이것이 치명적이다.

BI 도구 침해는 단순 계정 탈취가 아니다.
관리자 권한 탈취는 데이터 연결 전체를 위협한다.
저장 자격 증명 탈취는 Metabase 밖의 데이터베이스까지 위험하게 한다.
쿼리 기록과 활동 기록은 공격자가 어떤 데이터가 중요한지 알게 해준다.

기업이 Metabase를 내부망에서만 쓴다고 생각해도, 인스턴스가 인터넷에 노출되어 있거나 취약 엔드포인트가 공개되어 있으면 위험은 현실이 된다.

공격 패턴은 로그에서 찾을 수 있다

Metabase는 공격 패턴도 공개했다.

공격은 대체로 POST /api/session/reset_password 호출에서 400 상태 코드가 발생한 뒤, GET /api/user/current 호출에서 200 상태 코드가 이어지는 형태로 나타난다.

Metabase는 애플리케이션 로그나 서버 ingress 로그에서 이 패턴을 발견하면 인스턴스가 침해됐을 가능성이 높다고 밝혔다.

이 정보는 self-hosted 운영자에게 매우 중요하다.

업그레이드만으로 끝나지 않기 때문이다.

이미 공격이 발생했을 수 있다. 따라서 패치 이후에도 로그를 확인해야 한다. 해당 패턴이 있다면 세션, API 키, 관리자 계정, 연결 DB 자격 증명, 데이터 웨어하우스 로그, Metabase 활동과 쿼리 기록까지 점검해야 한다.

보안 사고 대응에서 흔한 실수가 있다.

패치하면 끝났다고 생각하는 것이다.

하지만 취약점이 이미 악용됐다면 공격자는 세션을 확보했거나, API 키를 만들었거나, 관리자 계정을 바꿨거나, 데이터베이스 자격 증명을 가져갔을 수 있다. 이 경우 패치만으로는 부족하다.

패치는 문을 닫는 일이다.
사고 대응은 이미 들어온 흔적을 찾는 일이다.

둘은 다르다.

즉시 해야 할 조치들

Metabase는 /api/session/reset_password 엔드포인트가 공개 접근 가능했다면 업그레이드 후 여러 조치를 취하라고 안내했다.

먼저 모든 활성 사용자 세션을 무효화해야 한다. Metabase Application Database에 접근해 core_session 테이블의 모든 행을 삭제하는 방식이다. 이는 공격자가 획득했을 수 있는 세션을 끊기 위한 조치다.

다음으로 API 키를 검토하고 알 수 없는 키를 삭제해야 한다. 공격자가 지속 접근을 위해 API 키를 만들어뒀을 수 있기 때문이다.

관리자 계정도 확인해야 한다. 예상치 못한 관리자 추가나 권한 변경이 있었는지 봐야 한다.

연결된 데이터베이스의 자격 증명도 교체해야 한다. BI 도구에 저장된 DB 계정이 탈취됐을 가능성이 있기 때문이다.

데이터 웨어하우스 로그도 확인해야 한다. 권한 없는 접근이나 비정상 쿼리가 있었는지 봐야 한다.

마지막으로 Metabase activity와 query history에서 예상치 못한 활동이나 무단 활동을 검토해야 한다.

이 조치들은 모두 같은 원칙을 따른다.

Metabase만 보지 말고, Metabase를 통해 연결된 데이터 경로 전체를 보라는 것이다.

클라우드 고객과 self-hosted 고객의 차이

Metabase는 Metabase Cloud 고객의 인스턴스는 이미 업그레이드와 패치가 완료됐다고 밝혔다.

반면 self-hosted 고객은 직접 조치해야 한다. 이 차이는 오픈소스·SaaS형 소프트웨어에서 반복되는 중요한 문제다.

클라우드 서비스는 공급자가 패치를 중앙에서 적용할 수 있다. 고객은 상대적으로 빠르게 보호받는다. 하지만 self-hosted 환경은 고객이 직접 버전을 확인하고, 업데이트하고, 로그를 점검하고, 자격 증명을 교체해야 한다.

self-hosted는 통제력이 크다.
하지만 책임도 크다.

특히 보안 업데이트 대응 속도는 고객 조직의 운영 역량에 달려 있다. 작은 스타트업이나 개발팀은 Metabase를 쉽게 설치해 쓸 수 있지만, 취약점이 나오면 즉시 업그레이드하고 로그를 분석할 보안 역량이 부족할 수 있다.

이번 공지는 self-hosted 도구 운영의 현실을 다시 보여준다.

설치가 쉽다고 운영 책임까지 쉬운 것은 아니다.

안전 버전과 버전 관리의 중요성

Metabase는 각 주요 버전별 최소 안전 릴리스를 제시했다.

63 계열은 0.63.5, 62 계열은 0.62.9, 61 계열은 0.61.11, 60 계열은 0.60.17, 59 계열은 0.59.21, 58 계열은 0.58.24 이상으로 업그레이드해야 한다. 예를 들어 0.58.6을 사용 중이라면 0.58.24 이상으로 올려야 한다. 58보다 낮은 버전은 취약하지 않다고 설명했다.

이 안내는 버전 관리가 얼마나 중요한지 보여준다.

많은 조직은 “우리는 Metabase를 쓰고 있다”는 사실은 알아도 정확히 어떤 버전을 쓰는지, 어떤 인스턴스가 어디에 있는지, 누가 관리하는지 명확히 모를 수 있다. 개발팀이 임시로 설치한 BI 도구가 나중에 운영 도구가 되는 경우도 많다.

보안 사고 대응의 첫 단계는 자산 식별이다.

어떤 버전을 쓰는가.
인터넷에 노출되어 있는가.
어떤 데이터베이스와 연결되어 있는가.
어떤 계정 권한으로 연결되어 있는가.
누가 관리자 권한을 갖고 있는가.
로그는 어디에 저장되는가.

이 질문에 답하지 못하면 패치도 제대로 할 수 없다.

BI 도구는 ‘읽기 전용’이어도 위험하다

많은 조직은 BI 도구를 읽기 전용으로 설정하면 안전하다고 생각한다.

물론 읽기 전용 권한은 중요하다. 데이터베이스를 수정할 수 있는 계정보다 위험이 낮다. 하지만 읽기 전용도 데이터 유출에는 충분하다. 공격자가 고객정보, 매출정보, 운영지표, 내부 분석자료, 개인정보, 로그 데이터를 읽고 내보낼 수 있다면 기업 피해는 크다.

더구나 BI 도구에는 종종 광범위한 읽기 권한이 부여된다.

대시보드가 여러 부서에 필요하다는 이유로 많은 테이블에 접근 권한이 열린다. 분석 편의를 위해 운영 DB 복제본이나 데이터 웨어하우스에 넓은 권한을 준다. 관리자는 “조회만 가능하니 괜찮다”고 생각할 수 있다.

하지만 공격자에게는 조회 권한만으로도 충분하다.

고객 목록.
이메일 주소.
전화번호.
주소.
주문 이력.
사용자 행동 로그.
매출 데이터.
계약 정보.
내부 운영 지표.

이 모든 것이 기업의 민감 데이터다.

Framework 안내문에서 주문·결제정보는 포함되지 않았다고 밝힌 것은 그나마 피해 범위가 제한됐음을 말한다. 그러나 이름, 이메일, 전화번호, 주소만으로도 피싱, 스미싱, 사회공학 공격에 활용될 수 있다.

읽기 전용은 무해가 아니다.

외부 벤더 데이터 저장 방식의 재검토

Framework는 안내문에서 외부 데이터베이스 벤더에 데이터를 저장하는 방법론을 검토하고 개선하고 있다고 밝혔다.

이 문장은 이번 사고의 후속 과제를 잘 보여준다.

기업은 데이터 분석과 BI를 위해 외부 SaaS 또는 오픈소스 도구를 사용한다. 데이터 일부를 외부 서비스에 저장하거나, 외부 도구가 내부 데이터베이스에 접근하도록 자격 증명을 제공한다. 이는 효율적이지만, 데이터 경계가 복잡해진다.

외부 벤더가 침해되면 어떤 데이터가 노출되는가.
해당 벤더에는 최소한의 데이터만 제공되는가.
개인정보는 가명화 또는 최소화되어 있는가.
연결 자격 증명은 회전되고 있는가.
벤더 계정 권한은 최소 권한인가.
로그와 감사 기록은 확보되는가.
침해 통지 의무는 계약에 명확한가.

이런 질문이 필요하다.

데이터 분석은 더 많은 데이터를 한곳에 모으려는 유혹을 만든다. 그러나 보안은 필요한 만큼만 모으라고 요구한다. BI 도구는 이 긴장이 집중되는 지점이다.

데이터가 많을수록 분석은 좋아진다.

하지만 침해 피해도 커진다.

규제 통지의 회색지대

Framework 안내문에는 규제 통지에 관한 흥미로운 설명도 있다.

회사는 관련 규제가 존재하는 각 지역의 규제기관에 통지하는 절차를 진행 중이라고 밝혔다. 동시에 대부분 지역에서는 이름, 이메일 주소, 전화번호, 주소 침해만으로는 통지가 요구되지 않을 수 있다고 설명했다. 그럼에도 고객에게 가시성을 제공하고 필요한 조치를 할 수 있게 하기 위해 이메일을 보낸다고 했다.

이 대목은 개인정보 침해 통지의 회색지대를 보여준다.

모든 데이터 침해가 동일한 규제 의무를 만들지는 않는다. 지역별 법률은 침해된 정보의 종류, 민감도, 위험 수준, 암호화 여부, 피해 가능성에 따라 통지 요건을 다르게 둔다. 결제정보나 주민번호, 건강정보, 비밀번호가 포함되면 통지 의무가 강해질 수 있다. 반면 이름과 연락처만으로는 지역에 따라 의무가 다를 수 있다.

하지만 법적 의무와 고객 신뢰는 다르다.

법적으로 반드시 통지하지 않아도, 고객에게 알려야 하는 상황이 있다. Framework가 고객에게 안내한 것은 이 신뢰 차원의 대응으로 볼 수 있다.

데이터 침해 대응에서 중요한 것은 “법적으로 최소한만 했는가”가 아니다.

고객이 자신의 정보가 어떤 상황에 놓였는지 알고 대응할 수 있게 했는가다.

공격 이후 고객에게 남는 위험

Framework는 주문정보와 결제정보는 포함되지 않았다고 밝혔다.

이는 중요한 안심 요소다. 그러나 고객 이름, 이메일 주소, 전화번호, 주소가 노출됐다면 위험이 완전히 사라지는 것은 아니다.

공격자는 이런 정보를 이용해 피싱과 스미싱을 시도할 수 있다. Framework 고객을 대상으로 제품 배송, 보증, 리콜, 결제 확인, 계정 보안, 할인 쿠폰 등을 가장한 메시지를 보낼 수 있다. 이름과 주소, 전화번호가 함께 있으면 메시지는 더 그럴듯해진다.

따라서 고객에게 필요한 조치는 다음과 같다.

Framework 또는 Metabase를 사칭한 이메일과 문자에 주의해야 한다.
비밀번호나 결제정보를 요구하는 링크를 클릭하지 않아야 한다.
주문·배송 관련 메시지도 공식 웹사이트에서 직접 확인해야 한다.
의심스러운 전화나 문자는 고객센터 공식 채널로 확인해야 한다.
같은 이메일을 다른 서비스 로그인에 쓰는 경우 계정 보안 알림을 점검해야 한다.

데이터 침해는 한 번의 유출로 끝나지 않는다.

그 뒤에 이어지는 사회공학 공격이 더 큰 피해를 만들 수 있다.

한국 기업에 주는 시사점

한국 기업들도 Metabase 같은 BI 도구를 많이 사용한다.

스타트업, SaaS 기업, 커머스 기업, 금융사, 공공기관, 연구기관, 제조기업까지 데이터 대시보드와 리포트를 위해 BI 도구를 연결한다. 자체 호스팅을 하거나, 클라우드형으로 사용하거나, 내부망에 설치한다.

이번 사고는 한국 기업에도 몇 가지 점검 항목을 던진다.

첫째, BI 도구가 인터넷에 노출되어 있는지 확인해야 한다. 관리자 페이지와 API 엔드포인트가 외부에서 접근 가능하면 위험하다.

둘째, 버전과 패치 상태를 관리해야 한다. 오픈소스 도구는 설치 후 방치되기 쉽다. 담당자와 업데이트 절차가 명확해야 한다.

셋째, 연결 DB 자격 증명을 최소 권한으로 설정해야 한다. BI 조회에 필요한 범위만 허용하고, 관리자성 권한이나 쓰기 권한을 주지 않아야 한다.

넷째, 자격 증명은 주기적으로 회전해야 한다. 침해가 의심되면 즉시 교체할 수 있어야 한다.

다섯째, 쿼리 로그와 활동 기록을 보존하고 모니터링해야 한다. 누가 어떤 데이터를 조회했는지 알아야 사고 대응이 가능하다.

여섯째, 개인정보가 포함된 테이블은 BI 도구 접근 범위를 별도로 제한해야 한다. 모든 직원이 대시보드에서 고객 연락처를 볼 필요는 없다.

일곱째, 외부 SaaS와 BI 도구에 제공하는 데이터는 최소화해야 한다. 분석에 필요 없는 원본 개인정보를 그대로 넣지 않는 설계가 필요하다.

여덟째, 침해 통지 기준을 사전에 정해야 한다. 어떤 데이터가 유출되면 누구에게, 언제, 어떤 방식으로 알릴지 준비해야 한다.

한국에서도 개인정보보호법과 정보통신망 관련 규제, 산업별 보안 기준은 데이터 침해 대응을 요구한다. 특히 고객 연락처와 주소가 포함된 경우 사회공학 피해 가능성까지 고려해야 한다.

BI 도구는 내부 편의 도구로 취급하기에는 너무 많은 데이터 접근권을 갖고 있다.

데이터 분석 권한은 보안 권한이다

이번 사고가 던지는 가장 중요한 교훈은 이것이다.

데이터 분석 권한은 보안 권한이다.

기업은 종종 분석 도구 접근을 업무 편의 차원에서 다룬다. 더 많은 사람이 대시보드를 보면 데이터 기반 의사결정이 쉬워진다. 그러나 데이터 접근권이 넓어질수록 침해 피해도 커진다.

특히 BI 도구는 여러 데이터를 연결하고, 사용자가 쉽게 조회하게 만들고, 쿼리 기록과 대시보드를 저장한다. 이는 공격자에게 매우 매력적이다. 복잡한 데이터베이스 구조를 몰라도 BI 도구를 통해 무엇이 중요한지 볼 수 있기 때문이다.

따라서 BI 도구에는 다음 원칙이 필요하다.

최소 권한.
네트워크 제한.
강한 인증과 MFA.
관리자 계정 최소화.
감사 로그.
정기 패치.
자격 증명 회전.
민감 데이터 마스킹.
쿼리 이력 모니터링.
외부 공유 제한.

데이터를 보기 쉽게 만드는 도구일수록, 보안은 더 어려워진다.

편리한 조회는 공격자에게도 편리하다.

결론: 대시보드는 데이터의 끝이 아니라 시작점이다

Metabase의 보안 사고는 BI 도구 보안의 중요성을 다시 확인시켰다.

Metabase는 1.58 이상 버전에 영향을 미치는 0-day 취약점을 악용한 공격을 공개했고, Cloud 고객은 이미 패치됐지만 self-hosted 사용자는 즉시 업그레이드해야 한다고 안내했다. 취약한 인스턴스가 침해되면 공격자는 임의 SQL을 통해 관리자 권한을 얻고, 애플리케이션 설정을 바꾸고, 연결된 데이터베이스의 저장 자격 증명을 훔치고, 접근 가능한 데이터를 읽고 내보낼 수 있다.

Framework 고객 안내문은 이 위험이 실제 고객정보 유출로 이어질 수 있음을 보여줬다. 공격자는 고객 이름, 이메일 주소, 전화번호, 주소에 접근했다. 주문정보나 결제정보는 포함되지 않았지만, 연락처와 주소만으로도 피싱과 사회공학 위험은 남는다.

이번 사건의 본질은 Metabase라는 특정 제품의 취약점만이 아니다.

기업이 데이터를 분석하기 위해 만든 편리한 통로가 공격자에게는 데이터 접근의 지름길이 될 수 있다는 점이다. BI 도구는 여러 데이터베이스의 자격 증명과 접근권을 모은다. 따라서 BI 도구 보안은 대시보드 보안이 아니라 기업 데이터 보안이다.

데이터 분석은 기업 경쟁력이다.

하지만 분석 도구가 뚫리면, 그 경쟁력은 침해 경로가 된다.

앞으로 기업은 BI 도구를 단순 내부 업무도구로 보아서는 안 된다. 인터넷 노출을 줄이고, 버전을 관리하고, 연결 자격 증명을 최소 권한으로 설정하고, 로그를 모니터링하고, 민감 데이터를 분리해야 한다. 외부 벤더와 self-hosted 도구 모두 같은 기준으로 봐야 한다.

대시보드는 데이터를 보여주는 화면이다.

하지만 보안 관점에서는 데이터로 들어가는 문이다.

그 문을 어떻게 잠그느냐가 이번 Metabase 사고가 남긴 가장 중요한 질문이다.