데이터 플랫폼 보안 사고 대응: 유출 탐지, 격리, 영향도 분석
데이터 사고는 서버 한 대의 문제가 아니라 “어떤 데이터가 어디까지 갔는가”의 문제다
보안 사고 대응을 인프라 관점으로만 보면 “침해된 서버를 격리하고 계정을 잠그면 끝”처럼 보인다. 데이터 플랫폼에서는 그렇게 단순하지 않다. 공격자가 프로덕션 DB, BigQuery, S3, Kafka topic, BI export, Airflow connection 중 하나에 접근했다면 핵심 질문은 곧바로 바뀐다.
- 어떤 데이터셋이 노출됐는가?
- 누가, 어떤 권한으로, 어떤 경로를 통해 읽거나 내보냈는가?
- 원본 데이터뿐 아니라 복제본, query result, CSV export, 백업, downstream mart까지 영향을 받았는가?
- 추가 유출을 막으면서도 증거를 훼손하지 않으려면 무엇을 먼저 격리해야 하는가?
NIST SP 800-61 Rev. 3는 사고 대응을 단독 절차가 아니라 Govern, Identify, Protect, Detect, Respond, Recover가 연결된 위험 관리 활동으로 본다. 데이터 플랫폼 운영자에게 이 관점은 특히 중요하다. 평소의 분류, 소유자, lineage, audit log, 권한 관리가 준비되어 있지 않으면 사고가 난 뒤에는 영향도 분석이 추측이 된다.
1. 데이터 플랫폼 사고의 전형적인 신호
일반적인 보안 알림은 악성 IP, malware, 비정상 로그인처럼 시스템 중심이다. 데이터 플랫폼 사고는 여기에 “데이터 이동” 신호를 더 봐야 한다.
| 신호 | 예시 | 왜 중요한가 |
|---|---|---|
| 비정상 대량 조회 | 평소 1GB 조회하던 계정이 새벽에 2TB 조회 | 단순 조회 권한만으로도 유출이 가능하다 |
| 외부 위치로 export | BigQuery export job, S3 cross-account copy, DB dump download | 데이터가 통제 경계 밖으로 이동했을 수 있다 |
| 권한 급상승 | dataset owner 추가, service account token 발급 | 공격자가 접근을 유지하거나 확대할 수 있다 |
| 보안 통제 우회 | VPC Service Controls violation, DLP 정책 예외, masking 해제 | 방어선이 실제로 공격 경로가 되었는지 봐야 한다 |
| downstream 이상 | BI extract 증가, Airflow backfill로 민감 테이블 재처리 | 원본이 아니라 파생 데이터가 새로 노출될 수 있다 |
Google Cloud BigQuery threat model은 bigquery.jobs.create, bigquery.tables.export, bigquery.tables.getData 같은 권한이 query 기반 유출이나 외부 bucket/export 유출로 이어질 수 있다고 설명한다. 즉 “read-only라서 안전하다”는 가정은 데이터 플랫폼에서는 위험하다.
2. 사고 대응 흐름: 탐지 → 보존 → 격리 → 영향도 분석 → 복구
데이터 사고 대응의 순서는 단순히 빠른 차단만이 아니다. 너무 빠른 삭제나 재배포는 증거를 없앨 수 있고, 너무 느린 분석은 유출을 키울 수 있다. 운영자는 증거 보존과 추가 피해 차단 사이의 순서를 정해야 한다.
3. 탐지: “누가 무엇을 읽었는가”를 재구성한다
데이터 사고의 1차 분석은 경보 이름을 읽는 것이 아니라 행위를 재구성하는 것이다.
3.1 최소 수집 로그
| 계층 | 봐야 할 로그 |
|---|---|
| Identity | SSO sign-in, MFA 실패, impossible travel, service account token 발급, role binding 변경 |
| DB / Warehouse | query log, audit log, slow query log, export/load job, DDL/DCL 이력 |
| Object Storage | object read/write, bucket policy 변경, cross-account access, presigned URL 생성 |
| Orchestration | Airflow DAG run, connection 변경, variable/secret 접근, backfill 실행 |
| Network | egress flow, VPC Service Controls violation, private endpoint 우회 여부 |
| Catalog / Lineage | 민감도 label, owner, upstream/downstream table, BI dashboard 연결 |
Google Cloud 문서는 BigQuery audit log가 “누가, 무엇을, 어디서, 언제 했는가”를 답하는 기본 소스이며, job의 영향과 세부 실행 정보는 INFORMATION_SCHEMA와 함께 봐야 한다고 설명한다. 데이터 플랫폼 운영자는 이 둘을 같이 보아야 한다. audit log만 보면 API 호출은 보이지만 실제 query가 어떤 테이블을 참조했고 얼마나 큰 결과를 만들었는지 놓칠 수 있다.
3.2 예시: BigQuery 유출 의심 triage
Security Command Center의 Exfiltration: BigQuery Data Exfiltration finding은 principal email, source table, target table, job link, query, 관련 Cloud Logging URI를 확인하라고 안내한다. 실무 triage는 다음 순서로 잡을 수 있다.
- finding의
principal email과jobLink를 고정한다. JobService.InsertJob로그로 query, destination, export target을 확인한다.- 해당 principal의 IAM binding, service account impersonation, 최근 권한 변경을 확인한다.
- source table의 classification과 owner를 확인한다.
- destination이 조직 밖인지, 승인된 공유 경로인지, VPC Service Controls가 막았는지 확인한다.
- 같은 principal 또는 같은 IP가 다른 dataset을 조회했는지 시간 범위를 넓혀 본다.
4. 격리: 계정을 잠그기 전에 증거와 운영 영향도를 본다
격리는 빠르게 해야 하지만 무조건 “삭제”부터 하면 안 된다. 계정 삭제, VM 재배포, bucket 비우기, 로그 rotation은 증거를 훼손할 수 있다. 더 안전한 기본값은 접근을 끊되 증거는 보존하는 것이다.
| 조치 | 권장 방식 | 주의점 |
|---|---|---|
| 사용자 계정 | 세션 revoke, MFA reset, 임시 disable | 내부 업무 계정이면 업무 중단 영향 확인 |
| service account | key disable, token revoke, binding 축소 | pipeline 전체 장애 가능성 확인 |
| DB 계정 | LOCK ACCOUNT, password rotation, 권한 축소 | 장애 복구용 계정까지 잠그지 않기 |
| object storage | bucket policy 제한, public access block, versioning 유지 | 삭제보다 접근 차단 우선 |
| warehouse | export 권한 회수, 외부 destination 제한 | 정상 ETL export와 충돌 가능 |
| network | egress deny, VPC perimeter 강화 | 운영 트래픽까지 막는지 확인 |
AWS와 Microsoft의 클라우드 사고 대응 가이드는 공통적으로 준비된 역할, 로그, 자동화, 증거 보존, containment/recovery 절차를 강조한다. 데이터 플랫폼에서는 이 원칙을 권한과 데이터 이동 경로에 맞게 해석해야 한다. 예를 들어 compromised VM 격리보다 더 급한 조치가 bigquery.tables.export 권한 회수이거나 외부 bucket으로의 egress 차단일 수 있다.
5. 영향도 분석: 테이블 하나가 아니라 데이터 계보를 따라간다
영향도 분석은 “어떤 row가 노출됐는가”만 묻지 않는다. 데이터 플랫폼에서는 원본 테이블의 파생물이 많다.
- raw zone table
- cleaned/staging table
- mart table
- BI extract
- notebook result
- CSV export
- ML feature snapshot
- backup/dump
- search index
- cache
- downstream customer API
따라서 영향도 분석은 세 단계로 나눈다.
5.1 노출된 행위의 범위
- 조회인지, export인지, 복사인지, 권한 변경인지 구분한다.
- query text와 referenced tables를 확인한다.
- result size, scanned bytes, destination table/bucket을 확인한다.
- 같은 actor가 전후 24~72시간 동안 수행한 비슷한 job을 묶는다.
5.2 데이터 민감도와 대상자 범위
- classification label이
Restricted인지 확인한다. - PII, payment data, credential, secret, health data, customer contract가 포함됐는지 확인한다.
- masking/tokenization이 적용된 데이터인지 원문인지 구분한다.
- row-level security나 authorized view가 우회됐는지 확인한다.
5.3 downstream 확산 범위
- lineage로 downstream table과 dashboard를 추적한다.
- Airflow, dbt, Spark/Flink job이 사고 시간대 이후 재처리했는지 본다.
- 외부 공유 dataset, partner export, BI scheduled delivery가 있는지 확인한다.
- 백업과 snapshot에도 동일한 민감 데이터가 들어 있는지 확인한다.
이 단계의 산출물은 “사고 보고서 문장”이 아니라 의사결정용 표여야 한다.
| 항목 | 예시 |
|---|---|
| Incident ID | SEC-DATA-2026-0705-01 |
| Actor | svc-analytics-export@... |
| 최초 탐지 | 2026-07-05 02:14 KST |
| 의심 행위 | customer PII mart를 외부 bucket으로 export 시도 |
| 확정 노출 | Needs confirmation / blocked by perimeter / exported 3 files |
| 영향 데이터셋 | restricted.customer_profile, mart.crm_customer |
| 데이터 주체 규모 | Needs confirmation |
| 격리 조치 | service account key disable, export role removed |
| 다음 결정 | 법무/개인정보보호 담당자 notification 판단 필요 |
6. 복구와 재발 방지: 원인 하나가 아니라 통제 사슬을 고친다
데이터 유출 사고의 원인은 보통 하나가 아니다. “서비스 계정 키가 노출됐다”는 직접 원인 뒤에는 장기 키 사용, 과도한 권한, 외부 export 허용, query log 미보존, owner 불명확, lineage 부재가 함께 있다.
복구 후에는 다음 통제를 점검한다.
- 권한 최소화:
read,export,owner,impersonation권한을 분리한다. - 외부 이동 제한: 승인된 bucket/project/account 외 export를 막는다.
- 민감 데이터 label 연동: label이 권한, DLP, masking, audit rule에 실제로 연결되게 한다.
- service account hygiene: owner, purpose, rotation, last used, allowed resource를 문서화한다.
- 로그 보존: 사고 조사 기간보다 긴 audit log retention을 보장한다.
- runbook 훈련: table-top exercise로 “누가 계정을 잠그고, 누가 법무 판단을 하고, 누가 고객 영향도를 산정하는가”를 확인한다.
NIST Rev. 3의 핵심은 incident response가 Detect, Respond, Recover에서 끝나지 않고 Identify의 improvement로 돌아간다는 점이다. 데이터 플랫폼 사고도 마찬가지다. 한 번의 사고가 끝나면 권한 모델, lineage, catalog, DLP, backup, audit evidence가 함께 개선되어야 한다.
7. 운영 체크리스트
- [ ] 민감 데이터셋에 owner, classification, retention, allowed export path가 있다.
- [ ] query log와 audit log가 중앙 저장소에 보존되고 삭제 권한이 분리되어 있다.
- [ ]
SELECT권한과EXPORT/COPY권한이 분리되어 있다. - [ ] service account마다 담당자, 목적, 권한 범위, rotation 정책이 있다.
- [ ] 외부 bucket, 외부 project, public sharing에 대한 alert가 있다.
- [ ] 사고 시 session revoke, key disable, DB account lock 절차가 문서화되어 있다.
- [ ] lineage로 downstream table, BI, export job을 추적할 수 있다.
- [ ] 법무/보안/데이터 owner/플랫폼 운영자 escalation 경로가 정해져 있다.
- [ ] 복구 후 post-incident review에서 통제 개선 항목과 owner를 배정한다.
References
- NIST CSRC, Incident Response project and SP 800-61 Rev. 3 overview: https://csrc.nist.gov/projects/incident-response
- NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r3.pdf
- AWS Security Incident Response User Guide: https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html
- Microsoft Cloud Security Benchmark v2, Incident Response: https://learn.microsoft.com/en-us/security/benchmark/azure/mcsb-v2-incident-response
- Google Cloud, BigQuery threat model report: https://docs.cloud.google.com/docs/security/threat-model/bigquery-threat-model
- Google Cloud Security Command Center, Exfiltration: BigQuery Data Exfiltration: https://docs.cloud.google.com/security-command-center/docs/findings/threats/big-query-exfil
- Google Cloud, Introduction to audit logs in BigQuery: https://docs.cloud.google.com/bigquery/docs/introduction-audit-workloads