W dzisiejszym szybko rozwijającym się środowisku SaaS uwaga skupia się na kontach użytkowników. Jest to jeden z najbardziej zagrożonych obszarów zarządzania bezpieczeństwem SaaS i wymaga ścisłego zarządzania rolami i uprawnieniami, monitorowania uprzywilejowanych użytkowników, ich poziomu aktywności (uśpiony, aktywny, nadpobudliwy), ich typu (wewnętrzny/zewnętrzny), a także tego, czy są to „joinerzy”, „moverzy” czy „leaverzy”.
Nic dziwnego, że wysiłki w zakresie zapewnienia bezpieczeństwa skupiały się do tej pory na kontach należących do ludzi. Opcje konfiguracji kont obejmują narzędzia takie jak MFA i SSO do uwierzytelniania. Kontrola dostępu oparta na rolach (RBAC) ogranicza poziom dostępu, a wytyczne dotyczące złożoności haseł uniemożliwiają nieupoważnionym osobom dostęp do aplikacji.
Jednak w świecie SaaS nie brakuje dostępu przyznawanego aktorom innym niż ludzie, czyli, innymi słowy, połączonym aplikacjom stron trzecich.
Konta usług, autoryzacje OAuth i klucze API to tylko niektóre z tożsamości innych niż ludzkie, które wymagają dostępu SaaS. Patrząc przez pryzmat aplikacyjny, konta maszynowe są bardzo podobne do tych używanych przez człowieka. Muszą zostać uwierzytelnione, otrzymać zestaw uprawnień i być monitorowane. Ponieważ jednak nie stoją za nimi ludzie, znacznie mniej uwagi poświęca się zapewnieniu im odpowiedniego bezpieczeństwa.
Przykłady dostępów non-human
Integracje to prawdopodobnie najłatwiejszy sposób zrozumienia dostępu do aplikacji SaaS przez konta inne niż ludzkie. Calendly to aplikacja, która eliminuje przesyłanie wiadomości e‑mail związanych z umawianiem spotkań, wyświetlając dostępność użytkownika. Integruje się z kalendarzem użytkownika, odczytuje go w celu określenia dostępności i automatycznie dodaje spotkania. Podczas integracji z Google Workspace poprzez autoryzację OAuth żąda uprawnień, które umożliwiają mu między innymi wyświetlanie, edytowanie, udostępnianie i usuwanie Kalendarzy Google. Integracja jest inicjowana przez człowieka, ale samo Calendly nie jest człowiekiem, a tożsamością maszynową istniejącą w naszym środowisku SaaS.
Inne konta maszynowe obejmują udostępnianie danych między dwiema lub większą liczbą aplikacji. SwiftPOS to aplikacja i urządzenie do obsługi punktów sprzedaży (POS) dla barów, restauracji i punktów sprzedaży detalicznej. Dane przechwycone przez punkt sprzedaży są przesyłane do platformy analityki biznesowej, takiej jak Microsoft Power BI, gdzie poddaje się je przetworzeniu i analizie. Dane przesyłane z SwiftPOS do Power BI są integrowane za pośrednictwem konta typu non-human.
Wyzwania w zabezpieczeniu kont non-human
Zarządzanie i zabezpieczanie kont maszynowych nie jest tak proste, jak mogłoby się wydawać. Przede wszystkim każda aplikacja ma własne podejście do zarządzania tego typu kontami. Niektóre rozłączają na przykład integrację OAuth, gdy użytkownik, który ją autoryzował, zostanie wyrejestrowany z aplikacji, podczas gdy inne utrzymują połączenie.
Same platformy SaaS również przyjmują różne podejścia do zarządzania tymi kontami. Niektóre włączają konta non-human do swoich zasobów użytkownika, podczas gdy inne przechowują i wyświetlają dane w innej sekcji, dzięki czemu łatwo je przeoczyć.
Konta ludzkie można uwierzytelniać za pośrednictwem usługi MFA lub SSO, natomiast konta inne niż ludzkie są uwierzytelniane jednorazowo i zapominane, chyba że wystąpi problem z integracją. Ludzie mają także typowe wzorce zachowań, takie jak logowanie się do aplikacji w godzinach pracy. Konta inne niż ludzkie często uzyskują dostęp do aplikacji poza godzinami szczytu, aby zmniejszyć ruch i obciążenie sieci. Kiedy człowiek loguje się do swojego SaaS o 3 rano, może to spowodować wszczęcie dochodzenia lub alarm w SOC. Kiedy o 3 nad ranem do sieci dostaje się konto niebędące tożsamością ludzką, wszystko wydaje się w porządku.
Aby uprościć zarządzanie kontami maszynowymi, wiele organizacji używa tego samego klucza API do wszystkich integracji. Dodatkowo przyznają szerokie zestawy uprawnień do klucza API, aby pokryć wszystkie potencjalne potrzeby organizacji. Innym razem programista użyje własnego klucza API o wysokich uprawnieniach, aby przyznać dostęp do konta innego niż człowiek, umożliwiając mu dostęp do wszystkiego w aplikacji. Takie klucze API działają jak przepustki pełnego dostępu używane przez wiele integracji, co sprawia, że są niezwykle trudne do kontrolowania.
Podejmowanie kroków w celu zabezpieczenia kont non-human
Korzystając z platformy SaaS Security Posture Management (SSPM) w połączeniu z rozwiązaniami Identity Threat Detection & Response (ITDR), organizacje mogą skutecznie zarządzać swoimi kontami non-human i wykrywać ich nietypowe zachowanie.
Konta inne niż ludzkie wymagają tej samej widoczności ze strony zespołów ds. bezpieczeństwa co konta ludzkie i powinny być zarządzane w tych samych zasobach użytkowników, co ich ludzkie odpowiedniki. Dzięki ujednoliceniu zarządzania tożsamością znacznie łatwiej jest przeglądać dostęp i uprawnienia oraz aktualizować konta niezależnie od tego, kto jest ich właścicielem. Zapewnia to także ujednolicone podejście do zarządzania kontami. Zasady organizacyjne, takie jak zakaz dzielenia się kontem, powinny być stosowane powszechnie. Konta inne niż ludzkie powinny być ograniczone do określonych adresów IP, które zostały wstępnie zatwierdzone na liście dozwolonych, i nie powinny mieć dostępu za pośrednictwem standardowych ekranów logowania (logowanie do interfejsu użytkownika). Co więcej, uprawnienia powinny być dostosowane do ich konkretnych potrzeb jako aplikacji i nie powinny być za szerokie ani dopasowane do ich ludzkich odpowiedników.
ITDR również odgrywa tu ważną rolę. Konta inne niż ludzkie mogą uzyskiwać dostęp do aplikacji SaaS o każdej porze dnia i nocy, ale zazwyczaj ich interakcje są dość spójne. ITDR może wykryć anomalie w zachowaniu niezależnie od tego, czy są to zmiany w harmonogramie, rodzaju danych dodawanych do aplikacji czy też działania wykonywane przez konto inne niż ludzkie.
Wgląd, jaki zapewnia SSPM w konta, a ITDR w zachowania związane z tożsamością non-human, jest niezbędny do zarządzania ryzykiem i identyfikowania zagrożeń. Jest to czynność nieodzowna do utrzymania bezpiecznych aplikacji SaaS.