Zabezpieczenia platformy Azure dla aplikacji natywnych dla chmury

Wskazówka

Ta zawartość jest fragmentem e-książki, Architektura Cloud Native .NET Applications for Azure, dostępnej w .NET Docs lub jako bezpłatny plik PDF do pobrania, który można czytać offline.

Pobierz plik PDF

Aplikacje natywne dla chmury mogą być łatwiejsze i trudniejsze do zabezpieczenia niż tradycyjne aplikacje. Na minusie, trzeba zabezpieczyć drobniejsze aplikacje i poświęcić więcej energii na rozwój infrastruktury 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 podejście muszą być częścią każdego kroku procesu tworzenia 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?
• Kto powinien 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 jakiś podmiot na poziomie państwowym mógłby wprowadzić 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 pozwalające na Id przyrostowe ataki (zastępowanie Id=2Id=3 w adresie URL) lub wstrzyknięcie kodu SQL, są bardziej atrakcyjne do tworzenia mechanizmów ochronnych. Środki zaradcze wobec tych zagrożeń są dość rozsądne, aby zapobiegać kłopotliwym lukom w zabezpieczeniach, które mogą zepsuć reputację firmy.

Zasada najniższych 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 sejfu jest rzadką czynnością. Tak więc przeciętny kasjer nie może samodzielnie otworzyć sejfu. 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 przestrzegania zasady najmniejszych uprawnień. Można to znaleźć podczas konfigurowania zapór, grup zabezpieczeń sieciowych, ról i zakresów dostępu 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 wykrywane są obszerne luki w zabezpieczeniach, które muszą być załatane. 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. Im bardziej kuszący staje się cel, tym bardziej prawdopodobne, że zewnętrzni aktorzy będą próbować go wykorzystać, a na świecie jest niewiele celów bardziej kuszących niż platforma Azure.

Nadzorowanie

Jeśli osoba atakująca spróbuje przeniknąć przez aplikację, powinno zostać wyświetlone ostrzeżenie. Często można wykryć ataki, analizując logi usług. Ataki pozostawiają charakterystyczne ślady, 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 w obrębie systemu logowania może wykrywać dziwne wzorce, które odbiegają od typowego schematu 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 budowania

Jednym z miejsc, w których zabezpieczenia są często pomijane, jest proces kompilacji. Nie tylko należy uruchamiać testy zabezpieczeń budowy, takie jak skanowanie w poszukiwaniu niezabezpieczonego kodu lub zatwierdzonych poświadczeń, ale sama budowa powinna być bezpieczna. Jeśli serwer kompilacji zostanie naruszony, staje się idealnym wektorem 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 znajdują się na serwerze kompilacji. Wykorzystany kod przejdzie do środowiska produkcyjnego, w którym może zbierać hasła. Prawdopodobnie nie istnieje dziennik kontroli zmian procesu kompilacji, lub przynajmniej nikt nie monitoruje jego audytu.

Ten scenariusz jest doskonałym przykładem celu o pozornie niskiej wartości, który może być użyty do włamania do systemu. 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, na przykład przekroczenia granic tablic. Praca jest aktywnie wykonywana w celu naprawienia otworów zabezpieczających w miarę ich odnajdowania. ** Istnieje nawet program nagród za błędy, który płaci naukowcom za znalezienie problemów w frameworku i zgłoszenie ich zamiast je wykorzystywać.

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, czy nikt nie wprowadził przypadkowo uwierzytelnień.

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ń mają na celu oszczędzanie pieniędzy użytkowników, inne zaś identyfikację potencjalnie niezabezpieczonych konfiguracji, takich jak otwarcie kontenera magazynu na dostęp publiczny i niechroniony 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 tym podobnych to skomplikowana praca. 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 na wypadek, gdyby w połowie opracowany fragment kodu zachował się nieprzewidywalnie i usunął dużą ilość 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. Tak więc, chociaż serwer SQL jest chroniony przed zagrożeniami zewnętrznymi, atakujący musi skonfigurować przyczółek platformy Azure, z którego może przeprowadzać ataki na wszystkie instancje 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 utworzeniu sieci wewnętrzne zasoby, takie jak konta magazynowe, można skonfigurować w taki sposób, aby umożliwić dostęp tylko zasobom, które również znajdują się w Wirtualnej Sieci. Ten firewall zapewnia dodatkowy poziom zabezpieczeń. W przypadku, gdy klucze dla tego konta magazynu zostaną ujawnione, osoby atakujące nie będą mogły 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 rezultacie przydzielana jest podsieć w sieci wirtualnej, na której umieszczane są maszyny wirtualne i obrazy kontenerów.

Kontynuując ścieżkę ilustrowania zasady najmniejszego przywileju, nie każdy element w sieci wirtualnej musi komunikować się z każdym innym elementem. Na przykład w aplikacji, która udostępnia webowe API za pośrednictwem konta przechowywania i bazy danych SQL, jest mało prawdopodobne, aby baza danych i konto przechowywania 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 (RBAC) 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ł.

Główne elementy bezpieczeństwa

Pierwszy składnik w RBAC to główny element bezpieczeństwa. 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.
• Główna usługa - tożsamość bezpieczeństwa, 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 jej komunikację z wystąpieniem usługi Active Directory w celu zweryfikowania JWT dla użytkownika wywołującego. Po włączeniu usług z principalem usługi można zarządzać ich uprawnieniami szczegółowo przy użyciu ról i zakresów.

Role

Podmiot zabezpieczeń może przyjąć wiele ról lub, używając bardziej krawieckiej 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.

W Azure wbudowane są również szereg ról wysokiego poziomu, takich jak Właściciel, Współautor, Czytelnik i Administrator 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 administrator konta użytkownika 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.

Odmów

Wcześniej tylko zezwalające reguły były dozwolone dla kontroli dostępu na podstawie ról. To zachowanie utrudniało budowanie niektórych zakresów. Na przykład, zezwolenie podmiotowi zabezpieczeń na dostęp do wszystkich kont magazynu, z wyjątkiem jednego, wymagało udzielenia wyraźnego zezwolenia 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. Obecnie, aby reprezentować ten sam zakres "zezwalaj na wszystko oprócz jednego", można to przedstawić jako dwie reguły: "zezwalaj na wszystko" i "zablokować ten jeden konkretny". 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ętrzenie dodatkowych reguł odmowy tylko zwiększa złożoność. Na szczęście istnieje kalkulator uprawnień , który może wyświetlać obowiązujące uprawnienia dla dowolnej jednostki usługi. Zazwyczaj można go znaleźć na karcie IAM w portalu, jak pokazano na rysunku 9-3.

Rysunek 9–4. Kalkulator uprawnień dla usługi aplikacji.

Zabezpieczanie tajemnic

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ł do przechowywania 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 tajemnic.

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 tym, jak tajemnica zostanie wprowadzona do skarbca, nigdy nie jest wyświetlana ponownie, a polecenia dotyczące jej wyodrębniania i wyświetlania są celowo 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 RBAC, co oznacza, że tylko niektórzy użytkownicy mogą uzyskać dostęp do informacji w magazynie. Załóżmy, że aplikacja internetowa chce uzyskać dostęp do parametrów połączenia bazy danych przechowywanych w usłudze Azure Key Vault. Aby uzyskać dostęp, aplikacje muszą być uruchamiane przy użyciu reprezentanta usługi. W ramach tej roli mogą odczytywać tajemnice z sejfu. Istnieje wiele różnych ustawień zabezpieczeń, które mogą dodatkowo ograniczyć dostęp aplikacji do magazynu, aby nie mogła ona aktualizować tajemnic, a jedynie je odczytywać.

Dostęp do magazynu kluczy można śledzić, aby upewnić się, że tylko oczekiwane aplikacje uzyskują do niego dostęp. 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. Sekrety Kubernetes można ustawić przy użyciu typowego pliku wykonywalnego kubectl.

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 tajemnic o nazwie secret.yml, na przykład podobnego do poniższego.

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 tajne dane mogą być następnie umieszczane w woluminach lub udostępniane procesom kontenera za pomocą zmiennych środowiskowych. Podejście Twelve-factor app 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 tajemnic platformy Kubernetes jest uzyskiwanie dostępu do tajemnic w Azure Key Vault z poziomu platformy Kubernetes. Najprostszym sposobem wykonania tej czynności jest przypisanie roli RBAC do kontenera, który chce załadować sekrety. Następnie aplikacja może uzyskiwać dostęp do tajemnic 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 sekretów Kubernetes, ponieważ są one dostępne dla użytkowników w klastrze.

Szyfrowanie podczas przesyłania i w spoczynku

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. Platforma Azure obsługuje szeroką gamę opcji szyfrowania.

W trakcie transportu

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, czy połączenie z serwerem używa dobrze skonfigurowanych protokołów, takich jak up-to-date.

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 z laboratoriów SSL przedstawiający ocenę A dla punktu końcowego usługi magistrali.

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.

W stanie spoczynku

W każdej aplikacji istnieje wiele miejsc, w których dane znajdują się na dysku. Sam kod aplikacji jest ładowany z jakiegoś mechanizmu przechowywania. 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 te bazy danych używają silnie zaszyfrowanego przechowywania danych, aby upewnić się, że nikt oprócz aplikacji z odpowiednimi uprawnieniami nie może odczytać Twoich danych. 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.

Przechowywanie danych

Podstawą dużej części platformy Azure jest silnik 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 Azure Functions i Azure Container Instances, korzystają z 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 zgodnego ze standardem FIPS 140-2256-bitowego 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ż dostarczyć własne klucze do magazynowania, które są zarządzane w usłudze Azure Key Vault. Klucze te można odwołać w dowolnym momencie, co skutecznie uczyni zawartość konta Storage korzystającego z nich niedostępną.

Maszyny wirtualne używają 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łby z magazynu, jego odczytanie pozostanie prawie niemożliwe.

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 polega na tym, że do korzystania z zaszyfrowanej bazy danych nie są potrzebne zmiany po stronie klienta." 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. Parametry połączenia należy zaktualizować za pomocą Column Encryption Setting=Enabled polecenia , a poświadczenia klienta muszą zostać pobrane z usługi Key Vault. Klient programu SQL Server musi być następnie skonfigurowany przy użyciu kluczy szyfrowania kolumn. 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 - baza danych

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ć. Połączone z wymaganiem wykorzystania TLS 1.2 do komunikacji, całe rozwiązanie magazynowania danych 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ół dokonał znaczących wysiłków, aby zapewnić, że pozostanie zgodna z wymaganiami PCI-DSS, pomimo braku tej funkcji. 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 i biblioteki szyfrowania.

PoprzedniNastępny