- 30/03/2017
- 6 minutter at læse
-
-
g -
D -
m -
Y -
s -
+8
-
Varsel
Code Access Security (CAS) og delvist betroet kode
Den .NET Framework indeholder en mekanisme til håndhævelse af forskellige niveauer af tillid til forskellig kode, der kører i det samme program, kaldet Code Access Security (CAS).
CAS understøttes ikke i .NET Core, .NET 5 eller senere versioner. CAS understøttes ikke af versioner af C# senere end 7.0.
CAS i .NET Framework bør ikke anvendes som en mekanisme til at håndhæve sikkerhedsgrænser baseret på kodeoprindelse eller andre identitetsaspekter. CAS og Security-Transparent Code understøttes ikke som en sikkerhedsgrænse med delvist betroet kode, især kode af ukendt oprindelse. Vi fraråder indlæsning og udførelse af kode af ukendt oprindelse uden at indføre alternative sikkerhedsforanstaltninger. .NET Framework vil ikke udstede sikkerhedspatches for eventuelle elevation-of-privilege-eksperimenter, der måtte blive opdaget mod CAS-sandkassen.
Denne politik gælder for alle versioner af .NET Framework, men gælder ikke for .NET Framework, der indgår i Silverlight.
Sikkerhed omfatter tre dele, der spiller sammen: sandkasser, tilladelser og håndhævelse. Sandboxing henviser til praksis med at oprette isolerede domæner, hvor noget kode behandles som fuldt ud betroet, mens anden kode er begrænset til tilladelserne i den tildeling, der er fastsat for sandkassen. Den programkode, der kører inden for sandkassens tilladelsessæt, anses for at være gennemsigtig, dvs. at den ikke kan udføre nogen operationer, der kan påvirke sikkerheden. Sandkassens tilladelsessæt bestemmes af beviser (Evidence-klassen). Bevismateriale identificerer, hvilke specifikke tilladelser der kræves af sandkasser, og hvilke typer sandkasser der kan oprettes. Håndhævelse henviser til, at gennemsigtig kode kun må udføres inden for sit tildelingssæt.
Vigtigt
Sikkerhedspolitik var et centralt element i tidligere versioner af .NET Framework. Fra og med .NET Framework 4 er sikkerhedspolitik forældet. Afskaffelsen af sikkerhedspolitik er adskilt fra sikkerhedstransparens. Du kan finde oplysninger om virkningerne af denne ændring under Kompatibilitet og migration af sikkerhedspolitik for kodeadgang.
Mål for gennemsigtighedsmodellen
Transparens er en håndhævelsesmekanisme, der adskiller kode, der kører som en del af programmet, fra kode, der kører som en del af infrastrukturen. Gennemsigtighed trækker en barriere mellem kode, der kan gøre privilegerede ting (kritisk kode), som f.eks. at kalde indfødt kode, og kode, der ikke kan det (gennemsigtig kode). Gennemsigtig kode kan udføre kommandoer inden for rammerne af det tilladelsessæt, den opererer i, men kan ikke udføre, aflede fra eller indeholde kritisk kode.
Det primære mål med håndhævelse af gennemsigtighed er at tilvejebringe en enkel og effektiv mekanisme til at isolere forskellige grupper af kode på grundlag af privilegier. Inden for rammerne af sandkassemodellen er disse rettighedsgrupper enten fuldt betroede (dvs. ikke begrænsede) eller delvist betroede (dvs. begrænsede til det tilladelsessæt, der er givet til sandkassen).
Vigtigt
Gennemsigtighedsmodellen går ud over kodeadgangssikkerhed. Gennemsigtighed håndhæves af just-in-time compileren og forbliver i kraft uanset tilladelsessættet for en samling, herunder fuld tillid.
Transparens blev indført i .NET Framework version 2.0 for at forenkle sikkerhedsmodellen og gøre det lettere at skrive og implementere sikre biblioteker og programmer. Gennemsigtig kode anvendes også i Microsoft Silverlight for at forenkle udviklingen af delvist betroede programmer.
Note
Når du udvikler et delvist betroet program, skal du være opmærksom på tilladelseskravene for dine målværter. Du kan udvikle et program, der bruger ressourcer, som ikke er tilladt af nogle værter. Denne applikation vil kompilere uden fejl, men vil fejle, når den indlæses i værtsmiljøet. Hvis du har udviklet dit program ved hjælp af Visual Studio, kan du aktivere debugging i delvis tillid eller i et begrænset tilladelsessæt fra udviklingsmiljøet. Du kan finde flere oplysninger under Sådan gør du: Debugge en ClickOnce-applikation med begrænsede tilladelser. Funktionen Beregn tilladelser, der leveres til ClickOnce-programmer, er også tilgængelig for ethvert program med delvis tillid.
Specificering af gennemsigtighedsniveauet
Attributten SecurityRulesAttribute på samlingsniveau vælger eksplicit de SecurityRuleSet-regler, som samlingen skal følge. Reglerne er organiseret under et numerisk niveausystem, hvor højere niveauer betyder strengere håndhævelse af sikkerhedsreglerne.
Niveauerne er som følger:
Niveau 2 (Level2) – gennemsigtighedsreglerne i .NET Framework 4.
Niveau 1 (Level1) – gennemsigtighedsreglerne i .NET Framework 2.0.
Den primære forskel mellem de to gennemsigtighedsniveauer er, at niveau 1 ikke håndhæver gennemsigtighedsreglerne for kald fra uden for samlingen og kun er beregnet til kompatibilitet.
Vigtigt
Du bør kun angive gennemsigtighedsniveau 1 med henblik på kompatibilitet; dvs. angiv kun niveau 1 for kode, der er udviklet med .NET Framework 3.5 eller tidligere, som bruger attributten AllowPartiallyTrustedCallersAttribute eller ikke bruger gennemsigtighedsmodellen. Brug f.eks. gennemsigtighed på niveau 1 for .NET Framework 2.0-samlinger, der tillader opkald fra delvist betroede opkaldere (APTCA). For kode, der er udviklet til .NET Framework 4, skal du altid bruge gennemsigtighed på niveau 2.
Gennemsigtighed på niveau 2
Gennemsigtighed på niveau 2 blev indført i .NET Framework 4. De tre principper i denne model er gennemsigtig kode, sikkerhedskritisk kode og sikkerhedskritisk kode.
Transparent kode kan, uanset hvilke tilladelser den er tildelt (herunder fuld tillid), kun kalde anden gennemsigtig kode eller sikkerhedskritisk kode. Hvis koden er delvist betroet, kan den kun udføre handlinger, der er tilladt i henhold til domænets tilladelsessæt. Gennemsigtig kode kan ikke gøre følgende:
Udføre en Assert-operation eller elevation af privilegier.
Indeholde usikker eller ukontrollabel kode.
Kald direkte kritisk kode.
Kald indfødt kode eller kode, der har attributten SuppressUnmanagedCodeSecurityAttribute.
Kald et medlem, der er beskyttet af en LinkDemand.
Arvér fra kritiske typer.
Transparente metoder kan desuden ikke overskrive kritiske virtuelle metoder eller implementere kritiske grænseflademetoder.
Sikkerhedssikker kritisk kode er fuldt ud betroet, men kan kaldes af transparent kode. Den eksponerer et begrænset overfladeareal af kode med fuld tillid. Korrektheds- og sikkerhedskontrol finder sted i sikker-kritisk kode.
Sikkerhedskritisk kode kan kalde enhver kode og er fuldt pålidelig, men den kan ikke kaldes af gennemsigtig kode.
Gennemsigtighed på niveau 1
Gennemsigtighedsmodellen på niveau 1 blev indført i .NET Framework version 2.0 for at give udviklerne mulighed for at reducere mængden af kode, der er genstand for en sikkerhedsrevision. Selv om niveau 1-gennemsigtighed var offentligt tilgængelig i version 2.0, blev den primært kun brugt inden for Microsoft til sikkerhedsrevisionsformål. Ved hjælp af annotationer kan udviklere angive, hvilke typer og medlemmer der kan udføre sikkerhedsforbedringer og andre betroede handlinger (sikkerhedskritisk), og hvilke der ikke kan (sikkerhedstransparent). Kode, der er identificeret som gennemsigtig, kræver ikke en høj grad af sikkerhedsrevision. Gennemsigtighed på niveau 1 angiver, at håndhævelsen af gennemsigtighed er begrænset til at foregå inden for samlingen. Med andre ord er alle offentlige typer eller medlemmer, der er identificeret som sikkerhedskritiske, kun sikkerhedskritiske inden for samlingen. Hvis du ønsker at håndhæve sikkerheden for disse typer og medlemmer, når de kaldes uden for samlingen, skal du bruge linkkrav for fuld tillid. Hvis du ikke gør det, behandles offentligt synlige sikkerhedskritiske typer og medlemmer som sikkerhedskritiske og kan kaldes af delvist betroet kode uden for samlingen.
Gennemsigtighedsmodellen på niveau 1 har følgende begrænsninger:
Sikkerhedskritiske typer og medlemmer, der er offentlige, er tilgængelige fra sikkerhedstransparent kode.
Gennemsigtighedsannotationerne håndhæves kun inden for en samling.
Sikkerhedskritiske typer og medlemmer skal bruge linkkrav for at håndhæve sikkerheden for kald udefra i en assembly.
Overleveringsregler håndhæves ikke.
Der er mulighed for, at gennemsigtig kode kan gøre skadelige ting, når den køres i fuld tillid.
Transparenshåndhævelse
Transparensreglerne håndhæves ikke, før gennemsigtigheden er beregnet. På det tidspunkt kastes der en InvalidOperationException, hvis en gennemsigtighedsregel overtrædes. Det tidspunkt, hvor gennemsigtigheden beregnes, afhænger af flere faktorer og kan ikke forudsiges. Den beregnes så sent som muligt. I .NET Framework 4 sker beregningen af gennemsigtighed på assemblageniveau tidligere end i .NET Framework 2.0. Den eneste garanti er, at gennemsigtighedsberegningen finder sted på det tidspunkt, hvor der er behov for den. Dette svarer til, hvordan JIT-compileren (Just-in-time) kan ændre det tidspunkt, hvor en metode kompileres, og hvor eventuelle fejl i den pågældende metode opdages. Gennemsigtighedsberegning er usynlig, hvis din kode ikke har nogen gennemsigtighedsfejl.