SQL Server-Portleitfaden: Datenbankzugriff auf Port 1433

Ein SQL-Client stellt eine Verbindung zum Server-Listener her, handelt Protokolleinstellungen aus, authentifiziert sich mit SQL-Authentifizierung, Windows-Authentifizierung, Entra-ID oder einer anderen unterstützten Methode und sendet dann Abfragen, Transaktionen und Metadatenanforderungen.

Der Port bestätigt lediglich, dass der Listener erreichbar ist. Der tatsächliche Datenbankzugriff hängt auch vom Anmeldestatus, Datenbankberechtigungen, Verschlüsselungseinstellungen, Instanzkonfiguration, Verbindungszeichenfolgen, DNS und Firewallregeln auf mehreren Ebenen ab.

Eine Standard-SQL Server-Instanz lauscht normalerweise auf TCP 1433. Benannte Instanzen können dynamische Ports verwenden, es sei denn, Sie konfigurieren einen statischen Port. Der SQL Server-Browser kann Clients dabei helfen, benannte Instanzen zu erkennen, aber viele Produktionsumgebungen bevorzugen statische Ports für klarere Firewall-Richtlinien.

Wenn Ihre Verbindungszeichenfolge die Server-Port-Syntax verwendet, überprüfen Sie den genauen Port. Wenn ein Instanzname verwendet wird, überprüfen Sie den SQL Server-Konfigurationsmanager, das Fehlerprotokoll oder die Servereinstellungen, um festzustellen, an welchem ​​Port die Instanz tatsächlich lauscht.

Open SQL-Zugriff nur von Anwendungsservern, Administrator-Workstations, Migrationstools, Berichtsdiensten oder vertrauenswürdigen Netzwerken, die Datenbankkonnektivität benötigen. Der öffentliche Zugang sollte vermieden werden, es sei denn, es besteht eine ganz bestimmte verwaltete und überwachte Anforderung.

Bevorzugen Sie für Cloud-Datenbanken private Endpunkte, VPC- oder VNet-Peering, VPN, Bastionspfade, Dienstnetzwerke oder anbietereigene Firewall-Zulassungslisten, anstatt zuzulassen, dass das gesamte Internet 1433 erreicht.

Bevor Sie TCP 1433 zulassen, vergewissern Sie sich, dass die Instanz die erwartete Schnittstelle und den erwarteten Port überwacht, die Verschlüsselungsrichtlinie bekannt ist, die Anmeldungen auf einen Gültigkeitsbereich beschränkt sind, Datenbankrollen mit den geringsten Rechten vorhanden sind und Sicherungen zuverlässig sind.

Ein Portprüfer kann die Netzwerkerreichbarkeit bestätigen, aber nicht beweisen, dass die Datenbank sicher ist. Testen Sie die echte Verbindungszeichenfolge mit sqlcmd, SQL Server Management Studio, Azure Data Studio, Anwendungszustandsprüfungen und Serverprotokollen.

Aktivieren Sie unter Windows Server TCP/IP für die SQL Server-Instanz, legen Sie bei Bedarf einen statischen Port fest, starten Sie den Dienst neu und lassen Sie eingehenden TCP 1433 in der Windows Defender-Firewall nur von vertrauenswürdigen Quellen zu.

Bestätigen Sie bei Linux SQL Server-Bereitstellungen, dass mssql-server den vorgesehenen Port überwacht, und lassen Sie diesen Port in den Sicherheitsgruppen firewalld, ufw, nftables, iptables oder Cloud zu. Halten Sie den Verwaltungszugriff vom Anwendungszugriff getrennt.

Verwenden Sie für verwaltete SQL-Dienste Anbieter-Firewallregeln, private Endpunkte und Identitätskontrollen. Gehen Sie nicht davon aus, dass das Öffnen eines Cloud-Datenbank-Endpunkts gleichbedeutend mit der Offenlegung eines einzelnen VM-Ports ist. Auch die Zugriffsrichtlinie auf Anbieterebene ist wichtig.

Beginnen Sie mit einer externen oder internen Portprüfung anhand des Datenbank-Hostnamens und TCP 1433, je nachdem, wo der Client ausgeführt wird. Wenn der Port geöffnet ist, testen Sie die tatsächliche Verbindung mit sqlcmd, SSMS, Azure Data Studio oder der Anwendungsverbindungszeichenfolge.

Wenn TLS erforderlich ist, überprüfen Sie die Zertifikatsvertrauens- und Verschlüsselungseinstellungen vom Client. Überprüfen Sie dann die Serverprotokolle auf Anmeldefehler, Firewall-Ablehnungen, Berechtigungsfehler auf Datenbankebene und Verbindungs-Timeout-Muster.

Wenn Port 1433 geschlossen ist, wird SQL Server möglicherweise nicht ausgeführt, TCP/IP ist möglicherweise deaktiviert, die Instanz verwendet möglicherweise einen anderen Port oder ein Host, eine Cloud oder eine Netzwerk-Firewall blockiert möglicherweise den Pfad. Benannte Instanzen schlagen häufig fehl, weil der tatsächliche dynamische Port von dem abweicht, was der Client erwartet.

Wenn der Port geöffnet ist, die Anmeldung jedoch fehlschlägt, überprüfen Sie den Authentifizierungsmodus, das Benutzernamenformat, den Kennwortstatus, deaktivierte Anmeldungen, die Datenbankbenutzerzuordnung, Berechtigungen, Verschlüsselungsanforderungen und Serverfehlerprotokolle. Wenn Abfragen eine Verbindung herstellen, aber langsam sind, prüfen Sie Sperren, Indizes, CPU, Speicher, E/A und Abfragepläne.

Halten Sie SQL Server nach Möglichkeit vom öffentlichen Internet fern. Beschränken Sie Quellen, verlangen Sie Verschlüsselung, patchen Sie die Engine, deaktivieren Sie nicht verwendete Anmeldungen, verwenden Sie Rollen mit den geringsten Rechten, rotieren Sie Anmeldeinformationen und überwachen Sie fehlgeschlagene Anmeldungen und privilegierte Aktionen.

Sichern Sie Datenbanken, testen Sie Wiederherstellungen, überwachen Sie langsame Abfragen und den Replikationszustand und trennen Sie den Verwaltungszugriff vom Anwendungszugriff. Ein Datenbankport ist ein direkter Pfad zu sensiblen Daten, daher muss die Erreichbarkeit des Netzwerks mit starken Identitäts- und Datenkontrollen gepaart sein.