Verwenden von Virtual Network-Dienstendpunkten und -Regeln für Server in Azure SQL-Datenbank

Gilt für:Azure SQL-DatenbankAzure Synapse Analytics

VNET-Regeln sind ein Firewallsicherheitsfeature, mit dem gesteuert wird, ob der Server für Ihre Datenbanken und Pools für elastische Datenbanken in Azure SQL-Datenbank oder für Ihre Datenbanken mit dediziertem SQL-Pool (ehemals SQL DW) in Azure Synapse Analytics Nachrichten akzeptiert, die von bestimmten Subnetzen in virtuellen Netzwerken gesendet werden. In diesem Artikel wird erläutert, warum VNET-Regeln manchmal die beste Möglichkeit darstellen, um eine sichere Kommunikation mit Ihrer Datenbank in SQL-Datenbank und Azure Synapse Analytics zu ermöglichen.

Hinweis

Dieser Artikel gilt sowohl für SQL-Datenbank als auch für Azure Synapse Analytics. Der Einfachheit halber wird der Begriff Datenbank verwendet, wenn auf Datenbanken sowohl in SQL-Datenbank als auch in Azure Synapse Analytics verwiesen wird. Ebenso bezieht sich der Begriff Server auf den logischen Server, der SQL-Datenbank und Azure Synapse Analytics hostet.

Damit eine VNET-Regel erstellt werden kann, muss zuerst ein VNET-Dienstendpunkt vorhanden sein, auf den die Regel verweisen kann.

Hinweis

Microsoft Entra ID war zuvor als Azure Active Directory (Azure AD) bekannt.

Erstellen von VNET-Regeln

Wenn Sie nur eine VNET-Regel erstellen möchten, können Sie mit den Schritten und der Erklärung weiter unten in diesem Artikel fortfahren.

Details zu VNET-Regeln

In diesem Abschnitt werden verschiedene Details zu VNET-Regeln beschrieben.

Nur eine geografische Region

Jeder VNET-Dienstendpunkt gehört nur zu einer Azure-Region. Der Endpunkt ermöglicht anderen Regionen nicht das Akzeptieren von Nachrichten aus dem Subnetz.

Eine VNET-Regel ist auf die Region beschränkt, zu der der zugrunde liegende Endpunkt gehört.

Auf Serverebene, nicht auf Datenbankebene

Jede VNET-Regel gilt für den gesamten Server und nicht nur für eine bestimmte Datenbank auf dem Server. Das heißt, dass VNET-Regeln auf Server- und nicht auf Datenbankebene gelten.

Im Gegensatz dazu können IP-Regeln auf beiden Ebenen gelten.

Sicherheitsverwaltungsrollen

Bei der Verwaltung der VNET-Dienstendpunkte erfolgt eine Trennung von Sicherheitsrollen. Die folgenden Rollen müssen Aktionen ausführen:

• Netzwerkadministrator (Rolle Netzwerkmitwirkender): Aktivieren des Endpunkts.
• Datenbankadministrator (SQL Server-Rolledes Mitwirkenden): Aktualisieren der Zugriffssteuerungsliste, um das angegebene Subnetz dem Server hinzuzufügen.

Alternative zur Azure RBAC

Die Rollen „Netzwerkadministrator“ und „Datenbankadministrator“ haben mehr Zugriffsrechte, als für die Verwaltung von VNET-Regeln erforderlich ist. Es wird nur eine Teilmenge der Zugriffsrechte benötigt.

Sie können mit der rollenbasierten Zugriffssteuerung (RBAC) in Azure arbeiten, um eine einzelne benutzerdefinierte Rolle zu erstellen, die nur über die benötigte Teilmenge von Zugriffsrechten verfügt. Die benutzerdefinierte Rolle kann definiert werden, anstatt den Netzwerk- oder Datenbankadministrator einzubeziehen. Die auf die Sicherheit bezogene Angriffsfläche ist kleiner, wenn Sie einen Benutzer einer benutzerdefinierte Rolle hinzufügen und ihn nicht den beiden anderen wichtigen Administratorrollen hinzufügen.

Hinweis

In einigen Fällen befinden sich die Datenbank in SQL-Datenbank und das VNET-Subnetz in unterschiedlichen Abonnements. In diesen Fällen müssen Sie folgende Konfigurationen sicherstellen:

• Beide Abonnements müssen demselben Microsoft Entra-Mandanten zugeordnet sein.
• Der Benutzer muss über die erforderlichen Berechtigungen zum Initiieren der Vorgänge verfügen. Dazu gehören z. B. das Aktivieren von Dienstendpunkten und das Hinzufügen eines VNET-Subnetzes auf dem angegebenen Server.
• In beiden Abonnements muss der Anbieter „Microsoft.Sql“ registriert sein.

Einschränkungen

Bei SQL-Datenbank gelten für VNET-Regeln folgende Einschränkungen:

• In der Firewall für Ihre Datenbank in SQL-Datenbank verweist jede VNET-Regel auf ein Subnetz. Alle Subnetze, auf die verwiesen wird, müssen in derselben geografischen Region gehostet werden, in der die Datenbank gehostet wird.
• Für jeden Server können für ein angegebenes virtuelles Netzwerk maximal 128 Einträge in der Zugriffssteuerungsliste enthalten sein.
• VNET-Regeln gelten nur für virtuelle Netzwerke im Azure Resource Manager-Bereitstellungsmodell und nicht im klassischen Bereitstellungsmodell.
• Durch das Aktivieren von VNET-Dienstendpunkten für SQL-Datenbank werden auch die Endpunkte für Azure Database for MySQL und Azure Database for PostgreSQL aktiviert. Wenn Endpunkte auf EIN festgelegt sind, führen Verbindungsversuche von den Endpunkten mit Ihren Azure Database for MySQL- oder Azure Database for PostgreSQL-Instanzen zu Fehlern.
  • Der Grund dafür ist, dass für Azure Database for MySQL und Azure Database for PostgreSQL wahrscheinlich keine VNET-Regel konfiguriert wurde. Sie müssen für Azure Database for MySQL und Azure Database for PostgreSQL eine VNET-Regel konfigurieren.
  • Legen Sie zum Definieren von Firewallregeln für virtuelle Netzwerke auf einem logischen SQL-Server, der bereits mit privaten Endpunkten konfiguriert wurde, die Einstellung Zugriff auf öffentliches Netzwerk verweigern auf Nein fest.
• In der Firewall gelten zwar IP-Adressbereiche für die folgenden Netzwerkelemente, VNET-Regeln jedoch nicht:
  • Virtuelles privates S2S-Netzwerk (Site-to-Site-VPN)
  • Lokal über Azure ExpressRoute

Überlegungen zur Verwendung von Dienstendpunkten

Berücksichtigen Sie bei der Verwendung von Dienstendpunkten für SQL-Datenbank folgende Überlegungen:

• Ausgehend zu öffentlichen IP-Adressen von Azure SQL-Datenbank ist erforderlich: Netzwerksicherheitsgruppen (NSGs) müssen für IP-Adressen von SQL-Datenbank geöffnet werden, um Verbindungen zuzulassen. Sie erreichen dies, indem Sie für SQL-Datenbank NSG-Diensttags verwenden.

ExpressRoute

Wenn Sie ExpressRoute lokal für öffentliches Peering oder für Microsoft-Peering verwenden, müssen Sie die verwendeten NAT-IP-Adressen identifizieren. Beim öffentlichen Peering werden für jede ExpressRoute-Verbindung standardmäßig zwei NAT-IP-Adressen verwendet. Diese werden auf den Datenverkehr der Azure-Dienste angewendet, wenn der Datenverkehr im Microsoft Azure-Netzwerk-Backbone eintrifft. Beim Microsoft-Peering werden die verwendeten NAT-IP-Adressen entweder vom Kunden oder vom Dienstanbieter bereitgestellt. Um den Zugriff auf Ihre Dienstressourcen zuzulassen, müssen Sie diese öffentlichen IP-Adressen in der Ressourceneinstellung der IP-Firewall zulassen. Öffnen Sie über das Azure-Portal ein Supportticket für ExpressRoute, um die IP-Adressen Ihrer ExpressRoute-Verbindung für öffentliches Peering zu ermitteln. Weitere Informationen zur Netzwerkadressenübersetzung für öffentliches ExpressRoute-Peering und Microsoft-Peering finden Sie unter NAT-Anforderungen für öffentliches Azure-Peering.

Um die Kommunikation von Ihrer Verbindung mit SQL-Datenbank zu ermöglichen, müssen Sie IP-Netzwerkregeln für die öffentlichen IP-Adressen Ihrer Netzwerkadressenübersetzung erstellen.

Auswirkungen der Verwendung von VNET-Dienstendpunkten mit Azure Storage

In Azure Storage ist dasselbe Feature implementiert, mit dem Sie die Konnektivität mit Ihrem Azure Storage-Konto beschränken können. Wenn Sie dieses Feature mit einem Azure Storage-Konto verwenden, das von SQL-Datenbank genutzt wird, können Probleme auftreten. Im Folgenden finden Sie eine Liste mit Erläuterungen der Features von SQL-Datenbank und Azure Synapse Analytics, die hiervon betroffen sind.

Azure Synapse Analytics PolyBase und COPY-Anweisung

PolyBase und die COPY-Anweisung werden häufig verwendet, um Daten aus Azure Storage-Konten in Azure Synapse Analytics zu laden und damit einen hohem Durchsatz bei der Datenerfassung zu erzielen. Wenn das Azure Storage-Konto, aus dem Sie Daten laden, den Zugriff nur auf eine Gruppe von VNET-Subnetzen beschränkt, wird die Konnektivität mit dem Speicherkonto unterbrochen, wenn PolyBase und die COPY-Anweisung verwendet werden. Führen Sie die in diesem Abschnitt angegebenen Schritte aus, um Import- und Exportszenarien mit der COPY-Anweisung und PolyBase zu ermöglichen, in denen Azure Synapse Analytics eine Verbindung mit Azure Storage (im VNET gesichert) herstellt.

Voraussetzungen

• Installieren Sie Azure PowerShell. Weitere Informationen finden Sie unter Installieren des Azure Az PowerShell-Moduls.
• Wenn Sie über ein Konto vom Typ „Universell V1“ oder ein Azure Blob Storage-Konto verfügen, müssen Sie zunächst ein Upgrade auf „Universell V2“ durchführen. Befolgen Sie dazu die Schritte in Durchführen eines Upgrades auf ein Speicherkonto vom Typ „Universell V2“.
• Im Einstellungsmenü Firewalls und virtuelle Netzwerke des Azure Storage-Kontos muss die Option Vertrauenswürdigen Microsoft-Diensten den Zugriff auf dieses Speicherkonto erlauben aktiviert sein. Die Aktivierung dieser Konfiguration ermöglicht es PolyBase und der COPY-Anweisung, eine Verbindung mit dem Speicherkonto unter Verwendung starker Authentifizierung herzustellen, wobei der Netzwerkdatenverkehr auf dem Azure-Backbone verbleibt. Weitere Informationen finden Sie in diesem Leitfaden.

Wichtig

Das Azure Resource Manager-Modul von PowerShell wird von Azure SQL-Datenbank weiterhin unterstützt, aber alle zukünftigen Entwicklungen erfolgen für das Az.Sql-Modul. Das AzureRM-Modul erhält mindestens bis Dezember 2020 weiterhin Fehlerbehebungen. Die Argumente für die Befehle im Az-Modul und den AzureRm-Modulen sind im Wesentlichen identisch. Weitere Informationen zur Kompatibilität finden Sie in der Einführung in das neue Azure PowerShell Az-Modul.

Schritte

1. Wenn Sie über einen eigenständigen dedizierten SQL-Pool (ehemals SQL DW) verfügen, registrieren Sie Ihren SQL-Server mithilfe von PowerShell bei Microsoft Entra ID:

   Connect-AzAccount
   Select-AzSubscription -SubscriptionId <subscriptionId>
   Set-AzSqlServer -ResourceGroupName your-database-server-resourceGroup -ServerName your-SQL-servername -AssignIdentity
   

   Dieser Schritt ist für dedizierte SQL-Pools in einem Azure Synapse Analytics-Arbeitsbereich nicht erforderlich. Die vom System zugewiesene verwaltete Identität (SA-MI) des Arbeitsbereichs ist ein Mitglied der Synapse-Administratorrolle und verfügt daher über erhöhte Rechte für die dedizierten SQL-Pools des Arbeitsbereichs.

2. Erstellen Sie anhand der Schritte unter Erstellen eines Speicherkontos ein Speicherkonto vom Typ „Universell V2“ .

   • Wenn Sie über ein Konto vom Typ „Universell V1“ oder ein Blob Storage-Konto verfügen, müssen Sie zunächst ein Upgrade auf „Universell V2“ durchführen. Befolgen Sie dazu die Schritte in Durchführen eines Upgrades auf ein Speicherkonto vom Typ „Universell V2“.
   • Weitere Informationen zu Problemen mit Azure Data Lake Storage Gen2 finden Sie unter Bekannte Probleme mit Azure Data Lake Storage Gen2.

3. Wählen Sie auf der Seite für Ihr Speicherkonto die Option Zugriffssteuerung (IAM) aus.

4. Wählen Sie Hinzufügen>Rollenzuweisung hinzufügen aus, um die Seite Rollenzuweisung hinzufügen zu öffnen.

5. Weisen Sie die folgende Rolle zu. Ausführliche Informationen finden Sie unter Zuweisen von Azure-Rollen über das Azure-Portal.

   Einstellung	Wert
   Role	Mitwirkender an Storage-Blobdaten
   Zugriff zuweisen zu	Benutzer, Gruppe oder Dienstprinzipal
   Member	Server oder Arbeitsbereich, auf bzw. in dem Ihr bei Microsoft Entra ID registrierter dedizierter SQL-Pool gehostet wird

   

   Hinweis

   Nur Mitglieder mit der Berechtigung „Besitzer“ für das Speicherkonto können diesen Schritt ausführen. Informationen zu den integrierten Azure-Rollen finden Sie unter Integrierte Azure-Rollen.

6. So aktivieren Sie PolyBase-Konnektivität mit dem Azure Storage-Konto

   1. Erstellen Sie einen Masterschlüssel für die Datenbank, falls Sie dies noch nicht durchgeführt haben.

      CREATE MASTER KEY [ENCRYPTION BY PASSWORD = 'somepassword'];
      

   2. Erstellen Sie mit IDENTITY = 'Managed Service Identity' datenbankweit gültige Anmeldeinformationen.

      CREATE DATABASE SCOPED CREDENTIAL msi_cred WITH IDENTITY = 'Managed Service Identity';
      

      • Es ist nicht erforderlich, für den Azure Storage-Zugriffsschlüssel den Zusatz SECRET anzugeben, da bei diesem Vorgang die verwaltete Identität im Hintergrund verwendet wird. Dieser Schritt ist für dedizierte SQL-Pools in einem Azure Synapse Analytics-Arbeitsbereich nicht erforderlich. Die vom System zugewiesene verwaltete Identität (SA-MI) des Arbeitsbereichs ist ein Mitglied der Synapse-Administratorrolle und verfügt daher über erhöhte Rechte für die dedizierten SQL-Pools des Arbeitsbereichs.

      • Der IDENTITY-Name muss 'Managed Service Identity' lauten, damit die PolyBase-Konnektivität mit dem im virtuellen Netzwerk geschützten Azure Storage-Konto funktioniert.

   3. Erstellen Sie mit dem Schema abfss:// eine externe Datenquelle für die Verbindungsherstellung mit Ihrem Speicherkonto vom Typ „Universell V2“ unter Verwendung von PolyBase.

      CREATE EXTERNAL DATA SOURCE ext_datasource_with_abfss WITH (TYPE = hadoop, LOCATION = 'abfss://myfile@mystorageaccount.dfs.core.windows.net', CREDENTIAL = msi_cred);
      

      • Falls dem Speicherkonto vom Typ „Universell V1“ oder dem Blob Storage-Konto bereits externe Tabellen zugeordnet sind, sollten Sie zuerst diese externen Tabellen verwerfen. Trennen Sie danach die entsprechende externe Datenquelle. Erstellen Sie als Nächstes wie oben gezeigt mit dem Schema abfss:// eine externe Datenquelle, die mit Ihrem Speicherkonto vom Typ „Universell V2“ verbunden ist. Erstellen Sie dann alle externen Tabellen mit dieser neuen externen Datenquelle neu. Sie können den Assistenten zum Generieren und Veröffentlichen von Skripts verwenden, um auf einfache Weise Erstellungsskripts für alle externen Tabellen zu generieren.
      • Weitere Informationen zum Schema abfss:// finden Sie unter Verwenden des Azure Data Lake Storage Gen2-URI.
      • Weitere Informationen zu den T-SQL-Befehlen finden Sie unter CREATE EXTERNAL DATA SOURCE.

   4. Führen Sie Abfragen wie gewohnt durch, indem Sie externe Tabellen verwenden.

SQL-Datenbank – Blobüberwachung

Die Azure SQL-Überwachung kann SQL-Überwachungsprotokolle in Ihr eigenes Speicherkonto schreiben. Wenn dieses Speicherkonto das VNET-Dienstendpunktfeature verwendet, finden Sie weitere Informationen unter Schreiben von Überwachungsprotokollen in ein Speicherkonto hinter einem VNET oder einer Firewall.

Hinzufügen einer Firewallregel für virtuelle Netzwerke auf dem Server

Vor der Verbesserung dieses Features mussten Sie die VNET-Dienstendpunkte aktivieren, bevor Sie eine aktive VNET-Regel in der Firewall implementieren konnten. Die Endpunkte verknüpften ein bestimmtes VNET-Subnetz mit einer Datenbank in SQL-Datenbank. Seit Januar 2018 können Sie diese Anforderung umgehen, indem Sie das Flag IgnoreMissingVNetServiceEndpoint festlegen. Nun können Sie auf dem Server eine Firewallregel für virtuelle Netzwerke hinzufügen, ohne VNET-Dienstendpunkte zu aktivieren.

Allein das Festlegen einer Firewallregel trägt nicht zum Schutz des Servers bei. Sie müssen auch VNET-Dienstendpunkte aktivieren, damit der Server geschützt wird. Wenn Sie Dienstendpunkte aktivieren, fällt das VNET-Subnetz solange aus, bis der Übergang von „deaktiviert“ zu „aktiviert“ abgeschlossen ist. Diese Ausfallzeit ist insbesondere bei großen virtuellen Netzwerken von Bedeutung. Mithilfe des Flags IgnoreMissingVNetServiceEndpoint können Sie die Ausfallzeit während des Übergangs reduzieren bzw. vermeiden.

Verwenden Sie PowerShell, um das Flag IgnoreMissingVNetServiceEndpoint festzulegen. Weitere Informationen finden Sie unter Verwenden von PowerShell zum Erstellen eines VNET-Dienstendpunkts und einer Regel für SQL-Datenbank.

Hinweis

Ähnliche Anweisungen in Azure Synapse Analytics finden Sie unter IP-Firewallregeln für Azure Synapse Analytics

Erstellen einer VNET-Regel im Azure-Portal

In diesem Abschnitt wird veranschaulicht, wie Sie im Azure-Portal eine VNET-Regel in Ihrer Datenbank in SQL-Datenbank erstellen. Die Regel weist Ihre Datenbank an, Nachrichten von einem bestimmten Subnetz zu akzeptieren, das als VNET-Dienstendpunkt gekennzeichnet ist.

Hinweis

Wenn Sie beabsichtigen, den VNET-Firewallregeln Ihres Servers einen Dienstendpunkt hinzuzufügen, stellen Sie zunächst sicher, dass die Dienstendpunkte für das Subnetz aktiviert sind.

Wenn Dienstendpunkte für das Subnetz nicht aktiviert sind, werden Sie im Portal dazu aufgefordert. Wählen Sie im selben Bereich, auf dem Sie auch die Regel hinzufügen, die Schaltfläche Aktivieren aus.

Voraussetzungen

Falls Sie bereits ein Subnetz haben, das mit dem bestimmten VNET-Dienstendpunkt gekennzeichnet ist, geben Sie den Namen ein, der zur SQL-Datenbank-Instanz gehört.

• Der Typname dieses Endpunkts ist Microsoft.Sql.
• Wenn Ihr Subnetz nicht mit dem Typnamen gekennzeichnet werden kann, lesen Sie unter Überprüfen, ob Ihr Subnetz ein Endpunkt ist nach.

Schritte im Azure-Portal

1. Melden Sie sich beim Azure-Portal an.

2. Suchen Sie nach SQL-Server, und wählen Sie dann Ihren Server aus. Wählen Sie unter Sicherheit die Option Netzwerk aus.

3. Stellen Sie auf der Registerkarte Öffentlicher Zugriff sicher, dass der Öffentlicher Netzwerkzugriff auf Netzwerke auswählen festgelegt ist. Andernfalls sind die Einstellungen für virtuelle Netzwerke ausgeblendet. Wählen Sie die Option + Vorhandenes virtuelles Netzwerk hinzufügen in dem Abschnitt Virtuelle Netzwerke aus.

   

4. Füllen Sie im Bereich Erstellen/Aktualisieren die Felder mit den Namen Ihrer Azure-Ressourcen aus.

   Tipp

   Sie müssen das richtige Adresspräfix für Ihr Subnetz hinzufügen. Den Wert für das Adresspräfix finden Sie im Portal. Navigieren Sie zu Alle Ressourcen>Alle Typen>Virtuelle Netzwerke. Der Filter zeigt Ihre virtuellen Netzwerke an. Wählen Sie Ihr virtuelles Netzwerk und dann Subnetze aus. Die Spalte ADRESSBEREICH enthält das Adresspräfix, das Sie benötigen.

   

5. Die resultierende VNET-Regel wird im Bereich Firewall angezeigt.

   

6. Legen Sie Azure-Diensten und -Ressourcen den Zugriff auf diesen Server erlauben auf Nein fest.

   Wichtig

   Wenn Sie Azure-Diensten und -Ressourcen den Zugriff auf diesen Server erlauben aktiviert lassen, akzeptiert Ihr Server die Kommunikation von jedem Subnetz innerhalb der Azure-Grenzen. Dies umfasst die gesamte Kommunikation, die von einer der IP-Adressen stammt, die innerhalb der für Azure-Rechenzentren definierten Bereiche liegen. Wenn Sie das Steuerelement nicht deaktivieren, kann das unter Sicherheitsaspekten zu einem übermäßigen Zugriff führen. Mithilfe der Features VNET-Dienstendpunkte von Microsoft Azure und VNET-Regeln von SQL-Datenbank können Sie die sicherheitsrelevante Angriffsfläche verkleinern.

7. Wählen Sie am unteren Rand des Bereichs die Schaltfläche OK aus.

Hinweis

Für die Regeln gelten die folgenden Status oder Zustände:

• Bereit: Gibt an, dass der von Ihnen initiierte Vorgang erfolgreich war.
• Fehler: Gibt an, dass der von Ihnen initiierte Vorgang zu einem Fehler geführt hat.
• Gelöscht: Gilt nur für den Löschvorgang und gibt an, dass die Regel gelöscht wurde und nicht mehr angewandt wird.
• InProgress (In Bearbeitung): Gibt an, dass der Vorgang ausgeführt wird. In diesem Zustand wird die alte Regel weiter angewendet.

Erstellen einer VNET-Regel in PowerShell

Mit einem Skript können Sie auch VNET-Regeln erstellen. Verwenden Sie dazu das PowerShell-Cmdlet New-AzSqlServerVirtualNetworkRuleoder oder den Befehl az network vnet create. Weitere Informationen finden Sie unter Verwenden von PowerShell zum Erstellen eines VNET-Dienstendpunkts und einer Regel für SQL-Datenbank.

Erstellen einer VNET-Regel in einer REST-API

Intern rufen die PowerShell-Cmdlets für SQL-VNET-Aktionen REST-APIs auf. Sie können die REST-APIs direkt aufrufen. Weitere Informationen finden Sie unter VNET-Regeln: Vorgänge.

Problembehandlung 40914 und 40615

Der Verbindungsfehler 40914 bezieht sich auf VNET-Regeln, die im Azure-Portal im Bereich Firewall angegeben werden. Beim Fehler 40615 verhält es sich ähnlich, nur dass sich dieser Fehler auf IP-Adressregeln in der Firewall bezieht.

Fehler 40914

Nachrichtentext: „Der bei der Anmeldung angeforderte Server ' [Servername] ' kann nicht geöffnet werden. Dem Client ist der Zugriff auf den Server nicht gestattet.“

Fehlerbeschreibung: Der Client befindet sich in einem Subnetz, das Endpunkte des virtuellen Netzwerkservers enthält. Der Server enthält jedoch keine VNET-Regeln, die dem Subnetz die Berechtigung zur Kommunikation mit der Datenbank gewähren.

Fehlerbehebung: Verwenden Sie im Azure-Portal im Bereich Firewall die Steuerung von VNET-Regeln, um eine VNET-Regel für das Subnetz hinzuzufügen.

Fehler 40615

Nachrichtentext: „In Anmeldung angeforderter Server '{0}'kann nicht geöffnet werden. Der Client mit der IP-Adresse '{1}' hat keine Zugriffsberechtigung für den Server.“

Fehlerbeschreibung: Der Client versucht, eine Verbindung über eine IP-Adresse herzustellen, die nicht zum Herstellen einer Verbindung mit dem Server autorisiert ist. Die Serverfirewall enthält keine IP-Adressregel, die einem Client die Kommunikation mit der Datenbank über eine bestimmte IP-Adresse erlaubt.

Fehlerbehebung: Geben Sie als IP-Regel die IP-Adresse des Clients ein. Führen Sie diesen Schritt im Bereich Firewall des Azure-Portals aus.

Verwandte Artikel

• Azure-VNET-Dienstendpunkte
• Firewallregeln auf Server- und Datenbankebene

Nächste Schritte

• Verwenden von PowerShell zum Erstellen eines VNET-Dienstendpunkts und einer VNET-Regel für SQL-Datenbank
• VNET-Regeln: Vorgänge mit REST-APIs