Planungs- und Bereitstellungshandbuch

Der Beschleuniger für Azure Arc-Zielzonen für Hybrid- und Multicloudumgebungen enthält einen vollständigen Leitfaden, den Sie bei der Planung einer Azure Arc-fähigen Serverbereitstellung berücksichtigen können. Dieser Abschnitt enthält eine Auswahl dieser Inhalte mit Bezug auf die Sicherheit.

Ressourcenhierarchie und geerbter Zugriff

Das Abonnement und die Ressourcengruppe, in dem bzw. der Sie Ihren Computer verbinden, beeinflussen, welche Benutzer und Konten in Ihrer Organisation den Computer in Azure anzeigen und verwalten können. Im Allgemeinen sollten Sie Ihre Server basierend auf den Gruppen von Konten organisieren, die darauf zugreifen müssen. Wenn Sie zwei Teams haben, die zwei separate Servergruppen verwalten und nicht in der Lage sein sollen, die Computer der anderen Gruppe zu verwalten, sollten Sie zwei Ressourcengruppen verwenden und den Zugriff auf die Server in der Ressourcengruppe steuern.

Anmeldeinformationen für das Onboarding

Wenn Sie einen Server mit Azure Arc verbinden, müssen Sie Onboarding-Anmeldeinformationen verwenden, um den Computer zum Erstellen einer Ressource in Ihrem Azure-Abonnement zu autorisieren. Es gibt drei Möglichkeiten zum Bereitstellen der Anmeldeinformationen:

1. Interaktive Anmeldungen, entweder mit dem lokalen Webbrowser (nur Windows) oder einem Geräteanmeldungscode, der auf jedem Computer mit Internetzugang eingegeben werden kann.

2. Dienstprinzipale, d. h. dedizierte Konten, die für geskriptete Installationen des Agents verwendet werden können. Dienstprinzipale bestehen aus einer eindeutigen Anwendungs-ID und entweder einem Nur-Text-Geheimnis oder einem Zertifikat. Wenn Sie sich für die Verwendung eines Dienstprinzipals entscheiden, sollten Sie Zertifikate anstelle geheimer Schlüssel verwenden, da sie mit Microsoft Entra-Richtlinien für bedingten Zugriff gesteuert werden können. Denken Sie daran, den Zugriff auf geheime Schlüssel/Zertifikate des Dienstprinzipals zu schützen und regelmäßig zu rotieren, um das Risiko von kompromittierten Anmeldeinformationen zu minimieren.

3. Zugriffstoken, die kurzlebig sind und aus anderen Anmeldeinformationen abgerufen werden.

Ganz gleich, welche Art von Anmeldeinformationen Sie verwenden, der wichtigste Punkt besteht darin, sicherzustellen, dass sie ausschließlich über die erforderlichen Berechtigungen zum Onboarding von Computern in Azure Arc verfügen, nicht mehr. Die Rolle „Onboarding von Azure Connected Machine“ wurde speziell für Onboarding-Anmeldeinformationen entwickelt und umfasst nur die erforderlichen Berechtigungen zum Erstellen und Lesen von Azure Arc-fähigen Serverressourcen in Azure. Sie sollten auch den Umfang der Rollenzuweisung auf die Ressourcengruppen oder Abonnements beschränken, die zum Onboarding Ihrer Server erforderlich sind.

Die Onboarding-Anmeldeinformationen sind nur zum Zeitpunkt der Ausführung des Schritts „azcmagent connect“ auf einem Server erforderlich. Sie sind nicht erforderlich, sobald ein Server verbunden ist. Wenn die Onboarding-Anmeldeinformationen ablaufen oder gelöscht werden, ist der Server weiterhin mit Azure verbunden.

Wenn ein böswilliger Akteur Zugriff auf Ihre Onboarding-Anmeldeinformationen erhält, kann er die Anmeldeinformationen verwenden, um Server außerhalb Ihrer Organisation in Azure Arc innerhalb Ihres Abonnements/Ihrer Ressourcengruppe zu onboarden. Sie können privaten Endpunkte zum Schutz vor solchen Angriffen verwenden, indem Sie den Zugriff auf Azure Arc innerhalb Ihres Netzwerks einschränken.

Schützen von Geheimnissen im Onboarding-Skript

Das Onboarding-Skript enthält alle Informationen, die erforderlich sind, um Ihren Server mit Azure zu verbinden. Dazu gehören Schritte zum Herunterladen, Installieren und Konfigurieren des Azure Connected Machine-Agents auf Ihrem Server. Es enthält auch die Onboarding-Anmeldeinformationen, die verwendet werden, um diesen Server nicht interaktiv mit Azure zu verbinden. Es ist wichtig, die Onboarding-Anmeldeinformationen zu schützen, damit sie nicht versehentlich in Protokollen erfasst werden und in die falschen Händen gelangen.

Bei Produktionsbereitstellungen ist es üblich, das Onboarding-Skript mithilfe eines Automatisierungstools wie Microsoft Configuration Manager, Red Hat Ansible oder Gruppenrichtlinien zu orchestrieren. Überprüfen Sie in Ihrem Automatisierungstool, ob es eine Möglichkeit zum Schutz von Geheimnissen gibt, die im Installationsskript verwendet werden. Wenn dies nicht der Fall ist, sollten Sie die Onboarding-Skriptparameter in eine dedizierte Konfigurationsdatei verschieben. Dadurch wird verhindert, dass Geheimnisse direkt in der Befehlszeile analysiert und potenziell protokolliert werden. Der Onboarding-Leitfaden für Gruppenrichtlinien enthält zusätzliche Schritte zum Verschlüsseln der Konfigurationsdatei, sodass nur Computerkonten sie entschlüsseln können, keine Benutzer oder andere außerhalb Ihrer Organisation.

Wenn Ihr Automatisierungstool die Konfigurationsdatei auf den Server kopiert, stellen Sie sicher, dass die Datei danach auch bereinigt wird, damit die Geheimnisse nicht länger als erforderlich beibehalten werden.

Wie bei allen Azure-Ressourcen werden Tags für Azure Arc-fähige Server als Nur-Text gespeichert. Platzieren Sie vertrauliche Informationen nicht in Tags.

Updates für Agents

Eine neue Version des Azure Connected Machine-Agents wird in der Regel jeden Monat veröffentlicht. Es gibt keinen genauen Zeitplan, zu dem die Updates verfügbar sind, aber Sie sollten monatlich nach Updates suchen und diese anwenden. Weitere Informationen finden Sie in der Liste aller neuen Versionen, einschließlich der darin enthaltenen spezifischen Änderungen. Die meisten Updates beziehen sich auf Sicherheit, Leistung und Qualitätskorrekturen. Einige umfassen auch neue Features und Funktionen. Wenn ein Hotfix erforderlich ist, um ein Problem mit einer Version zu beheben, wird es als neue Agentversion veröffentlicht und ist auf dieselbe Weise wie eine normale Agentversion verfügbar.

Der Azure Connected Machine-Agent aktualisiert sich nicht selbst. Sie müssen ihn mit Ihrem bevorzugten Updateverwaltungstool aktualisieren. Für Windows-Computer werden Updates über Microsoft Update bereitgestellt. Eigenständige Server sollten sich für Microsoft Updates anmelden (mithilfe der Option Updates für andere Microsoft-Produkte erhalten). Wenn Ihre Organisation Windows Server Update Services verwendet, um Updates lokal zwischenzuspeichern und zu genehmigen, muss Ihr WSUS-Administrator Updates für das Azure Connected Machine-Agentprodukt synchronisieren und genehmigen.

Linux-Updates werden unter packages.microsoft.com veröffentlicht. Ihre Paketverwaltungssoftware (apt, yum, dnf, zypper usw.) sollte „azcmagent“-Updates zusammen mit Ihren anderen Systempaketen anzeigen. Weitere Informationen zum Upgrade von Linux-Agents.

Microsoft empfiehlt, nach Möglichkeit mit der aktuellen Agentversion auf dem neuesten Stand zu bleiben. Wenn Ihre Wartungsfenster weniger häufig sind, unterstützt Microsoft alle Agentversionen, die innerhalb der letzten 12 Monate veröffentlicht wurden. Da die Agentupdates jedoch Sicherheitsupdates enthalten, sollten Sie so häufig wie möglich aktualisieren.

Wenn Sie nach einem Patchverwaltungstool suchen, um Updates des Azure Connected Machine-Agents sowohl unter Windows als auch unter Linux zu orchestrieren, sollten Sie Azure Update Manager in Betracht ziehen.

Updates für Erweiterungen

Automatische Erweiterungsupdates

Standardmäßig sind für jede Erweiterung, die Sie auf einem Azure Arc-fähigen Server bereitstellen, automatische Erweiterungsupgrades aktiviert. Wenn der Erweiterungsherausgeber dieses Feature unterstützt, werden neue Versionen der Erweiterung automatisch innerhalb von 60 Tagen installiert, nachdem die neue Version verfügbar wird. Automatische Erweiterungsupgrades folgen einer sicheren Bereitstellungspraxis, was bedeutet, dass jeweils nur eine kleine Anzahl von Erweiterungen aktualisiert wird. Rollouts werden in allen Regionen und Abonnements langsam fortgesetzt, bis jede Erweiterung aktualisiert wurde.

Es gibt keine präzisen Kontrollen für automatische Erweiterungsupgrades. Sie werden immer auf die neueste Version der Erweiterung aktualisiert und können nicht auswählen, wann das Upgrade erfolgt. Der Erweiterungs-Manager verfügt über integrierte Ressourcengovernance, um sicherzustellen, dass ein Erweiterungsupgrade nicht zu viel der CPU des Systems verbraucht und während des Upgrades Ihre Workloads beeinträchtigt.

Wenn Sie keine automatischen Upgrades für Erweiterungen verwenden möchten, können Sie sie pro Erweiterung und pro Server mithilfe des Azure-Portals, der CLI oder PowerShell deaktivieren.

Manuelle Erweiterungsupdates

Für Erweiterungen, die keine automatischen Upgrades unterstützen oder für die automatische Upgrades deaktiviert wurden, können Sie das Azure-Portal, die CLI oder PowerShell verwenden, um Erweiterungen auf die neueste Version zu aktualisieren. Die CLI- und PowerShell-Befehle unterstützen auch das Downgrading einer Erweiterung, falls Sie zu einer früheren Version zurückkehren müssen.

Betriebssystemupdates

Direkte Upgrades: Das Durchführen eines direkten Upgrades des Betriebssystems auf Ihrem Arc-fähigen Computer wirkt sich nicht auf die Azure Arc-Verbindung aus. Der Connected Machine-Agent sollte weiterhin normal funktionieren, und der Server muss nicht erneut mit Azure integriert werden.

Neuinstallation des Betriebssystems: Wenn Sie das Betriebssystem auf derselben Hardware völlig neu installieren, wird der Connected Machine-Agent entfernt. Dadurch wird die Azure-Ressource, die dem Computer zugeordnet ist, nicht automatisch gelöscht. Sie können vor der Neuinstallation azcmagent disconnect verwenden, um den Computer zu trennen, oder die Ressource über das Portal oder ein Befehlszeilentool aus Azure löschen. Nachdem Sie das Betriebssystem neu installiert haben, installieren Sie den Connected Machine-Agent neu auf dem Computer, und führen Sie azcmagent connect erneut aus, um sich bei Azure Arc erneut zu registrieren.

Verwenden der Datenträgerverschlüsselung

Der Azure Connected Machine-Agent verwendet die Authentifizierung mit öffentlichem Schlüssel für die Kommunikation mit dem Azure-Dienst. Nachdem Sie einen Server in Azure Arc integriert haben, wird ein privater Schlüssel auf dem Datenträger gespeichert und immer dann verwendet, wenn der Agent mit Azure kommuniziert. Bei Diebstahl kann der private Schlüssel auf einem anderen Server verwendet werden, um mit dem Dienst zu kommunizieren, und so agieren, als ob es sich um den ursprünglichen Server handelt. Dies umfasst das Erhalten des Zugriffs auf die systemseitig zugewiesene Identität sowie auf alle Ressourcen, auf die diese Identität Zugriff hat. Die Datei mit dem privaten Schlüssel ist so geschützt, dass Sie nur das himds-Konto zum Lesen darauf Zugriff hat. Um Offlineangriffe zu verhindern, wird dringend empfohlen, die vollständige Datenträgerverschlüsselung (z. B. BitLocker, dm-crypt usw.) auf dem Betriebssystemvolume Ihres Servers zu verwenden.