역할 기반 접근 제어

권한을 사람마다 손으로 주던 시절에는 관리해야 하는 칸이 곱셈으로 늘어났습니다. 구성원이 마흔다섯 명이고 권한 종류가 스무 개면 확인해야 할 칸이 구백 개입니다. 표로 만들어 놓아도 한 화면에 들어오지 않습니다.

그래서 실무에서는 복사로 처리했습니다. 새로 들어온 사람의 권한을 정할 때 같은 팀 사람의 설정을 그대로 복사합니다. 복사한 쪽에 필요 없는 권한이 하나 붙어 있으면 그것까지 따라옵니다. 반년이 지나면 처음 그 권한이 왜 붙었는지 아는 사람이 아무도 없고, 빼자고 말하는 사람도 없습니다. 감사에서 계정 열두 개가 쓸 일 없는 삭제 권한을 갖고 있었다는 결과가 이렇게 나옵니다.

떠난 사람 정리도 같은 문제를 겪었습니다. 계정을 막는 일은 기억하지만 그 사람에게만 따로 붙여 준 권한이 어디에 있었는지는 기록에 없습니다. 접속한 사람이 누구인지 확인하는 인증은 로그인 한 곳에서 처리되는데, 확인된 사람이 무엇을 해도 되는지 판단하는 인가는 사람마다 흩어져 있었습니다.

권한을 사람에게서 떼어 역할에 붙이는 일이고 다섯 단계로 짭니다.

1. 권한을 목록으로 적습니다. 화면 단위가 아니라 동작 단위로 적습니다. 설정 화면 접근이라고 적으면 그 화면 안의 여섯 가지 동작이 한 칸에 묶이므로, 구성원 초대, 결제 정보 보기, 문서 영구 삭제처럼 하나씩 갈라 적습니다.
2. 역할을 정합니다. 조직도가 아니라 실제로 하는 일에서 출발합니다. 협업 문서 제품이라면 소유자, 관리자, 편집자, 댓글만 달 수 있는 사람, 열람자 정도로 다섯이면 대개 충분합니다. 역할이 스무 개를 넘어가면 사람마다 권한을 주던 상태로 되돌아온 것입니다.
3. 역할에 권한을 붙입니다. 역할을 가로줄, 권한을 세로줄로 둔 표를 만들고 칸마다 표시합니다. 이 표를 채울 때 기준은 필요한 만큼만 주는 최소 권한 원칙입니다. 편집자에게 결제 정보를 보여 줄 이유가 없으면 그 칸은 비웁니다.
4. 사람에게 역할을 붙입니다. 한 사람에게 역할 하나가 기본입니다. 여러 역할을 겹쳐 붙일 수 있게 만들면 권한이 합집합으로 계산되어, 각 역할은 안전한데 둘을 함께 가진 사람이 예상 밖의 일을 할 수 있는 상태가 생깁니다.
5. 주기마다 되짚습니다. 분기에 한 번 역할별 인원과 실제 사용 기록을 봅니다. 관리자 역할을 가진 사람이 스무 명이면 대개 역할 설계가 잘못된 것이고, 붙여 둔 권한을 여섯 달 동안 한 번도 쓰지 않은 역할이 있으면 그 칸을 뺄 후보입니다.

역할만으로는 부족해서 범위를 함께 둡니다. 같은 편집자라도 워크스페이스 전체의 편집자인지 특정 문서의 편집자인지가 다릅니다. 실무에서는 역할과 범위를 짝으로 붙여서, 한 사람이 A 워크스페이스에서는 관리자이고 B 워크스페이스에서는 열람자인 상태를 만듭니다.

잘 맞는 자리는 셋입니다. 사람이 늘어 손으로 관리할 수 없게 된 조직, 직무가 뚜렷하게 갈리는 조직, 그리고 누가 무엇을 할 수 있는지를 밖에 보여 줘야 하는 경우입니다. 마지막이 실무에서 큰 몫입니다. 보안 검토에서 권한 체계를 설명하라는 요구가 오면 역할과 권한을 나열한 표 한 장으로 답할 수 있습니다.

안 맞는 자리도 분명합니다. 셋으로 갈립니다.

1. 역할로 갈리지 않는 조건 — 자기가 만든 문서만, 같은 팀 문서만, 근무 시간에만 같은 조건은 역할 이름으로 표현할 수 없습니다. 이런 조건은 데이터마다 붙는 성질로 판단해야 하고, 행 단위로 접근 권한을 거는 행 수준 보안 같은 장치가 그 자리를 맡습니다.
2. 예외가 많은 조직 — 예외마다 역할을 하나 만들면 역할 수가 빠르게 늘어납니다. 마케팅팀장용 역할, 인턴 중 계약직만 쓰는 역할처럼 한 사람을 위한 역할이 생기기 시작하면 역할이라는 장치의 값이 사라집니다.
3. 잠깐만 필요한 권한 — 장애 대응으로 두 시간만 데이터베이스를 봐야 하는 경우입니다. 역할을 붙였다 떼는 방식으로 처리하면 떼는 것을 잊습니다. 기간이 정해진 임시 부여를 따로 만들어 두는 편이 낫습니다.

한계 하나가 더 있습니다. 역할을 조직도에 맞춰 짜면 조직 개편마다 다시 짜야 합니다. 팀 이름이 아니라 하는 일로 짜야 개편을 넘깁니다.

"권한을 화면 단위로 적으셨네요. 동작 단위로 쪼개야 합니다."

한 칸에 여러 동작이 묶여 최소 권한을 줄 수 없다는 지적입니다.

"관리자 역할이 스무 명이에요. 이건 역할이 아니라 기본값이 된 겁니다."

역할 설계가 실제 직무를 반영하지 못하고 있다는 판단입니다.

"장애 대응용 권한은 역할로 주지 말고 두 시간짜리로 발급합시다."

떼는 것을 잊게 되는 방식을 피하자는 제안입니다.

페이지덱에서는 태오가 역할을 다섯 개로 두고 권한 스물두 개를 표로 관리합니다. 표는 코드와 같은 저장소에 두고, 칸을 바꾸는 변경은 규원이 함께 확인합니다. 분기마다 역할별 인원을 뽑는데 지난 분기에는 관리자 역할이 열한 명이었고, 그중 여섯 명은 결제 정보를 볼 일이 없어 편집자로 내렸습니다.

역할 기반 접근 제어를 붙이면 권한 문제가 해결된다고 읽는 경우가 가장 많습니다. 권한을 다루는 장치이니 자연스러운 기대입니다. 하지만 이 방식이 정하는 것은 누가 무엇을 할 수 있는지의 규칙일 뿐이고, 그 규칙을 실제 요청마다 확인하는 일은 따로입니다. 공유 링크를 아는 사람에게 문서가 그대로 열리는 사고는 로그인은 통과했고 권한 검사가 그 자리에 없었던 경우입니다. 역할 표를 잘 만들어 두고도 새로 만든 창구에서 그 표를 읽지 않으면 그 창구는 아무 제한 없이 열려 있습니다.

화면에서 버튼을 숨기면 권한을 막은 것과 같다고 읽는 것도 흔합니다. 사용자 눈에 안 보이면 누를 수 없다는 계산이 그럴듯합니다. 그런데 화면은 요청을 보내는 여러 방법 가운데 하나일 뿐입니다. 창구 주소를 알면 화면을 거치지 않고 직접 부를 수 있고, 그 요청에는 숨긴 버튼이 아무 영향을 주지 않습니다. 검사는 요청을 받는 쪽에서 해야 하고, 화면에서 버튼을 감추는 일은 잘못 누르는 것을 줄이는 편의로만 셉니다.