10 Min. Lesezeit

Lernziele

Am Ende dieses Moduls werden Sie in der Lage sein:

  • Die drei Kontotypen unterscheiden und die Berechtigungen (was eine Gruppe tun darf) von den Ressourcenfreigaben (welche Ressourcen sie berühren darf) trennen.
  • Das Prinzip der geringsten Berechtigung auf einer Plattform anwenden, deren Zugriffsmodell implizites Lesen vorsieht und keine Verweigerungsregel kennt, wobei geringste Berechtigung schlicht bedeutet, keine Berechtigungen zu erteilen.
  • Erklären, warum Federation nur die Authentifizierung umfasst, ohne just-in-time-Versorgung und ohne Zuordnung von Identitätsanbietern zu Gruppen, und das daraus resultierende manuelle Joiner/Mover/Leaver-Handbuch entwerfen.
  • In der Data Center Designer eine Gruppe erstellen, eine Ressourcenfreigabe eingrenzen und ein Mitglied hinzufügen sowie ein API-Token ausgeben und eingrenzen, das persönliche Zugangsdaten aus der Automatisierung heraushält.

Einheit 2.2: Identität, RBAC und Federation

Einführung

Die Zugriffskontrolle in IONOS CLOUD unterscheidet sich von der IAM-Policy-Sprache der US-amerikanischen Hyperscaler. Es gibt kein JSON-Policy-Dokument, keinen expliziten Deny und keine feingranularen Bedingungen pro Aktion. Der Zugriff ist gruppenbasiert: Berechtigungen werden einer Gruppe zugewiesen und Ressourcen derselben Gruppe gewährt. Lesezugriff ist implizit vorhanden, sobald eine Ressource zugewiesen wird. Dieses Modell ist einfacher, erfordert jedoch eine bestimmte Disziplin: Least Privilege wird erreicht, indem man nichts zugewährt, nicht indem man eine restriktive Regel formuliert. Diese Einheit etabliert diese Disziplin, legt darlegen, wo Federation tatsächlich endet, und schließt mit dem Aufbau einer bereichseingeschränkten Gruppe und eines bereichseingeschränkten API-Tokens im Data Center Designer für FinCorp.

1. Kontotypen, Berechtigungen und Ressourcenfreigaben

Innerhalb eines Vertrags existieren drei Kontotypen. Der Vertragsinhaber wird automatisch für die Person erstellt, die sich zuerst registriert hat, verfügt über vollen Zugriff auf alle Ressourcen, kann Benutzer erstellen und löschen sowie die Rolle Administrator zuweisen, und ist das einzige Konto, das die Zahlungsmethode des Vertrags ändern kann; es gibt genau einen solchen Inhaber, und diese Rolle kann nicht entzogen werden. Ein Administrator (unbegrenzte Anzahl pro Vertrag) hat dieselben Befugnisse wie der Inhaber, mit Ausnahme der Zahlungsmethode, kann die Rolle Administrator anderen zuweisen und greift auf alle vertraglich vereinbarten Ressourcen zu, ohne Mitglied einer Gruppe sein zu müssen. Ein Benutzer ist der grundlegende Kontotyp: Er hat keinerlei Zugriff, außer über die Gruppenmitgliedschaft und die diesen Gruppen zugewiesenen Berechtigungen, und kann zum Administrator hochgestuft werden.

Für Benutzer wird der Zugriff aus zwei unabhängigen Ebenen aufgebaut, und die klare Trennung dieser Ebenen ist der Kern des Modells:

  • Berechtigungen sind vertragsweite Fähigkeiten, die einer Gruppe zugewiesen werden und regeln, welche Art von Aktionen ihre Mitglieder ausführen dürfen. Die zuweisbaren Gruppenrechte umfassen: Rechenzentren erstellen, Snapshots erstellen, IP-Blöcke reservieren, Internetzugang erstellen, Object Storage nutzen, Sicherungseinheiten erstellen, Kubernetes-Cluster erstellen und Zugriff auf Aktivitätsprotokoll.
  • Ressourcenfreigaben legen fest, welche konkreten Ressourcen eine Gruppe berühren darf, ausgewählt aus den steuerbaren Ressourcentypen: Virtuelle Rechenzentren, Snapshots, Images, IP-Blöcke, Sicherungseinheiten und Kubernetes-Cluster. Jede Freigabe umfasst eine Autorisierungsebene: Lesezugriff (implizit ab dem Moment, in dem einer Gruppe eine Ressource zugewiesen wird), Bearbeitung und Freigabe.

Eine Gruppe mit dem Recht „Rechenzentren erstellen“, der jedoch kein VDC freigegeben wurde, kann neue Rechenzentren erstellen, sieht und berührt jedoch keine bestehenden. Eine Gruppe, der ein bestimmtes VDC auf der Ebene „Bearbeitung“ freigegeben wurde, die aber über das Recht „Rechenzentren erstellen“ nicht verfügt, kann dieses eine VDC ändern, aber keine neuen erstellen. Die Berechtigung und die Freigabe sind orthogonal, und ein Benutzer erhält den Durchschnittsbereich beider Ebenen über alle Gruppen, denen er angehört. Administratoren stehen vollständig außerhalb dieses Systems: Da sie direkt auf alle Ressourcen zugreifen, benötigen sie keine Gruppenmitgliedschaft, was die Rolle Administrator zu einer bewusst knappen Zuweisung macht, nicht zu einer Bequemlichkeit.

2. Implizites Lesen, kein Verweigern und geringste Berechtigungen durch Nicht-Vergabe

Die Plattform verfügt über keine Verweigerungsregel. Es ist nicht möglich, eine Richtlinie zu erstellen, die Zugriffsrechte abzieht; es können lediglich Funktionsrechte und Ressourcenberechtigungen hinzugefügt werden. Zusammen mit dem impliziten Lesen (der Zuweisung einer Ressource zu einer Gruppe wird automatisch die Leseberechtigung für diese Ressource erteilt) bedeutet dies, dass das Prinzip der geringsten Berechtigungen eine Frage der Zurückhaltung bei der Vergabe ist, nicht aber einer nachträglichen Korrekturregel. Die Haltung der geringsten Berechtigungen lautet daher: Erstellen Sie eng umrissene Gruppen, erteilen Sie jeder Gruppe nur die Ressourcen, die sie tatsächlich auf der niedrigsten funktionierenden Ebene benötigt (bevorzugen Sie Lesen gegenüber Bearbeiten und halten Sie Freigaben bewusst zurück), und verlassen Sie sich niemals auf die Administrator-Rolle als Abkürzung.

Da es keine Verweigerung gibt, kann eine zu weit gefasste Berechtigung nicht durch eine Ausnahme behoben werden; sie muss entfernt und neu umrissen werden. Die daraus folgende operative Disziplin besteht darin, Gruppen um Rollen herum zu modellieren (eine Datenbank-Betriebsgruppe, eine Netzwerkgruppe, eine rein lesende Prüfergruppe) und den Satz der jeder Gruppe erteilten Ressourcen so eng wie möglich zu halten, es sei denn, die Rolle erfordert mehr. Für FinCorp unter BSI-Prüfung wird einer Prüfergruppe das Recht auf das Aktivitätsprotokoll des Zugriffs sowie Leseberechtigungen für die relevanten VDCs erteilt und nichts darüber hinaus, damit der Prüfer ohne jegliche Möglichkeit, Infrastruktur zu ändern, prüfen kann.

3. Federation ist nur Authentifizierung

FinCorp betreibt bereits einen unternehmensweiten Identity Provider, daher liegt es nahe, Federation einzusetzen und den IdP für alles verantwortlich zu machen. Die Plattform unterstützt Federation mit SAML 2.0 und OpenID Connect (OIDC) Identity Providern, doch ihr aktueller Umfang beschränkt sich auf die Authentifizierung. Dieser Satz hat drei harte Konsequenzen, die bei der Planung berücksichtigt werden müssen:

  • Kein Just-in-Time-Provisioning. Ein federierter Login erstellt kein IONOS CLOUD-Konto auf dem Weg. Der Benutzer muss bereits als IONOS CLOUD-Benutzer existieren, bevor er sich über den IdP authentifizieren kann; die Kontozuordnung erfordert einen vorhandenen Benutzer.
  • Keine Zuordnung von Identity-Providern zu Gruppen. Der IdP steuert die Gruppenmitgliedschaft in IONOS CLOUD nicht. Federation authentifiziert die Person; sie weist keine Berechtigungen oder Ressourcenfreigaben zu. Die Abbildung von IdP-Claims auf IONOS CLOUD-Gruppen ist im Roadmap, aber derzeit nicht verfügbar.
  • Authentifizierung, nicht Autorisierung. Federation beantwortet die Frage „Ist dies die richtige Person“; das Modell aus Gruppen und Berechtigungen beantwortet weiterhin die Frage „Was darf diese Person tun“, und dieses Modell wird unabhängig vom IdP innerhalb von IONOS CLOUD verwaltet.

Das daraus resultierende Muster ist ein expliziter, manuell durchgeführter Runbook-Prozess für Neueintritte, Rollenwechsel und Austritte. Wenn jemand eintritt, erstellt ein Administrator den IONOS CLOUD-Benutzer und weist die richtigen Gruppen zu, bevor der federierte Login nützlich ist. Wenn jemand die Rolle wechselt (Mover), passt ein Administrator die Gruppenmitgliedschaft manuell an. Wenn jemand austritt (Leaver), verhindert das Deaktivieren im IdP neue Logins, aber der IONOS CLOUD-Benutzer und seine Berechtigungen müssen separat entfernt werden, da der IdP nie die Zugriffsseite auf der IONOS CLOUD-Seite verwaltet hat. Federation so zu behandeln, als würde sie Konten provisionieren und deprovisionieren, ist die gefährliche Fehlinterpretation; sie tut beides nicht. Das native Muster besteht darin, ein dokumentiertes Runbook zu führen und die IONOS CLOUD-Benutzerliste regelmäßig mit dem HR-System abzugleichen, da nichts diese automatisch synchronisiert.

Implementierungsanleitung für DCD

Sie erstellen eine auf FinCorp beschränkte Gruppe, weisen ihr eine einzelne Ressource zu, fügen ein Mitglied hinzu und stellen anschließend ein eng begrenztes API-Token aus. Nur Vertragsinhaber und Administratoren können Benutzer verwalten. Das architektonische Ziel ist eine Gruppe mit dem geringstmöglichen Berechtigungsgrad, deren Zugriff genau den zugewiesenen Ressourcen entspricht, sowie ein Automatisierungszertifikat, das sich nicht mit dem persönlichen Login einer Person verwechselt.

Ziel der Erstellung: Eine Gruppe erstellen, eine Ressourcenzuweisung beschränken, ein Mitglied hinzufügen; ein API-Token ausstellen und beschränken.

Schritte (im Data Center Designer):

  1. Öffnen Sie den User Manager (Benutzer und Gruppen). Wählen Sie im Tab Gruppen die Option Erstellen aus, geben Sie einen Gruppennamen ein (zum Beispiel fincorp-db-ops) und bestätigen Sie mit Erstellen. Die Gruppe erscheint nun in der Gruppenliste, verfügt jedoch noch über keine Rechte und keine Ressourcen.
  2. Weisen Sie der ausgewählten Gruppe ihre Fähigkeitsrechte zu, indem Sie nur die Berechtigungen aktivieren, die die Rolle benötigt (zum Beispiel „Kubernetes-Cluster erstellen“ oder „Zugriff auf Aktivitätsprotokoll“ für eine Auditorengruppe). Alle anderen Rechte bleiben deaktiviert; ein nicht angehaktes Feld bedeutet Verweigerung.
  3. Öffnen Sie den Tab Ressourcen der Gruppe, klicken Sie auf Zugriff gewähren und wählen Sie die spezifische Ressource (zum Beispiel das fincorp-prod-de VDC) aus dem Dropdown-Menü aus. Die Zuweisung einer Ressource aktiviert implizit die Leseberechtigung; erhöhen Sie diese nur dann auf „Bearbeiten“, wenn die Rolle Änderungen erfordert.
  4. Öffnen Sie den Tab Mitglieder und fügen Sie den Benutzer über das Dropdown-Menü Benutzer hinzufügen hinzu. Der Benutzer erbt nun genau die Rechte und Zuweisungen dieser Gruppe, und nichts darüber hinaus. (Fügen Sie Administratoren nicht zu Gruppen hinzu; sie haben bereits Zugriff auf alles.)
  5. Für die Automatisierung navigieren Sie zu Menü > Verwaltung > Token Manager und generieren Sie ein Authentifizierungstoken. Wählen Sie eine TTL aus den erlaubten Werten (1 Stunde, 4 Stunden, 1 Tag, 7 Tage, 30 Tage, 60 Tage, 90 Tage, 180 Tage, 365 Tage) und wählen Sie den kürzesten Wert, der für die Aufgabe ausreicht. Die Berechtigungen des Tokens entsprechen den Berechtigungen des Benutzers, unter dem es generiert wird. Generieren Sie es daher unter einem eigens dafür erstellten Service-Benutzer, der nur der eng beschränkten Gruppe angehört, niemals unter einem persönlichen Admin-Account.
  6. Kopieren Sie den Token-Wert sofort. Er wird genau einmal bei der Generierung angezeigt und ist danach nicht wiederherstellbar; speichern Sie ihn in Ihrem Secrets-Manager, bevor Sie den Bildschirm verlassen.

Häufige Fehler:

  • Zuweisung einer Ressource mit „Bearbeiten“, obwohl „Lesen“ ausreicht. Es gibt keine Verweigerungsregel, mit der man dies rückgängig machen kann; eine zu weit gefasste Zuweisung muss entfernt und neu beschränkt werden.
  • Ausgabe von API-Tokens unter einem persönlichen oder Admin-Account. Das Token erbt die volle Reichweite dieses Accounts; stellen Sie es stattdessen unter einem dedizierten, eng beschränkten Service-Benutzer aus.
  • Annahme, dass ein Token pausiert werden kann. Die Deaktivierung eines Tokens bedeutet dessen Löschung; die Löschung ist sofort und endgültig, und der Wert kann nicht wiederhergestellt werden. Planen Sie die Rotation daher als „Löschen und neu ausstellen“.
  • Erwartung, dass Federation Accounts erstellt oder entfernt. Sie authentifiziert nur; der Lebenszyklus für Beitritt, Wechsel und Austritt ist ein manuelles Runbook auf der IONOS CLOUD-Seite.
  • Behandlung der einmaligen Token-Anzeige als wiederherstellbar. Erfassen Sie den Wert bei der Generierung; es gibt keine zweite Chance, ihn zu lesen.

Eine kurze Veranschaulichung der Zertifikatsgrenze: Skripte, die gegen die API ausgeführt werden, verwenden das Token als Bearer-Credential, niemals Benutzername und Passwort. Genau deshalb muss das Token nur den minimalen Bereich des Service-Benutzers tragen.

curl --location \
  --request GET 'https://api.ionos.com/cloudapi/v6/datacenters' \
  --header 'Authorization: Bearer <SERVICE_USER_TOKEN>'

Der architektonische Kernpunkt steht im Header: Das Token ist die Identität. Alles, was der Servicebenutzer ausführen kann, kann auch das Skript ausführen. Aus diesem Grund ist die Beschränkung des Benutzers, nicht des Skripts, die entscheidende Steuerungsmöglichkeit.

Zusammenfassung

Die Zugriffskontrolle in IONOS CLOUD ist gruppenbasiert. Berechtigungen (Capability Rights) und Ressourcenfreigaben (Resource Grants) werden getrennt verwaltet. Lesezugriff ist implizit vorhanden, und es gibt keine Verweigerungsregel (Deny Rule). Das Prinzip der geringsten Berechtigung (Least Privilege) wird daher durch gezielte, eng umrissene Berechtigungen erreicht, nicht durch das Erstellen restriktiver Richtlinien. Federation mit SAML oder OIDC dient ausschließlich der Authentifizierung. Es gibt kein Just-in-Time-Provisioning und keine Zuordnung von IdP zu Gruppen. Dadurch ist ein manuelles Runbook für Prozesse bei Eintritt, Wechsel und Austritt von Mitarbeitenden (Joiner/Mover/Leaver) erforderlich. API-Tokens erben die Berechtigungen des ausstellenden Benutzers und werden nur einmal angezeigt. Sie gehören daher zu Service-Benutzern mit engem Geltungsbereich und werden durch Löschen und erneutes Ausstellen rotiert.

Wichtige Punkte:

  • Drei Kontotypen: ein nicht widerrufbarer Vertragsinhaber, eine unbegrenzte Anzahl von Administratoren (volle Zugriffsberechtigungen, jedoch ohne Zugriff auf die Zahlungsmethode; keine Gruppe erforderlich) und Benutzer, die Zugriff ausschließlich über Gruppen erhalten.
  • Berechtigungen (Capability Rights, was eine Gruppe tun darf) und Ressourcenfreigaben (welche Ressourcen, auf der Ebene Lesen/Bearbeiten/Freigeben) sind voneinander unabhängig. Ein Benutzer erhält die Schnittmenge über all seine Gruppen hinweg.
  • Es gibt keine Verweigerungsregel und der Lesezugriff ist implizit. Das Prinzip der geringsten Berechtigung bedeutet daher, keine Berechtigungen zu erteilen. Eine zu weit gefasste Berechtigung wird entfernt und neu eingegrenzt, nicht nachträglich angepasst.
  • Federation dient nur der Authentifizierung: Der Benutzer muss bereits existieren (kein JIT), das IdP wird nicht mit Gruppen abgeglichen, und Joiner/Mover/Leaver ist ein manuelles Runbook.
  • API-Tokens erben die Berechtigungen des ausstellenden Benutzers, es sind bis zu 100 pro Benutzer erlaubt, sie werden einmalig angezeigt und sind nicht wiederherstellbar. Zur Widerrufung werden sie gelöscht (nicht deaktiviert). Sie sollten unter Service-Benutzern mit engem Geltungsbereich ausgestellt werden.

Wichtige Begriffe:

  • Capability Right (Berechtigung): Eine gruppenweite Berechtigung auf Vertragsebene, die regelt, welche Art von Aktionen Mitglieder ausführen dürfen (zum Beispiel Erstellen von Kubernetes Clustern).
  • Resource Grant (Ressourcenfreigabe): Eine Zuweisung einer bestimmten Ressource an eine Gruppe auf der Ebene Lesen, Bearbeiten oder Freigeben. Die Erteilung einer Berechtigung aktiviert den Lesezugriff implizit.
  • Federation: SAML 2.0 / OIDC-Authentifizierungsvertrauensstellung. Sie verifiziert nur die Identität und provisioniert keine Konten oder weist keine Gruppen zu.
  • API-Token: Eine Bearer-Credential, die die Berechtigungen des ausstellenden Benutzers erbt, bei der Generierung einmalig angezeigt wird und durch Löschung widerrufen wird.