Kontainer & GDPR

DSGVO-konforme Bilddatenbank, der Datenschutz am Herzen liegt.

Kontainer operiert in 2 separaten Rechenzentren in der EU – nachhaltig 100% hydroelektrisch angetrieben. Kontainer ist so eingerichtet, dass es via Mikroservices in einem skalierbaren Cluster läuft. Alle Dateien werden in gespiegelten Speichern in zwei Rechenzentren mit redundantem Setup und Failover Ausfallsicherung, sowie in einem Backup an einer dritten Lokation abgelegt. Alle Services werden in Netzwerksegmente unterteilt und es gibt eine avancierte Intrusionsprävention auf dem gesamten Netzwerktraffic.

Vor allen Servern liegt ein effektiver DDoS Filter auf dem gesamten Traffic. Im Netzwerkzugang liegt ein Firewall Cluster mit IDP Scanning des gesamten Traffics. Firewall Sicherheitsregeln werden laufend analysiert. Alle Logs und verdächtiger Traffic werden analysiert und wir agieren, falls notwendig.

Alle Netzwerkequipments unterlaufen geplante Firmwareupdates.  Alle Anwendungen, die Kontainer verwendet, werden in geplanten Prozessen aktualisiert. Verdächtige Operationen auf Kontainer werden analysiert und wir agieren, falls notwendig.

Kontainer wird jährlich durch Price Waterhouse Cooper’s geprüft und gemäß ISEA 3402 zertifiziert, welches auf Sicherheitsstandards der ISO 27001 Norm zur DSGVO-Konformität der Software und Netzwerks basiert. Der Bericht kann allen Kunden ausgeliefert werden.

Schreiben Sie uns, wenn Sie mehr über unsere ISAE 3402 Zertifizierung erfahren möchten.

 

Backup & Wiederherstellung

• Von allen Daten wird täglich eine Sicherheitskopie erstellt, die 90 Tage lang gespeichert wird.
• Alle Dateien werden laufend zwischen den 2 Rechenzentren gespiegelt.
• Es besteht die Möglichkeit, das Backup zu erweitern.

Skalierbarkeit & Kompatibilität

Das System ist auf Mikroservices gebaut. Alle Mikroservices laufen auf einem Service Cluster. Das bedeutet, dass individuelle Bereiche sich bei Bedarf sehr leicht hoch oder runter skalieren lassen.

Der Speicher bedient sich Objekttechnologie und kann ebenfalls auf große Datenmengen erweitert werden.

Der standardmäßige Zugriff auf Kontainer erfolgt via Webbrowser. Aktuell unterstützt Kontainer Chrome, Safari, Edge und Firefox. Das System wird laufend aktualisiert, um die neuesten Browserversionen zu unterstützen. Support von älteren Browsern wird ggf. entfernt.

Sicherer Betrieb & Instandhaltung

• Telefon, Chat und E-Mail-Support für Administratoren: Ja
• 24 Stunden Überwachung und Plattformwartung: Inklusive
• Hosting, laufende Updates und neue Features: In Paketen enthalten
• Möglichkeit, stets das gewählte Paket anzupassen: Ja
• Uptime: 99.9%
• Komplette Restful API: Ja
• Private Cloud in 2 Rechenzentren mit redundanter Umgebung und Failover-Sicherung: Ja

Sicherheit

• Globaler DDoS-Filter
• Firewall mit erweiterter Filterung und Paketprüfung
• Frontend-Sicherheits-Proxy-Schicht für den gesamten eingehenden Datenverkehr

Alle Microservices und Speicher sind in VLANs getrennt. Der gesamte Zugriff auf die Plattform von einer externen Firewall erfolgt über https basierend auf TLS 1.2. Der Datenverkehr zwischen der Firewall und dem Haupt-Proxyserver wird per https basierend auf TLS 1.2 verschlüsselt.

Reaktionszeit

Alle standardmäßigen Aufrufe in Kontainer dauern weniger als 1 Sekunde. Erweiterte Suchen können bis zu 3 Sekunden dauern.

Es gelten folgende Reaktionszeiten:

• Anmeldeseite: < 1 Sek
• Anmeldung: < 2 Sek
• Ordnerliste: < 2 Sek
• Attributänderung: < 1 Sek
• Suche: < 3 Sek
• Erweiterte Suche: < 3 Sek
• Metadaten bearbeiten: < 2 Sek
• Metadaten anzeigen: < 2 Sek

Die Geschwindigkeit der Datenübertragung hängt von der Geschwindigkeit der Download-Verbindung ab. Bei 1 Gbit beträgt die Download-Geschwindigkeit etwa 100 MB/s.

Https wird für alle Dateiübertragungen verwendet. Dateiübertragungen können entweder über die Browseroberfläche oder per API-Aufruf erfolgen.

Es ist auch möglich, Dateien über WebDav oder über die Plugins für Microsoft Office und Adobe-Programme herunterzuladen.

Verfahren zu Kontainer Deployments

Wenn Kontainer neue Versionen entwickelt und implementiert, erfolgt dies in den folgenden Schritten:

1. Tickets werden in Jira erstellt und vor dem Start genau definiert. Alle Aufgaben sind so aufgeteilt, dass sie maximal 14 Tage dauern und in Kontainers 14-tägigen Entwicklungssprints bearbeitet werden.
2. Projektmanager spezifizieren, priorisieren und planen alle Sprints.
3. Nach der Bearbeitung der Tickets wird der gesamte Code zur internen Überprüfung gesendet, bevor Bugfixes oder Funktionsanpassungen auf dem internen Entwicklungs-/Testserver von Kontainer veröffentlicht werden.
4. Bei allen Codeänderungen werden automatisch Unit-Tests durchgeführt. Neuer Code kann nicht auf den Testservern veröffentlicht werden, wenn der Code einen Unit-Test nicht besteht.
5. Wenn die Tickets fertig sind, werden sie von den Entwicklern auf dem internen Entwicklungs-/Testserver zusammengeführt und getestet.
6. Nach dem internen Test werden die Bugfixes/Funktionsanpassungen auf dem internen Staging-Server von Kontainer für abschließende manuelle Tests durch das Testteam veröffentlicht.
7. Derselbe Code kann zur Freigabe gleichzeitig auf einem kundenspezifischen Staging-Server bereitgestellt werden.
8. Wenn die Bereitstellung genehmigt ist, werden die Korrekturen live bereitgestellt (ohne Ausfallzeit).
9. Das Live-Server-Setup wird nach der endgültigen Veröffentlichung manuell mit allen Korrekturen getestet.
10. Wenn wider Erwarten etwas schief gelaufen ist, können Releases zurückgesetzt werden (ohne Ausfallzeiten).
11. Die gesamte Dokumentation zu Bugfixes und zusätzlichen Funktionen wird in einer internen Datei „change.log“ beschrieben.

Kundenspezifische Testserver und -verfahren

Wenn ein Kunde einen bestimmten Test-Staging-Server wünscht, um größere Updates oder Updates im Zusammenhang mit kundenspezifischen Integrationen oder primären Arbeitsabläufen vor diesen Live-Releases zu testen, kann dieser hinzugefügt werden.

Im Falle einer kundenspezifischen Testumgebung wird der Kunde mindestens 2 Werktage vor der Veröffentlichung von Releases zum Testen auf dem kundeneigenen Testserver benachrichtigt.

Der Kunde hat dann 5 Tage Zeit, Fixes/Add-ons auf dem Staging-Server zu testen. Wenn Fixes/Add-ons genehmigt werden, werden sie live bereitgestellt. Wenn sie nicht genehmigt werden, gibt es eine neue Testrunde auf dem kundenspezifischen Testserver, sobald die Korrekturen vorgenommen wurden. Für alle Testrunden gelten die gleichen Benachrichtigungsintervalle. Bei der Live-Bereitstellung neuer Versionen kommt es zu keinen Ausfallzeiten.

Vor der Inbetriebnahme wird in Zusammenarbeit mit dem Kunden festgelegt, welche Art von Aufgaben als kritische Integrationen und Updates definiert werden können.

Für kundenspezifische Testserver fällt ein Aufpreis an.

Kommunikation mit dem Kunden über Releases

• Veröffentlichungen, die sich auf die Arbeitsabläufe oder Integrationen des Kunden auswirken, werden mindestens 5 Tage vor der Veröffentlichung bekanntgegeben.
• Minimale Optimierungen, kleinere neue Funktionen und Fehlerbehebungen, die sich nicht auf die Arbeitsabläufe des Kunden auswirken, werden ohne Benachrichtigung des Kunden veröffentlicht.
• Administratoren beim Kunden erhalten E-Mail-Benachrichtigungen über bevorstehende neue Funktionen in der Roadmap.