Wenn eine Agentur klein ist, ist die Verwaltung von Benutzerzugriffen eher eine Frage der Gewohnheit als ein festgelegter Prozess. Man teilt Admin-Zugangsdaten, weil es schneller geht, gewährt in MyKinsta Zugriff auf Unternehmensebene, weil das Einrichten eines Benutzers auf Website-Ebene ein paar Minuten länger dauert, und lässt einen Auftragnehmer im System, weil es nicht dringend ist, ihn zu entfernen.
Das Problem ist, dass diese Abkürzungen Teil der Vorlage für jedes nachfolgende Projekt werden. Wenn dann ein Kunde fragt, wer eine Einstellung geändert hat, oder sich herausstellt, dass ein Auftragnehmer, mit dem du dich im letzten Quartal getrennt hast, immer noch Zugriff auf eine Live-Website hat, hat sich dieses Muster in deinem gesamten Portfolio wiederholt.
Die Verwaltung von Kundenzugängen ist die Art von Problem, die mit deiner Agentur mit wächst, ohne ins Rampenlicht zu rücken – bis es im ungünstigsten Moment zum Vorschein kommt.
Das Berechtigungsmodell von Kinsta bietet dir die Infrastruktur, um Zugangsentscheidungen genauso bewusst zu treffen wie jeden anderen Teil deines Agentur-Workflows.
Wie sich „Zugriffswildwuchs“ unbemerkt in einer wachsenden Agentur entwickelt
Zugriffsausuferung beginnt typischerweise mit einer Entscheidung, die einmal Sinn ergab und dann ohne Überprüfung wiederholt wurde. Der erste Fall ist meist harmlos, wie zum Beispiel das Weitergeben von Admin-Zugangsdaten an einen Kunden während einer Projektbesprechung, weil das Einrichten eines separaten Accounts zehn Minuten dauern würde, die du nicht hast.
Der zweite Fall ist ähnlich: Du gewährst einem Auftragnehmer in MyKinsta „Company Developer“-Zugriff, weil das Anlegen eines Benutzers auf Website-Ebene am Ende eines Onboarding-Gesprächs wie zusätzliche Arbeit wirkt. Beide Entscheidungen erscheinen angemessen, aber bei keiner wurde die Skalierbarkeit im Blick behalten.
Jede dieser Entscheidungen schafft jedoch einen Präzedenzfall für das nächste Projekt. Innerhalb eines Jahres kann eine Agentur, die zwanzig Kunden-Websites verwaltet, ein Dutzend Nutzer mit Zugriffsrechten haben, die nie bewusst festgelegt wurden:
- Ehemalige Mitarbeiter, die beim Ausscheiden nie entfernt wurden.
- Auftragnehmer, die noch Berechtigungen für Projekte haben, die schon vor Monaten beendet wurden.
- Kunden mit unternehmensweiter Einsicht in Daten, die nie für sie bestimmt waren.
Die beiden Berechtigungssysteme, die jede Agentur verstehen muss
Eine Kinsta-Konfiguration umfasst zwei separate Berechtigungssysteme. Du steuerst den Zugriff auf die Hosting-Umgebung in MyKinsta und legst über WordPress fest, was Nutzer innerhalb der Anwendung tun dürfen.
Da diese Systeme jedoch unabhängig voneinander funktionieren, entstehen die meisten Fehler beim Zugriff gerade dadurch, dass man die beiden miteinander verwechselt.
MyKinsta-Rollen und was sie tatsächlich steuern
MyKinsta verfügt über sechs Rollen auf zwei Ebenen, und erst wenn du die Grenzen zwischen ihnen verstehst, kannst du das System zu deinem Vorteil nutzen.
Es gibt vier Rollen auf Unternehmensebene:
- Unternehmensinhaber. Es gibt nur einen pro Konto, und es ist die einzige Rolle, die einen Tarif kündigen oder die Unternehmensinhaberschaft übertragen kann. Im täglichen Gebrauch funktioniert sie genauso wie der Unternehmensadministrator und ist für den Leiter der Agentur vorgesehen.
- Unternehmensadministrator. Diese Rolle gewährt vollständige Kontrolle über alle Unternehmensdaten und uneingeschränkten Zugriff auf jede Website, einschließlich Migrationsanfragen. Sie umfasst Einblick in die Abrechnung und die Möglichkeit, Tarife zu ändern – daher ist sie für leitende Teammitglieder gedacht, denen du diese Verantwortlichkeiten anvertraust.
- Unternehmensentwickler. Mit dieser Rolle kannst du alle Websites und DNS-Einstellungen im gesamten Konto sowie die Benutzer auf Website-Ebene verwalten. Unternehmensentwickler können die Liste der Unternehmensbenutzer (einschließlich E-Mail-Adressen und Rollen) einsehen, dürfen jedoch weder den Zugriff auf Unternehmensebene ändern noch Abrechnungsdetails einsehen. Dies ist die richtige Standardeinstellung für die meisten internen Entwickler.
- Unternehmensabrechnung. Diese Rolle dient ausschließlich dem Zugriff auf Abrechnungsdetails wie Rechnungen, Firmennamen und Adressen. Verwende sie für Ansprechpartner aus der Finanzabteilung, die Einblick in Rechnungen benötigen und sonst nichts.
Die beiden Rollen auf Website-Ebene sind für den Zugriff von Kunden und Auftragnehmern vorgesehen:
- Website-Administrator. Du erhältst vollständigen Zugriff auf eine bestimmte Website und alle ihre Umgebungen, einschließlich der DNS-Verwaltung. Beauftragte können die Website nicht aus dem Unternehmenskonto entfernen, Migrationsanfragen stellen oder Premium-Staging-Umgebungen erstellen.
- Website-Entwickler. Diese Rolle gewährt ausschließlich Zugriff auf Staging-Umgebungen. Die betreffenden Personen haben keinen Zugriff auf die Live-Umgebung, können keine Staging-Umgebungen in die Produktion übertragen und keine Daten auf Unternehmensebene einsehen.
Die Schutzlogik der Rollen auf Website-Ebene ist die Grundlage einer soliden Zugriffsrichtlinie für Kunden. Kurz gesagt: Der Zugriffsbereich einer Benutzerrolle ist auf eine Website beschränkt. Im Fall eines Website-Entwicklers gilt dies ausschließlich für die Staging-Umgebung.
WordPress-Dashboard-Rollen und wo sie hingehören
WordPress-Benutzerrollen legen fest, was Benutzer innerhalb von WordPress tun können, und sind völlig unabhängig von MyKinsta. Ein Benutzer kann also eine WordPress-Rolle innehaben, ohne Zugriff auf MyKinsta zu haben, und umgekehrt.
Ein häufiges Problem ist es, einem Kunden gleichzeitig den Zugriff als „Website-Administrator“ in MyKinsta und als „WordPress-Administrator“ auf derselben Website zu gewähren. Das Ergebnis ist ein Kunde, der in dem einen System Einstellungen auf Serverebene anpassen kann, während er im anderen System Plugins installiert, Benutzer verwaltet und Themes ändert.
Es ist wichtig, die WordPress-Rolle an die tatsächliche Aufgabe anzupassen:
- Ein Kunde, der Inhalte verwaltet, benötigt Editor-Zugriff in WordPress und keinen MyKinsta-Zugriff.
- Ein Entwickler, der auf der Staging-Umgebung arbeitet, benötigt „Website-Entwickler“-Zugriff in MyKinsta und möglicherweise Administrator-Zugriff in WordPress auf der Staging-Umgebung. Du solltest das vor dem Go-Live überprüfen.
- Ein Kunde, der seine Website nach der Übergabe selbst verwaltet, benötigt „Website-Administrator“-Zugriff in MyKinsta und eine WordPress-Administrator-Rolle, sofern seine Fähigkeiten und der Projektumfang beides rechtfertigen.
Das gleiche Prinzip gilt für beide Systeme: Erteile nur den Mindestzugriff, den die Rolle erfordert. Mehr zu gewähren, nur weil es einfacher zu erklären ist, schafft Sicherheitslücken, die erst sichtbar werden, wenn sie ein Problem verursachen.
Was Agenturen typischerweise falsch machen, wenn sie Kunden einbeziehen
Die meisten Agenturen kommen nicht aus Nachlässigkeit zu einer fehlerhaften Zugriffskonfiguration, sondern aufgrund von isoliert betrachtet vernünftigen Annahmen. Jede dieser Annahmen birgt jedoch ein Versagensrisiko, das erst dann offensichtlich wird, wenn bestimmte Umstände es auslösen.
„Wir verwalten die Zugriffe manuell“
Manuelle Zugriffsverwaltung funktioniert, wenn das Portfolio klein und das Team stabil ist, versagt aber, sobald keines dieser beiden Kriterien mehr zutrifft.
Ein Kunde, der beispielsweise versehentlich den Zugriff als „Unternehmensentwickler“ erhält, weil eine Einladung auf Unternehmensebene statt auf Website-Ebene verschickt wurde, kann die E-Mail-Adressen und Rollen aller Nutzer in deinem Konto einsehen. Ebenso kann ein Auftragnehmer, dem auf einer Projekt-Website WordPress-Administrator-Zugriff gewährt wurde, die gesamte Benutzertabelle exportieren, einschließlich aller dort gespeicherten Kundenkontakte.
Auch wenn beides keine dramatischen Sicherheitsvorfälle darstellt, handelt es sich doch um Sicherheitslücken, die eine schriftlich festgelegte Zugriffsrichtlinie verhindert hätte. Eine einfache Tabelle, die Projektrollen den MyKinsta-Rollen und WordPress-Rollen zuordnet, reicht aus:
| Projektrolle | MyKinsta-Rolle | WordPress-Rolle | Anmerkungen |
| Agenturinhaber oder Geschäftsführer | Unternehmensinhaber | Administrator | Eine pro Konto. Die einzige Rolle, die einen Tarif kündigen oder die Unternehmensinhaberschaft übertragen kann |
| Leitender Entwickler oder Kundenbetreuer | Unternehmensadministrator oder Unternehmensentwickler | Administrator | Wähle den Unternehmensadministrator, wenn Einblick in die Abrechnung sinnvoll ist; den Unternehmensentwickler, wenn nicht |
| Projektbeauftragter | Website-Entwickler | Administrator (nur Staging) | Nur Zugriff auf die Staging-Umgebung. Kann keine Änderungen in die Live-Umgebung übertragen oder Staging-Umgebungen löschen |
| Kunde – Content-Management | Keine | Redakteur | Für Inhaltsaufgaben ist keine Hosting-Sichtbarkeit erforderlich |
| Client – Eigentumsrechte nach der Übergabe | Website-Administrator | Administrator | Nur, wenn Fähigkeiten und der Projektumfang beides rechtfertigen |
Wenn die Entscheidung bereits gefallen ist, wird der Onboarding-Schritt zur reinen Umsetzung und nicht mehr zu einer unter Zeitdruck getroffenen Ermessensentscheidung.
„Kunden brauchen gar nicht so viel Zugriff“
Die Einschränkung des Kundenzugriffs fühlt sich wie Risikomanagement an, ist in der Praxis aber nicht dasselbe. Ein Kunde, der zum Beispiel eine Mitarbeiterbiografie aktualisieren, ein Hero-Bild austauschen oder einen Blogbeitrag veröffentlichen muss, braucht keinen Serverzugriff.
Wenn er keine WordPress-Rolle hat, die ihm diese Aufgaben ermöglicht, wird jede einzelne Aufgabe zu einem Ticket in deinem Projektmanagement-Tool. Die Vergabe angemessener Zugriffsrechte ist eine Entscheidung, die deinem Team wiederkehrende Arbeitsaufwände erspart. Ein Kunde mit Editor-Zugriff in WordPress kann beispielsweise seine eigenen Inhalte verwalten, ohne Einblick in die Hosting-Umgebung zu haben.
Die Organic Media Group, eine Agentur für digitales Marketing, die Kundenportfolios bei Kinsta verwaltet, beschreibt die Erfahrung aus Sicht des Teams:
Ich kann einfach jemanden Neues einsteigen lassen, und der kann ein paar dieser Konten problemlos verwalten.
Das Gleiche gilt auf Kundenseite. Die MyKinsta-Oberfläche ist auch für Nutzer ohne technischen Hintergrund zugänglich, und die Rollenstruktur beschränkt den Zugriff auf das, wofür sie verantwortlich sind.
„Das hat bisher noch keine Probleme verursacht“
Zugriffsvorfälle treten in der Regel entweder sofort zutage oder tauchen erst Monate später auf, wenn die Umstände dafür günstig sind. Ein Auftragnehmer, der also noch Staging-Zugriff auf ein Projekt hat, das vor sechs Monaten beendet wurde, ist kein Problem – solange er keine Änderungen vornimmt. Je länger der Zeitraum zwischen der Erteilung einer Berechtigung und der nächsten Überprüfung ist, desto schwieriger wird es, nachzuvollziehen, was wann passiert ist.
Außerdem können bei der manuellen Abmeldung bestimmte Zugriffsprobleme regelmäßig übersehen werden. Wenn du beispielsweise einen Nutzer aus MyKinsta entfernst, werden die von ihm möglicherweise erstellten API-Schlüssel nicht automatisch widerrufen und die SSH-/SFTP-Zugangsdaten nicht zurückgesetzt.
Beides erfordert einen separaten Schritt. Um API-Schlüssel zu widerrufen, geh zu Unternehmenseinstellungen > API-Schlüssel, identifiziere alle Schlüssel, die der ausscheidende Nutzer erstellt hat, und lösche sie. Um SSH-/SFTP-Zugangsdaten zurückzusetzen, geh auf die Website-Ebene, navigiere zu „Info“ und generiere die Zugangsdaten neu. Beides geschieht nicht automatisch, wenn ein Nutzer entfernt wird.
Das Aktivitätsprotokoll hilft hier zwar, aber nur, wenn du es dir ansiehst. Unternehmensadministratoren und Unternehmensentwickler können das Protokoll nach Benutzer oder Website filtern, und jeder Eintrag ist anklickbar, um die Aktion im Detail anzuzeigen. Wenn du einen Benutzer aus dem System entfernst, filtere das Protokoll nach seinem Namen, bevor du ihn entfernst. So erhältst du einen Überblick über seine letzten Aktionen und kannst überprüfen, ob Änderungen überprüft oder rückgängig gemacht werden müssen.
So strukturierst du die Zugriffsrechte bei Kinsta, wenn deine Agentur wächst
Schau dir zunächst deine Rollenstruktur an. Gehe dazu in MyKinsta zu Unternehmenseinstellungen > Benutzer > Benutzer einladen. Im Einladungsfenster kannst du bis zu zehn Benutzer gleichzeitig einladen, indem du ihre E-Mail-Adressen durch Kommas getrennt eingibst, und dann auswählen, ob du Unternehmens– oder Website-Zugriff gewähren möchtest.
So weist du Rollen in einem typischen Agenturteam und im Kundenbeziehungsmanagement zu:
- Ein Agenturinhaber oder Geschäftsführer sollte die Rolle Unternehmensinhaber erhalten.
- Erfahrene Entwickler und Kundenbetreuer könnten entweder die Rolle Unternehmensadministrator erhalten, wenn Einblick in die Abrechnung für ihre Rolle angemessen ist, oder die Rolle Unternehmensentwickler, wenn dies nicht der Fall ist. „Unternehmensentwickler“ ist die richtige Standardrolle für die meisten internen technischen Mitarbeiter.
- Für Projektmitarbeiter weist du die Rolle Website-Entwickler nur in der entsprechenden Staging-Umgebung zu.
- Wenn du Kunden hast, die für das Content-Management zuständig sind, weise ihnen in WordPress den Editor-Zugriff zu. Sie benötigen keinen MyKinsta-Zugang, es sei denn, der Projektumfang umfasst ausdrücklich selbstverwaltetes Hosting.
Für website-spezifische Rollen (wie z. B. „Website-Entwickler“) wähle im Einladungsmodal Website statt Unternehmen aus. Von dort aus suchst du die Website und legst die richtige Rolle fest.
Zur Erinnerung: Weise Kunden, die nach der Übergabe die Verantwortung übernehmen, die Rolle Website-Administrator in MyKinsta und die Rolle WordPress-Administrator zu, sofern ihre Kompetenzen dies rechtfertigen.
Eine Einstellung, die du in deinem gesamten Konto aktivieren solltest, ist die Zwei-Faktor-Authentifizierung (2FA). Kinsta verlangt 2FA für alle Nutzer und unterstützt sowohl die Verifizierung per E-Mail als auch über eine Authentifizierungs-App. Unter Unternehmens-Einstellungen > Nutzer > 2FA kannst du sehen, welche Methode jeder Nutzer aktiviert hat. Für eine Agentur, die mehrere Kunden-Websites verwaltet, ist die Sicherstellung, dass bei jedem Nutzer in deinem Konto 2FA aktiv ist, eine grundlegende Sicherheitsmaßnahme, die parallel zu deiner Rollenstruktur gilt.
Übergabe einer Website an das eigene Konto eines Kunden
Wenn ein Projekt abgeschlossen ist und der Kunde die volle Verantwortung übernimmt, kannst du bei Kinsta die Website direkt auf sein eigenes Kinsta-Konto übertragen, anstatt sie mit neu konfigurierten Berechtigungen in deinem Konto zu belassen.
Um die Übertragung zu starten, navigiere in MyKinsta zu Websites, klicke auf das Drei-Punkte-Menü (Kebab-Symbol) in der Zeile der Website und wähle dann Website übertragen aus dem Dropdown-Menü aus.
Gib im Dialogfeld die E-Mail-Adresse oder die Unternehmens-ID des Zielkontos ein. Du kannst außerdem beliebige DNS-Domains auswählen, die zusammen mit der Website übertragen werden sollen, und dem Kunden optional einen Kinsta-Tarif empfehlen. Klicke auf Website übertragen, um die Anfrage zu senden.
Sobald sich der Kunde bei Kinsta anmeldet, erscheint die Website als Eingehende Übertragung in seiner Website-Liste. Er akzeptiert die Übertragung, indem er auf den Namen der Website klickt und dann Übertragung bestätigen > Übertragung akzeptieren wählt.
Durchführung einer vierteljährlichen Zugriffsprüfung
Die Planung einer vierteljährlichen Überprüfung ist ein schneller Weg, um die Lücken zu schließen, die beim täglichen Offboarding übersehen werden. Gehe zunächst in MyKinsta zu Unternehmenseinstellungen > Benutzer und rufe die vollständige Benutzerliste auf. Du kannst nach Website filtern, um zu sehen, wer Zugriff auf die einzelnen Kundenobjekte hat.
Vergleiche die Liste anschließend mit deinen aktiven Projektdatensätzen. Jeder, dessen Projekt beendet wurde und der noch nicht entfernt wurde, stellt eine Lücke dar. Du entfernst Nutzer, indem du auf das Papierkorbsymbol in ihrer Zeile klickst, oder wählst mehrere Nutzer aus und klickst auf Entfernen.
Zur Erinnerung: Entferne alle zugehörigen API-Schlüssel und überprüfe, ob die SSH-/SFTP-Zugangsdaten für alle Websites mit kürzlich erfolgten Personalwechseln aktualisiert wurden.
Deine Kundenzugriffsstruktur ist im Grunde eine Beziehungsinfrastruktur
Die Zugriffsverwaltung ist ein fortlaufendes Anliegen und kann Auswirkungen auf die Sicherheit haben. Die Art und Weise, wie du Berechtigungen strukturierst, signalisiert den Kunden, ob eine Website von anderen isoliert ist und ob deine Agentur nach einem festgelegten Prozess oder eher nach Gewohnheit arbeitet.
Der nächste Schritt besteht darin, die Zugriffsrichtlinie mithilfe der obigen Rollenzuordnungstabelle schriftlich festzuhalten und eine erste vierteljährliche Überprüfung deines bestehenden Portfolios durchzuführen, um aufzudecken, was sich bereits angesammelt hat. Von da an wird die von euch aufgebaute Zugriffsstruktur für Kunden auf die richtige Art und Weise sichtbar: ein Auftragnehmer, der nur auf die Staging-Umgebung zugreifen kann, ein Kunde, dessen Content-Tools eure Hosting-Umgebung nicht offenlegen, und ein sauberes Offboarding, wenn ein Projekt endet. So sieht es aus, wenn eine Agentur nach einem Prozess statt nach Gewohnheiten arbeitet.
Für Agenturen, die Kundenwebsites in großem Umfang verwalten, bietet das Agency-Partner-Programm von Kinsta euch dedizierten Support, Ressourcen für den gemeinsamen Vertrieb und Tools, die speziell auf die Arbeitsweise von Agenturen zugeschnitten sind, die bei Kinsta hosten.
Joel ist Frontend-Entwickler und arbeitet bei Kinsta als Technical Editor. Er ist ein leidenschaftlicher Lehrer mit einer Vorliebe für Open Source und hat über 200 technische Artikel geschrieben, die sich hauptsächlich um JavaScript und seine Frameworks drehen.
