Es ist üblich, dass Organisationen Accounts verwenden, die von mehreren Personen gemeinsam genutzt werden, um ihre Social-Media-Präsenz zu verwalten. Aber die Herausforderung für IT- und Security-Teams besteht darin, die ordnungsgemäße Nutzung dieser Accounts sicherzustellen. Das Hijacking eines Social-Media-Accounts oder die Kompromittierung von Anmeldedaten kann dem Image und Ruf einer Marke erheblichen Schaden zufügen.
Das Passwort nur mit dem Social-Media-Team zu teilen und es nie zu ändern, ist keine effektive Strategie. Einige Teams entscheiden sich möglicherweise für die Nutzung eines Passwortmanagers, damit Teammitglieder auf gemeinsam genutzte Anmeldedaten zugreifen können, und das ist vielleicht schon alles, was Sie benötigen.
In diesem Artikel sehen wir uns an, wie Okta dabei helfen kann, den Zugriff auf gemeinsam genutzte Accounts für Social-Media-Dienste zu kontrollieren. Diese sind in aufsteigender Reihenfolge des Reifegrads:
- Verwendung von Secure Web Authentication (SWA)-Apps in Okta mit gemeinsam genutzten Accounts
- Verwendung von manuellen SaaS-Service-Accounts in Okta Privileged Access
- Verwendung automatisierter SaaS-Service-Accounts in Okta Privileged Access
- Verwendung des Okta Shared Accounts in Okta Privileged Access für einen föderierten Shared Account
Wir werden diese in den folgenden Abschnitten behandeln.
Verwendung von Secure Web Authentication (SWA)-Apps in Okta mit gemeinsam genutzten Konten
Okta arbeitet traditionell mit einer Mischung aus föderierten und nicht-föderierten Accounts. Föderierte Accounts nutzen föderierte Single Sign-On-Protokolle (SSO) wie Security Assertion Markup Language (SAML) und OpenID Connect (OIDC) und erfordern keine Passwörter. Nicht föderierte Accounts sind die Legacy-Accounts mit Benutzer-ID und Passwort, die im Repository der SaaS-App gespeichert sind und auf die über Login-Eingabeaufforderungen oder die Übergabe von Anmeldedaten über HTTP-Header zugegriffen wird.
Wenn wir von Accounts sprechen, die gemeinsam genutzt und zur Verwaltung von Plattformen verwendet werden, sprechen wir normalerweise von Letzterem. Hier kommen Secure Web Authentication-Apps ins Spiel. Der SWA-Mechanismus verknüpft Anmeldedaten mit einer Anwendung in Okta, und wenn ein:e Benutzer:in die Kachel auswählt, fügt das Browser-Plugin die Anmeldedaten ein.
Im Folgenden wird eine in Okta definierte LinkedIn-App mit SWA als Anmeldemethode gezeigt.
Von allen Optionen für Anmeldedaten verwendet das Beispiel „Benutzer:innen teilen sich einen einzigen Benutzernamen und ein Passwort, die von dem:der Administrator:in festgelegt werden.“ Dies sind die vom Marketingteam gemeinsam genutzten Anmeldedaten für den Zugriff auf LinkedIn. Wenn die Anwendung in Okta konfiguriert wird, muss der:die Administrator:in den Benutzernamen und das Passwort für die App kennen und eingeben. Aber die Benutzer:innen müssen das nicht.
Wenn eine:r der zugewiesenen Benutzer:innen auf die LinkedIn-Kachel auf dem Dashboard klickt, ruft das Browser-Plugin den gespeicherten Benutzernamen und das Passwort ab und fügt diese in den Anmeldebildschirm der Anwendung ein.
Wie bei jeder Anwendung in Okta können Zuweisungen auf individueller und/oder Gruppenebene erfolgen.
Idealerweise weisen Sie den Zugriff auf eine App mithilfe gemeinsamer Anmeldedaten über eine Gruppe zu. Sie könnten dann Kontrollen für die Gruppenmitgliedschaft anwenden. Sie könnten Gruppenregeln verwenden, um die Gruppenmitgliedschaft an ein Attribut im Benutzerprofil zu binden (z. B. Abteilung = Marketing).
Noch besser wäre es jedoch, die Gruppenmitgliedschaft mit den Kontrollen von Okta Identity Governance zu verwalten. Sie können die Funktion Zugriff anfordern verwenden, um Nutzer:innen dazu zu zwingen, den Zugriff auf die Gruppe oder App mit einem Approval-Flow (z. B. Genehmigung durch den Manager) und einer Zeitbeschränkung (z. B. Zugriff wird nur für zwei Stunden gewährt) anzufordern. Sie können die Funktion Zugriffszertifizierung verwenden, um regelmäßig zu überprüfen, ob Benutzer:innen, die über Zugriff verfügen, diesen weiterhin benötigen.
Beachten Sie, dass es keine automatische Rotation des Passworts für den Social-Media-Account gibt; der in Okta gespeicherte Wert muss mit dem in der App synchron bleiben. Wenn das App-Passwort geändert wird, muss das in Okta gespeicherte Passwort entsprechend aktualisiert werden. Aber nur ein:e einzige:r Administrator:in muss dies wissen, und das aktualisierte Passwort muss nicht innerhalb eines Teams weitergegeben werden. Dies ist keine perfekte Lösung, bietet aber eine höhere Sicherheit, als das Passwort per E-Mail oder auf einem Zettel unter Teammitgliedern zu teilen.
Verwendung von manuellen SaaS-Service-Accounts in Okta Privileged Access
Okta hat kürzlich eine neue Funktion im Early Access eingeführt, um gemeinsam genutzte Accounts für SaaS-Anwendungen in Okta Privileged Access zu verwalten. Das bedeutet, dass Anmeldedaten für SaaS-Apps, wie z. B. gemeinsam genutzte Accounts zur Verwaltung von Social-Media-Plattformen, im Vault von Okta Privileged Access gespeichert werden können. Darüber hinaus kann eine Richtlinie angewendet werden, um zu steuern, wer auf die Anmeldedaten zugreifen darf und welchen Prozess Nutzer:innen durchlaufen müssen, um die Anmeldedaten einzusehen (z. B. Just-in-Time-Zugriffsgenehmigung, Durchführung einer Multi-Faktor-Authentifizierung).
Diese Funktion verfügt über zwei Modi:
- Manuell, wobei statische Anmeldedaten (Benutzername und Passwort) im Vault gespeichert werden und den Anmeldedaten in der App entsprechen. Wenn die Anmeldedaten der App aktualisiert werden, muss der Vault entsprechend aktualisiert werden.
- Automatisch, wenn die Integration des Okta Integration Network (OIN) für die App die Provisionierung unterstützt, sodass Okta Privileged Access der Manager des Passworts dieses Social-Media-Accounts sein kann.
Social-Media-Plattformen wie Facebook und LinkedIn setzen auf den manuellen Ansatz – Sie müssen statische Anmeldedaten speichern und eine Richtlinie einrichten, um zu steuern, wie diese offengelegt werden können.
Da Okta die Anmeldung für die manuelle App nicht durchführt, wird sie in Okta als Dummy-App definiert (d. h. als Lesezeichen-App, die in den Dashboards der Benutzer:innen ausgeblendet ist). Anschließend werden die gemeinsam genutzten Anmeldedaten als Service-Accounts in Okta gespeichert.
Mithilfe des in Okta gespeicherten und in Okta Privileged Access zugewiesenen gemeinsam genutzten Accounts können Nutzer:innen (je nach Richtlinie) den Benutzernamen und das Passwort anzeigen.
Sie verwenden die Benutzeroberfläche von Okta Privileged Access, um die SaaS-App zu finden.
Wählen Sie dann den Account aus.
Mit dem Account können Kontrollen verknüpft sein, wie beispielsweise eine Just-in-Time-Zugriffsgenehmigung oder eine Multi-Faktor-Authentifizierung. Dann können sie die Anmeldedaten anzeigen, die kopiert und in das Login-Formular der Social-Media-App eingefügt werden können.
Im Vergleich zum früheren SWA-Ansatz wird bei diesem Ansatz das Passwort für die Endbenutzer:innen offengelegt, und da das Passwort nicht automatisch rotiert wird, besteht das Risiko, dass sie es notieren und weitergeben. Sie benötigen einen Prozess, um das Passwort auf der Social-Media-Plattform regelmäßig zu ändern und die Kopie im Vault zu aktualisieren.
Dieser Ansatz bedeutet auch, dass der Zugriff auf die Anmeldeinformationen stärker kontrolliert werden kann. Der SWA-Ansatz war auf Kontrollen der Gruppenmitgliedschaft beschränkt, während dieser Ansatz auch zusätzliche Kontrollen wie MFA und Zugriffsgenehmigungen anwenden kann.
Dieser Ansatz verfügt noch nicht über das Browser-Plugin zum automatischen Einfügen von Anmeldedaten, das der SWA-Ansatz bietet.
Verwendung automatisierter SaaS-Service-Accounts in Okta Privileged Access
Die zweite Option für die Nutzung von SaaS-Service-Accounts in Okta Privileged Access besteht darin, dass das Passwort für diese Accounts von Okta aus über die Okta Integration Network-Integration für die App verwaltet werden kann. Es basiert auf:
- Es verfügt über eine Integration, die SCIM unterstützt
- Diese Integration wurde darauf getestet, die Funktion zur Passwortrotation mit Okta Privileged Access zu unterstützen.
Die aktuelle Liste der SaaS-Apps, die diese automatische Verwaltung von Passwörtern unterstützen, finden Sie hier. Zum Zeitpunkt der Erstellung (Januar 2025) ist die einzige Social-Media-App in der Liste Workplace by Facebook (obwohl Sie Google Workspace und einige der anderen als Apps zur Verwaltung des Zugriffs auf soziale Medien betrachten könnten).
Der Mechanismus ist derselbe wie oben, außer dass das Passwort für den gemeinsam genutzten Account nach seiner Verwendung und in regelmäßigen Abständen rotiert (in Okta geändert und für die App bereitgestellt) wird. Auf diese Weise kennt nur Okta Privileged Access das Passwort. Die Nutzer:in lässt sich das Passwort anzeigen, um es zu kopieren und in die Login-Eingabeaufforderung der App einzufügen. Sobald das Passwort jedoch verwendet wurde, wird es ersetzt, sodass es keinen Sinn hat, es aufzuschreiben und weiterzugeben.
Da Okta Privileged Access das Passwort verwaltet und nach der Verwendung rotiert, kann es auch einen exklusiven Check-out nutzen, sodass jeweils nur ein:e Benutzer:in auf das Passwort zugreifen kann. Zusätzlich zur Beschränkung des Zugriffs auf den gemeinsam genutzten Account auf eine:n Benutzer:in bedeutet dies, dass jeder Audit-Trail eine:n individuelle:n Okta-Benutzer:in mit den Aktionen des gemeinsam genutzten Accounts verknüpfen kann.
Dies ist offensichtlich ein sichererer Ansatz als die beiden vorherigen, da es kein statisches Passwort gibt, das weitergegeben werden kann.
Verwendung eines Okta Shared Accounts in Okta Privileged Access für einen föderierten Shared Account
Der letzte Ansatz, der verwendet werden kann, besteht darin, dass der zur Verwaltung der Social-Media-Plattform verwendete Account ein föderierter Account ist (kein Passwort, für die sichere Verbindung mit dem Account wird föderiertes Single Sign-On verwendet), der gemeinsam genutzt wird. Es muss kein Passwort weitergegeben werden, aber der Zugriff auf den Account erfordert einen Identity-Anbieter wie Okta, um das Single Sign-On zu initiieren und die entsprechenden Token zu übergeben. Aber wie verwalten Sie den Zugriff auf diese Accounts in Okta?
Sie könnten in Okta eine:n dedizierte:n Benutzer:in haben, der oder die der Social-Media-App zugeordnet ist, und diese:r Benutzer:in ist als einzige:r Okta-Benutzer:in berechtigt, auf die App zuzugreifen. Die einzige Möglichkeit für Benutzer:innen, auf die Social-Media-App zuzugreifen, besteht darin, den Login bei Okta als diese:r spezielle Benutzer:in durchzuführen und auf die Kachel zu klicken. Aber stehen wir dann wieder vor dem Problem, ein gemeinsames Passwort zu haben, um auf den speziellen Okta-Benutzer-Account zuzugreifen? Das muss nicht sein.
Die neue Funktion für SaaS-Service-Accounts umfasst auch Okta-Accounts. Sie könnten die Okta-Social-Media-Benutzer:in und Okta Privileged Access wie oben beschrieben konfigurieren, sodass die Anmeldedaten für die Anmeldung bei Okta als diese Social-Media-Benutzer:in auf die gleiche Weise offengelegt werden, wie wir oben gesehen haben. Der:die Benutzer:in würde zu Okta Privileged Access navigieren, den speziellen Okta-Social-Media-Benutzer-Account anzeigen, die Anmeldedaten verwenden, um sich als diese:r Benutzer:in bei Okta anzumelden, auf die Social-Media-Kachel klicken und bei der App angemeldet werden. Wenn sie fertig sind, checken sie den Okta-Account ein und das Passwort wird rotiert.
Sie könnten theoretisch mehrere föderierte Social-Media-Accounts unter dem einen Okta-Account zusammenfassen und den Zugriff auf diese Weise verwalten.
Weitere Informationen zu diesem Mechanismus finden Sie unter Verwaltung und Nutzung von freigegebenen Okta-Accounts mit Okta Privileged Access.
Bei diesem Ansatz verwalten Sie nicht das Passwort des Social-Media-Accounts (da dieser föderiert ist und über keines verfügt), sondern das Passwort des Okta-Accounts, mit dem Sie sich per SSO bei diesem föderierten Social-Media-Account anmelden können.
Fazit
Es gibt eine Bandbreite an Ansätzen zur Verwaltung gemeinsam genutzter Social-Media-Accounts in Okta.
Auf der einen Seite haben wir den bestehenden Mechanismus der Secure Web Authentication (SWA), der es ermöglicht, dass ein gemeinsamer Benutzername und ein Passwort von Administrator:innen gespeichert und durch das Browser-Plugin in das App-Login eingefügt werden. Dies hat einige Sicherheitseinschränkungen.
Hinzu kommt die Nutzung der neuen Funktion für SaaS-Service-Accounts in Okta Privileged Access. Diese speichert Social-Media-Anmeldedaten im Vault und ermöglicht es autorisierten Nutzer:innen, diese mit entsprechenden Kontrollen auszuchecken, wie etwa der Anforderung einer Genehmigung durch eine:n Manager:in zu dem Zeitpunkt, an dem sie den Account nutzen müssen. Sofern die Integration die Passwortrotation unterstützt, verwaltet Okta Privileged Access das Passwort dieser Accounts.
Ein letzter Ansatz besteht darin, dass die Social-Media-Plattform föderierte Accounts unterstützt, Sie diese Accounts jedoch mit mehreren Benutzer:innen teilen möchten. In diesem Fall könnten Sie eine:n spezielle:n Okta-Benutzer:in für diese föderierten Accounts erstellen und die Funktion „Okta Service-Accounts“ von Okta Privileged Access nutzen, um diesen speziellen Okta-Benutzer:innen bei Bedarf mit den entsprechenden Kontrollen Zugriff zu gewähren.
Diese Optionen spiegeln verschiedene Sicherheitsaspekte wider, und der von Ihnen gewählte Ansatz hängt von der Social-Media-Plattform, deren Umgang mit geteilten Accounts und der Risikobereitschaft Ihrer Organisation ab. Auch wenn Sie einen Passwortmanager verwenden, können die neuen Funktionen von Okta Privileged Access für eine verbesserte Sicherheit und ein reduziertes Risiko von Nutzen sein.
