War diese Seite hilfreich?
Ihr Feedback ist uns wichtig. Teilen Sie uns Ihre Meinung mit.
Weiteres Feedback?
1500 verbleibende Zeichen
MSDN Library

Microsoft .NET Framework-Sicherheit - Übersicht

Veröffentlicht: 24. Jul 2001 | Aktualisiert : 07. Nov 2004

Das vorliegende Dokument gibt eine Übersicht über die Sicherheitsarchitektur von Microsoft .NET Framework. Es beschreibt u. a. die beweisbasierte Sicherheit, die rollenbasierte Sicherheit, Konzepte der Authentifizierung und Autorisierung sowie isolierte Speicher, Verschlüsselung und Erweiterbarkeit. Darüber hinaus erläutert es die wichtigsten Vorteile der .NET Framework-Sicherheitslösung für Entwickler, Administratoren und Endbenutzer. Dieses Dokument setzt voraus, dass der Leser mit der Common Language Runtime (CLR) von .NET Framework und dem Konzept verwalteter Codes vertraut ist.

Auf dieser Seite

Einführung
Die Bausteine der Microsoft .NET Framework-Sicherheit
Wie Sicherheit spezifiziert wird
Zusammenfassung

Einführung

Sicherheitsprobleme, die heutzutage bewältigt werden müssen
Heutzutage kommen die Anwendungen in einer Softwareumgebung aus vielen verschiedenen Quellen und führen die unterschiedlichsten Aufgaben durch. Dem Anwendungscode vertrauen zu können, ist daher eine der Hauptvoraussetzungen, da niemand Schäden an der Software oder den Daten riskieren möchte. Eine Sicherheitsrichtlinie, die unerwünschte Berechtigungen erteilt, könnte unberechtigten Zugriff auf sensible Informationen ermöglichen oder den lokalen Computer für böswillige Programme oder fehlerhaften Code zugänglich machen.

Herkömmlicherweise ermöglichten Sicherheitsarchitekturen Isolation und Zugriffssteuerung auf Benutzerkontenebene und erteilten Codes uneingeschränkt Zugriffsrechte, unter der Annahme, dass der von einem bestimmten Benutzer ausgeführte Code vertrauenswürdig ist. Leider kann das Isolieren von Code auf Benutzerbasis Programme gegenseitig nicht ausreichend schützen, wenn diese Programme vom selben Benutzer ausgeführt werden. Alternativ wurde Code, der als nicht vollständig vertrauenswürdig galt, oft in Form eines sogenannten Sandkasten-Ausführungsmodells, d. h. in einer isolierten Umgebung ausgeführt, in der er auf die meisten Dienste keinen Zugriff hatte.

Ein erfolgreiches Sicherheitsmodell für heutige Anwendungen muss Ausgewogenheit zwischen den beiden Sicherheitsmodellen gewährleisten. Es muss Zugriff auf Ressourcen ermöglichen, da nur dann effizientes Arbeiten möglich es, und es muss eine genauere Steuerung der Anwendungssicherheit möglich machen, damit Code identifiziert, untersucht und diesem eine entsprechende Vertrauensstufe zugewiesen werden kann. Das .NET Framework-Sicherheitsmodell bietet genau diese Lösung.

Die Sicherheitslösung von Microsoft .NET Framework
Die .NET Framework-Sicherheitslösung basiert auf dem Konzept verwalteten Codes, wobei die Sicherheitsrichtlinien von der Common Language Runtime (CLR) erzwungen werden. Verwalteter Code wird in der Regel überprüft, um Typ-Sicherheit sowie das ordnungsgemäße Verhalten anderer Eigenschaften sicherzustellen. In überprüftem Code wird z. B. eine Methode, für die deklariert wurde, dass sie einen 4-Byte-Wert akzeptieren muss, einen 8-Byte-Parameter als nicht typ-sicher zurückweisen. Die Überprüfung stellt außerdem sicher, dass während der Ausführung nur bekannte Stellen, z. B. der Einsprungspunkt einer Methode, übertragen werden. Dieser Prozess verhindert, dass die Ausführung an einem beliebigen, unerwünschten Ort fortgesetzt werden kann.

Die Überprüfung verhindert die Ausführung von nicht typ-sicherem Code und fängt viele der am häufigsten verbreiteten Programmierfehler ab, bevor diese Schäden verursachen können. Häufige Probleme, z. B. Pufferüberläufe, das Lesen von beliebigen Speichern oder von Speichern, die nicht initialisiert wurden, sowie die willkürliche Übergabe der Steuerung, können nicht mehr auftreten. Davon profitiert der Endbenutzer, da der Code, den er ausführt, zuvor überprüft worden ist. Ebenso profitiert der Entwickler, da häufige Fehler, die die Entwicklung früher sehr behindert haben, jetzt identifiziert werden und keine Schäden mehr verursachen.

Die CLR ermöglicht auch das Ausführen von nichtverwaltetem Code, dieser profitiert jedoch nicht von den hier beschriebenen Sicherheitsmaßnahmen. Wenn nichtverwalteter Code aufgerufen wird, gelten bestimmte Berechtigungen, und eine zuverlässige Sicherheitsrichtlinie stellt sicher, dass diese Berechtigungen auf eher konservativer Basis erteilt werden. Die Umstellung von nichtverwaltetem auf verwalteten Code wird im Laufe der Zeit die Anzahl der Aufrufe von nichtverwaltetem Code reduzieren.

Die Bausteine der Microsoft .NET Framework-Sicherheit

Beweisbasierte Sicherheit.NET Framework führt das Konzept der beweisbasierten Sicherheit ein. Ein Beweis verweist in der Sicherheitsrichtlinie auf Informationen über Code. Es handelt sich im Grunde um eine Reihe von Antworten auf Fragen von Seiten der Sicherheitsrichtlinie:

  • Von welcher Site stammt die Assemblierung?
    Assemblierungen sind Bausteine von .NET Framework-Anwendungen. Sie bilden die Basiseinheit für Bereitstellung, Versionskontrolle, Wiederverwendung, Aktivierungsscoping und Sicherheitsautorisierung. Die Assemblierungen einer Anwendung werden von einer Website auf den Client gedownloadet.

  • Von welchem URL stammt die Assemblierung?
    Die Sicherheitsrichtlinie verlangt, dass die Assemblierung von einer bestimmten Adresse gedownloadet wird.

  • Aus welcher Zone stammt die Assemblierung?
    Zonen sind Beschreibungen von Sicherheitskriterien, z. B. Internet, Intranet, lokaler Computer usw., basierend auf dem Herkunftsort des Codes.

  • Wie lautet der starke Name der Assemblierung?
    Der starke Name ist eine stark verschlüsselte ID, die vom Autor einer Assemblierung vergeben wird. Diese ID bietet keine Authentifizierung des Autors, sondern identifiziert eindeutig die Assemblierung und stellt sicher, dass diese nicht verändert worden ist.

Auf der Basis der Antworten auf diese Fragen und anderer Beweiselemente kann die Sicherheitsrichtlinie eine entsprechende Gruppe von Berechtigungen ermitteln und der Assemblierung erteilen. Beweise können, abhängig von der Quelle des Codes, aus unterschiedlichen Quellen stammen, darunter die CLR, der Browser, Microsoft ASP .NET und die Shell.

Richtliniengesteuertes Vertrauensmodell unter Verwendung con Codebeweisen
Wenn eine Assemblierung geladen wird, ermittelt das Richtliniensystem der CLR, welche Berechtigungen erteilt werden sollen. Dazu sammelt sie die Beweise der Assemblierung und bewertet diese im Kontext der Sicherheitsrichtlinie. Das Richtliniensystem der CLR erteilt dann der Assemblierung auf der Basis der ausgewerteten Beweise und möglicher Berechtigungsanforderungen von Seiten der Assemblierung eine Gruppe von Berechtigungen. Der Autor einer Assemblierung kann u. U. feststellen, dass die Assemblierung ordnungsgemäß ausgeführt wird, wenn eine Mindestanzahl an Berechtigungen erteilt wurde, oder dass die Assemblierung bestimmte Berechtigungen nie benötigen wird. Solche Zusatzberechtigungen können in Form einer oder mehrerer Anforderungen für bestimmte Berechtigungen erteilt werden.

Abhängig vom Typ der Berechtigungsanforderung kann das Richtliniensystem die Erteilung an die Assemblierung weiter einschränken (und nicht benötigte Berechtigungen entfernen) oder sogar das Laden der Assemblierung verweigern (wenn die Richtlinie nicht die Mindestgruppe der erforderlichen Richtlinien erteilt). Einer Assemblierung können nie mehr Berechtigungen erteilt werden, als das Richtliniensystem dieser ohne Vorhandensein von Anforderungen für Berechtigungen erteilen würde. Die Anforderungen dienen nur dazu, die Anzahl der erteilten Berechtigungen weiter einzuschränken.

Sicherheitsrichtlinien bestehen aus einer Reihe von Codegruppen, die die auf der Basis von Beweisen erteilten Berechtigungen enthalten. Codegruppen können z. B. die einer Assemblierung aus einer bestimmten Sicherheitszone erteilten Berechtigungen oder von einem bestimmten Autor signierten Berechtigungen beschreiben. Die CLR wird mit einem Standardsatz von Codegruppen (und den zugehörigen Berechtigungen) ausgeliefert, die der Administrator an seine speziellen Anforderungen anpassen kann. Beachten Sie hierbei, dass nahezu alles als Beweis übergeben werden kann, vorausgesetzt die Sicherheitsrichtlinie hat Verwendung hierfür. Dazu wird dann eine Codegruppe für den jeweiligen Beweis definiert.

Das Verfahren zum Erteilen von Berechtigungen beinhaltet die Bewertung des Beweises zum Ermitteln der zutreffenden Codegruppen auf drei unterschiedlichen Ebenen: Unternehmen, Computer und Benutzer. Die Richtlinie wertet diese drei Ebenen in der genannten Reihenfolge aus und erstellt dann eine Gruppe von Berechtigungen, die eine Schnittmenge dieser 3 Bereiche darstellt. Der Administrator kann eine Richtlinie als endgültig markieren und damit die Auswertung weiterer Richtlinien auf anderen Ebenen verhindern. Er kann z. B. eine Richtlinie auf Computerebene als endgültig erklären, um die Anwendung von Richtlinien auf Benutzerebene für diese Assemblierung zu verhindern.

Sobald eine Richtlinie fertiggestellt ist, wird eine Anfangsgruppe von Berechtigungen erstellt. Assemblierungen können die hier erteilten Berechtigungen mit Hilfe von Anforderungen in drei Bereichen optimieren:

  • Zunächst muss eine Mindestgruppe von Berechtigungen definiert werden, die die Assemblierung benötigt, um ordnungsgemäß zu funktionieren. Wenn diese Berechtigungen nicht erteilt sind, kann die Assemblierung nicht geladen werden, und es wird ein Ausnahmefehler generiert.

  • Zusätzlich kann eine optionale Gruppe von Berechtigungen definiert werden. Obwohl die Assemblierung diese Berechtigungen vorzugsweise verwenden möchte, kann sie auch geladen werden, wenn diese nicht zur Verfügung stehen.

  • Außerdem können besonders "brave" Assemblierungen auch Berechtigungen verweigern, die sie nicht benötigen. Diese drei Optimierungsoptionen werden als deklarative Anweisungen beim Laden ausgeführt.

Während der Laufzeit werden die Berechtigungen auf der Basis der Codeausführung ausgewertet. Die Abbildung auf der rechten Seite verdeutlicht diesen Prozess. Die Assemblierung A3 stellt der Richtlinienauswertung ihren Beweis zusammen mit dem Beweis vom Host zur Verfügung. Die Richtlinienauswertung berücksichtigt bei der Erteilung von Berechtigungen außerdem Berechtigungsanforderungen (G3) von der Assemblierung. Die Assemblierung A3 wird von der Assemblierung A2 aufgerufen, die selbst von der Assemblierung A1 aufgerufen wird. Wenn die Assemblierung A3 eine Operation ausführt, die eine Sicherheitsprüfung auslöst, werden auch die Berechtigungen von A2 und A1 überprüft, um sicherzustellen, dass diese über die von A3 angefragten Berechtigungen verfügen. Dieser Prozess wird als Stack-Walking bezeichnet. Dabei werden die Berechtigungen jeder Assemblierung im Stack untersucht, um zu ermitteln, ob die Gruppe der Berechtigungen die Anforderungen der Sicherheitsprüfung erfüllt. Wenn jede Assemblierung im Stack über die von der Sicherheitsprüfung geforderten Berechtigungen verfügt, ist der Aufruf erfolgreich. Wenn eine Assemblierung nicht über die erforderliche Berechtigungen verfügt, schlägt der Aufruf fehl, und es wird ein Ausnahmefehler generiert.

security

Abbildung 1. Der Host und die Assemblierung stellen der Richtlinienauswertung Beweise zur Verfügung, anhand derer die Sicherheitsrichtlinie und die Berechtigungsanforderung ermitteln, welche Berechtigungen der Assemblierung erteilt werden. Anschließend werden die Berechtigungen verschiedener laufender Komponenten der Anwendung verwendet, um Autorisierungsentscheidungen treffen zu können.

Der "Stack-Walk" für sicheren Zugriff auf Code schützt vor einem "Verführungsangriff". Bei einem solchen, häufig auftretenden Angriff verführt böswilliger Code vertrauenswürdigeren Code dazu, etwas zu tun, das er allein nicht tun könnte. Damit werden die Berechtigungen des "guten" Codes missbraucht. Vor einem solchen Angriff können Entwickler sich nur schwer schützen, aber der Stack-Walk stellt sicher, dass wenn weniger vertrauenswürdiger Code im Spiel ist, die verfügbaren Berechtigungen auf die desjenigen Codes reduziert werden, dem am wenigsten vertraut wird.

Auf diese Weise kann Code von Quellen mit unterschiedlichen Vertrauensstufen verwendet und mit den für den jeweiligen Kontext der Ausführung des Codes geltenden Beschränkungen ausgeführt werden.

"Freie" Sicherheit für .NET Framework-Aufrufe
Aktionen wie z. B. das Lesen oder Schreiben von Dateien, Anzeigen von Dialogfeldern oder Lesen und Schreiben von Umgebungsvariablen werden unter Verwendung von .NET Framework-Methoden ausgeführt, die in der Framework-Sicherheitsinfrastruktur enthalten sind. Auf diese Weise kann .NET Framework eine auf der Sicherheitsrichtlinie basierte Aktion ohne zusätzlichen Aufwand auf Seiten des Programmierers zulassen oder deren Zulassung aufheben. Während Autoren verwalteter Klassen, die geschützte Ressourcen bereitstellen, in ihren Bibliotheken die betreffenden Sicherheitsanfragen vornehmen müssen, können Entwickler, die zum Zugreifen auf geschützten Code die .NET Framework-Klassenbibliotheken verwenden, die Vorteile des Sicherheitssystems für Codezugriff "frei" nutzen, d. h. Sie müssen keine ausdrücklichen Sicherheitsaufrufe vornehmen.

Der Administrator kann die Sicherheitsrichtlinie optimieren. Dazu muss er ermitteln, welche Berechtigungen erteilt wurden. Alle anderen Sicherheitsoperationen übernimmt dann .NET Framework. Die Sicherheit für den Codezugriff verhindert die meisten "Verführungsangriffe", und die Überprüfung des Codes schließt Pufferüberläufe und andere unerwartete Verhaltensweisen aus, die zu Sicherheitslücken führen könnten. Anwendungen und Komponenten werden daher automatisch vor den meisten Sicherheitsproblemen geschützt, die bisher bei Codeimplementationen zu einer wahren Plage werden konnten.

Rollenbasierte Sicherheit
Gelegentlich erfordert die Autorisierung Entscheidungen auf der Basis einer authentifizierten Identität oder einer mit dem Kontext der Codeausführung verbundenen Rolle. Buchhaltungs- oder Businesssoftware erzwingt z. B. möglicherweise die Einhaltung von Richtlinien unter Verwendung von Businesslogik, die Rolleninformationen auswertet. Der Betrag in einer Finanztransaktion kann z. B. auf der Basis der Rolle des Benutzers, der die Anforderung macht, beschränkt werden. Bankautomaten können Anforderungen bis zu einem bestimmten Betrag zulassen, während alle darüber hinausgehenden Anforderungen von einer übergeordneten Rolle ausgeführt werden müssen. .NET Framework unterstützt Dienste, die Anwendungen ermöglichen, solche Logik problemlos zu implementieren und auf dem Konzept von Identitäten und Hauptberechtigungen aufzubauen.

Identitäten können dem am Betriebssystem angemeldeten Benutzer zugeordnet oder von der Anwendung definiert werden. Die betreffende Hauptberechtigung kapselt die Identität zusammen mit den betreffenden Rolleninformationen (z. B. die vom Betriebssystem definierte "Gruppe" des Benutzers).

Authentifizierung und Autorisierung
Authentifizierung bezeichnet das Akzeptieren von Anmeldedaten von einem Benutzer und Bestätigen dieser Daten mit Hilfe einer Autorisierungsstelle. Wenn die Anmeldedaten gültig sind, handelt es sich um eine authentifizierte Identität. Autorisierung bezeichnet den Prozess zum Ermitteln, ob eine authentifizierte Identität Zugriff auf eine bestimmte Ressource hat. Authentifizierung kann vom System oder von Seiten der Businesslogik erfolgen und steht über eine einzelne API zur Verfügung. Die Authentifizierungs-API ist vollständig erweiterbar, so dass der Entwickler bei Bedarf seine eigene Businesslogik einsetzen kann. Der Entwickler kann seine Authentifizierungsanforderungen in dieser einzelnen API programmieren und die zugrundeliegenden Authentifizierungsmethoden überarbeiten, ohne größere Programmcodeänderungen vornehmen zu müssen. Zusätzlich zur Authentifizierung der Identität des Betriebssystems Microsoft Windows® stehen Authentifizierungsmethoden wie HTTP, Digest und Kerberos sowie Microsoft Passport und formularbasierte Authentifizierung zur Verfügung. Diese Authentifizierungsmethoden sind auch vollständig in ASP .NET integriert.

Bei der ASP .NET-Formularauthentifizierung stellt der Benutzer Anmeldeinformationen bereit und übermittelt die Formulare. Wenn die Anwendung die Anforderung authentifiziert, gibt das System einen Cookie aus, das die Anmeldeinformationen in Form eines Schlüssels enthält, mit dem die Identität erneut erworben werden kann. Nachfolgende Anforderungen werden ohne Cookie im Kopf der Anforderung ausgegeben und von einem ASP .NET-Handler authentifiziert und autorisiert, unabhängig davon, welche Bestätigungsmethode die Anwendung fordert. Wenn eine Anwendung nicht authentifiziert wird, wird die Umleitung auf Clientseite verwendet, um eine Anforderung an ein Authentifizierungsformular zu senden, in dem der Benutzer seine Anmeldeinformationen angeben kann. Formularbasierte Authentifizierung wird gelegentlich für Personalisierung verwendet, d. h. für die Personalisierung von Inhalten für einen bekannten Benutzer. In einigen dieser Fälle ist die Identität eher das Problem als die Authentifizierung, d. h. die Personalisierungsinformationen für einen Benutzer können einfach durch Zugreifen auf den Benutzernamen abgefragt werden.

Zweck der Autorisierung ist es, zu ermitteln, ob eine anfragende Identität Zugriff auf eine bestimmte Ressource erhält oder nicht. ASP .NET bietet zwei Arten von Autorisierungsdiensten: Dateiautorisierung und URL-Autorisierung. Dateiautorisierung ermittelt, welche Zugriffssteuerungslisten sowohl auf der verwendeten HHTP-Methode als auch auf der Identität, die die Anforderung gemacht hat, untersucht werden. URL-Autorisierung ist eine logische Zuordnung zwischen Elementen des URL-Namespace und verschiedenen Benutzern oder Rollen.

Isolierter Speicher
.NET Framework unterstützt eine spezielle Funktion - isolierte Speicher - zum Speichern von Daten, wenn der Zugriff auf Dateien nicht möglich ist, z. B. wenn ein verwaltetes Steuerelement aus dem Internet gedownloadet und ausgeführt wird. Dem isolierten Speicher wird eine eingeschränkte Gruppe von Berechtigungen erteilt, nicht jedoch die Berechtigungen zum Lesen oder Schreiben von Dateien.

Ein isolierter Speicher ist eine neue Gruppe von Typen und Methoden, die .NET Framework zum lokalen Speichern unterstützt. Das heißt, jede Assemblierung erhält Zugriff auf einen separaten Bereich auf dem Datenträger. Der Zugriff auf andere Daten ist nicht erlaubt, und der isolierte Speicher steht nur für die jeweilige Assemblierung zur Verfügung, für die er erstellt wurde.

Ein isolierter Speicher kann von einer Anwendung zum Speichern von Aktivitätsprotokollen, von Einstellungen oder von Statusdaten auf dem Datenträger, die später wiederverwendet werden sollen, verwendet werden. Da der Speicherort eines isolierten Speichers vordefiniert ist, sind isolierte Speicher eine bequeme Methode zum Festlegen eines eindeutigen Speicherbereichs ohne Dateipfadangaben.

Für Code aus dem lokalen Intranet gelten ähnliche Einschränkungen, allerdings kann dieser auf einen größeren Teil des isolierten Speichers zugreifen. Außerdem erhält Code aus der Zone der Sites, denen nicht vertraut wird (Restricted Sites Zone), keinen Zugriff auf den isolierten Speicher.

Verschlüsselung
.NET Framework unterstützt eine Gruppe von Verschlüsselungsobjekten, die Verschlüsselung ermöglichen, darunter digitale Signaturen, Hashing und die Generierung von Zufallszahlen, implementiert mit Hilfe bekannter Algorithmen wie RSA, DSA, Rijndael/AES, Triple DES, DES und RC2, sowie die Hashalgorithmen MD5, SHA1, SHA-256, SHA-384 und SHA-512. Ebenso wird die XML-Spezifikation für digitale Signaturen (entwickelt von der IETF (Internet Engineering Task Force) und dem W3C (World Wide Web Consortium) unterstützt. .NET Framework verwendet für die Unterstützung interner Dienste Verschlüsselungsobjekte. Die Objekte stehen Entwicklern, die Verschlüsselungsunterstützung benötigen, auch in Form von verwaltbarem Code zur Verfügung.

Wie Sicherheit spezifiziert wird

Änderungen am Laufzeitsicherheitsverhalten einer Assemblierung können entweder deklarativ oder imperativ sein, abhängig von den Anforderungen des Programmierers.

Deklarative Sicherheit
Deklarative Sicherheit ermöglicht einem Programmierer, die Sicherheitsanforderungen für eine Assemblierung direkt in den Metadaten des Codes für die Assemblierung anzugeben. Die Berechtigungsanforderungen und alle andere Arten deklarativer Sicherheit werden im Code in Form von benutzerdefinierten Attributen angegeben. Zum Optimieren von Berechtigungen werden Anmerkungen zu Klassen, Eigenschaften und Methoden verwendet. Deklarative Sicherheit kann z. B. eingesetzt werden, wenn überprüft werden soll, ob der Aufruf einer bestimmten Klassen von einem bekannten Autor signiert oder einen bestimmten "starken Namen" hat. Erst nach dieser Prüfung kann eine Methode aufgerufen werden.

Da deklarative Attribute Teil der Metadaten für eine Assemblierung werden, können die Sicherheitsanforderungen der Assemblierung leichter identifiziert werden. Tools können Assemblierungen untersuchen, um zu ermitteln, welche Methoden bestimmte Berechtigungen benötigen und welche Methoden bestimmte Berechtigungen zwingend voraussetzen.

Verwenden Sie deklarative Prüfungen, wenn die angefragte Aktion und die Berechtigung zur Kompilierungszeit bekannt sind. Wenn eine Methode immer prüfen soll, ob Schreibzugriff für C:\temp existiert, kann es vorteilhaft sein, wenn die Berechtigungsprüfung deklarativ ist. Auf der anderen Seite empfiehlt sich möglicherweise eher imperative Sicherheit, wenn sich der Ort, für den Schreibzugriff angefordert ist, ändern kann.

Imperative Sicherheit
Imperative Sicherheit wird direkt in den Code implementiert. Der Entwickler programmiert Sicherheitsaktionen, und die Berechtigung wird entweder erteilt oder verweigert - abhängig vom Status des Sicherheitsstacks. Wenn eine Methode eine Anforderung für den Zugriff auf eine bestimmte Datei ausgibt, schlägt diese Anforderung bei Fehlen der erforderlichen Berechtigung (auf Seiten des Aufrufes der Methode oder auf Seiten eines der Aufrufe des Aufrufes). Da die imperative Sicherheit programmiert wird, können dynamische Anforderungen erfüllt werden. Wenn Sie die Berechtigung für den Zugriff auf eine bestimmte Datei benötigen, die sich auf der Basis anderer Informationen ändert, sollten Sie imperative Sicherheit verwenden.

Zusammenfassung

Das Sicherheitssystem von .NET Framework wird den Ansprüchen von Software gerecht, die sich auf mehrere, mobile Komponenten hinbewegt, und bietet auf dieser Basis Schutz. Mit einem detailliert steuerbaren, erweiterbaren Richtlinien- und Berechtigungssystem kann der Kunde noch leistungsstärkeren Code ausführen, während gleichzeitig das betreffende hohe Sicherheitsrisiko sinkt. Das Fehlen von Entscheidungen für die Vertrauenswürdigkeit von Code zur Laufzeit ermöglicht Administratoren das Erstellen leistungsstarker Sicherheitsrichtlinien auf allen Ebenen. Richtlinien können vollständig benutzerdefiniert werden. Der Entwickler kann sich auf die Anwendungslogik konzentrieren und die Sicherheit auf Programmkernebene vernachlässigen: diese wird transparent von der CLR gehandhabt. Außerdem kann der Entwickler das Sicherheitsmodell nutzen und jederzeit erweitern.

Microsoft führt eine Onlineumfrage durch, um Ihre Meinung zur MSDN-Website zu erfahren. Wenn Sie sich zur Teilnahme entscheiden, wird Ihnen die Onlineumfrage angezeigt, sobald Sie die MSDN-Website verlassen.

Möchten Sie an der Umfrage teilnehmen?
Anzeigen:
© 2015 Microsoft