Zabezpieczenia platformy Azure dla aplikacji natywnych dla chmury
Napiwek
Ta zawartość jest fragmentem książki eBook, Architekting Cloud Native .NET Applications for Azure, dostępnej na platformie .NET Docs lub jako bezpłatny plik PDF do pobrania, który można odczytać w trybie offline.
Aplikacje natywne dla chmury mogą być łatwiejsze i trudniejsze do zabezpieczenia niż tradycyjne aplikacje. Na minusie należy zabezpieczyć bardziej mniejsze aplikacje i przeznaczyć więcej energii, aby utworzyć infrastrukturę zabezpieczeń. Heterogeniczny charakter języków programowania i stylów w większości wdrożeń usług oznacza również, że należy zwrócić większą uwagę na biuletyny zabezpieczeń od wielu różnych dostawców.
Z drugiej strony mniejsze usługi, z których każdy ma własny magazyn danych, ograniczają zakres ataku. Jeśli osoba atakująca naruszy jeden system, prawdopodobnie trudniej jest osobie atakującej przejść do innego systemu niż w aplikacji monolitycznej. Granice procesów są silnymi granicami. Ponadto jeśli kopia zapasowa bazy danych zostanie uwidoczniona, uszkodzenie jest bardziej ograniczone, ponieważ baza danych zawiera tylko podzestaw danych i prawdopodobnie nie będzie zawierać danych osobowych.
Modelowanie zagrożeń
Niezależnie od tego, czy zalety przewyższają wady aplikacji natywnych dla chmury, należy przestrzegać tego samego całościowego podejścia do zabezpieczeń. Bezpieczeństwo i bezpieczne myślenie musi być częścią każdego kroku historii programowania i operacji. Podczas planowania aplikacji zadaj pytania, takie jak:
- Jaki byłby wpływ na utratę tych danych?
- Jak możemy ograniczyć szkody wynikające z nietrafionych danych wstrzykiwanych do tej usługi?
- KtoTo mieć dostęp do tych danych?
- Czy istnieją zasady inspekcji dotyczące procesu tworzenia i wydawania?
Wszystkie te pytania są częścią procesu nazywanego modelowaniem zagrożeń. Ten proces próbuje odpowiedzieć na pytanie, jakie zagrożenia istnieją w systemie, jak prawdopodobne są zagrożenia i potencjalne szkody z nich.
Po ustanowieniu listy zagrożeń należy zdecydować, czy warto je złagodzić. Czasami zagrożenie jest tak mało prawdopodobne i kosztowne, aby zaplanować, że nie warto wydawać na nią energii. Na przykład niektórzy aktor na poziomie stanu mogą wprowadzać zmiany w projekcie procesu używanego przez miliony urządzeń. Teraz zamiast uruchamiać określony fragment kodu w pierścieniu 3, ten kod jest uruchamiany w pierścieniu 0. Ten proces umożliwia wykorzystanie luki, która może pominąć funkcję hypervisor i uruchomić kod ataku na maszynach bez systemu operacyjnego, umożliwiając ataki na wszystkie maszyny wirtualne uruchomione na tym sprzęcie.
Zmienione procesory są trudne do wykrycia bez mikroskopu i zaawansowanej wiedzy na temat projektowania krzemowego tego procesora. Ten scenariusz jest mało prawdopodobny i kosztowny w celu ograniczenia ryzyka, więc prawdopodobnie żaden model zagrożeń nie zaleciłby utworzenia ochrony przed programami wykorzystującą luki w zabezpieczeniach.
Bardziej prawdopodobne zagrożenia, takie jak uszkodzone mechanizmy kontroli dostępu zezwalające Id na przyrostowe ataki (zastępowanie Id=2Id=3 za pomocą adresu URL) lub wstrzyknięcie kodu SQL, są bardziej atrakcyjne do tworzenia ochrony przed. Środki zaradcze dla tych zagrożeń są dość rozsądne do budowy i zapobiegania kłopotliwym dziurom bezpieczeństwa, które rozmazują reputację firmy.
Zasada najmniejszych uprawnień
Jednym z pomysłów założycieli w zabezpieczeniach komputerowych jest zasada najniższych uprawnień (POLP). To w rzeczywistości fundamentalny pomysł w większości każdej formy zabezpieczeń, to cyfrowy lub fizyczny. Krótko mówiąc, zasada polega na tym, że każdy użytkownik lub proces powinien mieć najmniejszą liczbę praw do wykonania zadania.
Na przykład pomyśl o kasjerach w banku: uzyskiwanie dostępu do bezpiecznego jest nietypową aktywnością. Tak więc przeciętny teller nie może otworzyć się bezpiecznie. Aby uzyskać dostęp, muszą eskalować swoje żądanie za pośrednictwem menedżera banku, który wykonuje dodatkowe kontrole bezpieczeństwa.
W systemie komputerowym fantastycznym przykładem są prawa użytkownika łączącego się z bazą danych. W wielu przypadkach istnieje jedno konto użytkownika używane do kompilowania struktury bazy danych i uruchamiania aplikacji. Z wyjątkiem skrajnych przypadków konto z uruchomioną aplikacją nie potrzebuje możliwości aktualizowania informacji o schemacie. Powinno istnieć kilka kont, które zapewniają różne poziomy uprawnień. Aplikacja powinna używać tylko poziomu uprawnień, który przyznaje dostęp do odczytu i zapisu danych w tabelach. Tego rodzaju ochrona eliminuje ataki mające na celu usunięcie tabel bazy danych lub wprowadzenie złośliwych wyzwalaczy.
Prawie każda część tworzenia aplikacji natywnej dla chmury może korzystać z zapamiętania zasady najniższych uprawnień. Można go znaleźć podczas konfigurowania zapór, sieciowych grup zabezpieczeń, ról i zakresów w kontroli dostępu opartej na rolach (RBAC).
Testy penetracyjne
W miarę jak aplikacje stają się bardziej skomplikowane, liczba wektorów ataków zwiększa się z niepokojącym współczynnikiem. Modelowanie zagrożeń jest wadliwe, ponieważ zwykle jest wykonywane przez tych samych ludzi tworzących system. W ten sam sposób, w jaki wielu deweloperów ma problemy z przewidywaniem interakcji użytkowników, a następnie tworzenie bezużytecznych interfejsów użytkownika, większość deweloperów ma trudności z wyświetlaniem każdego wektora ataku. Istnieje również możliwość, że deweloperzy tworzący system nie są dobrze zorientowani w metodologiach ataków i przegapią coś kluczowego.
Testy penetracyjne lub "testowanie penetracyjne" obejmują wprowadzenie zewnętrznych podmiotów do próby ataku na system. Osoby atakujące mogą być zewnętrzną firmą konsultingową lub innymi deweloperami z dobrą wiedzą na temat zabezpieczeń z innej części firmy. Otrzymują carte blanche, aby spróbować odwrócić system. Często znajdziesz w nich obszerne otwory zabezpieczające, które muszą być zakleszczone. Czasami wektor ataku będzie coś zupełnie nieoczekiwanego, takiego jak wykorzystanie ataku wyłudzania informacji wobec dyrektora generalnego.
Sama platforma Azure stale przechodzi ataki zespołu hakerów w firmie Microsoft. Przez lata byli pierwszymi, którzy znaleźli dziesiątki potencjalnie katastroficznych wektorów ataków, zamykając je, zanim będą mogły być wykorzystywane zewnętrznie. Tym bardziej kuszące jest cel, tym bardziej prawdopodobne, że wieczni aktorzy będą próbować go wykorzystać i istnieje kilka celów na świecie bardziej kuszących niż platforma Azure.
Monitorowanie
Jeśli osoba atakująca spróbuje przeniknąć przez aplikację, powinno zostać wyświetlone ostrzeżenie. Często można wykryć ataki, sprawdzając dzienniki z usług. Ataki pozostawiają znaki telltale, które można zauważyć, zanim odniosą sukces. Na przykład osoba atakująca próbująca odgadnąć hasło wyśle wiele żądań do systemu logowania. Monitorowanie wokół systemu logowania może wykrywać dziwne wzorce, które są poza granicą z typowym wzorcem dostępu. To monitorowanie można przekształcić w alert, który może z kolei powiadamiać osobę operacyjną o aktywowaniu pewnego rodzaju środków zaradczych. Wysoce dojrzały system monitorowania może nawet podejmować działania na podstawie tych odchyleń, proaktywnie dodając reguły do blokowania żądań lub ograniczania odpowiedzi.
Zabezpieczanie kompilacji
Jednym z miejsc, w których zabezpieczenia są często pomijane, jest proces kompilacji. Nie tylko należy uruchamiać testy zabezpieczeń kompilacji, takie jak skanowanie pod kątem niezabezpieczonego kodu lub poświadczeń zaewidencjonowania, ale sama kompilacja powinna być bezpieczna. Jeśli serwer kompilacji zostanie naruszony, zapewnia fantastyczny wektor do wprowadzania dowolnego kodu do produktu.
Załóżmy, że osoba atakująca chce ukraść hasła osób logujących się do aplikacji internetowej. Mogą wprowadzić krok kompilacji, który modyfikuje wyewidencjonowany kod w celu zdublowania dowolnego żądania logowania na innym serwerze. Następnym razem, gdy kod przejdzie przez kompilację, zostanie on w trybie dyskretnym zaktualizowany. Skanowanie luk w zabezpieczeniach kodu źródłowego nie przechwyci tej luki w zabezpieczeniach, ponieważ jest uruchamiane przed kompilacją. Podobnie nikt nie przechwyci go w przeglądzie kodu, ponieważ kroki kompilacji działają na serwerze kompilacji. Wykorzystany kod przejdzie do środowiska produkcyjnego, w którym może zbierać hasła. Prawdopodobnie nie ma dziennika inspekcji zmian procesu kompilacji lub przynajmniej nikt nie monitoruje inspekcji.
Ten scenariusz jest doskonałym przykładem pozornie niskiej wartości docelowej, która może służyć do podziału na system. Gdy osoba atakująca naruszy obwód systemu, może rozpocząć pracę nad znalezieniem sposobów podniesienia uprawnień do tego stopnia, że może spowodować rzeczywiste szkody w dowolnym miejscu, w którym się podoba.
Kompilowanie bezpiecznego kodu
Program .NET Framework jest już dość bezpieczną strukturą. Pozwala uniknąć niektórych pułapek niezarządzanego kodu, takich jak odejścia od końców tablic. Praca jest aktywnie wykonywana w celu naprawienia otworów zabezpieczających w miarę ich odnajdowania. Istnieje nawet program bounty błędów, który płaci naukowcom znaleźć problemy w ramach i zgłosić je zamiast wykorzystywać je.
Istnieje wiele sposobów zwiększenia bezpieczeństwa kodu platformy .NET. Postępując zgodnie z wytycznymi dotyczącymi bezpiecznego kodowania dla platformy .NET , należy wykonać rozsądny krok, aby upewnić się, że kod jest bezpieczny od podstaw. OWASP top 10 to kolejny nieoceniony przewodnik tworzenia bezpiecznego kodu.
Proces kompilacji jest dobrym miejscem do umieszczenia narzędzi do skanowania w celu wykrywania problemów w kodzie źródłowym, zanim przejdą do środowiska produkcyjnego. Większość projektów ma zależności od innych pakietów. Narzędzie, które może skanować pod kątem nieaktualnych pakietów, będzie przechwytywać problemy w nocnej kompilacji. Nawet podczas tworzenia obrazów platformy Docker warto sprawdzić i upewnić się, że obraz podstawowy nie ma znanych luk w zabezpieczeniach. Kolejną rzeczą do sprawdzenia jest to, że nikt nie został przypadkowo zaewidencjonowany poświadczeń.
Wbudowane zabezpieczenia
Platforma Azure jest przeznaczona do równoważenia użyteczności i zabezpieczeń dla większości użytkowników. Różni użytkownicy będą mieć różne wymagania dotyczące zabezpieczeń, więc muszą dostosować swoje podejście do zabezpieczeń w chmurze. Firma Microsoft publikuje wiele informacji o zabezpieczeniach w Centrum zaufania. Ten zasób powinien być pierwszym przystankiem dla tych specjalistów, którzy chcą zrozumieć, jak działają wbudowane technologie ograniczania ryzyka ataków.
W witrynie Azure Portal usługa Azure Advisor to system, który stale skanuje środowisko i tworzy zalecenia. Niektóre z tych zaleceń są przeznaczone do oszczędzania pieniędzy użytkowników, ale inne są przeznaczone do identyfikowania potencjalnie niezabezpieczonych konfiguracji, takich jak otwarcie kontenera magazynu na świecie i brak ochrony przez sieć wirtualną.
Infrastruktura sieci platformy Azure
W środowisku wdrażania lokalnego wiele energii jest przeznaczone do konfigurowania sieci. Konfigurowanie routerów, przełączników i taka praca jest skomplikowana. Sieci umożliwiają niektórym zasobom komunikację z innymi zasobami i zapobieganie dostępowi w niektórych przypadkach. Częstą regułą sieci jest ograniczenie dostępu do środowiska produkcyjnego ze środowiska programistycznego poza szansą, że w połowie opracowany fragment kodu działa awry i usuwa pokos danych.
Obecnie większość zasobów platformy Azure PaaS ma tylko podstawową i permisywną konfigurację sieci. Na przykład każda osoba w Internecie może uzyskać dostęp do usługi aplikacji. Nowe wystąpienia programu SQL Server są zwykle ograniczone, dzięki czemu strony zewnętrzne nie mogą uzyskać do nich dostępu, ale zakresy adresów IP używane przez samą platformę Azure są dozwolone. Dlatego serwer SQL jest chroniony przed zagrożeniami zewnętrznymi, osoba atakująca musi skonfigurować mostek platformy Azure, z którego może uruchamiać ataki na wszystkie wystąpienia SQL na platformie Azure.
Na szczęście większość zasobów platformy Azure można umieścić w usłudze Azure Virtual Network, która umożliwia szczegółową kontrolę dostępu. Podobnie jak w przypadku sieci lokalnych, które tworzą sieci prywatne chronione przed szerszym światem, sieci wirtualne to wyspy prywatnych adresów IP, które znajdują się w sieci platformy Azure.
Rysunek 9–1. Sieć wirtualna na platformie Azure.
W ten sam sposób, w jaki sieci lokalne mają zaporę zarządzającą dostępem do sieci, można ustanowić podobną zaporę na granicy sieci wirtualnej. Domyślnie wszystkie zasoby w sieci wirtualnej nadal mogą komunikować się z Internetem. Jest to tylko połączenia przychodzące, które wymagają jakiejś formy jawnego wyjątku zapory.
Po ustanowieniu sieci zasoby wewnętrzne, takie jak konta magazynu, można skonfigurować tak, aby zezwalać na dostęp tylko przez zasoby, które znajdują się również w sieci wirtualnej. Ta zapora zapewnia dodatkowy poziom zabezpieczeń, jeśli klucze dla tego konta magazynu zostaną ujawnione, osoby atakujące nie będą mogli nawiązać z nim połączenia w celu wykorzystania ujawnionych kluczy. Ten scenariusz jest kolejnym przykładem zasady najniższych uprawnień.
Węzły w klastrze Usługi Azure Kubernetes mogą uczestniczyć w sieci wirtualnej, podobnie jak w przypadku innych zasobów, które są bardziej natywne dla platformy Azure. Ta funkcja jest nazywana interfejsem sieciowym kontenera platformy Azure. W efekcie przydziela podsieć w sieci wirtualnej, na której są przydzielane maszyny wirtualne i obrazy kontenerów.
Kontynuując ścieżkę ilustrowania zasady najniższych uprawnień, a nie każdy zasób w sieci wirtualnej musi komunikować się z każdym innym zasobem. Na przykład w aplikacji, która udostępnia internetowy interfejs API za pośrednictwem konta magazynu i bazy danych SQL, jest mało prawdopodobne, aby baza danych i konto magazynu musiały komunikować się ze sobą. Wszelkie udostępnianie danych między nimi będzie przechodzić przez aplikację internetową. W związku z tym sieciowa grupa zabezpieczeń może służyć do odmowy ruchu między dwiema usługami.
Zasady odmowy komunikacji między zasobami mogą być irytujące do zaimplementowania, szczególnie pochodzące z tła korzystania z platformy Azure bez ograniczeń ruchu. W niektórych innych chmurach pojęcie sieciowych grup zabezpieczeń jest znacznie bardziej powszechne. Na przykład domyślne zasady na platformie AWS polegają na tym, że zasoby nie mogą komunikować się między sobą, dopóki nie będą włączone przez reguły w sieciowej grupie zabezpieczeń. Chociaż jest to wolniejsze do opracowania, bardziej restrykcyjne środowisko zapewnia bezpieczniejsze ustawienie domyślne. Korzystanie z odpowiednich rozwiązań DevOps, zwłaszcza przy użyciu usługi Azure Resource Manager lub narzędzia Terraform do zarządzania uprawnieniami, może ułatwić kontrolowanie reguł.
Sieci wirtualne mogą być również przydatne podczas konfigurowania komunikacji między zasobami lokalnymi i w chmurze. Wirtualna sieć prywatna może służyć do bezproblemowego dołączania tych dwóch sieci. Takie podejście umożliwia uruchamianie sieci wirtualnej bez żadnej bramy w scenariuszach, w których wszyscy użytkownicy znajdują się w lokacji. Istnieje wiele technologii, których można użyć do ustanowienia tej sieci. Najprostszym sposobem jest użycie sieci VPN typu lokacja-lokacja, którą można ustanowić między wieloma routerami i platformą Azure. Ruch jest szyfrowany i tunelowany przez Internet po tym samym koszcie na bajt co każdy inny ruch. W scenariuszach, w których pożądane jest zwiększenie przepustowości lub większej liczby zabezpieczeń, platforma Azure oferuje usługę o nazwie Express Route , która używa obwodu prywatnego między siecią lokalną a platformą Azure. Jest to bardziej kosztowne i trudne do ustanowienia, ale także bezpieczniejsze.
Kontrola dostępu oparta na rolach w celu ograniczenia dostępu do zasobów platformy Azure
Kontrola dostępu oparta na rolach to system, który zapewnia tożsamość aplikacjom działającym na platformie Azure. Aplikacje mogą uzyskiwać dostęp do zasobów przy użyciu tej tożsamości zamiast lub oprócz używania kluczy lub haseł.
Podmioty zabezpieczeń
Pierwszy składnik w kontroli dostępu opartej na rolach jest podmiotem zabezpieczeń. Podmiot zabezpieczeń może być użytkownikiem, grupą, jednostką usługi lub tożsamością zarządzaną.
Rysunek 9–2. Różne typy podmiotów zabezpieczeń.
- Użytkownik — każdy użytkownik, który ma konto w usłudze Azure Active Directory, jest użytkownikiem.
- Grupa — kolekcja użytkowników z usługi Azure Active Directory. Jako członek grupy użytkownik przejmuje role tej grupy oprócz własnych.
- Jednostka usługi — tożsamość zabezpieczeń, w ramach której działają usługi lub aplikacje.
- Tożsamość zarządzana — tożsamość usługi Azure Active Directory zarządzana przez platformę Azure. Tożsamości zarządzane są zwykle używane podczas tworzenia aplikacji w chmurze, które zarządzają poświadczeniami do uwierzytelniania w usługach platformy Azure.
Podmiot zabezpieczeń można zastosować do większości dowolnego zasobu. Ten aspekt oznacza, że istnieje możliwość przypisania podmiotu zabezpieczeń do kontenera uruchomionego w usłudze Azure Kubernetes, co umożliwi mu dostęp do wpisów tajnych przechowywanych w usłudze Key Vault. Funkcja platformy Azure może przyjąć uprawnienie umożliwiające mu komunikację z wystąpieniem usługi Active Directory w celu zweryfikowania JWT dla użytkownika wywołującego. Po włączeniu usług z jednostką usługi ich uprawnienia mogą być zarządzane szczegółowo przy użyciu ról i zakresów.
Role
Podmiot zabezpieczeń może podjąć wiele ról lub, używając bardziej sartorial analogii, nosić wiele kapeluszy. Każda rola definiuje serię uprawnień, takich jak "Odczyt komunikatów z punktu końcowego usługi Azure Service Bus". Efektywny zestaw uprawnień podmiotu zabezpieczeń jest kombinacją wszystkich uprawnień przypisanych do wszystkich ról, które ma podmiot zabezpieczeń. Platforma Azure ma dużą liczbę wbudowanych ról, a użytkownicy mogą definiować własne role.
Rysunek 9–3. Definicje ról RBAC.
Wbudowane na platformie Azure są również wieloma rolami wysokiego poziomu, takimi jak właściciel, współautor, czytelnik i Administracja istrator konta użytkownika. Przy użyciu roli Właściciel podmiot zabezpieczeń może uzyskiwać dostęp do wszystkich zasobów i przypisywać uprawnienia innym osobom. Współautor ma ten sam poziom dostępu do wszystkich zasobów, ale nie może przypisać uprawnień. Czytelnik może wyświetlać tylko istniejące zasoby platformy Azure, a konto użytkownika Administracja istrator może zarządzać dostępem do zasobów platformy Azure.
Bardziej szczegółowe wbudowane role, takie jak współautor strefy DNS, mają prawa ograniczone do pojedynczej usługi. Podmioty zabezpieczeń mogą przyjmować dowolną liczbę ról.
Zakresy
Role można stosować do ograniczonego zestawu zasobów na platformie Azure. Na przykład zastosowanie zakresu do poprzedniego przykładu odczytu z kolejki usługi Service Bus umożliwia zawężenie uprawnienia do jednej kolejki: "Odczyt komunikatów z punktu końcowego blah.servicebus.windows.net/queue1usługi Azure Service Bus"
Zakres może być tak wąski jak pojedynczy zasób lub można go zastosować do całej grupy zasobów, subskrypcji, a nawet grupy zarządzania.
Podczas testowania, czy podmiot zabezpieczeń ma pewne uprawnienia, uwzględniana jest kombinacja roli i zakresu. Ta kombinacja zapewnia zaawansowany mechanizm autoryzacji.
Zablokuj
Wcześniej tylko reguły zezwalania były dozwolone dla kontroli dostępu opartej na rolach. To zachowanie utrudniało kompilowanie niektórych zakresów. Na przykład zezwolenie podmiotowi zabezpieczeń na dostęp do wszystkich kont magazynu z wyjątkiem jednego wymaganego udzielenia jawnego uprawnienia do potencjalnie niekończącej się listy kont magazynu. Za każdym razem, gdy zostanie utworzone nowe konto magazynu, konieczne będzie dodanie go do tej listy kont. To dodało obciążenie związane z zarządzaniem, które z pewnością nie było pożądane.
Reguły odmowy mają pierwszeństwo przed regułami zezwalania. Teraz reprezentując ten sam zakres "zezwalaj na wszystkie, ale jeden" może być reprezentowany jako dwie reguły "zezwalaj na wszystko" i "odmówić tego jednego konkretnego". Reguły odmowy nie tylko ułatwiają zarządzanie, ale umożliwiają korzystanie z zasobów, które są bardzo bezpieczne, odmawiając dostępu wszystkim.
Sprawdzanie dostępu
Jak można sobie wyobrazić, posiadanie dużej liczby ról i zakresów może sprawić, że ustalenie skutecznego uprawnienia jednostki usługi jest dość trudne. Piętrzące reguły odmowy na tym, służy tylko do zwiększenia złożoności. Na szczęście istnieje kalkulator uprawnień, który może wyświetlać obowiązujące uprawnienia dla dowolnej jednostki usługi. Zazwyczaj znajduje się on na karcie Zarządzanie dostępem i tożsamościami w portalu, jak pokazano na rysunku 9–3.
Rysunek 9–4. Kalkulator uprawnień dla usługi app Service.
Zabezpieczanie wpisów tajnych
Hasła i certyfikaty są typowym wektorem ataku dla osób atakujących. Sprzęt łamania haseł może wykonać atak siłowy i spróbować odgadnąć miliardy haseł na sekundę. Dlatego ważne jest, aby hasła używane do uzyskiwania dostępu do zasobów były silne, z dużą ilością znaków. Te hasła są dokładnie tego rodzaju hasłami, które są prawie niemożliwe do zapamiętania. Na szczęście hasła na platformie Azure nie muszą być znane przez żadnego człowieka.
Wielu ekspertów ds. zabezpieczeń sugeruje , że użycie menedżera haseł w celu zachowania własnych haseł jest najlepszym rozwiązaniem. Scentralizowanie haseł w jednej lokalizacji umożliwia również używanie wysoce złożonych haseł i zapewnienie ich unikatowości dla każdego konta. Ten sam system istnieje na platformie Azure: centralny magazyn dla wpisów tajnych.
Azure Key Vault
Usługa Azure Key Vault zapewnia scentralizowaną lokalizację do przechowywania haseł dla takich elementów jak bazy danych, klucze interfejsu API i certyfikaty. Po wprowadzeniu wpisu tajnego do magazynu nigdy nie jest wyświetlany, a polecenia wyodrębniania i wyświetlania go celowo są skomplikowane. Informacje w bezpiecznym miejscu są chronione przy użyciu szyfrowania oprogramowania lub zweryfikowanych sprzętowych modułów zabezpieczeń fiPS 140-2 poziom 2.
Dostęp do magazynu kluczy jest udostępniany za pośrednictwem RBACs, co oznacza, że nie tylko żaden użytkownik może uzyskać dostęp do informacji w magazynie. Załóżmy, że aplikacja internetowa chce uzyskać dostęp do parametry połączenia bazy danych przechowywanej w usłudze Azure Key Vault. Aby uzyskać dostęp, aplikacje muszą być uruchamiane przy użyciu jednostki usługi. W ramach tej roli mogą odczytywać wpisy tajne z bezpiecznego. Istnieje wiele różnych ustawień zabezpieczeń, które mogą dodatkowo ograniczyć dostęp aplikacji do magazynu, dzięki czemu nie może aktualizować wpisów tajnych, ale tylko je odczytywać.
Dostęp do magazynu kluczy można monitorować, aby upewnić się, że tylko oczekiwane aplikacje uzyskują dostęp do magazynu. Dzienniki można zintegrować z usługą Azure Monitor, odblokowując możliwość konfigurowania alertów w przypadku napotkania nieoczekiwanych warunków.
Kubernetes
W ramach platformy Kubernetes istnieje podobna usługa do obsługi małych informacji tajnych. Wpisy tajne platformy Kubernetes można ustawić za pomocą typowego kubectl pliku wykonywalnego.
Tworzenie wpisu tajnego jest tak proste, jak znalezienie wersji base64 wartości, które mają być przechowywane:
echo -n 'admin' | base64
YWRtaW4=
echo -n '1f2d1e2e67df' | base64
MWYyZDFlMmU2N2Rm
Następnie dodaj go do pliku wpisów tajnych o nazwie secret.yml na przykład podobny do następującego przykładu:
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
password: MWYyZDFlMmU2N2Rm
Na koniec ten plik można załadować do platformy Kubernetes, uruchamiając następujące polecenie:
kubectl apply -f ./secret.yaml
Te wpisy tajne mogą być następnie instalowane w woluminach lub udostępniane procesom kontenera za pomocą zmiennych środowiskowych. Podejście aplikacji dwunastoskładnikowej do tworzenia aplikacji sugeruje użycie najniższego wspólnego mianownika do przesyłania ustawień do aplikacji. Zmienne środowiskowe są najniższym wspólnym mianownikiem, ponieważ są obsługiwane niezależnie od systemu operacyjnego lub aplikacji.
Alternatywą dla użycia wbudowanych wpisów tajnych platformy Kubernetes jest uzyskiwanie dostępu do wpisów tajnych w usłudze Azure Key Vault z poziomu platformy Kubernetes. Najprostszym sposobem wykonania tej czynności jest przypisanie roli RBAC do kontenera, który chce załadować wpisy tajne. Następnie aplikacja może uzyskiwać dostęp do wpisów tajnych za pomocą interfejsów API usługi Azure Key Vault. Jednak takie podejście wymaga modyfikacji kodu i nie jest zgodne ze wzorcem używania zmiennych środowiskowych. Zamiast tego można wstrzyknąć wartości do kontenera. Takie podejście jest faktycznie bezpieczniejsze niż bezpośrednie używanie wpisów tajnych platformy Kubernetes, ponieważ są one dostępne dla użytkowników w klastrze.
Szyfrowanie podczas przesyłania i magazynowania
Zapewnienie bezpieczeństwa danych jest ważne zarówno na dysku, jak i podczas przesyłania danych między różnymi usługami. Najskuteczniejszym sposobem na uniemożliwienie wycieku danych jest zaszyfrowanie ich w formacie, który nie może być łatwo odczytywany przez inne osoby. pomoc techniczna platformy Azure szeroką gamę opcji szyfrowania.
W trakcie przesyłania
Istnieje kilka sposobów szyfrowania ruchu w sieci na platformie Azure. Dostęp do usług platformy Azure jest zwykle wykonywany za pośrednictwem połączeń korzystających z protokołu Transport Layer Security (TLS). Na przykład wszystkie połączenia z interfejsami API platformy Azure wymagają połączeń TLS. Podobnie połączenia z punktami końcowymi w usłudze Azure Storage mogą być ograniczone do pracy tylko za pośrednictwem połączeń szyfrowanych przy użyciu protokołu TLS.
Protokół TLS jest skomplikowanym protokołem i po prostu wiedząc, że połączenie korzysta z protokołu TLS, nie jest wystarczające, aby zapewnić bezpieczeństwo. Na przykład protokół TLS 1.0 jest chronicznie niezabezpieczony, a protokół TLS 1.1 nie jest znacznie lepszy. Nawet w wersjach protokołu TLS istnieją różne ustawienia, które mogą ułatwić odszyfrowywanie połączeń. Najlepszym sposobem działania jest sprawdzenie i sprawdzenie, czy połączenie serwera korzysta z aktualnych i dobrze skonfigurowanych protokołów.
Tę kontrolę można sprawdzić za pomocą usługi zewnętrznej, takiej jak test serwera SSL laboratoriów SSL. Przebieg testu dla typowego punktu końcowego platformy Azure, w tym przypadku punktu końcowego usługi Service Bus, daje niemal doskonały wynik A.
Nawet usługi, takie jak Bazy danych Azure SQL Database, używają szyfrowania TLS, aby przechowywać dane ukryte. Interesującą częścią szyfrowania danych przesyłanych przy użyciu protokołu TLS jest to, że nie jest możliwe, nawet dla firmy Microsoft, nasłuchiwanie w połączeniu między komputerami z uruchomionym protokołem TLS. Powinno to zapewnić komfort firmom, które obawiają się, że ich dane mogą być narażone na ryzyko ze strony firmy Microsoft właściwej, a nawet ze strony aktora stanu z większą ilością zasobów niż standardowy atakujący.
Rysunek 9–5. Raport laboratoriów SSL przedstawiający ocenę wartości A dla punktu końcowego usługi Service Bus.
Chociaż ten poziom szyfrowania nie będzie wystarczający przez cały czas, powinno to inspirować pewność, że połączenia TLS platformy Azure są dość bezpieczne. Platforma Azure będzie nadal rozwijać swoje standardy zabezpieczeń w miarę ulepszania szyfrowania. Miło jest wiedzieć, że podczas ulepszania platformy Azure ktoś obserwuje standardy zabezpieczeń i aktualizuje platformę Azure.
Magazynowanie
W każdej aplikacji istnieje wiele miejsc, w których dane znajdują się na dysku. Sam kod aplikacji jest ładowany z pewnego mechanizmu magazynu. Większość aplikacji używa również jakiejś bazy danych, takiej jak SQL Server, Cosmos DB, a nawet niezwykle wydajna cenowo usługa Table Storage. Wszystkie bazy danych używają silnie zaszyfrowanego magazynu, aby upewnić się, że nikt inny niż aplikacje z odpowiednimi uprawnieniami może odczytywać dane. Nawet operatorzy systemu nie mogą odczytać danych, które zostały zaszyfrowane. Dzięki temu klienci mogą mieć pewność, że ich tajne informacje pozostają tajne.
Storage
Podstawą dużej części platformy Azure jest aparat usługi Azure Storage. Dyski maszyny wirtualnej są instalowane na platformie Azure Storage. Usługa Azure Kubernetes Service działa na maszynach wirtualnych, które same są hostowane w usłudze Azure Storage. Nawet technologie bezserwerowe, takie jak Aplikacje usługi Azure Functions i Azure Container Instances, zabraknie dysku będącego częścią usługi Azure Storage.
Jeśli usługa Azure Storage jest dobrze zaszyfrowana, zapewnia podstawę dla większości innych elementów do szyfrowania. Usługa Azure Storage jest szyfrowana przy użyciu 140-2 zgodnej ze standardem FIPS 256-bitowej AES. Jest to dobrze uznana technologia szyfrowania, która była przedmiotem szeroko zakrojonej kontroli akademickiej w ciągu ostatnich 20 lub tak lat. Obecnie nie ma znanego praktycznego ataku, który umożliwiłby komuś bez znajomości klucza odczytywanie danych zaszyfrowanych przez usługę AES.
Domyślnie klucze używane do szyfrowania usługi Azure Storage są zarządzane przez firmę Microsoft. Istnieje szeroka ochrona, aby zapobiec złośliwemu dostępowi do tych kluczy. Jednak użytkownicy z określonymi wymaganiami dotyczącymi szyfrowania mogą również udostępniać własne klucze magazynu zarządzane w usłudze Azure Key Vault. Klucze te można odwołać w dowolnym momencie, co skutecznie renderuje zawartość konta magazynu przy użyciu ich niedostępności.
Maszyny wirtualne korzystają z zaszyfrowanego magazynu, ale można udostępnić inną warstwę szyfrowania przy użyciu technologii takich jak BitLocker w systemie Windows lub DM-Crypt w systemie Linux. Te technologie oznaczają, że nawet jeśli obraz dysku wyciekł z magazynu, pozostanie prawie niemożliwe do odczytania.
Azure SQL
Bazy danych hostowane w usłudze Azure SQL używają technologii o nazwie Transparent Data Encryption (TDE), aby zapewnić, że dane pozostają zaszyfrowane. Jest ona domyślnie włączona dla wszystkich nowo utworzonych baz danych SQL, ale musi być włączona ręcznie dla starszych baz danych. Funkcja TDE wykonuje szyfrowanie i odszyfrowywanie w czasie rzeczywistym nie tylko bazy danych, ale także kopie zapasowe i dzienniki transakcji.
Parametry szyfrowania są przechowywane w master bazie danych i podczas uruchamiania są odczytywane do pamięci dla pozostałych operacji. Oznacza to, że master baza danych musi pozostać niezaszyfrowana. Rzeczywisty klucz jest zarządzany przez firmę Microsoft. Jednak użytkownicy z dokładnymi wymaganiami dotyczącymi zabezpieczeń mogą podać własny klucz w usłudze Key Vault w taki sam sposób, jak w przypadku usługi Azure Storage. Usługa Key Vault zapewnia takie usługi jak rotacja kluczy i odwoływanie.
Część "Przezroczysta" TDS pochodzi z faktu, że nie są wymagane zmiany klienta do korzystania z zaszyfrowanej bazy danych. Chociaż takie podejście zapewnia dobre zabezpieczenia, wyciek hasła bazy danych wystarczy, aby użytkownicy mogli odszyfrować dane. Istnieje inne podejście, które szyfruje poszczególne kolumny lub tabele w bazie danych. Funkcja Always Encrypted gwarantuje, że w żadnym momencie zaszyfrowane dane nie są wyświetlane w postaci zwykłego tekstu wewnątrz bazy danych.
Skonfigurowanie tej warstwy szyfrowania wymaga uruchomienia kreatora w programie SQL Server Management Studio w celu wybrania rodzaju szyfrowania i lokalizacji w usłudze Key Vault do przechowywania skojarzonych kluczy.
Rysunek 9–6. Wybieranie kolumn w tabeli do szyfrowania przy użyciu funkcji Always Encrypted.
Aplikacje klienckie, które odczytują informacje z tych zaszyfrowanych kolumn, muszą mieć specjalne uprawnienia do odczytywania zaszyfrowanych danych. ciągi Połączenie ion muszą zostać zaktualizowane za pomocą Column Encryption Setting=Enabled polecenia i należy pobrać poświadczenia klienta z usługi Key Vault. Klient programu SQL Server musi być następnie przygotowany przy użyciu kluczy szyfrowania kolumny. Po wykonaniu tych czynności pozostałe akcje używają standardowych interfejsów do klienta SQL. Oznacza to, że narzędzia takie jak Dapper i Entity Framework, które są oparte na kliencie SQL, będą nadal działać bez zmian. Funkcja Always Encrypted może nie być jeszcze dostępna dla każdego sterownika programu SQL Server w każdym języku.
Kombinacja funkcji TDE i Always Encrypted, która może być używana z kluczami specyficznymi dla klienta, zapewnia, że są obsługiwane nawet najbardziej dokładne wymagania dotyczące szyfrowania.
Cosmos DB
Cosmos DB to najnowsza baza danych dostarczana przez firmę Microsoft na platformie Azure. Został zbudowany od podstaw z myślą o zabezpieczeniach i kryptografii. Szyfrowanie AES-256bit jest standardem dla wszystkich baz danych usługi Cosmos DB i nie można ich wyłączyć. W połączeniu z wymaganiami protokołu TLS 1.2 dotyczącymi komunikacji całe rozwiązanie magazynu jest szyfrowane.
Rysunek 9–7. Przepływ szyfrowania danych w usłudze Cosmos DB.
Chociaż usługa Cosmos DB nie zapewnia dostarczania kluczy szyfrowania klienta, zespół wykonał znaczącą pracę, aby upewnić się, że pozostanie ona zgodna z normą PCI-DSS bez tego. Usługa Cosmos DB nie obsługuje również żadnego rodzaju szyfrowania pojedynczej kolumny podobnego do funkcji Always Encrypted usługi Azure SQL.
Utrzymywanie bezpieczeństwa
Platforma Azure ma wszystkie narzędzia niezbędne do wydania wysoce bezpiecznego produktu. Jednak łańcuch jest tak silny, jak jego najsłabsze ogniwo. Jeśli aplikacje wdrożone na platformie Azure nie są opracowywane z odpowiednim nastawieniem na zabezpieczenia i dobrymi inspekcjami zabezpieczeń, stają się słabym linkiem w łańcuchu. Istnieje wiele doskonałych narzędzi do analizy statycznej, bibliotek szyfrowania i praktyk zabezpieczeń, które mogą służyć do zapewnienia, że oprogramowanie zainstalowane na platformie Azure jest tak bezpieczne, jak sama platforma Azure. Przykłady obejmują narzędzia do analizy statycznej, biblioteki szyfrowania i praktyki zabezpieczeń.
