• 03/30/2017
• 6 minut na przeczytanie
• • g
  • D
  • m
  • Y

  .

  • s
  • +8

Bezpieczeństwo obejmuje trzy współdziałające elementy: sandboxing, uprawnienia i egzekwowanie. Sandboxing odnosi się do praktyki tworzenia izolowanych domen, gdzie część kodu jest traktowana jako w pełni zaufana, a inny kod jest ograniczony do uprawnień w zestawie grantów dla piaskownicy. Kod aplikacji, który działa w ramach zestawu uprawnień piaskownicy jest uważany za przezroczysty, to znaczy, że nie może wykonywać żadnych operacji, które mogą wpływać na bezpieczeństwo. Zestaw uprawnień dla piaskownicy jest określany na podstawie dowodów (klasa Evidence). Dowody określają jakie konkretne uprawnienia są wymagane przez piaskownice oraz jakie rodzaje piaskownic mogą być tworzone. Enforcement odnosi się do zezwalania przezroczystemu kodowi na wykonywanie tylko w ramach jego zestawu uprawnień.

Cel modelu przejrzystości

Przejrzystość jest mechanizmem wykonawczym, który oddziela kod działający jako część aplikacji od kodu działającego jako część infrastruktury. Przezroczystość rysuje barierę między kodem, który może robić rzeczy uprzywilejowane (kod krytyczny), takie jak wywoływanie kodu natywnego, a kodem, który nie może tego robić (kod przezroczysty). Kod przezroczysty może wykonywać polecenia w granicach zestawu uprawnień, w którym działa, ale nie może wykonywać, pochodzić z, ani zawierać kodu krytycznego.

Podstawowym celem egzekwowania przezroczystości jest zapewnienie prostego, efektywnego mechanizmu izolowania różnych grup kodu na podstawie przywilejów. W kontekście modelu piaskownicy, te grupy uprawnień są albo w pełni zaufane (czyli bez ograniczeń) albo częściowo zaufane (czyli ograniczone do zestawu uprawnień przyznanych piaskownicy).

Przejrzystość została wprowadzona w .NET Framework w wersji 2.0 w celu uproszczenia modelu zabezpieczeń oraz ułatwienia pisania i wdrażania bezpiecznych bibliotek i aplikacji. Przezroczysty kod jest również używany w Microsoft Silverlight, aby uprościć tworzenie częściowo zaufanych aplikacji.

Określanie poziomu przejrzystości

Atrybut SecurityRulesAttribute na poziomie zespołu jednoznacznie wybiera reguły SecurityRuleSet, których zespół będzie przestrzegał. Reguły są zorganizowane w systemie poziomów numerycznych, gdzie wyższe poziomy oznaczają bardziej rygorystyczne egzekwowanie reguł bezpieczeństwa.

Poziomy są następujące:

• Poziom 2 (Level2) – reguły przejrzystości .NET Framework 4.

• Poziom 1 (Level1) – reguły przejrzystości .NET Framework 2.0.

Podstawową różnicą między tymi dwoma poziomami przezroczystości jest to, że poziom 1 nie wymusza reguł przezroczystości dla wywołań spoza złożenia i jest przeznaczony tylko dla kompatybilności.

Przezroczystość poziomu 2

Przezroczystość poziomu 2 została wprowadzona w .NET Framework 4. Trzy założenia tego modelu to kod przezroczysty, kod krytyczny pod względem bezpieczeństwa i kod krytyczny pod względem bezpieczeństwa.

• Kod przezroczysty, niezależnie od przyznanych mu uprawnień (w tym pełnego zaufania), może wywoływać tylko inny kod przezroczysty lub kod krytyczny pod względem bezpieczeństwa. Jeśli kod jest częściowo zaufany, może wykonywać tylko akcje, które są dozwolone przez zestaw uprawnień domeny. Kod przezroczysty nie może wykonywać następujących czynności:

  • Wykonać operacji asercji lub podniesienia uprawnień.

  • Zawierać niebezpiecznego lub nieweryfikowalnego kodu.

  • Bezpośrednie wywołanie krytycznego kodu.

  • Wywołanie natywnego kodu lub kodu, który ma atrybut SuppressUnmanagedCodeSecurityAttribute.

  • Wywołaj członka, który jest chroniony przez LinkDemand.

  • Dziedziczy po typach krytycznych.

    Dodatkowo, metody transparentne nie mogą nadpisywać krytycznych metod wirtualnych ani implementować krytycznych metod interfejsu.

• Kod krytyczny bezpieczny jest w pełni zaufany, ale jest wywoływany przez kod transparentny. Odsłania on ograniczoną powierzchnię kodu w pełni zaufanego. Weryfikacje poprawności i bezpieczeństwa zachodzą w kodzie bezpiecznym.

• Kod krytyczny pod względem bezpieczeństwa może wywoływać dowolny kod i jest w pełni zaufany, ale nie może być wywoływany przez kod przezroczysty.

Przejrzystość poziomu 1

Model przejrzystości poziomu 1 został wprowadzony w .NET Framework w wersji 2.0, aby umożliwić programistom zmniejszenie ilości kodu, który podlega audytowi bezpieczeństwa. Chociaż poziom 1 przezroczystości był publicznie dostępny w wersji 2.0, był on głównie używany tylko w firmie Microsoft do celów audytu bezpieczeństwa. Poprzez adnotacje, programiści są w stanie zadeklarować, które typy i członkowie mogą wykonywać podniesienia zabezpieczeń i inne zaufane akcje (security-critical), a które nie (security-transparent). Kod, który jest określony jako przezroczysty, nie wymaga wysokiego stopnia audytu bezpieczeństwa. Poziom 1 przejrzystości określa, że egzekwowanie przejrzystości jest ograniczone do wnętrza zespołu. Innymi słowy, wszelkie publiczne typy lub członkowie, którzy są określeni jako krytyczni pod względem bezpieczeństwa, są krytyczni pod względem bezpieczeństwa tylko wewnątrz zespołu. Jeśli chcesz wymusić bezpieczeństwo dla tych typów i członków, gdy są one wywoływane spoza zespołu, musisz użyć żądań łącza dla pełnego zaufania. Jeśli tego nie zrobisz, publicznie widoczne typy i członkowie krytyczni pod względem bezpieczeństwa są traktowani jako krytyczni pod względem bezpieczeństwa i mogą być wywoływani przez częściowo zaufany kod spoza zespołu.

Model przejrzystości poziomu 1 ma następujące ograniczenia:

• Typy i członkowie krytyczni pod względem bezpieczeństwa, którzy są publiczni, są dostępni z kodu transparentnego pod względem bezpieczeństwa.

• Adnotacje przejrzystości są egzekwowane tylko w obrębie zespołu.

• Typy i członkowie krytyczni pod względem bezpieczeństwa muszą używać żądań powiązań w celu wymuszenia bezpieczeństwa dla wywołań spoza zespołu.

• Reguły dziedziczenia nie są egzekwowane.

• Istnieje możliwość, że przezroczysty kod może robić szkodliwe rzeczy, gdy jest uruchomiony w pełnym zaufaniu.

Wymuszanie przejrzystości

Reguły przejrzystości nie są egzekwowane, dopóki przejrzystość nie zostanie obliczona. W tym czasie, wyjątek InvalidOperationException jest rzucany, jeśli reguła przezroczystości jest naruszona. Czas, w którym obliczana jest przezroczystość zależy od wielu czynników i nie można go przewidzieć. Jest ona obliczana tak późno, jak to tylko możliwe. W .NET Framework 4 obliczanie przezroczystości na poziomie zespołu odbywa się wcześniej niż w .NET Framework 2.0. Jedyną gwarancją jest to, że obliczenie przezroczystości nastąpi w momencie, gdy będzie ono potrzebne. Jest to podobne do tego, w jaki sposób kompilator just-in-time (JIT) może zmienić moment, w którym metoda jest kompilowana, a ewentualne błędy w tej metodzie są wykrywane. Obliczenia przezroczystości są niewidoczne, jeśli twój kod nie ma żadnych błędów przezroczystości.

Zobacz także

• Kod przezroczysty, poziom 1
• Kod przezroczysty, poziom 2

.