외부 SaaS·대행사에 운영 권한을 줄 때의 접근 검토 기준

외부 SaaS나 대행사에 운영 권한을 줄 때는 업체를 믿을지 말지보다 어떤 작업에 얼마 동안 어떤 증거로 접근하게 할지를 정해야 합니다. 관리 콘솔 전체 권한을 먼저 주고 나중에 줄이는 방식은 회수 누락과 책임 공백을 만들기 쉽습니다. 요청한 업무, 대상 자산, 필요한 작업, 종료 시각을 한 건의 승인으로 묶는 것이 출발점입니다.

NIST 사이버보안 프레임워크 2.0은 외부 서비스 목록을 관리하고 접근 권한을 최소 권한과 직무 분리 원칙에 따라 검토하도록 안내합니다. 이 기준을 작은 조직에 적용할 때도 계약서만 보관하는 데서 끝내지 말고, 실제 계정과 토큰의 상태를 확인해야 합니다.

권한 요청을 업무 단위로 쪼개기

‘운영을 도와주세요’는 승인 기준이 아닙니다. 업체가 처리할 티켓이나 변경 작업을 먼저 적고, 조회·생성·수정·삭제·배포 중 어떤 동작이 필요한지 분리합니다. 고객 데이터와 결제 설정처럼 영향이 큰 자산은 작업 범위와 필드를 더 좁혀야 합니다. 조회만 필요한 분석 업무에 쓰기 권한을 포함하지 않는 것처럼 역할을 업무 결과에 맞춥니다.

• 대상: 계정, 프로젝트, 저장소, 데이터셋, 환경을 식별자로 적습니다.

• 동작: 읽기·쓰기·배포·비밀 조회를 구분하고 불필요한 동작은 제외합니다.

• 기간: 시작 시각, 만료 시각, 연장이 필요한 경우의 재승인자를 정합니다.

• 책임: 내부 소유자, 업체 담당자, 최종 승인자를 각각 기록합니다.

계정과 인증 수단을 분리하기

공유 관리자 계정은 누가 무엇을 했는지 확인하기 어렵고 담당자가 바뀌어도 권한이 남습니다. 가능하면 업체 개인별 계정이나 조직이 통제하는 외부 협력자 계정을 사용하고, 다중 인증과 승인된 로그인 경로를 요구합니다. API 연동은 사람 계정의 비밀번호를 전달하지 말고 용도별 서비스 계정과 제한된 토큰을 사용합니다. 토큰에는 대상, 허용 범위, 발급자, 만료와 교체 절차를 연결합니다.

긴급 작업 때문에 임시로 높은 권한이 필요하다면 평상시 계정과 별도의 승격 절차로 다룹니다. 승격 사유와 승인 시각, 실행한 명령 또는 변경 식별자를 남기고 작업이 끝난 즉시 원래 역할로 돌아왔는지 확인합니다. 비밀 값을 메신저나 문서에 복사하는 편의는 통제된 비밀 저장소의 일회성 공유로 대체해야 합니다.

로그와 회수 증거를 승인에 포함하기

권한을 줬다는 기록만으로는 사용 범위를 증명할 수 없습니다. 로그인, 권한 변경, 토큰 발급·폐기, 데이터 내보내기, 배포와 삭제 이벤트가 감사 로그에 남는지 확인하고 내부 사건 번호와 연결합니다. 로그를 볼 수 있는 사람과 보존 기간도 정해야 합니다. 외부 서비스가 상세 로그를 제공하지 않는다면 그 한계를 위험 수용 또는 대체 통제의 근거로 명시합니다.

종료일에 확인할 것

계약 종료나 작업 완료 때는 사용자 계정만 끄지 말고 초대된 그룹, 개인 액세스 토큰, OAuth 연결, SSH 키, 웹훅과 저장된 세션을 함께 찾습니다. 회수 결과에는 대상 식별자, 적용 시각, 확인한 화면이나 로그의 위치, 검토자만 남기고 비밀 값은 기록하지 않습니다. 회수 뒤 일정 시간 동안 성공한 접근이 없는지도 재조회하면 비활성화 요청과 실제 적용 사이의 차이를 발견할 수 있습니다.

운영 가능한 승인 완료 조건

1. 업체와 작업 목적, 대상 자산, 허용 동작, 데이터 범위를 문서로 합의했다.

2. 개인별 계정 또는 통제된 서비스 계정에 최소 권한과 만료 시각을 적용했다.

3. 로그 확인 경로와 사건 대응 연락망, 연장 승인자를 지정했다.

4. 모의 종료에서 계정·토큰·세션·연결을 회수하고 결과를 재조회했다.

외부 업체 접근 검토의 완료는 승인 문서가 저장된 때가 아니라 권한이 실제 업무에 맞고 끝나는 순간 사라진다는 사실을 증명한 때입니다. 매월 모든 권한을 똑같이 다시 심사하기 어렵다면 고위험 자산과 만료 임박 항목부터 검토하고, 업체·업무·권한·증거의 변경이 생길 때마다 재승인을 발생시키세요.