최소 권한 원칙

구성원이 열 명 남짓인 팀에서는 권한을 나누는 일이 손해처럼 보입니다. 누가 무엇을 할 수 있는지 정하는 데 시간이 걸리고, 정해 두면 필요할 때마다 막혀서 다시 풀어 달라고 요청해야 합니다. 그래서 초기 팀 대부분이 전원에게 관리자 권한을 주고 아무도 막히지 않게 둡니다.

이 선택은 팀이 커질 때까지 아무 문제도 일으키지 않습니다. 문제가 드러나는 건 계정 하나가 뚫린 날입니다. 마케팅 담당자가 메일에 온 가짜 로그인 화면에 비밀번호를 한 번 넣으면, 그 계정으로 들어온 사람이 고객 문서 전체와 결제 정보와 서버 설정까지 손에 넣습니다. 사고의 크기를 정한 것은 뚫린 계정의 중요도가 아니라 그 계정에 붙어 있던 권한의 범위였습니다.

실수도 같은 모양으로 커집니다. 운영 데이터베이스에 접근할 수 있는 사람이 여덟 명이면 잘못된 명령 한 줄이 나올 가능성도 여덟 배입니다.

최소 권한 원칙은 여기서 나온 규칙입니다. 뚫리는 일과 실수하는 일을 0으로 만들 수 없다고 인정한 다음, 그때 벌어질 일의 크기를 미리 줄여 둡니다.

기본값을 거부로 두고 필요한 것만 하나씩 열어 주는 방식으로 돌아갑니다. 무엇을 막을지 목록을 만드는 게 아니라 아무것도 안 되는 상태에서 출발해 일하는 데 필요한 것만 더합니다.

권한 하나를 정할 때 짚는 것은 넷입니다.

1. 누가 — 사람만이 아닙니다. 배포 스크립트, 결제 연동 서버, 통계 수집 도구처럼 사람 없이 도는 프로그램도 각자 계정과 권한을 가집니다.
2. 무엇에 — 고객 문서 전체인지, 자기 팀 문서인지, 자기가 만든 문서인지 범위를 좁힙니다.
3. 어떤 동작을 — 읽기와 쓰기와 삭제를 따로 봅니다. 통계를 뽑는 도구에 필요한 것은 읽기뿐이고, 그 도구에 삭제 권한이 붙어 있을 이유는 없습니다.
4. 언제까지 — 장애를 처리하려고 연 운영 데이터베이스 접근 권한은 그날 저녁에 닫습니다. 기한이 없는 권한은 아무도 회수하지 않아 계속 남습니다.

사람마다 이 넷을 따로 정하면 마흔다섯 명이 있는 회사에서 관리할 수 없는 양이 됩니다. 그래서 실제로는 관리자·편집자·열람자 같은 역할에 권한을 묶어 두고 사람에게는 역할만 붙이는 역할 기반 접근 제어를 씁니다. 역할을 고치면 그 역할을 가진 사람 전체에 한 번에 반영됩니다.

권한을 확인하는 자리는 둘로 나뉩니다. 접속한 사람이 누구인지 확인하는 절차가 인증이고, 그 사람이 지금 요청한 일을 해도 되는지 판단하는 절차가 인가입니다. 이 원칙이 작동하는 곳은 뒤쪽이라, 로그인만 하면 모든 화면이 열리는 서비스에는 인증만 있고 인가가 없습니다.

한 번 정하고 끝나지도 않습니다. 사람이 팀을 옮기고 프로젝트가 끝나면 권한은 남고 필요는 사라집니다. 그래서 누가 무엇에 접근할 수 있는지 주기적으로 열어 보는 접근 권한 점검이 짝으로 붙습니다. 분기에 한 번 목록을 뽑아 지금도 필요한지 묻고, 답이 없으면 닫는 식입니다.

사람의 권한을 손대는 자리가 가장 많습니다. 입사할 때는 직무에 맞는 역할 하나만 붙이고, 팀을 옮기면 예전 역할을 떼고 새 역할을 붙입니다. 떼는 쪽을 빠뜨리면 권한만 쌓이는 사람이 생깁니다. 퇴사할 때 인수인계와 권한 회수를 처리하는 오프보딩에서 이 원칙이 가장 자주 언급되는데, 마지막 출근일에 닫히지 않은 계정이 몇 달 뒤 사고의 입구가 되기 때문입니다.

프로그램 쪽은 더 조용히 쌓입니다. 외부 서비스와 연동하려고 발급한 열쇠 문자열은 대개 처음 만들 때 모든 권한이 붙은 상태로 만들어집니다. 되는지부터 확인하려고 넓게 열어 두고, 되고 나면 아무도 다시 좁히지 않습니다. 사람과 달리 퇴사하지 않으니 그대로 몇 년을 갑니다.

고객 데이터를 다루는 자리에서도 기준이 됩니다. 문의를 처리하는 사람에게 고객 문서 본문을 열어 볼 권한이 필요한지, 계정 상태와 결제 이력만으로 충분한지를 정해 둡니다.

점검 결과를 받아 볼 때도 마찬가지입니다. 외부 전문가가 실제 공격처럼 서비스를 두드려 보는 모의 침투 테스트 보고서에는 구멍 자체보다 그 구멍으로 어디까지 갈 수 있었는지가 더 길게 적힙니다.

"이 스크립트에 쓰기 권한까지 필요해요? 읽기만 있으면 되는 것 같은데요."

연동 도구에 붙은 권한을 실제로 쓰는 만큼으로 줄이자는 요청입니다.

"장애 대응용으로 하루만 열어 주세요. 내일 아침에 회수하겠습니다."

권한을 여는 대신 기한을 못 박아 두자는 제안입니다.

"지금 구조면 계정 하나만 털려도 전부 털립니다. 최소 권한이 안 지켜져 있어요."

사고 한 건의 피해 범위가 계정 하나로 제한되지 않는다는 경고입니다.

페이지덱에서 이 말이 본격적으로 나온 건 기업 고객이 보낸 보안 점검표를 채우면서였습니다. 수아가 받아 온 문서에 직원별 접근 범위를 적는 칸이 있었는데, 태오가 설정을 열어 보니 개발자 전원이 운영 데이터베이스에 직접 접근할 수 있었습니다.

태오는 두 주 동안 역할을 셋으로 나눴습니다. 평소에는 아무도 운영 데이터에 직접 닿지 않고, 장애가 나면 사유를 적고 여덟 시간짜리 권한을 받게 바꿨습니다. 규원은 일이 느려질 것을 걱정했지만 실제로 권한 요청이 올라온 횟수는 한 달에 세 번이었습니다. 여덟 명이 늘 가지고 있던 권한은 한 달에 세 번 필요한 권한이었던 셈입니다.

권한을 조이면 일이 느려진다고 읽는 경우가 가장 많습니다. 막히는 순간이 눈에 보이고 요청하고 기다리는 시간이 체감되니 그렇게 느껴집니다. 그런데 재 보면 느려지는 양은 대개 작습니다. 페이지덱에서 한 달에 세 번이었던 것처럼, 늘 열어 두던 권한이 실제로 쓰이는 빈도는 낮습니다. 반대로 열어 둔 채 사고가 나면 그날 하루가 아니라 몇 주가 조사와 통보와 복구에 들어갑니다.

사람 권한만 다루는 원칙으로 아는 것도 흔합니다. 조직도와 계정 목록이 먼저 떠오르기 때문입니다. 실제로 사고가 나는 자리는 프로그램 쪽이 더 많습니다. 코드 저장소에 적힌 채 잊힌 열쇠 문자열, 테스트용으로 만들어 두고 지우지 않은 계정처럼 주인이 없는 권한이 남아 있습니다. 사람은 퇴사하면 목록에서 사라지지만 이런 권한은 아무도 회수를 요청하지 않아 계속 살아 있습니다.