Teilen über

Azure Service Fabric-Sicherheit

  • Artikel

Weitere Informationen zu den bewährten Methoden in Bezug auf die Azure-Sicherheit finden Sie unter Bewährte Methoden für die Azure Service Fabric-Sicherheit.

Key Vault

Azure Key Vault ist der empfohlene Dienst für die Verwaltung von Geheimnissen für Azure Service Fabric-Anwendungen und -Cluster.

Hinweis

Wenn Zertifikate/Geheimnisse aus einem Schlüsseltresor (Key Vault) in einer VM-Skalierungsgruppe als zugehöriges Geheimnis bereitgestellt werden, müssen sich der Key Vault und die VM-Skalierungsgruppe in derselben Region befinden.

Erstellen eines von einer Zertifizierungsstelle ausgestellten Service Fabric-Zertifikats

Ein Azure Key Vault-Zertifikat kann entweder erstellt oder in einen Key Vault importiert werden. Wenn ein Key Vault-Zertifikat erstellt wird, wird der private Schlüssel innerhalb des Schlüsseltresors erstellt und niemals für den Zertifikatsinhaber verfügbar gemacht. Hier sind die Möglichkeiten zum Erstellen eines Zertifikats in Key Vault angegeben:

  • Erstellen Sie ein selbstsigniertes Zertifikat, um ein öffentlich-privates Schlüsselpaar zu erstellen und einem Zertifikat zuzuordnen. Das Zertifikat wird mit einem eigenen Schlüssel signiert.
  • Erstellen Sie manuell ein neues Zertifikat, um ein öffentlich-privates Schlüsselpaar zu erstellen und die Anforderung einer X.509-Zertifikatsignatur zu generieren. Die Signaturanforderung kann von Ihrer Registrierungs- oder Zertifizierungsstelle signiert werden. Das signierte x509-Zertifikat lässt sich dann mit dem ausstehenden Schlüsselpaar zusammenführen, um das KV-Zertifikat in Key Vault zu vervollständigen. Obwohl diese Methode mehr Schritte erfordert, bietet sie Ihnen mehr Sicherheit, da der private Schlüssel in Key Vault erstellt und darauf beschränkt wird. Dies wird im folgenden Diagramm erläutert.

Weitere Informationen finden Sie unter Methoden für die Zertifikaterstellung.

Bereitstellen von Key Vault-Zertifikaten für VM-Skalierungsgruppen von Service Fabric-Clustern

Verwenden Sie zum Bereitstellen von Zertifikaten aus einem in derselben Region angeordneten Schlüsseltresor in einer VM-Skalierungsgruppe die VM-Skalierungsgruppe osProfile. Hier sind die Eigenschaften von Resource Manager-Vorlagen aufgeführt:

"secrets": [
   {
       "sourceVault": {
           "id": "[parameters('sourceVaultValue')]"
       },
       "vaultCertificates": [
          {
              "certificateStore": "[parameters('certificateStoreValue')]",
              "certificateUrl": "[parameters('certificateUrlValue')]"
          }
       ]
   }
]

Hinweis

Für den Tresor muss die Bereitstellung von Resource Manager-Vorlagen aktiviert sein.

Anwenden einer Zugriffssteuerungsliste (Access Control List, ACL) auf Ihr Zertifikat für Ihren Service Fabric-Cluster

Der Microsoft.Azure.ServiceFabric-Herausgeber für VM-Skalierungsgruppenerweiterungen wird verwendet, um Ihre Knotensicherheit zu konfigurieren. Verwenden Sie die folgenden Resource Manager-Vorlageneigenschaften, um eine ACL auf die Zertifikate für Ihre Service Fabric-Clusterprozesse anzuwenden:

"certificate": {
   "commonNames": [
       "[parameters('certificateCommonName')]"
   ],
   "x509StoreName": "[parameters('certificateStoreValue')]"
}

Schützen eines Service Fabric-Clusterzertifikats anhand eines allgemeinen Namens

Verwenden Sie die Resource Manager-Vorlageneigenschaft certificateCommonNames wie folgt, um Ihren Service Fabric-Cluster anhand des Zertifikats Common Name zu schützen:

"certificateCommonNames": {
    "commonNames": [
        {
            "certificateCommonName": "[parameters('certificateCommonName')]",
            "certificateIssuerThumbprint": "[parameters('certificateIssuerThumbprint')]"
        }
    ],
    "x509StoreName": "[parameters('certificateStoreValue')]"
}

Hinweis

Für Service Fabric-Cluster wird das erste gültige Zertifikat verwendet, das im Zertifikatspeicher Ihres Hosts gefunden wird. Unter Windows ist dies das Zertifikat mit dem spätesten Ablaufdatum, das mit Ihrem allgemeinen Namen und dem Fingerabdruck des Ausstellers übereinstimmt.

Azure-Domänen, z.B. „*<IHRE UNTERDOMÄNE>.cloudapp.azure.com“ oder „<IHRE UNTERDOMÄNE>.trafficmanager.net“, befinden sich im Besitz von Microsoft. Zertifizierungsstellen stellen für nicht berechtigte Benutzer keine Zertifikate für Domänen aus. Die meisten Benutzer müssen eine Domäne von einer Registrierungsstelle erwerben oder ein autorisierter Domänenadministrator für eine Zertifizierungsstelle sein, um für Sie ein Zertifikat mit diesem allgemeinen Namen ausstellen zu können.

Weitere Informationen dazu, wie Sie den DNS-Dienst zum Auflösen Ihrer Domäne in eine Microsoft-IP-Adresse konfigurieren, finden Sie in der Anleitung zur Konfiguration von Azure DNS zum Hosten Ihrer Domäne.

Hinweis

Nachdem Sie Ihre Domänennamenserver an Ihre Azure DNS-Zonennamenserver delegiert haben, können Sie Ihrer DNS-Zone die beiden folgenden Einträge hinzufügen:

  • Einen A-Eintrag für den Domänen-APEX, bei dem es sich NICHT um ein Alias record set für alle IP-Adressen handelt, die von Ihrer benutzerdefinierten Domäne aufgelöst werden.
  • Einen C-Eintrag für von Ihnen bereitgestellte Microsoft-Unterdomänen, bei denen es sich NICHT um ein Alias record set handelt. Sie können beispielsweise den DNS-Namen Ihrer Traffic Manager-Instanz oder Ihres Load Balancers verwenden.

Aktualisieren Sie die folgenden Resource Manager-Vorlageneigenschaften für den Service Fabric-Cluster, damit in Ihrem Portal ein benutzerdefinierter DNS-Name für den "managementEndpoint" Ihres Service Fabric-Clusters angezeigt wird:

 "managementEndpoint": "[concat('https://<YOUR CUSTOM DOMAIN>:',parameters('nt0fabricHttpGatewayPort'))]",

Verschlüsseln der Geheimniswerte von Service Fabric-Paketen

Allgemeine Werte, die in Service Fabric-Paketen verschlüsselt werden, umfassen ACR-Anmeldeinformationen (Azure Container Registry), Umgebungsvariablen, Einstellungen und Speicherkontoschlüssel für Azure-Volume-Plug-Ins.

Gehen Sie wie folgt vor, um ein Verschlüsselungszertifikat einzurichten und Geheimnisse in Windows-Clustern zu verschlüsseln:

Generieren Sie ein selbstsigniertes Zertifikat zum Verschlüsseln Ihres Geheimnisses:

New-SelfSignedCertificate -Type DocumentEncryptionCert -KeyUsage DataEncipherment -Subject mydataenciphermentcert -Provider 'Microsoft Enhanced Cryptographic Provider v1.0'

Befolgen Sie die Anleitung unter Bereitstellen von Key Vault-Zertifikaten für VM-Skalierungsgruppen von Service Fabric-Clustern, um Key Vault-Zertifikate für die VM-Skalierungsgruppen Ihres Service Fabric-Clusters bereitzustellen.

Verschlüsseln Sie Ihr Geheimnis mit dem folgenden PowerShell-Befehl, und aktualisieren Sie Ihr Service Fabric-Anwendungsmanifest anschließend mit dem verschlüsselten Wert:

Invoke-ServiceFabricEncryptText -CertStore -CertThumbprint "<thumbprint>" -Text "mysecret" -StoreLocation CurrentUser -StoreName My

Gehen Sie wie folgt vor, um ein Verschlüsselungszertifikat einzurichten und Geheimnisse in Linux-Clustern zu verschlüsseln:

Generieren Sie ein selbstsigniertes Zertifikat zum Verschlüsseln Ihrer Geheimnisse:

openssl req -newkey rsa:2048 -nodes -keyout TestCert.prv -x509 -days 365 -out TestCert.pem
cat TestCert.prv >> TestCert.pem

Befolgen Sie die Anleitung unter Bereitstellen von Key Vault-Zertifikaten für VM-Skalierungsgruppen von Service Fabric-Clustern, um dies für die VM-Skalierungsgruppen Ihres Service Fabric-Clusters durchzuführen.

Verschlüsseln Sie Ihr Geheimnis mit den folgenden Befehlen, und aktualisieren Sie Ihr Service Fabric-Anwendungsmanifest anschließend mit dem verschlüsselten Wert:

echo "Hello World!" > plaintext.txt
iconv -f ASCII -t UTF-16LE plaintext.txt -o plaintext_UTF-16.txt
openssl smime -encrypt -in plaintext_UTF-16.txt -binary -outform der TestCert.pem | base64 > encrypted.txt

Nachdem Sie Ihre geschützten Werte verschlüsselt haben, können Sie verschlüsselte Geheimnisse in der Service Fabric-Anwendung angeben und verschlüsselte Geheimnisse aus dem Dienstcode entschlüsseln.

Einbinden eines Endpunktzertifikats in Service Fabric-Anwendungen

Binden Sie zum Konfigurieren des Anwendungsendpunktzertifikats das Zertifikat ein, indem Sie dem Anwendungsmanifest ein EndpointCertificate-Element zusammen mit dem User-Element für das Prinzipalkonto hinzufügen. Standardmäßig trägt das Prinzipalkonto den Namen NetworkService. Dadurch wird die Verwaltung der ACL des privaten Schlüssels des Anwendungszertifikats für den bereitgestellten Prinzipal bereitgestellt.

<ApplicationManifest … >
  ...
  <Principals>
    <Users>
      <User Name="Service1" AccountType="NetworkService" />
    </Users>
  </Principals>
  <Certificates>
    <EndpointCertificate Name="MyCert" X509FindType="FindByThumbprint" X509FindValue="[YourCertThumbprint]"/>
  </Certificates>
</ApplicationManifest>

Einbinden eines Geheimniszertifikats in Service Fabric-Anwendungen

Um Ihrer Anwendung Zugriff auf Geheimnisse zu gewähren, binden Sie das Zertifikat ein, indem Sie ein SecretsCertificate-Element zum Anwendungsmanifest hinzufügen.

<ApplicationManifest … >
  ...
  <Certificates>
    <SecretsCertificate Name="MyCert" X509FindType="FindByThumbprint" X509FindValue="[YourCertThumbprint]"/>
  </Certificates>
</ApplicationManifest>

Authentifizieren von Service Fabric-Anwendungen für Azure-Ressourcen per verwalteter Dienstidentität (Managed Service Identity, MSI)

Informationen zu verwalteten Identitäten für Azure-Ressourcen finden Sie unter Was sind verwaltete Identitäten für Azure-Ressourcen?. Azure Service Fabric-Cluster werden in VM-Skalierungsgruppen gehostet, die die verwaltete Dienstidentität unterstützen. Eine Liste der Dienste, für die MSI für die Authentifizierung genutzt werden kann, finden Sie unter Azure-Dienste, die die Microsoft Entra-Authentifizierung unterstützen.

Deklarieren Sie die folgende "Microsoft.Compute/virtualMachinesScaleSets"-Eigenschaft, um die vom System zugewiesene verwaltete Identität bei der Erstellung einer VM-Skalierungsgruppe oder in einer vorhandenen VM-Skalierungsgruppe zu aktivieren:

"identity": { 
    "type": "SystemAssigned"
}

Weitere Informationen finden Sie unter Was sind verwaltete Identitäten für Azure-Ressourcen?.

Wenn Sie eine benutzerzugeordnete verwaltete Identität erstellt haben, deklarieren Sie die folgende Ressource in Ihrer Vorlage, um sie Ihrem Skalierungssatz für virtuelle Computer zuzuweisen. Ersetzen Sie \<USERASSIGNEDIDENTITYNAME\> durch den Namen der vom Benutzer zugewiesenen verwalteten Identität, die Sie erstellt haben:

"identity": {
    "type": "userAssigned",
    "userAssignedIdentities": {
        "[resourceID('Microsoft.ManagedIdentity/userAssignedIdentities/',variables('<USERASSIGNEDIDENTITYNAME>'))]": {}
    }
}

Bevor Ihre Service Fabric-Anwendung eine verwaltete Identität nutzen kann, müssen den Azure-Ressourcen die Berechtigungen gewährt werden, die für die Authentifizierung erforderlich sind. Mit den folgenden Befehlen wird der Zugriff auf eine Azure-Ressource gewährt:

PRINCIPAL_ID=$(az resource show --id /subscriptions/<YOUR SUBSCRIPTON>/resourceGroups/<YOUR RG>/providers/Microsoft.Compute/virtualMachineScaleSets/<YOUR SCALE SET> --api-version 2018-06-01 | python -c "import sys, json; print(json.load(sys.stdin)['identity']['principalId'])")

az role assignment create --assignee $PRINCIPAL_ID --role 'Contributor' --scope "/subscriptions/<YOUR SUBSCRIPTION>/resourceGroups/<YOUR RG>/providers/<PROVIDER NAME>/<RESOURCE TYPE>/<RESOURCE NAME>"

Rufen Sie in Ihrem Service Fabric-Anwendungscode ein Zugriffstoken für Azure Resource Manager ab, indem Sie beispielsweise einen REST-Aufruf wie den folgenden durchführen:

ACCESS_TOKEN=$(curl 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https%3A%2F%2Fmanagement.azure.com%2F' -H Metadata:true | python -c "import sys, json; print json.load(sys.stdin)['access_token']")

Ihre Service Fabric-App kann das Zugriffstoken dann zum Authentifizieren gegenüber Azure-Ressourcen verwenden, die Active Directory unterstützen. Im folgenden Beispiel ist dargestellt, wie Sie dies für die Azure Cosmos DB-Ressource durchführen:

COSMOS_DB_PASSWORD=$(curl 'https://management.azure.com/subscriptions/<YOUR SUBSCRIPTION>/resourceGroups/<YOUR RG>/providers/Microsoft.DocumentDB/databaseAccounts/<YOUR ACCOUNT>/listKeys?api-version=2016-03-31' -X POST -d "" -H "Authorization: Bearer $ACCESS_TOKEN" | python -c "import sys, json; print(json.load(sys.stdin)['primaryMasterKey'])")

Windows-Sicherheitsbaselines

Es empfiehlt sich, eine branchenübliche Konfiguration zu implementieren, die allgemein bekannt ist und ausführlich getestet wurde (beispielsweise Microsoft-Sicherheitsbaselines), anstatt eine eigene Baseline zu erstellen. Zur Bereitstellung für Ihre VM-Skalierungsgruppen können Sie beispielsweise den Azure-DSC-Erweiterungshandler (Desired State Configuration) verwenden, um die virtuellen Computer zu konfigurieren, sobald sie online geschaltet werden, damit auf ihnen die Produktionssoftware ausgeführt wird.

Azure Firewall

Azure Firewall ist ein verwalteter, cloudbasierter Netzwerksicherheitsdienst, der Ihre Azure Virtual Network-Ressourcen schützt. Es ist eine vollständig zustandsbehaftete Firewall als ein Dienst mit integrierter Hochverfügbarkeit und uneingeschränkter Cloudskalierbarkeit.; Dies aktiviert die Fähigkeit, den ausgehenden HTTP/S-Datenverkehr auf eine angegebene Liste vollständig qualifizierter Domänennamen (Fully Qualified Domain Names, FQDNs) einschließlich Platzhalter zu beschränken. Diese Funktion erfordert keine TLS-/SSL-Terminierung. Es wird empfohlen, FQDN-Tags von Azure Firewall für Windows-Updates zu nutzen und Netzwerkdatenverkehr für Microsoft Windows Update-Endpunkte zu aktivieren, damit dieser Ihre Firewall passieren kann. Der Artikel Bereitstellen von Azure Firewall mit einer Vorlage enthält ein Beispiel für die Definition einer Microsoft.Network/azureFirewalls-Ressourcenvorlage. Firewallregeln für Service Fabric-Anwendungen erlauben häufig Folgendes für das virtuelle Netzwerk Ihrer Cluster:

  • *download.microsoft.com
  • *servicefabric.azure.com
  • *.core.windows.net

Diese Firewallregeln ergänzen Ihre zulässigen ausgehenden Netzwerksicherheitsgruppen, die Service Fabric und Storage als zulässige Ziele aus Ihrem virtuellen Netzwerk enthalten.

TLS 1.2

Microsoft Azure empfiehlt allen Kunden eine vollständige Migration zu Lösungen, die TLS 1.2 (Transport Layer Security) unterstützen, um sicherzustellen, dass TLS 1.2 standardmäßig verwendet wird.

Für Azure-Dienste einschließlich Service Fabric wurden die Entwicklungsarbeiten abgeschlossen, um die Abhängigkeit von TLS 1.0/1.1-Protokollen zu entfernen und vollständige Unterstützung für Kunden zu bieten, die ihre Workloads so konfigurieren möchten, dass sie nur TLS 1.2-Verbindungen herstellen und annehmen.

Kunden sollten ihre von Azure gehosteten Workloads und lokalen Anwendungen, die mit Azure-Diensten interagieren, so konfigurieren, dass TLS 1.2 standardmäßig verwendet wird. Hier erfahren Sie, wie Sie Service Fabric-Clusterknoten und -Anwendungen so konfigurieren, dass eine bestimmte TLS-Version verwendet wird.

Windows Defender

Standardmäßig ist Windows Defender Antivirus unter Windows Server 2016 installiert. Weitere Informationen finden Sie unter Windows Defender Antivirus auf Windows Server2016. Die Benutzeroberfläche wird bei einigen SKUs standardmäßig installiert, aber dies ist keine erforderliche Komponente. Gehen Sie wie folgt vor, um durch Windows Defender verursachte Leistungsbeeinträchtigungen und Erhöhungen des Ressourcenverbrauchs zu verringern (und falls Ihre Sicherheitsrichtlinien es zulassen, Prozesse und Pfade für Open-Source-Software auszuschließen): Deklarieren Sie die folgenden Resource Manager-Vorlageneigenschaften für die VM-Skalierungsgruppenerweiterung, um Ihren Service Fabric-Cluster von Scanvorgängen auszuschließen:

 {
    "name": "[concat('VMIaaSAntimalware','_vmNodeType0Name')]",
    "properties": {
        "publisher": "Microsoft.Azure.Security",
        "type": "IaaSAntimalware",
        "typeHandlerVersion": "1.5",
        "settings": {
            "AntimalwareEnabled": "true",
            "Exclusions": {
                "Paths": "[concat(parameters('svcFabData'), ';', parameters('svcFabLogs'), ';', parameters('svcFabRuntime'))]",
                "Processes": "Fabric.exe;FabricHost.exe;FabricInstallerService.exe;FabricSetup.exe;FabricDeployer.exe;ImageBuilder.exe;FabricGateway.exe;FabricDCA.exe;FabricFAS.exe;FabricUOS.exe;FabricRM.exe;FileStoreService.exe;FabricBRS.exe;BackupCopier.exe"
            },
            "RealtimeProtectionEnabled": "true",
            "ScheduledScanSettings": {
                "isEnabled": "true",
                "scanType": "Quick",
                "day": "7",
                "time": "120"
            }
        },
        "protectedSettings": null
    }
}

Hinweis

Sehen Sie sich in der Dokumentation zu Ihrer Antischadsoftware-Anwendung die Konfigurationsregeln an, falls Sie Windows Defender nicht nutzen. Windows Defender wird unter Linux nicht unterstützt.

Hosting nicht vertrauenswürdiger Anwendungen in einem Service Fabric-Cluster

Ein Service Fabric-Cluster ist standardmäßig ein einzelner Mandant, und gehostete Anwendungen werden als vertrauenswürdig eingestuft. Anwendungen erhalten daher Zugriff auf die Service Fabric-Runtime, was sich in unterschiedlicher Form auswirkt, unter anderem durch: Umgebungsvariablen, die auf Dateipfade der Anwendungs- und Fabric-Dateien auf dem Host verweisen, Hostpfade, die mit Schreibzugriff auf Containerworkloads eingerichtet sind, ein Endpunkt für die Kommunikation zwischen Prozessen, der anwendungsspezifische Anforderungen akzeptiert, und das Clientzertifikat, das Fabric erwartet, wenn sich die Anwendung selbst authentifiziert.

Wenn Sie nicht vertrauenswürdige Anwendungen hosten möchten, müssen Sie zusätzliche Schritte ausführen, um die schädliche mehrinstanzenfähige Umgebung für Ihren Service Fabric-Cluster zu definieren und zu kontrollieren. Dies erfordert, dass Sie im Kontext Ihres Szenarios mehrere Aspekte berücksichtigen, einschließlich, aber nicht beschränkt auf die folgenden:

  • Eine umfassende Sicherheitsüberprüfung der Interaktionen von nicht vertrauenswürdigen Anwendungen mit anderen Anwendungen, dem Cluster selbst und der zugrunde liegenden Compute-Infrastruktur.
  • Verwendung der strengsten anwendbaren Sandboxing-Technologie (z. B. geeignete Isolationsmodi für Containerworkloads).
  • Risikobewertung von nicht vertrauenswürdigen Anwendungen, die nicht der Sandboxing-Technologie unterliegen, da die nächste Vertrauens- und Sicherheitsgrenze der Cluster selbst ist.
  • Entfernung des Zugriffs nicht vertrauenswürdiger Anwendungen auf die Service Fabric-Runtime.

RemoveServiceFabricRuntimeAccess

Der Zugriff auf die Service Fabric-Runtime kann durch die folgende Deklaration im Abschnitt „Policies“ des Anwendungsmanifests aufgehoben werden:

<ServiceManifestImport>
    <Policies>
        <ServiceFabricRuntimeAccessPolicy RemoveServiceFabricRuntimeAccess="true"/>
    </Policies>
</ServiceManifestImport>

Nächste Schritte