g
D
m
Y
sAtenție
Securitatea accesului la cod (CAS) și codul parțial de încredere
Codul .NET Framework oferă un mecanism pentru aplicarea unor niveluri diferite de încredere asupra diferitelor coduri care rulează în aceeași aplicație, numit Code Access Security (CAS).
CAS nu este acceptat în .NET Core, .NET 5 sau în versiunile ulterioare. CAS nu este suportat de versiunile de C# mai recente de 7.0.
CAS în .NET Framework nu ar trebui să fie utilizat ca un mecanism de impunere a limitelor de securitate pe baza originii codului sau a altor aspecte legate de identitate. CAS și codul transparent din punct de vedere al securității (Security-Transparent Code) nu sunt acceptate ca o limită de securitate cu codul parțial de încredere, în special codul de origine necunoscută. Vă sfătuim să nu încărcați și să executați cod de origine necunoscută fără a pune în aplicare măsuri de securitate alternative. .NET Framework nu va emite patch-uri de securitate pentru orice exploit de ridicare a privilegiilor care ar putea fi descoperit împotriva sandbox-ului CAS.
Această politică se aplică tuturor versiunilor de .NET Framework, dar nu se aplică la .NET Framework inclus în Silverlight.
Securitatea implică trei elemente care interacționează: sandboxing, permisiuni și aplicare. Sandboxing se referă la practica de a crea domenii izolate în care o parte din cod este tratată ca fiind de încredere deplină, iar alt cod este restricționat la permisiunile din granturile stabilite pentru sandbox. Codul aplicației care rulează în cadrul setului de permisiuni al sandbox-ului este considerat a fi transparent, adică nu poate efectua nicio operațiune care poate afecta securitatea. Setul de autorizații pentru sandbox este determinat de dovezi (clasa Evidence). Probele identifică ce permisiuni specifice sunt necesare pentru sandbox-uri și ce tipuri de sandbox-uri pot fi create. Enforcement se referă la a permite codului transparent să se execute numai în cadrul setului său de acordare.
Important
Politica de securitate a fost un element cheie în versiunile anterioare ale .NET Framework. Începând cu .NET Framework 4, politica de securitate este învechită. Eliminarea politicii de securitate este separată de transparența securității. Pentru informații despre efectele acestei modificări, consultați Compatibilitatea și migrarea politicii de securitate a accesului la cod.
Scop al modelului de transparență
Transparența este un mecanism de aplicare care separă codul care rulează ca parte a aplicației de codul care rulează ca parte a infrastructurii. Transparența trasează o barieră între codul care poate face lucruri privilegiate (cod critic), cum ar fi apelarea codului nativ, și codul care nu poate face acest lucru (cod transparent). Codul transparent poate executa comenzi în limitele setului de permisiuni în care operează, dar nu poate executa, deriva din sau conține cod critic.
Obiectivul principal al aplicării transparenței este acela de a oferi un mecanism simplu și eficient pentru a izola diferite grupuri de cod pe baza privilegiilor. În contextul modelului de sandboxing, aceste grupuri de privilegii sunt fie de încredere totală (adică nu sunt restricționate), fie de încredere parțială (adică sunt restricționate la setul de permisiuni acordate sandbox-ului).
Important
Modelul de transparență transcende securitatea accesului la cod. Transparența este impusă de compilatorul just-in-time și rămâne în vigoare indiferent de setul de permisiuni pentru un ansamblu, inclusiv încrederea deplină.
Transparența a fost introdusă în .NET Framework versiunea 2.0 pentru a simplifica modelul de securitate și pentru a facilita scrierea și implementarea bibliotecilor și aplicațiilor sigure. Codul transparent este, de asemenea, utilizat în Microsoft Silverlight, pentru a simplifica dezvoltarea aplicațiilor de încredere parțială.
Nota
Când dezvoltați o aplicație de încredere parțială, trebuie să fiți conștienți de cerințele de permisiune pentru gazdele țintă. Puteți dezvolta o aplicație care utilizează resurse care nu sunt permise de unele gazde. Această aplicație se va compila fără erori, dar va eșua atunci când va fi încărcată în mediul găzduit. Dacă ați dezvoltat aplicația utilizând Visual Studio, puteți activa depanarea în încredere parțială sau într-un set de permisiuni restricționate din mediul de dezvoltare. Pentru mai multe informații, consultați How to: Depanarea unei aplicații ClickOnce cu permisiuni restricționate. Caracteristica Calculate Permissions (Calcularea permisiunilor) furnizată pentru aplicațiile ClickOnce este disponibilă și pentru orice aplicație cu încredere parțială.
Specificarea nivelului de transparență
Atributul SecurityRulesAttribute de la nivelul ansamblului selectează în mod explicit regulile SecurityRuleSet pe care le va urma ansamblul. Regulile sunt organizate în cadrul unui sistem de niveluri numerice, în care nivelurile mai ridicate înseamnă o aplicare mai strictă a regulilor de securitate.
Nivelurile sunt următoarele:
-
Nivelul 2 (Level2) – regulile de transparență .NET Framework 4.
-
Nivelul 1 (Level1) – regulile de transparență .NET Framework 2.0.
-
Codul transparent, indiferent de permisiunile care îi sunt acordate (inclusiv încredere deplină), poate apela numai alt cod transparent sau cod critic de securitate. În cazul în care codul beneficiază de încredere parțială, acesta poate efectua numai acțiuni care sunt permise de setul de permisiuni al domeniului. Codul transparent nu poate face următoarele:
-
Realiza o operațiune Assert sau o ridicare de privilegii.
-
Conține cod nesigur sau neverificabil.
-
Apelează direct cod critic.
-
Apelează cod nativ sau cod care are atributul SuppressUnmanagedCodeSecurityAttribute.
-
Apelează un membru care este protejat de un LinkDemand.
-
Impreună cu tipurile critice.
În plus, metodele transparente nu pot suprascrie metodele virtuale critice sau implementa metode de interfață critice.
-
-
Codul critic sigur din punct de vedere al securității este de încredere deplină, dar poate fi apelat de codul transparent. Acesta expune o suprafață limitată de cod de încredere deplină. Verificările de corectitudine și de securitate au loc în codul safe-critical.
-
Codul safe-critical poate apela orice cod și este de încredere deplină, dar nu poate fi apelat de codul transparent.
-
Tipurile și membrii critici pentru securitate care sunt publici sunt accesibili din codul transparent pentru securitate.
-
Anotațiile de transparență sunt aplicate numai în cadrul unui ansamblu.
-
Tipurile și membrii critici din punct de vedere al securității trebuie să utilizeze cerințe de legătură pentru a impune securitatea pentru apelurile din afara ansamblului.
-
Nu se aplică regulile de moștenire.
-
Există potențialul ca un cod transparent să facă lucruri dăunătoare atunci când este rulat în deplină încredere.
- Cod transparent din punct de vedere al securității, nivel 1
- Cod transparent din punct de vedere al securității, nivel 2
Diferența principală dintre cele două niveluri de transparență este că nivelul 1 nu impune reguli de transparență pentru apelurile din afara ansamblului și este destinat doar pentru compatibilitate.
Important
Ar trebui să specificați nivelul 1 de transparență numai pentru compatibilitate; adică, specificați nivelul 1 numai pentru codul care a fost dezvoltat cu .NET Framework 3.5 sau anterior care utilizează atributul AllowPartiallyTrustedCallersAttribute sau care nu utilizează modelul de transparență. De exemplu, utilizați nivelul 1 de transparență pentru ansamblurile .NET Framework 2.0 care permit apeluri de la apelanți parțial de încredere (APTCA). Pentru codul care este dezvoltat pentru .NET Framework 4, utilizați întotdeauna transparența de nivel 2.
Transparență de nivel 2
Transparența de nivel 2 a fost introdusă în .NET Framework 4. Cele trei principii ale acestui model sunt codul transparent, codul critic de securitate și codul critic de securitate.
Transparența de nivel 1
Modelul de transparență de nivel 1 a fost introdus în .NET Framework versiunea 2.0 pentru a permite dezvoltatorilor să reducă cantitatea de cod care face obiectul unui audit de securitate. Deși nivelul 1 de transparență a fost disponibil publicului în versiunea 2.0, acesta a fost utilizat în principal numai în cadrul Microsoft în scopul auditului de securitate. Prin intermediul adnotărilor, dezvoltatorii au posibilitatea de a declara ce tipuri și membri pot efectua ridicări de securitate și alte acțiuni de încredere (security-critical) și care nu (security-transparent). Codul care este identificat ca fiind transparent nu necesită un grad ridicat de audit de securitate. Nivelul 1 de transparență declară că aplicarea transparenței este limitată la interiorul ansamblului. Cu alte cuvinte, orice tipuri sau membri publici care sunt identificați ca fiind critici din punct de vedere al securității sunt critici din punct de vedere al securității numai în cadrul ansamblului. Dacă doriți să impuneți securitatea pentru aceste tipuri și membri atunci când sunt apelate din afara ansamblului, trebuie să utilizați cerințe de legătură pentru încredere deplină. Dacă nu o faceți, tipurile și membrii publici critici pentru securitate sunt tratați ca fiind critici pentru securitate și pot fi apelați de codul parțial de încredere din afara ansamblului.
Modelul de transparență de nivel 1 are următoarele limitări:
Executarea transparenței
Reguli de transparență nu sunt puse în aplicare până când transparența nu este calculată. În acel moment, se aruncă o InvalidOperationException dacă o regulă de transparență este încălcată. Momentul în care se calculează transparența depinde de mai mulți factori și nu poate fi prezis. Acesta este calculat cât mai târziu posibil. În .NET Framework 4, calcularea transparenței la nivel de ansamblu are loc mai devreme decât în .NET Framework 2.0. Singura garanție este că calculul transparenței va avea loc în momentul în care este necesar. Acest lucru este similar cu modul în care compilatorul just-in-time (JIT) poate schimba momentul în care o metodă este compilată și în care sunt detectate eventualele erori din acea metodă. Calculul de transparență este invizibil dacă codul dumneavoastră nu are erori de transparență.
Vezi și
.