Změny zabezpečení v rozhraní .NET Framework 4
V rozhraní .NET Framework verze 4 byly provedeny dvě podstatné změny zabezpečení. Zásady zabezpečení pro celý počítač byly odstraněny, ačkoli systém oprávnění zůstává na místě a transparentnost zabezpečení se stala výchozím mechanismem vynucování. (Další informace naleznete v tématu Transparentní kód pro zabezpečení, úroveň 2.) Kromě toho některé operace oprávnění, které představují potenciální slabá místa zabezpečení nebyly prohlášeny za zastaralé.
.gif "Důležitá poznámka") Důležité |
|---|
Zabezpečení přístupu ke kódu (CAS) bylo odstraněno, zásady zabezpečení bylo odstraněno z CAS, ale důkazy a oprávnění jsou stále v platnosti.Bylo odstraněno několik oprávnění a průhlednost zjednodušila prosazování zabezpečení.Stručný přehled změn naleznete v tématu Souhrn změn v zabezpečení přístupu ke kódu. |
Měli byste si být vědomi následujících klíčových bodů:
Transparentnost odděluje kód, který běží jako část aplikace od kódu, která běží jako část infrastruktury. Tohle bylo poprvé představeno v rozhraní .NET Framework verze 2.0 a vylepšeno tak, aby se z toho stal mechanismus vynucování pro zabezpečení přístupu kódu. Na rozdíl od zásad zabezpečení, pravidla transparentnosti druhé úrovně jsou uplatněna za běhu, nikoli v době načtení sestavení. Tato pravidla platí vždy, i pro sestavení, která automaticky běží jako plně důvěryhodná. Nicméně transparentnost druhé úrovně neovlivní plně důvěryhodný kód, který není označený, jako třeba aplikace pro stolní počítače. Sestavení (včetně sestavení pro stolní počítače), které jsou označeny SecurityTransparentAttribute a které volají metody označené SecurityCriticalAttribute obdrží MethodAccessException. Můžete změnit toto chování použitím SecurityRulesAttribute a nastavením vlastnosti SecurityRulesAttribute.RuleSet na hodnotu Level1; nicméně tento postup byste měli provést pouze pro zpětnou kompatibilitu. Musíte explicitně označit běžné aplikace jako bezpečnostně transparentní, aby bylo možné na ně aplikovat omezení transparentnosti.
Kód, který volá API rozhraní zásad zabezpečení obdrží vedle upozornění kompilátoru v době běhu také výjimku NotSupportedException. Zásady mohou být opět povoleny pomocí konfiguračního elementu <NetFx40_LegacySecurityPolicy>. Když jsou zásady povoleny, transparentnost zabezpečení je stále v platnosti. Zásady zabezpečení se aplikují v okamžiku načtení sestavení a nemají žádný vliv na transparentnost, která je vynucena modulem runtime.
Zastaralé žádosti o oprávnění (RequestMinimum, RequestOptional a RequestRefuse) obdrží upozornění kompilátoru a nebudou funkční v rozhraní .NET Framework 4, ale nezpůsobí vyvolání výjimky. Požadavky Deny způsobují výjimku NotSupportedException, která je vyvolána za běhu.
Akce zabezpečení LinkDemand není zastaralá, ale neměla by být používána k ověřování oprávnění. Místo toho použijte SecurityCriticalAttribute pro typy a metody, které vyžadují úplnou důvěryhodnost nebo použijte metodu Demand pro typy a metody, které vyžadují individuální oprávnění.
Pokud je vaše aplikace sestavena pomocí sady Visual Studio 2010, můžete ji spustit bez těchto změn zadáním cílové verze rozhraní .NET Framework, která je starší než .NET Framework 4 v nastavení projektu sady Visual Studio. Ale nebude moci používat nové typy a členy rozhraní .NET Framework 4. Můžete také specifikovat dřívější verzi rozhraní .NET Framework použitím elementu <supportedruntime> v schématu nastavení spuštění ve vašem konfiguračním souboru aplikace.
Následující oddíly popisují tyto a další změny v .NET Framework 4:
Zjednodušení zásad zabezpečení
Druhá úroveň transparentnosti zabezpečení
Zastaralé požadavky oprávnění
Podmíněný atribut APTCA
Objekty legitimace
Kolekce legitimace
Zjednodušení zásad zabezpečení
Počínaje rozhraním .NET Framework 4 se modul CLR (Common Language Runtime) vzdaluje od poskytování zásad zabezpečení pro počítače. Historicky rozhraní .NET Framework poskytovalo zásady zabezpečení přístupu kódu (CAS) jako mechanismus pro pevné řízení a konfiguraci možností spravovaného kódu. I když zásady CAS jsou výkonné, tak mohou být komplikované a omezující. Kromě toho zásady CAS se nevztahují na nativní aplikace, takže jejich záruky zabezpečení jsou omezené. Správci systému by měl vypadat jako na úrovni operačního systému řešení Zásady omezení softwaru Windows (SRP) nebo AppLocker na Windows 7 a Windows Server 2008 R2 jako náhrada zásad certifikačních ÚŘADŮ. Zásady SRP a AppLocker poskytují jednoduchý mechanismus důvěryhodnosti, který se aplikuje na spravovaný i nativní kód. Jako řešení pro zásady zabezpečení jsou SRP a AppLocker jednodušší a poskytují lepší záruky zabezpečení než CAS.
V rozhraní .NET Framework 4 jsou zásady zabezpečení celého počítače ve výchozím nastavení vypnuty. Aplikace, které nejsou hostovány (to znamená aplikace, které jsou spouštěny prostřednictvím Průzkumníka Windows nebo z příkazové řádky) nyní běží jako plně důvěryhodné. To zahrnuje všechny aplikace, které jsou umístěny ve sdílených složkách v místní síti. Aplikace hostované nebo umístěné v izolovaném prostoru pokračují v běhu se zásadami důvěryhodnosti, které jsou vybrány jejich hostiteli (například aplikací Internet Explorer, ClickOnce nebo technologií ASP.NET). Aplikace nebo ovládací prvky, které běží v izolovaných prostorech jsou považovány za částečně důvěryhodné.
Pro zjednodušení zásad zabezpečení, byl u rozhraní .NET Framework aplikován transparentní model. Aplikace a ovládací prvky, které běží v hostiteli nebo v izolovaném prostoru s omezenou sadou oprávnění udělenou izolovaným prostorem jsou považovány za transparentní. Transparentnost znamená, že se nemusíte starat o kontrolu zásad CAS při spouštění částečně důvěryhodných aplikací. Transparentní aplikace stačí spustit pomocí jejich udělené sady. Jako programátor by vašim jediným zájmem mělo být to, zda vaše aplikace plní udělenou sadu pro jejich izolovaný prostor a zda nevolají kód, který vyžaduje úplnou důvěryhodnost (kód kritický pro bezpečnost).
| Důležité |
|---|
V důsledku těchto změn zásad zabezpečení, se můžete setkat s upozorněními kompilace a výjimkami za běhu, pokud zavoláte (explicitně nebo implicitně) zastaralé typy a členy zásad CAS (prostřednictvím jiných typů a členů).Seznam zastaralých typů a členů, jejich náhrad naleznete v tématu Kompatibilita a migrace zásad zabezpečení přístupu kódu. Varováním a chybám se můžete vyhnout použitím konfiguračního elementu <NetFx40_LegacySecurityPolicy> ve schématu nastavení modulu runtime, který se přidá do starší verze chování zásad CAS.Pokud nedojde k migraci na .NET Framework 4, tak specifikování použití starší verze zásad zabezpečení nezahrnuje žádné vlastní zásady CAS pro tuto verzi. Můžete také povolit starší verzi CAS zásad tak, že cílovou verzi rozhraní .NET Framework pro váš projekt sady Visual Studio nastavíte na starší verzi než je .NET Framework 4. To umožňuje starší verzi CAS zásad a zahrnuje libovolné vlastní zásady CAS, které jste specifikovali pro tuto verzi. Ale nebude moci používat nové typy a členy rozhraní .NET Framework 4. Také můžete specifikovat starší verzi rozhraní .NET Framework použitím elementu <supportedruntime> ve schématu nastavení spuštění. |
Zpět na začátek
Druhá úroveň transparentnosti zabezpečení
Transparentnost zabezpečení byla představena v rozhraní .NET Framework verze 2.0, ale byla velmi omezená a primárně používána ke zlepšení účinnosti ověřování kódu. V rozhraní .NET Framework 4 představuje transparentnost mechanismus vynucování, který odděluje kód, který běží jako část aplikace od kódu, který běží jako část infrastruktury. Transparentnost kreslí bariéru mezi kódem, který může dělat privilegované věci (kritický kód), jako je například volání nativního kódu a kódem, který tyto věci dělat nemůže (transparentní kód). Transparentní kód může provádět příkazy uvnitř omezení sady oprávnění, v rámci které funguje, ale nemůže spouštět, volat, odvozovat nebo obsahovat kritický kód.
Primární cíl vynucování transparentnosti je poskytnout jednoduchý a účinný mechanismus pro izolaci různých skupin kódu založený na oprávnění. V modelu izolování prostoru jsou tyto skupiny oprávnění buď plně důvěryhodné (to znamená, nejsou omezeny) nebo částečně důvěryhodné (tedy omezeny sadou oprávnění udělenou izolovanému prostoru).
Běžné aplikace běží jako plně důvěryhodné; proto nejsou ovlivněny modelem transparentnosti. Další informace o změnách transparentnosti zabezpečení naleznete v tématu Transparentní kód pro zabezpečení, úroveň 2.
Zpět na začátek
Zastaralé požadavky oprávnění
Podpora modulu runtime byla odebrána pro vynucování následujících žádostí o oprávnění: Deny, RequestMinimum, RequestOptional a RequestRefuse. Všeobecně tyto požadavky nebyly dobře srozumitelné a představovaly potenciální slabá místa zabezpečení, když nebyly správně použity:
Akce Deny by mohla být snadno přepsána akcí Assert. Kód v sestavení byl schopen spouštět akci Assert pro oprávnění, pokud bylo v udělené sadě pro sestavení. Assert chrání Deny od spatření na zásobníku tak, že ji činí neúčinnou.
RequestMinimum nemůže být efektivně použito mimo rozsah aplikace. Pokud se RequestMinimum objeví ve spustitelném souboru (.exe) a sada oprávnění nebyla splněna, tak koncoví uživatelé souboru obdrží neošetřenou výjimku FileLoadException, která neobsahuje žádné informace o tom, jak problém opravit. Nemohli byste použít samostatnou minimální požadovanou sadu pro knihovny (.dll soubory), protože různé typy a členy v sestavení mají obecně různé požadavky na oprávnění.
RequestOptional byl matoucí a často nesprávně používaný s neočekávanými výsledky. Vývojáři mohou snadno vynechat oprávnění ze seznamu aniž by si uvědomili, že pokud toto dělají implicitně, tak dojde k odmítnutí vynechaných oprávnění.
RequestRefuse neposkytl efektivní model nejnižších možných oprávnění, protože vyžadoval, aby jste explicitně identifikovali oprávnění, která jste nechtěli, místo určení potřebných oprávnění. Navíc pokud byla k dispozici nová oprávnění, nebyla by zařazena do seznamu. Kromě toho odmítnutí nedávalo smysl pro všechna oprávnění. Například mohli jste odmítnout hodnotu pro vlastnost UserQuota v IsolatedStoragePermission.
Nakonec specifikováním pouze oprávnění jste nechtěli vytvořit potenciál pro slabá místa zabezpečení, pokud se vám nepodařilo identifikovat všechna potenciálně škodlivá oprávnění.
RequestOptional a RequestRefuse umožňuje vývojářům narušit homogenní domény vytvořením více sad oprávnění v rámci domény.
Rozhraní .NET Framework 4 odstraňuje prosazování těchto hodnot výčtu modulem runtime. Sestavení obsahující atributy, které používají tyto hodnoty SecurityAction budou pokračovat v načtení; ale CLR neodmítne načíst odkazovaná sestavení nebo změnit jejich sadu oprávnění založenou na sadách oprávnění.
Zpět na začátek
Podmíněný atribut APTCA
Podmíněné použití atributu AllowPartiallyTrustedCallersAttribute (APTCA) umožňuje hostitelům identifikovat sestavení, které chtějí zpřístupnit částečně důvěryhodným volajícím, kteří jsou načteni v rámci kontextu hostitele. Kandidátská sestavení musí být již navržena pro částečnou důvěryhodnost; to znamená, musí být buď APTCA (bezpečné pro kritické zabezpečení v modelu transparentnosti) nebo zcela transparentní. Nový konstruktor pro AllowPartiallyTrustedCallersAttribute umožňuje hostiteli určovat úroveň viditelnosti pro APTCA sestavení pomocí použití výčtu PartialTrustVisibilityLevel ve volání konstruktoru.
Zpět na začátek
Objekty legitimace
Před rozhraním .NET Framework 4 téměř libovolný objekt by mohl být použit jako objekt legitimace, pokud by hostitelský kód ho chtěl použít jako legitimaci. Například některý kód rozhraní .NET Framework rozpoznal objekty System.Uri jako legitimaci. Modul runtime považoval objekty legitimace za odkazy System.Object a neaplikoval na ně žádnou bezpečnost typů.
Toto představovalo problém, protože rozhraní .NET Framework zavedlo implicitní omezení, na kterých by typy mohly být použity jako objekty legitimace. Konkrétně libovolný objekt použitý jako legitimace musel být serializovatelný a nemohl mít hodnotu null. Pokud nebyly splněny tyto požadavky, CLR vyhodil výjimku při každé operaci, která vyžadovala, aby jeden z těchto předpokladů byl proveden.
Rozhraní .NET Framework 4 zavádí novou základní třídu System.Security.Policy.EvidenceBase, od které musí být odvozeny všechny objekty legitimace. Díky tomu lze povolit omezení pro typy objektů, které mohou být použity jako legitimace a poskytnout možnost přidat nové vlastnosti a požadavky na všechny objekty legitimace. Třída EvidenceBase při vytváření instance zajišťuje, že objekt legitimace je serializovatelný. Navíc nové požadavky legitimace lze v budoucnu vytvořit přidáním nové výchozí implementace k základní třídě.
Zpětná kompatibilita
Všechny typy použité CLR jako objekty legitimace byly v rozhraní .NET Framework 4 aktualizovány tak, aby byly odvozené z EvidenceBase. Nicméně vlastní typy legitimace použité aplikacemi třetích stran nejsou známy a nelze je aktualizovat. Proto nelze tyto typy legitimace použít s novými členy, které očekávají legitimaci odvozenou z EvidenceBase.
Zpět na začátek
Kolekce legitimace
Před rozhraním .NET Framework 4CLR generoval úplnou sada objektů legitimace, které byly aplikovány na sestavení v momentě, kdy bylo sestavení načteno. Tyto objekty byly uloženy v seznamu, přes který poté zákazníci mohli iterovat při hledání určitého objektu. Proto všechny legitimace byly k dispozici, bez ohledu na to, zda byly použity. U většiny objektů legitimace nebylo toto chování problém; ale pro objekty legitimace, jako je například System.Security.Policy.Publisher (který vyžaduje ověření pomocí technologie Authenticode) bylo toto chování neefektivní.
Pro zlepšení tohoto chování byla v rozhraní .NET Framework 4 přepracována interakce s kolekcí legitimace. Nyní se kolekce legitimace chová jako slovník místo seznamu. Místo iterování přes kolekci legitimace za účelem zjištění, zda požadovaný objekt legitimace existuje, nyní zákazníci mohou požadovat určitý typ legitimace a kolekce vrátí legitimaci, pokud je nalezena. Například volání StrongName name = evidence.GetHostEvidence<StrongName>(); vrátí objekt StrongName, pokud nějaký existuje; jinak vrátí hodnotu null.
Tento slovníkový model zpožďuje generování objektů legitimace, dokud nejsou požadovány. V příkladu legitimace Publisher, režie výkonu ověřování podpisu technologie Authenticode sestavení je zpožděna, dokud tato informace není potřeba. U nejběžnějších případů plně důvěryhodných aplikací, kde legitimace Publisher není nutná, je proces ověření zcela odstaven.
Zpět na začátek
Viz také
Koncepty
Kód transparentní pro zabezpečení