Beskriva säkerhetsfunktioner

  • 8 minuter

Azure Database for MySQL – Flexibel server innehåller flera funktioner som är utformade för att skydda dina data och åtgärder. Nu ska vi titta på var och en av dessa funktioner.

Nätverk

Azure Database for MySQL – Flexibel server tillhandahåller robusta brandväggsinställningar för att skydda databasanslutningar för offentlig åtkomst samt virtuella Azure-nätverk (VNet). Det finns tre inställningar för den flexibla MySQL-serveranslutningen: offentlig åtkomst, privat åtkomst och en privat länk. I samtliga fall måste anslutningar fortfarande autentiseras med servern.

Offentlig åtkomst ger en offentligt matchbar DNS-adress som är tillgänglig via Internet genom en lista över tillåtna IP-adressintervall. Som standard tillåts inga IP-adresser. Du kan lägga till IP-adresser under eller efter skapandet. Du kan också tillåta åtkomst från valfri Azure IP-adress (inklusive andra kundprenumerationer i andra regioner).

Privat åtkomst använder ett delegerat undernät som värd för flexibla MySQL-servrar och tillhandahåller en DNS-adress som kan matchas inifrån det virtuella nätverket eller ett peer-kopplat virtuellt nätverk. Detta låser databasåtkomsten till bara din virtuella nätverksinfrastruktur. Du kan konfigurera brandväggsregler för nätverkssäkerhetsgrupp (NSG) för att filtrera nätverkstrafik mer exakt. Du kan använda privat åtkomst för att på ett säkert sätt ansluta till en flexibel MySQL-server från samma virtuella nätverk, från ett annat virtuellt nätverk med peering eller till och med lokalt med hjälp av en ExpressRoute- eller VPN-anslutning.

Privat länk ger en privat IP-adressslutpunkt i ett VNet-undernät för att ansluta till den flexibla MySQL-servern direkt. Azure Private Link innehåller i princip Azure-tjänster i ditt privata virtuella nätverk via en IP-adress som alla andra VNet-resurser. Du kan skapa flera privata slutpunkter, till exempel en per anslutande program eller Azure PaaS-resurs. I kombination med NSG-brandväggsregler ger privata länkar detaljerad kontroll över vilka tjänster som kan komma åt databasen.

Microsoft Defender för molnet

Microsoft Defender för molnet övervakar databasen efter ovanliga och potentiellt skadliga aktiviteter. Defender för molnet tillhandahålls som en tilläggsplan för att hantera potentiella hot utan att behöva skapa eller hantera säkerhetsövervakning. Defender för molnet har tillgänglighet för flera moln i Azure Database for MySQL – flexibel server, utöver MySQL på AWS Aurora och RDS. Defender för molnet stöder också PostgreSQL och MariaDB.

Defender för molnet identifierar databashot som:

  • Brute force-attacker: onormalt höga inloggningsfel och lyckad inloggning efter många fel.
  • Ovanliga inloggningsmönster: om en användare loggar in för första gången på över två månader.
  • Ovanliga inloggningsplatser: om en användare loggar in från en ovanlig Azure-databas, en annan molnleverantör eller en IP-adress som har flaggats som misstänkt.

Defender för molnet skickar identifieringsaviseringar till Azure Portal och via e-post. Aviseringar omfattar:

  • Information om den misstänkta aktiviteten.
  • Tillhörande MITRE ATT&CK (kontradiktoriska taktiker, tekniker och allmän kunskap).
  • Förslag för att undersöka och minimera attacken.
  • Fler alternativ att undersöka med Microsoft Sentinel.

Autentisering

Azure Database for MySQL erbjuder två autentiseringslägen: MySQL-autentisering (användarnamn/lösenord) och Microsoft Entra ID-autentisering. Du kan aktivera båda samtidigt.

Microsoft Entra ID-autentisering möjliggör identitetsbaserad autentisering till den flexibla MySQL-servern med hjälp av identiteter som tillhandahålls av Microsoft Entra ID. Detta centraliserar användarhantering för databasen och andra Microsoft-tjänster.

Som standard är en flexibel MySQL-server inställd på att endast använda MySQL-autentisering (användarnamn/lösenord). Du kan ändra den här inställningen så att endast Microsoft Entra ID-autentisering används (inga databasanvändare) eller kombinera hanterade identiteter med MySQL-autentisering.

När du använder Microsoft Entra-ID-autentisering finns det två administratörskonton: den ursprungliga MySQL-administratören och Microsoft Entra-ID-administratören. Microsoft Entra-ID-administratören kan vara antingen en användare eller en användargrupp. Om administratören är en grupp kan alla medlemmar i gruppen hantera Microsoft Entra-ID-autentisering. Administratörsgrupper är enklare att hantera eftersom det centraliserar användarhantering i Microsoft Entra-ID i stället för att behöva uppdatera MySQL-användare eller behörigheter direkt. Du kan bara konfigurera en Microsoft Entra-ID-administratör, oavsett om det är en enskild användare eller en enskild användargrupp.

Följande diagram visar de två lägena för att hantera autentisering.

Diagram som visar hur MySQL-administratörer och Microsoft Entra-administratörer för MySQL kan skapa användare och hantera Azure Database for MySQL – flexibel server.

När användare eller program försöker ansluta till en flexibel MySQL-server med hjälp av en Microsoft Entra-identitet utfärdas en token för att tillåta inloggning. Identiteten är associerad med en databasanvändare via deras unika Microsoft Entra-användar-ID i stället för deras namn eller andra attribut.

Datakryptering

MySQL flexibla servrar krypterar data under överföring. Som standard kräver servrar anslutning med TLS (Transport Layer Security) 1.2 och nekar okrypterade anslutningar eller anslutningar med hjälp av de inaktuella TLS 1.0- och 1.1-protokollen. Du kan inaktivera krypterade anslutningar (kan vara ett äldre program som inte stöder kryptering) eller tillåta versioner före 1.2 eller använda TLS 1.3, vilket är den rekommenderade inställningen för ny programutveckling.

Som standard krypterar Azure Database for MySQL – flexibel server vilande data (inklusive säkerhetskopiering och temporära filer som skapas när frågor körs) med hjälp av en symmetrisk AES 256-bitars datakrypteringsnyckel (DEK). Med kundhanterade nycklar (CMK) kan du ta med din egen nyckel (BYOK) för att lägga till ytterligare ett krypteringslager genom att kryptera tjänstens DEK.

BYOK ger dig fullständig kontroll över datakryptering och nyckellivscykel: skapande, uppladdning, rotation och borttagning. Genom att hantera nyckellivscykeln kan du anpassa nyckelrotationen till företagets principer och möjliggör separation av ansvarsområden för säkerhetsteam, DBA och systemadministratör.

Om du aktiverar CMK måste du länka en databas till en användartilldelad hanterad identitet (UMI) och sedan ange nyckeln, som lagras i Azure Key Vault, som ska användas. Om du skapar en kopia av servern krypteras kopian och du kan även lägga till hanterade identiteter och nycklar till befintliga repliker.