Sicherheit von Mietsoftware: Was Sie fragen sollten, bevor Sie Ihre Daten anvertrauen

Schon nach wenigen Monaten im Einsatz verwaltet die Software eines Vermietbetriebs eine wirklich sensible Mischung an Informationen. Namen, Adressen und Telefonnummern von Kunden. Zahlungskartendaten und Kautionsbeträge. Unterschriebene Mietverträge und Lieferscheine. Immer häufiger auch die Ausweisdokumente, die Kunden hochladen, um sich auszuweisen, bevor sie Geräte im Wert von mehreren tausend Euro mitnehmen. Dazu kommen die operativen Details — wer welchen Artikel ausgegeben hat, welcher Fahrer wann welche Adresse angefahren ist, welcher Mitarbeiter welche Rückerstattung bearbeitet hat — und schon wirkt eine Vermietplattform weniger wie ein Planungstool und mehr wie ein zentrales Verzeichnis der Kunden eines Unternehmens, seines Geldes und der Handlungen des eigenen Personals, alles an einem Ort.

Nichts davon ist ungewöhnlich oder vermeidbar. Es passiert einfach, sobald aus Angeboten Verträge, aus Verträgen Lieferungen und aus Lieferungen Zahlungen werden. Vermeidbarer ist dagegen, wie wenig Aufmerksamkeit diese Daten während des Kaufprozesses in der Regel bekommen. Die meisten Softwarebewertungen verbringen Wochen damit, Funktionen zu vergleichen: Kann das System serialisierte Anlagen verwalten, spricht es mit der Buchhaltungssoftware, funktioniert die Fahrer-App auf einer Baustelle auch ohne Netz. Sicherheit bekommt meist nur eine Zeile, wenn überhaupt — „ist das sicher?“ —, beantwortet mit einer Beruhigungsfloskel statt einer echten Frage, und für bare Münze genommen, weil niemand derjenige sein will, der eine Entscheidung wegen etwas scheinbar Abstraktem aufhält.

Das ist die falsche Reihenfolge, denn eine Sicherheitslücke meldet sich nicht von selbst so wie ein umständlicher Buchungsbildschirm. Niemand bemerkt ein Problem, bis der Zugang eines ehemaligen Mitarbeiters Wochen nach dessen Austritt immer noch funktioniert, oder ein Support-Gespräch offenbart, dass jeder Mitarbeiter die Kartendaten jedes Kunden einsehen konnte, unabhängig davon, was seine Aufgabe tatsächlich erforderte. Die Lösung besteht nicht darin, vor Vertragsabschluss zum Sicherheitsexperten zu werden. Sie besteht darin, eine kurze Liste konkreter, beantwortbarer Fragen zu stellen — die Art von Fragen, die ein Anbieter, der seinem eigenen Produkt vertraut, klar beantworten können sollte. Dieser Beitrag behandelt vier davon: Anmeldung, Berechtigungen, Audit-Protokolle und API-Zugriff — durchgehend anhand der Antworten von Renttix als ein Beispiel dafür, wie eine solide Antwort auf jede dieser Fragen aussieht.

Ein Passwort allein ist ein schwaches Tor. Nutzer verwenden dasselbe Passwort für mehrere Dienste, notieren es sich oder wählen leicht zu erratende Varianten — und das liegt selten an Nachlässigkeit, sondern daran, dass von jedem erwartet wird, sich Dutzende einzigartiger Passwörter für Systeme zu merken, die er nur wenige Male pro Woche nutzt. Das ist in der Sicherheitsforschung gut belegtes Terrain: Moderne Authentifizierungsmethoden senken die Rate passwortbezogener Sicherheitsverletzungen messbar, weil sie den einzelnen Ausfallpunkt beseitigen, den ein Passwort darstellt.

Es lohnt sich also, jedem Anbieter drei konkrete Fragen zu stellen. Ist Zwei-Faktor-Authentifizierung (2FA) verfügbar, sodass ein gestohlenes oder erratenes Passwort allein nicht zum Einloggen ausreicht? Kann sich Ihr Team über das eigene Single Sign-On (SSO) des Unternehmens anmelden, sodass der Zugriff auf das Mietsystem mit dem zentralen Unternehmenskonto jeder Person steigt und fällt, statt von einem separaten Login abzuhängen, an dessen Verwaltung jemand denken muss? Und werden Passkeys angeboten — eine neuere Authentifizierungsmethode, die ein eingetipptes Passwort durch einen kryptografischen Schlüssel ersetzt, der an ein Gerät gebunden ist, wodurch der häufigste Phishing-Trick (eine gefälschte Login-Seite, die zur Eingabe des Passworts auffordert) weitgehend wirkungslos wird, weil es gar kein Passwort mehr zum Eintippen gibt?

Jede dieser Maßnahmen löst ein anderes Ausfallszenario. 2FA fängt ein durchgesickertes Passwort ab, bevor daraus ein Einbruch wird. SSO bedeutet: Wenn jemand das Unternehmen verlässt, entzieht die Sperrung des zentralen Identitätskontos gleichzeitig den Zugriff auf alle verbundenen Systeme, einschließlich der Vermietplattform — statt sich darauf zu verlassen, dass jemand daran denkt, ein leicht zu vergessendes separates Mietsoftware-Login extra zu deaktivieren. Passkeys entfernen die Schwachstelle — ein Passwort, das gephisht, erraten oder wiederverwendet werden kann — gleich ganz.

Die Antwort von Renttix auf diese Frage ist eindeutig: SSO, Passkeys und 2FA stehen für jede Anmeldung zur Verfügung, statt eine Zusatzoption zu sein, die einer Enterprise-Stufe vorbehalten oder hinter einem Support-Ticket versteckt ist. Bei welchem Anbieter Sie auch prüfen: Es lohnt sich, genau das zu fragen — welche dieser drei Optionen unterstützen Sie, und steht sie uns als Kunde schon heute zur Verfügung, nicht erst auf einer Roadmap?

Das ist die Frage, die die wenigsten Käufer überhaupt stellen, weil Berechtigungen an der Oberfläche in fast jedem Mietsystem am Markt funktionieren scheinen. Die mobile App eines Fahrers zeigt keine Kundenpreise an. Ein Junior-Mitarbeiter im Büro sieht keine Menüoption zum Ausstellen von Rückerstattungen. Das sieht nach funktionierender Zugriffskontrolle aus — beweist aber nur, dass bestimmte Optionen auf bestimmten Bildschirmen ausgeblendet sind. Es sagt nichts darüber aus, was passiert, wenn jemand dieselbe Aktion auf anderem Weg erreicht.

Der entscheidende Unterschied liegt zwischen Autorisierung, die in der Oberfläche durchgesetzt wird, und Autorisierung, die auf dem Server durchgesetzt wird. Eine reine Oberflächen-Durchsetzung bedeutet, dass die Einschränkung vollständig davon abhängt, welche Schaltflächen und Menüs ein Bildschirm anzeigt — das ist für einen ehrlichen Nutzer, der die App wie vorgesehen bedient, unproblematisch, bedeutet aber nichts für jemanden mit technischem Können, der die Entwicklertools eines Browsers öffnet, die zugrunde liegende Anfrage der App abfängt und dieselbe Anfrage direkt sendet, wodurch die Oberfläche umgangen wird, die ihn eigentlich stoppen sollte. Wenn der Server selbst niemals prüft, ob die Person, die diese Anfrage stellt, dazu tatsächlich berechtigt ist, gab es die Einschränkung nie wirklich — sie war nur nicht sichtbar.

Serverseitig durchgesetzte Berechtigungen funktionieren anders: Jede Anfrage wird, unabhängig davon, auf welchem Weg sie eintrifft, gegen die aktuelle Rolle und die Berechtigungen dieses Nutzers geprüft, bevor irgendetwas geschieht — unabhängig davon, was die Oberfläche angezeigt hätte. Das ist eine deutlich stärkere Garantie, weil sie nicht darauf vertraut, dass niemand im Team und niemand, der Zugriff auf ein Gerät, ein Konto oder einen alten Integrations-Token erlangt, jemals nach einer Abkürzung um die Oberfläche herum suchen wird. Sie hält, unabhängig davon, auf welchem Weg die Anfrage ankommt.

Ein anschauliches Beispiel

Stellen Sie sich einen Depotleiter vor, der das Unternehmen im Streit verlässt. Sein Konto wird noch am selben Tag deaktiviert — zumindest theoretisch. Wenn Berechtigungsprüfungen nur in der Oberfläche existieren, könnten eine noch nicht abgelaufene alte Sitzung, eine mobile App, die auf einem privaten Telefon noch eingeloggt ist, oder ein unter seinem Konto ausgestellter Integrations-Token weiterhin Anfragen durchlassen, weil serverseitig nichts wirklich erneut prüft, wer da anfragt. Werden Berechtigungen stattdessen serverseitig durchgesetzt, wird in dem Moment, in dem dieses Konto deaktiviert wird oder sich seine Rolle ändert, jede in seinem Namen gestellte Anfrage — von jedem Gerät, auf jedem Weg — gegen die aktuellen Berechtigungen geprüft und abgelehnt. Der Unterschied ist nicht kosmetisch: Er entscheidet, ob ein Zugriffsentzug tatsächlich wirkt oder nur so aussieht.

Die Frage, die sich an einen Anbieter zu stellen lohnt, ist unverblümt: Wenn ich diese Anfrage direkt sende und dabei Ihre Oberfläche vollständig umgehe, prüft Ihr Server trotzdem, ob ich dazu berechtigt bin? Die Antwort von Renttix lautet, dass Berechtigungen serverseitig durchgesetzt werden, rollenbasiert, bei jeder Anfrage — und nicht nur davon abhängen, was ein bestimmter Bildschirm anzuzeigen entscheidet.

Fragen Sie jeden Anbieter, ob es ein Protokoll gibt, wer was wann getan hat — ein geänderter Preis, eine stornierte Rechnung, eine zu früh freigegebene Kaution, ein bearbeiteter Kundendatensatz. Ohne ein solches Protokoll werden Streitigkeiten darüber, was bei einem bestimmten Auftrag passiert ist, zu widersprüchlichen Erinnerungen an ein Telefonat. Mit einem Protokoll werden sie zu einer Zwei-Minuten-Suche, die die Frage mit einem Zeitstempel und einem Namen klärt.

Doch ein Audit-Protokoll wirft eine zweite, ebenso wichtige und weit häufiger übersehene Frage auf: Wer kann es tatsächlich einsehen, und was zeigt es dieser Person? Ein Protokoll, das jedem Mitarbeiter mit Zugriff darauf vollständige Kartennummern, Ausweisdokumente oder personenbezogene Daten zu einem Eintrag anzeigt, dokumentiert nicht nur Verantwortlichkeit — es wird still und leise zu einem weiteren Ort, an dem sensible Daten an Personen gelangen, die sie nie hätten sehen müssen. Ein Support-Mitarbeiter, der herausfinden will, warum sich der Status eines Auftrags geändert hat, muss dafür nicht die vollständige Kartennummer eines Kunden sehen; er muss sehen, dass sich der Status geändert hat, wann und durch wen.

Die schärfere Version der Audit-Frage lautet also: Wendet das Protokoll selbst das Need-to-know-Prinzip an, indem es sensible Felder je nach Betrachter unkenntlich macht, statt alles jedem offenzulegen, der irgendeinen Grund hat, es zu öffnen? Die Antwort von Renttix ist ein Audit-Protokoll mit Schwärzung — sensible Felder bleiben je nach Betrachter verborgen, sogar innerhalb des Protokolls, das eigentlich dokumentieren soll, was geschehen ist. Das ist der Unterschied zwischen einem Protokoll, das Verantwortlichkeit schafft, und einem, das still und leise eine zweite Exposition derselben Daten schafft, über die es eigentlich wachen soll.

Die meisten Vermietunternehmen verbinden ihre Mietsoftware irgendwann mit etwas anderem — einer Buchhaltungsplattform, einem Marketing-Tool, einem individuellen Reporting-Dashboard, der eigenen Website für Online-Buchungen. Jede dieser Verbindungen läuft in der Regel über einen API-Schlüssel: ein Zugangsdatum, mit dem das andere System im Namen des Unternehmens mit der Vermietplattform kommuniziert.

Die Frage, die sich hier zu stellen lohnt, ist, ob dieser Schlüssel eingeschränkt und widerrufbar ist oder alles-oder-nichts funktioniert. Ein eingeschränkter Schlüssel lässt sich genau auf das begrenzen, was eine bestimmte Integration benötigt — etwa Lesezugriff auf Buchungsdaten für ein Reporting-Tool, ohne die Möglichkeit, Rückerstattungen auszustellen oder Preise zu ändern. Ein widerrufbarer Schlüssel lässt sich einzeln deaktivieren, sobald er nicht mehr gebraucht wird oder ein Verdacht auf Kompromittierung besteht, ohne andere Integrationen zu stören, die auf ihren eigenen, separaten Schlüssel angewiesen sind.

Die Alternative ist ein einziger, gemeinsam genutzter Schlüssel, der vollen Zugriff auf alles gewährt, was das Konto kann, und für jede Integration des Unternehmens verwendet wird. Das ist ein einzelner Ausfallpunkt: Landet er versehentlich in einem öffentlichen Code-Repository, wird er in den falschen Chat-Kanal eingefügt oder liegt er in einem Drittanbieter-Tool, das später selbst von einem Datenleck betroffen ist, kann jeder, der ihn besitzt, alles tun, was das Konto kann. Und ihn zu deaktivieren, um das Leck zu stoppen, bedeutet, den einen Schlüssel zu rotieren, von dem alle anderen Integrationen ebenfalls abhängen — wodurch alle gleichzeitig ausfallen, um ein Problem zu lösen, das nur eine einzige verursacht hat.

Die Entwickler-API von Renttix stellt eingeschränkte, widerrufbare API-Schlüssel aus, sodass ein einzelnes durchgesickertes oder stillgelegtes Zugangsdatum nicht alle damit verbundenen Systeme mit sich reißt. Es lohnt sich außerdem, eine verwandte Frage zur kundenseitigen Sichtbarkeit zu stellen: Was sieht ein Kunde, wenn er sich in sein eigenes Online-Konto einloggt? Das Kundenportal von Renttix ist so gebaut, dass Kunden nur ihre eigenen Daten sehen — ihre eigenen Aufträge, Rechnungen und gespeicherten Zahlungsmethoden — und nichts darüber hinaus. Das ist ein kleines Detail, aber es ist dasselbe Prinzip, angewandt auf ein anderes Publikum: Zugriff begrenzt auf das, was eine bestimmte Person tatsächlich braucht.

Keine der vier oben genannten Fragen erfordert technisches Fachwissen, um sie zu stellen — nur die Disziplin, nach einem konkreten Mechanismus zu fragen, statt eine allgemeine Beruhigung zu akzeptieren. „Nehmen Sie Sicherheit ernst“ erhält von jedem Anbieter in jedem Verkaufsgespräch dasselbe selbstbewusste Ja. „Prüft Ihr Server bei jeder Anfrage die Berechtigungen, unabhängig davon, was die Oberfläche anzeigt“ erhält eine ganz andere Art von Antwort, und der Unterschied zwischen einem Anbieter, der genau beschreiben kann, wie das funktioniert, und einem, der um die Frage herumredet, ist selbst aufschlussreich.

Als kurze Checkliste für ein Anbietergespräch: Unterstützt die Plattform 2FA, SSO und Passkeys für die Anmeldung? Werden Berechtigungen serverseitig bei jeder Anfrage geprüft, oder nur durch das gesteuert, was die Oberfläche anzeigt? Gibt es ein Audit-Protokoll, und schwärzt es sensible Felder je nach Betrachter? Sind API-Schlüssel auf das beschränkt, was jede Integration tatsächlich benötigt, und einzeln widerrufbar statt über alle Verbindungen hinweg geteilt?

Diese vier Fragen verraten Ihnen nicht alles darüber, wie eine Plattform gebaut ist, aber sie verraten Ihnen sehr viel darüber, wie ernsthaft ein Anbieter über die Daten nachgedacht hat, die Ihr Unternehmen ihm gleich anvertraut — und sie lohnen sich, bevor die Daten wandern, nicht erst, nachdem etwas schiefgelaufen ist. Wenn Sie sehen möchten, wie Renttix diese Fragen an einem echten System beantwortet statt auf einer Präsentationsfolie, vereinbaren Sie eine Demo und fragen Sie nach.