Amazon jest pionierem rynku chmurowego, a AWS wręcz synonimem chmury – nie oznacza to jednak, że nie ma on konkurencji. Wg Gartnera konsekwentnie drugim graczem na rynku cloud jest właśnie Microsoft Azure, które choć ma sporo do nadrobienia, to dysponuje bardzo ciekawą ofertą, co w połączeniu z różnymi programami zniżkowymi, skutecznie przyciąga do siebie dużych klientów.

Struktura uprawnień

Azure stosuje zupełnie inny model zarządzania użytkownikami niż AWS, oparty na kontach federacyjnych Live (dawniej Microsoft Passport). A więc podstawowym podmiotem zabezpieczeń nie jest sztucznie stworzony użytkownik w ramach subskrypcji Azure, tylko konto imienne Live – czyli takie samo jak to, za pomocą którego można zalogować się do usług Xbox, przypisać licencje na Office / Microsoft 365, czy zarządzać usługami w ramach partnerstwa handlowego z Microsoftem.

Model taki ma dość zasadniczą wadę z punktu widzenia użytkownika: zalogowanie się na konto Live w jednej zakładce przeglądarki wpływa również na inne zakładki – dlatego też ciężko jest używać kilku (a tym bardziej kilkunastu czy kilkudziesięciu) kont Live do różnych usług w ramach jednej przeglądarki. W przeciwieństwie do kont AWS, które po pierwsze są „sztuczne” (tj. nie muszą być z nikim powiązane imiennie, a jedynie ze sztucznie wykreowaną rolą) i służą tylko i wyłącznie do obsługi konsoli AWS, a po drugie bazują wyłącznie na ciasteczkach sesyjnych – nie kolidują więc z usługami typu poczta, kalendarz, Xbox itp.

Do takich kont można następnie na kilka różnych sposobów (co wynika z konieczności utrzymania kompatybilności z bardzo wczesną wersją Azure) przypisywać uprawnienia – w formie:

• przypisania ról – włącznie z możliwością dodania kolejnych właścicieli całego konta głównego, zwanego Subskrypcją Azure (możliwe jest też tworzenie ról niestandardowych, zawierających pojedyncze uprawnienia, na zasadzie podobnej jak polisy w AWS)
• przypisania odmów – czyli np. granularnie blokować dostęp udzielony jakąś szerszą rolą
• przypisania współadministratorów (administratorów klasycznych)

Możliwe jest także użycie grup, jednakże w przeciwieństwie do AWS, nie są to grupy tworzone ad hoc na potrzeby przypisywania samych uprawnień, ale obiekty grup dziedziczone z:

• grup Azure AD
• grup Microsoft 365 (dawnego Office 365)

Sposoby dostępu

W Azure jest 5 głównych sposobów dostępu do usług:

• przez konsolę webową, po zalogowaniu na konto federacyjne Live – a jeśli użytkownik ma przypisane uprawnienia do więcej niż jednej subskrypcji, może się między nimi przełączać po zalogowaniu
• przez API Azure, za pomocą OAuth2, konta Live zalogowanego w przeglądarce i wizyty na stronie https://microsoft.com/devicelogin – metoda deweloperska
• przez API Azure, za pomocą service principal (czyli AZURE_CLIENT_ID) – metoda produkcyjna
• przez protokół SMB do usługi Azure Files, dla której z poziomu konsoli tworzy się odrębne hasła
• dedykowany dostęp do wybranych usług w specjalny sposób, np.:
  • logowanie ssh do instancji VM za pomocą klucza ssh (w przeciwieństwie do AWS, tworzonego wyłącznie lokalnie – treść klucza publicznego przekazywana jest każdorazowo przy tworzeniu instancji)
  • dostęp do baz danych w usłudze Azure Database za pomocą ich natywnych mechanizmów kontroli dostępu
  • osobny system uprawnień w usłudze Kubernetes

Sposoby zapisu kluczy i innych danych dostępowych do API

Metoda produkcyjna

Najbardziej charakterystycznym elementem, którego można próbować szukać, są nazwy zmiennych środowiskowych dla trybu logowania „service principal”, zalecanego do zastosowań produkcyjnych:

• AZURE_CLIENT_ID
• AZURE_CLIENT_SECRET
• AZURE_TENANT_ID
• AZURE_SUBSCRIPTION_ID – ta zmienna jest potrzebna dopiero po zalogowaniu i tylko w przypadku używania kilku subskrypcji, więc może jej nie być wraz z pozostałymi

Samo podłączanie klienta do subskrypcji wygląda następująco:

az login --service-principal -u $AZURE_CLIENT_ID -p $AZURE_CLIENT_SECRET -t $AZURE_TENANT_ID

Metoda deweloperska

Klient może być też zalogowany na stałe do subskrypcji metodą deweloperską – wówczas aplikacja w ogóle nie musi przechowywać żadnych danych logowania. Wszystkie potrzebne dane zawarte są w 2 plikach JSON:

• ~/.azure/accessTokens.json – tutaj jest bieżący token OAuth2
• ~/.azure/azureProfile.json – tutaj są dane subskrypcji

Potrzebnych plików w katalogu ~/.azure jest więcej, ale można je z łatwością wygenerować lub przerobić, znając zawartość drugiego z powyższych plików.

Subskrypcja i dzierżawa

„Subskrypcja” to używana przez Microsoft nazwa dla konta głównego.

W przeciwieństwie do AWS, subskrypcja nie ma żadnego stałego użytkownika głównego, czy własnego hasła – ma jedynie domyślnie przypisanego Właściciela (konto imienne Live, które jest twórcą tej subskrypcji – takich Właścicieli potem może być wielu, można też pierwotnego Właściciela całkowicie odpiąć od subskrypcji, np. jeśli pracownik kończy pracę w firmie).

„Dzierżawa” (tenant) oznacza konkretną instancję Azure AD.

Standardowo jedna subskrypcja posiada jedną dzierżawę – może jednak posiadać ich kilka. Możliwe jest również przeniesienie dzierżawy między subskrypcjami, jak również import dzierżawy z Microsoft 365.

Identyfikatory subskrypcji i dzierżawy mają format UUID, np. odpowiednio 9146fb8f-38fe-4136-ae92-3c99cc432547 i 1fcaa52b-1f0f-4999-b61f-86baf513faad (to realne identyfikatory z konta testowego).

Obsługa wielu kont

Klient konsolowy może być podłączony do wielu subskrypcji jednocześnie – albo przez zalogowanie przez OAuth2 do konta Live przyłączonego do wielu subskrypcji, albo przez bezpośrednie zalogowanie poleceniem „az login” do kilku różnych kont Live.

W takich przypadkach, aby wywoływać polecenia w kontekście odpowiedniej subskrypcji lub dzierżawy, do wywołań dodaje się parametr --subscription lub --tenant z identyfikatorem odpowiedniej subskrypcji lub dzierżawy.

Sposoby zapisu haseł do Azure Files

Microsoft Azure posiada dwie różne usługi odpowiedzialne za serwowanie plików:

• Azure Blobs (Blob Storage) – czyli w uproszczeniu odpowiednik Amazon S3 (tzw. object storage)
• Azure Files (File Storage, Cloud File Storage) – czyli usługa bardziej na wzór Amazon EBS, z dostępem przez protokół SMB (ten sam, który służy do współdzielenia plików przez systemy Windows w sieciach lokalnych) i z odrębnymi danymi dostępowymi

Azure Files posiada 2 poziomy podziału usług:

• „Udział” – pojedynczy kontener na pliki o zadeklarowanej wielkości. Współdzieli hasła dostępowe z konta magazynu.
• „Konto magazynu” (storage account) – jest to zbiór wielu udziałów, mający:
  • osobny adres serwera plików (patrz poniższy przykład kodu w PowerShellu)
  • wspólne polityki replikacji geograficznej, szyfrowania danych, firewalli i innych zabezpieczeń dla wszystkich udziałów
  • przydzielone na stałe 2 wspólne hasła dostępowe (mogą być w razie czego wygenerowane ponownie)
  • zbiorczy billing zużycia zasobów dla wszystkich udziałów

Pełny deskryptor endpointa Azure Files wygląda następująco (nazwa utworzonego konta magazynu to „mojtest2020” – jest ona unikalna w skali całej usługi, nie tylko w skali subskrypcji):

DefaultEndpointsProtocol=https;AccountName=mojtest2020;AccountKey=EUbi7dgVZW5u8MovluXb5pknwFDQLaT16tV4/WiDGLak9SCbpT/hd2MAA8Vx6Wqi091ZRsDc53qEns2nv12wqg==;EndpointSuffix=core.windows.net

Kreator udziałów generuje dość charakterystyczny kod przykładowy w PowerShellu (język komentarzy zależy od języka ustawionego w przeglądarce):

$connectTestResult = Test-NetConnection -ComputerName mojtest2020.file.core.windows.net -Port 445
if ($connectTestResult.TcpTestSucceeded) {
    # Zapisz hasło, aby utrwalić dysk po ponownym uruchomieniu 
    cmd.exe /C "cmdkey /add:`"mojtest2020.file.core.windows.net`" /user:`"Azure\mojtest2020`" /pass:`"EUbi7dgVZW5u8MovluXb5pknwFDQLaT16tV4/WiDGLak9SCbpT/hd2MAA8Vx6Wqi091ZRsDc53qEns2nv12wqg==`""
    # Zainstaluj dysk
    New-PSDrive -Name Z -PSProvider FileSystem -Root "\\mojtest2020.file.core.windows.net\udzialtest2020" -Persist
} else {
    Write-Error -Message "Unable to reach the Azure storage account via port 445. Check to make sure your organization or ISP is not blocking port 445, or use Azure P2S VPN, Azure S2S VPN, or Express Route to tunnel SMB traffic over a different port."
}

Narzędzia do enumeracji zawartości kont Azure

Rekomendowanym rozwiązaniem do enumeracji kont Azure będzie projekt Polynimbus – jest to narzędzie typu inventory, zorientowane na codzienne, bardzo dogłębne skanowanie konta Azure pod kątem wielu usług, oraz udostępnienie panelu webowego, w którym można nawigować po listach użytkowników i poszczególnych usług.