Bewährte Methoden für den Informationsschutz

Von Bedeutung

Versionen des Microsoft Rights Management Service SDK, das vor März 2020 veröffentlicht wurde, sind veraltet; Anwendungen, die frühere Versionen verwenden, müssen aktualisiert werden, um die Version vom März 2020 zu verwenden. Ausführliche Informationen finden Sie im Hinweis zur Außerkraftsetzung .

Für das Microsoft Rights Management Service SDK sind keine weiteren Verbesserungen geplant. Wir empfehlen dringend die Einführung des Microsoft Information Protection SDK für Klassifizierung, Bezeichnung und Schutzdienste.

Information Protection Software Development Kits (SDKs) bieten ein robustes System zum Veröffentlichen und Nutzen geschützter Informationen aller Arten. Damit ein System so stark wie möglich ist, müssen mithilfe bewährter Methoden Anwendungen für den Informationsschutz erstellt werden. Anwendungen teilen die Verantwortung für die Aufrechterhaltung der Sicherheit dieses Ökosystems. Die Identifizierung von Sicherheitsrisiken und die Bereitstellung von Risikominderungen für diese Risiken, die während der Anwendungsentwicklung eingeführt wurden, trägt dazu bei, die Wahrscheinlichkeit einer weniger sicheren Softwareimplementierung zu minimieren.

Diese Informationen ergänzen die rechtliche Vereinbarung, die unterzeichnet werden muss, um digitale Zertifikate für Anwendungen mit den SDKs zu erhalten.

Themen, die nicht abgedeckt sind

Obwohl die folgenden Themen wichtige Überlegungen zum Erstellen einer Entwicklungsumgebung und sicheren Anwendungen sind, haben sie keinen Gültigkeitsbereich für diesen Artikel:

  • Verwaltung von Softwareentwicklungsprozessen – Konfigurationsverwaltung , Sicherung von Quellcode, Minimieren des Zugriffs auf debuggiertem Code und Zuweisen von Priorität zu Fehlern. Für einige Kunden ist es von größter Bedeutung, einen sichereren Softwareentwicklungsprozess für sie zu haben. Einige Kunden schreiben sogar einen Entwicklungsprozess vor.
  • Häufige Codierungsfehler – Informationen zum Vermeiden von Pufferüberläufen. Wir empfehlen die neueste Version von Writing Secure Code von Michael Howard und David LeBlanc (Microsoft Press, 2002), um diese allgemeinen Bedrohungen und Abhilfemaßnahmen zu überprüfen.
  • Social Engineering – Enthält Informationen zu verfahrenstechnischen und strukturellen Schutzmaßnahmen, um Code vor der Ausbeutung durch Entwickler oder andere Personen innerhalb der Organisation des Herstellers zu schützen.
  • Physische Sicherheit – Enthält Informationen zum Sperren des Zugriffs auf Ihre Codebasis und das Signieren von Zertifikaten.
  • Bereitstellung oder Verteilung von Vorabversionssoftware – Enthält Informationen zur Verteilung Ihrer Betasoftware.
  • Netzwerkverwaltung – Enthält Informationen über Angriffserkennungssysteme in Ihren physischen Netzwerken.

Bedrohungsmodelle und Gegenmaßnahmen

Digitale Informationsbesitzer benötigen die Möglichkeit, die Umgebungen auszuwerten, in denen ihre Ressourcen entschlüsselt werden. Eine Erklärung der Mindestsicherheitsstandards bietet Informationsbesitzern ein Framework für das Verständnis und die Bewertung des Sicherheitsniveaus der Anwendungen.

Einige Branchen, z. B. Behörden und Gesundheitsversorgung, verfügen über Zertifizierungs- und Akkreditierungsprozesse und Standards, die für Ihr Produkt gelten können. Die Erfüllung dieser Mindestsicherheitsempfehlungen ist kein Ersatz für die eindeutigen Akkreditierungsanforderungen Ihrer Kunden. Die Absicht der Sicherheitsstandards besteht jedoch darin, Sie bei der Vorbereitung auf aktuelle und zukünftige Kundenanforderungen zu unterstützen, und alle Investitionen, die Sie frühzeitig im Entwicklungszyklus vornehmen, profitieren von Ihrer Anwendung. Diese Richtlinien sind Empfehlungen, kein formelles Microsoft-Zertifizierungsprogramm.

Es gibt mehrere hauptkategorien von Sicherheitsrisiken in einem Rechteverwaltungssystem, darunter:

  • Lecks – Informationen werden an nicht autorisierten Orten angezeigt.
  • Manipulation – Software oder Daten werden in nicht autorisierter Weise geändert.
  • Denial – Eine Computerressource ist nicht für die Verwendung verfügbar.

Diese Themen konzentrieren sich hauptsächlich auf Leckageprobleme. Die Integrität eines API-Systems hängt von der Fähigkeit ab, Informationen im Laufe der Zeit zu schützen und den Zugriff nur auf bestimmte Entitäten zu ermöglichen. Diese Themen befassen sich auch mit Korruptionsproblemen. Ablehnungsprobleme werden nicht behandelt.

Microsoft testt oder überprüft keine Testergebnisse im Zusammenhang mit der Erfüllung des Mindeststandards. Der Partner ist dafür verantwortlich, dass die Mindeststandards eingehalten werden. Microsoft bietet zwei zusätzliche Empfehlungen, um häufige Bedrohungen zu mindern. Im Allgemeinen sind diese Vorschläge additiv. Bei der Besprechung bevorzugter Empfehlungen wird beispielsweise davon ausgegangen, dass Sie ggf. Mindeststandards erfüllt haben, sofern nicht anders angegeben.

Standardebene BESCHREIBUNG
Mindeststandard Eine Anwendung, die geschützte Informationen verarbeitet, muss den Mindeststandard erfüllen, bevor sie mit dem von Microsoft empfangenen Produktionszertifikat signiert werden kann. Partner verwenden in der Regel das Produktionshierarchiezertifikat zum Zeitpunkt der endgültigen Veröffentlichung der Software. Die eigenen internen Tests eines Partners werden verwendet, um zu überprüfen, ob die Anwendung diesen Mindeststandard erfüllt. Die Einhaltung des Mindeststandards ist nicht und sollte nicht als Eine Garantie der Sicherheit durch Microsoft ausgelegt werden. Microsoft testt oder überprüft keine Testergebnisse im Zusammenhang mit der Erfüllung des Mindeststandards. Der Partner ist dafür verantwortlich, sicherzustellen, dass das Minimum erfüllt ist.
Empfohlener Standard Empfohlene Richtlinien zeigen sowohl einen Pfad zur verbesserten Anwendungssicherheit als auch einen Hinweis darauf, wie sich das SDK entwickeln kann, wenn mehr Sicherheitskriterien implementiert werden. Anbieter können ihre Anwendungen durch die Erstellung dieser höheren Sicherheitsrichtlinien unterscheiden.
Bevorzugter Standard Dieser Standard ist die höchste Sicherheitskategorie, die derzeit definiert ist. Anbieter, die Anwendungen entwickeln, die als hochsicher vermarktet werden, sollten auf diesen Standard abzielen. Anwendungen, die diesem Standard entsprechen, sind wahrscheinlich am wenigsten anfällig für Angriffe.

Schadsoftware

Microsoft hat mindest erforderliche Standards definiert, die Ihre Anwendung erfüllen muss, um Inhalte vor bösartiger Software zu schützen.

Importieren bösartiger Software mithilfe von Adresstabellen

Das Informationsschutz-SDK unterstützt weder Codeänderung zur Laufzeit noch Änderungen der Importadressentabelle (IAT). Für jede dll, die in Ihrem Prozessbereich geladen wird, wird eine Importadressentabelle erstellt. Es gibt die Adressen aller Funktionen an, die Ihre Anwendung importiert. Ein häufiger Angriff besteht darin, die IAT-Einträge in einer Anwendung so zu ändern, dass sie beispielsweise auf schadhafte Software verweisen. Das SDK stoppt die Anwendung, wenn diese Art von Angriff erkannt wird.

Mindeststandard

  • Sie können die Importadressentabelle während der Ausführung nicht im Anwendungsprozess ändern. Ihre Anwendung gibt viele der Funktionen an, die zur Laufzeit mithilfe von Adresstabellen aufgerufen werden. Diese Tabellen können während oder nach der Laufzeit nicht geändert werden. Diese Einschränkung bedeutet unter anderem, dass Sie keine Codeprofilerstellung für eine Anwendung ausführen können, die mit dem Produktionszertifikat signiert ist.
  • Sie können die DebugBreak-Funktion nicht innerhalb einer dll aufrufen, die im Manifest angegeben ist.
  • Sie können LoadLibrary nicht mit dem DONT_RESOLVE_DLL_REFERENCES Flagsatz aufrufen. Dieses Flag weist das Ladeprogramm an, die Bindung an die importierten Module zu überspringen und dadurch die Importadressentabelle zu ändern.
  • Sie können das Laden nicht verzögern, indem Sie laufzeit- oder nachfolgende Änderungen an der Verknüpfungsoption /DELAYLOAD vornehmen.
  • Sie können das verzögerte Laden nicht ändern, indem Sie Ihre eigene Version der Delayimp.lib-Hilfsfunktion angeben.
  • Sie können keine Module entladen, die durch authentifizierte Module verzögert geladen werden, während die Informationsschutz-SDK-Umgebung vorhanden ist.
  • Sie können den /DELAY:UNLOAD Linkerschalter nicht verwenden, um das Entladen verzögerter Module zu ermöglichen.

Falsche Interpretation von Lizenzrechten

Wenn Ihre Anwendung die in der SDK-Veröffentlichungslizenz ausgedrückten Rechte nicht ordnungsgemäß interpretiert und erzwingt, stellen Sie möglicherweise Informationen auf die Art und Weise zur Verfügung, die der Besitzer der Informationen nicht beabsichtigt hat. Wenn beispielsweise eine Anwendung es einem Benutzer ermöglicht, unverschlüsselte Informationen in neuen Medien zu speichern, wenn die Ausstellungslizenz nur das Recht zum Anzeigen der Informationen zulässt.

Azure Information Protection (AIP)

Das Information-Protection-System organisiert die Rechte in mehrere Gruppen. Weitere Informationen finden Sie unter Konfigurieren von Nutzungsrechten für Azure Information Protection.

AIP ermöglicht es einem Benutzer, Informationen zu entschlüsseln oder nicht. Die Informationen haben keinen inhärenten Schutz. Wenn ein Benutzer das Recht hat, die Entschlüsselung zu entschlüsseln, gestattet die API dies. Die Anwendung ist dafür verantwortlich, diese Informationen zu verwalten oder zu schützen, nachdem sie unverschlüsselt vorliegt. Eine Anwendung ist für die Verwaltung ihrer Umgebung und Schnittstelle verantwortlich, um die unbefugte Verwendung von Informationen zu verhindern. Beispielsweise das Deaktivieren der Schaltflächen Drucken und Kopieren, wenn eine Lizenz nur das Anzeigerecht gewährt. Ihre Testsuite sollte überprüfen, ob Ihre Anwendung für alle von ihr erkannten Lizenzrechte ordnungsgemäß funktioniert.

Mindeststandard

  • Die Kundenimplementierung von XrML v.1.2-Rechten sollte mit den Definitionen dieser Rechte übereinstimmen, wie in den XrML-Spezifikationen beschrieben, die auf der XrML-Website (http://www.xrml.org) verfügbar sind. Alle für Ihre Anwendung spezifischen Rechte müssen für alle Entitäten definiert werden, die an Ihrer Anwendung interessiert sind.
  • Die Testsuite und der Testprozess sollten sicherstellen, dass Ihre Anwendung korrekt in Übereinstimmung mit den von ihr unterstützten Rechten ausgeführt wird. Außerdem sollte überprüft werden, ob sie nicht auf nicht unterstützte Rechte reagiert.
  • Wenn Sie eine Veröffentlichungsanwendung erstellen, müssen Sie Informationen zur Verfügung stellen, die die verwendeten systeminternen Rechte erläutern. Dazu gehören diejenigen, die von der Veröffentlichungsanwendung unterstützt werden und diejenigen, die nicht unterstützt werden, sowie wie diese Rechte interpretiert werden sollen. Darüber hinaus sollte die Benutzeroberfläche dem Endbenutzer klar aufzeigen, welche Folgen es hat, wenn Einzelinformationen gewährt oder verweigert werden.
  • Alle Rechte, die durch die Einbeziehung neuer Rechte, die von einer Anwendung implementiert werden, abstrahiert werden, müssen der neuen Terminologie zugeordnet werden. Beispielsweise kann ein neues Recht namens MANAGER als abstrahierte Rechte die Rechte PRINT, COPY und EDIT enthalten.

Zurzeit keine.

Bevorzugter Standard

Zurzeit keine.

Nächste Schritte

Zu den bewährten Methoden für die Implementierung von Anwendungen mithilfe des AIP SDK gehören die folgenden Artikel:

  • Zuletzt aktualisiert um