Die Sicherheit der cloud-Lösung

In diesem Artikel möchte ich die Sicherheitsarchitektur der cloud-Lösung beschreiben.
Ich werde dabei auch etwas in die technischen Details gehen, soweit notwendig und hilfreich.

Auktuell benötigt das System mindestens zwei Server:

• Ein virtualisierter Server, der die Installation von open3A und den anderen Anwendungen hostet,
• sowie einen Backup-Server.

Zu letzterem komme ich in einem weiteren Artikel, zunächst möchte ich den Anwendungsserver beschreiben und warum er sicher ist.

Die einfachste Methode um den Zugriff auf einen Server zu limitieren, ist, die Anzahl der offenen Ports zu reduzieren. Daher hat der Anwendungsserver nur zwei offene Ports:

• Port 443 für die HTTPS-Verbindungen
  Auf Port 443 bauen die Browser die Verbindung zum Apache Webserver auf, um die Anwendungen aufzurufen.
• Port 22 für das Management via SSH
  Der SSH-Server wurde so konfiguriert, dass ein Login als Root-Benutzer und mit Passwort nicht möglich ist. Zulässig ist also nur ein neu angelegter Benutzer, der sich mit einem von zwei unterschiedlichen Schlüsseln ausweisen kann:
  • Ein Schlüssel zur Verwaltung
  • Ein Schlüssel für das Deployment-System, um neue Versionen hochzuladen

Der Zugriff auf den Server ist also immer verschlüsselt und der Management-Zugang nur durch nicht erratbare Schlüssel erreichbar.

Die Struktur der Installation

Es gibt für alle Benutzer nur eine Anwendungsinstallation, so dass sich ein Update immer auf alle auswirkt. Dabei bleibt die alte Version stets erhalten, so dass im Fehlerfall schnell auf diese zurück gewechselt werden kann.

Die von den Benutzern hochgeladenen Dateien liegen dabei außerhalb des Versionsverzeichnisses.

Um die unterschiedlichen Benutzer untereinander zu trennen und einen gegenseitigen Zugriff auf die Daten zu verhindern, erhält jeder Benutzer eine eigene Datenbank im MySQL-Server mit eigenem MySQL-Benutzer, der nur auf diese Datenbank zugreifen kann.

Diese Zugangsdaten werden in einer Datenbank gespeichert, an Hand der ID in der URL ausgelesen und der Anwendung für die Verbindung übergeben. Wenn die ID aus der URL nicht mehr mit dem Datenbankbenutzer übereinstimmt, löscht die Anwendung die Zugangsdaten und sie werden erneut passend ausgelesen. Das verhindert ein gegenseitiges Auslesen der Daten nach bereits gestarteter Anwendung.

Warum ein virtualisierter Server und kein root-Server als Anwendungsserver?

Die virtualisierten Server haben den Vorteil, dass sie auf einer viel größeren Maschine laufen, als es ein dedizierter root-Server wäre. Die Verantwortung für die korrekte Funktionsweise der Hostmaschine wird damit an den Provider übertragen, der sich um Festplattenausfälle und andere Probleme kümmern muss.

Außerdem lassen sich virtuelle Maschinen leichter auf neue Instanzen kopieren und umziehen, falls zusätzliche Kapazitäten benötigt werden.