• Noser.com
facebook
linkedin
twitter
youtube
  • NOSERmobile
    • Android
    • HTML 5
    • Hybrid Apps
    • iOS
    • Windows Phone
  • NOSERembedded
    • Medizintechnik
  • NOSERprojektmanagement
  • NOSERtesting
  • NOSERlifecycle
    • .NET Allgemein
    • Application Lifecylce Management
    • Apps
    • Architektur
    • ASP.NET
    • Azure
    • Cleancode
    • Cloud
    • Silverlight
    • Visual Studio / Team Foundation Server
    • Windows 8
    • Windows Presentation Foundation
  • NOSERinnovation
    • Big Data
    • Cloud
    • IoT
    • Operations Research
    • Augmented Reality
    • RFID, NFC, Bluetooth LE

Azure Übersicht Teil 2: SQL Datenspeicher

05. März 2020
Hans Peter Bornhauser
3
Azure, Big Data, SQL

Eine erste Übersicht über den Azure Storage wurde im ersten Teil dieser Blog Serie gegeben. In diesem Teil geht es um den Azure SQL Datenspeicher.

Für strukturierte Daten benötigt man eine Datenbank. Davon gibt es in Azure eine ganze Reihe, darunter 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 Datenspeicher

Azure SQL Database ist ein vollautomatischer Cloud-Dienst. Der Einsatz mind. 3 Kopien der Datenbank erhöht Zuverlässigkeit und Verfügbarkeit – 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.

Für die Verwaltung mehrere Datenbanken gibt es den Elastic Pool. Weil Applikationen normalerweise nicht eine konstante Last generieren, sind die erforderlichen Ressourcen auf möglichst viele Datenbanken verteilt. 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. Das sogenannte Encryption-at-rest 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. Der Service erkennt 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 werden unstrukturierten Daten betrachtet, welche z.B. in einer CosmosDB gespeichert werden können.

← Voriger Post
Nächster Post →

Azure Übersicht Teil 1: Storage

02. März 2020
Hans Peter Bornhauser
3
Azure, Big Data, Cloud

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 Storage Technologien zu finden, um ein gegebenes Problem zu lösen. Dabei spielen auch Betriebskosten, verfügbare Algorithmen und Entwicklungsaufwände eine Rolle. Darüber soll diese Blog-Serie 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 ist jede Datei mit einer eindeutigen URL von der ganzen Welt erreichbar, 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.

Azure Storage Types

Blob Storage

Blob Storage eignet sich besonders gut für:

  • Dateien, auf die der Browser direkt zugreifen kann (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), die eine unlimitierte Zahl von Blobs (entspricht File) enthalten können. 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. Queues entkoppeln einzelne Services skalierbarer Applikationen. 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. Hier findet sich ein 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 werden die verschiedenen Arten von strukturierten Datenspeichern in Azure wie z.B. dem SQL Server betrachtet.

Nächster Post →
12345

Tag Cloud

.NET android ANgular AngularJs app Arduino ASP.Net automated testing Azure Big Data C# C++ Cloud continuous integration Elm Embedded gRPC Internet of Things IoT Java Javascript M2M OWASP Projektmanagement protobuf Python Raspberry Pi Reactive Programming REST Scrum Security Softwarequalität SPA Testen testing Testmanagement Teststrategie Visual Studio WebAPI windows WPF Xamarin Xamarin.Android Xamarin.Forms Xamarin.iOS

Archive

Current Posts

  • Kreative Interaktion mit Xamarin.Forms Touch-Actions
  • Angular vs. React: Ein pragmatischer Vergleich
  • Eine Alternative zu Azure Time Series Insights, bitte?
  • Focus on the Secure Storage service of Trusted Firmware (TFM)
  • ZeroMQ / NetMQ mit Protocobuf

Last Comments

  • Noser Blog Touch-Actions in Xamarin.Forms - Noser Blog bei Mach mehr aus Animationen in Xamarin.Forms mit SkiaSharp
  • Noser Blog Focus on the Secure Storage service of Trusted Firmware (TFM) - Noser Blog bei First run of the Trusted Firmware (TFM) application
  • Noser Blog First run of the Trusted Firmware (TFM) application - Noser Blog bei Focus on the Secure Storage service of Trusted Firmware (TFM)
  • Noser Blog Focus on the Secure Storage service of Trusted Firmware (TFM) - Noser Blog bei Security management with Trusted Firmware
  • Noser Blog ZeroMQ / NetMQ mit Protocobuf - Noser Blog bei Tutorial: Protocol Buffers in ASP.NET Core

Popular Posts

Xamarin.Android Code Obfuscation

6 Comments

ManuScripts: Wenn jemand eine Reise tut... Funktionale Programmierung mit Elm - Teil 1 - Aufbruch

5 Comments

ManuScripts: Wenn jemand eine Reise tut... Funktionale Programmierung mit Elm - Teil 2 - Kein Picknick

4 Comments

Contact us

  1. Name *
    * Please enter your name
  2. Email *
    * Please enter a valid email address
  3. Message *
    * Please enter message
© 2013 NOSER ENGINEERING AG. All rights reserved. Datenschutz | Cookie-Richtlinie