Przejście na RBAC po aktualizacji

Wraz z wprowadzeniem kontroli dostępu opartej na rolach (RBAC), system zawiera zestaw predefiniowanych ról zaprojektowanych tak, aby ułatwić przejście z poprzedniego modelu uprawnień. Role te są automatycznie mapowane na podstawie wcześniejszej konfiguracji, co pozwala zachować podstawową strukturę dostępu i zminimalizować zakłócenia podczas aktualizacji.


Rola superadmin jest stała i nie można jej modyfikować ani usuwać. Wszystkie pozostałe role predefiniowane — takie jak admin, operator, session viewer, safes admin i auditor — można modyfikować lub rozszerzać według potrzeb. Elastyczność ta pozwala organizacjom stopniowo dostosowywać model dostępu do wewnętrznych polityk bezpieczeństwa.

Ostrzeżenie

  • Po aktualizacji administratorzy powinni przejrzeć i dostosować predefiniowane role, aby upewnić się, że odpowiadają one wymaganiom ich organizacji. Dostosowanie ról jest kluczowe, by w pełni wykorzystać możliwości kontroli i szczegółowości oferowane przez RBAC.

  • W przypadku aktualizacji systemu do wersji opartej na zdolnościach (capabilities), konieczne jest odwzorowanie wszystkich obiektów, do których użytkownicy mieli przydzielone zdolności / uprawnienia.

  • Automatyczne mapowanie ról z poprzedniego systemu odbywa się jednorazowo i wyłącznie w trakcie aktualizacji z wersji bez RBAC. Role predefiniowane nie mają odwzorowywać poprzednich uprawnień jeden do jednego — mają być punktem wyjścia do dalszych zmian.

  • Po zmodyfikowaniu lub usunięciu roli predefiniowanej zmiana ta jest trwała — nie istnieje mechanizm przywracania jej pierwotnej wersji. W przypadku potrzeby przywrócenia domyślnej konfiguracji należy skontaktować się z pomocą techniczną Fudo Enterprise.

Zrozumienie uprawnień i zdolności

Odczyt

Uprawnienie *-read zapewnia dostęp do danej zakładki w interfejsie, a co za tym idzie — do wszystkich obiektów danego typu w systemie, niezależnie od posiadanych zdolności. Jest to dostęp tylko do podglądu — bez możliwości edycji, usuwania czy wykonywania innych działań.

Przykład:

Użytkownik z uprawnieniem user-read może otworzyć zakładkę Użytkownicy i zobaczyć pełną listę kont, w tym kont, których nie utworzył i do których nie ma zdolności. Nie może jednak ich modyfikować, blokować ani usuwać — chyba że ma do tego dodatkowe zdolności lub przywileje.

Tworzenie

Uprawnienia zakończone sufiksem *-create pozwalają użytkownikowi tworzyć nowe obiekty danego typu. Przykładowo, user-create umożliwia tworzenie nowych użytkowników. System automatycznie przyznaje twórcy wszystkie dostępne zdolności do stworzonego obiektu, co oznacza pełną możliwość jego zarządzania.

Przykład:

Jeśli administrator ma uprawnienie user-create i utworzy nowego użytkownika, automatycznie otrzymuje zdolności do:

  • modyfikowania ustawień użytkownika,

  • blokowania i odblokowywania konta,

  • usuwania użytkownika.

W takim przypadku administrator nie potrzebuje osobnych uprawnień, takich jak user-block czy user-delete — przyznane zdolności są wystarczające.

Usuwanie

Przyznanie roli uprawnienia z grupy *-delete (np. server-delete) pozwala na usuwanie dowolnych obiektów danego typu — niezależnie od tego, kto je utworzył. W interfejsie może być nadal wymagany dostęp do odpowiedniej zakładki, ale przez API można usuwać dowolne obiekty, jeśli uprawnienie *-delete jest obecne. W wielu przypadkach uprawnienie *-read nie jest wymagane do takich operacji przez API.

Ostrzeżenie

To może stanowić potencjalne zagrożenie bezpieczeństwa: przyznanie *-delete może nieumyślnie zwiększyć poziom dostępu roli. Zalecenia:

  • Preferuj przydzielanie uprawnień *-create, jeśli rola ma zarządzać tylko obiektami, które sama utworzyła.

  • Używaj *-delete tylko dla ról, które mają mieć pełną kontrolę nad wszystkimi obiektami danego typu.

Podczas migracji z wersji 5.5 należy dokładnie przeanalizować uprawnienia ról, aby uniknąć niezamierzonego rozszerzenia ich uprawnień.

Predefiniowane role jako punkt wyjścia

System zawiera zestaw predefiniowanych ról wspierających zgodność wsteczną i strukturę dostępu sprzed wprowadzenia RBAC:

  • Superadmin – Ma nieograniczony dostęp do wszystkich funkcji i ustawień systemu. Może tworzyć role niestandardowe z dowolnymi dostępnymi uprawnieniami.

  • Operator – Ma uprawnienia zbliżone do wcześniejszej roli operator sprzed wprowadzenia RBAC. Rola ta jest automatycznie mapowana na podstawie wcześniejszej konfiguracji. Wybrane przykładowe uprawnienia:

    • Może przeglądać listę sesji i ich szczegóły, ale tylko dla sesji powiązanych z obiektami, do których ma przypisane zdolności.

    • Może odtwarzać sesje zarchiwizowane i na żywo, ograniczone do obiektów, do których ma dostęp.

    • Nie może tworzyć nowych obiektów.

    • Może blokować tylko obiekty, do których ma przypisane zdolności.

    • Widzi tylko obiekty, do których ma zdolności, ale może podglądać wszystkie role i grupy.

    • Rola operator domyślnie zawiera uprawnienie listener-read. W wyniku zmian w RBAC operatorzy widzą obecnie wszystkich listenerów, nawet tych nieprzypisanych.

    • Może podglądać modyfikatory haseł, weryfikatory i polityki haseł.

    • Może podglądać aplikacje zdalne.

    • Nie może podglądać polityk ani wyrażeń regularnych.

    • Może zarządzać powiadomieniami i je przeglądać dla użytkowników, do których ma przypisane zdolności.

    • Może widzieć stopkę Panelu administratora.

    • Nie może udostępniać sesji do dołączenia ani ich usuwać.

    • Może przeglądać i głosować w oczekujących, aktywnych i zarchiwizowanych żądaniach powiązanych z obiektami, do których ma dostęp (użytkownik wnioskujący, konto, sejf, serwer/pula).

    • Może generować raporty z zakładki Sesje.

    • Może zarządzać subskrypcjami raportów.

    • Może ręcznie dodać subskrypcję do Raportu systemowego, ale tylko dla obiektów, do których ma zdolności (użytkownicy nie widzą raportów innych użytkowników).

    • Ma dostęp do zakładki Uwierzytelnianie, co umożliwia administratorom przeglądanie i przypisywanie metod uwierzytelniania zewnętrznego.

    • Ma dostęp do zakładki Zewnętrzne repozytoria haseł, aby przypisywać repozytoria do kont.

    • Ma dostęp do zakładki Cluster, aby przekazywać sesje do innych węzłów.

    • Nie ma dostępu do pozostałych podzakładek zakładki Ustawienia.

  • Admin – Posiada uprawnienia zbliżone do wcześniejszej roli admin sprzed wprowadzenia RBAC. Rola ta jest automatycznie mapowana na podstawie wcześniejszej konfiguracji. Wybrane przykładowe uprawnienia:

    • Ma dostęp do Dashboardu i jego widżetów, zależnie od przypisanych zdolności.

    • Może tworzyć nowe obiekty, takie jak użytkownicy, grupy, serwery, konta, pule i sejfy. Twórca automatycznie otrzymuje pełne zdolności do utworzonych obiektów.

    • Może zarządzać użytkownikami, grupami, serwerami, kontami, pulami i sejfami do których ma przypisane zdolności.

    • Nie może tworzyć listenerów.

    • Może tworzyć użytkowników i podglądać przypisane im role, ale nie może przypisywać ról (wymagane uprawnienie role-modify).

    • Może zarządzać powiadomieniami i je przeglądać dla użytkowników, do których ma przypisane zdolności.

    • Może widzieć stopkę Panelu administratora oraz uzyskać dostęp do Menu użytkownika w prawym górnym rogu.

    • Może przeglądać i odtwarzać sesje powiązane z dostępnymi obiektami, zarządzać retencją, usuwać sesje w swoim zakresie, korzystać z funkcji zawartych w uprawnieniu session-modify (Uprawnienia do zakładki Sesje), a także kodować, udostępniać, komentować, kończyć, eksportować i dołączać do sesji.

    • Może przeglądać i głosować w oczekujących, aktywnych i zarchiwizowanych żądaniach powiązanych z obiektami, do których ma dostęp.

    • Może tworzyć i zarządzać modyfikatorami haseł, weryfikatorami i politykami haseł.

    • Może tworzyć i zarządzać aplikacjami zdalnymi.

    • Może tworzyć i zarządzać politykami oraz podglądać wyrażenia regularne.

    • Może generować raporty z zakładki Sesje.

    • Może zarządzać subskrypcjami raportów.

    • Może ręcznie dodać subskrypcję do Raportu systemowego, ale tylko dla obiektów, do których ma zdolności.

    • Ma dostęp do zakładki Uwierzytelnianie, co umożliwia przypisywanie metod uwierzytelniania zewnętrznego.

    • Ma dostęp do zakładki Zewnętrzne repozytoria haseł, aby przypisywać repozytoria do kont.

    • Ma dostęp do zakładki Cluster, aby przekazywać sesje do innych węzłów.

    • Nie ma dostępu do pozostałych podzakładek zakładki Ustawienia.

  • Session Viewer – Ma uprawnienia zbliżone do wcześniejszej roli session viewer sprzed wprowadzenia RBAC. Rola ta jest automatycznie mapowana na podstawie wcześniejszej konfiguracji. Wybrane przykładowe uprawnienia:

    • Może przeglądać listę sesji i ich szczegóły, ograniczone do sesji powiązanych z obiektami, do których ma uprawnienia.

    • Może odtwarzać sesje zarchiwizowane i na żywo, ograniczone do dostępnych obiektów (zobacz również: Uprawnienia do zakładki Sesje).

    • Może dołączać do sesji, kończyć je, komentować oraz kodować, jeśli ma dostęp do odpowiednich obiektów.

    • Ma dostęp do stopki Panelu administratora.

    • Nie może modyfikować konfiguracji związanej z sesjami (np. retencji, ustawień kodowania itp.).

    • Ma dostęp do zakładki Pliki i może pobierać dostępne pliki powiązane z sesjami, do których ma uprawnienia.

  • Safes Admin – Posiada uprawnienia zbliżone do roli admin, z wyjątkiem dostępu do modyfikatorów haseł i polityk haseł. Dodatkowo nie ma dostępu do konfiguracji klastra ani widgetów. Wybrane przykładowe uprawnienia:

    • Nowo utworzony użytkownik z tą rolą nie zobaczy żadnych obiektów, dopóki nie zostaną mu jawnie przypisane zdolności do istniejących obiektów.

    • Ma dostęp do Dashboardu i jego widżetów, w zależności od przypisanych zdolności.

    • Może tworzyć nowe obiekty, takie jak użytkownicy, grupy, serwery, konta, pule i sejfy. Twórca otrzymuje pełne uprawnienia do utworzonych obiektów.

    • Może podglądać wszystkie role, grupy, użytkowników i konta.

    • Może zarządzać użytkownikami, grupami, serwerami, kontami, pulami i sejfami do których ma przypisane zdolności.

    • Nie może tworzyć listenerów.

    • Może tworzyć użytkowników i podglądać przypisane im role, ale nie może przypisywać ról użytkownikom (wymagane uprawnienie role-modify).

    • Może przeglądać i zarządzać powiadomieniami użytkowników, do których ma przypisane zdolności.

    • Ma dostęp do stopki Panelu administratora oraz Menu użytkownika w prawym górnym rogu.

    • Może przeglądać i odtwarzać sesje powiązane z dostępem, zarządzać retencją, usuwać sesje w swoim zakresie, korzystać z funkcji uprawnienia session-modify (Uprawnienia do zakładki Sesje), kodować, udostępniać, komentować, kończyć, eksportować i dołączać do sesji.

    • Może przeglądać i głosować w oczekujących, aktywnych i zarchiwizowanych żądaniach dotyczących obiektów, do których ma dostęp.

    • Może podglądać modyfikatory haseł, weryfikatory i polityki haseł.

    • Może tworzyć i zarządzać aplikacjami zdalnymi.

    • Może podglądać polityki i wyrażenia regularne.

    • Może generować raporty z zakładki Sesje.

    • Może zarządzać subskrypcjami raportów.

    • Może ręcznie zapisać się na Raport systemowy, ale dostęp będzie ograniczony do obiektów, do których ma zdolności (użytkownicy nie widzą raportów innych).

    • Ma dostęp do zakładki Uwierzytelnianie, aby przypisywać metody uwierzytelniania zewnętrznego użytkownikom.

    • Ma dostęp do zakładki Zewnętrzne repozytoria haseł, aby przypisywać je kontom.

    • Ma dostęp do zakładki Cluster, aby przesyłać sesje do innych węzłów.

    • Nie ma dostępu do pozostałych podzakładek zakładki Ustawienia.

  • Auditor – Rola tylko do odczytu z wglądem we wszystkie obszary systemu. Pod względem zakresu zbliżona do roli superadmin, ale bez możliwości edycji istniejących obiektów ani tworzenia nowych.

Należy pamiętać, że istnieją wyjątki i mapowanie nie zawsze odwzorowuje wcześniejsze role jeden do jednego. Wybrane przykłady:

  • Po aktualizacji administrator posiadający przypisane zdolności do obiektu automatycznie otrzymuje pełne uprawnienia do tego obiektu.

  • Ponieważ listenery są traktowane jako globalna i sieciowa konfiguracja, po aktualizacji do wersji 5.6 użytkownicy admin nie mają już uprawnień do ich tworzenia.

  • Role admin, safes admin i operator zawierają domyślnie uprawnienie extauth-read, by móc przypisywać metody uwierzytelniania zewnętrznego użytkownikom.

  • Role admin, safes admin i operator zawierają domyślnie uprawnienie passvn-read, by móc przypisywać zewnętrzne repozytoria haseł kontom.

  • Role admin, safes admin i operator zawierają domyślnie uprawnienie cluster-read, by móc przesyłać sesje do innych węzłów.

  • Rola operator zawiera domyślnie listener-read. W wyniku zmian RBAC operatorzy obecnie widzą wszystkich listenerów, nie tylko tych jawnie przypisanych.

  • Zmiana modelu dostępu do listenerów – użytkownik ma albo dostęp do wszystkich listenerów, albo do żadnego. Nie można już przypisywać dostępu do pojedynczych listenerów.

  • Można ręcznie dodać subskrypcję tego typu raportu, ale będzie ona ograniczona do obiektów, do których użytkownik ma zdolności.

  • Mają dostęp do następujących widżetów dashboardu: sesje równoczesne, podejrzane sesje, wykres sesji równoczesnych, widżet „Aktywni użytkownicy” oraz „Alerty dotyczące kont”.

  • Mają teraz dostęp do zakładki Pobieranie > Pliki i mogą pobierać tam wymienione pliki. Uprawnienie to jest wymagane do prawidłowego wyświetlania sesji SFTP/SCP.

  • Rola session viewer ma teraz dostęp do dodatkowych elementów interfejsu, w tym nowych zakładek oraz możliwość dodania widżetu Aktywni użytkownicy z marketplace’u widżetów. Odzwierciedla to rozszerzone uprawnienia w nowej macierzy dostępu.

Uwaga

  • Rola superadmin jest chroniona i nie można jej modyfikować ani usuwać. Dotyczy to:

    • Edycji jej uprawnień i zdolności,

    • Zmiany nazwy lub dezaktywacji roli,

    • Całkowitego usunięcia roli.

  • Ograniczenie to gwarantuje, że system zawsze będzie miał przynajmniej jedną rolę z nieograniczonym dostępem administracyjnym.

  • System wymusza, aby przynajmniej jeden użytkownik zawsze miał przypisaną rolę superadmin.

Ostrzeżenie

  • Predefiniowana rola user została usunięta z systemu. Po aktualizacji do wersji 5.6 wszyscy użytkownicy, którzy mieli tę rolę, nie będą mieli przypisanej żadnej roli.

  • Predefiniowana rola service została usunięta z systemu.

    • Przed aktualizacją klienci, którzy mieli przypisanych wielu użytkowników do roli service, muszą usunąć wszystkich poza jednym.

    • Ustawienia SNMP skonfigurowane wcześniej dla tego użytkownika zostaną przeniesione do zakładki System i zastosowane globalnie.

Zobacz także: