Udostępnij przez

Wprowadzenie do zabezpieczania tworzenia aplikacji systemu Windows

Ten artykuł wprowadzający pomaga architektom aplikacji i deweloperom lepiej zrozumieć różne możliwości platformy windows 10 przyspieszające tworzenie bezpiecznych aplikacji platformy uniwersalnej systemu Windows (UWP). Szczegółowe informacje na temat korzystania z funkcji zabezpieczeń systemu Windows dostępnych na każdym z następujących etapów: uwierzytelnianie, dane w tranzycie i dane w spoczynku. Więcej szczegółowych informacji na temat każdego tematu można znaleźć, przeglądając dodatkowe zasoby zawarte w każdym rozdziale.

1 Introduction

Tworzenie bezpiecznej aplikacji może stanowić wyzwanie. W dzisiejszym szybkim tempie świat mobilnych, społecznościowych, chmurowych i złożonych aplikacji dla przedsiębiorstw klienci oczekują, że aplikacje staną się dostępne i aktualizowane szybciej niż kiedykolwiek wcześniej. Używają również wielu typów urządzeń, co dodatkowo zwiększa złożoność tworzenia środowisk aplikacji. Jeśli tworzysz aplikację dla platformy uniwersalnej systemu Windows (UWP), może to obejmować tradycyjną listę komputerów stacjonarnych, laptopów, tabletów i urządzeń przenośnych; Oprócz rosnącej listy nowych urządzeń obejmujących Internet rzeczy, Xbox One, Microsoft Surface Hub i HoloLens. Jako deweloper musisz zapewnić, że aplikacje komunikują się i przechowują dane bezpiecznie na wszystkich platformach lub urządzeniach.

Poniżej przedstawiono niektóre korzyści wynikające z korzystania z funkcji zabezpieczeń systemu Windows.

  • Będziesz mieć ustandaryzowane zabezpieczenia na wszystkich urządzeniach, które obsługują system Windows, przy użyciu spójnych interfejsów API dla składników i technologii zabezpieczeń.
  • Piszesz, testujesz i utrzymujesz mniej kodu niż w przypadku zaimplementowania niestandardowego kodu w celu pokrycia tych scenariuszy zabezpieczeń.
  • Aplikacje stają się bardziej stabilne i bezpieczne, ponieważ używasz systemu operacyjnego do kontrolowania sposobu uzyskiwania przez aplikację dostępu do zasobów oraz zasobów systemu lokalnego lub zdalnego.

Podczas uwierzytelniania tożsamość użytkownika żądającego dostępu do określonej usługi jest weryfikowana. Funkcja Windows Hello jest składnikiem systemu Windows, który ułatwia tworzenie bezpieczniejszego mechanizmu uwierzytelniania w aplikacjach systemu Windows. Za jego pomocą można użyć osobistego numeru identyfikacyjnego (PIN) lub biometrycznego, takiego jak odciski palców, twarzy lub tęczówki użytkownika, aby zaimplementować uwierzytelnianie wieloskładnikowe dla aplikacji.

Dane w locie odnoszą się do połączenia i komunikatów przesyłanych przez nie. Przykładem tego jest pobieranie danych z serwera zdalnego przy użyciu usług internetowych. Użycie protokołu SECURE Sockets Layer (SSL) i Secure Hypertext Transfer Protocol (HTTPS) zapewnia bezpieczeństwo połączenia. Zapobieganie stronom pośredniczącym dostępu do tych komunikatów lub nieautoryzowanym aplikacjom komunikowania się z usługami internetowymi jest kluczem do zabezpieczania danych w locie.

Na koniec dane w spoczynku dotyczą danych przechowywanych w pamięci lub na nośniku danych. Aplikacje systemu Windows mają model aplikacji, który uniemożliwia nieautoryzowany dostęp do danych między aplikacjami i oferuje interfejsy API szyfrowania w celu dalszego zabezpieczania danych na urządzeniu. Funkcja o nazwie Credential Locker może służyć do bezpiecznego przechowywania poświadczeń użytkownika na urządzeniu z systemem operacyjnym uniemożliwiającym innym aplikacjom dostęp do nich.

2 Czynniki uwierzytelniania

Aby chronić dane, osoba żądająca dostępu musi zostać zidentyfikowana i autoryzowana do uzyskania dostępu do żądanych zasobów danych. Proces identyfikowania użytkownika jest nazywany uwierzytelnianiem, a określanie uprawnień dostępu do zasobu jest nazywane autoryzacją. Są to ściśle powiązane operacje i dla użytkownika mogą być nie do odróżnienia. Mogą one być stosunkowo proste lub złożone operacje, w zależności od wielu czynników: na przykład niezależnie od tego, czy dane znajdują się na jednym serwerze, czy są rozproszone w wielu systemach. Serwer dostarczający usługi uwierzytelniania i autoryzacji jest określany jako dostawca tożsamości.

Aby uwierzytelnić się przy użyciu określonej usługi i/lub aplikacji, użytkownik stosuje poświadczenia złożone z czegoś, czego użytkownik zna, czego użytkownik posiada i/lub czym użytkownik jest. Każdy z nich jest nazywany czynnikami uwierzytelniania.

  • Coś, co użytkownik wie, jest zwykle hasłem, ale może być również osobistym numerem identyfikacyjnym (PIN) lub parą "tajnych" pytań i odpowiedzi.
  • Coś, co użytkownik ma, jest najczęściej urządzeniem pamięci sprzętowej, takim jak pamięć USB zawierająca dane uwierzytelniania unikatowe dla użytkownika.
  • Coś, co charakteryzuje użytkownika często obejmuje odciski palców, ale coraz bardziej popularne są takie czynniki jak mowa użytkownika, twarz, oczy lub wzorce zachowania. Gdy są przechowywane jako dane, te pomiary są nazywane biometrycznymi.

Hasło utworzone przez użytkownika jest czynnikiem uwierzytelniania, ale często nie jest wystarczające; każdy, kto zna hasło, może personifikować użytkownika, który jest jego właścicielem. Karta inteligentna może zapewnić wyższy poziom zabezpieczeń, ale może zostać skradziona, utracona lub zagubiona. System, który może uwierzytelnić użytkownika za pomocą odcisku palca lub skanu okularnego, może zapewnić najwyższy i najbardziej wygodny poziom zabezpieczeń, ale wymaga kosztownego i wyspecjalizowanego sprzętu (na przykład aparatu Intel RealSense do rozpoznawania twarzy), który może nie być dostępny dla wszystkich użytkowników.

Projektowanie metody uwierzytelniania używanego przez system jest złożonym i ważnym aspektem zabezpieczeń danych. Ogólnie rzecz biorąc, im większa liczba czynników używanych w uwierzytelnianiu, tym bezpieczniejszy jest system. Jednocześnie uwierzytelnianie musi być możliwe do użycia. Użytkownik zazwyczaj loguje się wiele razy dziennie, więc proces musi być szybki. Wybór typu uwierzytelniania jest kompromisem między zabezpieczeniami a łatwością użycia; Uwierzytelnianie jednoskładnikowe jest najmniej bezpieczne i najłatwiejsze w użyciu, a uwierzytelnianie wieloskładnikowe staje się bezpieczniejsze, ale bardziej złożone w miarę dodawania większej liczby czynników.

2.1 Uwierzytelnianie jednoskładnikowe

Ta forma uwierzytelniania jest oparta na pojedynczym poświadczaniu użytkownika. Zazwyczaj jest to hasło, ale może to być również osobisty numer identyfikacyjny (PIN).

Oto proces uwierzytelniania jednoskładnikowego.

  • Użytkownik podaje swoją nazwę użytkownika i hasło dostawcy tożsamości. Dostawca tożsamości to proces serwera, który weryfikuje tożsamość użytkownika.
  • Dostawca tożsamości sprawdza, czy nazwa użytkownika i hasło są takie same jak te przechowywane w systemie. W większości przypadków hasło będzie szyfrowane, zapewniając dodatkowe zabezpieczenia, aby inne osoby nie mogły go odczytać.
  • Dostawca tożsamości zwraca stan uwierzytelniania wskazujący, czy uwierzytelnianie zakończyło się pomyślnie.
  • Jeśli się uda, rozpoczyna się wymiana danych. Jeśli nie powiedzie się, użytkownik musi zostać ponownie uwierzytelniony.

single-factor authentication

Obecnie ta metoda uwierzytelniania jest najczęściej używana między usługami. Jest to również najmniej bezpieczna forma uwierzytelniania, jeśli jest używana jako jedyna metoda uwierzytelniania. Wymagania dotyczące złożoności haseł, "pytania tajne" i regularne zmiany haseł mogą być bezpieczniejsze przy użyciu haseł, ale obciążają użytkowników i nie są skutecznym odstraszaniem przed hakerami.

Wyzwaniem z hasłami jest to, że łatwiej jest odgadnąć je pomyślnie niż systemy, które mają więcej niż jeden czynnik. Jeśli ukraść bazę danych z kontami użytkowników i skrót hasła z małego sklepu internetowego, mogą używać haseł używanych w innych witrynach internetowych. Użytkownicy mają tendencję do ponownego używania kont przez cały czas, ponieważ złożone hasła są trudne do zapamiętania. W przypadku działu IT zarządzanie hasłami wiąże się również ze złożonością konieczności oferowania mechanizmów resetowania, częstego aktualizowania haseł i przechowywania ich w bezpieczny sposób.

W przypadku wszystkich jego wad uwierzytelnianie jednoskładnikowe zapewnia użytkownikowi kontrolę nad poświadczeniami. Tworzą go i modyfikują, a tylko klawiatura jest wymagana do procesu uwierzytelniania. Jest to główny aspekt, który odróżnia jeden czynnik od uwierzytelniania wieloskładnikowego.

2.1.1 Broker uwierzytelniania sieci Web

Jak wspomniano wcześniej, jednym z wyzwań związanych z uwierzytelnianiem haseł w dziale IT jest dodatkowe obciążenie związane z zarządzaniem bazą nazw użytkowników/haseł, mechanizmami resetowania itp. Coraz bardziej popularną opcją jest poleganie na dostawcach tożsamości innych firm, którzy oferują uwierzytelnianie za pośrednictwem protokołu OAuth, czyli otwartym standardem uwierzytelniania.

Za pomocą protokołu OAuth działy IT mogą skutecznie "zlecić" złożoność utrzymywania bazy danych przy użyciu nazw użytkowników i haseł, resetowania funkcji haseł itp. do zewnętrznego dostawcy tożsamości, takiego jak Facebook, X lub Microsoft.

Użytkownicy mają pełną kontrolę nad tożsamością na tych platformach, ale aplikacje mogą żądać tokenu od dostawcy, po uwierzytelnieniu użytkownika i z ich zgodą, które mogą służyć do autoryzowania uwierzytelnionych użytkowników.

Broker uwierzytelniania internetowego w systemie Windows udostępnia zestaw interfejsów API i infrastruktury dla aplikacji do używania protokołów uwierzytelniania i autoryzacji, takich jak OAuth i OpenID. Aplikacje mogą inicjować operacje uwierzytelniania za pomocą interfejsu API WebAuthenticationBroker, co powoduje zwrócenie wyniku WebAuthenticationResult. Omówienie przepływu komunikacji przedstawiono na poniższym rysunku.

wab workflow

Aplikacja działa jako broker, inicjując uwierzytelnianie u dostawcy tożsamości za pośrednictwem WebView w aplikacji. Gdy dostawca tożsamości uwierzytelnił użytkownika, zwraca token do aplikacji, który może służyć do żądania informacji o użytkowniku od dostawcy tożsamości. Jako środek bezpieczeństwa aplikacja musi być zarejestrowana przez dostawcę tożsamości, zanim będzie mogła pośredniczyć w procesach uwierzytelniania z dostawcą tożsamości. Te kroki rejestracji różnią się w zależności od dostawcy.

Oto: ogólna procedura wywoływania interfejsu API WebAuthenticationBroker w celu komunikacji z dostawcą.

  • Utwórz ciągi żądań, które mają być wysłane do dostawcy tożsamości. Liczba ciągów i informacje w każdym ciągu są różne dla każdej usługi internetowej, ale zwykle zawiera dwa ciągi identyfikatora URI zawierające adres URL: jeden, do którego jest wysyłane żądanie uwierzytelniania, i jeden, do którego użytkownik jest przekierowywany po zakończeniu autoryzacji.
  • Wywołaj WebAuthenticationBroker.AuthenticationAsync, przekazując ciągi żądania i poczekaj na odpowiedź od dostawcy tożsamości.
  • Wywołaj WebAuthenticationResult.ResponseStatus, aby uzyskać stan po odebraniu odpowiedzi.
  • Jeśli komunikacja zakończy się pomyślnie, przetwórz ciąg odpowiedzi zwrócony przez dostawcę tożsamości. Jeśli się nie powiedzie, przetwórz błąd.

Jeśli komunikacja zakończy się pomyślnie, przetwórz ciąg odpowiedzi zwrócony przez dostawcę tożsamości. Jeśli się nie powiedzie, przetwórz błąd.

Poniżej znajduje się przykładowy kod języka C# dla tego procesu. Aby uzyskać informacje i szczegółową instrukcję, zobacz WebAuthenticationBroker. Aby zapoznać się z kompletnym przykładem kodu, zapoznaj się z przykładem WebAuthenticationBroker w witrynie GitHub.

string startURL = "https://<providerendpoint>?client_id=<clientid>";
string endURL = "http://<AppEndPoint>";

var startURI = new System.Uri(startURL);
var endURI = new System.Uri(endURL);

try
{
    WebAuthenticationResult webAuthenticationResult = 
        await WebAuthenticationBroker.AuthenticateAsync( 
            WebAuthenticationOptions.None, startURI, endURI);

    switch (webAuthenticationResult.ResponseStatus)
    {
        case WebAuthenticationStatus.Success:
            // Successful authentication. 
            break;
        case WebAuthenticationStatus.ErrorHttp:
            // HTTP error. 
            break;
        default:
            // Other error.
        break;
    }
}
catch (Exception ex)
{
    // Authentication failed. Handle parameter, SSL/TLS, and
    // Network Unavailable errors here. 
}

2.2 Uwierzytelnianie wieloskładnikowe

Uwierzytelnianie wieloskładnikowe korzysta z więcej niż jednego czynnika uwierzytelniania. Zazwyczaj "coś, co wiesz", takie jak hasło, jest łączone z "czymś, co masz", które może być telefonem komórkowym lub kartą inteligentną. Nawet jeśli osoba atakująca wykryje hasło użytkownika, konto jest nadal niedostępne bez urządzenia lub karty. Jeśli tylko urządzenie lub karta zostanie naruszona, nie jest to przydatne dla osoby atakującej bez hasła. Uwierzytelnianie wieloskładnikowe jest zatem bezpieczniejsze, ale także bardziej złożone niż uwierzytelnianie jednoskładnikowe.

Usługi korzystające z uwierzytelniania wieloskładnikowego często dają użytkownikowi wybór sposobu odbierania drugiego poświadczenia. Przykładem tego typu uwierzytelniania jest często używany proces, w którym kod weryfikacyjny jest wysyłany na telefon komórkowy użytkownika przy użyciu wiadomości SMS.

  • Użytkownik podaje swoją nazwę użytkownika i hasło dostawcy tożsamości.
  • Dostawca tożsamości weryfikuje nazwę użytkownika i hasło, tak jak w przypadku autoryzacji jednoskładnikowej, a następnie wyszukuje numer telefonu komórkowego użytkownika przechowywanego w systemie.
  • Serwer wysyła wiadomość SMS zawierającą wygenerowany kod weryfikacyjny na telefon komórkowy użytkownika.
  • Użytkownik udostępnia kod weryfikacyjny dostawcy tożsamości; za pośrednictwem formularza przedstawionego użytkownikowi.
  • Dostawca tożsamości zwraca stan uwierzytelniania wskazujący, czy uwierzytelnianie obu poświadczeń zakończyło się pomyślnie.
  • Jeśli się uda, rozpoczyna się wymiana danych. W przeciwnym razie użytkownik musi zostać ponownie uwierzytelniony.

two-factor authentication

Jak widać, ten proces różni się również od uwierzytelniania jednoskładnikowego w tym, że drugie poświadczenie użytkownika jest wysyłane do użytkownika, a nie tworzone lub udostępniane przez użytkownika. W związku z tym użytkownik nie ma pełnej kontroli nad niezbędnymi poświadczeniami. Dotyczy to również sytuacji, gdy karta inteligentna jest używana jako drugie poświadczenie: organizacja jest odpowiedzialna za utworzenie i dostarczenie jej użytkownikowi.

2.2.1 Azure Active Directory

Azure Active Directory (Azure AD) to oparta na chmurze usługa zarządzania tożsamościami i dostępem, która może służyć jako dostawca tożsamości w uwierzytelnianiu jednoskładnikowym lub wieloskładnikowym. Uwierzytelnianie usługi Azure AD może być używane z kodem weryfikacyjnym lub bez tego kodu.

Chociaż usługa Azure AD może również implementować uwierzytelnianie jednoskładnikowe, przedsiębiorstwa zwykle wymagają wyższego poziomu zabezpieczeń uwierzytelniania wieloskładnikowego. W konfiguracji uwierzytelniania wieloskładnikowego użytkownik uwierzytelniający się przy użyciu konta usługi Azure AD ma możliwość wysłania kodu weryfikacyjnego jako wiadomości SMS na telefon komórkowy lub aplikację mobilną Azure Authenticator.

Ponadto usługa Azure AD może służyć jako dostawca OAuth, zapewniając użytkownikowi standardowi mechanizm uwierzytelniania i autoryzacji dla aplikacji na różnych platformach. Aby dowiedzieć się więcej, zobacz Azure Active Directory i Uwierzytelnianie wieloskładnikowe na platformie Azure.

2.4 Windows Hello

W systemie Windows wygodny mechanizm uwierzytelniania wieloskładnikowego jest wbudowany w system operacyjny. Windows Hello to nowy system logowania biometrycznego wbudowany w system Windows. Ponieważ jest on wbudowany bezpośrednio w system operacyjny, funkcja Windows Hello umożliwia identyfikację twarzy lub odcisku palca w celu odblokowania urządzeń użytkowników. Bezpieczny magazyn poświadczeń systemu Windows chroni dane biometryczne na urządzeniu.

Funkcja Windows Hello zapewnia niezawodny sposób rozpoznawania pojedynczego użytkownika przez urządzenie, który zajmuje się pierwszą częścią ścieżki między użytkownikiem a żądaną usługą lub elementem danych. Po rozpoznaniu użytkownika urządzenie nadal musi uwierzytelnić użytkownika przed ustaleniem, czy przyznać dostęp do żądanego zasobu. Funkcja Windows Hello zapewnia również silne uwierzytelnianie dwuskładnikowe (2FA), które jest w pełni zintegrowane z systemem Windows i zastępuje hasła wielokrotnego użytku kombinacją określonego urządzenia oraz gest biometryczny lub numer PIN. Numer PIN jest określany przez użytkownika w ramach rejestracji konta Microsoft.

Funkcja Windows Hello nie jest jednak tylko zamiennikiem tradycyjnych systemów 2FA. Jest ona koncepcyjnie podobna do kart inteligentnych: uwierzytelnianie odbywa się przy użyciu kryptograficznych elementów pierwotnych zamiast porównań ciągów, a materiał klucza użytkownika jest bezpieczny w sprzęcie odpornym na naruszenia. Usługa Microsoft Hello nie wymaga dodatkowych składników infrastruktury wymaganych do wdrożenia karty inteligentnej. W szczególności nie potrzebujesz infrastruktury kluczy publicznych (PKI), aby zarządzać certyfikatami, jeśli nie masz go obecnie. Funkcja Windows Hello łączy główne zalety kart inteligentnych — elastyczność wdrażania wirtualnych kart inteligentnych i niezawodne zabezpieczenia fizycznych kart inteligentnych — bez żadnych wad.

Aby użytkownicy mogli się z nim uwierzytelnić, należy zarejestrować urządzenie w usłudze Windows Hello. Funkcja Windows Hello używa szyfrowania asymetrycznego (klucza publicznego/prywatnego), w którym jedna ze stron używa klucza publicznego do szyfrowania danych, które druga strona może odszyfrować przy użyciu klucza prywatnego. W przypadku usługi Windows Hello tworzy zestaw par kluczy publicznych/prywatnych i zapisuje klucze prywatne na mikroukład modułu TPM (Trusted Platform Module). Po zarejestrowaniu urządzenia aplikacje platformy UWP mogą wywoływać interfejsy API systemu w celu pobrania klucza publicznego użytkownika, które mogą służyć do rejestrowania użytkownika na serwerze.

Przepływ rejestracji w aplikacji może wyglądać następująco:

rejestracja usługi Windows Hello

Zebrane informacje rejestracyjne mogą zawierać o wiele więcej informacji identyfikujących niż w tym prostym scenariuszu. Jeśli na przykład aplikacja uzyskuje dostęp do zabezpieczonej usługi, takiej jak usługa bankowa, musisz zażądać potwierdzenia tożsamości i innych elementów w ramach procesu rejestracji. Po spełnieniu wszystkich warunków klucz publiczny tego użytkownika będzie przechowywany w zapleczu i używany do sprawdzania poprawności przy następnym użyciu usługi.

Aby uzyskać więcej informacji na temat funkcji Windows Hello, zobacz Omówienie usługi Windows Hello dla firm i przewodnik dewelopera usługi Windows Hello.

3 Metody zabezpieczeń danych w locie

Metody zabezpieczeń danych w locie mają zastosowanie do danych przesyłanych między urządzeniami połączonymi z siecią. Dane mogą być przesyłane między systemami w środowisku o wysokim poziomie zabezpieczeń prywatnego intranetu firmowego lub między klientem a usługą internetową w niezabezpieczonym środowisku sieci Web. Aplikacje systemu Windows obsługują standardy, takie jak protokół SSL za pośrednictwem interfejsów API sieciowych, i współpracują z technologiami, takimi jak usługa Azure API Management, za pomocą której deweloperzy mogą zapewnić odpowiedni poziom zabezpieczeń aplikacji.

3.1 Uwierzytelnianie systemu zdalnego

Istnieją dwa ogólne scenariusze, w których komunikacja odbywa się z systemem komputerowym zdalnym.

  • Serwer lokalny uwierzytelnia użytkownika za pośrednictwem bezpośredniego połączenia. Na przykład gdy serwer i klient znajdują się w firmowym intranecie.
  • Z usługą internetową komunikujemy się przez Internet.

Wymagania dotyczące zabezpieczeń komunikacji z usługami internetowymi są wyższe niż w scenariuszach bezpośredniego połączenia, ponieważ dane nie są już częścią bezpiecznej sieci, a prawdopodobieństwo przechwycenia danych przez złośliwych osób atakujących jest również wyższe. Ponieważ różne typy urządzeń będą uzyskiwać dostęp do usługi, prawdopodobnie będą one tworzone jako usługi RESTful, w przeciwieństwie do usługi WCF, na przykład, co oznacza, że uwierzytelnianie i autoryzacja w usłudze również wprowadza nowe wyzwania. Omówimy dwa wymagania dotyczące bezpiecznej komunikacji z systemem zdalnym.

Pierwszym wymaganiem jest poufność wiadomości: informacje przekazywane między klientem a usługami internetowymi (na przykład tożsamość użytkownika i inne dane osobowe) nie mogą być czytelne przez osoby trzecie podczas przesyłania. Jest to zwykle realizowane przez szyfrowanie połączenia, za pośrednictwem którego są wysyłane komunikaty i przez szyfrowanie samego komunikatu. W przypadku szyfrowania klucza prywatnego/publicznego klucz publiczny jest dostępny dla każdego użytkownika i służy do szyfrowania komunikatów wysyłanych do określonego odbiornika. Klucz prywatny jest przechowywany tylko przez odbiorcę i służy do odszyfrowywania komunikatu.

Drugim wymaganiem jest integralność komunikatów: klient i usługa internetowa muszą mieć możliwość sprawdzenia, czy odbierane komunikaty są tymi, które mają być wysyłane przez inną stronę, i że wiadomość nie została zmieniona podczas przesyłania. Jest to realizowane przez podpisywanie komunikatów przy użyciu podpisów cyfrowych i używanie uwierzytelniania certyfikatu.

3.2 Połączenia SSL

Aby ustanowić i zachować bezpieczne połączenia z klientami, usługi internetowe mogą używać protokołu Secure Sockets Layer (SSL), który jest obsługiwany przez protokół HTTPS (Secure Hypertext Transfer Protocol). Protokół SSL zapewnia poufność i integralność komunikatów, obsługując szyfrowanie kluczy publicznych, a także certyfikaty serwera. Protokół SSL jest zastępowany przez protokół Transport Layer Security (TLS), ale protokół TLS jest często określany jako SSL.

Gdy klient żąda dostępu do zasobu na serwerze, protokół SSL rozpoczyna proces negocjacji z serwerem. Jest to nazywane uzgadnianiem SSL. Poziom szyfrowania, zestaw kluczy szyfrowania publicznego i prywatnego oraz informacje o tożsamości w certyfikatach klienta i serwera są uzgadniane jako podstawa całej komunikacji przez czas trwania połączenia SSL. Serwer może również wymagać uwierzytelnienia klienta w tej chwili. Po nawiązaniu połączenia wszystkie komunikaty są szyfrowane przy użyciu wynegocjowanego klucza publicznego do momentu zamknięcia połączenia.

3.2.1 Przypinanie protokołu SSL

Protokół SSL może zapewnić poufność komunikatów przy użyciu szyfrowania i certyfikatów, ale nie sprawdza, czy serwer, z którym komunikuje się klient, jest poprawny. Zachowanie serwera może być naśladowane przez nieautoryzowaną osobę trzecią, przechwytując poufne dane przesyłane przez klienta. Aby temu zapobiec, używana jest technika przypinania protokołu SSL w celu sprawdzenia, czy certyfikat na serwerze jest certyfikatem oczekiwanym i zaufanym przez klienta.

Istnieje kilka różnych sposobów implementowania przypinania protokołu SSL w aplikacjach, z których każdy ma własne zalety i wady. Najprostszym podejściem jest poprzez deklarację tych Certyfikatów w manifeście pakietu aplikacji. Ta deklaracja umożliwia pakietowi aplikacji instalowanie certyfikatów cyfrowych i określanie w nich wyłącznego zaufania. Powoduje to zezwolenie na połączenia SSL tylko między aplikacją a serwerami, które mają odpowiednie certyfikaty w łańcuchu certyfikatów. Ten mechanizm umożliwia również bezpieczne korzystanie z certyfikatów samopodpisanych, ponieważ nie ma potrzeby polegania na zewnętrznych zaufanych publicznych urzędach certyfikacji.

ssl manifest

Aby uzyskać większą kontrolę nad logiką walidacji, interfejsy API są dostępne do weryfikowania certyfikatów zwróconych przez serwer w odpowiedzi na żądanie HTTPS. Należy pamiętać, że ta metoda wymaga wysłania żądania i sprawdzenia odpowiedzi, dlatego przed wysłaniem poufnych informacji w żądaniu pamiętaj, aby dodać tę metodę jako walidację.

Poniższy kod w języku C# ilustruje tę metodę przypinania protokołu SSL. Metoda ValidateSSLRoot używa klasy HttpClient do wykonania żądania HTTP. Po tym, jak klient wyśle odpowiedź, używa kolekcji RequestMessage.TransportInformation.ServerIntermediateCertificates, aby sprawdzić certyfikaty zwrócone przez serwer. Klient może następnie zweryfikować cały łańcuch certyfikatów z dołączonymi odciskami palcami. Ta metoda wymaga zaktualizowania odcisków palca certyfikatu w aplikacji po wygaśnięciu i odnowieniu certyfikatu serwera.

private async Task ValidateSSLRoot()
{
    // Send a get request to Bing
    var httpClient = new HttpClient();
    var bingUri = new Uri("https://www.bing.com");
    HttpResponseMessage response = 
        await httpClient.GetAsync(bingUri);

    // Get the list of certificates that were used to
    // validate the server's identity
    IReadOnlyList<Certificate> serverCertificates = response.RequestMessage.TransportInformation.ServerIntermediateCertificates;
  
    // Perform validation
    if (!ValidateCertificates(serverCertificates))
    {
        // Close connection as chain is not valid
        return;
    }
    // Validation passed, continue with connection to service
}

private bool ValidateCertificates(IReadOnlyList<Certificate> certs)
{
    // In this example, we iterate through the certificates
    // and check that the chain contains
    // one specific certificate we are expecting
    foreach (var cert in certs)
    {
        byte[] thumbprint = cert.GetHashValue();

        // Check if the thumbprint matches whatever you 
        // are expecting
        var expected = new byte[] { 212, 222, 32, 208, 94, 102, 
            252, 83, 254, 26, 80, 136, 44, 120, 219, 40, 82, 202, 
            228, 116 };

        // ThumbprintMatches does the byte[] comparison 
        if (ThumbprintMatches(thumbprint, expected))
        {
            return true;
        }
    }
    return false;
}

3.3 Publikowanie i zabezpieczanie dostępu do interfejsów API REST

Aby zapewnić autoryzowany dostęp do usług internetowych, muszą wymagać uwierzytelniania za każdym razem, gdy jest wykonywane wywołanie interfejsu API. Możliwość kontrolowania wydajności i skalowania jest również czymś, co należy wziąć pod uwagę, gdy usługi internetowe są uwidocznione w Internecie. Azure API Management to usługa, która może pomóc uwidocznić interfejsy API w Internecie, udostępniając funkcje na trzech poziomach.

Wydawcy/Administratorzy interfejsu API mogą łatwo skonfigurować interfejs API za pośrednictwem Portalu Wydawcy usługi Azure API Management. W tym miejscu można tworzyć zestawy interfejsów API i uzyskiwać do nich dostęp, aby kontrolować, kto ma dostęp do których interfejsów API.

Deweloperzy chcący uzyskać dostęp do tych API mogą wysyłać żądania przez Portal Deweloperów, który albo natychmiast udziela dostępu, albo wymaga zatwierdzenia przez Wydawcę/Administratora. Deweloperzy mogą również wyświetlać dokumentację interfejsu API i przykładowy kod w portalu deweloperów, aby szybko wdrażać interfejsy API oferowane przez usługę internetową.

Aplikacje tworzone przez tych deweloperów, a następnie uzyskują dostęp do interfejsu API za pośrednictwem serwera proxy oferowanego przez usługę Azure API Management. Serwer proxy zapewnia warstwę ukrycia, chowając rzeczywisty punkt końcowy API na serwerze wydawcy/administratora. Może także zawierać dodatkową logikę, taką jak na przykład tłumaczenie API, aby zachować spójność udostępnionego API, gdy wywołanie do jednego API zostaje przekierowane do innego. Może również używać filtrowania adresów IP do blokowania wywołań interfejsu API pochodzących z określonej domeny IP lub zestawu domen. Usługa Azure API Management zapewnia również bezpieczeństwo swoich usług internetowych przy użyciu zestawu kluczy publicznych nazywanych kluczami interfejsu API w celu uwierzytelniania i autoryzacji każdego wywołania interfejsu API. W przypadku niepowodzenia autoryzacji dostęp do interfejsu API i obsługiwane przez nią funkcje są blokowane.

Usługa Azure API Management może również zmniejszyć liczbę wywołań interfejsu API do usługi (procedury nazywanej ograniczaniem), aby zoptymalizować wydajność usługi internetowej. Aby dowiedzieć się więcej, zapoznaj się z Azure API Management oraz Azure API Management na AzureCon 2015.

4 Metody zabezpieczeń danych w stanie spoczynku

Gdy dane docierają do urządzenia, nazywamy je "danymi magazynowymi". Te dane muszą być przechowywane na urządzeniu w bezpieczny sposób, aby nie mogły uzyskać do niego dostępu nieautoryzowani użytkownicy ani aplikacje. Model aplikacji w systemie Windows ma wiele do zapewnienia, że dane przechowywane przez dowolną aplikację są dostępne tylko dla tej aplikacji, jednocześnie udostępniając interfejsy API do udostępniania danych w razie potrzeby. Dostępne są również dodatkowe interfejsy API w celu zapewnienia, że dane mogą być szyfrowane, a poświadczenia mogą być bezpiecznie przechowywane.

4.1 Model aplikacji systemu Windows

Tradycyjnie system Windows nigdy nie miał definicji aplikacji. Najczęściej określano go jako plik wykonywalny (.exe), a nigdy nie obejmował instalacji, przechowywania stanu, długości wykonywania, przechowywania wersji, integracji systemu operacyjnego lub komunikacji między aplikacjami. Model platformy uniwersalnej systemu Windows definiuje model aplikacji obejmujący instalację, środowisko uruchomieniowe, zarządzanie zasobami, aktualizacje, model danych i odinstalowywanie.

Aplikacje systemu Windows 10 są uruchamiane w kontenerze, co oznacza, że domyślnie mają ograniczone uprawnienia (dodatkowe uprawnienia można zażądać i przyznać użytkownikowi). Jeśli na przykład aplikacja chce uzyskać dostęp do plików w systemie, selektor plików z Windows.Storage.Pickers przestrzeni nazw musi być używany, aby umożliwić użytkownikowi wybranie pliku (nie jest włączony bezpośredni dostęp do plików). Innym przykładem jest to, że jeśli aplikacja chce uzyskać dostęp do danych lokalizacji użytkownika, należy zadeklarować możliwość korzystania z funkcji lokalizacji urządzenia, informując użytkownika w momencie pobierania, że ta aplikacja zażąda dostępu do lokalizacji użytkownika. Oprócz tego, po raz pierwszy aplikacja chce uzyskać dostęp do lokalizacji użytkownika, zostanie wyświetlony dodatkowy monit o zgodę dla użytkownika, żądając uprawnień dostępu do danych.

Należy pamiętać, że ten model aplikacji działa jako "więzienie" dla aplikacji, co oznacza, że nie mogą się komunikować na zewnątrz, ale nie jest to "zamek", do którego nie można się dostać z zewnątrz (aplikacje z uprawnieniami administratora mogą oczywiście nadal mieć do niego dostęp). Funkcja Device Guard w systemie Windows, która umożliwia organizacjom/DZIAŁowi IT określenie, które aplikacje (Win32) mogą być wykonywane, mogą dodatkowo pomóc ograniczyć ten dostęp.

Model aplikacji zarządza również cyklem życia aplikacji. Domyślnie ogranicza wykonywanie aplikacji w tle, na przykład gdy tylko aplikacja przejdzie w tryb tła, proces zostanie zawieszony — po podaniu aplikacji krótkiego okresu na obsługę zawieszenia w kodzie aplikacji — a jego pamięć jest zamrożona. System operacyjny udostępnia mechanizmy umożliwiające aplikacjom wykonywanie określonych zadań w tle (zgodnie z harmonogramem, wyzwalane przez różne zdarzenia, takie jak łączność z Internetem/Bluetooth, zmiany zasilania itp., i w określonych scenariuszach, takich jak odtwarzanie muzyki lub śledzenie GPS).

Gdy zasoby pamięci na urządzeniu są niskie, system Windows zwalnia miejsce na pamięć, przerywając aplikacje. Ten model cyklu życia wymusza na aplikacjach utrwalanie danych za każdym razem, gdy są one zawieszone, ponieważ między zawieszeniem a kończeniem nie jest dostępny dodatkowy czas.

Aby uzyskać więcej informacji, zobacz It's Universal: Understanding the Lifecycle of a Windows 10 Application (Uniwersalny: opis cyklu życia aplikacji systemu Windows 10).

Ochrona przechowywanych poświadczeń

Aplikacje systemu Windows, które uzyskują dostęp do uwierzytelnionych usług, często zapewniają użytkownikom możliwość przechowywania poświadczeń na urządzeniu lokalnym. Jest to wygoda dla użytkowników; po podaniu nazwy użytkownika i hasła aplikacja automatycznie używa ich w kolejnych uruchomieniach aplikacji. Ponieważ może to być problem z bezpieczeństwem, jeśli osoba atakująca uzyska dostęp do tych przechowywanych danych, system Windows umożliwia aplikacjom opakowanym przechowywanie poświadczeń użytkownika w bezpiecznym menedżerze poświadczeń. Aplikacja wywołuje interfejs API Credential Locker do przechowywania i pobierania poświadczeń z Credential Locker zamiast ich przechowywania w kontenerze danych aplikacji. Funkcja locker poświadczeń jest zarządzana przez system operacyjny, ale dostęp jest ograniczony do aplikacji, która je przechowuje, zapewniając bezpieczne rozwiązanie do przechowywania poświadczeń.

Gdy użytkownik dostarcza poświadczenia do przechowywania, aplikacja uzyskuje odwołanie do magazynu poświadczeń za pomocą obiektu PasswordVault w przestrzeni nazw Windows.Security.Credentials. Następnie tworzy obiekt PasswordCredential zawierający identyfikator aplikacji systemu Windows oraz nazwę użytkownika i hasło. Jest to przekazywane do metody PasswordVault.Add, aby przechowywać poświadczenia w locker. Poniższy przykład kodu w języku C# pokazuje, jak to zrobić.

var vault = new PasswordVault();
vault.Add(new PasswordCredential("My App", username, password));

W poniższym przykładzie kodu w języku C# aplikacja żąda wszystkich poświadczeń odpowiadających aplikacji przez wywołanie metody FindAllByResource obiektu PasswordVault. Jeśli zostanie zwrócona więcej niż jedna, zostanie wyświetlony monit o wprowadzenie nazwy użytkownika. Jeśli poświadczenia nie znajdują się w skrytce, aplikacja wyświetli monit o ich podanie. Użytkownik jest następnie zalogowany na serwerze przy użyciu poświadczeń.

private string resourceName = "My App";
private string defaultUserName;

private void Login()
{
    PasswordCredential loginCredential = GetCredentialFromLocker();

    if (loginCredential != null)
    {
        // There is a credential stored in the locker.
        // Populate the Password property of the credential
        // for automatic login.
        loginCredential.RetrievePassword();
    }
    else
    {
        // There is no credential stored in the locker.
        // Display UI to get user credentials.
        loginCredential = GetLoginCredentialUI();
    }
    // Log the user in.
    ServerLogin(loginCredential.UserName, loginCredential.Password);
}

private PasswordCredential GetCredentialFromLocker()
{
    PasswordCredential credential = null;

    var vault = new PasswordVault();

    IReadOnlyList<PasswordCredential> credentialList = null;

    try
    {
        credentialList = vault.FindAllByResource(resourceName);
    }
    catch(Exception)
    {
        return null;
    }

    if (credentialList.Count == 1)
    {
        credential = credentialList[0];
    }
    else if (credentialList.Count > 0)
    {
        // When there are multiple usernames,
        // retrieve the default username. If one doesn't
        // exist, then display UI to have the user select
        // a default username.
        defaultUserName = GetDefaultUserNameUI();

        credential = vault.Retrieve(resourceName, defaultUserName);
    }
    return credential;
}

Aby uzyskać dalsze informacje, zobacz Credential locker.

4.3 Zapisana ochrona danych

Gdy masz do czynienia z przechowywanymi danymi, często określanymi jako dane magazynowane, szyfrowanie może uniemożliwić nieautoryzowanym użytkownikom dostęp do przechowywanych danych. Dwa typowe mechanizmy szyfrowania danych używają kluczy symetrycznych lub kluczy asymetrycznych. Jednak szyfrowanie danych nie może zagwarantować, że dane są niezmienione między chwilą ich wysłania a momentem ich przechowywania. Innymi słowy, nie można zagwarantować integralności danych. Używanie kodów uwierzytelniania komunikatów, skrótów i podpisywania cyfrowego to typowe techniki rozwiązywania tego problemu.

4.3.1 Szyfrowanie danych

W przypadku szyfrowania symetrycznego zarówno nadawca, jak i odbiorca mają ten sam klucz i używają go do szyfrowania i odszyfrowywania danych. Wyzwanie z tym podejściem jest bezpieczne dzielenie się kluczem, więc obie strony są o tym świadomi.

Jedną z odpowiedzi na to jest szyfrowanie asymetryczne, w którym jest używana para kluczy publicznych/prywatnych. Klucz publiczny jest udostępniany bezpłatnie każdemu, kto chce zaszyfrować wiadomość. Klucz prywatny jest zawsze przechowywany w tajemnicy, dzięki czemu można go używać tylko do odszyfrowywania danych. Typową techniką umożliwiającą odnajdywanie klucza publicznego jest użycie certyfikatów cyfrowych, nazywanych również certyfikatami. Certyfikat zawiera informacje o kluczu publicznym, oprócz informacji o użytkowniku lub serwerze, takich jak nazwa, wystawca, adres e-mail i kraj/region.

Deweloperzy aplikacji systemu Windows mogą używać klas SymmetricKeyAlgorithmProvider i AsymmetricKeyAlgorithmProvider do implementowania symetrycznego i asymetrycznego szyfrowania w aplikacjach platformy UWP. Ponadto klasa CryptographicEngine może służyć do szyfrowania i odszyfrowywania danych, podpisywania zawartości i weryfikowania podpisów cyfrowych. Aplikacje mogą również używać klasy DataProtectionProvider w Windows.Security.Cryptography.DataProtection przestrzeni nazw do szyfrowania i odszyfrowywania przechowywanych danych lokalnych.

4.3.2 Wykrywanie manipulacji komunikatami (MACs, skróty i podpisy)

Mac to kod (lub tag), który wynika z używania klucza symetrycznego (nazywanego kluczem tajnym) lub komunikatu jako danych wejściowych algorytmu szyfrowania MAC. Klucz tajny i algorytm są uzgadniane przez nadawcę i odbiorcę przed przesłaniem komunikatu.

Kody MAC weryfikują wiadomości podobne do tych.

  • Nadawca uzyskuje tag MAC przy użyciu klucza tajnego jako danych wejściowych algorytmu MAC.
  • Nadawca wysyła tag MAC i komunikat do odbiorcy.
  • Odbiornik uzyskuje tag MAC przy użyciu klucza tajnego i komunikatu jako danych wejściowych algorytmu MAC.
  • Odbiorca porównuje swój tag MAC z tagiem MAC nadawcy. Jeśli są takie same, wiemy, że wiadomość nie została naruszona.

mac verification

Aplikacje systemu Windows mogą implementować weryfikację komunikatów MAC przez wywołanie klasy MacAlgorithmProvider w celu wygenerowania klucza i klasy CryptographicEngine w celu wykonania algorytmu szyfrowania MAC.

4.3.3 Używanie skrótów

Funkcja skrótu to algorytm kryptograficzny, który przyjmuje dowolnie długi blok danych i zwraca ciąg bitowy o stałym rozmiarze nazywany wartością skrótu. Istnieje cała rodzina funkcji skrótu, które mogą to zrobić.

Wartość skrótu można użyć zamiast adresu MAC w powyższym scenariuszu transferu komunikatów. Nadawca wysyła wartość skrótu i komunikat, a odbiorca uzyskuje własną wartość skrótu z wartości skrótu i komunikatu nadawcy i porównuje dwie wartości skrótu. Aplikacje uruchomione w systemie Windows mogą wywoływać klasę HashAlgorithmProvider , aby wyliczyć dostępne algorytmy skrótu i uruchomić jedną z nich. Klasa CryptographicHash reprezentuje wartość skrótu. Metoda CryptographicHash.GetValueAndReset może służyć do wielokrotnego tworzenia skrótów różnych danych bez konieczności ponownego tworzenia obiektu dla każdego użycia. Metoda Append klasy CryptographicHash dodaje nowe dane do bufora przeznaczonego do skrótu kryptograficznego. Ten cały proces jest pokazany w poniższym przykładzie kodu w języku C#.

public void SampleReusableHash()
{
    // Create a string that contains the name of the
    // hashing algorithm to use.
    string strAlgName = HashAlgorithmNames.Sha512;

    // Create a HashAlgorithmProvider object.
    HashAlgorithmProvider objAlgProv = HashAlgorithmProvider.OpenAlgorithm(strAlgName);

    // Create a CryptographicHash object. This object can be reused to continually
    // hash new messages.
    CryptographicHash objHash = objAlgProv.CreateHash();

    // Hash message 1.
    string strMsg1 = "This is message 1";
    IBuffer buffMsg1 = CryptographicBuffer.ConvertStringToBinary(strMsg1, BinaryStringEncoding.Utf16BE);
    objHash.Append(buffMsg1);
    IBuffer buffHash1 = objHash.GetValueAndReset();

    // Hash message 2.
    string strMsg2 = "This is message 2";
    IBuffer buffMsg2 = CryptographicBuffer.ConvertStringToBinary(strMsg2, BinaryStringEncoding.Utf16BE);
    objHash.Append(buffMsg2);
    IBuffer buffHash2 = objHash.GetValueAndReset();

    // Convert the hashes to string values (for display);
    string strHash1 = CryptographicBuffer.EncodeToBase64String(buffHash1);
    string strHash2 = CryptographicBuffer.EncodeToBase64String(buffHash2);
}

4.3.4 Podpisy cyfrowe

Integralność danych zapisanego cyfrowo komunikatu jest weryfikowana w podobny sposób do uwierzytelniania MAC. Oto sposób działania przepływu pracy podpisu cyfrowego.

  • Nadawca uzyskuje wartość skrótu (znaną również jako skrót lub digest), wykorzystując komunikat jako wejście dla algorytmu skrótu.
  • Nadawca szyfruje skrót przy użyciu klucza prywatnego.
  • Nadawca wysyła wiadomość, zaszyfrowany skrót i nazwę użytego algorytmu skrótu.
  • Odbiorca używa klucza publicznego do odszyfrowywania odebranego zaszyfrowanego skrótu. Następnie używa algorytmu skrótu, aby zahaszować wiadomość i stworzyć z niej własny skrót. I wreszcie odbierający porównuje dwa skróty (ten, który otrzymał i odszyfrował, i ten, który stworzył). Tylko wtedy, gdy te dwa elementy się zgadzają, odbiorca może mieć pewność, że wiadomość została wysłana przez posiadacza klucza prywatnego i że osoba ta jest rzeczywiście tym, za kogo się podaje, oraz że wiadomość nie została zmieniona podczas przesyłania.

digital signatures

Algorytmy tworzenia skrótów są bardzo szybkie, więc wartości skrótów mogą być szybko uzyskiwane z nawet dużych komunikatów. Wynikowa wartość skrótu jest dowolną długością i może być krótsza niż pełny komunikat, dlatego użycie kluczy publicznych i prywatnych do szyfrowania i odszyfrowywania tylko skrótu, a nie pełnego komunikatu, jest optymalizacją.

Aby uzyskać więcej informacji, zapoznaj się z artykułami dotyczącymi podpisów cyfrowych, MAC, skrótów i podpisóworaz kryptografii .

5 Summary

Platforma uniwersalna systemu Windows w systemie Windows oferuje wiele sposobów wykorzystania możliwości systemu operacyjnego w celu tworzenia bezpieczniejszych aplikacji. W różnych scenariuszach uwierzytelniania, takich jak uwierzytelnianie jednoskładnikowe, wieloskładnikowe lub obsługiwane przez brokera z dostawcą tożsamości OAuth, istnieją interfejsy API, aby wyeliminować najczęstsze wyzwania związane z uwierzytelnianiem. Funkcja Windows Hello udostępnia nowy system logowania biometrycznego, który rozpoznaje użytkownika i aktywnie pokonuje wysiłki mające na celu obejście odpowiedniej identyfikacji. Dostarcza również wiele warstw kluczy i certyfikatów, które nigdy nie mogą być ujawniane lub używane poza modułem zaufanej platformy. Ponadto dodatkowa warstwa zabezpieczeń jest dostępna za pośrednictwem opcjonalnego użycia kluczy tożsamości zaświadczania i certyfikatów.

Aby zabezpieczyć dane w locie, interfejsy API istnieją do bezpiecznego komunikowania się z systemami zdalnymi za pośrednictwem protokołu SSL, zapewniając jednocześnie możliwość weryfikacji autentyczności serwera przy użyciu przypinania protokołu SSL. Bezpieczne i kontrolowane publikowanie interfejsów API to zadanie, które Azure API Management ułatwia, oferując potężne opcje konfiguracji do uwidaczniania interfejsów API w sieci za pomocą serwera proxy, który zapewnia dodatkowe zaciemnienie punktu końcowego interfejsu API. Dostęp do tych interfejsów API jest zabezpieczony przy użyciu kluczy interfejsu API, a wywołania interfejsu API mogą być ograniczane w celu kontrolowania wydajności.

Po nadejściu danych na urządzenie model aplikacji systemu Windows zapewnia większą kontrolę nad sposobem instalowania, aktualizowania i uzyskiwania dostępu do danych, jednocześnie zapobiegając nieautoryzowanemu dostępowi do danych innych aplikacji. Funkcja Credential Locker może zapewnić bezpieczny magazyn poświadczeń użytkownika zarządzanych przez system operacyjny, a inne dane mogą być chronione na urządzeniu przy użyciu szyfrowania i tworzenia skrótów interfejsów API oferowanych przez platformę uniwersalną systemu Windows.

6 Resources

6.1 Artykuły z instrukcjami

6.2 Przykłady kodu

Dokumentacja interfejsu API 6.3

  • Last updated on