Beveiligingsfuncties beschrijven

  • 8 minuten

Azure Database for MySQL - Flexible Server biedt verschillende functies die zijn ontworpen voor het beveiligen en beveiligen van uw gegevens en bewerkingen. Laten we eens kijken naar elk van deze functies.

Netwerken

Azure Database for MySQL – Flexible Server biedt robuuste firewallinstellingen voor het beveiligen van databaseconnectiviteit voor openbare toegang en Azure Virtual Networks (VNets). Er zijn drie instellingen voor de flexibele MySQL-serververbinding: openbare toegang, privétoegang en een privékoppeling. In alle gevallen moeten verbindingen nog steeds worden geverifieerd met de server.

Openbare toegang biedt een openbaar om te omzetten DNS-adres dat toegankelijk is via internet door een lijst met toegestane IP-adresbereiken. Standaard zijn er geen IP-adressen toegestaan. U kunt IP-adressen toevoegen tijdens of na het maken. U kunt ook toegang vanaf elk Azure-IP-adres toestaan (inclusief andere klantabonnementen in andere regio's).

Privétoegang maakt gebruik van een gedelegeerd subnet voor het hosten van flexibele MySQL-servers en biedt een DNS-adres dat kan worden omgezet vanuit het VNet of een gekoppeld VNet. Hierdoor wordt databasetoegang tot alleen uw virtuele netwerkinfrastructuur vergrendeld. U kunt firewallregels voor netwerkbeveiligingsgroepen (NSG) instellen om netwerkverkeer nauwkeuriger te filteren. U kunt privétoegang gebruiken om veilig verbinding te maken met een flexibele MySQL-server vanuit hetzelfde VNet, vanuit een ander VNet met behulp van peering of zelfs vanuit on-premises met behulp van een ExpressRoute- of VPN-verbinding.

Private Link biedt een privé-IP-adreseindpunt in een VNet-subnet om rechtstreeks verbinding te maken met de flexibele MySQL-server. Azure Private Link brengt in wezen Azure-services binnen uw privé-VNet via een IP-adres zoals elke andere VNet-resource. U kunt verschillende privé-eindpunten maken, bijvoorbeeld één per verbindingstoepassing of Azure PaaS-resource. In combinatie met NSG-firewallregels bieden privékoppelingen nauwkeurige controle over welke services toegang hebben tot de database.

Microsoft Defender for Cloud

Microsoft Defender voor Cloud controleert uw database op ongebruikelijke en mogelijk schadelijke activiteiten. Defender voor Cloud wordt geleverd als een addon-plan om potentiële bedreigingen aan te pakken zonder dat u beveiligingsbewaking hoeft te bouwen of te beheren. Defender voor Cloud beschikt over multicloudbeschikbaarheid in Azure Database for MySQL - Flexible Server, naast MySQL op AWS Aurora en RDS. Defender voor Cloud ondersteunt ook PostgreSQL en MariaDB.

Defender voor Cloud detecteert databasebedreigingen zoals:

  • Beveiligingsaanvallen: abnormaal hoge aanmeldingsfouten en geslaagde aanmelding na veel fouten.
  • Ongebruikelijke aanmeldingspatronen: als een gebruiker zich gedurende meer dan twee maanden voor het eerst aanmeldt.
  • Ongebruikelijke aanmeldingslocaties: als een gebruiker zich aanmeldt vanuit een ongebruikelijke Azure-database of een andere cloudprovider, of een IP-adres dat als verdacht wordt gemarkeerd.

Defender voor Cloud stuurt detectiewaarschuwingen naar Azure Portal en via e-mail. Waarschuwingen zijn onder andere:

  • Details van de verdachte activiteit.
  • De bijbehorende MITRE ATT&CK (Adversarial Tactics, Techniques en Common Knowledge).
  • Suggesties voor het onderzoeken en beperken van de aanval.
  • Meer opties om te onderzoeken met Microsoft Sentinel.

Verificatie

Azure Database for MySQL biedt twee verificatiemodi: MySQL-verificatie (gebruikersnaam/wachtwoord) en Microsoft Entra ID-verificatie. U kunt beide tegelijk inschakelen.

Met Microsoft Entra ID-verificatie wordt verificatie op basis van identiteiten naar de flexibele MySQL-server mogelijk gemaakt met behulp van identiteiten die worden geleverd door Microsoft Entra ID. Hiermee centraliseert u gebruikersbeheer voor de database en andere Microsoft-services.

Een flexibele MySQL-server is standaard ingesteld op alleen MySQL-verificatie (gebruikersnaam/wachtwoord). U kunt deze instelling wijzigen om alleen Microsoft Entra ID-verificatie te gebruiken (geen databasegebruikers) of beheerde identiteiten combineren met MySQL-verificatie.

Wanneer u Microsoft Entra ID-verificatie gebruikt, zijn er twee beheerdersaccounts: de oorspronkelijke MySQL-beheerder en de Microsoft Entra ID-beheerder. De Microsoft Entra ID-beheerder kan een gebruiker of een gebruikersgroep zijn. Als de beheerder een groep is, kan elk lid van de groep Microsoft Entra ID-verificatie beheren. Beheerdersgroepen zijn eenvoudiger te beheren omdat het gebruikersbeheer in Microsoft Entra ID centraliseert in plaats van MySQL-gebruikers of -machtigingen rechtstreeks bij te werken. U kunt slechts één Microsoft Entra ID-beheerder configureren, ongeacht of dit één gebruiker of één gebruikersgroep is.

In het volgende diagram ziet u de twee modi voor het beheren van verificatie.

Diagram waarin wordt getoond hoe MySQL-beheerders en Microsoft Entra-beheerders voor MySQL gebruikers kunnen maken en Azure Database for MySQL - Flexible Server kunnen beheren.

Wanneer gebruikers of toepassingen verbinding proberen te maken met een flexibele MySQL-server met behulp van een Microsoft Entra-identiteit, wordt er een token uitgegeven om aanmelding toe te staan. De identiteit is gekoppeld aan een databasegebruiker via hun unieke Microsoft Entra-gebruikers-id, in plaats van hun naam of andere kenmerken.

Gegevensversleuteling

Flexibele MySQL-servers versleutelen gegevens tijdens overdracht. Servers moeten standaard verbinding maken met TLS 1.2 (Transport Layer Security) en niet-versleutelde verbindingen of verbindingen weigeren met behulp van de afgeschafte TLS 1.0- en 1.1-protocollen. U kunt versleutelde verbindingen uitschakelen (mogelijk een verouderde toepassing biedt geen ondersteuning voor versleuteling), of versies toestaan vóór 1.2 of TLS 1.3 gebruiken. Dit is de aanbevolen instelling voor het ontwikkelen van nieuwe toepassingen.

Azure Database for MySQL - Flexible Server versleutelt standaard data-at-rest (inclusief back-up- en tijdelijke bestanden die zijn gemaakt tijdens het uitvoeren van query's) met behulp van een symmetrische AES 256-bits gegevensversleutelingssleutel (DEK). Met door de klant beheerde sleutels (CMK) kunt u byok (Bring Your Own Key) gebruiken om een andere versleutelingslaag toe te voegen door de DEK van de service te versleutelen.

BYOK biedt u volledige controle over de levenscyclus van gegevensversleuteling en sleutel: maken, uploaden, rouleren en verwijderen. Door de levenscyclus van de sleutel te beheren, kunt u sleutelrotatie afstemmen op bedrijfsbeleid en kunt u de verantwoordelijkheden van beveiligingsteam, DBA en systeembeheerders scheiden.

Als u CMK inschakelt, moet u een database koppelen aan een door de gebruiker toegewezen beheerde identiteit (UMI) en vervolgens de sleutel opgeven die is opgeslagen in Azure Key Vault. Als u een kopie van de server maakt, wordt de kopie versleuteld en kunt u ook beheerde identiteiten en sleutels toevoegen aan bestaande replica's.