Sicherheitsüberlegungen für unternehmenskritische Workloads

Unternehmenskritische Workloads müssen inhärent gesichert werden. Wenn eine Anwendung oder ihre Infrastruktur kompromittiert ist, ist die Verfügbarkeit gefährdet. Der Schwerpunkt der vorliegenden Architektur liegt auf der Maximierung der Zuverlässigkeit, um zu gewährleisten, dass die Anwendung unter allen Umständen leistungsfähig und verfügbar bleibt. Sicherheitskontrollen werden in erster Linie mit dem Zweck angewendet, Bedrohungen zu verringern, die sich auf Verfügbarkeit und Zuverlässigkeit auswirken.

Hinweis

Ihre geschäftlichen Anforderungen benötigen möglicherweise mehr Sicherheitsmaßnahmen. Es wird dringend empfohlen, die Steuerelemente in Ihrer Implementierung entsprechend den Anleitungen in Azure Well-Architected Framework-Sicherheitsüberlegungen für unternehmenskritische Workloads zu erweitern.

Identitäts- und Zugriffsverwaltung

Auf der Ebene der Anwendung verwendet diese Architektur ein einfaches Authentifizierungsschema auf der Grundlage von API-Schlüsseln für einige eingeschränkte Vorgänge, wie das Erstellen von Katalogelementen oder das Löschen von Kommentaren. Erweiterte Szenarien wie Benutzerauthentifizierung und Benutzerrollen gehen über den Umfang der Basisarchitektur hinaus.

Wenn Ihre Anwendung benutzerauthentifizierung und Kontoverwaltung erfordert, befolgen Sie die Empfehlungen für die Identitäts- und Zugriffsverwaltung. Einige Strategien umfassen die Verwendung von verwalteten Identitätsanbietern, das Vermeiden der benutzerdefinierten Identitätsverwaltung und die Verwendung kennwortloser Authentifizierung, wenn möglich.

Zugriff mit den geringsten Rechten

Konfigurieren Sie Zugriffsrichtlinien so, dass Benutzer und Anwendungen den minimalen Zugriff erhalten, den sie benötigen, um ihre Funktion zu erfüllen. Entwickler benötigen in der Regel keinen Zugriff auf die Produktionsinfrastruktur, aber die Bereitstellungspipeline benötigt vollständigen Zugriff. Kubernetes-Cluster pushen in der Regel keine Containerimages in eine Registrierung, GitHub-Workflows hingegen schon. Front-End-APIs erhalten in der Regel keine Nachrichten vom Nachrichtenbroker, und Back-End-Mitarbeiter senden nicht unbedingt neue Nachrichten an den Broker. Diese Entscheidungen hängen von der Arbeitsauslastung ab, und die Zugriffsstufe, die Sie zuweisen, sollte die Funktionalität der einzelnen Komponenten widerspiegeln.

Beispiele aus der unternehmenskritischen Azure-Referenzimplementierung sind:

• Jede Anwendungskomponente, die mit Azure Event Hubs arbeitet, verwendet eine Verbindungszeichenfolge entweder mit Listenberechtigungen () oder Senden (BackgroundProcessor) (CatalogService). Diese Zugriffsebene stellt sicher, dass jeder Pod nur den minimalen Zugriff hat, der für die Erfüllung seiner Funktion erforderlich ist.
• Der Dienstprinzipal für den Azure Kubernetes Service (AKS)-Agentpool verfügt nur über die Berechtigungen "Abrufen " und "Auflisten " für Geheime Schlüssel im Azure Key Vault.
• Die AKS Kubelet-Identität verfügt nur über die AcrPull-Berechtigung für den Zugriff auf die globale Containerregistrierung.

Verwaltete Identitäten

Um die Sicherheit einer unternehmenskritischen Workload zu verbessern, vermeiden Sie nach Möglichkeit die Verwendung dienstbasierter geheimer Schlüssel, z. B. Verbindungszeichenfolge oder API-Schlüssel. Es wird empfohlen, verwaltete Identitäten zu verwenden, wenn der Azure-Dienst diese Funktion unterstützt.

Die Referenzimplementierung verwendet eine vom Dienst zugewiesene verwaltete Identität im AKS-Agentpool ("Kubelet-Identität"), um auf die globale Azure-Containerregistrierung und den Schlüsseltresor eines Stempels zuzugreifen. Geeignete integrierte Rollen werden verwendet, um den Zugriff zu beschränken. Dieser Terraform-Code weist beispielsweise nur die Rolle der AcrPull Kubelet-Identität zu:

resource "azurerm_role_assignment" "acrpull_role" {
  scope                = data.azurerm_container_registry.global.id
  role_definition_name = "AcrPull"
  principal_id         = azurerm_kubernetes_cluster.stamp.kubelet_identity.0.object_id
}

Geheimnisse

Verwenden Sie nach Möglichkeit die Microsoft Entra-Authentifizierung anstelle von Schlüsseln, wenn Sie auf Azure-Ressourcen zugreifen. Viele Azure-Dienste wie Azure Cosmos DB und Azure Storage unterstützen die Option, die Schlüsselauthentifizierung vollständig zu deaktivieren. AKS unterstützt die Microsoft Entra Workload-ID.

Für Szenarien, in denen Sie die Microsoft Entra-Authentifizierung nicht verwenden können, verfügt jeder Bereitstellungsstempel über eine dedizierte Instanz von Key Vault zum Speichern von Schlüsseln. Diese Schlüssel werden während der Bereitstellung automatisch erstellt und in Key Vault mit Terraform gespeichert. Kein menschlicher Operator, mit Ausnahme von Entwicklern in End-to-End-Umgebungen, kann mit geheimen Schlüsseln interagieren. Darüber hinaus sind Key Vault-Zugriffsrichtlinien so konfiguriert, dass keine Benutzerkonten auf geheime Schlüssel zugreifen dürfen.

Hinweis

Diese Workload verwendet keine benutzerdefinierten Zertifikate, aber die gleichen Prinzipien gelten.

Im AKS-Cluster ermöglicht der Key Vault-Anbieter für den geheimen Speicher die Anwendung, geheime Schlüssel zu nutzen. Der CSI-Treiber lädt Schlüssel aus Key Vault und stellt sie als Dateien in einzelne Pods ein.

#
# /src/config/csi-secrets-driver/chart/csi-secrets-driver-config/templates/csi-secrets-driver.yaml
#
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: azure-kv
spec:
  provider: azure
  parameters:
    usePodIdentity: "false"
    useVMManagedIdentity: "true"
    userAssignedIdentityID: {{ .Values.azure.managedIdentityClientId | quote }}
    keyvaultName: {{ .Values.azure.keyVaultName | quote }}
    tenantId: {{ .Values.azure.tenantId | quote }}
    objects: |
      array:
        {{- range .Values.kvSecrets }}
        - |
          objectName: {{ . | quote }}
          objectAlias: {{ . | lower | replace "-" "_" | quote }}
          objectType: secret
        {{- end }}

Die Referenzimplementierung verwendet Helm mit Azure Pipelines, um den CSI-Treiber bereitzustellen, der alle Schlüsselnamen aus Key Vault enthält. Der Treiber ist auch für die Aktualisierung von bereitgestellten geheimen Schlüsseln verantwortlich, wenn sie sich im Key Vault ändern.

Auf der Consumerseite verwenden beide .NET-Anwendungen die integrierte Funktionalität, die Konfiguration aus Dateien zu lesen (AddKeyPerFile):

//
// /src/app/AlwaysOn.BackgroundProcessor/Program.cs
// + using Microsoft.Extensions.Configuration;
//
public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
    .ConfigureAppConfiguration((context, config) =>
    {
        // Load values from Kubernetes CSI Key Vault driver mount point.
        config.AddKeyPerFile(directoryPath: "/mnt/secrets-store/", optional: true, reloadOnChange: true);
        
        // More configuration if needed...
    })
    .ConfigureWebHostDefaults(webBuilder =>
    {
        webBuilder.UseStartup<Startup>();
    });

Die Kombination der automatischen Neuladevorgänge des CSI-Treibers und reloadOnChange: true trägt dazu bei, dass die neuen Werte beim Ändern der Schlüssel im Key Vault auf dem Cluster bereitgestellt werden. Dieser Prozess garantiert keine geheime Drehung in der Anwendung. Die Implementierung verwendet eine Singleton Azure Cosmos DB-Clientinstanz, für die der Pod neu gestartet werden muss, um die Änderung anzuwenden.

Benutzerdefinierte Domänen und TLS

Webbasierte Workloads sollten HTTPS verwenden, um Man-in-the-Middle-Angriffe auf alle Interaktionsebenen zu verhindern, z. B. kommunikation vom Client an die API oder von API zu API. Stellen Sie sicher, dass Sie die Zertifikatrotation automatisieren, da abgelaufene Zertifikate immer noch eine häufige Ursache für Ausfälle und beeinträchtigte Erfahrungen sind.

Die Referenzimplementierung unterstützt vollständig HTTPS mit benutzerdefinierten Domänennamen, z contoso.com. B. . Sie wendet auch die entsprechende Konfiguration sowohl auf die Als prod auch auf die int Umgebungen an. Sie können auch benutzerdefinierte Domänen für e2e Umgebungen hinzufügen. Diese Referenzimplementierung verwendet jedoch keine benutzerdefinierten Domänennamen aufgrund der kurzlebigen Art und e2e der erhöhten Bereitstellungszeit, wenn Sie benutzerdefinierte Domänen mit SSL-Zertifikaten in Azure Front Door verwenden.

Um die vollständige Automatisierung der Bereitstellung zu aktivieren, sollten Sie die benutzerdefinierte Domäne über eine Azure DNS-Zone verwalten. Die Pipeline für die Infrastrukturbereitstellung erstellt dynamisch CNAME-Einträge in der Azure DNS-Zone und ordnet diese Einträge automatisch einer Azure Front Door-Instanz zu.

Azure Front Door-verwaltete SSL-Zertifikate sind aktiviert, wodurch die Anforderung für manuelle SSL-Zertifikatverlängerungen entfernt wird. TLS 1.2 ist als Mindestversion konfiguriert.

#
# /src/infra/workload/globalresources/frontdoor.tf
#
resource "azurerm_frontdoor_custom_https_configuration" "custom_domain_https" {
  count                             = var.custom_fqdn != "" ? 1 : 0
  frontend_endpoint_id              = "${azurerm_frontdoor.main.id}/frontendEndpoints/${local.frontdoor_custom_frontend_name}"
  custom_https_provisioning_enabled = true

  custom_https_configuration {
    certificate_source = "FrontDoor"
  }
}

Auf Umgebungen, die nicht mit benutzerdefinierten Domänen bereitgestellt werden, kann über den standardmäßigen Azure Front Door-Endpunkt zugegriffen werden. Sie können sie z. B. an einer Adresse wie env123.azurefd.net.

Hinweis

Für den Eingangsdatencontroller des Clusters werden in beiden Fällen keine benutzerdefinierten Domänen verwendet. Stattdessen wird ein von Azure bereitgestellter DNS-Name verwendet, [prefix]-cluster.[region].cloudapp.azure.com z. B. mit Let's Encrypt, der kostenlose SSL-Zertifikate für diese Endpunkte ausstellen kann.

Die Referenzimplementierung verwendet Jetstacks cert-manager zum automatischen Bereitstellen von SSL/TLS-Zertifikaten aus Let's Encrypt für Eingangsregeln. Weitere Konfigurationseinstellungen wie die ClusterIssuer, die Zertifikate von Let's Encrypt anfordert, werden über ein separates cert-manager-config Steuerdiagramm bereitgestellt, das in src/config/cert-manager/chart gespeichert ist.

Diese Implementierung verwendet ClusterIssuer anstelle von Issuer Ausstellern für jeden Namespace zu vermeiden. Weitere Informationen finden Sie in der Zertifikat-Manager-Dokumentation und den Versionshinweisen des Zertifikat-Managers.

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-staging
spec:
  acme:

Konfiguration

Alle Anwendungslaufzeitkonfigurationen werden im Key Vault gespeichert, einschließlich geheimer Schlüssel und nicht sensibler Einstellungen. Sie können einen Konfigurationsspeicher verwenden, z. B. Azure App Configuration, um die Einstellungen zu speichern. Das Vorhandensein eines einzelnen Speichers reduziert jedoch die Anzahl potenzieller Fehlerpunkte für unternehmenskritische Anwendungen. Verwenden Sie Key Vault für die Laufzeitkonfiguration, um die allgemeine Implementierung zu vereinfachen.

Schlüsseltresor sollten von der Bereitstellungspipeline ausgefüllt werden. In der Implementierung werden die erforderlichen Werte entweder direkt aus Terraform bezogen (z. B. Verbindungszeichenfolgen für Datenbanken) oder als Terraform-Variablen aus der Bereitstellungspipeline übergeben.

Infrastruktur- und Bereitstellungskonfiguration einzelner Umgebungen, ze2eint. B. , und prod, werden in Variablendateien gespeichert, die Teil des Quellcode-Repositorys sind. Dieser Ansatz hat zwei Vorteile:

• Alle Änderungen in einer Umgebung werden nachverfolgt und durchlaufen die Bereitstellungspipelines, bevor sie auf die Umgebung angewendet werden.
• Einzelne e2e Umgebungen können unterschiedlich konfiguriert werden, da die Bereitstellung auf Code in einer Verzweigung basiert.

Eine Ausnahme bildet die Speicherung vertraulicher Werte für Pipelines. Diese Werte werden als Geheimnisse in Azure DevOps-Variablengruppen gespeichert.

Containersicherheit

Es ist erforderlich, Containerimages für alle containerisierten Workloads zu sichern.

Diese Referenzimplementierung verwendet Workload-Docker-Container, die auf Laufzeitimages basieren, nicht auf SDK, um den Speicherbedarf und die potenzielle Angriffsfläche zu minimieren. Es sind keine anderen Tools wie ping, oder wgetcurl, installiert.

Die Anwendung wird unter einem nicht privilegierten Benutzer workload ausgeführt, der als Teil des Imagebuildprozesses erstellt wurde:

RUN groupadd -r workload && useradd --no-log-init -r -g workload workload
USER workload

Die Referenzimplementierung verwendet Helm zum Packen der YAML-Manifeste, die zum Bereitstellen einzelner Komponenten erforderlich sind. Dieser Prozess umfasst die Kubernetes-Bereitstellung, Dienste, die Automatische Skalierungskonfiguration für horizontale Pods und den Sicherheitskontext. Alle Helm-Diagramme enthalten grundlegende Sicherheitsmaßnahmen, die kubernetes bewährte Methoden befolgen.

Zu diesen Sicherheitsmechanismen gehören:

• readOnlyFilesystem: Die Stammdateisystem / in jedem Container ist auf schreibgeschützt festgelegt, um zu verhindern, dass der Container in das Hostdateisystem schreibt. Diese Einschränkung hindert Angreifer daran, weitere Tools herunterzuladen und Code im Container zu speichern. Verzeichnisse, die Lese- und Schreibzugriff erfordern, werden als Volumes eingebunden.
• privileged: Alle Container sind so festgelegt, dass sie als nicht privilegierter Container ausgeführt werden. Das Ausführen eines Containers als privilegierter Container bietet dem Container alle Funktionen und hebt auch alle Einschränkungen auf, die der Gerätesteuerungsgruppencontroller erzwingt.
• allowPrivilegeEscalation: Verhindert, dass die Komponenten in einem Container mehr Privilegien erhalten als der übergeordnete Prozess.

Diese Sicherheitsmaßnahmen sind auch für Nicht-Microsoft-Container und Helm-Diagramme wie cert-manager möglich konfiguriert. Sie können Azure-Richtlinie verwenden, um diese Sicherheitsmaßnahmen zu überwachen.

#
# Example:
# /src/app/charts/backgroundprocessor/values.yaml
#
containerSecurityContext:
  privileged: false
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false

Jede Umgebung, einschließlich prod, intund jede e2e Umgebung, verfügt über eine dedizierte Instanz der Containerregistrierung, die über eine globale Replikation für die einzelnen Regionen verfügt, in denen Stempel bereitgestellt werden.

Hinweis

Diese Referenzimplementierung verwendet keine Sicherheitsrisikoüberprüfung von Docker-Images. Es wird empfohlen, Microsoft Defender für Containerregistrierungen zu verwenden, möglicherweise mit GitHub-Aktionen.

Eingehender Datenverkehr

Für den globalen Lastenausgleich in dieser Architektur sorgt Azure Front Door. Alle Webanforderungen werden über Azure Front Door weitergeleitet, wodurch das entsprechende Back-End ausgewählt wird. Unternehmenskritische Anwendungen sollten andere Azure Front Door-Funktionen nutzen, z. B. Webanwendungsfirewalls (WAFs).

Web Application Firewall

Eine wichtige Azure Front Door-Funktion ist die WAF, da azure Front Door den Datenverkehr überprüfen kann, der durchläuft. Im Präventionsmodus werden alle verdächtigen Anforderungen blockiert. In der Implementierung werden zwei Regelsätze konfiguriert. Diese Regelsätze sind Microsoft_DefaultRuleSet und Microsoft_BotManagerRuleSet.

Tipp

Wenn Sie Azure Front Door mit WAF bereitstellen, empfehlen wir, mit dem Erkennungsmodus zu beginnen. Überwachen Sie ihr Verhalten eng mit dem natürlichen Kundenverkehr und optimieren Sie die Erkennungsregeln. Nachdem Sie falsch positive Ergebnisse beseitigt haben oder falsch positive Ergebnisse selten sind, wechseln Sie zum Präventionsmodus . Dieser Vorgang ist erforderlich, da jede Anwendung anders ist und einige Nutzlasten als böswillig betrachtet werden können, auch wenn sie für diese bestimmte Arbeitsauslastung legitim sind.

Routing

Nur die Anforderungen, die über Azure Front Door kommen, werden an die API-Container weitergeleitet, z CatalogService . B. und HealthService. Verwenden Sie eine Nginx-Eingangskonfiguration, um dieses Verhalten zu erzwingen. Es überprüft das Vorhandensein eines X-Azure-FDID Headers und ob es das richtige für die globale Azure Front Door-Instanz einer bestimmten Umgebung ist.

#
# /src/app/charts/catalogservice/templates/ingress.yaml
#
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  # ...
  annotations:
    # To restrict traffic coming only through our Azure Front Door instance, we use a header check on the X-Azure-FDID.
    # The pipeline injects the value. Therefore, it's important to treat this ID as a sensitive value.
    nginx.ingress.kubernetes.io/modsecurity-snippet: |
      SecRuleEngine On
      SecRule &REQUEST_HEADERS:X-Azure-FDID \"@eq 0\"  \"log,deny,id:106,status:403,msg:\'Front Door ID not present\'\"
      SecRule REQUEST_HEADERS:X-Azure-FDID \"@rx ^(?!{{ .Values.azure.frontdoorid }}).*$\"  \"log,deny,id:107,status:403,msg:\'Wrong Front Door ID\'\"
  # ...

Bereitstellungspipelines helfen sicherzustellen, dass dieser Header ordnungsgemäß ausgefüllt ist, aber auch diese Einschränkung für Rauchtests umgehen muss, da sie jeden Cluster direkt statt über Azure Front Door testen. Die Referenzimplementierung verwendet die Tatsache, dass Rauchtests als Teil der Bereitstellung ausgeführt werden. Mit diesem Design kann der Headerwert bekannt sein und den Rauchtest-HTTP-Anforderungen hinzugefügt werden.

#
# /.ado/pipelines/scripts/Run-SmokeTests.ps1
#
$header = @{
  "X-Azure-FDID" = "$frontdoorHeaderId"
  "TEST-DATA"  = "true" # Header to indicate that posted comments and ratings are for tests and can be deleted again by the app.
}

Sichere Bereitstellungen

Um die grundlegenden gut durchdachten Prinzipien für die operative Exzellenz zu befolgen, automatisieren Sie alle Bereitstellungen vollständig. Sie sollten keine manuellen Schritte erfordern, außer die Ausführung auszulösen oder ein Gate zu genehmigen.

Sie müssen böswillige Versuche oder versehentliche Fehlkonfigurationen verhindern, die Sicherheitsmaßnahmen deaktivieren können. Die Referenzimplementierung verwendet dieselbe Pipeline sowohl für die Infrastruktur als auch für die Anwendungsbereitstellung, wodurch ein automatisiertes Rollback möglicher Konfigurationsabweichungen erzwungen wird. Dieses Rollback trägt dazu bei, die Integrität der Infrastruktur und ausrichtung mit dem Anwendungscode aufrechtzuerhalten. Alle Änderungen werden bei der nächsten Bereitstellung verworfen.

Terraform generiert vertrauliche Werte für die Bereitstellung während der Pipelineausführung, oder Azure DevOps liefert sie als geheime Schlüssel. Diese Werte werden durch rollenbasierte Zugriffsbeschränkungen geschützt.

Hinweis

GitHub-Workflows bieten ein ähnliches Konzept separater Speicher für geheime Werte. Geheime Schlüssel sind verschlüsselte Umgebungsvariablen, die GitHub-Aktionen verwenden können.

Es ist wichtig, auf alle Artefakte zu achten, die die Pipeline erzeugt, da diese Artefakte potenziell geheime Werte oder Informationen zu den inneren Arbeiten der Anwendung enthalten können. Die Azure DevOps-Bereitstellung der Referenzimplementierung generiert zwei Dateien mit Terraform-Ausgaben. Eine Datei ist für Stempel und eine Datei für die globale Infrastruktur vorgesehen. Diese Dateien enthalten keine Kennwörter, die die Infrastruktur gefährden könnten. Sie sollten diese Dateien jedoch als vertraulich betrachten, da sie Informationen über die Infrastruktur offenlegen, einschließlich Cluster-IDs, IP-Adressen, Speicherkontonamen, Key Vault-Namen, Azure Cosmos DB-Datenbanknamen und Azure Front Door-Header-IDs.

Für Workloads, die Terraform verwenden, müssen Sie zusätzlichen Aufwand in den Schutz der Zustandsdatei setzen, da sie den vollständigen Bereitstellungskontext enthält, einschließlich geheimer Schlüssel. Die Statusdatei wird in der Regel in einem Speicherkonto gespeichert, das einen separaten Lebenszyklus von der Workload aufweisen sollte und nur über eine Bereitstellungspipeline zugänglich sein sollte. Sie sollten alle anderen Zugriffe auf diese Datei protokollieren und Benachrichtigungen an die entsprechende Sicherheitsgruppe senden.

Updates für Abhängigkeiten

Bibliotheken, Frameworks und Tools, die die Anwendung verwendet, werden im Laufe der Zeit aktualisiert. Es ist wichtig, diese Updates regelmäßig abzuschließen, da sie häufig Korrekturen für Sicherheitsprobleme enthalten, die Angreifern unbefugten Zugriff auf das System gewähren können.

Die Referenzimplementierung verwendet GitHubs Dependabot für NuGet-, Docker-, npm-, Terraform- und GitHub-Aktionsabhängigkeitsupdates. Die dependabot.yml Konfigurationsdatei wird aufgrund der Komplexität der verschiedenen Teile der Anwendung automatisch mit einem PowerShell-Skript generiert. Beispielsweise benötigt jedes Terraform-Modul einen separaten Eintrag.

#
# /.github/dependabot.yml
#
version: 2
updates:
- package-ecosystem: "nuget"
  directory: "/src/app/AlwaysOn.HealthService"
  schedule:
    interval: "monthly" 
  target-branch: "component-updates" 

- package-ecosystem: "docker"
  directory: "/src/app/AlwaysOn.HealthService"
  schedule:
    interval: "monthly" 
  target-branch: "component-updates" 

# ... the rest of the file...

• Updates werden monatlich ausgelöst, um einen Kompromiss zwischen den neuesten Bibliotheken und einem überschaubaren Wartungsaufwand zu finden. Darüber hinaus werden wichtige Tools wie Terraform kontinuierlich überwacht, und wichtige Updates werden manuell ausgeführt.
• Pullanforderungen (PRs) zielen auf die component-updates Verzweigung anstelle von main.
• Npm-Bibliotheken sind so konfiguriert, dass nur Abhängigkeiten überprüft werden, die zur kompilierten Anwendung wechseln, anstatt Tools wie @vue-cli.

Dependabot erstellt eine separate PR für jedes Update, was das Betriebsteam überwältigen kann. Die Referenzimplementierung sammelt zuerst einen Batch von Updates in der component-updates Verzweigung und führt dann Tests in der e2e Umgebung aus. Wenn diese Tests erfolgreich sind, wird eine weitere PR erstellt, die auf die main Verzweigung ausgerichtet ist.

Defensive Programmierung

API-Aufrufe können aus verschiedenen Gründen fehlschlagen, z. B. Codefehler, fehlerhafte Bereitstellungen und Infrastrukturfehler. Wenn ein API-Aufruf fehlschlägt, sollte der Aufrufer oder die Clientanwendung keine umfangreichen Debuginformationen erhalten, da diese Informationen angreifern hilfreiche Datenpunkte zu der Anwendung liefern können.

Die Referenzimplementierung veranschaulicht dieses Prinzip, indem nur die Korrelations-ID in der fehlgeschlagenen Antwort zurückgegeben wird. Sie teilt nicht den Fehlergrund, z. B. Ausnahmemeldung oder Stapelablaufverfolgung. Mithilfe dieser ID und mithilfe der Server-Location Kopfzeile kann ein Operator den Vorfall mithilfe von Application Insights untersuchen.

//
// Example ASP.NET Core middleware, which adds the Correlation ID to every API response.
//
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
   // ...

    app.Use(async (context, next) =>
    {
        context.Response.OnStarting(o =>
        {
            if (o is HttpContext ctx)
            {
                context.Response.Headers.Add("Server-Name", Environment.MachineName);
                context.Response.Headers.Add("Server-Location", sysConfig.AzureRegion);
                context.Response.Headers.Add("Correlation-ID", Activity.Current?.RootId);
                context.Response.Headers.Add("Requested-Api-Version", ctx.GetRequestedApiVersion()?.ToString());
            }
            return Task.CompletedTask;
        }, context);
        await next();
    });
    
    // ...
}

Nächster Schritt

Stellen Sie die Referenzimplementierung bereit, um ein umfassendes Verständnis der Ressourcen und ihrer Konfiguration zu erhalten.

Implementierung: Mission-Critical-Online-Vorlage