다음을 통해 공유


Microsoft Defender for Identity에 대한 디렉터리 서비스 계정

이 문서에서는 Id용 Microsoft Defender에서 DSA(디렉터리 서비스 계정)를 사용하는 방법을 설명합니다.

일부 시나리오에서는 DSA가 선택 사항이지만 전체 보안 범위를 위해 Defender for Identity용 DSA를 구성하는 것이 좋습니다.

예를 들어 DSA를 구성한 경우 DSA를 사용하여 시작할 때 도메인 컨트롤러에 연결합니다. DSA를 사용하여 네트워크 트래픽, 모니터링된 이벤트 및 모니터링된 ETW 활동에 표시되는 엔터티에 대한 데이터를 도메인 컨트롤러에 쿼리할 수도 있습니다.

DSA는 다음 기능과 기능에 필요합니다.

  • AD FS/AD CS 서버에 설치된 센서로 작업하는 경우

  • 디바이스에 대한 SAM-R 호출을 통해 네트워크 트래픽, 이벤트 및 ETW 활동에 표시되는 디바이스에서 로컬 관리자 그룹에 대한 멤버 목록을 요청합니다. 수집된 데이터는 잠재적인 횡적 이동 경로를 계산하는 데 사용됩니다.

  • DeletedObjects 컨테이너에 액세스하여 삭제된 사용자 및 컴퓨터에 대한 정보를 수집합니다.

  • 센서 시작 시 그리고 10분마다 다시 발생하는 도메인 및 신뢰 매핑입니다.

  • 다른 도메인의 엔터티에서 활동을 검색할 때 LDAP를 통해 다른 도메인을 쿼리하여 세부 정보를 검색합니다.

단일 DSA를 사용하는 경우 DSA에는 포리스트의 모든 도메인에 대한 읽기 권한이 있어야 합니다. 신뢰할 수 없는 다중 포리스트 환경에서는 각 포리스트에 DSA 계정이 필요합니다.

각 도메인의 한 센서는 도메인 동기화 장치정의되며 도메인의 엔터티에 대한 변경 내용을 추적합니다. 예를 들어 변경 내용에는 생성된 개체, Defender for Identity에서 추적하는 엔터티 특성 등이 포함될 수 있습니다.

참고 항목

기본적으로 Defender for Identity는 최대 30개의 자격 증명을 지원합니다. 자격 증명을 더 추가하려면 Defender for Identity 지원에 문의하세요.

지원되는 DSA 계정 옵션

Defender for Identity는 다음 DSA 옵션을 지원합니다.

옵션 설명 구성
그룹 관리 서비스 계정 gMSA (권장) 보다 안전한 배포 및 암호 관리를 제공합니다. Active Directory는 컴퓨터 계정의 암호와 마찬가지로 계정 암호의 생성 및 회전을 관리하며 계정의 암호가 변경되는 빈도를 제어할 수 있습니다. 자세한 내용은 gMSA를 사용하여 Defender for Identity에 대한 디렉터리 서비스 계정 구성을 참조하세요.
일반 사용자 계정 시작할 때 사용하기 쉽고 신뢰할 수 있는 포리스트 간에 읽기 권한을 더 간단하게 구성할 수 있지만 암호 관리에 추가 오버헤드가 필요합니다.

일반 사용자 계정은 암호를 만들고 관리해야 하므로 보안이 떨어지며, 암호가 만료되고 사용자와 DSA 모두에 대해 업데이트되지 않는 경우 가동 중지 시간이 발생할 수 있습니다.
DeletedObjects 컨테이너에 대한 권한을 포함하여 모든 개체에 대한 읽기 권한이 있는 DSA로 사용할 새 계정을 Active Directory에 만듭니다. 자세한 내용은 필요한 DSA 권한 부여를 참조 하세요.
로컬 서비스 계정 로컬 서비스 계정은 기본적으로 사용되며 DSA가 구성되지 않은 경우 기본적으로 사용됩니다.
참고:
  • SAM-R은 이 시나리오에서 지원되지 않는 잠재적인 횡적 이동 경로에 대해 쿼리합니다.
  • LDAP는 센서가 설치된 도메인 내에서만 쿼리합니다. 동일한 포리스트 또는 크로스 포리스트의 다른 도메인에 대한 쿼리가 실패합니다.
  • None

    참고 항목

    로컬 서비스 계정은 기본적으로 센서와 함께 사용되며 일부 시나리오에서는 DSA가 선택 사항이지만 전체 보안 범위를 위해 Defender for Identity용 DSA를 구성하는 것이 좋습니다.

    DSA 항목 사용

    이 섹션에서는 DSA 항목이 사용되는 방법과 센서가 지정된 시나리오에서 DSA 항목을 선택하는 방법을 설명합니다. 센서 시도는 DSA 항목 유형에 따라 다릅니다.

    Type 설명
    gMSA 계정 센서는 Active Directory에서 gMSA 계정 암호를 검색한 다음 도메인에 로그인합니다.
    일반 사용자 계정 센서는 구성된 사용자 이름 및 암호를 사용하여 도메인에 로그인하려고 시도합니다.

    다음 논리가 적용됩니다.

    1. 센서는 대상 도메인의 도메인 이름과 정확히 일치하는 항목을 찾습니다. 정확히 일치하는 항목이 발견되면 센서는 해당 항목의 자격 증명을 사용하여 인증을 시도합니다.

    2. 정확히 일치하는 항목이 없거나 인증에 실패한 경우 센서는 DNS FQDN을 사용하여 상위 도메인에 대한 항목을 검색하고 대신 부모 항목의 자격 증명을 사용하여 인증을 시도합니다.

    3. 부모 도메인에 대한 항목이 없거나 인증에 실패한 경우 센서는 DNS FQDN을 사용하여 형제 도메인 항목 목록을 검색하고 대신 형제 항목의 자격 증명을 사용하여 인증을 시도합니다.

    4. 형제 도메인에 대한 항목이 없거나 인증에 실패한 경우 센서는 목록을 다시 검토하고 성공할 때까지 각 항목으로 다시 인증을 시도합니다. DSA gMSA 항목은 일반 DSA 항목보다 우선 순위가 높습니다.

    DSA를 사용하는 샘플 논리

    이 섹션에서는 gMSA 계정과 일반 계정을 포함하여 여러 계정이 있는 경우 센서가 DSA 전체를 시도하는 방법의 예를 제공합니다.

    다음 논리가 적용됩니다.

    1. 센서는 대상 도메인의 DNS 도메인 이름(예: emea.contoso.com DSA gMSA 항목 emea.contoso.com)과 같은 일치 항목을 찾습니다.

    2. 센서는 대상 도메인의 DNS 도메인 이름(예: emea.contoso.com DSA 일반 항목 DSA)과 일치하는 항목을 찾습니다. emea.contoso.com

    3. 센서는 대상 도메인의 루트 DNS 이름(예: emea.contoso.com DSA gMSA 항목 도메인 이름) contoso.com에서 일치 항목을 찾습니다.

    4. 센서는 대상 도메인의 루트 DNS 이름(예: emea.contoso.com DSA 일반 항목 도메인 이름 contoso.com)에서 일치 항목을 찾습니다.

    5. 센서는 형제 도메인의 대상 도메인 이름(예: emea.contoso.com DSA gMSA 항목 도메인 이름) apac.contoso.com을 찾습니다.

    6. 센서는 형제 도메인의 대상 도메인 이름(예: emea.contoso.com DSA 일반 항목 도메인 이름) apac.contoso.com을 찾습니다.

    7. 센서는 모든 DSA gMSA 항목의 라운드 로빈을 실행합니다.

    8. 센서는 모든 DSA 일반 항목의 라운드 로빈을 실행합니다.

    이 예제에 표시된 논리는 다음 구성으로 구현됩니다.

    • DSA 항목:

      • DSA1.emea.contoso.com
      • DSA2.fabrikam.com
    • 먼저 사용되는 센서 및 DSA 항목:

      도메인 컨트롤러 FQDN 사용된 DSA 항목
      DC01.emea.contoso.com DSA1.emea.contoso.com
      DC02.contoso.com DSA1.emea.contoso.com
      DC03.fabrikam.com DSA2.fabrikam.com
      DC04.contoso.local 라운드 로빈

    Important

    시작 시 센서가 LDAP를 통해 Active Directory 도메인에 성공적으로 인증할 수 없는 경우 센서가 실행 중 상태가 되지 않고 상태 문제가 생성됩니다. 자세한 내용은 Defender for Identity 상태 문제를 참조하세요.

    필요한 DSA 권한 부여

    DSA에는 삭제된 개체 컨테이너를 포함하여 Active Directory의 모든 개체에 대한 읽기 전용 권한이 필요합니다.

    삭제된 개체 컨테이너에 대한 읽기 전용 권한을 사용하면 Defender for Identity가 Active Directory에서 사용자 삭제를 검색할 수 있습니다.

    다음 코드 샘플을 사용하여 gMSA 계정을 사용하는지 여부에 관계없이 지운 개체 컨테이너에 필요한 읽기 권한을 부여할 수 있습니다.

    권한을 부여하려는 DSA가 gMSA(그룹 관리 서비스 계정)인 경우 먼저 보안 그룹을 만들고, gMSA를 멤버로 추가하고, 해당 그룹에 권한을 추가해야 합니다. 자세한 내용은 gMSA를 사용하여 Defender for Identity에 대한 디렉터리 서비스 계정 구성을 참조하세요.

    # Declare the identity that you want to add read access to the deleted objects container:
    $Identity = 'mdiSvc01'
    
    # If the identity is a gMSA, first to create a group and add the gMSA to it:
    $groupName = 'mdiUsr01Group'
    $groupDescription = 'Members of this group are allowed to read the objects in the Deleted Objects container in AD'
    if(Get-ADServiceAccount -Identity $Identity -ErrorAction SilentlyContinue) {
        $groupParams = @{
            Name           = $groupName
            SamAccountName = $groupName
            DisplayName    = $groupName
            GroupCategory  = 'Security'
            GroupScope     = 'Universal'
            Description    = $groupDescription
        }
        $group = New-ADGroup @groupParams -PassThru
        Add-ADGroupMember -Identity $group -Members ('{0}$' -f $Identity)
        $Identity = $group.Name
    }
    
    # Get the deleted objects container's distinguished name:
    $distinguishedName = ([adsi]'').distinguishedName.Value
    $deletedObjectsDN = 'CN=Deleted Objects,{0}' -f $distinguishedName
    
    # Take ownership on the deleted objects container:
    $params = @("$deletedObjectsDN", '/takeOwnership')
    C:\Windows\System32\dsacls.exe $params
    
    # Grant the 'List Contents' and 'Read Property' permissions to the user or group:
    $params = @("$deletedObjectsDN", '/G', ('{0}\{1}:LCRP' -f ([adsi]'').name.Value, $Identity))
    C:\Windows\System32\dsacls.exe $params
      
    # To remove the permissions, uncomment the next 2 lines and run them instead of the two prior ones:
    # $params = @("$deletedObjectsDN", '/R', ('{0}\{1}' -f ([adsi]'').name.Value, $Identity))
    # C:\Windows\System32\dsacls.exe $params
    

    자세한 내용은 삭제된 개체 컨테이너에 대한 권한 변경을 참조 하세요.

    PowerShell을 통해 DSA 권한 및 위임 테스트

    다음 PowerShell 명령을 사용하여 DSA에 강력한 관리자 권한과 같은 권한이 너무 많지 않은지 확인합니다.

    Test-MDIDSA [-Identity] <String> [-Detailed] [<CommonParameters>]
    

    예를 들어 mdiSvc01 계정에 대한 권한을 확인하고 전체 세부 정보를 제공하려면 다음을 실행합니다.

    Test-MDIDSA -Identity "mdiSvc01" -Detailed
    

    자세한 내용은 DefenderForIdentity PowerShell 참조를 참조하세요.

    다음 단계