다음을 통해 공유

JEA 보안 고려 사항

  • 아티클

JEA를 사용하면 컴퓨터의 영구 관리자 수를 줄여 보안 상태를 개선할 수 있습니다. JEA는 PowerShell 세션 구성을 사용하여 시스템을 관리할 수 있는 사용자에 대한 새 진입점을 만듭니다. 관리 작업을 수행하기 위해 머신에 대한 상승된(그러나 제한되지는 않은) 액세스 권한이 필요한 사용자에게 JEA 엔드포인트에 대한 액세스 권한을 부여할 수 있습니다. JEA를 사용하면 이러한 사용자가 전체 관리자 액세스 권한 없이 관리 명령을 실행할 수 있으므로 권한이 높은 보안 그룹에서 해당 사용자를 제거할 수 있습니다.

실행 계정

각 JEA 엔드포인트에는 연결된 사용자의 작업이 실행되는 지정된 실행 계정이 있습니다. 이 계정은 세션 구성 파일에서 구성할 수 있으며 선택한 계정은 엔드포인트의 보안에 상당한 영향을 줍니다.

가상 계정은 실행 계정을 구성하는 권장 방법입니다. 가상 계정은 연결하는 사용자가 JEA 세션 기간 동안 사용하도록 만들어지는 일회성 임시 로컬 계정입니다. 세션이 종료되는 즉시 가상 계정이 삭제되고 더 이상 사용할 수 없습니다. 연결하는 사용자는 가상 계정에 대한 자격 증명을 모릅니다. 가상 계정은 원격 데스크톱 또는 제약이 없는 PowerShell 엔드포인트와 같은 다른 수단을 통해 시스템에 액세스하는 데 사용할 수 없습니다.

기본적으로 가상 계정은 컴퓨터의 로컬 관리istrators 그룹의 구성원입니다. 이 멤버 자격은 시스템의 모든 항목을 관리할 수 있는 모든 권한을 부여하지만 네트워크에서 리소스를 관리할 수 있는 권한은 없습니다. 사용자가 JEA 세션에서 다른 컴퓨터에 연결하는 경우 사용자 컨텍스트는 가상 계정이 아닌 로컬 컴퓨터 계정의 컨텍스트입니다.

할기본 컨트롤러는 로컬 관리istrators 그룹이 없으므로 특별한 경우입니다. 대신 가상 계정은 Do기본 관리에 속하며 do기본 컨트롤러에서 디렉터리 서비스를 관리할 수 있습니다. do기본 ID는 JEA 세션이 인스턴스화된 do기본 컨트롤러에서 계속 사용하도록 제한됩니다. 모든 네트워크 액세스는 대신 do기본 컨트롤러 컴퓨터 개체에서 제공되는 것으로 보입니다.

두 경우 모두 특정 보안 그룹에 가상 계정을 할당할 수 있습니다. 특히 로컬 또는 기본 관리자 권한 없이 작업을 수행할 수 있는 경우입니다. 관리자에 대해 정의된 보안 그룹이 이미 있는 경우 해당 그룹에 가상 계정 멤버 자격을 부여합니다. 가상 계정의 그룹 멤버 자격은 워크스테이션 및 멤버 서버의 로컬 보안 그룹으로 제한됩니다. do기본 컨트롤러에서 가상 계정은 할 일기본 보안 그룹의 구성원이어야 합니다. 가상 계정이 하나 이상의 보안 그룹에 추가되면 더 이상 기본 그룹(로컬 또는 할기본 관리자)에 속하지 않습니다.

다음 표에는 가상 계정에 대한 가능한 구성 옵션 및 결과 사용 권한이 요약되어 있습니다.

컴퓨터 유형 가상 계정 그룹 구성 로컬 사용자 컨텍스트 네트워크 사용자 컨텍스트
도메인 컨트롤러 기본값 Do기본 user, member<DOMAIN>\Domain Admins 컴퓨터 계정
도메인 컨트롤러 그룹 A 및 B를 기본 do기본 user, member of <DOMAIN>\A,<DOMAIN>\B 컴퓨터 계정
구성원 서버 또는 워크스테이션 기본값 로컬 사용자, 다음의 멤버 BUILTIN\Administrators 컴퓨터 계정
구성원 서버 또는 워크스테이션 로컬 그룹 C 및 D 로컬 사용자, 멤버 및 <COMPUTER>\C<COMPUTER>\D 컴퓨터 계정

보안 감사 및 애플리케이션 이벤트 로그를 보면 각 JEA 사용자 세션에 고유한 가상 계정이 있음을 알 수 있습니다. 이 고유한 계정을 사용하면 JEA 엔드포인트의 사용자 작업을 명령을 실행한 원래 사용자로 다시 추적할 수 있습니다. 가상 계정 이름은 형식 WinRM Virtual Users\WinRM_VA_<ACCOUNTNUMBER>_<DOMAIN>_<sAMAccountName> 을 따릅니다. 예를 들어 사용자 Alice in do기본 Contoso가 JEA 엔드포인트에서 서비스를 다시 시작하면 모든 서비스 제어 관리자 이벤트와 연결된 사용자 이름이 됩니다WinRM Virtual Users\WinRM_VA_1_contoso_alice.

gMSA(그룹 관리 서비스 계정) 는 구성원 서버가 JEA 세션의 네트워크 리소스에 액세스할 수 있어야 하는 경우에 유용합니다. 예를 들어 JEA 엔드포인트를 사용하여 다른 컴퓨터에서 호스트되는 REST API 서비스에 대한 액세스를 제어하는 경우입니다. REST API를 호출하는 함수를 작성하는 것은 쉽지만 API로 인증하려면 네트워크 ID가 필요합니다. 그룹 관리 서비스 계정을 사용하면 기본 계정을 사용할 수 있는 컴퓨터를 제어하는 동안 두 번째 홉이 가능합니다. gMSA의 보안 그룹(로컬 또는 할기본) 멤버 자격은 gMSA 계정에 대한 유효 권한을 정의했습니다.

gMSA를 사용하도록 JEA 엔드포인트를 구성하면 모든 JEA 사용자의 작업이 동일한 gMSA에서 온 것으로 보입니다. 특정 사용자에게 작업을 다시 추적하는 유일한 방법은 PowerShell 세션 대본에서 실행되는 명령 집합을 식별하는 것입니다.

통과 자격 증명은 실행 계정을 지정하지 않을 때 사용됩니다. PowerShell은 연결 사용자의 자격 증명을 사용하여 원격 서버에서 명령을 실행합니다. 통과 자격 증명을 사용하려면 연결된 사용자에게 권한 있는 관리 그룹에 대한 직접 액세스 권한을 부여해야 합니다. 이 구성은 JEA에 권장되지 않습니다 . 연결 사용자에게 이미 관리자 권한이 있는 경우 JEA를 우회하고 다른 액세스 방법을 사용하여 시스템을 관리할 수 있습니다.

표준 실행 계정을 사용하면 전체 PowerShell 세션이 실행되는 사용자 계정을 지정할 수 있습니다. 고정 실행 계정( -RunAsCredential 매개 변수 포함)을 사용하는 세션 구성은 JEA를 인식하지 않습니다. 역할 정의는 더 이상 예상대로 작동하지 않습니다. 엔드포인트에 액세스할 권한이 있는 모든 사용자에게는 동일한 역할이 할당됩니다.

특정 사용자에게 작업을 다시 추적하기 어렵고 사용자를 역할에 매핑할 수 있는 지원이 부족하기 때문에 JEA 엔드포인트에서 RunAsCredential을 사용하면 안 됩니다.

WinRM 엔드포인트 ACL

일반 PowerShell 원격 엔드포인트와 마찬가지로 각 JEA 엔드포인트에는 JEA 엔드포인트로 인증할 수 있는 사용자를 제어하는 별도의 ACL(액세스 제어 목록)이 있습니다. 잘못 구성된 경우 신뢰할 수 있는 사용자가 JEA 엔드포인트에 액세스할 수 없으며 신뢰할 수 없는 사용자에게 액세스 권한이 있을 수 있습니다. WinRM ACL은 JEA 역할에 대한 사용자 매핑에 영향을 주지 않습니다. 매핑은 엔드포인트를 등록하는 데 사용되는 세션 구성 파일의 RoleDefinitions 필드에 의해 제어됩니다.

기본적으로 JEA 엔드포인트에 여러 역할 기능이 있는 경우 WinRM ACL은 매핑된 모든 사용자에 대한 액세스를 허용하도록 구성됩니다. 예를 들어 다음 명령을 사용하여 구성된 JEA 세션은 모든 액세스 권한을 CONTOSO\JEA_Lev1 부여합니다 CONTOSO\JEA_Lev2.

$roles = @{ 'CONTOSO\JEA_Lev1' = 'Lev1Role'; 'CONTOSO\JEA_Lev2' = 'Lev2Role' }
New-PSSessionConfigurationFile -Path '.\jea.pssc' -SessionType RestrictedRemoteServer -RoleDefinitions $roles -RunAsVirtualAccount
Register-PSSessionConfiguration -Path '.\jea.pssc' -Name 'MyJEAEndpoint'

Get-PSSessionConfiguration cmdlet을 사용하여 사용자 권한을 감사할 수 있습니다.

Get-PSSessionConfiguration -Name 'MyJEAEndpoint' | Select-Object Permission

Permission
----------
CONTOSO\JEA_Lev1 AccessAllowed
CONTOSO\JEA_Lev2 AccessAllowed

액세스 권한이 있는 사용자를 변경하려면 대화형 프롬프트를 실행 Set-PSSessionConfiguration -Name 'MyJEAEndpoint' -ShowSecurityDescriptorUI 하거나 Set-PSSessionConfiguration -Name 'MyJEAEndpoint' -SecurityDescriptorSddl <SDDL string> 권한을 업데이트합니다. 사용자는 JEA 엔드포인트에 액세스하려면 최소한 호출 권한이 필요합니다.

정의된 역할을 액세스 권한이 있는 모든 사용자에게 매핑하지 않는 JEA 엔드포인트를 만들 수 있습니다. 이러한 사용자는 JEA 세션을 시작할 수 있지만 기본 cmdlet에만 액세스할 수 있습니다. 를 실행 Get-PSSessionCapability하여 JEA 엔드포인트에서 사용자 권한을 감사할 수 있습니다. 자세한 내용은 JEA에 대한 감사 및 보고를 참조 하세요.

최소 권한 역할

JEA 역할을 디자인할 때는 백그라운드에서 실행되는 가상 및 그룹 관리 서비스 계정이 로컬 컴퓨터에 무제한으로 액세스할 수 있다는 점을 기억해야 합니다. JEA 역할 기능은 권한 있는 컨텍스트에서 실행할 수 있는 명령 및 애플리케이션을 제한하는 데 도움이 됩니다. 부적절하게 디자인된 역할은 사용자가 JEA 경계를 벗어나거나 중요한 정보에 액세스할 수 있도록 허용하는 위험한 명령을 허용할 수 있습니다.

예를 들어 다음과 같은 역할 기능 항목을 생각해 봅니다.

@{
    VisibleCmdlets = 'Microsoft.PowerShell.Management\*-Process'
}

이 역할 기능을 통해 사용자는 Microsoft.PowerShell.Management 모듈에서 명사 Process를 사용하여 모든 PowerShell cmdlet을 실행할 수 있습니다. 사용자는 시스템에서 Stop-Process 실행 중인 애플리케이션을 확인하고 응답하지 않는 애플리케이션을 종료하기 위해 cmdlet Get-Process 에 액세스해야 할 수 있습니다. 그러나 이 항목은 전체 관리자 권한으로 임의 프로그램을 시작하는 데 사용될 수 있는 Start-Process도 허용합니다. 프로그램을 시스템에 로컬로 설치할 필요가 없습니다. 연결된 사용자는 사용자 로컬 관리자 권한을 부여하고 맬웨어를 실행하는 파일 공유에서 프로그램을 시작할 수 있습니다.

이 동일한 역할 기능의 더 안전한 버전은 다음과 같습니다.

@{
    VisibleCmdlets = 'Microsoft.PowerShell.Management\Get-Process',
                     'Microsoft.PowerShell.Management\Stop-Process'
}

역할 기능에 와일드카드를 사용하지 마세요. 사용자가 액세스할 수 있는 명령을 확인하려면 효과적인 사용자 권한을 정기적으로 감사해야 합니다. 자세한 내용은 JEA에 대한 감사 및 보고 문서의 유효 권한 확인 섹션을 참조하세요.

모범 사례 권장 사항

다음은 JEA 엔드포인트의 보안을 보장하기 위한 모범 사례 권장 사항입니다.

PowerShell 공급자의 사용 및 기능 제한

허용된 공급자를 사용하여 구성된 세션에서 취약성을 만들지 않도록 하는 방법을 검토합니다.

Warning

FileSystem 공급자를 허용하지 않습니다. 사용자가 파일 시스템의 어느 부분에나 쓸 수 있는 경우 보안을 완전히 무시할 수 있습니다.

인증서 공급자를 허용하지 않습니다. 공급자를 사용하도록 설정하면 사용자는 저장된 프라이빗 키에 액세스할 수 있습니다.

새 Runspace를 만들 수 있는 명령을 허용하지 않습니다.

Warning

cmdlet은 *-Job 제한 없이 새 Runspace를 만들 수 있습니다.

cmdlet을 Trace-Command 허용하지 않습니다.

Warning

사용하면 Trace-Command 추적된 모든 명령이 세션에 표시됩니다.

제한된 명령에 대한 고유한 프록시 구현을 만들지 마세요.

PowerShell에는 제한된 명령 시나리오에 대한 프록시 명령 집합이 있습니다. 이러한 프록시 명령은 입력 매개 변수가 세션의 보안을 손상시킬 수 없도록 합니다. 다음 명령은 프록시를 제한했습니다.

  • Exit-PSSession
  • Get-Command
  • Get-FormatData
  • Get-Help
  • Measure-Object
  • Out-Default
  • Select-Object

이러한 명령의 고유한 구현을 만드는 경우 사용자가 실수로 JEA 프록시 명령에서 금지된 코드를 실행하도록 허용할 수 있습니다.

JEA는 관리자로부터 보호하지 않습니다.

JEA의 핵심 원칙 중 하나는 비관리자가 일부 관리 작업을 수행할 수 있도록 허용한다는 것입니다. JEA는 이미 관리자 권한이 있는 사용자로부터 보호하지 않습니다. Do기본 관리s, 로컬 관리istrators 또는 기타 높은 권한이 있는 그룹에 속한 사용자는 다른 방법으로 JEA의 보호를 우회할 수 있습니다. 예를 들어 RDP로 로그인하거나, 원격 MMC 콘솔을 사용하거나, 제약이 없는 PowerShell 엔드포인트에 연결할 수 있습니다. 또한 시스템의 로컬 관리자는 JEA 구성을 수정하여 사용자를 더 추가하거나 역할 기능을 변경하여 사용자가 JEA 세션에서 수행할 수 있는 작업의 범위를 확장할 수 있습니다. JEA 사용자의 확장된 사용 권한을 평가하여 시스템에 대한 권한 있는 액세스 권한을 얻는 다른 방법이 있는지 확인해야 합니다.

일상적인 기본 테넌스에 JEA를 사용하는 것 외에도 Just-In-Time 권한 있는 액세스 관리 시스템을 사용하는 것이 일반적입니다. 이러한 시스템을 통해 지정된 사용자는 해당 사용 권한의 사용을 문서화하는 워크플로를 완료한 후에만 일시적으로 로컬 관리자가 될 수 있습니다.