Bezpieczeństwo chmury i SaaS

To podział obowiązków bezpieczeństwa między dostawcą chmury a Tobą, a większość incydentów w chmurze wydarza się po Twojej stronie tej linii. Dostawca zabezpiecza to, co sam prowadzi: centra danych, sprzęt, sieć między nimi oraz, zależnie od usługi, system operacyjny i samą aplikację. Ty odpowiadasz za sposób korzystania: kto ma konta i z jakimi uprawnieniami, uwierzytelnianie wieloskładnikowe (MFA), konfigurację magazynów i usług, dane, które tam umieszczasz, własne aplikacje i ich poprawki oraz kopie zapasowe. Linia przesuwa się wraz z rodzajem usługi. Przy wynajmowanych serwerach wirtualnych zarządzasz niemal wszystkim powyżej sprzętu; przy produkcie SaaS, takim jak pakiet biurowy, zarządzasz głównie tożsamościami, ustawieniami udostępniania i danymi. Przeczytaj macierz odpowiedzialności swojego dostawcy, przypisz każdą pozycję do wskazanego właściciela w firmie i sprawdzaj ją przy każdej nowej usłudze. Certyfikaty dostawcy obejmują jego część, a nie Twoją konfigurację.

Opisują, jaką część stosu prowadzi za Ciebie dostawca, a więc ile pracy związanej z bezpieczeństwem zostaje po Twojej stronie. W infrastrukturze jako usłudze (IaaS) wynajmujesz serwery wirtualne, przestrzeń dyskową i sieci; sam instalujesz i łatasz system operacyjny, konfigurujesz zapory i uruchamiasz aplikacje, więc praca nad bezpieczeństwem przypomina utrzymanie własnych serwerów. W platformie jako usłudze (PaaS) dostawca prowadzi system operacyjny i środowisko uruchomieniowe, na przykład zarządzaną bazę danych czy platformę aplikacyjną; Ty odpowiadasz za swój kod, konfigurację, tożsamości i dane. W oprogramowaniu jako usłudze (SaaS) korzystasz z gotowej aplikacji, takiej jak poczta, CRM czy księgowość; Twoja część to głównie to, kto ma dostęp, z jakimi uprawnieniami i uwierzytelnianiem wieloskładnikowym, jak udostępniane są dane, oraz własna kopia ważnych danych. Wiele firm korzysta jednocześnie ze wszystkich trzech. Przypisz każdą usługę do jej typu, bo pytania audytora czy ubezpieczyciela różnią się dla każdego z nich, podobnie jak dostępne logi.

Może, w zakresie tego, co przejmuje dostawca, ale bardziej przenosi ryzyko, niż je usuwa. Duży dostawca łata swoją infrastrukturę, prowadzi redundantne centra danych i zatrudnia zespoły bezpieczeństwa, na które stać niewiele średnich firm, więc bezpieczeństwo fizyczne, awarie sprzętu i podstawowa dostępność zwykle się poprawiają. Nie przenosi się natomiast odpowiedzialność za tożsamości, konfigurację i dane, a te stają się bardziej wystawione: konto administratora chmury jest osiągalne z każdego miejsca w internecie, ustawienie magazynu może jednym kliknięciem upublicznić pliki, a skradzione hasło bez uwierzytelniania wieloskładnikowego otwiera wszystko naraz. Napastnicy podążyli za firmami do chmury, a wiele wywołanych przez nich incydentów zaczyna się od wyłudzonego konta lub wycieku klucza dostępu. Bezpieczna migracja to MFA na każdym koncie, minimalne uprawnienia administratorów, włączone i przeglądane logi, kopie zapasowe pod Twoją kontrolą i ktoś, kto odpowiada za konfigurację chmury. Sieć biurowa też nadal ma znaczenie: laptopy, drukarki i serwery, które zostały na miejscu, to często pierwszy przyczółek napastnika.

Połączenia między Twoimi urządzeniami a chmurą, a nie to, co dzieje się w chmurze. Czujnik w sieci biurowej lub agent na serwerze widzi, które urządzenia łączą się z którymi usługami chmurowymi i SaaS, kiedy, jak często i ile danych przepływa w każdą stronę, a także nazwę serwera w handshake'u TLS tam, gdzie przechwytywane są pakiety. To wystarcza, by zauważyć laptop wysyłający gigabajty do usługi przechowywania, z której nigdy nie korzystał, serwer meldujący się co kilka minut na wynajętej maszynie w chmurze czy urządzenie łączące się z nieoczekiwanym regionem. Nie widzi, co użytkownicy robią wewnątrz aplikacji SaaS, na przykład publicznego udostępnienia folderu, utworzenia reguły przekazywania poczty czy nadania aplikacji dostępu do skrzynki; nie widzi ruchu między usługami chmurowymi; i nie widzi pracowników pracujących z domu na niezarządzanych urządzeniach. To dają logi audytowe i konsole administracyjne samego dostawcy. NetSenX obejmuje stronę sieciową: beaconing, skanowanie, ruch lateralny i nietypową ilość danych wychodzących w każdym planie. Nie zastępuje logów dostawcy chmury.

Częściowo: widzi zachowanie sieciowe serwerów z Linuksem, na których działa jego agent, gdziekolwiek pracują, ale nie odczytuje warstwy zarządzania dostawcy chmury. Agent NetSenX działa na Linuksie i macOS, więc wirtualny serwer z Linuksem, który utrzymujesz u dostawcy chmury, może go uruchomić jak każda inna maszyna z Linuksem; agent widzi wtedy połączenia tego serwera, a podstawowe detekcje działają w każdym planie: beaconing C2, skanowanie, ruch lateralny do innych serwerów i nietypowa ilość danych wychodzących. Każdy taki serwer liczy się jako urządzenie w Twoim planie. Poza zasięgiem zostają: usługi zarządzane, których nie prowadzisz sam, takie jak bazy danych, funkcje bezserwerowe i magazyny; ruch między usługami chmurowymi, który nigdy nie dotyka serwera z agentem; oraz wszystko w warstwie zarządzania dostawcy, czyli logowania do kont, zmiany uprawnień i konfiguracja. Dla nich włącz logi audytowe i logi przepływów samego dostawcy i kieruj je tam, gdzie ktoś je przegląda. Połączenie obu widoków daje Ci zachowanie sieciowe serwerów i aktywność kont wokół nich.

Patrząc na to, kim jest cel, jak zachowuje się połączenie i czy cokolwiek w Twojej działalności je wyjaśnia. Napastnicy lubią wynajmowane serwery w chmurze, bo każdy może je utworzyć w kilka minut, a adres należy do renomowanego dostawcy, więc sama nazwa dostawcy niczego nie dowodzi. Lepsze pytania: czy cel pasuje do usługi, z której korzystasz, po nazwie w handshake'u TLS lub w DNS, i czy ta usługa jest na Twojej liście dostawców? Czy połączenie jest regularne, małe i całodobowe, jak program meldujący się na serwerze, a nie napędzane przez ludzi w godzinach pracy? Czy zaczęło się zaraz po czymś nietypowym na tym urządzeniu, na przykład nowym programie czy logowaniu z zagranicy? Czy serwer, który zwykle tylko przyjmuje połączenia, nagle sam je otwiera na zewnątrz? Legalna usługa kopii zapasowych czy monitoringu ma zwykle udokumentowany cel i umowę; nieznana maszyna wirtualna, z którą stacja robocza łączy się co pięć minut, już nie. NetSenX w każdym planie sygnalizuje wzorzec regularnego meldowania się, czyli beaconing, i nietypową ilość danych wychodzących, wraz z celem, więc możesz zapytać właściwą osobę.

Najpierw ustal to z połączeń, a potem zapytaj właściciela każdego serwera, bo większość takich połączeń ma nudne wyjaśnienie, a nieliczne nie. Uzasadnione powody to usługi monitoringu i kopii zapasowych, serwery lustrzane aktualizacji, API dostawcy, maszyna testowa programisty czy dostawca SaaS hostujący się u taniego operatora. Niepokojące sygnały są odwrotne: serwer, który nie ma żadnego powodu biznesowego, by łączyć się z internetem, połączenia powtarzane w stałych odstępach dniem i nocą, ruch, który zaczął się po incydencie lub nowej instalacji, i cele, których nikt w firmie nie rozpoznaje. Wynajmowane serwery wirtualne u tanich hostingodawców to częste miejsce dla serwerów sterujących napastników i do gromadzenia skradzionych danych, właśnie dlatego, że są tanie, szybkie i anonimowe w wynajmie. Prowadź listę oczekiwanych celów dla każdego serwera, przeglądaj ją z właścicielami i blokuj ruch wychodzący z serwerów, które go nie potrzebują. W każdym planie NetSenX pokazuje połączenia Twoich hostów z ich celami i alarmuje o beaconingu oraz nietypowej ilości danych wychodzących, czyli o wzorcach, które tu liczą się najbardziej.

Tak i robią to, bo ruch do znanej usługi chmurowej rzadko jest blokowany czy kwestionowany. Malware może pobierać polecenia z pliku na publicznym koncie przechowywania w chmurze, ze współdzielonego dokumentu, z serwisu hostującego kod, z interfejsu bota komunikatora czy z sieci CDN i tą samą drogą odsyłać skradzione dane. Dla zapory oceniającej cele po reputacji wygląda to jak zwykły pracownik korzystający z popularnej usługi. Zdradza je nadal zachowanie. Program sprawdzający plik w chmurze w regularnych odstępach, dniem i nocą, z urządzenia, którego użytkownik nie pracuje, ma rytm, jakiego ludzie nie mają; wysyłki mogą być nietypowo duże dla tego urządzenia; a odcisk klienta w handshake'u TLS może nie pasować do przeglądarki ani oficjalnej aplikacji usługi. Praktyczne kroki: dopuszczaj tylko te usługi chmurowe, z których korzysta firma, w miarę możliwości na poziomie dzierżawy (tenanta), i badaj urządzenia łączące się z prywatnymi kontami popularnych usług. NetSenX wykrywa beaconing i nietypową ilość danych wychodzących w każdym planie, niezależnie od celu, a odciski TLS od planu Starter tam, gdzie agent przechwytuje pakiety.

Porównaj transfer z tym, co dane urządzenie zwykle robi, i z narzędziami, z których firma faktycznie korzysta. Klient synchronizacji wysyłający pliki do zatwierdzonej przez firmę usługi przechowywania ma swój wzorzec: działa na stacjach osób, które z niego korzystają, jego wolumen rośnie i maleje wraz z godzinami pracy, a celem jest usługa, za którą płacisz. Kradzież danych zwykle różni się przynajmniej pod jednym względem: dużo wysyła serwer, a nie stacja robocza; celem jest prywatne lub nieznane konto, serwis wymiany plików albo wynajęty serwer; wolumen znacznie przekracza zwykły poziom tego hosta; dzieje się to w nocy lub w weekend; albo następuje po innych sygnałach ostrzegawczych, takich jak skanowanie czy nowe logowania administratorów. Narzędzia, których napastnicy używają do tego celu, na przykład narzędzia synchronizacji z wiersza poleceń, często wyglądają jak legalna kopia zapasowa. Najpierw zapytaj właściciela hosta, potem sprawdź w logach samego dostawcy przechowywania, jakiego konta użyto. W każdym planie NetSenX alarmuje o nietypowej ilości danych wychodzących z każdego hosta i pokazuje cel; nie widzi, jakie pliki wysłano.

Zobaczysz, czy firmowe urządzenie wysyła do usług chmurowych nietypowe ilości danych, co często jest najbardziej przydatnym wczesnym sygnałem, ale nie zobaczysz, kto to zrobił ani jakie to były pliki. W tygodniach przed odejściem gwałtowny wzrost wysyłek z laptopa do prywatnej usługi przechowywania, serwisu przesyłania plików czy narzędzia AI jest wart rozmowy, zwłaszcza o nietypowych porach. Ważniejszy od wykrywania jest dobry proces offboardingu: ustal na piśmie, co zostaje w firmie, odbierz dostęp do kont SaaS i chmurowych ostatniego dnia, unieważnij tokeny i hasła aplikacji, sprawdź linki udostępniania i reguły przekazywania w poczcie i magazynach oraz odbierz urządzenia. Nazwy plików mogą pokazać ochrona przed wyciekiem danych i logi audytowe usług przechowywania i poczty; czujnik sieciowy nie. Każdy przegląd prowadź proporcjonalnie, skupiony na urządzeniach i danych firmy, uzgodniony z HR i tam, gdzie to wymagane, z przedstawicielami pracowników, bo monitorowanie pracowników jest regulowane w każdym kraju UE. W każdym planie NetSenX alarmuje o nietypowej ilości danych wychodzących z urządzenia i pokazuje cel.

Tak, głównie przez urządzenia i konta, które je synchronizują lub nimi administrują. Gdy ransomware szyfruje pliki na laptopie, którego foldery są synchronizowane z magazynem w chmurze, klient synchronizacji wiernie wysyła zaszyfrowane wersje, więc kopie w chmurze też się zmieniają. Napastnik ze skradzionym kontem administratora może usuwać lub szyfrować dane bezpośrednio w usłudze, kasować kopie zapasowe i wersje albo najpierw wszystko wyprowadzić i grozić publikacją. Co pomaga: trzymaj włączone wersjonowanie plików z wystarczającą historią i wiedz, jak cofnąć cały folder naraz; chroń konta administratorów uwierzytelnianiem wieloskładnikowym odpornym na phishing i oddziel je od kont codziennych; włącz ochronę przed usunięciem lub blokady retencji, jeśli usługa je oferuje; miej niezależną kopię zapasową, której ci sami administratorzy nie mogą usunąć; i ograniczaj synchronizację do folderów, których ludzie potrzebują. Obserwuj kroki poprzedzające szyfrowanie, bo wtedy wciąż możesz zareagować: w każdym planie NetSenX wykrywa beaconing, skanowanie, ruch lateralny i nietypową ilość danych wychodzących, w tym duże wysyłki do magazynów w chmurze. Nie widzi działań w konsoli administracyjnej usługi chmurowej.

Zwykle nie w taki sposób, jakiego potrzebujesz. Dostawcy SaaS chronią swoją usługę przed własnymi awariami, dzięki redundantnemu przechowywaniu i planom odtwarzania po katastrofie, ale na ogół nie obiecują przywrócenia Twoich danych po tym, co zrobiłeś Ty lub napastnik wewnątrz Twojego konta. Usunięte elementy leżą w koszach i historii wersji przez ograniczony czas, a potem znikają; atak ransomware szyfrujący synchronizowane pliki, złośliwy administrator usuwający skrzynki czy błąd synchronizacji nadpisujący folder mogą trwać dłużej niż te okna; a po wygaśnięciu subskrypcji lub licencji użytkownika dane mogą zostać usunięte. Przeczytaj warunki dostawcy: większość opisuje ten podział jako część współdzielonej odpowiedzialności. Jeśli dane są ważne, miej własną kopię: usługę kopii zapasowych lub eksport, który kopiuje pocztę, pliki i kluczowe dane aplikacji do magazynu, którego administratorzy SaaS nie mogą usunąć, przechowywany tak długo, jak wymagają tego potrzeby biznesowe i prawne. Przynajmniej raz przetestuj odtworzenie skrzynki i folderu, bo wtedy wychodzą luki. Czujnik sieciowy tu nie pomoże; to kwestia planowania kopii zapasowych i retencji.

Zacznij od tożsamości, bo większość przejęć kont zaczyna się od wyłudzonego lub ponownie użytego hasła. Podstawy, po kolei: uwierzytelnianie wieloskładnikowe dla każdego użytkownika, a dla administratorów metody odporne na phishing, takie jak klucze bezpieczeństwa czy passkeys; osobne konta administratorów używane tylko do administracji i jak najmniej globalnych administratorów; wyłączone starsze protokoły uwierzytelniania, które omijają MFA; zasady logowania blokujące ryzykowne lokalizacje lub niezarządzane urządzenia, jeśli pozwala na to licencja; włączone logi audytowe przechowywane wystarczająco długo do dochodzenia; alerty o nowych regułach przekazywania poczty, nowych rolach administratora i nowych zgodach na aplikacje OAuth; ograniczenia udostępniania na zewnątrz i aplikacji firm trzecich, które użytkownicy mogą podłączać; i kopia zapasowa poczty i plików poza dostawcą, bo kosze dostawcy nie są kopią zapasową. Co kwartał przeglądaj role administratorów i konta gości. Większość z tego to konfiguracja, za którą już płacisz. Czujnik sieciowy nie widzi, co dzieje się w tych usługach; może dodać widok urządzeń, które się z nimi łączą, na przykład laptopa, który zaczyna beaconing po otwarciu załącznika phishingowego.

To atak, w którym ofiara zostaje nakłoniona do przyznania złośliwej aplikacji dostępu do swojego konta, zamiast oddać hasło. Użytkownik dostaje link do czegoś, co wygląda jak przydatna aplikacja lub prośba o dokument, loguje się na prawdziwej stronie Microsoft czy Google i klika, by zatwierdzić uprawnienia, takie jak czytanie poczty, plików czy kontaktów. Od tej chwili aplikacja napastnika ma token, który działa bez hasła i często przetrwa zmianę hasła i uwierzytelnianie wieloskładnikowe, bo użytkownik wyraził zgodę. Atak jest skuteczny właśnie dlatego, że każda strona, którą widzi ofiara, jest prawdziwa. Obrona: ogranicz zgody użytkowników tak, by dostęp można było przyznać tylko zweryfikowanym wydawcom lub aplikacjom zatwierdzonym przez administratora, wymagaj przeglądu administratora dla uprawnień wysokiego ryzyka, ustaw alerty o nowych zgodach na aplikacje i regularnie przeglądaj listę podłączonych aplikacji, usuwając to, czego nikt nie rozpoznaje. Jeśli znajdziesz złośliwą zgodę, odbierz dostęp aplikacji i unieważnij jej tokeny, a potem sprawdź w logach audytowych, do czego miała dostęp. Czujnik sieciowy nie widzi zgód, które odbywają się u dostawcy tożsamości; tam należą zabezpieczenia.

Te, których będziesz potrzebować, by po incydencie odpowiedzieć, co się stało: kto się zalogował, co się zmieniło i do jakich danych sięgnięto. W każdej usłudze chmurowej i SaaS sprawdź, czy są włączone: logi logowań z lokalizacją i urządzeniem; zmiany administracyjne i konfiguracyjne, takie jak nowe role, zasady, reguły przekazywania i zgody na aplikacje; dostęp do plików i skrzynek, jeśli usługa to oferuje; aktywność API dla kont chmurowych; i logi przepływów sieciowych dla sieci w chmurze, jeśli masz tam serwery. Potem sprawdź, jak długo każdy z nich jest domyślnie przechowywany, bo niektóre usługi trzymają tylko krótkie okno, chyba że dopłacisz lub je wyeksportujesz. Przechowuj kopie tam, gdzie administratorzy danej usługi nie mogą ich usunąć, by napastnik z uprawnieniami administratora nie zatarł śladów. Ustal, kto je przegląda i jakie zdarzenia wywołują alert. Zgłaszanie incydentów w ramach NIS2 i RODO, a także ubezpieczyciel, będą oczekiwać odtworzenia osi czasu. Czujnik sieciowy dodaje do niej stronę urządzeń: NetSenX przechowuje alerty przez okres przewidziany w Twoim planie, z hostami, celami i czasem.

Zwykle nic dobrego, i to szybko, bo napastnicy nieustannie przeszukują publiczne repozytoria kodu w poszukiwaniu kluczy. Klucz dostępu do chmury lub token API działa jak hasło, które nigdy nie pyta o uwierzytelnianie wieloskładnikowe; kto go ma, może korzystać z konta z uprawnieniami klucza z dowolnego miejsca. Typowe nadużycia to uruchamianie drogich zasobów obliczeniowych do kopania kryptowalut, kopiowanie magazynów i baz danych oraz tworzenie nowych użytkowników, by napastnik zachował dostęp po unieważnieniu klucza. Wycieki zdarzają się przez kod zapisany w publicznych lub współdzielonych repozytoriach, pliki konfiguracyjne w kopiach zapasowych, zrzuty ekranu, logi CI i wiadomości na czacie. Jeśli to się stanie: natychmiast unieważnij lub zrotuj klucz, a nie dopiero po dochodzeniu; przejrzyj logi aktywności konta pod kątem wszystkiego, co zrobiono z jego użyciem od wycieku, w tym nowych użytkowników, kluczy i zasobów w nietypowych regionach; usuń to, co utworzył napastnik; i sprawdź rozliczenia. By temu zapobiec, używaj skanowania sekretów w repozytoriach, krótkotrwałych poświadczeń zamiast długoterminowych kluczy, wąskich uprawnień dla każdego klucza i alertów budżetowych. Czujnik sieciowy nie zobaczy klucza opublikowanego w internecie; może zobaczyć skutki na serwerach, które obserwuje.

To przestrzeń w chmurze, którą może czytać, a nawet zapisywać, więcej osób, niż zamierzano, często każdy w internecie. Usługi przechowywania obiektów pozwalają udostępnić bucket lub kontener publicznie jednym ustawieniem albo linkiem, co jest przydatne dla obrazów strony internetowej, a niebezpieczne dla kopii zapasowych, eksportów, faktur czy plików klientów. Wiele nagłośnionych wycieków danych wcale nie było włamaniami, tylko plikami znalezionymi przez kogoś, kto skanował otwarte buckety. Unikniesz tego kilkoma nawykami: włącz u dostawcy blokadę publicznego dostępu na poziomie całego konta, chyba że bucket naprawdę musi być publiczny, a treści publiczne trzymaj w osobnych, wyraźnie nazwanych bucketach; zamiast publicznego udostępniania preferuj podpisane linki z ograniczonym czasem ważności; szyfruj dane i ograniczaj, kto może zmieniać ustawienia udostępniania; korzystaj z kontroli konfiguracji dostawcy lub narzędzia do oceny stanu, które oznacza publiczne magazyny; i przeglądaj linki udostępniania w magazynach SaaS, takie jak linki działające dla każdego, kto je ma. Sprawdzaj po każdym nowym projekcie, bo testowe buckety to częsty winowajca. Czujnik sieciowy nie widzi ustawień bucketów; to należy do zarządzania konfiguracją chmury.

To specjalny wewnętrzny adres dostępny na każdej maszynie wirtualnej w chmurze, z którego maszyna może odczytać informacje o sobie, w tym tymczasowe poświadczenia dla przypisanych jej uprawnień. Oprogramowanie działające na serwerze używa tych poświadczeń, by sięgać do magazynów, baz danych i innych usług chmurowych bez hasła w konfiguracji, co jest dobrą praktyką. Ryzyko polega na tym, że wszystko, co potrafi sprawić, by serwer wysłał żądanie WWW na ten adres, może te poświadczenia również odczytać. Częstą drogą jest server-side request forgery (SSRF): błąd w aplikacji internetowej pozwalający napastnikowi zmusić serwer do pobrania wybranego adresu URL. Mając poświadczenia, napastnik działa na Twoim koncie chmurowym z uprawnieniami serwera. Obrona: wymagaj nowszej, opartej na sesji wersji usługi metadanych tam, gdzie dostawca ją oferuje, bo blokuje proste sfałszowane żądania; dawaj roli każdego serwera tylko potrzebne uprawnienia; naprawiaj błędy SSRF i weryfikuj adresy URL pobierane przez aplikacje; i ustaw alerty, gdy poświadczenia z roli serwera są używane spoza Twojego środowiska, co mogą pokazać logi aktywności dostawcy.

Zwykle najpierw na rachunku, dlatego alerty budżetowe to najtańsza detekcja, jaką możesz ustawić. Napastnicy, którzy zdobędą poświadczenia do chmury, często uruchamiają wiele mocnych maszyn wirtualnych lub kontenerów, nierzadko w regionach, z których nigdy nie korzystasz, by kopać kryptowaluty na Twój koszt. Sygnały: nagły wzrost wydatków na moc obliczeniową lub liczby instancji, maszyny z GPU, których nikt nie zamawiał, nowe zasoby w nieznanych regionach, nowe klucze dostępu lub użytkownicy utworzeni mniej więcej w tym samym czasie i serwery pracujące całą dobę z pełnym obciążeniem procesora. Na serwerze, który sam prowadzisz, proces kopiący widać też w sieci: stałe, długotrwałe połączenia z pulami kopania, często na nietypowych portach, z maszyny, która zwykle obsługuje tylko żądania WWW. Reaguj, unieważniając użyte poświadczenia, usuwając to, co napastnik utworzył we wszystkich regionach, szukając mechanizmów utrzymania dostępu, takich jak nowi użytkownicy, role i zaplanowane funkcje, i pytając dostawcę o opłaty. NetSenX widzi zachowanie sieciowe serwerów, na których działa jego agent, na przykład regularne połączenia z nieznanym celem; nie śledzi Twojego rachunku za chmurę ani zasobów bez agenta.

Połącz kilka tanich źródeł, bo żadne z nich nie widzi wszystkiego. Dostawca tożsamości pokazuje, do jakich aplikacji ludzie logują się kontem firmowym, łącznie z aplikacjami OAuth podłączonymi do poczty czy plików. Raporty wydatków i wyciągi z kart ujawniają subskrypcje kupione przez zespoły. Zarządzanie przeglądarkami i urządzeniami pozwala wypisać zainstalowane rozszerzenia i aplikacje desktopowe. Logi DNS oraz logi zapory lub proxy pokazują, z jakimi usługami łączą się firmowe urządzenia. Potem posortuj listę: narzędzia dublujące zatwierdzone, narzędzia przechowujące dane firmy lub klientów i te nieszkodliwe. Dla każdego narzędzia przetwarzającego dane zdecyduj: zatwierdzić je porządnie, z umową i kontrolą administracyjną, zastąpić albo wycofać, i wyjaśnij użytkownikom dlaczego. Robione raz na kwartał utrzymuje listę krótką. Widok sieci pomaga w części dotyczącej połączeń: NetSenX pokazuje, które hosty łączą się z którymi celami, a od planu Pro ma osobny widok usług AI; nie rozpoznaje każdej aplikacji SaaS z nazwy i nie widzi logowań ani zgód na aplikacje, które są u dostawcy tożsamości.

To trzy rodzaje narzędzi bezpieczeństwa chmury, które patrzą na różne rzeczy. Zarządzanie stanem bezpieczeństwa chmury (CSPM) sprawdza konfigurację kont chmurowych, na przykład publiczne magazyny, otwarte reguły zapory, brak szyfrowania czy zbyt szerokie uprawnienia, porównuje ją z dobrymi praktykami i zgłasza odchylenia. Zarządzanie stanem bezpieczeństwa SaaS (SSPM) robi to samo dla aplikacji SaaS, sprawdzając ustawienia takie jak wymuszanie MFA, udostępnianie na zewnątrz i role administratorów. Broker bezpieczeństwa dostępu do chmury (CASB) stoi między użytkownikami a usługami chmurowymi, przez proxy lub API dostawców, by wykrywać używane usługi i egzekwować zasady, na przykład blokować wysyłanie danych wrażliwych. Czy ich potrzebujesz, zależy od skali. Firma z jednym kontem chmurowym i jednym pakietem biurowym często zajdzie daleko dzięki wbudowanym rekomendacjom dostawców i pulpitom oceny bezpieczeństwa, które nic dodatkowo nie kosztują. Kilka kont chmurowych, wiele narzędzi SaaS lub dane regulowane sprawiają, że dedykowane narzędzia stają się bardziej opłacalne. Żadne z nich nie obserwuje zachowania urządzeń w Twojej sieci; to inna warstwa, którą obejmuje detekcja sieciowa.

Zadawaj pytania, na które odpowiedzi da się sprawdzić i które mają znaczenie, gdy coś pójdzie źle. Dowody: jakie niezależne raporty lub certyfikaty obejmują kupowaną usługę, na przykład raport SOC 2 Type II czy certyfikat ISO/IEC 27001, z zakresem i datą, i czy możesz je przeczytać. Dane: gdzie są przechowywane i przetwarzane, jakie podmioty przetwarzające biorą w tym udział, czy są używane do trenowania modeli, jak długo są przechowywane i jak odzyskasz je w użytecznym formacie, gdy odejdziesz. Dostęp: logowanie jednokrotne, wymuszanie MFA, uprawnienia oparte na rolach i logi audytowe, które możesz wyeksportować. Incydenty: jak szybko Cię powiadomią, jakim kanałem i jakie wsparcie dadzą w Twoich własnych obowiązkach zgłoszeniowych z RODO czy NIS2. Odporność: kopie zapasowe, cele odtworzenia i to, jak chronią przed nadużyciem konta administratora. Podatności: jak obsługują zgłoszenia i jak szybko łatają. Kluczowe odpowiedzi wpisz do umowy lub umowy powierzenia, a nie tylko do ankiety. Mniejszy dostawca z jasnymi, uczciwymi odpowiedziami może być bezpieczniejszy niż duży z ogólnikowymi.

Zwykle obie strony, za różne rzeczy. Dostawca odpowiada za zabezpieczenie swojej usługi, a zgodnie z RODO dostawca działający jako Twój podmiot przetwarzający musi powiadomić Cię bez zbędnej zwłoki po stwierdzeniu naruszenia ochrony danych osobowych. Ty, jako administrator danych swoich klientów czy pracowników, nadal odpowiadasz za ocenę ryzyka dla osób, których dotyczy, i w razie potrzeby za zgłoszenie organowi nadzorczemu w ciągu 72 godzin od stwierdzenia naruszenia oraz za poinformowanie tych osób, jeśli ryzyko jest wysokie. Jeśli Twoja firma podlega NIS2, poważny incydent wywołany przez dostawcę może uruchomić Twoje własne obowiązki zgłoszeniowe, a NIS2 oczekuje zarządzania bezpieczeństwem łańcucha dostaw jako części środków zarządzania ryzykiem. Wiele praktycznych kwestii rozstrzygają umowy: terminy powiadomień, współpraca, informacje, które otrzymasz, i odpowiedzialność. Przygotuj się zawczasu: wiedz, którzy dostawcy przechowują jakie dane, miej ich kontakty ds. bezpieczeństwa i uwzględnij naruszenie u dostawcy w planie reagowania na incydenty. Krajowe przepisy wdrażające NIS2 mogą dodawać szczegóły; sprawdź je.

Nie za jego prowadzenie, ale za zarządzanie ryzykiem, jakie ono dla Ciebie tworzy, jeśli Twoja firma podlega NIS2. Dyrektywa (UE) 2022/2555 wymienia bezpieczeństwo łańcucha dostaw, w tym aspekty bezpieczeństwa relacji z bezpośrednimi dostawcami i usługodawcami, wśród środków zarządzania ryzykiem cyberbezpieczeństwa z art. 21. W praktyce oznacza to wiedzę, od których dostawców chmury i SaaS zależą Twoje ważne usługi, ocenę ich bezpieczeństwa, wpisanie wymagań do umów i planowanie na wypadek ich awarii lub przejęcia. Dostawcy usług przetwarzania w chmurze są w NIS2 sami wymienieni jako podmioty sektora infrastruktury cyfrowej, więc wielu ma własne obowiązki, co pomaga, ale nie zastępuje Twojej oceny. Przydatne dowody od dostawców to niezależne raporty z audytów, certyfikaty z jasnym zakresem, zobowiązania do powiadamiania o incydentach i warunki wyjścia. Prowadź rejestr dostawców wskazujący dane i usługi, które każdy z nich obsługuje, i przeglądaj go co roku oraz po incydentach. Krajowe transpozycje mogą dodawać wymagania lub wytyczne; sprawdź przepisy swojego kraju i publikacje właściwego organu.

Najpierw ogranicz szkody, potem ustal, co się stało, i na bieżąco wszystko dokumentuj. Ograniczenie: zresetuj hasło i unieważnij wszystkie aktywne sesje i tokeny konta; usuń metody MFA, których nie rejestrowałeś, i zarejestruj je ponownie; sprawdź i usuń nowe reguły przekazywania, zgody na aplikacje, klucze API, użytkowników czy role administratora utworzone przez napastnika; a jeśli było to konto administratora, przejrzyj całą dzierżawę lub konto chmurowe, bo napastnicy tworzą tylne furtki. Dochodzenie: użyj logów logowań i audytu dostawcy, by ustalić, kiedy zaczął się dostęp, skąd i co odczytano, zmieniono, udostępniono lub pobrano; sprawdź, czy tego samego hasła nie używano gdzie indziej. Potem rozstrzygnij obowiązki: dostęp do danych osobowych może oznaczać zgłoszenie z RODO w ciągu 72 godzin od stwierdzenia naruszenia, a poważny incydent może podlegać zgłoszeniu w ramach NIS2 w Twoim kraju. Spójrz też na urządzenia: skradzione hasło często pochodziło z zainfekowanego laptopa lub strony phishingowej. W każdym planie NetSenX może pokazać, czy jakieś urządzenie w Twojej sieci zaczęło w tym czasie beaconing, skanowanie lub wysyłanie nietypowych ilości danych. Nie widzi logowań do konta w chmurze.