Security in .NET Teil 1

Der Sicherheitsaspekt in modernen Applikationen ist mehr den je gefragt. Egal ob es dabei um die Rechte eines Benutzers, einer Benutzergruppe (Rollen) oder den Erzeugern einer Software geht. Das .NET Framework bietet hierfür reichliche Unterstützung, bzw. ist das Security Konzept fest in die Common Language Runtime (CLR) des .NET Frameworks integriert.

Das Microsoft .NET Framework bietet unteranderem ?code access security? und ?role-based security?, um Fragen der Sicherheit über Code zu liefern und es somit Komponenten zu ermöglichen festzustellen was für Berechtigungen ein User ( oder der Quellcode) hat.

Sicherheitsgrundlagen:

Grundlegend müssen einige Begriffe erklärt werden die in der weitern Ausführung benötigt werden:

- Code Access Security

o Was darf der Quellcode?

o Überprüfen, Einstellen ob der Quellcode auf geschützte Ressourcen zugreifen darf

- Role ? based Security

o Was darf der User?

o Überprüfen der User und Rollen Rechte

- Principal

o Ein Principal Objekt liefert zugriff auf den Sicherheitskontext den ein ?caller? (meist User) innehat

- Application Domain

o Application Domain kann man mit einem Win32 Prozess vergleichen, ist jedoch gegenüber einem Win32 Prozesse OS unabhängig. Ein Host richtet beim Ausführen einer .NET Anwendung eine Application Domain ein und lädt das Assembly

Implementiert wird die Sicherheit in .NET durch sogennante ?permissions?. Mit den ?permissions? wird festgelegt, welche Rechte ein Code hat um seine Operationen durchführen zu können. Natürlich kann ein Code auch verschiedene Rechte bei der selben Operation habe, abhängig vom ?caller? (meist der User). ?Permission? Objekte können abgefragt, erteilt oder verwehrt werden. Ausserdem gibt es noch ?policies?. ?Policies? sind Regeln für die CLR wie ?permissions? überprüft werden sollen. Das gute daran ist, dass ein ?normaler? Administrator diese ?policies? durch ein Administrations Tool verwalten kann und somit ein Assembly in punkto Sicherheit einstellen kann. Ich werde in diesem Artikel jedoch nur auf den (für Programmierer) wichtigen Teil des Coding?s eingehen und nicht auf die Administrativen Aufgaben.

Ausgangspunkt für das Sicherheitssystem in .NET ist der Namespace System.Security. Darunter liegen verschiedene Klassen die wir kurz betrachten:

?System.Security.Policy

?Klassen um mit ?permissions? zu arbeiten

?System.Security.Permissions

?Klassen um Zugriff auf Operationen und Ressourcen zu kontrollieren

?System.Security.Principal

?Objekt das den Sicherheitskontext unter dem der Code läuft repräsentiert. (?caller?)

?System.Security.Cryptography

?Verschlüsseln und Entschlüsseln von Daten

Role-Based Security:

Um eine Rollen - basierende Sicherheit in einer Anwendung zu gewährleisten muss ein ?principal? Objekt angelegt werden, indem Informationen über den aktuellen User abrufbar sind (Name, Rolle). Hier teilt sich aber schon wieder der Lösungsweg, erstens kann man untereilen in Mehrfachauthentifizierung oder Einmalige Authentifizierung. Bei der Einmaligen Authentifizierung kann ich direkt über das WindowsIdentity Objekt gehen. Wir gehen aber davon aus das man sich mehrmals ausweisen muss. Dazu muss ich ersteinmal ein für die Application Domain die Art des ?Principals? einstellen. Wichtig: Bei Windows Standard Rollen kann man hier PrincipalPolicy.WindowsPrincipal verwenden. Werden allerdings eigene Rollen im Windows System verwendet muss ich ein GenericPrincipal Objekt erzeugen welches an den aktuellen Thread gehängt wird.

Sample: Überprüfen eines Users mit einer benutzerdefinierte Rollen:

AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal);

WindowsPrincipal myUser =WindowsPrincipal)System.Threading.Thread.CurrentPrincipal;

GenericIdentity MyIdentity = new GenericIdentity(myUser.Identity.Name.ToString());

String[] MyStringArray = {"TobiTest", "Teller"};

GenericPrincipal MyPrincipal = new GenericPrincipal(MyIdentity, MyStringArray);

System.Threading.Thread.CurrentPrincipal = MyPrincipal;

//Return User values

String Name = MyPrincipal.Identity.Name;

bool Auth = MyPrincipal.Identity.IsAuthenticated;

bool IsInRole = MyPrincipal.IsInRole("Seppl");

if(IsInRole){System.Windows.Forms.MessageBox.Show("Der Test war erfolgreich als User in der Benutzerdefinierten Rolle TobiTest");}

else{System.Windows.Forms.MessageBox.Show("Der Test war nicht erfolgreich ");}

Implementierte Namespaces sind:

using System.Security;

using System.Security.Permissions;

using System.Security.Principal;

Ausserdem wird das Assembly deklarativ eingestellt, das es mindestens eine Principalüberprüfung machen muss:

[assembly:SecurityPermission(SecurityAction.RequestMinimum, ControlPrincipal=true)]

In dem Beispiel oben wird ersteinmal die PrincipalPolicy auf WindowsPrincipal eingestellt. Danach hole ich mir die Informationen über den aktuellen User und erzeuge darauf hin ein GenericIdentity Objekt. Anschliessend erzeuge ich ein Array mit zwei benutzerdefinierten Rollen TobiTest und Teller. Jetzt kann ein GernericPrincipal Objekt erzeugt werden das wir an den aktuellen Thread hängen. Danach kann ich überprüfen ob ein User in einer bestimmten Rolle ist oder nicht (IsInRole).

Generell hat man zwei Möglichkeiten Sicherheitsmechanismen in ein .NET Assembly einzubauen:

- Deklarative Sicherheit

o Implementiert durch Attribute im Quellcode

- Imperative Sicherheit

Implementieren von extra Code

Deklarative Sicherheit:

Hierbei stellt man die Sicherheit in auf Assembly-, Klassen-, oder Klassenmember- Ebene ein. Syntaktisch ist möglich über die SecurityAttribute Klasse zu gehen oder über die SecurityAction Aufzählung zu gehen. Bei der SecurityAction Aufzählung gibt es die Methoden Assert(), Deny() und Demand(), aber später dazu mehr.

Sample: Deklarative Sicherheit mit Attributen und SecurityAction Aufzählung:

[PrincipalPermissionAttribute(SecurityAction.Demand, Name = "MyUser", Role = "User")]

public static void PrivateInfo()

{//Ausgabe geheimer Daten

Console.WriteLine("Sie haben Zugriff auf die geheimen Daten!");

}

Nun wollen wir das Beispiel von vorhin erweitern und implementieren deklarative Sicherheit für eine Funktion MyFunction():

[PrincipalPermission(SecurityAction.Demand, Role=@"TobiTest")]

private string MyFunction()

{

return "Deklarativer Check für die Rolle TobiTest wahr erfolgreich. Diese Funktion kann von Ihnen ausgeführt werden!";

}

Die Attribut Einstellung sagt, dass nur derjenige (?principal?) diese Funktion ausführen darf, wenn er sich in der Rolle ?TobiTest? befindet.

Mehr im zweiten Teil!