10 Min. Lesezeit

Lernziele

Am Ende dieses Moduls werden Sie in der Lage sein:

  • Die drei Kontotypen unterscheiden und separate Berechtigungsrechte (was eine Gruppe tun darf) von Ressourcengrants (welche Ressourcen sie berühren darf) trennen.
  • Das Prinzip der geringsten Rechte auf einer Plattform anwenden, deren Zugriffsmodell implizit lesbar ist und keine Ablehnungsregel hat, wobei das Prinzip der geringsten Rechte einfach bedeutet, keine Rechte zu gewähren.
  • Erklären, warum Föderation nur Authentifizierung ist, ohne just-in-time-Bereitstellung und ohne Zuordnung von Identitätsanbieter zu Gruppe, und das manuelle Runbook für Joiner/Mover/Leaver entwerfen, das dies erzwingt.
  • Eine Gruppe erstellen, einen Ressourcengrant zuweisen und ein Mitglied im Data Center Designer hinzufügen, und ein API-Token ausstellen und zuweisen, das persönliche Anmeldedaten aus der Automatisierung heraus hält.

Einheit 2.2: Identität, RBAC und Föderation

Einführung

Die Zugriffskontrolle bei IONOS sieht nicht aus wie die Policy-Sprache IAM der US-Hyperscaler. Es gibt kein JSON-Richtliniendokument, keine explizite Ablehnung und keine feingranularen pro-Aktions-Bedingungen. Der Zugriff ist gruppenbasiert, wobei Berechtigungsrechte einer Gruppe zugewiesen und Ressourcen dieser Gruppe gewährt werden, und der Lesezugriff ist implizit, sobald eine Ressource gewährt wird. Dieses Modell ist einfacher, aber es erzwingt eine bestimmte Disziplin: das Prinzip der geringsten Rechte wird durch Nicht-Gewährung und nicht durch das Schreiben einer restriktiven Regel erreicht. Diese Einheit etabliert diese Disziplin, legt fest, wo die Federation tatsächlich endet, und endet mit dem Erstellen einer berechtigten Gruppe und eines berechtigten API-Tokens im Data Center Designer für FinCorp.

1. Kontotypen, Berechtigungsrechte und Ressourcengenehmigungen

Es existieren drei Kontotypen innerhalb eines Vertrags. Der Vertragsinhaber wird automatisch für den Erstregistrierenden erstellt, hat vollen Zugriff auf alle Ressourcen, kann Benutzer erstellen und löschen sowie die Administratorrolle zuweisen und ist der einzige, der die Vertragszahlungsmethode ändern kann; es gibt genau einen und er kann nicht widerrufen werden. Ein Administrator (unbegrenzt pro Vertrag) hat die gleiche Reichweite wie der Inhaber, außer für die Zahlungsmethode, kann die Administratorrolle anderen zuweisen und hat Zugriff auf alle vertraglich vereinbarten Ressourcen, ohne einer Gruppe anzugehören. Ein Benutzer ist der grundlegende Kontotyp: er hat keinen Zugriff, außer durch Gruppenmitgliedschaft und die den Gruppen zugewiesenen Rechte, und kann zu einem Administrator aufgewertet werden.

Für Benutzer wird der Zugriff aus zwei unabhängigen Schichten aufgebaut, und die Trennung dieser Schichten ist das Kernstück des Modells:

  • Berechtigungsrechte 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 Erstellen von Rechenzentren, Erstellen von Snapshots, Reservieren von IP-Blöcken, Erstellen von Internetzugriff, Verwenden von Object Storage, Erstellen von Sicherungseinheiten, Erstellen von Kubernetes-Clustern und Zugriff auf Aktivitätsprotokolle.
  • Ressourcengenehmigungen bestimmen, welche spezifischen Ressourcen eine Gruppe berühren darf, und werden aus den steuerbaren Ressourcentypen gezogen: Virtuelle Rechenzentren, Snapshots, Bilder, IP-Blöcke, Sicherungseinheiten und Kubernetes-Cluster. Jede Genehmigung trägt ein Autorisierungsniveau: Lesen (implizit, sobald eine Gruppe einer Ressource zugewiesen wird), Bearbeiten und Teilen.

Eine Gruppe mit dem Recht, Rechenzentren zu erstellen, aber ohne zugewiesenes Virtuelles Rechenzentrum, kann neue Rechenzentren erstellen, aber keine bestehenden sehen oder berühren; eine Gruppe, die ein bestimmtes Virtuelles Rechenzentrum mit Bearbeitungsrecht zugewiesen bekommt, aber das Recht, Rechenzentren zu erstellen, nicht hat, kann dieses eine Virtuelle Rechenzentrum bearbeiten, aber keine neuen erstellen. Die Berechtigung und die Genehmigung sind orthogonal, und ein Benutzer erhält die Schnittmenge beider über alle Gruppen, denen er angehört. Administratoren stehen außerhalb dieses Systems: da sie direkt auf alle Ressourcen zugreifen, benötigen sie keine Gruppenmitgliedschaft, was die Administratorrolle zu einer bewusst sparsamen Zuweisung macht, anstatt einer Bequemlichkeit.

2. Implizit-Lese-, Kein-Verwehr- und Least-Privilege-Prinzip durch nicht gewährte Berechtigungen

Die Plattform hat keine Verwehrregel. Sie können keine Richtlinie schreiben, die den Zugriff entzieht, sondern nur Berechtigungsrechte und Ressourcengewährungen hinzufügen. In Kombination mit implizit-Lese (das Zuweisen einer Ressource zu einer Gruppe gewährt automatisch Lesezugriff darauf) bedeutet dies, dass das Least-Privilege-Prinzip eine Funktion der Zurückhaltung bei der Gewährung von Berechtigungen ist und nicht einer korrigierenden Regel danach. Die Haltung des Least-Privilege-Prinzips ist daher: eng umrissene Gruppen erstellen, jeder Gruppe nur die Ressourcen gewähren, die sie tatsächlich benötigt, auf dem niedrigsten Level, das funktioniert (Lesezugriff bevorzugen gegenüber Bearbeitung und Teilen bewusst vorbehalten), und nie auf die Administrator-Rolle als Abkürzung zurückgreifen.

Da es keine Verwehr gibt, kann ein zu weit gefasster Zugriff nicht mit einer Ausnahme gepatcht werden, sondern muss entfernt und neu gefasst werden. Die operationale Disziplin, die daraus folgt, besteht darin, Gruppen um Rollen herum zu modellieren (eine Datenbank-Operations-Gruppe, eine Netzwerkgruppe, eine lesende Auditor-Gruppe) und die Menge der Ressourcen, die jeder Gruppe gewährt wird, so eng wie die Rolle es zulässt, zu halten. Für FinCorp unter BSI-Prüfung wird einer Auditor-Gruppe das Recht auf Zugriff auf das Aktivitätsprotokoll und Lesezugriff auf die relevanten virtuellen Rechenzentren (VDCs) gewährt und nichts mehr, so dass der Auditor überprüfen kann, ohne die Möglichkeit, die Infrastruktur zu ändern.

3. Föderation Ist Nur Authentifizierung

FinCorp betreibt bereits einen Unternehmens-Identitätsanbieter, daher besteht der Instinkt darin, eine Föderation zu erstellen und den IdP alles steuern zu lassen. Die Plattform unterstützt eine Föderation mit SAML 2.0 und OpenID Connect (OIDC)-Identitätsanbietern, aber ihr Umfang ist heute nur Authentifizierung. Dieser Satz hat drei harte Konsequenzen, die berücksichtigt werden müssen:

  • Keine just-in-time-Bereitstellung. Ein föderierter Login erstellt kein IONOS-Konto auf Abruf. Der Benutzer muss bereits als IONOS-Cloud-Benutzer existieren, bevor er sich über den IdP authentifizieren kann; die Kontoverknüpfung erfordert einen vorhandenen Benutzer.
  • Keine Zuordnung von Identitätsanbieter zu Gruppe. Der IdP bestimmt nicht die IONOS-Gruppenmitgliedschaft. Die Föderation authentifiziert die Person; sie weist jedoch keine Berechtigungen oder Ressourcengenehmigungen zu. Die Zuordnung von IdP-Ansprüchen zu IONOS-Gruppen ist auf der Roadmap, aber heute noch nicht verfügbar.
  • Authentifizierung, nicht Autorisierung. Die Föderation beantwortet die Frage "ist dies die richtige Person"; das Gruppen- und Genehmigungsmodell beantwortet jedoch immer noch die Frage "was dürfen sie tun", und dieses Modell wird innerhalb von IONOS verwaltet, unabhängig vom IdP.

Das Muster, das dies erzwingt, ist ein explizites, manuelles Runbook für Joiner/Mover/Leaver. Wenn jemand beitritt, erstellt ein Administrator den IONOS-Benutzer und weist die richtigen Gruppen zu, bevor der föderierte Login nützlich ist. Wenn jemand die Rolle wechselt (Mover), passt ein Administrator die Gruppenmitgliedschaft manuell an. Wenn jemand geht (Leaver), stoppt die Deaktivierung im IdP neue Anmeldungen, aber der IONOS-Benutzer und seine Genehmigungen müssen separat entfernt werden, da der IdP nie den Zugriff auf der IONOS-Seite besaß. Die Föderation als wenn sie Konten bereitstellte und außer Betrieb nahm, ist die gefährliche Fehlinterpretation; sie tut beides nicht. Das native Muster ist es, ein dokumentiertes Runbook zu pflegen und die IONOS-Benutzerliste gegen das HR-System in regelmäßigen Abständen zu überprüfen, da nichts sie automatisch abgleicht.

DCD Implementierung Schritt-für-Schritt

Sie erstellen eine FinCorp-Gruppe mit eingeschränktem Zugriff, gewähren ihr eine einzelne Ressource, fügen ein Mitglied hinzu und stellen dann ein eng umgrenztes API-Token aus. Nur Vertragsinhaber und Administratoren können Benutzer verwalten. Das Architekturziel ist eine Gruppe mit minimalem Zugriff, deren Zugriff genau den gewährten Ressourcen entspricht, plus ein Automatisierungs-Zertifikat, das nicht der persönliche Login eines Benutzers ist.

Ziel: Erstellen Sie eine Gruppe, gewähren Sie eine Ressourcen-Zuweisung, fügen Sie ein Mitglied hinzu; stellen Sie ein API-Token aus und grenzen Sie es ein.

Schritte (in der Data Center Designer):

  1. Öffnen Sie den Benutzer-Manager (Benutzer und Gruppen). Im Gruppen-Reiter wählen Sie Erstellen, geben Sie einen Gruppennamen ein (zum Beispiel fincorp-db-ops) und wählen Sie Erstellen, um zu bestätigen. Die Gruppe erscheint jetzt in der Gruppenliste mit keinen Rechten und noch keinen Ressourcen.
  2. Mit der ausgewählten Gruppe weisen Sie ihre Fähigkeitsrechte zu, indem Sie nur die Privilegien aktivieren, die die Rolle benötigt (zum Beispiel Erstellen von Kubernetes-Clustern oder Zugriff auf die Aktivitäts-Log für eine Auditor-Gruppe). Lassen Sie alle anderen Rechte deaktiviert; nicht aktiviert ist das Verneinen.
  3. Öffnen Sie den Ressourcen der Gruppe-Reiter, klicken Sie auf Zugriff gewähren und wählen Sie die spezifische Ressource (zum Beispiel die fincorp-prod-de-VDC) aus der Dropdown-Liste aus. Die Gewährung einer Ressource aktiviert implizit den Lesezugriff; erhöhen Sie ihn nur auf Bearbeiten, wenn die Rolle Änderungen erfordert.
  4. Öffnen Sie den Mitglieder-Reiter und fügen Sie den Benutzer aus der Benutzer hinzufügen-Dropdown-Liste hinzu. Der Benutzer erbt jetzt genau die Rechte und Gewährungen dieser Gruppe und nichts mehr. (Fügen Sie keine Administratoren zu Gruppen hinzu; sie haben bereits Zugriff auf alles.)
  5. Für die Automatisierung gehen Sie zu Menü > Verwaltung > Token Manager und generieren Sie ein Authentifizierungstoken. Wählen Sie eine TTL aus den zulässigen Werten (1 Stunde, 4 Stunden, 1 Tag, 7 Tage, 30 Tage, 60 Tage, 90 Tage, 180 Tage, 365 Tage) aus, indem Sie den kürzesten Wert wählen, der für die Aufgabe geeignet ist. Die Berechtigungen des Tokens sind die Berechtigungen des Benutzers, unter dem es generiert wird, also generieren Sie es unter einem speziell dafür erstellten Dienstbenutzer, der nur dieser eng umgrenzten Gruppe angehört, und nie unter einem persönlichen Admin-Konto.
  6. Kopieren Sie den Token-Wert sofort. Er wird genau einmal bei der Generierung angezeigt und kann später nicht wiederhergestellt werden; speichern Sie ihn in Ihrem Secrets-Manager, bevor Sie den Bildschirm verlassen.

Häufige Fehler:

  • Gewährung einer Ressource mit Bearbeitungsrecht, wenn der Lesezugriff ausreicht. Es gibt keine Verneinungsregel, um dies rückgängig zu machen; eine zu weit gefasste Gewährung muss entfernt und neu umgrenzt werden.
  • Ausstellen von API-Tokens unter einem persönlichen oder Admin-Konto. Das Token erbt den vollen Zugriff dieses Kontos; stellen Sie es unter einem speziell dafür erstellten, eng umgrenzten Dienstbenutzer aus.
  • Annahme, dass ein Token pausiert werden kann. Die Deaktivierung eines Tokens bedeutet die Löschung; die Löschung ist sofortig und dauerhaft, und der Wert kann nicht wiederhergestellt werden, also planen Sie die Rotation als Löschen und Neu-Ausstellen.
  • Erwartung, dass die Federation Benutzerkonten erstellt oder löscht. Sie authentifiziert nur; der Lebenszyklus von Joiner/Mover/Leaver ist ein manuelles IONOS-seitiges Runbook.
  • Behandlung der einmaligen Token-Anzeige als wiederherstellbar. Erfassen Sie es bei der Generierung; es gibt keine zweite Chance, es zu lesen.

Eine kurze Illustration der Credential-Grenze: das Skripten gegen das API verwendet das Token als Bearer-Credential und nie einen Benutzernamen und ein Passwort, und das ist genau der Grund, warum das Token nur den minimalen Umfang des Dienstbenutzers tragen darf.

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

Der architektonische Punkt liegt im Header: Das Token ist die Identität. Was auch immer der Dienstbenutzer tun kann, kann das Skript tun, weshalb die Einschränkung des Benutzers und nicht des Skripts die Kontrolle ist.

Zusammenfassung

Die Zugriffskontrolle von IONOS ist gruppenbasiert mit Capability-Rechten und Ressourcengrants, die getrennt gehalten werden, implizitem Lesen und keiner Verwehrregel, so dass das Prinzip der geringsten Rechte durch eine eng gefasste Vergabe erreicht wird, anstatt durch eine restriktive Richtlinie. Die Federation mit SAML oder OIDC ist nur Authentifizierung, ohne just-in-time-Bereitstellung und ohne IdP-zu-Gruppen-Zuordnung, was ein manuelles Joiner/Mover/Leaver-Runbook erzwingt. API-Tokens erben die Berechtigungen des ausgebenden Benutzers und werden nur einmal angezeigt, so dass sie zu den benannten Dienstbenutzern gehören und durch Löschen und Neuausgabe rotiert werden.

Wichtige Punkte:

  • Drei Kontotypen: ein nicht widerrufbarer Vertragsinhaber, unbegrenzte Administratoren (vollständiger Zugriff minus Zahlungsmethode, keine Gruppe erforderlich) und Benutzer, die nur über Gruppen Zugriff erhalten.
  • Capability-Rechte (was eine Gruppe tun darf) und Ressourcengrants (welche Ressourcen, auf Lesen/Bearbeiten/Teilen) sind orthogonal; ein Benutzer erhält die Schnittmenge über seine Gruppen.
  • Es gibt keine Verwehrregel und Lesen ist implizit, so dass das Prinzip der geringsten Rechte bedeutet, nicht zu vergeben; eine zu weit gefasste Vergabe wird entfernt und neu gefasst, nicht gepatcht.
  • Federation ist nur Authentifizierung: der Benutzer muss bereits existieren (keine JIT), der IdP ordnet nicht zu Gruppen zu, und Joiner/Mover/Leaver ist ein manuelles Runbook.
  • API-Tokens erben die Berechtigungen des ausgebenden Benutzers, erlauben bis zu 100 pro Benutzer, werden nur einmal angezeigt und sind nicht wiederherstellbar, und werden gelöscht (nicht deaktiviert), um zu widerrufen; sie werden unter benannten Dienstbenutzern ausgegeben.

Wichtige Begriffe:

  • Capability-Recht: Ein vertragsweites Gruppenprivileg, das regelt, welche Art von Aktionen Mitglieder ausführen dürfen (zum Beispiel Erstellen von Kubernetes-Clustern).
  • Ressourcengrant: Eine Zuordnung einer bestimmten Ressource zu einer Gruppe auf Lesen-, Bearbeiten- oder Teilebene; die Vergabe ermöglicht implizites Lesen.
  • Federation: SAML 2.0 / OIDC-Authentifizierungsvertrauen; es verifiziert nur die Identität und bereitstellt keine Konten oder ordnet keine Gruppen zu.
  • API-Token: Ein Bearer-Zeichen, das die Berechtigungen des ausgebenden Benutzers erbt, wird nur einmal bei der Generierung angezeigt und durch Löschung widerrufen.