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.
Microsoft 365 erzwingt Änderungsverwaltungsverfahren, wenn sowohl Code- als auch Nicht-Code-Änderungen an seinen Systemen vorgenommen werden, um den Sicherheitsstatus beizubehalten. Jede Konfigurationsabweichung vom ursprünglichen Status kann zu Sicherheitsrisiken führen, die Funktionalität beeinträchtigen oder die Verfügbarkeit beeinträchtigen. Sobald ein Informationssystem in Microsoft 365 mit einem stabilen Sicherheitsstatus bereitgestellt wurde, werden detaillierte Änderungsverwaltungsprozesse erzwungen, um die Systemintegrität aufrechtzuerhalten.
Es gibt viele Faktoren für Änderungen in Microsoft 365, einschließlich neuer Funktions- oder Sicherheitsanforderungen, Feedback von Kunden, identifizierten Sicherheitsrisiken und Überwachungsergebnissen. Unabhängig vom Treiber für die Änderung verwenden Serviceteams Ticketing- oder Quellcodeverwaltungstools, um Genehmigungsnachweise zu dokumentieren und alle Änderungen nachzuverfolgen.
Änderungen am Quellcode
Änderungen werden gemäß dem Secure Development Lifecycle (SDL) von Microsoft bereitgestellt, auf den alle Engineering- und Entwicklungsprojekte in Microsoft 365 folgen. Dies ist ein Softwareentwicklungsmodell, das bestimmte Sicherheitsüberlegungen im Zusammenhang mit Codeüberprüfungen, Tests und Genehmigungen umfasst, bevor diese systematisch in der Microsoft 365-Umgebung veröffentlicht werden.
Das SDL fungiert als Rahmen und umfasst die Identifizierung möglicher Risiken für das fertige Entwicklungsprojekt sowie Strategien zur Risikominderung, die während der Entwicklungsphase implementiert und getestet werden können. Kritische Sicherheitsüberprüfungs- und Genehmigungsprüfpunkte sind ebenfalls enthalten.
Änderungsidentifikation und Planung
Serviceteams treffen sich regelmäßig, um vorgeschlagene Änderungen zu besprechen, einschließlich Begründung, Umfang, Sicherheitsauswirkungen, Priorität, Abhängigkeiten, Bereitstellungspläne, Rollen und Zuständigkeiten. Diese Informationen sind im Änderungsverwaltungssystem dokumentiert. Wenn die Änderung abgelehnt wird, wird die Begründung explizit im Ticket zur späteren Referenz dokumentiert.
Personalcodeüberprüfungen
Bevor neuer Code in einen neuen Build aufgenommen und bereitgestellt werden kann, muss er die Überprüfung des Personalcodes bestehen. Die Erzwingung dieser Überprüfungen erfolgt über eine automatisierte Codepipeline, die an jedes Coderepository angefügt ist, und kann nicht umgangen werden. Sobald die erforderliche Genehmigung eingegangen ist, kann der Code mit der nächsten Phase fortfahren.
Codeprüfer überprüfen auf Codierungsfehler, überprüfen, ob die Änderungen die Anforderungen erfüllen, und führen eine Analyse der Auswirkungen auf die Sicherheit durch. Überprüfungen müssen von einer anderen Person als den Personen durchgeführt werden, die den Kodex entwickelt haben, wobei das Prinzip der Aufgabentrennung durchgesetzt wird. Das Verhindern, dass dieselben Personen ihren eigenen Code übermitteln und genehmigen, ist eine wichtige Kontrolle, die Microsoft strikt erzwingt. Dies verringert die Wahrscheinlichkeit, dass Personen absichtlich oder unbeabsichtigt schädlichen oder fehlerhaften Code im Alleingang freigeben. Wenn Prüfer während der Codeüberprüfung Probleme finden, halten sie die Änderung an und lassen Entwickler den Code mit vorgeschlagenen Änderungen und zusätzlichen Tests erneut übermitteln. Codeprüfer können auch das Einchecken für Code, der die identifizierten Anforderungen nicht erfüllt, vollständig ablehnen. Sobald der Code vom Prüfer als zufriedenstellend eingestuft wird, wird die Genehmigung erteilt, und der Code wird in den Standard-Branch eingecheckt, um in den nächsten Build eingeschlossen zu werden.
Automatisierte Buildpipeline und Sicherheitsüberprüfungen
Sobald alle Änderungen für den Sprint an den Standard-Branch committet wurden, beginnt der automatisierte Buildprozess. Code wird verschiedenen automatisierten Sicherheitsüberprüfungen unterzogen, einschließlich statischer Codeanalyse, Binäranalyse, Überprüfung von Anmeldeinformationen und Geheimnissen sowie Verschlüsselungsüberprüfung. Microsoft 365 definiert eine Reihe wichtiger Tests, die jeder Build vor der Bereitstellung in Präproduktionsumgebungen bestehen muss. Builds, die nicht bestanden werden, werden abgelehnt und an das Entwicklungsteam zurückgesendet, wo Anpassungen vorgenommen werden, bis alle Überprüfungen erfolgreich sind. Erfolgreiche Builds werden über eine automatisierte Bereitstellungspipeline zur Präproduktionsumgebung weitergeleitet.
Buildrelease
Builds werden anfänglich nur für das Dienstteam freigegeben, das das Feature entwickelt hat. Stabilität und Funktionalität werden vor der Veröffentlichung in zunehmend größeren Testgruppen in logisch isolierten Cloudumgebungen getestet, die als Ringe bezeichnet werden. Nach dem Serviceteam wird der Build für alle internen Microsoft 365-Gruppen freigegeben, gefolgt von der Veröffentlichung des Builds für alle internen Microsoft-Gruppen. Diese Tests, die intern häufig als Dogfooding bezeichnet werden, ermöglichen Es Microsoft, Fehler in der wahren Produktionsumgebung zu identifizieren, bevor der Build für externe Kunden veröffentlicht wird. Diese Testmethoden stellen sicher, dass der Code von Microsoft sicher ist und erwartungsgemäß funktioniert, bevor er Kunden und die weltweite Bereitstellung erreicht. Frühere Builds werden immer für Rollbackzwecke beibehalten.
Die Entwicklungsteams bestimmen die Zeit, die ein Build in jedem Ring verbringt. In der Regel bleiben sie für mehrere Zeiträume mit hoher Auslastung, bevor sie mit dem nächsten Ring fortfahren. Wenn alle Tests in jedem internen Ring erfolgreich sind, wird der Build für Kunden weltweit freigegeben, zunächst als gezieltes Release für Kundenmandanten, die sich für diesen Ring entschieden haben, gefolgt von einem Worldwide Standard Release.
Änderungen ohne Code
Änderungen ohne Code werden als änderungen an Microsoft 365-Systemen definiert, die nicht das Erstellen oder Bearbeiten von Dienstquellcode beinhalten. Dies kann das Öffnen von Ports, das Ändern von Access Control Listen (ACLs) oder andere Änderungen am zugrunde liegenden System umfassen. Im Vergleich dazu treten Änderungen ohne Code seltener auf als Codeänderungen, erfordern aber dennoch ein hohes Maß an Überprüfung.
Eine Beschreibung der Änderung wird zusammen mit Implementierungsschritten, Validierungsschritten und einem Rollbackplan dokumentiert. Bevor die Änderung implementiert wird, werden die Pläne von mindestens einer Person auf Genauigkeit und Sicherheit überprüft. Nach der Genehmigung werden die dokumentierten Pläne implementiert. Wenn alle Überprüfungsschritte erfolgreich bestanden wurden, werden die Ergebnisse im Ticket dokumentiert und als gelöst gekennzeichnet.
Wenn die Implementierung der Änderung nicht erfolgreich ist, werden die Rollbackpläne ausgelöst, und das Team kehrt zur Planungsphase zurück und wiederholt den Prozess, bis der Vorgang erfolgreich war.