Open YouTube

Configure Azure Storage security | AZ-104 | Episode 18

Microsoft Learndutchenpublicupdated

Read in about 3 minutes instead of watching 20 minutes.

Beveiliging als uitgangspunt

  1. Azure-resources zijn meestal standaard beveiligd; open toegang alleen tot het noodzakelijke niveau.
  2. De sessie richt zich op gegevensbeveiliging voor Azure Blob Storage, met SAS-tokens, RBAC, toegangsbeheer en encryptie.
  3. Onderliggende objecten erven instellingen van bovenliggende objecten en machtigingen zijn cumulatief, behalve bij een expliciete deny.

Encryptie van opslag

  1. Alle gegevens in Azure Storage worden minimaal drie keer opgeslagen en standaard versleuteld in rust.
  2. Storage Service Encryption versleutelt blobs, files, tables en queues via encryptiesleutels op opslagaccountniveau.
  3. Standaard gebruikt Azure door Microsoft beheerde sleutels, maar organisaties kunnen ook eigen sleutels meenemen.
  4. Bij eigen sleutels wordt Key Vault aanbevolen voor veilige opslag en ophalen van sleutels.

RBAC en SAS-tokens

  1. RBAC biedt gecontroleerde toegang op basis van geauthenticeerde gebruikers en groepslidmaatschap.
  2. Het is meestal beter om machtigingen aan groepen toe te wijzen in plaats van direct aan individuele gebruikers.
  3. SAS-tokens geven toegang via een gedeelde tekenreeks en moeten zorgvuldig worden verspreid en beperkt.
  4. SAS-tokens kunnen worden beperkt met machtigingen, start- en eindtijd, IP-adresbereik en protocol.
  5. Gebruik bij voorkeur HTTPS voor SAS-toegang en bewaar tokens liever in Key Vault dan via e-mail te delen.

Container- en netwerktoegang

  1. Blobcontainers zijn standaard privé en staan geen anonieme toegang toe.
  2. De demonstratie laat zien hoe netwerktoegang en containerinstellingen kunnen worden geopend of weer afgesloten.
  3. Anonieme containertoegang maakt objecten publiek toegankelijk en wordt afgeraden voor gevoelige gegevens.
  4. Wanneer een object weer privé wordt gemaakt, geeft Azure aan dat het object niet bestaat, wat helpt tegen footprinting.
  5. Een SAS-token kan toegang geven tot een privéobject zonder de container publiek te maken.

SAS-URL en toegangsbeleid

  1. Een SAS-URL bevat de opslagaccountnaam, containernaam en beveiligingsinformatie waarmee toegang wordt verleend.
  2. Opslagaccountnamen moeten wereldwijd uniek zijn, maar DNS CNAME-records kunnen gebruiksvriendelijkere namen bieden.
  3. Er kunnen maximaal vijf access policies worden gebruikt om toegang voor groepen blobs te beheren.
  4. Immutable storage kan juridische bewaarplichten of tijdgebonden retentie afdwingen, ook wanneer objecten lijken te zijn verwijderd.

Lifecycle, tiers en replicatie

  1. Lifecycle management kan regels gebruiken om bestanden op basis van datum automatisch naar bijvoorbeeld cool storage te verplaatsen.
  2. Blobobjecten kunnen opslagtiers erven van het opslagaccount, zoals hot of cool inferred.
  3. Een expliciet ingestelde tier, zoals cold, blijft behouden wanneer de standaardtier van het account verandert.
  4. Objectreplicatie kan specifieke containers of mappen naar een ander opslagaccount kopiëren, bijvoorbeeld alleen nieuwe objecten.

Aanbevolen praktijken

  1. Gebruik waar mogelijk HTTPS en vermijd onversleutelde HTTP-communicatie.
  2. Beperk het aantal storage policies en verwijder beleid dat niet meer wordt gebruikt.
  3. Gebruik korte vervaltijden voor SAS-tokens en houd rekening met tijdzones bij internationale gebruikers.
  4. Security geldt voor alle Azure-services; storagebeheerders moeten de beschikbare beveiligingsopties goed kennen.

Actiepunten

  1. Gebruik waar mogelijk HTTPS voor toegang tot opslag en SAS-tokens.
  2. Beperk het aantal storage policies en verwijder policies die niet meer worden gebruikt.
  3. Gebruik korte vervaltijden voor SAS-tokens.
  4. Houd rekening met tijdzones bij het instellen van start- en eindtijden voor SAS-tokens.
  5. Gebruik Key Vault voor het opslaan en ophalen van SAS-tokens of eigen encryptiesleutels.