Ponieważ świat w coraz większym stopniu opiera się na danych, bezpieczne przetwarzanie danych użytkowników jest ważniejsze niż kiedykolwiek.
Nasza praca jako programistów jest już wystarczająco ciężka: radzenie sobie z bardzo złożonymi i delikatnymi systemami z wieloma punktami awarii, podczas gdy my przekładamy przemykające ludzkie życzenia na interfejsy użytkownika i backend. Dodanie do zadania pojawia się i ma zasadnicze znaczenie: bezpieczeństwo danych. I nie bez powodu: my, klienci, jesteśmy wściekli, gdy nasze dane są niewłaściwie wykorzystywane (tak więc jest sprawiedliwe, że zapewniamy naszym użytkownikom bezpieczne i przyjemne korzystanie), a rządy i przedsiębiorstwa wymagają tego w celu zapewnienia zgodności.
Spis treści:
Bezpieczeństwo danych jako przekazywanie pieniędzy
Tym, co sprawia, że bezpieczeństwo jest trudniejsze, jest to, że składa się z kilku warstw i staje się kwestią odpowiedzialności wszystkich za niczyją. W nowoczesnym zespole chmurowym wiele zespołów bezpośrednio kontroluje wejście/wyjście danych: programiści, administratorzy baz danych, administratorzy systemu (ludzie DevOps, jeśli wolicie), uprzywilejowani użytkownicy zaplecza i tak dalej. Te role/zespoły mogą szybko zamknąć oczy i myśleć o bezpieczeństwie danych jako o problemie innych. Mimo to w rzeczywistości mają swoje własne światy, którymi muszą się zająć, ponieważ administrator bazy danych nie może kontrolować bezpieczeństwa aplikacji, osoba DevOps nie może absolutnie nic zrobić z dostępem do zaplecza i tak dalej.
Programiści i bezpieczeństwo danych
To powiedziawszy, programiści mają największą powierzchnię dostępu do danych: budują każdą część aplikacji; łączą się z różnymi usługami zaplecza; żetony dostępu do promu tam iz powrotem; mają do dyspozycji cały klaster bazy danych do odczytu/zapisu; aplikacje, które piszą, mają niekwestionowany dostęp do wszystkich części systemu (na przykład produkcyjna aplikacja Django ma wszystkie uprawnienia do zrzucania lub wymazywania całej kolekcji S3 z ostatnich dziesięciu lat) i tak dalej. W rezultacie największe prawdopodobieństwo niechlujstwa lub przeoczenia w zakresie bezpieczeństwa istnieje na poziomie kodu źródłowego i jest bezpośrednią odpowiedzialnością programisty.
Teraz bezpieczeństwo danych to królicza dziura bez dna i nie ma możliwości, żebym nawet zarysował powierzchnię w jednym poście. Chcę jednak omówić podstawową terminologię, którą programiści muszą znać, aby zapewnić bezpieczeństwo swoim aplikacjom. Pomyśl o tym jako o bezpieczeństwie danych aplikacji 101.
Zacznijmy!
Haszowanie
Jeśli chcesz bardzo rygorystycznej definicji, zawsze jest Wikipedii, ale w uproszczeniu haszowanie to proces konwersji danych do innej postaci, w której informacje są nieczytelne. Na przykład przy użyciu dobrze znanego (i bardzo niepewnego) procesu kodowanie base64, ciąg „Czy mój sekret jest u ciebie bezpieczny?” można przekonwertować („zaszyfrować”) na „SXMgbXkgc2VjcmV0IHNhZmUgd2l0aCB5b3U/”. Jeśli na przykład zaczniesz pisać swój osobisty pamiętnik w formacie Base64, nie ma możliwości, aby twoja rodzina mogła przeczytać twoje sekrety (chyba że wiedzą, jak rozszyfrować z Base64)!
Ten pomysł szyfrowania danych jest używany podczas przechowywania haseł, numerów kart kredytowych itp. W aplikacjach internetowych (właściwie powinien być używany we wszystkich typach aplikacji). Pomysł polega oczywiście na tym, że w przypadku naruszenia danych osoba atakująca nie powinna mieć możliwości wykorzystania haseł, numerów kart kredytowych itp. do wyrządzenia rzeczywistych szkód. Do wykonywania tego mieszania używane są wysoce niezawodne i wyrafinowane algorytmy; coś takiego jak Base64 będzie żartem i zostanie natychmiast złamane przez każdego atakującego.
Hasło haszowane wykorzystuje technikę kryptograficzną znaną jako haszowanie jednokierunkowe, co oznacza, że chociaż możliwe jest zaszyfrowanie danych, nie jest możliwe ich rozszyfrowanie. Skąd więc aplikacja wie, że to twoje hasło, kiedy się logujesz? Cóż, używa tego samego procesu i porównuje zaszyfrowaną formę tego, co właśnie wprowadziłeś jako hasło, z zaszyfrowaną formą przechowywaną w bazie danych; jeśli pasują, możesz się zalogować!
Skoro jesteśmy przy temacie skrótów, oto coś interesującego. Jeśli kiedykolwiek pobierałeś oprogramowanie lub pliki z Internetu, być może zostałeś poproszony o zweryfikowanie plików przed ich użyciem. Na przykład, jeśli chcesz pobrać system Ubuntu Linux ISO, strona pobierania wyświetli opcję weryfikacji pobrania; jeśli go klikniesz, otworzy się wyskakujące okienko:
Wyskakujące okienko mówi ci o uruchomieniu polecenia, które zasadniczo spowoduje zaszyfrowanie całego właśnie pobranego pliku i porównanie wyniku z ciągiem skrótów widocznym na stronie pobierania: 5fdebc435ded46ae99136ca875afc6f05bde217be7dd018e1841924f71db46b5. Ta konwersja jest wykonywana za pomocą Algorytm SHA256o którym mowa w końcowych fragmentach polecenia: shasum -a 256 –check.
Pomysł polega na tym, że jeśli hash wygenerowany podczas sprawdzania jest inny, oznacza to, że ktoś ingerował w pobieranie i zamiast tego dostarczył zainfekowany plik.
Niektóre znane nazwy, które usłyszysz w dziedzinie mieszania haseł, to MD5 (niepewne i obecnie nieistniejące), SHA-1 i SHA-2 (rodziny algorytmów, których członkiem jest SHA-256, podobnie jak SHA-512), SCRYPT, BCRYPT itp.
Solenie
Wszystkie rodzaje zabezpieczeń to gra w kotka i myszkę: złodziej uczy się obecnego systemu i wymyśla nowe luki, które zostają zauważone, a twórcy zamków ulepszają swoją grę i tak dalej, i tak dalej. Kryptografia nie jest wyjątkiem. Podczas gdy konwersja skrótów z powrotem na hasła stała się niemożliwa, osoby atakujące z czasem opracowały wyrafinowane techniki, które łączą inteligentne domysły z czystą mocą obliczeniową; w rezultacie dziewięć razy na dziesięć mogą przewidzieć prawidłowe hasło, biorąc pod uwagę tylko skrót.
„Pan. Rumpelstiltskin, jak mniemam?!”
W rezultacie rozwinęła się technika solenia. Oznacza to jedynie, że obliczenie skrótu hasła (lub dowolnych danych) zostanie wykonane na podstawie kombinacji dwóch rzeczy: samych danych oraz nowego losowego ciągu, którego atakujący nie może odgadnąć. Tak więc w przypadku solenia, jeśli chcemy zaszyfrować hasło superman009, najpierw wybralibyśmy losowy ciąg jako „sól”, powiedzmy bCQC6Z2LlbAsqj77, a następnie wykonalibyśmy obliczenie skrótu na superman009-bCQC6Z2LlbAsqj77. Wynikowy skrót będzie odbiegał od zwykłych struktur tworzonych przez algorytm, znacznie zmniejszając zakres inteligentnej inżynierii wstecznej lub zgadywania.
Zarówno haszowanie, jak i solenie są niezwykle skomplikowanymi domenami i są stale rozwijane. Dlatego jako twórcy aplikacji nigdy nie mielibyśmy z nimi bezpośredniego kontaktu. Ale bardzo by nam pomogło, gdybyśmy je znali i mogli podejmować lepsze decyzje. Na przykład, jeśli utrzymujesz stary framework PHP i zauważysz, że używa on skrótów MD5 do haseł, wiesz, że nadszedł czas, aby wstawić kolejną bibliotekę haseł w procesie tworzenia konta użytkownika.
Klucze
Często spotykasz się z terminem „klucze” w kontekście szyfrowania. Do tej pory zajmowaliśmy się haszowaniem haseł lub szyfrowaniem jednokierunkowym, w których nieodwracalnie konwertujemy dane i niszczymy pierwotną formę. To zły pomysł do codziennego użytku praktycznego — dokument napisany i wysłany pocztą elektroniczną tak bezpiecznie, że nigdy nie można go odczytać, jest bezużyteczny! Dlatego chcemy zaszyfrować dane tak, aby informacje były otwarte dla nadawcy i odbiorcy, ale podczas przesyłania lub przechowywania powinny być nieczytelne.
W tym celu w kryptografii istnieje koncepcja „klucza”. Dokładnie to brzmi: klucz do zamka. Osoba, która jest właścicielem informacji, szyfruje je za pomocą jakiegoś sekretu zwanego kluczem. Jeśli odbiorca/napastnik nie ma tego klucza, niemożliwe jest rozszyfrowanie danych, bez względu na to, jak wyrafinowane mogą być ich algorytmy.
Obrotowe klucze
Chociaż klucze umożliwiają szyfrowanie i są niezawodne, niosą ze sobą ryzyko, które niesie ze sobą hasło: gdy ktoś zna klucz, cała gra się kończy. Wyobraź sobie scenariusz, w którym ktoś włamuje się do jakiejś części usługi takiej jak GitHub (nawet jeśli na kilka sekund) i może zdobyć kod sprzed 20 lat. Wewnątrz kodu znajdują również klucze kryptograficzne używane do szyfrowania danych firmy (okropna praktyka przechowywania kluczy wraz z kodem źródłowym, ale zdziwiłbyś się, jak często się to zdarza!). Jeśli firma nie zadała sobie trudu, aby zmienić swoje klucze (podobnie jak hasła), ten sam klucz może zostać użyty do siania spustoszenia.
W rezultacie praktyka częstej zmiany kluczy ewoluowała. Nazywa się to rotacją kluczy, a jeśli korzystasz z jakiegokolwiek szanowanego dostawcy usługi PaaS w chmurze, powinna ona być dostępna jako usługa zautomatyzowana.
Źródło obrazu: AWS
Na przykład AWS ma do tego dedykowaną usługę o nazwie Usługa zarządzania kluczami AWS (KMS). Zautomatyzowana usługa oszczędza kłopotów związanych ze zmianą i dystrybucją kluczy między wszystkimi serwerami i jest obecnie oczywista, jeśli chodzi o duże wdrożenia.
Kryptografia klucza publicznego
Jeśli cała poprzednia rozmowa o szyfrowaniu i kluczach sprawia, że myślisz, że jest to bardzo uciążliwe, masz rację. Przechowywanie kluczy w bezpiecznym miejscu i przekazywanie ich w taki sposób, aby tylko odbiorca mógł zobaczyć dane, napotyka problemy logistyczne, które nie pozwoliłyby na pomyślne funkcjonowanie dzisiejszej bezpiecznej komunikacji. Ale wszystko dzięki kryptografii z kluczem publicznym możemy bezpiecznie komunikować się czy robić zakupy online.
Ten rodzaj kryptografii był wielkim matematycznym przełomem i jest jedynym powodem, dla którego Internet nie rozpada się ze strachu i nieufności. The szczegóły algorytmu są skomplikowane i wysoce matematyczne, więc mogę je tutaj wyjaśnić tylko koncepcyjnie.
Źródło obrazu: The Electronic Frontier Foundation
Kryptografia klucza publicznego opiera się na użyciu dwóch kluczy do przetwarzania informacji. Jeden z kluczy nazywa się kluczem prywatnym i powinien pozostać dla ciebie prywatny i nigdy nikomu go nie udostępniać; drugi nazywa się Kluczem Publicznym (skąd pochodzi nazwa metody) i ma być publikowany publicznie. Jeśli wysyłam do Ciebie dane, najpierw muszę zdobyć Twój klucz publiczny, zaszyfrować dane i wysłać je do Ciebie; na koniec możesz odszyfrować dane za pomocą kombinacji klucza prywatnego i klucza publicznego. Dopóki przypadkowo nie ujawnisz swojego klucza prywatnego, mogę przesłać Ci zaszyfrowane dane, które tylko Ty możesz otworzyć.
Piękno tego systemu polega na tym, że nie muszę znać twojego klucza prywatnego, a każdy, kto przechwyci wiadomość, nie może nic zrobić, aby ją przeczytać, mimo że ma twój klucz publiczny. Jeśli zastanawiasz się, jak to w ogóle możliwe, najkrótsza i najbardziej nietechniczna odpowiedź pochodzi z właściwości mnożenia liczb pierwszych:
Komputerom trudno jest rozłożyć na czynniki duże liczby pierwsze. Tak więc, jeśli oryginalny klucz jest bardzo duży, możesz być pewien, że wiadomości nie da się odszyfrować nawet za tysiące lat.
Zabezpieczenia warstwy transportowej (TLS)
Wiesz już, jak działa kryptografia klucza publicznego. Ten mechanizm (znajomość klucza publicznego odbiorcy i wysyłanie mu danych zaszyfrowanych przy jego użyciu) jest tym, co kryje się za całą popularnością HTTPS i powoduje, że Chrome mówi: „Ta witryna jest bezpieczna”. Dzieje się tak, ponieważ serwer i przeglądarka szyfrują ruch HTTP (pamiętaj, że strony internetowe to bardzo długie ciągi tekstu, które przeglądarki mogą interpretować) za pomocą swoich kluczy publicznych, co skutkuje bezpiecznym HTTP (HTTPS).
Źródło zdjęcia: Mozilla Warto zauważyć, że szyfrowanie nie odbywa się w warstwie transportowej jako takiej; the modelu OSI nic nie mówi o szyfrowaniu danych. Po prostu dane są szyfrowane przez aplikację (w tym przypadku przeglądarkę) przed przekazaniem ich do warstwy transportowej, która później umieszcza je w miejscu docelowym, gdzie są odszyfrowywane. Jednak proces ten obejmuje warstwę transportową, a ostatecznie wszystko to skutkuje bezpiecznym transportem danych, więc luźny termin „bezpieczeństwo warstwy transportowej” utknął.
W niektórych przypadkach możesz nawet spotkać się z terminem Secure Socket Layer (SSL). Jest to ta sama koncepcja co TLS, z tą różnicą, że SSL powstał dużo wcześniej i teraz został zastąpiony TLS.
Pełne szyfrowanie dysku
Czasami potrzeby w zakresie bezpieczeństwa są tak duże, że niczego nie można pozostawić przypadkowi. Na przykład serwery rządowe, na których przechowywane są wszystkie dane biometryczne danego kraju, nie mogą być udostępniane i działać jak zwykłe serwery aplikacji, ponieważ ryzyko jest zbyt wysokie. Dla tych potrzeb nie wystarczy, aby dane były szyfrowane tylko podczas przesyłania; musi być zaszyfrowany również w stanie spoczynku. W tym celu szyfrowanie całego dysku jest używane do zaszyfrowania całego dysku twardego, aby zapewnić bezpieczeństwo danych nawet w przypadku fizycznego naruszenia.
Należy zauważyć, że pełne szyfrowanie dysku musi być wykonane na poziomie sprzętowym. Dzieje się tak, ponieważ jeśli zaszyfrujemy cały dysk, system operacyjny jest również zaszyfrowany i nie może działać podczas uruchamiania komputera. Tak więc sprzęt musi rozumieć, że zawartość dysku jest zaszyfrowana i musi przeprowadzać deszyfrowanie w locie, gdy przekazuje żądane bloki dysku do systemu operacyjnego. Ze względu na tę dodatkową pracę, szyfrowanie pełnego dysku powoduje wolniejszy odczyt/zapis, o czym muszą pamiętać twórcy takich systemów.
Szyfrowanie typu end-to-end
Przy ciągłych koszmarach związanych z prywatnością i bezpieczeństwem dużych sieci społecznościowych, nikt nie jest nieświadomy terminu „szyfrowanie typu end-to-end”, nawet jeśli nie mają oni nic wspólnego z tworzeniem lub utrzymywaniem aplikacji.
Widzieliśmy wcześniej, jak pełne szyfrowanie dysku zapewnia najlepszą strategię kuloodporną, ale dla zwykłego użytkownika nie jest to wygodne. Wyobraź sobie, że Facebook chce, aby dane telefonu, które generuje i przechowuje w telefonie, były bezpieczne, ale nie może mieć dostępu do szyfrowania całego telefonu i blokowania wszystkiego innego w tym procesie.
Z tego powodu firmy te rozpoczęły kompleksowe szyfrowanie, co oznacza, że dane są szyfrowane podczas ich tworzenia, przechowywania lub przesyłania przez aplikację. Innymi słowy, nawet gdy dane dotrą do odbiorcy, są w pełni zaszyfrowane i dostępne tylko z telefonu odbiorcy.
Źródło obrazu: Google
Należy zauważyć, że szyfrowanie typu End-to-End (E2E) nie daje żadnych gwarancji matematycznych, tak jak ma to miejsce w przypadku kryptografii klucza publicznego; to po prostu standardowe szyfrowanie, w którym klucz jest przechowywany w firmie, a Twoje wiadomości są tak bezpieczne, jak zdecyduje firma.
Wniosek 👩🏫
Prawdopodobnie słyszałeś już o większości tych terminów. Może nawet wszystkie. Jeśli tak, zachęcam Cię do ponownego przemyślenia swojego rozumienia tych pojęć, a także do oceny, na ile poważnie je traktujesz. Pamiętaj, że bezpieczeństwo danych aplikacji to wojna, którą musisz wygrać za każdym razem (i nie tylko raz), ponieważ nawet jedno naruszenie wystarczy, aby zniszczyć całe branże, kariery, a nawet życie!