Technicznie jest to bardzo przydatne, ponieważ pozwala na bardzo drobnoziarnistą specyfikację uprawnień. Jest to zarówno dobre dla Ciebie (teoretycznie utrudnia to wykorzystywanie luk w zabezpieczeniach - nawet jeśli atakujący uzyska pełną kontrolę nad twoją aplikacją, nadal jest zablokowany w piaskownicy CAS), jak i dla Twojego klienta (ponieważ może dokładnie zobaczyć, co może zrobić Twoja aplikacja i uruchomić własny audyt bezpieczeństwa).

W praktycznym użyciu jest w większości bez znaczenia. Myślę, że to zbyt skomplikowane, zbyt mało obsługiwane przez dostępne narzędzia dev i większość użytkowników i tak nie obchodzi.

Są oczywiście wyjątki (rządy i klienci, którzy naprawdę znają. NET/CAS) i chciałbym powiedzieć, że CAS jest absolutnie przydatny i obowiązkowy, ale rzeczywistość mówi jasnym językiem.

Uwaga dla czytelnika: zobacz dwa komentarze poniżej; wygląda na to, że przypadkowo zawyżam definicję CAS, aby (niepoprawnie) zawierała RBS. Zostawię tutaj odpowiedź dla odniesienia, ale zwróć uwagę na rozróżnienie.

Są dwie havle do CAS; rzecz, którą najbardziej zobaczysz w tym egzaminie to wszystkie niuanse dla kodu wywołującego inny kod, który może być przydatny do częściowego zaufania , ale przez większość czasu jest to po prostu ból - i co gorsza: jeśli twój kod ma pełne zaufanie (co robi większość / zbyt wiele) żadna z nich nie wykonuje (jest pomijana całkowicie).

użyteczna Część CAS RBS jest głównym uprawnieniem, które jest używane; oczywiście, twój interfejs powinien zweryfikować dostęp do funkcji, ale możesz umieścić (w logice low-down):

[PrincipalPermission(SecurityAction.Demand, Role = "ADMIN")]
static void DeleteOrder(int id) { ... }

Będzie to egzekwowane nawet przy pełnym zaufaniu; możesz zdefiniować swój własny principal (powiązany z użytkownikiem) poprzez implementację IPrincipal (Spójrz na IsInRole()). A ponieważ dyrektorzy są wspierani w większości środowiska (winforms, webforms, mvc, wcf itp.) może to być bardzo elastyczny sposób na podwójne sprawdzenie zabezpieczeń w warstwie biznesowej bez konieczności odwoływania się do określonego modelu zabezpieczeń. Zauważ, że powyższe sprawdzenie działa w dowolnym środowisku .

Możesz również użyć tego do kierowania interfejsem użytkownika. Miałem post usenetowy, który włączał / wyłączał kontrolki winforms w oparciu o principal (używając właściwości runtime do określenia roli dla kontrolki, trochę jak ToolTip etc) - nie mogę go znaleźć w tej chwili, chociaż (edit: może ten).

Rzeczą do zrozumienia o zabezpieczeniu dostępu do kodu jest to, że jest on bardzo mało przydatny dla programisty aplikacji poza zrozumieniem, w jaki sposób jest używany i na jakim poziomie uprawnień dla API, które możesz wywoływać. Jedynym wyjątkiem od tego, który naprawdę uważam za przydatny, jest CAS o nazwie PrincipalPermission, który w zasadzie nie pozwala na wykonanie określonego kodu, jeśli właściwa rola nie jest zdefiniowana dla bieżącego głównego. Zobacz ten post na it:

Http://www.coderjournal.com/2008/03/securing-mvc-controller-actions/

Deweloperami, którzy naprawdę muszą zwracać uwagę na CAS i to, jak powinien być zaimplementowany w ich aplikacji, są Programiści frameworku i biblioteki kodu. Ponieważ istnieje pewien poziom zaufania, którego potrzebujesz, aby aplikacja inorder działała szczególnie w przypadku niezarządzanych zasobów, takich jak pliki, strumienie sieciowe, porty szeregowe itp. Lub jeśli tworzysz kod w przypadku tego niezarządzanego zasobu, takiego jak speicalized server, lub jakiegokolwiek dostępu niskiego poziomu do Twoich zestawów, będziesz chciał stworzyć wokół niego zabezpieczenia dostępu do kodu, aby ludzie nie mogli wykonać czegoś, co zostało im surowo odmówione.

Nie pomaga to, że Microsoft nie zrobił tak wielkiej roboty wyjaśniając, jak CAS powinien być używany w codziennej aplikacji. Więc to jest naprawdę powód braku użycia. Jednak CAS jest jednym z wielu powodów, że . NET jest tak bezpiecznym językiem i ma o wiele mniej problemów niż jego konkurenci.

Byłem liderem rozwoju projektu, aby uzyskać certyfikat JITC (Departament Obrony USA) dla rozwiązania opartego na. Net, A ustawienia CAS zostały dokładnie zbadane podczas testów certyfikacyjnych.

Podobnie jak większość innych wymagań certyfikacyjnych, kod mógł korzystać tylko z uprawnień potrzebnych do działania i nie więcej.

Jeśli planujesz uzyskać certyfikaty bezpieczeństwa CAS może być zdecydowanie ważne.

Jedną rzeczą, którą powinieneś wiedzieć, jest to, że zabezpieczenie dostępu do kodu jest w zasadzie zepsute jako metoda zabezpieczania przed manipulacją. Zobacz:

CAS Tamper-Proofing is Broken: Consequences for Software Licensing

...

Bezpieczeństwo dostępu do kodu nie może być już oparte na zapobieganiu użyciu manipulowanych zespołów w wysyłanych produktach. Oznacza to, że jeśli Twoja aplikacja jest zależna od zabezpieczeń dostępu do kodu, aby przeprowadzać kontrole licencji, jest to trywialne dla atakujący zastąpi twój zestaw licencji innym, uzyskując w ten sposób bezpłatny dostęp do Twojej aplikacji.

...

Chociaż nigdy go nie używałem, moje zrozumienie CAS było takie, że można go również wykorzystać do rozszerzenia obiektowej mechaniki projektowania. Załóżmy na przykład, że opracowujesz ogromny pakiet dostępu do danych dla banku, który musi zaimplementować dostęp do bazy danych i buforowanie. Nawet jeśli są one częścią tego samego pakietu wdrażania, biorąc pod uwagę hipotetyczny rozmiar projektu, logika powinna być implementowana w oddzielnych zespołów, ponieważ są one wystarczająco różne zestawy problemów, które zawiasują na różnych siły zewnętrzne (Infrastruktura baz danych a wykorzystanie przez konsumentów).

Jednak kod buforowania może wymagać dostępu do pewnych wrażliwych klas lub metod w zbiorze dostępu do danych, do których konsumenci całego pakietu nie powinni mieć dostępu. Dlatego te klasy i metody dostępu do danych nie mogą być po prostu public. Protected methods in the data access assembly with subclases in the caching assembly może obejść niektóre przypadki, ale często jest to nadużycie dziedziczenia. Może być po prostu bardziej eleganckie jest pozostawienie ich public z LinkDemands umieszczonymi na wywołujących dla niestandardowych uprawnień (np. DataPackagePermisson), które administratorzy przyznaliby tylko zespołowi buforowania.

Użyliśmy CAS dla naszych aplikacji nie było naprawdę trudne, ponieważ staraliśmy się tylko zatrzymać nieautoryzowane wykonywanie kodu. Problemy pojawiły się raz przy użyciu naszego oprogramowania z lokalnego udziału sieciowego, ale Polityka cas wyczyściła problem.

Zabezpieczyliśmy wszystkie nasze zgromadzenia używając silnej nazwy.
1. stworzyliśmy politykę cas dla wszystkich zespołów o naszej silnej nazwie i pozwoliliśmy kodowi podpisanemu naszą silną nazwą zaczynać się od sieci lokalnej i lokalnie umieszczonego kodu.
2. zespoły załadowane z sieci lokalnej wymagające lokalnego dostępu do plików (komponent do nagrywania płyt CD z danymi) potrzebne do uzyskania atrybutu link-demand na wszystkich klasach publicznych.

Od aktualizacji .NET3.5 nasze problemy już nie istniały, ponieważ kod w sieci lokalnej jest teraz obsługiwany jak kod lokalny.