Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Verwenden Sie nur zugelassene symmetrische Blockchiffren und Schlüssellängen
| Titel | Einzelheiten |
|---|---|
| Komponente | Webanwendung. |
| SDL-Phase | Bauen |
| Zutreffende Technologien | Allgemein |
| Attribute | Nicht verfügbar |
| Informationsquellen | Nicht verfügbar |
| Schritte | Produkte dürfen nur die symmetrischen Blockchiffren und die zugehörigen Schlüssellängen verwenden, die explizit vom Crypto Advisor in Ihrem Unternehmen genehmigt wurden. Zu den bei Microsoft zugelassenen symmetrischen Algorithmen gehören die folgenden Blockchiffren:
Bitte beachten Sie, dass alle symmetrischen Blockchiffren mit einem zugelassenen Verschlüsselungsmodus verwendet werden müssen, der die Verwendung eines geeigneten Initialisierungsvektors (IV) erfordert. Ein geeigneter IV ist in der Regel eine Zufallszahl und niemals ein konstanter Wert Die Verwendung von älteren oder anderweitig nicht genehmigten Kryptoalgorithmen und kleineren Schlüssellängen zum Lesen vorhandener Daten (im Gegensatz zum Schreiben neuer Daten) kann nach der Überprüfung durch das Crypto Board Ihrer Organisation zulässig sein. Sie müssen jedoch eine Ausnahme von dieser Anforderung beantragen. Darüber hinaus sollten Produkte bei Unternehmensbereitstellungen erwägen, Administratoren zu warnen, wenn schwache Kryptowährung zum Lesen von Daten verwendet wird. Solche Warnungen sollten erläuternd und umsetzbar sein. In einigen Fällen kann es angebracht sein, die Verwendung schwacher Kryptowährungen von der Gruppenrichtlinie steuern zu lassen. Zulässige .NET-Algorithmen für verwaltete Krypto-Agilität (in der Reihenfolge ihrer Präferenz)
Bitte beachten Sie, dass keiner dieser Algorithmen über die |
Verwenden Sie genehmigte Blockchiffre-Modi und Initialisierungsvektoren für symmetrische Chiffren
| Titel | Einzelheiten |
|---|---|
| Komponente | Webanwendung. |
| SDL-Phase | Bauen |
| Zutreffende Technologien | Allgemein |
| Attribute | Nicht verfügbar |
| Informationsquellen | Nicht verfügbar |
| Schritte | Alle symmetrischen Blockchiffren müssen mit einem zugelassenen symmetrischen Verschlüsselungsmodus verwendet werden. Die einzigen zugelassenen Modi sind CBC und CTS. Insbesondere sollte die Funktionsweise des elektronischen Codebuchs (EZB) vermieden werden. Die Nutzung der EZB erfordert die Überprüfung durch das Crypto Board Ihrer Organisation. Jegliche Verwendung von OFB, CFB, CTR, CCM und GCM oder einem anderen Verschlüsselungsmodus muss vom Crypto Board Ihrer Organisation überprüft werden. Die Wiederverwendung desselben Initialisierungsvektors (IV) mit Blockchiffren in "Streaming-Chiffren-Modi", wie z. B. CTR, kann dazu führen, dass verschlüsselte Daten offengelegt werden. Alle symmetrischen Blockchiffren müssen auch mit einem entsprechenden Initialisierungsvektor (IV) verwendet werden. Ein passender IV ist eine kryptographisch starke, zufällige Zahl und niemals ein konstanter Wert. |
Verwenden Sie genehmigte asymmetrische Algorithmen, Schlüssellängen und Auffüllungen
| Titel | Einzelheiten |
|---|---|
| Komponente | Webanwendung. |
| SDL-Phase | Bauen |
| Zutreffende Technologien | Allgemein |
| Attribute | Nicht verfügbar |
| Informationsquellen | Nicht verfügbar |
| Schritte | Die Verwendung verbotener kryptografischer Algorithmen birgt ein erhebliches Risiko für die Produktsicherheit und muss vermieden werden. Produkte dürfen nur die kryptografischen Algorithmen und die zugehörigen Schlüssellängen und Auffüllungen verwenden, die explizit vom Crypto Board Ihrer Organisation genehmigt wurden.
|
Verwenden Sie zugelassene Zufallszahlengeneratoren
| Titel | Einzelheiten |
|---|---|
| Komponente | Webanwendung. |
| SDL-Phase | Bauen |
| Zutreffende Technologien | Allgemein |
| Attribute | Nicht verfügbar |
| Informationsquellen | Nicht verfügbar |
| Schritte | Produkte müssen zugelassene Zufallszahlengeneratoren verwenden. Pseudozufallsfunktionen wie die C-Laufzeitfunktion rand, die .NET Framework-Klasse System.Random oder Systemfunktionen wie GetTickCount dürfen daher niemals in solchem Code verwendet werden. Die Verwendung des DUAL_EC_DRBG-Algorithmus (Dual Elliptic Curve Random Number Generator) ist verboten
|
Verwenden Sie keine symmetrischen Stromchiffren
| Titel | Einzelheiten |
|---|---|
| Komponente | Webanwendung. |
| SDL-Phase | Bauen |
| Zutreffende Technologien | Allgemein |
| Attribute | Nicht verfügbar |
| Informationsquellen | Nicht verfügbar |
| Schritte | Symmetrische Stromchiffren, wie z.B. RC4, dürfen nicht verwendet werden. Anstelle von symmetrischen Stromchiffren sollten Produkte eine Blockchiffre verwenden, insbesondere AES mit einer Schlüssellänge von mindestens 128 Bit. |
Verwenden Sie genehmigte MAC/HMAC/Keyed-Hash-Algorithmen
| Titel | Einzelheiten |
|---|---|
| Komponente | Webanwendung. |
| SDL-Phase | Bauen |
| Zutreffende Technologien | Allgemein |
| Attribute | Nicht verfügbar |
| Informationsquellen | Nicht verfügbar |
| Schritte | Produkte dürfen nur MAC-Algorithmen (Approved Message Authentication Code) oder HMAC-Algorithmen (Hash-Based Message Authentication Code) verwenden. Ein Nachrichtenauthentifizierungscode (Message Authentication Code, MAC) ist eine Information, die an eine Nachricht angehängt ist und es dem Empfänger ermöglicht, sowohl die Authentizität des Absenders als auch die Integrität der Nachricht mithilfe eines geheimen Schlüssels zu überprüfen. Die Verwendung einer Hash-basierten MAC (HMAC) oder einer Block-Cipher-basierten MAC ist zulässig, solange alle zugrunde liegenden Hash- oder symmetrischen Verschlüsselungsalgorithmen ebenfalls für die Verwendung zugelassen sind. Dazu gehören derzeit die HMAC-SHA2 Funktionen (HMAC-SHA256, HMAC-SHA384 und HMAC-SHA512) sowie die CMAC/OMAC1 und OMAC2 Block Cipher-basierten MACs (diese basieren auf AES). Die Verwendung von HMAC-SHA1 kann aus Gründen der Plattformkompatibilität zulässig sein, aber Sie müssen eine Ausnahme von diesem Verfahren einreichen und sich der Crypto-Überprüfung Ihrer Organisation unterziehen. Das Abschneiden von HMACs auf weniger als 128 Bit ist nicht zulässig. Die Verwendung von Kundenmethoden zum Hashen eines Schlüssels und von Daten wird nicht genehmigt und muss vor der Verwendung der Crypto Board-Überprüfung Ihrer Organisation unterzogen werden. |
Verwenden Sie nur genehmigte kryptografische Hash-Funktionen
| Titel | Einzelheiten |
|---|---|
| Komponente | Webanwendung. |
| SDL-Phase | Bauen |
| Zutreffende Technologien | Allgemein |
| Attribute | Nicht verfügbar |
| Informationsquellen | Nicht verfügbar |
| Schritte | Produkte müssen die SHA-2-Familie von Hash-Algorithmen (SHA256, SHA384 und SHA512) verwenden. Wenn ein kürzerer Hash benötigt wird, z. B. eine Ausgabelänge von 128 Bit, um eine Datenstruktur anzupassen, die mit dem kürzeren MD5-Hash im Hinterkopf entwickelt wurde, können Produktteams einen der SHA2-Hashes (in der Regel SHA256) kürzen. Beachten Sie, dass SHA384 eine gekürzte Version von SHA512 ist. Das Abschneiden von kryptografischen Hashes aus Sicherheitsgründen auf weniger als 128 Bit ist nicht zulässig. Neuer Code darf die Hashalgorithmen MD2, MD4, MD5, SHA-0, SHA-1 oder RIPEMD nicht verwenden. Hash-Kollisionen sind für diese Algorithmen rechnerisch machbar, wodurch sie effektiv unterbrochen werden. Zulässige .NET-Hashalgorithmen für verwaltete Kryptoagilität (in der Reihenfolge ihrer Präferenz):
|
Verwenden Sie starke Verschlüsselungsalgorithmen, um Daten in der Datenbank zu verschlüsseln
| Titel | Einzelheiten |
|---|---|
| Komponente | Datenbank |
| SDL-Phase | Bauen |
| Zutreffende Technologien | Allgemein |
| Attribute | Nicht verfügbar |
| Informationsquellen | Auswahl eines Verschlüsselungsalgorithmus |
| Schritte | Verschlüsselungsalgorithmen definieren Datentransformationen, die nicht einfach von nicht autorisierten Benutzern rückgängig gemacht werden können. SQL Server ermöglicht Administratoren und Entwicklern die Auswahl zwischen mehreren Algorithmen, darunter DES, Triple DES, TRIPLE_DES_3KEY, RC2, RC4, 128-Bit-RC4, DESX, 128-Bit-AES, 192-Bit-AES und 256-Bit-AES |
SSIS-Pakete sollten verschlüsselt und digital signiert werden
| Titel | Einzelheiten |
|---|---|
| Komponente | Datenbank |
| SDL-Phase | Bauen |
| Zutreffende Technologien | Allgemein |
| Attribute | Nicht verfügbar |
| Informationsquellen | Identifizieren der Quelle von Paketen mit digitalen Signaturen, Bedrohungs- und Schwachstellenminderung (Integration Services) |
| Schritte | Die Quelle eines Pakets ist die Einzelperson oder die Organisation, die das Paket erstellt hat. Das Ausführen eines Pakets von einer unbekannten oder nicht vertrauenswürdigen Quelle kann riskant sein. Um unbefugte Manipulationen an SSIS-Paketen zu verhindern, sollten digitale Signaturen verwendet werden. Um die Vertraulichkeit der Pakete während der Lagerung/des Transports zu gewährleisten, müssen SSIS-Pakete verschlüsselt werden |
Hinzufügen einer digitalen Signatur zu kritischen sicherungsfähigen Datenbanken
| Titel | Einzelheiten |
|---|---|
| Komponente | Datenbank |
| SDL-Phase | Bauen |
| Zutreffende Technologien | Allgemein |
| Attribute | Nicht verfügbar |
| Informationsquellen | SIGNATUR HINZUFÜGEN (Transact-SQL) |
| Schritte | In Fällen, in denen die Integrität einer kritischen sicherungsfähigen Datenbank überprüft werden muss, sollten digitale Signaturen verwendet werden. Sicherungsfähige Datenbankdateien, z. B. eine gespeicherte Prozedur, eine Funktion, eine Assembly oder ein Trigger, können digital signiert werden. Im Folgenden finden Sie ein Beispiel dafür, wann dies nützlich sein kann: Nehmen wir an, ein ISV (Independent Software Vendor) hat Support für eine Software geleistet, die an einen seiner Kunden geliefert wurde. Vor der Bereitstellung von Support möchte der ISV sicherstellen, dass eine in der Software sicherungsfähige Datenbank weder versehentlich noch durch einen böswilligen Versuch manipuliert wurde. Wenn das sicherungsfähige Element digital signiert ist, kann der ISV seine digitale Signatur überprüfen und seine Integrität überprüfen. |
Verwenden von SQL Server EKM zum Schützen von Verschlüsselungsschlüsseln
| Titel | Einzelheiten |
|---|---|
| Komponente | Datenbank |
| SDL-Phase | Bauen |
| Zutreffende Technologien | Allgemein |
| Attribute | Nicht verfügbar |
| Informationsquellen | SQL Server Extensible Key Management (EKM), ExtensibleKey Management mit Azure Key Vault (SQL Server) |
| Schritte | SQL Server Extensible Key Management ermöglicht es, die Verschlüsselungsschlüssel, die die Datenbankdateien schützen, in einem externen Gerät wie einer Smartcard, einem USB-Gerät oder einem EKM/HSM-Modul zu speichern. Dies ermöglicht auch den Datenschutz von Datenbankadministratoren (mit Ausnahme von Mitgliedern der Sysadmin-Gruppe). Daten können mithilfe von Verschlüsselungsschlüsseln verschlüsselt werden, auf die nur der Datenbankbenutzer zugriff auf das externe EKM/HSM-Modul hat. |
Verwenden der AlwaysEncrypted-Funktion, wenn Verschlüsselungsschlüssel nicht für das Datenbankmodul offengelegt werden sollen
| Titel | Einzelheiten |
|---|---|
| Komponente | Datenbank |
| SDL-Phase | Bauen |
| Zutreffende Technologien | SQL Azure, lokal |
| Attribute | SQL-Version – V12, MsSQL2016 |
| Informationsquellen | „Immer verschlüsselt“ (Datenbank-Engine) |
| Schritte | Always Encrypted ist ein Feature zum Schutz vertraulicher Daten, z. B. Kreditkartennummern oder nationale/regionale Identifikationsnummern (z. B. Sozialversicherungsnummern in den USA), die in Azure SQL-Datenbank oder SQL Server-Datenbanken gespeichert sind. Always Encrypted ermöglicht Clients, vertrauliche Daten in Clientanwendungen zu verschlüsseln und die Verschlüsselungsschlüssel niemals für das Datenbankmodul (SQL-Datenbank oder SQL Server) offenzulegen. Daher bietet Always Encrypted eine Trennung zwischen denjenigen, die die Daten besitzen (und sie anzeigen können) und denen, die die Daten verwalten (aber keinen Zugriff haben sollten) |
Speichern Sie kryptografische Schlüssel sicher auf einem IoT-Gerät
| Titel | Einzelheiten |
|---|---|
| Komponente | IoT-Gerät |
| SDL-Phase | Bauen |
| Zutreffende Technologien | Allgemein |
| Attribute | Gerätebetriebssystem – Windows IoT Core, Gerätekonnektivität – Azure IoT-Geräte-SDKs |
| Informationsquellen | TPM unter Windows IoT Core, Einrichten von TPM unter Windows IoT Core, Azure IoT Device SDK TPM |
| Schritte | Symmetrische oder private Zertifikatschlüssel sicher in einem hardwaregeschützten Speicher wie TPM- oder Smartcard-Chips. Windows 10 IoT Core unterstützt den Benutzer eines TPM, und es gibt mehrere kompatible TPMs, die verwendet werden können: Diskretes TPM (dTPM). Es wird empfohlen, eine Firmware oder ein diskretes TPM zu verwenden. Ein Software-TPM sollte nur zu Entwicklungs- und Testzwecken verwendet werden. Sobald ein TPM verfügbar ist und die Schlüssel darin bereitgestellt werden, sollte der Code, der das Token generiert, ohne vertrauliche Informationen fest codiert werden. |
Beispiel
TpmDevice myDevice = new TpmDevice(0);
// Use logical device 0 on the TPM
string hubUri = myDevice.GetHostName();
string deviceId = myDevice.GetDeviceId();
string sasToken = myDevice.GetSASToken();
var deviceClient = DeviceClient.Create( hubUri, AuthenticationMethodFactory. CreateAuthenticationWithToken(deviceId, sasToken), TransportType.Amqp);
Wie zu sehen ist, ist der Primärschlüssel des Geräts nicht im Code vorhanden. Stattdessen wird es im TPM an Steckplatz 0 gespeichert. Das TPM-Gerät generiert ein kurzlebiges SAS-Token, das dann zum Herstellen einer Verbindung mit dem IoT Hub verwendet wird.
Generieren eines zufälligen symmetrischen Schlüssels mit ausreichender Länge für die Authentifizierung bei IoT Hub
| Titel | Einzelheiten |
|---|---|
| Komponente | IoT Cloud Gateway |
| SDL-Phase | Bauen |
| Zutreffende Technologien | Allgemein |
| Attribute | Wahl des Gateways: Azure IoT Hub |
| Informationsquellen | Nicht verfügbar |
| Schritte | IoT Hub enthält eine Geräteidentitätsregistrierung, und beim Bereitstellen eines Geräts wird automatisch ein zufälliger symmetrischer Schlüssel generiert. Es wird empfohlen, dieses Feature der Azure IoT Hub-Identitätsregistrierung zu verwenden, um den für die Authentifizierung verwendeten Schlüssel zu generieren. IoT Hub ermöglicht auch die Angabe eines Schlüssels beim Erstellen des Geräts. Wenn während der Gerätebereitstellung ein Schlüssel außerhalb von IoT Hub generiert wird, wird empfohlen, einen zufälligen symmetrischen Schlüssel oder mindestens 256 Bit zu erstellen. |
Stellen Sie sicher, dass eine Geräteverwaltungsrichtlinie vorhanden ist, die eine PIN erfordert und das Löschen aus der Ferne zulässt.
| Titel | Einzelheiten |
|---|---|
| Komponente | Dynamics CRM Mobiler Client |
| SDL-Phase | Einsatz |
| Zutreffende Technologien | Allgemein |
| Attribute | Nicht verfügbar |
| Informationsquellen | Nicht verfügbar |
| Schritte | Stellen Sie sicher, dass eine Geräteverwaltungsrichtlinie vorhanden ist, die eine PIN erfordert und das Löschen aus der Ferne zulässt. |
Stellen Sie sicher, dass eine Geräteverwaltungsrichtlinie vorhanden ist, die eine PIN/ein Passwort/eine automatische Sperre erfordert und alle Daten (z. B. BitLocker) verschlüsselt.
| Titel | Einzelheiten |
|---|---|
| Komponente | Dynamics CRM Outlook-Client |
| SDL-Phase | Bauen |
| Zutreffende Technologien | Allgemein |
| Attribute | Nicht verfügbar |
| Informationsquellen | Nicht verfügbar |
| Schritte | Stellen Sie sicher, dass eine Geräteverwaltungsrichtlinie vorhanden ist, die eine PIN/ein Passwort/eine automatische Sperre erfordert und alle Daten (z. B. BitLocker) verschlüsselt. |
Sicherstellen, dass bei Verwendung von Identity Server ein Rollover für Signaturschlüssel ausgeführt wird.
| Titel | Einzelheiten |
|---|---|
| Komponente | Identitätsserver |
| SDL-Phase | Einsatz |
| Zutreffende Technologien | Allgemein |
| Attribute | Nicht verfügbar |
| Informationsquellen | Nicht verfügbar |
| Schritte | Stellen Sie sicher, dass bei Verwendung von Identity Server ein Rollover für Signaturschlüssel ausgeführt wird. Der Link im Abschnitt "Referenzen" erläutert, wie dies geplant werden sollte, ohne dass es zu Ausfällen für Anwendungen kommt, die auf Identity Server angewiesen sind. |
Stellen Sie sicher, dass die kryptografisch sichere Client-ID und der geheime Clientschlüssel in Identity Server verwendet werden
| Titel | Einzelheiten |
|---|---|
| Komponente | Identitätsserver |
| SDL-Phase | Bauen |
| Zutreffende Technologien | Allgemein |
| Attribute | Nicht verfügbar |
| Informationsquellen | Nicht verfügbar |
| Schritte | Stellen Sie sicher, dass die kryptografisch sichere Client-ID und der geheime Clientschlüssel in Identity Server verwendet werden. Die folgenden Richtlinien sollten beim Generieren einer Client-ID und eines geheimen Schlüssels verwendet werden:
|