Verwalten der Konformität virtueller Computer

In diesem Artikel wird beschrieben, wie Sie die Compliance virtueller Computer (VM) verwalten, ohne DevOps-Praktiken zu unterbrechen. Verwenden Sie Azure VM Image Builder und Azure Compute Gallery, um das Risiko durch System-Images zu minimieren. Die Lösung besteht aus dem Gold Image Publishing-Prozess und dem VM-Compliance-Tracking-Prozess.

Architecture

Laden Sie eine Visio-Datei dieser Architektur herunter.

Datenfluss

In den folgenden Abschnitten werden die beiden Prozesse in dieser Lösung beschrieben.

Goldene Bildveröffentlichung

Der folgende Datenfluss entspricht dem vorherigen Diagramm:

1. Jeden Monat erfasst der goldene Bildveröffentlichungsprozess ein Basisimage von Microsoft Marketplace. Ein goldenes Bild ist die veröffentlichte Version eines Marketplace-Bilds.

2. Azure VM Image Builder passt das Image an.

3. Der Bild-Tattooing-Prozess verfolgt Bildversionsinformationen wie die Quelle und das Veröffentlichungsdatum.

4. Automatisierte Tests validieren das Image.

5. Wenn der Test des Image fehlschlägt, wird es zum Anpassungsschritt für Reparaturen zurückgeleitet.

6. Der Prozess veröffentlicht das fertige Image.

7. Compute Gallery stellt das Image den DevOps-Teams zur Verfügung.

Nachverfolgen der VM-Compliance

Laden Sie eine Visio-Datei dieser Architektur herunter.

Der folgende Datenfluss entspricht dem vorherigen Diagramm:

1. Der Vm-Compliance-Nachverfolgungsprozess verwendet Azure-Richtlinie, um VMs Richtliniendefinitionen zuzuweisen und die VMs für die Compliance zu bewerten.

2. Azure Policy veröffentlicht Konformitätsdaten für die VMs und andere Azure-Ressourcen auf dem Azure Policy-Dashboard.

Components

• VM Image Builder ist ein verwalteter Dienst zum Anpassen von System-Images. Es erstellt Bilder, die DevOps-Teams verwenden. In dieser Architektur erfasst VM Image Builder monatliche Basisimages von Marketplace, wendet Härtungsänderungen an und installiert Agents. Die Image-Erstellung in diesem Prozess ist das goldenes Image.

• Compute Gallery ist ein Azure-Dienst zum Speichern und Organisieren von benutzerdefinierten VM-Images. Es zentralisiert die Bildverwaltung und steuert den Zugriff für interne Teams und alle externen Mandanten, die Sie autorisieren. In dieser Architektur speichert die Compute Gallery die goldenen Bilder, die DevOps-Teams verwenden müssen. Azure-Richtlinie erzwingt, dass DevOps-Teams VMs nur von Abbildern in dieser Galerie bereitstellen.

• Azure Policy ist ein Azure-Governancedienst, der Richtliniendefinitionen bereitstellt. Sie können diese Definitionen verwenden, um die Standards Ihrer Organisation zu erzwingen und die Compliance im Großen und Umfang zu bewerten. Das Azure-Richtliniendashboard zeigt Ergebnisse aus Azure-Richtlinienauswertungen an und informiert Sie über den Compliancestatus Ihrer Ressourcen. In dieser Architektur weist Azure Policy VMs Richtliniendefinitionen zu, wertet sie für Compliance aus, veröffentlicht Ergebnisse im Azure-Richtliniendashboard und schränkt DevOps-Teams auf die Verwendung von Compute Gallery-Bildern ein.

• Das Azure-Computerkonfigurationsfeature von Azure Policy bietet eine Möglichkeit zum dynamischen Überwachen oder Zuweisen von Konfigurationen zu Computern über Code. Die Konfigurationen umfassen in der Regel Umgebungs- oder Betriebssystemeinstellungen. In dieser Architektur überprüft die Azure-Maschinenkonfiguration die Konfigurationseinstellungen, die die Imageanpassung festlegt, und kennzeichnet im Azure-Richtliniendashboard VMs als nicht konform, wenn eine Konfigurationsabweichung auftritt.

Alternatives

• Sie können ein Nicht-Microsoft-Tool zum Verwalten der Compliance verwenden. Normalerweise müssen Sie einen Agent auf der Ziel-VM installieren und möglicherweise eine Lizenzgebühr bezahlen.

• Sie können benutzerdefinierte Skripterweiterungen verwenden, um Software auf VMs zu installieren oder virtuelle Computer nach der Bereitstellung zu konfigurieren. Jeder VM- oder VM-Skalierungssatz unterstützt nur eine benutzerdefinierte Skripterweiterung.

Szenario-Details

Compliance-Vorschriften, Sicherheitsstandards und akzeptable Risikostufen variieren je nach Organisation und Region.

Unterschiedliche Standards können bei der dynamischen Skalierung von Cloudumgebungen als in lokalen Systemen schwieriger zu befolgen sein. Wenn Teams DevOps-Methoden verwenden, legen sie häufig weniger Einschränkungen für die Erstellung von Azure-Ressourcen wie VMs fest. Diese Flexibilität erschwert die Compliance-Bemühungen.

Azure-Richtlinien und rollenbasierte Zugriffskontrollzuweisungen (RBAC) können Unternehmen dabei helfen, Standards für Azure-Ressourcen durchzusetzen. Bei virtuellen Computern gelten diese Steuerelemente jedoch nur für die Steuerebene oder die Route zur VM. Die Systemimages, die auf dem virtuellen Computer ausgeführt werden, stellen eine Sicherheitsrisiken dar. Einige Unternehmen verhindern, dass Entwickler auf VMs zugreifen, was die Flexibilität verringert und es schwierig macht, DevOps-Praktiken zu befolgen.

Diese Lösung verwendet VM Image Builder, Compute Gallery und Azure Policy zum Verwalten der VM-Compliance in Azure. Es verfolgt die Compliance, minimiert das Risiko von Systemimages, die auf virtuellen Computern ausgeführt werden, und unterstützt DevOps-Praktiken.

Mögliche Anwendungsfälle

Verwenden Sie diese Lösung, wenn Ihre Organisation VMs verwendet, und Sie müssen:

• Bereitstellen goldener Bilder für DevOps-Teams.

• Testen und überprüfen Sie Bilder, bevor Sie sie für DevOps-Teams verfügbar machen.

• Verfolgen Sie, welches Bild von jedem DevOps-Team verwendet wird.

• Erzwingen Sie Unternehmensstandards ohne Produktivitätsverlust.

• Stellen Sie sicher, dass DevOps-Teams die neuesten Imageversionen verwenden.

• Verwalten Sie die Einhaltung von Tierservern, die wartungsintensiv sind, und Rinderserver, die leicht austauschbar sind.

Approach

Die folgenden Abschnitte enthalten eine ausführliche Beschreibung des Lösungsansatzes.

Identifizieren von Haustieren und Vieh

DevOps-Teams verwenden eine Analogie zu Haustieren und Rindern , um Servicemodelle zu definieren. Um die Compliance eines virtuellen Computers nachzuverfolgen, bestimmen Sie zuerst, ob es sich um ein Haustier oder einen Rinderserver handelt:

• Tierserver erfordern eine erhebliche Aufmerksamkeit und sind nicht einfach zu ersetzen. Die Wiederherstellung eines Pet-Servers benötigt erhebliche Zeit und finanzielle Ressourcen. Beispielsweise kann ein Server, auf dem SAP ausgeführt wird, ein Pet-Server sein. Über die Software auf dem Server hinaus können andere Überlegungen das Dienstmodell bestimmen. Produktionsserver in Echtzeit und nahezu echtzeitbasierte Systeme können auch Haustiere sein, wenn Sie eine geringe Fehlertoleranz haben.

• Rinderserver sind Teil einer identischen Gruppe und leicht zu ersetzen. Beispielsweise sind virtuelle Computer, die in einer VM-Skalierungsgruppe ausgeführt werden, Rinder. Testumgebungsserver sind ein weiteres Beispiel für Rinder, wenn sie die folgenden Bedingungen erfüllen:

  • Sie verwenden ein automatisiertes Verfahren, um die Server von Grund auf neu zu erstellen.
  • Nachdem Sie die Tests ausgeführt haben, werden die Server außer Betrieb genommen.

Eine Umgebung kann nur Tierserver oder nur Rinderserver enthalten. Im Gegensatz dazu könnte es sich bei einer Gruppe von VMs in einer Umgebung um Pets handeln. Andere VMs in derselben Umgebung könnten als "Cattle" betrachtet werden.

Compliance-Anforderungen unterscheiden sich bei Haustier- und Viehumgebungen.

• Die Konformität von Pet-Servern kann schwieriger nachzuverfolgen sein als dies bei Cattle-Servern der Fall ist. In der Regel können nur DevOps-Teams die Konformität von Pet-Serverumgebungen und -servern nachverfolgen und aufrechterhalten. Diese Lösung erhöht die Sichtbarkeit des Status jedes Haustiers, damit jeder in der Organisation die Compliance nachverfolgen kann.

• Aktualisieren Sie für Rinderumgebungen die virtuellen Computer, und erstellen Sie sie regelmäßig neu, um die Compliance aufrechtzuerhalten. Sie können diesen Aktualisierungszyklus mit dem regelmäßigen Release-Rhythmus Ihres DevOps-Teams abstimmen.

Einschränken von Bildern

Erlauben Sie DevOps-Teams nicht, Marketplace-VM-Images zu verwenden. Erlauben Sie nur VM-Images zu, die von Compute Gallery veröffentlicht werden. Diese Einschränkung ist für die VM-Compliance von entscheidender Bedeutung. Sie können eine benutzerdefinierte Richtlinie in Azure Policy verwenden, um diese Einschränkung zu erzwingen. Ein Beispiel finden Sie unter Bildveröffentlichungen erlauben.

Im Rahmen dieser Lösung sollte vm Image Builder ein Marketplace-Image verwenden. Es ist wichtig, dass Sie das neueste verfügbare Image in Marketplace verwenden. Wenden Sie Ihre Anpassungen auf das Bild an. Marketplace-Bilder werden häufig aktualisiert und enthalten voreingestellte Konfigurationen, mit denen Ihre Bilder standardmäßig geschützt werden.

Anpassen von Bildern

Ein goldenes Bild ist eine angepasste Version eines Marketplace-Images, das Sie in der Compute Gallery für DevOps-Teams veröffentlichen. Anpassungsaktivitäten sind für jedes Unternehmen einzigartig. Zu den üblichen Aktivitäten gehören:

• Betriebssystemhärtung

• Bereitstellung von benutzerdefinierten Agents für Nicht-Microsoft-Software

• Installation von Stammzertifikaten der Unternehmenszertifizierungsstelle (Ca)

Sie können vm Image Builder verwenden, um Bilder anzupassen, indem Sie Betriebssystemeinstellungen anpassen und benutzerdefinierte Skripts und Befehle ausführen. VM Image Builder unterstützt Windows- und Linux-Images. Weitere Informationen finden Sie unter regulatorische Compliance-Kontrollen der Azure-Richtlinien für Azure Virtual Machines.

Verstärken Sie Bilder mithilfe des Trusted Launch

Über Anpassungen auf Anwendungsebene hinaus sollten "golden images" eine hardwarebasierte Vertrauenskette vom Boot bis zur Laufzeit einrichten. Der vertrauenswürdige Start stellt diese Grundlage für VMs der Generation 2 bereit. Konfigurieren Sie goldene Bilder mit diesen Funktionen für die vertrauenswürdige Einführung:

• Sicherer Start: Stellt sicher, dass nur signierte und vertrauenswürdige Betriebssystemladeprogramme, Kernel und Treiber während des Starts ausgeführt werden. Dieser Ansatz schützt vor Bootkits und Rootkits.

• Virtual Trusted Platform Module (vTPM): Emuliert ein Hardware Trusted Platform Module (TPM) innerhalb der VM und bietet sicheren Speicher für Verschlüsselungsschlüssel, Zertifikate und Startmessungen. vTPM unterstützt Szenarien wie BitLocker-Datenträgerverschlüsselung und kryptografische Gastnachweise.

• Startintegritätsüberwachung: Misst die gesamte Startkette und stellt Telemetriedaten für Microsoft Defender for Cloud bereit.

Bild-Tattoo-Verfolgung

Bild-Tattooing ist der Prozess der Verfolgung aller Bildversionsinformationen, die eine VM verwendet. Diese Informationen sind während der Problembehandlung von unschätzbarem Wert und können Folgendes umfassen:

• Die ursprüngliche Quelle des Bilds, z. B. der Name und die Version des Herausgebers.

• Die Betriebssystemversionszeichenfolge für ein direktes Upgrade.

• Die Version Ihres benutzerdefinierten Images.

• Ihr Veröffentlichungsdatum.

Die Menge und Art der Informationen, die Sie nachverfolgen, hängt von der Konformitätsebene Ihrer Organisation ab.

Für das Tätowieren von Images auf Windows-VMs richten Sie eine benutzerdefinierte Registrierung ein. Fügen Sie diesem Registrierungspfad alle erforderlichen Informationen als Schlüssel-Wert-Paare hinzu. Speichern Sie auf Linux-VMs Bildtätowierungsdaten in Umgebungsvariablen oder einer Datei. Platzieren Sie die Datei in dem /etc/ Ordner, in dem es keinen Konflikt mit Der Entwicklerarbeit oder -anwendungen gibt. Wenn Sie Azure Policy verwenden möchten, um die Tattooing-Daten nachzuverfolgen oder zu melden, speichern Sie jedes Datenelement als eindeutiges Schlüssel-Wert-Paar. Weitere Informationen finden Sie unter "Suchen einer Marketplace-Imageversion".

Generieren einer Software-Stückliste für goldene Images

Bild-Tattooing zeichnet Metadaten über das Bild auf, z. B. die Quelle, Version und das Veröffentlichungsdatum. Eine Software-Stückliste (SBOM) ergänzt das Tattooing-Verfahren, indem festgehalten wird, was das Bild enthält, z. B. Betriebssystempakete, Agenten, Bibliotheken und Patches. Dieser Bestand unterstützt die Reaktion auf Sicherheitsrisiken, Compliance-Audits und Lieferkettentransparenz.

Ein SBOM für Golden Images hilft auf folgende Arten:

• Schnellere Reaktion auf häufige Schwachstellen und Risiken (CVE): Wenn eine kritische Sicherheitsanfälligkeit offengelegt wird, identifiziert ein SBOM, welche Gold-Image-Versionen die betroffene Komponente enthalten.

• Regulatorische Compliance: Gesetze und Standards erfordern häufig SBOMs für Softwareartefakte. VM-Images sind Teil dieser Software-Lieferkette.

• Audit-Nachverfolgbarkeit: Wenn Sie Bild-Tattoos mit SBOMs koppeln, erhalten die Auditoren ein vollständiges Bild davon, welches Image eine VM ausführt und welche Softwarekomponenten das Image zum Zeitpunkt des Build-Prozesses enthält.

Generieren Sie das SBOM während des Image-Builds

Fügen Sie die SBOM-Generierung als Schritt in der VM Image Builder-Pipeline unmittelbar nach der Anpassung und vor der Überprüfung hinzu.

Verwenden Sie das Open-Source-Microsoft SBOM-Tool , um SBOMs im SPDX-Format zu generieren. Das Tool listet installierte Betriebssystempakete, Agents und Abhängigkeiten auf. Führen Sie das Tool auf dem angepassten Image als Anpassungsschritt des VM Image Builder oder als Skript nach der Anpassung in Ihrer Pipeline aus. Signieren Sie das generierte SBOM kryptografisch, um seine Integrität sicherzustellen.

Speichern Sie das SBOM zusammen mit dem Bild. Laden Sie das SBOM in ein Azure Storage-Konto oder einen Artefaktspeicher hoch, der mit der Compute Gallery-Imageversion verknüpft ist. Verwenden Sie eine konsistente Benennungskonvention, die jede SBOM-Datei ihrer Imagedefinition, Version und dem Erstellungsdatum zuordnet. Halten Sie das SBOM mindestens so lange verfügbar, wie die Bildversion verwendet wird.

Überprüfen goldener Bilder mithilfe automatisierter Tests

Im Allgemeinen sollten Sie goldene Bilder monatlich aktualisieren, um mit den neuesten Updates und Änderungen in Marketplace-Bildern aktuell zu bleiben. Verwenden Sie zu diesem Zweck ein wiederkehrendes Testverfahren. Verwenden Sie im Rahmen der Image-Erstellung eine Azure-Pipeline oder einen anderen automatisierten Workflow zum Testen. Richten Sie die Pipeline ein, um einen neuen virtuellen Computer bereitzustellen, um Tests vor Beginn jedes Monats auszuführen. Die Tests sollten vorbereitete Bilder bestätigen, bevor Sie sie für den Verbrauch veröffentlichen. Automatisieren Sie Tests mithilfe einer Testautomatisierungslösung oder ausführen von Befehlen oder Batches auf dem virtuellen Computer.

Zu den gängigen Testszenarien gehören:

• Überprüfen Sie die Startzeit des virtuellen Computers.

• Bestätigen Sie Image-Anpassungen, z. B. Betriebssystemeinstellungen oder Agentbereitstellungen.

Ein fehlgeschlagener Test sollte den Prozess unterbrechen. Wiederholen Sie den Test, nachdem Sie die Ursache des Problems behoben haben. Wenn die Tests reibungslos verlaufen, verringert die Automatisierung des Testprozesses den Aufwand, der zur Aufrechterhaltung eines konstant aktuellen Zustands erforderlich ist.

Veröffentlichen Sie Gold-Images

Veröffentlichen Sie endgültige Bilder in der Compute gallery als verwaltete Bilder, die DevOps-Teams verwenden können. Markieren Sie frühere Bilder als veraltet. Wenn Sie kein Enddatum für eine Bildversion in der Compute Gallery festgelegt haben, sollten Sie in Erwägung ziehen, das älteste Bild entsprechend den Richtlinien Ihres Unternehmens außer Betrieb zu nehmen.

Weitere Informationen zu Grenzwerten, die bei der Verwendung von Compute Gallery gelten, finden Sie unter Speichern und Freigeben von Bildern in Compute Gallery.

Das Veröffentlichen der neuesten Bilder in verschiedenen Regionen ist eine bewährte Methode. Sie können den Compute Gallery verwenden, um den Lebenszyklus und die Replikation Ihrer Bilder in verschiedenen Azure-Regionen zu verwalten.

Aktualisieren von Golden Images

Wenn eine Anwendung ein Image verwendet, kann das zugrunde liegende Betriebssystemimage mit den letzten Complianceänderungen schwierig aktualisiert werden. Strenge Geschäftsanforderungen können das Aktualisieren des zugrunde liegenden VMs erschweren. Das Aktualisieren ist auch für geschäftskritische VMs komplex.

Rinderserver sind verzichtbar, sodass Sie sich mit DevOps-Teams abstimmen können, um sie während eines geplanten Wartungsfensters routinemäßig zu aktualisieren.

Pet-Server sind schwieriger zu aktualisieren. Durch das Absetzen eines Images können Anwendungen gefährdet werden. In Skalierungsszenarien kann Azure die entsprechenden Bilder nicht finden, was zu Fehlern führt.

Beachten Sie beim Aktualisieren von Pet-Servern die folgenden Richtlinien:

• Bewährte Methoden finden Sie in der Übersicht über die Zuverlässigkeitssäulen im Azure Well-Architected Framework.

• Um den Prozess zu vereinfachen, lesen Sie die Prinzipien in den folgenden Artikeln:

  • Muster mit Bereitstellungsstempeln
  • Geode-Muster
  • Massenkopfmuster

• Markieren Sie jeden Pet-Server als „Pet“. Konfigurieren Sie eine Richtlinie in Der Azure-Richtlinie, um diese Kategorie während der Aktualisierungen zu berücksichtigen.

Notfallpatching für kritische Sicherheitsrisiken

Der monatliche goldene Bildaktualisierungsrhythmus eignet sich für Routineupdates, aber kritische Sicherheitsrisiken und CVEs erfordern Eine Aktion vor dem nächsten geplanten Zyklus. Richten Sie einen Out-of-Band-Notfall-Patchingprozess ein, der unabhängig vom monatlichen Rhythmus ausgeführt wird und bei Bedarf ausgelöst wird. Abonnieren Sie Azure Service Health - und Microsoft Security Response Center-Benachrichtigungen für CVE-Warnungen, die sich auf Ihre Basisimages auswirken.

Wenn sich ein kritisches CVE auf ein veröffentlichtes goldenes Image auswirkt, reagieren Sie sofort, um die Bereitstellung neuer VMs mit der anfälligen Version zu verhindern. Markieren Sie zunächst die betroffene Bildversion als ausgeschlossen von der Bildversion, die Azure auswählt, wenn Benutzer oder Automatisierung die neueste Version anfordern. Legen Sie in der Compute Gallery die excludeFromLatest-Eigenschafttrue auf jede betroffene Bildversion fest. Nach dieser Änderung erhalten Automatisierung und Benutzer, die die neueste verfügbare Version anfordern, die anfällige Version nicht mehr. Verwenden Sie die Beschreibung der Azure-Richtlinienzuweisung, um einen Link zu einem Runbook oder einem internen Wiki zu erstellen, in dem die CVE, die betroffenen Bildversionen und die erforderlichen Korrekturaktionen aufgeführt sind.

Auslösen eines OOB-Image-Builds

Verwenden Sie dieselbe VM Image Builder-Pipeline, die das monatliche Golden Image erstellt, und lösen Sie sie bei Bedarf aus.

1. Wenden Sie den Sicherheitspatch an. Fügen Sie den kritischen Fix dem Image-Anpassungsprozess als ein Betriebssystemupdate, eine Konfigurationsänderung, oder ein Skript hinzu, das die spezifische Sicherheitsanfälligkeit behebt.

2. Führen Sie die automatisierte Testsuite aus. Überspringen Sie die Überprüfung nicht. Die gleichen Tests, die während des monatlichen Zyklus durchgeführt werden, sollten für Notfall-Builds durchgeführt werden.

3. Veröffentlichen Sie das gepatchte Bild. Veröffentlichen Sie die neue Bildversion im Compute Gallery, und replizieren Sie sie in alle erforderlichen Regionen. Die betroffene Version wird von der neuesten Versionsauswahl ausgeschlossen, sodass die gepatchte Version automatisch zur Version wird, die von neuen Bereitstellungen verwendet wird.

4. Aktualisieren Sie das Bild-Tattoo. Notieren Sie den OOB-Charakter des Updates im Image-Tattoo, und schließen Sie den CVE-Bezeichner, das Patchdatum und ein Kennzeichen ein, das es von einer geplanten monatlichen Veröffentlichung unterscheidet. Diese Daten unterstützen Complianceüberwachungen.

Verbessern der Sichtbarkeit

Im Allgemeinen sollten Sie Azure-Richtlinie verwenden, um Complianceaktivitäten auf Steuerungsebene zu verwalten. Sie können azure Policy auch verwenden, um die folgenden Aufgaben auszuführen:

• Nachverfolgen der VM-Compliance.

• Installieren Sie Azure-Agents. Verwenden Sie den Azure Monitor-Agent für die Überwachung.

• Erfassen Sie Diagnoseprotokolle.

• Verbessern Sie die Sichtbarkeit der VM-Compliance.

Verwenden Sie die Azure-Computerkonfiguration, um Konfigurationsänderungen zu überwachen, die Sie während der Imageanpassung vornehmen. Wenn die Abweichung auftritt, listet das Azure-Richtliniendashboard die betroffene VM als nicht konform auf. Azure Policy kann sogenannte Bild-Tattooing-Informationen verwenden, um nachzuverfolgen, wann Sie veraltete Images oder Betriebssysteme verwenden.

Überprüfen Sie die Pet-Server für jede Anwendung. Sie können die Sichtbarkeit dieser Server verbessern, indem Sie Azure-Richtlinien verwenden, die den Überwachungseffekt haben. Passen Sie den Auditprozess entsprechend den akzeptablen Risiko- und internen Risikomanagementprozessen Ihres Unternehmens an.

Jedes DevOps-Team kann die Konformitätsebenen seiner Anwendungen im Azure Policy-Dashboard nachverfolgen und entsprechende Korrekturmaßnahmen ergreifen. Wenn Sie diese Richtlinien einer Verwaltungsgruppe oder einem Abonnement zuweisen, fügen Sie eine URL zu unternehmensweiten Dokumentationen zur Richtlinie in die Zuordnungsbeschreibung ein. Ihre Dokumentation sollte die Schritte auflisten, die DevOps-Teams ausführen sollten, um ihre VMs kompatibel zu machen.

IT-Risikomanager und Sicherheitsbeauftragte können auch das Azure-Richtliniendashboard verwenden, um Unternehmensrisiken gemäß dem zulässigen Risikoniveau ihres Unternehmens zu verwalten.

Azure-Computerkonfiguration mit Korrekturoptionen wendet automatisch Korrekturmaßnahmen an. Häufige Abfragen oder Änderungen an einem virtuellen Computer, den Sie für eine geschäftskritische Anwendung verwenden, können sich jedoch auf die Leistung auswirken. Planen Sie Korrekturmaßnahmen für Produktions-Workloads stets sorgfältig. Weisen Sie einem DevOps-Team den Besitz der Anwendungscompliance in allen Umgebungen zu. Verwenden Sie diesen Ansatz für Pet-Server und Umgebungen, die in der Regel langfristige Azure-Komponenten sind.

Bewährte Methoden für goldene Bildhygiene

Ein gut strukturierter Imagebuildprozess verhindert häufige Fehler, die zu Sicherheitsvorfällen, Konfigurationsabweichungen und betrieblichen Reibungen führen. Befolgen Sie die folgenden Richtlinien, wenn Sie goldene Bilder anpassen und verwalten:

• Verstecken Sie niemals Geheimnisse in Bildern. Betten Sie keine API-Schlüssel, Verbindungszeichenfolgen, Kennwörter, privaten Schlüssel von Zertifikaten oder Token in das Bild ein. Wenn Sie geheime Schlüssel in ein Image einbetten, machen Sie sie für jeden virtuellen Computer verfügbar, der das Image verwendet, und allen Personen, die Lesezugriff auf compute Gallery haben. Rufen Sie stattdessen Geheimnisse in der Laufzeit aus Azure Key Vault mithilfe einer verwalteten Identität ab.

• Bevorzugen Sie die externe Konfiguration gegenüber hartcodierten Werten. Externe Einstellungen, die sich zwischen Umgebungen oder vor der nächsten Image-Erstellung ändern können, z. B. Endpunkte, Feature-Flags, regionale Einstellungen oder Log-Level. Reservieren Sie die Imageanpassung für Einstellungen, die für alle Bereitstellungen statisch und universell sind.

• Minimieren Sie den Softwarebedarf. Installieren Sie nur Komponenten, die jeder Verbraucher des Images benötigt. Stellen Sie zusätzliche Tools bereit, die speziell für einen einzelnen Anwendungsfall oder eine Arbeitsauslastung nach der Bereitstellung mithilfe von Erweiterungen oder der Konfigurationsverwaltung spezifisch sind. Ein geringerer Speicherbedarf reduziert die Angriffsfläche und die Anzahl der Komponenten, die Patching erfordern.

• Schließen Sie Anwendungscode und Bereitstellungsartefakte aus dem Image aus. Goldene Images sollten eine sichere, gesetzeskonforme Betriebssystem-Grundlage bereitstellen. Stellen Sie Anwendungscode separat über kontinuierliche Integrations- und Bereitstellungspipelines (CI/CD) bereit. Diese Trennung sorgt dafür, dass der Bildlebenszyklus und der Anwendungslebenszyklus unabhängig sind.

• Verwenden Sie deterministische, wiederholbare Buildskripts. Fixieren Sie Paketversionen in Ihren Anpassungsskripten. Vermeiden Sie Befehle wie apt-get upgrade oder yum update die unterschiedliche Bilder an unterschiedlichen Buildtagen erzeugen können.

Considerations

Diese Überlegungen bilden die Säulen des Azure Well-Architected Framework, einer Reihe von Leitprinzipien, die Sie zur Verbesserung der Qualität eines Workloads verwenden können. Weitere Informationen finden Sie unter Well-Architected Framework.

Reliability

Zuverlässigkeit trägt dazu bei, dass Ihre Anwendung die Verpflichtungen erfüllen kann, die Sie für Ihre Kunden vornehmen. Weitere Informationen finden Sie unter Prüfliste zur Entwurfsüberprüfung für Zuverlässigkeit.

Diese Lösung verwendet verwaltete Komponenten, die auf regionaler Ebene automatisch resilient sind. Weitere Informationen finden Sie unter Entwerfen robuster Anwendungen für Azure.

Sie können die Anzahl der Replikate jedes Bilds konfigurieren, das der Compute Gallery speichert. Eine höhere Anzahl von Replikaten reduziert das Risiko einer Drosselung, wenn Sie mehrere virtuelle Maschinen gleichzeitig bereitstellen. Weitere Informationen finden Sie unter "Skalierung für Compute Gallery".

Kostenoptimierung

Die Kostenoptimierung konzentriert sich auf Möglichkeiten, unnötige Ausgaben zu reduzieren und die betriebliche Effizienz zu verbessern. Weitere Informationen finden Sie unter Prüfliste für die Überprüfung der Kostenoptimierung.

Wenn Sie nur Microsoft-Dienste verwenden, können Sie die zusätzlichen Kosten von Nicht-Microsoft-Tools wie Ansible oder Terraform vermeiden. Azure-Gebühren können jedoch weiterhin für Speicher-, Ausgangs-, Imageerstellungs-, Replikations- und Hybridressourcen gelten. Andere mögliche Gebühren umfassen die folgenden Komponenten:

• Die Azure-Richtlinie und die Azure-Computerkonfiguration sind für Azure-Ressourcen kostenlos. Wenn Ihr Unternehmen einen Hybridansatz verwendet, fügen Azure Arc-Ressourcen zusätzliche Gebühren hinzu.

• VM Image Builder verwendet einen einzelnen Computeinstanztyp mit 1 vCPU und 3,5 GB RAM. Für die Datenspeicherung und -übertragung können Gebühren anfallen.

• Compute Gallery verursacht nur Gebühren für Replikatspeicherung und den Netzwerkausgangsverkehr im Zusammenhang mit der Replikation von Bildern.

Contributors

Dieser Artikel wird von Microsoft gepflegt. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautor:

• Yunus Emre Alpozen | Program Architect

Um nicht öffentliche LinkedIn-Profile zu sehen, melden Sie sich bei LinkedIn an.

Nächste Schritte

• Azure-Zielzone
• Einführung in die Cloudinfrastruktur
• VM Image Builder
• Rechnergalerie
• Azure Policy und das Policy-Dashboard
• Azure-Computerkonfiguration

Verwandte Ressourcen

• DevTest und DevOps für Infrastruktur als Service (IaaS)-Lösungen
• DevSecOps in AKS