Azure Local, versie 23H2 implementeren met behulp van een lokale identiteit met Azure Key Vault (preview)

Artikel
11/23/2024

Van toepassing op: Azure Local 2311.2 en hoger

In dit artikel wordt beschreven hoe u lokale identiteit gebruikt met Azure Key Vault voor azure Local versie 23H2-implementatie.

Belangrijk

Deze functie is momenteel beschikbaar als PREVIEW-versie. Raadpleeg de Aanvullende voorwaarden voor Microsoft Azure-previews voor juridische voorwaarden die van toepassing zijn op Azure-functies die in bèta of preview zijn of die anders nog niet algemeen beschikbaar zijn.

Overzicht

Voorheen bekend als AD-less-implementatie, kan Azure Local met behulp van een lokale identiteit veilig geheimen beheren en opslaan, zoals BitLocker-sleutels, knooppuntwachtwoorden en andere gevoelige informatie, zonder gebruik te maken van AD. Door te integreren met Key Vault en verificatie op basis van certificaten, kunt u uw beveiligingspostuur verbeteren en de continuïteit van bewerkingen garanderen.

Vergoedingen

Het gebruik van lokale identiteit met Key Vault in Azure Local biedt verschillende voordelen, met name voor omgevingen die niet afhankelijk zijn van AD. Hier volgen enkele belangrijke voordelen:

Minimale randinfrastructuur. Voor omgevingen die geen gebruik maken van AD, biedt lokale identiteit met Key Vault een veilige en efficiënte manier om gebruikersidentiteiten en geheimen te beheren.
Geheime opslag. Key Vault beheert en bewaart geheimen, zoals BitLocker-sleutels, knooppuntwachtwoorden en andere gevoelige informatie. Dit vermindert het risico op onbevoegde toegang en verbetert het algehele beveiligingspostuur.
Vereenvoudigd beheer onderhouden. Door integratie met Key Vault kunnen organisaties het beheer van geheimen en referenties stroomlijnen. Dit omvat het opslaan van implementatie- en lokale identiteitsgeheimen in één kluis, waardoor het eenvoudiger is om deze geheimen te beheren en te openen.
Vereenvoudigde implementatie. Tijdens de systeemimplementatie via Azure Portal hebt u de mogelijkheid om een lokale id-provider te selecteren die is geïntegreerd met Key Vault. Met deze optie wordt het implementatieproces gestroomlijnd door ervoor te zorgen dat alle benodigde geheimen veilig worden opgeslagen in Key Vault. De implementatie wordt efficiënter door het verminderen van afhankelijkheden van bestaande AD-systemen of andere systemen waarop AD wordt uitgevoerd, waarvoor doorlopend onderhoud is vereist. Bovendien vereenvoudigt deze aanpak firewallconfiguraties voor operationele technologienetwerken, waardoor het eenvoudiger is om deze omgevingen te beheren en te beveiligen.

Vereisten

Voordat u begint, moet u ervoor zorgen dat u het volgende doet:

Onderteken de lokale identiteit met het aanmeldingsformulier van Azure Key Vault Preview om deel te nemen aan de beperkte openbare preview. Raadpleeg de Privacyverklaring van Microsoft voor meer informatie over hoe we uw persoonsgegevens verzamelen, gebruiken en beschermen tijdens uw deelname aan de preview.
Voldoet aan de vereisten en voltooi de controlelijst voor implementatie. Sla de AD-specifieke vereisten over.
Maak een lokaal gebruikersaccount met dezelfde referenties op alle knooppunten en voeg dit toe aan de lokale beheerdersgroep in plaats van het ingebouwde beheerdersaccount te gebruiken.
Download de lokale Azure-software. Instructies voor het downloaden van de lokale Azure-software worden verstrekt aan degenen die zich hebben geregistreerd voor de preview.
Voor deze preview vereisen de knooppunten statische IP-adressen en bieden geen ondersteuning voor DHCP. Nadat het besturingssysteem is geïnstalleerd, gebruikt u SConfig om het statische IP-adres, subnet, gateway en DNS in te stellen.
Een DNS-server met een correct geconfigureerde zone hebben. Deze installatie is van cruciaal belang voor een goede werking van het netwerk. Zie DNS-server configureren voor Azure Local.

DNS-server configureren voor Azure Local

Volg deze stappen om DNS te configureren voor Azure Local:

DNS-server maken en configureren.

Stel uw DNS-server in als u er nog geen hebt. Dit kan worden gedaan met Behulp van Windows Server DNS of een andere DNS-oplossing.
DNS Host A-records maken.

Maak voor elk knooppunt in uw lokale Azure-exemplaar een DNS-host A-record. Deze record wijst de hostnaam van het knooppunt toe aan het IP-adres, zodat andere apparaten in het netwerk het knooppunt kunnen vinden en met het knooppunt kunnen communiceren.

Maak bovendien een DNS Host A-record voor het systeem zelf. Deze record moet het eerste IP-adres uit het netwerkbereik gebruiken dat u voor het systeem hebt toegewezen.
DNS-records verifiëren.

Voer de volgende opdracht uit om te controleren of de DNS-records voor een specifieke computer juist zijn ingesteld:
```
nslookup "machine name"
```
Dns-doorsturen instellen.

Configureer DNS-doorsturen op uw DNS-server om DNS-query's naar Azure DNS of een andere externe DNS-provider door te sturen, indien nodig.
Netwerkinstellingen bijwerken.

Werk de netwerkinstellingen op uw Lokale Azure-knooppunten bij om de DNS-server te gebruiken die u hebt geconfigureerd. U kunt dit doen via de netwerkadapterinstellingen of met behulp van PowerShell-opdrachten.
Controleer de DNS-configuratie.

Test de DNS-configuratie om ervoor te zorgen dat DNS-query's correct zijn omgezet. U kunt hulpprogramma's gebruiken zoals nslookup of graven om DNS-omzetting te controleren.

Registersleutel instellen op elk knooppunt.

Stel de registersleutel in met de zonenaam/FQDN op elk knooppunt. Voer de volgende opdracht uit:

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

Start het besturingssysteem opnieuw op lokale en externe computers met behulp van de volgende opdracht:
```
Restart-Computer
```

Azure Local implementeren via de portal met behulp van lokale identiteit met Key Vault

Tijdens de implementatie via Azure Portal kunt u een lokale id-provider selecteren die is geïntegreerd met Key Vault. Hiermee kunt u een lokale identiteit met Key Vault gebruiken om geheimen veilig te beheren en op te slaan in plaats van te vertrouwen op AD voor verificatie.

De algemene implementatiestappen zijn hetzelfde als de stappen die worden beschreven in Deploy an Azure Local, version 23H2 system using the Azure Portal. Wanneer u echter lokale identiteit gebruikt met Key Vault, moet u specifieke stappen uitvoeren op de tabbladen Netwerken en beheer .

Tabblad Netwerken

Geef de details van de DNS-server op die zijn geconfigureerd in de sectie DNS configureren voor Azure Local .

Tabblad Beheer

Selecteer de optie Lokale identiteit met Azure Key Vault .
Als u een nieuwe Sleutelkluis wilt maken, selecteert u Een nieuwe Sleutelkluis maken. Voer de vereiste gegevens in het rechtercontextvenster in en selecteer Vervolgens Maken.
Voer in de naam van de sleutelkluis de nieuwe naam van de sleutelkluis in.

Stappen na implementatie

Nadat u het systeem hebt geïmplementeerd, controleert u of de implementatie ad-less is en controleert u of er een back-up van geheimen wordt gemaakt naar Key Vault.

Bevestigen dat het systeem is geïmplementeerd zonder Active Directory

Nadat u het systeem hebt geïmplementeerd, controleert u of de implementatie zonder AD (AD-less) is.

Controleer of het knooppunt niet is gekoppeld aan een AD-domein door de volgende opdracht uit te voeren. Als de uitvoer wordt weergegeven WORKGROUP, is het knooppunt niet lid van een domein.
```
Get-WmiObject Win32_ComputerSystem.Domain
```
Hier volgt een voorbeelduitvoer:
```
[host]: PS C:\Users\LocalAdmin\Documents> (Get-WmiObject Win32_ComputerSystem).Domain 
WORKGROUP
```

Controleer of een cluster een werkgroepcluster is dat werkt zonder AD. Voer de volgende opdracht uit en controleer de waarde van de ADAware parameter:

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.

Controleren of er een back-up wordt gemaakt van geheimen naar Key Vault

BitLocker-sleutels en beheerderswachtwoorden voor herstel worden veilig back-ups gemaakt naar Azure en worden geroteerd om de maximale beveiliging te garanderen.

In scenario's waarin AD niet beschikbaar is, kunt u een toegewezen gebruiker voor herstelbeheerders gebruiken om het systeem te herstellen. De aangewezen gebruikersnaam voor dit doel is RecoveryAdmin. Het bijbehorende wachtwoord kan veilig worden opgehaald uit Azure Key Vault, zodat u over de benodigde referenties beschikt om systeemherstelbewerkingen effectief uit te voeren.

Dit zorgt ervoor dat alle kritieke informatie veilig wordt opgeslagen en eenvoudig kan worden opgehaald wanneer dat nodig is, waardoor een extra beveiligings- en betrouwbaarheidslaag voor onze infrastructuur wordt geboden.

Key Vault bijwerken in Azure Local

Als u de back-upconfiguratie wilt bijwerken voor het gebruik van een nieuwe Sleutelkluis, moet u uw systeem patchen met de nieuwe Key Vault-gegevens.

Volg deze stappen om de key vault-configuratie van uw back-up van een systeem bij te werken voor het gebruik van een nieuwe Key Vault:

Begin met het maken van een nieuwe Key Vault in Azure Portal. Zorg ervoor dat deze is geconfigureerd voor het opslaan van back-upgeheimen.
Stel de juiste toegangsbeheer in voor de nieuwe Sleutelkluis. Dit omvat het verlenen van de benodigde machtigingen aan de knooppuntidentiteit. Zorg ervoor dat uw Key Vault de rol Key Vaults Secret Officer heeft toegewezen. Zie Toegang verlenen tot Key Vault-sleutels, -certificaten en -geheimen met een op rollen gebaseerd toegangsbeheer van Azure voor instructies.

Werk de systeemconfiguratie bij.

Gebruik een POST-aanvraag om de clusterconfiguratie bij te werken met de nieuwe Key Vault-details. Dit omvat het verzenden van een aanvraag naar het volgende API-eindpunt:

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/"
}
}

Valideer de configuratie. Open de systeemresource in Azure Portal en controleer of Resource JSON de bijgewerkte Key Vault-details bevat.

Hier volgt een voorbeeldschermopname van Resource JSON waar u de Key Vault kunt bijwerken:
Controleer geheimen in de nieuwe sleutelkluis. Controleer of alle back-upgeheimen correct zijn opgeslagen in de nieuwe sleutelkluis.
Schoon de oude sleutelkluis op. De oude Sleutelkluis en de bijbehorende geheimen worden niet automatisch verwijderd. Nadat u hebt gecontroleerd of de nieuwe sleutelkluis correct is geconfigureerd en alle geheimen zijn opgeslagen zoals verwacht, kunt u de oude sleutelkluis zo nodig verwijderen.

Een verwijderde Sleutelkluis herstellen en back-up hervatten

Wanneer u een Sleutelkluis verwijdert en vervolgens herstelt, wordt de beheerde identiteit die eerder toegang tot de Key Vault had, op de volgende manieren beïnvloed:

Intrekking van toegang tot beheerde identiteiten. Tijdens het verwijderingsproces worden de toegangsmachtigingen van de beheerde identiteit voor de Sleutelkluis ingetrokken. Dit betekent dat de identiteit geen toegang meer heeft tot de Key Vault.
Fout bij uitbreidingsbewerkingen. De back-upsleutelkluisextensie die verantwoordelijk is voor het beheren van geheime back-ups, is afhankelijk van de beheerde identiteit voor toegang. Als de toegangsmachtigingen zijn ingetrokken, kan de extensie geen back-upbewerkingen uitvoeren.
Extensiestatus in Azure Portal. In Azure Portal wordt de status van de extensie weergegeven als Mislukt , wat aangeeft dat de extensie geen back-up van geheimen kan maken vanwege het verlies van de benodigde machtigingen.

Voer de volgende stappen uit om het probleem van de mislukte extensie op te lossen en normale back-upbewerkingen te herstellen:

Wijs beheerde identiteit toegang opnieuw toe.
1. Bepaal de beheerde identiteit waarvoor toegang tot de Sleutelkluis is vereist.
2. Wijs de rol Key Vault Secret Officer opnieuw toe aan de beheerde identiteit.
Controleer de functionaliteit van de extensie.
1. Na het opnieuw toewijzen controleert u de extensiestatus in Azure Portal om ervoor te zorgen dat deze wordt gewijzigd van Mislukt in Geslaagd. Dit geeft aan dat de extensie de benodigde machtigingen heeft hersteld en nu goed werkt.
2. Test de back-upbewerkingen om ervoor te zorgen dat er een back-up van geheimen correct wordt gemaakt en dat het back-upproces naar verwachting functioneert.

Volgende stappen

Als u tijdens de implementatie geen workloadvolumes hebt gemaakt, maakt u workloadvolumes en opslagpaden voor elk volume. Zie Volumes maken op lokale azure- en Windows Server-clusters en opslagpad maken voor Azure Local voor meer informatie.
Ondersteuning krijgen voor problemen met lokale Implementatie van Azure.

Delen via