Übersicht über Sicherheitsentwicklung und -betrieb
Wie implementiert Microsoft sichere Entwicklungsmethoden?
Der Security Development Lifecycle (SDL) von Microsoft ist ein Prozess zur Gewährleistung der Sicherheit, der sich auf die Entwicklung und den Betrieb sicherer Software konzentriert. Der SDL enthält detaillierte, messbare Sicherheitsanforderungen für Entwickler und Techniker bei Microsoft, um die Anzahl und den Schweregrad von Sicherheitsrisiken in unseren Produkten und Dienstleistungen zu reduzieren. Alle Microsoft-Softwareentwicklungsteams müssen die SDL-Anforderungen erfüllen, und wir aktualisieren das SDL kontinuierlich, um die sich ändernde Bedrohungslandschaft, bewährte Branchenmethoden und gesetzliche Standards für Compliance widerzuspiegeln.
Wie verbessert SDL von Microsoft die Anwendungssicherheit?
Der SDL-Prozess bei Microsoft kann in fünf Phasen der Entwicklung betrachtet werden: Anforderungen, Entwurf, Implementierung, Überprüfung und Release. Es beginnt mit der Definition von Softwareanforderungen unter Berücksichtigung der Sicherheit. Wir stellen sicherheitsrelevante Fragen dazu, was die Anwendung leisten muss. Muss die Anwendung beispielsweise vertrauliche Daten sammeln? Wird der Antrag vertrauliche oder wichtige Aufgaben erfüllen? Muss die Anwendung Eingaben aus nicht vertrauenswürdigen Quellen akzeptieren?
Sobald die relevanten Sicherheitsanforderungen identifiziert sind, entwerfen wir unsere Software so, dass sie Sicherheitsfunktionen enthält, die diese Anforderungen erfüllen. Unsere Entwickler implementieren SDL- und Designanforderungen in den Code, den wir durch manuelle Codeüberprüfung, automatisierte Sicherheitstools und Penetrationstests verifizieren. Bevor Der Code veröffentlicht werden kann, werden neue Features und wesentliche Änderungen abschließend einer endgültigen Sicherheits- und Datenschutzüberprüfung unterzogen, um sicherzustellen, dass alle Anforderungen erfüllt sind.
Weitere Informationen zum SDL finden Sie unter Microsoft Security Development Lifecycle.
Wie testt Microsoft Quellcode auf häufige Sicherheitsrisiken?
Um unsere Entwickler beim Implementieren von Sicherheitsanforderungen während der Codeentwicklung und nach der Veröffentlichung zu unterstützen, bietet Microsoft eine Reihe sicherer Entwicklungstools, mit denen der Quellcode automatisch auf Sicherheitslücken und -risiken überprüft werden kann. Microsoft definiert und veröffentlicht eine Liste der genehmigten Tools, die von unseren Entwicklern verwendet werden können, z. B. Compiler und Entwicklungsumgebungen, sowie die integrierten Sicherheitsüberprüfungen, die automatisch in Microsoft-Buildpipelines ausgeführt werden.
Bevor Code in einen Releasebranch eingecheckt werden kann, erfordert der SDL eine manuelle Codeüberprüfung durch einen separaten Prüfer. Codeüberprüfer suchen nach Codierungsfehlern und überprüfen, ob Codeänderungen den SDL- und Konzeptanforderungen entsprechen, ob sie Funktions- und Sicherheitstests bestehen und zuverlässig funktionieren. Außerdem prüfen sie zugeordnete Dokumentationen, Konfigurationen und Abhängigkeiten, um sicherzustellen, dass die Codeänderungen ordnungsgemäß dokumentiert wurden und keine unbeabsichtigten Nebeneffekte zur Folge haben. Wenn ein Überprüfer während der Codeüberprüfung auf Probleme stößt, kann er die einreichende Person auffordern, den Code mit den vorgeschlagenen Änderungen und nach zusätzlichen Tests erneut einzureichen. Codeüberprüfer können die Übernahme des Codes auch gänzlich verhindern, wenn dieser den Anforderungen nicht entspricht. Sobald der Code vom Prüfer als zufriedenstellend eingestuft wurde, erteilt der Prüfer eine Genehmigung, die erforderlich ist, bevor der Code mit der nächsten Bereitstellungsphase fortfahren kann.
Zusätzlich zu sicheren Entwicklungstools und manueller Codeüberprüfung erzwingt Microsoft SDL-Anforderungen mithilfe automatisierter Sicherheitstools. Viele dieser Tools sind in die Commitpipeline integriert und analysieren Code automatisch auf Sicherheitslücken, wenn er eingecheckt wird und wenn neue Builds kompiliert werden. Beispiele hierfür sind statische Codeanalyse für häufige Sicherheitslücken und Überprüfungen von Anmeldeinformationen, die Code auf eingebettete Geheimnisse analysieren. Probleme, die von automatisierten Sicherheitstools aufgedeckt werden, müssen behoben werden, bevor neue Builds die Sicherheitsüberprüfung bestehen und für die Veröffentlichung genehmigt werden können.
Wie verwaltet Microsoft Open-Source-Software?
Microsoft hat eine allgemeine Strategie für die Verwaltung von Open-Source-Sicherheit eingeführt, die Tools und Workflows verwendet, die für Folgendes konzipiert sind:
- Verstehen, welche Open Source-Komponenten in unseren Produkten und Diensten verwendet werden.
- Erfassen, wo und wie diese Komponenten verwendet werden.
- Ermitteln, ob diese Komponenten Sicherheitsrisiken aufweisen.
- Bei ermittelten Sicherheitsrisiken, die sich auf diese Komponenten auswirken, angemessen zu reagieren.
Microsoft-Entwicklungsteams sind für die Sicherheit aller Open Source-Software, die in einem Produkt oder Dienst enthalten ist, verantwortlich. Um diese Sicherheit im großen Stil zu erreichen, hat Microsoft wesentliche Funktionen in Entwicklungssysteme über Die Komponentengovernance (Component Governance, CG) integriert, die Open-Source-Erkennung, rechtliche Anforderungsworkflows und Warnungen für anfällige Komponenten automatisiert. Automatisierte CG-Tools überprüfen Builds bei Microsoft auf Open-Source-Komponenten und zugehörige Sicherheitsrisiken oder gesetzliche Verpflichtungen. Entdeckte Komponenten werden registriert und den zuständigen Teams für Business-und Security Reviews übermittelt. Diese Überprüfungen sind so ausgelegt, dass sie alle rechtlichen Verpflichtungen oder Sicherheitsrisiken auswerten, die mit Open Source-Komponenten verbunden sind, und diese beheben, bevor sie Komponenten für die Bereitstellung genehmigen.
Verwandte externe Vorschriften & Zertifizierungen
Die Onlinedienste von Microsoft werden regelmäßig auf Einhaltung externer Vorschriften und Zertifizierungen überprüft. In der folgenden Tabelle finden Sie Informationen zur Überprüfung von Steuerelementen im Zusammenhang mit der Entwicklung und dem Betrieb der Sicherheit.
Azure und Dynamics 365
| Externe Überwachungen | Section | Datum des letzten Berichts |
|---|---|---|
|
ISO 27001 Erklärung der Anwendbarkeit Zertifikat |
A.12.1.2: Steuerungen der Änderungsverwaltung A.14.2: Sicherheit in Entwicklungs- und Supportprozessen |
8. April 2024 |
|
ISO 27017 Erklärung der Anwendbarkeit Zertifikat |
A.12.1.2: Steuerungen der Änderungsverwaltung A.14.2: Sicherheit in Entwicklungs- und Supportprozessen |
8. April 2024 |
|
SOC 1 SOC 2 SOC 3 |
SDL-1: Sdl-Methodik (Security Development Lifecycle) SDL-2: Sicherheitskontrollanforderungen, die in Releases dokumentiert sind SDL-4: Trennung von Test- und Produktionsumgebungen SDL-6: Malwarescans für Quellcodebuilds SDL7: Halbjährlicher SDL-Review |
20. Mai 2024 |
Microsoft 365
| Externe Überwachungen | Section | Datum des letzten Berichts |
|---|---|---|
| FedRAMP | SA-3: Lebenszyklus der Systementwicklung | Dienstag, 21. August 2024 |
|
ISO 27001/27017 Erklärung der Anwendbarkeit Zertifizierung (27001) Zertifizierung (27017) |
A.12.1.2: Steuerungen der Änderungsverwaltung A.14.2: Sicherheit in Entwicklungs- und Supportprozessen |
März 2024 |
|
SOC 1 SOC 2 |
CA-03: Risikomanagement CA-18: Change Management CA-19: Änderungsüberwachung CA-21: Änderungstests CA-38: Baselinekonfigurationen CA-46: Sicherheitsüberprüfung |
Dienstag, 1. August 2024 |