애플리케이션의 기존 사용자 관리 - Microsoft PowerShell

아티클
04/03/2024

애플리케이션을 액세스 검토와 같은 Microsoft Entra ID 거버넌스 기능과 함께 사용하기 전에 애플리케이션의 기존 사용자로 Microsoft Entra ID를 채워야 하는 세 가지 일반적인 시나리오가 있습니다.

라이선스 요구 사항

이 기능을 사용하려면 Microsoft Entra ID Governance 라이선스가 필요합니다. 요구 사항에 적합한 라이선스를 찾으려면 Microsoft Entra ID Governance 라이선스 기본 사항을 참조하세요.

자체 ID 공급자 사용 후 Microsoft Entra ID로 마이그레이션된 애플리케이션

첫 번째 시나리오는 애플리케이션이 이미 환경에 있는 경우입니다. 이전에는 애플리케이션에서 자체 ID 공급자나 데이터 저장소를 사용하여 액세스한 사용자를 추적했습니다.

애플리케이션에서 Microsoft Entra ID를 사용하도록 변경하면 Microsoft Entra ID에 있고 액세스가 허용된 사용자만 해당 애플리케이션에 액세스할 수 있습니다. 구성 변경 과정에서 해당 애플리케이션의 데이터 저장소에 있는 기존 사용자를 Microsoft Entra ID로 가져올 수 있습니다. 그런 다음, 해당 사용자는 Microsoft Entra ID를 통해 계속 액세스할 수 있습니다.

애플리케이션과 사용자의 관계가 다른 곳에서 시작된 경우에도Microsoft Entra ID에서 표시되는 애플리케이션과 연결된 사용자는 Microsoft Entra ID를 사용하여 애플리케이션에 대한 액세스 권한이 있는 사용자를 추적할 수 있습니다. 예를 들어 관계가 애플리케이션의 데이터베이스나 디렉터리에서 시작되었을 수 있습니다.

Microsoft Entra ID에서 사용자의 할당을 알고 있으면 애플리케이션의 데이터 저장소에 업데이트를 보낼 수 있습니다. 업데이트에는 사용자 특성이 변경되거나 사용자가 애플리케이션 범위를 벗어나는 경우를 포함합니다.

Microsoft Entra ID를 유일한 ID 공급자로 사용하지 않는 애플리케이션

두 번째 시나리오는 애플리케이션이 단독으로 Microsoft Entra ID를 ID 공급자로 사용하지 않는 경우입니다.

경우에 따라 애플리케이션이 AD 그룹에 의존할 수 있습니다. 이 시나리오는 애플리케이션에 대한 사용자 액세스 검토 준비의 패턴 B에 설명되어 있습니다. 해당 문서에 설명된 대로 해당 애플리케이션에 대한 프로비전을 구성할 필요가 없습니다. 대신 AD 그룹의 멤버 자격을 검토하는 방법에 대한 해당 문서의 패턴 B에 대한 지침을 따릅니다.

경우에 따라 애플리케이션은 여러 ID 공급자를 지원하거나 자체 기본 제공 자격 증명 스토리지를 보유할 수 있습니다. 이 시나리오는 사용자의 애플리케이션 액세스에 대한 액세스 검토 준비에서 패턴 C로 설명되어 있습니다.

애플리케이션에서 다른 ID 공급자나 로컬 자격 증명 인증을 제거하는 것이 불가능할 수 있습니다. 이러한 경우 Microsoft Entra ID를 사용하여 해당 애플리케이션에 대한 액세스 권한이 있는 사용자를 검토하거나 해당 애플리케이션에서 다른 사용자의 액세스를 제거하면 Microsoft Entra ID에서 인증을 위해 Microsoft Entra ID에 의존하지 않는 애플리케이션 사용자를 나타내는 할당을 만들어야 합니다.

액세스 검토 과정에서 애플리케이션에 대한 액세스 권한이 있는 모든 사용자를 검토하려는 경우 이러한 할당이 필요합니다.

예를 들어 사용자가 애플리케이션의 데이터 저장소에 있다고 가정합니다. Microsoft Entra ID는 애플리케이션에 역할 할당을 요구하도록 구성됩니다. 그러나 사용자에게는 Microsoft Entra ID의 애플리케이션 역할 할당이 없습니다.

사용자가 Microsoft Entra ID에서 업데이트되면 애플리케이션에 변경 사항이 전송되지 않습니다. 그리고 애플리케이션의 역할 할당을 검토하는 경우 사용자가 검토에 포함되지 않습니다. 모든 사용자를 검토에 포함하려면 애플리케이션의 모든 사용자에 대한 애플리케이션 역할 할당이 있어야 합니다.

애플리케이션은 Microsoft Entra ID를 ID 공급자로 사용하지 않으며 프로비전을 지원하지 않습니다.

일부 레거시 애플리케이션의 경우 애플리케이션에서 다른 ID 공급자 또는 로컬 자격 증명 인증을 제거하거나 해당 애플리케이션에 대한 프로비전 프로토콜 지원을 사용하도록 설정하는 것이 불가능할 수 있습니다.

프로비전 프로토콜을 지원하지 않는 애플리케이션 시나리오는 프로비전을 지원하지 않는 애플리케이션의 기존 사용자 관리라는 별도 문서에서 다룹니다.

용어

이 문서에서는 Microsoft Graph PowerShell cmdlet을 사용하여 애플리케이션 역할 할당을 관리하는 프로세스를 설명합니다. 다음 Microsoft Graph 용어를 사용합니다.

Microsoft Graph 용어를 보여 주는 다이어그램

Microsoft Entra ID에서 서비스 주체(ServicePrincipal)는 특정 조직의 디렉터리에 있는 애플리케이션을 나타냅니다. ServicePrincipal에는 애플리케이션에서 지원하는 역할(예: Marketing specialist)을 나열하는 AppRoles라는 속성이 있습니다. AppRoleAssignment는 서비스 주체에 사용자를 연결하고 해당 애플리케이션에서 사용자의 역할을 지정합니다. 애플리케이션에 대한 Single Sign-On과 애플리케이션에 대한 프로비전이 별도로 처리되는 경우 애플리케이션에 둘 이상의 서비스 주체가 있을 수 있습니다.

Microsoft Entra 권한 관리 액세스 패키지를 사용하여 사용자에게 애플리케이션에 대한 시간 제한 액세스를 제공할 수도 있습니다. 권한 관리에서 AccessPackage에는 잠재적으로 여러 서비스 주체의 리소스 역할이 하나 이상 포함됩니다. AccessPackage에는 액세스 패키지에 대한 사용자 할당(Assignment)도 있습니다.

액세스 패키지에 대한 사용자 할당을 만들면 Microsoft Entra 권한 관리는 액세스 패키지의 각 애플리케이션 서비스 주체에 대해 사용자에게 필요한 AppRoleAssignment 인스턴스를 자동으로 만듭니다. 자세한 내용은 PowerShell을 통해 액세스 패키지를 만드는 방법에 대한 Microsoft Entra 권한 관리에서 리소스에 대한 액세스 관리 자습서를 참조하세요.

시작하기 전에

테넌트에 다음 라이선스 중 하나가 있어야 합니다.
- Microsoft Entra ID P2 또는 Microsoft Entra ID 거버넌스
- Enterprise Mobility + Security E5 라이선스
적절한 관리 역할이 있어야 합니다. 이러한 단계를 처음 수행하는 경우 테넌트에서 Microsoft Graph PowerShell 사용을 승인할 수 있는 전역 관리자 역할이 필요합니다.
애플리케이션의 테넌트에 하나 이상의 서비스 주체가 필요합니다.
- 애플리케이션에서 LDAP 디렉터리를 사용하는 경우 Microsoft Entra Connect 프로비전 에이전트 패키지를 다운로드, 설치 및 구성하는 섹션을 통해 사용자를 LDAP 디렉터리로 프로비전하도록 Microsoft Entra ID를 구성하는 가이드를 따릅니다.
- 애플리케이션에서 SQL 데이터베이스를 사용하는 경우 Microsoft Entra Connect 프로비전 에이전트 패키지를 다운로드, 설치 및 구성하는 섹션을 통해 사용자를 SQL 기반 애플리케이션으로 프로비전하도록 Microsoft Entra ID를 구성하는 가이드를 따릅니다.
- 애플리케이션이 SAP Cloud Identity Services를 사용하거나 SCIM 프로토콜을 지원하는 클라우드 애플리케이션이고 애플리케이션이 테넌트에서 아직 구성되지 않은 경우 이 가이드의 뒷부분에서 애플리케이션 갤러리에서 애플리케이션을 등록합니다.
- 애플리케이션이 온-프레미스이고 SCIM 프로토콜을 지원하는 경우 Microsoft Entra ID를 구성하여 온-프레미스 SCIM 기반 애플리케이션에 사용자를 프로비전하기 위한 가이드를 따릅니다.

애플리케이션에서 기존 사용자 수집

모든 사용자를 Microsoft Entra ID에 기록하기 위한 첫 번째 단계는 애플리케이션에 대한 액세스 권한이 있는 기존 사용자의 목록을 수집하는 것입니다.

일부 애플리케이션에는 데이터 저장소에서 현재 사용자 목록을 내보내는 기본 제공 명령이 있을 수 있습니다. 다른 경우에는 애플리케이션에서 외부 디렉터리나 데이터베이스를 사용할 수 있습니다.

일부 환경에서는 애플리케이션이 Microsoft Entra ID에 대한 액세스를 관리하는 데 부적절한 네트워크 세그먼트나 시스템에 있을 수 있습니다. 따라서 해당 디렉터리 또는 데이터베이스에서 사용자 목록을 추출한 다음, 파일로 Microsoft Entra와 상호 작용하는 데 사용할 수 있는 다른 시스템으로 전송해야 합니다.

이 섹션에서는 CSV(쉼표로 구분된 값) 파일에서 사용자 목록을 가져오는 방법에 대한 네 가지 방법을 설명합니다.

LDAP 디렉터리에서
SQL Server 데이터베이스에서
다른 SQL 기반 데이터베이스에서
SAP Cloud Identity Services에서

LDAP 디렉터리를 사용하는 애플리케이션에서 기존 사용자 수집

이 섹션은 Microsoft Entra ID에 인증하지 않는 사용자를 위해 LDAP 디렉터리를 기본 데이터 저장소로 사용하는 애플리케이션에 적용됩니다. Active Directory와 같은 많은 LDAP 디렉터리에는 사용자 목록을 출력하는 명령이 포함됩니다.

애플리케이션의 사용자 범위에 있는 해당 디렉터리의 사용자를 식별합니다. 이 선택은 애플리케이션의 구성에 따라 달라집니다. 일부 애플리케이션의 경우 LDAP 디렉터리에 있는 모든 사용자가 유효한 사용자입니다. 다른 애플리케이션에서는 사용자가 특정 특성을 가지고 있거나 해당 디렉터리에 있는 그룹의 구성원이어야 할 수 있습니다.
디렉터리에서 해당 사용자 하위 집합을 검색하는 명령을 실행합니다. 출력에 Microsoft Entra ID와 일치시키는 데 사용할 사용자 특성이 포함되어 있는지 확인합니다. 이러한 특성의 예로는 직원 ID, 계정 이름 및 이메일 주소가 있습니다.

예를 들어 이 명령은 LDAP 디렉터리에 있는 모든 사람의 특성을 사용하여 userPrincipalName 현재 파일 시스템 디렉터리에 CSV 파일을 생성합니다.
```
$out_filename = ".\users.csv"
csvde -f $out_filename -l userPrincipalName,cn -r "(objectclass=person)"
```
필요한 경우 사용자 목록이 포함된 CSV 파일을 Microsoft Graph PowerShell cmdlet이 설치된 시스템으로 전송합니다.
이 문서의 뒷부분에 있는 애플리케이션의 사용자와 일치하는 사용자가 있는 Microsoft Entra ID 확인 섹션을 계속 읽어보세요.

SQL Server 마법사를 사용하여 애플리케이션의 데이터베이스 테이블에서 기존 사용자 수집

이 섹션은 SQL Server를 기본 데이터 저장소로 사용하는 애플리케이션에 적용됩니다.

먼저 테이블에서 사용자 목록을 가져옵니다. 대부분의 데이터베이스는 테이블의 내용을 CSV 파일과 같은 표준 파일 형식으로 내보내는 방법을 제공합니다. 애플리케이션에서 SQL Server 데이터베이스를 사용하는 경우 SQL Server 가져오기 및 내보내기 마법사를 사용하여 데이터베이스의 일부를 내보낼 수 있습니다. 데이터베이스의 유틸리티가 없으면 다음 섹션의 설명대로 PowerShell에서 ODBC 드라이버를 사용할 수 있습니다.

SQL Server가 설치된 시스템에 로그인합니다.
SQL Server 2019 가져오기 및 내보내기(64비트) 또는 데이터베이스에 해당하는 유틸리티를 엽니다.
기존 데이터베이스를 원본으로 선택합니다.
플랫 파일 대상을 대상으로 선택합니다. 파일 이름을 입력하고 코드 페이지 값을 65001(UTF-8)로 변경합니다.
마법사를 완료하고 즉시 실행하는 옵션을 선택합니다.
실행이 완료될 때까지 기다립니다.
필요한 경우 사용자 목록이 포함된 CSV 파일을 Microsoft Graph PowerShell cmdlet이 설치된 시스템으로 전송합니다.
이 문서의 뒷부분에 있는 애플리케이션의 사용자와 일치하는 사용자가 있는 Microsoft Entra ID 확인 섹션을 계속 읽어보세요.

PowerShell을 사용하여 애플리케이션의 데이터베이스 테이블에서 기존 사용자 수집

이 섹션은 다른 SQL 데이터베이스를 기본 데이터 저장소로 사용하는 애플리케이션에 적용되며 여기에서는 ECMA 커넥터 호스트를 사용하여 사용자를 해당 애플리케이션에 프로비전합니다. 프로비전 에이전트를 아직 구성하지 않았으면 이 가이드를 사용하여 이 섹션에서 사용할 DSN 연결 파일을 만듭니다.

프로비전 에이전트가 설치되어 있거나 설치될 시스템에 로그인합니다.
PowerShell을 엽니다.
데이터베이스 시스템에 연결하는 데 사용할 연결 문자열을 생성합니다.

연결 문자열 구성 요소는 데이터베이스 요구 사항에 따라 달라집니다. SQL Server를 사용하는 경우 DSN 및 연결 문자열 키워드와 특성 목록을 참조하세요.

다른 데이터베이스를 사용하는 경우 해당 데이터베이스에 연결할 수 있는 필수 키워드를 포함해야 합니다. 예를 들어 데이터베이스에서 DSN 파일의 정규화된 경로 이름, 사용자 ID 및 암호를 사용하는 경우 다음 명령을 사용하여 연결 문자열을 생성합니다.
```
$filedsn = "c:\users\administrator\documents\db.dsn"
$db_cs = "filedsn=" + $filedsn + ";uid=p;pwd=secret"
```
다음 명령을 사용하여 데이터베이스에 대한 연결을 열고 연결 문자열을 제공합니다.
```
$db_conn = New-Object data.odbc.OdbcConnection
$db_conn.ConnectionString = $db_cs
$db_conn.Open()
```
데이터베이스 테이블에서 사용자를 검색하는 SQL 쿼리를 생성합니다. 애플리케이션 데이터베이스의 사용자와 Microsoft Entra ID의 사용자를 일치시키는 데 사용할 열을 포함해야 합니다. 열에는 직원 ID, 계정 이름 또는 이메일 주소가 포함될 수 있습니다.

예를 들어 사용자가 name 및 email 열이 있는 USERS라는 데이터베이스 테이블에 있으면 다음 명령을 입력합니다.
```
$db_query = "SELECT name,email from USERS"
```

연결을 통해 데이터베이스에 쿼리를 보냅니다.

$result = (new-object data.odbc.OdbcCommand($db_query,$db_conn)).ExecuteReader()
$table = new-object System.Data.DataTable
$table.Load($result)

결과는 쿼리에서 검색된 사용자를 나타내는 행 목록입니다.

CSV 파일에 결과를 씁니다.

$out_filename = ".\users.csv"
$table.Rows | Export-Csv -Path $out_filename -NoTypeInformation -Encoding UTF8

이 시스템에 Microsoft Graph PowerShell cmdlet이 설치되어 있지 않거나 시스템이 Microsoft Entra ID에 연결되지 않은 경우 사용자 목록이 포함된 CSV 파일을 Microsoft Graph PowerShell cmdlet이 설치된 시스템으로 전송합니다.

SAP Cloud Identity Services에서 기존 사용자 수집

이 섹션은 SAP Cloud Identity Services를 사용자 프로비전의 기본 서비스로 사용하는 SAP 애플리케이션에 적용됩니다.

SAP Cloud Identity Services 관리 콘솔 https://<tenantID>.accounts.ondemand.com/admin 에 로그인하거나 https://<tenantID>.trial-accounts.ondemand.com/admin 평가판인 경우 로그인합니다.
사용자 및 권한 부여로 이동하여 사용자를 내보 > 냅니다.
MICROSOFT Entra 사용자를 SAP의 사용자와 일치시키는 데 필요한 모든 특성을 선택합니다. 여기에는 SAP 시스템에서 사용할 수 있는 , userNameemails및 기타 특성이 포함SCIM ID됩니다.
내보내기를 선택하고 브라우저가 CSV 파일을 다운로드할 때까지 기다립니다.
이 시스템에 Microsoft Graph PowerShell cmdlet이 설치되어 있지 않거나 시스템이 Microsoft Entra ID에 연결되지 않은 경우 사용자 목록이 포함된 CSV 파일을 Microsoft Graph PowerShell cmdlet이 설치된 시스템으로 전송합니다.

애플리케이션의 사용자와 일치하는 사용자가 Microsoft Entra ID에 있는지 확인

이제 애플리케이션에서 가져온 모든 사용자 목록이 있으므로 애플리케이션 데이터 저장소의 해당 사용자를 Microsoft Entra ID의 사용자와 일치시킵니다.

계속하기 전에 원본 및 대상 시스템에서 사용자 일치에 대한 정보를 검토합니다. 나중에 동등한 매핑을 사용하여 Microsoft Entra 프로비전을 구성합니다. 이 단계를 수행하면 Microsoft Entra 프로비전이 동일한 일치 규칙으로 애플리케이션의 데이터 저장소를 쿼리할 수 있습니다.

Microsoft Entra ID에서 사용자의 ID를 검색합니다.

이 섹션에서는 Microsoft Graph PowerShell cmdlet을 사용하여 Microsoft Entra ID와 상호 작용하는 방법을 보여 줍니다.

조직에서 이 시나리오에 이러한 cmdlet을 처음 사용하는 경우 테넌트에서 Microsoft Graph PowerShell을 사용할 수 있도록 허용하는 전역 관리자 역할이 필요합니다. 후속 상호 작용에서 다음과 같은 낮은 권한 있는 역할을 사용할 수 있습니다.

사용자 관리자(새 사용자를 만들 것으로 예상되는 경우)
애플리케이션 관리자 또는 ID 거버넌스 관리자(애플리케이션 역할 할당만 관리하는 경우)

PowerShell을 엽니다.
Microsoft Graph PowerShell 모듈을 아직 설치하지 않았으면 이 명령을 사용하여 Microsoft.Graph.Users 모듈과 다른 모듈을 설치합니다.
```
Install-Module Microsoft.Graph
```
모듈이 이미 설치되어 있으면 최신 버전을 사용하고 있는지 확인합니다.
```
Update-Module microsoft.graph.users,microsoft.graph.identity.governance,microsoft.graph.applications
```

Microsoft Entra ID에 연결합니다.

$msg = Connect-MgGraph -ContextScope Process -Scopes "User.ReadWrite.All,Application.ReadWrite.All,AppRoleAssignment.ReadWrite.All,EntitlementManagement.ReadWrite.All"

이 명령을 처음 사용하는 경우 Microsoft Graph 명령줄 도구에 이러한 사용 권한이 있도록 허용하는 데 동의해야 할 수 있습니다.
애플리케이션의 데이터 저장소에서 가져온 사용자 목록을 PowerShell 세션으로 읽어 들입니다. 사용자 목록이 CSV 파일에 있으면 PowerShell cmdlet Import-Csv를 사용하고 이전 섹션의 파일 이름을 인수로 제공할 수 있습니다.

예를 들어 SAP Cloud Identity Services에서 가져온 파일의 이름이 Users-exported-from-sap.csv 현재 디렉터리에 있는 경우 이 명령을 입력합니다.
```
$filename = ".\Users-exported-from-sap.csv"
$dbusers = Import-Csv -Path $filename -Encoding UTF8
```
데이터베이스 또는 디렉터리를 사용하는 경우 파일 이름이 users.csv 현재 디렉터리에 있는 경우 다음 명령을 입력합니다.
```
$filename = ".\users.csv"
$dbusers = Import-Csv -Path $filename -Encoding UTF8
```
Microsoft Entra ID의 사용자 특성과 일치할 users.csv 파일의 열을 선택합니다.

SAP Cloud Identity Services를 사용하는 경우 기본 매핑은 Microsoft Entra ID 특성을 userName 사용하는 SAP SCIM 특성 userPrincipalName입니다.
```
$db_match_column_name = "userName"
$azuread_match_attr_name = "userPrincipalName"
```
데이터베이스 또는 디렉터리를 사용하는 경우 이름이 지정된 EMail 열의 값이 Microsoft Entra 특성 userPrincipalName과 동일한 값인 데이터베이스에 사용자가 있을 수 있습니다.
```
$db_match_column_name = "EMail"
$azuread_match_attr_name = "userPrincipalName"
```

Microsoft Entra ID에서 해당 사용자의 ID를 검색합니다.

다음 PowerShell 스크립트에서는 앞에서 지정한 $dbusers, $db_match_column_name 및 $azuread_match_attr_name 값을 사용합니다. Microsoft Entra ID를 쿼리하여 원본 파일의 각 레코드에 대해 일치하는 값을 가진 특성을 가진 사용자를 찾습니다. 원본 SAP Cloud Identity Services, 데이터베이스 또는 디렉터리에서 가져온 파일에 많은 사용자가 있는 경우 이 스크립트를 완료하는 데 몇 분 정도 걸릴 수 있습니다. 값이 있는 Microsoft Entra ID 특성이 없고 contains 또는 다른 필터 식을 사용해야 하는 경우 이 스크립트를 사용자 지정하고 다음 11단계에서 다른 필터 식을 사용해야 합니다.

$dbu_not_queried_list = @()
$dbu_not_matched_list = @()
$dbu_match_ambiguous_list = @()
$dbu_query_failed_list = @()
$azuread_match_id_list = @()
$azuread_not_enabled_list = @()
$dbu_values = @()
$dbu_duplicate_list = @()

foreach ($dbu in $dbusers) { 
   if ($null -ne $dbu.$db_match_column_name -and $dbu.$db_match_column_name.Length -gt 0) { 
      $val = $dbu.$db_match_column_name
      $escval = $val -replace "'","''"
      if ($dbu_values -contains $escval) { $dbu_duplicate_list += $dbu; continue } else { $dbu_values += $escval }
      $filter = $azuread_match_attr_name + " eq '" + $escval + "'"
      try {
         $ul = @(Get-MgUser -Filter $filter -All -Property Id,accountEnabled -ErrorAction Stop)
         if ($ul.length -eq 0) { $dbu_not_matched_list += $dbu; } elseif ($ul.length -gt 1) {$dbu_match_ambiguous_list += $dbu } else {
            $id = $ul[0].id; 
            $azuread_match_id_list += $id;
            if ($ul[0].accountEnabled -eq $false) {$azuread_not_enabled_list += $id }
         } 
      } catch { $dbu_query_failed_list += $dbu } 
    } else { $dbu_not_queried_list += $dbu }
}

이전 쿼리의 결과를 봅니다. 오류 또는 누락된 일치 항목으로 인해 SAP Cloud Identity Services, 데이터베이스 또는 디렉터리의 사용자를 Microsoft Entra ID에 배치할 수 없는지 확인합니다.

다음 PowerShell 스크립트에 찾지 못한 레코드 수가 표시됩니다.

$dbu_not_queried_count = $dbu_not_queried_list.Count
if ($dbu_not_queried_count -ne 0) {
  Write-Error "Unable to query for $dbu_not_queried_count records as rows lacked values for $db_match_column_name."
}
$dbu_duplicate_count = $dbu_duplicate_list.Count
if ($dbu_duplicate_count -ne 0) {
  Write-Error "Unable to locate Microsoft Entra ID users for $dbu_duplicate_count rows as multiple rows have the same value"
}
$dbu_not_matched_count = $dbu_not_matched_list.Count
if ($dbu_not_matched_count -ne 0) {
  Write-Error "Unable to locate $dbu_not_matched_count records in Microsoft Entra ID by querying for $db_match_column_name values in $azuread_match_attr_name."
}
$dbu_match_ambiguous_count = $dbu_match_ambiguous_list.Count
if ($dbu_match_ambiguous_count -ne 0) {
  Write-Error "Unable to locate $dbu_match_ambiguous_count records in Microsoft Entra ID as attribute match ambiguous."
}
$dbu_query_failed_count = $dbu_query_failed_list.Count
if ($dbu_query_failed_count -ne 0) {
  Write-Error "Unable to locate $dbu_query_failed_count records in Microsoft Entra ID as queries returned errors."
}
$azuread_not_enabled_count = $azuread_not_enabled_list.Count
if ($azuread_not_enabled_count -ne 0) {
 Write-Error "$azuread_not_enabled_count users in Microsoft Entra ID are blocked from sign-in."
}
if ($dbu_not_queried_count -ne 0 -or $dbu_duplicate_count -ne 0 -or $dbu_not_matched_count -ne 0 -or $dbu_match_ambiguous_count -ne 0 -or $dbu_query_failed_count -ne 0 -or $azuread_not_enabled_count) {
 Write-Output "You will need to resolve those issues before access of all existing users can be reviewed."
}
$azuread_match_count = $azuread_match_id_list.Count
Write-Output "Users corresponding to $azuread_match_count records were located in Microsoft Entra ID."

스크립트가 완료되면 데이터 원본의 레코드가 Microsoft Entra ID에 없는 경우 오류가 표시됩니다. 애플리케이션 데이터 저장소의 사용자에 대한 모든 레코드를 Microsoft Entra ID의 사용자로 찾을 수 없는 경우 일치하지 않는 레코드와 그 이유를 조사해야 합니다.

예를 들어, 애플리케이션의 데이터 원본에서 해당 mail 속성이 업데이트되지 않은 상태에서 누군가의 이메일 주소와 userPrincipalName이 Microsoft Entra ID에서 변경되었을 수 있습니다. 또는 사용자가 이미 조직을 떠났지만 여전히 애플리케이션의 데이터 원본에 있을 수 있습니다. 또는 Microsoft Entra ID의 특정 개인과 일치하지 않는 애플리케이션의 데이터 원본에 공급업체 또는 최고 관리자 계정이 있을 수 있습니다.
Microsoft Entra ID에 위치할 수 없거나 활성 상태이며 로그인할 수 없는 사용자가 있지만 SAP Cloud Identity Services, 데이터베이스 또는 디렉터리에서 해당 액세스 권한을 검토하거나 해당 특성을 업데이트하려는 경우 애플리케이션, 일치 규칙을 업데이트하거나 Microsoft Entra 사용자를 업데이트하거나 만들어야 합니다. 변경할 내용 에 대한 자세한 내용은 Microsoft Entra ID의 사용자와 일치하지 않는 애플리케이션의 매핑 및 사용자 계정 관리를 참조하세요.

Microsoft Entra ID에서 사용자를 만드는 옵션을 선택하는 경우 다음 중 하나를 사용하여 사용자를 대량으로 만들 수 있습니다.
- CSV 파일(Microsoft Entra 관리 센터에서 사용자 대량 만들기에 설명됨)
- New-MgUser cmdlet
이러한 새 사용자가 나중에 애플리케이션의 기존 사용자와 일치하도록 Microsoft Entra ID에 필요한 특성과 userPrincipalName, mailNickname 및 displayName을 포함하여 Microsoft Entra ID에 필요한 특성으로 채워졌는지 확인합니다. userPrincipalName은 디렉터리의 모든 사용자 중에서 고유해야 합니다.

예를 들어 이름이 지정된 EMail 열의 값이 Microsoft Entra 사용자 계정 이름으로 사용할 값이고, 열의 값에 Microsoft Entra ID 메일 애칭이 포함되고, 열 AliasFull name 의 값에 사용자의 표시 이름이 포함된 데이터베이스에 사용자가 있을 수 있습니다.
```
$db_display_name_column_name = "Full name"
$db_user_principal_name_column_name = "Email"
$db_mail_nickname_column_name = "Alias"
```
그런 다음 이 스크립트를 사용하여 MICROSOFT Entra ID의 사용자와 일치하지 않는 SAP Cloud Identity Services, 데이터베이스 또는 디렉터리에 있는 사용자를 위한 Microsoft Entra 사용자를 만들 수 있습니다. 조직에 필요한 Microsoft Entra 특성을 추가하거나 $azuread_match_attr_name이 mailNickname도 아니고 userPrincipalName도 아닌 경우 해당 Microsoft Entra 특성을 제공하려면 이 스크립트를 수정해야 할 수도 있습니다.
```
$dbu_missing_columns_list = @()
$dbu_creation_failed_list = @()
foreach ($dbu in $dbu_not_matched_list) {
   if (($null -ne $dbu.$db_display_name_column_name -and $dbu.$db_display_name_column_name.Length -gt 0) -and
       ($null -ne $dbu.$db_user_principal_name_column_name -and $dbu.$db_user_principal_name_column_name.Length -gt 0) -and
       ($null -ne $dbu.$db_mail_nickname_column_name -and $dbu.$db_mail_nickname_column_name.Length -gt 0)) {
      $params = @{
         accountEnabled = $false
         displayName = $dbu.$db_display_name_column_name
         mailNickname = $dbu.$db_mail_nickname_column_name
         userPrincipalName = $dbu.$db_user_principal_name_column_name
         passwordProfile = @{
           Password = -join (((48..90) + (96..122)) * 16 | Get-Random -Count 16 | % {[char]$_})
         }
      }
      try {
        New-MgUser -BodyParameter $params
      } catch { $dbu_creation_failed_list += $dbu; throw }
   } else {
      $dbu_missing_columns_list += $dbu
   }
}
```

누락된 사용자를 Microsoft Entra ID에 추가한 후 7단계에서 스크립트를 다시 실행합니다. 그런 다음, 8단계에서 스크립트를 실행합니다. 오류가 보고되지 않는지 확인합니다.

$dbu_not_queried_list = @()
$dbu_not_matched_list = @()
$dbu_match_ambiguous_list = @()
$dbu_query_failed_list = @()
$azuread_match_id_list = @()
$azuread_not_enabled_list = @()
$dbu_values = @()
$dbu_duplicate_list = @()

foreach ($dbu in $dbusers) { 
   if ($null -ne $dbu.$db_match_column_name -and $dbu.$db_match_column_name.Length -gt 0) { 
      $val = $dbu.$db_match_column_name
      $escval = $val -replace "'","''"
      if ($dbu_values -contains $escval) { $dbu_duplicate_list += $dbu; continue } else { $dbu_values += $escval }
      $filter = $azuread_match_attr_name + " eq '" + $escval + "'"
      try {
         $ul = @(Get-MgUser -Filter $filter -All -Property Id,accountEnabled -ErrorAction Stop)
         if ($ul.length -eq 0) { $dbu_not_matched_list += $dbu; } elseif ($ul.length -gt 1) {$dbu_match_ambiguous_list += $dbu } else {
            $id = $ul[0].id; 
            $azuread_match_id_list += $id;
            if ($ul[0].accountEnabled -eq $false) {$azuread_not_enabled_list += $id }
         } 
      } catch { $dbu_query_failed_list += $dbu } 
    } else { $dbu_not_queried_list += $dbu }
}

$dbu_not_queried_count = $dbu_not_queried_list.Count
if ($dbu_not_queried_count -ne 0) {
  Write-Error "Unable to query for $dbu_not_queried_count records as rows lacked values for $db_match_column_name."
}
$dbu_duplicate_count = $dbu_duplicate_list.Count
if ($dbu_duplicate_count -ne 0) {
  Write-Error "Unable to locate Microsoft Entra ID users for $dbu_duplicate_count rows as multiple rows have the same value"
}
$dbu_not_matched_count = $dbu_not_matched_list.Count
if ($dbu_not_matched_count -ne 0) {
  Write-Error "Unable to locate $dbu_not_matched_count records in Microsoft Entra ID by querying for $db_match_column_name values in $azuread_match_attr_name."
}
$dbu_match_ambiguous_count = $dbu_match_ambiguous_list.Count
if ($dbu_match_ambiguous_count -ne 0) {
  Write-Error "Unable to locate $dbu_match_ambiguous_count records in Microsoft Entra ID as attribute match ambiguous."
}
$dbu_query_failed_count = $dbu_query_failed_list.Count
if ($dbu_query_failed_count -ne 0) {
  Write-Error "Unable to locate $dbu_query_failed_count records in Microsoft Entra ID as queries returned errors."
}
$azuread_not_enabled_count = $azuread_not_enabled_list.Count
if ($azuread_not_enabled_count -ne 0) {
 Write-Warning "$azuread_not_enabled_count users in Microsoft Entra ID are blocked from sign-in."
}
if ($dbu_not_queried_count -ne 0 -or $dbu_duplicate_count -ne 0 -or $dbu_not_matched_count -ne 0 -or $dbu_match_ambiguous_count -ne 0 -or $dbu_query_failed_count -ne 0 -or $azuread_not_enabled_count -ne 0) {
 Write-Output "You will need to resolve those issues before access of all existing users can be reviewed."
}
$azuread_match_count = $azuread_match_id_list.Count
Write-Output "Users corresponding to $azuread_match_count records were located in Microsoft Entra ID."

응용 프로그램 등록

애플리케이션이 이미 Microsoft Entra ID에 등록되어 있으면 다음 단계를 계속 진행합니다.

애플리케이션이 LDAP 디렉터리를 사용하는 경우 사용자를 LDAP 디렉터리에 프로비전하도록 Microsoft Entra ID 구성 가이드 섹션에 따라 Microsoft Entra ID에서 온-프레미스 ECMA 앱에 대한 새 등록을 만듭니다.
애플리케이션이 SQL 데이터베이스를 사용하는 경우 사용자를 SQL 기반 애플리케이션으로 프로비전하도록 Microsoft Entra ID 구성 가이드 섹션에 따라 Microsoft Entra ID에서 온-프레미스 ECMA 앱에 대한 새 등록을 만듭니다.
SAP Cloud Identity Services를 사용하는 경우 사용자를 SAP Cloud Identity Services에 프로비전하도록 Microsoft Entra ID를 구성하는 가이드에 따릅니다.
SCIM 프로토콜을 지원하는 클라우드 애플리케이션인 경우 애플리케이션 갤러리에서 애플리케이션을 추가할 수 있습니다.
애플리케이션이 온-프레미스이고 SCIM 프로토콜을 지원하는 경우 Microsoft Entra ID를 구성하여 온-프레미스 SCIM 기반 애플리케이션에 사용자를 프로비전하기 위한 가이드를 따릅니다.

애플리케이션에 아직 할당되지 않은 사용자 확인

이전 단계에서는 애플리케이션의 데이터 저장소에 있는 모든 사용자가 Microsoft Entra ID에 사용자로 있음을 확인했습니다. 그러나 현재 Microsoft Entra ID의 애플리케이션 역할에 모두 할당되어 있지 않을 수 있습니다. 따라서 다음 단계는 애플리케이션 역할에 대한 할당이 없는 사용자를 확인하는 것입니다.

애플리케이션의 서비스 사용자에 대한 서비스 사용자 ID를 찾습니다. 최근에 LDAP 디렉터리 또는 SQL 데이터베이스를 사용하는 애플리케이션에 대한 서비스 주체를 만든 경우 해당 서비스 주체의 이름을 사용합니다.

예를 들어 엔터프라이즈 애플리케이션 이름이 CORPDB1이면 다음 명령을 입력합니다.
```
$azuread_app_name = "CORPDB1"
$azuread_sp_filter = "displayName eq '" + ($azuread_app_name -replace "'","''") + "'"
$azuread_sp = Get-MgServicePrincipal -Filter $azuread_sp_filter -All
```
현재 애플리케이션에 할당된 사용자를 Microsoft Entra ID에서 검색합니다.

이는 이전 명령에서 설정된 $azuread_sp 변수를 기반으로 합니다.
```
$azuread_existing_assignments = @(Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $azuread_sp.Id -All)
```
이전 섹션의 사용자 ID 목록을 현재 애플리케이션에 할당된 사용자와 비교합니다.
```
$azuread_not_in_role_list = @()
foreach ($id in $azuread_match_id_list) {
   $found = $false
   foreach ($existing in $azuread_existing_assignments) {
      if ($existing.principalId -eq $id) {
         $found = $true; break;
      }
   }
   if ($found -eq $false) { $azuread_not_in_role_list += $id }
}
$azuread_not_in_role_count = $azuread_not_in_role_list.Count
Write-Output "$azuread_not_in_role_count users in the application's data store are not assigned to the application roles."
```
애플리케이션 역할에 할당되지 않은 사용자가 0명인 경우 이는 모든 사용자가 애플리케이션 역할에 할당된 것이며 액세스 검토를 수행하기 전에 추가 변경이 필요하지 않습니다.

그러나 현재 애플리케이션 역할에 할당되지 않은 사용자가 한 명 이상이면 절차를 계속 진행하여 애플리케이션 역할 중 하나에 추가해야 합니다.
나머지 사용자를 할당할 애플리케이션의 역할을 선택합니다.

애플리케이션에는 둘 이상의 역할이 있을 수 있으며 서비스 주체에는 추가 역할이 있을 수 있습니다. 이 명령을 사용하여 서비스 주체의 사용 가능한 역할을 나열합니다.
```
$azuread_sp.AppRoles | where-object {$_.AllowedMemberTypes -contains "User"} | ft DisplayName,Id
```
목록에서 적절한 역할을 선택하고 해당 역할 ID를 가져옵니다. 예를 들어 역할 이름이 Admin이면 다음 PowerShell 명령에 해당 값을 제공합니다.
```
$azuread_app_role_name = "Admin"
$azuread_app_role_id = ($azuread_sp.AppRoles | where-object {$_.AllowedMemberTypes -contains "User" -and $_.DisplayName -eq $azuread_app_role_name}).Id
if ($null -eq $azuread_app_role_id) { write-error "role $azuread_app_role_name not located in application manifest"}
```

애플리케이션 프로비전 구성

애플리케이션이 LDAP 디렉터리, SQL 데이터베이스, SAP Cloud Identity Services 또는 SCIM을 지원하는 경우 새 할당을 만들기 전에 애플리케이션에 대한 Microsoft Entra 사용자의 프로비저닝을 구성합니다. 할당을 만들기 전에 프로비전을 구성하면 Microsoft Entra ID가 Microsoft Entra ID의 사용자를 애플리케이션의 데이터 저장소에 이미 있는 사용자에 대한 애플리케이션 역할 할당과 일치시킬 수 있습니다. 애플리케이션에 프로비전할 온-프레미스 디렉터리 또는 데이터베이스가 있고 페더레이션 SSO도 지원하는 경우 디렉터리에서 애플리케이션을 나타내기 위해 두 개의 서비스 주체(프로비전용 및 SSO용)가 필요할 수 있습니다. 애플리케이션이 프로비전을 지원하지 않는 경우 다음 섹션에서 계속 읽으세요.

애플리케이션이 선택한 사용자만 애플리케이션에 프로비전되도록 사용자에게 애플리케이션 역할 할당을 요구하게끔 구성되어 있는지 확인합니다.
애플리케이션에 프로비전이 구성되지 않은 경우 지금 프로비전을 구성합니다(하지만 프로비전을 시작하지 않음).
- 애플리케이션에서 LDAP 디렉터리를 사용하는 경우 사용자를 LDAP 디렉터리로 프로비전하도록 Microsoft Entra ID를 구성하는 가이드를 따릅니다.
- 애플리케이션에서 SQL 데이터베이스를 사용하는 경우 사용자를 SQL 기반 애플리케이션으로 프로비전하도록 Microsoft Entra ID를 구성하는 가이드를 따릅니다.
- 애플리케이션에서 SAP Cloud Identity Services를 사용하는 경우 사용자를 SAP Cloud Identity Services로 프로비전하도록 Microsoft Entra ID를 구성하는 가이드에 따릅니다.
- 다른 애플리케이션의 경우 1-3단계에 따라 Graph API를 통해 프로비저닝을 구성합니다.
애플리케이션의 속성 탭을 확인합니다. 사용자 할당이 필요한가요? 옵션이 예로 설정되어 있는지 확인합니다. 아니요로 설정되면 외부 ID를 포함하여 디렉터리의 모든 사용자가 애플리케이션에 액세스할 수 있지만 애플리케이션에 대한 액세스는 검토할 수 없습니다.
해당 애플리케이션에 프로비전하기 위한 특성 매핑을 확인합니다. 이전 섹션에서 일치시키는 데 사용한 Microsoft Entra 특성과 열에 이 특성을 사용하여 개체 일치가 설정되어 있는지 확인합니다.

이러한 규칙에서 이전에 사용한 특성과 동일한 특성을 사용하지 않는 경우 애플리케이션 역할 할당이 생성되면 Microsoft Entra ID가 애플리케이션의 데이터 저장소에서 기존 사용자를 찾지 못할 수 있습니다. 그러면, Microsoft Entra ID에서 실수로 중복 사용자를 만들 수 있습니다.
애플리케이션 특성에 대한 isSoftDeleted 특성 매핑이 있는지 확인합니다.

사용자가 애플리케이션에서 할당 해제되거나 Microsoft Entra ID에서 일시 삭제되거나 로그인에서 차단된 경우 Microsoft Entra 프로비전은 isSoftDeleted에 매핑된 특성을 업데이트합니다. 매핑된 특성이 없으면 나중에 애플리케이션 역할에서 할당 해제된 사용자가 애플리케이션의 데이터 저장소에 계속 존재합니다.
애플리케이션에 프로비전이 이미 사용하도록 설정된 경우 애플리케이션 프로비전이 격리되어 있지 않은지 확인합니다. 계속하기 전에 격리를 일으키는 문제를 해결합니다.

Microsoft Entra ID에서 앱 역할 할당 만들기

Microsoft Entra ID가 애플리케이션의 사용자를 Microsoft Entra ID의 사용자와 일치시키려면 Microsoft Entra ID에 애플리케이션 역할 할당을 만들어야 합니다. 각 애플리케이션 역할 할당은 한 사용자를 한 서비스 주체의 한 애플리케이션 역할에 연결합니다.

애플리케이션에 대한 사용자를 위해 Microsoft Entra ID에서 애플리케이션 역할 할당이 만들어지고 애플리케이션이 프로비전을 지원하는 경우:

Microsoft Entra ID는 SCIM 또는 해당 디렉터리나 데이터베이스를 통해 애플리케이션을 쿼리하여 사용자가 이미 있는지 확인합니다.
Microsoft Entra ID에서 사용자의 특성에 대한 후속 업데이트가 이루어지면 Microsoft Entra ID가 해당 업데이트를 애플리케이션에 보냅니다.
사용자는 Microsoft Entra ID 외부에서 업데이트되지 않은 경우 또는 Microsoft Entra ID에서 할당이 제거될 때까지 애플리케이션에 무기한 유지됩니다.
해당 애플리케이션의 역할 할당에 대한 다음 액세스 검토에서 사용자는 액세스 검토에 포함됩니다.
액세스 검토에서 사용자가 거부되면 애플리케이션 역할 할당이 제거됩니다. Microsoft Entra ID에서 사용자가 로그인하지 못하도록 차단되었음을 애플리케이션에 알립니다.

애플리케이션이 프로비전을 지원하지 않는 경우

사용자는 Microsoft Entra ID 외부에서 업데이트되지 않은 경우 또는 Microsoft Entra ID에서 할당이 제거될 때까지 애플리케이션에 무기한 유지됩니다.
사용자는 해당 애플리케이션의 역할 할당에 대한 다음 검토에 포함됩니다.
액세스 검토에서 사용자가 거부되면 애플리케이션 역할 할당이 제거됩니다. 사용자는 더 이상 Microsoft Entra ID에서 애플리케이션에 로그인할 수 없습니다.

현재 역할 할당이 없는 사용자에 대한 애플리케이션 역할 할당을 만듭니다.

foreach ($u in $azuread_not_in_role_list) {
   $res = New-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $azuread_sp.Id -AppRoleId $azuread_app_role_id -PrincipalId $u -ResourceId $azuread_sp.Id 
}

변경 사항이 Microsoft Entra ID 내에 전파되도록 1분 정도 기다립니다.

Microsoft Entra 프로비전이 기존 사용자와 일치하는지 확인

Microsoft Entra ID를 쿼리하여 업데이트된 역할 할당 목록을 가져옵니다.

$azuread_existing_assignments = @(Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $azuread_sp.Id -All)

이전 섹션의 사용자 ID 목록을 현재 애플리케이션에 할당된 사용자와 비교합니다.

$azuread_still_not_in_role_list = @()
foreach ($id in $azuread_match_id_list) {
   $found = $false
   foreach ($existing in $azuread_existing_assignments) {
      if ($existing.principalId -eq $id) {
         $found = $true; break;
      }
   }
   if ($found -eq $false) { $azuread_still_not_in_role_list += $id }
}
$azuread_still_not_in_role_count = $azuread_still_not_in_role_list.Count
if ($azuread_still_not_in_role_count -gt 0) {
   Write-Output "$azuread_still_not_in_role_count users in the application's data store are not assigned to the application roles."
}

애플리케이션 역할에 할당된 사용자가 없는 경우 Microsoft Entra 감사 로그에서 이전 단계의 오류를 확인합니다.

애플리케이션 서비스 주체가 프로비전하도록 구성되어 있고 서비스 주체에 대한 프로비저닝 상태가 해제된 경우 켜기로 설정합니다. Graph API를 사용하여 프로비저닝을 시작할 수도 있습니다.
사용자를 프로비전하는 데 걸리는 기간에 대한 참고 자료에 따라 Microsoft Entra 프로비전이 애플리케이션의 기존 사용자와 방금 할당된 사용자를 일치시킬 때까지 기다립니다.
포털 또는 Graph API를 통해 프로비전 상태를 모니터링하여 모든 사용자가 성공적으로 일치하는지 확인합니다.

프로비전 중인 사용자가 표시되지 않으면 프로비전 중인 사용자가 없음에 대한 문제 해결 가이드를 확인합니다. 프로비전 상태에 오류가 표시되고 온-프레미스 애플리케이션에 프로비전하고 있으면 온-프레미스 애플리케이션 프로비전에 대한 문제 해결 가이드를 확인합니다.
Microsoft Entra 관리 센터 또는 Graph API를 통해 프로비전 로그를 확인합니다. 로그를 실패 상태로 필터링합니다. DuplicateTargetEntries의 ErrorCode와 함께 오류가 발생하는 경우 이는 프로비전 일치 규칙의 모호성을 나타내며 각 Microsoft Entra 사용자가 애플리케이션 사용자 한 명과 일치하도록 일치에 사용되는 Microsoft Entra 사용자나 매핑을 업데이트해야 합니다. 그런 다음, 로그를 작업 만들기 및 건너뜀 상태로 필터링합니다. 사용자가 NotEffectivelyEntitled의 SkipReason 코드를 건너뛴 경우 이는 사용자 계정 상태가 사용 안 함이므로 Microsoft Entra ID 사용자 계정이 일치하지 않음을 나타낼 수 있습니다.

Microsoft Entra 프로비전 서비스가 생성된 애플리케이션 역할 할당에 따라 사용자를 일치시키면 해당 사용자에 대한 이후 변경 사항이 애플리케이션으로 전송됩니다.

적절한 검토자 선택

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

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

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

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

액세스 검토 또는 권한 관리 구성

사용자가 애플리케이션 역할에 있고 검토자가 식별되면 액세스 검토 또는 권한 관리를 사용하여 액세스가 필요한 사용자 및 추가 사용자를 제어할 수 있습니다.

애플리케이션에 단일 애플리케이션 역할만 있는 경우 애플리케이션은 디렉터리의 단일 서비스 주체로 표시되며 추가 사용자가 애플리케이션에 액세스할 필요가 없는 경우 다음 섹션을 계속 진행하여 액세스 검토를 사용하여 기존 액세스를 검토하고 제거합니다.
그렇지 않은 경우 권한 관리를 사용하여 액세스를 제어하려면 이 문서의 섹션을 계속 진행합니다.

앱 역할 할당의 액세스 검토를 사용하여 기존 액세스 검토 및 제거

애플리케이션에 여러 애플리케이션 역할이 있거나, 여러 서비스 주체로 표현되거나, 사용자가 애플리케이션에 대한 액세스를 요청하거나 할당하는 프로세스를 갖도록 하려는 경우 이 문서의 다음 섹션에서 권한 관리를 사용하여 액세스를 제어합니다.

이제 기존 사용자에게 애플리케이션 역할에 대한 할당이 있으므로 해당 할당에 대한 검토를 시작하도록 Microsoft Entra ID를 구성할 수 있습니다.

이 단계에서는 Global administrator 또는 Identity Governance administrator 역할에 있어야 합니다.
그룹 또는 애플리케이션에 대한 액세스 검토 만들기 가이드의 지침에 따라 애플리케이션의 역할 할당에 대한 검토를 만듭니다. 완료되면 결과를 적용하도록 검토를 구성합니다. Id 거버넌스 모듈용 Microsoft Graph PowerShell New-MgIdentityGovernanceAccessReviewDefinition cmdlet의 cmdlet을 사용하여 PowerShell에서 액세스 검토를 만들 수 있습니다. 자세한 내용은 예시를 참조하십시오.

참고 항목

액세스 검토를 만들 때 검토 의사 결정 도우미를 사용하도록 설정하는 경우 의사 결정 도우미 권장 사항은 사용자가 Microsoft Entra ID를 사용하여 애플리케이션에 마지막으로 로그인한 시기에 따라 30일 간격 기간을 기반으로 합니다.
액세스 검토를 시작할 때 입력을 제공하도록 검토자에게 요청합니다. 기본적으로 각 애플리케이션에 대한 액세스를 검토하는 액세스 패널에 대한 링크가 포함된 Microsoft Entra ID에서 전자 메일을 받습니다.
검토가 시작되면 액세스 검토가 완료될 때까지 진행 상황을 모니터링하고 필요한 경우 승인자를 업데이트할 수 있습니다. 그런 다음, 검토자가 액세스가 거부된 사용자의 액세스 권한이 애플리케이션에서 제거되었는지 확인할 수 있습니다.
검토를 만들 때 자동 적용을 선택하지 않은 경우 검토가 완료되면 검토 결과를 적용해야 합니다.
검토 상태가 결과 적용됨으로 변경될 때까지 기다립니다. 거부된 사용자(있는 경우)가 몇 분 안에 해당 애플리케이션 역할 할당이 제거되는 것을 볼 수 있습니다.
결과가 적용되면 Microsoft Entra ID는 애플리케이션에서 거부된 사용자를 프로비전 해제하기 시작합니다. 사용자를 프로비전하는 데 걸리는 기간에 대한 지침에 따라 Microsoft Entra 프로비저닝이 거부된 사용자 프로비저닝 해제를 시작할 때까지 기다립니다. 포털 또는 Graph API를 통해 프로비전 상태 모니터링하여 거부된 모든 사용자가 성공적으로 제거되었는지 확인합니다.

프로비전 해제되는 사용자가 표시되지 않으면 프로비전되지 않는 사용자에 대한 문제 해결 가이드를 검사. 프로비전 상태에 오류가 표시되고 온-프레미스 애플리케이션에 프로비전하고 있으면 온-프레미스 애플리케이션 프로비전에 대한 문제 해결 가이드를 확인합니다.

이제 기존 액세스가 검토되었는지 확인하는 기준이 있으므로 다음 섹션에서 자격 관리를 구성하여 새 액세스 요청을 사용하도록 설정할 수 있습니다.

권한 관리를 사용하여 액세스 제어

각 애플리케이션 역할에 대해 서로 다른 검토자를 두려는 경우, 애플리케이션이 여러 서비스 주체로 표시되거나 사용자가 애플리케이션에 대한 액세스를 요청하거나 할당받는 프로세스를 원하면 각 애플리케이션 역할에 대한 액세스 패키지를 사용하여 Microsoft Entra ID를 구성할 수 있습니다. 각 액세스 패키지에는 해당 액세스 패키지에 대한 할당을 되풀이적으로 검토하는 정책이 있을 수 있습니다. 액세스 패키지 및 정책이 만들어지면 액세스 패키지에 기존 애플리케이션 역할 할당이 있는 사용자를 할당하여 액세스 패키지를 통해 할당을 검토할 수 있습니다.

이 섹션에서는 앱 역할 할당이 포함된 액세스 패키지 할당을 검토하도록 Microsoft Entra 권한 관리를 구성하고 사용자가 애플리케이션의 역할에 대한 액세스를 요청할 수 있도록 추가 정책을 구성합니다.

이 단계에서는 또는 역할에 있거나 Global administrator 카탈로그 작성자 및 애플리케이션 소유자로 위임되어야 Identity Governance administrator 합니다.
애플리케이션 거버넌스 시나리오에 대한 카탈로그가 아직 없는 경우 Microsoft Entra 권한 관리에서 카탈로그를 만듭니다. PowerShell 스크립트를 사용하여 각 카탈로그를 만들 수 있습니다.
애플리케이션 및 애플리케이션이 사용하는 모든 Microsoft Entra 그룹을 해당 카탈로그의 리소스로 추가하여 필요한 리소스로 카탈로그를 채웁니다. PowerShell 스크립트를 사용하여 카탈로그에 각 리소스를 추가할 수 있습니다.
각 애플리케이션 및 해당 애플리케이션 역할 또는 그룹에 대해 해당 역할 또는 그룹을 리소스로 포함하는 액세스 패키지를 만듭니다. 이러한 액세스 패키지를 구성하는 이 단계에서는 각 액세스 패키지의 첫 번째 액세스 패키지 할당 정책을 직접 할당에 대한 정책으로 구성하여 관리자만 해당 정책을 할당하고 기존 사용자에 대한 액세스 검토 요구 사항을 설정하여 무기한 액세스를 유지하지 않도록 합니다. 액세스 패키지가 많은 경우 PowerShell 스크립트 를 사용하여 카탈로그에 각 액세스 패키지를 만들 수 있습니다.
각 액세스 패키지에 대해 해당 역할의 애플리케이션의 기존 사용자 또는 해당 그룹의 멤버를 액세스 패키지 및 직접 할당 정책에 할당합니다. Microsoft Entra 관리 센터를 사용하거나 Graph 또는 PowerShell을 통해 대량으로 액세스 패키지에 사용자를 직접 할당할 수 있습니다.
액세스 패키지 할당 정책에서 액세스 검토를 구성한 경우 액세스 검토가 시작되면 검토자에게 입력을 요청합니다. 기본적으로 각 사용자는 액세스 패널에 대한 링크가 있는 Microsoft Entra ID에서 전자 메일을 받으며, 여기서 액세스 패키지 할당을 검토합니다. 검토가 완료되면 몇 분 안에 애플리케이션 역할 할당이 제거되는 거부된 사용자(있는 경우)가 표시되어야 합니다. 이후에 Microsoft Entra ID는 애플리케이션에서 거부된 사용자를 프로비전 해제하기 시작합니다. 사용자를 프로비전하는 데 걸리는 기간에 대한 지침에 따라 Microsoft Entra 프로비저닝이 거부된 사용자 프로비저닝 해제를 시작할 때까지 기다립니다. 포털 또는 Graph API를 통해 프로비전 상태 모니터링하여 거부된 모든 사용자가 성공적으로 제거되었는지 확인합니다.
의무 분리 요구 사항이 있는 경우 액세스 패키지에 대해 호환되지 않는 액세스 패키지 또는 기존 그룹을 구성합니다. 시나리오에서 의무 분리 검사를 재정의하는 기능을 요구하는 경우 이러한 재정의 시나리오에 대한 추가 액세스 패키지를 설정할 수도 있습니다.
액세스 권한을 아직 요청하지 않은 사용자를 허용하려면 각 액세스 패키지 에서 사용자가 액세스를 요청할 수 있도록 추가 액세스 패키지 할당 정책을 만듭니다. 해당 정책에서 승인 및 반복 액세스 검토 요구 사항을 구성합니다.