멀티 테넌트 인증을 허용하는 애플리케이션

로그인 지원을 위해 Microsoft Entra ID에 등록된 애플리케이션은 싱글 테넌트 또는 멀티 테넌트 인증을 신청할 수 있습니다("로그인 대상"이라고도 함). 싱글 테넌트 인증의 경우 같은 테넌트 내 사용자에게로만 액세스를 제한하고, 멀티 테넌트 인증의 경우 모든 Entra 테넌트의 사용자에게 액세스를 허용합니다. 이렇게 싱글 테넌트와 멀티 테넌트 앱을 구분하면 보안에 영향이 발생할 수 있습니다. 애플리케이션을 멀티 테넌트로 구성할 때 그 영향에 대한 충분한 이해와 필요한 예방 조치가 없으면 보안 위험을 초래할 수 있습니다.

멀티 테넌트 앱의 경우, 모든 테넌트의 악성 Entra 사용자가 해당 애플리케이션을 탐색하고 액세스할 수 있을 가능성이 있기 때문에 노출 위험이 높습니다. 애플리케이션의 코드가 이 구성을 고려하지 않는 경우(예: 사용자의 소스 테넌트를 인증된 테넌트 목록과 비교하여 검사하지 않음) 무단 액세스가 발생할 수 있습니다. 취약한 앱은 인증이 정상이라고 가정하고, 유효한 토큰이 있다는 사실에만 근거하여 추가 검사를 실시하지 않고 액세스를 부여하는 앱을 말합니다. 이런 유형의 취약성은 "인증(AuthN) vs. 권한 부여(AuthZ)" 결함의 영역에 속합니다. "공동 책임 모델"에 따르면 Entra ID는 사용자 인증을 처리하고, 권한 부여 측면은 앱이 담당하게 되어 있습니다.

Microsoft마저도 2023년 3월에 이 혼동으로 인해 피해를 보았습니다. 자세한 내용은 "BingBang" 사례 연구를 참조하십시오. 보안 연구진이 이 구성 오류를 악용하여 여러 Microsoft 애플리케이션을 침해할 수 있었으며, 이 중에는 Bing 검색 엔진의 관리 포털도 있었습니다. Microsoft에서는 자사 애플리케이션에서 이 취약성을 해결했지만, 이 사례는 비슷한 취약성이 사용자의 자체 애플리케이션에 영향을 미칠 수 있으니 필요에 따라 검토하여 시정해야 한다는 사실을 일깨워 줍니다.

멀티 테넌트 앱은 nOAuth 결함과 같은 다른 인증 혼동을 초래할 가능성도 있습니다.

멀티 테넌트 앱의 정당한 사용 사례도 있습니다. 특히 다른 조직(예: 소프트웨어 공급업체로서 또는 조직 간 협업 목적으로)이나 같은 조직 소속이지만 다른 테넌트의 사용자(예: 자회사당 테넌트가 하나씩 있음)가 귀하의 조직에서 호스팅하는 애플리케이션에 액세스해야 하는 경우가 그러합니다. 이러한 애플리케이션은 추가적인 권한 부여 검사를 실시하지 않고 인증 성공에만 의존하는 경우에만 취약한 앱으로 간주됩니다. 이 위험 노출 지표는 특정 애플리케이션이 원래 공개를 목적으로 하는 것인지 또는 멀티 테넌트 인증을 고의로 사용으로 설정한 것인지 파악할 수 없습니다. 또한 멀티 테넌시가 꼭 필요한지 확인할 수도 없고, 애플리케이션 코드에 액세스할 수 없으면 필요한 권한 부여 검사가 마련되어 있는지도 확인할 수 없습니다. 그래서 이 IoE는 모든 멀티 테넌트 애플리케이션을 사용자가 개별적으로 검토해야 하는 발견 사항으로 플래그합니다. 확인을 마쳤으면 해당 항목은 무시됨으로 표시해도 됩니다.

애플리케이션 소유자의 도움을 받아 애플리케이션을 검토하고, 앱의 멀티 테넌트 특성이 예상과 일치하는지 확인합니다. 싱글 테넌트 앱과 멀티 테넌트 앱의 차이점을 온전히 인지하고 이 구성을 사용으로 설정했어야 합니다. 해당 애플리케이션이 원래 등록된 테넌트 이외에 다른 테넌트의 사용자도 수용할 수 있는지 확인합니다.

애플리케이션이 공개를 목적으로 한 경우, 해당 사실을 명시하면 이 위험 노출 지표가 해당 앱을 무시합니다.

애플리케이션에 멀티 테넌트 인증이 필요하지 않은 경우, 해당 애플리케이션을 다시 싱글 테넌트 모드로 전환할 수 있습니다. 단, Entra ID는 지원되는 계정 유형에 따라 앱마다 다른 유효성 검사 규칙을 적용한다는 점에 유의해야 합니다. 따라서 다른 매개 변수를 조정해야만 싱글 테넌트 모드로 전환 가능할 수도 있습니다. 신중하게 진행하고, 변경으로 인한 영향을 주의 깊게 검토하십시오. 대상을 업데이트하는 방법에 관한 Microsoft 안내를 따르거나 다음 절차를 이용할 수 있습니다.

1. Azure 포털/Entra 관리자 센터에 애플리케이션을 소유한 Entra 사용자 또는 애플리케이션 관리자나 클라우드 애플리케이션 관리자 등 Entra 역할이 있는 사용자로 인증합니다(정확한 필수 Entra 권한은 microsoft.directory/applications/audience/update임).
2. "앱 등록" 메뉴를 엽니다.
3. 애플리케이션을 검색합니다(이름 또는 발견 사항에 표시된 개체 ID 사용).
4. "개요" 페이지를 보면 현재 "지원되는 계정 유형" 섹션에 "여러 조직" 또는 "모든 Microsoft 계정 사용자"가 표시되어 있어야 합니다.
5. "인증" 메뉴를 클릭하고 안내에 따라 애플리케이션을 "싱글 테넌트"로 전환합니다.

반대로, 애플리케이션에 멀티 테넌트 인증이 필요한 경우라면 앱 개발자에게 문의하여 수신된 인증 토큰에 대한 추가 권한 부여 검사가 코드에 포함되어 있는지 확인합니다(클레임 유효성 검사라고 함).

• 해당하는 경우, 애플리케이션은 테넌트 ID 클레임에 따라 사전 정의된 확인된 Entra 테넌트 목록(예: 조직 자회사의 테넌트)에 속한 사용자의 토큰만 허용해야 합니다.
• 해당하는 경우, 애플리케이션에서 개체 ID 클레임에 따라 미리 알려진 특정 사용자의 토큰도 허용할지 고려해야 합니다.
• 애플리케이션에서는 Entra 앱 역할, Entra 그룹 또는 자체 데이터 스토어 등 다양한 방법을 사용하여 역할 기반 액세스 제어(RBAC) 모델을 구현할 수 있습니다.

이러한 검사가 마련되어 있음을 확인했거나 애플리케이션이 원래 공개를 목적으로 한 경우, 이 위험 노출 지표에서 해당 애플리케이션을 무시하도록 표시할 수 있습니다.

참고: 조건부 액세스 정책은 같은 테넌트의 사용자에게만 적용됩니다. 따라서 조건부 액세스 정책으로 다른 테넌트의 사용자가 귀하의 멀티 테넌트 애플리케이션에 액세스하는 것을 제한할 수 없습니다.

또한, Microsoft의 Entra ID를 사용하는 멀티 테넌트 애플리케이션의 잠재적 권한 부여 구성 오류 관련 공식 참고 자료에서 구체적인 추가 권장 사항을 설명하고 있으므로 이를 준수하는 것이 좋습니다.

마지막으로, Entra와 Azure 관리자의 인식을 강화하여 Entra 앱 등록 페이지를 통해서나 Azure App Service 만들기를 통해 애플리케이션을 만들 때 싱글 테넌트와 멀티 테넌트 구성 중에 어떤 것으로 할지 현명하게 선택하도록 해야 합니다.

이름: 멀티 테넌트 인증을 허용하는 애플리케이션

코드명: APPLICATION-ALLOWING-MULTI-TENANT-AUTHENTICATION

심각도: Low

유형: Microsoft Entra ID Indicator of Exposure