보안 정책

작은 회사에서 보안 규칙은 오랫동안 사람 머릿속에 있었습니다. 관리자 권한을 누가 줄 수 있는지, 고객 데이터를 개인 노트북에 내려받아도 되는지, 새 도구에 회사 데이터를 넣기 전에 누구에게 물어야 하는지가 묻는 사람과 답하는 사람에 따라 달라졌습니다.

그러다 이런 일이 생깁니다. 개발자 한 명이 퇴사하면서 노트북을 반납하고 계정도 정리했는데, 몇 달 뒤 그 사람의 개인 클라우드 저장소에 운영 데이터베이스 접속 키가 남아 있는 것이 드러납니다. 문제를 되짚어 보면 누가 규칙을 어긴 것이 아니었습니다. 작업 파일을 개인 저장소에 두지 말라는 규칙이 애초에 없었고, 퇴사할 때 무엇까지 확인하는지도 정해져 있지 않았습니다.

규칙이 없으면 판단은 매번 그 자리에서 내려지고, 그 판단은 대개 일이 빨리 되는 쪽으로 기웁니다. 급하니 잠깐만 권한을 열어 달라는 요청은 거절할 근거가 없으면 거절되지 않습니다.

보안 정책은 그 판단을 미리 해 두고 문서로 고정한 것입니다. 상황이 닥쳤을 때 누가 결정할지를 논의하는 대신 이미 적힌 것을 따르게 만듭니다. 기업 고객의 보안 검토나 인증 심사에서 이 문서를 요구하기 때문에 문서화 자체가 목적처럼 보이기도 하지만, 실제 효용은 급한 순간에 기준이 이미 있다는 쪽에 있습니다.

담을 묶음은 계정, 권한, 기기, 데이터 취급, 도구 도입, 사고 신고, 예외 처리 일곱 가지입니다.

1. 계정과 인증 — 비밀번호를 어떻게 만들고 관리하는지, 2단계 인증을 어디까지 의무로 하는지, 여러 사람이 하나의 계정을 함께 쓰는 것을 허용하는지를 적습니다. 공용 계정은 사고가 났을 때 누가 했는지 알 수 없게 만들어 대개 금지합니다.
2. 권한 — 관리자 권한을 누가 승인하는지, 기본값을 어디까지 두는지, 임시로 열어 준 권한이 언제 닫히는지를 정합니다. 기한을 함께 적지 않으면 접근 권한 점검 때마다 같은 항목이 남습니다.
3. 기기 — 노트북 디스크 암호화, 자리를 비울 때의 화면 잠금, 개인 기기로 업무 데이터를 열 수 있는 범위, 분실했을 때 몇 시간 안에 누구에게 알릴지를 적습니다.
4. 데이터 취급 — 데이터를 등급으로 나누고 등급마다 둘 수 있는 곳과 공유하는 방법을 정합니다. 공개해도 되는 것, 회사 안에서만 보는 것, 고객 데이터, 개인을 특정할 수 있는 민감한 것 네 단계가 흔합니다.
5. 도구 도입 — 새 외부 서비스에 회사 데이터를 넣기 전에 누구의 확인을 받는지를 정합니다. 팀 하나가 법인카드로 결제해 쓰기 시작한 도구에 고객 정보가 쌓이는 일이 이 규칙 없이 생깁니다.
6. 사고 신고 — 무엇을 사고로 보고, 알아챈 사람이 몇 분 안에 누구에게 알리는지를 적습니다. 침해 사고 대응 계획이 이 신고를 받아 움직입니다.
7. 예외 처리 — 규칙을 지킬 수 없는 상황에서 승인을 받는 경로입니다. 이 칸이 없는 정책은 지켜지지 않고 우회됩니다.

작성은 보안을 맡은 사람이 하고, 그 자리가 없으면 대표가 개발자와 함께 씁니다. 시작점은 이상적인 규칙이 아니라 지금 실제로 하고 있는 것입니다. 현실보다 두 단계 엄한 규칙을 적어 두면 전원이 우회하는 길을 찾습니다.

분량도 규칙의 일부입니다. 구성원 50명 아래의 회사에서는 A4 서너 장이 적당합니다. 40장짜리 문서를 만들면 아무도 끝까지 읽지 않고, 읽지 않은 규칙은 없는 규칙과 같습니다.

읽는 쪽은 넷입니다.

1. 구성원 — 입사 첫 주에 한 번 읽고, 그 뒤에는 애매한 상황이 생겼을 때 찾아봅니다.
2. 개발팀 — 규칙을 코드와 설정으로 옮기는 쪽입니다. 2단계 인증 의무 범위가 적혀 있으면 그것이 곧 계정 설정의 기준이 됩니다.
3. 기업 고객 — 계약 전 보안 검토에서 문서를 요구합니다.
4. 심사원 — 보안 인증을 받을 때 문서와 실제 운영이 맞는지 확인합니다. 문서만 잘 만든 회사가 여기서 걸립니다.

갱신은 반년에서 1년에 한 번, 그리고 쓰는 도구나 조직이 바뀔 때 합니다. 개정 이력을 남기고, 바뀐 내용은 보안 교육에 실어 사람에게 닿게 합니다.

"이거 정책에 뭐라고 적혀 있어요? 개인 노트북에 고객 데이터 내려받는 거요."

판단을 개인 재량이 아니라 문서에서 찾겠다는 말입니다.

"임시 권한은 2주 뒤 자동 회수로 적혀 있으니 날짜 걸어 두고 드릴게요."

규칙에 기한이 적혀 있어 그대로 집행한다는 뜻입니다.

"정책을 그렇게 엄하게 쓰면 아무도 안 지켜요. 지킬 수 있는 선으로 낮춥시다."

문서의 수준과 현실의 거리를 조절하자는 제안입니다.

페이지덱은 첫 기업 고객의 보안 검토 목록을 받고 이 문서를 만들었습니다. 규원이 초안을 쓰면서 처음 한 일은 규칙을 정하는 것이 아니라 지금 어떻게 하고 있는지를 태오에게 묻는 것이었습니다. 관리자 권한을 가진 사람이 몇 명인지, 고객 데이터가 담긴 화면을 누가 열 수 있는지를 먼저 셌습니다.

세어 보니 관리자 권한이 45명 중 12명에게 있었습니다. 정책에 관리자는 대표 승인으로만이라고 적는 순간 열두 명 중 아홉 명의 권한을 회수해야 했습니다. 규원은 문서를 낮추는 대신 권한을 줄이는 쪽을 골랐고, 그 작업을 2주에 걸쳐 먼저 끝낸 뒤 정책의 해당 문장을 확정했습니다.

엄하게 적을수록 안전해진다고 생각하는 경우가 많습니다. 문서에 강한 문장이 들어가면 그만큼 보호받는 것처럼 보입니다. 그런데 지킬 수 없는 규칙은 지켜지지 않고 우회됩니다. 모든 파일 공유를 금지하면 구성원은 개인 메신저로 파일을 보내기 시작하고, 그때부터 회사는 무엇이 어디로 갔는지 볼 수 없게 됩니다. 규칙이 없을 때보다 나쁜 상태인데, 회사는 금지했다고 믿고 있어서 확인하지 않습니다.

문서가 있으면 정책이 있는 것이라고 읽는 오해도 흔합니다. 인증 심사나 고객 검토가 문서를 요구하기 때문에 만드는 것으로 일이 끝난 것처럼 느껴집니다. 문서와 실제 운영이 어긋나면 그 문서는 회사가 스스로 적어 둔 기준이 되어 어긋난 부분을 증명하는 자료가 됩니다. 정책이 정책으로 작동하는 것은 점검과 훈련이 붙었을 때입니다. 적어 둔 권한 규칙을 분기마다 실제 권한 목록과 대조하는 절차가 있어야 문서가 현실을 따라옵니다.