Data Lake에 개인정보를 평문으로 저장해도 될까?

※ 본 글은 ISMS-P 인증심사 및 개인정보보호 실무 학습을 위한 가상의 사례를 바탕으로 작성한 교육용 콘텐츠다. 특정 기업이나 실제 심사 결과를 의미하지 않는다. 시스템 구성, 인터뷰 내용, 증적 및 수치는 이해를 돕기 위해 가공한 예시다.

Data Lake에 개인정보를 평문으로 저장해도 될까?

— ISMS-P 2.7 관점에서 보는 클라우드 데이터 암호화 통제

AWS S3와 같은 클라우드 스토리지에 개인정보를 저장하고 Athena, Spark 등의 분석 도구로 활용하는 데이터레이크 환경이 빠르게 늘어나고 있다.

문제는 운영 DB에서는 보호되고 있던 개인정보가 분석이나 마케팅 연계를 위해 Data Lake로 이동하는 과정에서 평문으로 저장되는 경우다.

특히 다음과 같은 이유가 자주 등장한다.

• 분석 쿼리 성능을 높이기 위해
• 외부 CRM API와 바로 매칭하기 위해
• 복호화 과정에서 발생하는 처리시간을 줄이기 위해
• 기존 시스템과의 호환성을 유지하기 위해
• 데이터 처리 구조를 단순화하기 위해

그러나 업무상 필요성이 있다는 이유만으로 개인정보를 평문 상태로 저장해도 되는 것은 아니다.

이번 글에서는 가상의 전자책 플랫폼을 예로 들어 운영 DB → AWS S3 Data Lake → Athena → 외부 CRM으로 이어지는 개인정보 처리 흐름을 살펴보고, ISMS-P 암호화 적용 관점에서 어떤 부분을 확인해야 하는지 정리한다.

---

1. 가상 기업 및 운영 환경

1.1 기업 환경

 

구분	내용
기업	A사
서비스	전자책 구독 및 소장 플랫폼
회원 규모	약 350만 명
주요 개인정보	이메일, 휴대폰번호, 회원 식별자 등
운영 DB	AWS Aurora MySQL
Data Lake	AWS S3
분석	AWS Athena
ETL	PySpark
외부 연계	Cloud CRM
주요 목적	맞춤형 도서 추천 및 타겟 마케팅

 

A사는 사용자의 독서 패턴과 구매 이력을 활용한 맞춤형 추천 및 타겟 마케팅 서비스를 신규 도입했다.

전체적인 데이터 흐름은 다음과 같다.

[Aurora MySQL]
       │
       │ PySpark ETL
       ▼
[AWS S3 Data Lake]
       │
       ├── AWS Athena 분석
       │
       └── Target Group 추출
                  │
                  ▼
          [외부 Cloud CRM]
                  │
                  ├── Email
                  └── App Push

 

문제는 Aurora에서는 보호되고 있던 개인정보가 Data Lake에서는 평문으로 저장되는 구조가 만들어졌다는 점이다.

---

2. 현장에서 확인된 운영 관행

가상의 인터뷰에서는 다음과 같은 답변이 확인됐다.

“운영 DB에서는 개인정보를 보호하고 있으며 S3 역시 IAM과 버킷 접근제어를 적용하고 있다.”

여기까지만 보면 특별한 문제가 없어 보인다.

그러나 Data Lake 내부의 실제 데이터 처리 방식을 확인한 결과, S3의 analytics_user_profile 데이터셋에는 외부 CRM API와의 수신자 매칭을 위해 이메일과 휴대폰번호가 평문으로 저장되고 있었다.

운영 담당자는 그 이유를 다음과 같이 설명한다.

“추출 시점에 마스킹이나 해시를 적용하면 CRM에서 수신자를 식별하지 못하는 문제가 발생하기 때문에 Data Lake와 CRM 연동 구간에서는 원본 값을 유지하고 있다.”

 

여기서 중요한 것은 단순히 왜 평문을 사용했는가가 아니다.

다음 사항을 확인해야 한다.

해당 개인정보에 대해 암호화 정책과 위험분석 결과에 따른 보호조치가 실제 처리환경에 적용되어 있는가?

---

3. 데이터 처리 파이프라인에서 발생하는 문제

가상의 ETL 과정은 다음과 같다.

raw_user_df = spark.read.jdbc(
    jdbc_url,
    "user_master",
    properties=connection_properties
)

raw_reading_df = spark.read.jdbc(
    jdbc_url,
    "user_reading_log",
    properties=connection_properties
)

transformed_df = raw_user_df.join(
    raw_reading_df,
    "user_id",
    "inner"
).select(
    "user_id",
    "user_email",
    "phone_number",
    "age_group",
    "gender",
    "preferred_genre",
    "last_read_date"
)

transformed_df.write \
    .mode("overwrite") \
    .partitionBy("preferred_genre") \
    .parquet(
        "s3://analytics-datalake/user_profile/"
    )

 

이 구조에서는 다음과 같은 데이터가 Data Lake에 생성될 수 있다.

user_id
user_email
phone_number
age_group
gender
preferred_genre
last_read_date

 

특히 user_email과 phone_number가 원본 문자열 그대로 저장된다면 S3 객체 자체가 직접 식별 가능한 개인정보 저장소가 된다.

원문에서도 PySpark ETL 과정에서 이메일과 휴대폰번호를 평문 상태로 S3 Parquet 데이터셋에 저장하도록 구성되어 있다.

---

4. “S3 접근권한을 잘 막았으니 괜찮다”는 판단의 한계

현장에서 자주 나오는 설명 중 하나가 다음과 같다.

“S3 버킷은 외부 공개가 차단되어 있고 IAM 권한도 제한되어 있으므로 평문으로 저장해도 안전하다.”

하지만 암호화와 접근통제는 서로 대체 관계가 아니다.

예를 들어 다음과 같은 상황을 생각할 수 있다.

S3
 │
 ├─ IAM 권한
 │    └─ 분석팀 접근 가능
 │
 ├─ Athena
 │    └─ 쿼리 가능
 │
 └─ CRM Pipeline
      └─ 원본 데이터 접근

IAM 설정이 잘못되거나,

• 과도한 권한이 부여되거나
• 분석 계정이 탈취되거나
• 역할(Role)이 잘못 위임되거나
• S3 객체가 다른 계정으로 공유되거나
• ETL 작업 권한이 과도하게 부여되거나
• 데이터가 임시 스테이징 영역으로 복사되는 경우

평문 데이터가 그대로 노출될 가능성이 있다.

따라서 점검에서는 단순히

“S3가 외부에서 접근되지 않는다.”

 

만 확인할 것이 아니라,

개인정보가 저장·전송·전달되는 각 구간에 어떤 보호조치가 적용되어 있는가?

 

를 확인해야 한다.

---

5. ISMS-P에서는 어떤 기준을 확인해야 할까?

이 사례의 핵심 기준은 ISMS-P 2.7 암호화 적용이다.

현재 ISMS-P 인증기준에서도 2.7은 ‘암호화 적용’ 항목으로 구성되어 있다.

세부적으로는 다음 사항을 중심으로 확인할 필요가 있다.

암호정책 적용

• 암호화 대상이 정의되어 있는가?
• 관련 법적 요구사항을 반영했는가?
• 개인정보 유형별 암호화 기준이 있는가?
• 저장 시 암호화가 필요한 데이터가 정의되어 있는가?
• 전송·전달 구간에 암호화가 적용되는가?
• 안전한 암호 알고리즘 및 보안강도를 사용하는가?
• 암호화 예외가 있다면 근거와 승인절차가 있는가?

암호키 관리

• 암호키 관리절차가 존재하는가?
• KMS 등 안전한 키 관리수단을 사용하는가?
• 키 접근권한이 최소화되어 있는가?
• 키의 생성·변경·폐기 절차가 존재하는가?
• 운영환경과 개발환경의 키가 분리되어 있는가?
• 키가 소스코드나 설정파일에 하드코딩되어 있지 않은가?

이 사례에서는 단순히 S3의 암호화 기능 활성화 여부만 확인할 것이 아니라 조직의 암호화 정책에서 해당 데이터와 처리구간을 어떻게 정의하고 있는지를 먼저 확인해야 한다.

---

6. 개인정보 보호법 제29조와 함께 확인해야 하는 이유

개인정보 보호법 제29조는 개인정보처리자가 개인정보의 유출 등을 방지하기 위해 대통령령에서 정하는 바에 따라 안전성 확보에 필요한 기술적·관리적·물리적 조치를 하도록 규정하고 있다. 현재 법령에도 이러한 안전조치의무가 규정되어 있다.

개인정보 보호법 시행령 제30조에서는 접근권한 제한 등 개인정보의 안전성 확보를 위한 구체적인 조치를 규정하고 있다.

또한 개인정보보호위원회는 2024년 「개인정보의 안전성 확보조치 기준 안내서」를 공개하면서 개정된 안전성 확보조치 기준과 문의사례 등을 반영했다고 안내하고 있다.

따라서 이 사례를 단순히

“S3에 평문 저장했으니 법 위반이다.”

 

라고 결론내리는 것은 적절하지 않다.

보다 정확한 접근은 다음과 같다.

해당 개인정보의 종류와 처리환경에 적용되는 안전조치 요구사항을 확인하고, 내부 암호화 정책 및 위험분석 결과에 따라 적절한 보호조치가 적용되어 있는지를 확인한다.

 

즉, 평문 저장이라는 사실 자체만으로 모든 법적 판단이 끝나는 것이 아니라 해당 환경에 요구되는 보호조치와 실제 운영상태를 함께 확인해야 한다.

---

7. 마스킹과 암호화는 같은 조치가 아니다

실무에서 자주 혼동하는 부분이다.

 

구분	목적	예시
마스킹	화면 등에서 개인정보 표시 제한	ab***@example.com
암호화	원본 데이터를 암호문으로 변환하여 보호	AES 등
해시	특정 값을 다른 값으로 변환	SHA-256
가명처리	추가정보 등을 이용하지 않고는 특정 개인을 알아보기 어렵게 처리	가명 식별자 등

 

따라서 다음과 같은 표현은 주의해야 한다.

“이메일을 화면에서 ab***@example.com으로 표시했으므로 암호화했다.”

 

이는 맞지 않다.

화면 마스킹은 표시 제한이고 저장 데이터에 대한 암호화와는 별개의 보호조치다.

원문에서도 웹 Dashboard에서는 이메일 일부를 마스킹하고 있었지만, 실제 S3 Parquet 데이터셋에서는 이메일과 휴대폰번호를 평문으로 유지하는 구조가 확인된다.

---

8. SHA-256을 적용하면 개인정보가 없어지는가?

이 역시 자주 나오는 오해다.

예를 들어 다음과 같이 처리했다고 가정한다.

.withColumn(
    "user_hash_id",
    sha2(col("user_id"), 256)
)

 

이렇게 생성된 값은 원래의 user_id 대신 사용할 수 있는 식별자로 활용할 수 있다.

하지만 단순히 SHA-256을 적용했다는 사실만으로 자동으로 가명처리가 완료되거나 개인정보 위험이 사라지는 것은 아니다.

특히 이메일이나 전화번호처럼 가능한 원본값의 범위가 제한된 데이터는 추측이나 대조를 통해 원본을 알아낼 가능성을 검토해야 한다.

따라서 실무에서는 다음을 함께 확인해야 한다.

• 어떤 값을 해시하는가?
• Salt 또는 별도 비밀값을 사용하는가?
• 동일한 입력값이 항상 동일한 결과를 만들어야 하는가?
• 원본값과 결과값을 연결할 수 있는 추가정보가 존재하는가?
• 해당 결과값에 접근할 수 있는 사람은 누구인가?
• 다른 데이터셋과 결합했을 때 개인을 다시 식별할 가능성이 있는가?

즉,

“SHA-256 적용 = 안전”

 

이라는 단순한 공식으로 판단해서는 안 된다.

---

9. Data Lake에서는 저장영역을 분리하는 것이 중요하다

개인정보가 필요한 모든 분석 작업에 원본 이메일과 전화번호를 제공하는 구조는 피할 필요가 있다.

예를 들어 다음과 같이 영역을 구분할 수 있다.

                    ┌─────────────────────┐
                    │    Aurora MySQL     │
                    │  원본 개인정보 관리  │
                    └──────────┬──────────┘
                               │
                         ETL / 통제
                               │
                ┌──────────────▼──────────────┐
                │       Restricted Zone       │
                │ 최소한의 원본 개인정보      │
                │ 접근권한 최소화              │
                └──────────────┬──────────────┘
                               │
                       가명/분석 데이터
                               │
                ┌──────────────▼──────────────┐
                │       Analytics Zone        │
                │ 가명식별자 중심 분석         │
                │ Athena 조회                 │
                └──────────────┬──────────────┘
                               │
                       필요한 경우에만
                               │
                ┌──────────────▼──────────────┐
                │        CRM Zone             │
                │ 목적에 필요한 데이터만 전달 │
                └─────────────────────────────┘

핵심은 모든 데이터셋에서 동일한 수준의 개인정보를 사용할 필요가 없도록 설계하는 것이다.

분석업무에 이메일 주소가 필요하지 않다면 분석영역까지 원본 이메일을 전달하지 않는 것이 더 적절한 통제가 될 수 있다.

---

10. 외부 CRM 연동에서는 별도의 통제가 필요하다

외부 Cloud CRM을 사용한다면 암호화 문제만 확인해서는 부족하다.

다음 사항도 별도로 확인할 필요가 있다.

처리 목적

• 마케팅 목적의 개인정보 이용이 적법한가?
• 처리 목적과 실제 CRM 활용 범위가 일치하는가?

외부 제공·위탁

• 해당 CRM 사업자의 역할은 무엇인가?
• 개인정보 처리위탁에 해당하는가?
• 제3자 제공에 해당하는가?
• 계약 및 관리·감독 절차가 마련되어 있는가?

국외 이전

• CRM 서비스의 데이터 저장 위치는 어디인가?
• 국외 이전이 발생하는가?
• 발생한다면 관련 절차가 적용되어 있는가?

전송구간

• CRM API 통신구간이 안전하게 암호화되어 있는가?
• API 인증정보와 키가 안전하게 관리되는가?
• 스테이징 영역에 생성된 파일은 언제 삭제되는가?

이 글의 가상 시나리오만으로는 위 사항의 구체적인 사실관계를 확인할 수 없으므로 별도의 검토 항목으로 분리하는 것이 적절하다.

---

11. 기술적으로는 “암호화 위치”를 설계해야 한다

암호화를 적용한다고 해서 모든 데이터를 동일한 방식으로 암호화하면 되는 것은 아니다.

예를 들어 분석용 데이터에 다음과 같은 구조가 있을 수 있다.

user_hash_id
email_ciphertext
phone_ciphertext
age_group
gender
preferred_genre
last_read_date

분석팀은 대부분의 작업에서 email_ciphertext, phone_ciphertext를 직접 사용할 필요가 없다.

따라서 Athena에서는 다음과 같이 분석용 View를 제공하는 방식도 검토할 수 있다.

CREATE VIEW analytics_user_summary AS
SELECT
    user_hash_id,
    age_group,
    gender,
    preferred_genre,
    last_read_date
FROM user_profile;

이렇게 하면 일반 분석업무에서 원본 이메일이나 전화번호에 직접 접근할 필요가 줄어든다.

---

12. CRM 발송 시에는 필요한 시점에만 식별정보를 사용한다

CRM 발송 때문에 이메일과 전화번호가 반드시 필요한 경우에도 전체 분석환경에 원본 개인정보를 노출할 필요는 없다.

예를 들어 다음과 같이 영역을 분리할 수 있다.

[Analytics]

user_hash_id
     │
     │ target_user 선정
     ▼
[Restricted CRM Mapping]
     │
     │ 필요한 사용자만 매핑
     ▼
email / phone
     │
     │ 암호화된 API 통신
     ▼
[External CRM]

이 구조의 핵심은 분석 목적과 발송 목적의 데이터 요구사항을 분리하는 것이다.

분석팀 전체가 이메일과 전화번호를 볼 필요가 없다면 해당 권한을 제공하지 않는 것이 바람직하다.

---

13. 암호키는 데이터와 분리해야 한다

암호화를 적용하면서도 다음과 같은 구조라면 문제가 된다.

aes_encrypt(
    email,
    "MY_AES_KEY_123456"
)

특히 실제 운영환경에서 키가 다음과 같이 저장되는 것은 피해야 한다.

소스코드
설정파일
Git Repository
배치 스크립트
Docker Image
로그 파일

AWS 환경이라면 KMS 등 적절한 키 관리수단을 활용하고, 애플리케이션이나 ETL 작업에는 필요한 권한만 부여하는 구조를 검토할 수 있다.

개념적으로는 다음과 같은 구조다.

PySpark ETL
     │
     │ IAM Role
     ▼
AWS KMS
     │
     ▼
암호키 사용
     │
     ▼
S3 암호화 데이터

이때 중요한 것은 단순히 “KMS를 사용한다”가 아니다.

누가 어떤 키를 어떤 목적으로 사용할 수 있는지까지 통제하는 것이 중요하다.

---

14. 심사에서는 어떤 증적을 확인할까?

이와 같은 환경이라면 다음 자료를 확인할 수 있다.

정책·관리 측면

• 암호화 정책
• 암호화 대상 정의
• 암호 알고리즘 및 보안강도 기준
• 암호키 관리절차
• 개인정보 처리 현황
• 위험분석 결과
• 예외 승인 기록

AWS 환경

• S3 Bucket Policy
• IAM Policy
• IAM Role
• KMS Key Policy
• S3 기본 암호화 설정
• CloudTrail
• S3 접근 로그
• Athena Workgroup 및 접근권한

ETL

• PySpark 소스코드
• ETL 배치 설정
• 실행계정
• Secrets 관리방식
• 암호화 적용 여부
• 임시파일 생성 위치
• 스크립트 내 개인정보 및 암호키 노출 여부

외부 CRM

• 계약서
• 개인정보 처리위탁 관련 자료
• API 연계 명세
• 전송구간 암호화 설정
• API 인증정보 관리
• 데이터 보관 및 삭제정책
• 국외 이전 여부

---

15. 인터뷰에서 확인하면 좋은 질문

실제 심사나 내부 점검이라면 다음 질문이 유용하다.

질문 1

운영 DB에서는 암호화되어 있는데 Data Lake에서는 평문으로 저장하는 이유는 무엇인가?

단순히 “CRM API가 필요해서”라는 답변에서 끝내지 않고 정책상 예외인지, 위험분석을 했는지를 확인한다.

질문 2

이메일과 전화번호에 대해 암호화 대상 여부를 어떤 기준으로 판단했는가?

암호화 정책과 실제 운영환경이 일치하는지 확인한다.

질문 3

S3에서 원본 이메일과 전화번호를 조회할 수 있는 사람은 누구인가?

IAM 권한과 실제 업무상 필요성을 비교한다.

질문 4

Athena 분석 담당자가 원본 이메일을 조회해야 하는 업무가 있는가?

업무상 필요성과 최소권한 원칙을 확인한다.

질문 5

CRM 발송용으로 생성된 임시 파일은 언제 삭제되는가?

평문 데이터가 별도의 스테이징 영역으로 복제되는지를 확인한다.

질문 6

암호키는 어디에서 관리하고 누가 접근할 수 있는가?

암호키 관리 기준과 실제 운영환경이 일치하는지 확인한다.

---

16. 자주 발생하는 판단 오류

오류 1. “S3는 Private이니까 괜찮다”

S3 접근통제는 중요한 보호조치지만 암호화 정책 적용 여부와 동일한 개념은 아니다.

---

오류 2. “마스킹했으니까 암호화했다”

마스킹과 암호화는 서로 다른 보호조치다.

---

오류 3. “SHA-256이면 개인정보가 아니다”

해시 결과가 개인과 연결될 가능성이 있는지 별도로 검토해야 한다.

---

오류 4. “KMS를 사용하니까 암호화 통제는 끝났다”

키 관리수단을 사용하더라도 실제 데이터가 암호화되어 있는지, 어떤 데이터가 암호화 대상인지, 접근권한이 적절한지 확인해야 한다.

---

오류 5. “CRM 때문에 평문이 필요하므로 예외다”

업무상 필요성이 있다는 것과 암호화 정책상 적절한 예외라는 것은 다르다.

예외를 허용한다면 최소한 다음 사항을 확인할 필요가 있다.

업무상 필요성
      ↓
위험분석
      ↓
대체 보호조치 검토
      ↓
예외 승인
      ↓
접근권한 최소화
      ↓
기간·범위 제한
      ↓
정기 재검토

---

17. 이 사례에서 개선된 데이터 구조

기존 구조가 다음과 같았다면,

Aurora
  ↓
PySpark
  ↓
S3
  ├─ email 평문
  ├─ phone 평문
  └─ 분석 데이터
       ↓
    Athena
       ↓
    CRM

개선 구조는 다음과 같이 설계할 수 있다.

Aurora
  │
  ▼
PySpark ETL
  │
  ├───────────────┐
  │               │
  ▼               ▼
Restricted      Analytics
Zone            Zone
  │               │
  │             가명식별자
  │               │
  │               ▼
  │             Athena
  │               │
  └───────┬───────┘
          │
     필요한 사용자만
          │
          ▼
    CRM Mapping
          │
      암호화 전송
          │
          ▼
     External CRM

이 구조에서 중요한 것은 원본 개인정보를 무조건 없애는 것만이 목표가 아니라, 원본 개인정보에 접근해야 하는 범위 자체를 줄이는 것이다.

---

18. 사후 검증은 “암호화 설정이 켜져 있는가”에서 끝나면 안 된다

실제 점검에서는 다음을 함께 확인하는 것이 좋다.

S3

□ 저장 데이터 암호화 설정
□ Bucket Policy
□ IAM Role
□ Object 접근권한
□ Public Access 차단
□ KMS Key Policy

Athena

□ 테이블/뷰 접근권한
□ 원본 개인정보 컬럼 노출 여부
□ 쿼리 권한
□ Query Result 저장 위치
□ Query Result에 개인정보 포함 여부

ETL

□ 원본 데이터 접근권한
□ 임시파일
□ 로그 내 개인정보 포함 여부
□ 스크립트 내 암호키 존재 여부
□ Secrets 관리방식

CRM

□ 전송 데이터 최소화
□ API 인증정보 관리
□ 전송구간 보호
□ 스테이징 데이터 삭제
□ 외부 서비스 보관기간

---

19. “암호화 적용”과 “데이터 최소화”를 함께 봐야 한다

이번 사례에서 가장 중요한 실무 포인트는 이것이다.

암호화만 적용한다고 개인정보 보호 문제가 모두 해결되는 것은 아니다.

예를 들어 분석팀이 실제로 이메일 주소를 필요로 하지 않는다면,

이메일 평문

을

암호화된 이메일

로 바꾸는 것보다 더 근본적인 방법은

이메일 자체를 분석 영역에서 제거

하는 것이다.

즉,

원본 개인정보
     ↓
필요성 검토
     ↓
불필요한 정보 제거
     ↓
필요한 데이터만 가명화/암호화
     ↓
접근권한 최소화
     ↓
전송구간 보호

와 같은 순서로 설계하는 것이 효과적이다.

---

20. 최종 점검 체크리스트

점검항목확인

개인정보 처리현황 파악	□
개인정보 유형별 암호화 대상 정의	□
암호화 정책 수립	□
저장 시 암호화 적용	□
전송·전달 구간 암호화	□
안전한 암호 알고리즘 사용	□
암호키 관리절차 수립	□
KMS 등 키 관리수단 적용	□
키 접근권한 최소화	□
Data Lake 접근권한 최소화	□
분석영역 원본 개인정보 최소화	□
Athena 조회권한 제한	□
CRM 연계 데이터 최소화	□
스테이징 데이터 관리	□
로그 내 개인정보 노출 여부 확인	□
외부 CRM 위탁·제공 여부 검토	□
국외 이전 여부 검토	□
정기적인 통제 검증	□

---

21. 이번 사례에서 얻을 수 있는 실무적인 교훈

Data Lake 환경에서는 개인정보가 한 번만 저장되는 것이 아니다.

운영 DB
 ↓
ETL
 ↓
Raw Data
 ↓
Cleansed Data
 ↓
Analytics Data
 ↓
Athena 결과
 ↓
Staging
 ↓
CRM

데이터가 여러 단계로 복제되면서 원래 DB에서는 존재하지 않던 새로운 개인정보 저장소가 만들어질 수 있다.

따라서 개인정보 보호 담당자는 운영 DB만 확인해서는 안 된다.

다음 질문을 함께 확인해야 한다.

“이 개인정보가 실제로 어디까지 복제되고 있는가?”

그리고 그 다음 질문은 다음과 같다.

“각 구간에서 이 개인정보를 정말 원본 형태로 가지고 있어야 하는가?”

마지막으로,

“원본이 필요한 구간에서는 어떤 암호화·접근통제·키 관리가 적용되어 있는가?”

까지 확인해야 한다.

---

22. 마무리

클라우드 Data Lake 환경에서 개인정보 보호의 핵심은 단순히 “S3 암호화를 켜는 것”이 아니다.

실제 운영환경에서는 다음 네 가지를 함께 봐야 한다.

① 어떤 개인정보를 보유하는가?
        ↓
② 어디까지 복제되는가?
        ↓
③ 누가 원본을 볼 수 있는가?
        ↓
④ 저장·전송·키 관리 보호조치가 적절한가?

특히 ISMS-P 관점에서는 2.7 암호화 적용을 중심으로 법적 요구사항, 암호화 대상, 암호강도, 저장·전송·전달 구간의 보호조치가 실제 운영환경에 적용되어 있는지 확인하는 것이 중요하다. 현재 ISMS-P 공식 인증기준에서도 2.7은 ‘암호화 적용’으로 분류되어 있다.

개인정보 보호법 제29조 역시 개인정보의 유출 등을 방지하기 위해 필요한 안전성 확보조치를 요구하고 있으며, 시행령 제30조에서 접근권한 제한 등 구체적인 안전조치 사항을 규정하고 있다.

그리고 암호화만으로 끝내지 않고 데이터 최소화 → 접근권한 최소화 → 가명화/암호화 → 안전한 전송 → 암호키 관리 → 지속적인 검증까지 하나의 통제로 연결해야 한다.

결국 Data Lake의 개인정보 보호는 특정 AWS 설정 하나의 문제가 아니라,

데이터가 생성되는 순간부터 분석·연계·삭제되는 순간까지 개인정보의 전체 흐름을 통제하는 문제

라고 보는 것이 실무적으로 더 적절하다.

---

참고자료

• 개인정보 보호법 제29조(안전조치의무) — 국가법령정보센터
• 개인정보 보호법 시행령 제30조(개인정보의 안전성 확보 조치) — 국가법령정보센터
• ISMS-P 인증기준 — 2.7 암호화 적용
• 개인정보의 안전성 확보조치 기준 안내서 — 개인정보보호위원회