Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Azure pomaga uruchamiać aplikacje i maszyny wirtualne (VM) na współdzielonej infrastrukturze fizycznej. Jedną z głównych korzyści ekonomicznych uruchamiania aplikacji w środowisku chmurowym jest możliwość rozdzielenia kosztów współdzielonych zasobów pomiędzy wielu dzierżawców. Ten model wielodzierżawności zwiększa efektywność dzięki multipleksowaniu zasobów między wieloma dzierżawcami przy niskim koszcie. Jednak wprowadza to także ryzyko współdzielenia fizycznych serwerów i innych zasobów infrastrukturalnych do uruchamiania wrażliwych aplikacji i maszyn wirtualnych, które mogą należeć do arbitralnego i potencjalnie złośliwego użytkownika.
Ten artykuł opisuje, jak Azure zapewnia izolację zarówno przed złośliwymi, jak i niezłośliwymi użytkownikami. Służy jako przewodnik po projektowaniu rozwiązań chmurowych, oferując architektom kilka opcji izolacji.
Izolacja na poziomie dzierżawy
Jedną z głównych zalet chmury obliczeniowej jest koncepcja wspólnej, wspólnej infrastruktury pomiędzy wieloma najemcami jednocześnie, co prowadzi do efektów skali. Ta koncepcja jest nazywana wielodostępnością. Microsoft nieustannie pracuje, aby zapewnić, że wielodzierżawcowa architektura Microsoft Azure wspiera standardy bezpieczeństwa, poufności, prywatności, integralności i dostępności.
W środowisku pracy z obsługą chmury dzierżawca jest klientem lub organizacją, która jest właścicielem i zarządza określonym wystąpieniem tej usługi chmurowej. W platformie tożsamości dostarczanej przez Microsoft Azure, tenant to dedykowana instancja Microsoft Entra ID, którą Twoja organizacja otrzymuje i posiada po rejestracji w usłudze chmurowej Microsoft.
Każdy katalog Microsoft Entra jest odrębny i oddzielony od innych katalogów firmy Microsoft Entra. Podobnie jak budynek biurowy firmy, katalog Microsoft Entra jest bezpiecznym zasobem do użytku wyłącznie przez Twoją organizację. Architektura Microsoft Entra izoluje dane klientów oraz informacje o ich tożsamości od mieszania. Ta izolacja oznacza, że użytkownicy i administratorzy jednego katalogu Microsoft Entra nie mogą przypadkowo lub złośliwie uzyskać dostępu do danych w innym katalogu.
dzierżawa Azure
Dzierżawa platformy Azure (subskrypcja platformy Azure) oznacza relację klienta z rozliczeniami oraz unikalnego dzierżawcę w Microsoft Entra ID. Microsoft Entra ID oraz jego kontrola dostępu oparta na rolach Azure zapewniają izolację na poziomie dzierżawcy w Microsoft Azure. Każda subskrypcja Azure jest skojarzona z jednym katalogiem Microsoft Entra.
Użytkownicy, grupy i aplikacje z tego katalogu mogą zarządzać zasobami w subskrypcji Azure. Przypisz te prawa dostępu za pomocą portalu Azure, narzędzi wiersza poleceń Azure oraz API zarządzania Azure. Granice zabezpieczeń logicznie izolują dzierżawę Microsoft Entra, aby żaden klient nie mógł uzyskać dostępu lub naruszyć współdzierżawców, złośliwie lub przypadkowo. Microsoft Entra ID działa na fizycznych serwerach izolowanych w segregowanym segmencie sieci, gdzie filtrowanie pakietów na poziomie hosta i Windows Firewall blokują niechciane połączenia i ruch sieciowy.
Access do danych w Microsoft Entra ID wymaga uwierzytelniania użytkownika za pośrednictwem usługi tokenu zabezpieczającego (STS). System autoryzacji wykorzystuje informacje o istnieniu użytkownika, stanie włączonym i roli, aby ustalić, czy użytkownik ma autoryzowany dostęp do docelowego tenanta w tej sesji.
Dzierżawy są odrębnymi kontenerami i nie ma relacji między tymi kontenerami.
Nie istnieje możliwość uzyskania dostępu między dzierżawami, chyba że administrator dzierżawy udziela go poprzez federację lub zakładanie kont użytkowników z innych dzierżaw.
Microsoft ogranicza fizyczny dostęp do serwerów tworzących usługę Microsoft Entra oraz bezpośredni dostęp do systemów zaplecza Microsoft Entra ID.
Użytkownicy Microsoft Entra nie mają dostępu do fizycznych zasobów ani lokalizacji, więc nie mogą obejść logicznych kontroli polityki Azure RBAC opisanych poniżej.
W przypadku potrzeb diagnostycznych i konserwacyjnych należy użyć modelu operacyjnego, który korzysta z systemu podnoszenia uprawnień w trybie just-in-time. Microsoft Entra Privileged Identity Management (PIM) wprowadza koncepcję uprawnionego administratora. Uprawnieni administratorzy to użytkownicy, którzy od czasu do czasu potrzebują dostępu uprzywilejowanego, ale nie codziennie. Rola jest nieaktywna, dopóki użytkownik nie potrzebuje dostępu. Następnie użytkownik kończy proces aktywacji i staje się aktywnym administratorem na określony czas.
Microsoft Entra ID hostuje każdego dzierżawcę we własnym chronionym kontenerze, z zasadami i uprawnieniami dotyczącymi kontenera będącymi wyłącznie własnością i pod zarządem dzierżawcy.
Koncepcja kontenerów dzierżawców jest głęboko zakorzeniona w usłudze katalogowej, obejmując wszystkie warstwy – od portali aż po trwałe magazynowanie.
Nawet jeśli metadane z wielu dzierżaw Microsoft Entra są przechowywane na tym samym dysku fizycznym, nie ma między kontenerami innych relacji niż te zdefiniowane przez usługę katalogową, która z kolei jest określana przez administratora dzierżawy.
Kontrola dostępu oparta na rolach w Azure (Azure RBAC)
Kontrola dostępu oparta na rolach Azure (Azure RBAC) pozwala dzielić się kilkoma komponentami dostępnymi w ramach subskrypcji Azure, zapewniając precyzyjne zarządzanie dostępem dla Azure. Azure RBAC umożliwia segregowanie obowiązków w organizacji i udzielanie dostępu na podstawie tego, co użytkownicy potrzebują do wykonywania swoich zadań. Zamiast przydzielać wszystkim nieograniczone uprawnienia w subskrypcji lub zasobach Azure, można zezwolić tylko na określone akcje.
Azure kontrola dostępu oparta na rolach ma trzy podstawowe role, które mają zastosowanie do wszystkich typów zasobów:
Owner ma pełny dostęp do wszystkich zasobów, w tym prawo do delegowania dostępu innym osobom.
Contributor może tworzyć i zarządzać wszystkimi typami zasobów Azure, ale nie może udzielać dostępu innym osobom.
Reader może wyświetlać istniejące zasoby Azure.
Pozostałe role Azure w systemie Azure umożliwiają zarządzanie określonymi zasobami Azure. Na przykład rola Współautor maszyny wirtualnej umożliwia użytkownikowi tworzenie virtual machines i zarządzanie nimi. Nie daje im access do Azure Virtual Network ani podsieci, z którą łączy się maszyna wirtualna.
Azure wbudowane role wyświetlić listę ról dostępnych w Azure. Określają one operacje i zakres, które każda wbudowana rola przyznaje użytkownikom. Jeśli chcesz zdefiniować własne role, aby uzyskać jeszcze większą kontrolę, zobacz, jak utworzyć dowolne role w usłudze Azure RBAC.
Niektóre inne możliwości Microsoft Entra ID obejmują:
Microsoft Entra ID umożliwia logowanie jednokrotne do aplikacji SaaS, niezależnie od tego, gdzie są hostowane. Niektóre aplikacje są sfederowane z Microsoft Entra ID, a inne używają logowania jednokrotnego przy użyciu hasła. Aplikacje federacyjne mogą również obsługiwać aprowizowanie użytkowników i przechowywanie haseł.
Microsoft Entra ID zapewnia tożsamość jako usługę za pośrednictwem federacji przy użyciu Active Directory Federation Services, synchronizacji i replikacji z katalogami lokalnymi.
Uwierzytelnianie wieloskładnikowe firmy Microsoft wymaga, aby użytkownicy weryfikowali logowania przy użyciu aplikacji mobilnej, rozmowy telefonicznej lub wiadomości SMS. Używaj go z Microsoft Entra ID, aby zabezpieczyć zasoby lokalne, korzystając z Multi-Factor Authentication Server, a także z niestandardowymi aplikacjami i katalogami za pomocą SDK.
Microsoft Entra Domain Services pomaga łączyć maszyny wirtualne Azure z domeną Active Directory bez konieczności wdrażania kontrolerów domeny. Możesz zalogować się do tych maszyn wirtualnych przy użyciu poświadczeń firmowych Active Directory i administrować maszynami wirtualnymi przyłączonymi do domeny przy użyciu zasad grupy, w celu wymuszenia podstaw zabezpieczeń na wszystkich maszynach wirtualnych Azure.
Tożsamość zewnętrzna Microsoft Entra to wysoko dostępna usługa zarządzania globalną tożsamością dla aplikacji skierowanych do konsumentów, która skaluje się do setek milionów tożsamości. Możesz go integrować na platformach mobilnych i internetowych. Twoi konsumenci mogą logować się do wszystkich Twoich aplikacji za pomocą dostosowanych przeżyć, używając istniejących kont społecznościowych lub tworząc nowe poświadczenia.
Izolacja od administratorów firmy Microsoft i usuwanie danych
Microsoft podejmuje surowe środki w celu ochrony twoich danych przed nieodpowiednim dostępem lub wykorzystaniem przez nieautoryzowane osoby. Warunki Online Services oferują zobowiązania umowne, które regulują dostęp do danych i wspierają te procesy operacyjne i mechanizmy kontroli.
- Inżynierowie firmy Microsoft nie mają domyślnego dostępu do twoich danych w chmurze. Zamiast tego otrzymują dostęp, pod nadzorem kierownictwa, tylko wtedy, gdy jest to konieczne. Ten dostęp jest dokładnie kontrolowany i rejestrowany oraz cofany, gdy nie jest już potrzebny.
- Firma Microsoft może zatrudnić inne firmy do świadczenia ograniczonych usług w swoim imieniu. Podwykonawcy mogą access dane klienta tylko do świadczenia usług, dla których firma Microsoft je zatrudniła, i nie mogą korzystać z nich w żadnym innym celu. Ponadto są umownie zobowiązani do zachowania poufności informacji klientów.
Firmy Microsoft i akredytowane firmy inspekcji regularnie weryfikują usługi biznesowe z certyfikatami inspekcji, takimi jak ISO/IEC 27001. Ci audytorzy przeprowadzają audyty wyrywkowe, aby potwierdzić, że dostęp jest wykorzystywany tylko w uzasadnionych celach biznesowych. Możesz zawsze uzyskać dostęp do swoich danych klientów w dowolnym momencie i z dowolnego powodu.
Jeśli usuniesz jakiekolwiek dane, firma Microsoft Azure usunie dane, w tym wszelkie kopie z pamięci podręcznej lub kopii zapasowej. W odniesieniu do usług objętych zakresem, usunięcie następuje w ciągu 90 dni po zakończeniu okresu przechowywania. (Sekcja 'Warunki przetwarzania danych' Online Services Terms definiuje usługi objęte zakresem).
Jeśli w dysku używanym do przechowywania danych wystąpi awaria sprzętowa, firma Microsoft bezpiecznie wipes lub niszczy dysk przed jego zwróceniem do producenta w celu wymiany lub naprawy. Microsoft nadpisuje dane na dysku, aby zapewnić, że nikt nie odzyska ich w żaden sposób.
Izolacja środowiska obliczeniowego
Firma Microsoft Azure oferuje różne usługi obliczeniowe oparte na chmurze, które obejmują szeroki wybór wystąpień obliczeniowych i usług, które mogą automatycznie skalować w górę i w dół w celu zaspokojenia potrzeb aplikacji lub przedsiębiorstwa. Te instancje obliczeniowe i usługi oferują izolację na wielu poziomach, aby zabezpieczyć dane bez rezygnacji z elastyczności konfiguracyjnej, której wymagają organizacje.
Rozmiary izolowanych maszyn wirtualnych
Azure Compute oferuje rozmiary maszyn wirtualnych, które są izolowane do określonego typu sprzętu i przeznaczone dla jednego klienta. Rozmiary izolowane działają na określonych generacjach sprzętu. Azure wycofuje te rozmiary, gdy generacja sprzętu się kończy lub pojawia się nowa generacja sprzętu.
Izolowane rozmiary maszyn wirtualnych najlepiej nadają się do zadań roboczych wymagających wysokiego stopnia izolacji od obciążeń roboczych innych dzierżawców. Ta izolacja bywa czasem wymagana ze względu na spełnienie wymogów zgodności i regulacji. Użycie izolowanego rozmiaru gwarantuje, że tylko Twoja maszyna wirtualna działa na tej konkretnej instancji serwera.
Ponieważ maszyny wirtualne o izolowanym rozmiarze są duże, możesz zdecydować się na podział ich zasobów, korzystając z pomoc techniczna platformy Azure dla zagnieżdżonych maszyn wirtualnych.
Obecne oferty izolowanych maszyn wirtualnych obejmują:
Standard_E192is_v6Standard_E192ids_v6Standard_E104i_v5Standard_E104id_v5Standard_E104is_v5Standard_E104ids_v5Standard_E112ias_v5Standard_E112iads_v5Standard_E80is_v4Standard_E80ids_v4Standard_E96ias_v4Standard_E112ibs_v5Standard_E112ibds_v5Standard_EC96ias_v5Standard_EC96iads_v5Standard_HB120rs_v3Standard_HB176rs_v4Standard_HB368rs_v5Standard_HX176rsStandard_M832is_16_v3Standard_M832ids_16_v3Standard_M192is_v2Standard_M192ids_v2Standard_M192ims_v2Standard_M192idms_v2Standard_NC64as_T4_v3Standard_NC96ads_A100_v4Standard_NC80adis_H100_v5Standard_ND128isr_NDR_GB200_v6Standard_ND128isr_NDR_GB300_v6Standard_ND96isr_H100_v5Standard_ND96isr_H200_v5Standard_ND96isr_MI300X_v5Standard_NG32ads_V620_v1Standard_NG32adms_V620_v1Standard_NV72ads_A10_v5
Uwaga
Izolowane rozmiary maszyn wirtualnych mają ograniczony okres eksploatacji ze względu na wycofywanie sprzętu z użycia.
Wycofanie izolowanych rozmiarów maszyn wirtualnych
Izolowane rozmiary maszyn wirtualnych mają sprzętowo ograniczoną żywotność. Azure wysyła przypomnienia z wyprzedzeniem 12 miesięcy przed oficjalną datą wycofania obsługiwanych rozmiarów i oferuje zaktualizowaną opcję izolacyjną do rozważenia. Azure ogłosił następujące rozmiary na emeryturę.
| Rozmiar | Data wycofania izolacji |
|---|---|
Standard_DS15_v2 |
15 maja 2020 |
Standard_D15_v2 |
15 maja 2020 |
Standard_G5 |
28 lutego 2022 r. |
Standard_GS5 |
28 lutego 2022 r. |
Standard_E64i_v3 |
28 lutego 2022 r. |
Standard_E64is_v3 |
28 lutego 2022 r. |
Standard_M192is_v2 |
31 marca 2027 r. |
Standard_M192ims_v2 |
31 marca 2027 r. |
Standard_M192ids_v2 |
31 marca 2027 r. |
Standard_M192idms_v2 |
31 marca 2027 r. |
Aby dalej podzielić zasoby tych izolowanych maszyn wirtualnych, zobacz pomoc techniczna platformy Azure for nested virtual machines.
Dedykowane hosty
Oprócz izolowanych hostów opisanych w poprzedniej sekcji Azure również oferuje dedykowane hosty. Azure Dedicated Host to usługa, która udostępnia fizyczne serwery mogące hostować jedną lub więcej maszyn wirtualnych i są dedykowane jednej subskrypcji Azure. Dedykowane hosty zapewniają izolację sprzętu na poziomie serwera fizycznego. Na hostach nie są umieszczane żadne inne maszyny wirtualne. Dedykowane hosty są wdrażane w tych samych centrach danych co inne hosty i dzielą tę samą sieć oraz podstawową infrastrukturą przechowywania co inne, nieizolowane hosty. Aby uzyskać więcej informacji, zapoznaj się ze szczegółowym omówieniem dedykowanych hostów Azure.
Hyper-V i izolacja głównego systemu operacyjnego między maszyną wirtualną głównego systemu a maszynami wirtualnymi gości
platforma obliczeniowa Azure jest oparta na wirtualizacji maszyn. Cały kod klienta jest uruchamiany na maszynie wirtualnej Hyper-V. W każdym węźle Azure (lub punkcie końcowym sieci) hypervisor działa bezpośrednio na sprzęcie i dzieli węzeł na zmienną liczbę maszyn wirtualnych gościa.
Każdy węzeł ma również jedną specjalną główną maszynę wirtualną, na której działa system operacyjny hosta. Hypervisor i główny system operacyjny zarządzają izolacją maszyny wirtualnej głównej od maszyn wirtualnych gości oraz izolacją maszyn wirtualnych gości między sobą. To połączenie hiperwizora i głównego systemu operacyjnego wykorzystuje wieloletnie doświadczenie firmy Microsoft w zakresie bezpieczeństwa systemów operacyjnych oraz nowsze wnioski płynące z technologii Hyper-V firmy Microsoft, aby zapewnić silną izolację gościnnych maszyn wirtualnych.
Platforma Azure korzysta ze środowiska zwirtualizowanego. Wystąpienia użytkowników działają jako autonomiczne maszyny wirtualne, które nie mają dostępu do fizycznego serwera hosta.
Hypervisor Azure działa jak mikrojądro. Przekazuje wszystkie żądania dostępu do sprzętu z maszyn wirtualnych gościa do hosta do przetwarzania przy użyciu interfejsu współdzielonej pamięci o nazwie VM Bus. Ta architektura uniemożliwia użytkownikom uzyskiwanie bezpośredniego dostępu do operacji odczytu, zapisu lub wykonywania w systemie i zmniejsza ryzyko współdzielenia zasobów systemowych.
Zaawansowany algorytm rozmieszczania maszyn wirtualnych i ochrona przed atakami kanałami bocznymi
Każdy atak cross-VM składa się z dwóch etapów: umieszczenia VM kontrolowanej przez przeciwnika na tym samym hostze co jedna z VM ofiary, a następnie przekroczenia granicy izolacji, aby albo ukraść wrażliwe informacje ofiary, albo wpłynąć na jej wydajność w wyniku kradzieży zasobów lub zakłóceń. Firma Microsoft Azure zapewnia ochronę w obu krokach przy użyciu zaawansowanego algorytmu umieszczania maszyn wirtualnych i ochrony przed wszystkimi znanymi atakami kanału bocznego, w tym hałaśliwymi maszynami wirtualnymi sąsiadów.
Kontroler sieci szkieletowej Azure
Kontroler warstwy Fabric Azure przydziela zasoby infrastruktury do obciążeń dzierżawców i zarządza komunikacją jednokierunkową z hosta do Virtual Machines. Algorytm umieszczania VM jest bardzo zaawansowany i niemal niemożliwy do przewidzenia na poziomie fizycznego hosta.
W Azure główna maszyna wirtualna uruchamia wzmocniony system operacyjny o nazwie główny system operacyjny hostujący agenta sieci szkieletowej (FA). FAs zarządzają agentami gościa (GA) w systemach operacyjnych gościa na maszynach wirtualnych klienta, a także zarządzają węzłami pamięci.
Zestaw hypervisor Azure, systemu operacyjnego/głównej funkcjonalności oraz maszyn wirtualnych klienta/Agentów składa się na węzeł obliczeniowy. Kontroler fabric (FC) zarządza agentami fabric (FA). Klaster trybu awaryjnego istnieje poza węzłami obliczeniowymi i magazynującymi. Oddzielne kontrolery sieciowe zarządzają klastrami obliczeniowymi i pamięciowymi. Jeśli klient aktualizuje plik konfiguracji aplikacji podczas działania, FC komunikuje się z FA. Fa kontaktuje się z GAs, które powiadamiają o zastosowaniu zmiany konfiguracji. W przypadku awarii sprzętu FC automatycznie znajduje dostępny sprzęt i ponownie uruchamia maszynę wirtualną.
Komunikacja od kontrolera tkaniny do agenta jest jednokierunkowa. Agent implementuje usługę chronioną protokołem SSL, która odpowiada tylko na żądania od kontrolera. Agent nie może inicjować połączeń z kontrolerem ani innymi uprzywilejowanymi węzłami wewnętrznymi. Fc traktuje wszystkie odpowiedzi tak, jakby były niezaufane.
Izolacja rozciąga się od głównej maszyny wirtualnej do maszyn wirtualnych gościa i z jednej maszyny wirtualnej gościa do innej. Węzły obliczeniowe są również odizolowane od węzłów storage w celu zwiększenia ochrony.
Funkcja hypervisor i system operacyjny hosta zapewniają filtry pakietów sieciowych. Te filtry pomagają zagwarantować, że niezaufane maszyny wirtualne nie mogą generować sfałszowanego ruchu ani odbierać ruchu, który nie jest do nich adresowany. Kierują ruch do chronionych punktów końcowych infrastruktury i uniemożliwiają wysyłanie lub odbieranie nieodpowiedniego ruchu rozgłaszanego.
Inne reguły skonfigurowane przez agenta kontrolera tkankowego w celu izolowania maszyn wirtualnych
Domyślnie Azure blokuje cały ruch podczas tworzenia maszyny wirtualnej. Następnie agent kontrolera sieci szkieletowej konfiguruje filtr pakietów w celu dodania reguł i wyjątków w celu zezwolenia na autoryzowany ruch.
Agent kontrolera tkaniny programuje dwie kategorie reguł:
- Konfiguracja maszyn lub zasady infrastruktury: Domyślnie Azure blokuje wszelką komunikację. Dodaj wyjątki umożliwiające maszynie wirtualnej wysyłanie i odbieranie ruchu DHCP i DNS. Maszyny wirtualne mogą również wysyłać ruch do „publicznego” Internetu, a także do innych maszyn wirtualnych w ramach tej samej sieci Azure Virtual Network oraz do serwera aktywacji systemu operacyjnego. Lista dozwolonych miejsc docelowych wychodzących dla maszyn wirtualnych nie obejmuje podsieci routerów Azure, zarządzania Azure ani innych właściwości Microsoft.
- Plik konfiguracji roli: Ten plik definiuje listy kontroli dostępu (ACL) dla ruchu przychodzącego na podstawie modelu usługi najemcy.
Izolacja sieci VLAN
Każdy klaster zawiera trzy sieci VLAN:
- Główny VLAN: Łączy nieufne węzły klientów.
- FC VLAN: Zawiera zaufane FC i systemy wspierające.
- VLAN urządzeń: Zawiera zaufane urządzenia sieciowe oraz inne urządzenia infrastrukturalne.
FC VLAN może komunikować się z głównym VLAN-em, ale główny VLAN nie może inicjować komunikacji z FC VLAN. Główny VLAN również nie może komunikować się z VLAN-em urządzenia. Ta architektura VLAN zapewnia, że nawet jeśli węzeł, na którym uruchamiany jest kod klienta, zostanie przejęty, nie będzie mógł zaatakować węzłów ani na VLAN-ach FC, ani na VLAN-ach urządzeń.
izolacja magazynowania
Izolacja logiczna między obliczeniami a przechowywaniem danych
W ramach podstawowego projektu firma Microsoft Azure oddziela obliczenia oparte na maszynach wirtualnych od storage. Taka konstrukcja umożliwia niezależne skalowanie obliczeń i pamięci, co ułatwia zapewnienie wielodzierżawności i izolacji.
W związku z tym Azure Storage działa na oddzielnym sprzęcie bez łączności sieciowej z usługą Azure Compute z wyjątkiem łączności logicznej. Taki projekt pamięci oznacza, że gdy tworzysz wirtualny dysk, system nie przydziela miejsca na całej jego pojemności. Zamiast tego system tworzy tabelę, która mapuje adresy na dysku wirtualnym na obszary na dysku fizycznym. Ta tabela jest początkowo pusta. Przy pierwszym zapisie danych na dysku wirtualnym system przydziela miejsce na dysku fizycznym i umieszcza wskaźnik w tabeli.
Izolacja przy użyciu kontroli dostępu do pamięci masowej
Access control w Azure Storage używa prostego modelu access control. Każda subskrypcja Azure może utworzyć co najmniej jedno konto storage. Każde konto storage ma jeden klucz tajny, którego używasz do kontrolowania access do wszystkich danych na tym koncie storage.
Możesz kontrolować dostęp do danych Azure Storage (w tym Tabele) za pośrednictwem sygnatury wspólnego dostępu (SAS), który przyznaje dostęp o określonym zakresie. Tworzysz SAS za pomocą szablonu zapytania (URL) i podpisujesz go przy użyciu SAK (Klucz konta magazynu). Możesz przekazać podpisany adres URL innemu procesowi (delegowanego). Proces delegowany może następnie wypełnić szczegóły zapytania i wysłać żądanie usługi przechowywania. Korzystając z SAS (Shared Access Signature), można udzielić klientom dostępu opartego na czasie bez ujawniania klucza tajnego konta magazynu.
Dzięki SAS możesz przyznać klientowi ograniczone uprawnienia do obiektów w swoim koncie pamięci na określony czas i określony zestaw uprawnień. Przyznajesz te ograniczone uprawnienia bez konieczności udostępniania kluczy dostępu do konta.
Izolacja przechowywania na warstwie IP
Zapory można ustanowić i zdefiniować zakres adresów IP dla zaufanych klientów. Korzystając z zakresu adresów IP, tylko klienci, którzy mają adres IP w zdefiniowanym zakresie, mogą łączyć się z Azure Storage.
Użyj mechanizmu sieciowego, który przydziela dedykowany tunel ruchu do pamięci IP, aby chronić dane IP przed nieautoryzowanymi użytkownikami.
Szyfrowanie
Azure oferuje następujące typy szyfrowania w celu ochrony danych:
- Szyfrowanie podczas transferu
- Szyfrowanie w spoczynku
Szyfrowanie podczas transferu
Szyfrowanie podczas przesyłania chroni dane podczas ich przesyłania między sieciami. Za pomocą Azure Storage można zabezpieczyć dane przy użyciu:
- Szyfrowania na poziomie transportu, takich jak HTTPS podczas przesyłania danych do lub z Azure Storage.
- Szyfrowanie komunikacyjne, takie jak szyfrowanie SMB 3.0 dla udziałów plików w usłudze Azure.
- Szyfrowania po stronie klienta w celu zaszyfrowania danych przed ich przesłaniem do storage i odszyfrowywania danych po ich przeniesieniu z storage.
Szyfrowanie w spoczynku
Dla wielu organizacji szyfrowanie danych w spoczynku jest obowiązkowym krokiem w kierunku ochrony prywatności danych, zgodności i suwerenności danych. Funkcje Azure, które zapewniają szyfrowanie danych w spoczynku, obejmują:
- Szyfrowanie usługi przechowywania automatycznie szyfruje dane podczas zapisu ich do Azure Storage.
- Szyfrowanie po stronie klienta szyfruje dane przed przeniesieniem ich do pamięci masowej.
- Encryption na hoście zapewnia kompleksowe szyfrowanie danych maszyny wirtualnej.
Szyfrowanie na hoście
Ważne
Azure Disk Encryption ma zostać wycofana September 15, 2028. Do tej pory można nadal używać Azure Disk Encryption bez zakłóceń. 15 września 2028 r. obciążenia z obsługą programu ADE będą nadal działać, ale zaszyfrowane dyski nie będą mogły zostać odblokowane po ponownym uruchomieniu maszyny wirtualnej, co spowoduje przerwy w działaniu usługi.
Użyj szyfrowania na hoście dla nowych maszyn wirtualnych lub rozważ poufne rozmiary maszyn wirtualnych z szyfrowaniem dysków systemu operacyjnego na potrzeby obciążeń przetwarzania poufnego. Wszystkie maszyny wirtualne z obsługą programu ADE (w tym kopie zapasowe) muszą migrować do szyfrowania na hoście przed datą wycofania, aby uniknąć przerw w działaniu usługi. Aby uzyskać szczegółowe informacje, przejdź do przenoszenia z Azure Disk Encryption do szyfrowania na hoście.
Encryption na hoście zapewnia kompleksowe szyfrowanie danych maszyny wirtualnej przez szyfrowanie danych na poziomie hosta maszyny wirtualnej. Domyślnie używa ona kluczy zarządzanych przez platformę, ale opcjonalnie można używać kluczy zarządzanych przez klienta przechowywanych w Azure Key Vault lub zarządzanym module HSM Azure Key Vault gdy potrzebujesz większej kontroli.
Szyfrowanie na hoście zapewnia szyfrowanie po stronie serwera na poziomie hosta maszyny wirtualnej przy użyciu szyfrowania AES 256, które jest zgodne ze standardem FIPS 140-2. To szyfrowanie odbywa się bez korzystania z zasobów procesora CPU maszyny wirtualnej i zapewnia kompleksowe szyfrowanie dla:
- Dyski tymczasowe
- Pamięć podręczna systemu operacyjnego i dysków danych
- Przepływy danych do Azure Storage
Najważniejsze korzyści z szyfrowania na hoście:
- Brak wpływu na wydajność: szyfrowanie odbywa się na poziomie hosta bez użycia zasobów CPU VM.
- Szerokie wsparcie VM: Obsługiwane w większości serii i rozmiarów maszyn wirtualnych.
- Klucze zarządzane przez klienta: Opcjonalna integracja z Azure Key Vault lub zarządzanym HSM do kontroli kluczy.
- Domyślnie zarządzane przez platformę klucze: Nie wymaga dodatkowej konfiguracji do szyfrowania.
Aby uzyskać więcej informacji, zobacz Encryption na hoście i Przegląd opcji szyfrowania dysków zarządzanych.
Izolacja usługi SQL Database
Azure SQL Database to oparta na chmurze relacyjna usługa bazy danych oparta na silniku Microsoft SQL Server. Azure SQL Database to wysoce dostępna, skalowalna, wielodzierżawcza usługa bazy danych z przewidywalną izolacją danych na poziomie konta, geografii, regionu i sieci. Usługa zapewnia izolację tej bazy danych z niemal zerową administracją.
Model aplikacji usługi SQL Database
Z punktu widzenia aplikacji usługa SQL Database zapewnia następującą hierarchię, w której każdy poziom zawiera jeden do wielu poziomów poniżej.
Konto i subskrypcja to pojęcia związane z platformą Microsoft Azure do kojarzenia rozliczeń i zarządzania.
Logiczne serwery SQL i bazy danych to specyficzne pojęcia dla baz danych SQL. Zarządzasz nimi, korzystając z interfejsów OData i T-SQL dostarczanych przez bazę SQL lub portalu Azure.
Serwery w SQL Database nie są instancjami fizycznymi ani instancjami maszyn wirtualnych. Zamiast tego są to zbiory baz danych, które dzielą zasady zarządzania i bezpieczeństwa, przechowywane w tzw. logicznej bazie danych głównych.
Logiczne główne bazy danych obejmują:
- Loginy SQL używane do łączenia się z serwerem
- Reguły zapory sieciowej
Nie ma gwarancji, że bazy danych z tego samego serwera, dla których dostępne są informacje o rozliczeniach i użyciu, znajdują się na tej samej fizycznej instancji w klastrze. Aplikacje muszą podać docelową nazwę bazy danych podczas połączenia.
Z twojej perspektywy tworzysz serwer w regionie geograficznym, ale Azure tworzy serwer w jednym z klastrów w tym regionie.
Izolacja za pośrednictwem topologii sieci
Gdy tworzysz serwer i rejestrujesz jego nazwę DNS, nazwa DNS wskazuje na adres VIP Bramy w konkretnym centrum danych, gdzie umieszczasz serwer.
Za wirtualnym adresem IP (adres IP) znajduje się zbiór bezstanowych usług bramy. Ogólnie rzecz biorąc, bramki uaktywniają się, gdy konieczna jest koordynacja między wieloma źródłami danych (główna baza danych, baza danych użytkowników itd.). Usługi bramkowe implementują następujące funkcje:
- Proxy dla połączeń TDS. Ta funkcja obejmuje lokalizowanie bazy danych użytkownika w klastrze zaplecza, implementowanie sekwencji uwierzytelniania, a następnie przekazywanie pakietów TDS do zaplecza i z powrotem.
- Zarządzanie bazami danych. Ta funkcja obejmuje implementowanie kolekcji przepływów pracy do obsługi operacji TWORZENIA, ALTER i DROP bazy danych. Usługa może wywoływać operacje na bazie danych, podsłuchując pakiety TDS albo za pomocą jawnych interfejsów API OData.
- OPERACJE TWORZENIA, ALTER i DROP uwierzytelniania i użytkownika
- Operacje zarządzania serwerem za pośrednictwem interfejsu API OData
Warstwa za bramami jest nazywana zapleczem. Poziom back-end przechowuje wszystkie dane w sposób wysoce dostępny. Każdy element danych należy do partycji lub jednostki trybu failover, a każda partycja ma co najmniej trzy repliki. Silnik SQL Server przechowuje i replikuje dane, a system przełączania awaryjnego często nazywany fabric nimi zarządza.
Ogólnie rzecz biorąc, system back-end nie nawiązuje połączeń wychodzących do innych systemów ze względów bezpieczeństwa. Azure zachowuje komunikację wychodzącą dla systemów na poziomie front-end (gateway). Maszyny poziomu bram mają ograniczone uprawnienia na maszynach zaplecza. To ograniczenie minimalizuje powierzchnię ataku jako mechanizm obrony w głębi.
Izolacja według funkcji i dostępu maszyny
Baza danych SQL obejmuje usługi działające na różnych funkcjach maszyny. Usługa SQL Database dzieli te usługi na środowisko back-end bazy danych w chmurze oraz środowiska front-end bramy i zarządzania, kierując się ogólną zasadą, że ruch jest kierowany wyłącznie do back-endu, a nie z niego na zewnątrz. Środowisko front-end może komunikować się ze światem zewnętrznym innych usług i zasadniczo ma jedynie ograniczone uprawnienia w back-endzie (wystarczające do wywoływania punktów wejścia, które musi wywoływać).
Izolacja sieci
Wdrożenia Azure mają wiele warstw izolacji sieci. Poniższy diagram przedstawia różne warstwy izolacji sieci, które zapewnia Azure. Warstwy te obejmują natywne funkcje platformy Azure oraz funkcje definiowane przez klienta. Ruch przychodzący z Internetu, Azure DDoS Protection zapewnia izolację przed atakami na dużą skalę skierowanymi na Azure. Kolejną warstwą izolacji są zdefiniowane przez klienta publiczne adresy IP (punkty końcowe), których używasz do określenia, który ruch może przechodzić przez usługę w chmurze do virtual network. Natywna izolacja sieci wirtualnej Azure zapewnia całkowitą izolację od wszystkich innych sieci. Ruch przepływa wyłącznie przez ścieżki i metody skonfigurowane przez użytkownika. Te ścieżki i metody stanowią kolejną warstwę, gdzie NSG, UDR oraz wirtualne urządzenia sieciowe mogą tworzyć granice izolacji chroniące wdrożenia aplikacji w chronionej sieci.
Izolacja ruchu:Sieć wirtualna jest granicą izolacji ruchu na platformie Azure. Virtual machines (maszyny wirtualne) w jednym virtual network nie mogą komunikować się bezpośrednio z maszynami wirtualnymi w innym virtual network, nawet jeśli obie sieci wirtualne są tworzone przez tego samego klienta. Izolacja to kluczowa cecha, która zapewnia, że maszyny wirtualne i komunikacja klientów pozostają prywatne w ramach sieci wirtualnej.
Podsieć zapewnia kolejną warstwę izolacji w sieci wirtualnej opartej na zakresie adresów IP. Można podzielić virtual network na wiele podsieci dla organizacji i zabezpieczeń. Wirtualne maszyny i instancje roli PaaS wdrożone w podsieciach (tej samej lub różnych) w sieci wirtualnej mogą komunikować się ze sobą bez konieczności dodatkowej konfiguracji. Można również skonfigurować grupy zabezpieczeń sieciowych (NSG), aby pozwalać lub blokować ruch sieciowy do instancji maszyny wirtualnej na podstawie reguł zabezpieczeń. Sieciowe grupy zabezpieczeń można skojarzyć z podsieciami lub poszczególnymi interfejsami sieciowymi dołączonymi do maszyn wirtualnych. Kiedy skojarzysz grupę zabezpieczeń sieci (NSG) z podsiecią, reguły zabezpieczeń mają zastosowanie do wszystkich maszyn wirtualnych w tej podsieci.
Dalsze kroki
Dowiedz się więcej o grupach zabezpieczeń sieci . Sieciowe grupy zabezpieczeń filtrują ruch sieciowy między zasobami Azure w sieci wirtualnej. Możesz ograniczyć ruch do podsieci lub virtual machines na podstawie źródła, miejsca docelowego, portu i protokołu przy użyciu reguł zabezpieczeń.
Dowiedz się więcej o izolacji maszyn wirtualnych w Azure. Azure Compute oferuje rozmiary maszyn wirtualnych, które są izolowane do określonego typu sprzętu i przeznaczone dla jednego klienta.