고객이 화면 오류를 신고했습니다. 담당자가 상황을 재현하려면 그 고객사의 데이터가 필요합니다. 여기서 운영자에게 모든 고객사의 데이터를 볼 수 있는 상시 관리자 권한을 주는 선택은 편하지만 위험합니다. 문제가 끝나도 권한이 남고, 누가 무엇을 봤는지 설명하기도 어렵습니다. 반대로 아무 접근도 못 하게 하면 고객 지원이 지연됩니다. 답은 지원 업무에 필요한 범위만, 필요한 시간 동안 열어 주는 임시 접근입니다.
고객 지원 권한은 일반 관리자 권한과 다르다
제품 운영 권한과 고객 데이터 열람 권한을 같은 역할에 묶지 마세요. 운영자는 배포 상태와 서비스 지표를 볼 수 있어도 특정 고객의 계약서나 직원 정보를 볼 필요는 없을 수 있습니다. 먼저 업무를 지원 유형으로 분리합니다. 오류 재현에는 화면 상태만 필요한지, 특정 문서의 메타데이터가 필요한지, 실제 원본 파일을 열어야 하는지에 따라 허용 범위가 달라집니다. 고객사, 대상 레코드, 허용 행위, 요청 이유, 만료 시각을 별도 속성으로 다루면 무제한 관리자 계정의 필요를 줄일 수 있습니다.
접근을 요청할 때는 티켓 번호와 고객이 제기한 문제를 연결합니다. 고객 승인 또는 내부 이중 승인 중 무엇이 필요한지는 계약과 데이터 민감도에 따라 정해야 합니다. 모든 지원 건에 같은 승인 절차를 강요하면 긴급 장애에서 우회 계정이 생기기 쉽습니다. 긴급 접속이 필요하다면 별도 경로를 만들되 더 짧은 유효 시간, 강한 인증, 사후 검토를 붙입니다. Microsoft의 PIM 배포 지침도 시간 기반·승인 기반 권한 활성화를 과도한 상시 권한을 줄이는 방법으로 설명합니다.
허용 범위는 화면이 아니라 서버에서 검증한다
지원 도구 화면에서 다른 고객 메뉴를 숨기는 것만으로는 충분하지 않습니다. 요청마다 서버가 현재 지원 세션의 고객사, 데이터 유형, 동작과 만료 여부를 확인해야 합니다. 예를 들어 고객사 A의 문서 열람만 허용된 세션으로 고객사 B의 문서 URL을 직접 호출하면 거부돼야 합니다. 다운로드, 검색, 대량 내보내기, API 호출도 같은 정책을 통과해야 합니다. 접근 범위를 표시한 짧은 수명의 세션이나 서버 측 권한 레코드를 사용하되, 클라이언트가 보내는 고객사 ID를 신뢰해 권한을 넓혀서는 안 됩니다.
지원자가 실제로 무엇을 봤는지도 남겨야 합니다. 승인 이벤트 하나만 기록하면 승인 후 수백 건을 조회했는지 알 수 없습니다. 누가, 어느 고객사에, 어떤 사유로, 언제, 어떤 기능을 사용했는지 감사 이벤트를 분리해 기록합니다. 민감한 원문 자체를 로그에 복제하지 않고 대상 식별자와 행위를 남기는 편이 안전합니다. 고객에게 지원 접속 내역을 보여 줄 수 있다면 설명 책임도 분명해집니다. 다만 기록 보존 기간과 열람 권한은 고객 계약과 내부 정책에 맞춰 정해야 합니다.
만료는 달력 알림이 아니라 시스템 동작이어야 한다
‘작업이 끝나면 권한을 지워 주세요’라는 수동 약속은 야간 장애와 담당자 교체에 취약합니다. 시작과 종료 시각을 서버에서 강제하고, 티켓 종료나 고객 철회가 발생하면 더 일찍 회수할 수 있게 합니다. 이미 열린 브라우저 탭이나 발급된 토큰도 이후 요청에서 다시 검증해야 합니다. 권한 회수 직후 기존 세션이 계속 통과한다면 실제로는 회수되지 않은 것입니다. 작업을 연장해야 한다면 새 이유와 승인으로 갱신하고, 무기한 연장 버튼은 두지 않습니다.
도입 전에는 네 가지 장면을 시험해 보세요. 승인 전 접근, 승인된 고객사 밖의 URL 호출, 만료 직후 재요청, 고객의 중도 철회입니다. 지원 편의와 보안은 둘 중 하나를 포기하는 문제가 아닙니다. 필요한 데이터만 보게 하는 좁은 권한과 자동 회수, 사용 이력이 결합되면 고객 문제를 빠르게 풀면서도 접근을 설명할 수 있습니다. 특히 여러 고객의 데이터를 하나의 SaaS에 담는 회사라면 지원 도구 자체를 별도 보안 제품처럼 설계해야 합니다.
