Sicherheit
Hosting in Deutschland Mandantengetrennt Audit-Logs

Security-Awareness-Sicherheit, die in der Architektur verankert ist.

Eine Awareness-Plattform verarbeitet sensible Lern-, Sicherheits- und Organisationsdaten. Aronion setzt deshalb auf klare Mandantentrennung, sichere Authentifizierung, gehärtete Browser-Policies, nachvollziehbare Admin-Aktionen und mehrschichtige Kontrollen — überprüfbar, nicht nur behauptet.

Beratung anfragen Welche Daten wir verarbeiten

Grundprinzipien

Sicherheit ist kein Add-on, sondern Bauweise.

01

Defense in Depth

Keine einzelne Kontrolle entscheidet über die Sicherheit des Systems. Sichere Sessions, CSRF-Schutz, Rate-Limiting, Rollenprüfung, parametrisierte Datenbankabfragen und Audit-Protokolle greifen als unabhängige Schichten ineinander. Fällt eine Schicht, trägt die nächste.

02

Least Privilege

Jede Rolle erhält nur die Rechte, die sie für ihre Aufgabe braucht. Manager sehen ausschließlich ihren Bereich, Auswertungen sind rollenbasiert eingeschränkt und sensible Admin-Funktionen sind getrennt vergeben und werden protokolliert.

03

Sichere Standardwerte

Die Plattform startet im sicheren Zustand — restriktive Browser-Policies, strikte Session-Einstellungen und Datenminimierung sind Standard, nicht Option. Was zusätzliche Rechte oder Datentiefe braucht, muss bewusst freigeschaltet werden, nicht umgekehrt.

Sicherheitsarchitektur

Sechs Schichten zwischen Angreifer und Daten.

Vom Browser bis zur Datenbank ist jede Ebene eigenständig abgesichert. Die folgende Übersicht zeigt die wichtigsten Kontrollen — so, wie sie tatsächlich implementiert sind, nicht als Marketingversprechen.

Orientiert an OWASP ASVS und den Prinzipien von ISO 27001 — als Architektur-Leitlinie und Grundlage für spätere Zertifizierungsfähigkeit.

1 Browser

Strenge Content-Security-Policy mit Nonce, X-Frame-Options: DENY, Referrer- und Permissions-Policy, HSTS.

2 Zugang

Argon2id-Passwort-Hashing, Leak-Prüfung per k-Anonymität (das Passwort verlässt nie das System), optionale TOTP-MFA, SSO & SCIM im Enterprise-Plan.

3 Session

HttpOnly-, Secure- und SameSite=Strict-Cookies, strikter Session-Modus ohne IDs in URLs, automatischer Timeout bei Inaktivität.

4 Anwendung

Rotierende CSRF-Tokens, Rate-Limits pro IP, Konto-Sperren bei Brute-Force, Honeypots in öffentlichen Formularen.

5 Daten

Mandantenbindung in jeder Abfrage, ausschließlich parametrisierte SQL-Statements, Geheimnisse (z. B. SSO-Schlüssel) mit AES-256-GCM verschlüsselt.

6 Nachvollziehbarkeit

Audit-Log mit HMAC-Hash-Kette gegen Manipulation, automatische Redaktion sensibler Felder, Akteur und Vorher-/Nachher-Stand je Eintrag.

Bewusste Grenzen

Was diese Plattform absichtlich nicht tut.

Ein Phishing-Simulationsmodul ist nur dann vertretbar, wenn es technisch nicht als echtes Angriffswerkzeug taugt und niemanden bloßstellt. Diese Grenzen sind in der Architektur fest verankert — sie lassen sich nicht per Konfiguration umgehen.

  • Keine echten Zugangsdaten Landingpages speichern nur, dass eine Eingabe erfolgte — nie die Werte. Es existieren keine Datenbankspalten für Credentials.
  • Keine Roh-IP in Ereignissen IP-Adresse und Browser-Kennung werden vor der Speicherung mit SHA-256 gehasht. Kein Geräte-Fingerprinting, keine Standortermittlung.
  • Kein Schadcode, keine gefährlichen Anhänge Simulationen arbeiten mit harmlosen Trainingsinhalten. Echte Malware oder riskante Dateitypen sind ausgeschlossen.
  • Keine freie Phishing-Infrastruktur Kampagnen, Absender und Landingpages sind strikt an den eigenen Mandanten gebunden — die Plattform lässt sich nicht gegen Dritte richten.
  • Keine Bewertung Einzelner Der Betriebsrats-Modus erzwingt aggregierte bzw. anonymisierte Auswertung mit Mindestgruppengröße. Ziel ist Lernen im Kollektiv.

Nachvollziehbarkeit

Jede relevante Aktion ist nachvollziehbar.

Administrative und sicherheitsrelevante Vorgänge werden in einem Audit-Log mit Akteur, Aktion, Vorher-/Nachher-Stand sowie Zeit, IP und Quelle festgehalten. Sensible Werte werden dabei automatisch entfernt.

Die Einträge sind über eine HMAC-Hash-Kette manipulationssicher verkettet — nachträgliche Änderungen fallen auf. Das schafft die Grundlage für Audits und interne Reviews: Wer hat wann was geändert, und stimmt die Kette noch?

Beispiel: Audit-Eintrag

Akteur
Admin (Name & ID)
Aktion
Rolle geändert
Vorher / Nachher
protokolliert
Zeit & Quelle
Zeitstempel, IP
Integrität
HMAC-Kette

FAQ

Fragen, die Security-Teams uns stellen.

Die häufigsten Fragen aus Sicherheitsprüfungen und Vendor-Reviews — kurz und konkret beantwortet.

Ausschließlich in Deutschland, über die Aronion-Infrastruktur bei einem deutschen Anbieter (IONOS). Es findet kein Datentransfer in Drittländer statt, und ein Auftragsverarbeitungsvertrag (AVV) ist standardmäßig enthalten.

Nein, zu keinem Zeitpunkt. Simulations-Landingpages speichern ausschließlich das Ereignis, dass eine Eingabe stattgefunden hat — niemals die eingegebenen Werte. In der Datenbank existieren keine Spalten, in denen Zugangsdaten abgelegt werden könnten.

Passwörter werden mit Argon2id gehasht und bei der Vergabe per k-Anonymität gegen bekannte Datenlecks geprüft, ohne dass das Passwort das System verlässt. Zusätzlich stehen optionale TOTP-Mehr-Faktor-Authentifizierung mit einmaligen Recovery-Codes sowie im Enterprise-Plan Single Sign-On über Microsoft Entra ID (OIDC) und SCIM-Provisioning zur Verfügung.

Sicherheitsrelevante und administrative Vorgänge landen in einem Audit-Log mit Akteur, Aktion, Vorher-/Nachher-Stand, Zeitstempel und Quelle. Die Einträge sind über eine HMAC-Hash-Kette verkettet, sodass nachträgliche Manipulation auffällt. Sensible Werte wie Passwörter werden vor dem Schreiben automatisch entfernt.

Jeder Kunde erhält einen eigenen Mandanten mit eigener Subdomain (z. B. firma.aronion.de). Jede Datenbankabfrage ist an den Mandantenkontext gebunden, Rollen und Berechtigungen gelten pro Mandant, und Auswertungen oder Exporte umfassen ausschließlich die Daten des eigenen Tenants.

Ja. Auswertungen der Phishing-Simulation lassen sich aggregiert bzw. anonymisiert betreiben. Eine konfigurierbare Mindestgruppengröße verhindert Rückschlüsse auf einzelne Personen. So bleibt das Programm mitbestimmungsfreundlich und datenschutzkonform.

Verantwortungsvolle Offenlegung

Eine Schwachstelle entdeckt?

Melden Sie uns mögliche Sicherheitslücken vertraulich. Wir prüfen jeden Hinweis sorgfältig und gehen gegen Sicherheitsforschende, die in gutem Glauben und ohne Schaden für Nutzer:innen handeln, nicht rechtlich vor. Bitte testen Sie niemals gegen echte Mandantendaten und legen Sie keine fremden Daten offen.

Sicherheitshinweis senden

Nächster Schritt

Sprechen wir über Ihre Anforderungen.

Security-Review, technische Schutzmaßnahmen oder eine Demo für Ihr IT- und Security-Team — wir zeigen Ihnen, wie Aronion zu Ihren Sicherheitsanforderungen passt.

Beratung & Demo anfragen Datenschutz & Datenverarbeitung