접근 권한 점검

Access Review

관행

어떤 시스템에 지금 누가 들어갈 수 있는지를 주기마다 뽑아 보고, 필요 없어진 권한을 회수하는 절차입니다.

등장 배경

권한은 줄 때와 거둘 때의 사정이 다릅니다. 줄 때는 누군가 필요하다고 말하고 누군가 승인하니 요청과 기록이 남습니다. 반면 필요 없어지는 순간에는 아무 일도 일어나지 않습니다. 담당이 바뀌어 그 시스템을 더 볼 일이 없어져도 권한은 그대로 있고, 본인조차 자기가 아직 열 수 있다는 사실을 잊습니다.

그래서 회사가 커지는 동안 권한은 한 방향으로만 쌓입니다. 2년 사이 세 팀을 옮긴 사람은 세 팀의 권한을 다 갖고 있고, 두 달 일하고 떠난 외주 개발자의 저장소 접근이 반년째 살아 있습니다. 이 상태는 평소에 아무 증상도 보이지 않다가, 계정 하나가 털리는 날 한꺼번에 드러납니다. 그 계정이 볼 수 있는 범위가 곧 사고의 크기가 되기 때문입니다.

잠깐만 열어 달라는 요청이 문제를 키웁니다. 장애를 보느라 하루만 운영 데이터베이스를 보겠다고 받은 권한은 그날 끝나지 않습니다. 회수해 달라고 말하는 사람이 없고, 회수하는 쪽도 쓰고 있는지 아닌지 알 수 없어 그냥 둡니다.

접근 권한 점검은 이 일을 사람의 기억이 아니라 날짜에 맡깁니다. 누가 알려 주길 기다리는 대신, 분기가 바뀌면 전체 명단을 뽑아 한 줄씩 지금도 필요한지 묻습니다. 점검이 찾아내는 것은 사고가 아니라 오래된 권한이고, 그것이 목적입니다.

진행 순서

한 회차는 여섯 단계로 돕니다.

  1. 대상 정하기 — 자산 목록에서 이번에 볼 시스템을 고릅니다. 자산 목록은 지켜야 할 시스템과 데이터를 한 표에 모아 둔 것입니다. 이 표에 없는 시스템은 점검에서도 통째로 빠지므로, 팀이 따로 결제해 쓰는 도구가 표에 들어 있는지부터 봅니다.
  2. 명단 뽑기 — 시스템마다 지금 누가 어떤 권한을 갖고 있는지 내려받습니다. 싱글 사인온으로 묶인 도구는 한 화면에서 전부 나오지만, 따로 가입해 쓰는 도구는 관리자 화면에 들어가 손으로 받아야 합니다.
  3. 확인 요청 — 명단을 그 시스템을 아는 관리자에게 보냅니다. 보안 담당은 이 계정이 지금도 필요한지 판단할 수 없습니다. 결제 데이터베이스에 정산 담당자가 들어가야 하는지는 정산 업무를 아는 사람만 압니다.
  4. 판정 — 항목마다 유지·회수·등급 낮추기 셋 중 하나를 고릅니다. 등급 낮추기는 지우지는 않되 쓰기 권한을 읽기 권한으로 내리는 선택이라, 조회는 필요하고 수정은 필요 없는 자리에 씁니다.
  5. 회수 실행 — 결정한 것을 실제로 지웁니다. 판정만 하고 실행이 밀리는 일이 흔해서, 회수한 날짜와 처리한 사람을 함께 남겨 둡니다.
  6. 예외 남기기 — 남겨 두기로 한 권한에는 이유와 다음에 다시 볼 날짜를 적습니다. 이유 없이 살아남은 항목은 다음 회차에서도 같은 이유로 살아남습니다.

각 단계의 기록은 그대로 증적이 됩니다. 보안 인증을 받을 때 심사자가 요구하는 것이 정책 문서가 아니라 이 기록입니다. 분기마다 점검했다는 문장보다 3월 회차에서 12건을 회수했다는 목록이 훨씬 강한 증거입니다.

참여자와 시점

점검에는 세 자리가 필요합니다. 명단을 뽑고 일정을 미는 진행자, 이 권한이 아직 쓰이는지 판단하는 시스템 관리자, 그리고 사람 쪽 사정을 아는 팀장입니다. 진행자는 판단하지 않고 판단을 모읍니다. 시스템 관리자가 빠지면 점검은 아무도 답을 못 하는 명단 돌리기가 되고, 팀장이 빠지면 지난달 조직 개편으로 업무가 바뀐 사람의 권한이 그대로 통과됩니다.

시점은 두 갈래입니다. 하나는 날짜로 거는 정기 점검입니다. 분기에 한 번이 가장 흔하고, 고객 개인정보가 들어 있는 시스템은 한 달에 한 번까지 당깁니다. 다른 하나는 사건에 붙는 점검입니다. 퇴사와 조직 개편, 직무 변경, 외부 협력사와의 계약 종료가 여기 해당합니다. 퇴사 쪽은 오프보딩 절차 안에 권한 회수가 들어 있어 마지막 날 한꺼번에 처리되지만, 직무 변경에는 그런 절차가 없어 정기 점검이 대부분을 걸러 냅니다.

둘 중 어느 쪽도 혼자서는 충분하지 않습니다. 정기 점검만 돌리면 퇴사자의 계정이 최대 석 달을 살아 있고, 사건 기반만 돌리면 아무도 떠나지 않은 분기에는 한 건도 걸러지지 않습니다.

실무 용례

"이번 분기 접근 권한 점검 명단 보냈습니다. 금요일까지 확인 부탁드려요."

각 시스템 관리자에게 판단을 요청하는 말이고, 답이 없으면 회차가 멈춥니다.

"90일 동안 한 번도 안 들어간 계정은 일단 회수하고, 필요하면 다시 신청받죠."

개별 판단이 어려울 때 쓰는 기준을 제안하는 말입니다.

"이 권한은 예외 사유가 비어 있네요. 이번엔 회수하겠습니다."

지난 회차에 이유 없이 남겨진 항목을 정리하겠다는 뜻입니다.

페이지덱에서는 분기 첫 주에 규원이 점검을 엽니다. 45명 규모라 보안 전담이 따로 없어 대표가 진행을 맡고, 시스템별 판단은 태오를 비롯한 담당자들이 합니다. 지난 회차에서 가장 오래 걸린 항목은 퇴사자가 아니라 세 번 팀을 옮긴 구성원이었습니다. 어느 권한이 지금 업무에 필요한지 본인도 확신하지 못해, 팀장과 함께 하나씩 짚어 가며 여섯 개를 정리했습니다.

두 번째 회차부터는 일이 줄었습니다. 첫 회차에서 오래된 권한을 한 번 걷어 내고 나면 그다음부터는 지난 분기에 새로 생긴 것만 보면 되기 때문입니다.

흔한 오해

퇴사자 계정만 지우면 되는 일로 아는 경우가 많습니다. 사고 사례로 알려지는 것이 대개 퇴사자 계정이라 그렇게 보입니다. 실제로 점검에서 가장 많이 걸리는 쪽은 회사에 그대로 다니는 사람입니다. 팀을 옮기고 역할이 바뀌는 동안 권한은 더해지기만 해서, 3년 차 구성원 한 명이 신입보다 네 배 넓은 범위를 열 수 있는 상태가 됩니다. 이 상태를 그냥 두면 최소 권한 원칙은 문서에만 남습니다. 최소 권한 원칙은 각자에게 지금 하는 일에 필요한 만큼만 권한을 주자는 원칙입니다.

보안 담당이 알아서 판단하면 되는 일로 여기는 것도 흔합니다. 보안이 맡는 영역이니 자연스러운 생각입니다. 그런데 명단에 뜨는 것은 계정 이름과 권한 등급뿐이라, 그 사람이 그 권한으로 무슨 일을 하는지는 명단에 없습니다. 진행자가 혼자 판정하면 두 가지 중 하나가 됩니다. 확신이 없어 전부 유지하거나, 과감하게 지웠다가 월요일 아침에 정산이 멈춥니다. 둘 다 한 번 겪고 나면 다음 분기 점검은 아무도 열지 않게 됩니다.

같이 보면 좋은 페이지

  • 보안 관리 체계

    이 점검이 어느 틀의 한 조각인지, 옆에 무엇이 함께 도는지 봅니다

  • 보안 교육

    같은 절차 갈래에서 사람 쪽을 맡는 활동을 이어서 봅니다

  • 최소 권한 원칙

    점검이 회수 판단을 내릴 때 기준으로 삼는 원칙입니다

연관 용어

마지막 업데이트 2026-09-16