Uwaga
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
W tym artykule opisano szczegółowe informacje o protokole Transport Layer Security (TLS) i certyfikatach cyfrowych.
Bezpieczeństwo warstwy transportowej (TLS)
Protokoły TLS i SSL znajdują się między warstwą protokołu aplikacji a warstwą TCP/IP, gdzie mogą zabezpieczać i wysyłać dane aplikacji do warstwy transportu. Protokoły TLS/SSL używają algorytmów z zestawu szyfrowania do tworzenia kluczy i szyfrowania informacji. Klient i serwer negocjują wersję protokołu i zestaw szyfrowania, który ma być używany do szyfrowania w fazie początkowego połączenia (przed logowaniem) podczas ustanawiania połączenia. Najwyższa obsługiwana wersja protokołu TLS jest zawsze preferowana w uzgadnianiu protokołu TLS. Aby sprawdzić wersje protokołów TLS obsługiwane przez różne wersje systemów operacyjnych Windows, zobacz Protokoły w protokole TLS/SSL (SSP Schannel). W przypadku protokołu SSL i wcześniejszych wersji protokołu TLS zgłoszono kilka znanych luk w zabezpieczeniach. Zalecamy uaktualnienie do protokołu TLS 1.2 w celu zapewnienia bezpiecznej komunikacji.
Program SQL Server może używać protokołu TLS do szyfrowania danych przesyłanych przez sieć między wystąpieniem programu SQL Server i aplikacją kliencką. Protokół TLS używa certyfikatu do implementowania szyfrowania.
Włączenie szyfrowania TLS zwiększa bezpieczeństwo danych przesyłanych między sieciami między wystąpieniami programu SQL Server i aplikacji. Jeśli jednak cały ruch między programem SQL Server a aplikacją kliencką jest szyfrowany przy użyciu protokołu TLS, wymagane jest następujące dodatkowe przetwarzanie:
- Dodatkowa przepustowość sieci jest wymagana w czasie połączenia.
- Pakiety wysyłane z aplikacji do wystąpienia programu SQL Server muszą być szyfrowane przez stos TLS klienta i odszyfrowywane przez stos TLS serwera.
- Pakiety wysyłane z wystąpienia programu SQL Server do aplikacji muszą być szyfrowane przez stos TLS serwera i odszyfrowywane przez stos TLS klienta.
Ważne
Począwszy od programu SQL Server 2016 (13.x), protokół Secure Sockets Layer (SSL) został przerwany. Zamiast tego należy użyć protokołu TLS (zaleca się użycie protokołu TLS 1.2). Aby uzyskać więcej informacji, zobacz artykuł KB3135244 — obsługa protokołu TLS 1.2 w programie Microsoft SQL Server. Program SQL Server 2022 wprowadza obsługę protokołu TLS 1.3. Aby uzyskać więcej informacji, zobacz Obsługa protokołu TLS 1.3. Jeśli między klientem a serwerem nie istnieją żadne zgodne protokoły, można napotkać błąd Istniejące połączenie zostało zamknięte przez zdalnego hosta.
Omówienie certyfikatu cyfrowego
Certyfikaty cyfrowe to pliki elektroniczne, które działają jak hasło online w celu zweryfikowania tożsamości użytkownika lub komputera. Są one używane do tworzenia zaszyfrowanego kanału używanego do komunikacji klienta. Certyfikat jest oświadczeniem cyfrowym wydanym przez urząd certyfikacji ,który ręczy tożsamość posiadacza certyfikatu i umożliwia stronom bezpieczne komunikowanie się przy użyciu szyfrowania.
Certyfikaty cyfrowe zapewniają następujące usługi:
- Szyfrowanie: pomagają chronić dane wymieniane przed kradzieżą lub manipulowaniem.
- Uwierzytelnianie: sprawdzają, czy ich posiadacze (osoby, witryny internetowe, a nawet urządzenia sieciowe, takie jak routery) są naprawdę tym, kto lub co twierdzi. Zazwyczaj uwierzytelnianie jest jednokierunkowe, gdzie źródło weryfikuje tożsamość obiektu docelowego, ale możliwe jest również wzajemne uwierzytelnianie TLS.
Certyfikat zawiera klucz publiczny i dołącza ten klucz publiczny do tożsamości osoby, komputera lub usługi, która zawiera odpowiedni klucz prywatny. Klucze publiczne i prywatne są używane przez klienta i serwer do szyfrowania danych przed ich przesłaniem. W przypadku użytkowników systemu Windows, komputerów i usług zaufanie do urzędu certyfikacji jest ustanawiane, gdy certyfikat główny jest zdefiniowany w zaufanym magazynie certyfikatów głównych, a certyfikat zawiera prawidłową ścieżkę certyfikacji. Certyfikat jest uznawany za prawidłowy, jeśli nie został odwołany (nie znajduje się na liście odwołania certyfikatów urzędu certyfikacji lub listy CRL) lub wygasł.
Trzy podstawowe typy certyfikatów cyfrowych zostały opisane w poniższej tabeli:
Typ | Opis | Zalety | Niekorzyści |
---|---|---|---|
Certyfikat z podpisem własnym | Certyfikat jest podpisany przez aplikację, która go utworzyła, lub jest tworzony przy użyciu polecenia New-SelfSignedCertificate. | Koszt (bezpłatny) | — Certyfikat nie jest automatycznie zaufany przez komputery użytkowników i urządzenia mobilne. Certyfikat należy ręcznie dodać do magazynu zaufanych certyfikatów głównych na wszystkich komputerach klienckich i urządzeniach, ale nie wszystkie urządzenia przenośne zezwalają na zmiany w zaufanym magazynie certyfikatów głównych. — Nie wszystkie usługi działają z certyfikatami z podpisem własnym. - Trudno ustanowić infrastrukturę do zarządzania cyklem życia certyfikatów. Na przykład nie można odwołać certyfikatów z podpisem własnym. |
Certyfikat wystawiony przez wewnętrzny urząd certyfikacji | Certyfikat jest wystawiany przez infrastrukturę kluczy publicznych (PKI) w organizacji. Przykładem są usługi certyfikatów Active Directory (AD CS). Aby uzyskać więcej informacji, zobacz Omówienie usług certyfikatów Active Directory. | — Umożliwia organizacjom wystawianie własnych certyfikatów. - Tańsze niż certyfikaty z komercyjnego urzędu certyfikacji. |
— Większa złożoność wdrażania i obsługi infrastruktury kluczy publicznych. — Certyfikat nie jest automatycznie zaufany przez komputery klienckie i urządzenia przenośne. Certyfikat należy ręcznie dodać do magazynu zaufanych certyfikatów głównych na wszystkich komputerach klienckich i urządzeniach, ale nie wszystkie urządzenia przenośne zezwalają na zmiany w zaufanym magazynie certyfikatów głównych. |
Certyfikat wystawiony przez komercyjny urząd certyfikacji | Certyfikat kupuje się od zaufanego komercyjnego urzędu certyfikacji. | Wdrażanie certyfikatów jest uproszczone, ponieważ wszyscy klienci, urządzenia i serwery automatycznie ufają certyfikatom. | Koszt Należy zaplanować z wyprzedzeniem, aby zminimalizować liczbę wymaganych certyfikatów. |
Aby udowodnić, że właściciel certyfikatu jest tym, za kogo się podaje, certyfikat musi dokładnie zidentyfikować właściciela certyfikatu dla innych klientów, urządzeń lub serwerów. Trzy podstawowe metody, które należy wykonać, zostały opisane w poniższej tabeli:
Metoda | Opis | Zalety | Niekorzyści |
---|---|---|---|
Dopasowanie podmiotu certyfikatu | Pole Podmiot certyfikatu zawiera nazwę pospolitą (CN) hosta. Na przykład certyfikat wystawiony dla www.contoso.com może być używany na stronie internetowej https://www.contoso.com . |
— Zgodne ze wszystkimi klientami, urządzeniami i usługami. - Przedziałyzacja. Odwołanie certyfikatu dla hosta nie ma wpływu na inne hosty. |
— Wymagana liczba certyfikatów. Można użyć certyfikatu tylko dla określonego hosta. Na przykład nie można użyć certyfikatu www.contoso.com dla ftp.contoso.com programu , nawet jeśli usługi są zainstalowane na tym samym serwerze.-Złożoność. Na serwerze sieci Web każdy certyfikat wymaga własnego powiązania adresu IP. |
Dopasowanie alternatywnej nazwy podmiotu certyfikatu (SAN) | Oprócz pola Podmiot pole Alternatywna nazwa podmiotu certyfikatu zawiera listę wielu nazw hostów. Na przykład:www.contoso.com ftp.contoso.com ftp.eu.fabrikam.net |
- Wygoda. Możesz użyć tego samego certyfikatu dla wielu hostów w wielu oddzielnych domenach. — Większość klientów, urządzeń i usług obsługuje certyfikaty SAN. - Inspekcja i zabezpieczenia. Wiesz dokładnie, które hosty mogą używać certyfikatu SAN. |
- Wymagane jest więcej planowania. Podczas tworzenia certyfikatu należy podać listę hostów. - Brak podziału na sekcje. Nie można selektywnie odwołać certyfikatów dla niektórych określonych hostów bez wpływu na wszystkie hosty w certyfikacie. |
Dopasowanie certyfikatu wildcard | Pole Podmiot certyfikatu zawiera nazwę pospolitą jako symbol wieloznaczny (*) oraz pojedynczą domenę lub poddomenę. Na przykład: *.contoso.com lub *.eu.contoso.com . Certyfikat typu *.contoso.com wildcard można użyć do:www.contoso.com ftp.contoso.com mail.contoso.com |
Elastyczność Nie musisz podawać listy hostów podczas żądania certyfikatu i można użyć certyfikatu na dowolnej liczbie hostów, które mogą być potrzebne w przyszłości. | — Nie można używać certyfikatów wieloznacznych z innymi domenami najwyższego poziomu (TLD). Na przykład nie można użyć certyfikatu wieloznacznika *.contoso.com dla hostów *.contoso.net .— Można używać tylko certyfikatów z symbolem wieloznacznym dla nazw hostów na poziomie symbolu wieloznacznego. Na przykład nie można użyć certyfikatu *.contoso.com dla programu www.eu.contoso.com . Lub nie można użyć certyfikatu *.eu.contoso.com dla programu www.uk.eu.contoso.com .— Starsi klienci, urządzenia, aplikacje lub usługi mogą nie obsługiwać certyfikatów wieloznacznych. — Wildcards nie są dostępne w przypadku certyfikatów rozszerzonej weryfikacji (EV). - Wymagane są staranne inspekcje i kontrola. Jeśli certyfikat z symbolami wieloznacznymi zostanie naruszony, wpłynie to na każdego hosta w określonej domenie. |