IAM i organizacja
Analizujemy efektywne prawa i granice administracyjne.
- Role, polityki, service accounts i federation
- Organizacje, konta, projekty i guardrails
- Klucze, sekrety i workload identity
Sprawdzamy, jak konfiguracja IAM, sieci, danych i automatyzacji łączy się w realne scenariusze eskalacji.
Chmura rzadko zawodzi przez jeden „krytyczny checkbox”. Ryzyko powstaje między polityką IAM, rolą CI/CD, sekretem, publiczną usługą i brakiem telemetrii. Oceniamy te zależności jako system.
Analizujemy efektywne prawa i granice administracyjne.
Sprawdzamy ekspozycję usług oraz odporność danych.
Oceniamy sposób wdrażania i zdolność wykrywania nadużyć.
Ustalamy konta, właścicieli, dane krytyczne, regiony i dopuszczalne granice zaufania.
Łączymy stan runtime z Terraformem, politykami i pipeline’ami, jeśli są dostępne.
Sprawdzamy, czy pozornie ograniczona rola może przejąć inny workload, sekret albo tożsamość.
Tworzymy backlog zmian z właścicielem, wpływem i bezpieczną kolejnością wdrożenia.
Oceniamy skuteczne uprawnienia, a nie wyłącznie nazwę i przeznaczenie roli.
Przykład przedstawia format analizy i nie odnosi się do klienta.
Pipeline może zmienić definicję uruchamianego workloadu
Workload dziedziczy szerszą tożsamość runtime
Tożsamość ma odczyt sekretów poza zakresem aplikacji
Naprawa rozdziela role, ogranicza trust i dodaje alert
Nie zawsze. Preferujemy dedykowane role read-only uzupełnione kontrolowanymi uprawnieniami do uzgodnionych testów. Minimalizujemy dostęp i rejestrujemy działania.
Tak, jeśli IaC jest dostępne. Porównanie kodu ze stanem rzeczywistym pozwala znaleźć drift i naprawić źródło problemu, a nie tylko pojedynczy zasób.
Możemy mapować ustalenia do standardu, ale podstawowym celem jest ryzyko techniczne. Sam audyt nie jest certyfikacją.
Zmapujemy konta, dane krytyczne i najbardziej prawdopodobne ścieżki eskalacji.