Azure Key Vault에서 로컬 ID를 사용하여 Azure 로컬 버전 23H2 배포(미리 보기)

아티클
11/23/2024

적용 대상: Azure Local, 버전 23H2

이 문서에서는 Azure Local 버전 23H2 배포용 Azure Key Vault에서 로컬 ID를 사용하는 방법을 설명합니다.

Important

이 기능은 현재 미리 보기로 제공됩니다. 베타, 미리 보기로 제공되거나 아직 일반 공급으로 릴리스되지 않은 Azure 기능에 적용되는 약관은 Microsoft Azure 미리 보기에 대한 추가 사용 약관을 참조하세요.

개요

이전에는 AD가 없는 배포로 알려진 Key Vault에서 로컬 ID를 사용하는 방법을 통해 Azure Local은 AD를 사용하지 않고 BitLocker 키, 노드 암호 및 기타 중요한 정보와 같은 비밀을 안전하게 관리하고 저장할 수 있습니다. Key Vault와 통합하고 인증서 기반 인증을 사용하여 보안 상태를 개선하고 작업의 연속성을 보장할 수 있습니다.

이점

Azure Local에서 Key Vault와 함께 로컬 ID를 사용하면 특히 AD에 의존하지 않는 환경에 대해 몇 가지 이점이 있습니다. 다음은 몇 가지 주요 이점입니다.

최소 에지 인프라. AD를 사용하지 않는 환경의 경우 Key Vault를 사용하는 로컬 ID는 사용자 ID 및 비밀을 관리하는 안전하고 효율적인 방법을 제공합니다.
비밀 저장소 Key Vault는 BitLocker 키, 노드 암호 및 기타 중요한 정보와 같은 비밀을 안전하게 관리하고 저장합니다. 이렇게 하면 무단 액세스의 위험이 줄어들고 전반적인 보안 태세가 향상됩니다.
간소화된 관리를 유지 관리합니다. 조직은 Key Vault와 통합하여 비밀 및 자격 증명 관리를 간소화할 수 있습니다. 여기에는 배포 및 로컬 ID 비밀을 단일 자격 증명 모음에 저장하여 이러한 비밀을 보다 쉽게 관리하고 액세스할 수 있도록 하는 것이 포함됩니다.
간소화된 배포. Azure Portal을 통해 시스템을 배포하는 동안 Key Vault와 통합된 로컬 ID 공급자를 선택할 수 있습니다. 이 옵션은 필요한 모든 비밀이 Key Vault 내에 안전하게 저장되도록 하여 배포 프로세스를 간소화합니다. 지속적인 유지 관리가 필요한 기존 AD 시스템 또는 AD를 실행하는 다른 시스템에 대한 종속성을 줄이면 배포의 효율성이 높아집니다. 또한 이 방법은 운영 기술 네트워크에 대한 방화벽 구성을 간소화하여 이러한 환경을 보다 쉽게 관리하고 보호할 수 있도록 합니다.

필수 조건

시작하기 전에 다음을 수행해야 합니다.

제한된 공개 미리 보기에 참여하려면 Azure Key Vault 미리 보기 등록 양식을 사용하여 로컬 ID에 서명합니다. 미리 보기에 참여하는 동안 개인 데이터를 수집, 사용 및 보호하는 방법에 대한 자세한 내용은 Microsoft 개인정보처리방침을 검토하세요.
필수 구성 요소를 충족하고 배포 검사 목록을 완료합니다. AD 관련 필수 구성 요소를 건너뜁니다.
모든 노드에서 동일한 자격 증명을 사용하여 로컬 사용자 계정을 만들고 기본 제공 관리자 계정을 사용하는 대신 로컬 관리자 그룹에 추가합니다.
제대로 구성된 영역이 있는 DNS 서버가 있어야 합니다. 이 설정은 네트워크가 올바르게 작동하는 데 중요합니다. Azure Local에 대한 DNS 서버 구성을 참조하세요.
Azure 로컬 소프트웨어를 다운로드합니다. Azure 로컬 소프트웨어를 다운로드하는 방법에 대한 지침은 미리 보기에 등록한 사용자에게 제공됩니다.

Azure Local에 대한 DNS 서버 구성

다음 단계에 따라 Azure Local에 대한 DNS를 구성합니다.

DNS 서버를 만들고 구성합니다.

DNS 서버가 아직 없는 경우 설정합니다. 이 작업은 Windows Server DNS 또는 다른 DNS 솔루션을 사용하여 수행할 수 있습니다.
DNS 호스트 A 레코드를 만듭니다.

Azure 로컬 인스턴스의 각 노드에 대해 DNS 호스트 A 레코드를 만듭니다. 이 레코드는 노드의 호스트 이름을 IP 주소에 매핑하여 네트워크의 다른 디바이스가 노드를 찾아서 통신할 수 있도록 합니다.

또한 시스템 자체에 대한 DNS 호스트 A 레코드를 만듭니다. 이 레코드는 시스템에 할당한 네트워크 범위의 첫 번째 IP 주소를 사용해야 합니다.
DNS 레코드를 확인합니다.

특정 컴퓨터에 대한 DNS 레코드가 올바르게 설정되었는지 확인하려면 다음 명령을 실행합니다.
```
nslookup "machine name"
```
DNS 전달을 설정합니다.

필요에 따라 DNS 쿼리를 Azure DNS 또는 다른 외부 DNS 공급자로 전달하도록 DNS 서버에서 DNS 전달을 구성합니다.
네트워크 설정을 업데이트합니다.

구성한 DNS 서버를 사용하도록 Azure 로컬 노드의 네트워크 설정을 업데이트합니다. 네트워크 어댑터 설정을 통해 또는 PowerShell 명령을 사용하여 이 작업을 수행할 수 있습니다.
DNS 구성을 확인합니다.

DNS 구성을 테스트하여 DNS 쿼리가 올바르게 확인되었는지 확인합니다. 같은 nslookup 도구를 사용하거나 DNS 확인을 확인할 수 있습니다.

각 노드에서 레지스트리 키를 설정합니다.

각 노드에서 영역 이름/FQDN을 사용하여 레지스트리 키를 설정합니다. 다음 명령을 실행합니다.

$zoneName = "replace.with.your.zone.name.here" 
$RegistryPath = 'HKLM:\SYSTEM\CurrentControlSet\services\Tcpip\Parameters' 
Set-ItemProperty -Path $RegistryPath -Name 'Domain' -Value $zoneName

다음 명령을 사용하여 로컬 및 원격 컴퓨터에서 운영 체제를 다시 시작합니다.
```
Restart-Computer
```

Key Vault에서 로컬 ID를 사용하여 포털을 통해 Azure 로컬 배포

Azure Portal을 통해 배포하는 동안 Key Vault와 통합된 로컬 ID 공급자를 선택할 수 있습니다. 이렇게 하면 인증을 위해 AD를 사용하는 대신 Key Vault에서 로컬 ID를 사용하여 비밀을 안전하게 관리하고 저장할 수 있습니다.

일반 배포 단계는 Azure Portal을 사용하여 Azure 로컬 버전 23H2 시스템 배포에 설명된 단계와 동일합니다. 그러나 Key Vault에서 로컬 ID를 사용하는 경우 네트워킹 및 관리 탭에서 특정 단계를 수행해야 합니다.

네트워킹 탭

Azure 로컬에 대한 DNS 구성 섹션에 구성된 DNS 서버 세부 정보를 제공합니다.

관리 탭

Azure Key Vault를 사용하여 로컬 ID 옵션을 선택합니다.
새 Key Vault를 만들려면 새 Key Vault 만들기를 선택합니다. 올바른 컨텍스트 창에 필요한 세부 정보를 입력한 다음 만들기를 선택합니다.
키 자격 증명 모음 이름에 새 Key Vault 이름을 입력합니다.

배포 후 단계

시스템을 배포한 후 배포가 AD가 없는지 확인하고 비밀이 Key Vault에 백업되고 있는지 확인합니다.

Active Directory 없이 시스템이 배포되었는지 확인

시스템을 배포한 후 배포가 AD(AD 없는)가 없는지 확인합니다.

다음 명령을 실행하여 노드가 AD 도메인에 조인되지 않는지 확인합니다. 출력이 표시 WORKGROUP되면 노드가 도메인에 가입되지 않습니다.
```
Get-WmiObject Win32_ComputerSystem.Domain
```
샘플 출력은 다음과 같습니다.
```
[host]: PS C:\Users\LocalAdmin\Documents> (Get-WmiObject Win32_ComputerSystem).Domain 
WORKGROUP
```

클러스터가 AD 없이 작동하는 작업 그룹 클러스터인지 확인합니다. 다음 명령을 실행하고 매개 변수 값을 ADAware 확인합니다.

Get-ClusterResource "Cluster Name" | Get-ClusterParameter ADAware 

Object       Name    Value Type 

------       ----    ----- ---- 

ClusterName  ADAware  2    UInt32 

For ADAware property, 0 = None, 1 = AD, 2 = DNS (AD'less) only.

비밀이 Key Vault에 백업되는지 확인

BitLocker 키 및 복구 관리자 암호는 Azure에 안전하게 백업되고 최대 보안을 보장하기 위해 회전됩니다.

AD를 사용할 수 없는 시나리오에서는 전용 복구 관리자 사용자를 활용하여 시스템을 복원할 수 있습니다. 이 용도로 지정된 사용자 이름은 .입니다 RecoveryAdmin. Azure Key Vault에서 해당 암호를 안전하게 검색하여 시스템 복구 작업을 효과적으로 수행하는 데 필요한 자격 증명이 있는지 확인할 수 있습니다.

이렇게 하면 모든 중요한 정보가 안전하게 저장되고 필요할 때 쉽게 검색할 수 있으므로 인프라에 대한 추가 보안 및 안정성 계층을 제공합니다.

Azure 로컬에서 Key Vault 업데이트

새 Key Vault를 사용하도록 백업 구성을 업데이트하려면 새 Key Vault 정보로 시스템을 패치해야 합니다.

다음 단계에 따라 새 Key Vault를 사용하도록 시스템의 백업 Key Vault 구성을 업데이트합니다.

먼저 Azure Portal에서 새 Key Vault를 만듭니다. 백업 비밀을 저장하도록 구성되어 있는지 확인합니다.
새 Key Vault에 대한 적절한 액세스 제어를 설정합니다. 여기에는 노드 ID에 필요한 권한을 부여하는 것이 포함됩니다. Key Vault에 Key Vault 비밀 책임자 역할이 할당되었는지 확인합니다. 지침은 Azure 역할 기반 액세스 제어를 사용하여 Key Vault 키, 인증서 및 비밀에 대한 액세스 권한 제공을 참조하세요.

시스템 구성을 업데이트합니다.

POST 요청을 사용하여 새 Key Vault 세부 정보로 클러스터 구성을 업데이트합니다. 여기에는 다음 API 엔드포인트에 요청을 보내는 작업이 포함됩니다.

API Spec:
API Version: 2024-07-01-preview
API Path: /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.AzureStackHCI/clusters/{clusterName}/updateSecretsLocations
Payload:
{
"properties": {
    "secretsType": "BackupSecrets",
    "secretsLocation": "https://hcikeyvaulttestingnew.vault.azure.net/"
}
}

구성의 유효성을 검사합니다. Azure Portal에서 시스템 리소스를 열고 Resource JSON에 업데이트된 Key Vault 세부 정보가 포함되어 있는지 확인합니다.

Key Vault를 업데이트할 수 있는 Resource JSON의 샘플 스크린샷은 다음과 같습니다.
새 Key Vault에서 비밀을 확인합니다. 모든 백업 비밀이 새 Key Vault에 제대로 저장되어 있는지 확인합니다.
이전 Key Vault를 정리합니다. 이전 Key Vault 및 해당 비밀은 자동으로 삭제되지 않습니다. 새 Key Vault가 올바르게 구성되고 모든 비밀이 예상대로 저장되었는지 확인한 후 필요한 경우 이전 Key Vault를 삭제할 수 있습니다.

삭제된 Key Vault 복구 및 백업 다시 시작

Key Vault를 삭제한 후 복구하는 경우 이전에 Key Vault에 액세스할 수 있었던 관리 ID는 다음과 같은 방법으로 영향을 받습니다.

관리 ID 액세스 해지 삭제 프로세스 중에 Key Vault에 대한 관리 ID의 액세스 권한이 취소됩니다. 즉, ID에 더 이상 Key Vault에 액세스할 수 있는 권한이 없습니다.
확장 작업의 실패입니다. 비밀 백업 관리를 담당하는 백업 키 자격 증명 모음 확장은 액세스에 대한 관리 ID에 의존합니다. 액세스 권한이 취소되면 확장에서 백업 작업을 수행할 수 없습니다.
Azure Portal의 확장 상태입니다. Azure Portal에서 확장 상태는 필요한 권한 손실로 인해 확장을 백업할 수 없음을 나타내는 실패로 표시됩니다.

실패한 확장 문제를 해결하고 해결하고 정상적인 백업 작업을 복원하려면 다음 단계를 수행합니다.

관리 ID 액세스를 다시 할당합니다.
1. Key Vault에 액세스해야 하는 관리 ID를 결정합니다.
2. Key Vault 비밀 책임자 역할을 관리 ID에 다시 할당합니다.
확장 기능을 확인합니다.
1. 다시 할당한 후 Azure Portal에서 확장 상태를 모니터링하여 실패에서 성공으로 변경되었는지 확인합니다. 이는 확장이 필요한 권한을 되찾았으며 이제 제대로 작동하고 있음을 나타냅니다.
2. 백업 작업을 테스트하여 비밀이 올바르게 백업되고 백업 프로세스가 예상대로 작동하는지 확인합니다.

다음 단계

배포 중에 워크로드 볼륨을 만들지 않은 경우 각 볼륨에 대한 워크로드 볼륨 및 스토리지 경로를 만듭니다. 자세한 내용은 Azure 로컬 및 Windows Server 클러스터에서 볼륨 만들기 및 Azure Local에 대한 스토리지 경로 만들기를 참조하세요.
Azure 로컬 배포 문제에 대한 지원을 받으세요.

다음을 통해 공유