Schützen Sie Ihren Azure Table Storage

Azure Table Storage bietet einen NoSQL-Schlüssel-Wertspeicher für strukturierte, nicht-relationale Daten. Table Security teilt Grundlagen mit den anderen Azure Storage-Datendiensten, hat aber einige Besonderheiten – darunter eine eigenständige Microsoft Entra ID-Autorisierungsfläche und eine Überschneidung mit der Azure Cosmos DB für die Table API –, die Aufmerksamkeit verdienen.

Note

Dieser Artikel behandelt Sicherheitspraktiken speziell für Azure Table Storage. Für Sicherheitsratschläge auf Kontoebene siehe Secure your Azure Storage account.

Dienstspezifische Sicherheit

Sowohl Azure Table Storage als auch die Azure Cosmos DB for Table API bieten ein ähnliches Tabellendatenmodell offen, aber ihre Sicherheitsfähigkeiten unterscheiden sich erheblich. Wählen Sie die Plattform, die Ihre Sicherheitsanforderungen zu Beginn des Projekts erfüllt. Die Datenmigration zwischen ihnen ist nicht trivial.

  • Verwenden Sie Azure Cosmos DB für Tabellen, wenn Sie dedizierten Durchsatz, globale Verteilung oder feiner Netzwerkisolation pro Tabellen-Workload benötigen: Die Cosmos DB for Table API ist eine eigenständige Ressource mit eigenen privaten Endpunkten, Firewall und IAM-Konfiguration, unabhängig von jedem Speicherkonto. Das verschafft dir einen isolierten Explosionsradius, wenn die Table-Workload andere Netzwerk- oder Governance-Anforderungen hat als die Workloads, die dein Allzweckspeicherkonto teilen. Weitere Informationen finden Sie unter Einführung in Azure Cosmos DB for Table.

  • Verwenden Sie Azure Table Storage, wenn Sie eine Co-Location auf Kontoebene mit Blobs, Dateien und Warteschlangen benötigen: Table Storage befindet sich in einem allgemeinen Speicherkonto, sodass ein einziger Satz von Netzwerkregeln, privaten Endpunkten und Identitätsrichtlinien auf allen vier Datendiensten angewendet wird. Cosmos DB für Table ist eine separate Ressource mit unabhängiger Sicherheitskonfiguration.

Identitäts- und Zugriffsverwaltung

  • Verwenden Sie Microsoft Entra ID, um Tabellendatenoperationen zu autorisieren: Die Entra ID-Autorisierung beseitigt die Notwendigkeit von Kontoschlüsseln im Anwendungscode und bietet identitätsbasierte Audit-Trails. Weisen Sie nach Möglichkeit die integrierten Rollen Storage Table Data Reader oder Storage Table Data Contributor im Tabellenbereich zu. Weitere Informationen finden Sie unter Zugriff auf Tabellen autorisieren mit Microsoft Entra ID.

  • Rollenzuweisungen auf bestimmte Tabellen beschränken: Eine Beschränkung auf Tabellenebene wird für die integrierten Tabellendatenrollen unterstützt. Wenn ein Service Zugriff auf nur eine Tabelle benötigt, weist man die Rolle an der Tabellenressource und nicht am Konto zu.

  • SAS-Token auf bestimmte Partitionsschlüssel- und Zeilenschlüsselbereiche beschränken: Table SAS unterstützt Einschränkungen für Partitionsschlüssel- und Zeilenschlüsselbereiche. Verwenden Sie sie, um ein Token auf die Zeilen eines einzelnen Tenants in einer Multi-Tenant-Tabelle oder auf einen bestimmten Datenschnitt zu beschränken. Weitere Informationen finden Sie unter Gewähren von eingeschränktem Zugriff auf Azure Storage-Ressourcen mithilfe von SAS (Shared Access Signature).

  • Gewähren Sie nur die spezifischen Tabellenoperationen: Tabellen-SAS unterstützt query, add, update, und delete Berechtigungen separat. Aufrufender Code im Leserstil sollte nur query enthalten, niemals update oder delete.

Datenschutz

Table Storage speichert Entitäten als flache Eigenschaftensammlungen ohne ACLs pro Entität. Berücksichtigen Sie Sicherheit in Ihrer Partitionierungsstrategie, anstatt die Zugriffskontrolle nachzubauen.

  • Partitionstabellen zur Ausrichtung auf Zugriffsgrenzen: Wenn eine Tabelle mehrere Tenants oder Klassifikationsebenen bedient, wählen Sie einen Partitionsschlüssel, der die Entitäten nach Tenant oder Klassifikation gruppiert. Kombinieren Sie dies mit Bereichsbeschränkungen für SAS-Partitionsschlüssel, um die Mandantenisolierung ohne eine separate Tabelle pro Mandant zu erzwingen.

  • Speichern Sie keine Geheimnisse oder unnötigen personenbezogenen Daten in Entitätseigenschaften: Entitäten sind für jeden Prinzipal mit query- oder read-Zugriff auf die Tabelle oder Partition sichtbar. Speichern Sie Geheimnisse in Azure Key Vault mit Referenzen in der Entität und minimieren Sie die persönlichen Daten, die Sie in abfragbare Eigenschaften einfügen.

  • Verschlüsseln Sie sensible Eigenschaftswerte auf der Anwendungsebene: Für Eigenschaftswerte, die vertraulich bleiben müssen, verschlüsseln Sie den Wert im Client vor dem Einfügen oder Aktualisieren mit einem Schlüssel aus Key Vault. Diese Verschlüsselung ist unabhängig von der speicherseitigen Verschlüsselung, die auf die gesamte Tabelle angewendet wird. Weitere Informationen finden Sie unter "Informationen zu Schlüsseln".

Protokollierung und Überwachung

  • Aktivieren Sie Diagnoseeinstellungen für Tabellenoperationen: Senden Sie die Kategorien StorageRead, StorageWrite und StorageDelete an Log Analytics. Warnung bei unerwarteten Autorisierungsmethoden, insbesondere beim Zugriff auf den geteilten Schlüssel bei Konten, bei denen er deaktiviert werden sollte. Weitere Informationen finden Sie unter Monitoring Azure Table Storage.

  • Warnung bei umfangreichen Lösch- oder Aktualisierungsoperationen: Massen DeleteEntity oder UpdateEntity Aktivitäten, die vom Ausgangspunkt der Tabelle abweichen, können auf Datenvernichtung oder Manipulation hinweisen. Legen Sie eine Baseline fest und alarmieren Sie bei Abweichungen.

Nächste Schritte

  • Zuletzt aktualisiert um