Udostępnij za pośrednictwem

Zabezpieczanie usług

  • Artykuł

Zabezpieczenia usługi Windows Communication Foundation (WCF) składają się z dwóch podstawowych wymagań: zabezpieczeń transferu i autoryzacji. (Trzecie wymaganie, inspekcja zdarzeń zabezpieczeń, jest opisane w Inspekcja. Krótko mówiąc, zabezpieczenia transferu obejmują uwierzytelnianie (weryfikowanie tożsamości zarówno usługi, jak i klienta), poufność (szyfrowanie komunikatów) i integralność (podpisywanie cyfrowe w celu wykrywania manipulacji). Autoryzacja to kontrola dostępu do zasobów, na przykład zezwalanie tylko uprzywilejowanym użytkownikom na odczytywanie pliku. Dzięki funkcjom programu WCF dwa podstawowe wymagania są łatwo implementowane.

Z wyjątkiem BasicHttpBinding klasy (lub podstawowego <elementuHttpBinding> w konfiguracji) zabezpieczenia transferu są domyślnie włączone dla wszystkich wstępnie zdefiniowanych powiązań. Tematy w tej sekcji obejmują dwa podstawowe scenariusze: implementowanie zabezpieczeń transferu i autoryzacji w usłudze intranetowej hostowanej w usługach Internet Information Services (IIS) oraz implementowanie zabezpieczeń i autoryzacji transferu w usłudze hostowanej w usługach IIS.

Podstawy zabezpieczeń

Zabezpieczenia opierają się na poświadczeniach. Poświadczenie potwierdza, że jednostka jest tym, kim jest. (Jednostka może być osobą, procesem oprogramowania, firmą lub cokolwiek innego, co może być autoryzowane). Na przykład klient usługi zgłasza oświadczenieo tożsamości, a poświadczenie potwierdza, że oświadczenie w jakiś sposób. W typowym scenariuszu następuje wymiana poświadczeń. Najpierw usługa zgłasza roszczenie o jego tożsamość i potwierdza ją klientowi przy użyciu poświadczeń. Z drugiej strony klient zgłasza oświadczenie o tożsamości i przedstawia poświadczenie do usługi. Jeśli obie strony ufają poświadczeń drugiej strony, można ustanowić bezpieczny kontekst, w którym wszystkie wiadomości są wymieniane w poufności, a wszystkie wiadomości są podpisane w celu ochrony ich integralności. Po ustanowieniu tożsamości klienta usługa może następnie dopasować oświadczenia w poświadczeniu do roli lub członkostwa w grupie. W obu przypadkach przy użyciu roli lub grupy, do której należy klient, usługa autoryzuje klienta do wykonywania ograniczonego zestawu operacji na podstawie uprawnień roli lub grupy.

mechanizmy Zabezpieczenia Windows

Jeśli klient i komputer usługi znajdują się zarówno w domenie systemu Windows, która wymaga zalogowania się do sieci, poświadczenia są dostarczane przez infrastrukturę systemu Windows. W takim przypadku poświadczenia są ustanawiane, gdy użytkownik komputera loguje się do sieci. Każdy użytkownik i każdy komputer w sieci muszą zostać zweryfikowane jako należące do zaufanego zestawu użytkowników i komputerów. W systemie Windows każdy taki użytkownik i komputer jest również znany jako podmiot zabezpieczeń.

W domenie systemu Windows wspieranej przez kontroler Kerberos kontroler Kerberos używa schematu opartego na udzielaniu biletów do każdego podmiotu zabezpieczeń. Bilety, które przyznaje kontroler, są zaufane przez innych grantatorów biletów w systemie. Za każdym razem, gdy jednostka próbuje wykonać jakąś operację lub uzyskać dostęp do zasobu (takiego jak plik lub katalog na maszynie), bilet jest badany pod kątem jego ważności i, jeśli przejdzie, podmiot zabezpieczeń otrzymuje inny bilet dla operacji. Ta metoda udzielania biletów jest wydajniejsza niż alternatywa próby zweryfikowania podmiotu zabezpieczeń dla każdej operacji.

Starszy, mniej bezpieczny mechanizm używany w domenach systemu Windows to NT LAN Manager (NTLM). W przypadkach, gdy nie można użyć protokołu Kerberos (zazwyczaj poza domeną systemu Windows, na przykład w grupie roboczej), protokół NTLM może być używany jako alternatywa. Protokół NTLM jest również dostępny jako opcja zabezpieczeń dla usług IIS.

W systemie Windows autoryzacja działa przez przypisanie każdego komputera i użytkownika do zestawu ról i grup. Na przykład każdy komputer z systemem Windows musi być skonfigurowany i kontrolowany przez osobę (lub grupę osób) w roli administratora. Inną rolą jest to, że użytkownik ma znacznie bardziej ograniczony zestaw uprawnień. Oprócz roli użytkownicy są przypisywani do grup. Grupa umożliwia wielu użytkownikom wykonywanie tej samej roli. W związku z tym maszyna z systemem Windows jest administrowana przez przypisanie użytkowników do grup. Na przykład do grupy użytkowników komputera można przypisać kilka użytkowników, a do grupy administratorów można przypisać znacznie bardziej ograniczony zestaw użytkowników. Na komputerze lokalnym administrator może również tworzyć nowe grupy i przypisywać innych użytkowników (a nawet inne grupy) do grupy.

Na komputerze z systemem Windows każdy folder w katalogu może być chroniony. Oznacza to, że można wybrać folder i kontrolować, kto może uzyskać dostęp do plików i czy może skopiować plik, lub (w najbardziej uprzywilejowanym przypadku) zmienić plik, usunąć plik lub dodać pliki do folderu. Jest to nazywane kontrolą dostępu i mechanizmem, który jest znany jako lista kontroli dostępu (ACL). Podczas tworzenia listy ACL można przypisać uprawnienia dostępu do dowolnej grupy lub grup, a także poszczególnych członków domeny.

Infrastruktura WCF została zaprojektowana tak, aby korzystała z tych mechanizmów zabezpieczeń systemu Windows. W związku z tym, jeśli tworzysz usługę, która jest wdrażana w intranecie i której klienci są ograniczeni do członków domeny systemu Windows, zabezpieczenia są łatwo implementowane. Tylko prawidłowi użytkownicy mogą zalogować się do domeny. Po zalogowaniu użytkowników kontroler Kerberos umożliwia każdemu użytkownikowi ustanawianie bezpiecznych kontekstów z dowolnym innym komputerem lub aplikacją. Na komputerze lokalnym można łatwo tworzyć grupy, a podczas ochrony określonych folderów te grupy mogą służyć do przypisywania uprawnień dostępu na komputerze.

Implementowanie Zabezpieczenia Windows w usługach intranetowych

Aby zabezpieczyć aplikację działającą wyłącznie w domenie systemu Windows, możesz użyć domyślnych WSHttpBinding ustawień zabezpieczeń powiązania lub NetTcpBinding . Domyślnie każda osoba w tej samej domenie systemu Windows może uzyskiwać dostęp do usług WCF. Ponieważ ci użytkownicy zalogowali się do sieci, są zaufani. Komunikaty między usługą a klientem są szyfrowane pod kątem poufności i podpisane pod kątem integralności. Aby uzyskać więcej informacji na temat tworzenia usługi korzystającej z zabezpieczeń systemu Windows, zobacz How to: Secure a Service with Windows Credentials (Jak zabezpieczyć usługę przy użyciu poświadczeń systemu Windows).

Autoryzacja przy użyciu klasy PrincipalPermissionAttribute

Jeśli musisz ograniczyć dostęp do zasobów na komputerze, najprostszym sposobem jest użycie PrincipalPermissionAttribute klasy . Ten atrybut umożliwia ograniczenie wywołania operacji usługi przez wymaganie, aby użytkownik był w określonej grupie lub roli systemu Windows lub być określonym użytkownikiem. Aby uzyskać więcej informacji, zobacz How to: Restrict Access with the PrincipalPermissionAttribute Class (Instrukcje: ograniczanie dostępu za pomocą klasy PrincipalPermissionAttribute).

Personifikacja

Personifikacja to inny mechanizm, którego można użyć do kontrolowania dostępu do zasobów. Domyślnie usługa hostowana przez usługi IIS będzie działać w ramach tożsamości konta ASPNET. Konto ASPNET może uzyskiwać dostęp tylko do zasobów, dla których ma uprawnienia. Można jednak ustawić listę ACL dla folderu, aby wykluczyć konto usługi ASPNET, ale zezwolić niektórym innym tożsamościom na dostęp do folderu. Następnie staje się pytaniem, jak zezwolić tym użytkownikom na dostęp do folderu, jeśli konto ASPNET nie może tego zrobić. Odpowiedź polega na użyciu personifikacji, gdzie usługa może używać poświadczeń klienta w celu uzyskania dostępu do określonego zasobu. Innym przykładem jest uzyskiwanie dostępu do bazy danych programu SQL Server, do której mają uprawnienia tylko niektórzy użytkownicy. Aby uzyskać więcej informacji na temat personifikacji, zobacz Instrukcje: personifikacja klienta w usłudze i delegowaniu i personifikacji.

Zabezpieczenia w Internecie

Zabezpieczenia w Internecie składają się z tych samych wymagań co zabezpieczenia w intranecie. Usługa musi przedstawić swoje poświadczenia, aby udowodnić swoją autentyczność, a klienci muszą potwierdzić swoją tożsamość w usłudze. Po sprawdzeniu tożsamości klienta usługa może kontrolować, ile dostępu musi mieć klient do zasobów. Jednak ze względu na heterogeniczny charakter Internetu przedstawione poświadczenia różnią się od tych używanych w domenie systemu Windows. Podczas gdy kontroler Kerberos obsługuje uwierzytelnianie użytkowników w domenie z biletami dla poświadczeń, w Internecie, usługach i klientach polega na jednym z kilku różnych sposobów prezentowania poświadczeń. Celem tego tematu jest jednak przedstawienie typowego podejścia, które umożliwia utworzenie usługi WCF dostępnej w Internecie.

Używanie usług IIS i ASP.NET

Wymagania dotyczące zabezpieczeń Internetu i mechanizmy rozwiązywania tych problemów nie są nowe. Usługi IIS to serwer sieci Web firmy Microsoft dla Internetu i ma wiele funkcji zabezpieczeń, które dotyczą tych problemów; ponadto ASP.NET zawiera funkcje zabezpieczeń, których mogą używać usługi WCF. Aby korzystać z tych funkcji zabezpieczeń, hostuj usługę WCF w usługach IIS.

Korzystanie z ASP.NET członkostwa i dostawców ról

ASP.NET zawiera dostawcę członkostwa i roli. Dostawca jest bazą danych par nazwy użytkownika/hasła do uwierzytelniania wywołujących, które umożliwiają również określenie uprawnień dostępu każdego obiektu wywołującego. Za pomocą programu WCF można łatwo użyć istniejącego członkostwa i dostawcy ról za pośrednictwem konfiguracji. Aby zapoznać się z przykładową aplikacją, która to pokazuje, zobacz przykład Członkostwo i dostawca ról.

Poświadczenia używane przez usługi IIS

W przeciwieństwie do domeny systemu Windows wspieranej przez kontroler Kerberos, Internet jest środowiskiem bez jednego kontrolera do zarządzania milionami użytkowników logując się w dowolnym momencie. Zamiast tego poświadczenia w Internecie najczęściej są w postaci certyfikatów X.509 (znanych również jako Secure Sockets Layer lub SSL). Te certyfikaty są zwykle wystawiane przez urząd certyfikacji, który może być firmą innej firmy, która ręczy za autentyczność certyfikatu i osobę, do której został wystawiony. Aby uwidocznić usługę w Internecie, należy również podać taki zaufany certyfikat, aby uwierzytelnić usługę.

W tym momencie pojawia się pytanie, jak uzyskać taki certyfikat? Jednym z podejść jest przejście do urzędu certyfikacji innej firmy, takiego jak Authenticode lub VeriSign, gdy wszystko będzie gotowe do wdrożenia usługi i zakup certyfikatu dla usługi. Jeśli jednak jesteś w fazie opracowywania za pomocą programu WCF i nie jesteś jeszcze gotowy do zatwierdzenia zakupu certyfikatu, narzędzia i techniki istnieją do tworzenia certyfikatów X.509, których można użyć do symulowania wdrożenia produkcyjnego. Aby uzyskać więcej informacji, zobacz Praca z certyfikatami.

Tryby zabezpieczeń

Zabezpieczenia programowania WCF wiążą się z kilkoma krytycznymi punktami decyzyjnymi. Jednym z najbardziej podstawowych jest wybór trybu zabezpieczeń. Dwa główne tryby zabezpieczeń to tryb transportu i tryb komunikatów.

Trzeci tryb, który łączy semantyka obu głównych trybów, to transport z trybem poświadczeń komunikatu.

Tryb zabezpieczeń określa sposób zabezpieczania komunikatów, a każdy wybór ma zalety i wady, jak wyjaśniono poniżej. Aby uzyskać więcej informacji na temat ustawiania trybu zabezpieczeń, zobacz Instrukcje: ustawianie trybu zabezpieczeń.

Tryb transportu

Istnieje kilka warstw między siecią a aplikacją. Jedną z nich jest warstwa transportu *,*, która zarządza transferem komunikatów między punktami końcowymi. W obecnym celu wymagane jest tylko zrozumienie, że w programie WCF jest używanych kilka protokołów transportowych, z których każdy może zabezpieczyć transfer komunikatów. (Aby uzyskać więcej informacji na temat transportu, zobacz Transporty).

Często używanym protokołem jest HTTP; innym jest TCP. Każdy z tych protokołów może zabezpieczyć transfer komunikatów za pomocą mechanizmu (lub mechanizmów) określonego w protokole. Na przykład protokół HTTP jest zabezpieczony przy użyciu protokołu SSL za pośrednictwem protokołu HTTP, często skracany jako "HTTPS". W związku z tym po wybraniu trybu transportu dla zabezpieczeń decydujesz się używać mechanizmu zgodnie z dyktowaniem protokołu. Jeśli na przykład wybierzesz klasę WSHttpBinding i ustawisz jej tryb zabezpieczeń na Transport, jako mechanizm zabezpieczeń wybierasz protokół SSL za pośrednictwem protokołu HTTP (HTTPS). Zaletą trybu transportu jest to, że jest bardziej wydajny niż tryb komunikatów, ponieważ zabezpieczenia są zintegrowane na stosunkowo niskim poziomie. W przypadku korzystania z trybu transportu mechanizm zabezpieczeń musi być wdrożony zgodnie ze specyfikacją transportu, a tym samym komunikaty mogą przepływać bezpiecznie tylko z punktu do punktu w transporcie.

Tryb komunikatu

Natomiast tryb komunikatów zapewnia bezpieczeństwo, uwzględniając dane zabezpieczeń w ramach każdego komunikatu. Przy użyciu nagłówków zabezpieczeń XML i SOAP poświadczenia i inne dane potrzebne do zapewnienia integralności i poufności wiadomości są dołączane do każdego komunikatu. Każdy komunikat zawiera dane zabezpieczeń, dzięki czemu skutkuje opłatami za wydajność, ponieważ każdy komunikat musi być przetwarzany indywidualnie. (W trybie transportu po zabezpieczeniu warstwy transportu wszystkie komunikaty przepływają swobodnie). Jednak bezpieczeństwo komunikatów ma jedną przewagę nad zabezpieczeniami transportu: jest bardziej elastyczna. Oznacza to, że wymagania dotyczące bezpieczeństwa nie są określane przez transport. Aby zabezpieczyć komunikat, możesz użyć dowolnego typu poświadczeń klienta. (W trybie transportu protokół transportowy określa typ poświadczeń klienta, których można użyć).

Transport przy użyciu poświadczeń komunikatu

Trzeci tryb łączy najlepsze zarówno zabezpieczenia transportu, jak i wiadomości. W tym trybie bezpieczeństwo transportu służy do efektywnego zapewnienia poufności i integralności każdego komunikatu. Jednocześnie każdy komunikat zawiera dane poświadczeń, które umożliwiają uwierzytelnienie komunikatu. W przypadku uwierzytelniania można również zaimplementować autoryzację. Uwierzytelniając nadawcę, dostęp do zasobów można udzielić (lub odmówić) zgodnie z tożsamością nadawcy.

Określanie typu poświadczeń klienta i wartości poświadczeń

Po wybraniu trybu zabezpieczeń możesz również określić typ poświadczeń klienta. Typ poświadczeń klienta określa, jakiego typu klient musi używać do uwierzytelniania się na serwerze.

Nie wszystkie scenariusze wymagają jednak typu poświadczeń klienta. Przy użyciu protokołu SSL za pośrednictwem protokołu HTTP (HTTPS) usługa uwierzytelnia się na kliencie. W ramach tego uwierzytelniania certyfikat usługi jest wysyłany do klienta w procesie nazywanym negocjowaniem. Transport zabezpieczony za pomocą protokołu SSL gwarantuje, że wszystkie komunikaty są poufne.

Jeśli tworzysz usługę, która wymaga uwierzytelnienia klienta, wybór typu poświadczeń klienta zależy od wybranego transportu i trybu. Na przykład użycie transportu HTTP i wybranie trybu transportu daje kilka opcji, takich jak Podstawowa, Szyfrowane i inne. (Aby uzyskać więcej informacji na temat tych typów poświadczeń, zobacz Opis uwierzytelniania HTTP).

Jeśli tworzysz usługę w domenie systemu Windows, która będzie dostępna tylko dla innych użytkowników sieci, najprostszym do użycia jest typ poświadczeń klienta systemu Windows. Jednak może być również konieczne dostarczenie usługi z certyfikatem. Pokazano to w temacie Instrukcje: Określanie wartości poświadczeń klienta.

Wartości poświadczeń

Wartość poświadczeń to rzeczywiste poświadczenia używane przez usługę. Po określeniu typu poświadczeń może być również konieczne skonfigurowanie usługi przy użyciu rzeczywistych poświadczeń. Jeśli wybrano system Windows (i usługa zostanie uruchomiona w domenie systemu Windows), nie określisz rzeczywistej wartości poświadczeń.

Tożsamość

W programie WCF termin tożsamość ma różne znaczenie dla serwera i klienta. Krótko mówiąc, podczas uruchamiania usługi tożsamość jest przypisywana do kontekstu zabezpieczeń po uwierzytelnieniu. Aby wyświetlić rzeczywistą tożsamość, sprawdź WindowsIdentity właściwości ServiceSecurityContext i PrimaryIdentity klasy . Aby uzyskać więcej informacji, zobacz How to: Examine the Security Context (Instrukcje: badanie kontekstu zabezpieczeń).

Z kolei na kliencie tożsamość jest używana do weryfikowania usługi. W czasie projektowania deweloper klienta może ustawić <element tożsamości> na wartość uzyskaną z usługi. W czasie wykonywania klient sprawdza wartość elementu względem rzeczywistej tożsamości usługi. Jeśli sprawdzanie zakończy się niepowodzeniem, klient zakończy komunikację. Wartość może być główną nazwą użytkownika (UPN), jeśli usługa działa w ramach tożsamości określonego użytkownika lub głównej nazwy usługi (SPN), jeśli usługa działa na koncie komputera. Aby uzyskać więcej informacji, zobacz Service Identity and Authentication (Tożsamość usługi i uwierzytelnianie). Poświadczenie może być również certyfikatem lub polem znalezionym w certyfikacie identyfikującym certyfikat.

Poziomy ochrony

Właściwość ProtectionLevel występuje w kilku klasach atrybutów (takich jak ServiceContractAttribute i klasy OperationContractAttribute ). Poziom ochrony to wartość określająca, czy komunikaty (lub części komunikatów), które obsługują usługę, są podpisane, podpisane i szyfrowane, czy wysyłane bez podpisów lub szyfrowania. Aby uzyskać więcej informacji na temat właściwości, zobacz Opis poziomu ochrony i przykłady programowania, zobacz How to: Set the ProtectionLevel Property (Instrukcje: ustawianie właściwości ProtectionLevel). Aby uzyskać więcej informacji na temat projektowania kontraktu usługi z ProtectionLevel programem w kontekście, zobacz Projektowanie kontraktów usług.

Zobacz też