15. 계정·권한 관리, 생각보다 사고와 직결되는 이유

보안 사고 리포트를 보다 보면
기대 이상으로 자주 등장하는 키워드가 있습니다.

바로 계정과 권한입니다.

비밀번호가 약해서 털리는 경우도 있지만,
“원래 주면 안 됐던 권한이 있었다”거나
“이미 퇴사한 사람 계정이 남아 있었다”
같은 상황에서 시작되는 사고들도 꽤 많습니다.

권한은 일단 넓어지고, 잘 줄어들지 않는다

실무에서 권한 관리를 하다 보면
처음에는 최소 권한으로 시작하더라도
시간이 지나면서 조금씩 넓어지는 경향이 있습니다.

• 급해서 일단 전체 권한을 주고
• 나중에 정리하자고 했다가
• 실제로는 정리할 시간이 없어서 그대로 굳어버리는 경우

저도 여러 시스템에서 이런 패턴을 봤습니다.

그래서 가급적이면
“일단 넓게 주고 나중에 줄이는 방식”보다는
“처음부터 단계별로 필요할 때만 확장하는 방식”이
결과적으로 더 안전하고 관리도 수월했습니다.

최소 권한 원칙을 현실적으로 적용하는 방법

최소 권한이라는 말 자체는 다들 알고 있지만
현실에서는 적용하기가 쉽지 않습니다.

그래서 저는 보통 아래 정도를 먼저 정리해 봅니다.

• 이 역할에서 꼭 필요한 화면과 기능은 어디까지인지
• 데이터 조회와 수정, 삭제를 분리할 수 있는지
• 관리자 기능을 정말 써야 하는 사람이 누구인지

처음부터 완벽하게 역할을 나누기는 어렵지만,
일단 두세 단계만이라도 역할을 나누어 두면
나중에 권한을 줄이거나 추가할 때 훨씬 손대기 편했습니다.

계정의 전 생애 주기 보기

계정 관리는 발급에서 끝나지 않고,
사용 중과 종료까지 이어집니다.

• 생성: 누가, 어떤 절차로 계정을 요청하고 승인하는지
• 변경: 권한 변경 요청이 들어왔을 때 어떤 기준으로 허용하는지
• 종료: 퇴사·전배·역할 변경 시 계정을 어떻게 정리하는지

특히 종료 단계가 정리되어 있지 않으면
퇴사자 계정이 남아 있거나,
이미 다른 팀으로 옮긴 사람의 권한이 그대로 유지되는 일이 생깁니다.

그래서 인사 정보와 계정 정보를
어느 정도 연동해 두는 것이
조직 규모가 커질수록 중요해졌습니다.

공유 계정과 기본 계정

현장에서 자주 마주치는 이슈 중 하나가
공유 계정입니다.

• 여러 사람이 같이 쓰는 관리자 계정
• 기본 비밀번호가 바뀌지 않은 장비 계정

편의성만 고려하면
한 계정만 같이 쓰는 것이 가장 편하지만,
사고나 문제가 생겼을 때
누가 어떤 행위를 했는지 확인하기 어려워집니다.

그래서 가능하면

• 개인 계정을 기본으로 사용하고
• 꼭 필요한 경우에만 제한적으로 공유 계정을 쓰되
• 사용 내역을 별도로 남겨두는 방식

으로 방향을 잡는 것이 좋다고 느꼈습니다.

“나중에 설명할 수 있는가”라는 기준

계정·권한 관리를 하면서
가장 자주 떠올리는 질문은 이겁니다.

“만약 이 권한 구조에서 사고가 났을 때
지금 상태를 설명할 수 있을까?”

설명이 가능하다면
완벽하지는 않아도 어느 정도 설계가 되어 있는 것이고,
설명이 어렵다면
어딘가 정리가 덜 되어 있다는 신호일 수 있습니다.

저 역시 이 기준을 머릿속에 두고
조금씩 구조를 손보려고 하고 있습니다.