Code transparent de sécurité, niveau 1
La transparence aide les développeurs à écrire des bibliothèques .NET Framework plus sécurisées qui exposent les fonctionnalités à du code ayant un niveau de confiance partiel. La transparence de niveau 1 a été introduite dans le .NET Framework version 2.0 et a principalement été utilisée dans Microsoft uniquement. À compter du .NET Framework version 4, vous pouvez utiliser la transparence de niveau 2. Toutefois, la transparence de niveau 1 a été conservée afin que vous puissiez identifier le code hérité qui doit s'exécuter avec les anciennes règles de sécurité.
.gif "Remarque importante") Important |
|---|
Vous devez spécifier la transparence de niveau 1 pour la compatibilité uniquement, c'est-à-dire, spécifier le niveau 1 uniquement pour le code développé avec le .NET Framework 3.5 ou version antérieure qui utilise l'attribut AllowPartiallyTrustedCallersAttribute ou n'utilise pas le modèle de transparence.Par exemple, utilisez la transparence de niveau 1 pour les assemblys .NET Framework 2.0 qui autorisent les appels d'appelants d'un niveau de confiance partiel.Pour le code développé pour le .NET Framework 4, utilisez toujours la transparence de niveau 2. |
Cette rubrique contient les sections suivantes :
Modèle de transparence de niveau 1
Attributs de transparence
Exemples de transparence de la sécurité (Security Transparency)
Modèle de transparence de niveau 1
Lorsque vous utilisez la transparence de niveau 1, vous utilisez un modèle de sécurité qui répartit le code selon trois méthodes : transparent de sécurité (security-transparent), critique sécurisé (security-safe-critical) et critique de sécurité (security-critical).
Vous pouvez marquer un assembly entier, quelques classes dans un assembly ou quelques méthodes dans une classe comme Security Transparent. Le code Security Transparent ne peut pas élever les privilèges. Cette restriction a trois conséquences :
Le code transparent de sécurité ne peut pas exécuter d'actions Assert.
Toute demande de liaison qui serait satisfaite par le code Security Transparent devient une demande complète.
Tout code unsafe (non vérifiable) qui doit s'exécuter dans du code transparent de sécurité (security-transparent) provoque une demande complète pour l'autorisation de sécurité UnmanagedCode.
Ces règles sont appliquées pendant l'exécution par le Common Language Runtime (CLR). Le code Security Transparent passe toutes les conditions de sécurité du code qu'il rappelle à ses appelants. Exige que le flux à travers le code Security Transparent ne puisse pas élever de privilèges. Si une application de confiance basse appelle du code Security Transparent et provoque une demande pour un privilège élevé, la demande retournera au code de confiance basse et échouera. Le code transparent de sécurité ne peut pas arrêter la demande car il ne peut pas exécuter d'actions d'assertion. Le même code Security Transparent appelé à partir d'un code de confiance totale aboutit à une demande réussie.
Critique de sécurité est le contraire de transparent de sécurité. Le code critique de sécurité s'exécute avec une confiance totale et peut exécuter toutes les opérations privilégiées. Le code critique sécurisé est du code privilégié qui a fait l'objet d'un audit de sécurité étendu afin de confirmer qu'il ne permet pas aux appelants partiellement fiables d'utiliser des ressources auxquelles ils ne sont pas autorisés à accéder.
Vous devez appliquer la transparence explicitement. La majeure partie de votre code qui gère la manipulation des données et la logique peut être marquée comme étant transparent de sécurité, alors que la partie restante du code qui exécute les élévations de privilèges est marquée comme étant critique de sécurité ou critique sécurisé.
| Important |
|---|
La transparence de niveau 1 est limitée à la portée de l'assembly ; elle n'est pas appliquée entre les assemblys.La transparence de niveau 1 était utilisée à l'origine au sein de Microsoft à des fins d'audit de la sécurité.Les types et membres critiques de sécurité au sein d'un assembly de niveau 1 sont accessibles au code transparent de sécurité d'autres assemblys.Il est important d'effectuer des demandes de liaisons en confiance totale dans tous vos types et membres critiques de sécurité de niveau 1.Les types et membres critiques sécurisés doivent également confirmer que les appelants disposent d'autorisations sur les ressources protégées accessibles au type ou au membre. |
Pour assurer la compatibilité descendante avec les versions antérieures du .NET Framework, tous les membres qui ne sont pas annotés avec des attributs de transparence sont considérés comme critiques sécurisés. Tous les types qui ne sont pas annotés sont considérés comme transparents. Il n'existe pas de règles d'analyse statique pour valider la transparence. Par conséquent, vous pouvez être amené à déboguer des erreurs de transparence à l'exécution.
Attributs de transparence
Le tableau suivant décrit les trois attributs que vous utilisez pour annoter votre code pour la transparence.
Attribut |
Description |
|---|---|
Autorisé uniquement au niveau de l'assembly. Identifie tous les types et membres de l'assembly comme étant transparents de sécurité. L'assembly ne peut pas contenir de code de sécurité critique. |
|
En cas d'utilisation au niveau de l'assembly sans la propriété Scope, identifie par défaut tout le code dans l'assembly comme étant transparent de sécurité, mais indique que l'assembly peut contenir du code critique de sécurité. En cas d'utilisation au niveau d'une classe, identifie la classe ou la méthode comme critique de sécurité, mais pas les membres de la classe. Pour considérer tous les membres comme étant critiques de sécurité, affectez à la propriété Scope la valeur Everything. En cas d'utilisation au niveau d'un membre, l'attribut s'applique uniquement à ce membre. La classe ou la méthode identifiée comme étant critique de sécurité peut exécuter des élévations de privilège. Important
Dans la transparence de niveau 1, les types et membres critiques de sécurité sont traités comme étant critiques sécurisés lorsqu'ils sont appelés depuis l'extérieur de l'assembly.Vous devez protéger les types et membres critiques de sécurité à l'aide d'une demande liaison en confiance totale pour éviter toute élévation de privilège non autorisée.
|
|
Identifie le code critique de sécurité accessible par le code transparent de sécurité dans l'assembly. Sinon, le code Security Transparent ne peut pas accéder aux membres de sécurité critique privés ou internes dans le même assembly. Une telle approche influencerait le code de sécurité critique et rendrait des élévations de privilège inattendues possibles. Le code critique sécurisé doit subir un audit de sécurité rigoureux. .gif "Remarque") Remarque
Les types et membres critiques sécurisés doivent valider les autorisations des appelants afin de déterminer si l'appelant dispose de l'autorité requise pour accéder aux ressources protégées.
|
L'attribut SecuritySafeCriticalAttribute permet au code Security Transparent d'accéder aux membres de sécurité critique dans le même assembly. Considérez le code Security Transparent et le code de sécurité critique dans votre assembly comme étant séparés dans deux assemblys. Le code Security Transparent ne serait pas en mesure de voir les membres privés ou internes du code de sécurité critique. En outre, le code de sécurité critique est vérifié en général pour l'accès à son interface publique. Il est inhabituel qu'un état privé ou interne soit accessible à l'extérieur de l'assembly ; vous souhaiteriez garder l'état isolé. L'attribut SecuritySafeCriticalAttribute maintient l'isolation d'état entre le code Security Transparent et le code de sécurité critique tout en laissant la possibilité de substituer l'isolation lorsque c'est nécessaire. Le code transparent de sécurité ne peut pas accéder au code critique de sécurité privé ou interne à moins que ces membres n'aient été marqués avec SecuritySafeCriticalAttribute. Avant d'appliquer le SecuritySafeCriticalAttribute, auditez ce membre comme s'il était exposé publiquement.
Annotation au niveau de l'assembly
Le tableau suivant décrit les effets de l'utilisation d'attributs de sécurité au niveau de l'assembly.
Attribut d'assembly |
État de l'assembly |
|---|---|
Aucun attribut sur un assembly partiellement fiable |
Tous les types et membres sont transparents. |
Aucun attribut sur un assembly entièrement fiable (dans le Global Assembly Cache ou identifié comme étant de confiance totale dans AppDomain) |
Tous les types sont transparents et tous les membres sont critiques sécurisés. |
SecurityTransparent |
Tous les types et membres sont transparents. |
SecurityCritical(SecurityCriticalScope.Everything) |
Tous les types et membres sont critique de sécurité. |
SecurityCritical |
L'ensemble du code est transparent par défaut. Toutefois, certains types et membres spécifiques peuvent avoir d'autres attributs. |
Exemples de transparence de la sécurité (Security Transparency)
Pour utiliser les règles de transparence du .NET Framework 2.0 (transparence de niveau 1), utilisez l'annotation d'assembly suivante :
[assembly: SecurityRules(SecurityRuleSet.Level1)]
Si vous souhaitez rendre un assembly entier transparent pour indiquer que l'assembly ne contient pas de code critique et n'élève en aucune façon des privilèges, vous pouvez ajouter explicitement la transparence à l'assembly à l'aide de l'attribut suivant :
[assembly: SecurityTransparent]
Si vous souhaitez combiner code critique et code transparent dans le même assembly, commencez par marquer l'assembly avec l'attribut SecurityCriticalAttribute pour indiquer que l'assembly peut contenir du code critique, comme suit :
[assembly: SecurityCritical]
Si vous souhaitez exécuter des actions de sécurité critique, vous devez marquer explicitement le code qui exécutera l'action critique avec un autre attribut SecurityCriticalAttribute, comme illustré dans l'exemple de code suivant :
[assembly: SecurityCritical]
Public class A
{
[SecurityCritical]
private void Critical()
{
// critical
}
public int SomeProperty
{
get {/* transparent */ }
set {/* transparent */ }
}
}
public class B
{
internal string SomeOtherProperty
{
get { /* transparent */ }
set { /* transparent */ }
}
}
Le code précédent est transparent à l'exception de la méthode Critical, qui est marquée explicitement comme de sécurité critique. La transparence est le paramètre par défaut, même avec l'attribut SecurityCriticalAttribute au niveau de l'assembly.