At-Rest 암호화 — auth 로 부족할 때 · Solo Auth Quest

Auth 는 누가 물어볼 수 있는지를 정해. 암호화는 auth 를 이미 지나쳐버린 쪽 (도둑맞은 디스크, 뚫린 host, 나쁜 마음 먹은 클라우드 admin, 권한이 잘못 열린 backup) 이 뭘 읽을 수 있는지를 정하고.

세 tier

Tier	방어하는 것	노력
Disk-level (FileVault, LUKS)	전원 꺼진 디바이스의 물리적 도난	한 번만 하면 되고 공짜야. 요즘 OS 는 대부분 기본이 켜짐
Database-level (SQLCipher, Postgres TDE)	파일엔 닿지만 앱엔 못 들어온 상대	라이브러리를 바꾸면 됨. 하루쯤
Field-level (민감 컬럼 암호화)	Rogue DBA, leak 된 backup, 앱 레벨 XSS-extracted dump	손이 제일 많이 감. 게다가 key 관리라는 새 문제가 생김

Key 관리 현실

암호화는 보안 문제를 "데이터" 에서 "키" 로 옮겨놔. 그래서 새 질문이 생겨.

Key 가 어디 살아? (OS keychain, KMS, HSM, env var)
deploy 하거나 재시작할 땐 어떻게 되지? (서비스가 시작할 때 키를 가져와야 해)
키를 잃어버리면? (데이터가 영영 사라져. 키는 따로 백업해둬)
회전은 어떻게 하지? (새 키로 전부 다시 암호화해야 해. 규모가 커지면 간단하지 않아)

field 레벨 암호화가 값어치를 하는 것들

전부는 아니야. index 나 foreign key 를 암호화하면 쿼리 패턴이 깨져. 현실적인 목록은 이래. 사용자 대신 보관하는 API 키와 토큰, 개인 노트와 일기, 건강·재무 데이터, session 토큰 (보통은 one-way hash 로 충분해), 그리고 컴플라이언스 규정 (HIPAA, GDPR 특수 범주) 이 걸리는 것들.

Code

cryptography.Fernet 으로 field 레벨 암호화·python

from cryptography.fernet import Fernet

# 키는 Keychain 에서. repo 엔 절대 두지 마
fernet = Fernet(get_keychain("APP_DATA_KEY"))

def encrypt_field(value: str) -> bytes:
    return fernet.encrypt(value.encode())

def decrypt_field(blob: bytes) -> str:
    return fernet.decrypt(blob).decode()

# DB 엔 blob 만 저장. 앱이 write 할 때 암호화하고 read 할 때 복호화.
# Leak 된 backup 은 APP_DATA_KEY 없이 unreadable.

At-Rest 암호화 — auth 로 부족할 때

세 tier

Key 관리 현실

field 레벨 암호화가 값어치를 하는 것들

Code

External links

Exercise

Progress

댓글 0