개인 식별 정보

데이터를 한 덩어리로 다루면 규칙도 한 덩어리로 걸 수밖에 없습니다. 전체를 엄격하게 잠그면 분석하는 사람이 매번 승인을 받아야 해서 아무도 데이터를 보지 않게 되고, 느슨하게 두면 이름과 연락처가 아무 화면에나 실립니다. 둘 다 잘못된 선택인데 중간이 없습니다.

느슨하게 둔 쪽에서 사고가 먼저 났습니다. 분석용으로 복사한 표에 사용자 메일 주소가 그대로 들어가고, 그 표로 만든 사내 대시보드에 200명의 메일이 화면에 떴습니다. 계정 이름을 확인하려고 같이 옮겨 둔 칸이었습니다.

지우려는 순간 더 큰 문제가 드러났습니다. 그 메일 주소가 어느 표에 몇 군데 들어 있는지 아무도 몰랐습니다. 원천 표에서 지워도 가공된 표 넷에 남아 있고, 그중 하나는 외부 분석 도구로 매일 나가고 있었습니다.

그래서 데이터를 한 덩어리로 보지 않고 어느 칸이 사람을 특정하는 칸인지 표시하는 개념이 자리를 잡았습니다. 표시가 있으면 규칙을 전체가 아니라 그 칸에만 걸 수 있습니다.

무엇이 여기 해당하는지부터 정합니다. 두 종류로 갈립니다.

1. 혼자서 사람을 특정하는 값입니다. 이름, 전화번호, 메일 주소, 주민등록번호, 계좌번호가 여기입니다.
2. 조합으로 특정되는 값입니다. 생년월일과 우편번호와 성별 셋만 있으면 특정 지역에서 한 사람이 남는 경우가 많습니다. 이쪽이 자주 빠집니다. 각각은 개인정보가 아닌 것처럼 보이기 때문입니다. 그래서 표시를 다는 기준을 문서로 적어 두고 새 칸이 생길 때마다 대조합니다.

표시는 칸 단위로 답니다. 회사 안에 어떤 데이터가 어디 있는지 정리해 둔 목록에 이 칸이 해당한다는 표시를 달고, 그 표시를 기준으로 뒤의 규칙이 자동으로 적용되게 만듭니다. 사람이 매번 판단하는 방식은 표가 200개가 되는 순간 무너집니다.

붙는 규칙은 넷입니다.

1. 열람 권한을 좁힙니다. 그 칸이 든 표는 필요한 역할만 열 수 있게 하고, 나머지에게는 그 칸을 뺀 뷰를 줍니다.
2. 보관 기간을 따로 둡니다. 나머지 데이터는 3년을 두더라도 이 칸은 목적을 다하면 지웁니다.
3. 밖으로 내보내는 파일에서 뺍니다. 협력사에 주는 파일과 외부 분석 도구로 나가는 데이터가 여기 걸립니다.
4. 접근 기록을 남깁니다. 누가 언제 그 칸을 조회했는지가 남아 있어야 사고가 났을 때 범위를 잴 수 있습니다. 기록이 없으면 유출 범위를 추정으로 답하게 됩니다.

수집 단계에서 줄이는 것이 가장 값싼 방법입니다. 필요한 만큼만 모아야 한다는 원칙을 최소 수집이라고 하는데, 애초에 받지 않은 값에는 규칙을 걸 일도 지울 일도 없습니다. 분석에 필요한 것이 개인이 아니라 집단의 경향이라면 알아볼 수 없는 형태로 바꿔 두는 비식별 처리를 거쳐 내보냅니다.

삭제와 열람 요청을 처리하려면 목록이 전제입니다. 그 데이터의 주인인 정보주체가 자기 정보를 지워 달라고 요청했을 때, 어느 표 어느 칸에 있는지 적혀 있지 않으면 응답 기한 안에 다 찾지 못합니다.

이 구분을 여는 자리는 다섯입니다.

1. 권한 설계입니다. 어느 역할이 어느 표를 열 수 있는지 정할 때 이 표시가 기준이 됩니다. 표 단위가 아니라 칸 단위로 끊을 수 있어서, 분석가에게 표는 열어 주고 메일 칸만 가리는 방식이 가능해집니다.
2. 분석 환경입니다. 분석용으로 복사하는 데이터셋을 만들 때 이 칸들을 걷어 내거나 가공한 값으로 바꿉니다. 사용자를 구분해야 한다면 메일 대신 내부 번호를 씁니다.
3. 외부로 나가는 자리입니다. 협력사에 넘기는 파일, 외부 분석 도구, 고객 지원 도구가 모두 여기 걸립니다. 도구를 새로 붙일 때마다 무엇이 그 도구로 나가는지 확인하는 절차가 붙습니다. 도구가 하나 늘면 나갈 수 있는 경로도 하나 늘어납니다.
4. 열람과 삭제 요청 대응입니다. 요청이 들어오면 목록을 열어 해당하는 칸을 전부 찾습니다.
5. 사고 대응입니다. 유출이 났을 때 무엇이 나갔는지를 몇 시간 안에 답해야 하는데, 표시와 접근 기록이 그 답의 재료입니다.

"이 칸은 표시해 주세요. 분석용 표로 그대로 복사되고 있습니다."

표시가 없어 규칙이 걸리지 않는다는 지적입니다.

"삭제 요청 들어왔습니다. 목록에서 해당하는 칸 전부 뽑아 주세요."

목록이 있어야 기한 안에 응답한다는 전제입니다.

"메일 주소 대신 내부 번호로 바꾸죠. 사용자 구분만 되면 됩니다."

필요한 것이 신원이 아니라 구분이라는 판단입니다.

페이지덱이 이 정리를 한 분기에 했습니다. 태오가 표 백열 개를 훑어 사람을 특정하는 칸을 세어 보니 서른네 개였고, 그중 열한 개는 분석용 표에 복사된 것이었습니다. 원래 있어야 할 곳은 계정 표 하나였습니다.

복사된 열한 개를 걷어 내고 분석용 표에는 내부 계정 번호만 남겼습니다. 두 달 뒤에 삭제 요청이 처음 들어왔을 때 찾는 데 20분이 걸렸습니다. 정리 전이었다면 어디에 있는지부터 물어보는 데 하루가 갔을 것입니다.

이름과 연락처만 해당한다고 보는 경우가 가장 많습니다. 그 둘이 가장 분명하니 자연스러운 오해입니다. 하지만 기기 식별자와 접속 주소처럼 사람 이름이 안 들어간 값도 한 사람을 계속 따라갈 수 있으면 같은 취급을 받고, 각각으로는 평범한 값 셋이 합쳐져 한 사람을 남기는 경우도 마찬가지입니다. 좁게 보면 규칙을 걸어야 할 칸의 절반이 표시 없이 남고, 그 절반이 사고가 났을 때 문제가 되는 쪽입니다.

지웠으니 끝났다고 보는 것도 흔합니다. 원천 표에서 지우면 사라진 것처럼 보이기 때문입니다. 하지만 같은 값이 가공된 표와 로그와 백업과 외부 도구에 흩어져 있습니다. 서비스 로그에 요청 내용이 그대로 찍히고 있었다면 그 로그의 보관 기간이 다할 때까지 남아 있는 셈입니다. 지운다는 결정에는 어디를 지울지의 목록이 함께 있어야 합니다.