운영 기능을 권한으로 나눌 때 먼저 정할 것

역할 이름보다 허용할 작업을 먼저 적습니다

관리자와 일반 사용자 두 가지로만 나누면 일부 업무를 맡은 운영자에게 지나치게 넓은 권한이 생기기 쉽습니다. 먼저 조회, 수정, 승인, 내보내기, 삭제처럼 실제 작업을 나열하고 각 업무 담당자가 무엇을 해야 하는지 연결합니다.

예를 들어 문의 담당자는 고객 문의를 볼 수 있지만 정산 정보를 바꾸지는 못하도록 구분할 수 있습니다. 지점 담당자는 자신의 지점 데이터만 다루고 본사 담당자는 여러 지점을 조회하도록 정할 수도 있습니다. 이는 역할 설계를 설명하기 위한 가정입니다.

표에는 역할과 작업뿐 아니라 데이터 범위도 함께 적습니다. 같은 “조회”여도 본인 자료, 소속 조직 자료, 전체 자료는 다른 권한입니다. 새로운 역할을 더할 때도 이 세 축을 확인하면 이름만 늘어나는 일을 피할 수 있습니다.

화면과 서버가 각각 맡을 일을 정합니다

화면에서 버튼을 숨기는 것은 사용자가 가능한 작업을 이해하도록 돕는 방법입니다. 실제 허용 여부는 서버가 요청마다 판단해야 합니다. 다른 사용자의 식별자를 요청에 넣었거나 역할이 바뀐 뒤 이전 화면을 그대로 쓰는 상황도 고려합니다.

OWASP 권한 검증 지침은 기본 거부, 최소 권한, 요청마다 권한 확인을 강조합니다. 로그인 여부를 확인하는 것과 해당 데이터에 대한 작업을 허용하는 것은 별개의 판단입니다.

서버는 현재 사용자, 요청한 작업, 대상 데이터의 범위를 함께 확인하고 필요한 정보만 반환하도록 설계합니다. 화면을 하나로 합쳤다는 이유로 모든 데이터를 먼저 내려보낸 뒤 기기에서 숨기는 구조가 되지 않도록 검토해야 합니다.

화면을 나눌지는 업무 흐름으로 판단합니다

공통 화면에 운영 기능을 더하면 같은 데이터를 보며 처리할 수 있다는 장점이 있습니다. 반대로 대량 작업, 별도 승인, 집중적인 통계 확인처럼 일반 사용자와 업무가 크게 다르면 운영 화면을 분리하는 편이 이해하기 쉬울 수 있습니다.

분리 여부와 관계없이 데이터 모델과 권한 규칙의 기준은 일관되게 유지해야 합니다. 같은 작업을 두 화면에서 실행했을 때 허용 범위나 기록 방식이 달라지지 않는지 확인합니다.

삭제나 승인처럼 영향이 큰 작업에는 대상과 결과를 다시 확인할 수 있는 정보를 보여 줍니다. 처리 기록에는 누가 어떤 대상을 언제 바꿨는지 남기되, 기록 자체를 누가 볼 수 있는지도 정합니다. 화면 수를 줄이는 목표보다 운영자가 실수 없이 일을 끝내는지가 우선입니다.

허용되는 경우와 거부되는 경우를 함께 검증합니다

관리자 계정으로 모든 버튼이 동작하는지만 확인하면 권한 검증의 절반을 놓칩니다. 각 역할에서 허용된 작업이 되는지와 허용되지 않은 작업이 차단되는지를 함께 확인해야 합니다.

• 다른 조직의 대상 식별자로 요청했을 때 접근이 거부되는지 확인합니다.
• 권한을 회수한 뒤 기존 화면에서 다시 실행해 봅니다.
• 조회와 내보내기, 단일 작업과 대량 작업의 범위가 같은지 비교합니다.
• 거부된 요청이 데이터를 바꾸지 않았는지 확인합니다.

기대 결과는 역할 표에서 가져옵니다. 구현과 테스트가 같은 잘못된 가정을 공유하지 않도록 업무 담당자도 그 표를 검토하면 실제 운영 기준과 맞추기 쉽습니다.