사용자의 애플리케이션 액세스에 대한 액세스 검토 준비

  • 아티클

Microsoft Entra ID 거버넌스를 사용하면 올바른 프로세스 및 표시 유형을 사용하여 보안 및 직원 생산성에 대한 조직의 필요를 분산시킬 수 있습니다. 적절한 사용자에게 적절한 리소스에 대한 적절한 액세스 권한을 제공할 수 있습니다.

규정 준수 요구 사항 또는 위험 관리 계획이 있는 조직에는 중요한 애플리케이션이나 중요 비즈니스용 애플리케이션이 있습니다. 애플리케이션 민감도는 조직의 고객에 대한 재무 정보 또는 개인 정보와 같이 해당 용도 또는 포함된 데이터를 기반으로 할 수 있습니다. 이러한 애플리케이션의 경우 조직의 모든 사용자 중 일부만 액세스 권한을 부여받으며 문서화된 비즈니스 요구 사항에 따라 액세스만 허용해야 합니다. Microsoft Entra ID는 표준 프로토콜 및 API 인터페이스를 사용하여 조직에서 개발하는 많은 인기 있는 SaaS 애플리케이션, 온-프레미스 애플리케이션 및 애플리케이션과 통합할 수 있습니다. 이러한 인터페이스를 통해 Microsoft Entra ID는 해당 애플리케이션에 액세스할 수 있는 사용자를 제어하는 ​​신뢰할 수 있는 원본이 될 수 있습니다. 애플리케이션을 Microsoft Entra ID와 통합하면 액세스 검토를 사용하여 해당 애플리케이션에 대한 액세스 권한이 있는 사용자를 다시 인증하고 더 이상 액세스할 필요가 없는 사용자의 액세스 권한을 제거할 수 있습니다. 환경의 애플리케이션에 대한 액세스를 제어하는 방법에 설명된 대로 사용 약관, 조건부 액세스 및 권한 관리를 비롯한 다른 기능을 사용하여 애플리케이션에 대한 액세스를 제어할 수도 있습니다.

액세스 검토를 위한 필수 구성 요소

Microsoft Entra ID를 애플리케이션에 대한 액세스 검토에 사용하려면 테넌트에 다음 라이선스 중 하나가 있어야 합니다.

  • Microsoft Entra ID P2 또는 Microsoft Entra ID Governance
  • EMS(Enterprise Mobility + Security) E5 라이선스

액세스 검토 기능을 사용하면 사용자에게 해당 라이선스를 할당하여 기능을 사용할 필요가 없지만 충분한 라이선스가 있어야 합니다. 자세한 내용은 액세스 검토에 대한 예제 라이선스 시나리오를 참조하세요.

또한 애플리케이션에 대한 액세스를 검토하는 데 필요하지는 않지만 모든 애플리케이션에 대한 다른 사용자의 액세스를 제어할 수 있는 권한 있는 디렉터리 역할의 멤버 자격도 정기적으로 검토하는 것이 좋습니다. Global Administrator, Identity Governance Administrator, User Administrator, Application Administrator, Cloud Application Administrator 및 Privileged Role Administrator의 관리자는 사용자 및 해당 애플리케이션 역할 할당을 변경할 수 있으므로 이러한 디렉터리 역할에 대한 액세스 검토가 예약되었는지 확인합니다.

애플리케이션을 Microsoft Entra ID와 통합하는 방법 결정

애플리케이션에 액세스 검토를 사용하려면 먼저 애플리케이션을 Microsoft Entra ID와 통합하고 디렉터리에 표시해야 합니다. Microsoft Entra ID와 통합되는 애플리케이션은 다음 두 가지 요구 사항 중 하나를 충족해야 함을 의미합니다.

  • 애플리케이션은 페더레이션된 SSO를 위해 Microsoft Entra ID를 사용하며 Microsoft Entra ID는 인증 토큰 발급을 제어합니다. Microsoft Entra ID가 애플리케이션의 유일한 ID 공급자인 경우 Microsoft Entra ID의 애플리케이션 역할 중 하나에 할당된 사용자만 애플리케이션에 로그인할 수 있습니다. 검토에서 거부된 사용자는 애플리케이션 역할 할당을 잃게 되며 애플리케이션에 로그인하기 위한 새 토큰을 더 이상 가져올 수 없습니다.
  • 애플리케이션은 Microsoft Entra ID가 애플리케이션에 제공하는 사용자 또는 그룹 목록을 사용합니다. 이 처리는 MICROSOFT Graph를 통해 Microsoft Entra ID를 쿼리하는 애플리케이션, Microsoft Entra 프로비전 사용자를 AD DS에 기록된 애플리케이션의 데이터베이스 또는 그룹에 쿼리하여 SCIM(Cross-Do기본 Identity Management)과 같은 프로비저닝 프로토콜을 통해 수행할 수 있습니다. 검토에서 거부된 사용자는 애플리케이션 역할 할당 또는 그룹 멤버 자격을 잃게 되며, 이러한 변경 내용을 애플리케이션에서 사용할 수 있게 되면 거부된 사용자는 더 이상 액세스할 수 없습니다.

애플리케이션에서 Microsoft Entra ID를 사용하지 않으므로 이러한 조건 중 어느 것도 애플리케이션에 대해 충족되지 않는 경우 액세스 검토를 계속 사용할 수 있지만 몇 가지 제한 사항이 있습니다. Microsoft Entra ID에 없거나 Microsoft Entra ID의 애플리케이션 역할에 할당되지 않은 사용자는 검토에 포함되지 않습니다. 또한 애플리케이션에서 지원하는 프로비저닝 프로토콜이 없으면 거부된 제거 변경 내용을 애플리케이션에 자동으로 보낼 수 없습니다. 대신 조직에는 완료된 검토 결과를 애플리케이션에 보내는 프로세스가 있어야 합니다.

Microsoft Entra ID를 사용하여 다양한 애플리케이션 및 IT 요구 사항을 처리할 수 있도록 허용하기 위해 애플리케이션을 Microsoft Entra ID와 통합하는 방법에 대한 여러 패턴이 있습니다. 각 패턴은 서로 다른 Microsoft Entra 아티팩트 사용을 만듭니다. 다음 순서도는 ID 거버넌스와 함께 사용하기 위해 애플리케이션에 적합한 세 가지 통합 패턴 A, B 및 C 중에서 선택하는 방법을 보여 줍니다. 특정 애플리케이션에 어떤 패턴이 사용되는지 알면 Microsoft Entra ID에서 액세스 검토를 위해 적절한 리소스를 구성하는 데 도움이 됩니다.

Flowchart for application integration patterns

패턴 애플리케이션 통합 패턴 액세스 검토를 준비하는 단계
A 애플리케이션에서 페더레이션된 SSO를 지원하고, Microsoft Entra ID는 유일한 ID 공급자이며, 애플리케이션은 그룹 또는 역할 클레임에 사용하지 않습니다. 이 패턴에서는 애플리케이션에 개별 애플리케이션 역할 할당이 필요하고 사용자가 애플리케이션에 할당되도록 구성합니다. 그런 다음 검토를 수행하려면 이 애플리케이션 역할에 할당된 사용자의 애플리케이션에 대한 단일 액세스 검토를 만듭니다. 검토가 완료되면 사용자가 거부된 경우 애플리케이션 역할에서 제거됩니다. 그러면 Microsoft Entra ID에서 더 이상 해당 사용자에게 페더레이션 토큰을 발급하지 않으며, 사용자는 해당 애플리케이션에 로그인할 수 없습니다.
b 애플리케이션에서 애플리케이션 역할 할당 외에도 그룹 클레임을 사용하는 경우 애플리케이션은 보다 세분화된 액세스를 표현하기 위해 애플리케이션 역할과 구별되는 Active Directory 또는 Microsoft Entra 그룹 멤버 자격을 사용할 수 있습니다. 여기서는 비즈니스 요구 사항에 따라 애플리케이션 역할 할당이 있는 사용자를 검토하거나 그룹 멤버 자격이 있는 사용자를 검토하도록 선택할 수 있습니다. 그룹이 포괄적인 액세스 범위를 제공하지 않는 경우, 특히 사용자가 해당 그룹의 구성원이 아니더라도 애플리케이션에 액세스할 수 있는 경우 이전 패턴 A와 같이 애플리케이션 역할 할당을 검토하는 것이 좋습니다.
C 애플리케이션이 페더레이션된 SSO를 위해 Microsoft Entra ID에만 의존하지 않지만 사용자의 SQL 테이블 업데이트를 통해 SCIM을 통한 프로비전을 지원하는 경우 AD가 아닌 LDAP 디렉터리가 있거나 SOAP 또는 REST 프로비전 프로토콜을 지원합니다. 이 패턴에서는 애플리케이션의 데이터베이스 또는 디렉터리에 애플리케이션 역할 할당을 사용하여 사용자를 프로비전하고, Microsoft Entra ID의 애플리케이션 역할 할당을 현재 액세스 권한이 있는 사용자 목록으로 업데이트한 다음, 애플리케이션 역할 할당에 대한 단일 액세스 검토를 만들도록 Microsoft Entra ID를 구성합니다. 자세한 내용은 애플리케이션의 기존 사용자 관리를 참조하여 Microsoft Entra ID에서 앱 역할 할당을 업데이트합니다.

기타 옵션

이전 섹션에 나열된 통합 패턴은 타사 SaaS 애플리케이션 또는 조직에서 개발한 애플리케이션에 적용할 수 있습니다.

  • Exchange Online과 같은 일부 Microsoft Online Services는 라이선스를 사용합니다. 사용자의 라이선스를 직접 검토할 수는 없지만, 그룹 기반 라이선스 할당을 사용하는 경우 할당된 사용자가 있는 그룹을 사용하여 해당 그룹의 멤버 자격을 대신 검토할 수 있습니다.
  • 일부 애플리케이션에서는 위임된 사용자 동의를 사용하여 Microsoft Graph 또는 기타 리소스에 대한 액세스를 제어합니다. 각 사용자의 동의는 승인 프로세스에서 제어되지 않으므로 동의를 검토할 수 없습니다. 대신 애플리케이션 역할 할당 또는 그룹 멤버 자격을 기반으로 할 수 있는 조건부 액세스 정책을 통해 애플리케이션에 연결할 수 있는 사용자를 검토할 수 있습니다.
  • 애플리케이션이 페더레이션 또는 프로비전 프로토콜을 지원하지 않는 경우 검토가 완료되면 결과를 수동으로 적용하는 프로세스가 필요합니다. 암호 SSO 통합만 지원하는 애플리케이션의 경우 검토가 완료될 때 애플리케이션 할당이 제거되면 애플리케이션이 사용자의 myapps 페이지에 표시되지 않지만 암호를 이미 알고 있는 사용자는 여전히 애플리케이션에 로그인할 수 있습니다. 온-프레미스 애플리케이션의 경우 프로비저닝을 지원하지 않는 애플리케이션의 사용자 관리를 참조 하세요. SaaS 애플리케이션의 경우 표준 프로토콜을 지원하도록 애플리케이션을 업데이트하여 페더레이션 또는 프로비전을 위해 SaaS 공급업체에 앱 갤러리에 온보딩하도록 요청하세요.

애플리케이션이 검토 준비가 되었는지 확인합니다.

이제 애플리케이션에 대한 통합 패턴을 식별했으므로 Microsoft Entra ID에 표시된 대로 애플리케이션을 검토할 준비가 되었는지 확인합니다.

  1. Microsoft Entra 관리 Center에 최소한 ID 거버넌스 관리istrator로 로그인합니다.

  2. >ID>애플리케이션>엔터프라이즈 애플리케이션으로 이동합니다.

  3. 여기서 애플리케이션이 테넌트에서 엔터프라이즈 애플리케이션 목록에 있는지 확인할 수 있습니다.

  4. 애플리케이션이 아직 나열되지 않은 경우 페더레이션된 SSO 또는 프로비전에 통합할 수 있는 애플리케이션에 애플리케이션 갤러리를 사용할 수 있는지 검사. 갤러리에 있는 경우 자습서를 사용하여 페더레이션에 맞게 애플리케이션을 구성하고, 프로비전을 지원하는 경우 프로비전에 맞게 애플리케이션을 구성합니다.

  5. 애플리케이션이 아직 나열되지 않았지만 AD 보안 그룹을 사용하고 웹 애플리케이션인 경우 애플리케이션의 구성을 변경하여 AD에서 다른 보안 그룹을 찾은 다음, 애플리케이션 프록시 통해 원격 액세스용 애플리케이션을 추가하고, 기존 AD 보안 그룹의 멤버 자격을 새 Microsoft Entra 그룹으로 이동하고, AD에 대한 그룹 쓰기 저장을 구성할 수 있습니다. 그런 다음, kerberos(온-프레미스 Active Directory 기반 앱)에 설명된 대로 그룹 쓰기 저장에서 만든 새 AD 그룹에 대해 검사 애플리케이션을 업데이트합니다.

  6. 애플리케이션이 아직 나열되지 않았지만 AD 보안 그룹을 사용하고 웹 애플리케이션이고 애플리케이션의 구성을 변경하여 AD에서 다른 보안 그룹을 찾을 수 없는 경우, 애플리케이션 프록시 통해 원격 액세스를 위한 애플리케이션을 추가하고, 기존 AD 보안 그룹의 멤버 자격을 새 Microsoft Entra 그룹으로 이동하고, AD에 대한 그룹 쓰기 저장을 구성합니다. 그런 다음, kerberos(온-프레미스 Active Directory 기반 앱)에 설명된 대로 새 그룹을 멤버로 포함하도록 애플리케이션이 검사 기존 AD 보안 그룹을 업데이트합니다.

  7. 애플리케이션이 아직 나열되지 않은 경우 AD 보안 그룹을 사용하고 웹 애플리케이션이 아닌 경우 애플리케이션의 구성을 변경하여 AD에서 다른 보안 그룹을 찾은 다음 기존 AD 보안 그룹의 멤버 자격을 새 Microsoft Entra 그룹으로 이동하고 AD에 대한 그룹 쓰기 저장을 구성할 수 있습니다. 다음으로, kerberos(온-프레미스 Active Directory 기반 앱)에 설명된 대로 그룹 쓰기 저장에서 만든 새 AD 그룹에 대해 검사 애플리케이션을 업데이트합니다. 그런 다음, 다음 섹션에서 계속 진행합니다.

  8. 애플리케이션이 아직 나열되지 않은 경우 AD 보안 그룹을 사용하고 웹 애플리케이션이 아니며 애플리케이션의 구성을 변경하여 AD에서 다른 보안 그룹을 찾은 다음, 기존 AD 보안 그룹의 멤버 자격을 새 Microsoft Entra 그룹으로 이동하고 AD에 대한 그룹 쓰기 저장을 구성할 수 없습니다. 다음으로, Kerberos(온-프레미스 Active Directory 기반 앱)에 설명된 대로 새 그룹을 멤버로 포함하도록 애플리케이션이 검사 기존 AD 보안 그룹을 업데이트합니다. 그런 다음, 다음 섹션에서 계속 진행합니다.

  9. 애플리케이션이 테넌트의 엔터프라이즈 애플리케이션 목록에 있으면 목록에서 해당 애플리케이션을 선택합니다.

  10. 속성 탭으로 변경합니다. 사용자 할당 필요? 옵션이 예로 설정되어 있는지 확인합니다. 아니요로 설정되면 외부 ID를 포함하여 디렉터리의 모든 사용자가 애플리케이션에 액세스할 수 있지만 애플리케이션에 대한 액세스는 검토할 수 없습니다.

    Screenshot that shows planning app assignments.

  11. 역할 및 관리자 탭으로 변경합니다. 이 탭에는 Microsoft Entra ID에서 애플리케이션의 액세스 권한이 아니라 애플리케이션의 표현을 제어할 수 있는 권한을 부여하는 관리 역할이 표시됩니다. 애플리케이션 통합 또는 할당을 변경할 수 있는 권한이 있고 해당 관리 역할에 할당된 각 관리 역할에 대해 권한 있는 사용자만 해당 역할에 있는지 확인합니다.

  12. 프로비전 탭으로 변경합니다 . 자동 프로비저닝이 구성되지 않았거나, 중지되거나, 격리된 경우 Microsoft Entra ID는 검토 중에 해당 액세스가 거부된 경우 사용자의 액세스가 제거될 때 애플리케이션에 알릴 방법이 없습니다. 애플리케이션이 페더레이션되고 Microsoft Entra ID를 ID 공급자로만 사용하거나 애플리케이션이 AD DS 그룹을 사용하는 경우 일부 통합 패턴에는 프로비전이 필요하지 않을 수 있습니다. 그러나 애플리케이션 통합이 패턴 C이고 애플리케이션이 유일한 ID 공급자인 Microsoft Entra ID와 페더레이션된 SSO를 지원하지 않는 경우 Microsoft Entra ID에서 애플리케이션으로 프로비저닝을 구성해야 합니다. 검토가 완료되면 Microsoft Entra ID가 애플리케이션에서 검토된 사용자를 자동으로 제거할 수 있도록 프로비저닝이 필요하며, 이 제거 단계는 SCIM, LDAP, SQL, SOAP 또는 REST를 통해 Microsoft Entra ID에서 애플리케이션으로 전송된 변경을 통해 수행할 수 있습니다.

자세한 내용은 Microsoft Entra ID와 애플리케이션 통합을 참조하세요.

  1. 프로비저닝이 구성된 경우 특성 매핑 편집을 선택하고 매핑 섹션을 확장하고 Microsoft Entra 사용자 프로비저닝을 선택합니다. 특성 매핑 목록에서 사용자가 액세스 권한을 잃을 때 Microsoft Entra ID를 false로 설정하려는 애플리케이션 데이터 저장소의 특성에 대한 isSoftDeleted 매핑이 있는지 확인합니다. 이 매핑이 없으면 프로비전 작동 방식에 설명된 대로 사용자가 범위를 떠날 때 Microsoft Entra ID가 애플리케이션에 알리지 않습니다.

  2. 애플리케이션에서 페더레이션된 SSO를 지원하는 경우 조건부 액세스 탭으로 변경합니다. 이 애플리케이션에 사용하도록 설정된 정책을 검사합니다. 사용하도록 설정된 정책이 있고 액세스를 차단하고 정책에 할당된 사용자가 있지만 다른 조건이 없는 경우 해당 사용자는 이미 애플리케이션에 대한 페더레이션된 SSO를 가져올 수 없도록 차단되었을 수 있습니다.

  3. 사용자 및 그룹 탭으로 변경합니다. 이 목록에는 Microsoft Entra ID의 애플리케이션에 할당된 모든 사용자가 포함되어 있습니다. 목록이 비어 있으면 검토자가 검토할 액세스 권한이 없으므로 애플리케이션 검토가 즉시 완료됩니다.

  4. 애플리케이션이 패턴 C와 통합된 경우 검토를 시작하기 전에 이 목록의 사용자가 애플리케이션의 내부 데이터 저장소에 있는 사용자와 동일한지 확인해야 합니다. Microsoft Entra ID는 애플리케이션에서 사용자 또는 해당 액세스 권한을 자동으로 가져오지는 않지만 PowerShell을 통해 애플리케이션 역할에 사용자를 할당할 수 있습니다. 다른 애플리케이션 데이터 저장소의 사용자를 Microsoft Entra ID로 가져와 애플리케이션 역할에 할당하는 방법은 애플리케이션의 기존 사용자 관리를 참조하세요.

  5. 모든 사용자가 사용자와 같은 동일한 애플리케이션 역할에 할당되었는지 확인합니다. 사용자가 여러 역할에 할당된 경우 애플리케이션에 대한 액세스 검토를 만들면 모든 애플리케이션 역할에 대한 모든 할당이 함께 검토됩니다.

  6. 역할에 할당된 디렉터리 개체 목록을 확인하여 애플리케이션 역할에 할당된 그룹이 없는지 확인합니다. 역할에 할당된 그룹이 있는 경우 이 애플리케이션을 검토할 수 있습니다. 그러나 역할에 할당된 그룹의 구성원이고 액세스가 거부된 사용자는 그룹에서 자동으로 제거되지 않습니다. 애플리케이션 자체가 그룹에 의존하지 않는 경우 액세스 검토 중에 액세스가 거부된 사용자가 애플리케이션 역할 할당을 자동으로 제거할 수 있도록 먼저 애플리케이션을 변환하여 그룹의 구성원이 아닌 직접 사용자 할당을 갖는 것이 좋습니다. 애플리케이션이 그룹을 사용하고 애플리케이션의 모든 그룹이 동일한 애플리케이션 역할에 할당되는 경우 애플리케이션 할당을 검토하는 대신 그룹 멤버 자격을 검토합니다.

그룹이 검토할 준비가 되었는지 확인합니다.

애플리케이션이 그룹을 사용하지 않는 경우 다음 섹션으로 건너뜁니다. 그렇지 않은 경우 애플리케이션 통합에서 패턴 B에 설명된 대로 하나 이상의 그룹을 검토해야 하는 경우 각 그룹을 검토할 준비가 검사.

  1. Microsoft Entra 관리 Center에 최소한 ID 거버넌스 관리istrator로 로그인합니다.
  2. >그룹으로 이동합니다.
  3. 목록에서 각 그룹을 검색하고 선택합니다.
  4. 개요 탭에서 멤버 자격 유형이 할당됨이고 원본이 클라우드인지 확인합니다. 애플리케이션이 동적 그룹 또는 온-프레미스에서 동기화된 그룹을 사용하는 경우 해당 그룹 멤버 자격은 Microsoft Entra ID에서 변경할 수 없습니다. 애플리케이션을 할당된 멤버 자격을 사용하여 Microsoft Entra ID에서 만든 그룹으로 변환한 다음, 멤버 사용자를 해당 새 그룹에 복사하는 것이 좋습니다.
  5. 역할 및 관리자 탭으로 변경합니다. 이 탭에는 Microsoft Entra ID에서 애플리케이션의 액세스 권한이 아니라 그룹의 표현을 제어할 수 있는 권한을 부여하는 관리 역할이 표시됩니다. 그룹 멤버 자격을 변경할 수 있고 해당 관리 역할에 사용자가 있는 각 관리 역할에 대해 권한 있는 사용자만 해당 역할에 있는지 확인합니다.
  6. 멤버 탭으로 변경합니다. 그룹의 멤버가 사용자이고 사용자가 아닌 멤버 또는 중첩된 그룹이 없는지 확인합니다. 검토가 시작될 때 그룹의 구성원이 없으면 해당 그룹의 검토가 즉시 완료됩니다.
  7. 소유자 탭으로 변경합니다. 권한이 없는 사용자가 소유자로 표시되지 않는지 확인합니다. 그룹 소유자에게 그룹의 액세스 검토를 수행하도록 요청하는 경우 그룹에 하나 이상의 소유자가 있는지 확인합니다.

적절한 검토자 선택

각 액세스 검토를 만들 때 관리자는 한 명 이상의 검토자를 선택할 수 있습니다. 검토자는 리소스에 계속 액세스할 사용자를 선택하거나 제거하여 검토를 수행할 수 있습니다.

일반적으로 리소스 소유자는 검토를 수행할 책임이 있습니다. 그룹 검토를 만드는 경우 패턴 B에 통합된 애플리케이션에 대한 검토 액세스의 일환으로 그룹 소유자를 검토자로 선택할 수 있습니다. Microsoft Entra ID의 애플리케이션에는 반드시 소유자가 있는 것은 아니므로 애플리케이션 소유자를 검토자로 선택하는 옵션은 불가능합니다. 대신 검토를 만들 때 검토자가 될 애플리케이션 소유자의 이름을 제공할 수 있습니다.

또한 그룹 또는 애플리케이션에 대한 검토를 만들 때 다단계 검토를 선택할 수 있습니다. 예를 들어 할당된 각 사용자의 관리자가 검토의 첫 번째 단계를 수행하고 리소스 소유자가 두 번째 단계를 수행하도록 선택할 수 있습니다. 이렇게 하면 리소스 소유자가 관리자의 승인을 받은 사용자에게 집중할 수 있습니다.

검토를 만들기 전에 테넌트에 충분한 Microsoft Entra ID P2 또는 Microsoft Entra ID 거버넌스 SKU 사용자가 있는지 확인합니다. 또한 모든 검토자가 이메일 주소를 가진 활성 사용자인지 확인합니다. 액세스 검토가 시작되면 각각 Microsoft Entra ID에서 보낸 이메일을 검토합니다. 검토자에게 사서함이 없는 경우 검토가 시작될 때 이메일 또는 이메일 미리 알림을 받지 못합니다. 또한, Microsoft Entra ID 로그인이 차단된 경우에는 검토를 수행할 수 없습니다.

검토 만들기

통합 패턴 및 검토자가 누구인지에 따라 리소스, 애플리케이션 및 선택적으로 하나 이상의 그룹이 식별되었으면 검토를 시작하도록 Microsoft Entra ID를 구성할 수 있습니다.

  1. 이 단계에서는 역할 또는 Identity Governance administrator 역할에 있어야 Global administrator 합니다.

  2. 패턴 A 및 C에서는 애플리케이션을 선택하여 하나의 액세스 검토를 만듭니다. 그룹 또는 애플리케이션에 대한 액세스 검토 만들기 가이드의 지침에 따라 애플리케이션의 역할 할당에 대한 검토를 만듭니다.

  3. 애플리케이션이 패턴 B와 통합된 경우 동일한 가이드를 사용하여 각 그룹에 대한 추가 액세스 검토를 만듭니다.

    참고 항목

    액세스 검토를 만들고 검토 결정 도우미를 사용하도록 설정하는 경우 결정 도우미는 검토 중인 리소스에 따라 달라집니다. 리소스가 애플리케이션인 경우 권장 사항은 사용자가 애플리케이션에 마지막으로 로그인한 시간에 따라 30일 간격을 기반으로 합니다. 리소스가 그룹인 경우 권장 사항은 해당 그룹을 사용하는 애플리케이션뿐만 아니라 사용자가 테넌트의 애플리케이션에 마지막으로 로그인한 간격도 기반으로 합니다.

  4. 액세스 검토가 시작되면 입력을 제공하도록 검토자에게 요청합니다. 기본적으로 각 검토자는 Microsoft Entra ID로부터 액세스 패널에 대한 링크가 포함된 이메일을 받습니다. 여기서 그룹의 멤버 자격 또는 애플리케이션에 대한 액세스 권한을 검토합니다.

검토가 완료되면 업데이트되는 할당 보기

검토가 시작되면 검토가 완료될 때까지 진행 상황을 모니터링하고, 필요한 경우 승인자를 업데이트할 수 있습니다. 그런 다음, 검토자가 액세스가 거부된 사용자의 액세스 권한이 애플리케이션에서 제거되었는지 확인할 수 있습니다.

  1. 액세스 검토를 모니터링하여 액세스 검토가 완료될 때까지 검토자가 사용자의 지속적인 액세스 요구 사항을 승인하거나 거부하도록 선택하는지 확인합니다.

  2. 검토를 만들 때 자동 적용이 선택되지 않은 경우 검토 결과가 완료되면 적용해야 합니다.

  3. 검토 상태가 결과 적용됨으로 변경될 때까지 기다립니다. 거부된 사용자(있는 경우)가 몇 분 내에 그룹 구성원 자격 또는 애플리케이션 할당에서 제거되는 것을 볼 수 있어야 합니다.

  4. 이전에 애플리케이션에 대한 사용자 프로비저닝을 구성한 경우 결과가 적용되면 Microsoft Entra ID는 애플리케이션에서 거부된 사용자를 프로비전 해제하기 시작합니다. 사용자를 프로비전 해제하는 프로세스를 모니터링할 수 있습니다. 프로비전에서 애플리케이션 관련 오류가 표시되면 프로비전 로그를 다운로드하여 애플리케이션에 문제가 있는지 조사할 수 있습니다.

  5. 검토된 그룹에 대한 그룹 쓰기 저장을 구성한 경우 Microsoft Entra 클라우드 동기화에서 그룹 쓰기 저장이 완료되고 변경 내용이 모든 도메인 컨트롤러에 전파될 때까지 기다립니다.

  6. 애플리케이션에 대해 프로비저닝이 구성되지 않은 경우 거부된 사용자 목록을 애플리케이션에 별도로 복사해야 합니다. 예를 들어 Windows Server AD 관리 그룹에 대한 액세스 검토에서 이 PowerShell 샘플 스크립트를 사용합니다. 이 스크립트는 필요한 Microsoft Graph 호출을 간략하게 설명하고, 변경을 수행하는 Windows Server AD PowerShell cmdlet을 내보냅니다.

  7. 원하는 경우 완료된 검토의 검토 기록 보고서를 다운로드할 수도 있습니다.

  8. 계속 액세스가 거부된 사용자가 페더레이션된 애플리케이션을 계속 사용할 수 있는 기간은 애플리케이션의 세션 수명 및 액세스 토큰 수명에 따라 달라집니다. 애플리케이션이 Kerberos를 사용하는 경우 Kerberos는 도메인에 로그인할 때 사용자의 그룹 멤버 자격을 캐시하므로 Kerberos 티켓이 만료될 때까지 사용자가 계속 액세스할 수 있습니다. 액세스 토큰의 수명을 제어하는 방법에 대한 자세한 내용은 구성 가능한 토큰 수명을 참조하세요.

다음 단계