Azure SQL Database-beveiligingsfuncties

Azure SQL Database biedt een relationele databaseservice in Azure. Om klantgegevens te beschermen en sterke beveiligingsfuncties te bieden die klanten verwachten van een relationele databaseservice, beschikt SQL Database over eigen beveiligingsmogelijkheden. Deze mogelijkheden zijn gebaseerd op de besturingselementen die worden overgenomen van Azure.

Beveiligingsmogelijkheden

Gebruik van het TDS-protocol

Azure SQL Database ondersteunt alleen het TDS-protocol (Tabular Data Stream). Hiervoor moet de database alleen toegankelijk zijn via de standaardpoort van TCP/1433.

Azure SQL Database-firewall

Om klantgegevens te beschermen, bevat Azure SQL Database een firewallfunctionaliteit, die standaard alle toegang tot SQL Database voorkomt.

Azure SQL Database-firewall

De gatewayfirewall kan adressen beperken, waardoor klanten gedetailleerde controle kunnen opgeven om bereiken van acceptabele IP-adressen op te geven. De firewall verleent toegang op basis van het oorspronkelijke IP-adres van elke aanvraag.

Klanten kunnen firewallconfiguratie bereiken met behulp van een beheerportal of programmatisch met behulp van de Azure SQL Database Management REST API. De firewall van Azure SQL Database-gateway voorkomt standaard alle TDS-toegang van klanten tot Azure SQL Database. Klanten moeten de toegang configureren met behulp van toegangsbeheerlijsten (ACL's) om Azure SQL Database-verbindingen op internetadressen, protocollen en poortnummers van bron en doel toe te staan.

DoSGuard

DosGuard, een SQL Database gatewayservice, vermindert DoS-aanvallen (Denial of Service). DoSGuard traceert actief mislukte aanmeldingen van IP-adressen. Als er binnen een bepaalde periode meerdere mislukte aanmeldingen vanaf een IP-adres zijn, heeft het IP-adres gedurende een vooraf gedefinieerde periode geen toegang tot resources in de service.

Daarnaast voert de Azure SQL Database-gateway het volgende uit:

  • Onderhandelingen over de mogelijkheid van beveiligde kanalen om versleutelde verbindingen met TDS FIPS 140-2 te implementeren wanneer deze verbinding maakt met de databaseservers.
  • Stateful TDS-pakketinspectie terwijl verbindingen van clients worden geaccepteerd. De gateway valideert de verbindingsgegevens. De gateway geeft de TDS-pakketten door aan de juiste fysieke server op basis van de databasenaam die is opgegeven in de connection string.

Het overkoepelend principe voor netwerkbeveiliging van de Azure SQL Database-service is dat alleen de verbinding en communicatie die nodig zijn om de service uit te voeren, worden toegestaan. Alle andere poorten, protocollen en verbindingen worden standaard geblokkeerd. VLAN's (Virtual Local Area Networks) en ACL's worden gebruikt om netwerkcommunicatie te beperken op basis van bron- en doelnetwerken, protocollen en poortnummers.

Mechanismen die zijn goedgekeurd voor het implementeren van netwerkgebaseerde ACL's zijn ACL's op routers en load balancers. Deze mechanismen worden beheerd door Azure-netwerken, een firewall voor gast-VM's en Azure SQL Database-gatewayfirewallregels die door de klant zijn geconfigureerd.

Gegevensscheiding en klantisolatie

Het Azure-productienetwerk is zo gestructureerd dat openbaar toegankelijke systeemonderdelen worden gescheiden van interne resources. Er bestaan fysieke en logische grenzen tussen webservers die toegang bieden tot de openbare Azure Portal en de onderliggende virtuele Azure-infrastructuur, waar klanttoepassingsexemplaren en klantgegevens zich bevinden.

Alle openbaar toegankelijke informatie wordt beheerd in het Azure-productienetwerk. Het productienetwerk is:

  • Onderworpen aan mechanismen voor tweeledige verificatie en grensbescherming
  • Maakt gebruik van de set met firewall- en beveiligingsfuncties die in de vorige sectie zijn beschreven
  • Maakt gebruik van gegevensisolatiefuncties die in de volgende secties worden vermeld

Niet-geautoriseerde systemen en isolatie van de FC

Omdat de infrastructuurcontroller (FC) de centrale orchestrator van de Azure-infrastructuur is, zijn er belangrijke controles aanwezig om bedreigingen voor de infrastructuur te beperken, met name van mogelijk aangetaste CA's binnen klanttoepassingen. De FC herkent geen hardware waarvan de apparaatgegevens (bijvoorbeeld MAC-adres) niet vooraf zijn geladen in de FC. De DHCP-servers op de FC hebben een lijst geconfigureerd met MAC-adressen van de knooppunten die ze willen opstarten. Zelfs als niet-geautoriseerde systemen zijn verbonden, worden ze niet opgenomen in de infrastructuurinventaris en daarom niet verbonden of geautoriseerd om te communiceren met een systeem binnen de infrastructuurinventaris. Dit vermindert het risico dat niet-geautoriseerde systemen communiceren met de FC en toegang krijgen tot het VLAN en Azure.

VLAN-isolatie

Het Azure-productienetwerk is logisch gescheiden in drie primaire VLAN's:

  • Het belangrijkste VLAN: interconnects niet-vertrouwde klantknooppunten.
  • Het FC VLAN: bevat vertrouwde FC's en ondersteunende systemen.
  • Het VLAN van het apparaat: bevat vertrouwde netwerk- en andere infrastructuurapparaten.

Pakketfiltering

Het IPFilter en de softwarefirewalls die zijn geïmplementeerd op het hoofd- en gastbesturingssystemen van de knooppunten dwingen connectiviteitsbeperkingen af en voorkomen onbevoegd verkeer tussen VM's.

Hypervisor, hoofdbesturingssystemen en gast-VM's

De hypervisor en het hoofd-besturingssysteem beheren de isolatie van het hoofd-besturingssysteem van de gast-VM's en de gast-VM's van elkaar.

Typen regels voor firewalls

Een regel wordt gedefinieerd als:

{Src IP, Src Port, Destination IP, Destination Port, Destination Protocol, In/Out, Stateful/Stateless, Stateful Flow Timeout}.

Synchrone niet-actieve tekenpakketten (SYN) zijn alleen toegestaan als een van de regels dit toestaat. Voor TCP gebruikt Azure staatloze regels, waarbij het principe is dat alleen alle niet-SYN-pakketten in of uit de VM worden toegestaan. Het beveiligingspremisse is dat elke hoststack bestand is tegen het negeren van een niet-SYN als deze nog geen SYN-pakket eerder heeft gezien. Het TCP-protocol zelf is stateful en zorgt in combinatie met de stateless SYN-gebaseerde regel voor een algemeen gedrag van een stateful implementatie.

Voor User Datagram Protocol (UDP) gebruikt Azure een stateful regel. Telkens wanneer een UDP-pakket overeenkomt met een regel, wordt er een omgekeerde stroom in de andere richting gemaakt. Deze stroom heeft een ingebouwde time-out.

Klanten zijn verantwoordelijk voor het instellen van hun eigen firewalls op basis van wat Azure biedt. Hier kunnen klanten de regels voor inkomend en uitgaand verkeer definiëren.

Productieconfiguratiebeheer

Beveiligde standaardconfiguraties worden onderhouden door de respectieve operationele teams in Azure en Azure SQL Database. Alle configuratiewijzigingen in productiesystemen worden gedocumenteerd en bijgehouden via een centraal traceringssysteem. Software- en hardwarewijzigingen worden bijgehouden via het centrale traceringssysteem. Netwerkwijzigingen die betrekking hebben op ACL worden bijgehouden met behulp van een ACL-beheerservice.

Alle configuratiewijzigingen in Azure worden ontwikkeld en getest in de faseringsomgeving en worden vervolgens geïmplementeerd in de productieomgeving. Softwarebuilds worden beoordeeld als onderdeel van het testen. Beveiligings- en privacycontroles worden beoordeeld als onderdeel van de criteria van de controlelijst voor invoer. Wijzigingen worden volgens geplande intervallen geïmplementeerd door het respectieve implementatieteam. Releases worden gecontroleerd en afgetekend door het personeel van het respectieve implementatieteam voordat ze in productie worden geïmplementeerd.

Wijzigingen worden gecontroleerd op succes. In een foutscenario wordt de wijziging teruggedraaid naar de vorige status of wordt er een hotfix geïmplementeerd om de fout op te lossen met goedkeuring van het aangewezen personeel. Source Depot, Git, TFS, Master Data Services (MDS), runners, Azure-beveiligingsbewaking, de FC en het WinFabric-platform worden gebruikt om de configuratie-instellingen in de virtuele Azure-omgeving centraal te beheren, toe te passen en te verifiëren.

Op dezelfde manier hebben hardware- en netwerkwijzigingen validatiestappen ingesteld om te evalueren of ze voldoen aan de buildvereisten. De releases worden beoordeeld en geautoriseerd via een coordinated change advisory board (CAB) van de respectieve groepen in de stack.

Volgende stappen

Zie voor meer informatie over wat Microsoft doet om de Azure-infrastructuur te beveiligen: