FLAMOX365 Architektur und Sicherheit

1. Kurzfassung für Entscheider

FLAMOX365 wird als cloudbasierte B2B-SaaS-Plattform mit strikter Mandantenarchitektur konzipiert. Jeder teilnehmende Betrieb, Hersteller oder Partner wird als eigener, isolierter Mandant geführt. Benutzer sehen ausschließlich die Daten, die zu ihrem eigenen Mandanten gehören und für die sie innerhalb dieses Mandanten eine konkrete Berechtigung besitzen.

Die anwendungsspezifischen Produktivdaten der Plattform werden in Microsoft Azure in deutschen Azure-Regionen betrieben werden. Damit wird ein technischer und organisatorischer Rahmen geschaffen, der auf europäische und deutsche Datenschutzanforderungen ausgerichtet ist. Microsoft stellt für Azure umfangreiche Compliance-, Datenschutz- und Sicherheitsinformationen bereit; Azure-Dienste können laut Microsoft im Rahmen der DSGVO eingesetzt werden, wobei die konkrete rechtskonforme Ausgestaltung immer von Architektur, Konfiguration und Vertragslage abhängt.

Wichtig: Sicherheit entsteht nicht allein durch die Wahl eines Cloud-Anbieters - entscheidend ist die Kombination aus sauberer Architektur, konsequenter Mandantenisolierung, rollenbasierter Berechtigung, Verschlüsselung, geregeltem Betrieb, kontrollierten Deployments, datensparsamer Administration und klaren Verantwortlichkeiten.

2. Sicherheits- und Datenschutzgrundprinzipien

FLAMOX365 folgt dem Grundsatz: Geschäftsdaten gehören dem jeweiligen Mandanten. Die Plattform wird Prozesse verbinden, ohne Daten unkontrolliert zwischen Beteiligten offenzulegen.

• Vertraulichkeit: Daten sind nur für berechtigte Personen, Rollen, Systeme und Integrationen sichtbar.
• Integrität: Datenänderungen erfolgen nachvollziehbar, kontrolliert und möglichst manipulationsgeschützt.
• Verfügbarkeit: Die Plattform wird auf einen belastbaren Cloud-Betrieb mit Backup-, Monitoring- und Wiederherstellungskonzept ausgerichtet.
• Strikte Mandantentrennung: Jeder Mandant wird isoliert geführt. Mandantenübergreifende Interaktionen sind im regulären Systemmodell nicht vorgesehen, nicht durch Benutzer auslösbar und technisch nicht möglich.
• Least Privilege: Benutzer, Entwickler, Administratoren und Dienste erhalten nur die Berechtigungen, die sie für ihre Aufgabe benötigen.
• Privacy by Design: Datenschutz wird in Datenmodell, Rollenmodell, API-Design, Protokollierung und Betriebsprozesse eingebaut.
• Security by Design: Sicherheitsanforderungen werden nicht nachträglich aufgesetzt, sondern von Beginn an in Architektur, Code, Infrastruktur und Deployment-Prozess berücksichtigt.

3. Technische Zielarchitektur

FLAMOX365 wird als moderne Webplattform mit klar getrennten Anwendungsschichten konzipiert. Nach außen ist dabei nicht entscheidend, welche konkreten Einzeltechnologien intern verwendet werden, sondern dass die Plattform auf gängigen, langlebigen und wartbaren Webstandards basiert. Die Architektur ist darauf ausgelegt, Sicherheitsprüfungen zentral durchzusetzen und direkte Zugriffe auf Datenbanken, Dokumentenspeicher, Dateien oder interne Systeme zu verhindern. Sämtliche sicherheitsrelevanten Entscheidungen werden zentral innerhalb der Plattformarchitektur getroffen und nicht einzelnen Oberflächen, Anwendungen oder Integrationen überlassen.

3.1 Benutzeroberfläche

Die Benutzeroberfläche wird mit etablierten Webtechnologien umgesetzt. Sie stellt Prozesse, Formulare, Übersichten, Dokumente und Statusinformationen dar. Sie ist jedoch nicht die verbindliche Sicherheitsinstanz. Selbst wenn eine Oberfläche eine Funktion anzeigt oder ausblendet, entscheidet letztlich immer die serverseitige Anwendungsschicht, ob ein Zugriff erlaubt ist.

3.2 Anwendungsschicht

Die Anwendungsschicht bildet die fachliche und sicherheitsrelevante Kontrollinstanz von FLAMOX365. Sie prüft Identität, Rolle, Mandant, Berechtigung, Vorgang und fachlichen Kontext jeder relevanten Aktion. Dadurch wird verhindert, dass Benutzer, Integrationen oder Oberflächen direkt auf fremde Daten zugreifen können.

3.3 Zentrale API als Sicherheits- und Kontrollschicht

Ein wesentlicher Bestandteil der Sicherheitsarchitektur von FLAMOX365 ist die zentrale Anwendungs-API. Sämtliche fachlichen Interaktionen zwischen Benutzeroberflächen, mobilen Anwendungen, Integrationen, Automatisierungen und internen Diensten erfolgen ausschließlich über definierte und kontrollierte API-Schnittstellen.

Die API dient dabei nicht nur der technischen Kommunikation zwischen Systemkomponenten, sondern bildet eine zentrale Sicherheits- und Kontrollinstanz der gesamten Plattform. Direkte Zugriffe auf Datenbanken, Dokumentenspeicher oder interne Systemkomponenten sind nicht vorgesehen. Stattdessen werden sämtliche Zugriffe über die Anwendungs-API geleitet und dort geprüft.

Die FLAMOX365 API stellt die einzige autorisierte Zugriffsschicht auf fachliche Produktivdaten dar. Weder Benutzeroberflächen noch Integrationen oder externe Systeme erhalten unmittelbaren Zugriff auf Datenbanken, Dokumentenspeicher oder interne Systemkomponenten.

Zu den Aufgaben der zentralen API gehören insbesondere:

• Authentifizierung von Benutzern, Anwendungen und Integrationen.
• Durchsetzung der strikten Mandantentrennung.
• Prüfung von Rollen, Berechtigungen und Sicherheitsrichtlinien.
• Serverseitige Durchsetzung des Least-Privilege-Prinzips.
• Validierung fachlicher Geschäftsprozesse.
• Kontrolle von Dokumenten-, Datei- und Medienzugriffen.
• Absicherung externer Integrationen und Herstelleranbindungen.
• Protokollierung sicherheitsrelevanter Ereignisse.
• Verhinderung unzulässiger oder manipulierter Zugriffe.

Durch diesen Ansatz werden Sicherheitsentscheidungen nicht in einzelnen Oberflächen, mobilen Anwendungen oder Integrationen getroffen, sondern zentral und konsistent innerhalb der Plattform. Dies reduziert die Angriffsfläche erheblich und ermöglicht eine einheitliche Durchsetzung von Datenschutz-, Sicherheits-, Compliance- und Governance-Anforderungen über sämtliche Anwendungen und Schnittstellen hinweg.

3.4 Datenhaltung

Die Datenhaltung wird über professionelle, skalierbare und cloudfähige Datenbank- und Speicherdienste umgesetzt. Alle fachlichen Datensätze werden so modelliert, dass sie einem Mandanten, einem Vorgang und einem Berechtigungskontext zugeordnet sind. Datenzugriffe erfolgen nicht frei, sondern ausschließlich über kontrollierte Anwendungsschichten und die zentrale Sicherheits-API von FLAMOX365.

3.5 Schnittstellen und Systemkommunikation

Die Kommunikation zwischen Web-App, mobilen Anwendungen, internen Diensten und externen Integrationen erfolgt über definierte, dokumentierte und abgesicherte Schnittstellen. Schnittstellen sind nicht als offene Hintertüren konzipiert, sondern als kontrollierte Kommunikationswege mit Authentifizierung, Autorisierung, Mandantenprüfung, Rollenprüfung und Zweckbindung. Sämtliche Kommunikationswege unterliegen den gleichen zentralen Sicherheits- und Berechtigungsmechanismen der Plattform.

3.6 Dokumente und Dateien

Dokumente wie Angebote, Auftragsbestätigungen, Montageunterlagen, Rechnungsinformationen oder Herstellerdokumente werden nicht unkontrolliert verteilt, sondern einem Mandanten, einem Vorgang und einer Berechtigung zugeordnet. Der Zugriff erfolgt über kontrollierte Mechanismen wie serverseitige Prüfung, geschützte Links, zeitlich begrenzte Zugriffstoken oder vergleichbare Schutzmaßnahmen. Auch Dokumenten- und Dateizugriffe werden zentral über die Sicherheitsmechanismen der Plattform kontrolliert und unterliegen den gleichen Mandanten-, Rollen- und Berechtigungsprüfungen wie fachliche Datenzugriffe.

3.7 Hochverfügbarkeit und Ausfallsicherheit

FLAMOX365 wird für einen hochverfügbaren Cloud-Betrieb konzipiert. Die Plattform nutzt moderne Cloud-Architekturen mit automatischer Lastverteilung, redundanter Infrastruktur, kontinuierlicher Überwachung und automatisierten Wiederherstellungsmechanismen. Kritische Komponenten werden so ausgelegt, dass einzelne Infrastrukturstörungen nicht unmittelbar zu einem Ausfall der Gesamtplattform führen.

Je nach Betriebsmodell können hierfür moderne Container-Plattformen, Kubernetes-Cluster, skalierbare Plattformdienste sowie geografisch redundante Speicher- und Datenbankdienste eingesetzt werden. Ziel ist eine maximale Verfügbarkeit geschäftskritischer Prozesse auch bei technischen Störungen einzelner Systemkomponenten.

4. Hosting, Datenstandort und Cloud-Betrieb

FLAMOX365 wird für anwendungsspezifische Produktivdaten auf Microsoft Azure betrieben werden. Für deutsche und europäische Unternehmen ist dabei besonders wichtig, dass Datenstandort, Vertragsgrundlagen, Auftragsverarbeitung, technische Schutzmaßnahmen und Unterauftragsverarbeiter nachvollziehbar dokumentiert werden.

Das Zielbild lautet: Produktive FLAMOX365-Anwendungsdaten werden in Azure-Ressourcen innerhalb Deutschlands betrieben, soweit dies für die jeweiligen Dienste technisch verfügbar und vertraglich vorgesehen ist.

Microsoft beschreibt Azure als Plattform, die Kunden bei der Einhaltung der DSGVO unterstützt und stellt Informationen zu Datenresidenz, Compliance-Angeboten und Datenschutz bereit. Die Verantwortung bleibt jedoch geteilt: Microsoft stellt Cloud-Infrastruktur und Sicherheitsfunktionen bereit; FLAMOX365 ist für die konkrete sichere Architektur, Konfiguration, Zugriffskonzepte, Datenverarbeitung und Anwendungssicherheit verantwortlich.

5. Mandantenmodell und Datentrennung

Die Mandantenfähigkeit ist einer der zentralen Sicherheitsbausteine von FLAMOX365. Ein Mandant kann beispielsweise ein Ofenbau-Betrieb, ein Hersteller, eine Unternehmensgruppe, ein Standortverbund oder ein integrationsberechtigter Partner sein.

5.1 Grundsatz der Mandantenisolierung

Jede fachliche Entität wird einem konkreten Mandanten zugeordnet. Dazu gehören insbesondere Benutzer, Kunden, Interessenten, Angebote, Aufträge, Aufgaben, Dokumente, Artikelkonfigurationen, Herstellerinformationen, Statusmeldungen, interne Notizen und Schnittstellenereignisse.

• Ein Benutzer arbeitet immer in einem definierten Mandantenkontext.
• Jede fachliche Anfrage wird serverseitig auf Mandant, Rolle und Berechtigung geprüft.
• Datenabfragen werden mandantenbezogen eingeschränkt.
• Mandantenübergreifende Sichten, freie Wechsel zwischen Mandanten oder allgemeine Datenräume sind im regulären Systemmodell nicht vorgesehen.
• Hersteller sehen nicht automatisch Daten von Betrieben.
• Betriebe sehen nicht Daten anderer Betriebe.
• Partner, Dienstleister und Integrationen erhalten keine pauschale Sicht auf fremde Daten.
• Support- oder Administrationsprozesse sind datenschutzorientiert, zweckgebunden und auf technische Systemfunktionen begrenzt.

5.2 Hersteller-Mandanten

Ein Hersteller-Mandant kann produktbezogene Informationen, Konfigurationsdaten, Artikelstammdaten, technische Unterlagen, Schnittstelleninformationen oder Bestellprozesse bereitstellen. Diese Informationen bleiben dem Herstellerkontext zugeordnet. Ein Hersteller erhält dadurch keinen allgemeinen Einblick in Betriebsdaten, Kundendaten, Angebotsdaten, Kalkulationen oder interne Vorgänge anderer Mandanten.

5.3 Ofenbau-Betriebe als Mandanten

Ein Ofenbau-Betrieb verwaltet eigene Interessenten, Kunden, Angebote, Aufträge, Dokumente, Montageinformationen und Abrechnungsprozesse. Diese Informationen sind ausschließlich für den jeweiligen Betrieb und dessen berechtigte Benutzer sichtbar. Andere Betriebe, Hersteller oder Partner erhalten daraus keine automatische Sichtbarkeit.

5.4 Zusammenarbeit ohne mandantenübergreifenden Datenraum

FLAMOX365 kann fachliche Prozesse zwischen Beteiligten unterstützen, etwa eine Bestellung an einen Hersteller, eine technische Rückmeldung, einen Dokumentenaustausch oder eine Statusinformation. Solche Vorgänge werden jedoch nicht als allgemeine mandantenübergreifende Interaktion umgesetzt. Es handelt sich um gezielte, zweckgebundene Prozessereignisse mit klar definiertem Inhalt, Richtung, Berechtigung und rechtlicher Grundlage. Die Mandanten bleiben dabei getrennt.

5.5 Technische Umsetzung der Mandantentrennung

Die konkrete Umsetzung besteht aus mehreren Schutzschichten, die sich gegenseitig ergänzen:

• Eindeutige Mandantenzuordnung für fachliche Datensätze, Benutzer, Dokumente und Vorgänge,
• serverseitige Prüfung von Mandant, Rolle, Berechtigung und Vorgangskontext,
• kontrollierte Anwendungsschichten statt direkter Datenzugriffe aus der Oberfläche,
• automatisierte Tests für kritische Mandanten- und Berechtigungsfälle,
• getrennte Rollenmodelle für Betriebe, Hersteller, Partner und Systemfunktionen,
• datenschutzorientierte Administrationsprozesse ohne routinemäßige fachliche Einsichtnahme durch den Betreiber,
• klare Trennung zwischen Produktivdaten, Entwicklungsdaten, Testdaten und technischen Betriebsinformationen.

6. Authentifizierung, Autorisierung und Zugriffsschutz

Der Zugriff auf FLAMOX365 wird über ein abgestuftes Sicherheitsmodell erfolgen. Es reicht nicht, dass jemand angemeldet ist. Entscheidend ist, welche Rolle, welcher Mandant, welcher Vorgang und welche konkrete Berechtigung vorliegen.

6.1 Authentifizierung

Die Authentifizierung stellt sicher, dass Benutzer eindeutig identifiziert werden. Technisch sind moderne Verfahren wie JWT, OAuth, OpenID Connect oder vergleichbare Identity-Mechanismen vorgesehen. Je nach Ausbaustufe können zusätzliche Funktionen wie Single Sign-on, Multi-Faktor-Authentifizierung oder externe Identitätsanbieter angebunden werden.

6.2 Autorisierung

Die Autorisierung beantwortet die Frage: Was darf ein Benutzer konkret tun? FLAMOX365 wird rollen- und rechtebasiert arbeiten. Typische Rollen können beispielsweise sein:

• Mandanten-Administrator
• Geschäftsführung
• Vertrieb
• Auftragsbearbeitung
• Montageleitung
• Monteur
• Buchhaltung
• Hersteller-Administration
• Hersteller-Sachbearbeitung
• Support mit eingeschränktem Zugriff
• Systemadministration mit besonders geregelten Rechten

6.3 Least-Privilege-Prinzip

Benutzer erhalten nur die Rechte, die sie für ihre Aufgabe benötigen. Ein Monteur muss beispielsweise nicht automatisch vollständige Kalkulationsdetails, Einkaufskonditionen oder vertrauliche Herstellerinformationen sehen. Ein Hersteller muss nicht automatisch Kunden- oder Angebotsdaten eines Betriebs sehen, sofern diese für den konkreten Prozess nicht erforderlich sind.

6.4 Support- und Administrationszugriffe

Support- und Administrationsprozesse sind besonders sensibel. Deshalb ist das Zielbild von FLAMOX365 ausdrücklich datenschutzorientiert: Der Betreiber wird nicht routinemäßig in fachliche Mandantendaten hineinsehen und insbesondere keine allgemeine Übersicht darüber erhalten, welche natürliche Person innerhalb eines Mandanten welche fachliche Handlung vorgenommen hat.

• Kein pauschaler Betreiberzugriff auf fachliche Produktivdaten einzelner Mandanten.
• Keine allgemeine mandantenübergreifende Benutzer- oder Aktivitätssicht für den Betreiber im normalen Betrieb.
• Support nur bei konkretem Anlass, definierter Grundlage und möglichst ohne Einsicht in fachliche Inhalte.
• Administrative Funktionen werden soweit möglich systemseitig, regelbasiert und datensparsam ausgeführt.
• Technische Betriebsdaten werden nur soweit verarbeitet, wie dies für Sicherheit, Stabilität, Fehleranalyse, Missbrauchsschutz oder rechtliche Pflichten erforderlich ist.
• Kein allgemeines Teilen von Passwörtern oder Benutzerkonten.
• Trennung zwischen Entwicklungs-, Test- und Produktivumgebung.
• Regelmäßige Überprüfung privilegierter Zugänge.

7. Datenarten und Schutzbedarf

FLAMOX365 verarbeitet unterschiedliche Datenarten mit unterschiedlichem Schutzbedarf. Die Sicherheitsarchitektur orientiert sich daran, welche Daten besonders kritisch sind.

8. Verschlüsselung und Transportabsicherung

Die Plattform wird auf verschlüsselte Kommunikation und geschützte Speicherung ausgerichtet. Dabei sind mehrere Ebenen zu unterscheiden:

• Transportverschlüsselung: Kommunikation zwischen Browser, App, Backend und externen Diensten erfolgt über HTTPS/TLS.
• Verschlüsselung ruhender Daten: Datenbanken, Storage und Backups werden mit den Verschlüsselungsmechanismen der eingesetzten Cloud-Dienste geschützt werden.
• Secret Management: API-Schlüssel, Datenbankverbindungen und Zugangsdaten gehören nicht in den Quellcode, sondern in sichere Secret- und Environment-Mechanismen.
• Token-Schutz: Zugriffstoken müssen zeitlich, technisch und organisatorisch begrenzt werden.
• Dateizugriffe: Dokumente werden nicht dauerhaft öffentlich erreichbar sein, sondern über kontrollierte Zugriffsmechanismen bereitgestellt werden.

8.1 Schutz von Geheimnissen und Schlüsseln

Ein wesentlicher Bestandteil moderner Cloud-Sicherheitsarchitekturen ist der sichere Umgang mit geheimen Zugangsinformationen. Hierzu zählen insbesondere Passwörter, API-Schlüssel, Zertifikate, Zugriffstoken, Verbindungsschlüssel und sonstige sicherheitsrelevante Anmeldedaten.

FLAMOX365 verfolgt das Ziel, solche Informationen grundsätzlich nicht innerhalb von Anwendungen, Quellcodes, Konfigurationsdateien oder Entwicklungswerkzeugen zu speichern. Stattdessen sollen zentrale Sicherheitsmechanismen für die sichere Verwaltung, Verschlüsselung, Rotation, Protokollierung und kontrollierte Bereitstellung sensibler Zugangsdaten eingesetzt werden.

Dadurch wird das Risiko reduziert, dass Zugangsdaten durch Softwarefehler, Fehlkonfigurationen, kompromittierte Entwicklungsumgebungen oder unbeabsichtigte Veröffentlichungen offengelegt werden können.

9. Verfügbarkeit, Backup und Wiederherstellung

Hersteller und Betriebe benötigen Verlässlichkeit im Tagesgeschäft. Deshalb muss FLAMOX365 nicht nur sicher, sondern auch verfügbar und wiederherstellbar sein.

9.1 Verfügbarkeit

Die Plattform wird auf Cloud-Dienste setzen, die professionellen Betrieb, Skalierbarkeit, Monitoring und Wiederherstellungsoptionen unterstützen. Die konkrete Verfügbarkeit hängt von gebuchten Azure-Diensten, Architektur, Regionen, Redundanzkonzept, Betriebsmodell und Service-Level-Vereinbarungen ab.

9.2 Backup

Zur Absicherung gegen Datenverlust, technische Störungen, Fehlbedienungen oder andere Ausfallszenarien ist für Produktivdaten ein geregeltes Sicherungs- und Wiederherstellungskonzept vorgesehen. Datensicherungen sollen verschlüsselt gespeichert, vor unbefugtem Zugriff geschützt und regelmäßig hinsichtlich ihrer Wiederherstellbarkeit überprüft werden. Dazu gehören insbesondere:

• regelmäßige Datenbank-Backups,
• gesicherte Ablage von Datei- und Dokumentenbeständen,
• Aufbewahrungsfristen für Sicherungen,
• getrennte Betrachtung von Löschpflichten und Backup-Aufbewahrung,
• regelmäßige Wiederherstellungstests,
• dokumentierte Recovery-Prozesse.

9.3 Monitoring und Incident Response

Ein sicherer Plattformbetrieb endet nicht bei Infrastruktur und Backup. FLAMOX365 setzt zusätzlich auf kontinuierliche Überwachung technischer Systeme, Dienste und Schnittstellen.

• Verfügbarkeitsüberwachung zentraler Dienste.
• Überwachung technischer Fehlerzustände.
• Früherkennung ungewöhnlicher Systemereignisse.
• Überwachung sicherheitsrelevanter Ereignisse.
• Automatisierte Benachrichtigung bei kritischen Störungen.
• Definierte Prozesse für Analyse, Eskalation und Behebung von Vorfällen.

Ziel ist eine Plattform, die potenzielle Probleme möglichst früh erkennt, automatisiert auf technische Ereignisse reagieren kann und auch bei Störungen einen kontrollierten und nachvollziehbaren Betrieb ermöglicht.

9.4 Überwachung und Angriffserkennung

Neben der technischen Betriebsüberwachung sollen auch sicherheitsrelevante Ereignisse kontinuierlich analysiert werden. Ziel ist es, ungewöhnliche Zugriffsmuster, potenzielle Angriffsversuche, Missbrauch von Berechtigungen oder sonstige Auffälligkeiten frühzeitig erkennen zu können.

Hierzu können zentrale Monitoring-, Alarmierungs- und Analysemechanismen eingesetzt werden, die sowohl Infrastruktur-, Plattform- als auch Anwendungsebene überwachen. Kritische Ereignisse können automatisiert erkannt, protokolliert und definierten Reaktionsprozessen zugeführt werden.

Durch diese zusätzlichen Sicherheitsmechanismen wird die Fähigkeit verbessert, Sicherheitsvorfälle frühzeitig zu erkennen, ihre Auswirkungen zu begrenzen und notwendige Gegenmaßnahmen zeitnah einzuleiten.

10. Entwicklung, Qualitätssicherung und Deployment

FLAMOX365 wird als moderne Softwareplattform entwickelt. Quellcodeverwaltung, Review-Prozesse und Deployments sind Teil der Sicherheitsarchitektur.

10.1 Kontrollierte Entwicklungsplattform

FLAMOX365 nutzt moderne Entwicklungs- und Kollaborationswerkzeuge für Quellcodeverwaltung, Versionierung, Code Reviews, Aufgabensteuerung und Deployment-Prozesse. Diese Werkzeuge sind Entwicklungsinfrastruktur und nicht der Speicherort produktiver Mandantendaten.

10.2 Schutz des Quellcodes

• Geschützte Quellcodebereiche für nicht öffentlichen Anwendungscode.
• Zugriff nur für berechtigte Entwickler und Dienstleister.
• Verpflichtende Code Reviews für kritische Änderungen.
• Branch Protection Rules für produktionsnahe Branches.
• Keine produktiven Zugangsdaten im Repository.
• Prüfung von Geheimnissen, Zugangsdaten und Abhängigkeiten, soweit im jeweiligen Entwicklungsprozess verfügbar und aktiviert.
• Nachvollziehbare Änderungshistorie über Codeänderungen, Reviews und Freigaben.

10.3 CI/CD und Deployments

Automatisierte Deployments reduzieren manuelle Fehler, wenn sie sauber abgesichert sind. Ziel ist ein kontrollierter Prozess von Entwicklung über Test bis Produktion:

• getrennte Entwicklungs-, Test-, Staging- und Produktivumgebungen,
• automatisierte Tests vor produktiven Deployments,
• Code Review vor Freigabe,
• Deployment nur durch berechtigte Personen oder abgesicherte Pipelines,
• Rollback-Möglichkeiten bei Fehlern,
• Protokollierung von Deployments und Releases.

11. Rolle externer Web- und Deployment-Dienste

Moderne Webprojekte nutzen häufig externe Dienste für öffentliche Webseiten, statische Inhalte, Preview-Umgebungen, Build-Prozesse oder schnelle Veröffentlichung von Oberflächen. Solche Dienste können sinnvoll sein, wenn ihr Einsatzzweck klar begrenzt ist und keine vertraulichen Produktivdaten unkontrolliert dorthin gelangen.

Für FLAMOX365 gilt eine klare Abgrenzung: Produktive Mandantendaten gehören in die definierte Azure-Anwendungs- und Datenumgebung. Externe Web- und Deployment-Dienste können für öffentliche Website-Inhalte, Marketingseiten, technische Vorschauen oder nicht-produktive Oberflächen genutzt werden, sofern dabei keine vertraulichen Produktivdaten verarbeitet oder gespeichert werden.

12. Mosaik-Framework

Ein zentraler technologischer Bestandteil der App-Architektur ist das moderne Mosaik-Framework. Es bildet die UI- und Komponentenbasis der Anwendungen und unterstützt eine einheitliche, wartbare und wiederverwendbare Oberfläche.

Wichtig ist die Abgrenzung: Eine UI-Komponentenbasis entscheidet nicht allein über Datensicherheit. Mosaik unterstützt die strukturierte Darstellung und Bedienung; die verbindliche Durchsetzung von Berechtigungen, Mandantentrennung und Datenzugriff erfolgt über die serverseitige Anwendungsschicht, abgesicherte Schnittstellen, Authentifizierung, Autorisierung und das Datenmodell.

Weitere Informationen findest Du hier: https://beta.mosaik.breadstone.de/

13. Governance, Betrieb und Verantwortlichkeiten

Technische Sicherheit muss organisatorisch begleitet werden. FLAMOX365 benötigt deshalb klare Regeln für Betrieb, Zugriff, Entwicklung, Support, Datenschutz und automatisierte Administration.

13.1 Interne Governance

• Benennung technischer und organisatorischer Verantwortlichkeiten.
• Dokumentierte Rollen- und Rechtevergabe innerhalb der jeweiligen Mandanten.
• Regelmäßige Überprüfung privilegierter Konten.
• Trennung von Entwicklungs-, Test- und Produktivzugriffen.
• Dokumentierte Änderungen an produktionsrelevanten Systemen, ohne dadurch eine allgemeine fachliche Mandanteneinsicht für den Betreiber zu schaffen.
• Verfahren für Sicherheitsvorfälle, Datenschutzanfragen und Löschanforderungen.

13.2 Protokollierung und Nachvollziehbarkeit

Nachvollziehbarkeit ist ein wesentlicher Bestandteil moderner Sicherheits- und Compliance-Architekturen. Sicherheitsrelevante Ereignisse sollen daher zentral protokolliert, kontrolliert ausgewertet und entsprechend definierter Aufbewahrungsrichtlinien gespeichert werden.

Hierzu können insbesondere Anmeldevorgänge, fehlgeschlagene Anmeldeversuche, Berechtigungsänderungen, sicherheitsrelevante Systemereignisse, administrative Tätigkeiten, API-Zugriffe, Integrationsereignisse sowie weitere sicherheitsrelevante Vorgänge gehören.

Die Protokollierung dient der Fehleranalyse, der Sicherheitsüberwachung, der Unterstützung von Audits, der Erfüllung regulatorischer Anforderungen sowie der Nachvollziehbarkeit sicherheitsrelevanter Aktivitäten innerhalb der Plattform.

13.3 Shared Responsibility

In der Cloud teilen sich Anbieter und Betreiber die Verantwortung. Microsoft verantwortet die Sicherheit der Cloud-Infrastruktur. FLAMOX365 verantwortet insbesondere sichere Anwendung, Konfiguration, Datenmodell, Zugriffslogik, Prozesse, Verträge und Supportorganisation. Die fachliche Benutzer- und Rechteverwaltung liegt im jeweiligen Mandantenkontext beziehungsweise in systemseitig gesteuerten Administrationsprozessen.

13.4 Dienstleister und Entwickler

Entwickler, Dienstleister und technische Partner erhalten keinen pauschalen Dauerzugriff auf Produktivdaten und keine mandantenübergreifende fachliche Sicht. Zugriffe auf produktionsnahe Systeme müssen erforderlich, zweckgebunden, begrenzt und organisatorisch geregelt sein. Externe Dienstleister sind vertraglich einzubinden, sofern sie personenbezogene Daten oder sicherheitsrelevante Systeme berühren.

14. Datenschutz, DSGVO und Auftragsverarbeitung

FLAMOX365 wird für den Einsatz im europäischen Rechtsraum konzipiert. Die Datenschutz-Grundverordnung verlangt nicht nur sichere Technik, sondern auch nachvollziehbare Rechtsgrundlagen, Auftragsverarbeitung, Zweckbindung, Datenminimierung, Transparenz und Betroffenenrechte.

14.1 Rollen im Datenschutz

Je nach konkreter Nutzung kann ein Ofenbau-Betrieb oder Hersteller Verantwortlicher für seine Kundendaten sein, während FLAMOX365 als Auftragsverarbeiter tätig wird. In bestimmten Konstellationen können abweichende Rollen entstehen, etwa bei eigenen FLAMOX365-Verarbeitungen, Support, Abrechnung oder Plattformbetrieb.

14.2 Auftragsverarbeitung

Für Mandanten, deren personenbezogene Daten über FLAMOX365 verarbeitet werden, ist ein Auftragsverarbeitungsvertrag vorgesehen. Dieser regelt insbesondere Gegenstand und Dauer der Verarbeitung, Art und Zweck der Verarbeitung, Kategorien betroffener Personen, technische und organisatorische Maßnahmen, Unterauftragsverarbeiter und Weisungsrechte.

14.3 Datenschutzprinzipien

• Zweckbindung: Daten werden für definierte Plattform- und Geschäftsprozesse verarbeitet.
• Datenminimierung: Es werden nur Daten verarbeitet, die für den jeweiligen Prozess erforderlich sind.
• Transparenz: Mandanten erhalten klare Informationen zur Verarbeitung.
• Integrität und Vertraulichkeit: Zugriffsschutz, Verschlüsselung und Mandantentrennung schützen Daten.
• Speicherbegrenzung: Lösch- und Aufbewahrungsfristen werden konzeptionell berücksichtigt.
• Rechenschaftspflicht: Prozesse, TOMs und Verträge müssen dokumentiert werden.

14.4 Technische und organisatorische Maßnahmen

Zu den vorgesehenen technischen und organisatorischen Maßnahmen gehören unter anderem:

• Zugriffskontrolle über Benutzer, Rollen und Mandanten,
• strikte Verhinderung mandantenübergreifender Interaktionen im regulären Systemmodell,
• datensparsame Betreiberrolle ohne routinemäßige Einsicht in fachliche Mandantenaktivitäten,
• Transportverschlüsselung über HTTPS/TLS,
• geschützte Cloud-Infrastruktur und Datenhaltung,
• Protokollierung sicherheitsrelevanter Ereignisse,
• Backup- und Wiederherstellungskonzepte,
• Trennung von Entwicklungs- und Produktivumgebungen,
• geregelte Support- und Administrationsprozesse,
• Vertraulichkeitsverpflichtungen für Mitarbeitende und Dienstleister,
• Prüfung und Dokumentation von Unterauftragsverarbeitern.

15. Besondere Anforderungen von Herstellern

Hersteller stellen häufig besonders schützenswerte Informationen bereit: Artikelstämme, Preislisten, Konfigurationsregeln, technische Dokumentationen, Schnittstellenbeschreibungen, Verfügbarkeiten oder Bestellprozesse. FLAMOX365 wird diese Informationen so einbinden, dass Hersteller Kontrolle und Vertrauen behalten.

15.1 Herstellerdaten sind nicht automatisch für alle sichtbar

Ein Hersteller kann Daten für bestimmte Zwecke bereitstellen, ohne dass daraus automatisch eine vollständige Offenlegung gegenüber allen anderen Plattformteilnehmern entsteht. Sichtbarkeit wird fachlich definiert werden: Welche Betriebe dürfen welche Produkte sehen? Welche Preise gelten? Welche technischen Dokumente sind öffentlich, partnergebunden oder intern?

15.2 Herstellerintegration

Herstellerintegrationen können unterschiedliche Tiefe haben:

• Bereitstellung von Produktdaten und Downloads,
• Konfigurationsdaten für digitale Produktkonfiguratoren,
• Bestellübermittlung über API, Datei oder strukturierten Export,
• Statusrückmeldungen zu Aufträgen oder Lieferungen,
• Service- und After-Sales-Prozesse.

Jede Integration benötigt klare Regeln: Welche Daten werden übertragen? Zu welchem Zweck? In welche Richtung? Für welchen Mandanten? Mit welcher Authentifizierung? Wie lange werden Daten gespeichert? Wer darf sie einsehen?

15.3 Wettbewerbs- und Konditionsschutz

Preis- und Konditionsdaten sind besonders sensibel. FLAMOX365 wird diese Informationen mandanten- und partnerbezogen modellieren, sodass ein Betrieb keine Konditionen eines anderen Betriebs sieht - und auch Herstellerdaten nicht unkontrolliert weitergegeben werden (können).

16. Häufige Fragen

Können andere Betriebe meine Interessenten, Kunden, Angebote oder Aufträge sehen?

Nein. Die Plattform wurde von Beginn an nach dem Prinzip einer strikten Mandantentrennung konzipiert. Jeder Betrieb arbeitet innerhalb eines eigenen, technisch isolierten Mandantenkontextes. Sämtliche geschäftlichen Informationen - darunter Interessenten, Kunden, Angebote, Aufträge, Dokumente, Aufgaben, Kommunikationsdaten, Statusinformationen und weitere betriebsrelevante Daten - sind ausschließlich dem jeweiligen Mandanten zugeordnet.

Ein Betrieb erhält grundsätzlich keinen Zugriff auf Daten eines anderen Betriebs. Die Plattform stellt keine Funktion bereit, mit der Benutzer fremde Mandanten durchsuchen, auswählen, öffnen oder einsehen können. Mandantenübergreifende Interaktionen sind im Systemmodell nicht vorgesehen und technisch nicht möglich.

Jeder Datenzugriff wird serverseitig geprüft. Dabei werden Identität, Mandant, Rolle, Berechtigungen und der fachliche Kontext der jeweiligen Anfrage bewertet, bevor Daten bereitgestellt werden. Selbst wenn eine Anfrage technisch manipuliert oder verändert würde, greifen zusätzliche Sicherheitsmechanismen, die unzulässige Zugriffe verhindern.

Die Mandantentrennung wird dabei nicht ausschließlich über die Benutzeroberfläche umgesetzt, sondern zentral innerhalb der Anwendungs- und Sicherheitsarchitektur durchgesetzt. Dadurch kann ein Fehler in einer einzelnen Oberfläche nicht dazu führen, dass Benutzer automatisch Zugriff auf Daten anderer Betriebe erhalten.

Kurz gesagt: Die Daten eines Betriebs gehören ausschließlich diesem Betrieb. Andere Betriebe können diese Daten weder einsehen noch durchsuchen oder abrufen. Die technische Architektur von FLAMOX365 ist ausdrücklich darauf ausgelegt, die Vertraulichkeit und Trennung der Daten aller Mandanten dauerhaft sicherzustellen.

Kann ein Hersteller alle Daten eines Ofenbau-Betriebs sehen?

Nein. Hersteller erhalten grundsätzlich keinen Zugriff auf die Daten eines Ofenbau-Betriebs. Insbesondere erhalten Hersteller keinen automatischen Einblick in Interessenten, Kundenstammdaten, Angebotskalkulationen, Aufträge, interne Notizen, Dokumente, Kommunikationsverläufe, Aufgaben, Margen, Preise oder sonstige betriebsinterne Informationen eines Fachbetriebs.

FLAMOX365 verfolgt bewusst das Prinzip der Datenhoheit. Jeder Betrieb bleibt Eigentümer und Verantwortlicher seiner geschäftlichen Informationen. Die Plattform ist nicht darauf ausgelegt, Herstellern eine generelle Sicht auf die Datenbestände von Fachbetrieben bereitzustellen.

Sofern Geschäftsprozesse eine Zusammenarbeit zwischen Herstellern und Fachbetrieben erfordern, erfolgt diese ausschließlich über klar definierte, zweckgebundene Prozessereignisse. Dabei werden nur diejenigen Informationen bereitgestellt, die für den jeweiligen Prozessschritt tatsächlich erforderlich sind. Der Informationsumfang wird dabei fachlich, technisch und organisatorisch begrenzt.

Auch in diesen Fällen erfolgt die Freigabe von Informationen nicht durch eine offene Mandantensicht, sondern über kontrollierte Plattformprozesse mit rollenbasierten Berechtigungen, serverseitigen Prüfungen und klar definierten Zugriffsregeln. Hersteller erhalten dadurch ausschließlich Zugriff auf diejenigen Informationen, die für einen konkreten Vorgang vorgesehen sind.

Die technische Architektur von FLAMOX365 verhindert, dass Hersteller Mandanten von Fachbetrieben durchsuchen, Datenbestände einsehen oder auf Informationen außerhalb der vorgesehenen Geschäftsprozesse zugreifen können. Eine allgemeine Hersteller-Sicht auf die Geschäftsdaten von Ofenbau-Betrieben ist nicht Bestandteil des Plattformkonzepts und wird durch die Sicherheits- und Mandantenarchitektur der Plattform ausdrücklich ausgeschlossen.

Kann FLAMOX365 intern auf alle Daten zugreifen?

FLAMOX365 ist nicht darauf ausgerichtet, Mitarbeitern oder Betreibern eine allgemeine fachliche Einsicht in die Datenbestände von Herstellern, Fachbetrieben oder anderen Mandanten zu ermöglichen. Die Plattform verfolgt vielmehr das Prinzip der Datensparsamkeit, Zweckbindung sowie der technisch und organisatorisch beschränkten Zugriffsrechte.

Der reguläre Betrieb der Plattform erfordert keine routinemäßige Einsicht in Interessenten-, Kunden-, Angebots-, Auftrags-, Dokumenten- oder Prozessdaten einzelner Mandanten. Administrative Tätigkeiten werden daher so gestaltet, dass sie sich auf den technisch erforderlichen Betrieb, die Stabilität, die Sicherheit und die Verfügbarkeit der Plattform beschränken.

Ein Großteil betrieblicher Abläufe erfolgt automatisiert innerhalb der Plattform selbst. Hierzu zählen insbesondere Sicherheitsprüfungen, Berechtigungsprüfungen, Mandantenprüfungen, Systemüberwachung, Fehlererkennung, Protokollierung sowie weitere technische Betriebsprozesse. Dadurch wird die Notwendigkeit manueller Eingriffe zusätzlich reduziert.

Sofern in Ausnahmefällen technische Analysen, Fehlerbehebungen oder Supportmaßnahmen erforderlich werden, erfolgen diese ausschließlich zweckgebunden, nachvollziehbar, auf das notwendige Maß beschränkt und unter Berücksichtigung der geltenden Datenschutz- und Sicherheitsanforderungen.

FLAMOX365 verfolgt das Ziel, administrative Zugriffe konsequent nach dem Least-Privilege-Prinzip auszurichten. Technisch erforderliche Betriebsinformationen werden daher nur im jeweils notwendigen Umfang verarbeitet. Eine allgemeine fachliche Einsicht in die Geschäftsvorgänge, Kundenbeziehungen, Kalkulationen oder internen Prozesse eines Mandanten ist weder Zweck noch Bestandteil des regulären Plattformbetriebs.

Werden produktive Daten in Entwicklungswerkzeugen gespeichert?

Nein. Produktive Mandantendaten sind nicht Bestandteil von Entwicklungswerkzeugen, Quellcode-Verwaltungssystemen oder Softwareentwicklungsprozessen. Entwicklungsplattformen dienen ausschließlich der Entwicklung, Qualitätssicherung, Dokumentation, Versionsverwaltung und Bereitstellung von Softwarekomponenten.

Daten von Herstellern, Fachbetrieben und anderen Mandanten gehören grundsätzlich nicht in Quellcode-Repositorys, Ticketsysteme, Entwicklungsdatenbanken, Build-Protokolle, Testumgebungen oder vergleichbare Entwicklungsbereiche. Die Plattformarchitektur ist darauf ausgerichtet, produktive Geschäftsdaten und Entwicklungsprozesse organisatorisch sowie technisch voneinander zu trennen.

Produktive Datenbestände werden nicht für Entwicklungszwecke kopiert oder in Entwicklungswerkzeugen verarbeitet. Entwicklungs-, Test- und Qualitätssicherungsprozesse erfolgen grundsätzlich auf Basis geeigneter Test-, Demo- oder anonymisierter Datenbestände, sofern dies für den jeweiligen Zweck erforderlich ist.

Darüber hinaus werden Zugangsdaten, Passwörter, API-Schlüssel, Zertifikate und andere sicherheitsrelevante Informationen nicht innerhalb von Quellcode oder Entwicklungsprojekten gespeichert. Stattdessen kommen hierfür zentrale Sicherheitsmechanismen und speziell dafür vorgesehene Verwaltungsverfahren zum Einsatz.

Durch die konsequente Trennung von Produktivbetrieb und Softwareentwicklung wird sichergestellt, dass geschäftskritische Informationen von Herstellern und Fachbetrieben nicht unbeabsichtigt in Entwicklungsprozesse, Testumgebungen oder technische Hilfssysteme gelangen. Dies reduziert Risiken und unterstützt die Einhaltung moderner Sicherheits-, Compliance- und Datenschutzanforderungen.

Nein. Werden produktive Daten in externen Web- oder Deployment-Diensten gespeichert?

Die produktive Datenhaltung von FLAMOX365 ist für den Betrieb innerhalb einer professionellen Cloud-Infrastruktur vorgesehen. Produktive Mandantendaten, Geschäftsdaten, Dokumente und sonstige betriebsrelevante Informationen werden dabei ausschließlich in den für den Produktivbetrieb vorgesehenen Daten- und Speichersystemen verarbeitet und gespeichert.

Externe Web-, Entwicklungs-, Deployment-, Monitoring- oder Bereitstellungsdienste können im Rahmen des Softwareentwicklungs- und Veröffentlichungsprozesses eingesetzt werden. Diese Dienste dienen jedoch der Entwicklung, Qualitätssicherung, Bereitstellung, Überwachung oder dem Betrieb von Softwarekomponenten und sind nicht als Speicherort für produktive Mandantendaten vorgesehen.

Insbesondere werden Interessenten-, Kunden-, Angebots-, Auftrags-, Dokumenten-, Kommunikations- oder sonstige fachliche Produktivdaten nicht in Quellcode-Verwaltungssystemen, Deployment-Plattformen, Vorschauumgebungen oder vergleichbaren Entwicklungs- und Veröffentlichungswerkzeugen gespeichert. Die Plattformarchitektur verfolgt eine klare Trennung zwischen Produktivbetrieb und Entwicklungsprozessen.

Sofern externe Dienste im Entwicklungs- oder Bereitstellungsprozess genutzt werden, beschränkt sich deren Zweck auf technische Betriebs- und Entwicklungsaufgaben. Die Speicherung produktiver Mandantendaten außerhalb der vorgesehenen Produktivumgebung ist nicht Bestandteil des regulären Plattformkonzepts.

Dadurch wird sichergestellt, dass geschäftskritische Informationen von Herstellern, Fachbetrieben und weiteren Mandanten ausschließlich innerhalb der dafür vorgesehenen Betriebsumgebungen verarbeitet werden und nicht unbeabsichtigt in Entwicklungs-, Test-, Vorschau- oder Deployment-Systeme gelangen.

Ist Azure automatisch DSGVO-konform?

Nein. Kein Cloud-Dienst und keine technische Plattform macht eine Anwendung automatisch DSGVO-konform. Datenschutz und Compliance entstehen nicht allein durch die Auswahl eines Hosting-Anbieters, sondern durch das Zusammenspiel von Technologie, Architektur, Verträgen, Prozessen, organisatorischen Maßnahmen und einer datenschutzgerechten Umsetzung der Anwendung selbst.

Microsoft Azure stellt hierfür umfangreiche Sicherheits-, Datenschutz- und Compliance-Funktionen bereit und zählt zu den weltweit führenden Cloud-Plattformen. Dazu gehören unter anderem moderne Sicherheitsmechanismen, Verschlüsselungsfunktionen, Identitäts- und Zugriffsmanagement, Auditierungs- und Protokollierungsfunktionen, Compliance-Nachweise sowie vertragliche Grundlagen für die datenschutzkonforme Verarbeitung von Daten.

Die tatsächliche Einhaltung datenschutzrechtlicher Anforderungen hängt jedoch davon ab, wie eine Anwendung konzipiert, betrieben und verwaltet wird. Entscheidend sind insbesondere die technische Architektur, die Datenflüsse, die Mandantentrennung, die Zugriffskonzepte, die technischen und organisatorischen Maßnahmen (TOMs), die Auftragsverarbeitung, die Speicherorte der Daten sowie die definierten Betriebs- und Sicherheitsprozesse.

FLAMOX365 verfolgt deshalb einen ganzheitlichen Ansatz. Datenschutz und Informationssicherheit werden nicht als einzelne Funktion betrachtet, sondern als integraler Bestandteil der gesamten Plattformarchitektur. Die Nutzung von Microsoft Azure bildet dabei ein wichtiges Fundament, wird jedoch durch zusätzliche technische, organisatorische und vertragliche Maßnahmen ergänzt, um die Anforderungen an Datenschutz, Sicherheit, Verfügbarkeit und Compliance bestmöglich zu unterstützen.

Kurz gesagt: Azure stellt leistungsfähige Werkzeuge und Rahmenbedingungen bereit. Die datenschutzgerechte und rechtskonforme Umsetzung entsteht jedoch erst durch die sichere Architektur, den verantwortungsvollen Betrieb und die konsequente Umsetzung entsprechender Datenschutz- und Sicherheitsmaßnahmen innerhalb der Plattform selbst.

Was passiert bei einem Ausfall?

Die Verfügbarkeit geschäftskritischer Prozesse gehört zu den zentralen Anforderungen an FLAMOX365. Angebote, Aufträge, Dokumente, Terminplanungen, Montageinformationen und weitere betriebliche Abläufe müssen zuverlässig verfügbar sein. Aus diesem Grund wird die Plattform nach den Grundsätzen moderner Cloud- und Hochverfügbarkeitsarchitekturen entwickelt und betrieben.

Die technische Infrastruktur ist darauf ausgelegt, Ausfallrisiken bestmöglich zu minimieren und einzelne Fehlerquellen nicht zu einem Ausfall der gesamten Plattform werden zu lassen. Hierzu kommen unter anderem redundante Infrastrukturkomponenten, Cluster-Architekturen, automatisierte Überwachungs- und Alarmierungsmechanismen, geregelte Backup- und Wiederherstellungsverfahren sowie moderne Verfahren zur automatisierten Fehlererkennung und Wiederherstellung von Diensten zum Einsatz.

Technische Störungen einzelner Komponenten, Dienste oder Infrastrukturressourcen sollen nicht unmittelbar zu einer Unterbrechung des gesamten Plattformbetriebs führen. Durch automatisierte Wiederanlaufmechanismen, Lastverteilung, kontinuierliches Monitoring und definierte Betriebsprozesse können betroffene Dienste stabilisiert, neu bereitgestellt oder kontrolliert wiederhergestellt werden.

Zusätzlich werden Datensicherungen, Wiederherstellungsverfahren und betriebliche Notfallkonzepte berücksichtigt, um die Auswirkungen außergewöhnlicher Störungen, technischer Defekte oder sonstiger Betriebsereignisse möglichst gering zu halten. Ziel ist eine Plattform, die auch unter anspruchsvollen Betriebsbedingungen ein hohes Maß an Stabilität, Belastbarkeit und Verfügbarkeit gewährleistet.

Kurz gesagt: FLAMOX365 wird nicht für den Idealfall entwickelt, sondern auch für den Fall, dass einzelne Komponenten ausfallen. Die Architektur verfolgt das Ziel, Störungen frühzeitig zu erkennen, Auswirkungen zu begrenzen und den regulären Betrieb schnellstmöglich wiederherzustellen, damit Hersteller, Fachbetriebe und Partner sich im Tagesgeschäft auf die Plattform verlassen können.

Wie wird verhindert, dass ein Fehler im Frontend Daten offenlegt?

Moderne Sicherheitsarchitekturen dürfen sich nicht darauf verlassen, dass Sicherheitsentscheidungen ausschließlich innerhalb einer Benutzeroberfläche getroffen werden. Aus diesem Grund wird die Sicherheit von FLAMOX365 nicht allein durch das Frontend gewährleistet, sondern durch mehrstufige serverseitige Sicherheitsmechanismen innerhalb der Plattformarchitektur.

Die Benutzeroberfläche dient in erster Linie der Darstellung von Informationen, Prozessen und Funktionen. Sie entscheidet jedoch nicht verbindlich darüber, ob ein Benutzer auf Daten oder Funktionen zugreifen darf. Selbst wenn eine Oberfläche fehlerhaft konfiguriert wäre, Informationen falsch darstellen würde oder technische Manipulationsversuche erfolgen sollten, entsteht daraus nicht automatisch ein gültiger Datenzugriff.

Jede sicherheitsrelevante Anfrage wird serverseitig durch die zentrale Anwendungs- und Sicherheitsarchitektur von FLAMOX365 geprüft. Dabei werden unter anderem Identität, Mandant, Rolle, Berechtigungen, fachlicher Kontext sowie die Zulässigkeit der angeforderten Aktion bewertet, bevor Daten bereitgestellt oder Änderungen durchgeführt werden.

Darüber hinaus erfolgt die Durchsetzung der Mandantentrennung, der Rollen- und Berechtigungskonzepte sowie weiterer Sicherheitsrichtlinien nicht innerhalb einzelner Oberflächen, sondern zentral innerhalb der Plattform. Dadurch wird verhindert, dass Fehler in einer Benutzeroberfläche unmittelbar zu einem Zugriff auf fremde Daten oder Funktionen führen können.

FLAMOX365 verfolgt damit das Prinzip „Server Side Security Enforcement“. Sicherheitsentscheidungen werden grundsätzlich dort getroffen, wo Daten verarbeitet werden - innerhalb der kontrollierten Anwendungs- und Sicherheitsarchitektur der Plattform. Dies reduziert die Angriffsfläche erheblich und stellt sicher, dass Datenschutz-, Sicherheits- und Mandantenanforderungen konsistent über sämtliche Anwendungen, Schnittstellen und Endgeräte hinweg durchgesetzt werden.

Wie werden externe APIs abgesichert?

Externe Schnittstellen und APIs gehören zu den zentralen Integrationsmechanismen von FLAMOX365. Sie ermöglichen die kontrollierte Anbindung von Herstellern, ERP-Systemen, Dokumentendiensten, Signaturlösungen, mobilen Anwendungen sowie weiteren internen und externen Systemen. Gleichzeitig stellen sie einen sicherheitsrelevanten Bestandteil der Plattformarchitektur dar und unterliegen deshalb den gleichen Sicherheitsanforderungen wie die eigentlichen Anwendungen.

Jede API-Kommunikation erfolgt ausschließlich über definierte, dokumentierte und abgesicherte Schnittstellen. Unkontrollierte oder direkte Zugriffe auf Datenbanken, Dokumentenspeicher oder interne Systemkomponenten sind nicht vorgesehen. Sämtliche Anfragen werden über die zentrale Anwendungs- und Sicherheitsarchitektur von FLAMOX365 verarbeitet und geprüft.

Vor der Verarbeitung einer Anfrage werden Identität, Mandant, Rolle, Berechtigungen, Sicherheitsrichtlinien sowie der fachliche Kontext der jeweiligen Aktion bewertet. Dadurch gelten für externe Systeme die gleichen Mandanten-, Rollen- und Berechtigungsregeln wie für Benutzer innerhalb der Plattform.

Zur Absicherung der Kommunikation kommen moderne Authentifizierungs- und Autorisierungsverfahren, verschlüsselte Kommunikationswege, Zugriffstoken, zeitlich begrenzte Berechtigungen, Protokollierungsmechanismen sowie weitere Sicherheitsmaßnahmen nach aktuellem Stand der Technik zum Einsatz. Sicherheitsrelevante Ereignisse können dabei nachvollziehbar protokolliert und überwacht werden.

Besonderer Wert wird darauf gelegt, dass Integrationen ausschließlich auf diejenigen Informationen zugreifen können, die für den jeweiligen Geschäftsprozess tatsächlich erforderlich sind. Auch über externe APIs erfolgt daher keine freie Sicht auf Datenbestände oder Mandanten. Die Plattform setzt stattdessen auf das Prinzip der geringstmöglichen Berechtigung (Least Privilege) sowie auf eine konsequente Mandanten- und Zugriffstrennung.

Darüber hinaus werden Zugangsdaten, API-Schlüssel, Zertifikate und sonstige sicherheitsrelevante Geheimnisse nicht innerhalb von Quellcode oder Entwicklungsprojekten gespeichert. Für deren Verwaltung kommen zentrale Sicherheitsmechanismen und speziell dafür vorgesehene Verfahren zum Einsatz.

Kurz gesagt: Eine API stellt in FLAMOX365 keinen Sonderweg an den Sicherheitsmechanismen vorbei dar. Jede externe Integration unterliegt denselben Prüfungen, Berechtigungen, Mandantenregeln und Sicherheitsanforderungen wie die Plattform selbst.

17. Quellen und weiterführende Informationen

Dieses Whitepaper basiert auf dem geplanten technischen Zielbild von FLAMOX365 sowie auf öffentlich verfügbaren Herstellerinformationen der eingesetzten Plattformen. Die konkrete rechtliche und technische Verbindlichkeit ergibt sich aus finaler Architektur, Verträgen, Auftragsverarbeitungsvereinbarungen, technischen und organisatorischen Maßnahmen, Betriebsdokumentation und tatsächlicher Produktivkonfiguration.

• Microsoft Azure - Data Residency und GDPR-Informationen: https://azure.microsoft.com/explore/global-infrastructure/data-residency
• Microsoft Azure - Compliance und Datenschutzinformationen: https://learn.microsoft.com/azure/compliance/
• Mosaik-Framework: https://mosaik.breadstone.de/