"Percona" 태그로 연결된 3개 게시물개의 게시물이 있습니다.

DB를 지키려고 붙인 모니터링 도구가 DB로 들어가는 문이 되면 곤란하겠죠. 2026년 8월 19일 Percona가 자사 모니터링 제품에서 그런 경로를 공개했습니다.

Percona 보안 공지의 대상은 Percona Monitoring and Management(PMM) 3.9.0 이하입니다. CVSS는 8.7, CVE 번호는 공지 시점에 아직 배정되지 않았고 배정되면 공지를 갱신한다고 적혀 있습니다.

문제의 모양​

PMM은 Grafana를 화면으로 쓰고, 쿼리 분석 데이터를 ClickHouse에 담습니다. 문제는 그 둘을 잇는 데이터소스 설정에 있었습니다.

두 가지가 겹칩니다. 첫째, Grafana는 로그인한 사용자가 raw data source API에 접근하는 것을 허용합니다. Viewer 역할도 포함입니다. 대시보드만 볼 수 있는 계정이 데이터소스에 직접 쿼리를 보낼 수 있다는 뜻입니다. 둘째, ClickHouse 데이터소스가 연결할 때 쓰는 기본 신원이 전역 DDL, DML, SOURCES 권한을 가지고 있었습니다.

Grafana에서 anonymous access를 켜 두면 로그인하지 않은 사용자까지 이 경로에 닿습니다. 기본값은 꺼져 있습니다. 이 조건은 명확히 해 두는 게 좋습니다. 뒤에 나오는 전체 공격 체인은 anonymous access가 켜져 있고 AWS EC2에 올라간 배포에서 성립합니다.

SOURCES 권한이 실제로 무엇을 여는가​

공지가 url() 함수를 언급하는데, ClickHouse를 자주 다루지 않으면 이게 왜 위험한지 감이 안 옵니다. 직접 확인해 봤습니다. 기본 설정으로 ClickHouse 컨테이너를 띄웠습니다.

$ docker run -d --name chtest -e CLICKHOUSE_PASSWORD=pw \
    clickhouse/clickhouse-server:latest
$ docker exec chtest clickhouse-client --password pw -q "select version()"
26.7.5.10

default 사용자가 가진 권한을 그대로 뽑아 봤습니다.

show grants for default;

GRANT SOURCES ON *.* TO default
GRANT TABLE ENGINE ON * TO default
GRANT CHECK, SHOW, SELECT, INSERT, ALTER, CREATE, DROP, UNDROP TABLE,
      TRUNCATE, OPTIMIZE, BACKUP, KILL QUERY, KILL TRANSACTION,
      MOVE PARTITION BETWEEN SHARDS, SYSTEM, dictGet,
      displaySecretsInShowAndSelect, INTROSPECTION, CLUSTER,
      FILE, URL, REMOTE, MONGO, REDIS, MYSQL, POSTGRES, SQLITE,
      ODBC, JDBC, HDFS, S3, HIVE, AZURE, KAFKA, NATS, RABBITMQ,
      YTSAURUS, ARROW FLIGHT, SOURCES ON *.* TO default

목록을 보면 성격이 드러납니다. FILE, URL, REMOTE, S3, MONGO, MYSQL, POSTGRES, HDFS가 전부 들어 있습니다. SOURCES는 이들을 묶은 상위 권한입니다.

이게 뜻하는 바는 ClickHouse의 쿼리가 데이터베이스 안에서 끝나지 않는다는 것입니다. url() 테이블 함수는 SELECT 문 안에서 HTTP 요청을 보냅니다. s3()는 S3 버킷을 읽습니다. file()은 서버 로컬 파일을 테이블처럼 읽습니다. SELECT 권한만 있는 계정이 아니라, HTTP 클라이언트를 겸하는 계정이 되는 셈입니다.

file()에는 별도 울타리가 하나 더 있습니다. 임의 경로는 막습니다.

$ clickhouse-client -q "select count() from file('/etc/hostname','LineAsString')"
Code: 291. DB::Exception: File `/etc/hostname` is not inside
`/var/lib/clickhouse/user_files`. (DATABASE_ACCESS_DENIED)

user_files 디렉터리 밖은 거부됩니다. 다만 그 안이라면 그대로 읽힙니다.

$ docker exec chtest sh -c 'echo secret-token-abc > /var/lib/clickhouse/user_files/t.txt'
$ clickhouse-client -q "select * from file('t.txt','LineAsString')"
secret-token-abc

네트워크 쪽은 울타리가 없습니다. 권한이 실제로 통과하는지 확인하려고 닫힌 포트를 겨냥해 봤습니다.

$ clickhouse-client -q "select * from url('http://127.0.0.1:1/x','LineAsString')"
Code: 1000. DB::Exception: Connection refused. (POCO_EXCEPTION)

돌아온 것이 권한 거부가 아니라 연결 거부입니다. 권한 검사를 통과해 실제로 소켓을 열려고 시도했다는 뜻입니다. 겨냥한 주소가 열려 있었다면 요청이 나갔을 것입니다. SELECT 문 하나가 DB 서버에서 출발하는 HTTP 요청이 되는 지점입니다.

공격 체인​

공지가 설명하는 흐름은 네 단계입니다.

url() 함수로 AWS IMDSv1에 요청을 보냅니다. 인스턴스 메타데이터 서비스의 v1은 토큰 없이 GET 하나로 응답합니다. 여기서 EC2 인스턴스에 붙은 role의 임시 자격증명을 얻습니다.

그 자격증명으로 S3에 접근해 Terraform state 파일을 읽습니다. state 파일에는 인프라 구성이 그대로 들어 있고, 관리자 비밀번호 같은 값이 평문으로 남아 있는 경우가 흔합니다.

마지막으로 그 값으로 PMM 관리자로 인증합니다. 모니터링 시스템의 관리자가 되면 감시 대상 DB의 접속 정보를 그 안에서 찾을 수 있습니다.

단계마다 그 자체로는 알려진 문제입니다. IMDSv1이 토큰 없이 응답하는 것도, Terraform state에 비밀이 남는 것도 오래된 이야기입니다. 이 공지가 보여 주는 건 그 알려진 약점들이 SELECT 권한 하나로 연결된다는 점입니다.

수정과 완화​

수정 버전은 PMM 3.9.1이고 2026년 8월 19일 나왔습니다. 근본 수정은 이쪽입니다.

바로 올릴 수 없는 환경을 위해 공지가 완화 스크립트를 함께 제공합니다. 방향은 단순합니다. 데이터소스가 쓰는 계정을 읽기 전용으로 새로 만들고, SOURCES 계열을 주지 않는 것입니다.

CREATE USER IF NOT EXISTS grafana_ro
  IDENTIFIED WITH plaintext_password BY '<password>'
  SETTINGS readonly = 1;
GRANT SELECT ON pmm.* TO grafana_ro;

readonly = 1을 걸고 pmm 데이터베이스에 SELECT만 줍니다. SOURCES를 주지 않으면 url(), s3(), mongodb(), remote(), file() 호출이 막힙니다. 대시보드가 필요한 것은 SELECT뿐이니 기능은 그대로 돕니다.

참고로 위 CREATE USER를 기본 default 계정으로 실행하면 거부될 수 있습니다. 제 컨테이너에서는 이렇게 나왔습니다.

Code: 497. DB::Exception: default: Not enough privileges.
To execute this query, it's necessary to have the grant
CREATE USER ON grafana_ro. (ACCESS_DENIED)

SOURCES는 넉넉히 주면서 사용자 관리 권한은 안 주는 기본 구성입니다. 이 스크립트를 돌리려면 ACCESS MANAGEMENT 권한이 있는 계정으로 접속해야 합니다.

관측 스택 계정 권한을 점검하는 자리​

공지가 다루지 않는 부분을 하나 짚고 싶습니다. 이번 문제의 뼈대는 PMM에 국한되지 않습니다. "대시보드가 DB에 붙을 때 어떤 권한으로 붙는가"라는 질문입니다. 이 질문은 어느 관측 스택에나 유효합니다.

점검할 지점을 정리하면 이렇습니다.

DB 계정 권한부터 보는 게 순서지만, 네트워크 쪽에서도 한 겹 막을 수 있습니다. DB 서버가 외부로 HTTP를 보낼 이유가 대개 없습니다. IMDSv2를 강제하는 것도 이 체인 두 번째 단계를 끊습니다.

남는 생각​

Copy Fail이나 NGINX Rift 같은 사례는 코드 한 줄의 결함이었습니다. 이번 건은 성격이 다릅니다. ClickHouse가 url()을 제공하는 것도, Grafana가 데이터소스 API를 여는 것도 각각은 의도된 기능입니다. 두 기능이 만나는 자리에서 권한 설정이 넉넉했던 것이 문제였습니다.

그래서 패치만으로 끝나지 않습니다. 3.9.1로 올린 뒤에도 데이터소스 계정에 무엇이 붙어 있는지 한 번 확인해 볼 만합니다. 저는 이 공지를 읽고 나서 ClickHouse의 SOURCES 권한이 그렇게 많은 것을 묶고 있는 줄 몰랐다는 걸 알았어요.

참고​

• Percona 보안 공지 (2026-08-19)
• ClickHouse 접근 권한 문서
• ClickHouse url 테이블 함수

MySQL에서 분석 쿼리를 억지로 버텨 본 경험이 있다면, 이 숫자들이 남 일 같지 않을 거예요. InnoDB로 28시간 넘게 돌리고도 다 못 끝낸 TPC-H 22개 쿼리를, 같은 MySQL 프로세스 안의 DuckDB 엔진이 185.6초에 끝냈습니다.

Percona가 8월 7일 공개한 실험입니다. DuckDB를 MySQL의 스토리지 엔진으로 붙인 실험 프로젝트를 TPC-H 스케일팩터 500, 그러니까 원본 CSV 500GB(약 30억 행) 규모에서 검증했습니다. MySQL은 스토리지 엔진을 갈아 끼울 수 있는 구조라는 걸 다들 알지만, 그 자리에 컬럼 지향 분석 엔진을 꽂는 발상을 실제 수치로 검증한 것은 드문 일입니다.

숫자부터​

테스트 환경은 80코어, 187.5GB RAM 서버 한 대입니다. 같은 데이터를 InnoDB, MySQL+DuckDB 엔진, 순수 DuckDB 세 가지로 적재하고 비교했습니다.

쿼리별로 보면 격차가 더 생생합니다. Q1은 InnoDB 11,864초가 11.1초로, Q6는 3,539초가 1.3초로 줄었습니다. InnoDB는 쿼리당 2시간 제한을 두었는데도 4개를 완주하지 못했습니다.

디스크 방향도 반대입니다. 원본 CSV 500GB가 InnoDB에서는 673GB로 늘어났고, DuckDB에서는 132GB로 압축됐습니다. 행 지향 저장과 인덱스 오버헤드 대 컬럼 저장과 압축의 차이가 그대로 드러납니다.

정확성 검증도 곁들여져 있습니다. 22개 쿼리 중 21개가 순수 DuckDB 결과와 소수점 4자리까지 일치했습니다.

어떻게 동작하나​

핵심은 MySQL의 스토리지 엔진 인터페이스입니다. 애플리케이션은 여전히 MySQL 프로토콜로 접속해 SQL을 실행하고, 해당 테이블의 저장과 스캔을 DuckDB가 담당합니다. 적재가 25.5배 빨랐던 비결도 여기 있는데, 엔진이 LOAD DATA를 행 단위 삽입으로 처리하지 않고 DuckDB의 COPY로 직접 전달해 배치 적재로 바꿉니다.

시도해 보는 것도 쉽게 만들어 놨습니다. Docker 이미지 한 줄로 실행됩니다.

docker run -d -p 3306:3306 -e MYSQL_ROOT_PASSWORD=secret \
  perconalab/ducksdb-mysql-engine:latest

냉정하게 볼 부분​

Percona 스스로 못박은 제약들이 있습니다.

첫째, 이것은 실험 소프트웨어입니다. 운영 투입 대상이 아니라고 글에서 반복해 강조합니다. 둘째, 분석 전용입니다. 포인트 조회 같은 OLTP 패턴은 여전히 행 경로가 낫고, 이 엔진의 목적이 아닙니다. 셋째, 메모리 관리가 아직 거칩니다. 메모리 제한을 넘는 쿼리는 디스크 스필 설정을 손봐야 합니다. 넷째, 서버 한 대의 특정 워크로드만 검증한 결과입니다.

그리고 벤치마크 자체의 성격도 감안해야 합니다. TPC-H는 컬럼 스토어에 유리한 순수 분석 워크로드입니다. InnoDB가 28시간 걸렸다는 것은 InnoDB가 나쁘다는 뜻이 아니라, 애초에 이 일을 시키면 안 되는 엔진에 이 일을 시켰다는 뜻에 가깝습니다. 문제는 현실의 많은 조직이 정확히 그렇게 쓰고 있다는 점이고, 이 실험의 가치는 그 간극을 숫자로 보여준 데 있습니다.

이어지는 실험: 복제로 OLTP와 분석 분리​

Percona는 이 실험을 한 단계 더 밀고 나가는 중입니다. 8월 13일 후속 글 Replicating from InnoDB into a DuckDB storage engine에서는 primary의 InnoDB 테이블을 replica의 DuckDB 엔진 테이블로 복제하는 구성을 다뤘습니다. 쓰기는 InnoDB가 받고, 분석은 DuckDB replica가 받는 그림입니다.

이 방향이 흥미로운 이유는 기존 선택지와의 비교 때문입니다. MySQL의 분석 부하를 떼어내는 전통적인 답은 별도 웨어하우스(ClickHouse, BigQuery 등)로의 CDC 파이프라인인데, 그 순간 스키마 동기화, 지연, 운영 부담이 따라옵니다. replica 한 대의 스토리지 엔진만 바꿔서 같은 효과를 얻는다면, MySQL 프로토콜과 권한 체계 안에서 문제가 끝납니다. PostgreSQL 진영에서 pg_duckdb가 겨냥하는 자리와 정확히 같은 자리입니다.

아직 붙일 이름은 실험이지만, 방향은 뚜렷해 보여요. 분석 엔진을 밖에 두고 데이터를 나르는 대신, 익숙한 DB 안으로 분석 엔진을 들여오는 흐름입니다. Docker 이미지가 공개되어 있으니 가벼운 데이터로 직접 실행해 보고, 결과가 재미있으면 후속으로 다루겠습니다.

참고 자료​

• The DuckDB MySQL engine at 500 GB - Percona Blog, 2026-08-07
• Replicating from InnoDB into a DuckDB storage engine - Percona Blog, 2026-08-13

2026-05-19, Percona가 주도하는 6사 컨소시엄(AWS, Percona, Supabase, pgEdge, Tiger Data, Eon)이 pgBackRest의 후원을 공식화했고, David Steele(데이비드 스틸)은 메인테이너로 복귀해요.

한 사람이 13년 짊어진 모델이 22일 만에 여러 사람이 함께 짊어지는 모델로 바뀌었습니다. 그게 이번 사건의 진짜 줄거리입니다.

DBA 입장에서 결론은 짧습니다. 즉각 마이그레이션 압력은 사라졌고, PostgreSQL 19(2026-09 예정) 호환성도 컨소시엄이 책임집니다. 지난달 종료 발표 시점에 썼던 글의 결말이 한 달 만에 바뀌었습니다.

22일짜리 정세 변동​

22일입니다. 종료 발표를 알아채고 분노했다가 분석으로 넘어가는 사이클을 한 바퀴 다 돌 시간도 안 됐습니다. 그동안 PostgreSQL DBA 커뮤니티 안에서는 "진짜 멈추면 어떻게 되나"의 시뮬레이션이 활발했고, Barman으로의 마이그레이션과 CNPG의 plugin-barman-cloud, WAL-G 회의론 등이 한곳에서 다시 정리됐습니다. 결과적으로 그 압박이 후원사들의 의사 결정 속도를 끌어올린 그림입니다.

6사가 모인 계산​

발표문은 회사 이름 외에 각자 동기를 길게 풀지 않았지만, 각 회사의 PG 사업 위치를 보면 그림은 그려집니다.

요약하면 pgBackRest를 잃었을 때 가장 비싸게 무는 회사들이 모였습니다. 단독 후원사 모델은 시장 한 곳에서 손해를 보는 회사가 비용을 다 짊어지는 구조였고, 컨소시엄 모델은 시장 전체에서 손해를 보는 회사들이 N분의 1로 나누는 구조입니다. Crunchy Data가 한 명을 13년 받쳐 줬다면, 이제는 6사가 함께 받칩니다.

Percona CEO **Peter Farkas(피터 파카스)**의 발표문 한 줄이 이를 그대로 짚습니다.

"pgBackRest has been our recommended backup solution/tool for years... coordinating with other companies to keep it healthy was a straightforward decision."

(pgBackRest는 우리가 수년 동안 권장해 온 백업 도구다. 이 도구를 건강하게 유지하기 위해 다른 회사들과 손을 잡는 결정은 어려운 결정이 아니었다.)

Percona에서 PostgreSQL P&E를 이끄는 **Kai Wagner(카이 바그너)**는 여기에 한마디 더 보탰습니다.

"Open source stays open. That's not a slogan. It's how we make decisions when situations like this come up."

("오픈소스는 열려 있다"는 슬로건이 아니다. 이런 상황이 닥쳤을 때 우리가 결정을 내리는 방식이다.)

읽는 사람에 따라 마케팅으로 받아칠 수도 있습니다. 다만 22일 만에 6사가 실제로 모였다는 사실이 그 슬로건을 한 번은 받쳐 줬다는 점은 분명합니다.

단독 메인테이너에서 다중 메인테이너로​

이번 컨소시엄 발표에는 자금만큼 중요한 두 번째 줄기가 있습니다. Percona가 새 메인테이너 onboarding을 명시적으로 책임진다는 점입니다.

"Percona engineering involvement to onboard a new maintainer."

13년 동안 코드 리뷰, 릴리스, 이슈 트리아지를 거의 한 사람이 처리한 프로젝트였습니다. 지난달 종료 글에서 정리한 구조적 함정이 정확히 그 지점입니다. 자금이 모여도 한 사람이 다시 떠안는 구조라면 같은 위기가 5년 뒤 그대로 반복됩니다.

이번 발표에서 공식화된 변화는 셋입니다. 첫째, Steele이 메인테이너로 복귀합니다. 후원 자금으로 dedicated time을 확보했습니다. 둘째, 단일 후원사 의존 모델을 해체하고 컨소시엄 모델로 전환합니다. 한 회사의 매각이나 예산 삭감 한 번으로 프로젝트가 흔들리지 않게 됩니다. 셋째, 추가 메인테이너를 영입합니다. Percona가 엔지니어링 리소스를 들여 후속 메인테이너를 onboarding합니다.

세 번째 항목이 가장 묵직합니다. 단독 메인테이너가 후원만 받는다고 지속가능성 문제가 사라지지 않는다는 인식을, DBA 커뮤니티 바깥에서도 받아들인 결과이기 때문입니다. 메인테이너가 한 명에서 둘, 둘에서 셋으로 늘어나는 구간을 실제로 통과해야 위기 반복이 끊깁니다.

오픈소스 지속가능성 모델로서의 의미​

pgBackRest 한 건의 부활로 보면 작은 사건이지만, 비슷한 구조의 위기는 곳곳에 있습니다. Linux 커널의 일부 파일시스템 메인테이너, Curl의 Daniel Stenberg, SQLite의 D. Richard Hipp, 그리고 PostgreSQL 안의 Barman 자체도 결국 한 회사(EDB) 한 줄로 묶여 있습니다.

이번 사건이 보여준 흐름은 셋입니다.

• 단일 회사 후원 + 단일 메인테이너 모델은 매각 한 번으로 무너집니다. Crunchy Data 매각 이후 Steele의 후속 정착이 안정될 때까지 시간이 충분히 주어지지 않았습니다.
• DBA 커뮤니티의 압박이 후원사 의사 결정 속도를 끌어올립니다. 종료 발표 직후 "진짜 멈추면 어떻게 되나"의 시뮬레이션이 빠르게 돌면서, 후원하지 않을 때의 운영 비용이 후원할 때의 자금 부담보다 크다는 계산이 빠르게 섰습니다.
• 컨소시엄 모델 + 다중 메인테이너 영입이 새 표준이 될 수 있습니다. Eclipse Foundation/CNCF처럼 형식화된 거버넌스까지 가지 않더라도, 비공식 컨소시엄으로 출발해 단계적으로 자리를 잡아가는 그림이 자연스럽습니다.

순서를 보면 씁쓸한 구석이 있어요. 한 사람이 손을 놓고 22일이 지나서야 6사가 모였지만, 그가 13년 일하는 동안에는 한 회사만 받쳐 줬고, 컨소시엄 모델이 정말 새 표준이 되려면 위기가 터진 다음이 아니라 터지기 전에 모이는 회의가 필요해요.

DBA 입장에서 결정을 다시 풀어 봅니다​

지난달 종료 글의 DBA 가이드는 다음 PostgreSQL 메이저까지 여유를 두고 점진적으로 Barman/CNPG plugin-barman-cloud로 마이그레이션을 검토하라고 권했습니다. 이제 그 결정이 풀립니다.

신규 도입 시점에 가장 큰 차이가 생깁니다. 종료 발표 시점에는 "한 사람만 만지는 도구를 신규로 쓰겠다고 결정하기는 어렵다"가 권고였습니다. 컨소시엄 발표 이후에는 "6사가 함께 받치는 도구"로 그 결론이 갈렸습니다.

다음 분기점은 PostgreSQL 19​

진짜 검증은 다음 메이저 출시입니다.

• PostgreSQL 19(2026-09 예정)이 컨소시엄 체제의 첫 메이저 대응입니다. v2.59 또는 그 후속 릴리스에서 PG 19 공식 지원이 들어와야 합니다. 이게 제때 풀리면 컨소시엄 모델은 DBA 신뢰를 한 번 얻습니다.
• 새 메인테이너 영입 시점도 관건입니다. Percona가 명시적으로 책임진 onboarding이 1~2년 안에 가시화돼야 합니다. 단순히 Steele 한 명 복귀로 끝나면 5년 뒤 같은 위기가 반복됩니다.
• 추가 후원사 합류가 남습니다. 6사가 중심이지만 지속 가능성 차원에서는 더 두꺼워질 필요가 있습니다. EDB, Crunchy Data, Cloud Native(EnterpriseDB Postgres) 같은 큰 회사들이 어떻게 움직일지가 관전 포인트입니다.

정리​

4월 27일 종료 발표 때 archive였던 저장소는 다시 active로 돌아왔고, 없던 메인테이너 자리는 Steele 복귀에 더해 신규 영입까지 예고됐습니다. 후원은 6사 컨소시엄이 떠안았고, 불확실하던 PostgreSQL 19 호환성도 컨소시엄이 책임집니다. 종료 발표 직후 점진 마이그레이션을 검토하라던 DBA 권고는, 이제 그대로 유지하되 신규 도입에서도 다시 후보에 올리는 쪽으로 바뀌었습니다.

13년 단독 시대가 22일 만에 6사 컨소시엄 시대로 넘어갔어요. 정세는 풀렸지만 컨소시엄 모델이 정말 지속 가능한지는 첫 번째 PostgreSQL 메이저 대응과 새 메인테이너 영입 시점이 결정하며, 그동안 DBA는 마이그레이션 압력 없이 한 분기 정도 더 호흡할 수 있어요.

참고​

• Open Source Stays Open: Percona Sponsors pgBackRest (Percona, GlobeNewswire)
• MAINTENANCE UPDATE (pgBackRest GitHub)
• pgBackRest is archived, what now? (Percona Community)
• pgBackRest News
• pgBackRest is dead. Now what? (MyDBA Notebook)
• pgBackRest의 종료 (4/30, 본 블로그)
• Barman 시작하기 (본 블로그)/Barman 14년의 발자취 (본 블로그)