Wissensprüfung - Governance, Identität und Kosten
FinCorp möchte seine Nicht-Produktionsumgebung von der Produktionsumgebung trennen, rein damit jede als eigene Zeile auf der monatlichen Rechnung erscheint, während ein gemeinsamer Bereich für Governance und Auditierung beibehalten wird. Der Architekt wird gefragt, ob hierfür ein zweiter Vertrag erforderlich ist. Was ist die richtige Empfehlung?
Ein VDC ist das Segmentierungselement für Region und Umgebung innerhalb eines Vertrags, und jeder VDC erzeugt bereits einen eigenen Abschnitt auf der monatlichen Rechnung. Sichtbarkeit der Kosten allein rechtfertigt daher keinen zweiten Vertrag, der die Grenze für kommerzielle Belange, Governance und Auditierung darstellt. Ein neuer Vertrag ist nur gerechtfertigt für Compliance-Isolation, einen anderen Eigentümer oder eine andere Rechtsperson oder einen separaten Auditierungsbereich.
Ein Architekt weist den ersten regulierten VDC von FinCorp einer deutschen Region zu und stellt später fest, dass eine andere deutsche Region vorzuziehen gewesen wäre. Wie sieht die Realität einer Änderung aus?
Die Region eines VDC wird bei der Erstellung festgelegt. Reservierte IPv4-Blöcke sind nur in der Region nutzbar, in der sie reserviert wurden, und Images sowie Snapshots sind regionsspezifisch, ohne eine verwaltete Replikation über Regionen hinweg. Da diese an die Region gebundenen Attribute den VDC nicht an einen anderen Ort begleiten können, ist die Region (und der Name) eine Einweg-Entscheidung, weshalb die Platzierung bewusst und nur einmal festgelegt wird.
Ein Auditor von FinCorp muss Aktivitäten überprüfen, darf aber keine Infrastrukturänderungen vornehmen. Die Plattform verfügt über keine Verweigerungsregel. Wie sollte der Architekt diesen Zugriff gewähren?
Der Zugriff ist gruppenbasiert, wobei Fähigkeitsrechte und Ressourcenberechtigungen getrennt gehalten werden. Wenn eine Ressource zugewiesen wird, ist der Lesezugriff implizit enthalten. Eine Verweigerungsregel existiert nicht. Das Prinzip der geringsten Berechtigung wird daher erreicht, indem nur das zugewiesen wird, was die Rolle benötigt: die Fähigkeit „Access Activity Log“ und Ressourcenberechtigungen auf Leseebene. Eine zu weit gefasste Berechtigung kann nicht durch eine Ausnahme korrigiert werden, da keine Verweigerungsregel vorhanden ist. Sie müsste entfernt und neu abgegrenzt werden.
FinCorp betreibt einen unternehmensweiten Identitätsanbieter und möchte den Zugriff auf IONOS CLOUD federieren, sodass neue Mitarbeitende beim ersten Login automatisch erstellt und Gruppen zugewiesen werden. Was muss die Architektin oder der Architekt dem Team mitteilen?
Die Föderation in IONOS CLOUD unterstützt SAML 2.0 und OIDC, ihr Umfang ist jedoch derzeit auf die Authentifizierung beschränkt. Es gibt keine just-in-time-Provisionierung (der Nutzer muss vorab vorhanden sein), und der IdP steuert die Gruppenmitgliedschaft in IONOS CLOUD nicht (die Zugriffsabbildung ist auf der Roadmap, aber nicht verfügbar). Die Föderation verifiziert die Person; das Modell aus Gruppen und Berechtigungen regelt weiterhin, was sie tun darf. Daher ist der Lebenszyklus ein explizites manuelles Runbook.
FinCorp wird einen stabilen Baseline-Betrieb mit dedizierten Kernen für mindestens drei Jahre durchführen, erwartet jedoch gelegentliche Lastspitzen, die deutlich darüber liegen. Der Architekt dimensioniert einen Savings Plan. Welcher Ansatz ist korrekt?
Ein Savings Plan ist eine ressourcenbasierte Commitment-Verpflichtung mit einem Rabatt von 15 % für 1 Jahr und 40 % für 3 Jahre auf dedizierte Kerne und RAM. Nutzung über der commitierten Menge wird zum regulären PAYG-Tarif abgerechnet (Überschreitung wird nicht abgelehnt), und der Plan kann nach der Aktivierung weder bearbeitet noch storniert werden. Die sichere Vorgehensweise besteht darin, nur den Mindestbedarf zu commiten, dessen Laufzeit über den gesamten Vertragszeitraum sicher ist, und variable Lastspitzen dem flexiblen PAYG-Tarif zu überlassen, anstatt optimistische Spitzenausgaben zu fixieren, die später nicht reduziert werden können.