애플리케이션은 편의를 위해 광범위한 권한을 가진 단일의 장기 실행 서비스 계정을 사용하는 경우가 많습니다. 그러나 이 접근 방식은 코드에서 수행하는 작업에 대한 안전한 테넌트별 권한 부여 모델이 아닙니다. 한 테넌트에 대한 요청이 작업을 트리거할 때, 권한이 있는 서비스 계정은 종종 다른 테넌트에 속한 데이터에 액세스할 수 있습니다. 데이터베이스에서 테넌트 ID만 확인하는 것에 의존하는 것은 불충분하며, 캐시나 검색 인덱스와 같은 후속 추가 기능이 이 제한적인 확인을 우회할 수 있습니다.보안을 보장하기 위해 서비스 계정은 모든 작업에 대한 권한 부여 증명으로 사용되는 것이 아니라 최대 프로세스 기능을 정의해야 합니다. 부작용을 수행하기 전에 온라인 API의 범위와 일치하는 권한 부여가 적용되어야 하며, 백그라운드 작업의 경우에도 마찬가지입니다. 단일의 전능한 비밀 대신 아웃바운드 호출에 대해 수명이 짧고 범위가 좁은 토큰을 사용하는 것이 좋습니다. 테넌트 ID, 리소스 ID 및 사용된 서비스 ID의 정확한 로깅은 사고 조사에 중요합니다.공유 서비스 계정을 사용하여 동일한 코드 경로가 다른 테넌트의 리소스에 성공적으로 액세스할 수 있다면, 이는 진정한 보안이 아니라 권한 부여 부족을 나타냅니다. 공유 자격 증명이 프로세스 실행을 관리하지만, 궁극적으로 어떤 객체에 액세스하고 수정할 수 있는지를 제어하는 것은 권한 부여입니다.