암호화

서버 안에 들어온 데이터는 안전하다고 보던 시절이 길었습니다. 로그인 화면만 지키면 그 뒤는 우리 영역이라는 전제였고, 데이터베이스에는 이름과 연락처와 고객이 쓴 문서가 읽을 수 있는 그대로 적혀 있었습니다.

그 전제는 유출 사고가 날 때마다 무너졌습니다. 관리자 계정 하나가 털리거나 백업 파일이 잘못된 저장소에 올라가면, 상대가 손에 넣은 파일 하나에 고객 12만 명의 정보가 표 그대로 들어 있었습니다. 다음 날 나가는 공지에는 늘 같은 두 문장이 들어갑니다. 침입 경로는 막았다는 말과, 이미 나간 자료는 되돌릴 방법이 없다는 말입니다. 오가는 구간도 사정이 같아서, 카페 와이파이로 로그인하면 같은 망에 앉은 사람이 아이디와 비밀번호를 들여다볼 수 있었습니다.

암호화는 관문이 언젠가 한 번은 열린다고 가정하고, 그때 상대가 들고 가는 것이 읽을 수 없는 덩어리가 되도록 미리 바꿔 두는 방법입니다. 접속한 사람이 누구인지 확인하는 인증이나 그 사람이 이 일을 해도 되는지 판단하는 인가가 문 앞에서 막는 일이라면, 이쪽은 문이 열린 뒤를 준비하는 일입니다.

무엇을 바꿔 둘지 고르고, 저장과 전송 두 구간에 각각 방식을 정하고, 열쇠를 데이터와 따로 보관하는 순서로 붙입니다.

1. 대상 고르기 — 가진 데이터를 전부 바꾸지는 않습니다. 바꿔 둔 값은 검색도 정렬도 되지 않기 때문입니다. 이름·연락처·주민등록번호 같은 개인 식별 정보, 곧 한 사람을 특정할 수 있는 항목과 고객이 쓴 문서 본문이 먼저입니다. 가입일이나 조회수처럼 새 나가도 사람을 다치게 하지 않는 값은 그대로 둡니다.
2. 구간 나누기 — 오가는 구간과 쌓여 있는 구간을 따로 봅니다. 오가는 구간은 TLS를 붙입니다. 주소창의 자물쇠 표시가 그것이고, 붙이면 같은 망에 앉은 사람이 내용을 읽지 못합니다. 쌓여 있는 구간은 다시 둘로 갈립니다. 디스크 전체를 바꿔 두면 서버를 통째로 들고 갔을 때만 막아 주고, 조회 권한을 손에 넣은 상대에게는 여전히 평문으로 보입니다. 실제 유출에 답하려면 항목 단위로 걸어야 합니다.
3. 방식 고르기 — 잠글 때와 열 때 같은 열쇠를 쓰는 방식이 빠르고, 열쇠를 두 개로 나눠 하나는 공개하고 하나는 숨기는 방식은 느린 대신 열쇠를 안전하게 건넬 수 있습니다. 실제 서비스는 둘을 섞습니다. 느린 쪽으로 열쇠만 주고받고, 본문은 빠른 쪽으로 처리합니다.
4. 열쇠 보관 — 열쇠는 데이터와 같은 곳에 두지 않습니다. 코드 저장소나 설정 파일에 적어 두면 저장소 접근 권한을 얻은 사람이 데이터와 열쇠를 함께 가져갑니다. 그래서 시크릿 관리, 곧 열쇠와 비밀번호를 따로 보관했다가 실행 시점에만 넣어 주는 장치를 함께 씁니다.
5. 교체와 복구 계획 — 열쇠는 주기적으로 바꾸고, 바꾼 뒤에도 옛 열쇠로 잠긴 데이터를 읽을 수 있도록 순서를 미리 정해 둡니다. 열쇠를 잃으면 데이터도 함께 잃습니다. 지운 것과 결과가 같아서 열쇠 백업도 데이터 백업만큼 챙깁니다.

원래 내용을 나중에 다시 읽어야 하는 데이터에 씁니다. 고객이 쓴 문서 본문, 연락처, 계약서 파일이 그렇습니다. 되돌릴 수 있다는 성질이 여기서는 기능입니다.

반대로 원래 값을 알 필요가 아예 없는 데이터에는 쓰지 않습니다. 비밀번호가 대표적이고, 이때는 되돌릴 수 없게 뭉개는 해싱을 씁니다. 분석팀이나 외부에 넘길 데이터라면 개인을 알아볼 수 없게 가공하는 비식별 처리가 맞습니다. 열쇠를 함께 넘겨야 하는 암호화는 넘긴 뒤를 통제하지 못합니다.

계약 때문에 붙이는 경우도 많습니다. SOC 2처럼 고객사가 도입 전에 보내는 보안 점검표에 저장 시 암호화 항목이 거의 빠지지 않습니다.

한계는 세 가지입니다. 첫째, 열쇠를 가진 쪽에서는 평문입니다. 서비스가 내용을 보여 주려면 열쇠를 들고 있어야 하므로, 서버가 장악되면 열쇠도 함께 넘어갑니다. 둘째, 권한 검사를 대신하지 못합니다. 로그인한 사용자가 주소의 숫자를 바꿔 남의 문서를 여는 사고는 서비스가 정상적으로 열쇠를 써서 보여 주는 과정이라 이 방법과 무관합니다. 셋째, 운영 비용이 듭니다. 항목 단위로 걸면 그 항목으로 검색하는 기능을 포기하거나 따로 만들어야 합니다.

"이 컬럼은 저장할 때 암호화돼서 이름으로 검색은 못 합니다."

기능 요구를 거절하는 말이 아니라, 검색이 필요하면 다른 설계를 같이 정하자는 뜻입니다.

"열쇠가 코드 저장소에 같이 들어가 있으면 안 건 거나 마찬가지예요."

잠금 자체보다 열쇠를 어디에 두었는지가 실제 안전을 가른다는 지적입니다.

"고객사 점검표에 저장 시 암호화 항목이 있어서 이번 스프린트에 넣어야 합니다."

기술 판단이 아니라 계약 조건으로 일정이 정해진 경우입니다.

페이지덱에서 이 말이 오간 것은 처음으로 기업 고객과 계약을 앞두었을 때입니다. 세일즈 수아가 받아 온 보안 점검표에 고객 데이터 저장 시 암호화 여부를 묻는 항목이 있었고, 개발자 태오가 문서 본문 항목에 암호화를 붙였습니다. 붙이고 나서 걸린 것은 성능이 아니라 검색이었습니다. 제목으로 찾는 기능이 본문까지 훑던 구조였는데, 본문이 읽히지 않으니 결과가 비어 버린 겁니다.

결국 검색용 색인을 따로 두고 본문은 잠근 채로 남기는 쪽으로 정리했습니다.

암호화를 걸어 두면 그 데이터는 안전해진다고 보는 오해가 가장 흔합니다. 잠갔다는 말이 안전하다는 말처럼 들리니 자연스럽습니다. 실제로 안전을 결정하는 것은 잠금이 아니라 열쇠의 위치입니다. 열쇠가 같은 서버의 설정 파일에 적혀 있으면 데이터를 가져간 상대가 열쇠도 함께 가져갑니다. 그 상태로 사고가 나면 대외적으로는 암호화된 자료가 유출됐다고 알리게 되는데, 실제로는 평문이 나간 것과 다르지 않습니다.

주소창에 자물쇠가 떠 있으니 저장된 데이터도 잠겨 있다고 보는 오해도 자주 나옵니다. 같은 말로 부르다 보니 한 번 걸면 끝이라고 생각하기 쉽습니다. 오가는 구간과 쌓여 있는 구간은 별개라서 각각 따로 붙여야 합니다. 앞만 갖춘 상태에서 백업 파일이 새 나가면, 그 안의 내용은 처음부터 잠긴 적이 없습니다.