Zentrales Source Code Management

Jedes unserer digitalen Produkte enthält Softwarekomponenten. Das sind u.a. eine aktuelle WordPress-Version,
Plugins, Composer / NPM Pakete, Auftragsentwicklungen und Eigenentwicklungen. Der gesamte Source Code
aller Komponenten wird im Source Code Managementsystem GitHub im VNR AG Organisations Account verwaltet
und geprüft. Nur von dort kann Software in unsere Platform X Produktionsumgebung gelangen.

Nur die Administratoren des Teams Platform Engineering (Einheit Software Solutions) haben die Berechtigung neue
Entwickler (interne / wie externe) unserem Organisationsaccount hinzuzufügen und ihnen (in Abstimmung mit dem
internen technischen Owner) Rechte auf ausgewählte Code-Repositories zuzuordnen.
Es gibt keine Gruppen-Accounts oder und keine anonyme Accounts.

Jede Änderung am Source Code wird versioniert gespeichert inkl. der Erläuterung des Entwicklers, warum
die Änderung durchgeführt wurde. Jede Änderung ist dabei einem (für den Code-Bereich zugelassenen)
Softwareentwickler (Mitarbeiter oder Externer) zugeordnet, der eindeutig identifizierbar ist.

Kontinuierliche Paketüberwachung

Innerhalb unseres GitHub-Source Code Management Systems setzen wir den Standard-Dienst Dependabot ein.
Der Dienst überwacht kontinuierlich die von uns bzw. den zugelassenen Softwareentwicklern genutzten Software-
pakete (hierbei kommen die Paketmanagement-Systeme NPM und Composer zum Einsatz).

Soweit sich in von uns eingesetzten Paketen Sicherheitslücken finden, erstellt Dependabot automatisiert Warnungen
(Alerts), die unsere internen Entwicklerteams per E-Mail und/oder Slack mitgeteilt bekommen. Wir nutzen diese
Warnungen, um so schnell wie möglich die Pakete zu patchen / zu aktualisieren, um die gefundenen Lücken so
schnell wie möglich (i.d.R. binnen weniger Stunden, soweit ein Patch nicht zu einer Inkompatibilität mit der restlichen
Code-Base führt) zu beheben.

Damit verlassen wir uns nicht auf manuelle zyklische Updates, sondern patchen Sicherheitslücken direkt, wenn sie
entstehen. Um diese Prozesse zu beschleunigen, erfolgt das Deployment neuer Versionen über die AWS Code Pipeline.

Keine Secrets in Source Code Management

Externe Partner wundern sich oft, dass sie bei uns keine Zugangsdaten zu zentralen Systemen, wie den Datenbankservern
erhalten. Das liegt zum einen daran, dass sie diese Daten nicht haben müssen und zum anderen daran, dass wir solche
Daten nicht in den Quelltexten und nicht im Source Coude Management System haben wollen. Darüber hinaus wollen wir
keine neue Versionen der Software für Test- oder Produktionsumgebungen bauen und trotzdem unterschiedliche Zugangs-
daten für diese Umgebungen pflegen können.

Über unsere Betriebsumgebung in der AWS Cloud und die genutzt AWS Code Pipeline können wir dynamisch zentral
verwaltet und abgesicherte Credentials (z. B. Datenbankzugangsdaten) im AWS Parameter Store (Secure Strings) verwalten.
Nur die Administratoren des Teams Platform Engineering (Einheit Software Solutions) die Credentials unserer Infrastruktur.

Infrastructure As Code, CVE-Scan

Die Laufzeit-Infrastructure wird (außerhalb von frühen Entwicklungstests) via Infrastructure As Code (IAC) in Cloudformation-
Code gebaut. Der Cloudformation Code ist, wie jeder Quelltext, im Source Code Managementsystem gebaut. Durch Einsatz
von Templates etc. stellen wir in dieser Form sicher, dass unsere Infrastruktur für Datenspeicher (Datenbanken, Objektspeicher)
und Computing-Einheiten (Elastic Computing, Auto-Scaling-Groups, Load-Balancer, Kubernetes-Cluster, etc.) alle Einheiten
in Deutschland (AWS Europe-Central-01) erstellt und betrieben werden (auch bei einem Neubau aus Code).

U.a. für manuell erstellte Entwicklungsumgebungen prüfen wir mittels Skript monatlich, dass alle Komponenten in Europe-Central-01
(=Deutschland / Frankfurt) laufen, damit später davon abgeleitete IAC-Definitionen für den produktiven Einsatz garantiert in Deutschland
erstellt und betrieben werden. Soweit es Ausnahmen gibt, in denen ein Betrieb außerhalb von Deutschland / Europa sinnvoll / nötig ist,
dokumentieren wir an der Ressource die Notwendigkeit und die Unbedenklichkeit im Sinne der EU DSVGO (z. B. keine Verarbeitung
personenbezogener Daten).

Innerhalb der AWS Code Pipelines prüfen wir größere Softwarekomponenten, wie WordPress, gegen öffentliche Common Vulnerability
& Exploit Datenbanken, um ggf. IT-Security-Risiken in diesen Versionen zu erkennen und vor der Produktivname zu beheben.

Dreistufiges Deployment

Obwohl es bereits die Infrastruktur zur Durchführung automatisierter Tests in der Pipeline gibt, erreichen wir hier noch nicht die
gewünschte automatische Softwaretestung mit der nötigen Verlässlichkeit.

Daher werden Softwareänderungen vor der Übernahme in die Produktion und nach der teilweise automatischen Durchführung
von z. B. Unit-Tests zunächst in eine zur Produktionsumgebung strukturgleiche PRE-PRODUCTION-Umgebung deployed, so dass
jede neue Version der Software durch die Fachkollegen getestet und abgenommen werden kann.

Dieser Prozess erhöht die Softwarequalität und reduziert das Risiko von Fehlern und Ausfällen.

Amazon Webservice – AWS Cloud (Europe-Central-01 (Frankfurt))

Die Betriebsumgebungen der digitalen Produkte der VNR AG laufen jeweils in drei AWS Accounts (Developer, Pre-Production und Production)
parallel, was sauberes Testing und Abnahmen ermöglicht. Die Umgebungen werden über Infrastructure As Code (IAC, Cloudformation-Skripte)
automatisiert erstellt (auch bei einer Wiederherstellung nach einem Desaster-Recovery). Sämtliche Ressourcen der Datenverarbeitung und
Speicherung (Kubernetes-Cluster, Elastic Computing Nodes, Autoscaling Groups, Loadbalancer, Simple Storage Service (S3) und die Datenbanken
sind per IAC auf den Standort Europe-Central-01 (Frankfurt) konfiguriert.

Als Mittelständler würden uns aktuell noch die Kapazitäten fehlen, um alle nötigen Systeme und Systemkomponenten auf dem hohen technischen
Sicherheitsniveau zu halten, den wir uns als Maßstab setzen. Um diesen dennoch für unsere Verlagskollegen, Kunden und Partner bieten zu
können, setzen wir zum einen auf Managed Serverless Services von AWS (z. B. Aurora Serverless DB, S3, Lambda), die als Teil der Infrastruktur
in die technische Sicherheitshoheit von Amazon Webservices fallen. Die zentrale Computing-Laufzeitumgebung, der Elastic Kubernetes Cluster
(EKS) wird im Auftrag der VNR AG durch unseren strategischen IT-Partner, die Arvato Systems GmbH, gewartet, supported und betrieben.
Ebenso wurden gemeinsam mit AWS Certified Solution Architects der Arvato Systems GmbH die System Architekturen in AWS konzipiert,

designed und gemeinsam mit der IT der VNR AG implementiert. In Folge nutzen wir auch die Monitoring-Lösung der Arvato-Services um auf-
fälliges oder fehlerhaftes Verhalten von Systemen / Systemkomponenten frühzeitig zu erkennen.

Compliance & Security in AWS

Grundsätzlich gilt das Modell der Shared Responsibility für die Absicherung
von Applikationen, die auf der Amazon Webservices Plattform betrieben werden.

Aufgrund dessen haben wir uns dafür entschieden im Betrieb weitgehend auf
„Managed“ und „Serverless“ Infrastruktur-Services von AWS zu setzen, wo neben
der Infrastruktur an sich, auch die Wartung der Infrastruktur in die Verantwortung
von AWS fällt.

Seinen Verantwortungsbereich lässt AWS für den deutschen Markt beispielsweise
nach dem Standard C5 (Cloud Computing Compliance Controls Catalog) des Bundes-

amtes für Sicherheit in der Informationstechnik zertifizieren.

Siehe:

• https://aws.amazon.com/de/compliance/bsi-c5/
• https://aws.amazon.com/de/compliance/programs/

Hochverfügbarkeit und Sicherheit durch Segmentierung

• Digitale Produkte werden separiert in 2..n Containern
  auf einem geo-redundanten Kubernetes-Cluster betrieben,
  das über die drei deutschen Standorte der AWS Cloud
  (EU-Central-1a .. c) auf- gespannt ist. In Verbindung mit den
  ebenfalls redundant ausgelegten serverless Services von AWS
  entsteht so ein hoch verfügbares Applikationssystem.
• Die Container-Applikationen sind dabei voneinander
  getrennt und die Applikationsschicht ist wiederum von der
  Datenschicht getrennt, so dass in den Applikationscontainern
  keinerlei Nutzerdaten gespeichert werden.
• D.h. selbst ein erfolgreicher Angriff eines Hackers auf einen
  Webserver in einem der Applikations-Containern bringt den
  Angreifer noch nicht auf ein System, auf dem Nutzerdaten zu
  finden sind.

Absicherung durch Web Application Firewall, Shield

Die Auslieferung der Applikationsdaten (dynamisch und statisch, wie z. B. Bilder) erfolgt über den AWS Service Cloudfront.

Cloudfront ist hierbei auch als Schutzschild für die Applikation eingerichtet, in dem dort eine Web Application Firewall (WAF)
eingerichtet ist, die typische Angriffe auf Webserver bzw. Web-Applikationen erkennt und gar nicht erst bis zum Container, in
dem die Applikation läuft kommen lässt. So verfügt das Betriebskonstrukt über eine weitere Sicherheitsebene, die erfolgreiche
Angriffe auf die Web-Server, bzw. Web-Applikationen auf der Containerebene noch unwahrscheinlicher machen.

Ergänzend ist die Shield Standard Sicherheit durch AWS Cloudfront gegeben, Distributed Denial of Service (DDoS)-Schutzservice,

der Anwendungen schützt, die auf AWS ausgeführt werden. AWS Shield bietet immer aktive Erkennung und automatische

Inline-Mitigationen, welche die Ausfallzeiten und Latenzzeiten von Anwendungen minimieren.

Verschlüsselung aller Daten „at rest“ und „in transit“

Trotz unseres hohen Vertrauens in die Sicherheit der Amazon Webservice Infrastruktur, folgen wir natürlich auch deren Sicherheits-
empfehlungen, die eine konsequente und permanente Verschlüsselung der Daten „at rest“ empfiehlt. D.h. insbesondere Daten und
Dateien, die in den Services S3 und den Datenbanken der Applikation gespeichert werden, werden stets verschlüsselt abgelegt, so
das ein direkter Angriff auf die Infrastruktur von AWS im Zweifelsfall nur auf die verschlüsselten Daten treffen würde.

Daneben ist es der von AWS vorgegebene Standard auch sämtliche Datentransfers mittels SSL/TLS-Zertifikat für eine HTTPS-basierte
Kommunikation zu verschlüsseln. Auch diesen Sicherheitsstandard setzen wir in all unseren digitalen Produkten durchgängig um.

Das Management der Zertifikate selber haben wir über den AWS Certificate Manager (ACM) automatisiert, um Fehler oder temporäre
Sicherheitseinschränkungen durch „vergessene“ Zertifikatserneuerungen zu verhindern.