Czytając o ACL i RBAC, wydaje mi się, że łatwo to rozumiem - istnieją nazwy użytkowników lub role, które mają dostęp do zasobu. Widzę też, jak mogłem je wdrożyć.

tj. ten obraz daje mi jasny widok ACL i RBAC dla mnie (tak jak mogę przejść i zaprojektować tabele bazy danych na podstawie powyższego): (Zdjęcie dzięki uprzejmości podręczników )

Mam problem z ABAC. Różne obrazy, które do tej pory znalazłem, są ręcznie falowane lub nadmiernie skomplikowane, lub sugerują użycie zewnętrznego podmiotu zewnętrznego do autoryzacji. Lub podaj dziwne przykłady atrybutów, których nie jestem do końca pewien, jak ich używać.

Przykład początkowy

Zacznę więc od czegoś w prawdziwym życiu. Powiedzmy, że mam firmę zatrudniającą 70-200 osób. A moim atutem do ochrony jest strona internetowa z wieloma różnymi stronami. Chcę umożliwić niektórym osobom dostęp do niektórych zasobów.

Na przykład chcę, Leslieaby osoba miała dostęp do strony o nazwie Price Manageri pozwalała jej zarządzać cenami tylko dla Travelgrupy cenowej na tej stronie, ale nie mogła zarządzać cenami dla Productgrupy na tej samej stronie. Jak mam to zaimplementować za pomocą ABAC?

Grzebiąc do tej pory, domyślam się, że mógłbym przypisać Leslieniektóre atrybuty (ale które i jakie są te atrybuty?), A następnie mieć tabelę bazy danych, która je przechowuje. Następnie mogę zaprojektować silnik, który będzie przeglądał te atrybuty (ale nie będzie postrzegany Lesliejako „rola”, jak ma to miejsce w RBAC) i stamtąd decyduje, czy przyznać dostęp do strony. Jak wyglądałby ten silnik? Czy jest to prosty blok if / else? Coś innego?

Co się stanie, jeśli Leslie później zmieni pozycję i ktoś będzie musiał zmienić jej dostęp? Jak to będzie wyglądać, jeśli będzie potrzebować przeniesienia Producti odebrania dostępu Travel? W jaki sposób zostanie zakodowany, jeśli będzie musiała Price Managercałkowicie odwołać dostęp do strony, a zatem nie będzie już miała dostępu do żadnej z nich Travelani Product?

Atutem w moim przypadku jest, aby go odtworzyć Price Manager, a użytkownik może uzyskać dostęp do różnych grup cen na tej stronie, takich jak Travelceny, Productceny itp.

To, czego szukam, to dość kompletna mapa drogowa mająca na celu wyjaśnienie szczegółów i wdrożenie w miejscu, w którym mógłbym rozpocząć i wdrożyć go bez zgadywania. tzn. można go zrealizować koncepcyjnie i / lub podać konkretny przykład, w którym mogę wizualizować strukturę bazy danych itp.

Premia: Czy ABAC to właściwy sposób na względnie małe potrzeby uzyskania zezwolenia, tj. Zarządzanie 70-200 osobami i dostęp do około 150 - 450 aktywów? Czy lepiej będzie trzymać się ACL / RBAC?

Implementacja ABAC jest bardziej złożona niż ACL / RBAC. Niektóre frameworki oferują nawet trochę infrastruktury do radzenia sobie z tym drugim. Jeśli osoby i zasoby można zgrupować w relatywnie małą i stałą liczbę ról / kategorii, prawdopodobnie najlepiej trzymać się ACL / RBAC. Jeśli uprawnienia różnią się znacznie w zależności od osoby, ABAC może zapewnić lepsze i bardziej elastyczne rozwiązanie.

Jeśli zdecydujesz się pójść ścieżką ABAC, pierwszą rzeczą, którą musisz zrobić, to poświęcić trochę czasu na przeczytanie i zrozumienie standardu XACML . Przykłady podane w dokumencie używają składni zgodnej z XACML i początkowo są trochę trudne do przeżuwania. Zgaduję, że nie chcesz wdrożyć standardowego kompatybilnego rozwiązania, więc potrzebujesz tylko ogólnych pomysłów.

Pojęcia

XACML obraca się wokół 4 pojęć i ich atrybutów: tematów , działań , zasobów i środowiska . Jest jeszcze kilka, ale te są najważniejsze. Wszystko inne jest na nich zbudowane. Gdybym miał wypowiedzieć się na podstawie tych pojęć, mogłoby to być coś w stylu: podmioty wykonują działania na zasobach w określonym środowisku . Zastosowanie tego w scenariuszu przekładałoby się na coś takiego:

• Leslie otwiera stronę internetową menedżera cen.
• Leslie tworzy cenę podróży, korzystając ze strony internetowej menedżera cen.

Kolekcja atrybutów

Pierwszą rzeczą, którą musimy zrobić, to zebrać odpowiednie atrybuty pojęć wymienionych powyżej. Idealnie nie powinieneś przypisywać żadnych konkretnych atrybutów, ponieważ XACML stara się być dyskretny i polegać tylko na tym, co system naturalnie zapewnia. Mamy więc:

Przedmiot

Każdy aktor, czy to osoba, czy usługa, w twoim systemie. Naszym przedmiotem jest Leslie. Jakie atrybuty są wymagane do jednoznacznej identyfikacji Leslie? Prawdopodobnie niektóre z następujących: first name, last name, e-mail, ssn, company id, position(s).

Akcja

Wszelkie działania wykonywane przez badanych. Mogą to być standardowe operacje CRUD lub coś bardziej złożonego. Nasze działania to open/viewi create. Atrybuty tych działań mogą się różnić w zależności od używanego środowiska aplikacji WWW. Porozmawiamy o tym więcej, gdy dotrzemy do zasobu.

Ratunek

Dość oczywiste. Nasze zasoby są price manager page, travel pricesi the newly created price. Może być więcej, jeśli naprawdę chcesz. Możesz ukryć działania, których użytkownicy nie mogą wykonać. Na przykład. create price buttonmoże być zasobem, który może być pokazany / ukryte na podstawie tego, czy użytkownik ma uprawnienia do tworzenia cen. Ponieważ jedynym sposobem, w jaki użytkownik może zobaczyć listę cen, może być przejście przez tę stronę, prawdopodobnie dobrym pomysłem byłoby wymuszenie autoryzacji na tym poziomie, a nie na dalszych etapach.

Dostęp do zasobów jest najbardziej skomplikowany do wdrożenia, szczególnie w przypadku tych, które pochodzą z bazy danych. Bardziej szczegółową opcją jest bezpieczeństwo na poziomie wiersza. Niektóre bazy danych obsługują go w pewnym stopniu. Niektóre implementatory XACML posunęły się nawet do utworzenia kontrolki SQL. To naprawdę zależy od twoich potrzeb związanych z autoryzacją, ale jedyne, czego nie chcesz robić, to wyciągnąć wszystko ze stołu, a następnie zdecydować, co pokazać. Możesz grupować zasoby według zestawów uprawnień, wyodrębniać je za interfejsem API i wymuszać autoryzację w punktach końcowych interfejsu API.

Środowisko

Nie mogę go poprawnie zdefiniować (XACML również nie ma właściwej definicji), ale powiedzmy, że to „bańka”, w której wszystko to się dzieje. Obejmuje to: web application, web server, operating system, browser, office. Można wyodrębnić cechy jak: ip address, time of day, user locale, user agent, operating system version. Możesz ich użyć, aby nawet zablokować dostęp użytkowników ze środowisk, które nie są obsługiwane przez twoją aplikację (np. Stare przeglądarki, stare systemy operacyjne, komputery spoza twojej sieci, dostęp poza godzinami pracy).

Żądanie autoryzacji

Po zebraniu wszystkich niezbędnych atrybutów łączymy je w żądanie autoryzacji i przekazujemy je podmiotowi, który może podejmować decyzje autoryzacyjne na podstawie wartości tych atrybutów. W języku XACML lingua miejsce, w którym zbierasz te atrybuty i egzekwujesz podjęte decyzje, nazywa się punktem egzekwowania polityki (PEP), a decyzje podejmujące decyzję nazywa się punktem decyzji politycznej (PDP). Lokalizacje, z których uzyskiwane są wartości atrybutów, nazywane są punktami informacyjnymi polityki (PIP). PEP, PDP i PIP mogą być częścią twojego zastosowania, mogą to być systemy zewnętrzne. Możesz znaleźć schemat, w jaki sposób komunikują się ze sobą w standardzie XACML.

Proces decyzyjny

Proces decyzyjny oparty jest na zasadach . Reguły można pogrupować w polityki, które można dalej pogrupować w zestawy polityk . Każdy z nich ma cel . Cel służy do decydowania, czy którakolwiek z reguł ma zastosowanie do żądania autoryzacji. Pomyśl o tym jak o filtrze. Cel zawiera warunki zbudowane przy użyciu nazw i wartości atrybutów. Na przykład reguły aplikacji można pogrupować w coś takiego:

Aplikacja internetowa (zestaw zasad)
| - target: application-name == "Aplikacja internetowa"
`- Wersja 1.0 (zestaw zasad)
    | - target: wersja aplikacji == "1.0"
    `- Zobacz menedżera cen (zasady)
        | - target: web-page-name == "menedżer cen" && action-name == "view"
        `- Leslie może wyświetlić menedżera cen (reguła)
            | - target: subject-name == "Leslie"
            `- pozwolenie: zezwól

PDP dopasuje wszystko w powyższym zestawie do wartości atrybutów w żądaniu autoryzacji. Co się stanie, jeśli nie ma pasujących do niego reguł, zależy od wdrożenia PDP. Gdy PDP podjęła decyzję ( allow, denylub not-applicable) wysyła go z powrotem do PEP, która działa na niego poprzez przyznanie lub odmowę dostępu do zasobu. Wraz z odpowiedzią PDP może wysłać listę obligationsi advicesże moszczu PEP lub powinny spełniać w procesie egzekwowania. W zależności od sposobu przechowywania reguł (plików tekstowych lub bazy danych) administrator może użyć standardowego edytora tekstu lub niestandardowej aplikacji do edycji, aby zmienić je według własnego uznania. Cofnięcie dostępu Leslie do menedżera cen wznawia się po prostu zmieniając uprawnienia z allownadeny, pod warunkiem, że PEP wykonuje swoją pracę.

Egzekwowanie

Jest to wysoce zależne od stosu technologii. Niektóre frameworki mają naturalne punkty wymuszania (np. ASP.NET MVC ma filtry atrybutów). Twoje warstwy biznesowe mogą wymagać zdefiniowania takich punktów egzekwowania. Odkryłem, że łatwiej jest stosować wymuszanie na punktach końcowych usługi (na przykład w mikrousługach) lub na poziomie interfejsu użytkownika.

Inne korzyści

Przyjemnym efektem ubocznym wdrożenia tego jest to, że otrzymujesz dość bogatą ścieżkę audytu, którą można wykorzystać do innych celów.