Udostępnij za pośrednictwem


Specjalne przypadki szyfrowania połączeń z programem SQL Server

Komputer kliencki musi ufać certyfikatowi serwera, aby klient mógł zażądać szyfrowania Tls (Transport Layer Security), a certyfikat musi już istnieć na serwerze. Najbardziej typowym scenariuszem szyfrowania programu SQL Server są środowiska, które:

  • Wymusza szyfrowanie dla wszystkich przychodzących połączeń klientów z programem SQL Server.
  • Użyj certyfikatów z publicznego komercyjnego urzędu certyfikacji, któremu ufa już system Windows. Odpowiedni certyfikat główny urzędu certyfikacji jest instalowany w magazynie certyfikatów zaufanych głównych urzędów certyfikacji na wszystkich komputerach w sieci.

W tym scenariuszu nie trzeba wykonywać dodatkowych kroków dotyczących pomyślnego szyfrowania po skonfigurowaniu programu SQL Server pod kątem szyfrowania zgodnie z procedurą opisaną w Konfigurowanie aparatu bazy danych programu SQL Server na potrzeby szyfrowania połączeń. Ten artykuł zawiera procedury szyfrowania połączeń z programem SQL Server w przypadku mniej typowych scenariuszy, które nie zostały omówione w Konfigurowanie aparatu bazy danych programu SQL Server na potrzeby szyfrowania połączeń.

Notatka

Aby uzyskać pełną listę uczestników programu Microsoft Trusted Root Program, zobacz Lista uczestników — Microsoft Trusted Root Program.

Używanie certyfikatu wystawionego przez publiczny komercyjny urząd certyfikacji i tylko niektórzy klienci potrzebują zaszyfrowanych połączeń

  1. Skonfiguruj certyfikat w programie SQL Server zgodnie z procedurą opisaną w Konfigurowanie programu SQL Server do używania certyfikatów.

  2. Określ słowo kluczowe szyfrowania we właściwościach połączenia, aby Tak lub True. Jeśli na przykład używasz sterownika Microsoft ODBC dla programu SQL Server, parametry połączenia powinny określać Encrypt=yes;.

Używanie certyfikatu wystawionego przez wewnętrzny urząd certyfikacji lub utworzonego przy użyciu New-SelfSignedCertificate lub makecert

Scenariusz 1. Chcesz zaszyfrować wszystkie połączenia z programem SQL Server

Po wykonaniu obu procedur opisanych w Krok 1: Konfigurowanie programu SQL Server pod kątem używania certyfikatów i Krok 2: Konfigurowanie ustawień szyfrowania w programie SQL Server w artykule Konfigurowanie aparatu bazy danych programu SQL Server pod kątem szyfrowania połączeń, użyj jednej z następujących opcji, aby skonfigurować aplikację kliencą na potrzeby szyfrowania.

Opcja 1: Konfigurowanie aplikacji klienckich w celu certyfikatu serwera zaufania. To ustawienie powoduje, że klient pomija krok, który weryfikuje certyfikat serwera i kontynuuje proces szyfrowania. Jeśli na przykład używasz programu SQL Server Management Studio (SSMS) 20 lub nowszych wersji, możesz wybrać certyfikat serwera zaufania na stronie logowania (lub na stronie Opcje we wcześniejszych wersjach).

opcja 2: Na każdym kliencie dodaj urząd wystawiający certyfikat do magazynu zaufanych urzędów głównych, wykonując następujące czynności:

  1. Wyeksportuj certyfikat z komputera z uruchomionym programem SQL Server, korzystając z procedury opisanej w Eksportowanie certyfikatu serwera.

  2. Zaimportuj certyfikat przy użyciu procedury opisanej w Eksportowanie i importowanie certyfikatów.

Scenariusz 2. Tylko niektórzy klienci potrzebują szyfrowanych połączeń

Po skonfigurowaniu certyfikatu do użycia z programem SQL Server zgodnie z opisem w Krok 1 w Konfigurowanie aparatu bazy danych programu SQL Server na potrzeby szyfrowania połączeń, użyj jednej z następujących opcji, aby skonfigurować aplikację kliencką na potrzeby szyfrowania:

opcja 1: skonfiguruj aplikacje klienckie, aby ufały certyfikatowi serwera i określ słowo kluczowe szyfrowania we właściwościach połączenia, aby Tak lub true. Jeśli na przykład używasz sterownika Microsoft ODBC dla programu SQL Server, parametry połączenia powinny określać Encrypt=Yes;TrustServerCertificate=Yes;.

Aby uzyskać więcej informacji na temat certyfikatów serwera i szyfrowania, zobacz Using TrustServerCertificate.

opcja 2: na każdym kliencie dodaj urząd wystawiający certyfikat do magazynu zaufanych urzędów głównych i określ parametry szyfrowania na Tak w ciągu połączenia:

  1. Wyeksportuj certyfikat z komputera z uruchomionym programem SQL Server, korzystając z procedury opisanej w Eksportowanie certyfikatu z komputera z uruchomionym programem SQL Server.

  2. Zaimportuj certyfikat.

  3. Określ słowo kluczowe szyfrowania we właściwościach połączenia, aby Tak lub True. Jeśli na przykład używasz sterownika Microsoft OLEDB dla programu SQL Server, parametry połączenia powinny określać Użyj szyfrowania dla danych = True;

Używanie certyfikatu z podpisem własnym automatycznie utworzonego przez program SQL Server

Scenariusz 1. Chcesz zaszyfrować wszystkie połączenia przychodzące z programem SQL Server

  1. Włącz szyfrowanie w programie SQL Server przy użyciu procedury Krok 2: Konfigurowanie ustawień szyfrowania w programie SQL Server udokumentowanych w Konfigurowanie aparatu bazy danych programu SQL Server na potrzeby szyfrowania połączeń.

  2. Skonfiguruj aplikacje klienckie, aby ufały certyfikatowi serwera. Ufanie certyfikatowi serwera powoduje, że klient pominąć krok weryfikujący certyfikat serwera i kontynuować proces szyfrowania. Jeśli na przykład używasz programu SQL Server Management Studio (SSMS) 20 lub nowszych wersji, możesz wybrać certyfikat serwera zaufania na stronie logowania (lub na stronie Opcje we wcześniejszych wersjach).

Scenariusz 2. Tylko niektórzy klienci potrzebują szyfrowanych połączeń

Skonfiguruj aplikacje klienckie, aby ufały certyfikatowi serwera i określ słowo kluczowe szyfrowania we właściwościach połączenia, aby Tak lub true. Jeśli na przykład używasz sterownika Microsoft ODBC dla programu SQL Server, parametry połączenia powinny określać Encrypt=Yes;TrustServerCertificate=Yes;.

W tym scenariuszu w programie SQL Server nie jest wymagana żadna dodatkowa konfiguracja.

Ostrzeżenie

Połączenia TLS/SSL szyfrowane przy użyciu certyfikatu z podpisem własnym nie zapewniają silnego bezpieczeństwa, ponieważ długość klucza w certyfikatach z podpisem własnym jest krótsza niż klucz w certyfikatach generowanych przez urząd certyfikacji. Są podatne na ataki typu man-in-the-middle. Nie należy polegać na protokole TLS/SSL przy użyciu certyfikatów z podpisem własnym w środowisku produkcyjnym lub na serwerach połączonych z Internetem.