Microsoft załatał poważną lukę w zabezpieczeniach Azure Automation, która mogła pozwolić atakującym przekraczać granice dzierżaw (tenantów) i przejmować tożsamość automatyzacji innej organizacji. Luka, oznaczona jako CVE-2025-29827, otrzymała ocenę CVSS 9,9 i dotyczyła niewłaściwej autoryzacji w Azure Automation.
Ta podatność jest szczególnie istotna, ponieważ Azure Automation jest powszechnie wykorzystywany do zadań operacyjnych, takich jak przepływy pracy DevOps, wdrażanie zasobów, instalowanie poprawek, skryptowe runbooki i rotacja sekretów. Zadania te często działają z użyciem tożsamości zarządzanych, które mają dostęp do innych zasobów Azure.
Co się wydarzyło
Lukę odkrył Shay Shavit, starszy badacz bezpieczeństwa w zespole Azure Networking Security Research firmy Microsoft, który zgłosił ją do Microsoft Security Response Center. Microsoft opublikował następnie komunikat dotyczący tej podatności.
Zgodnie z raportem błąd mógł pozwolić atakującemu, który miał już dostęp do własnego konta Azure Automation, przekroczyć granicę zaufania w chmurze i przejąć tożsamość automatyzacji innej dzierżawy. W efekcie atakujący mógłby potencjalnie tworzyć lub modyfikować skrypty automatyzacji, uzyskiwać dostęp do poufnych danych konfiguracyjnych lub poświadczeń przechowywanych na kontach Azure Automation oraz tworzyć, zmieniać lub usuwać zasoby w chmurze.
Dlaczego tożsamość Azure Automation ma znaczenie
Konta Azure Automation mogą używać tożsamości zarządzanych do uwierzytelniania w innych usługach Azure bez przechowywania tradycyjnych poświadczeń w skryptach. Dokumentacja Microsoftu wyjaśnia, że tożsamość zarządzana przypisana przez system do konta Automation może pobierać tokeny umożliwiające dostęp do zasobów chronionych przez Microsoft Entra ID, takich jak Azure Key Vault.
Dlatego tożsamości zarządzane są tak potężne. Są przydatne, bo eliminują zaszyte w kodzie sekrety, ale jednocześnie stają się podmiotami zabezpieczeń o wysokiej wartości. Jeśli tożsamość automatyzacji zostanie nadużyta, atakujący może odziedziczyć wszystkie uprawnienia, które ta tożsamość ma w subskrypcjach, grupach zasobów, usługach Key Vault, kontach magazynu, maszynach wirtualnych i innych usługach chmurowych.
Sedno ryzyka: naruszona izolacja dzierżaw
Najpoważniejszym aspektem problemu jest nie tylko eskalacja uprawnień, lecz międzydzierżawowa eskalacja uprawnień.
Platformy chmurowe opierają się na silnej izolacji dzierżaw. Tożsamość jednego klienta nigdy nie powinna mieć wpływu na zasoby innego klienta. W tym przypadku zgłoszona luka mogła pozwolić atakującemu działającemu z jednego konta Azure Automation na przejęcie tożsamości automatyzacji innej dzierżawy.
Taka wada jest groźna, ponieważ podważa jedno z podstawowych założeń bezpieczeństwa chmury publicznej: że granice dzierżaw są egzekwowane przez dostawcę i nie mogą zostać przekroczone przez obciążenia kontrolowane przez klienta.
Ustawienia domyślne pogłębiły ryzyko
Problem wiązał się z domyślną konfiguracją Azure Automation, która mogła sprawiać, że tożsamości kont automatyzacji były publiczne. Według Dark Reading domyślnym ustawieniem tożsamości Azure Automation nie jest już dostęp publiczny.
To ważna lekcja dla zespołów odpowiedzialnych za bezpieczeństwo chmury. Ustawienia bezpieczne domyślnie mają znaczenie. Klienci często zakładają, że domyślne ustawienia platformy są bezpieczne, zwłaszcza w zarządzanych usługach chmurowych. Jeśli jednak domyślna konfiguracja zbyt szeroko udostępnia tożsamość lub relacje zaufania, klient może odziedziczyć ryzyko, nie zdając sobie z tego sprawy.
Dlaczego konta automatyzacji są celem o wysokiej wartości
Konta automatyzacji są atrakcyjne, ponieważ znajdują się blisko operacji.
Mogą uruchamiać skrypty, które włączają i wyłączają maszyny wirtualne, rotują sekrety, wdrażają infrastrukturę, instalują poprawki w systemach, zarządzają kopiami zapasowymi, współpracują z Key Vault lub wykonują zadania administracyjne w obciążeniach chmurowych. Wytyczne Microsoftu dotyczące Azure Automation opisują tę usługę jako platformę do orkiestracji częstych, czasochłonnych i podatnych na błędy zadań infrastrukturalnych i operacyjnych w środowiskach chmurowych i hybrydowych.
Jeśli atakujący może przejąć tożsamość automatyzacji lub się pod nią podszyć, nie musi włamywać się na konto administratora. Może nadużyć tożsamości maszynowej, która już wykonuje zaufane zadania.
Zasada najmniejszych uprawnień jest kluczowa
Własne wytyczne Microsoftu dotyczące bezpieczeństwa Azure Automation zalecają stosowanie zasady najmniejszych uprawnień przy nadawaniu dostępu do zasobów Automation, korzystanie ze szczegółowych ról RBAC, unikanie szerokich przypisań na poziomie subskrypcji tam, gdzie to możliwe, oraz ograniczanie ról o wysokich uprawnieniach, takich jak Automation Contributor.
Te wytyczne mają tu bezpośrednie znaczenie. Zasięg szkód po przejęciu jakiejkolwiek tożsamości automatyzacji zależy w dużej mierze od tego, jakie uprawnienia ma dane konto automatyzacji. Tożsamość ograniczona do jednego wąskiego zadania stwarza mniejsze ryzyko niż tożsamość z szerokimi uprawnieniami współautora w całej subskrypcji.
Co organizacje powinny przejrzeć
Mimo że Microsoft zmienił ustawienie domyślne, organizacje powinny nadal przeanalizować swoje zasoby Azure Automation.
Zespoły ds. bezpieczeństwa powinny sprawdzić:
- jakie konta Automation istnieją we wszystkich subskrypcjach
- jakie tożsamości zarządzane są włączone
- jakie uprawnienia RBAC mają te tożsamości
- czy jakiekolwiek konta Automation mają szeroki dostęp typu Contributor lub Owner
- czy runbooki zawierają sekrety, tokeny lub poufne dane konfiguracyjne
- czy konta Automation mają dostęp do usług Key Vault lub obciążeń produkcyjnych
- czy nieużywane runbooki, poświadczenia lub tożsamości można usunąć
Dokumentacja Microsoftu wprost zaleca przypisywanie wyłącznie tych uprawnień, które są potrzebne do wykonania zadania przez runbook. Na przykład jeśli konto Automation ma tylko uruchamiać lub zatrzymywać maszynę wirtualną, jego uprawnienia powinny być ograniczone do tej czynności, a nie obejmować szeroki dostęp.
Zalecane działania obronne
Organizacje korzystające z Azure Automation powinny traktować tożsamości automatyzacji jak konta uprzywilejowane.
Praktyczne kroki obejmują:
- wymuszanie zasady najmniejszych uprawnień dla wszystkich tożsamości zarządzanych kont Automation
- unikanie uprawnień z symbolami wieloznacznymi lub nadmiernie szerokich
- usuwanie nieużywanych kont Automation i runbooków
- przegląd dostępu do usług Key Vault, magazynu, sieci i zasobów produkcyjnych
- monitorowanie aktywności kont Automation i zmian w runbookach
- alarmowanie o nieoczekiwanym tworzeniu lub modyfikowaniu skryptów
- stosowanie Microsoft Entra Privileged Identity Management do dostępu uprzywilejowanego tam, gdzie to właściwe
- oddzielenie automatyzacji produkcyjnej od automatyzacji deweloperskiej o niższym ryzyku
- okresowy przegląd uprawnień tożsamości we wszystkich subskrypcjach
Wytyczne Microsoftu dotyczące bezpieczeństwa Azure Automation zalecają również unikanie uprawnień z symbolami wieloznacznymi oraz korzystanie z Microsoft Entra Privileged Identity Management, aby zwiększyć widoczność i ochronę kont uprzywilejowanych.
Podsumowanie
CVE-2025-29827 pokazuje, dlaczego granice tożsamości w chmurze należy traktować jako krytyczne mechanizmy kontroli bezpieczeństwa.
Problem nie dotyczył wyłącznie Azure Automation. Chodziło o to, co się dzieje, gdy zaufane tożsamości automatyzacji stają się osiągalne lub możliwe do przejęcia poza właściwą granicą.
Konta automatyzacji często przechowują klucze do przepływów operacyjnych. Mogą wdrażać, instalować poprawki, konfigurować, rotować i zarządzać zasobami chmurowymi na dużą skalę. Dzięki temu są niezwykle użyteczne dla obrońców i niezwykle cenne dla atakujących.
Tożsamości automatyzacji w chmurze muszą mieć ściśle ograniczony zakres, być stale przeglądane i monitorowane jak konta uprzywilejowane. Ustawienie domyślne nigdy nie powinno decydować o granicy bezpieczeństwa tożsamości w chmurze przedsiębiorstwa.
