Szyfrowanie

Szyfrowanie jest często tematem związanym z bezpieczeństwem, ale ma też znaczenie dla prywatności. Szyfrowanie ma zapobiec odczytywaniu zaszyfrowanych informacji przez inne osoby, ale to jeden ze sposobów na zachowanie prywatności. Użytkownik jest często ograniczony w zakresie możliwości samodzielnego wykonania tych czynności, ale z Twoją pomocą jako dostawca usługi, z której korzysta, szyfrowanie może pomóc zachować jego dane.

Istnieją 3 odpowiednie sposoby stosowania szyfrowania, aby lepiej chronić prywatność użytkowników: szyfrowanie podczas przesyłania, szyfrowanie w spoczynku i pełne szyfrowanie:

• Szyfrowanie podczas przesyłania to szyfrowanie danych między użytkownikiem a witryną, czyli HTTPS. Prawdopodobnie masz już skonfigurowany protokół HTTPS w swoich witrynach, ale czy wszystkie dane przesyłane do Twoich witryn są szyfrowane? Do tego służą przekierowania i HSTS. Opisujemy je poniżej. Powinny one być częścią konfiguracji HTTPS.
• Szyfrowanie w spoczynku to szyfrowanie danych przechowywanych na Twoich serwerach. Jest to ochrona przed naruszeniami bezpieczeństwa danych i ważnym elementem Twojego podejścia w zakresie bezpieczeństwa.
• Pełne szyfrowanie polega na szyfrowaniu danych na kliencie, zanim trafią na Twój serwer. Chroni to dane użytkowników nawet przed Tobą: możesz przechowywać dane użytkowników, ale nie możesz ich odczytywać. Jest trudna do wdrożenia i nie sprawdza się w przypadku wszystkich typów aplikacji. Stanowi jednak silne zabezpieczenie na poziomie prywatności użytkownika, ponieważ nikt poza nim nie widzi danych użytkownika.

HTTPS

Pierwszym krokiem jest udostępnianie usługi internetowej przez HTTPS. Jest bardzo prawdopodobne, że już to zrobisz, ale jeśli nie, jest to już ważny krok. HTTPS to protokół HTTP, czyli protokół, którego przeglądarka używa do przesyłania żądań stron internetowych z serwera, ale szyfrowany jest przy użyciu protokołu SSL. Oznacza to, że osoba przeprowadzająca atak z zewnątrz nie może odczytać ani zakłócić żądania HTTPS między nadawcą (użytkownikiem) a odbiorcą (Ty), ponieważ jest ono zaszyfrowane i nie może odczytać ani zmienić żądania. To szyfrowanie podczas przesyłania, czyli danych między Tobą a użytkownikiem. Szyfrowanie HTTPS podczas przesyłania uniemożliwia też dostawcy usług internetowych użytkownika lub dostawcy sieci Wi-Fi odczytanie danych wysyłanych w ramach korzystania z Twojej usługi. Może też wpływać na funkcje usługi: wiele zastosowań istniejących interfejsów API JavaScript wymaga, aby witryna była wyświetlana przy użyciu protokołu HTTPS. MDN ma bardziej kompleksową listę, ale interfejsy API dostępne w bezpiecznym kontekście obejmują mechanizmy Service Worker, powiadomienia push, udostępnianie internetowe i kryptowaluty, a także niektóre interfejsy API urządzeń.

Aby wyświetlać witrynę przy użyciu protokołu HTTPS, potrzebujesz certyfikatu SSL. Można je utworzyć bezpłatnie za pomocą Let's Encrypt lub często mogą być udostępniane przez Twoją usługę hostingową, jeśli z niej korzystasz. Możesz też korzystać z usługi zewnętrznej, która „serwera proxy” obsługuje Twoją usługę internetową i może udostępniać protokół HTTPS, a także usługi buforowania i usługi CDN. Jest wiele przykładów takich usług, np. Cloudflare czy Fastly. Wybór konkretnego sposobu zależy od Twojej obecnej infrastruktury. W przeszłości wdrożenie protokołu HTTPS było uciążliwe lub kosztowne, dlatego był używany wyłącznie na stronach płatności lub w szczególnie bezpiecznych źródłach. Jednak powszechnie dostępne certyfikaty, ulepszenia standardów i coraz większa liczba przeglądarek eliminują te przeszkody.

Tak

• Włącz protokół HTTPS na swoich serwerach w przypadku wszystkich celów (niezależnie od wybranej metody).
• Rozważ użycie serwera proxy, z którego korzystają Twoje serwery, na przykład Cloudflare (na httpsiseasy.com/ dowiesz się, jak to zrobić).
• Let's Encrypt przeprowadzi Cię przez proces tworzenia własnego certyfikatu SSL Let's Encrypt.
• Możesz też użyć OpenSSL bezpośrednio, aby utworzyć własny certyfikat i podpisać go przez wybrany urząd certyfikacji (szczegóły włącz HTTPS),

Wybór podejścia zależy od kompromisów biznesowych. Połączeniem SSL najłatwiej skonfigurować za pomocą usługi firmy zewnętrznej, która niesie ze sobą inne korzyści, takie jak równoważenie obciążenia, zapisywanie w pamięci podręcznej i analityka. Wiąże się to jednak również z oczywistym nałożeniem pewnej kontroli na firmę zewnętrzną i nieuniknionym uzależnieniem od jej usług (oraz możliwych płatności w zależności od wykorzystywanych usług i poziomu natężenia ruchu).

Generowanie certyfikatów i podpisywanie ich przez urząd certyfikacji to tak jak do tej pory proces SSL. Jednak korzystanie z Let's Encrypt może być łatwiejsze, jeśli obsługuje je Twój dostawca lub jeśli technicznie zespół dysponuje odpowiednimi umiejętnościami i jest bezpłatne. Jeśli używasz czegoś na wyższym poziomie niż hosting w chmurze, Twój dostawca często oferuje SSL jako usługę, więc warto to sprawdzić.

Dlaczego

Bezpieczeństwo jest częścią historii ochrony prywatności: możliwość zaprezentowania, że dane użytkowników są chronione przed zakłóceniami, pomaga budować zaufanie. Jeśli nie stosujesz protokołu HTTPS, Twoje witryny są też oznaczane jako „niezabezpieczone” przez przeglądarki (i od jakiegoś czasu). Istniejące interfejsy API JavaScript są często dostępne tylko dla stron HTTPS („bezpieczne źródła”). Chroni też użytkowników przed dostępem do internetu dla dostawców usług internetowych. Jest to z pewnością sprawdzona metoda – obecnie niemal nie ma powodu, aby używać protokołu HTTPS w witrynach.

Jak przeglądarki wyświetlają stronę HTTP (niezabezpieczoną)

Przekierowanie do HTTPS

Jeśli Twoja witryna jest dostępna zarówno pod adresami URL typu http:, jak i https:, wszystkie adresy URL z prefiksem http: przekieruj na adres https. Dzieje się tak z powyższych powodów i gwarantuje to również, że Twoja witryna nie pokaże się na whynohttps.com, jeśli stanie się popularna. Sposób, w jaki to zrobisz, zależy w dużym stopniu od infrastruktury. Jeśli Twoja witryna jest hostowana w AWS, możesz użyć systemu równoważenia obciążenia klasycznego lub aplikacji. Google Cloud działa podobnie. W Azure możesz utworzyć bramę Front Door, w węźle ekspresowym sprawdzać żądanie request.secure, w Nginx złapać cały port 80 i zwrócić 301, a w Apache – użyć reguły RewriteRule. Jeśli korzystasz z usługi hostingowej, jest dość prawdopodobne, że będzie ona automatycznie obsługiwać przekierowywanie do adresów URL HTTPS za Ciebie, np. Netlify, Firebase i GitHub Pages.

HSTS

HSTS to skrót od „HTTP Strict-Transport-Security” w celu uniemożliwienia przeglądarce na zawsze korzystania z protokołu HTTPS. Gdy zakończysz migrację do protokołu HTTPS, możesz dodać do odpowiedzi wychodzących nagłówek odpowiedzi HTTP Strict-Transport-Security. Przeglądarka, która wcześniej korzystała z Twojej witryny, zarejestruje, że widział ten nagłówek. Od tego momentu będzie automatycznie uzyskiwać dostęp do witryny, korzystając z protokołu HTTPS, nawet jeśli wyślesz żądanie HTTP. Pozwala to uniknąć przechodzenia przez przekierowanie w sposób opisany powyżej: to tak, jakby przeglądarka dyskretnie „uaktualnia” wszystkie żądania do usługi dotyczące korzystania z protokołu HTTPS.

I podobnie, wraz ze swoimi stronami możesz wyświetlać nagłówek Upgrade-Insecure-Requests (Zaktualizuj żądania niezabezpieczone). Wygląda to inaczej niż Strict-Transport-Security, ale jest z nim związane. Jeśli dodasz Upgrade-Insecure-Requests: 1, żądania z tej strony do innych zasobów (obrazów, skryptów) będą wysyłane za pomocą protokołu HTTPS, nawet jeśli link to http. Przeglądarka nie zażąda jednak ponownego połączenia się ze stroną za pomocą protokołu HTTPS i nie zapamięta go następnym razem. W praktyce zasada „Niezabezpieczone” żądania uaktualnienia przydaje się, gdy konwertujesz istniejącą witrynę z wieloma linkami do protokołu HTTPS i trudno jest przekonwertować adresy URL linków w treści, ale lepiej zmienić treść tam, gdzie to możliwe.

HSTS zapewnia przede wszystkim bezpieczeństwo – „blokuje” witrynę, używając protokołu HTTPS, u użytkowników, którzy ją wcześniej odwiedzili. Jednak tak jak powyżej, protokół HTTPS zapewnia ochronę prywatności, a HSTS – w przypadku protokołu HTTPS. Żądania niezabezpieczone nie są naprawdę potrzebne w przypadku aktualizowania całej treści. Jest to jednak przydatne podejście, które pozwala dogłębnie wzmocnić zabezpieczenia i zadbać o to, aby witryna zawsze korzystała z protokołu HTTPS.

Tak

Dodaj nagłówek HSTS do odpowiedzi wychodzących:

Strict-Transport-Security: max-age=300; includeSubDomains

Parametr max-age określa, jak długo (w sekundach) przeglądarka ma zapamiętać i wymuszać uaktualnienie HTTPS. (Ustawiliśmy czas na 300 sekund, czyli na pięć minut). Końcowy wynik powinien wynosić 6 3072 000, czyli 2 lata. Taką wartość rekomenduje hstspreload.org, ale w razie problemów trudno jest ją odzyskać. Najlepiej więc najpierw ustaw niską wartość (300) i testuj, aby sprawdzić, czy nic się nie popsuło, a potem stopniowo ją zwiększaj.

Dodaj nagłówki Upgrade-Insecure-Requests do odpowiedzi wychodzących:

Upgrade-Insecure-Requests: 1 Content-Security-Policy: upgrade-insecure-requests

Pełne szyfrowanie

Dobrym sposobem na zachowanie prywatności danych użytkownika jest niewyświetlanie ich nikomu poza użytkownikiem, w tym Tobie. W znacznym stopniu pomaga to w budowaniu zaufania: jeśli nie dysponujesz danymi użytkowników, jasne jest, że nie można z nimi zrobić niczego, czego użytkownik by nie chciał. Aby to zrobić, możesz na przykład nie dopuścić, aby dane użytkownika opuszczały ich urządzenie, przez przechowywanie wszystkich danych po stronie klienta. To podejście działa, ale istnieją pewne ograniczenia dotyczące aplikacji po stronie klienta: pamięć przeglądarki może być ograniczona, a w niektórych przeglądarkach może być wyczyszczona bez ostrzeżenia lub z niewielką ilością informacji. Trudny lub niemożliwy jest również dostęp do danych na dwóch urządzeniach, takich jak laptop i telefon komórkowy. Z tego powodu można w normalny sposób wysyłać dane na serwer, ale zaszyfrować je kluczem znanym tylko użytkownikowi. Dzięki temu serwer nie będzie miał do nich dostępu (ponieważ nie może ich odszyfrować), ale będzie mógł je zapisać.

Jak to działa?

Ta metoda jest często stosowana w aplikacjach do obsługi wiadomości, w których jest nazywane „pełnym szyfrowaniem” (e2e). W ten sposób 2 osoby, które znają się nawzajem, mogą szyfrować i odszyfrowywać swoje wiadomości, a także wysyłać je za pomocą dostawcy usług do obsługi wiadomości, ale dostawca wiadomości (który nie ma tych kluczy) nie może ich odczytać. Większość aplikacji nie jest aplikacjami do obsługi wiadomości, ale możliwe jest połączenie tych 2 podejść – przechowywanie danych wyłącznie po stronie klienta oraz szyfrowanie danych z kluczem znanym klientowi – w celu przechowywania danych lokalnie, ale także do wysyłania ich zaszyfrowanych do serwera. Takie podejście ma pewne ograniczenia: nie jest to możliwe w przypadku wszystkich usług, a w szczególności z tej metody nie można korzystać, jeśli usługodawca potrzebuje dostępu do danych przechowywanych przez użytkownika. Jak opisano w części 2 tej serii, najlepiej przestrzegać zasady minimalizacji danych i w miarę możliwości unikać gromadzenia danych. Jeśli użytkownik potrzebuje miejsca na dane, ale dostęp do nich nie jest potrzebny, aby świadczyć usługę, pełne szyfrowanie jest przydatną alternatywą. Jeśli świadczysz usługi, które wymagają wglądu w to, co przechowuje użytkownik, aby je świadczyć, pełne szyfrowanie nie jest odpowiednie. Jeśli tego nie zrobisz, możesz skorzystać z kodu JavaScript swojej usługi internetowej po stronie klienta, aby szyfrować dane wysyłane do serwera i odszyfrowywać odbierane dane.

Przykład: Excalidraw

Excalidraw robi to i wyjaśnia, jak to zrobić w poście na blogu. Jest to aplikacja do rysowania wektorowego, która przechowuje na serwerze rysunki, które są szyfrowane losowo wybranym kluczem. Jednym z powodów, dla których Excalidraw jest w stanie wdrożyć to pełne szyfrowanie przy użyciu stosunkowo małej ilości kodu, jest to, że biblioteki kryptograficzne są teraz wbudowane w przeglądarkę za pomocą window.crypto, czyli zestawu interfejsów API JavaScript obsługiwanych przez wszystkie nowoczesne przeglądarki. Kryptografia jest trudna, a wdrażanie algorytmów może wiązać się z wieloma skrajnymi przypadkami. To, że przeglądarka wykonuje najcięższą pracę, sprawia, że szyfrowanie jest łatwiejsze dla programistów i dlatego ułatwia wdrożenie ochrony prywatności za pomocą zaszyfrowanych danych. Zgodnie z opisem Excalidraw klucz szyfrowania pozostaje po stronie klienta, ponieważ jest częścią fragmentu adresu URL: gdy przeglądarka odwiedza adres URL https://example.com/path?param=1#fraghere, ścieżka adresu URL (/path) i parametry (param=1) są przekazywane do serwera (example.com), ale fragment (fraghere) już nie, więc serwer go nigdy nie widzi. Oznacza to, że nawet jeśli zaszyfrowane dane przejdą przez serwer, klucz szyfrowania nie zostanie zachowany, a tym samym prywatność zostanie w pełni szyfrowana.

Ograniczenia

To podejście do szyfrowania danych użytkownika nie jest niezawodne. Wpływa na Twoje zaufanie do użytkowników, ale nie może całkowicie go zastąpić. Użytkownicy nadal będą musieli ufać Twojej usłudze, bo w każdej chwili możesz zamienić kod JavaScript po stronie klienta na inny, subtelnie podobny kod JavaScript, który nie szyfruje danych w nieprzenikalny sposób. I chociaż jest możliwe, że użytkownik może to zrobić, jest to bardzo trudne. W praktyce użytkownicy będą jednak musieli zaufać, aby nie dopuścić do ich nadużywania, i w razie potrzeby zademonstrować usłudze, że nie warto jej zaufać.

Pamiętaj też, że jednym z celów pełnego szyfrowania jest uniemożliwienie właścicielowi witryny odczytania danych. Jest to korzystne dla ochrony prywatności, ale oznacza również, że jeśli wystąpią problemy, nie będzie można Ci pomóc. W skrócie: usługa wykorzystująca pełne szyfrowanie umożliwia użytkownikowi kontrolę nad kluczami szyfrowania. (Może to nie być oczywiste ani jawne, ale ktoś musi mieć klucz, a jeśli dane są prywatne, to Ty nie jesteś właścicielem). Jeśli te klucze zostaną utracone, nie będzie można nic zrobić, a wszystkie dane zaszyfrowane przy użyciu tych kluczy również mogą zostać utracone. Istnieje tu pewna równowaga między prywatnością a użytecznością: prywatność danych przed wszystkimi użytkownikami jest szyfrowana, ale należy też unikać zmuszania użytkowników do bycia ekspertami w dziedzinie kryptologii, którzy zarządzają własnymi kluczami w bezpieczny sposób.

Szyfrowanie w spoczynku

Oprócz szyfrowania danych użytkowników podczas przesyłania warto też szyfrować dane przechowywane na serwerze. Pomaga to chronić Cię przed naruszeniami bezpieczeństwa danych, ponieważ każdy, kto uzyska nieautoryzowany dostęp do Twoich przechowywanych danych, będzie mieć zaszyfrowane dane, których prawdopodobnie nie będzie mieć kluczy do odszyfrowania. Istnieją 2 różne, uzupełniające się podejście do szyfrowania danych w spoczynku: szyfrowanie dodane przez użytkownika oraz szyfrowanie dodane przez dostawcę miejsca w chmurze (jeśli korzystasz z usług dostawcy miejsca w chmurze). Szyfrowanie dostawcy pamięci masowej nie zapewnia dużej ochrony przed naruszeniami bezpieczeństwa danych w Twoim oprogramowaniu (ponieważ szyfrowanie po stronie dostawcy usług pamięci masowej jest zazwyczaj przejrzyste, jako użytkownik jego usługi), ale pomaga zapobiegać naruszeniom zabezpieczeń w infrastrukturze dostawcy. Często można je łatwo włączyć, więc warto się nad nimi zastanowić. To pole zmienia się szybko, a w tym zakresie najlepiej doradzać Twój zespół ds. bezpieczeństwa (lub doświadczeni inżynierowie w Twoim zespole). Jednak wszyscy dostawcy miejsca na dane w chmurze oferują szyfrowanie w spoczynku dla blokowej pamięci masowej Amazon S3 przez ustawienie domyślne Azure Storage i Google Cloud Storage, a także do przechowywania danych w bazie danych AWS RDS i Google Cloud SQL. Jeśli z niego korzystasz, sprawdź to u dostawcy miejsca w chmurze. Samodzielna obsługa szyfrowania danych w spoczynku w celu ochrony danych użytkowników przed naruszeniami bezpieczeństwa danych jest trudniejsza, ponieważ logistyka bezpiecznego zarządzania kluczami szyfrowania i udostępniania ich do kodu bez udostępniania ich osobom przeprowadzającym atak nie jest łatwa. Nie jest to jednak najlepsze miejsce do udzielania porad dotyczących kwestii bezpieczeństwa na tym poziomie. Porozmawiaj na ten temat z inżynierami specjalizującymi się w zabezpieczeniach, dedykowanym zespołem ds. zabezpieczeń lub zewnętrznymi agencjami ds. bezpieczeństwa.