lemniscus®
#hinter software stehen menschen und systeme
#zwei begriffe, die fast alles bedeuten können
„Wir haben ein Team“ und „unsere Software läuft in der Cloud“ klingen beruhigend. Beide Aussagen lassen aber offen, wer die Software tatsächlich entwickelt und betreibt – und ob dahinter ein einzelner Server oder eine belastbare, verteilte Systemlandschaft steht.
Von außen sehen sich zwei Praxisprogramme manchmal erstaunlich ähnlich. Beide werden im Browser geöffnet, beide speichern Daten online und beide nennen sich Cloud-Software. Der entscheidende Unterschied wird erst sichtbar, wenn man hinter die Oberfläche schaut: Wie ist der Dienst aufgebaut? Was passiert, wenn ein System ausfällt? Wer erkennt eine Störung, wer behebt sie und wer entwickelt die Architektur weiter?
Für eine kleine Internetseite kann eine einfache technische Lösung vollkommen angemessen sein. Eine Praxisverwaltung für tausende Praxen verarbeitet dagegen sensible Daten und wird jeden Tag für zentrale Arbeitsabläufe gebraucht. Dafür reicht es nicht, eine Anwendung irgendwie auf einen gemieteten Rechner zu kopieren.
Auch ein Team ist mehr als eine Zahl auf einer Über-uns-Seite. Entscheidend ist, welches Wissen im Unternehmen vorhanden ist, ob Verantwortung auf mehrere Schultern verteilt wird und ob neue Fachkräfte ausgebildet werden. Eine zuverlässige Cloud-Anwendung entsteht nicht allein durch gemietete Infrastruktur. Sie entsteht durch Menschen, die sie sinnvoll aufbauen und dauerhaft betreiben können.
Der Orientierungspunkt
Frage nicht nur, ob eine Software in der Cloud läuft. Frage, wie diese Cloud aufgebaut ist, wer sie betreibt und welche unabhängigen Nachweise sich auf den konkreten Dienst beziehen.
#team ist nicht gleich team
lemniscus ist ein People-Unternehmen. Menschen entwickeln die Software, betreuen Kundys, gestalten Prozesse, tragen Verantwortung für den Betrieb – und bilden die nächste Generation aus.
14 Menschen, sieben Entwicklys
Wir wachsen bewusst gegen einen Trend, bei dem Entwicklungsstellen abgebaut und immer mehr vollständige Aufgaben an KI delegiert werden sollen. KI kann unser Team unterstützen. Sie ersetzt aber weder Erfahrung und Verantwortungsbewusstsein noch die Menschen, die eine Entscheidung prüfen, vertreten und im Ernstfall für den Betrieb geradestehen.
Zur zweiten Jahreshälfte 2026 besteht unser Team – neue Kollegys bereits eingerechnet – aus 14 Menschen. Sieben davon arbeiten in der Softwareentwicklung. Dazu kommt unser „Inner Circle of Trust“ mit externer Entwicklungs-, Beratungs- und Rechtsexpertise sowie unseren B’scheidwisserlys.
Ausbildung ist Teil unserer Zukunftssicherung
Senior-Entwicklys entstehen nicht durch eine Stellenanzeige. Sie waren vorher Juniors, konnten ausprobieren, Verantwortung übernehmen und aus Fehlern lernen. Wer heute nicht ausbildet, schafft die Wissenslücke von morgen.
Unser erstes Azuby hat die Ausbildung erfolgreich abgeschlossen. Die individuellen Datenfelder in lemniscus waren das Abschlussprojekt: kein Übungsstück für die Schublade, sondern ein echtes Feature für echte Nutzys. Wir bilden weiter aus, stellen ein und entwickeln nicht nur unsere Software, sondern auch unser Team weiter.
#was cloud computing überhaupt bedeutet
Früher sagte man meistens: Wir mieten Rechnerinfrastruktur in einem Rechenzentrum. Heute heißt das Cloud Computing. Der Grundgedanke ist einfach: Rechenleistung, Speicher, Datenbanken und weitere technische Dienste werden über ein Netz bereitgestellt, statt im eigenen Keller zu stehen.
Der gemietete Rechner kann ein physischer Server sein. Häufiger ist er ein virtueller Rechner: Eine große physische Maschine wird technisch in mehrere voneinander getrennte Umgebungen aufgeteilt. Solche virtuellen Server gibt es schon lange. Neu ist nicht, dass man Rechner mieten kann, sondern wie schnell und automatisiert sich heute ganze Landschaften aus spezialisierten Diensten aufbauen lassen.
Ressourcen können bei Bedarf bereitgestellt, überwacht, ersetzt und verteilt werden. Datenbanken, Dateispeicher, Warteschlangen oder Schutzsysteme müssen nicht mehr alle auf demselben virtuellen Computer laufen. Genau darin liegt ein wesentlicher Vorteil – wenn ein Anbiety ihn auch nutzt.
Eine Praxisverwaltung für tausende Praxen braucht darüber hinaus rund um die Uhr Strom, Netzwerk, Brandschutz, Zugangsschutz, Ersatzsysteme, Überwachung und Menschen, die bei einer Störung reagieren. Professionelle Rechenzentren lösen den Infrastrukturteil. Wie die Software darin aufgebaut und betrieben wird, bleibt aber Aufgabe des Software-Anbietys.
Warum nicht im eigenen Keller?
Schon für den eigenen Praxisbedarf ist der Keller als alleiniger Betriebs- und Sicherungsort nicht ausreichend. Wasser, Feuer, Diebstahl und ein längerer Stromausfall sind keine abstrakten oder exotischen Bedrohungen. Die Überschwemmungen im Ahrtal 2021 haben sehr deutlich gezeigt, dass ein Ereignis nicht nur ein Gebäude, sondern eine ganze Umgebung samt Infrastruktur treffen kann.
Eine Sicherung im selben Gebäude schützt deshalb nicht vor einem Standortausfall. Und auch ein „Offsite-Backup“ zwei Straßenzüge weiter kann von derselben Überschwemmung oder einem anderen großflächigen Ereignis erfasst werden. Sicherungen müssen ausreichend weit entfernt liegen – und ihre Wiederherstellung muss regelmäßig erprobt werden.
Auch die Cloud hat eine physische Grundlage. Beim Brand im OVHcloud-Rechenzentrum in Straßburg im März 2021 wurde das Rechenzentrum SBG2 weitgehend zerstört und ein benachbartes Gebäude teilweise beschädigt. Das zeigt sehr anschaulich: Auch ein virtueller Rechner läuft am Ende auf echter Hardware – und kann sich ganz real in Rauch auflösen. Virtualisierung ersetzt deshalb weder räumliche Trennung noch ein belastbares Sicherungs- und Wiederanlaufkonzept.
#auch ein einzelner virtueller server ist cloud
Wer bei einem Hoster eine WordPress-Seite betreibt, nutzt im Kleinen ebenfalls gemietete Infrastruktur. Das kann sehr gut funktionieren. Es zeigt aber auch, warum das Wort „Cloud“ allein noch nichts über die Qualität einer Architektur verrät.
Das kompakte Webhosting
Bei einem einfachen Setup laufen Webserver, WordPress und Datenbank auf demselben virtuellen Computer. Manchmal teilt sich die Maschine zusätzlich Aufgaben mit einem Mailserver oder weiteren Websites und WordPress-Installationen.
Nicht jedes Webhosting ist so aufgebaut. Als Modell zeigt es aber das Prinzip: Laufen auf einer aus dem Internet erreichbaren Maschine Webserver, WordPress, Mailserver und weitere Dienste, bringt jeder öffentlich erreichbare Dienst zusätzliche potenzielle Angriffswege mit. Eine Schwachstelle in einer Komponente kann dadurch auch die anderen gefährden. Fällt die Maschine aus oder wird sie erfolgreich angegriffen, ist im Zweifel alles betroffen. Aus diesem Grund trennt man unterschiedliche Aufgaben schon lange voneinander, statt sie gemeinsam auf eine einzige Maschine zu werfen. Für eine überschaubare Website kann ein kompaktes Setup trotzdem ein vertretbarer Kompromiss sein.
Die ernsthaft betriebene SaaS-Anwendung
Bei einer Praxissoftware sind ein Ausfall, eine Sicherheitslücke oder ein Verlust nicht nur ärgerlich. Termine, Dokumentation, Abrechnung und sensible Daten hängen am System. Deshalb werden Schutz, Anwendung, Datenbank, Zwischenspeicher und Dateiablage voneinander getrennt und über mehrere Ausfallbereiche verteilt.
Auch die Ein- und Ausgänge werden bewusst gestaltet. Nur die Komponenten, die Anfragen aus dem Internet annehmen müssen, sind von dort erreichbar. Datenbank, Cache und interne Dateiablage stehen nicht mit einer öffentlichen Eingangstür im Netz.
Cloud ist eine Bezugsform, keine Qualitätsstufe
Eine Anwendung, ihre Datenbank, ein Mailserver und zahlreiche WordPress-Seiten können gemeinsam auf einem einzigen gemieteten Server laufen und sich trotzdem „Cloud-Software“ nennen. Der Begriff ist damit nicht falsch. Er beantwortet nur nicht die entscheidenden Fragen zu Trennung, Ausfallsicherheit und Betrieb.
Unsere drei sichtbaren Eingänge selbst prüfen
Öffne den kostenlosen
Server Test von SSL Labs
und gib office.lemniscus.de oder my.lemniscus.de ein. Für beide
Hostnamen zeigt SSL Labs jeweils drei unterschiedliche IP-Adressen an und prüft jeden dieser
öffentlich sichtbaren Endpunkte einzeln.
Bei lemniscus sind das die drei öffentlichen Eingänge des zweiten Türstehers – je einer für jeden unserer drei Rechenzentrumsstandorte. Dahinter verteilt er die zugelassenen Aufrufe auf die Anwendungsinstanzen. Die eigentlichen Anwendungsserver, die Datenbank, der Cache und die Dateiablage sind im SSL-Labs-Ergebnis nicht sichtbar.
Bei einem unbekannten Anbiety sind mehrere angezeigte IP-Adressen zunächst nur ein Hinweis auf mehrere öffentliche Endpunkte. Sie beweisen für sich allein noch keine Verteilung über verschiedene Rechenzentren. Umgekehrt kann auch eine einzige sichtbare IP-Adresse eine große, verteilte Architektur verdecken. SSL Labs macht den öffentlichen Eingang sichtbar; für die Architektur dahinter braucht es weiterhin eine belastbare Beschreibung oder einen dienstbezogenen Prüfbericht.
#saas ist software als laufender dienst
SaaS steht für „Software as a Service“, also Software als Dienstleistung. Du installierst nicht für jede Praxis einen eigenen Server und kümmerst dich selbst um Updates. Du öffnest lemniscus im Browser; wir entwickeln, aktualisieren, überwachen und betreiben den Dienst im Hintergrund.
Der erste Türsteher: ein knallharter Bouncer
Der erste Türsteher prüft jeden Aufruf nach festen Sicherheitsregeln. Auffällige oder bekannte schädliche Muster weist er ab, bevor sie den eigentlichen Eingang erreichen. Technisch heißt dieser Bouncer Web Application Firewall, kurz WAF.
Der zweite Türsteher: verteilt die Last
Der zweite Türsteher nimmt nur die zugelassenen Aufrufe entgegen. Für jeden einzelnen Aufruf entscheidet er sofort neu, welches der drei Rechenzentren ihn übernimmt. So verteilt er die Arbeit und schickt nichts an einen Standort, der gerade nicht gesund ist. Technisch heißt er Load Balancer.
Dahinter: drei geschützte Rechenzentren
In jedem Rechenzentrum laufen eine Anwendungsinstanz, eine Datenbank-Replik und ein Cache-Knoten. Auch die Dateiablage ist über alle drei Standorte verteilt. Diese Systeme kommunizieren über kontrollierte interne Wege und sind nicht direkt aus dem Internet erreichbar.
Der Weg einer Anfrage – stark vereinfacht
knallharter Bouncer: prüft und filtert
entscheidet für jeden Aufruf neu und verteilt die Last
- Anwendungsinstanz
- Datenbank-Replik
- Cache-Knoten
- Dateiablage, über alle drei Standorte verteilt
- Anwendungsinstanz
- Datenbank-Replik
- Cache-Knoten
- Dateiablage, über alle drei Standorte verteilt
- Anwendungsinstanz
- Datenbank-Replik
- Cache-Knoten
- Dateiablage, über alle drei Standorte verteilt
Bei AWS heißen diese getrennten Rechenzentrumsstandorte Availability Zones. Die Skizze zeigt bewusst nur das Grundprinzip und keine internen Produkt- oder Konfigurationsdetails.
#drei availability zones, eine nahtlose anwendung
Der Einstieg mit den beiden Türstehern erklärt das Grundprinzip. Für technisch neugierige Menschen mit etwas IT-Know-how gehen wir jetzt einen Schritt weiter: So greifen DNS Round Robin, WAF, Load Balancer und die verteilten Systeme bei lemniscus ineinander.
lemniscus wird in der AWS-Region Frankfurt über alle drei Availability Zones betrieben. Eine AZ besteht aus einem oder mehreren eigenständigen Rechenzentren mit getrennter Stromversorgung, Kühlung, Netzwerkanbindung und physischer Sicherheit.
Vom DNS bis zur Anwendungsinstanz
Unsere DNS-Server liefern für office.lemniscus.de und
my.lemniscus.de im Round-Robin-Verfahren drei öffentliche IP-Adressen zurück. Die
Reihenfolge wird gewechselt, sodass bereits die Namensauflösung Zugriffe auf die drei öffentlichen
Eingänge verteilt. Welchen der angebotenen Endpunkte ein Client tatsächlich verwendet, hängt auch
von dessen DNS-Auflösung und Zwischenspeicherung ab. Genau diese drei Endpunkte werden auch beim
Test mit SSL Labs sichtbar.
Ein eingehender Aufruf wird zunächst von der WAF geprüft. Nur wenn er deren Regeln besteht, reicht sie ihn an den Load Balancer weiter. Dieser wählt für jeden Aufruf ad hoc eine gesunde Anwendungsinstanz aus. Wir verwenden keine Sticky Sessions: Eine Sitzung wird also nicht dauerhaft an eine bestimmte Instanz oder AZ gebunden.
Der Load Balancer ist außerdem Teil der Elastizität des Gesamtsystems. Steigt die Last, kann das System vollautomatisch weitere Anwendungsinstanzen starten. Sobald sie bereit und gesund sind, nimmt der Load Balancer sie in die Verteilung auf. Sinkt der Bedarf wieder, werden nicht mehr benötigte Instanzen ebenso automatisch aus der Verteilung genommen und abgeschaltet.
Die erste Ansicht kann deshalb aus AZ A kommen, der Klick auf den Terminplan aus AZ B und die nächste Aktion aus AZ C. DNS Round Robin verteilt die öffentlichen Eingänge; der Load Balancer trifft dahinter die Entscheidung für den einzelnen Aufruf.
Anwendung und Daten in jeder AZ
In jeder AZ stehen Anwendungsinstanzen, eine Datenbank-Replik und ein Cache-Knoten bereit. Die Dateiablage ist ebenfalls über alle drei Availability Zones verteilt. Ein einzelner Anwendungsserver hält deshalb nicht den exklusiven Zustand einer Sitzung und wird nicht zur einzigen Lebensader eines Kundys.
Fällt eine Instanz aus, wird sie nicht mehr ausgewählt. Fällt eine ganze AZ aus, bleiben die Komponenten in den anderen Zonen erreichbar. Weil die Anwendung nicht an einer lokalen Sitzung festhält, kann ein anderer gesunder Standort den nächsten Aufruf übernehmen, ohne dass du dich neu anmelden oder etwas vom Wechsel merken musst.
Auch die Terminbuchung ist getrennt
Die öffentlichen Seiten der Online-Terminbuchung laufen auf eigenen Anwendungsservern. Sie teilen sich nicht einfach eine Maschine mit der Praxissoftware. So wird ein stark öffentlich genutzter Eingang nicht unnötig mit dem internen Arbeitsbereich der Praxen vermischt.
Räumliche Trennung innerhalb der Region
AWS beschreibt die Availability Zones als viele Kilometer voneinander entfernt; zugleich liegen alle innerhalb von höchstens 100 Kilometern. Damit sind es getrennte Ausfallstandorte innerhalb der Region Frankfurt. Genauer nennen wir das standort- oder zonenredundant.
#behaupten kann das jeder
Wir wissen, wie man ein solches System entwickelt und betreibt. Das ist unsere Expertise. Eine Website-Behauptung ist dafür aber kein Beleg. Deshalb lassen wir nicht nur die Infrastruktur anderer Unternehmen sprechen, sondern unseren eigenen Cloud-Dienst und unsere Kontrollen prüfen.
Was C5 bedeutet
C5 steht für „Cloud Computing Compliance Criteria Catalogue“. Der Kriterienkatalog wurde vom Bundesamt für Sicherheit in der Informationstechnik, kurz BSI, für die Beurteilung der Informationssicherheit von Cloud-Diensten entwickelt.
C5 betrachtet nicht nur Schlösser, Notstrom und Brandschutz im Rechenzentrum. Der Katalog umfasst 17 Bereiche. Dazu gehören unter anderem die Organisation der Informationssicherheit, Sicherheitsrichtlinien, Personal, der sichere Regelbetrieb, Berechtigungen, Kryptografie, Entwicklung und Änderungen, Lieferantys, Sicherheitsvorfälle, Notfallmanagement, Compliance und Produktsicherheit.
Genau deshalb ist ein C5-Bericht aussagekräftiger als der bloße Satz „Unser Rechenzentrum ist zertifiziert“. Ein Rechenzentrum kann hervorragend geprüft sein. Das sagt allein noch nicht, ob ein Software-Anbiety Datenbank und Anwendung trennt, Zugriffe sinnvoll begrenzt, Änderungen kontrolliert, Sicherheitsvorfälle bearbeitet oder Wiederanläufe plant.
Testat statt BSI-Zertifikat
Umgangssprachlich wird oft von einer „C5-Zertifizierung“ gesprochen. Fachlich genauer ist „C5-Testat“ oder „C5-Prüfung“: Das BSI stellt den Kriterienkatalog bereit, prüft lemniscus aber nicht selbst und erteilt dafür kein BSI-Zertifikat. Die Prüfung wird durch eine unabhängige Wirtschaftsprüfung durchgeführt und bezieht sich auf den beschriebenen Cloud-Dienst und dessen Kontrollsystem.
Bei einem Bericht vom Typ 1 wird zu einem bestimmten Zeitpunkt geprüft, ob die Beschreibung des Dienstes zutrifft und die vorgesehenen Kontrollen angemessen ausgestaltet und eingerichtet sind. Typ 2 geht weiter und prüft zusätzlich über einen Zeitraum, ob diese Kontrollen wirksam funktioniert haben.
Der Nachweis von lemniscus
Für den lemniscus-Cloud-Dienst liegt ein C5-Typ-1-Testat vor. Es macht unsere eigene Architektur und unsere eigenen organisatorischen Kontrollen zum Prüfungsgegenstand – nicht nur die Rechenzentren unseres Infrastruktur-Anbietys.
#fragen, die mehr verraten als das wort cloud
Du musst keine Architekturprüfung durchführen. Mit einigen konkreten Fragen lässt sich aber schnell erkennen, ob ein Anbiety nur die gemietete Infrastruktur beschreibt oder den eigenen Dienst wirklich erklären kann.
Zur Technik
- Laufen Anwendung und Datenbank getrennt?
- Sind Datenbank, Cache und Dateiablage direkt aus dem Internet erreichbar?
- Über wie viele unabhängige Ausfallbereiche wird der Dienst betrieben?
- Was passiert mit meiner Sitzung, wenn ein Anwendungsserver ausfällt?
- Ist die öffentliche Terminbuchung von der Praxisanwendung getrennt?
- Werden Wiederherstellung und Notfallverfahren tatsächlich getestet?
Zum Unternehmen und zum Nachweis
- Wer entwickelt und wer betreibt die Anwendung?
- Liegt das notwendige Betriebswissen im eigenen Team?
- Wird ausgebildet und Wissen auf mehrere Menschen verteilt?
- Beziehen sich genannte Zertifikate nur auf das Rechenzentrum?
- Gibt es ein Testat für den konkreten Cloud-Dienst?
- Welcher Dienst, welcher Zeitraum und welcher Prüfungstyp sind davon umfasst?
Kurz gesagt
Cloud ist nicht gleich Cloud, weil der Begriff vom einzelnen Mietserver bis zur verteilten SaaS-Plattform alles abdecken kann. Team ist nicht gleich Team, weil belastbarer Betrieb Erfahrung, Verantwortung, Ausbildung und Zusammenarbeit braucht. Erst beides zusammen macht aus gemieteter Infrastruktur einen verlässlichen Dienst.