데이터 보안 기본: classification, least privilege, separation of duties
데이터 보안은 “잠그기”보다 “다르게 다루기”에서 시작한다
데이터 플랫폼을 운영하다 보면 보안 요구가 자주 추상적으로 들린다. “민감정보를 보호하라”, “권한을 최소화하라”, “감사 대응이 가능해야 한다” 같은 말은 맞지만, 실제 운영자는 더 구체적인 질문 앞에 선다.
- 어떤 테이블이 민감한가?
- 누가 읽어도 되고, 누가 내려받아도 되는가?
- 운영자가 장애를 보려면 어디까지 접근해야 하는가?
- 개발자가 임시로 production 데이터를 봐야 한다면 어떤 절차가 필요한가?
- 한 사람이 권한 요청, 승인, 부여, 감사 로그 삭제까지 모두 할 수 있어도 되는가?
이 장의 핵심은 세 가지다.
- classification: 데이터를 민감도와 업무 영향도에 따라 분류한다.
- least privilege: 사람과 시스템에 필요한 최소 권한만 준다.
- separation of duties: 중요한 절차를 한 사람이 끝까지 장악하지 못하게 나눈다.
세 원칙은 따로 움직이지 않는다. 분류가 없으면 최소 권한의 기준이 흐려지고, 최소 권한이 없으면 분류는 라벨 장식이 된다. 역할 분리가 없으면 권한 요청과 승인, 운영 변경과 검증, 백업 접근과 복구 검증이 한 사람에게 몰려 사고가 늦게 발견된다.
1. Classification은 “중요한 데이터 목록”이 아니라 운영 정책의 입력이다
데이터 분류는 “개인정보가 들어 있는 테이블을 찾았다”로 끝나면 안 된다. 분류 결과는 실제 통제의 입력이어야 한다.
AWS Prescriptive Guidance는 데이터 분류를 네트워크 안의 데이터를 중요도와 민감도에 따라 식별하고 범주화하는 과정으로 설명한다. 또한 어떤 데이터를 처리하는지, 어디에 저장되는지, 누가 소유하는지, 어떻게 접근하고 공유해야 하는지를 알아야 적절한 보호와 보존 통제를 정할 수 있다고 한다.
CIS Control 3도 같은 방향을 잡는다. 데이터 보호의 핵심은 데이터를 식별하고, 분류하고, 안전하게 처리하고, 보존하고, 폐기하기 위한 프로세스와 기술 통제를 만드는 것이다.
운영 환경에서는 보통 다음 정도의 단순한 체계부터 시작하는 편이 좋다.
| 분류 | 예시 | 기본 통제 |
|---|---|---|
Public | 공개 문서, 공개 API 응답 예시 | 무결성 관리, 변경 승인 |
Internal | 내부 운영 문서, 일반 지표 | 사내 접근, 외부 공유 제한 |
Confidential | 매출, 계약, 고객 세그먼트, 내부 성과 | 업무 필요 기반 접근, 다운로드 제한, 감사 로그 |
Restricted | 주민번호, 계좌, 카드, 인증 토큰, 원본 PII | 강한 승인, 암호화, 마스킹, 세션 기록, 보존·파기 정책 |
분류 단계에서 가장 자주 생기는 실패는 두 가지다.
첫째, 모든 것을 Confidential이나 Restricted로 밀어 넣는 것이다. 그러면 실제로 위험한 데이터가 묻힌다. 운영자는 예외 요청을 계속 처리하다가 통제를 우회하는 문화를 만들 수 있다.
둘째, 분류만 하고 정책에 연결하지 않는 것이다. catalog에 “PII” 태그가 붙어 있어도 DB 권한, object storage policy, BI export 권한, 백업 접근 권한이 그대로라면 사고 가능성은 크게 줄지 않는다.
좋은 분류 체계는 완벽한 라벨 체계가 아니라 운영자가 결정을 빠르게 내릴 수 있는 기준이다.
2. 분류 단위는 테이블만이 아니다
데이터 플랫폼에서는 민감도가 여러 층위에 걸쳐 나타난다.
| 단위 | 운영 예시 | 주의점 |
|---|---|---|
| 시스템 | production PostgreSQL, S3 data lake, Kafka cluster | 시스템 단위 분류만 하면 컬럼별 민감도 차이를 놓친다 |
| 데이터셋 | orders, payments, user_profiles | owner와 보존 정책을 붙이기 쉽다 |
| 컬럼 | email, phone, access_token, amount | column-level masking, row policy와 연결 가능 |
| 행 | 특정 국가, VIP 고객, 미성년자 데이터 | row-level security나 ABAC가 필요할 수 있다 |
| 파생 데이터 | 집계 테이블, feature table, BI extract | 원본보다 낮은 민감도인지 검증해야 한다 |
| 백업·로그 | dump file, query log, audit log | 원본과 같은 수준으로 보호해야 하는 경우가 많다 |
특히 파생 데이터가 위험하다. 원본 테이블에는 접근 통제를 걸어도, 매일 생성되는 CSV export, BI extract, ML feature snapshot, 장애 분석용 dump가 느슨한 권한으로 남아 있으면 분류 체계는 우회된다.
그래서 데이터 inventory에는 최소한 다음 항목이 있어야 한다.
- 데이터셋 이름과 위치
- owner와 steward
- 분류 라벨
- 민감 컬럼 또는 민감 정보 유형
- 주요 소비자와 목적
- 보존 기간과 삭제 기준
- 백업·복제·export 위치
- 최근 검토일
NIST SP 800-60은 정보 유형과 정보 시스템을 보안 범주에 매핑할 때 기밀성, 무결성, 가용성 각각의 영향도를 본다. 실무에서도 같은 생각이 유용하다. 개인정보 테이블은 기밀성 영향이 크고, 정산 테이블은 무결성 영향이 크며, 인증 세션 저장소는 가용성 영향이 클 수 있다. “민감정보냐 아니냐”만으로는 충분하지 않다.
3. Least privilege는 권한을 작게 주는 일이 아니라 권한의 이유를 좁히는 일이다
NIST CSRC glossary는 least privilege를 사용자 또는 사용자 대신 동작하는 프로세스의 접근 권한을 할당된 작업을 수행하는 데 필요한 최소한으로 제한하는 보안 원칙으로 정의한다.
데이터 플랫폼에서 이 원칙은 다음처럼 번역된다.
| 대상 | 나쁜 권한 | 더 나은 권한 |
|---|---|---|
| 분석가 | warehouse 전체 SELECT | 담당 domain의 curated mart SELECT |
| 백엔드 서비스 | DB superuser | 필요한 schema의 필요한 DML 권한 |
| Airflow DAG | 모든 object storage bucket read/write | 해당 pipeline prefix에만 read/write |
| DBA | 항상 production full access | 평상시 read-only, 긴급 시 승인 기반 elevation |
| BI 사용자 | raw PII 포함 테이블 접근 | masking된 view 또는 aggregate mart 접근 |
중요한 것은 “작게”가 아니라 “이 권한이 왜 필요한가”다. 예를 들어 장애 대응 담당 DBA에게 production DB 접근이 필요할 수 있다. 하지만 그 권한이 항상 활성화되어 있어야 하는지는 별도 질문이다. 운영상 필요한 경우라도 다음처럼 좁힐 수 있다.
- 시간: 2시간짜리 temporary access
- 범위: 특정 database, schema, table, prefix
- 행동: read-only, DDL 금지, export 금지
- 경로: bastion, approved notebook, break-glass workflow
- 기록: ticket id, session log, query log
least privilege는 한 번 설정하고 끝나는 정책이 아니다. 업무가 바뀌고, 팀이 이동하고, pipeline이 폐기되고, 임시 권한이 남는다. 그래서 권한은 “부여”보다 “회수”가 어렵다. 운영자는 access review를 정기 작업으로 넣어야 한다.
4. 역할 기반 권한과 속성 기반 권한을 구분한다
권한 모델은 보통 RBAC와 ABAC가 섞인다.
| 모델 | 기준 | 장점 | 한계 |
|---|---|---|---|
| RBAC | 역할: DBA, analyst, data engineer | 이해하기 쉽고 승인 흐름이 단순하다 | 역할이 늘어나면 과권한이 생긴다 |
| ABAC | 속성: dataset owner, region, classification, purpose | 세밀한 정책을 만들 수 있다 | 속성 품질과 정책 관리가 어렵다 |
초기에는 RBAC로 시작해도 된다. 예를 들어 finance_analyst_readonly, marketing_bi_viewer, data_engineer_pipeline_operator 같은 역할은 운영하기 쉽다. 하지만 데이터가 많아지면 “같은 analyst라도 EU 고객 PII는 볼 수 없다” 같은 조건이 생긴다. 이때는 classification, domain, purpose, region 같은 metadata가 권한 판단에 들어가야 한다.
실무적인 기준은 다음과 같다.
- 역할은 적게 유지한다.
- 역할 이름에 권한 범위와 목적을 담는다.
- raw zone보다 curated zone 접근을 기본값으로 둔다.
- restricted 데이터는 별도 승인과 별도 로그를 요구한다.
- service account는 사람 계정과 분리하고 owner를 지정한다.
- 장기 권한보다 짧은 elevation을 우선한다.
Microsoft Purview sensitivity labels 문서는 label을 만들고 정책으로 사용자에게 게시한 뒤, 앱과 서비스가 암호화, 워터마크, 접근 제한 같은 설정을 적용하는 흐름을 설명한다. 이 사례의 교훈은 라벨과 정책, 적용 지점이 연결되어야 한다는 점이다. 데이터 catalog의 classification도 실제 DB, storage, BI, export 경로의 정책과 연결되어야 한다.
5. Separation of duties는 내부자를 의심하는 제도가 아니라 절차를 안전하게 만드는 구조다
separation of duties는 중요한 절차를 여러 역할로 나누어 한 사람이 단독으로 critical process를 훼손하지 못하게 하는 원칙이다. NIST SP 800-12는 예를 들어 결제 요청자와 승인자를 나누는 방식처럼 checks and balances를 프로세스와 직무에 설계해야 한다고 설명한다.
데이터 운영에서 역할 분리는 다음 상황에서 특히 중요하다.
| 작업 | 위험한 구조 | 더 안전한 구조 |
|---|---|---|
| production 권한 부여 | 요청자가 직접 자신에게 권한 부여 | 요청자, 승인자, 권한 부여자 분리 |
| schema 변경 | 개발자가 바로 production DDL 실행 | PR 리뷰, migration 승인, 배포자 분리 |
| 백업 복구 | 백업 관리자만 복구 검증 | 백업 운영자와 복구 검증자 분리 |
| 감사 로그 | 운영자가 로그 조회와 삭제 모두 가능 | 로그 저장소 write-only, 삭제 권한 제한 |
| 마스킹 해제 | 분석가가 원본 PII 접근 직접 승인 | data owner와 security 승인 필요 |
| 비상 접근 | 공용 admin 계정 사용 | named account, ticket, time-bound elevation |
역할 분리는 속도를 떨어뜨릴 수 있다. 그래서 모든 작업에 같은 강도의 분리를 적용하면 운영이 마비된다. 핵심은 위험도에 따라 분리 수준을 다르게 두는 것이다.
Public/Internal데이터: 일반 변경 관리와 peer review 중심Confidential데이터: owner 승인과 access review 필요Restricted데이터: security 승인, 세션 기록, 짧은 권한, export 제한- production control plane: break-glass와 사후 리뷰 필수
좋은 separation of duties는 “아무도 못 하게 하는 것”이 아니다. 누가 어떤 역할로 무엇을 했는지 남기고, critical action이 단독으로 끝나지 않게 만드는 것이다.
6. DBA와 데이터 플랫폼 엔지니어 관점의 기본 설계
데이터 보안 기본기를 운영에 넣으려면 다음 순서가 현실적이다.
6.1 먼저 데이터 지도를 만든다
처음부터 완벽한 catalog를 만들 필요는 없다. 가장 위험한 곳부터 시작한다.
- production DB 목록
- object storage bucket과 prefix
- BI dataset과 extract
- backup과 dump 위치
- Kafka topic과 DLQ
- Airflow connection과 secret
- query log와 audit log
각 항목에 owner, classification, 접근 그룹, 보존 기간을 붙인다. “owner 없음”은 보안 결함으로 취급한다.
6.2 raw 접근을 기본값에서 제외한다
데이터 플랫폼은 raw zone을 쉽게 열어 주고 싶어진다. 장애 분석, ad-hoc 분석, migration 검증이 편하기 때문이다. 하지만 raw zone에는 PII, token, payload, 삭제 요청 대상 데이터가 섞여 있을 수 있다.
기본 경로는 다음이 더 안전하다.
- raw 데이터는 pipeline과 제한된 운영자만 접근
- 분석은 masking 또는 pseudonymization된 curated table 사용
- 원본 PII 접근은 ticket, 목적, 기간, 승인자 필요
- export는 별도 권한으로 분리
- export 파일은 만료와 삭제 정책 적용
6.3 운영자 권한도 쪼갠다
DBA라고 해서 모든 권한이 항상 필요한 것은 아니다.
| 역할 | 평상시 권한 | 긴급 시 권한 |
|---|---|---|
| DB observer | metrics, logs, read-only catalog | 없음 |
| DB operator | replication status, kill session, controlled maintenance | 제한된 DDL 또는 failover action |
| DB admin | user/role 관리, backup/restore orchestration | break-glass superuser |
| Security reviewer | audit log, access review | 권한 부여 직접 수행 금지 |
이 구조를 만들면 장애 대응이 느려질 것 같지만, 실제로는 반대인 경우가 많다. 평상시 권한과 긴급 권한이 분리되어 있으면 “누가 superuser 비밀번호를 알고 있나” 같은 불명확한 상태가 줄어든다. 긴급 권한은 절차화되고, 사후 리뷰도 쉬워진다.
7. 운영 체크리스트
아래 질문에 답하지 못하면 아직 데이터 보안 기본기가 운영에 들어오지 않은 상태다.
| 질문 | 확인 방법 |
|---|---|
| production 데이터셋의 owner가 모두 있는가? | catalog, CMDB, repo metadata 점검 |
Restricted 데이터가 어디에 있는지 아는가? | discovery scan, column tag, DLP finding |
| raw PII를 직접 읽는 사람과 service account가 누구인가? | DB grants, IAM policy, query log |
| 임시 권한이 만료되는가? | access ticket, IAM condition, database role TTL 운영 |
| 백업과 dump도 원본과 같은 수준으로 보호되는가? | backup bucket policy, snapshot sharing 설정 |
| 감사 로그를 운영자가 삭제할 수 없는가? | log sink 권한, retention lock, 별도 계정 |
| 권한 요청자와 승인자가 분리되어 있는가? | access workflow, approval record |
| 비상 접근은 named account와 ticket으로 추적되는가? | break-glass log, session recording |
처음부터 모든 항목을 자동화할 수는 없다. 그래도 최소한 Restricted 데이터, production DB, 백업, audit log부터 시작해야 한다. 공격자나 내부 실수는 “가장 잘 정리된 policy 문서”가 아니라 “가장 느슨한 실제 접근 경로”를 따라간다.
8. 흔한 안티패턴
8.1 “읽기 권한은 안전하다”
데이터 보안에서 읽기는 가장 위험한 권한일 수 있다. SELECT 한 번이면 고객 목록, access token, 원본 payload가 외부 파일로 복사될 수 있다. 특히 BI export, notebook download, query result cache는 읽기 권한의 위험을 키운다.
8.2 “서비스 계정이니까 괜찮다”
service account는 사람이 아니어서 더 위험할 수 있다. 소유자가 바뀌어도 남고, 비밀번호나 key가 rotation되지 않고, 실제 사용 권한보다 훨씬 넓은 정책을 갖기 쉽다. service account에는 owner, 목적, 만료 또는 review 주기, 사용 위치가 있어야 한다.
8.3 “마스킹된 데이터는 항상 안전하다”
마스킹 방식에 따라 재식별 위험이 남는다. 이메일 일부만 가려도 다른 컬럼과 결합하면 개인을 추정할 수 있다. 집계 데이터도 segment가 너무 작으면 특정 개인이나 고객사를 드러낼 수 있다. 마스킹은 분류를 낮출 수 있는 후보이지, 자동 면책 장치가 아니다.
8.4 “admin은 감사 대상에서 제외한다”
가장 강한 권한일수록 더 강하게 기록해야 한다. DBA, platform admin, security admin의 작업은 장애 대응을 위해 필요하지만, 그래서 더더욱 named account, ticket, session log, 사후 리뷰가 필요하다.
마무리: 보안의 시작점은 catalog가 아니라 운영 결정이다
classification, least privilege, separation of duties는 보안팀만의 용어가 아니다. DBA와 데이터 플랫폼 엔지니어에게는 매일의 운영 결정을 정리하는 기준이다.
- 이 데이터는 어느 정도로 민감한가?
- 이 권한은 어떤 업무에 필요한가?
- 이 작업은 한 사람이 단독으로 끝내도 되는가?
- 나중에 누가 무엇을 했는지 설명할 수 있는가?
이 질문에 답할 수 있으면 다음 장에서 다룰 RBAC/ABAC, service account, credential rotation 같은 구체적인 권한 설계도 훨씬 단단해진다. 반대로 이 기준이 없으면 도구를 도입해도 권한은 계속 넓어지고, audit은 사후 변명 자료가 되며, 민감 데이터는 예외 경로로 흘러간다.
References
- NIST CSRC Glossary, “least privilege”: https://csrc.nist.gov/glossary/term/least_privilege
- NIST SP 800-60 Vol. 1 Rev. 1, “Guide for Mapping Types of Information and Information Systems to Security Categories”: https://csrc.nist.gov/pubs/sp/800/60/v1/r1/final
- NIST SP 800-12 Rev. 1, “An Introduction to Information Security”: https://doi.org/10.6028/NIST.SP.800-12r1
- CIS Critical Security Control 3, “Data Protection”: https://www.cisecurity.org/controls/data-protection
- AWS Prescriptive Guidance, “Security control recommendations for protecting data”: https://docs.aws.amazon.com/prescriptive-guidance/latest/security-controls-by-caf-capability/data-controls.html
- Microsoft Learn, “Get started with sensitivity labels”: https://learn.microsoft.com/en-us/purview/get-started-with-sensitivity-labels