App Control for Business und .NET
.NET-Apps (wie in einer allgemeinen Sprache wie C# geschrieben) werden in eine Intermediate Language (IL) kompiliert. IL ist ein kompaktes Codeformat, das unter jedem Betriebssystem oder jeder Architektur unterstützt werden kann. Die meisten .NET-Apps verwenden APIs, die in mehreren Umgebungen unterstützt werden, sodass nur die .NET-Runtime ausgeführt werden muss. IL muss in nativen Code kompiliert werden, um auf einer CPU ausgeführt werden zu können, z. B. Arm64 oder x64. Wenn .NET IL in ein natives Image (NI) auf einem Gerät mit einer App Control-Benutzermodusrichtlinie kompiliert, wird zuerst überprüft, ob die ursprüngliche IL-Datei die aktuellen App Control-Richtlinien übergibt. Falls ja, legt .NET ein erweitertes NTFS-Attribut (EA) für die generierte NI-Datei fest, sodass App Control ihr auch vertrauen kann. Wenn die .NET-App ausgeführt wird, sieht App Control den EA in der NI-Datei und lässt es zu.
Der in der NI-Datei festgelegte EA gilt nur für die derzeit aktiven App-Steuerungsrichtlinien. Wenn eine der aktiven App Control-Richtlinien aktualisiert oder eine neue Richtlinie angewendet wird, wird der EA in der NI-Datei ungültig gemacht. Wenn die App das nächste Mal ausgeführt wird, blockiert App Control die NI-Datei. .NET behandelt den Block ordnungsgemäß und greift auf den ursprünglichen IL-Code zurück. Wenn die IL weiterhin die neuesten App Control-Richtlinien übergibt, wird die App ohne auswirkungen auf die Funktion ausgeführt. Da die IL jetzt zur Laufzeit kompiliert wird, können Sie eine leichte Auswirkung auf die Leistung der App feststellen. Wenn .NET auf IL zurückgreifen muss, plant .NET auch einen Prozess, der im nächsten Wartungsfenster ausgeführt wird, um alle NI-Dateien neu zu generieren. Auf diese Weise wird die App-Steuerungs-EA für den gesamten Code wiederhergestellt, der die neuesten App Control-Richtlinien übergibt.
Wenn eine NI-Datei blockiert ist, wird im Ereignisprotokoll CodeIntegrity – Operational möglicherweise ein "falsch positives" Blockereignis angezeigt, wie unter App Control Admin Tips & Known Issues beschrieben.
Gehen Sie wie folgt vor, um Leistungseinbußen zu minimieren, die verursacht werden, wenn der Ea für die App-Steuerung ungültig ist oder fehlt:
- Vermeiden Sie es, die App-Steuerungsrichtlinien häufig zu aktualisieren.
- Führen Sie
ngen update(auf allen Computerarchitekturen) aus, um zu erzwingen, dass .NET alle NI-Dateien sofort nach dem Anwenden von Änderungen an Ihren App Control-Richtlinien neu generiert. - Migrieren von Anwendungen zu .NET Core (.NET 6 oder höher).
App-Steuerelement und .NET-Härtung
Sicherheitsexperten haben festgestellt, dass einige .NET-Funktionen, mit denen Apps Bibliotheken aus externen Quellen laden oder zur Laufzeit neuen Code generieren können, verwendet werden können, um App Control-Steuerelemente zu umgehen. Um dieses potenzielle Sicherheitsrisiko zu beheben, enthält App Control eine Option namens Dynamic Code Security , die mit .NET funktioniert, um zu überprüfen, ob Zur Laufzeit Code geladen wurde.
Wenn die Option Dynamische Codesicherheit aktiviert ist, wird die App-Steuerungsrichtlinie auf Bibliotheken angewendet, die .NET aus externen Quellen lädt. Beispielsweise alle Remotequellen, z. B. das Internet oder eine Netzwerkfreigabe.
Wichtig
Die Sicherheitshärtung für dynamischen .NET-Code wird aktiviert und erzwungen , wenn eine App Control-Richtlinie mit aktivierter UMCI die Option 19 Aktiviert:Dynamische Codesicherheit festgelegt hat. Für dieses Feature gibt es keinen Überwachungsmodus. Sie sollten Ihre Apps mit dieser Option testen, bevor Sie sie auf einer großen Anzahl von Geräten aktivieren.
Darüber hinaus erkennt es Manipulationen an Code, der von .NET auf dem Datenträger generiert wurde, und blockiert das Laden von Code, der manipuliert wurde.
Dynamische Codesicherheit ist standardmäßig nicht aktiviert, da vorhandene Richtlinien möglicherweise keine extern geladenen Bibliotheken berücksichtigen. Darüber hinaus werden einige .NET-Ladefeatures, einschließlich des Ladens nicht signierter Assemblys, die mit System.Reflection.Emit erstellt wurden, derzeit nicht unterstützt, wenn Dynamic Code Security aktiviert ist. Microsoft empfiehlt, dynamische Codesicherheit im Überwachungsmodus zu testen, bevor Sie sie erzwingen, um zu ermitteln, ob neue Bibliotheken in die Richtlinie einbezogen werden sollen.
Darüber hinaus können Kunden die Bereitstellung nur vorkompilieren, um zu verhindern, dass eine zulässige ausführbare Datei beendet wird, da sie versucht, nicht signierten dynamisch generierten Code zu laden. Informationen zum Beheben dieses Problems finden Sie im Abschnitt "Vorkompilieren nur für die Bereitstellung" im Dokument ASP.NET Übersicht über die Vorkompilierung .
Um Dynamic Code Security zu aktivieren, fügen Sie dem Abschnitt Ihrer App-Steuerungsrichtlinie die <Rules> folgende Option hinzu:
<Rule>
<Option>Enabled:Dynamic Code Security</Option>
</Rule>