Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
W wielu scenariuszach zabezpieczenia oparte na rolach są bardzo skutecznym mechanizmem, ale istnieją sytuacje, w których jest mniej skuteczna. Podczas podejmowania decyzji o miejscu i sposobie stosowania zabezpieczeń opartych na rolach do określonej aplikacji należy wziąć pod uwagę wiele czynników.
Charakterystyka użytkowników i danych oraz użyteczność ról
Role działają bardzo dobrze, aby scharakteryzować grupy użytkowników i, na tej podstawie, filtrować akcje, które mogą wykonywać ci użytkownicy. Często odbywa się to w praktyce przez utworzenie ról, które odzwierciedlają miejsce użytkownika w organizacji — na przykład role "Menedżerowie" i "Tellers", "Administratorzy" i "Czytelnicy", "Project One Employees" i "Project Two Employees". W takich przypadkach, gdy dostęp do danych jest dość ogólny względem użytkowników, role mogą być efektywnie używane do wymuszania reguł biznesowych, takich jak następujące:
"Menedżerowie mogą przenieść dowolną kwotę pieniędzy. Kasjerzy mogą przetransferować tylko do 10 000 dolarów.
"Administratorzy mogą zmienić wszystko. Wszyscy inni mogą tylko czytać.
"Pracownicy programu Project One mogą uzyskiwać dostęp do określonej bazy danych. Nikt inny nie może."
Użytkownicy mogą naturalnie należeć do wielu ról, w zależności od tego, jak role modelują strukturę organizacyjną firmy.
Jednak role nie działają zbyt dobrze, gdy decyzja o dostępie do zabezpieczeń opiera się na cechach określonego elementu danych. Na przykład trudno byłoby użyć ról do odzwierciedlenia skomplikowanych relacji danych użytkownika, takich jak następujące:
"Konkretny menedżer może uzyskiwać dostęp do danych personelu tylko dla swoich raportów".
"Joe Consumer może wyszukać swoje saldo konta."
W takich przypadkach sprawdzanie zabezpieczeń musi być często przeprowadzane w samej bazie danych, gdzie łatwiej jest uwzględnić cechy wrodzone danych, do których uzyskuje się dostęp. Oznacza to, że musisz użyć uwierzytelniania, aby przekazać tożsamość klienta do bazy danych i pozwolić bazie danych zweryfikować żądanie. Może to mieć wpływ na wydajność i może mieć wpływ na projekt aplikacji — na przykład buforowanie połączeń może nie działać, gdy połączenie zostanie otwarte w ramach określonej tożsamości użytkownika. Aby zapoznać się z omówieniem problemów, zobacz Wielowarstwowe zabezpieczenia aplikacji oraz Personifikacja klienta i delegowanie.
Złożoność i skalowalność zasad autoryzacji Role-Based
Jakakolwiek polityka bezpieczeństwa zostanie wdrożona, będzie tylko tak skuteczna, jak jej implementacja przez administratorów systemu odpowiedzialnych za wdrożenie aplikacji. Jeśli administratorzy popełniają błędy podczas przypisywania użytkowników do odpowiednich ról zgodnie z zasadami zabezpieczeń, zasady nie będą działać zgodnie z oczekiwaniami. Problemy najprawdopodobniej wystąpią w następujących okolicznościach:
- Utworzono bardzo skomplikowaną politykę opartą na rolach, z wieloma rolami i użytkownikami przypisującymi do wielu ról.
- Tworzysz role z niejednoznacznymi kryteriami dotyczącymi tego, kto powinien do nich należeć.
- Istnieje wielu użytkowników w miejscu, w którym zainstalowano aplikację, a użytkownicy często przemieszczają się w organizacji, zmieniając role, które zostały utworzone.
- Istnieje wielu administratorów w miejscu, w którym zainstalowano aplikację, z podziałem obowiązków, przez co administrator zaznajomiony z wymaganiami dotyczącymi zabezpieczeń aplikacji może nie być zaznajomiony z dużymi grupami użytkowników, którzy muszą z niej korzystać. Jest to szczególnie istotne, ponieważ użytkownicy zmieniają pozycję w organizacji — takie informacje muszą być dobrze przekazywane.
Ponadto, w miarę zwiększania się liczby ról przypisanych do aplikacji, COM+ musi poświęcać więcej czasu na wyszukanie członkostwa wywołującego w tych rolach, co prawdopodobnie prowadzi do obniżenia wydajności.
Aby zarządzać złożonością i ograniczyć te problemy, możesz użyć następujących wskazówek:
- Wybierz nazwy ról, które są samoopisowe. Uczyń jak najoczywistszym, do których ról powinni należeć użytkownicy.
- Uprość swoją politykę opartą na rolach (ale nie bardziej niż to konieczne). Wybierz tak mało ról, jak to możliwe, przy zachowaniu obowiązujących zasad.
- Udokumentuj jasno zasady ról, które tworzysz dla administratorów, bez względu na to, czy członkostwo w rolach jest oczywiste dla was. W szczególności użyj pola opisu dostępnego dla każdej roli, aby opisać intencję roli. Jeśli nie możesz opisać ogólnie, kto powinien należeć do roli w kilku zdaniach, prawdopodobnie jest to zbyt skomplikowane.
- Zdecydowanie zaleca się, aby administratorzy aplikacji wypełniali role grupami użytkowników, a nie poszczególnymi użytkownikami. Jest to o wiele bardziej skalowalne rozwiązanie. Ułatwia ponowne przypisywanie lub usuwanie użytkowników w miarę przenoszenia się w organizacji i izolowanie administratorów od pewnego nadzoru i problemów w komunikacji.
Tematy pokrewne