Qualität, Sicherheit & Nachweise

Filzmann · technische Qualität hinter den sichtbaren Funktionen

Was Nutzer nicht sehen, ist ein wesentlicher Teil der Software

Eine Buchung, ein Urlaubsantrag oder ein Planungsschritt ist an der Oberfläche schnell erklärt. Weniger sichtbar sind die Regeln dahinter: Wer darf Daten sehen oder verändern? Welche Rechte gelten im Backend? Welche Daten werden überhaupt benötigt? Und was wurde für einen konkreten Release tatsächlich geprüft?

Filzmann-Anwendungen behandeln diese Fragen als Teil der Architektur. Die folgenden Punkte beschreiben Entwicklungsprinzipien und Nachweisformen – keine pauschale Zertifizierung oder Garantie für jeden Softwarestand.

Vier unsichtbare Qualitätsbereiche

Serverseitige Berechtigungen

Eine ausgeblendete Schaltfläche ist keine Sicherheitskontrolle. Relevante Zugriffe werden serverseitig geprüft. Technische Administration und fachliche Berechtigung werden getrennt betrachtet.

Least Privilege

Rollen erhalten nur die Rechte, die für ihre Aufgabe benötigt werden. Administratorrechte sollen nicht automatisch Zugriff auf alle fachlichen Funktionen oder Inhalte erzeugen.

Privacy & Security by Design

Datenminimierung, Rollen, Zwecke, Speicher- und Löschlogik sowie Schutzgrenzen werden möglichst bereits bei der Modellierung berücksichtigt und nicht erst nachträglich dokumentiert.

Nachvollziehbare Releases

Tests und Prüfberichte werden einem konkreten Softwarestand zugeordnet. Release Evidence hält fest, was geprüft wurde, in welcher Umgebung und welche Grenzen oder offenen Punkte bestehen.

Aktuelle technische Schutzgrenzen

Die Entwicklungsdokumentation mehrerer Nextcloud-Module beschreibt versionierte, optionale Datenschutz-Provider für die Auskunft über eigene personenbezogene Daten und für app-eigene Verarbeitungsmetadaten. Fehlende Provider, unvollständige Abdeckung und technische Fehler sollen sichtbar bleiben. Diese Schnittstellen sind kein vollständiges Verzeichnis sämtlicher betrieblicher Verarbeitungen und ersetzen keine rechtliche Prüfung.

Daneben werden getrennte Verträge für die bloße Vorschau von Aufbewahrungsfällen und – in einem eigenen noch nicht produktiv freigegebenen Entwicklungsstand – für technisch kontrollierte Löschoperationen erprobt. Die technische Lösch-Ausführung ist bei Neuinstallation deaktiviert und an gesonderte Voraussetzungen geknüpft; eine Entscheidung über Rechtsgrundlagen oder erforderliche Beteiligung wird dadurch nicht getroffen.

Für besonders weitreichende fachliche Administrationszugriffe dokumentieren einzelne Module zeitlich begrenzte, rollenabhängig geprüfte Freigaben statt eines pauschalen Administrations-Bypasses. Umfang und Prüfnachweise gelten jeweils nur für die konkrete Anwendung und den geprüften Stand.

Eigenständige Module statt Pflicht-Suite

Filzmann-Fachanwendungen sollen eigenständig funktionieren. Gemeinsame Funktionen werden nur dort genutzt, wo eine definierte Schnittstelle sinnvoll ist. Eine optionale Integration darf nicht dazu führen, dass ein Fachmodul ohne die übrige Produktfamilie unbrauchbar wird.

Das reduziert Kopplung, erleichtert Tests und macht die tatsächlichen Zuständigkeiten für Daten und Berechtigungen nachvollziehbarer.

Nachweise statt pauschaler Versprechen

Ein erfolgreicher Test beweist nur die Eigenschaft, die er tatsächlich prüft. Deshalb werden geplante, implementierte, getestete und produktiv eingesetzte Funktionen voneinander getrennt beschrieben. Gültige Evidence kann wiederverwendet werden; relevante Änderungen können bestehende Nachweise veralten lassen.

Hinweise auf BSI-Empfehlungen oder andere Standards werden nur in dem Umfang verwendet, in dem konkrete Anforderungen tatsächlich geprüft wurden. Eine formale Zertifizierung wird nur behauptet, wenn sie tatsächlich vorliegt.

Von der Qualität zum Produkt

Die sichtbaren Fachfunktionen bleiben bewusst in den jeweiligen Produktseiten. Diese Seite erklärt gemeinsame technische Prinzipien und ausgewählte nachgewiesene Entwicklungsschritte; aus einem Architekturvertrag folgt keine pauschale Produkt-, Sicherheits- oder Datenschutzfreigabe. Das verlinkte Release-Evidence-PDF wird gesondert gegen den neueren GitHub-Stand geprüft.