Erstellen einer verwalteten Anwendung zum Speichern von Blob-Digests

Voraussetzungen

• Ein Azure Storage-Konto.
• Azure CLI (optional)
• Python-Version, die vom Azure SDK für Python unterstützt wird (optional)

Überblick

Der Blob Storage Digest, gesichert durch Confidential Ledger kann verwendet werden, um sicherzustellen, dass die Blobs in einem Blobcontainer vertrauenswürdig und nicht manipuliert werden. Die Anwendung, die einmal mit einem Speicherkonto verbunden ist, verfolgt alle Blobs, die jedem Container im Speicherkonto in Echtzeit hinzugefügt werden, zusätzlich zur Berechnung und Speicherung der Digests in Azure Confidential Ledger. Überprüfungen können jederzeit durchgeführt werden, um die Gültigkeit der Blobs zu überprüfen und sicherzustellen, dass der Blob-Container nicht manipuliert ist.

Bereitstellen der verwalteten Anwendung

Die verwaltete Anwendung finden Sie hier im Azure Marketplace: Blob Storage Digests, gesichert durch Confidential Ledger (Vorschau).

Zu erstellende Ressourcen

Sobald die erforderlichen Felder ausgefüllt und die Anwendung bereitgestellt wird, werden die folgenden Ressourcen unter einer verwalteten Ressourcengruppe erstellt:

• Confidential Ledger
• Service Bus-Warteschlange mit aktivierten Sitzungen
• Speicherkonto (Verleger-Speicherkonto, das zum Speichern der Digest-Logik und des Überprüfungsverlaufs verwendet wird)
• Funktions-App
• Application Insights

Verbinden eines Speicherkontos mit der verwalteten Anwendung

Nachdem eine verwaltete Anwendung erstellt wurde, können Sie die verwaltete Anwendung mit Ihrem Speicherkonto verbinden, um mit der Verarbeitung und Aufzeichnung von Blob-Containerdigests in Azure Confidential Ledger zu beginnen.

Erstellen eines Themas und eines Ereignisabonnements für das Speicherkonto

Die verwaltete Anwendung verwendet eine Azure Service Bus-Warteschlange, um alle Blob erstellen- und Blob löschen-Ereignisse nachzuverfolgen und aufzuzeichnen. Sie verwenden die von der verwalteten Anwendung in der verwalteten Ressourcengruppe erstellte Warteschlange und fügen sie als Ereignisabonnent für jedes Speicherkonto hinzu, für das Sie Blobs erstellen. Stellen Sie außerdem sicher, dass der dem Speicherkonto zugeordnete System Topic Name, den Sie nachverfolgen, dem Azure Service Bus Data Sender für die Azure Service Bus-Warteschlange zugewiesen ist, die von der verwalteten App erstellt wurde.

Azure portal

Im Azure-Portal können Sie zu dem Speicherkonto navigieren, für das Sie mit dem Erstellen von Blob-Digests beginnen und zum Blatt Events wechseln möchten. Dort können Sie ein Ereignisabonnement erstellen und mit dem Azure Service Bus Warteschlange-Endpunkt verbinden. Achten Sie darauf, den Managed identity type als System Assigned zu markieren.

Die Warteschlange verwendet Sitzungen, um die Sortierung über mehrere Speicherkonten hinweg aufrechtzuerhalten, sodass Sie auch zur Registerkarte Delivery Properties navigieren und eine eindeutige Sitzungs-ID für dieses Ereignisabonnement eingeben müssen.

BEFEHLSZEILENSCHNITTSTELLE (CLI)

Erstellen des Ereignisthemas:

Azure CLI

az eventgrid system-topic create \
  --resource-group {resource_group} \
  --name {sample_topic_name} \
  --location {location} \
  --topic-type microsoft.storage.storageaccounts \
  --source /subscriptions/{subscription}/resourceGroups/{resource_group}/providers/Microsoft.Storage/storageAccounts/{storage_account_name} \
  --identity SystemAssigned

resource-group – Ressourcengruppe, in der Thema erstellt werden soll

name – Name des zu erstellenden Themas

location – Ort des zu erstellenden Themas

source – Ressourcen-ID des Speicherkontos für welches das Thema erstellt werden soll

Erstellen des Ereignisabonnements:

Azure CLI

az eventgrid system-topic event-subscription create \
--name {sample_subscription_name} \
--system-topic-name {sample_topic_name} \
--resource-group {resource_group} \
--event-delivery-schema EventGridSchema \
--included-event-types Microsoft.Storage.BlobCreated \
--delivery-attribute-mapping sessionId static {sample_session_id} false \
--endpoint-type servicebusqueue \
--endpoint /subscriptions/{subscription}/resourceGroups/{managed_resource_group}/providers/Microsoft.ServiceBus/namespaces/{service_bus_namespace}/queues/{service_bus_queue}

name – Name des zu erstellenden Abonnements

system-topic-name – Name des Themas, für welches das Abonnement erstellt wird (Sollte dem neu erstellten Thema gleichen)

resource-group – Ressourcengruppe, von der das Abonnement erstellt werden soll

delivery-attribute-mapping – Zuordnung für das erforderliche sessionId-Feld. Geben Sie eine eindeutige sessionId ein

endpoint – Ressourcen-ID der Servicebuswarteschlange, die das Thema des Speicherkontos abonniert

Fügen Sie die erforderlichen Rolle zum Speicherkonto hinzu

Die verwaltete Anwendung erfordert, dass die Rolle Storage Blob Data Owner Hashes für jedes Blob lesen und erstellen kann und diese Rolle muss hinzugefügt werden, damit der Digest ordnungsgemäß berechnet wird.

Azure portal

BEFEHLSZEILENSCHNITTSTELLE (CLI)

Azure CLI

az role assignment create \
--role "Storage Blob Data Owner" \
--assignee-object-id {function_oid} \
--assignee-principal-type ServicePrincipal\
--scope /subscriptions/{subscription}/resourceGroups/{resource_group}/providers/Microsoft.Storage/storageAccounts/{storage_account_name}

assignee-object-id – OID der Azure-Funktion, die mit der verwalteten Anwendung erstellt wurde. Kann im Blatt „Identität“ gefunden werden

scope – Ressourcen-ID des Speicherkontos für welches die Rolle erstellt werden soll

Hinweis

Mehrere Speicherkonten können mit einer einzigen verwalteten Anwendungsinstanz verbunden werden. Wir empfehlen derzeit ein Maximum von 10 Speicherkonten, die häufig benutzte Blob-Container enthalten.

Hinzufügen von Blobs und Digest-Erstellung

Sobald das Speicherkonto ordnungsgemäß mit der verwalteten Anwendung verbunden ist, können Blobs zu Containern innerhalb des Speicherkontos hinzugefügt werden. Die Blobs werden in Echtzeit nachverfolgt und Digests werden in Azure Confidential Ledger berechnet und gespeichert.

Transaktions- und Blocktabellen

Alle Blob-Erstellungsereignisse werden in internen Tabellen nachverfolgt, welche in der verwalteten Anwendung gespeichert sind.

Die Transaktionstabelle enthält Informationen zu jedem Blob und einen eindeutigen Hash, der mithilfe einer Kombination der Metadaten und/oder Inhalte des Blobs generiert wird.

Die Blocktabelle enthält Informationen zu jedem Digest, der für den BLOB-Container erstellt wird, und die zugehörige Transaktions-ID für den Digest wird in Azure Confidential Ledger gespeichert.

Digesteinstellungen

Es gibt einige Digesteinstellungen, die beim Erstellen der verwalteten Anwendung ausgewählt werden können. Sie können den verwendeten Hashing Algorithm auswählen, um die Digests zu erstellen, ganz gleich, ob es sich um MD5 oder SHA256 handelt. Sie können auch die Anzahl der Blobs auswählen, die in den einzelnen Digesten oder im Digest Size enthalten sind. Die Digestgröße liegt im Bereich von 1-16 und gibt die Anzahl der Blobs an, die in jedem Block zusammengehasht werden. Schließlich können Sie Hash Contents auswählen und festlegen, was bei der Erstellung jedes Digests gehasht werden soll. Dies kann File Contents + Metadata eines jeden Blob sein oder nur File Contents.

Anzeigen des Digests in Azure Confidential Ledger

Sie können die Digests anzeigen, die direkt in Azure Confidential Ledger gespeichert werden, indem Sie zum Blatt Ledger Explorer navigieren.

Durchführen einer Überprüfung

Wenn Sie jemals die Gültigkeit der Blobs überprüfen möchten, die einem Container hinzugefügt werden, um sicherzustellen, dass sie nicht manipuliert werden, kann eine Überprüfung zu einem beliebigen Zeitpunkt ausgeführt werden. Die Überprüfung gibt jedes Blob-Erstellungsereignis wieder und berechnet die Digests mit den Blobs, die während der Überprüfung im Container gespeichert sind. Anschließend werden die neu berechneten Digests mit den in Azure Confidential gespeicherten Digests verglichen und es wird ein Bericht mit allen Digestvergleichen angezeigt und ob der BLOB-Container manipuliert wird.

Auslösen einer Überprüfung

Eine Überprüfung kann ausgelöst werden, indem die folgende Meldung zur Service Bus-Warteschlange hinzugefügt wird, die Ihrer verwalteten Anwendung zugeordnet ist:

JSON

{
    "eventType": "PerformAudit",
    "storageAccount": "<storage_account_name>",
    "blobContainer": "<blob_container_name>"
}

Azure portal

Achten Sie darauf, Session ID hinzuzufügen, da Sitzungen in der Warteschlange aktiviert sind.

Python SDK

Python

import json
import uuid
from azure.servicebus import ServiceBusClient, ServiceBusMessage

SERVICE_BUS_CONNECTION_STR = "<service_bus_connection_string>"
QUEUE_NAME = "<service_bus_queue_name>"
STORAGE_ACCOUNT_NAME = "<storage_account_name>"
BLOB_CONTAINER_NAME = "<blob_container_name>"
SESSION_ID = str(uuid.uuid4())

servicebus_client = ServiceBusClient.from_connection_string(conn_str=SERVICE_BUS_CONNECTION_STR, logging_enable=True)
sender = servicebus_client.get_queue_sender(queue_name=QUEUE_NAME)

message = {
    "eventType": "PerformAudit",
    "storageAccount": STORAGE_ACCOUNT_NAME,
    "blobContainer": BLOB_CONTAINER_NAME
}

message = ServiceBusMessage(json.dumps(message), session_id=SESSION_ID)
sender.send_messages(message)

Anzeigen von Überprüfungsergebnissen

Sobald eine Überprüfung erfolgreich durchgeführt wurde, können die Ergebnisse der Überprüfung in einem Container mit dem Namen <managed-application-name>-audit-records gefunden werden, der im jeweiligen Speicherkonto enthalten ist. Die Ergebnisse enthalten den neu berechneten Digest, den aus Azure Confidential Ledger abgerufenen Digest und ob die Blobs manipuliert werden.

Wenn Sie sich bei der Erstellung der verwalteten Anwendung für E-Mail-Benachrichtigungen entscheiden, erhalten Sie je nach gewählter Option während Audit Failure oder Audit Success and Failure eine E-Mail an Ihre E-Mail-Adresse.

Protokollierung und Fehler

Fehlerprotokolle finden Sie unter einem Container mit dem Namen <managed-application-name>-error-logs innerhalb des jeweiligen Speicherkontos. Wenn ein Blob-Erstellungsereignis oder ein Überprüfungsvorgang fehlschlägt, wird die Ursache des Fehlers aufgezeichnet und in diesem Container gespeichert. Wenn es Fragen zu den Fehlerprotokollen oder Anwendungsfunktionen gibt, wenden Sie sich an das Azure Confidential Ledger Supportteam, das in den Details zur verwalteten Anwendung bereitgestellt wurde.

Bereinigen verwalteter Anwendungen

Sie können die verwaltete Anwendung löschen, um alle zugehörigen Ressourcen zu bereinigen und zu entfernen. Durch das Löschen der verwalteten Anwendung werden alle Blob-Transaktionen nicht mehr nachverfolgt, und alle Digests werden nicht mehr erstellt. Überprüfungsberichte bleiben gültig für die Blobs, die vor dem Löschen hinzugefügt wurden.

Weitere Ressourcen

Weitere Informationen zu verwalteten Anwendungen und den bereitgestellten Ressourcen finden Sie unter den folgenden Links:

• Verwaltete Anwendungen
• Azure Service Queue-Sitzungen
• Azure Storage-Ereignisse

Nächste Schritte

• Übersicht über Microsoft Azure Confidential Ledger