Wróć do bloga

Współdzielenie kont SaaS w zespole: cztery ryzyka i zgodne alternatywy

Wspólne konto abonamentowe może ograniczyć koszt licencji, ale rzeczywisty koszt bywa wyższy. Artykuł omawia cztery problemy: naruszenie warunków, obieg danych logowania, brak przypisania działań w logach i utrzymujący się dostęp po odejściu członków zespołu, a także zgodne alternatywy.

Dodanie kolejnego miejsca użytkownika do narzędzia SaaS może być znaczącym wydatkiem. Wraz ze wzrostem zespołu koszt ten staje się coraz bardziej odczuwalny.

Dlatego współdzielenie jednego zestawu danych logowania może wydawać się naturalne, szczególnie gdy ktoś tylko od czasu do czasu sprawdza raport albo tymczasowo weryfikuje dane dla klienta. Rzeczywisty koszt takiego rozwiązania jest jednak często niedoszacowany i rozkłada się na kilka obszarów: warunki usługi, dane logowania, dzienniki aktywności oraz zmiany w składzie zespołu. Każdy z nich rodzi inne problemy.

团队共用 SaaS 账号:四类风险与合规替代路径的关键步骤与判断维度示意图

Warunki są jasne: kont nie należy współdzielić

Większość produktów SaaS korzysta z modelu licencjonowania na użytkownika. Poza planami enterprise lub zespołowymi, które wyraźnie obsługują wielu użytkowników, pozostałe pakiety są zwykle przeznaczone dla jednej osoby. Regulaminy usług zazwyczaj jednoznacznie zabraniają korzystania przez kilka osób z tych samych danych logowania, a platforma może po wykryciu takiej sytuacji zawiesić lub odebrać dostęp. Łatwo przeoczyć jeden szczegół: takie zakończenie dostępu zwykle nie wiąże się ze zwrotem pieniędzy, więc wcześniej zapłacone kwoty mogą przepaść.

Istnieje też mniej widoczny koszt. Celem współdzielenia jest oszczędność, ale platforma nadal wycenia usługę według liczby osób, które potrzebują dostępu. Pozorna oszczędność w praktyce oznacza zamianę kosztu licencji na ryzyko niezgodności, które pozostaje niewidoczne, dopóki nie wydarzy się problem.

Gdy wiele osób zna hasło, trudno ustalić, kto wykonał działanie

Współdzielenie oznacza, że hasło krąży między kilkoma osobami, często przez komunikatory, notatki lub inne miejsca, w których jedna wiadomość może stać się trwałym zapisem.

Problemem nie jest wyłącznie samo hasło, lecz dwie wynikające z tego konsekwencje. Po pierwsze, rośnie powierzchnia narażenia: im więcej osób bierze udział w udostępnianiu, tym większa szansa, że ktoś użył tego samego hasła gdzie indziej albo że jedno z urządzeń zostanie przejęte i stanie się drogą dostępu do konta. Po drugie, trudniej przypisać odpowiedzialność. Jeśli konto posłuży do eksportu danych, zmiany ustawień lub wysłania czegoś, czego nie należało wysyłać, później można zobaczyć jedynie, co zrobiło konto, ale nie kto wykonał działanie. Dla zespołów, które muszą wyjaśniać klientom przepływ danych, jest to często najbardziej kłopotliwy element.

Logi rejestrują konto, a nie osobę

Panele administracyjne SaaS zazwyczaj zapisują aktywność na poziomie konta: kto wyeksportował raport, jakie ustawienia zmieniono i jakie dane usunięto. W dzienniku pozostaje zwykle tylko jedna nazwa konta.

Gdy z konta korzysta kilka osób, ta warstwa identyfikowalności znika. Zespół nie potrafi ustalić, kto dokonał zmiany, a system wykrywania anomalii po stronie platformy ma ten sam problem. Może zobaczyć to samo konto logujące się z wielu miast, urządzeń i wyjść sieciowych, z równoległymi sesjami, i oznaczyć aktywność jako podejrzaną. Typowe reakcje to wymuszone wylogowanie, czasowa blokada lub ponowna weryfikacja. Jeśli narzędzie jest potrzebne w codziennej pracy, brak dostępu w godzinach pracy może kosztować znacznie więcej niż kilka dodatkowych licencji.

Zmiana serwerów proxy czy ujednolicenie odcisków przeglądarki może jedynie zmniejszyć prawdopodobieństwo wykrycia; nie sprawia, że wspólne dane logowania stają się zgodne z warunkami. Co więcej, jeśli wszystkie logowania są powiązane z jednym środowiskiem, problem z tym środowiskiem — na przykład oznaczony adres IP lub środowisko uznane za nietypowe — może jednocześnie odciąć dostęp wszystkim i zwiększyć skalę awarii.

Osoba odchodzi, ale dostęp pozostaje

Gdy pracownik odchodzi albo kończy się współpraca z wykonawcą, często nie ma jasno wyznaczonej osoby odpowiedzialnej za odebranie dostępu do współdzielonego konta. Powód jest prosty: konto należy do wszystkich, więc nie istnieje wyraźny etap przekazania odpowiedzialności.

Pozostaje kilka zagrożeń. Były członek zespołu może nadal znać hasło, a nikt nie wie, kto jeszcze je zapisał. Wcześniej wydane pliki cookie sesji mogą nadal być ważne. Jeśli dana osoba skonfigurowała za pomocą konta skrypty automatyzacji lub wywołania API, takie drogi dostępu również nie znikną automatycznie. Gdy problem zostanie zauważony, dane mogą już być zmienione.

Ponadto każda zmiana w składzie zespołu powinna oznaczać zmianę hasła dla wszystkich. W modelu współdzielenia często nie da się przeprowadzić tego całkowicie.

Zgodne alternatywy nie są skomplikowane

Po rozdzieleniu powodów współdzielenia odpowiednie rozwiązania stają się dość oczywiste.

  • Dla stałych członków zespołu, którzy potrzebują dostępu: kup dodatkowe miejsca. To jedyna oficjalnie obsługiwana forma korzystania przez wiele osób i pozwala ponownie przypisywać działania w logach do konkretnych użytkowników.
  • Dla większych zespołów: sprawdź, czy platforma oferuje wieloużytkownikowy plan zespołowy lub enterprise. Takie plany zwykle zawierają model uprawnień ograniczający według roli to, co można zobaczyć lub zmienić.
  • Do scentralizowanej kontroli dostępu: użyj SSO. Gdy ktoś odchodzi, dostęp można wyłączyć centralnie bez polegania na ręcznym przypomnieniu.
  • Aby tymczasowo pokazać klientowi wyniki: wyeksportuj raport lub utwórz link tylko do odczytu, aby klient mógł sprawdzić dane bez logowania się na konto.

Warto rozróżnić współdzielenie konta od korzystania z wielu kont. W pierwszym przypadku kilka osób używa tych samych danych logowania. W drugim każda osoba ma własne dane logowania, ale musi korzystać ze swojego konta na tym samym urządzeniu bez wzajemnych zakłóceń; taki model może być zgodny sam w sobie. Jeśli na przykład zespół kupił miejsce dla każdego członka i każdy ma własne konto, pliki cookie oraz sesje w jednej przeglądarce mogą się wzajemnie nadpisywać. Oddzielne środowisko przeglądarki dla każdego konta pozwala rozdzielić sesje, pamięć podręczną i dane. PurpleMark zapewnia właśnie taki rodzaj izolacji środowiska. Rozwiązuje problem stabilnego współistnienia wielu legalnych kont na jednym urządzeniu; nie zmienia jednak faktu, że korzystanie przez wiele osób z jednego zestawu danych logowania nadal narusza warunki usługi.

Najpierw policz koszty

W istocie współdzielenie konta oznacza zamianę ryzyka niezgodności na niewielką oszczędność w opłatach za miejsca. Sporadyczne, tymczasowe użycie przez jedną osobę może przez pewien czas wydawać się skuteczne, ale w skali zespołu odebranie dostępu lub incydent z danymi może kosztować znacznie więcej niż zaoszczędzona kwota.

Najpierw oblicz koszt licencji, a dopiero potem wybierz właściwe rozwiązanie. Jeśli możesz kupić miejsca, kup je; jeśli możesz wyeksportować dane, wyeksportuj je.

Szczegółowe zasady licencjonowania zawsze wynikają z oficjalnych warunków danego produktu.