Rollen und Zutrittsrechte in Ferienwohnungen: Wer darf was, wann und warum?

Für die erste Hochsaison organisieren Sie Unterstützung. Die Reinigung erhält einen Ersatzschlüssel, ein Co-Host den Code der Keybox und der Haustechniker einen Notfallschlüssel. Im Buchungskonto arbeiten zwei Personen mit demselben Login. Nach der Saison endet die Zusammenarbeit mit dem Co-Host. Jetzt kann niemand sicher sagen, welche Schlüsselkopien, Codes und Datenzugriffe noch bestehen.

Jede einzelne Abkürzung wirkte vernünftig. Zusammen ist ein unsichtbares Berechtigungsnetz entstanden. Der Fehler liegt nicht nur in einem alten Code. Es fehlt eine Antwort auf die grundlegende Frage: Wer darf auf welche Unterkunft, Information oder Entscheidung zugreifen, zu welchem Zweck und für wie lange?

Ein gutes Zugriffsmodell verbindet physische und digitale Rechte. Es unterscheidet die Identität einer Person von ihrer Rolle, begrenzt Berechtigungen auf Objekt und Arbeitsfall und plant den Entzug schon bei der Vergabe. Technik hilft dabei. Sie ersetzt weder die Erlaubnis zum Betreten noch die Verantwortung des Betriebs.

Zuerst alle Schlüssel, Codes, Konten und sensiblen Ansichten erfassen

Ferienwohnungen haben mehr Zugänge als die Eingangstür. Zum physischen Bereich gehören Hauptschlüssel, Kopien, Keyboxen, elektronische Schlösser, Parkkarten, Keller und Technikräume. Digital sind Buchungsportal, PMS, E-Mail, Cloudspeicher, Schliesssystem, WLAN-Verwaltung und operative Plattform relevant. Hinzu kommen sensible Ansichten wie Gästedaten, Ausweisdokumente, Kamerabilder sowie Rechte zur Freigabe von Kosten oder Aufgaben.

Vor einer Rollenmatrix braucht es deshalb ein Inventar. Für jedes Zugangsmittel werden Eigentümer oder verantwortliche Stelle, berechtigte Personen, Zweck, betroffene Objekte, Vergabedatum, vorgesehene Dauer und Entzugsweg erfasst. Bei einem Schlüssel gehört die Zahl bekannter Kopien dazu. Bei einem Konto sind Benutzer, Rollen und starke Authentisierung relevant. Bei einem Code muss erkennbar sein, wann und wo er gilt.

Beispiel für einen Inventareintrag: Partner A; Auftrag 024; Einheit 12; Zutritt am vereinbarten Termin von 10 bis 11 Uhr; Freigabe durch die zuständige Person; Code nach dem Termin deaktivieren; Entzug bestätigen.

Das Inventar soll keine Scheingenauigkeit erzeugen. Ein unbekannter Schlüsselbestand wird als Lücke ausgewiesen, nicht als Null. Ein gemeinsam genutztes Konto wird nicht einer fiktiven Person zugeordnet. Der Betrieb kann nur schützen und entziehen, was er kennt. Die erste praktische Massnahme ist daher oft unspektakulär: Schlüssel zählen, Konten exportieren, Codes erfassen und jede nicht erklärbare Berechtigung untersuchen.

Zugriff hängt von Person, Rolle, Unterkunft, Zweck und Zeitpunkt ab

Eine Identität beantwortet, wer eine Person oder Organisation ist. Eine Rolle beschreibt, welche Art von Tätigkeit sie grundsätzlich ausübt. Beides reicht für eine konkrete Freigabe noch nicht. Eine Reinigungskraft darf vielleicht in zwei Einheiten arbeiten, aber nicht in das Eigentümerdepot. Ein Host verwaltet ein Portfolio, soll jedoch keine Unterkunft eines anderen Unternehmens sehen. Eine Administratorin kann Konten konfigurieren, ohne selbst eine Reparatur fachlich freigeben zu dürfen.

Vor einer Freigabe sollten deshalb diese Punkte geprüft werden:

• Identität: Welche natürliche Person oder Organisation handelt?
• Rolle: Welche Aufgabe oder Verantwortung ist grundsätzlich vorgesehen?
• Organisation: Für welchen Betrieb oder Partner handelt die Person?
• Objekt: Welche Unterkunft oder welcher Bereich ist betroffen?
• Arbeitsfall: Welcher Aufenthalt, Auftrag oder Vorgang begründet den Zugriff?
• Zeit: Ab wann, bis wann und in welchem Zeitfenster ist er nötig?
• Aktion: Darf die Person lesen, ändern, ausführen, prüfen oder freigeben?

Das NIST-Modell für Role-Based Access Control ordnet Benutzern Rollen und Rollen wiederum Berechtigungen zu. NIST weist auf seiner archivierten Projektseite selbst darauf hin, dass der Inhalt nicht mehr aktualisiert wird. Das Grundprinzip bleibt als Modell nützlich, muss im Unterkunftsbetrieb aber um Objekt, Fall und Zeit ergänzt werden. Eine Rollenbezeichnung ist keine Dauerkarte.

Drei Prüfungen für Auftrag 024

Am fiktiven Inventareintrag für Einheit 12 lässt sich das digitale Berechtigungsmodell mit Testkonten prüfen. Legen Sie vor dem Test fest, was das Konto sehen und tun darf. Prüfen Sie anschliessend auch einen ausdrücklich ausgeschlossenen Zugriff.

• Richtiger Auftrag, falsche Einheit: Partner A kann die benötigten Angaben zu Auftrag 024 in Einheit 12 sehen und den vorgesehenen Nachweis einreichen. Der Zugriff auf einen Auftrag in Einheit 13 wird verweigert, wenn dafür keine Berechtigung besteht.
• Abgelaufene Berechtigung: Nach dem festgelegten Ende kann dasselbe Konto den zeitlich begrenzten Auftrag nicht mehr öffnen oder verändern. Prüfen Sie dies auch mit einer bereits geöffneten Sitzung.
• Geänderte Rolle: Nach einem Rollenwechsel gelten die neu festgelegten Rechte. Frühere Einträge bleiben der Person und der Rolle zugeordnet, unter der sie entstanden sind; der Wechsel darf ihre Herkunft nicht nachträglich verändern.

Halten Sie für jede Prüfung Konto, Organisation, Auftrag, erlaubte und ausgeschlossene Aktion, erwartetes und tatsächliches Ergebnis sowie Testzeitpunkt und Softwareversion fest. Ein fehlgeschlagener Test bleibt ein offener Punkt mit Zuständigkeit und Korrekturtermin. Für physische Schlüssel oder Türcodes ist der Entzug gesondert zu prüfen.

Vier klar begrenzte Rollen können die Arbeit ordnen

Oprivia veröffentlicht vier Arbeitsansichten: Gast, Host, Operator und Governance. Das sind Rollenfamilien innerhalb eines operativen Modells, keine universellen Berufsbezeichnungen. Derselbe Mensch kann in verschiedenen Organisationen oder Fällen unterschiedliche Rollen haben. Entscheidend ist, dass Berechtigungen nicht allein aus dem Titel abgeleitet werden.

• Gast: sieht den eigenen Aufenthalt, ergänzt erforderliche Angaben und meldet eigene Anliegen. Andere Aufenthalte und interne Kontrollinformationen bleiben ausserhalb.
• Host: steuert Unterkünfte und offene Punkte im zugeordneten Portfolio und koordiniert die Ausführung. Eigentum allein eröffnet nicht automatisch jede sensible Ansicht.
• Operator: bearbeitet zugewiesene Arbeiten, aktualisiert den Stand und ergänzt vorgesehene Nachweise. Der Auftrag begrenzt Objekt, Daten und mögliche Aktionen.
• Governance: prüft Ausnahmen, begleitet Eskalationen und dokumentiert Freigaben oder wesentliche Entscheide. Diese Rolle soll kritische Arbeit nicht stillschweigend selbst ausführen und danach selbst abnehmen.

Bei wenigen Einheiten können mehrere Aufgaben bei einer Person liegen. Das macht Funktionstrennung schwieriger, aber nicht bedeutungslos. Bei einem sensiblen oder kostenintensiven Vorgang kann ein Vier-Augen-Schritt, eine dokumentierte Zweitprüfung oder eine externe Fachbeurteilung vorgesehen werden. Die Tiefe folgt dem Risiko.

Für Servicepartner ist der Arbeitsfall besonders wichtig. Ein Installateur braucht nicht „Zugang zum Haus“, sondern Zugang zu einem bestimmten Bereich für einen bestimmten Auftrag. Annahme, Zutritt, Nachweis und Freigabe behandelt der Leitfaden zur Servicepartnersteuerung ausführlich.

Ein Code öffnet die Tür, erteilt aber keine Zutrittserlaubnis

Während einer Belegung hat der Gast eine berechtigte Erwartung an Privatsphäre. Die Airbnb-Richtlinie zum Schutz der Privatsphäre verlangt bei gesamten Unterkünften grundsätzlich die Erlaubnis des Gastes, bevor ein Host während der Reservierung eintritt, ausser es liegt ein Notfall vor. Die Expedia-Richtlinie für Vrbo-Buchungen nennt ebenfalls nur einen aktiven Notfall oder einen zeitkritischen Einsatz nach vorgängiger ausdrücklicher Zustimmung. Grund, Zeitpunkt und vorgesehene Dauer sollen klar kommuniziert werden.

Für einen geplanten Partnertermin bedeutet das: Die verantwortliche Rolle stimmt das Fenster mit dem Gast ab, benennt die eintretende Person und ordnet die Zustimmung dem konkreten Aufenthalt und Auftrag zu. Schweigen wird nicht als automatische Einwilligung behandelt. Ein Zutritt im Notfall bleibt auf das Erforderliche begrenzt und wird nachträglich sachlich dokumentiert. Ob darüber hinaus Vertrag oder anwendbares Recht einen Zutritt erlauben oder beschränken, ist im Einzelfall zu prüfen.

Masterkey, Eigentümerstatus oder Administrationsrecht ändern diese Grenze nicht von selbst. Sie erleichtern nur den technischen Zugang. Wer einen Notfall feststellen darf, welche Kontaktversuche erwartet werden und wie ein Schlüssel ausgegeben wird, sollte vor dem Ereignis definiert sein. Temporäre Codes sind hilfreich, wenn ihre Gültigkeit wirklich zeitlich und objektbezogen begrenzt wird. Ein Partnercode ohne Ablaufdatum ist lediglich ein digitaler Dauerschlüssel.

Datensparsamkeit gilt auch für Bilder, Chats und gemeinsam genutzte Konten

Das Prinzip der minimalen Berechtigung verlangt, nur jene Zugriffe zu vergeben, die für die Aufgabe erforderlich sind. Ein Partner braucht möglicherweise Adresse, Fehlerbild, Termin und einen Kontaktweg. Vollständige Buchungshistorie, Ausweiskopie, Zahlungsdaten und private Gästekorrespondenz gehören nicht vorsorglich dazu. Das Schweizer Datenschutzgesetz verlangt insbesondere eine verhältnismässige, zweckgebundene und sichere Bearbeitung von Personendaten.

Gemeinsam genutzte Benutzerkonten unterlaufen diese Kontrolle. Wenn mehrere Personen dasselbe Login verwenden, bleibt unklar, wer eine Information eingesehen oder eine Entscheidung verändert hat. Persönliche Konten, passende Rollen und eine nachvollziehbare Authentisierung sind deshalb nicht blosse IT-Ordnung. Sie verbinden eine Aktion mit einer verantwortlichen Identität.

Kameras bilden einen besonders sensiblen Zugriffsbereich. Die Airbnb-Richtlinie zu Sicherheitskameras verbietet Geräte, die Innenräume von Unterkünften überwachen, auch wenn sie ausgeschaltet sind. Andere Plattformen und lokales Recht können eigene Grenzen setzen. Für private Videoüberwachung in der Schweiz verlangt der EDÖB unter anderem einen begrenzten Aufnahmebereich, Rechtfertigung, Verhältnismässigkeit, Transparenz, kurze zweckgebundene Speicherung und einen möglichst kleinen Empfängerkreis. Nach seiner Orientierung genügt eine anlasslose Einsicht nicht, wenn eine Auswertung erst im Ereignisfall erforderlich ist.

Eine Aufnahme ist zudem nicht automatisch ein abschliessender Beweis für Ursache oder Verantwortlichkeit. Der EDÖB weist darauf hin, dass gefilmte Szenen nicht immer eindeutig sind und ein Gericht im Einzelfall über die Zulassung als Beweismittel entscheidet. Wer einen Schaden oder eine Abweichung klärt, braucht deshalb den gesamten Kontext. Wie Quelle, Zeitpunkt, Korrektur und Entscheidung verbunden werden, erläutert der Beitrag zum Audit-Trail für operative Nachweise.

Offboarding gehört zur Vergabe, nicht erst zum Abschied

Eine Berechtigung hat einen Lebenszyklus: beantragen, prüfen, vergeben, nutzen, kontrollieren, ändern und entziehen. Der letzte Schritt wird häufig erst bedacht, wenn eine Zusammenarbeit bereits beendet ist. Dann fehlen Schlüssel, Zuständigkeiten oder Administrationsrechte, um den Zugriff rasch zu stoppen.

Schon bei der Vergabe sollte deshalb feststehen, wer den Entzug auslöst und technisch ausführt. Typische Auslöser sind das Ende eines Aufenthalts, die Schliessung eines Auftrags, Rollenwechsel, Austritt, Vertragsende, Geräteverlust oder ein Sicherheitsereignis. Das Offboarding umfasst je nach Fall:

• persönliche Konten deaktivieren und aktive Sitzungen beenden
• Rollen, Gruppen und Rechte in verbundenen Systemen prüfen
• Codes sperren oder wechseln sowie Schlüssel und Karten zurückfordern
• gemeinsam bekannte Passwörter ersetzen, solange solche Altbestände bestehen
• offene Aufträge und Dateien übergeben sowie die Verantwortung für ausstehende Entscheidungen zuweisen
• bestätigen, welche Massnahme ausgeführt wurde und welche Lücke offenbleibt

Ein zurückgegebener Schlüssel beweist nicht, dass keine Kopie existiert. Wo der Bestand nicht verlässlich ist, muss der Betrieb das verbleibende Risiko bewerten und gegebenenfalls den Zylinder oder das Schliesskonzept ändern. Ebenso kann ein deaktiviertes Hauptkonto ungenügend sein, wenn die Person weiterhin über E-Mail-Weiterleitungen, Cloud-Freigaben oder ein Partnerportal zugreift.

Regelmässige Überprüfungen ergänzen das ereignisbezogene Offboarding. Dabei bestätigt die verantwortliche Stelle nicht einfach eine lange Benutzerliste. Sie prüft, ob Person, Rolle, Objekt, Fall und Zweck noch zusammenpassen. Das NIST-Prinzip des geringsten Privilegs bietet dafür eine fachliche Orientierung, schreibt aber keinem Ferienwohnungsbetrieb einen bestimmten Turnus vor.

Bei Ausnahmen muss klar sein, wer entscheidet und was Oprivia leistet

Ein verlorener Masterkey, ein Code ausserhalb des Zeitfensters, ein Login einer ausgeschiedenen Person oder ein nicht abgestimmter Zutritt verlangt mehr als eine rote Markierung. Der Betrieb muss den möglichen Zugriff begrenzen, betroffene Systeme oder Personen identifizieren, den Sachverhalt sichern und eine verantwortliche Rolle entscheiden lassen. Eine Eskalation ist erst abgeschlossen, wenn Massnahme, Ergebnis und verbleibendes Risiko festgehalten sind.

Fiktives Beispiel für einen administrativen Eingriff: Partner A darf bisher nur Auftrag 024 bearbeiten. Wegen einer Vertretung soll er zusätzlich Auftrag 025 in Einheit 12 bis 18 Uhr bearbeiten. Die entscheidungsberechtigte Person genehmigt die Erweiterung, eine Administratorin setzt sie um. Der Änderungsvermerk enthält die vorherigen und neuen Rechte, betroffene Aufträge, Anlass, genehmigende und ausführende Person sowie Beginn und Ende. Nach 18 Uhr wird geprüft, ob der Zugriff auf Auftrag 025 tatsächlich entzogen ist. Zeitpunkt, prüfende Person und Ergebnis werden festgehalten. Bleibt der Zugriff möglich, bleibt die Ausnahme mit einer verantwortlichen Person offen, bis der Entzug erfolgreich nachgeprüft ist.

Oprivia verbindet im veröffentlichten Modell Aufenthalt, Vorgang, Berechtigung, Frist, Nachweis und Entscheidung. Zugriffe werden nach Rolle und Kontext begrenzt. Gast, Host, Operator und Governance erhalten unterschiedliche Arbeitsansichten; Organisation, Objekt und konkreter Fall schränken den Umfang weiter ein. Nicht ausdrücklich definierte Berechtigungen werden nach der öffentlichen Plattformbeschreibung standardmässig verweigert.

Oprivia ist kein Türschloss, kein Kamerasystem und keine rechtliche Zutrittsbefugnis. Ein Benutzerkonto bestätigt für sich allein auch keine Identität. Identitätsprüfungen sind davon getrennte Funktionen und werden nur eingesetzt, soweit sie technisch aktiviert, vertraglich vereinbart und rechtlich zulässig sind. Welche Rollen, Verifikationen und Schnittstellen der Betrieb nutzt, richtet sich nach der aktuellen Produktversion, den vereinbarten Modulen und der Konfiguration.

Für eine erste Bestandsaufnahme genügen drei Prüfungen. Kann jeder Schlüssel, Code und Account einer verantwortlichen Person und einem Zweck zugeordnet werden? Endet jede Berechtigung, sobald Aufenthalt, Auftrag oder Zusammenarbeit endet? Bleibt bei einem sensiblen Zugriff erkennbar, wer ihn genehmigt und genutzt hat? Wo eine Antwort fehlt, liegt der nächste konkrete Verbesserungsschritt.