본문으로 건너뛰기

6.2 보안과 복구 경계

개발용 branch에서 운영 데이터의 조회 결과를 마스킹해도 확인할 사항이 남습니다. 원본 자격증명이나 예약 작업의 상태를 모르면 접속 정보를 배포하기 어렵습니다. 복구에서도 같은 문제가 생깁니다. 사본 접속 성공만으로 원본 삭제나 계정 장애 이후의 복구까지 검증했다고 판단하지 않습니다. 데이터 내용, 실행 권한, 장애 범위를 각각 확인합니다.

이 장은 2026-09-30 기준 사실 대장의 복제 범위를 유지합니다. 확정은 문서에서 확인한 좁은 동작을 뜻하며 전체 환경의 안전성을 보장하지 않습니다. 미확인은 지원 여부를 확인하지 못했다는 의미로 유지합니다. 검사 순서와 API 설계는 운영 정책 제안입니다. 실제 권한 차단 시험과 장애 복구 결과는 미실측입니다.

마스킹 기준 데이터와 접근 통제​

마스킹은 현재 SQL 조회 결과와 과거 정보의 제거를 구분해 검증합니다. PostgreSQL에서 UPDATE를 실행한 사실만으로 과거 원본 정보의 제거를 보장하지 않습니다. 여기에는 과거 tuple, snapshot, backup의 정보가 포함됩니다. 사실 대장은 PostgreSQL의 vacuum 설명과 ZFS snapshot의 참조 보존을 근거로 삼습니다. 이 근거에 따라 원본 정보가 제거됐다는 단정을 배제합니다. 현재 테이블의 값이 치환됐는지 검사합니다. 보존된 원본에 접근할 권한이 남았는지는 별도로 검사합니다.

다음 그림은 개발자에게 제공할 기준 데이터를 만드는 운영 정책 제안입니다. 수집 구역의 접근 권한을 제한합니다. 마스킹 검사와 실행 권한 검사를 모두 통과한 기준점만 배포 대상으로 지정합니다. 검사를 마친 뒤 사용자에게 endpoint나 secret을 전달하는 순서로 구성합니다. 검사 실패 자원에도 만료 시각을 지정하고 조사 후 정리합니다.

검사에는 마스킹 대상 컬럼의 누락과 관계 보존 여부를 포함하도록 제안합니다. 참조 키를 치환할 때는 관련 테이블이 같은 정책 버전을 사용하는지 확인합니다. 합성 데이터만으로 시험 목적을 충족하면 운영 데이터 수집을 생략하는 경로도 둡니다. 성능 시험에서 원본 분포가 필요하면 어떤 분포를 유지할지 먼저 정합니다. 마스킹 이후의 시험 한계는 결과에 적습니다.

조상 branch와 복구 이력도 접근 범위에 포함합니다. 개발자가 현재 branch의 권한만 보유하는지 시험합니다. 과거 시점 복구나 부모 접속을 요청할 권한도 보유하는지는 별도로 시험합니다. 관리자 계정으로 검사가 성공했다는 결과를 일반 사용자에게 적용하지 않습니다. 같은 실패를 다시 확인하려면 검사 주체의 role과 요청 경로를 기록해야 합니다.

외부 호출은 데이터 격리와 별개로 통제하는 정책을 제안합니다. 시험용 메일 수신처나 결제 대체 endpoint를 명시합니다. 운영 목적지 접근은 허용 목록에서 제외합니다. 예약 작업은 생성 직후 상태를 검사한 뒤 필요한 작업만 활성화합니다. 공급자의 특정 작업 비활성화 규칙은 해당 작업에 한정해 적용합니다. 다른 scheduler의 작업은 별도로 확인하고, 미확인 작업은 배포 보류 사유로 남깁니다.

제품별 복제 범위​

아래 표는 사실 대장의 N4N8, X6, P5, S5S6, B5, T6, A5, D6, F2~F6, U5, E5, L5, Z5, O5를 옮긴 대조 자료입니다. 세부 생성 모드와 엔진을 확정하지 못한 항목에는 미확인을 유지합니다. ZFS의 유력 판정은 파일 복사 범위에서 추론한 결과입니다. 제품 문서의 확정 규칙과 구분합니다.

제품과 범위SecretRoleExtensionScheduled job
Neon 데이터 포함 branch전체 사용자 secret 규칙 미확인포함 확정포함 확정, 지원 바이너리 범위 별도Functions scheduled trigger 상속 후 비활성 확정, pg_cron 전체 규칙 미확인
Xata Cloud/OSS미확인미확인미확인미확인
PlanetScale Postgres복원 시 세부 처리 미확인Branch 범위 API 확정, 복원 시 처리 미확인미확인미확인
SupabaseBranch별 API 자격증명, branch secret 자동 공유 없음 확정public 기본 권한의 migration 명시 필요 확정, custom role 미확인전체 범위 미확인전체 범위 미확인
DBLab physical/logical생성 자격증명 지정 확정, 전체 secret 미확인수집 방식별 미확인바이너리 포함 범위 미확인미확인
Tiger Cloud fork새 관리자 비밀번호 확정, 전체 secret 미확인새 비밀번호의 tsdbadmin 확정, custom role 미확인미확인미확인
Aurora 엔진별 cloneSecrets Manager 포함 규칙 미확인미확인미확인미확인
Doltgres버전 관리 범위 미확인버전 관리 범위 미확인버전 관리 범위 미확인버전 관리 범위 미확인
Turso의 두 Cloud 세대Token과 secret 미확인이 대장에서 미확인PostgreSQL 개념 대응 없음미확인
Snowflake 객체 clone전체 secret과 integration 미확인하위 객체 권한 상속 확정, container 예외와 database role 별도 명령PostgreSQL 개념 대응 없음Cloned task와 alert 정지 확정
Delta 테이블 clone실행 환경 전체 복제 대상 아님Workspace role 포함 환경 복제 아님PostgreSQL 개념 대응 없음실행 환경 전체 복제 대상 아님
Delphix VDB엔진과 connector별 미확인엔진과 connector별 미확인엔진과 connector별 미확인엔진과 connector별 미확인
ZFS 물리 snapshotDataset 밖 파일 자동 포함 없음 유력Catalog 포함 추론 유력, 배치별 검증 필요외부 바이너리 자동 포함 없음 유력OS scheduler 자동 포함 없음 유력
Oracle snapshot PDBWallet과 외부 연결 미확인사용자 복제 범위 미확인PostgreSQL 개념 대응 없음Scheduler 복제 범위 미확인

Neon은 database, role, extension을 포함합니다. 이를 지원 확장 목록 밖의 바이너리까지 복제한다는 뜻으로 해석하지 않습니다. 분기 확정 범위는 현재 backend의 Auth 상태와 object storage의 bucket 및 object입니다. 외부 인증 서비스나 외부 S3 bucket은 이 확정 범위에서 제외합니다. Functions scheduled trigger의 비활성 상속도 해당 기능에 한정합니다. 연결 정보 주입과 모든 사용자 secret의 복제는 서로 다른 확인 항목입니다.

Supabase는 기본 branch에서 운영 데이터와 Storage object를 제외합니다. Dashboard의 Include data는 PITR add-on을 요구합니다. 그 모드의 Auth와 Storage 세부 범위는 미확인입니다. Branch에 설정한 secret은 자동으로 공유되지 않습니다. 이는 배포 workflow가 Vault 또는 Function secret을 적용하는 동작과 구분합니다. Migration에는 필요한 권한 부여를 명시하고 최종 권한을 별도로 검사합니다.

Snowflake는 하위 객체 권한 상속과 container 자체의 권한에 서로 다른 규칙을 적용합니다. 지원 객체의 COPY GRANTS도 ownership은 제외합니다. Dolt의 branch 권한은 인증된 SQL server 세션의 변경 작업을 통제합니다. 로컬 CLI에는 같은 제약을 적용하지 않습니다. 이 규칙으로 확인한 범위는 Dolt에 한정합니다. Doltgres의 전체 환경 버전 관리 범위는 별도 확인 대상으로 남깁니다.

표의 미확인을 해소할 때는 role 이름의 존재와 실제 권한을 나누어 검사하도록 제안합니다. Extension도 catalog의 등록 상태와 실행 성공 여부를 구분합니다. Secret 검사는 값을 보고서에 복사하지 않고 식별자와 접근 성공 여부만 보존합니다. 예약 작업은 정의의 복제 여부와 활성 상태, 실행 계정, 외부 목적지를 함께 기록합니다.

독립 백업과 복구 목표​

ZFS clone은 origin snapshot에 의존합니다. 따라서 같은 pool의 clone을 독립적인 장애 복구용 backup으로 간주하지 않습니다. Delta OSS shallow clone도 원본 data file을 참조합니다. 원본의 VACUUM이 참조 파일을 제거하면 읽기 실패가 발생할 수 있습니다. Unity Catalog의 참조 추적은 유효한 clone의 파일을 보호합니다. 다만 원본 managed table 삭제 후 purge는 별도 위험으로 남습니다. Preview 상태와 Runtime 및 테이블 유형의 적용 조건도 확인합니다.

독립성을 평가할 때는 장애 범위별로 시험을 나누도록 제안합니다. 원본 데이터 손상, 원본 삭제, 저장소 소실, 계정 접근 상실을 각각 시험으로 작성합니다. 각 경우에 사용할 사본과 복구 권한을 지정합니다. 원본 없이 복구 자료를 읽는 절차도 확인합니다. 복구 담당자가 평소 관리 계정에만 의존한다면 그 계정의 접근 상실 시나리오도 별도로 검토합니다.

별도 backup 설계에는 보관 위치와 삭제 권한, 암호화 키의 복구 경로를 포함하도록 제안합니다. 시험용 clone의 TTL이 끝나도 backup 보존 정책은 독립적으로 평가합니다. 반대로 backup이 남아 있다는 이유로 개발용 사본의 접근을 계속 허용하지 않습니다. 보존 자료를 다른 실행 환경에 복원하고 데이터 검증까지 마친 기록을 남깁니다. 이 기록을 독립성 판정의 증거로 삼습니다.

보존 기간은 복구 대상으로 선택하는 과거 범위입니다. RPO는 장애 시 허용할 데이터 손실을 시간으로 나타낸 목표입니다. RTO는 서비스 복구에 허용할 시간을 나타낸 목표입니다. AWS의 복구 목표 설명을 기준으로 세 항목을 분리합니다. 긴 보존 기간을 설정했다는 사실만으로 최근 변경의 손실 목표를 충족했다고 판정하지 않습니다.

복구 시험에서는 마지막으로 성공 응답을 받은 변경과 복구 후 확인한 변경을 대조하도록 제안합니다. 접속 성공 이후 데이터 검증과 애플리케이션 재개까지 걸린 시간을 기록합니다. 운영 데이터의 일부를 사고 직전으로 되돌리는 작업은 별도 결과로 남깁니다. 저장소 장애 후 최신 상태를 복원하는 작업과 목표가 다르기 때문입니다.

PostgreSQL PITR의 기준 backup과 WAL 재생 조건은 복구 자료 목록에 반영합니다. LSN에는 cluster와 timeline 식별자를 함께 기록합니다. Neon의 저장 경로별 내구성 설명은 내구성과 가용성 모델에 연결합니다. 제품 간 RPO와 RTO의 우열은 이 장에서 판정하지 않습니다. 동일 장애 조건의 복구 시험을 수행하지 않았기 때문입니다.

이력이 만료된 시점의 복구 요청에는 남아 있는 별도 backup을 확인하는 절차를 둡니다. 유효한 복구 경로를 찾지 못하면 복구 가능 여부를 미확인으로 보고합니다. 요청 접수 시각이나 새 branch 생성 사실만으로 원하는 시점 복구의 성공을 표시하지 않습니다. 결과 데이터의 기준 시점이 요청과 일치하는지 검증한 뒤 종료합니다.

관리형 서비스의 제어 기능​

서비스 설계에서는 생성 API가 작업 식별자와 진행 상태를 반환하도록 제안합니다. 요청에는 원본과 기준 시점, 생성 모드, 마스킹 정책 버전을 포함합니다. 재시도에는 멱등 키를 사용합니다. 같은 키로 다른 요청 내용이 들어오면 충돌로 처리합니다. 응답 유실 뒤 새 요청을 만들기 전에 기존 작업의 결과를 조회하는 경로를 제공합니다.

Endpoint는 데이터 준비와 보안 검사가 끝난 뒤 사용자에게 전달합니다. 실패한 생성 작업에도 자원 식별자를 남깁니다. 정리 담당자가 이 식별자로 잔여 자원을 조회하도록 설계합니다. 사용 권한, 관리자 권한, 원본 수집 자격증명을 분리합니다. 각 주체의 접근 기록을 보존합니다. 고객 응답에는 secret 값을 포함하지 않는 상태 조회 방식도 마련합니다.

TTL과 quota는 수명 정책에 연결합니다. 생성 전에 quota를 예약하고 실패 뒤 예약량을 반환합니다. 남은 저장 자원은 계속 집계합니다. 감사 기록에는 요청자와 원본, 정책 판정, 상태 전이, 삭제 결과를 포함합니다. GC 관찰에는 삭제 대기와 참조 해제 대기, 회수 지표의 마지막 확인 시각을 분리합니다. 미확인 상태를 완료로 바꾸는 시간 기반 처리는 두지 않습니다.

Xata OSS의 공개 구성 설명은 제어 기능 검토의 근거로 사용합니다. 다만 공개 핵심 구성 요소와 상용 서비스의 보호 범위는 다릅니다. 공급자는 적대적 멀티테넌시 보호가 빠진 OSS를 공개 PaaS에 사용하는 것을 권장하지 않습니다. 이 조건은 자체 서비스의 인증과 격리 시험 범위를 정할 때 반영합니다. 라이선스상 BYOC 구매 의무 여부는 이 조건과 구분합니다.

관리형 서비스의 기존 논의는 관리형 PostgreSQL 관점의 시사점에 정리되어 있습니다. 이 장은 생성과 삭제 사이의 권한 검사와 복구 검증을 추가하는 설계 제안입니다. 도입 검토에는 제품 기능 확인 결과와 직접 시험한 결과를 구분해 제출합니다. 미확인 복제 규칙에는 담당자와 후속 확인 조건을 남깁니다.

참고​