Transparentní kód pro zabezpečení, úroveň 2

Transparentnost druhé úrovně byla představena v rozhraní .NET Framework verze 4. Tři zásady tohoto modelu jsou transparentní kód, bezpečný a kritický kód pro zabezpečení a kód kritický pro bezpečnost.

• Transparentní kód, včetně kódu, který běží jako plně důvěryhodný může volat jiný transparentní kód nebo pouze kód bezpečný a kritický pro zabezpečení. Může provádět pouze akce povolené částečně důvěryhodnou sadou oprávnění náležící doméně (pokud existuje). Transparentní kód nemůže provádět následující:

  • Provádět metodu Assert nebo zvyšovat úroveň oprávnění.

  • Obsahovat nebezpečný nebo neověřitelný kód.

  • Přímo volat kritický kód.

  • Volat nativní kód nebo kód s atributem SuppressUnmanagedCodeSecurityAttribute.

  • Volat člen, který je chráněn pomocí LinkDemand.

  • Dědit z kritických typů.

  Kromě toho transparentní metody nemohou přepsat kritické virtuální metody nebo implementovat kritické metody rozhraní.

• Kód kritický pro zabezpečení je plně důvěryhodný, ale je volatelný transparentním kódem. Poskytuje omezenou plochu povrchu plně důvěryhodného kódu, k ověření správnosti a zabezpečení dochází v kritickém kódu pro zabezpečení.

• Kritický kód pro zabezpečení může volat libovolný kód a je plně důvěryhodný, ale nemůže být volán transparentním kódem.

Toto téma obsahuje následující části:

• Příklady využití a chování

• Vzory přepsání

• Pravidla dědičnosti

• Další informace a pravidla

Příklady využití a chování

Chcete-li specifikovat pravidla rozhraní .NET Framework 4 pravidla (transparentnost druhé úrovně), použijte následující anotaci pro sestavení:

[assembly: SecurityRules(SecurityRuleSet.Level2)]

Chcete-li uzamknout pravidla pro rozhraní .NET Framework 2.0 (transparentnost první úrovně), použijte následující anotaci:

[assembly: SecurityRules(SecurityRuleSet.Level1)]

Pokud jste neanotovali sestavení, jsou automaticky použita pravidla rozhraní .NET Framework 4. Nicméně, doporučený osvědčený postup je použít atribut SecurityRulesAttribute místo závislosti na výchozím nastavení.

Anotace s rozsahem na sestavení

Následující pravidla jsou aplikována na použití atributů na úrovni sestavení:

• Žádné atributy: Pokud nezadáte žádné atributy, modul runtime interpretuje všechen kód jako kritický pro zabezpečení, s výjimkou případů, kde kód kritický pro zabezpečení porušuje pravidlo dědičnosti (například když přepisuje nebo implementuje virtuálně transparentní metodu nebo metodu rozhraní). V těchto případech jsou metody kritické pro bezpečnost. Nezadání žádného atributu způsobuje, že modul CLR (Common Language Runtime) pro vás určuje pravidla transparentnosti.

• SecurityTransparent: Veškerý kód je průhledné; celé shromáždění není nijak výsadní nebo nebezpečné.

• SecurityCritical: Veškerý kód, který je v tomto sestavení zavedený typy je kritický; všechen jiný kód je transparentní. Tento scénář je podobný v tom, že nespecifikuje žádné atributy; ale modul CLR (Common Language Runtime) automaticky neurčuje pravidla transparentnosti. Například pokud přepíšete virtuální nebo abstraktní metodu nebo implementujete metodu rozhraní, tak je tato metoda automaticky transparentní. Metodu musíte explicitně označit jako SecurityCritical nebo SecuritySafeCritical; v opačném případě bude v okamžiku načtení vyvolána výjimka TypeLoadException. Toto pravidlo také platí, pokud je základní i odvozená třída ve stejném sestavení.

• AllowPartiallyTrustedCallers (pouze pro druhou úroveň): Všechen kód je automaticky transparentní. Jednotlivé typy a členy však mohou mít jiné atributy.

Následující tabulka porovnává chování úrovně sestavení (úroveň 2 s úrovní 1).

Atribut sestavení	Úroveň 2	Úroveň 1
Žádný atribut v částečně důvěryhodném sestavení	Typy a členy jsou automaticky transparentní, ale mohou být kritické pro zabezpečení nebo bezpečné a kritické pro zabezpečení.	Všechny typy a členy jsou transparentní.
Žádný atribut	Nezadání žádného atributu způsobuje, že modul CLR (Common Language Runtime) pro vás určuje pravidla transparentnosti. Všechny typy a členy jsou kritické pro zabezpečení, s výjimkou případů, kde typy a členy kritické pro zabezpečení porušují pravidlo dědičnosti.	V plně důvěryhodných sestaveních (v globální mezipaměti sestavení (GAC) nebo identifikovaných jako plně důvěryhodné v AppDomain) jsou všechny typy transparentní a všechny členy bezpečné a kritické pro zabezpečení.
SecurityTransparent	Všechny typy a členy jsou transparentní.	Všechny typy a členy jsou transparentní.
SecurityCritical(SecurityCriticalScope.Everything)	Nelze použít	Všechny typy a členy jsou kritické pro zabezpečení.
SecurityCritical	Veškerý kód, který je v tomto sestavení zavedený typy je kritický; všechen jiný kód je transparentní. Pokud přepíšete virtuální nebo abstraktní metodu nebo implementujete metodu rozhraní, musíte metodu explicitně označit jako SecurityCritical nebo SecuritySafeCritical.	Všechen kód je automaticky transparentní. Jednotlivé typy a členy však mohou mít jiné atributy.

Anotace pro typ a člena

Atributy zabezpečení použité pro určitý typ se rovněž aplikují na členy, které jsou zavedeny typy. Nicméně neaplikují se na přepsanou implementaci virtuální nebo abstraktní základní třídy nebo rozhraní. Následující pravidla se aplikují na použití atributů na úrovni typu a členu:

• SecurityCritical: Typ nebo člen je důležitá a může být vyvolána pouze plnou důvěryhodnost kódu. Metody, které jsou zavedeny v typu kritickém pro zabezpečení jsou kritické.

  Důležité
  Virtuální a abstraktní metody, které jsou zavedené v základních třídách a rozhraních a jsou přepsány nebo implementovány ve třídě kritické pro zabezpečení, jsou automaticky transparentní.Musí být identifikovány buď jako SecuritySafeCritical nebo SecurityCritical.

• SecuritySafeCritical: Typ nebo člena je důležité pro bezpečné. Typ nebo člen však může být volán z transparentního (částečně důvěryhodného) kódu a je stejně schopný jako jiný kritický kód. Kód musí být auditován pro zabezpečení.

Zpět na začátek

Vzory přepsání

Následující tabulka ukazuje přepsání metody povolené pro druhou úroveň transparentnosti.

Základní virtuální/rozhraní člen	Přepsat/rozhraní
Transparent	Transparent
Transparent	SafeCritical
SafeCritical	Transparent
SafeCritical	SafeCritical
Critical	Critical

Zpět na začátek

Pravidla dědičnosti

V tomto oddíle je následující pořadí přiřazeno kódu: Transparent, Critical a SafeCritical na základě přístupu a možností:

Transparent < SafeCritical < Critical

• Pravidla pro typy: Přecházením zleva doprava se přístup stává více omezující. Odvozené typy musí být alespoň tak omezující jako základní typ.

• Pravidla pro metody: Odvozené metody nemohou změnit přístupnost, kterou mají od základní metody. Jako výchozí chování jsou všechny odvozené metody Transparent, pokud nejsou označeny jinak. Odvozené typy kritických typů způsobují výjimku, která je vyvolána, pokud přepsaná metoda není explicitně označena jako SecurityCritical.

Následující tabulka zobrazuje povolené vzory dědičnosti typů.

Základní třída	Odvozená třída může být
Transparent	Transparent
Transparent	SafeCritical
Transparent	Critical
SafeCritical	SafeCritical
SafeCritical	Critical
Critical	Critical

Následující tabulka zobrazuje nepovolené vzory dědičnosti typů.

Základní třída	Odvozené třída nemůže být
SafeCritical	Transparent
Critical	Transparent
Critical	SafeCritical

Následující tabulka zobrazuje povolené vzory dědičnosti metod.

Základní metoda	Odvozená metoda může být
Transparent	Transparent
Transparent	SafeCritical
SafeCritical	Transparent
SafeCritical	SafeCritical
Critical	Critical

Následující tabulka zobrazuje nepovolené vzory dědičnosti metod.

Základní metoda	Odvozená metoda nemůže být
Transparent	Critical
SafeCritical	Critical
Critical	Transparent
Critical	SafeCritical

Poznámka
Tato pravidla dědičnost se aplikují na typy a členy druhé úrovně.Typy v sestaveních první úrovně můžou dědit z typů a členů kritických pro zabezpečení druhé úrovně.Proto typy a členy druhé úrovně musí mít samostatné požadavky dědičnosti na dědice první úrovně.

Zpět na začátek

Další informace a pravidla

Podpora LinkDemand

Model transparentnosti druhé úrovně nahradí LinkDemand atributem SecurityCriticalAttribute. V starším kódu (první úroveň) se s LinkDemand automaticky zacházelo jako s Demand.

Reflection

Vyvolání kritické metody nebo čtení kritické položky spustí požadavek na úplnou důvěryhodnost (stejně jako kdyby jste vyvolávali soukromou metodu nebo položku). Proto plně důvěryhodný kód může vyvolat kritickou metodu, zatímco částečně důvěryhodné kód nemůže.

Následující vlastnosti byly přidány do oboru názvů System.Reflection, aby určily, zda je typ, metoda nebo pole SecurityCritical, SecuritySafeCritical nebo SecurityTransparent: IsSecurityCritical, IsSecuritySafeCritical a IsSecurityTransparent Tyto vlastnosti slouží k určení transparentnosti pomocí reflexe místo kontroly přítomnosti atributu. Pravidla transparentnosti jsou komplexní a kontrola atributu nemusí být dostačující.

Poznámka
A SafeCritical Metoda vrátí true obou IsSecurityCriticala IsSecuritySafeCritical, protože SafeCritical je skutečně důležité (má stejné možnosti jako kritický kód, ale lze volat z kódu průhledné).

Dynamické metody dědí transparentnost modulů, ke kterým jsou připojeny; nedědí transparentnost typu (pokud jsou k typu připojeny).

Přeskočit ověření u plné důvěryhodnosti

Můžete přeskočit ověření pro plně důvěryhodná transparentní sestavení a to pomocí nastavení vlastnosti SkipVerificationInFullTrust na hodnotu true v atributu SecurityRulesAttribute:

[assembly: SecurityRules(SecurityRulesSet.Level2, SkipVerificationInFullTrust = true)]

Vlastnost SkipVerificationInFullTrust má ve výchozím nastavení hodnotu false, takže vlastnost musí být nastavena na hodnotu true, aby mohlo být ověření přeskočeno. Tohle by mělo být provedeno pouze pro účely optimalizace. Měli byste zajistit, že transparentní kód v sestavení je ověřitelný pomocí použití možnosti transparent v nástroji PEVerify.

Zpět na začátek

Viz také

Koncepty

Kód transparentní pro zabezpečení, úroveň 1

Změny zabezpečení v rozhraní .NET Framework 4