Kurzbericht mit Links

Und auf deutsch hört sich das schon etwas seltsam an, wenn wir bei Enrollment von Immatrikulation sprechen. Aber genau das ist damit gemeint. Denn zwischen zwei Unternehmen (Microsoft und dem eigenen Unternehmen) wird ein Vertrag geschlossen, das sogenannte Enterprise Agreement EA. Und für die meisten werden im EA die Konditionen für Software Lizenzen verhandelt, aber seit ein paar Jahren ist eine Software Lizenz ja oft auch ein Cloud Service. Demzufolge braucht es ein EA um im nächsten Schritt die "Immatrikulation" der Server, der Cloud-Services, ... vornehmen zu können.

Dieser an sich logische erste Schritt des Enrollments, der Immatrikulation hört sich einfach an und ist auch einfach, wenn Klarheit über wichtige Fragen besteht, z.B.:

  • soll die Gliederung der Unternehmung in Abteilungen und Konten (mit Subscriptions) nach funktionalen, regionalen Aspekten oder nach Verantwortungsbereichen oder gar nicht in Abteilungen/Regionen/... untergliedert werden?
  • braucht es für einige Bereiche absolute Unberührbarkeit - also maximale Sicherheit, die vielleicht einen eigfenen Tenant (siehe nächster Punkt) erzwingt?
  • braucht es eine laufende Budgetkontrolle - wenn ja, für welche Dienste mit welchen Limits und für wen?
  • ...

Mit anderen Worten: genauso wie zu Beginn des Studierens viele bürokratische Hürden bei der Immatrikulation gemeistert werden wollen, so ist dies auch beim Enrollment eines Tenants ... und es ist sicher nicht unüblich dass nach 1 oder 2 Semestern ein anderes Studium, ein besonderes Nebenfach dazu kommen soll oder abgestossen werden muss. Im Chat meinten die Moderatoren, dass das Umhängen von Subscriptions (also der untersten Ebene) bei einem Re-Design kein Problem sei. Das hört sich fast so an, als ob man die Scheine aus dem Chemiestudium in Heidelberg auch im Psychologie-Studium in Brighton anrechnen lassen kann. Schön wär´s - aber vielleicht klappt´s ja in Azure :-)

Und nach dem Enrollment muss ja auch gearbeitet werden - d.h. schon beim ersten Buchen eines Services wird der AAD Tenant erzeugt und für diesen Tenant braucht es sicher ein sicheres Sicherheitskonzept und auch hier gilt, dass es einfach umzusetzen ist, wenn die Antworten auf wichtige Fragen bereits existieren. Z.B.:

  • Welche Tenants gibt es aktuell und wie sollen/müssen diese weitergeführt werden?
  • Ist es möglich ein (1) AAD für alle zu verwenden um einen Single Sign On der Anwender:innen für alle Services, Applikationen, Verzeichnisse, Apps zu ermöglichen?
  • Ist es möglich jeder Person auch eine Identität im Tenant zuzuweisen?
    Häufig werden Personen mit mehreren Accounts versehen, weil sie normalerweise einfache User-Aufgaben erledigen, aber manchmal als Administrator:in tätig werden. Dazu könnte dann auch ein Privileged Identity Management PIM (nein, kein Personal Information Manager!) temporär nach besonderer Authorisierung für eine Admin-Aufgabe freischalten. Vorteil: ein Account per User, temporäre Admins und Auditierbarkeit!)
  • ...

Ganz neu war für mich in diesem Zusammenhang der Hinweis aus Sicherheitsgründen einen Breaking Glass-Account einzurichten. Dieser Account hat maximalen Zugriff, höchste Rechte, ein brutales Kennwort aber keines der sonstigen Sicherheitsfeatures wie MultiFactor Authentication MFA, Prüfung und Abwehr des Zugriffs bei "selstsamen" Zugriffsmuster (conditional access), kein PIM, .... ABER: sobald dieser User zugreift melden alle Systeme Alarm. Damit sollte ein unbeobachteter Zugriff mit diesem Breaking Glass Account sofort entdeckt werden. 

Details zu all diesem finden auf den Microsoft-Docs-Seiten.

Volles Lob für diese Serie bisher - wer heute noch einstiegen will einfach mal hier gucken oder gleich fürs nächste Mal anmelden!

Wolfram von Rotberg
14.1.21