Der erste Teil der dreiteiligen Blogserie widmete sich einem Ansatz zur Findung der eigenen Cloudmaturität im Vergleich zu anderen Firmen. Der zweite Teil beinhaltet Tipps zur Verbesserung des Durchlaufen der Transformation.

 

Teil 1 – Wie «matur» bin ich?

Teil 2 – Welche Schritte müssen für die Transformation durchlaufen werden?

Teil 3 – Wie kann ich meine Cloudtransformation retten?

 

Dieser dritte Teil widmet sich der Rettung im Orbit verlorener Transformationen und möglichen Rettungsansätzen.
Ich wurde bei allen drei Teilen von Hammy tatkräftig mit Tipps und Ideen unterstützt. Teamwork halt, wie das bei uns üblich ist!


Inhaltsverzeichnis


Sie sind auf dem Weg in der Cloud und es nimmt kein Ende?

Einige Punkte aus Teil 2 sind Voraussetzung für das Gelingen – haben Sie alle diese Punkte berücksichtigt? Wenn nicht, kann schon das erneute Durchlesen des Teils 2 zu einem möglichen Lösungsansatz führen! Haben Sie überhaupt einen aussagekräftigen PoC gemacht?

Viele der folgenden Aussagen kommen aus Projekten mit der SaaS-Lösung, welche wir verkaufen. Ein grosser Teil davon kann auch auf andere Projekte übertragen werden.


Weg mit falschen Preisversprechungen

Bereiten Sie sich gut vor. Hinterfragen Sie Aussagen über den geringeren Preis. Der Preis während der Transformation wird höher – eventuell doppelt so hoch, da die alte und neue Infrastruktur zu betreiben ist. Wenn die Transformation zu lange dauert, kann das richtig ins Geld gehen. Lassen Sie die Bremser bei den Silos, was günstiger wird, als wenn Sie gezwungen werden und sich querstellen.


Vertrauen

Sie brauchen Vertrauen in den Partner, der Sie unterstützt.


Proof of Concept

Machen Sie unbedingt einen PoC vorgängig. Nehmen Sie sich die Zeit, die es braucht, um eine qualifizierte Aussage über die Dauer und den Aufwand des Projekts zu machen. Besprechen Sie die Resultate und definieren Sie die Strategie. Ihr Partner unterstützt Sie dabei.


Mögliche Kopfschmerzen und Lösungsansätze

Alles 1:1 in die Cloud verschieben

Macht es wirklich Sinn, das bestehende, in die Jahre gekommene Konzept einfach 1:1 in die Cloud verschieben zu wollen?

    1. Hinterfragen Sie Ihr aktuelles Ruleset – ist es cloudfähig?
    2. Oder die ganze Umgebung einfach in IaaS oder PaaS zu zügeln?
    3. Nehmen Sie die Transformation zum Anlass, Altes zu überdenken und zu vereinfachen oder gar andere, einfachere Lösungansätze zu suchen.

Übersicht verloren, nichts klappt mehr

Alles wurde in einem Big Bang ohne Tests von möglichst allen involvierten Applikationen ausgerollt. Man wollte alles auf einmal haben. Die Umgebung ist einfach zu komplex. Was ist nun zu tun?

 

    1. Den Partner kontaktieren, welcher bei der sinnvollen Stückelung der Aufgaben und Wünsche unterstützt. Aufbrechen in kleine Subprojekte – also Babysteps machen.
    2. Fallback Strategie anwenden: Einen Schritt zurück und die meisten User/Server-Systeme auf den alten Setup zurückstellen. Im Notfall einen Restore des alten Setups/Systems machen.
    3. Reduzieren auf wenige Test-User/Server auf den unterschiedlichen Lokationen.
    4. Wie in einem PoC nochmals alles in Ruhe vollständig testen und für die Probleme Lösungen suchen.
    5. Erst dann, wenn die Funktionalität 80% oder besser wird, wieder produktiv schalten.
    6. Die Produktivschaltung in kleinen phasenweisen Rollouts vornehmen, also Lokation um Lokation.

Unzuverlässige Anbindung an den Cloudproxy von Zscaler

Situation

Es treten immer wieder Zugriffsprobleme über den Cloudproxy auf. Teilweise ist der Zugriff instabil oder fällt aus. Der Traffic wird nicht immer wie gewünscht geblockt oder durchgelassen. Die User sind unzufrieden!

 

Problem / Challenge

Keine Tunnel eingesetzt oder gar die Best-Practice-Empfehlungen nicht befolgt.

Falsches Forwarding gewählt, welches wenig Toleranz oder keinen automatischen Failover erlaubt. Viele Applikationen, welche nicht proxyfähig sind. Zu aufwändiges Ruleset gewählt und möglichst alle Wünsche abbilden wollen. Zu aufwändige Aussenstellenanbindung mit komplexem Setup.

Lösungsansatz Forwarding

Die Best Practice Empfehlung ist GRE, PAC-File, ZAPP.

  1. IPsec eingesetzt statt GRE

    a. GRE bietet mehr als das Doppelte der Bandbreite pro Tunnel. Man spart public IPs und Konfigurationsaufwand.

    b. Ein Failover kann mit GRE einfacher aufgesetzt werden.

  2. Das Verhalten des Clients mit dem PAC-File ist unerwartet.

    a. Das PAC-File ist zu komplex und muss vereinfacht werden.

    i. Zusammenfassen und vereinfachen; klar strukturieren.

    ii. Alles mit DNS-Abfragen entfernen.

    iii. Variablen defineren, damit Abfragen nur einmal gemacht werden müssen.

    iv. Pactester zur Überprüfung verwenden.

  3. Der Einsatz der ZAPP könnte folgende Probleme lösen:

    a. Authentication-Issues,

    b. O365-Probleme,

    c. Applikationen sind nicht proxyfähig.

  4. Planen Sie, den Outbound-Firewall in kleinen Aussenstellen in die Cloud zu verschieben. Ein einfacher Router reicht als Perimeterschutz. Die ZAPP und der NGFW reichen.

Lösungsansatz Policyruleset

Wenn die Policy zu komplex ist, kann dies zu unerwartetem Verhalten führen. Das Troubleshooting braucht viel mehr Zeit und Lösungen sind nicht immer garantiert.

1. Reduce to the Max. Möglichst wenige Rules definieren.

a. Blocken, was unerwünscht ist.

b. Max. fünf Gruppen.

c. Nur dort eigene Rules, wo es die Governance verlangt.

d. Offene Policy, dafür möglichst alles SSL-intercepten.


Und zum Schluss noch ein Hinweis zum Thema Mail in der Cloud.

Probleme nach der Migration zu «nur» O365

Sie haben alle zusätzlichen Lösungen gestoppt und sind nun auf O365-only. Sie haben nun vermehrt SPAMs oder gar Malware? Starten Sie möglichst schnell einen PoC mit einer zusätzlichen Lösung, welche vor- oder zwischengeschaltet werden kann. Überdenken Sie, ob O365 alleine reicht? Zusätzlicher Schutz macht Sinn!

  1. Schalten Sie vor O365 eine weitere Instanz, welche bekannt ist für guten Schutz.
  2. Sensitive Mails in O365 sollten nach Möglichkeit verschlüsselt abgelegt werden.
    • Eine Möglichkeit ist die GINA-Technologie (verschlüsseltes Mail als HTML, welches am Verschlüsselungs-Gateway entschlüsselt werden kann) oder
    • interne Mailverschlüsselung mit privaten S/MIME-Zertifikaten.
  3. Bauen Sie den Mailfluss so, dass im unverschlüsselten Zustand auf dem Gateway ein Scanning gegen Malware und Ähnliches möglich ist.
  4. Wählen Sie Lösungen, welche ebenfalls in der Cloud sind. Versuchen Sie die Komponenten möglichst «nahe» zueinander zu bringen. Vielleicht sogar mit IaaS oder PaaS als Grundlage.
  5. TLS zwischen den Mailgateways sollte selbstverständlich sein.
  6. Schützen Sie Ihre privaten Schlüssel der Zertifikate in der Cloud mit einem HSM.

 

Wir hoffen mit diesem dreiteiligen Blog etwas Licht ins Dunkle gebracht oder Ansätze aufgezeigt zu haben, wie man die Transformation erfolgreich bestehen oder sie wenigstens wieder retten kann, wenn sie vom Weg abgekommen ist.