Eine erste Übersicht über den Azure Storage haben wir im ersten Teil dieser Blog Serie gesehen.

Für strukturierte Daten benötigen wir eine Datenbank. Davon gibt es in Azure eine ganze Reihe, auch solche, die nicht von Microsoft stammen, wie MariaDB, MySQL oder PostgreSQL.

Vom Microsoft SQL Server gibt es zunächst einmal zwei Varianten:

• Azure SQL Database Managed Instance
• Azure SQL Database

Die Managed Instance ist eine neue Deployment Variante des SQL Server, die mit dem normalen On-Premise Server weitgehend kompatibel ist. Dies macht es verhältnismässig einfach, eine bestehende Datenbank in die Cloud zu transferieren. Für 100% Kompatibilität braucht es einen SQL Server auf einer virtuellen Maschine, allerdings ist man dann selber für den Unterhalt (Backup und Patches) verantwortlich.

Azure SQL Database ist ein vollautomatischer Cloud-Dienst. Zuverlässigkeit und Verfügbarkeit wird erhöht durch mind. 3 Kopien der Datenbank – auch Geo-Redundanz ist möglich, um einem Totalausfall des Datacenters vorzubeugen. Im Vergleich zu einer On-Premise Datenbank fehlt der SQL Agent. Automatisches Backup (Full/differential und Transaction Log) erlaubt ein Restore zu jedem beliebigem Zeitpunkt. Bis zu 4 Geo-redundante Datenbanken sowie automatisches Fail-Over sind möglich. Automatisches Index Management und automatische Query Plan Korrekturen sorgen für bessere Performance.

Hat man viele Datenbanken, können diese in einem Elastic Pool verwaltet werden. Weil Applikationen normalerweise nicht eine konstante Last generieren, können vorhandene Ressourcen auf möglichst viele Datenbanken verteilt werden. Damit spart man Kosten, da die vorhandene Kapazität für viele Datenbanken zur Verfügung steht.

Die bisher beschriebenen Datenbanken eignen sich für OLTP (Online Transactional Processing), d.h. für transaktionsorientierte Aufgaben  (CRUD) für Applikationen und viele Benutzer. Die Datenbankgrösse ist bis 1 TByte.

Möchte man grosse Datenmengen per OLAP (Online Analytical Processing) analysieren, verwendet man das Azure SQL Data Warehouse, bzw. Azure Synapse Analytics, wie es inzwischen heisst.

Azure Synapse besteht aus 4 Komponenten:

• SQL Analytics
• Apache Spark
• Data Integration
• Studio

Der Azure Database Migration Service ermöglicht die Migration und Synchronisation einer On-Premise Datenbank mit einer Datenbank in der Cloud. Dies funktioniert sogar mit einer MySQL Datenbank.

Security Features

Azure SQL Database kennt vielfältige Security Features.

Verschlüsselung

SQL Server verwendet TLS 1.2 für die Datenübertragung. Gespeicherte Daten werden mit Transparent Data Encryption (TDE) geschützt. Encryption-at-rest, wie es auch genannt wird, eignet sich auch, um Dateien oder Backups zu verschlüsseln. Im Modus Always Encrypted (Encryption-in-use) besitzt nur der Client den Schlüssel, um die Daten zu sehen. Auch Server Admins oder andere privilegierte Benutzer können die Daten nicht lesen, was für Daten in der Cloud besonders nützlich ist. Die Verschlüsselung gilt für einzelne Spalten mit besonders sensitiven Informationen.

Dynamic Data Masking

Auf Daten, die nicht jeder Benutzer zu sehen bekommen soll (Kreditkartennummern, E-Mailadressen, Finanzzahlen) kann eine Maske gelegt werden, worauf nicht autorisierte Benutzer bei jedem Zugriff nur einen verschleierten Wert der Daten sehen. Dynamic Data Masking gibt es seit dem SQL Server 2016.

Threat Protection

Folgende 3 Mechanismen aus dem Advanced Data Security (ADS) Paket helfen dabei, mögliche Bedrohungen abzuwehren. ADS ist auch für Managed Instance und Azure Synapse Analytics erhältlich.

Data Discovery and Classification

Dieses Feature erlaubt es, sensitive Daten zu finden, klassifizieren, kennzeichnen und zu schützen. Der Zugriff auf so gekennzeichnete Daten kann überwacht werden.

Vulnerability Assessment

Der Vulnerability Assessment Service prüft eine Datenbank auf mögliche Sicherheitslöcher. Mögliche Fehlkonfigurationen (Berechtigungen, Firewall, sensitive Daten) werden so rasch aufgespürt und können behoben werden.

Threat Detection

Die Advanced Threat Detection überwacht den Zugriff auf eine Datenbank und detektiert Angriffe. Erkannt werden unsichere Abfragen, die SQL Injection erlauben, versuchte Angriffe auf die DB, ungewohnte Zugriffe, brute force Attacken auf die Authentisierung usw.

Auditing

Datenbank Events und Schreibzugriffe können in einem Audit Log gesammelt und von dort weiter verarbeitet werden. Dadurch lassen sich verdächtige Vorgänge aufspüren.

Im 3. Teil dieser Blogserie betrachten wir die unstrukturierten Daten, welche z.B. in einer CosmosDB gespeichert werden können.

Beschäftigt man sich mit Azure, trifft man auf eine ungeheure Vielzahl an Möglichkeiten und Varianten, wie man Daten in der Cloud speichern und analysieren kann. Es ist schwierig, unter den vielen ähnlichen Begriffen die richtige Kombination von Technologien zu finden, um ein gegebenes Problem zu lösen. Dabei spielen auch Betriebskosten, verfügbare Algorithmen und Entwicklungsaufwände eine Rolle. Diese Blog-Serie soll hier etwas Klärung verschaffen.

Beginnen wir mit dem Storage. Zuerst erstellt man einen neuen Storage Account:

Darin stehen 4 verschiedene Varianten zur Verfügung:

• Containers (Blob): kostengünstiger Speicher für alle Arten von unstrukturierten Daten wie Bilder, Dokumente oder binäre Daten.
• File Shares: File Shares, auf die via SMB Protokoll zugegriffen werden kann. Im Unterschied zu einem normalen Fileshare kann jede Datei mit einer eindeutigen URL von der ganzen Welt erreicht werden, geschützt mit einem Shared Access Signature (SAS) Token. Gut geeignet für Migration von Applikationen, die auf das Filesystem zugreifen.
• Tables: NoSQL Key-Value Store, ideal für strukturierte, nicht-relationale Daten.
• Queues: Asynchrone Message Queue für Kommunikation zwischen Micro-Services. Eine Message kann bis zu 64 kB gross sein, eine Queue kann Millionen von Messages speichern.

Blob Storage

Blob Storage eignet sich besonders gut für:

• Dateien, die direkt vom Browser geladen werden (Bilder, Dokumente)
• Video und Audio Streaming
• Log files
• Speicher für Backup und Archiv
• Speicher für Ergebnisse von Analysen

Es gibt drei Arten für Blob Storage, je nach der geforderten Zugriffsgeschwindigkeit: Hot, Cool oder Archive. Auf archivierte Blobs kann man nicht mehr direkt zugreifen. Ein Administrator kann Regeln definieren, unter welchen Bedingungen Blobs zwischen den Bereichen verschoben oder wann sie gelöscht werden sollen.

Blob Storage ist organisiert in Containern (entspricht Directory), in denen eine unlimitierte Zahl von Blobs (entspricht File) gespeichert werden kann. Man unterscheidet zwischen

• Block Blobs: Text und Binärdaten bis zu 4.7 TB.
• Append Blobs: Optimiert für das Hinzufügen von Daten, z.B. für Log Files
• Page Blobs: Speichern von Files bis zu 8 TB. Verwendet zum Speichern von VHD files oder als disks für virtuelle Maschinen.

Der Blobtyp kann beim Upload einer Datei spezifiziert werden.

Alle Daten sind automatisch verschlüsselt und redundant gespeichert. Die Schlüssel sind normalerweise im Microsoft Key Store oder im Azure Key Vault. Die Art der Replikation (lokal, Zone, Geo) wird beim Anlegen definiert.

Table Storage

Der Table Storage speichert strukturierte NoSQL-Daten als Key-Value ohne Schema. Er eignet sich für Daten, die keine komplexen Verknüpfungen haben und für schnellen Zugriff denormalisiert sind. Eine Alternative für den klassischen Table Storage ist inzwischen Cosmos DB, die auch ein Table API enthält und insgesamt mehr Funktionen bietet.

Queue

Der Azure Queue Storage ist ein Service, um eine grosse Zahl von Messages zu verarbeiten. Bei der Entwicklung skalierbarer Applikationen müssen einzelne Services entkoppelt werden.  Eine einzelne Queue Messsage kann bis zu 64 kByte gross sein und kann bis maximal 7 Tage in der Queue gespeichert sein. Queues sind über eine URL adressierbar:

https://<storage account>.queue.core.windows.net/<queue_name>

Clientbibliotheken sind für alle Plattformen erhältlich. Für .NET gibt es das NuGet Package “Microsoft.Azure.Storage.Common”.

Azure Data Lake

Eine spezielle Variante des Blob Storage ist der Azure Data Lake. Dabei handelt es sich um einen optimierten Speicher für sehr grosse Datenmengen mit hierarchischem Filesystem und Active Directory Unterstützung. Im Azure Data Lake speichert man vorwiegend grosse Mengen an Textfiles für die spätere Analyse. Vergleich zwischen Data Lake und Blob Storage.

Hinweis: Azure Data Lake Storage Gen1 wurde abgelöst durch Gen2. Für einen Data Lake Storage Gen 2 muss beim Anlegen eines Storage auf dem Advanced Tab der Hierarchical Namespace aktiviert werden.

Im 2. Teil dieser Blogserie möchte ich die verschiedenen Arten von strukturierten Datenspeichern in Azure wie z.B. dem SQL Server betrachten.