Letzte Woche war wieder Patchday für Magento. Aus diesem Anlass möchte ich einen Einblick geben, wie wir bei integer_net mit geplanten Sicherheitsupdates umgehen. Dank dieses Prozesses konnten wir die Shops für alle 20 aktiven Projekte innerhalb von weniger als 24 Stunden aktualisieren.
Unsere Herangehensweise: planbar und strukturiert
- Adobes Veröffentlichungszeitplan: Wir nutzen den strukturierten Veröffentlichungszeitplan von Adobe, nach dem alle zwei Monate Sicherheits-Patches veröffentlicht werden. Dank dieser Vorhersehbarkeit können wir unseren Patch-Implementierungsprozess weit im Voraus planen und so eine reibungslose Ausführung ohne Überraschungen in letzter Minute gewährleisten.
- Rollen und Zuständigkeiten: Einen Monat vor dem Patchday weisen wir den Teammitgliedern ihre Rollen zu. Es gibt eine Patchday-Koordinatorin und einen Entwickler, der für die Risikobewertung zuständig ist. Beide haben eine:n Vertreter:in für den Fall, dass unvorhergesehene Umstände eintreten. Dies gewährleistet eine klare Verantwortlichkeit und strafft den Prozess der Patchbereitstellung.
- Transparente Kommunikation: Wir informieren unsere Kunden proaktiv über anstehende Patches, was für Transparenz sorgt und Vertrauen schafft. Außerdem können sie die Abnahmetests auf ihrer Seite im Voraus planen. Wir erstellen Tickets für jedes Projekt und halten alle Beteiligten über den Status jedes einzelnen Schrittes auf dem Laufenden. Sie sind mit einem Haupt-Patchday-Ticket verknüpft, sodass unser Patchday-Koordinator immer den vollen Überblick hat.
- Robuster Plan für Qualitätssicherung: Wir erstellen für jedes Projekt einen Quality-Assurance-Plan, in dem klar festgelegt ist, wer für die Tests verantwortlich ist. Wir verwenden Qase für die Testfallverwaltung. Für Patchdays gibt es in jedem Projekt eine Testlaufvorlage, die nur Tests mit hoher Priorität enthält, sodass wir schnell beurteilen können, ob kritische Funktionalitäten noch einwandfrei funktionieren.
Darüber hinaus bestimmen wir, welche Features (Funktionen) betroffen sind und genau getestet werden sollten. Der Entwickler fertigt hierfür eine Risikobewertung des geänderten Codes an. - Priorität: Ein Sicherheitsupdate hat die höchste Priorität. Es SOLLTE so schnell wie möglich in das Livesystem eingespielt werden. Alle anderen Releases (Veröffentlichungen) oder ein Update der Magento-Versionen dürfen den Sicherheitspatch NICHT blockieren. Es gibt keine Ausnahmen, auch wenn das reguläre Release bereits im Staging* ist!
Für KRITISCHE Patches haben wir einen Notfallprozess und die Regel, dass alle Shops innerhalb von maximal 24 Stunden gepatcht werden MÜSSEN (unser Rekord liegt bei etwa 6 Stunden). Im Zweifelsfall bedeutet das, dass wir nicht auf die Abnahmetests der Kunden warten, um sie zu schützen.
*Ein Staging-System ist eine möglichst ähnliche Kopie des Livesystems.
Was ist ein KRITISCHER Patch?
Wir verwenden das Common Vulnerability Scoring System (CVSS), um festzustellen, wie kritisch das Sicherheitsproblem ist. Ein Sicherheitspatch für eine Schwachstelle mit einem CVSS-Score von 9.0-10.0 wird als KRITISCH eingestuft. CVSS-Scores für Magento-Sicherheitsupdates können unter folgender URL abrufen werden: https://helpx.adobe.com/security/security-bulletin.html#magento. Sobald sie verfügbar sind, prüft die Patchday-Koordinatorin, ob der „kritische Notfall-Patch“-Prozess eingeleitet werden muss. In diesem Fall hat das gesamte Team nur eine gemeinsame Priorität: alle Shops so schnell wie möglich zu patchen.
Fazit
Wir bei integer_net wissen, dass Sicherheit nicht nur eine einmalige Angelegenheit ist, sondern eine ständige Verpflichtung. Deshalb überwachen und aktualisieren wir unsere Sicherheitsprozesse kontinuierlich, um neuen Bedrohungen und Schwachstellen immer einen Schritt voraus zu sein. Bei uns können Sie sicher sein, dass Ihr Magento-Shop in sicheren Händen ist, sodass Sie sich auf das konzentrieren können, was Sie am besten können: die Führung und das Wachstum Ihres Unternehmens.
Möglich wird dies durch den vorhersehbaren, standardisierten Prozess der Sicherheitsfreigabe durch Adobe.
Bildnachweis: Alan O’Rourke (CC-BY 2.0)