Im Endeffekt sollte man Dingen wie 2-Faktor-Authentifizierung deutlich mehr Beachtung schenken als diesem BSI-Modell. Klar, es trennt die Rechte und damit (hoffentlich) die Ebenen die eine Ransomware befällt, aber für sonderlich sicher halte ich es nicht, weil es mit der Zeit verwässert wird.
### Warum nicht 20-Tier-Modell? Das ganze Modell ist schön und gut, bis man sieht wie viel ein Domänenadmin macht. Damit muss man klarkommen, die IT ist ziemlich zentral. Was also tun? die drei Ebenen sind nicht fix, man kann sicherlich Rechte zwischen dem einen zu dem anderen schieben. Zum Beispiel die Exchange Management Shell, wenn man sie denn per Remote-Shell irgendwo aufmacht als Serveradmin deklarieren, während die Mailverwaltung im adminportal von Microsoft (die zurückgebliebenen nennen das noch Exchange Control Panel) noch Domänenadmin bleibt... Ist völlig frei. In meinen Augen. Problematisch wirds, wenn man das in noch mehr Accounts unterteilt, weil die menschliche Psyche dann wieder die gleichen Kennwörter verwendet und ich habe noch nie ein System gesehen, dass Passwörter zwischen den Benutzern vergleicht. Was also bei >3 Tier passieren wird, ist dass selbst admins gleiche Kennwörter setzen, was den ganzen Zweck von feiner unterteilten Rechten zunichte macht. Ich sehe das Modell also recht statisch als 3-Tier an. # ExecutionPolicy bei Domänenscripts Scheinbar hängen manche gerade an dem Bedarf die ExecutionPolicy für Scripts (z.B. Bitlocker Einführung etc) zu ändern. Genau dafür ist der Scope Process eigentlich da... Siehe [Chocolatey](https://chocolatey.org/install) ```Powershell Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1')) ``` Sprich: Die Powershell wird als Admin ausgeführt (was im Falle einer GPO ja auch so wäre), setzt die Policy im Scope Process und lädt ein Powershellscript aus dem Netz. Kein Heckmeck, mit Batchscripts die Policy setzen und danach andere Powershellscripts starten. Einfach direkt in der GPO Policy auf Scope Process anpassen und Script ausm SYSVOL starten... Scope Process bedeutet ja, dass sie für diese Shellsitzung gilt und fertig... Eigentlich nichts, woran man groß hängen müsste. Richtiger wäre es, die Scripts mit der Domänen-CA zu signieren, ist aber halt die Frage wie viel Zeit man da hereinstecken möchte und ob man als Dienstleister auf Zeit spielt, weil man die ja berechnen kann, oder nicht. # Azure Brainstorming Azure AD sei funktionsmäßig nicht gleichzusetzen mit OnPrem, auf genauere Nachfrage was genau die Einschränkungen wären gibt es aber kaum einen technischen Grund.Fragt man nach Beispielen gibt es keinen technischen Grund nicht Fullcloud gehen zu können. Scheitern tut es an veralteten Betriebsrats-Regularien, oder daran, dass die Geschäftsführung nicht gegen eingesparte Lohn-Zeitkosten gegenrechnet oder einen sehr hohen Wert auf Quick-Wins legt... Azure Transitionen sind ein kostenintensiver Slow-Win, was gehen die Schnelllebigkeit heutzutage geht. Das muss auch finanziell verstanden werden.
### 1:1 Transition immer teurer Azure und Microsoft Cloud sollte immer ein SaaS Umstieg bedeuten. 1:1 Transition von Rechenzentren ist möglich, resultiert aber in weit höheren Kosten, wegen dedizierten Ressourcen. Daher sollte Cloud Einstieg immer mit SaaS Umstieg einhergehen. ### Funktionseinschränkungen #### Thema Anonyme Relays Anonyme Relays (z. B. für Drucker) sind in Exchange Online nicht vorhanden. Alternative ist ein Cloud-Server mit aktivierter Mailfunktion. Wenn wir beim Thema Drucker bleiben, bedeutet Cloud Umstieg also ein lizenziertes Scan-Postfach, was aber im Umkehrschluss bedeutet, dass man Drucker braucht, die mehr als nur anonyme Anmeldungen können.