Zaburzenia w Usługach Chmurowych: Skutki dla Tożsamości i Bezpieczeństwa

Ostatnie przerwy w działaniu kluczowych usług chmurowych nie umknęły uwadze ekspertów i użytkowników. Incydenty dotyczące renomowanych dostawców, takich jak AWS, Azure czy Cloudflare, wstrząsnęły dużymi częściami internetu, co skutkowało awariami stron internetowych i serwisów, na których bazują inne systemy. Efektem tych zakłóceń były problemy w działaniu aplikacji oraz codziennych procesów biznesowych, z których korzystają organizacje.

Dla konsumentów, te zakłócenia często są jedynie uciążliwością, taką jak niemożność zamówienia jedzenia, oglądania treści czy korzystania z usług online. Dla przedsiębiorstw natomiast konsekwencje są znacznie poważniejsze. Na przykład, gdy system rezerwacji linii lotniczych przestaje działać, każda utracona rezerwacja przekłada się na straty finansowe, szkodę reputacyjną oraz zakłócenia w operacjach.

Infrastruktura Chmurowa jako Wspólny Punkt Awarii

Usługi chmurowe nie są systemami tożsamości. Mimo to, współczesne architektury tożsamości w dużym stopniu polegają na chmurowej infrastrukturze i usługach współdzielonych. Nawet gdy usługa autoryzacji działa, awarie w innych elementach łańcucha zależności mogą uniemożliwić prawidłowe działanie przepływów tożsamości.

Większość organizacji korzysta z chmury do kluczowych komponentów związanych z tożsamością, takich jak:

• Bazy danych przechowujące atrybuty tożsamości oraz informacje katalogowe
• Dane dotyczące polityk i autoryzacji
• Load balancery, panele kontrolne oraz DNS

Te współdzielone zależności wprowadzają ryzyko do systemu. Awaria któregokolwiek z tych komponentów może całkowicie zablokować procesy autoryzacji lub autoryzacji, nawet jeśli dostawca tożsamości teoretycznie działa.

Tożsamość jako Klucz do Wszystkiego

Autoryzacja i uwierzytelnienie nie są odosobnionymi funkcjami wykorzystywanymi jedynie podczas logowania; są ciągłymi bramkami dla każdego systemu, API i usługi. Współczesne modele bezpieczeństwa, w szczególności Zero Trust, opierają się na zasadzie „nigdy nie ufaj, zawsze weryfikuj”. Ta weryfikacja w całkowitym stopniu zależy od dostępności systemów tożsamości.

Dotyczy to zarówno użytkowników ludzkich, jak i tożsamości maszynowych. Aplikacje nieustannie się uwierzytelniają. API weryfikują każdą prośbę. Usługi uzyskują tokeny do wywoływania innych usług. Gdy systemy tożsamości są niedostępne, nic nie działa.

Ukryta Złożoność Procesów Uwierzytelniania

Uwierzytelnienie obejmuje znacznie więcej niż weryfikację nazwy użytkownika i hasła lub klucza dostępu, zwłaszcza gdy organizacje przechodzą na modele bezhasłowe. Pojedyncza operacja uwierzytelniania zazwyczaj wyzwala skomplikowany łańcuch operacji. Systemy tożsamości często realizują atrybuty użytkowników z katalogów lub baz danych, przechowują stan sesji, wydają tokeny dostępu zawierające zakresy, roszczenia i atrybuty oraz podejmują szczegółowe decyzje autoryzacyjne przy użyciu silników polityk.

Kontrole autoryzacyjne mogą wystąpić zarówno podczas wydawania tokenów, jak i w czasie rzeczywistym, gdy dostępne są API. W wielu przypadkach API musi się uwierzytelnić i uzyskać tokeny przed wywołaniem innych usług. Każdy z tych kroków zależy od infrastruktury. Bazy danych, silniki polityk oraz usługi zewnętrzne stają się częścią procesu uwierzytelniania.

Dlaczego Tradycyjna Wysoka Dostępność Nie Wystarcza?

Wysoka dostępność jest szeroko stosowana i absolutnie niezbędna, ale często niewystarczająca dla systemów tożsamości. Większość rozwiązań wysokiej dostępności koncentruje się na regionalnym przełączaniu awaryjnym: podstawowy system w jednym regionie z zapasowym w innym. Jeśli jeden region zawiedzie, ruch przesuwa się do zapasowego.

Jednak ten model przestaje działać, gdy awarie dotyczą współdzielonych lub globalnych usług. Jeżeli systemy tożsamości w wielu regionach polegają na tym samym chmurowym panelu sterującym, dostawcy DNS lub zarządzanych usługach baz danych, regionalne przełączanie awaryjne nie zapewnia ochrony. W takich przypadkach system zapasowy zawodzi z tych samych powodów, co podstawowy.

Projektowanie Odporności dla Systemów Tożsamości

Prawdziwa odporność musi być starannie zaprojektowana. W przypadku systemów tożsamości oznacza to często ograniczenie zależności od jednego dostawcy lub domeny awarii. Strategie mogą obejmować plany multichmurowe lub kontrolowane alternatywy lokalne, które pozostaną dostępne, nawet gdy usługi chmurowe są obciążone.

Równie ważne jest planowanie działania w warunkach ograniczonej dostępności. Całkowite zablokowanie dostępu podczas awarii ma najwyższy możliwy wpływ na działalność gospodarczą. Umożliwienie ograniczonego dostępu, na podstawie zbuforowanych atrybutów, wcześniej obliczonych decyzji autoryzacyjnych lub ograniczonej funkcjonalności, może znacznie ograniczyć straty operacyjne i reputacyjne.

Nie wszystkie dane związane z tożsamością wymagają tego samego poziomu dostępności. Niektóre atrybuty czy źródła autoryzacji mogą być mniej odporne na awarie niż inne, i to może być akceptowalne. Ważne jest podejmowanie tych kompromisów celowo, na podstawie ryzyka biznesowego, a nie wygody architektonicznej.

Systemy tożsamości muszą być projektowane tak, aby w razie usterek działały płynnie. Gdy awarie infrastruktury są nieuniknione, kontrola dostępu powinna działać w sposób przewidywalny, a nie całkowicie się załamać.

Chcesz rozpocząć korzystanie z solidnego rozwiązania do zarządzania tożsamościami? Wypróbuj bezpłatnie Curity Identity Server.