Effizienz durch Automation

Um immer wiederkehrende IT-Infrastruktur Aufgaben mit gleichbleibend hoher Qualität und möglichst geringem Aufwand durchführen zu können, ist eine Automation solcher Abläufe unabdingbar.
Um erfolgreich solche “IT-Produkte” herstellen zu können, sind gewisse Vorbedingungen elementar wichtig. Wie z.B. klare detaillierte Vorstellungen des Endproduktes, einheitliche Konzepte, klare Definition der variablen Elemente und gute, vollständige Inventardaten.

Aussagen wie «wir wissen zwar noch nicht, wie das Produkt aussehen soll, wir werden dessen Herstellung jedoch auf jeden Fall automatisieren, um den Aufwand in Grenzen zu halten, beginnt doch mal mit den Überlegungen, wie eine Automatisierung aussehen könnte» ist als Basis für eine Automation nicht zielführend. Automatisierung ist ein evolutionärer Prozess, welcher durchlaufen wird, in welchem es wichtig ist, dass die Skills der Mitarbeitenden mit der zunehmenden Komplexität wachsen können.

In den folgenden Abschnitten werden wir auf wichtige Punkte, welche als Voraussetzung für eine erfolgreiche Automatisierung gelten, näher eingehen.

Low Level Design und Anzahl der Ausprägungen

Es muss in allen Details klar sein, wie das Produkt in allen seinen Ausprägungen aufgebaut werden soll. Die Anzahl unterschiedlicher Ausprägungen soll möglichst klein gehalten werden. Dabei wird oft der Begriff «T-Shirt Sizes» verwendet. Dieser Begriff impliziert gut, dass nicht beliebig viele Ausprägungen eines Produkts existieren sollen.

Der Schlüssel liegt in durchdachten Konzepten

Neben dem Blueprint sind in der Regel vielerlei Konzepte notwendig. Zum Beispiel Namens-, IP-Adress- und VLAN-Konzepte, um nur einige zu nennen. Bei den Konzepten ist darauf zu achten, dass die Werte für die verschiedenen Parameter berechnet werden können, ggf. müssen bestehende Konzepte dahingehend angepasst werden.

Kunden- und Factory-Seite beachten

Ein Automatisierungslösung hat immer zwei Seiten. Man spricht von den Kunden- und der Factory-Seite. Die Kundenseite bildet der Presentation Layer und es ist das wesentliche Element, das den Benutzer nicht überfordern darf, ihn unterstützt seine Angaben möglichst strukturiert und validiert zu erfassen. Der Presentation Layer ist eine definierte Bestelloberfläche für den Kunden und stellt die Integration ins Datenmanagement sicher.

Auf Factory-Seite wird der Orchestration Layer betrachtet, der alle Daten zur Herstellung des Produkts notwendigen Parameter und deren Werte liefert, um dieses möglichst automatisiert herzustellen, respektive auszurollen. Die Orchestration Layer kann auf verschiedenen Stufen abgebildet sein. Im einfachsten Fall werden Automatismen mit Scripts gesteuert. Eine weitere Stufe ist, dass bestehende Process Automation genutzt und mit Business Logiken versehen werden. Im fortgeschrittenen Fall kann ein oder mehrere bestehende Tools auf die Unternehmensbedürfnisse und Prozesse angepasst und deren APIs verwendet werden.

Datenquellen organisieren

Alle Daten, der zur Herstellung eines Produkts notwendigen Parameter, müssen auf irgendeinem System zur Verfügung stehen. Sollten diese auf mehreren Systemen verfügbar sein, muss klar sein, welches das führende System ist und wer für die Daten verantwortlich ist. «Single Source of Truth» heisst nicht, dass alle Daten auf einem System verfügbar sein müssen. Als Beispiel werden VLAN-Nummern und IP-Adressen von einem IP-Adress-Management System bezogen, während die Standort-Adressen, an welcher ein Gerät installiert werden soll, aus dem ERP stammen.

Fazit

Es gibt nicht “Die Automation”. In jeder Firma sind die Voraussetzungen und Bedürfnisse bestehend Automation sehr unterschiedlich. Dies insbesondere auch im Bereich der vorhandenen Skills der IT-Infrastruktur Teams, welche historisch nur wenige Softwareengineers und Programmierer enthalten.

Wichtig ist, sich dem Thema der Automatisierung vom Kleinen zum Grossen zu nähern und sich das notwendige Skill-Set zu erarbeiten, um so an den Aufgaben zu wachsen und diese auch erfolgreich abschliessen zu können.

---

Unsere Spezialisten haben in diversen Automatisierungsprojekten von der Konzeptionierung bis zur Einführung das erforderliche Know-how aufgebaut und weiterentwickelt. Wir unterstützen unsere Kunden, um die Voraussetzungen zur Automation in einem Review zu eruieren.

Mikrosegmentierung: Wo stehen wir heute?

Was versteht man unter Mikrosegmentierung (Microsegmentation) ?

Mikrosegmentierung hat im Zuge der Virtualisierung von IT- und Netzwerk-Infrastrukturen im Datacenter, dem Wachstum durch die allgemeine Digitalisierung, und der damit verbundenen Dynamik seine Bedeutung bekommen. Unter dem Begriff Mikrosegmentierung werden Sicherheitstechnologien und -produkte verstanden, die eine feingranulare Zuordnung von Sicherheitsrichtlinien (Security Policies) zu einzelnen Servern, Applikationen und Workloads im Datacenter erlauben. Dies ermöglicht es, Sicherheitsmodelle und deren Anwendung tief innerhalb der Datacenter-Infrastrukturen und Topologien und nicht nur an grösseren Netzwerk- und Zonenperimetern anzuwenden. Dies hat grosse Bedeutung bekommen als in modernen digitalisierten Umgebungen ein Grossteil des Datenverkehrs zwischen Applikationen und Servern innerhalb des Datacenters erfolgt und nicht mehr hauptsächlich von aussen nach innen oder umgekehrt.

Mikrosegmentierung hat sich in unterschiedlichem Grad etabliert.

In klassischen Infrastrukturen werden mit vermehrter Netzwerk-Virtualisierung und Automatisierung kleinere Netzwerksegmente gebildet. Allgemein gültige Firewallregeln, angewendet auf ganze Zonen, werden abgelöst durch pin-holing mit individuellen Regeln je Server/Applikation.

Die Server- und Netzwerkinfrastruktur hat sich verändert von wenig flexiblem, individualisiertem und manuellem Perimeterschutz über teil-automatisierte Zonen, Typen und Klassen von Servern zu mikrosegmentierten, hoch strukturierten, standardisierten und dafür automatisierten Systemen.

Dies stellt auch andere Anforderungen an die Verwaltung und den Unterhalt der Security Policies und Firewallregelsets im Speziellen als an vielen Orten nicht die eine oder anderer Umgebung in Reinkultur existiert, sondern Übergänge und Schnittstellen von alten auf neue und software defined zu klassischer Infrastruktur betrieben und sichergestellt werden müssen.

Unter den verfügbaren Produkten und Technologien gilt es zu unterscheiden zwischen

• Netzwerk-basiert
• Hypervisor integriert oder Cloud-native
• Server OS/Workload integriert als eigene Applikation

Dabei lassen sich die häufigsten Anwendungsfälle auch etwas gruppieren.

In konventionellen Serverinfrastrukturen wird primär mit Produkten mit netzwerk- oder OS-basierter Mikrosegmentierung gearbeitet. Dabei gilt es darauf zu achten inwiefern ältere Server und OS Versionen von OS basierten Produkten überhaupt unterstützt werden.

Für klassisch virtualisierte und private Cloud Infrastrukturen werden häufig die Hypervisor basierten, und in die Virtualisierung integrierte Mikrosegmentierungslösung verwendet und bei public Clouds die vom Cloud-Anbieter angebotene Cloud-native Lösung.

Vor allem in grösseren Umgebungen zeigt sich, dass häufig Kombinationen von Technologien und Produkten eingesetzt werden und Anforderungen an eine produktübergreifende Verwaltung und Administration von Security Policies und FW Regeln und Objekten gestellt werden. Diese Anforderungen steigen mit dem Grad der Virtualisierung, Mikrosegmentierung und hoch-dynamischen automatisierten Cloud- und Container-Infrastrukturen. Es wird zur Herausforderung, die dynamische und automatisierte Erstellung von Instanzen und Objekten, sowie deren Löschung in durchgängigen Konfigurationen automatisiert sicherzustellen. Die Entwickler von heute sind sich gewöhnt, ganze Applikationsumgebungen automatisiert zu erstellen und wieder zu löschen und die Infrastruktur muss Schritt halten damit die entsprechenden Security Policies und Regeln mit den effektiv vorhandenen Instanzierungen übereinstimmen.

---

Unsere Berater unterstützen Sie gerne, damit Ihr Mikrosegmentierungsprojekt ein voller Erfolg wird.

Cloud Netzwerkintegration

Egal, welche Cloudstrategie umgesetzt werden soll, ist es sinnvoll, das lokale Datacenter mit der Cloud zu verbinden, da der Weg in die Cloud einem schrittweisen Vorgehen entspricht. Es gibt immer Services im lokalen Datacenter, die einen Zugriff von der Cloud benötigen. So zum Beispiel Directory- und Identity Services, oder auch Zugriffe auf Datenbanken sowie die DDI Integration.

Cloud Anbindung

Die Art, wie die Anbindung realisiert wird, ist jedoch abhängig von der geforderten Qualität. Je nach Use-Case müssen vorgängig folgende Fragen gestellt und beantwortet werden.

Es sei angemerkt, dass in der Cloud für IaaS und PaaS in erster Linie virtuelle Netze mit privaten IP-Adressen (RFC 1918) erstellt werden, welche dann via der DC-Cloud Anbindung geroutet werden. SaaS Services, wozu auch das Cloud-Portal gehört, sind mit öffentlichen IP Adressen adressiert und werden via dem Internetzugang zugegriffen, welcher auch für das Surfen im Internet verwendet wird.

Diese Grafiken zeigen die Möglichkeiten der Anbindung einer Public Cloud ans lokale DC.

Diese Art der Anbindung ist kostengünstig und relativ schnell zu realisieren. Allerdings ist diese Art der Anbindung nicht für alle Qualitätsanforderungen geeignet.

Für hohe Qualitätsanforderungen eignet sich eine direkte Anbindung der Cloud ans lokale Datacenter. Eine solche Anbindung erfolgt jeweils über einen Service Provider, welcher im entsprechenden Land diese Dienste anbietet. Auch hier wird die Verbindung in der Regel verschlüsselt.

Eine weitere Variante stellt SD-WAN dar, welche in der Regel mit der Anbindung der Benutzer einhergeht. SD-WAN stellt eine Plattform dar, auf welcher verschiedene IPsec VPNs mit unterschiedlichen Topologien und Transportnetzwerken realisiert, und zentral gemanagt werden können. Sowohl die Variante IPsec VPN, sowie die direkte Anbindung lassen sich mit SD-WAN realisieren, respektive im Falle der direkten Anbindung als Transport integrieren.

Die folgende Tabelle zeigt auf, welche Anbindungsvarianten für die verschiedenen Use-Cases geeignet sind.

Cloud Networking

Neben der Anbindung ans lokale DC stellt sich die Frage, welche funktionalen Anforderungen ans Cloud Networking gestellt werden. Dabei geht es einerseits um Netzwerkkomponenten wie Router, VPN Gateways und Loadbalancer sowie um die Frage, ob eine lokal im DC eingesetzte Fabric-Technologie in die Cloud verlängert werden soll.

Die Frage betreffend der Netzwerkkomponenten in der Cloud lässt sich aus funktionaler Sicht wie folgt beantworten.

Ob eine DC Fabric in die Cloud erweitert werden soll ist abhängig davon, welche Cloudstrategie verfolgt wird. Wird die Cloud über längere Zeit im Hybrid-Modus betrieben und soll die Netzwerk-Segmentierung in der Cloud mit den gleichen Tools bewerkstelligt werden, dann ist es sinnvoll, die lokale DC Fabric in die Cloud zu verlängern. Wird die Cloud jedoch temporär eingesetzt, dann macht eine solche Verlängerung wenig Sinn. Um die lokale DC Fabric in die Cloud zu erweitern, sind im Falle von Cisco ACI Cloud-seitig «Cisco Cloud ACI» und im Falle von VMware NSX «VMware NSX Cloud» zu implementieren und zu aktivieren. Diese stehen in den entsprechenden Cloud-Stores zur Verfügung.

---

Unsere Consultants haben in unzähligen Cloudprojekten von der Konzeptionierung bis zur Einführung das erforderliche Know-How aufgebaut und weiterentwickelt. Wir unterstützen unsere Kunden, um ihre Cloudprojekte ganzheitlich, also über die Netzwerkebene hinausgehend, erfolgreich durchzuführen.

Automation

Aufgrund der agilen Vorgehensweisen in vielen IT-Bereichen und um den dadurch resultierenden kürzeren Bereitstellungszeiten von IT-Infrastruktur nachzukommen, denken viele IT-Organisationen darüber nach, was mit vertretbarem Aufwand automatisiert werden könnte, um die wachsenden Anforderungen seitens des Business zu erfüllen.
Neben der Agilität sind es auch die Kosten und nicht zuletzt die geforderte Qualität, welche der Automatisierung Vorschub leisten. Ist ein Ablauf einmal automatisiert, dann können auch anders qualifizierte IT-Mitarbeiter, oder im besten Falle der Besteller eines Services selbst, diesen Schritt durchführen, was sich schlussendlich auch positiv auf die Kosten auswirkt.

Bedingungen

Um einen Vorgang automatisieren zu können, muss dieser zwingend standardisiert sein, also mit möglichst wenigen Ausnahmen immer gleich ablaufen. Zudem muss dieser Vorgang häufig angefordert und durchgeführt werden, um den Aufwand einer Automatisierung zu rechtfertigen.
Eine Automatisierung erfordert zudem, dass die IT-Infrastruktur in den Bereichen Compute, Storage und Netzwerk virtualisiert ist. Wenn jedes Mal, wenn eine zusätzliche Instanz eines Service im Datacenter aufgeschaltet werden soll, Hardware angeschafft und installiert werden muss, kann nicht automatisiert werden.

Art der Automation

Es wird zwischen der vertikalen und der horizontalen Automatisierung unterschieden. Diese Grafik zeigt den Unterschied.

Bei der horizontalen Automation werden die Vorgänge beschränkt auf die jeweilige Ebene automatisiert. Hier als Beispiel das Datacenter Netzwerk, welches mit einer «out of the Box» SDN-Lösung eines Netzwerkherstellers automatisiert wird. Oder die Ebene «Firewall & Proxy Rules» wird mit einem Firewall-Policy-Management automatisiert. Das Gleiche gilt für die Ebene «Compute & Storage», welche mit den Automatisierungstools der Lieferenten der Virtualisierung von Compute oder Storage automatisiert werden.
Erst wenn die einzelnen Ebenen ausreichend automatisiert sind, kann eine vertikale Automatisierung realisiert werden, um Instanzen eines multilayer Service, also eines Service, welcher aus Services verschiedener Ebenen besteht, automatisiert zu provisionieren. Oftmals spricht man im Falle der vertikalen Automatisierung auch von Orchestrierung. Eine vertikale Automatisierung bedingt, dass die zur Automatisierung einer Ebene eingesetzten Produkte ein «Northbound API» aufweisen. Dieses wird vom Orchestrator der vertikalen Automatisierung verwendet, um Instanzen in der entsprechenden Ebene zu provisionieren. Zum Beispiel, um auf der Ebene «Datacenter Network» einen virtuellen Router mit den dazugehörenden VLANs zu konfigurieren, mit welchen der Orchestrator in einem weiteren Schritt die VMs via dem Compute Automatiserungstool verbindet.

Architektur Automatisierungstools

Die Automatisierungstools einer Ebene weisen alle in etwa dieselbe Architektur aus. Diese ist in der folgenden Grafik dargestellt.

Beginnen wir mit dem «Northbound API», welches verwendet wird um die Services einer Ebene zu konfigurieren. Dies geschieht entweder mittels dem GUI durch eine Person, oder direkt durch den Orchestrator der vertikalen Automation. Entscheidend ist hier, dass auch das GUI das «Northbound API» verwendet, da so sichergestellt ist, dass alle GUI Funktionen auch den Orchestrator zur Verfügung stehen.
Die «Workflow Engine» führt die verschiedenen Schritte durch, welche den Service ausmachen. Anschliessend erstellt die «Provisioning Engine» die zur Konfiguration notwendigen «Snipplets», welche dann via Rest-API, Netconf oder CLI auf die Komponenten der Infrastruktur provisioniert werden. Die Struktur und die Parameter eines Service werden in der Service DB festgehalten, welche immer den «Single Source of Truth» darstellt.
In einer Model-Driven Automatisierung werden die Konfigurationen der Infrastrukturkomponenten periodisch. mit der Service DB abgeglichen. Hier stellt sich die Frage, wie mit den Abweichungen umgegangen wird. Oftmals wird nur ein Reporting erstellt und die Differenzen müssen manuell bereinigt werden, da ein direktes Reprovisioning aus der Service DB einen Unterbruch des betroffenen Service zur Folge haben könnte.
Zudem kann aus der Service DB mittels dem «Service Viewer» die Service-Struktur und die -Parameter in der Form eines Service-Tree direkt online, oder als Report dargestellt werden. Dies ist ein wichtiges Feedbackinstrument, um die korrekte Funktion der Workflow- und der Provisionig-Engine zu überprüfen.

---

Unsere Berater unterstützen Sie gerne, damit Ihr Automationsprojekt ein voller Erfolg wird.

Umsetzung Netzwerk-Zonenkonzept in der Praxis

Im einfachsten Fall werden die Server von den Clients getrennt oder es werden äusserst umfangreiche Zonenkonzepte erstellt. Im Wesentlichen geht es immer darum, Systeme mit demselben Zweck und demselben Schutzbedarf in Netzwerkzonen zusammenzufassen. Damit ein Zonenkonzept erfolgreich umgesetzt werden kann, sind bereits bei dessen Erstellung einige Punkte zu beachten.

Zonenkonzept

Bereits bei der Erstellung des Zonenkonzepts sollte nicht der Anspruch bestehen, 100% der in der Praxis auftretenden Fälle abdecken zu wollen. Ein Ausnahmeprozess ist immer notwendig und es muss eine Vorstellung existieren, was sein muss und was mittels Ausnahmeregelung gehandhabt werden kann. Es sollen möglichst wenige Zonen realisiert werden, die in weitere Subzonen unterteilt werden können. Die Anforderungen für neue, zusätzliche Zonen sollen klar und entsprechend hoch sein.

Da es sich bei einer Netzwerkzonierung um ein anspruchsvolles Vorhaben mit höchst unterschiedlichen Anforderungen handelt, ist es wichtig, dass der Auftraggeber für alle Beteiligten weisungsbefugt ist und dass Vorgaben seitens Business, was überhaupt geschützt werden soll, existieren. Es ist äusserst hilfreich, wenn in einer Unternehmung eine Klassifizierung der Daten existiert und man so weiss, was es zu schützen gilt.

Auf Ebene Security, IT-Architektur, Engineering und Betrieb existieren völlig unterschiedliche, nicht kompatible Anforderungen. So muss es für die Security möglichst sicher, für die IT-Architektur und das Engineering möglichst klar und durchgängig strukturiert und für den Betrieb möglichst einfach in der Sache und auch einfach zu handhaben sein.

Zu Beginn eines solchen Vorhabens geht es darum die Begrifflichkeiten festzulegen damit alle Beteiligten das Gleiche unter einem Begriff verstehen. Beispielsweise bedeutet schon der Begriff Netzwerkzone nicht zum Vornherein für alle Beteiligten das Gleiche.

Umsetzung des Zonenkonzepts

Die Umsetzung eines Netzwerk-Zonenkonzepts besteht aus der Konzeptionsphase, dem Aufbau der Sicherheitselemente um die Zonen abzubilden und der Migration der Applikationen, respektive deren Infrastruktur in die verschiedenen Netzwerkzonen.

Für das Bereitstellen der Sicherheitselemente zwischen den Netzwerkzonen wäre es wichtig zu wissen, welche Kommunikationsverbindungen von den Applikationen benötigten werden. Um zu diesen Angaben zu kommen ist es wichtig, dass die Applikationsverantwortlichen bekannt sind und diese die Kommunikationsanforderungen ihrer Applikationen kennen. Es ist jedoch nicht realistisch davon auszugehen, dass dies immer der Fall sein wird. Es gibt unterschiedliche Methoden mit dieser Problematik umzugehen. Eine häufig angewendete Vorgehensweise ist, die bekannten Kommunikationsverbindungen auf den Sicherheitselementen abzubilden und am Ende des Regelwerks eine «forward any» Regel einzubauen. Dies mit dem Ziel, die «forward any» Regel nach dem Migrieren einer Applikation durch spezifische Regeln zu ersetzen und erst dann die nächste Applikation zu migrieren, wenn diese Regel nicht mehr benötigt wird.

Ein Migrationsteam muss in der Lage sein, alle Belange einer solchen Migration abzudecken. Je nach Migrationsvorgehen sind Security- und Netzwerk-Engineers, Applikationsbetreiber und -Tester und auch Lieferanten der Applikation notwendig, um eine Migration erfolgreich durchzuführen. Der Migrationsverantwortliche erstellt das Drehbuch und moderiert die Migration. Das Drehbuch enthält auch immer ein Fallback-Szenario um bei unüberbrückbaren Problemen wieder auf den Status vor der Migration zurückgehen zu können.

Als Teil der Migration muss eine Applikation anschliessend auf ihre Funktion getestet werden. Da solche Migrationen in der Regel ausserhalb der Bürozeiten durchgeführt werden, kann im Rahmen der Migration lediglich die Funktion, jedoch nicht das Verhalten unter Produktionsbedingungen getestet werden.

Um als Migrationsteam nach einer Migration nicht ewig für Incidents einer migrierten Applikation verantwortlich zu sein, gilt es mit dem Betrieb abzusprechen, wann eine Applikation wieder gemäss Standard-Incident-Prozess gehandhabt werden soll.

---

Unsere Spezialisten haben in unzähligen Projekten von der Konzeptierung über die Einführung bis zur Migration das Know-How aufgebaut und weiterentwickelt. Wir unterstützen Sie, um Ihr Zonierungsprojekt erfolgreich durchzuführen.

atrete verstärkt ihr Beratungsteam in den Bereichen Cloud und Connectivity

Die IT-Consultingfirma atrete wächst weiter und verstärkt sich mit Patrik Huber im Bereich Cloud Beratung und mit Dirk Metzger im Bereich Netzwerk Beratung/Engineering. 

Patrik Huber arbeitet seit 1.2.2020 als Consultant bei atrete. Er besitzt einen Hochschulabschluss als Master of Science FHO in Wirtschaftsinformatik. Vor atrete war er mehrere Jahre beim Migros-Genossenschafts-Bund tätig, zuletzt in einer Schlüsselrolle bei der Einführung von Cloud Lösungen.

Dirk Metzger ist seit 1.5.2020 zu 80% als Senior Consultant bei atrete tätig. Er hat mehrere Zertifizierungen im Bereich Connectivity und Security, so u.a. den Cisco CCNP, CCIP, CCSP und weitere von Aruba, Arista und Fortinet. Vor atrete war er mehrere Jahre als Netzwerk-Architekt im Banking Service Center in Bern tätig.

«Wir sind sehr erfreut, dass Patrik Huber und Dirk Metzger unser Team verstärken», sagt Michael Kaufmann, CEO und Managing Partner der atrete. Die Nachfrage nach Cloud- und Connectivity-Beratung bleibt trotz oder auch wegen der Corona Pandemie weiterhin hoch.»

Michael Kaufmann, CEO und Managing Partner

Medienkontakt:
at rete ag
Marlene Haberer
Telefon: +41 44 266 55 83
Email: marlene.haberer@atrete.ch