Dieser Artikel ist auch verfügbar in:
Dieses Dokument enthält die Leitprinzipien, wie wir bei Easy LMS die Sicherheit und den Datenschutz unserer Kunden gewährleisten.

Sicherheit kommt in Schichten und wir haben fünf Leitprinzipien, die es uns ermöglichen, mehr und bessere Sicherheitsschichten innerhalb unserer Organisation und unseres Produkts zu haben. Jedes dieser fünf Prinzipien wird in diesem Dokument separat behandelt. Unsere fünf wichtigsten Sicherheitsprinzipien sind:

Sicherheitsprinzip priorisieren
Sicherheitsprinzip besprechen
Keine ungewartete Software Prinzip
Mindestens 4 + 2 Augen-Prinzip
Prinzip des geringstmöglichen privilegierten Zugriffs

Sicherheitsprinzip priorisieren

Was auch immer wir tun, wir kümmern uns zuerst um die Sicherheit.

Kein Stück Software ist ohne Fehler, und auch wenn wir unser Bestes tun, um die höchstmögliche Qualität unseres Produkts zu erreichen, sind wir keine Ausnahme. Das bedeutet, dass wir manchmal (potenzielle) Sicherheitsprobleme innerhalb unseres Systems finden. Wann immer das Problem innerhalb unserer Produktionsinstallation auftritt, wird der protokollierte Fehler mit höchster Priorität behandelt, um sicherzustellen, dass kein Rückstau an ungelösten Sicherheitsproblemen entsteht. Wenn mehrere Sicherheitsprobleme gefunden werden, erhält das Sicherheitsproblem mit dem höchsten Schweregrad die höchste Priorität.

In dem Szenario, in dem ein Sicherheitsproblem gefunden wird, bevor es in unserer Produktionsumgebung landet, gibt es einen Prozess, der sicherstellt, dass weitere Implementierungen des verwundbaren Codes verhindert werden, bis das Sicherheitsproblem behoben ist. Da es uns davon abhalten könnte, neue Funktionen zu implementieren, wird diesen Problemen auch Priorität bei der Behebung eingeräumt.

Wir sagen oft, dass es besser ist, auf Nummer sicher zu gehen. Wir sind der Meinung, dass es bei der Gewährleistung eines sicheren Produkts nicht darum geht, aufgetretene Probleme zu beheben, sondern darum, sicherzustellen, dass diese Probleme gar nicht erst auftreten. Daher sind wir der Meinung, dass Sicherheit bereits in den frühesten Entwicklungsphasen Priorität haben sollte, um Sicherheit direkt in unser Produkt zu integrieren, anstatt Dinge nachträglich zu patchen.

Diskutieren Sie das Prinzip Datenschutz/Sicherheit

Wenn wir nicht darüber nachdenken und diskutieren, wie wir uns verbessern können, werden wir es nie tun.

Obwohl Sicherheit im Herzen unserer Software diskutiert und implementiert wird, denken wir, dass es immer Raum für Verbesserungen gibt. Eine Diskussion hilft uns dabei, uns auf die Sicherheit zu fokussieren und zu schärfen, wie wir sie angehen. Außerdem ist eine Diskussion eine Möglichkeit, gute Ideen in großartige Ideen und gute Designs in großartige Designs zu verwandeln. Noch wichtiger: Da es immer Raum für Verbesserungen gibt, können wir durch eine Diskussion herausfinden, was wir verbessern müssen und nicht, was wir verbessern können. Sicherheit ist immer so stark wie der schwächste Teil und wenn es um die Verbesserung der Sicherheit geht, werden nur Verbesserungen an Ihrem schwächsten Teil Ihre Sicherheit tatsächlich verbessern. Daher glauben wir, dass die laufende Umstellung immer lebendig gehalten werden sollte, was unser schwächster Teil ist, und wie wir diesen verbessern können.

Kein ungewartetes/ungesichertes Software-Prinzip

_Unsere Software ist nicht sicher, wenn die Plattform, auf der sie läuft, es nicht ist.

Wir haben das Rad nicht erfunden, und schon gar nicht unser eigenes Betriebssystem geschrieben. Also ja, wir sind auf den Code Dritter angewiesen. Das bedeutet, dass wir auch dafür sorgen müssen, dass dieser Code sicher ist. Für das Betriebssystem (eine Linux-Variante), die Programmiersprachenumgebung (php / node), unseren http-Server (apache) und die Datenbanksysteme (MariaDB) stellen wir sicher, dass wir immer eine Version verwenden, die zumindest noch Sicherheitspatches erhält. Das bedeutet, dass unsere Software regelmäßig aktualisiert wird, um auf einer aktuellen Version zu laufen. Außerdem sorgt es dafür, dass wir durchgehend sicher bleiben, da wir für diese Komponenten voraussetzen, dass Sicherheitspatches automatisch installiert werden.

Für Bibliotheken, die wir in unserem Code verwenden, setzen wir, wo immer möglich, automatisierte Tools ein, um sicherzustellen, dass diese eine aktuelle, aber vor allem eine sichere Version haben. In der Praxis verwenden wir "npm audit", um sicherzustellen, dass unsere node.js-Pakete auf dem neuesten Stand sind. Und wir verwenden "roave/security-advisors", um sicherzustellen, dass unsere php-Bibliotheken sicher sind.

Mindestens 4 + 2 Augen Prinzip

Jede Änderung, auch wenn sie noch so trivial erscheint, muss auf ihre Qualität überprüft werden.

Um die Qualität, die wir anstreben, aufrechtzuerhalten, sind wir der Meinung, dass unsere Software unter keinen Umständen überstürzt werden sollte. Das bedeutet, dass für jede Änderung, die wir an unserem Produkt vornehmen, ein vollständiger Prüfzyklus erforderlich ist. Das bedeutet, dass der Code von mindestens zwei Entwicklern gesehen und genehmigt werden muss und dann von einem unserer Testteams getestet wird. Dieses Prinzip ist in unserem Arbeitsablauf verankert. Bevor Code in eine Staging- oder Produktionsumgebung deployed werden kann, muss er einen Pull-Request bestehen. Pull-Requests müssen von mindestens einem weiteren Entwickler überprüft werden. Das eigentliche Zurückmischen wird von jemandem aus unserem Testing-Team durchgeführt. Daher ist ein Entwickler prinzipiell nicht in der Lage, einen Pull-Request zurück zu mergen. Sicherheit ist (natürlich) Teil des Review-Zyklus. Der andere Entwickler wird den Code bewerten, um zu sehen, ob es sicherheitsrelevante Probleme gibt. Der Tester testet auch auf häufige Sicherheitsfehler, um unnötige Lecks in unserem System zu verhindern.

Ein besonderes Augenmerk sollte auf die Infrastruktur/Systemadministration gelegt werden. Da der Code-Entwicklungszyklus es erlaubt, die Sicherheit und Qualität zu beurteilen, bevor er in die Produktion geht, bemühen wir uns, unsere gesamte Infrastruktur als Code zu verwalten. Dies ermöglicht uns, die meisten Funktionen zu automatisieren, was bedeutet, dass wir weniger menschliche Fehler machen. Außerdem kann ein einzelner Systemadministrator ohne Benachrichtigung Änderungen vornehmen, die unsere Systemsicherheit beeinträchtigen könnten.

Least-Privileged-Access-Prinzip

Jede Person darf nur Zugriff auf das haben, was sie braucht, und jedes Programm sollte nur auf das zugreifen können, was es braucht.

Der zuverlässigste Weg, jede Form von Datenlecks zu verhindern, ist, dafür zu sorgen, dass es überhaupt keine Datenlecks gibt. Das nächstbeste ist, dafür zu sorgen, dass niemand auf die nicht benötigten Informationen zugreifen kann. Zum Beispiel braucht ein Entwickler keinen Zugriff auf unsere Produktionsdaten, um neue Funktionen zu entwickeln. Ebenso muss ein Übersetzer nur sehen, was in unserem System übersetzt werden kann, und benötigt keinen Zugriff auf unsere Codebasis oder Kundendaten. Wir wollen sicherstellen, dass jeder in unserer Organisation nur die Aufgaben sehen und ausführen kann, die für seine oder ihre Rolle erforderlich sind.

Das Prinzip des am wenigsten privilegierten Zugriffs gilt für Menschen, aber es wird auch auf Systeme und Dienste angewendet. Wenn ein Teil unseres Systems kompromittiert wird, sind wir bestrebt, die Auswirkungen zu minimieren. Deshalb versuchen wir, Dienste auszusondern, die nur auf die Informationen zugreifen können, die sie benötigen. Zum Beispiel müssen wir bei der Anzeige von Lerninhalten keine Zahlungsinformationen verarbeiten. Daher sollten die für Lerninhalte zuständigen Systeme keinen Zugriff auf unser Zahlungssystem haben. Darüber hinaus ist dies auch für andere Dienste möglich. Wir streben an, die Dienste möglichst vom öffentlichen Internet abzukoppeln. Dies geschieht vorzugsweise dadurch, dass die Dienste in ein privates Netz gestellt werden, von dem aus sie nur aus diesem Netz erreichbar sind. Ist der Dienst nicht für die öffentliche Nutzung vorgesehen, sondern soll über das Internet abgerufen werden, arbeiten wir mit einer Whitelist von IP-Adressen, um die Belastung zu minimieren.

Abschließende Hinweise

Wir sind der Meinung, dass ein fortlaufender Aufwand erforderlich ist, um ein hohes Maß an Sicherheit zu gewährleisten. Dieses Bemühen bedeutet, dass es nicht bei Prinzipien bleiben sollte, sondern dass diese Prinzipien in alle unsere Arbeitsabläufe eingebettet werden sollten. Auf diese Weise können wir sicherstellen, dass die Sicherheit innerhalb unserer Organisation Priorität hat.
War dieser Beitrag hilfreich?
Stornieren
Danke!