Sicherheitsfragebögen fragen fast immer danach, wie ein Anbieter mit Patches umgeht: wie schnell bekannte Schwachstellen behoben werden und wie Updates in die Produktion gelangen, ohne etwas zu beschädigen. Dieser Artikel beantwortet genau das.
Zusammenfassung
edyoucated ist ausschließlich Cloud-Software. Es gibt nichts für Sie zu installieren und daher auch nichts, was Sie patchen müssten.
Jeder Kunde nutzt immer die aktuelle Version der Plattform.
Wir scannen fortlaufend nach Schwachstellen in unserem eigenen Code und in den von uns genutzten Drittanbieter-Komponenten.
Befunde werden danach bewertet, ob sie in unserer Umgebung tatsächlich ausnutzbar sind, nicht nur anhand eines generischen Schweregrads, und werden innerhalb festgelegter Fristen behoben.
Jedes Update, einschließlich Sicherheitskorrekturen, durchläuft dieselben automatisierten Testschritte und gestaffelten Umgebungen, bevor es bei Ihnen ankommt.
Es gibt nichts, was Sie patchen müssen
edyoucated wird ausschließlich als Multi-Tenant-Cloud-Software bereitgestellt. Es gibt keine On-Premise-Version und keine Client-Software, die in Ihrer eigenen IT-Umgebung läuft. Damit entfällt eine ganze Risikokategorie: Es existiert nirgendwo eine Version von edyoucated, die hinter einem Sicherheitsupdate zurückgeblieben ist, und es gibt keinen Patch-Zyklus, den Sie planen müssten.
Wer ist wofür verantwortlich
Ebene | Verantwortlich |
Physische Infrastruktur, Netzwerk, Host-Betriebssysteme, verwaltete Laufzeitumgebungen | Unsere Cloud-Anbieter. Beide Umgebungen sind ISO/IEC-27001-zertifiziert und werden regelmäßig von zertifizierten, unabhängigen Partnern penetrationsgetestet. |
Anwendungscode und Drittanbieter-Komponenten | edyoucated |
Plattformkonfiguration, Zugriffskontrolle, Trennung zwischen Kunden | edyoucated |
Mitarbeitergeräte, die zum Entwickeln und Betreiben der Plattform genutzt werden | edyoucated |
Ihre eigene Benutzerverwaltung: Rollen, Konfiguration des Identity Providers, Offboarding Ihrer Mitarbeitenden | Sie |
Wie wir Sicherheitsprobleme finden
Kontinuierliches automatisiertes Scannen jeder Drittanbieter-Komponente, von der unsere Anwendungen abhängen, ausgewertet in einem festen wöchentlichen Zyklus.
Abgleich mit Sicherheitswarnungen (Security Advisories), der uns alarmiert, wenn eine von uns tatsächlich genutzte Komponente in einer neu veröffentlichten Warnung genannt wird.
Sicherheitsbulletins unserer Cloud-Anbieter. Die Pflege eines Informationskanals mit unseren Anbietern zu veröffentlichten Updates und Patches ist eine feste Verpflichtung in unseren technischen und organisatorischen Maßnahmen.
Automatisiertes Secret-Scanning über unseren gesamten Code, das Zugangsdaten erkennt, die niemals hätten committet werden dürfen.
Kontinuierliches Fehler- und Anomalie-Monitoring in der Produktion, das wöchentlich ausgewertet wird und ungewöhnliches Verhalten sowie Ausnutzungsversuche sichtbar macht.
Eine Web Application Firewall mit Rate Limiting vor allen öffentlichen Endpunkten. Sie blockiert nicht nur gängige Angriffe, sondern erlaubt es uns auch, die Ausnutzung eines bekannten Problems abzuschwächen, während eine endgültige Korrektur vorbereitet wird.
Wie wir Befunde bewerten
Jeder Befund wird nach zwei Kriterien bewertet: wie schwerwiegend er ist und ob er in unserer Architektur tatsächlich ausnutzbar ist. Für die Priorisierung entscheidend ist nicht der generische Anbieter-Score, sondern ob der betroffene Codepfad in unserem Deployment überhaupt erreichbar ist und mit welchen Rechten. Eine Schwachstelle mit hoher Bewertung in einer Komponente, die wir nur in unserem Test-Tooling nutzen, stellt nicht das gleiche Risiko dar wie eine mittelschwere Schwachstelle auf einem produktiven Pfad.
Wie schnell wir reagieren
Sicherheitsbefunde werden nach derselben Skala wie jede andere Störung priorisiert, sodass eine Schwachstelle und ein gewöhnlicher Fehler denselben Prozess durchlaufen statt zwei getrennte. Die Kategorien, angewendet auf Sicherheitsbefunde, sind:
Kritisch: ausnutzbar gegen die Produktion ohne Konto, oder würde Zugriff über Kundengrenzen hinweg, eine Rechteausweitung auf Administratorrechte oder die Ausführung von Code aus der Ferne (Remote Code Execution) ermöglichen.
Signifikant: nur mit einem Konto oder unter ungewöhnlichen Bedingungen ausnutzbar, oder ein Befund mit hohem Schweregrad in einer Komponente, deren betroffener Pfad in der Produktion erreichbar ist.
Niedrig: Der betroffene Pfad ist in unserem Deployment nicht erreichbar, oder die Komponente ist auf Entwicklungs-, Test- oder Tooling-Umgebungen beschränkt.
Jede Kategorie ist mit einer verbindlichen Reaktionszeit und einem Lösungsziel verknüpft. Darüber hinaus gilt:
Kritische Korrekturen werden außerhalb des regulären wöchentlichen Zyklus veröffentlicht. Der Auslieferungsweg und alle seine Testschritte bleiben gleich, nur der Zeitplan ändert sich.
Für kritische und signifikante Befunde richten wir, wo möglich, einen Workaround ein, bis die endgültige Korrektur ausgeliefert wird. Bei einem Sicherheitsproblem kann das eine schützende Maßnahme wie eine Firewall-Regel, ein Rate Limit oder das vorübergehende Deaktivieren der betroffenen Funktion sein, statt einer Codeänderung.
Kann ein Befund nicht innerhalb des Zielzeitraums gelöst werden, informieren wir betroffene Kunden unverzüglich und nennen einen voraussichtlichen Zeitrahmen.
Die konkreten Reaktions- und Lösungszeiten für Ihre Organisation sind in Ihrem Vertrag festgelegt, da sich die Service-Level zwischen den Verträgen unterscheiden. Fragen Sie Ihren Account Manager, und wir bestätigen Ihnen die für Sie geltenden Werte.
Wie Updates und Komponenten verwaltet werden
Wir übernehmen brandneue Versionen von Drittanbieter-Komponenten bewusst nicht sofort nach deren Erscheinen. Eine neu veröffentlichte Version muss erst reifen, bevor wir sie einsetzen – das ist unser wichtigster Schutz davor, dass eine kompromittierte oder hastig zurückgezogene Version in unsere Lieferkette gelangt. Kritische Sicherheitskorrekturen sind von dieser Wartezeit ausgenommen und werden außerplanmäßig veröffentlicht.
Darüber hinaus gilt:
Updates werden standardmäßig von einer Person genehmigt. Sie werden zur Prüfung gelistet, ausdrücklich genehmigt und erst danach als Änderung vorbereitet, die jede automatisierte Prüfung durchlaufen und vor dem Merge überprüft werden muss. Updates werden nicht stillschweigend angewendet.
Automatisches Mergen ist beschränkt auf kleine Updates in Bereichen, die das Verhalten der Plattform in der Produktion nicht beeinflussen können, wie zum Beispiel Test-Tooling und Entwicklungswerkzeuge.
Upgrades auf eine neue Hauptversion werden immer separat behandelt, damit sie eine bewusste, eigenständige Entscheidung bleiben und nicht nebenbei passieren.
Wie ein Update in die Produktion gelangt
Jede Sicherheitskorrektur nimmt genau denselben Weg wie jede andere Änderung – deshalb ist die Robustheit dieses Wegs selbst eine Sicherheitsmaßnahme.
Entwicklungs-, Test- und Produktionssysteme sind getrennt. Eine Änderung durchläuft eine feste Abfolge von Umgebungen und kann keine Stufe überspringen.
Automatisierte Prüfungen laufen, bevor irgendetwas gemergt wird: Code-Linting, Typprüfung, Unit-Tests, Autorisierungs-Testsuiten und automatisierte End-to-End-Tests gegen eine produktionsähnliche Umgebung.
Eine manuelle Prüfung durch Menschen ist verpflichtend für jede Änderung, die Authentifizierung, Autorisierung, die Trennung zwischen Kunden, das Datenmodell, Datenmigrationen, Infrastruktur oder den Umgang mit, die Aufbewahrung oder die Löschung personenbezogener Daten betrifft. Für unser Backend wird dies technisch von der Plattform erzwungen und nicht der Gewohnheit überlassen.
Infrastruktur wird als Code verwaltet. Bevor eine Infrastrukturänderung in der Produktion angewendet wird, wird die genaue Auswirkung berechnet und überprüft.
Deployments sind versioniert und rückgängig machbar. Eine fehlerhafte Änderung wird durch eine Korrektur behoben, die dieselbe automatisierte Pipeline durchläuft. Fehlgeschlagene Infrastruktur-Updates werden auf ihren vorherigen Zustand zurückgesetzt. Die Datenwiederherstellung ist ein separater Mechanismus: Die Point-in-Time-Recovery deckt die vorangegangenen 35 Tage ab.
Alles ist nachverfolgbar. Jede Änderung in der Produktion lässt sich auf ein Ticket, einen Commit, eine prüfende Person und einen Pipeline-Lauf zurückführen.
Ausfallzeiten und wie Sie von Änderungen erfahren
Reguläre Releases, einschließlich Sicherheitspatches, benötigen keine geplante Ausfallzeit, sodass es kein wiederkehrendes Wartungsfenster gibt, um das Sie sich kümmern müssten.
Änderungen mit höherem Risiko werden in Zeiten geringerer Nutzung eingeplant.
Änderungen, die beeinflussen, wie Sie oder Ihre Nutzer mit der Plattform arbeiten, werden vorab per E-Mail angekündigt, mit mehr Vorlaufzeit, je bedeutender die Änderung ist.
Kleinere Verbesserungen werden in einer wiederkehrenden Produkt-Update-E-Mail zusammengefasst und erscheinen in unserem öffentlichen Änderungsprotokoll.
Was wir auf Anfrage mitteilen können
Manche Details werden nicht veröffentlicht, entweder weil sie einem Angreifer helfen würden oder weil sie vertragsabhängig variieren. Auf Anfrage für Kunden und Interessenten verfügbar:
die für Ihren Vertrag geltenden Reaktions- und Lösungszeiten
unsere technischen und organisatorischen Maßnahmen im vollen Umfang
ISO/IEC-27001-Zertifikate unserer Cloud-Infrastrukturanbieter
Informationen zu unseren Sicherheitstests und Audit-Aktivitäten
Antworten zu einem konkreten Sicherheitsfragebogen
Kontaktieren Sie Ihren Account Manager oder [email protected].