사내 업무 시스템의 로그인과 권한은 어떻게 설계해야 합니까?

권한은 사람이 아니라 역할에 줍니다

권한을 사람마다 하나씩 주면 처음에는 빠르지만, 인원이 늘고 부서 이동이 생기면 누가 무엇을 할 수 있는지 아무도 설명하지 못하게 됩니다. 그래서 권한은 역할에 주고, 사람은 역할에 배정합니다. 이 방식을 역할 기반 접근 제어(RBAC, Role-Based Access Control)라고 부릅니다.

역할을 정할 때는 조직도가 아니라 업무를 기준으로 삼습니다. 같은 팀 안에서도 입력하는 사람과 승인하는 사람은 다른 역할입니다. 역할과 기능을 표로 놓고 칸마다 허용 여부를 적으면, 설계와 검수 양쪽에서 같은 표를 기준으로 쓸 수 있습니다.

표의 마지막 줄이 중요합니다. 시스템을 관리하는 권한과 업무 데이터를 보는 권한은 분리하는 편이 안전합니다. 관리자라는 이유로 모든 고객 정보와 급여 정보를 볼 수 있게 두면, 관리자 계정 하나가 유출됐을 때 피해 범위가 시스템 전체가 됩니다.

협력사나 외주 인력처럼 회사 밖의 사람이 쓰는 계정은 따로 다룹니다. 이런 계정에는 처음부터 만료일을 두고, 계약이 연장될 때만 기간을 늘리는 방식이 안전합니다. 만료일이 없으면 계약이 끝난 뒤에도 계정이 살아 있는지 아무도 확인하지 않게 됩니다.

기능 권한과 데이터 범위를 나눕니다

권한에는 두 층이 있습니다. 어떤 기능을 쓸 수 있는가(조회·등록·승인·내려받기)와 어떤 데이터를 볼 수 있는가(자기 지점, 자기 부서, 담당 고객)입니다. 이 둘을 한 역할에 섞어 「서울지점 팀장」, 「부산지점 팀장」처럼 만들면 지점이 늘 때마다 역할이 곱절로 늘어납니다. 기능은 역할로, 데이터 범위는 사용자의 소속 정보로 따로 판단하게 설계하면 조직이 바뀌어도 역할 표는 그대로 유지됩니다.

또 하나 지켜야 할 원칙이 있습니다. 화면에서 버튼을 숨기는 것은 권한 통제가 아닙니다. 화면에 버튼이 없어도 서버에 직접 요청을 보내면 기능이 실행될 수 있으므로, 서버가 요청마다 「이 사용자가 이 기능을, 이 데이터에 대해 쓸 수 있는가」를 확인해야 합니다. 검수할 때 권한 없는 계정으로 직접 요청을 보내 막히는지를 시험 항목에 넣어 두십시오.

로그인 — 회사 계정과 연동하고, 바깥에서는 한 번 더 확인합니다

사내 시스템마다 아이디와 비밀번호를 따로 두면 퇴사자 계정이 시스템 곳곳에 남습니다. 회사가 이미 쓰는 업무용 계정과 통합 로그인(SSO) 으로 연동하면, 인사 담당자가 회사 계정을 정지하는 순간 연동된 모든 시스템 접근이 함께 끊깁니다. 연동은 SAML이나 OpenID Connect 같은 표준 방식으로 하는 것이 일반적입니다.

외부에서 접속하는 경우는 한 단계를 더 둡니다. 「개인정보의 안전성 확보조치 기준」은 개인정보처리시스템에 정보통신망을 통해 외부에서 접속하려는 경우 인증서, 보안토큰, 일회용 비밀번호 등 안전한 인증수단을 적용하도록 하고 있습니다(제6조 제2항, 일부 시스템은 가상사설망 같은 안전한 접속수단도 허용). 또 일정 횟수 이상 인증에 실패하면 접근을 제한하고(제5조 제6항), 일정 시간 업무 처리가 없으면 자동으로 접속이 차단되도록 하는 조치를 요구합니다(제6조 제4항).

국제 기준으로는 미국 국립표준기술연구소(NIST)가 2025년 7월 개정한 디지털 신원 지침(SP 800-63B-4)이 참고가 됩니다. 이 지침은 두 번째 인증 보증 수준(AAL2)에서 피싱에 강한 인증 방식을 최소 하나 제공하도록 하고, 비밀번호에 대해서는 문자 조합 규칙이나 주기적인 변경을 강제하지 말고 유출 증거가 있을 때 변경하게 하도록 정합니다. 미국 연방 시스템을 위한 지침이지만, 사내 시스템의 인증 정책을 정할 때 근거 있는 출발점이 됩니다.

개인정보를 다룬다면 지켜야 할 최소선

고객이나 직원의 개인정보를 다루는 시스템이라면 고시가 정한 최소 기준을 설계에 반영해야 합니다. 주요 조항과 설계 항목을 짝지으면 다음과 같습니다.

조항 번호와 내용은 국가법령정보센터에 게시된 고시 제2026-9호(2026. 7. 1. 시행) 기준입니다. 그중 제5조 제1항·제6항, 제6조 제2항, 제8조 제1항·제2항은 2025년 10월 31일 개정분(2026년 11월 1일 시행 · 개인정보보호위원회 안내서 표기)으로, 외부 접속 시 안전한 인증수단과 접속기록 보관의 대상을 「개인정보취급자」에서 정당한 접근 권한을 가진 자와 접속한 모든 자(정보주체 제외)로 넓혔습니다. 유지보수 업체나 외주 인력의 계정도 같은 기준으로 설계해 두는 편이 안전합니다.

특히 내려받기를 따로 다루십시오. 화면 조회는 기록이 남아도, 엑셀로 내려받은 파일은 시스템 밖으로 나가는 순간 통제가 끝납니다. 내려받기를 별도 권한으로 분리하고, 사유를 입력하게 하고, 내려받을 수 있는 항목을 업무에 필요한 범위로 줄이는 것이 고시의 출력 제한 취지에도 맞습니다.

설계 순서

1. 역할 목록조직도가 아니라 업무 기준으로 역할을 정합니다
2. 역할 × 기능 표칸마다 허용 여부를 적어 설계와 검수의 기준으로 씁니다
3. 데이터 범위 규칙지점·부서·담당 고객 중 무엇으로 볼 수 있는 범위를 나눌지 정합니다
4. 계정 수명주기입사·이동·휴직·퇴사 때 권한이 어떻게 바뀌는지 정합니다
5. 기록과 점검무엇을 남기고, 누가 얼마나 자주 확인할지 정합니다

넷째 단계는 빠지기 쉽습니다. 입사 때 권한을 주는 절차는 있어도, 부서를 옮긴 직원의 예전 권한을 거두는 일은 따로 챙기지 않으면 그대로 남습니다. 고시도 업무가 바뀌면 지체 없이 권한을 변경하거나 말소하도록 하고 있으므로, 인사 정보가 바뀔 때 권한 검토가 함께 일어나도록 절차를 붙여 두는 것이 좋습니다. 여기에 분기마다 한 번씩 역할별 사용자 목록을 각 부서장이 확인하는 점검을 더하면, 절차에서 빠진 계정도 걸러집니다.

참고 자료

• 개인정보의 안전성 확보조치 기준(개인정보보호위원회 고시) — 국가법령정보센터
• NIST SP 800-63B-4 — Digital Identity Guidelines: Authentication and Authenticator Management(2025)