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.
(Zdjęcie dzięki uprzejmości podręczników )