Translated ['', 'src/pentesting-cloud/azure-security/az-services/az-stor

2026-07-28 22:51:09 -07:00 · 2026-07-17 06:10:07 +00:00
parent 573438fcdd
commit 5eaa0e9c12
2 changed files with 153 additions and 153 deletions
@@ -4,47 +4,47 @@

 ## Azure SQL

-Azure SQL ist eine Familie von verwalteten, sicheren und intelligenten Produkten, die die **SQL Server database engine in der Azure cloud** verwenden. Das bedeutet, dass du dir keine Sorgen um die physische Administration deiner Server machen musst und dich auf die Verwaltung deiner Daten konzentrieren kannst.
+Azure SQL ist eine Familie verwalteter, sicherer und intelligenter Produkte, die die **SQL Server-Datenbank-Engine in der Azure-Cloud** verwenden. Das bedeutet, dass du dich nicht um die physische Administration deiner Server kümmern musst und dich auf die Verwaltung deiner Daten konzentrieren kannst.

-Azure SQL besteht aus vier Hauptangeboten:
+Azure SQL besteht aus vier主要 Angeboten:

 1. **Azure SQL Server**: Ein Server wird für die **Bereitstellung und Verwaltung** von SQL Server-Datenbanken benötigt.
-2. **Azure SQL Database**: Dies ist ein **vollständig verwalteter Database Service**, mit dem du einzelne Datenbanken in der Azure cloud hosten kannst.
-3. **Azure SQL Managed Instance**: Dies ist für Deployments mit größerem Umfang und für gesamte SQL Server instance-scoped Deployments gedacht.
-4. **Azure SQL Server on Azure VMs**: Dies ist am besten für Architekturen geeignet, bei denen du **Kontrolle über das operating system** und die SQL Server instance haben möchtest.
+2. **Azure SQL Database**: Dies ist ein **vollständig verwalteter Datenbankdienst**, mit dem du einzelne Datenbanken in der Azure-Cloud hosten kannst.
+3. **Azure SQL Managed Instance**: Dies ist für Bereitstellungen größeren Umfangs gedacht, die den gesamten SQL Server-Instanzbereich abdecken.
+4. **Azure SQL Server on Azure VMs**: Dies ist am besten für Architekturen geeignet, bei denen du **Kontrolle über das Betriebssystem **und die SQL Server-Instanz haben möchtest.

 ### SQL Server Security Features

-**Network access:**
+**Netzwerkzugriff:**

- Public endpoint (kann den Zugriff auf bestimmte networks beschränken).
- Private endpoints.
- Es ist auch möglich, Verbindungen basierend auf domain names einzuschränken.
- Es ist auch möglich, Azure services den Zugriff darauf zu erlauben (z. B. um den Query editor im portal zu verwenden oder damit sich eine Azure VM verbinden kann).
- Wenn bei einem SQL Server *Allow Azure services and resources to access this server* auf "Enabled" gesetzt ist, erstellt Azure automatisch eine versteckte firewall rule, die sämtlichen network traffic erlaubt, der aus Azure kommt, um sich mit dem SQL Server zu verbinden — einschließlich Ressourcen aus jedem tenant.
- Das bedeutet, dass du, wenn du gültige SQL credentials erhältst, dich von einer Azure VM innerhalb deines eigenen, vom Angreifer kontrollierten tenant mit dem Azure SQL Server des Opfers verbinden kannst. [Die MS docs erklärt das](https://learn.microsoft.com/en-us/azure/azure-sql/database/network-access-controls-overview?view=azuresql#allow-azure-services)
+- Öffentlicher Endpunkt (der Zugriff kann auf bestimmte Netzwerke beschränkt werden).
+- Private Endpunkte.
+- Es ist außerdem möglich, Verbindungen anhand von Domainnamen zu beschränken.
+- Es ist außerdem möglich, Azure-Diensten den Zugriff zu erlauben (beispielsweise zur Verwendung des Query editors im Portal oder damit sich eine Azure-VM verbinden kann).
+- Wenn bei einem SQL Server *Allow Azure services and resources to access this server* auf "Enabled" gesetzt ist, erstellt Azure automatisch eine verborgene Firewallregel, die sämtlichen Netzwerkverkehr aus Azure für die Verbindung mit dem SQL Server zulässt – einschließlich Ressourcen aus jedem Tenant.
+- Das bedeutet, dass du dich bei Erlangung gültiger SQL-Credentials von einer Azure-VM innerhalb deines eigenen, vom Angreifer kontrollierten Tenants mit dem Azure SQL Server des Opfers verbinden kannst. [Die MS-Dokumentation erklärt dies](https://learn.microsoft.com/en-us/azure/azure-sql/database/network-access-controls-overview?view=azuresql#allow-azure-services)

-**Authentication Methods:**
+**Authentifizierungsmethoden:**

- Microsoft **Entra-only** authentication: Du musst die Entra principals angeben, die Zugriff auf den service haben.
- **Both SQL and Microsoft Entra** authentication: Klassische SQL authentication mit username und password zusätzlich zu Microsoft Entra.
- **Only SQL** authentication: Zugriff nur über database users erlauben.
+- Microsoft **Entra-only**-Authentifizierung: Du musst die Entra-Principals angeben, die Zugriff auf den Dienst erhalten.
+- **Sowohl SQL- als auch Microsoft Entra**-Authentifizierung: Herkömmliche SQL-Authentifizierung mit Benutzername und Passwort zusätzlich zu Microsoft Entra.
+- **Nur SQL**-Authentifizierung: Zugriff wird nur über Datenbankbenutzer erlaubt.

-Beachte: Wenn irgendeine SQL auth erlaubt ist, muss ein admin user (username + password) angegeben werden, und wenn Entra ID auth ausgewählt ist, muss ebenfalls mindestens ein principal mit admin access angegeben werden.
+Beachte, dass bei erlaubter SQL-Authentifizierung ein Admin-Benutzer (Benutzername + Passwort) angegeben werden muss. Wenn die Entra-ID-Authentifizierung ausgewählt ist, muss außerdem mindestens ein Principal mit Admin-Zugriff angegeben werden.

-**Encryption:**
+**Verschlüsselung:**

- Sie heißt “Transparent data encryption” und verschlüsselt databases, backups und logs at rest.
- Wie immer wird standardmäßig ein Azure managed key verwendet, aber ein customer managed encryption key (CMEK) kann ebenfalls verwendet werden.
+- Sie wird „Transparent data encryption“ genannt und verschlüsselt Datenbanken, Backups und Logs im Ruhezustand.
+- Wie immer wird standardmäßig ein von Azure verwalteter Schlüssel verwendet, aber es kann auch ein kundenseitig verwalteter Verschlüsselungsschlüssel (CMEK) genutzt werden.
 **Managed Identities:**

- Es ist möglich, system- und user-managed MIs zuzuweisen.
- Wird verwendet, um auf den encryption key zuzugreifen (falls ein CMEK verwendet wird) und auf andere services aus den databases.
- Beispiele für Azure services, auf die von der database aus zugegriffen werden kann, findest du auf [dieser Seite der docs](https://learn.microsoft.com/en-us/sql/t-sql/statements/create-external-data-source-transact-sql)
- Wenn mehr als eine UMI zugewiesen ist, ist es möglich, die default one anzugeben, die verwendet werden soll.
- Es ist möglich, eine federated client identity für cross-tenant access zu konfigurieren.
+- Es ist möglich, system- und benutzerverwaltete MIs zuzuweisen.
+- Sie werden verwendet, um auf den Verschlüsselungsschlüssel (falls ein CMEK verwendet wird) und auf andere Dienste aus den Datenbanken zuzugreifen.
+- Beispiele für Azure-Dienste, auf die von der Datenbank aus zugegriffen werden kann, findest du [auf dieser Seite der Dokumentation](https://learn.microsoft.com/en-us/sql/t-sql/statements/create-external-data-source-transact-sql)
+- Wenn mehr als eine UMI zugewiesen ist, kann die standardmäßig zu verwendende angegeben werden.
+- Es ist möglich, eine federated client identity für den tenantübergreifenden Zugriff zu konfigurieren.

-Einige commands, um Informationen innerhalb eines blob storage aus einer SQL database zuzugreifen:
+Einige Befehle, um aus einer SQL-Datenbank auf Informationen innerhalb eines Blob Storage zuzugreifen:
 ```sql
 -- Create a credential for the managed identity
 CREATE DATABASE SCOPED CREDENTIAL [ManagedIdentityCredential]
@@ -71,58 +71,58 @@ GO
 ```
 **Microsoft Defender:**

- Useful for “mitigating potential database vulnerabilities, and detecting anomalous activities”
- We will talk about Defender in its own lesson (it can be enabled in several other Azure services)
+- Nützlich zur „Eindämmung potenzieller Datenbank-Schwachstellen und zur Erkennung anomaler Aktivitäten“
+- Wir werden Defender in einer eigenen Lektion behandeln (er kann in mehreren anderen Azure-Services aktiviert werden)

 **Backups:**
- Backup frequency is managed in the retention policies.
+- Die Backup-Häufigkeit wird in den Aufbewahrungsrichtlinien festgelegt.

-**Deleted databases:**
- It’s possible to restore DBs that have been deleted from existing backups.
+**Gelöschte Datenbanken:**
+- Es ist möglich, Datenbanken, die aus bestehenden Backups gelöscht wurden, wiederherzustellen.

 ## Azure SQL Database

-**Azure SQL Database** ist eine **fully managed database platform as a service (PaaS)**, die skalierbare und sichere relationale Datenbanklösungen bereitstellt. Es basiert auf den neuesten SQL Server-Technologien und macht Infrastrukturmanagement überflüssig, was es zu einer beliebten Wahl für cloud-based Anwendungen macht.
+**Azure SQL Database** ist eine **vollständig verwaltete Database platform as a service (PaaS)**, die skalierbare und sichere relationale Datenbanklösungen bereitstellt. Sie basiert auf den neuesten SQL Server-Technologien und macht die Verwaltung der Infrastruktur überflüssig, wodurch sie eine beliebte Wahl für cloudbasierte Anwendungen ist.

-To create a SQL database it’s needed to indicate the SQL server where it’ll be hosted.
+Zum Erstellen einer SQL-Datenbank muss der SQL-Server angegeben werden, auf dem sie gehostet wird.

 ### SQL Database Security Features

- **Always Up-to-Date**: Läuft auf der neuesten stabilen Version von SQL Server und erhält neue Features und Patches automatisch.
- **Inherited SQL Server security features:**
- Authentication (SQL and/or Entra ID)
- Assigned Managed Identities
+- **Always Up-to-Date**: Wird mit der neuesten stabilen Version von SQL Server ausgeführt und erhält automatisch neue Funktionen und Patches.
+- **Geerbte SQL Server-Sicherheitsfunktionen:**
+- Authentication (SQL und/oder Entra ID)
+- Zugewiesene Managed Identities
 - Network restrictions
 - Encryption
 - Backups
 - …
 - **Data redundancy:** Optionen sind local, zone, Geo oder Geo-Zone redundant.
- **Ledger:** Es verifiziert kryptografisch die Integrität von Daten und stellt sicher, dass jede Manipulation erkannt wird. Nützlich für Finanz-, Medizin- und alle Organisationen, die sensitive data verwalten.
+- **Ledger:** Überprüft die Integrität der Daten kryptografisch und stellt sicher, dass Manipulationen erkannt werden. Nützlich für Finanz-, Medizin- und jede andere Organisation, die sensible Daten verwaltet.


-A SQL database could be part of an **elastic Pool**. Elastic pools are a cost-effective solution for managing multiple databases by sharing configurable compute (eDTUs) and storage resources among them, with pricing based solely on the resources allocated rather than the number of databases.
+Eine SQL-Datenbank kann Teil eines **Elastic Pool** sein. Elastic Pools sind eine kostengünstige Lösung zur Verwaltung mehrerer Datenbanken, da sie konfigurierbare Compute-Ressourcen (eDTUs) und Speicherressourcen gemeinsam nutzen. Die Preisgestaltung basiert ausschließlich auf den zugewiesenen Ressourcen und nicht auf der Anzahl der Datenbanken.

 #### Azure SQL Column Level Security (Masking) & Row Level Security

-**Azure SQL's dynamic** data masking is a feature that helps **protect sensitive information by hiding it** from unauthorized users. Instead of altering the actual data, it dynamically masks the displayed data, ensuring that sensitive details like credit card numbers are obscured.
+**Das dynamische Data Masking von Azure SQL** ist eine Funktion, die dabei hilft, **sensible Informationen zu schützen, indem sie vor unbefugten Benutzern verborgen werden**. Anstatt die tatsächlichen Daten zu verändern, maskiert sie die angezeigten Daten dynamisch und stellt so sicher, dass sensible Details wie Kreditkartennummern unkenntlich gemacht werden.

-The **Dynamic Data Masking** affects to all users except the ones that are unmasked (these users need to be indicated) and administrators. It has the configuration option that specifies which SQL users are exempt from dynamic data masking, with **administrators always excluded**.
+Das **Dynamic Data Masking** betrifft alle Benutzer außer den Benutzern, für die die Maskierung aufgehoben wurde (diese Benutzer müssen angegeben werden), sowie Administratoren. Es verfügt über eine Konfigurationsoption, mit der festgelegt wird, welche SQL-Benutzer vom dynamischen Data Masking ausgenommen sind, wobei **Administratoren immer ausgeschlossen** sind.

-**Azure SQL Row Level Security (RLS)** is a feature that **controls which rows a user can view or modify**, ensuring each user only sees the data relevant to them. By creating security policies with filter or block predicates, organizations can enforce fine-grained access at the database level.
+**Azure SQL Row Level Security (RLS)** ist eine Funktion, die **kontrolliert, welche Zeilen ein Benutzer anzeigen oder ändern kann**, und stellt sicher, dass jeder Benutzer nur die für ihn relevanten Daten sieht. Durch das Erstellen von Sicherheitsrichtlinien mit Filter- oder Block-Prädikaten können Organisationen einen feingranularen Zugriff auf Datenbankebene erzwingen.

 ### Azure SQL Managed Instance

-**Azure SQL Managed Instances** are for larger scale, entire SQL Server instance-scoped deployments. It provides near 100% compatibility with the latest SQL Server on-premises (Enterprise Edition) Database Engine, which provides a native virtual network (VNet) implementation that addresses common security concerns, and a business model favorable for on-premises SQL Server customers.
+**Azure SQL Managed Instances** sind für groß angelegte Deployments auf Ebene einer vollständigen SQL Server-Instanz vorgesehen. Sie bieten nahezu 100 % Kompatibilität mit der neuesten lokalen SQL Server (Enterprise Edition) Database Engine. Außerdem bieten sie eine native Virtual Network (VNet)-Implementierung, die häufige Sicherheitsbedenken adressiert, sowie ein für lokale SQL Server-Kunden günstiges Geschäftsmodell.

 ### Azure SQL Virtual Machines

-**Azure SQL Virtual Machines** allows to **control the operating system** and the SQL Server instance, as a VM will be spawn in the VM service running the SQL server.
+**Azure SQL Virtual Machines** ermöglichen die **Kontrolle über das Betriebssystem** und die SQL Server-Instanz, da im VM-Service eine VM gestartet wird, auf der der SQL-Server ausgeführt wird.

-When a SQL Virtual Machine is created it’s possible to **selected all the settings of the VM** (as shown the VM lesson) that will be hosting the SQL server.
- This means that the VM will be accessing some VNet(s), might have **Managed Identities attached** to it, could have file shares mounted… making a **pivoting from the SQL** to the VM super interesting.
- Moreover, it’s possible to configure an app id and secret to **allow the SQL to access an specific key vault**, which could contain sensitive info.
+Beim Erstellen einer SQL Virtual Machine ist es möglich, **alle Einstellungen der VM auszuwählen** (wie in der VM-Lektion gezeigt), die den SQL-Server hosten wird.
+- Das bedeutet, dass die VM auf einige VNet(s) zugreifen kann, möglicherweise **Managed Identities an sie angehängt** sind und File Shares gemountet sein können … Dadurch wird ein **Pivoting von SQL** zur VM besonders interessant.
+- Außerdem ist es möglich, eine App-ID und ein Secret zu konfigurieren, um **SQL den Zugriff auf einen bestimmten Key Vault** zu ermöglichen, der sensible Informationen enthalten könnte.

-It's also possible to configure things like **automatic SQL updates**, **automatic backups**, **Entra ID authentication** and most of the features of the other SQL services.
+Es ist auch möglich, Dinge wie **automatische SQL-Updates**, **automatische Backups**, **Entra ID-Authentifizierung** und die meisten Funktionen der anderen SQL-Services zu konfigurieren.

 ## Enumeration

@@ -261,7 +261,7 @@ Get-AzSqlVM
 {{#endtab}}
 {{#endtabs}}

-Zusätzlich kannst du, wenn du Dynamic Data Masking und Row Level policies innerhalb der Datenbank enumerieren möchtest, folgende Abfrage verwenden:
+Zusätzlich können Sie, wenn Sie Dynamic Data Masking und Row Level policies innerhalb der Datenbank aufzählen möchten, Folgendes abfragen:
 ```sql
 --Enumerates the masked columns
 SELECT
@@ -286,9 +286,9 @@ JOIN sys.security_predicates AS sp2
 ON sp.object_id = sp2.object_id;

 ```
-### Verbinden und SQL-Abfragen ausführen
+### Verbindung herstellen und SQL-Abfragen ausführen

-Du könntest einen Verbindungsstring finden (der Anmeldedaten enthält) aus dem Beispiel [Enumerierung einer Az WebApp](az-app-services.md):
+Du könntest eine Verbindungszeichenfolge (mit Zugangsdaten) aus dem Beispiel zum enumerating einer Az WebApp finden:
 ```bash
 function invoke-sql{
 param($query)
@@ -307,11 +307,11 @@ $Connection.Close()

 invoke-sql 'Select Distinct TABLE_NAME From information_schema.TABLES;'
 ```
-Du kannst auch sqlcmd verwenden, um auf die Datenbank zuzugreifen. Es ist wichtig zu wissen, ob der Server öffentliche Verbindungen erlaubt `az sql server show --name <server-name> --resource-group <resource-group>`, und auch, ob die Firewall-Regel unsere IP den Zugriff erlaubt:
+Sie können auch sqlcmd verwenden, um auf die Datenbank zuzugreifen. Es ist wichtig zu wissen, ob der Server öffentliche Verbindungen zulässt: `az sql server show --name <server-name> --resource-group <resource-group>`; außerdem, ob die Firewall-Regel den Zugriff von unserer IP-Adresse erlaubt:
 ```bash
 sqlcmd -S <sql-server>.database.windows.net -U <server-user> -P <server-passworkd> -d <database>
 ```
-## References
+## Referenzen

 - [https://learn.microsoft.com/en-us/azure/azure-sql/azure-sql-iaas-vs-paas-what-is-overview?view=azuresql](https://learn.microsoft.com/en-us/azure/azure-sql/azure-sql-iaas-vs-paas-what-is-overview?view=azuresql)
 - [https://learn.microsoft.com/en-us/azure/azure-sql/database/single-database-overview?view=azuresql](https://learn.microsoft.com/en-us/azure/azure-sql/database/single-database-overview?view=azuresql)
@@ -4,52 +4,52 @@

 ## Grundlegende Informationen

-Azure Storage Accounts sind grundlegende Services in Microsoft Azure, die skalierbaren, sicheren und hochverfügbaren Cloud-**Storage für verschiedene Datentypen** bereitstellen, darunter blobs (binary large objects), files, queues und tables. Sie dienen als Container, die diese unterschiedlichen Storage-Services unter einem einzigen Namespace für eine einfache Verwaltung zusammenfassen.
+Azure Storage Accounts sind grundlegende Services in Microsoft Azure, die skalierbaren, sicheren und hochverfügbaren Cloud-**Speicher für verschiedene Datentypen** bereitstellen, einschließlich blobs (binary large objects), files, queues und tables. Sie dienen als Container, die diese verschiedenen Storage-Services zur einfachen Verwaltung unter einem einzigen Namespace zusammenfassen.

 **Wichtige Konfigurationsoptionen**:

- Jeder storage account muss einen **eindeutigen Namen innerhalb von Azure** haben.
- Jeder storage account wird in einer **Region** oder in einer Azure-Extended-Zone bereitgestellt
- Es ist möglich, die **premium**-Version des storage account für bessere Performance auszuwählen
- Es ist möglich, zwischen **4 Arten von Redundanz zu wählen, um sich** gegen Rack-, Drive- und Datacenter-**Ausfälle** zu schützen.
+- Jeder Storage Account muss einen **eindeutigen Namen in ganz Azure** haben.
+- Jeder Storage Account wird in einer **Region** oder einer Azure extended zone bereitgestellt.
+- Es ist möglich, die **Premium**-Version des Storage Accounts für eine bessere Performance auszuwählen.
+- Es ist möglich, zwischen **4 Redundanztypen zum Schutz** vor **Ausfällen** von Racks, Laufwerken und Rechenzentren auszuwählen.

-**Security-Konfigurationsoptionen**:
+**Sicherheitskonfigurationsoptionen**:

- **Require secure transfer for REST API operations**: TLS bei jeder Kommunikation mit dem Storage erzwingen
- **Allows enabling anonymous access on individual containers**: Wenn nicht, ist es in Zukunft nicht möglich, anonymen Zugriff zu aktivieren
- **Enable storage account key access**: Wenn nicht, wird der Zugriff mit Shared Keys verboten
+- **Require secure transfer for REST API operations**: TLS für jede Kommunikation mit dem Storage voraussetzen.
+- **Allows enabling anonymous access on individual containers**: Wenn dies nicht aktiviert ist, kann anonymer Zugriff in Zukunft nicht aktiviert werden.
+- **Enable storage account key access**: Wenn dies nicht aktiviert ist, wird der Zugriff mit Shared Keys verboten.
 - **Minimum TLS version**
- **Permitted scope for copy operations**: Erlaubt von jedem storage account, von jedem storage account aus demselben Entra tenant oder von storage account mit private endpoints im selben virtual network.
+- **Permitted scope for copy operations**: Kopien von jedem Storage Account, von jedem Storage Account im selben Entra tenant oder von Storage Accounts mit private endpoints im selben virtuellen Netzwerk erlauben.

 **Blob Storage-Optionen**:

 - **Allow cross-tenant replication**
- **Access tier**: Hot (häufig abgerufene Daten), Cool und Cold (selten abgerufene Daten)
+- **Access tier**: Hot (häufig verwendete Daten), Cool und Cold (selten verwendete Daten)

-**Networking-Optionen**:
+**Netzwerkoptionen**:

 - **Network access**:
- Zugriff von allen networks erlauben
- Zugriff von ausgewählten virtual networks und IP addresses erlauben
- Public access deaktivieren und private access verwenden
- **Private endpoints**: Ermöglicht eine private Verbindung zum storage account aus einem virtual network
+- Von allen Netzwerken erlauben.
+- Von ausgewählten virtuellen Netzwerken und IP-Adressen erlauben.
+- Öffentlichen Zugriff deaktivieren und privaten Zugriff verwenden.
+- **Private endpoints**: Ermöglicht eine private Verbindung zum Storage Account aus einem virtuellen Netzwerk.

-**Data protection-Optionen**:
+**Optionen für den Datenschutz**:

- **Point-in-time restore for containers**: Ermöglicht es, containers auf einen früheren Zustand wiederherzustellen
- Es erfordert, dass versioning, change feed und blob soft delete aktiviert sind.
- **Enable soft delete for blobs**: Aktiviert eine Aufbewahrungsdauer in Tagen für gelöschte blobs (auch überschrieben)
- **Enable soft delete for containers**: Aktiviert eine Aufbewahrungsdauer in Tagen für gelöschte containers
- **Enable soft delete for file shares**: Aktiviert eine Aufbewahrungsdauer in Tagen für gelöschte file shared
- **Enable versioning for blobs**: Frühere Versionen deiner blobs beibehalten
- **Enable blob change feed**: Logs für create-, modification- und delete-Änderungen an blobs behalten
- **Enable version-level immutability support**: Erlaubt dir, eine zeitbasierte Retention Policy auf Account-Ebene festzulegen, die für alle blob versions gilt.
+- **Point-in-time restore for containers**: Ermöglicht die Wiederherstellung von Containern auf einen früheren Zustand.
+- Erfordert, dass versioning, change feed und blob soft delete aktiviert sind.
+- **Enable soft delete for blobs**: Aktiviert einen Aufbewahrungszeitraum in Tagen für gelöschte blobs (auch überschriebene).
+- **Enable soft delete for containers**: Aktiviert einen Aufbewahrungszeitraum in Tagen für gelöschte Container.
+- **Enable soft delete for file shares**: Aktiviert einen Aufbewahrungszeitraum in Tagen für gelöschte file shares.
+- **Enable versioning for blobs**: Frühere Versionen deiner blobs beibehalten.
+- **Enable blob change feed**: Protokolle über Erstellungs-, Änderungs- und Löschvorgänge an blobs aufbewahren.
+- **Enable version-level immutability support**: Ermöglicht das Festlegen einer zeitbasierten Aufbewahrungsrichtlinie auf Account-Ebene, die auf alle blob-Versionen angewendet wird.
 - Version-level immutability support und point-in-time restore for containers können nicht gleichzeitig aktiviert werden.

-**Encryption-Konfigurationsoptionen**:
+**Optionen für die Verschlüsselungskonfiguration**:

- **Encryption type**: Es ist möglich, Microsoft-managed keys (MMK) oder Customer-managed keys (CMK) zu verwenden
- **Enable infrastructure encryption**: Ermöglicht eine doppelte Verschlüsselung der Daten „für mehr Sicherheit“
+- **Encryption type**: Es ist möglich, von Microsoft verwaltete Schlüssel (MMK) oder kundenseitig verwaltete Schlüssel (CMK) zu verwenden.
+- **Enable infrastructure encryption**: Ermöglicht die doppelte Verschlüsselung der Daten „für mehr Sicherheit“.

 ### Storage endpoints

@@ -62,21 +62,21 @@ Azure Storage Accounts sind grundlegende Services in Microsoft Azure, die skalie
 | **Queue storage** | `https://<storage-account>.queue.core.windows.net` |
 | **Table storage** | `https://<storage-account>.table.core.windows.net` |

-### Öffentliche Exponierung
+### Öffentliche Exposition

-Wenn "Allow Blob public access" **aktiviert** ist (standardmäßig deaktiviert), ist beim Erstellen eines Containers Folgendes möglich:
+Wenn **„Allow Blob public access“** **aktiviert** ist (standardmäßig deaktiviert), kann beim Erstellen eines Containers Folgendes festgelegt werden:

- **Öffentlichen Zugriff auf blobs zum Lesen gewähren** (du musst den Namen kennen).
- Container-blobs **auflisten** und **lesen**.
- Alles vollständig **privat** machen
+- **Öffentlichen Zugriff zum Lesen von blobs** gewähren (der Name muss bekannt sein).
+- **Container-blobs auflisten** und **lesen**.
+- Ihn vollständig **privat** machen.

 <figure><img src="https://lh7-rt.googleusercontent.com/slidesz/AGV_vUfoetUnYBPWQpRrWNnnlbqWpl8Rdoaeg5uBrCVlvcNDlnKwQHjZe8nUb2SfPspBgbu-lCZLmUei-hFi_Jl2eKbaxUtBGTjdUSDmkrcwr90VZkmuMjk9tyh92p75btfyzGiUTa0-=s2048?key=m8TV59TrCFPlkiNnmhYx3aZt" alt=""><figcaption></figcaption></figure>

-### Static website (`$web`) exposure & leaked secrets
+### Static website (`$web`)-Exposition & leaked secrets

- **Static websites** are served from the special `$web` container over a region-specific endpoint such as `https://<account>.z13.web.core.windows.net/`.
- The `$web` container may report `publicAccess: null` via the blob API, but files are still reachable through the static site endpoint, so dropping config/IaC artifacts there can leak secrets.
- Quick audit workflow:
+- **Static websites** werden über den speziellen `$web`-Container über einen regionsspezifischen Endpoint wie `https://<account>.z13.web.core.windows.net/` bereitgestellt.
+- Der `$web`-Container kann über die blob API `publicAccess: null` melden, aber Dateien sind weiterhin über den Static Site Endpoint erreichbar. Daher kann das Ablegen von Konfigurations-/IaC-Artefakten dort secrets leak.
+- Schneller Audit-Workflow:
 ```bash
 # Identify storage accounts with static website hosting enabled
 az storage blob service-properties show --account-name <acc-name> --auth-mode login
@@ -87,53 +87,53 @@ az storage blob list --container-name '$web' --account-name <acc-name> --auth-mo
 # Pull suspicious files directly (e.g., IaC tfvars containing secrets/SAS)
 az storage blob download -c '$web' --name iac/terraform.tfvars --file /dev/stdout --account-name <acc-name> --auth-mode login
 ```
-### Auditing anonymous blob exposure
+### Überprüfung anonymer Blob-Exponierung

- **Speicherkonten lokalisieren**, die Daten exponieren können: `az storage account list | jq -r '.[] | select(.properties.allowBlobPublicAccess==true) | .name'`. Wenn `allowBlobPublicAccess` `false` ist, kannst du Container nicht public machen.
- **Riskante Konten prüfen**, um das Flag und andere schwache Einstellungen zu bestätigen: `az storage account show --name <acc> --query '{allow:properties.allowBlobPublicAccess, minTls:properties.minimumTlsVersion}'`.
- **Container-level exposure auflisten**, wenn das Flag aktiviert ist:
+- **Storage accounts ermitteln**, die Daten offenlegen können: `az storage account list | jq -r '.[] | select(.properties.allowBlobPublicAccess==true) | .name'`. Wenn `allowBlobPublicAccess` auf `false` gesetzt ist, können Container nicht öffentlich gemacht werden.
+- **Riskante Accounts überprüfen**, um das Flag und andere unsichere Einstellungen zu bestätigen: `az storage account show --name <acc> --query '{allow:properties.allowBlobPublicAccess, minTls:properties.minimumTlsVersion}'`.
+- **Exponierung auf Containerebene ermitteln**, wenn das Flag aktiviert ist:
 ```bash
 az storage container list --account-name <acc> \
 --query '[].{name:name, access:properties.publicAccess}'
 ```
- `"Blob"`: anonyme Reads nur **wenn der Blob-Name bekannt ist** (kein Listing).
- `"Container"`: anonymes **list + read** von jedem Blob.
- `null`: privat; Authentication erforderlich.
- **Zugriff nachweisen** ohne credentials:
- Wenn `publicAccess` `Container` ist, funktioniert anonymes Listing: `curl "https://<acc>.blob.core.windows.net/<container>?restype=container&comp=list"`.
- Für sowohl `Blob` als auch `Container` funktioniert anonymes Downloaden eines Blobs, wenn der Name bekannt ist:
+- `"Blob"`: Anonyme Lesezugriffe sind **nur möglich, wenn der Blob-Name bekannt ist** (keine Auflistung).
+- `"Container"`: Anonyme **Auflistung + Lesen** jedes Blobs.
+- `null`: privat; Authentifizierung erforderlich.
+- **Zugriff ohne Zugangsdaten nachweisen:**
+- Wenn `publicAccess` den Wert `Container` hat, funktioniert die anonyme Auflistung: `curl "https://<acc>.blob.core.windows.net/<container>?restype=container&comp=list"`.
+- Sowohl für `Blob` als auch für `Container` funktioniert der anonyme Blob-Download, wenn der Name bekannt ist:
 ```bash
 az storage blob download -c <container> -n <blob> --account-name <acc> --file /dev/stdout
 # or via raw HTTP
 curl "https://<acc>.blob.core.windows.net/<container>/<blob>"
 ```
-### Connect to Storage
+### Mit Storage verbinden

-Wenn du irgendeinen **storage** findest, zu dem du dich verbinden kannst, könntest du das Tool [**Microsoft Azure Storage Explorer**](https://azure.microsoft.com/es-es/products/storage/storage-explorer/) dafür verwenden.
+Wenn du einen **Storage** findest, mit dem du dich verbinden kannst, könntest du dafür das Tool [**Microsoft Azure Storage Explorer**](https://azure.microsoft.com/es-es/products/storage/storage-explorer/) verwenden.

-## Access to Storage <a href="#about-blob-storage" id="about-blob-storage"></a>
+## Zugriff auf Storage <a href="#about-blob-storage" id="about-blob-storage"></a>

 ### RBAC

-Es ist möglich, Entra ID principals mit **RBAC roles** zu verwenden, um auf storage accounts zuzugreifen, und das ist der empfohlene Weg.
+Es ist möglich, Entra ID principals mit **RBAC roles** zu verwenden, um auf Storage accounts zuzugreifen. Dies ist die empfohlene Vorgehensweise.

 ### Access Keys

-Die storage accounts haben access keys, die verwendet werden können, um darauf zuzugreifen. Das bietet vollen Zugriff auf den storage account.
+Die Storage accounts verfügen über Access Keys, die für den Zugriff verwendet werden können. Dies ermöglicht den vollständigen Zugriff auf den Storage account.

 <figure><img src="../../../images/image (5).png" alt=""><figcaption></figcaption></figure>

 ### **Shared Keys & Lite Shared Keys**

-Es ist möglich, [**Shared Keys zu generieren**](https://learn.microsoft.com/en-us/rest/api/storageservices/authorize-with-shared-key), die mit den access keys signiert sind, um den Zugriff auf bestimmte Ressourcen über eine signierte URL zu autorisieren.
+Es ist möglich, mit den Access Keys signierte [**Shared Keys zu generieren**](https://learn.microsoft.com/en-us/rest/api/storageservices/authorize-with-shared-key), um den Zugriff auf bestimmte Ressourcen über eine signierte URL zu autorisieren.

 > [!NOTE]
-> Beachte, dass der Teil `CanonicalizedResource` die Ressource der storage services (URI) darstellt. Und wenn irgendein Teil in der URL kodiert ist, sollte er auch innerhalb von `CanonicalizedResource` kodiert sein.
+> Beachte, dass der Teil `CanonicalizedResource` die Ressource der Storage services (URI) darstellt. Wenn ein Teil der URL encoded ist, sollte er auch innerhalb von `CanonicalizedResource` encoded sein.

 > [!NOTE]
-> Dies wird standardmäßig vom `az` cli verwendet, um Requests zu authentifizieren. Damit es die Entra ID principal credentials verwendet, gib den Parameter `--auth-mode login` an.
+> Dies wird standardmäßig von der **az** cli verwendet, um Requests zu authentifizieren. Damit stattdessen die Credentials des Entra ID principals verwendet werden, muss der Parameter `--auth-mode login` angegeben werden.

- Es ist möglich, einen **shared key für blob, queue und file services** zu generieren, indem die folgenden Informationen signiert werden:
+- Es ist möglich, einen **shared key für blob-, queue- und file services** zu generieren, indem die folgenden Informationen signiert werden:
 ```bash
 StringToSign = VERB + "\n" +
 Content-Encoding + "\n" +
@@ -158,7 +158,7 @@ Content-Type + "\n" +
 Date + "\n" +
 CanonicalizedResource;
 ```
- Es ist möglich, einen **lite shared key for blob, queue and file services** zu generieren, indem die folgenden Informationen signiert werden:
+- Es ist möglich, einen **lite shared key für Blob-, Queue- und File-Services** zu generieren, indem die folgenden Informationen signiert werden:
 ```bash
 StringToSign = VERB + "\n" +
 Content-MD5 + "\n" +
@@ -167,12 +167,12 @@ Date + "\n" +
 CanonicalizedHeaders +
 CanonicalizedResource;
 ```
- Es ist möglich, einen **lite shared key for table services** zu generieren, indem die folgenden Informationen signiert werden:
+- Es ist möglich, einen **lite shared key für table services** zu generieren, indem die folgenden Informationen signiert werden:
 ```bash
 StringToSign = Date + "\n"
 CanonicalizedResource
 ```
-Dann kann der Schlüssel verwendet werden, indem er im Authorization-Header mit der folgenden Syntax angegeben wird:
+Dann kann der Schlüssel im Authorization-Header gemäß der folgenden Syntax verwendet werden:
 ```bash
 Authorization="[SharedKey|SharedKeyLite] <AccountName>:<Signature>"
 #e.g.
@@ -186,68 +186,68 @@ Content-Length: 0
 ```
 ### **Shared Access Signature** (SAS)

-Shared Access Signatures (SAS) sind sichere, zeitlich begrenzte URLs, die **spezifische Berechtigungen zum Zugriff auf Ressourcen** in einem Azure Storage account gewähren, ohne die access keys des Accounts offenzulegen. Während access keys vollständigen administrativen Zugriff auf alle Ressourcen bieten, ermöglicht SAS eine granulare Steuerung durch das Festlegen von Berechtigungen (wie read oder write) und einer Ablaufzeit.
+Shared Access Signatures (SAS) sind sichere, zeitlich begrenzte URLs, die **spezifische Berechtigungen für den Zugriff auf Ressourcen** in einem Azure Storage account gewähren, ohne die access keys des Accounts offenzulegen. Während access keys vollständigen administrativen Zugriff auf alle Ressourcen ermöglichen, erlaubt SAS eine granulare Kontrolle durch die Angabe von Berechtigungen (wie read oder write) und die Definition einer Ablaufzeit.

-#### SAS Types
+#### SAS-Typen

- **User delegation SAS**: Dies wird aus einem **Entra ID principal** erstellt, der die SAS signiert und die permissions vom user auf die SAS delegiert. Es kann nur mit **blob and data lake storage** verwendet werden ([docs](https://learn.microsoft.com/en-us/rest/api/storageservices/create-user-delegation-sas)). Es ist möglich, alle generierten user delegated SAS zu **revoke**.
- Auch wenn es möglich ist, eine delegation SAS mit "mehr" permissions zu generieren als die, die der user hat. Wenn der principal sie jedoch nicht hat, funktioniert es nicht (no privesc).
- **Service SAS**: Dies wird mit einem der storage account **access keys** signiert. Es kann verwendet werden, um Zugriff auf bestimmte Ressourcen innerhalb eines einzelnen storage service zu gewähren. Wenn der key erneuert wird, funktioniert die SAS nicht mehr.
- **Account SAS**: Auch dies wird mit einem der storage account **access keys** signiert. Es gewährt Zugriff auf Ressourcen über die storage account services hinweg (Blob, Queue, Table, File) und kann service-level operations enthalten.
+- **User delegation SAS**: Dies wird aus einem **Entra ID principal** erstellt, der die SAS signiert und die Berechtigungen vom Benutzer an die SAS delegiert. Es kann nur mit **blob and data lake storage** verwendet werden ([docs](https://learn.microsoft.com/en-us/rest/api/storageservices/create-user-delegation-sas)). Es ist möglich, alle generierten user delegated SAS zu **widerrufen**.
+- Auch wenn es möglich ist, eine delegation SAS mit „mehr“ Berechtigungen zu generieren, als der Benutzer besitzt, funktioniert sie nicht, wenn der principal diese Berechtigungen nicht besitzt (kein privesc).
+- **Service SAS**: Dies wird mit einem der **access keys** des storage account signiert. Es kann verwendet werden, um Zugriff auf bestimmte Ressourcen innerhalb eines einzelnen storage service zu gewähren. Wenn der key erneuert wird, funktioniert die SAS nicht mehr.
+- **Account SAS**: Sie wird ebenfalls mit einem der **access keys** des storage account signiert. Sie gewährt Zugriff auf Ressourcen über die services eines storage account hinweg (Blob, Queue, Table, File) und kann service-level operations enthalten.

-Eine SAS URL, die mit einem **access key** signiert ist, sieht so aus:
+Eine mit einem **access key** signierte SAS URL sieht wie folgt aus:

 - `https://<container_name>.blob.core.windows.net/newcontainer?sp=r&st=2021-09-26T18:15:21Z&se=2021-10-27T02:14:21Z&spr=https&sv=2021-07-08&sr=c&sig=7S%2BZySOgy4aA3Dk0V1cJyTSIf1cW%2Fu3WFkhHV32%2B4PE%3D`

-Eine SAS URL, die als **user delegation** signiert ist, sieht so aus:
+Eine als **user delegation** signierte SAS URL sieht wie folgt aus:

 - `https://<container_name>.blob.core.windows.net/testing-container?sp=r&st=2024-11-22T15:07:40Z&se=2024-11-22T23:07:40Z&skoid=d77c71a1-96e7-483d-bd51-bd753aa66e62&sktid=fdd066e1-ee37-49bc-b08f-d0e152119b04&skt=2024-11-22T15:07:40Z&ske=2024-11-22T23:07:40Z&sks=b&skv=2022-11-02&spr=https&sv=2022-11-02&sr=c&sig=7s5dJyeE6klUNRulUj9TNL0tMj2K7mtxyRc97xbYDqs%3D`

 Beachte einige **http params**:

- Der **`se`** param gibt das **expiration date** der SAS an
- Der **`sp`** param gibt die **permissions** der SAS an
- Der **`sig`** ist die **signature**, die die SAS validiert
+- Der **`se`**-Parameter gibt das **Ablaufdatum** der SAS an
+- Der **`sp`**-Parameter gibt die **Berechtigungen** der SAS an
+- **`sig`** ist die **Signatur**, die die SAS validiert

-#### SAS permissions
+#### SAS-Berechtigungen

-Beim Generieren einer SAS muss angegeben werden, welche permissions sie gewähren soll. Abhängig vom Objekt, über das die SAS generiert wird, können unterschiedliche permissions enthalten sein. Zum Beispiel:
+Beim Erstellen einer SAS müssen die zu gewährenden Berechtigungen angegeben werden. Abhängig von dem Objekt, für das die SAS generiert wird, können unterschiedliche Berechtigungen enthalten sein. Zum Beispiel:

 - (a)dd, (c)reate, (d)elete, (e)xecute, (f)ilter_by_tags, (i)set_immutability_policy, (l)ist, (m)ove, (r)ead, (t)ag, (w)rite, (x)delete_previous_version, (y)permanent_delete

-## SFTP Support for Azure Blob Storage
+## SFTP-Unterstützung für Azure Blob Storage

-Azure Blob Storage unterstützt jetzt das SSH File Transfer Protocol (SFTP), wodurch sichere Dateiübertragung und -verwaltung direkt zu Blob Storage möglich sind, ohne benutzerdefinierte Lösungen oder Produkte von Drittanbietern zu benötigen.
+Azure Blob Storage unterstützt jetzt das SSH File Transfer Protocol (SFTP) und ermöglicht sichere Dateiübertragungen sowie die Verwaltung direkt in Blob Storage, ohne dass individuelle Lösungen oder Produkte von Drittanbietern erforderlich sind.

-### Key Features
+### Hauptfunktionen

- Protocol Support: SFTP funktioniert mit Blob Storage accounts, die mit hierarchical namespace (HNS) konfiguriert sind. Dadurch werden blobs in directories und subdirectories organisiert, was die Navigation erleichtert.
- Security: SFTP kann lokale user identities verwenden, unterstützt aber auch Microsoft Entra ID-basierten Zugriff mit Azure RBAC zur authorization. Das bedeutet, dass Zugriff mit den üblichen Blob Storage data-plane roles gewährt werden kann, statt lokale SFTP users zu erstellen. Lokale users können sich authentifizieren über:
- Azure-generated passwords
- Public-private SSH key pairs
- Granular Permissions: Berechtigungen wie Read, Write, Delete und List können lokalen users für bis zu 100 containers zugewiesen werden.
- Networking Considerations: SFTP connections werden über port 22 hergestellt. Azure unterstützt network configurations wie firewalls, private endpoints oder virtual networks, um SFTP traffic abzusichern.
+- Protokollunterstützung: SFTP funktioniert mit Blob Storage accounts, die mit hierarchical namespace (HNS) konfiguriert sind. Dadurch werden blobs in Verzeichnissen und Unterverzeichnissen organisiert, was die Navigation erleichtert.
+- Sicherheit: SFTP kann lokale Benutzeridentitäten verwenden, unterstützt aber auch den auf Microsoft Entra ID basierenden Zugriff mit Azure RBAC zur Autorisierung. Dadurch kann der Zugriff mit den üblichen Blob Storage data-plane roles gewährt werden, anstatt lokale SFTP-Benutzer zu erstellen. Lokale Benutzer können sich authentifizieren über:
+- Von Azure generierte Passwörter
+- Öffentliche-private SSH-Schlüsselpaare
+- Granulare Berechtigungen: Berechtigungen wie Read, Write, Delete und List können lokalen Benutzern für bis zu 100 Container zugewiesen werden.
+- Netzwerkaspekte: SFTP-Verbindungen werden über Port 22 hergestellt. Azure unterstützt Netzwerkkonfigurationen wie Firewalls, private endpoints oder virtual networks, um den SFTP-Datenverkehr zu sichern.

-### Setup Requirements
+### Einrichtungsanforderungen

- Hierarchical Namespace: HNS muss beim Erstellen des storage account aktiviert sein.
- Supported Encryption: Erfordert von Microsoft Security Development Lifecycle (SDL) genehmigte cryptographic algorithms (z. B. rsa-sha2-256, ecdsa-sha2-nistp256).
- SFTP Configuration:
- SFTP auf dem storage account aktivieren.
- Für local-user access lokale user identities mit den passenden Berechtigungen erstellen.
- Für lokale users home directories konfigurieren, um ihren Startpunkt innerhalb des container zu definieren.
+- Hierarchical Namespace: HNS muss beim Erstellen des storage account aktiviert werden.
+- Unterstützte Verschlüsselung: Erfordert kryptografische Algorithmen, die vom Microsoft Security Development Lifecycle (SDL) genehmigt wurden (z. B. rsa-sha2-256, ecdsa-sha2-nistp256).
+- SFTP-Konfiguration:
+- SFTP im storage account aktivieren.
+- Für den Zugriff lokaler Benutzer lokale Benutzeridentitäten mit den entsprechenden Berechtigungen erstellen.
+- Für lokale Benutzer home directories konfigurieren, um ihren Startort innerhalb des Containers festzulegen.

-### Permissions
+### Berechtigungen

-| Permission             | Symbol | Description                          |
+| Berechtigung             | Symbol | Beschreibung                          |
 | ---------------------- | ------ | ------------------------------------ |
-| **Read**               | `r`    | Read file content.                   |
-| **Write**              | `w`    | Upload files and create directories. |
-| **List**               | `l`    | List contents of directories.        |
-| **Delete**             | `d`    | Delete files or directories.         |
-| **Create**             | `c`    | Create files or directories.         |
-| **Modify Ownership**   | `o`    | Change the owning user or group.     |
-| **Modify Permissions** | `p`    | Change ACLs on files or directories. |
+| **Read**               | `r`    | Dateiinhalt lesen.                   |
+| **Write**              | `w`    | Dateien hochladen und Verzeichnisse erstellen. |
+| **List**               | `l`    | Inhalte von Verzeichnissen auflisten.        |
+| **Delete**             | `d`    | Dateien oder Verzeichnisse löschen.         |
+| **Create**             | `c`    | Dateien oder Verzeichnisse erstellen.         |
+| **Modify Ownership**   | `o`    | Den besitzenden Benutzer oder die besitzende Gruppe ändern.     |
+| **Modify Permissions** | `p`    | ACLs für Dateien oder Verzeichnisse ändern. |

 ## Enumeration

@@ -379,7 +379,7 @@ az storage account local-user list \
 {{#tab name="Az PowerShell" }}

 <details>
-<summary>Az PowerShell Aufzählung</summary>
+<summary>Az PowerShell-Aufzählung</summary>
 ```powershell
 # Get storage accounts
 Get-AzStorageAccount | fl
@@ -442,7 +442,7 @@ New-AzStorageBlobSASToken `
 {{#endtab }}
 {{#endtabs }}

-### File Shares
+### Dateifreigaben

 {{#ref}}
 az-file-shares.md
@@ -466,7 +466,7 @@ az-file-shares.md
 ../az-persistence/az-storage-persistence.md
 {{#endref}}

-## References
+## Referenzen

 - [https://learn.microsoft.com/en-us/azure/storage/blobs/storage-blobs-introduction](https://learn.microsoft.com/en-us/azure/storage/blobs/storage-blobs-introduction)
 - [https://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview](https://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview)