Interfejs dostawcy wsparcia bezpieczeństwa - Security Support Provider Interface
Interfejs dostawcy obsługi zabezpieczeń ( SSPI ) to składnik interfejsu API systemu Windows, który wykonuje operacje związane z zabezpieczeniami, takie jak uwierzytelnianie .
SSPI działa jako wspólny interfejs dla kilku dostawców obsługi zabezpieczeń (SSP): Dostawca obsługi zabezpieczeń to biblioteka dołączana dynamicznie (DLL), która udostępnia aplikacjom jeden lub więcej pakietów zabezpieczeń.
Dostawcy
Następujące SSP są zawarte w systemie Windows:
- NTLMSSP (msv1_0.dll) - wprowadzone w systemie Windows NT 3.51 . Zapewnia uwierzytelnianie typu wezwanie / odpowiedź NTLM dla domen systemu Windows starszych niż Windows 2000 i dla systemów, które nie są częścią domeny.
- Kerberos (kerberos.dll) - wprowadzony w systemie Windows 2000 i zaktualizowany w systemie Windows Vista w celu obsługi AES . Wykonuje uwierzytelnianie dla domen Windows w systemie Windows 2000 i nowszych.
- NegotiateSSP (secur32.dll) - wprowadzona w systemie Windows 2000. Zapewnia możliwość pojedynczego logowania , czasami nazywaną zintegrowanym uwierzytelnianiem systemu Windows (szczególnie w kontekście usług IIS). W wersjach starszych niż Windows 7 próbuje korzystać z protokołu Kerberos przed powrotem do NTLM. W systemie Windows 7 i nowszych wprowadzono NEGOExts, który negocjuje użycie zainstalowanych niestandardowych dostawców SSP, które są obsługiwane na kliencie i serwerze w celu uwierzytelnienia.
- Bezpieczny kanał (schannel.dll) - wprowadzony w systemie Windows 2000 i zaktualizowany w systemie Windows Vista w celu obsługi silniejszego szyfrowania AES i ECC Ten dostawca używa rekordów SSL / TLS do szyfrowania ładunków danych.
- TLS / SSL - publiczny klucz kryptograficzny SSP, który zapewnia szyfrowanie i bezpieczną komunikację w celu uwierzytelniania klientów i serwerów przez Internet. Zaktualizowano w systemie Windows 7, aby obsługiwał TLS 1.2.
- Digest SSP (wdigest.dll) - wprowadzony w systemie Windows XP . Zapewnia uwierzytelnianie HTTP i SASL oparte na wyzwaniu / odpowiedzi między systemami Windows i innymi niż Windows, w których protokół Kerberos nie jest dostępny.
- CredSSP (credssp.dll) - wprowadzony w systemie Windows Vista i dostępny w systemie Windows XP z dodatkiem SP3. Zapewnia logowanie jednokrotne i uwierzytelnianie na poziomie sieci dla usług pulpitu zdalnego .
- Rozproszone uwierzytelnianie haseł (DPA, msapsspc.dll) - wprowadzone w systemie Windows 2000. Zapewnia uwierzytelnianie internetowe przy użyciu certyfikatów cyfrowych .
- Kryptografia klucza publicznego między użytkownikami (PKU2U, pku2u.dll) - wprowadzona w systemie Windows 7 . Zapewnia uwierzytelnianie peer-to-peer przy użyciu certyfikatów cyfrowych między systemami, które nie są częścią domeny.
Porównanie
SSPI to zastrzeżony wariant Generic Security Services Application Program Interface (GSSAPI) z rozszerzeniami i typami danych specyficznymi dla systemu Windows. Jest dostarczany z Windows NT 3.51 i Windows 95 z NTLMSSP . W systemie Windows 2000 dodano implementację protokołu Kerberos 5, wykorzystującą formaty tokenów zgodne z oficjalnym standardem protokołu RFC 1964 (mechanizm Kerberos 5 GSSAPI) i zapewniającą współdziałanie na poziomie przewodowym z implementacjami Kerberos 5 od innych dostawców.
Tokeny generowane i akceptowane przez SSPI są w większości zgodne z GSS-API, więc klient SSPI w systemie Windows może być w stanie uwierzytelnić się na serwerze GSS-API w systemie Unix, w zależności od konkretnych okoliczności.
Jedną ze znaczących wad SSPI jest brak powiązań kanałów , co uniemożliwia współdziałanie niektórych GSSAPI.
Inną fundamentalną różnicą między GSSAPI zdefiniowanym przez IETF a SSPI firmy Microsoft jest pojęcie „ podszywania się ”. W tym modelu serwer może działać z pełnymi uprawnieniami uwierzytelnionego klienta, dzięki czemu system operacyjny przeprowadza wszystkie kontrole dostępu , np. Podczas otwierania nowych plików. To, czy są to mniej uprawnień, czy więcej uprawnień niż pierwotne konto usługi, zależy całkowicie od klienta. W tradycyjnym modelu (GSSAPI), gdy serwer działa w ramach konta usługi, nie może podnieść swoich uprawnień i musi wykonywać kontrolę dostępu w sposób specyficzny dla klienta i aplikacji. Oczywiste negatywne konsekwencje koncepcji podszywania się dla bezpieczeństwa są chronione w systemie Windows Vista poprzez ograniczenie personifikacji do wybranych kont usług. Personifikację można zaimplementować w modelu Unix / Linux przy użyciu seteuid lub powiązanych wywołań systemowych. Chociaż oznacza to, że nieuprzywilejowany proces nie może podnieść swoich uprawnień, oznacza to również, że aby skorzystać z personifikacji, proces musi działać w kontekście konta użytkownika root .