- 03/30/2017
- 6 minuten om te lezen
-
g -
D -
m -
Y -
s -
+8
Caution
Code Access Security (CAS) and Partially Trusted Code
Het .NET Framework biedt een mechanisme voor het afdwingen van verschillende niveaus van vertrouwen op verschillende code die in dezelfde toepassing wordt uitgevoerd, Code Access Security (CAS) genaamd.
CAS wordt niet ondersteund in .NET Core, .NET 5, of latere versies. CAS wordt niet ondersteund door versies van C# later dan 7.0.
CAS in .NET Framework mag niet worden gebruikt als een mechanisme voor het afdwingen van beveiligingsgrenzen op basis van codeoorsprong of andere identiteitsaspecten. CAS en Security-Transparent Code worden niet ondersteund als beveiligingsgrens met gedeeltelijk vertrouwde code, met name code van onbekende oorsprong. Het wordt afgeraden code van onbekende oorsprong te laden en uit te voeren zonder alternatieve beveiligingsmaatregelen te treffen. .NET Framework zal geen beveiligingspatches uitgeven voor eventuele elevation-of-privilege exploits die tegen de CAS sandbox kunnen worden ontdekt.
Dit beleid geldt voor alle versies van .NET Framework, maar is niet van toepassing op het .NET Framework dat in Silverlight is opgenomen.
Veiligheid bestaat uit drie op elkaar inwerkende onderdelen: sandboxing, permissies, en handhaving. Sandboxing verwijst naar de praktijk van het creëren van geïsoleerde domeinen waar sommige code wordt behandeld als volledig vertrouwd en andere code is beperkt tot de machtigingen in de toelating set voor de sandbox. De applicatiecode die binnen de toekenningsverzameling van de zandbak draait, wordt als transparant beschouwd; dat wil zeggen dat het geen bewerkingen kan uitvoeren die de beveiliging kunnen beïnvloeden. De toekenningsverzameling voor de zandbak wordt bepaald door bewijsmateriaal (Evidence klasse). Bewijsmateriaal identificeert welke specifieke toestemmingen vereist zijn voor zandbakken, en welke soorten zandbakken gemaakt kunnen worden. Enforcement verwijst naar het toestaan van transparante code om alleen binnen zijn grant set uit te voeren.
Belangrijk
Het beveiligingsbeleid was een belangrijk element in eerdere versies van het .NET Framework. Met ingang van het .NET Framework 4 is het beveiligingsbeleid verouderd. De afschaffing van het beveiligingsbeleid staat los van de transparantie van de beveiliging. Voor informatie over de gevolgen van deze wijziging, zie Code Access Security Policy Compatibility and Migration.
Doel van het transparantiemodel
Transparantie is een handhavingsmechanisme dat code die draait als onderdeel van de applicatie scheidt van code die draait als onderdeel van de infrastructuur. Transparantie werpt een barrière op tussen code die geprivilegieerde dingen kan doen (kritieke code), zoals het aanroepen van native code, en code die dat niet kan (transparante code). Transparante code kan commando’s uitvoeren binnen de grenzen van de toestemmingenverzameling waarin het opereert, maar kan geen kritieke code uitvoeren, ervan afleiden of bevatten.
Het primaire doel van transparantiehandhaving is om een eenvoudig, effectief mechanisme te bieden voor het isoleren van verschillende groepen code op basis van privilege. Binnen de context van het sandboxing-model zijn deze groepen privileges ofwel volledig vertrouwd (dat wil zeggen, niet beperkt) of gedeeltelijk vertrouwd (dat wil zeggen, beperkt tot de toestemmingen die aan de sandbox zijn toegekend).
Belangrijk
Het transparantiemodel overstijgt de beveiliging van de codetoegang. Transparantie wordt afgedwongen door de “just-in-time” compiler en blijft van kracht ongeacht de “grant set” voor een assembly, inclusief “full trust”.
Transparantie is geïntroduceerd in het .NET Framework versie 2.0 om het beveiligingsmodel te vereenvoudigen, en om het eenvoudiger te maken veilige bibliotheken en toepassingen te schrijven en in te zetten. Transparante code wordt ook gebruikt in Microsoft Silverlight, om de ontwikkeling van gedeeltelijk vertrouwde toepassingen te vereenvoudigen.
Note
Wanneer u een gedeeltelijk vertrouwde toepassing ontwikkelt, moet u zich bewust zijn van de toestemmingsvereisten voor uw doelhosts. U kunt een toepassing ontwikkelen die bronnen gebruikt die door sommige hosts niet zijn toegestaan. Deze toepassing zal zonder fouten worden gecompileerd, maar zal mislukken wanneer deze in de gehoste omgeving wordt geladen. Als u uw toepassing hebt ontwikkeld met Visual Studio, kunt u debuggen inschakelen in gedeeltelijk vertrouwen of in een beperkte toestemmingsset vanuit de ontwikkelomgeving. Voor meer informatie, zie Hoe: Een ClickOnce-applicatie debuggen met beperkte machtigingen. De Calculate Permissions-functie voor ClickOnce-toepassingen is ook beschikbaar voor elke gedeeltelijk vertrouwde toepassing.
Specificeren van het transparantieniveau
Het SecurityRulesAttribute-attribuut op assemblageniveau selecteert expliciet de SecurityRuleSet-regels die de assemblage zal volgen. De regels zijn onderverdeeld in een numeriek niveausysteem, waarbij hogere niveaus een striktere handhaving van de beveiligingsregels betekenen.
De niveaus zijn als volgt:
-
Level 2 (Level2) – de .NET Framework 4-transparantieregels.
-
Level 1 (Level1) – de .NET Framework 2.0-transparantieregels.
Het belangrijkste verschil tussen de twee transparantieniveaus is dat niveau 1 geen transparantieregels afdwingt voor oproepen van buiten de assembly en alleen bedoeld is voor compatibiliteit.
Belangrijk
U moet transparantie van niveau 1 alleen specificeren voor compatibiliteit; dat wil zeggen, specificeer niveau 1 alleen voor code die is ontwikkeld met het .NET Framework 3.5 of eerder dat het AllowPartiallyTrustedCallersAttribute-attribuut gebruikt of geen gebruik maakt van het transparantiemodel. Gebruik bijvoorbeeld transparantie van niveau 1 voor .NET Framework 2.0-assemblies die oproepen van gedeeltelijk vertrouwde bellers (APTCA) toestaan. Gebruik voor code die is ontwikkeld voor het .NET Framework 4 altijd transparantie van niveau 2.
Level 2 Transparency
Level 2 transparantie is geïntroduceerd in het .NET Framework 4. De drie grondbeginselen van dit model zijn transparante code, beveiligingsveilige-kritische code, en beveiligingskritische code.
-
Transparante code kan, ongeacht de toestemmingen die het krijgt (inclusief volledig vertrouwen), alleen andere transparante code of beveiligingsveilige-kritische code aanroepen. Als de code gedeeltelijk wordt vertrouwd, kan deze alleen acties uitvoeren die zijn toegestaan door de toestemmingenverzameling van het domein. Transparante code kan niet het volgende doen:
-
Een Assert-bewerking of verhoging van privileges uitvoeren.
-
Onveilige of niet-controleerbare code bevatten.
-
Onmiddellijk kritieke code aanroepen.
-
Native code of code aanroepen die het kenmerk SuppressUnmanagedCodeSecurityAttribute heeft.
-
Een lid aanroepen dat wordt beschermd door een LinkDemand.
-
Erven over van kritieke typen.
Daarnaast kunnen transparante methoden kritieke virtuele methoden niet overschrijven of kritieke interfacemethoden implementeren.
-
Security-safe-kritieke code wordt volledig vertrouwd, maar kan worden aangeroepen door transparante code. Er wordt een beperkt oppervlak van volledig te vertrouwen code blootgelegd. Correctheids- en beveiligingsverificaties vinden plaats in veilig-kritische code.
-
Veiligheidskritische code kan elke code aanroepen en is volledig te vertrouwen, maar kan niet worden aangeroepen door transparante code.
Transparantie op niveau 1
Het transparantiemodel op niveau 1 is geïntroduceerd in het .NET Framework versie 2.0 om ontwikkelaars in staat te stellen de hoeveelheid code die aan een beveiligingsaudit wordt onderworpen, te verminderen. Hoewel niveau 1-transparantie in versie 2.0 openbaar beschikbaar was, werd het voornamelijk alleen binnen Microsoft gebruikt voor beveiligingsauditdoeleinden. Door middel van annotaties kunnen ontwikkelaars aangeven welke types en leden beveiligingsverhogingen en andere vertrouwde acties kunnen uitvoeren (beveiligingskritisch) en welke niet (beveiligingstransparant). Code die als transparant wordt aangemerkt, hoeft niet in hoge mate op veiligheid te worden gecontroleerd. Transparantie van niveau 1 houdt in dat de handhaving van de transparantie beperkt blijft tot binnen de assembly. Met andere woorden, alle publieke types of leden die als veiligheidskritisch worden geïdentificeerd zijn alleen veiligheidskritisch binnen de assembly. Als je beveiliging voor die types en leden wilt afdwingen als ze van buiten de assembly aangeroepen worden, dan moet je link eisen gebruiken voor full trust. Als u dat niet doet, worden openbaar zichtbare veiligheidskritische typen en leden behandeld als veiligheidskritische en kunnen ze worden aangeroepen door gedeeltelijk vertrouwde code buiten de assembly.
Het transparantiemodel van niveau 1 heeft de volgende beperkingen:
-
Types en leden met veiligheidskritische eigenschappen die openbaar zijn, zijn toegankelijk vanuit veiligheidstransparante code.
-
De transparantie-annotaties worden alleen afgedwongen binnen een assembly.
-
Voor beveiligingsgevoelige typen en leden moeten koppelingseisen worden gebruikt om de beveiliging af te dwingen voor aanroepen van buiten de assembly.
-
Regels voor overerving worden niet afgedwongen.
-
Transparantiehandhaving
Transparantieregels worden niet afgedwongen totdat transparantie wordt berekend. Op dat moment wordt een InvalidOperationException geworpen als een transparantieregel wordt overtreden. Het tijdstip waarop transparantie wordt berekend hangt af van meerdere factoren en kan niet worden voorspeld. Het wordt zo laat mogelijk berekend. In het .NET Framework 4 vindt de berekening van de transparantie op assembly-niveau eerder plaats dan in het .NET Framework 2.0. De enige garantie is dat de transparantieberekening plaatsvindt tegen de tijd dat zij nodig is. Dit is vergelijkbaar met hoe de just-in-time (JIT) compiler het punt kan veranderen waarop een methode wordt gecompileerd en eventuele fouten in die methode worden gedetecteerd. Transparantieberekening is onzichtbaar als uw code geen transparantiefouten bevat.
Zie ook
- Security-Transparent Code, Level 1
- Security-Transparent Code, Level 2
-