Creare un'applicazione gestita per archiviare i digest BLOB

2025-04-30

Prerequisiti

Un account di archiviazione di Azure
Interfaccia della riga di comando di Azure (facoltativo)
Versione di Python supportata da Azure SDK per Python (facoltativo)

Panoramica

Il digest dell'Archiviazione Blob, gestito da un'Applicazione Supportata dal Registro Riservato, può essere utilizzato per garantire che i blob all'interno di un contenitore di blob siano affidabili e non manomessi. L'applicazione, una volta connessa a un account di archiviazione, tiene traccia di tutti i BLOB aggiunti a ogni contenitore nell'account di archiviazione in tempo reale, oltre a calcolare e archiviare i digest nel libro mastro riservato di Azure. I controlli possono essere eseguiti in qualsiasi momento per verificare la validità dei BLOB e per assicurarsi che il contenitore BLOB non venga manomesso.

Distribuzione dell'applicazione gestita

L'applicazione gestita è disponibile in Azure Marketplace qui: Digest di archiviazione BLOB supportati da Libro mastro riservato (anteprima).

Risorse da creare

Dopo aver compilato i campi obbligatori e aver distribuito l'applicazione, le risorse seguenti vengono create in un gruppo di risorse gestite:

Registro confidenziale
Coda del bus di servizio con sessioni abilitate
Account di archiviazione (account di archiviazione di proprietà del publisher usato per memorizzare la logica di digest e la cronologia di controllo)
App per le funzioni
Application Insights

Connessione di un account di archiviazione all'applicazione gestita

Dopo aver distribuito correttamente l'applicazione gestita, è possibile connetterla a un account di archiviazione di Azure per abilitare l'elaborazione e la registrazione dei digest dei contenitori BLOB nel libro mastro riservato di Azure.

L'applicazione gestita supporta attualmente i tipi di account di archiviazione seguenti:

Account di archiviazione per uso generico standard v2 (GPv2), inclusi quelli configurati per i livelli di accesso frequente, sporadico o archivio.
Account di Azure Data Lake Storage Gen2 (ADLS Gen2) con Spazio dei Nomi Gerarchico (HNS) abilitato.
Gli account di archiviazione con configurazioni di endpoint pubblici o privati, purché siano concesse le autorizzazioni di rete e identità appropriate.
Livelli di prestazioni Standard o Premium, purché il servizio BLOB sia abilitato.

Nota: È supportato solo il servizio BLOB. Altri servizi ,ad esempio File, Tabella o Coda, non sono applicabili per l'uso con l'applicazione gestita.

Creare un argomento e una sottoscrizione di eventi per l'account di archiviazione

L'applicazione gestita usa una coda del bus di servizio di Azure per tenere traccia e registrare tutti gli eventi Create BLOB ed Delete BLOB . Si userà la coda creata nel gruppo di risorse gestite dall'applicazione gestita e la si aggiungerà come Sottoscrittore eventi per qualsiasi account di archiviazione per cui si stanno creando BLOB. Assicurarsi inoltre che all'account System Topic Name di archiviazione associato sia assegnato l'oggetto Azure Service Bus Data Sender per la coda bus di servizio di Azure creata dall'app gestita.

Portale di Azure
CLI

Nella portale di Azure è possibile passare all'account di archiviazione per cui si vogliono iniziare a creare digest BLOB e passare al Events pannello. È possibile creare una sottoscrizione di eventi e connetterla all'endpoint della coda bus di servizio di Azure. Assicurarsi di contrassegnare come Managed identity typeSystem Assigned.

La coda usa le sessioni per mantenere l'ordinamento tra più account di archiviazione, quindi sarà anche necessario passare alla Delivery Properties scheda e immettere un ID sessione univoco per questa sottoscrizione di eventi.

Creazione dell'argomento evento:

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 - Gruppo di risorse in cui creare l'argomento

name - Nome dell'argomento da creare

location - Posizione dell'argomento da creare

source - ID risorsa dell'account di archiviazione per cui creare l'argomento

Creazione della sottoscrizione di eventi:

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 - Nome della sottoscrizione da creare

system-topic-name - Nome dell'argomento per cui viene creata la sottoscrizione (deve essere uguale all'argomento appena creato)

resource-group - Gruppo di risorse in cui deve essere creata la sottoscrizione

delivery-attribute-mapping - Mapping per il campo sessionId obbligatorio. Immettere un id sessione univoco

endpoint - ID risorsa della coda del bus di servizio che sottoscrive l'argomento dell'account di archiviazione

Aggiungere il ruolo necessario all'account di archiviazione

L'applicazione gestita richiede il Storage Blob Data Owner ruolo per leggere e creare hash per ogni BLOB e questo ruolo deve essere aggiunto affinché il digest venga calcolato correttamente.

Portale di 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 della funzione di Azure creata con l'applicazione gestita. È possibile trovare il pannello "Identità"

scope - ID risorsa dell'account di archiviazione per cui creare il ruolo

Nota

È possibile connettere più account di archiviazione a una singola istanza dell'applicazione gestita. È attualmente consigliabile un massimo di 10 account di archiviazione che contengono contenitori BLOB con utilizzo elevato.

Aggiunta di BLOB e creazione del digest

Dopo che l'account di archiviazione è connesso correttamente all'applicazione gestita, i BLOB possono iniziare ad essere aggiunti ai contenitori all'interno dell'account di archiviazione. I BLOB vengono rilevati in tempo reale e i digest vengono calcolati e archiviati nel libro mastro riservato di Azure.

Tabelle transazioni e blocchi

Tutti gli eventi di creazione di BLOB vengono rilevati nelle tabelle interne archiviate nell'applicazione gestita.

La tabella delle transazioni contiene informazioni su ogni BLOB e un hash univoco generato usando una combinazione dei metadati e/o del contenuto del BLOB.

La tabella di blocchi contiene informazioni correlate a ogni digest creato per il contenitore BLOB e l'ID transazione associato per il digest viene archiviato in Registro dati riservati di Azure.

Impostazioni digest

Durante la creazione dell'applicazione gestita è possibile selezionare alcune impostazioni digest. È possibile scegliere l'oggetto Hashing Algorithm usato per creare i digest, sia che si tratti MD5SHA256di o . È anche possibile scegliere il numero di BLOB contenuti in ogni digest o .Digest Size La dimensione del digest è compresa tra 1-16 e e è il numero di BLOB che verranno sottoposto a hashing all'interno di ogni blocco. Infine, è possibile selezionare Hash Contents e cosa verrà sottoposto a hash durante la creazione di ogni digest. Può trattarsi di File Contents + Metadata ogni BLOB o solo di File Contents.

Visualizzazione del digest nel libro mastro riservato di Azure

È possibile visualizzare i digest archiviati direttamente nel libro mastro riservato di Azure passando al Ledger Explorer pannello.

Esecuzione di un controllo

Se si vuole verificare la validità dei BLOB aggiunti a un contenitore per assicurarsi che non vengano manomessi, è possibile eseguire un controllo in qualsiasi momento. Il controllo riproduce ogni evento di creazione di BLOB e ricalcola i digest con i BLOB archiviati nel contenitore durante il controllo. Confronta quindi i digest ricalcolati con i digest archiviati in Riservato di Azure e fornisce un report che visualizza tutti i confronti di digest e se il contenitore BLOB viene manomesso o meno.

Attivazione di un controllo

Un controllo può essere attivato includendo il messaggio seguente alla coda di bus di servizio associata all'applicazione gestita:

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

Portale di Azure
Python SDK

Assicurarsi di includere un oggetto Session ID perché nella coda sono abilitate le sessioni.

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)

Visualizzazione dei risultati del controllo

Una volta eseguito correttamente un controllo, i risultati del controllo sono disponibili in un contenitore denominato <managed-application-name>-audit-records trovato all'interno del rispettivo account di archiviazione. I risultati contengono il digest ricalcolato, il digest recuperato dal libro mastro riservato di Azure e se i BLOB vengono manomessi o meno.

Quando si crea l'applicazione gestita, se si acconsente esplicitamente agli avvisi di posta elettronica, si riceverà un messaggio di posta elettronica inviato al messaggio di posta elettronica durante un Audit Failure oggetto o un oggetto Audit Success and Failure a seconda dell'opzione selezionata.

Abilitazione delle verifiche di tracciamento utente

È possibile tenere traccia degli utenti che hanno caricato o eliminato oggetti (blobs) tramite i log di diagnostica inviati all'account di archiviazione interno creato dall'app gestita.

1. Abilitare le impostazioni di diagnostica

Vai al tuo Account di Archiviazione → Monitoraggio → Impostazioni di Diagnostica.
Aggiungere una nuova impostazione per il servizio "BLOB".
Abilitare:
- Storage Write
- Storage Delete
Impostare la destinazione sull'account di archiviazione dell'archivio interno creato dall'applicazione gestita.

2. Inviare il messaggio seguente alla coda del bus di servizio (con un ID sessione):

Dopo aver visualizzato i log di diagnostica che vengono inviati all'account di archiviazione, è possibile aggiungere il campo getUsers al momento di attivare un evento di controllo.

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

3. Controllare i risultati del controllo

Una volta elaborata correttamente una verifica, ogni voce includerà l'utente che ha eseguito l'operazione insieme al relativo OID, ove disponibile:

"user": {
  "upn": "[email protected]",
  "oid": "<object-id>"
}

Registrazione ed errori

I log degli errori sono disponibili in un contenitore denominato <managed-application-name>-error-logs trovato all'interno dell'account di archiviazione corrispondente. Se un evento di creazione blob o un processo di controllo ha esito negativo, la causa dell'errore viene registrata e archiviata in questo contenitore. In caso di domande sui log degli errori o sulle funzionalità dell'applicazione, contattare il team di supporto di Azure Confidential Ledger fornito nei dettagli dell'applicazione gestita.

Pulire l'applicazione gestita

È possibile eliminare l'applicazione gestita per pulire e rimuovere tutte le risorse associate. L'eliminazione dell'applicazione gestita impedisce la registrazione di tutte le transazioni BLOB e impedisce la creazione di tutti i digest. I report di controllo rimangono validi per i BLOB aggiunti prima dell'eliminazione.

Altre risorse

Per altre informazioni sulle applicazioni gestite e sulle risorse distribuite, vedere i collegamenti seguenti:

Passaggi successivi

Panoramica del libro mastro riservato di Microsoft Azure