개인정보·보안: masking, encryption, access control, audit log

데이터 플랫폼 엔지니어가 보안을 직접 다뤄야 하는 이유

데이터 플랫폼은 조직의 가장 민감한 정보가 모이는 곳이다. 사용자 행동, 결제 내역, 의료 기록, 인사 정보가 ingestion → 변환 → serving 레이어를 거치며 여러 저장소에 복제된다. 보안팀이 별도로 있더라도, 파이프라인 설계 단계에서 민감 데이터가 어느 경로를 통해 어디에 저장되는지 파악하고 있는 것은 플랫폼 엔지니어다.

보안 사고는 외부 공격보다 내부 설계 결함이나 접근 권한 실수로 생기는 경우가 많다. 개인정보가 포함된 staging 테이블이 public role에 노출되거나, S3 버킷이 리전 공개로 잘못 설정되거나, 로그에 신용카드 번호가 그대로 남아 있는 상황이 현실에서 반복된다. 이 장에서는 데이터 플랫폼에서 발생하는 개인정보·보안 문제를 masking, encryption, access control, audit log 네 가지 축으로 정리한다.

데이터 민감도 분류가 먼저다

마스킹이나 암호화를 적용하기 전에 어떤 데이터가 민감한지 파악해야 한다. 모든 컬럼에 동일한 보호를 적용하면 운영 비용이 높아지고, 보호 없이 쓰다가 뒤늦게 규정을 맞추려 하면 대규모 마이그레이션이 필요하다.

분류는 수동보다 자동화 도구를 쓰는 것이 현실적이다. BigQuery Data Catalog, AWS Macie, Collibra, OpenMetadata 같은 도구는 컬럼 이름과 샘플 값 패턴으로 PII를 자동 감지한다. 다만 자동 분류의 false negative(감지 누락)를 주기적으로 검토하는 수동 리뷰가 병행되어야 한다.

1. 마스킹: 민감 데이터를 숨기되 사용성을 유지한다

마스킹은 민감 데이터를 변형해서 원본을 알 수 없게 만드는 기법이다. 완전한 암호화와 달리 개발·테스트·분석 환경에서 실제 데이터와 유사한 구조의 데이터를 쓸 수 있어서 적용 범위가 넓다.

마스킹 기법 비교

가명화(Pseudonymization) 는 GDPR에서 중요한 기법이다. 개인을 직접 식별하는 정보를 제거하거나 코드로 바꾸어 추가 정보 없이는 특정 개인을 식별할 수 없게 만든다. 완전한 익명화와 달리 역복호화 키를 별도 보관하므로 필요 시 원본 참조가 가능하고, 복호화 접근은 엄격히 제한한다.

Static vs. Dynamic 마스킹

정적 마스킹(Static Data Masking) 은 원본 데이터를 물리적으로 변환해서 별도 복사본을 만든다. 개발·QA 환경에 마스킹된 복사본을 배포할 때 쓴다. 원본은 프로덕션에만 존재한다.

동적 마스킹(Dynamic Data Masking) 은 데이터를 물리적으로 바꾸지 않고, 쿼리 결과를 반환할 때 role에 따라 실시간으로 값을 숨긴다. Snowflake의 Column Masking Policy, BigQuery의 Column Policy Tag가 이 방식이다.

-- Snowflake: 마스킹 정책 생성 예시
create or replace masking policy email_mask as (val string)
returns string ->
  case
    when current_role() in ('ANALYST_FULL') then val
    when current_role() in ('ANALYST_LIMITED') then regexp_replace(val, '.+@', '****@')
    else '***MASKED***'
  end;

-- 테이블 컬럼에 적용
alter table users
  modify column email
  set masking policy email_mask;

동적 마스킹은 원본 데이터를 변경하지 않으므로 원래 값이 필요한 워크플로에서 권한이 있는 role은 계속 접근할 수 있다. 단, 마스킹 정책이 모든 쿼리 경로(뷰, 외부 테이블, export)를 커버하는지 검토해야 한다.

2. 암호화: 저장과 이동 구간을 모두 보호한다

암호화는 마스킹과 달리 데이터를 수학적으로 변환해서 키 없이는 읽을 수 없게 만든다. 플랫폼에서 암호화는 세 가지 구간으로 나눈다.

At-Rest 암호화

대부분의 클라우드 object storage는 기본 서버사이드 암호화(SSE)를 제공한다. 더 강한 키 통제가 필요하면 AWS KMS(SSE-KMS) 또는 고객 관리 키(SSE-C)를 사용한다. KMS를 쓰면 키 접근 권한을 IAM 정책으로 제어하고, 키 사용 내역이 CloudTrail에 기록된다.

컬럼 레벨 암호화(CLE)는 특정 컬럼만 암호화한다. 전체 테이블보다 암호화 대상을 줄여서 성능 오버헤드를 낮추고, 권한이 없는 사람이 raw 스토리지에 접근해도 해당 컬럼 값을 읽을 수 없다. PostgreSQL의 pgcrypto, MySQL의 AES_ENCRYPT/AES_DECRYPT, 또는 Snowflake의 ENCRYPT()/DECRYPT() 함수로 구현한다.

봉투 암호화 (Envelope Encryption)

클라우드 KMS는 봉투 암호화 방식을 쓴다. 실제 데이터는 데이터 암호화 키(DEK)로 암호화하고, DEK를 KMS의 마스터 키(CMK)로 다시 암호화해서 저장한다. 이 방식의 장점은 CMK를 로테이션해도 DEK만 다시 암호화하면 되고, 데이터 전체를 재암호화할 필요가 없다는 점이다.

3. Access Control: 필요한 사람이 필요한 것만 본다

민감 데이터 보호에서 가장 효과가 큰 것은 "올바른 사람만 접근할 수 있게 만드는 것"이다. 암호화와 마스킹이 데이터를 숨긴다면, 접근 제어는 아예 볼 수 없게 한다.

RBAC: 역할 기반 접근 제어

RBAC(Role-Based Access Control)는 사용자에게 직접 권한을 주지 않고, 역할(role)에 권한을 주고 사용자를 역할에 할당한다. 데이터 플랫폼에서는 역할을 계층적으로 설계하는 것이 일반적이다.

최소 권한 원칙(principle of least privilege)은 역할이 필요한 테이블만 접근하도록 제한한다. 서비스 계정에 SYSADMIN이나 warehouse 전체 접근을 주는 경우를 자주 보는데, 이는 파이프라인 장애나 코드 버그가 보안 사고로 이어질 수 있는 위험한 설정이다.

ABAC: 속성 기반 접근 제어

ABAC(Attribute-Based Access Control)는 사용자와 데이터에 속성을 부여하고, 속성 조건으로 접근을 결정한다. RBAC보다 세밀하고 동적인 제어가 가능하다.

예를 들어 "부서가 Finance인 사용자는 해당 부서의 급여 데이터만 볼 수 있다"는 정책을 ABAC로 표현하면, role이 아니라 user.department == data.department 조건으로 평가한다. Snowflake에서는 Row Access Policy로 ABAC 스타일의 행 단위 접근을 구현할 수 있다.

컬럼·행 단위 접근 제어

BigQuery에서는 Data Catalog Policy Tag를 컬럼에 붙이고, IAM 정책으로 특정 role만 해당 태그가 붙은 컬럼을 읽을 수 있게 한다. 태그가 없는 컬럼은 기본 테이블 접근 권한으로 읽히므로, PII 컬럼을 태그 없이 두면 노출된다.

4. Audit Log: 누가 언제 무엇을 했는지 기록한다

접근 제어로 권한을 제한해도, 권한 범위 내에서 민감 데이터를 과도하게 조회하거나 유출하는 경우를 탐지하려면 audit log가 필요하다. Audit log는 규정 준수를 위한 증거이기도 하지만, 이상 접근 탐지의 핵심 데이터 소스이기도 하다.

무엇을 로그해야 하는가

모든 DB 쿼리를 전부 로그하면 스토리지 비용과 노이즈가 너무 많다. 실용적인 기준은 민감 데이터가 포함된 테이블에 대한 접근 이벤트와 권한 변경 이벤트에 집중하는 것이다.

중요한 원칙이 있다. 로그 자체에 민감 데이터 원본 값을 넣지 않는다. 쿼리 결과 값이나 카드번호·주민번호가 로그에 그대로 쌓이면 로그 저장소가 새로운 공격 표적이 된다. query_text를 로그할 때도 값이 포함된 DML(WHERE ssn = '123-45-6789')은 해시 처리하거나 파라미터를 바인딩한 형태로만 저장한다.

Audit log의 이상 탐지 규칙 예시

5. 규정 준수와 데이터 플랫폼 엔지니어

개인정보 규정(GDPR, 국내 개인정보보호법)은 플랫폼 엔지니어가 직접 알아야 할 의무는 없지만, 기술 구현을 담당하는 만큼 규정 요건이 어떤 기술 설계로 이어지는지는 알아야 한다.

한국의 개인정보 보호법은 주민등록번호, 의료·금융 정보 등에 대한 암호화 의무, 접근 로그 보존(최소 3년), 이상 행위 탐지 의무를 명시한다. 규정 텍스트를 직접 읽기보다 보안·법무팀과 협의해서 플랫폼이 어떤 기술 통제를 제공해야 하는지 체크리스트를 만드는 것이 실용적이다.

6. 데이터 플랫폼 보안 점검 체크리스트

설계 단계와 정기 점검에서 확인해야 할 항목을 정리한다.

신규 파이프라인 온보딩 시 확인

• [ ] PII 컬럼이 어디에 저장되는지 파악했는가?
• [ ] staging 테이블의 접근 role이 필요한 service account만으로 제한되어 있는가?
• [ ] 마스킹 또는 익명화 처리 시점이 명확한가? (raw 이후 즉시 or mart에서 뷰로)
• [ ] 보존 기간 정책이 설정되어 있는가?
• [ ] 로그에 민감 데이터 원본 값이 포함되지 않는가?

정기 점검 (분기별)

• [ ] 미사용 service account 및 개인 계정 권한 정리
• [ ] 과도한 role (admin, sysadmin)을 가진 계정 현황
• [ ] 민감 테이블에 예상치 못한 새로운 접근자 없는지
• [ ] 생명주기 정책 적용 누락 테이블
• [ ] audit log 수집 커버리지 (민감 테이블 100% 로깅 여부)
• [ ] 데이터 삭제 요청 처리 결과 확인

마무리: 보안은 파이프라인 설계에 들어가야 한다

데이터 플랫폼에서 보안을 "나중에 얹는 것"으로 보면 항상 늦는다. 민감 데이터가 파이프라인을 통해 여러 저장소에 복제된 뒤에 마스킹을 추가하거나 접근 제어를 조이면, 이미 복제된 데이터를 하나씩 찾아서 정리해야 하는 대형 작업이 된다.

실용적인 접근은 새 파이프라인을 추가할 때 "이 파이프라인이 어떤 민감도의 데이터를 다루는가, 어디에 저장되는가, 누가 접근하는가, 얼마나 보존하는가"를 온보딩 체크리스트에 넣는 것이다. 이 네 가지 질문에 답하는 것이 masking, encryption, access control, audit log 설계의 출발점이다. 처음부터 맞게 만든 파이프라인은 운영 중 보안 사고를 막는 가장 효율적인 방법이다.

References

• Amazon Web Services, "What is Data Masking?," https://aws.amazon.com/what-is/data-masking/
• Snowflake, "Overview of Access Control," https://docs.snowflake.com/en/user-guide/security-access-control-overview
• Snowflake, "Column-Level Security using Masking Policies," https://www.phdata.io/blog/what-is-column-level-security-in-snowflake/
• Satori Cyber, "Pseudonymisation: 9 Ways to Protect Your PII," https://satoricyber.com/data-masking/pseudonymisation-9-ways-to-protect-your-pii/
• Immuta, "Data Masking vs. Tokenization," https://www.immuta.com/blog/tokenization-vs-data-masking/
• Onehouse, "Securing Your Data Lakehouse," https://www.onehouse.ai/blog/securing-your-data-lakehouse-best-practices-for-data-encryption-access-control-and-compliance
• ISO, "What is data masking? Types, techniques and best practice," https://www.iso.org/information-security/data-masking
• GDPR Logging and Monitoring guide, https://www.konfirmity.com/blog/gdpr-logging-and-monitoring
• TechTarget, "What is Data Masking?," https://www.techtarget.com/searchsecurity/definition/data-masking