SAP 원본 및 대상 앱을 사용한 사용자 프로비전을 위해 Microsoft Entra 배포 계획

아티클
06/21/2024

조직에서는 다양한 Azure 서비스 관련 Microsoft 또는 Microsoft 365를 사용합니다. SAP 소프트웨어 및 서비스는 조직의 HR(인사 관리) 및 ERP(엔터프라이즈 리소스 계획)와 같은 중요한 기능을 제공할 수도 있습니다. Microsoft Entra를 사용하여 SAP 및 비 SAP 애플리케이션에서 직원, 계약자, 기타 사용자의 ID 및 이들의 액세스 권한을 오케스트레이션할 수 있습니다.

이 자습서에서는 Microsoft Entra 기능을 사용하여 SAP HR 원본에서 시작된 ID의 속성을 기반으로 SAP 애플리케이션에서 ID를 관리하는 방법을 보여 줍니다. 이 자습서에서는 다음 사실을 가정합니다.

조직에는 상업용 클라우드에 Microsoft Entra 테넌트가 있으며 해당 테넌트에 최소 Microsoft Entra ID P1용 라이선스가 있습니다. (일부 단계에서는 Microsoft Entra ID 거버넌스 기능 사용도 보여 줍니다.)
사용자는 해당 테넌트의 관리자입니다.
조직에는 SAP SuccessFactors인 작업자 레코드 원본 시스템이 있습니다.
조직에는 SAP ECC(ERP 중앙 구성 요소), SAP S/4HANA 또는 기타 SAP 애플리케이션이 있으며 필요에 따라 SAP이 아닌 애플리케이션도 있습니다.
SAP ECC 이외의 SAP 애플리케이션에 대한 프로비전 및 SSO(Single Sign-On)에 SAP Cloud Identity Services를 사용하고 있습니다.

개요

이 자습서에서는 SAP SuccessFactors와 같이 조직의 작업자 목록에 대한 신뢰할 수 있는 원본과 Microsoft Entra를 연결하는 방법을 보여 줍니다. 또한 Microsoft Entra를 사용하여 해당 작업자의 ID를 설정하는 방법도 보여 줍니다. 그런 다음 Microsoft Entra를 사용하여 작업자에게 SAP ECC 또는 SAP S/4HANA와 같은 하나 이상의 SAP 애플리케이션에 로그인할 수 있는 액세스 권한을 제공하는 방법을 알아봅니다.

프로세스는 다음과 같습니다.

계획: 조직의 애플리케이션에 대한 ID 및 액세스 관련 요구 사항을 정의합니다. Microsoft Entra ID 및 관련 Microsoft 온라인 서비스가 이 시나리오에서 조직의 필수 구성 요소를 충족하는지 확인합니다.
배포: 필요한 사용자를 Microsoft Entra ID로 가져온 뒤 해당 사용자를 적절한 자격 증명으로 최신 상태로 유지하는 프로세스를 갖춥니다. Microsoft Entra에서 필요한 액세스 권한이 있는 사용자를 할당합니다. 해당 사용자와 애플리케이션에 대한 이들의 액세스 권한을 프로비전하여 이들이 해당 애플리케이션에 로그인할 수 있도록 합니다.
모니터: 필요에 따라 ID 흐름을 모니터링하여 오류를 감시하고 정책과 작업을 조정합니다.

프로세스가 완료되면 개인은 사용할 권한이 있는 SAP 및 비 SAP 애플리케이션에 Microsoft Entra 사용자 ID를 통해 로그인할 수 있습니다.

다음 다이어그램에서는 이 자습서에서 사용되는 토폴로지 예시를 보여 줍니다. 이 토폴로지에서 작업자는 SuccessFactors에 표시되며 Microsoft Entra, SAP ECC, SAP 클라우드 애플리케이션의 Windows Server AD(Windows Server Active Directory) 도메인에 계정이 있어야 합니다. 이 자습서에서는 Windows Server AD 도메인이 있는 조직을 보여 줍니다. 단, Windows Server AD는 이 자습서에서는 필요 없습니다.

이 자습서에서는 직원과 기타 작업자를 표시하는 사용자의 ID 수명 주기를 중점적으로 다룹니다. 게스트의 ID 수명 주기 및 역할 할당, 요청 및 검토에 대한 액세스 수명 주기는 이 자습서의 범위를 벗어납니다.

SAP 원본 및 대상과의 통합 계획

이 섹션에서는 조직의 애플리케이션에 대한 ID 및 액세스 관련 요구 사항을 정의합니다. 이 섹션에서는 SAP 애플리케이션과의 통합에 필요한 주요 결정을 강조합니다. SAP이 아닌 애플리케이션의 경우 해당 애플리케이션에 대한 액세스를 제어하기 위한 조직 정책을 정의할 수도 있습니다.

SAP IDM을 사용하고 있다면 SAP IDM에서 Microsoft Entra로 ID 관리 시나리오를 마이그레이션할 수 있습니다. 자세한 내용은 SAP IDM에서 Microsoft Entra로 ID 관리 시나리오 마이그레이션을 참조하세요.

애플리케이션 온보딩 시퀀스 및 애플리케이션이 Microsoft Entra와 통합되는 방법 결정

조직에서 사용 가능한 통합 시나리오의 일환으로 일부 애플리케이션을 Microsoft Entra와 이미 통합했을 수 있습니다. 예를 들어, 조건부 액세스의 장점을 살리기 위해 SSO용 Microsoft Entra와 SAP Cloud Identity Services를 통합했지만 여전히 수동 프로비전과 프로비전 해제에 의존하고 있을 수 있습니다. 또는, 아직 Microsoft Entra와 통합되지 않은 SAP ECC와 같은 애플리케이션이 조직에 있을 수 있습니다.

애플리케이션을 SSO및 프로비전용 Microsoft Entra에 통합하기 위한 우선 순위의 순서를 설정합니다. 조직은 일반적으로 최신 프로토콜을 지원하는 SaaS(Software as a Service) 애플리케이션과 통합을 시작합니다. SAP 애플리케이션의 경우 SAP 클라우드 애플리케이션이 있는 조직이 SSO와의 통합을 시작하고 SAP Cloud Identity Services와의 통합을 미들웨어로 프로비전하는 것이 좋습니다. 여기서는 Microsoft Entra에 대한 사용자 프로비전 및 SSO 통합이 여러 SAP 애플리케이션에 도움이 될 수 있습니다.
각각의 애플리케이션이 Microsoft Entra와 통합되는 방식을 확인합니다. 애플리케이션이 SAP S/4HANA와 같은 SAP Cloud Identity Services 프로비전 대상 시스템 중 하나로 나열된 경우 SAP Cloud Identity Services를 미들웨어로 사용하여 Microsoft Entra에서 애플리케이션으로 SSO 및 프로비전을 브리지할 수 있습니다. 애플리케이션이 SAP ECC인 경우 Microsoft Entra를 SSO용 SAP NetWeaver와 직접 통합하고 프로비전을 위해 SAP ECC의 BAPI(비즈니스 애플리케이션 프로그래밍 인터페이스)에 통합할 수 있습니다.

SAP가 아닌 애플리케이션의 경우 Microsoft Entra ID와의 애플리케이션 통합 내 지침에 따라 각각의 애플리케이션용으로 지원되는 SSO 및 프로비전에 지원되는 통합 기술을 결정합니다.
각 애플리케이션에서 제공하는 역할 및 권한을 수집합니다. 어떤 애플리케이션에는 하나의 역할만 있습니다. 예를 들어, SAP Cloud Identity Services에는 할당에 사용할 수 있는 사용자 역할이 하나뿐입니다. SAP Cloud Identity Services는 애플리케이션 할당에 사용하기 위해 Microsoft Entra ID에서 그룹을 읽을 수 있습니다. 다른 애플리케이션은 Microsoft Entra ID를 통해 관리해야 하는 다양한 역할을 노출할 수 있습니다. 이러한 애플리케이션 역할은 일반적으로 해당 역할을 가진 사용자가 앱 내에서 갖게 되는 액세스 권한에 대한 광범위한 제약 조건을 만듭니다.

다른 애플리케이션은 더 세분화된 역할 검사를 위해 그룹 멤버 자격 또는 클레임을 사용할 수도 있습니다. 페더레이션 SSO 프로토콜을 사용하여 발급된 프로비전 또는 클레임의 Microsoft Entra ID에서 각각의 애플리케이션에 이를 제공할 수 있습니다. Active Directory에 보안 그룹 멤버 자격으로 쓸 수도 있습니다.

참고 항목

프로비전을 지원하는 Microsoft Entra 애플리케이션 갤러리의 애플리케이션을 사용하는 경우, Microsoft Entra ID는 프로비전이 구성되고 나면 애플리케이션에서 정의된 역할을 가져와 애플리케이션 매니페스트를 애플리케이션의 역할로 자동 업데이트할 수 있습니다.
Microsoft Entra ID에서 관리할 멤버 자격이 있는 역할과 그룹을 선택합니다. 규정 준수 및 위험 관리 요구 사항에 따라 조직은 종종 권한 있는 액세스 권한 또는 중요한 정보에 대한 액세스 권한을 부여하는 해당 애플리케이션 역할 또는 그룹의 우선 순위를 지정합니다. 이 자습서에는 액세스 할당을 구성하는 단계가 포함되어 있지 않지만, 모든 멤버가 애플리케이션에 프로비전되도록 관련 있는 역할과 그룹을 식별해야 할 수 있습니다.

애플리케이션에 액세스하기 위한 사용자 필수 조건 및 기타 제약 조건으로 조직의 정책 정의

이 섹션에서는 각각의 애플리케이션에 대한 액세스 권한을 결정하는 데 사용할 조직 정책을 결정합니다.

필수 요구 사항이나 사용자가 애플리케이션 액세스 권한을 얻기 위해 충족해야 하는 표준이 있는지 확인합니다. 규정 준수 요구 사항 또는 위험 관리 계획이 있는 조직에는 중요한 애플리케이션이나 중요 비즈니스용 애플리케이션이 있습니다. Microsoft Entra ID와 통합하기 전에 해당 애플리케이션에 액세스할 수 있어야 하는 사용자에 대한 액세스 정책을 이미 문서화했을 것입니다. 그렇지 않다면 규정 준수 및 위험 관리 팀 등의 관련자와 상의해야 할 수 있습니다. 액세스 결정을 자동화하는 데 사용되는 정책이 시나리오에 적합한지 확인해야 합니다.

예를 들어, 정상적인 상황에서는 기본적으로 정규직 직원이나 특정 부서 또는 비용 센터의 직원만 특정 부서의 애플리케이션에 액세스할 수 있어야 합니다. Microsoft Entra ID 거버넌스에서 Microsoft Entra 권한 관리를 사용하는 경우 해당 사용자가 예외를 통해 액세스 권한을 얻을 수 있게끔 하나 이상의 승인자를 갖추도록 액세스를 요청하는 다른 부서의 사용자와 관련된 권한 관리 정책을 구성하도록 선택할 수 있습니다.

조직에 따라 직원이 액세스 요청을 하면 승인을 위해 두 단계가 필요할 수도 있습니다. 첫 번째 단계는 사용자의 관리자를 요청하는 것입니다. 두 번째 단계는 애플리케이션에 보관된 데이터를 담당하는 리소스 소유자 중 한 명에게 요청하는 것입니다.
액세스가 승인된 사용자에게 언제까지 액세스 권한을 줄 것인지와 액세스 권한을 언제 소멸시킬지를 결정합니다. 많은 애플리케이션의 경우 사용자가 조직을 떠날 때까지 액세스 권한을 무기한 유지할 수 있습니다. 경우에 따라 프로젝트가 종료되면 액세스 권한이 자동으로 제거되도록 액세스 권한이 특정 프로젝트 또는 마일스톤에 연결될 수도 있습니다. 또는 소수의 사용자만 정책을 통해 애플리케이션을 사용하는 경우 해당 정책을 통해 모든 사용자의 액세스 권한을 분기마다 또는 매년 검토하도록 구성하여 정기적으로 감독할 수 있습니다. 이러한 시나리오에는 Microsoft Entra ID 거버넌스가 필요합니다.
조직에서 이미 조직 역할 모델을 사용하여 액세스를 관리하고 있는 경우 해당 조직 역할 모델을 Microsoft Entra ID로 가져올 계획을 세우세요. 사용자의 직책이나 부서와 같은 속성에 따라 액세스 권한을 할당하는 조직 역할을 정의할 수 있습니다. 이러한 프로세스는 미리 결정된 프로젝트 종료 날짜가 없더라도 액세스 권한이 더 이상 필요 없으면 사용자에게서 액세스 권한이 사라지게 할 수 있습니다.

조직 역할 정의가 이미 있는 경우 Microsoft Entra ID 거버넌스로 조직 역할 정의를 마이그레이션할 수 있습니다.
의무 분리에 따른 제약 조건이 있는지 문의합니다. 이 자습서에서는 사용자에게 애플리케이션에 대한 기본 액세스를 제공하기 위한 ID 수명 주기를 중점적으로 다룹니다. 단, 애플리케이션 온보딩을 계획할 때 적용할 의무 분리에 따른 제약 조건을 식별할 수 있습니다.

예를 들어, 서부 영업 및 동부 영업이라는 두 개의 앱 역할이 있는 애플리케이션이 있다고 가정해 보겠습니다. 사용자에게 한 번에 하나의 영업 지역 역할만 있는지 확인하려고 합니다. 애플리케이션과 호환되지 않는 앱 역할 쌍의 목록을 포함합니다. 그렇게 하면 사용자에게 하나의 역할이 있는 경우 두 번째 역할을 요청할 수 없습니다. 액세스 패키지에 대한 Microsoft Entra 권한 관리 비호환 설정에는 이러한 제약 조건을 적용할 수 있습니다.
각각의 애플리케이션에 액세스하기 위한 적절한 조건부 액세스 정책을 선택합니다. 애플리케이션을 분석하여 동일한 사용자에 대한 동일한 리소스 요구 사항이 있는 애플리케이션 컬렉션으로 구성하는 것이 좋습니다.

페더레이션된 SSO 애플리케이션을 Microsoft Entra ID와 처음 통합할 때 제약 조건을 표현하는 새 조건부 액세스 정책을 만들어야 할 수 있습니다. MFA(다단계 인증) 또는 해당 애플리케이션 및 후속 애플리케이션에 대한 위치 기반 액세스 관련 요구 사항을 적용해야 할 수 있습니다. 조건부 액세스에서 사용자가 사용 약관에 동의해야만 하도록 구성할 수도 있습니다.

조건부 액세스 정책을 정의하는 방법에 대한 자세한 고려 사항은 조건부 액세스 배포 계획을 참조하세요.
조건에 대한 예외를 처리하는 방법을 결정합니다. 예를 들어, 애플리케이션은 일반적으로 지정된 직원만 사용할 수 있지만, 감사자 또는 공급업체가 특정 프로젝트에 대한 임시 액세스 권한이 필요할 수 있습니다. 또는 조직의 사무실이 하나도 없어서 일반적으로 액세스가 차단되는 위치로 출장을 간 직원이 해당 위치에서 액세스해야 할 때가 있습니다.

이러한 상황에서 Microsoft Entra ID Governance가 있다면 단계, 시간 제한 또는 승인자가 다른 승인에 대한 권한 관리 정책을 사용하도록 선택할 수도 있습니다. Microsoft Entra 테넌트에서 게스트 사용자로 로그인한 공급업체에는 관리자가 없을 수 있습니다. 대신 조직의 스폰서, 리소스 소유자 또는 보안 책임자가 액세스 요청을 승인할 수 있습니다.

프로비전 및 인증 토폴로지 결정

이제 사용자 프로비전 및 SSO를 위해 Microsoft Entra와 통합할 애플리케이션을 결정했으므로, 신뢰할 수 있는 레코드 원본 시스템에서 시작된 데이터를 기반으로 하여 사용자 ID 및 해당 특성이 해당 애플리케이션에 제공되는 방법에 대한 데이터 흐름을 결정합니다.

각각의 ID 및 그 특성에 대한 신뢰할 수 있는 원본을 선택합니다. 이 자습서에서는 SuccessFactors가 SAP 애플리케이션에 액세스해야 하는 사용자를 위한 신뢰할 수 있는 레코드 원본 시스템이라고 가정합니다. SuccessFactors에서 Microsoft Entra ID로 클라우드 HR 기반 사용자 프로비전을 구성하려면 다양한 측면을 다루는 계획 수립이 필요합니다. 이러한 요인에는 일치하는 ID 확인, 특성 매핑 정의, 특성 변환 정의, 범위 지정 필터 정의가 포함됩니다.

이 주제에 대한 전체적인 지침은 클라우드 HR 배포 계획을 참조하세요. 지원 가능 엔터티, 처리 세부 정보, 다양한 HR 시나리오에 맞게 통합을 사용자 지정하는 방법에 대한 자세한 내용은 SAP SuccessFactors 통합 참조를 참조하세요. 다른 ID에 대해 신뢰할 수 있는 다른 원본과 Microsoft Entra ID를 신뢰할 수 있는 원본으로 사용하는 비상 계정 또는 기타 IT 관리자 등 일부 ID가 있을 수도 있습니다.
사용자가 있는지 아니면 사용자를 Microsoft Entra ID 외에 Windows Server AD에 프로비전해야 하는지 확인합니다. 신뢰할 수 있는 HR 원본의 작업자에 해당하는 Windows Server AD에 기존 사용자가 이미 있을 수 있습니다. 아니면 LDAP(Lightweight Directory Access Protocol) 또는 Kerberos를 통해 Windows Server를 사용하도록 SAP ECC 또는 기타 애플리케이션을 구성했을 수 있습니다. 이러한 상황에서는 사용자를 Windows Server AD로 프로비전합니다. 그런 다음, 해당 사용자를 Microsoft Entra ID로 동기화합니다.
Microsoft Entra ID를 사용하여 SAP Cloud Identity Services에 프로비전할지 SAP Cloud Identity Services를 사용하여 Microsoft Entra ID에서 읽을지 결정합니다. Microsoft Entra 프로비전 기능에 대한 자세한 내용은 Microsoft Entra ID를 사용하여 SAP Cloud Identity Services에 사용자를 자동으로 프로비전 및 프로비전 해제를 참조하세요. SAP Cloud Identity Services에는 Microsoft Entra ID에서 사용자와 그룹을 읽을 수 있는 별도의 커넥터도 있습니다. 자세한 내용은 SAP Cloud Identity Services - ID 프로비전 - Microsoft Entra ID를 원본 시스템으로를 참조하세요.
SAP ECC에 사용자를 프로비전해야 하는지 여부를 결정합니다. Microsoft Entra ID의 사용자를 SAP ECC(이전의 SAP R/3) NetWeaver 7.0 이상으로 프로비전할 수 있습니다. 다른 버전의 SAP R/3을 사용하는 경우에도 Microsoft Identity Manager 2016용 커넥터에 제공된 가이드를 사용하여 프로비전을 위한 고유한 템플릿을 빌드하기 위한 참조로 다운로드할 있습니다.

Microsoft Entra ID를 구성하기 전에 조직의 필수 구성 요소가 충족되는지 확인합니다.

Microsoft Entra ID에서 중요 비즈니스용 애플리케이션 액세스를 프로비전하는 프로세스를 시작하기 전에 Microsoft Entra 환경이 적절하게 구성되어 있는지 확인해야 합니다.

Microsoft Entra ID 및 Microsoft Online Services 환경이 애플리케이션에 대한 규정 준수 요구 사항에 대해 준비되었는지 확인합니다. 규정 준수는 Microsoft, 클라우드 서비스 공급자 및 조직 간에 공유되는 책임입니다.
Microsoft Entra ID 테넌트에 적절한 라이선스가 있는지 확인합니다. Microsoft Entra ID를 사용하여 프로비전을 자동화하려면, 프로비전된 원본 HR 애플리케이션 또는 멤버(게스트 아님) 사용자가 공급하는 작업자가 있기 때문에 테넌트에 최소한 Microsoft Entra ID P1 에 대한 라이선스가 최대한 많이 있어야 합니다.

또한, 수명 주기 워크플로 및 프로비전 프로세스에서의 Microsoft Entra 권한 관리 자동 할당 정책과 같은 기타 Microsoft Entra ID 거버넌스 기능을 사용하려면 작업자에게 Microsoft Entra ID 거버넌스 라이선스가 필요합니다. 이 라이선스는 Microsoft Entra ID 거버넌스 또는 Microsoft Entra ID P2용 Microsoft Entra ID 거버넌스 업그레이드 버전입니다.
Microsoft Entra ID가 이미 감사 로그 및 선택적으로 다른 로그를 Azure Monitor로 보내고 있는지 확인합니다. Azure Monitor는 선택 사항이지만 Microsoft Entra 전용은 감사 로그에 최대 30일 동안 감사 이벤트를 저장하므로 앱에 대한 액세스를 관리하는 데 유용합니다. 감사 데이터를 이 기본 보존 기간보다 오래 유지할 수 있습니다. 자세한 내용은 Microsoft Entra ID에서 보고 데이터를 저장하는 기간을 참조하세요.

기록 감사 데이터에 대한 Azure Monitor 통합 문서와 사용자 지정 쿼리 및 보고서를 사용할 수도 있습니다. Microsoft Entra 관리 센터의 Microsoft Entra ID에서 Workbooks를 선택하여 Microsoft Entra 구성이 Azure Monitor를 사용하고 있는지 확인할 수 있습니다. 이 통합이 구성되지 않은 상태에서 Azure 구독이 있고 본인이 보안 관리자 이상일 때는 Microsoft Entra ID를 구성하여 Azure Monitor를 사용할 수 있습니다.
권한이 있는 사용자만 Microsoft Entra 테넌트에서 높은 권한을 가진 관리 역할을 갖고 있는지 확인합니다. 관리자로서 최소한 ID 거버넌스 관리자, 사용자 관리자, 애플리케이션 관리자, 클라우드 애플리케이션 관리자이거나 권한 있는 역할 관리자에 해당한다면 사용자 및 해당 애플리케이션 역할 할당을 변경할 수 있습니다. 최근에 이러한 역할의 멤버 자격을 검토하지 않은 경우 해당 디렉터리 역할에 대한 액세스 검토가 시작되었는지 확인하기 위해 권한 있는 역할 관리자 이상의 권한이 있는 사용자가 필요합니다.

또한 Microsoft Entra 구성 작업에 필요한 Azure Monitor, Logic Apps 및 기타 리소스를 보유 중인, 구독의 Azure 역할에 속한 사용자도 검토해야 합니다.
테넌트에 적절한 격리가 있는지 확인합니다. 조직에서 Active Directory 온-프레미스를 사용하고 이 AD 도메인이 Microsoft Entra ID에 연결되는 경우 클라우드 호스팅 서비스와 관련하여 권한이 높은 관리 작업이 온-프레미스 계정에서는 격리되도록 해야 합니다. 온-프레미스 손상으로부터 Microsoft 365 클라우드 환경을 보호하도록 구성했는지 확인합니다.
보안 모범 사례에 따라 환경을 평가합니다. Microsoft Entra ID 테넌트 보호 방법을 평가하려면, 모든 격리 아키텍처 관련 모범 사례를 확인합니다.
토큰 수명 및 애플리케이션의 세션 설정을 문서화합니다. 이 자습서의 끝부분에서는 SAP ECC 또는 SAP Cloud Identity Services 애플리케이션을 SSO용 Microsoft Entra와 통합합니다. 지속적인 액세스가 거부된 사용자가 페더레이션된 애플리케이션을 계속 사용할 수 있는 기간은 애플리케이션의 자체 세션 수명과 액세스 토큰 수명에 따라 달라집니다. 애플리케이션의 세션 수명은 애플리케이션 자체에 따라 달라집니다. 액세스 토큰의 수명을 제어하는 방법에 대한 자세한 내용은 구성 가능한 토큰 수명을 참조하세요.

애플리케이션에 필요한 스키마 매핑이 SAP Cloud Identity Services에 있는지 확인합니다.

각 조직의 SAP 애플리케이션에는 해당 애플리케이션의 사용자가 애플리케이션에 프로비전될 때 특정 특성이 채워지도록 하는 고유한 요구 사항이 있을 수 있습니다.

SAP Cloud Identity Services를 사용하여 SAP S/4HANA 또는 다른 SAP 애플리케이션에 프로비전하는 경우 SAP Cloud Identity Services를 통해 Microsoft Entra ID에서 해당 애플리케이션으로 관련 특성을 보내는 매핑이 SAP Cloud Identity Services에 있는지 확인합니다. SAP Cloud Identity Services를 사용하지 않는 경우 다음 섹션으로 건너뜁니다.

SAP 클라우드 애플리케이션에 필요한 사용자 스키마가 SAP 클라우드 디렉터리에 있는지 확인합니다. SAP Cloud Identity Services에서는 구성된 각 대상 시스템이 SAP Cloud Identity Services에 제공된 ID에 대한 원본의 데이터 모델에서 대상에 대한 요구 사항과 관련된 변환을 추가합니다. 특히, 구성한 대상 시스템이 다양한 경우 ID를 모델링하려는 방법에 맞게 SAP Cloud Identity Services에서 이러한 변환을 변경해야 할 수 있습니다. 그런 다음, Microsoft Entra가 SAP Cloud Identity Services를 통해 SAP 클라우드 애플리케이션에 제공하는 데 필요한 스키마를 기록합니다.
HR 원본에 해당 SAP 클라우드 애플리케이션에 필요한 스키마를 제공할 수 있는 작업자 스키마가 있는지 확인합니다. 애플리케이션에 필요한 각각의 특성의 출처는 조직이 보유한 원본이어야 합니다. 어떤 특성은 값이 상수이거나 다른 특성에서 변환된 값이 있을 수 있습니다. 사용자의 메일 주소 등과 같은 Microsoft 온라인 서비스에서 다른 값을 할당할 수 있습니다. 그 밖의 특성, 즉, 사용자 이름, 부서, 기타 조직 속성과 같은 특성의 출처는 일반적으로 신뢰할 수 있는 HR 레코드 시스템입니다.

계속하기 전에 출처가 Microsoft Entra나 그 밖의 Microsoft 온라인 서비스가 아닌 각각의 필수 특성을 SuccessFactors와 같은 원본에서 사용할 수 있는 속성으로 추적할 수 있는지 확인합니다. 원본에 필요한 스키마가 없거나 애플리케이션에 대한 액세스 권한을 받은 하나 이상의 ID에 속성이 채워지지 않거나 해당 속성을 Microsoft Entra가 읽을 수 없는 경우에는 프로비전을 사용하도록 설정하기 전에 이러한 스키마 요구 사항부터 해결해야 합니다.
Microsoft Entra ID와 레코드 시스템 간의 상관 관계에 사용되는 스키마를 기록합니다. SAP SuccessFactors의 작업자에 해당하는 기존 사용자가 Windows Server AD 또는 Microsoft Entra ID에 있을 수 있습니다. 해당 사용자를 만든 것이 Microsoft Entra ID가 아니라 다른 어떤 프로세스인 경우, SAP SuccessFactors 특성 참조와 사용 중인 Windows Server 또는 Microsoft Entra 사용자 스키마를 참조하여 사용자 개체에서 SAP SuccessFactors 작업자와 관련된 고유 식별자를 어떤 특성에 넣을지 선택합니다.

Microsoft Entra 인바운드 프로비전에서 작업자와 관련하여 이미 존재하는 사용자를 결정하고 중복 사용자를 만들지 않도록 이 특성에는 작업자에 해당하는 각각의 사용자마다 고유한 값이 있어야 합니다.

Microsoft Entra에서 SAP ECC에 필요한 BAPI를 사용할 준비가 되었는지 확인합니다.

Microsoft Entra 프로비전 에이전트 및 일반 웹 서비스 커넥터는 온-프레미스 SOAP 엔드포인트에 SAP BAPI 등의 연결을 제공합니다.

SAP ECC를 사용하지 않고 SAP 클라우드 서비스에만 프로비전하는 경우 다음 섹션으로 건너뜁니다.

프로비전에 필요한 BAPI가 게시되는지 확인합니다. 사용자를 만들기, 업데이트, 삭제하는 데 필요한 API를 SAP ECC NetWeaver 7.51에 노출합니다. Deploying SAP NetWeaver AS ABAP 7.pdf라는 이름의 Microsoft Identity Manager 2016 파일용 커넥터 파일은 필요한 API를 노출하는 방법을 안내합니다.
기존 SAP 사용자가 사용할 수 있는 스키마를 기록합니다. SAP ECC에 신뢰할 수 있는 레코드 원본 시스템의 작업자에 해당하는 기존 사용자가 있을 수 있습니다. 그러나 해당 사용자를 생성한 것이 Microsoft Entra ID가 아니라면 작업자의 고유 식별자로 사용할 수 있는 해당 사용자에 대해 어떤 필드를 채워야 합니다. 이 필드는 작업자에 해당하는 각각의 사용자마다 고유한 값으로 표시되어 있어야 합니다. 그런 다음, Microsoft Entra 프로비전은 작업자 기능을 위해 이미 존재하는 사용자가 누구인지 확인하고 중복된 사용자를 만들지 않도록 할 수 있습니다.

예를 들어 SAP BAPI인 BAPI_USER_GETLIST와 BAPI_USER_GETDETAIL을 사용 중일 수 있습니다. BAPI_USER_GETDETAIL이 반환하는 필드 중 하나는 반드시 원본과 상호 연결할 고유 식별자로 선택해야 합니다. 원본의 고유 식별자에 해당하는 필드가 없는 경우 다른 고유 식별자를 사용해야 할 수 있습니다. 예를 들어 해당 값이 개별 SAP 사용자마다 고유하게 부여되고 Microsoft Entra ID 사용자에게도 값이 있는 경우 SAP 필드인 address.e_mail을 사용해야 할 수 있습니다.
Microsoft Entra가 SAP BAPI에 공급하는 데 필요한 스키마를 기록합니다. 예를 들어, 사용자를 만들기 위해 ADDRESS,COMPANY,DEFAULTS,LOGONDATA,PASSWORD,SELF_REGISTER, USERNAME 필드를 필요로 하는 SAP BAPI BAPI_USER_CREATE1을 사용 중일 수 있습니다. Microsoft Entra ID 사용자 스키마에서 SAP ECC 요구 사항으로의 매핑을 구성할 때는 Microsoft ID 사용자 특성이나 상수는 필드마다 각각 매핑합니다.

엔드투엔드 특성 흐름 및 변환 문서화

레코드 원본 시스템에서 애플리케이션의 스키마 요구 사항과 사용 가능한 작업자 필드를 확인했습니다. 이제 해당 필드가 Microsoft Entra를 통해서나 필요에 따라 Windows Server AD 및 SAP Cloud Identity Services를 통해 애플리케이션으로 흘러가는 방법에 대한 경로를 문서화합니다.

애플리케이션에 필요한 특성이 원본에서 사용할 수 있는 데이터 값에 직접 해당하지 않는 경우도 있습니다. 이런 경우라면 해당 값을 대상 애플리케이션에 제공하기 전에 값을 변환해야 합니다.

변환을 적용할 수 있는 처리 단계는 여러 개가 있습니다.

단계	고려 사항	자세한 정보 확인용 링크
레코드 시스템 자체에	Microsoft Entra ID 수명 주기 관리는 레코드 원본 시스템에서 읽는 유일한 솔루션이 아닐 수 있습니다. Microsoft Entra에 데이터를 노출하기 전에 데이터 정규화를 수행하면 유사한 데이터가 필요한 다른 솔루션에도 도움을 줄 수 있습니다.	레코드 설명서 시스템 참조
레코드 시스템에서 Microsoft Entra 또는 Windows Server AD로의 인바운드 프로비전 흐름	하나 이상의 SuccessFactors 특성을 기반으로 하여 Windows Server AD 사용자 특성 또는 Microsoft Entra ID 사용자 특성에 사용자 지정 값을 쓸 수 있습니다.	사용자 지정용 함수가 있는 식
Windows Server AD에서 Microsoft Entra ID로 동기화하는 경우	Windows Server AD에 이미 사용자가 있는 경우 해당 사용자가 Microsoft Entra ID로 전환될 때 해당 사용자의 특성을 변환할 수 있습니다.	Microsoft Entra Connect에서 동기화 규칙을 사용자 지정하는 방법과 Microsoft Entra Cloud Sync와 식 작성기 사용
Microsoft Entra ID에서 SAP Cloud Identity Services, SAP ECC 또는 기타 SAP을 사용하지 않는 애플리케이션으로의 아웃바운드 프로비전 흐름	애플리케이션에 대한 프로비전을 구성할 때 지정할 수 있는 특성 매핑 유형 중 하나는 Microsoft Entra ID에 있는 특성을 하나 이상 대상의 특성에 매핑하는 식입니다.	사용자 지정용 함수가 있는 식
아웃바운드 페더레이션 SSO	기본적으로 Microsoft ID 플랫폼은 사용자를 고유하게 식별할 수 있는 사용자의 사용자 이름(또는 사용자 계정 이름) 값과 함께 클레임이 포함된 SAML 토큰을 애플리케이션에 발급합니다. SAML 토큰에는 사용자의 메일 주소 또는 표시 이름을 비롯한 다른 클레임도 포함되며 클레임 변환 함수를 사용할 수 있습니다.	SAML 토큰 클레임 사용자 지정과 고객 JSON 웹 토큰 클레임
SAP Cloud Identity Services	SAP Cloud Identity Services에서는 구성된 각 대상 시스템이 SAP Cloud Identity Services에 제공된 ID에 대한 원본의 데이터 모델에서 대상에 대한 요구 사항과 관련된 변환을 추가합니다. 특히, 구성한 대상 시스템이 다양한 경우 ID를 모델링하려는 방법에 맞게 SAP Cloud Identity Services에서 이러한 변환을 변경해야 할 수 있습니다. 특성 요구 사항이 SAP Cloud Identity Services에 연결된 하나 이상의 SAP 애플리케이션과 관련된 경우 이 방법이 적절한 방법일 수 있습니다.	SAP Cloud Identity Services - 변환 관리

새 인증 자격 증명 발급 준비

Windows Server AD를 사용하는 경우 애플리케이션 액세스가 필요하지만 이전에 Windows Server AD 사용자 계정을 받은 적은 없는 작업자를 위해 Windows Server AD 자격 증명을 발급하도록 계획합니다. 지금까지 일부 조직에서는 사용자가 애플리케이션 리포지토리에 직접 프로비전되었습니다. 작업자는 Microsoft Exchange 사서함 또는 Windows Server AD 통합 애플리케이션에 대한 액세스 권한이 필요한 경우에만 Windows Server AD 사용자 계정을 받았습니다.

이 시나리오에서는 Windows Server AD에 대한 인바운드 프로비전을 구성하는 경우 Microsoft Entra가 새 작업자와 이전에 Windows Server AD 사용자 계정을 받은 적 없던 기존 작업자 모두를 위해 Windows Server AD에서 사용자를 만듭니다. 사용자가 Windows 도메인에 로그인하는 경우, 사용자는 암호보다 강력한 인증을 위해 비즈니스용 Windows Hello에 등록하는 것이 좋습니다.
Windows Server AD를 사용하는 경우 애플리케이션 액세스가 필요하지만 이전에 Microsoft Entra ID 사용자 계정을 받은 적은 없는 작업자를 위해 Microsoft Entra ID 자격 증명을 발급하도록 계획합니다. Windows Server AD로 가장 먼저 이동하지 않고 Microsoft Entra ID에 대한 인바운드 프로비전을 구성하는 경우, Microsoft Entra가 새 작업자와 이전에 Microsoft Entra ID 사용자 계정을 받은 적 없던 기존 작업자 모두를 위해 Microsoft Entra에서 사용자를 만듭니다. 새 사용자를 위해 임시 액세스 패스를 생성할 수 있게 임시 액세스 패스 정책을 사용하도록 설정합니다.
사용자가 Microsoft Entra MFA에 준비가 되었는지 확인합니다. 페더레이션을 통해 통합된 중요 비즈니스용 애플리케이션에 대해 Microsoft Entra MFA를 요구하는 것이 좋습니다. 이러한 애플리케이션의 경우, 사용자가 애플리케이션에 로그인할 수 있도록 허용하는 Microsoft Entra ID에 앞서, MFA 요구 사항을 충족하도록 요구하는 정책이 하나는 있어야 합니다. 위치에 따라 액세스를 차단하거나 사용자가 등록된 디바이스에서 액세스하도록 요구하는 조직도 있을 수 있습니다.

인증, 위치, 디바이스, 사용 약관에 필요한 조건이 들어 있는 적절한 정책이 아직 없는 경우 조건부 액세스 배포에 정책을 추가합니다.
새 작업자를 위한 임시 액세스 패스 발급을 준비합니다. Microsoft Entra ID 거버넌스가 있는 상태이며 Microsoft Entra ID에 대한 인바운드 프로비전을 구성하는 경우 새 작업자를 위한 임시 액세스 패스를 발급할 수 있게 계획을 통해 수명 주기 워크플로를 구성합니다.

Microsoft Entra 통합 배포

이 섹션에서는 다음을 수행합니다.

신뢰할 수 있는 원본 시스템에서 사용자를 Microsoft Entra ID로 가져옵니다.
해당 사용자를 SAP Cloud Identity Services 또는 SAP ECC에 프로비전하여 이 사용자가 SAP 애플리케이션에 로그인할 수 있도록 합니다.

Windows Server AD 사용자 스키마 업데이트

사용자를 Windows Server AD 및 Microsoft Entra ID로 프로비전하는 경우 Windows Server AD 환경 및 관련 Microsoft Entra 에이전트가 SAP 애플리케이션에 필요한 스키마를 사용하여 Windows Server AD 안팎으로 사용자를 전송할 준비가 되었는지 확인합니다.

Windows Server AD를 사용하지 않는 경우 다음 섹션으로 건너뜁니다.

필요에 따라 Windows Server AD 스키마를 확장합니다. Microsoft Entra에 필요한 각 사용자 특성과 Windows Server AD 사용자 스키마에 아직 속하지 않은 애플리케이션과 관련해서는 기본 제공 Windows Server AD 사용자 확장 특성을 선택해야 합니다. 또는, Windows Server AD에서 해당 특성을 보유할 수 있도록 Windows Server AD 스키마를 확장해야 합니다. 이 요구 사항에는 작업자의 입사일 및 퇴사일와 같이 자동화에 사용되는 특성도 포함됩니다.

예를 들어 일부 조직에서는 이러한 속성을 유지하기 위해 extensionAttribute1 특성과 extensionAttribute2 특성을 사용할 수 있습니다. 기본 제공 확장 특성을 사용하도록 선택하는 경우 해당 특성이 Windows Server AD의 여타 LDAP 기반 애플리케이션이나 Microsoft Entra ID와 통합된 애플리케이션에서 아직 사용 중이 아닌지 확인합니다. contosoWorkerId처럼 자신들의 요구 사항에 관련된 이름으로 새 Windows Server AD 특성을 만드는 조직도 있습니다.
기존 Windows Server AD 사용자에게 HR 원본과의 상관 관계에 필요한 특성이 있는지 확인합니다. 작업자에 해당하는 기존 사용자가 Windows Server AD에 있을 수 있습니다. 이러한 사용자에게는 해당 작업자와 관련해 신뢰할 수 있는 레코드 원본 시스템 속성에 해당하는 고유 값의 특성이 반드시 필요합니다.

예를 들어, Windows Server AD에서 employeeId 같은 특성을 사용하는 조직이 있습니다. 해당 특성이 없는 사용자가 있다면, 이 사용자는 이어질 통합 중에는 고려에서 빠질 수 있습니다. 이러면 자동화된 프로비전으로 인해 Windows Server AD에서 중복 사용자가 생성됩니다. 사용자가 떠나는 경우, 원 사용자는 업데이트되거나 제거되지 않습니다. 다음을 사용할 수 있습니다.
- Active Directory 컨테이너의 사용자 전원을 가져오기 위해 Get-ADUser 명령을 사용해 도메인 조인된 컴퓨터 상의 PowerShell 파이프라인.
- {$_.employeeId -eq $null} 같은 필터를 사용해 누락된 특성이 있는 사용자를 필터링하기 위한 where-object 명령.
- 결과적으로 만들어진 사용자를 CSV 파일에 내보내는 export-csv 명령.
해당 특성이 누락된 작업자에 해당하는 사용자가 없는지 확인합니다. 이러한 사용자가 있는 경우, 계속하기 전에 누락된 특성을 추가하려면 Windows Server AD에서 해당 사용자를 편집해야 합니다.
Microsoft Entra ID 스키마를 확장하고 Windows Server AD 스키마에서 Microsoft Entra ID 사용자 스키마로 매핑을 구성합니다. Microsoft Entra Connect Sync를 사용 중이라면, Microsoft Entra Connect Sync: 디렉터리 확장의 단계를 실행하여 특성이 있는 Microsoft Entra ID 사용자 스키마를 확장합니다. Windows Server AD의 특성과 관련된 Microsoft Entra Connect Sync 매핑을 해당 특성으로 구성합니다.

Microsoft Entra Cloud Sync를 사용 중이라면, Microsoft Entra Cloud Sync: 디렉터리 확장 및 사용자 지정 특성 매핑의 단계를 실행하여 기타 필요한 특성이 있는 Microsoft Entra ID 사용자 스키마를 확장합니다. Windows Server AD의 특성과 관련된 Microsoft Entra Cloud Sync 매핑을 해당 특성으로 구성합니다. 수명 주기 워크플로에 필요한 특성을 동기화하고 있는지 확인합니다.
Windows Server AD에서 Microsoft Entra ID로 동기화가 완료될 때까지 기다립니다. Windows Server AD에서 더 많은 특성을 프로비전하기 위해 매핑을 변경한 경우 사용자에 대한 Microsoft Entra ID 표현에 Windows Server AD의 전체 특성 집합이 있도록 사용자가 Windows Server AD에서 Microsoft Entra ID로 변경될 때까지 기다립니다.

Microsoft Entra Cloud Sync를 사용 중인 경우, Microsoft Entra Cloud Sync를 표현하는 서비스 주체의 동기화 작업을 검색하여 동기화 상태의 steadyStateLastAchievedTime 속성을 모니터링할 수 있습니다. 서비스 주체 ID가 없는 경우, 동기화 스키마 보기를 참조하세요.

Microsoft Entra ID 사용자 스키마 업데이트

Windows Server AD를 사용하는 경우 Windows Server AD에서 매핑을 구성하는 일환으로 Microsoft Entra ID 사용자 스키마를 이미 확장했습니다. 이 단계가 완료되었다면 다음 섹션으로 건너뜁니다.

Windows Server AD를 사용하지 않는 경우, 이 섹션의 단계에 따라 Microsoft Entra ID 사용자 스키마를 확장합니다.

Microsoft Entra 스키마 확장을 담을 애플리케이션을 만듭니다. Windows Server AD에서 동기화되지 않은 테넌트의 경우 스키마 확장은 반드시 새 애플리케이션의 일부여야 합니다. 아직 해당 작업을 수행하지 않은 경우, 스키마 확장을 표시하는 애플리케이션을 만듭니다. 이 애플리케이션에는 할당된 사용자가 없습니다.
레코드 시스템과의 상관 관계에 대한 특성을 식별합니다. 작업자에 해당하는 기존 사용자가 Microsoft Entra ID에 있을 수 있습니다. 이 때, 이러한 사용자에게는 해당 작업자와 관련해 신뢰할 수 있는 레코드 원본 시스템 속성에 해당하는 고유 값의 특성이 반드시 필요합니다.

예를 들어, 이 용도로 새 특성을 갖기 위해 Microsoft Entra ID 사용자 스키마를 확장하는 조직이 있습니다. 아직 해당 용도로 특성을 만들지 않은 경우, 다음 단계에서 해당 특성을 특성으로 포함합니다.
새 특성에 대한 Microsoft Entra ID 사용자 스키마를 확장합니다. 아직 Microsoft Entra ID 사용자 스키마에 속하지 않은 SAP 애플리케이션에 필요한 특성 각각에 대한 디렉터리 스키마 확장을 만듭니다. 이들 특성은 Microsoft Entra가 사용자에 대한 데이터를 더 많이 저장하는 방법을 제공합니다. 확장 특성을 생성하여 스키마를 확장할 수 있습니다.

Microsoft Entra ID의 사용자가 HR 원본의 작업자 레코드와 상관 관계를 지정할 수 있는지 확인합니다.

작업자에 해당하는 기존 사용자가 Microsoft Entra ID에 있을 수 있습니다. 이 때, 이러한 사용자에게는 해당 작업자와 관련해 신뢰할 수 있는 레코드 원본 시스템 속성에 해당하는 고유 값의 특성이 반드시 필요합니다.

예를 들어, 이 용도로 새 특성을 갖기 위해 Microsoft Entra ID 사용자 스키마를 확장하는 조직이 있을 수 있습니다. 해당 특성이 없는 사용자가 있다면, 이 사용자는 이어질 통합 중에는 고려에서 빠질 수 있습니다. 이러면 자동화된 프로비전으로 인해 Windows Server AD에서 중복 사용자가 생성됩니다. 사용자가 떠나는 경우, 원 사용자는 업데이트되거나 제거되지 않습니다.

Microsoft Entra ID에서 사용자를 검색합니다. 작업자를 나타내는 Microsoft Entra ID에 이미 있는 모든 사용자가 상관 관계를 지정할 수 있도록 하는 특성이 있는지 확인합니다. 일반적으로, Microsoft Entra ID의 일부 사용자는 신뢰할 수 있는 레코드 원본 시스템의 작업자와 일치하지 않습니다. 이러한 사용자에는 긴급 관리 액세스에 대한 비상 계정, IT 공급업체 계정, 비즈니스 게스트가 포함됩니다. 나머지 사용자에게는 상관 관계에 사용할 고유한 값을 띤 특성이 이미 있어야 합니다.

상관 관계가 없는 사용자가 있다면, 해당 사용자는 업데이트 및 프로비전 해제에서는 누락될 수 있습니다. Microsoft Entra는 중복 사용자를 만들 수도 있습니다. 예를 들어, 비상 계정을 제외한 모든 멤버 사용자에게 employeeid 특성이 있어야 하는 경우, 다음 스크립트와 비슷한 PowerShell 명령 파이프라인을 사용하여 해당 사용자를 식별할 수 있습니다.
```
$u = get-mguser -all -property id,displayname,userprincipalname,usertype,employeeid | Where-Object {$_.UserType -ne 'Guest' -and $_.EmployeeId -eq $null}
```

ID 거버넌스 기능의 필수 구성 요소 설정

Microsoft Entra 권한 관리나 Microsoft Entra 수명 주기 워크플로 같은 Microsoft Entra ID 거버넌스 기능의 필요성을 확인한 경우, 작업자를 Microsoft Entra ID에 사용자로 가져오기 전에 이러한 기능을 배포합니다.

필요한 경우 사용 약관 문서를 업로드합니다. 사용자가 애플리케이션에 대한 액세스 권한을 받기 전에 사용 약관에 동의하도록 해야 하는 경우, 조건부 액세스 정책에 포함할 수 있도록 사용 약관 문서를 업로드합니다.
필요한 경우 카탈로그를 만듭니다. 기본적으로 관리자가 Microsoft Entra 권한 관리와 처음 상호 작용하면 기본 카탈로그가 자동으로 만들어집니다. 하지만 관리되는 애플리케이션에 대한 액세스 패키지는 지정된 카탈로그에 있어야 합니다. Microsoft Entra 관리 센터에서 카탈로그를 만들려면 카탈로그 만들기 섹션의 단계를 따릅니다.

PowerShell을 사용하여 카탈로그를 만들려면 Microsoft Entra ID에 인증 섹션과 카탈로그 만들기 섹션의 단계를 수행합니다.
참가자 워크플로를 만듭니다. Microsoft Entra ID에 대한 인바운드 프로비전을 구성하는 경우, 새 작업자를 위한 임시 액세스 패스 발급 작업이 포함된 수명 주기 워크플로 참가자 워크플로를 구성합니다.
로그인을 차단하는 퇴사자 워크플로를 만듭니다. Microsoft Entra 수명 주기 워크플로에서 사용자가 로그인하지 못하도록 차단하는 작업이 포함된 퇴사자 워크플로를 구성합니다. 이 워크플로는 주문형 실행도 가능합니다. 예약된 퇴사일 이후 작업자의 로그인을 차단하도록 레코드 원본에서 인바운드 프로비전을 구성하지 않은 경우 해당 작업자의 예약된 퇴사일에 실행되도록 퇴사자 워크플로를 구성합니다.
사용자 계정을 삭제하는 퇴사자 워크플로를 만듭니다. 필요에 따라 사용자를 삭제하는 작업이 포함된 퇴사자 워크플로를 구성합니다. 작업자의 예약된 퇴사일 이후 30일 또는 90일과 같이 일정 기간 동안 이 워크플로를 실행하도록 예약합니다.

Microsoft Entra ID의 사용자를 HR 원본의 작업자 레코드에 연결

이 섹션에서는 SAP SuccessFactors와 Microsoft Entra ID를 HR 원본 레코드 시스템으로 통합하는 방법을 보여줍니다.

서비스 계정이 포함된 레코드 시스템을 구성하고 Microsoft Entra ID에 적절한 권한을 부여합니다. SAP SuccessFactors를 사용 중인 경우, 통합 관련 SuccessFactors 구성 섹션의 단계를 따릅니다.
레코드 시스템에서 Windows Server AD 또는 Microsoft Entra ID로의 인바운드 매핑을 구성합니다. SAP SuccessFactors를 사용하고 사용자를 Windows Server AD와 Microsoft Entra ID로 프로비전하는 경우, SuccessFactors에서 Active Directory로의 사용자 프로비전 구성 섹션의 단계를 따릅니다.

SAP SuccessFactors를 사용하고 Windows Server AD로 프로비전하지 않는 경우, SuccessFactors에서 Microsoft Entra ID로의 사용자 프로비전 구성 섹션의 단계를 따릅니다.

매핑 구성 시에는 상관 관계에 사용되는 Windows Server AD 특성이나 Microsoft Entra ID 사용자 특성의 이 특성을 사용하여 개체 매치가 포함된 매핑을 구성해야 합니다. 또한 작업자 입사일과 퇴사일에 필요한 특성과 HR 원본에서 유래한 대상 애플리케이션에 필요한 모든 특성에 대한 매핑을 구성합니다.
레코드 시스템에서 초기 인바운드 프로비전을 수행합니다. SAP SuccessFactors를 사용하고 사용자를 Windows Server AD와 Microsoft Entra ID로 프로비전하는 경우, 프로비전 사용 설정 및 시작 섹션의 단계를 따릅니다. SAP SuccessFactors를 사용하고 사용자를 Windows Server AD로 프로비전하지 않는 경우, 프로비전 사용 설정 및 시작 섹션의 단계를 따릅니다.
레코드 시스템에서 초기 동기화가 완료되기를 기다립니다. SAP SuccessFactors에서 Windows Server AD 또는 Microsoft Entra ID로 동기화하는 경우, 디렉터리와의 초기 동기화가 완료된 후 Microsoft Entra는 Microsoft Entra 관리 센터의 SAP SuccessFactors 애플리케이션에서 프로비전 탭의 감사 요약 보고서를 업데이트합니다.
Windows Server AD로 프로비전하는 경우, Windows Server AD에서 만든 새 사용자나 거기에 업데이트된 사용자가 Windows Server AD에서 Microsoft Entra ID로 동기화될 때까지 기다립니다. Windows Server AD의 사용자가 Microsoft Entra ID로 변경될 때까지 기다리면 사용자의 Microsoft Entra ID 표시에 Windows Server AD의 전체 사용자 및 특성 집합이 포함됩니다.

Microsoft Entra Cloud Sync를 사용 중인 경우, Microsoft Entra Cloud Sync를 표현하는 서비스 주체의 동기화 작업을 검색하여 동기화 상태의 steadyStateLastAchievedTime을 모니터링할 수 있습니다. 서비스 주체 ID가 없는 경우, 동기화 스키마 보기를 참조하세요.
사용자가 Microsoft Entra ID로 프로비전되었는지 확인합니다. 이 시점에는 사용자가 대상 애플리케이션에 필요한 특성을 사용하여 Microsoft Entra ID에 있어야 합니다. 예를 들어, 사용자에게 givenname 특성과 surname 특성, employeeID 특성이 필요할 수 있습니다. 특정한 특성이 있는 사용자 수나 누락된 특성이 있는 사용자 수를 표시하려면 다음 스크립트와 유사한 PowerShell 명령을 사용하면 됩니다.
```
$u = get-mguser -all -property id,displayname,userprincipalname,usertype,givenname,surname,employeeid
$u2 = $u | where-object {$_.usertype -ne 'Guest' -and $_.employeeid -ne $null}
$u2c = $u2.Count
write-output "member users with employeeID attribute: $u2c"
$u3 = $u| Where-Object {$_.UserType -ne 'Guest' -and ($_.EmployeeId -eq $null -or $_.GivenName -eq $null -or $_.Surname -eq $null)}
$u3c = $u3.Count
write-output "member users missing employeeID, givenname or surname attributes: $u3c"
```
상관 관계 없는 예상 밖의 계정이 Microsoft Entra ID에 없는지 확인합니다. 일반적으로, Microsoft Entra ID의 일부 사용자는 신뢰할 수 있는 레코드 원본 시스템의 작업자와 일치하지 않습니다. 여기에는 긴급 관리 액세스에 대한 비상 계정, IT 공급업체 계정, 비즈니스 게스트가 포함됩니다.

그러나 현재 작업자의 계정과 유사하지만 작업자 레코드와 동기화되지 않은 Microsoft Entra의 고아 계정일 수도 있습니다. 예전에는 직원이었으나 더 이상 HR 시스템에 존재하지 않는 인원으로 인해 고아 계정이 발생할 수 있습니다. 일치 오류에서 비롯할 수도 있습니다. 아니면 이름을 변경하거나 재고용된 인원 같은 데이터 품질 관련 문제를 통해 발생할 수 있습니다.

이제 사용자가 Microsoft Entra ID에 있으므로 다음 섹션에서는 대상 애플리케이션에 프로비전합니다.

SAP Cloud Identity Services에 사용자 프로비전

이 섹션의 단계를 통해서는 Microsoft Entra ID에서 SAP Cloud Identity Services로의 프로비전을 구성합니다. 기본적으로는 Microsoft Entra ID를 설정하여 사용자를 SAP Cloud Identity Services에 자동으로 프로비전 및 프로비전 해제합니다. 그렇게 함으로써 해당 사용자가 SAP Cloud Identity Services에 인증할 수 있으며 SAP Cloud Identity Services에 통합된 기타 SAP 워크로드에 액세스할 수 있습니다. SAP Cloud Identity Services는 로컬 ID 디렉터리에서 다른 SAP 애플리케이션으로의 대상 시스템 프로비전을 지원합니다.

아니면, Microsoft Entra ID에서 읽도록 SAP Cloud Identity Services를 구성할 수 있습니다. SAP Cloud Identity Services를 사용하여 Microsoft Entra ID에서 사용자를 읽고 선택적으로 그룹까지 읽는 경우 SAP Cloud Identity Services 구성 방법에 대한 SAP 지침을 따르세요. 그런 다음, 다음 섹션으로 이동합니다.

SAP Cloud Identity Services를 사용하지 않는 경우 다음 섹션으로 건너뜁니다.

관리자 권한이 있는 SAP Cloud Identity Services의 사용자 계정이 있는 SAP Cloud Identity Services 테넌트가 있는지 확인합니다.
프로비전을 위해 SAP Cloud Identity Services를 설정합니다. SAP Cloud Identity Services 관리 콘솔에 로그인한 다음 프로비전을 위한 SAP Cloud Identity Services 설정 섹션의 단계를 따릅니다.
갤러리에서 SAP Cloud Identity Services를 추가하고 SAP Cloud Identity Services에 대한 자동 사용자 프로비전을 구성합니다. 갤러리에서 SAP Cloud Identity Services 추가하기 섹션과 SAP Cloud Identity Services에 대한 자동 사용자 프로비전 구성 섹션의 단계를 따릅니다.
Microsoft Entra ID에서 SAP Cloud Identity Services로 테스트 사용자를 프로비전합니다. Microsoft Entra ID에서 SAP Cloud Identity Services로 새 테스트 사용자 프로비전 섹션의 단계를 따라 수행하여 프로비전 통합이 준비되었는지 확인합니다.
Microsoft Entra 및 SAP Cloud Identity Services의 기존 사용자 상관 관계를 지정할 수 있는지 확인합니다. Microsoft Entra ID의 사용자를 SAP Cloud Identity Services에 이미 있는 사용자와 비교하려면 다음 섹션의 단계를 수행합니다.
- 기존 SAP Cloud Identity Services 사용자에게 필요한 일치 특성이 있는지 확인
- 기존 Microsoft Entra 사용자에게 필요한 특성이 있는지 확인
SAP Cloud Identity Services에 있는 사용자를 Microsoft Entra ID의 애플리케이션에 할당합니다. Microsoft Entra ID에서 SAP Cloud Identity Services 애플리케이션에 사용자 할당 섹션의 단계를 따릅니다. 이들 단계를 통해 다음을 수행해야 합니다.
- 프로비전이 격리되지 않도록 프로비전 문제를 해결합니다.
- SAP Cloud Identity Services에 있지만 Microsoft Entra ID의 애플리케이션에는 아직 할당되지 않은 사용자를 확인합니다.
- 남아 있는 사용자를 할당합니다.
- 초기 동기화를 모니터링합니다.
Microsoft Entra ID에서 SAP Cloud Identity Services로의 동기화를 기다립니다. 애플리케이션에 할당된 모든 사용자가 프로비전될 때까지 기다립니다. 초기 주기는 20분에서 몇 시간 사이가 걸립니다. 시간은 Microsoft Entra 디렉터리의 크기와 프로비전 범위에 있는 사용자 수에 따라 다릅니다. SAP Cloud Identity Services를 표현하는 서비스 주체의 동기화 작업을 검색하여 동기화 상태의 steadyStateLastAchievedTime 속성을 모니터링할 수 있습니다.
프로비전 오류를 확인합니다. Microsoft Entra 관리 센터 또는 Graph API를 통해 프로비전 로그를 확인합니다. 로그를 실패 상태로 필터링합니다.

오류 코드가 DuplicateTargetEntries인 오류가 있는 경우 이 코드는 프로비전 일치 규칙이 모호하다는 의미입니다. 개별 Microsoft Entra 사용자가 애플리케이션 사용자 1명과 일치하도록 하려면 일치에 사용되는 Microsoft Entra 사용자 또는 매핑을 업데이트해야 합니다. 그런 다음, 로그를 만들기 작업, 건너뜀 상태로 필터링합니다.

사용자가 *NotEffectivelyEntitled의 SkipReason 코드를 건너뛴 경우, 이 로그 이벤트가 의미하는 것은 사용자 계정 상태가 사용하지 않음이어서 Microsoft Entra ID의 사용자 계정이 일치하지 않았다는 뜻일 수 있습니다.
SAP Cloud Identity Services의 사용자를 Microsoft Entra ID의 사용자와 비교합니다. 기존 SAP Cloud Identity Services 사용자에게 필요한 일치 특성이 있는지 확인 섹션의 단계를 반복하여 SAP Cloud Identity Services의 사용자를 다시 내보냅니다. 그런 다음 내보낸 사용자에게 SAP 애플리케이션에 필요한 속성이 있는지 확인합니다. {$_.employeeId -eq $null} 같은 필터를 사용하면 누락된 특성이 있는 사용자로 사용자 목록을 필터링하기 위해 PowerShell where-object 명령을 사용할 수 있습니다.
Microsoft Entra에서 SAP Cloud Identity Services로 페더레이션된 SSO를 구성합니다. SAP Cloud Identity Services에 SAML 기반 SSO를 사용하도록 설정합니다. SAP Cloud Identity Services SSO 자습서에 나와 있는 지침을 따릅니다.
애플리케이션 웹 엔드포인트를 적절한 조건부 액세스 정책의 범위로 가져옵니다. 동일한 거버넌스 요구 사항이 적용되는 다른 애플리케이션을 위해서 만들어진 기존 조건부 액세스 정책을 가지고 있을 수 있습니다. 이런 경우, 정책을 여러 가지 사용하지 않도록 해당 정책을 이 애플리케이션에도 적용하게끔 업데이트할 수 있습니다.

업데이트를 수행한 후에는 예상한 정책이 적용되는지 확인합니다. 조건부 액세스 가상 도구를 사용하여 어떤 정책이 사용자에게 적용되는지 확인할 수 있습니다.
테스트 사용자가 SAP 애플리케이션에 연결할 수 있는지 확인합니다. Microsoft 내 앱을 사용하여 애플리케이션 SSO를 테스트할 수 있습니다. 테스트 사용자가 SAP Cloud Identity Services 애플리케이션에 할당되고 Microsoft Entra ID에서 SAP Cloud Identity Services로 프로비전되었는지 확인합니다. 그런 다음, 해당 사용자로 Microsoft Entra에 로그인하여 myapps.microsoft.com으로 이동합니다.

내 앱의 SAP Cloud Identity Services 타일을 선택할 때는, SP(서비스 공급자) 모드로 구성된 경우, 로그인 흐름을 시작하기 위해 애플리케이션의 로그인 페이지로 리디렉션됩니다. IDP(ID 공급자) 모드로 구성된 경우, SSO를 설정한 SAP Cloud Identity Services에 자동으로 로그인됩니다.

사용자를 SAP ECC에 프로비전

이제 Microsoft Entra ID에 사용자가 있으므로 SAP 온-프레미스로 프로비전할 수 있습니다.

SAP ECC를 사용하지 않는 경우 다음 섹션으로 건너뜁니다.

프로비전을 구성합니다. 사용자를 NetWeaver AS ABAP 7.0 이상을 통해 SAP ECC로 프로비전하도록 Microsoft Entra ID 구성에 나와 있는 지침을 따릅니다.
Microsoft Entra ID에서 SAP ECC로의 동기화를 기다립니다. SAP ECC 애플리케이션에 할당된 모든 사용자가 프로비전될 때까지 기다립니다. 초기 주기는 20분에서 몇 시간 사이가 걸립니다. 시간은 Microsoft Entra 디렉터리의 크기와 프로비전 범위에 있는 사용자 수에 따라 다릅니다. 서비스 주체의 동기화 작업을 검색하여 동기화 상태의 steadyStateLastAchievedTime 속성을 모니터링할 수 있습니다.
프로비전 오류를 확인합니다. Microsoft Entra 관리 센터 또는 Graph API를 통해 프로비전 로그를 확인합니다. 로그를 실패 상태로 필터링합니다.

오류 코드가 DuplicateTargetEntries인 오류가 있는 경우 이 로그 이벤트는 프로비전 일치 규칙이 모호하다는 의미입니다. 개별 Microsoft Entra 사용자가 애플리케이션 사용자 1명과 일치하도록 하려면 일치에 사용되는 Microsoft Entra 사용자 또는 매핑을 업데이트해야 합니다. 그런 다음, 로그를 만들기 작업, 건너뜀 상태로 필터링합니다.

사용자가 NotEffectivelyEntitled의 SkipReason 코드를 건너뛴 경우, 이 코드가 의미하는 것은 사용자 계정 상태가 사용하지 않음이어서 Microsoft Entra ID의 사용자 계정이 일치하지 않았다는 뜻일 수 있습니다.
SAP ECC의 사용자를 Microsoft Entra ID의 사용자와 비교합니다. SAP ECC에 프로비전하기 위한 프로비전 에이전트를 호스팅하는 Windows Server에서 Microsoft ECMA2Host Windows 서비스를 다시 시작합니다. 서비스가 다시 시작되면 SAP ECC에서 사용자의 전체 가져오기를 수행합니다.
Microsoft Entra에서 SAP로 페더레이션된 SSO를 구성합니다. SAP 애플리케이션의 SAML 기반 SSO를 사용하도록 설정합니다. SAP NetWeaver를 사용하는 경우 SAP NetWeaver SSO 자습서에 나와 있는 지침을 따릅니다.
애플리케이션 웹 엔드포인트를 적절한 조건부 액세스 정책의 범위로 가져옵니다. 동일한 거버넌스 요구 사항이 적용되는 다른 애플리케이션을 위해서 만들어진 기존 조건부 액세스 정책을 가지고 있을 수 있습니다. 이런 경우, 정책을 여러 가지 사용하지 않도록 해당 정책을 이 애플리케이션에도 적용하게끔 업데이트할 수 있습니다.

업데이트를 수행한 후에는 예상한 정책이 적용되는지 확인합니다. 조건부 액세스 가상 도구를 사용하여 어떤 정책이 사용자에게 적용되는지 확인할 수 있습니다.
테스트 사용자를 프로비전하고 SAP NetWeaver에 로그인할 수 있는지 확인합니다. SSO 테스트 섹션의 지침에 따라 조건부 액세스가 구성된 후 사용자가 로그인할 수 있는지 확인합니다.

SuccessFactors 및 기타 애플리케이션에 대한 프로비전 구성

회사 메일을 포함하여 Microsoft Entra ID에서 SAP SuccessFactors Employee Central에 특정 특성을 쓰도록 Microsoft Entra를 구성할 수 있습니다. 자세한 내용은 Microsoft Entra ID에서 SAP SuccessFactors 쓰기 저장 구성을 참조하세요.

Microsoft Entra는 OpenID Connect, SAML, SCIM, SQL, LDAP, SOAP, REST와 같은 표준을 사용하는 앱을 비롯한 다른 많은 애플리케이션에 프로비전할 수도 있습니다. 자세한 내용은 애플리케이션을 Microsoft Entra ID와 통합을 참조하세요.

Microsoft Entra에서 필요한 애플리케이션 액세스 권한을 사용자에게 할당

구성하려는 테넌트가 SAP 애플리케이션 액세스를 위해 특별히 구성된 완전히 격리된 테넌트가 아니면 테넌트의 모든 사용자가 SAP 애플리케이션에 액세스해야 할 가능성은 거의 없습니다. 애플리케이션에 애플리케이션 역할이 할당된 사용자만 애플리케이션에 프로비전되고 Microsoft Entra ID에서 해당 애플리케이션으로 로그인할 수 있도록 테넌트에서 SAP 애플리케이션이 구성됩니다.

애플리케이션에 할당된 사용자가 Microsoft Entra ID로 업데이트되면 해당 변경 내용이 해당 애플리케이션에 자동으로 프로비전됩니다.

Microsoft Entra ID Governance가 있는 경우 Microsoft Entra ID의 SAP Cloud Identity Services 또는 SAP ECC의 애플리케이션 역할 할당에 대한 변경을 자동화할 수 있습니다. 자동화를 사용하여 사용자가 조직에 참여하거나 역할을 떠나거나 변경할 때 할당을 추가하거나 제거할 수 있습니다.

기존 할당을 검토합니다. 필요에 따라, 애플리케이션 역할 할당에 대해 일회용 액세스 검토를 수행합니다. 이 검토가 완료되면 액세스 검토는 더 이상 필요 없는 할당을 제거합니다.
애플리케이션 역할 할당을 최신 상태로 유지하도록 프로세스를 구성합니다. Microsoft Entra 권한 관리를 사용하는 경우, PowerShell을 사용하여 역할이 하나인 애플리케이션의 권한 관리 관련 액세스 패키지 만들기를 참조하고 SAP Cloud Identity Services나 SAP ECC를 표시하는 애플리케이션에 대한 할당을 구성합니다.

해당 액세스 패키지에서 사용자가 액세스 권한을 요청할 때 할당할 수 있는 정책을 사용할 수 있습니다. 할당은 관리자에 의해 이루어지거나, 규칙에 따라 자동으로 이루어지거나, 수명 주기 워크플로를 통해 이루어질 수 있습니다.

Microsoft Entra ID Governance이 없는 경우, Microsoft Entra 관리 센터에서 각 개별 사용자를 애플리케이션에 할당할 수 있습니다. PowerShell cmdlet New-MgServicePrincipalAppRoleAssignedTo를 통해 애플리케이션에 개별 사용자를 할당할 수 있습니다.

새로 만든 Microsoft Entra 사용자 또는 Windows Server AD 사용자에게 자격 증명 배포

이 시점에는 Microsoft Entra ID에 모든 사용자가 있으며 이들이 관련 SAP 애플리케이션에 프로비전됩니다. 이 프로세스 중에 생성된 모든 사용자는 이전에 Windows Server AD 또는 Microsoft Entra ID에 없는 작업자이므로 새 자격 증명이 필요합니다.

Microsoft Entra 인바운드 프로비전이 Windows Server AD에서 사용자를 만드는 경우 새로 만든 사용자를 위해 Windows Server AD 초기 자격 증명을 배포합니다. Get-MgAuditLogProvisioning 명령을 사용하여 Microsoft Entra와 Windows Server AD의 상호작용에 대한 이벤트 목록을 검색할 수 있습니다.

도메인에 가입된 컴퓨터에서 -Reset매개 변수를 통해 Set-ADAccountPassword 명령을 사용하여 사용자의 새 Windows Server AD 암호를 설정할 수 있습니다. 그런 다음 -ChangePasswordAtLogon매개 변수를 통해 Set-ADUser 명령을 사용하여 사용자가 다음 로그인 시 새 암호를 선택하도록 요구합니다.
Microsoft Entra 인바운드 프로비전이 Microsoft Entra ID에서 사용자를 만드는 경우 새로 만든 사용자를 위해 Microsoft Entra ID 초기 자격 증명을 배포합니다. 새로 만든 사용자 목록을 Get-MgAuditLogDirectoryAudit -Filter "category eq 'UserManagement' and activityDisplayName eq 'Add user' and result eq 'success' and activityDateTime+ge+2024-05-01" -all 등의 매개 변수를 이용한 Get-MgAuditLogDirectoryAudit 명령으로 검색할 수 있습니다.

사용자가 사용할 임시 액세스 패스를 생성하려면 임시 액세스 패스 만들기에 설명되어 있는 것처럼 New-MgUserAuthenticationTemporaryAccessPassMethod와 Get-MgUserAuthenticationTemporaryAccessPassMethod 명령을 사용하면 됩니다.
사용자가 MFA에 등록되어 있는지 확인합니다. MFA 등록 사용자 관련 PowerShell 보고 섹션의 PowerShell 명령을 실행하여 MFA 미등록 사용자를 식별할 수 있습니다.
사용자에게 임시 정책 제외가 필요한 경우 되풀이 액세스 검토를 만듭니다. 경우에 따라 권한 있는 모든 사용자에게 조건부 액세스 정책을 즉시 적용하지 못할 수도 있습니다. 예를 들어 일부 사용자는 적절하게 등록된 디바이스를 갖고 있지 않을 수 있습니다. 조건부 액세스 정책에서 하나 이상의 사용자를 제외하고 액세스를 허용해야 하는 경우 조건부 액세스 정책에서 제외된 사용자 그룹의 액세스 검토를 구성합니다.

ID 흐름 모니터링

이제 애플리케이션을 사용하여 인바운드 프로비전과 아웃바운드 프로비전을 구성했으므로 Microsoft Entra의 자동화를 사용하여 신뢰할 수 있는 레코드 시스템에서 대상 애플리케이션으로의 지속적인 프로비전을 모니터링할 수 있습니다.

인바운드 프로비전 모니터링

프로비전 서비스에서 실행하는 작업은 Microsoft Entra 프로비전 로그에 기록됩니다. Microsoft Entra 관리 센터에서 프로비저닝 로그에 액세스할 수 있습니다. 원본 시스템이나 대상 시스템에서 사용자의 이름 또는 식별자를 기준으로 프로비전 데이터를 검색할 수 있습니다. 자세한 내용은 프로비저닝 로그를 참조하세요.

Windows Server AD의 변경 내용 모니터링

Windows Server 감사 정책 권장 사항의 설명대로, 사용자 계정 관리 성공 감사 이벤트를 모든 도메인 컨트롤러에서 사용하도록 설정했고 분석을 위해 수집했는지 확인합니다.

애플리케이션 역할 할당 모니터링

Microsoft Entra ID에서 감사 이벤트를 Azure Monitor에 보내도록 구성했다면, Azure Monitor 통합 문서를 사용하여 사용자들이 액세스 권한을 받은 방식에 대한 인사이트를 얻을 수 있습니다.

Microsoft Entra 권한 관리를 사용한다면 액세스 패키지 작업이라는 통합 문서에는 특정 액세스 패키지와 관련된 각 이벤트가 표시됩니다.
액세스 패키지 할당으로 인해 생성되지 않은 애플리케이션과 관련하여 애플리케이션 역할 할당이 변경되었는지 확인하려면 애플리케이션 역할 할당 작업이라는 통합 문서를 선택합니다. 권한 부여 작업을 생략하도록 선택하면 권한 관리를 통해 수행되지 않은 애플리케이션 역할 변경 내용만 표시됩니다. 예를 들어 다른 관리자가 사용자를 애플리케이션 역할에 직접 할당한 경우 행이 표시됩니다.

아웃바운드 프로비전 모니터링

Microsoft Entra에 통합되는 애플리케이션 하나하나마다 동기화 세부 정보 섹션을 사용하여 진행 상태를 모니터링하고 링크를 통해 프로비전 활동 보고서를 확인할 수 있습니다. 이 보고서는 해당 애플리케이션에서 Microsoft Entra 프로비전 서비스가 수행하는 모든 작업을 설명합니다. Microsoft Graph API를 통해 프로비전 프로젝트를 모니터링할 수도 있습니다.

Microsoft Entra 프로비전 로그를 읽는 방법에 대한 자세한 내용은 자동 사용자 계정 프로비전에 대한 보고를 참조하세요.

SSO 모니터링

Microsoft Entra 관리 센터의 로그인 보고서 또는 Microsoft Graph를 통해 지난 30일간의 애플리케이션 로그인을 볼 수 있습니다. 로그인 로그를 Azure Monitor로 보내 최대 2년 동안 로그인 활동을 보관할 수도 있습니다.

Microsoft Entra ID Governance에서 할당 모니터링

Microsoft Entra ID Governance를 사용하는 경우 Microsoft Entra ID Governance 기능을 사용하여 사용자가 액세스하는 방법을 보고할 수 있습니다. 예시:

관리자 또는 카탈로그 소유자는 Microsoft Entra 관리 센터, Microsoft Graph 또는 PowerShell을 통해 액세스 패키지가 할당된 사용자 목록을 검색할 수 있습니다.
Microsoft Entra 관리 센터 또는 PowerShell을 통해 감사 로그를 Azure Monitor로 보내고 액세스 패키지 변경 기록을 볼 수도 있습니다.

이러한 시나리오 및 기타 ID 거버넌스 시나리오에 대한 자세한 내용은 필요에 따라 권한 관리 정책 및 액세스를 조정하도록 모니터링하는 방법을 참조하세요.

다음을 통해 공유

SAP 원본 및 대상 앱을 사용한 사용자 프로비전을 위해 Microsoft Entra 배포 계획

개요

SAP 원본 및 대상과의 통합 계획

애플리케이션 온보딩 시퀀스 및 애플리케이션이 Microsoft Entra와 통합되는 방법 결정