PRINZIP — SECURITY FIRST
Security First
Sicherheit und Datenschutz sind Standard von Beginn an, nicht ein Punkt, den man am Ende abhakt. Und weil Selbsteinschätzung wenig wert ist, lassen wir unsere Ergebnisse gezielt angreifen.
Warum wir das so machen
Die Begründung.
Der erste Teil ist Datensparsamkeit als Vorgabewert. In der RetterApp ist das kein Kapitel in der Datenschutzerklärung, sondern Code: Adressen werden je nach Abholart gestaffelt freigegeben, Telefonnummern liegen nur als Prüfwert vor, und ein Kartenpunkt wird bis zu hundert Meter verschoben — deterministisch mit einem Verfahren, das sich nicht durch Mitteln mehrerer Angebote herausrechnen lässt.
Der zweite Teil ist, dass Regeln maschinell erzwungen werden müssen, wenn sie halten sollen. Wächter-Tests laufen über die real registrierten Schnittstellen und färben rot, sobald jemand eine Regel bricht: eine schreibende Route ohne Sperre für gesperrte Konten, eine Verwaltungsroute ohne zweiten Faktor, ein Antwortschema mit einem Klardatenfeld. Und jeder dieser Wächter wurde testweise gebrochen, um zu beweisen, dass er wirklich anschlägt — ein Test, der immer grün ist, prüft nichts.
Der dritte Teil ist die Haltung zur eigenen Arbeit. Bei unseren eigenen Prüfläufen kamen echte Funde heraus, etwa ein Datenschutz-Leck in einer Standard-Fehlerbehandlung, das personenbezogene Angaben ins Protokoll geschrieben hätte. Solche Funde nennen wir, weil eine Sicherheitsaussage ohne Fundliste nur eine Zusage ist.
Und der vierte Teil ist Betriebshärtung: Container laufen mit schreibgeschütztem Dateisystem und ohne jede unnötige Berechtigung, und der Reverse-Proxy bekommt keinen rohen Zugriff auf die Container-Steuerung, sondern spricht über einen schreibgeschützten Vermittler mit stark eingeschränktem Befehlssatz.
Was du davon hast
Die Software nimmt dir die Arbeit ab, die sich technisch erledigen lässt: Datensparsamkeit, Löschfristen und nachvollziehbare Zugriffe sind eingebaut statt nachgerüstet. Das senkt dein Risiko; die rechtliche Bewertung bleibt bei dir und deiner Beratung.
Konkret
Die Entscheidungen dahinter.
Datensparsamkeit als Vorgabewert
Nur erheben, was gebraucht wird: gestaffelte Sichtbarkeit, Prüfwerte statt Klardaten, Protokolle ohne personenbezogene Daten, und EXIF- und GPS-Daten werden beim Hochladen zwingend entfernt.
Regeln, die eine Maschine erzwingt
Automatische Prüfungen laufen über die real registrierten Routen und schlagen an, sobald eine Regel gebrochen wird.
Container ohne unnötige Rechte
Schreibgeschütztes Dateisystem, entzogene Berechtigungen, Speicher- und Prozessgrenzen, keine Root-Rechte zur Laufzeit — Ausnahmen im Code begründet.
Protokoll mit Manipulationsnachweis
Technisches und fachliches Protokoll getrennt, darunter eine Hash-Kette mit Änderungssperre auf Datenbankebene, nächtlichem Tagesnachweis und signierten Manifesten. Die Anwendungsrolle darf nur einfügen und lesen — nicht ändern, nicht löschen.
Adversariale Prüfung vor dem Bau
Sicherheitsreview mit abgearbeiteter Fixliste, bevor gebaut wird — statt Reparatur, nachdem etwas passiert ist.
Zugangssperren werden respektiert
Wo ein Anbieter eine Zugangshürde setzt, umgehen wir sie nicht, sondern verzichten auf die Quelle. Das haben wir in einem eigenen Werkzeug so dokumentiert (Stand 08/2026).
Lieferkette absichern, nicht nur Code
Für unsere eigene Plattform ist festgelegt: signierte Container-Abbilder, Stückliste je Build, automatische Prüfung auf Schwachstellen, Geheimnisse und riskante Muster — und Produktions-Geheimnisse liegen weder im Repository noch im Abbild noch in gewöhnlichen Konfigurationsdateien.
Belege
Woran du uns messen kannst.
- Adversariales Produktionsreife-Audit der RetterApp (02.07.2026): keine kritischen Funde — ein Prüfstand zu einem Zeitpunkt, kein Beweis für Fehlerfreiheit; spätere Prüfläufe brachten weitere Befunde, die bearbeitet wurden.
- Der Mailserver wurde vor dem Bau adversarial reviewt; jeder kritische und hohe Befund ist nachweislich in den Dateien adressiert.
- RetterApp, Stand 16.08.2026: über zwei Dutzend maschinell erzwungene Sicherheitsregeln, jede durch absichtlichen Regelbruch auf Wirksamkeit geprüft.
- RetterApp, Stand 16.08.2026: Zwei-Faktor-Pflicht für alle Verwaltungszugänge — die Ausnahmeliste ist leer; vor wirkungsstarken Aktionen zusätzlich eine frische Bestätigung.
- Härtungsindex des Produktivservers: 82 von 100 Punkten im automatisierten Lynis-Scan (Stand 24.06.2026); nur die notwendigen Ports erreichbar, TLS 1.3, kein offenes Mail-Relay.
- Der eigene Mailserver erreicht 10 von 10 Punkten im Zustellbarkeits- und Konfigurationstest von mail-tester.com (Stand 06/2026).
- Geoplattform, Stand 06/2026: Zugangsschlüssel liegen nur als kryptografische Prüfwerte in der Konfiguration; Klartext-Schlüssel gehören nie ins Repository.
Häufige Fragen
Was oft gefragt wird.
Wie belegt ihr Sicherheit, ohne ein Zertifikat vorzulegen?
Durch Nachvollziehbarkeit: Prüfprotokolle mit Datum, eine Liste der Funde samt Bearbeitungsstand, maschinell erzwungene Sicherheitsregeln, die man lesen kann, und offen benannte offene Punkte. Ein Zertifikat sagt, dass jemand geprüft hat; unsere Unterlagen sagen, was dabei herauskam.
Was passiert, wenn ihr in unserem System eine Schwachstelle findet?
Wir melden sie, auch wenn sie von uns stammt. In unseren eigenen Projekten ist die Fehlerkultur dokumentiert: Fehlschläge werden nicht nur behoben, sondern als wiederverwendbare Regel festgeschrieben, damit derselbe Fehler nicht zweimal möglich ist.
Verarbeitet ihr Daten außerhalb der EU?
Nein, wenn wir es vermeiden können — und wir vermeiden es konsequent. Karten und Adresssuche laufen über den eigenen Dienst in Österreich statt über einen Fremdanbieter. In einem Projekt verweigert die Anwendung in Produktion sogar den Start, wenn die Geocoding-Adresse auf einen öffentlichen Fremddienst zeigt.
Die anderen Prinzipien.
Jedes für sich erklärt, warum wir so bauen — und woran man es nachprüfen kann.