Säkerhetsdokument för Azure Synapse Analytics: Dataskydd

  • Artikel

Kommentar

Den här artikeln är en del av azure Synapse Analytics säkerhetsdokumentserie med artiklar. En översikt över serien finns i säkerhetsdokumentet för Azure Synapse Analytics.

Identifiering och klassificering av data

Organisationer måste skydda sina data för att följa federala, lokala riktlinjer och företagets riktlinjer för att minska riskerna för dataintrång. En utmaning som organisationer står inför är: Hur skyddar du data om du inte vet var de finns? En annan är: Vilken skyddsnivå behövs?– eftersom vissa datauppsättningar kräver mer skydd än andra.

Föreställ dig en organisation med hundratals eller tusentals filer som lagras i deras datasjö och hundratals eller tusentals tabeller i deras databaser. Det skulle dra nytta av en process som automatiskt söker igenom varje rad och kolumn i filsystemet eller tabellen och klassificerar kolumner som potentiellt känsliga data. Den här processen kallas för dataidentifiering.

När dataidentifieringsprocessen är klar ger den klassificeringsrekommendationer baserat på en fördefinierad uppsättning mönster, nyckelord och regler. Någon kan sedan granska rekommendationerna och tillämpa känslighetsklassificeringsetiketter på lämpliga kolumner. Den här processen kallas klassificering.

Azure Synapse innehåller två alternativ för dataidentifiering och -klassificering:

  • Dataidentifiering och klassificering, som är inbyggd i Azure Synapse och en dedikerad SQL-pool (tidigare SQL DW).
  • Microsoft Purview, som är en enhetlig datastyrningslösning som hjälper till att hantera och styra lokala, multimoln- och saaS-data (software-as-a-service). Den kan automatisera dataidentifiering, ursprungsidentifiering och dataklassificering. Genom att skapa en enhetlig karta över datatillgångar och deras relationer blir det enkelt att identifiera data.

Kommentar

Microsoft Purview-dataidentifiering och -klassificering är i offentlig förhandsversion för Azure Synapse, dedikerad SQL-pool (tidigare SQL DW) och serverlös SQL-pool. Dataursprung stöds för närvarande inte för Azure Synapse, dedikerad SQL-pool (tidigare SQL DW) och serverlös SQL-pool. Apache Spark-poolen stöder endast ursprungsspårning.

Datakryptering

Data krypteras i vila och under överföring.

Vilande data

Som standard krypterar Azure Storage automatiskt alla data med 256-bitars Krypteringsstandardkryptering (AES 256). Det är en av de starkaste blockkrypteringarna som är tillgängliga och är FIPS 140-2-kompatibel. Plattformen hanterar krypteringsnyckeln och utgör det första lagret av datakryptering. Den här krypteringen gäller för både användar- och systemdatabaser, inklusive huvuddatabasen.

Om du aktiverar transparent datakryptering (TDE) kan du lägga till ett andra lager datakryptering för dedikerade SQL-pooler. Den utför I/O-kryptering i realtid och dekryptering av databasfiler, transaktionsloggfiler och säkerhetskopior i vila utan att kräva några ändringar i programmet. Som standard använder den AES 256.

Som standard skyddar TDE databaskrypteringsnyckeln (DEK) med ett inbyggt servercertifikat (tjänsthanterat). Det finns ett alternativ för att ta med din egen nyckel (BYOK) som kan lagras på ett säkert sätt i Azure Key Vault.

Azure Synapse SQL-serverlös pool och Apache Spark-pool är analysmotorer som fungerar direkt på Azure Data Lake Gen2 (ALDS Gen2) eller Azure Blob Storage. Dessa analyskörningar har ingen permanent lagring och förlitar sig på Azure Storage-krypteringstekniker för dataskydd. Som standard krypterar Azure Storage alla data med hjälp av kryptering på serversidan (SSE). Den är aktiverad för alla lagringstyper (inklusive ADLS Gen2) och kan inte inaktiveras. SSE krypterar och dekrypterar data transparent med hjälp av AES 256.

Det finns två SSE-krypteringsalternativ:

  • Microsoft-hanterade nycklar: Microsoft hanterar alla aspekter av krypteringsnyckeln, inklusive nyckellagring, ägarskap och rotationer. Det är helt transparent för kunderna.
  • Kundhanterade nycklar: I det här fallet krypteras den symmetriska nyckel som används för att kryptera data i Azure Storage med hjälp av en kundbaserad nyckel. Den stöder RSA- och RSA-HSM-nycklar (maskinvarusäkerhetsmoduler) i storlekarna 2048, 3072 och 4096. Nycklar kan lagras säkert i Azure Key Vault eller Azure Key Vault Managed HSM. Den ger detaljerad åtkomstkontroll för nyckeln och dess hantering, inklusive lagring, säkerhetskopiering och rotationer. Mer information finns i Kundhanterade nycklar för Azure Storage-kryptering.

SSE utgör det första krypteringsskiktet, men försiktiga kunder kan dubbelkryptera genom att aktivera ett andra lager med 256-bitars AES-kryptering på Azure Storage-infrastrukturlagret. Den kallas infrastrukturkryptering och använder en plattformshanterad nyckel tillsammans med en separat nyckel från SSE. Därför krypteras data i lagringskontot två gånger. en gång på tjänstnivå och en gång på infrastrukturnivå med två olika krypteringsalgoritmer och olika nycklar.

Data under överföring

Azure Synapse, en dedikerad SQL-pool (tidigare SQL DW) och en serverlös SQL-pool använder TDS-protokollet (Tabular Data Stream ) för att kommunicera mellan SQL-poolslutpunkten och en klientdator. TDS är beroende av TLS (Transport Layer Security) för kanalkryptering, vilket säkerställer att alla datapaket skyddas och krypteras mellan slutpunkten och klientdatorn. Det använder ett signerat servercertifikat från certifikatutfärdare (CA) som används för TLS-kryptering som hanteras av Microsoft. Azure Synapse stöder datakryptering under överföring med TLS v1.2 med hjälp av AES 256-kryptering.

Azure Synapse använder TLS för att säkerställa att data krypteras i rörelse. SQL-dedikerade pooler stöder TLS 1.0-, TLS 1.1- och TLS 1.2-versioner för kryptering där Microsoft-tillhandahållna drivrutiner använder TLS 1.2 som standard. Serverlös SQL-pool och Apache Spark-pool använder TLS 1.2 för alla utgående anslutningar.

Nästa steg

I nästa artikel i den här white paper-serien får du lära dig mer om åtkomstkontroll.