Resilienz von Systemen Teil II - Anforderungen und Systemspezifikationen

 Die Systemspezifikation spielt bei der Robustheit eine entscheidende Rolle. Noch mehr als ein Systemmodell hat die Erfüllung bestimmter formaler Merkmale einen großen Einfluss auf den Wert einer Spezifikation. Eine Systemspezifikation ist beispielsweise unerlässlich, um Designvariationen zu reduzieren. Ähnlich wie bei einer Richtlinie kann eine Spezifikation so vage sein, dass viele technisch unterschiedliche mögliche Systemdesigns noch spezifikationskonform sein können, was zu unnötigen Abweichungen führt. Was Compliance für Richtlinien ist, ist Konformität für Spezifikationen.

Die Kriterien für die Systemspezifikation sind wie folgt:

- Eine Systemspezifikation steht als schriftliches Dokument zur Verfügung.

- Subjekt-Experten können überprüfen, ob die angegebenen Funktionalitäten , Implementierungen, Konfigurationen und Ausführungsverfahren zu einer Lösung führen, die die angegebenen Anforderungen erfüllt.

- Die Anwendung der Systemspezifikation führt zu einer funktionierenden Lösung.

- Die Anwendung der Systemspezifikation durch verschiedene Personen führt zu identischen Ergebnissen.

- Die Feststellung durch verschiedene Personen, ob ein bestimmtes Systemdesign spezifikationskonform ist, führt zu identischen Ergebnissen.

- Die Systemspezifikation ist in das Änderungsmanagement integriert.

Die Rolle der Anforderungen an die Robustifizierung

Die Anwendung von robustifizierungsstrategien verändert ein System. 

Eine solche Änderung ist nur dann sinnvoll, wenn die Funktionalität des Systems nicht beeinträchtigt wird, und wenn die neuen Systemeigenschaften - hoffentlich eine bessere Robustheit unter ihnen - als Fortschritt angesehen werden können.

Robustifizierung ist eine technische Disziplin, die lehrt , wie man ein technisches Problem besser als bisher löst. Dies ist nur möglich, wenn ein klares Verständnis der erforderlichen Funktionalität vorhanden ist, was in der Regel nicht Teil eines Systemmodells ist. Ein gutes Systemmodell sagt zwar, wie ein bestimmtes System gestaltet ist, erklärt aber in der Regel nicht, warum dieses spezielle Design gewählt wurde. Die Unfähigkeit, die Gründe für bestimmte Systemdesign-Entscheidung zu identifizieren, ist dagegen ein Hinweis auf ein unvollständiges Systemverständnis.

Anforderungen unterliegen nicht dem Aufwand für die Robustheit, und die Robustheit versucht nicht zu überprüfen, ob dokumentierte Anforderungen angemessen sind. In konkreten Robustheitsprojekten ist dies ein wichtiges Thema für die Kommunikation mit den Endanwendern, die in der Regel befürchten, dass ihre Anforderungen nicht mehr erfüllt werden, nachdem ihr System von Dritten „verbessert“ wurde.

Spezifikationsartikel

Ein Pflichtenheft verbindet Anforderungen, Funktion, Implementierung, Konfiguration und Ausführungsverfahren.

Spezifikationsfehler #1: Die Spezifikation endet vorzeitig nach unten.

Dies lässt Raum für Variabilität, wobei verschiedene Funktionen, Implementierungen (Produkte) oder Verfahren (Konfigurationen) verwendet werden können, die alle Spezifikationskonform sind.

Die Anforderung nach schneller Fehlerbehebung wird oft durch Fernzugriff erfüllt. Es bleibt jedoch offen, wie der Fernzugriff gestaltet und ausgeführt werden soll. In realen Installationen wird daher ein Mix aus Dial-in-Modelms und Internet/VPN-Zugang mit unterschiedlichen Protokollen und Produkten verwendet.

Spezifizierungsfehler #2: Die Spezifikation endet vorzeitig nach oben.

Dies erfordert lediglich ein bestimmtes Produkt, eine bestimmte Technologie oder Funktionalität , ohne zu sagen, warum. Da Anforderungen und Funktionalität nicht detailliert beschrieben sind, gibt es wenig Möglichkeiten, die vorgeschriebene Verwässerung durch eine Alternative zu ersetzen, z.B. wenn das betreffende Produkt oder die betreffende Technologie veraltet ist und nicht mehr zum Kauf angeboten wird.

Der Spezifikationsbaum

Für jede Anforderung gibt es in der Regel mehr als eine Möglichkeit , ihre Funktion zu erfüllen. Für jede Funktion gibt es in der Regel mehr als eine Möglichkeit , sie zu implementieren. Und für jede Implementierung gibt es in der Regel mehr als eine Möglichkeit, sie in Bezug auf Konfiguration, Umgebung, Kontext usw auszuführen.

Daher ist die Spezifikation, einem Entscheidungsbaum ähnlich, bei dem jeder neue Zweig einen neuen Satz von Variabilität eröffnet.

Eine gute Spezifikation begrenzt die Anzahl der möglichen Funktionen, Implementierungen, Konfigurationen und Verfahren - idealerweise auf eine einzige Instanz in jedem Knoten, wodurch die Variabilität reduziert wird. Eine gute Spezifikation erlaubt keine beliebigen alternativen Funktionen, Implementierungen und Prozeduren. Im Idealfall sollte es nur eine mögliche spezifikationskonforme Implementierung geben, d.h. Nur einen bestimmten Pfad von der Anforderung (root) zur Prozedur (leaf).

Eine gute Spezifikation ermöglicht es aber auch, festzustellen, ob alternative Verfahren, Implementierungen und Funktionen, die robuster sein können als die ursprüngliche Lösung , die Anforderungen noch erfüllen. Dies ist eine wesentliche Grundlage für die Robustheit.

Spezifische Betreibsbedingungen

Die Betriebsbedingungen legen fest, unter welchen Bedingungen eine bestimmte Implementierung und/oder ein bestimmtes Verfahren getestet und zuverlässig ist und unter welchen nicht. 

Ressourcenanforderungen und Abhängigkeiten

Die Spezifikation muss alle Ressourcen identifizieren, die von der Systemumgebung bereitgestellt werden müssen, damit das System wie angegeben funktionieren kann.

Zum Beispiel, wenn es einen Bedarf gibt an

- Ein DHCP-Server, DNS-Server oder NTP-Server, der über das Netzwerk zugänglich ist.

- Ein bestimmtes Produkt eines Drittanbieters, wie beispielsweise eine Datenbankmaschine.

- Eine bestimmte Softwarekomponente , wie z.B. eine DLL in einer bestimmten Version.

Damit das System funktioniert , höchstwahrscheinlich mit speziellen Konfigurationseinstellungen, muss dies dokumentiert werden.

Betriebsgrößen: Bedingungen , die für eine ordnungsgemäße Ausführung zu vermeiden sind.

Jedes technische System hat Betriebsgrenzen, über die hinaus die Funktionalität beeinträchtigt ist, und Betriebsvoraussetzungen, die erfüllt sein müssen, damit das System funktioniert. Der Planer und Implementierer des Systems erwartet, dass das System innerhalb dieser Grenzen betrieben wird. Leider bedeutet dies nicht, dass solche Grenzwerte, die genauso real sind wie ihre elektrischen Gegenstücke, zwangsläufig ordnungsgemäß dokumentiert werden müssen.

Variation sind nicht dasselbe wie ungültige Eingaben, Stress und Fehler.

Fehler und Störungen sind Verstöße gegen vorgegebene Parameter. Wenn keine Spezifikation existiert , kann sie nicht verletzt werden - dennoch versagen reale Systeme auch ohne Spezifikation, sie können nicht versagt werden - dennoch versagen reale Systeme auch ohne Spezifikation aufgrund einer de facto-Verletzung von Betriebsbedingungen.

Ein System ohne vorgegebene Betriebsgrenzen ist fragil, da die Leistung des Systems unter bestimmten Bedingungen nicht vorhergesagt oder garantiert werden kann.

Erster Teil:

https://einsiedlerkreps.blogspot.com/2023/04/resilienz-von-systemen.html

SAP Data Intelligence - Ein möglicher wichtiger Part in der Systemlandschaft

 Ich beschäftige mich ja schon seit einiger Zeit mit der Integration von Systemen , hier geht es aber um den Fluss von Daten. Das Thema der Daten in einer vernetzten Firma ist in aller Munde und einige Softwarehersteller bieten ihre Lösungen an.

SAP führte eine neue Plattform für die Verarbeitung komplexer Datenmengen in Echtzeit ein um für zukünftige Anforderungen ausgerichtet zu sein.

Für SAP war mit Sicherheit die Einführung von SAP HANA einer der größten Meilensteine. Sie bildet die Grundlage für die heutigen Möglichkeiten zur Verarbeitung von Informationen - neben einem höheren Erkenntnisgewinn führt das auch zu einer höheren Komplexität der Verarbeitung und Bereitstellung von Daten.

Für SAP - Abteilungen gewinnen die Fragestellungen immer mehr an Bedeutung:

- Welche Muster und Zusammenhänge lassen sich pro Datenquelle sowie quellübergreifend identifizieren? 

- Können auf Basis der Erfahrungen aus der Vergangenheit gegebenenfalls auch Aussagen über zukünftige Fehler getroffen werden?

- Können daraus resultierend vorbeugende Wartungsmaßnahmen eingeplant , ausbleibende Ausfälle berücksichtigt oder absehbare Kostensteigerungen eingeplant werden?

SAP Data Intelligence verfolgt einen ganzheitlichen Lösungsansatz für all diese Anforderungen.

Durch die Leistungsfähigkeit von SAP Data Intelligence verschwinden Systemgrenzen, und neue Möglichkeiten der übergreifenden Informationsbereitstellung und Zusammenarbeit können erschlossen werden.

Zukunftsgerichtete Organisationen haben bereits bei der Einführung von SAP HANA die Potenziale identifiziert und damit begonnen, die Geschwindigkeitsvorteile von In-Memory-Systemen nutzbar zu machen.

Was ist SAP Data Intelligence?

Die vier großen Leistungsfelder sind laut SAP:

- Data Pipelining und Prozessierung

- Datenorchestrierung und Monitoring

- Data Governance

- Data Science

Diese Platform lohnt sich im Auge zu behalten und in die Systemlandschaft einzuplanen.

Ich werde sicher noch mal was schreiben um auf Details näher einzugehen.  

Resilienz von Systemen

Resillienz von Systemen ist aus meiner Sicht ein wichtiges Thema , gerade in einem Bereich in dem Systeme in sog. Kritischen Infrastrukturen befinden, bei vernetzten Systemen ist nicht nur das jeweilige System zu betrachten sondern auch das gesamte Netzwerk von Systemen. Jetzt stellt sich die Frage wie kann man diese Resillienz erreichen.

Ich möchte hier folgende Robustheit‘s Axiome anführen und versuchen diese zu erklären.

„Das deutlichste Anzeichen für ein anfälliges System oder eine anfällige Installation ist ein unzureichendes Systemverständnis, das sich in einer fehlenden Dokumentation äußert.“

Unzureichendes Verständnis des betrachteten System angezeigt durch das Fehlen eines genauen, dokumentierenden Systemmodells führt zu fragilen Systemen , die von der Betriebsführung im Blindflug durchgeführt werden muss. Auch die Weiterentwicklung und Erweiterung des Systems ist schwierig wenn man die Auswirkung von Änderungen auf das System nicht abschätzen kann.

Ein nicht vollständig verstandenes System kann nicht zuverlässig sein und stellt ein großes Problem für die Wartung dar. Unzureichendes Systemverständnis und fehlende Dokumentation führen mit ziemlicher Sicherheit zu unangenehmen Überraschungen, insbesondere bei Systemen mit langer Lebensdauer. Wenn die Struktur und das Verhalten eines Systems unbekannt oder nur teilweise bekannt ist, ist es unmöglich, Ausfälle vorherzusagen.

„Je länger die voraussichtliche Lebensdauer eines System‘s ist , desto höher sind die Anforderungen an die Robustheit“

Natürlich je länger das System bestehen soll , desto wichtiger wird das das Thema , gewisse Fragestellungen werden wichtiger wenn das System länger 10 Jahre bestehen soll. Es kann auch durchaus bei der Entwicklung ein wenig zu kosten der Entwicklungsgeschwindigkeit geht. Die Auswahl der Technologie ist hier natürlich mit mehr Bedacht zu wählen.

Aspekte und Kriterien des Systemmodells

Ein Systemmodells kann verschiedenen Zwecken dienen. Es kann als Teil des Systemdesigns und der Spezifikation verwendet werden, Ein Modell ist eine abstrahierte Beschreibung , reduziert auf das Wesentliche, das für das Systemverständnis notwendig ist. Ziel ist es, das absolut notwendige Minimum an Dokumentation zu erstellen, das es ermöglicht, das System zu verstehen- auch von jemanden ohne Erfahrung vor Ort. In unserem Fall umfassen zwei Arten von Modellen unterschiedliche Bereiche, von denen einige trivial sind, andere sehr kompliziert werden können:

Ein strukturelles Systemmodell unterteilt das betrachtete System in kleinere Teile und identifiziert die Wechselwirkungen zwischen Subsystemen und Schnittstellen zu anderen Systemen.

Eine Ausführungsumgebung beschreibt die beteiligten Prozesse , einschließlich logischer, physischer und organisatorischer Einschränkungen.

Die Kriterien für das Systemmodell sind folgende:

Es existiert ein dokumentiertes Systemmodell.

Das Systemmodell ist auf ein Minimum reduziert.

Das Systemmodell ist verifizierbar.

Das Systemmodell ist genau.

Das Systemmodell wird so dokumentiert, dass auch unbeteiligte Personen ohne Erfahrung vor Ort (z.B. unabhängige Berater oder Mitarbeiter aus einer anderen Abteilung oder einer anderen Einrichtung) das Modell verstehen und verifizieren können.

Das Systemmodell ist in das Change Management integriert.

Bau eines strukturellen Systemmodells

Um ein System zu verstehen , müssen seine Subsysteme, Abhängigkeiten und Schnittstellen zu anderen Systemen bekannt und dokumentiert sein.

Hardware Inventarisierung

Es existiert ein Hardwareinventar, das anhand der realen Installation überprüft werden kann. Die Hardware-Inventur enthält Einträge für alle physischen Systeme und Komponenten, die durch den Umfang der Spezifikation abgedeckt sind. Alle Einträge sind auf dem neuesten Stand und soweit möglich vollständig. Der Systembestand ist für alle autorisierten Mitarbeiter zugänglich, die Bestandsinformation verwenden müssen. Die Systeminventur ist in das Änderungsmanagement integriert.

Software Inventarisierung

Das Inventar der Anwendungen und Dienste spezifiziert alle Anwendungen und Dienste, die erforderlich sind, um die angegebene Funktionalität des betrachteten Systems zu erfüllen. Alle Anwendungen und Dienste sind mit den Hardware-Systemen, auf denen sie gehostet werden, verknüpft. Für alle verteilten Anwendungen und Dienste sind die technischen Details des Datenflusses festgelegt. Die Auflistung der Anwendungen und Services ist in das Change Management integriert.

Netzwerkkonfiguration

Es existiert ein Dokument zur Netzwerkarchitektur, das die Netzwerkarchitektur, Endpunktsysteme, Segmentierung und Zonierung, Firewalls, Gateways und Schnittstellen zu anderen Netzwerken beschreibt. Das Dokument zur Netzwerkarchitektur ermöglicht die Identifizierung des technisch möglichen Verkehrs von und zu Endpunktsystemen, Access Points, Gateways und Schnittstellen. Das Dokument zur Netzwerkarchitektur ermöglicht das Bestimmen der Bandbreite, Latenz und QoS-Eigenschaften möglicher Kommunikationswege. Das Dokument zur Netzwerkarchitektur ist in das Änderungsmanagement integriert.

Menschen, Richtlinien, Verfahren

Personen, die mit dem betrachteten System und seinen Komponenten interagieren müssen oder können, werden zusammen mit Verantwortlichkeiten und Pflichten dokumentiert. Die Festlegung der Verantwortlichkeiten erfolgt über ein rollenbasierten Konzept, das den Benutzergruppen zuordenbar ist. Wiederkehrende Aufgaben werden als Standardanweisungen formalisiert. Das People und Policies Dokument listet die Anforderungen an Ausbildung und Zeiteinteilung auf, die erfüllt sein müssen, um die festgelegten Aufgaben angemessen zu erfüllen. Alle Personen , die mit dem System interagieren, sind nach Name, Abteilung und Unternehmen identifizierbar (im Falle von Lieferanten und Auftragnehmern). Die Verfahren sind dokumentiert und überprüfbar. Das Personen- und Verfahrensdokument (oder die Datenbank) ist in den Change-Management-Prozess integriert.

Fazit:

Ich bin der Meinung wenn diese Punkte durchgeführt werden ist der erste Schritt zur Resilienz gemacht. Es gibt noch weitere Punkte die vorgenommen werden können um den „Robustheits-Reifegrad“ zu steigern. 

Enterprise Architektur und SAP

 Die große Frage die immer am Anfang steht ist was ist Unternehmensarchitektur?

Wenn sie zehn verschiedene Leute fragen erhalten sie zehn verschiedene Antworten. Jedes Unternehen hat eine Architektur, ob es sich dessen bewusst ist oder nicht.

Jedes Unternehmen besteht aus Elementen, die es ausmacht.

Unternehmensziele, Stakeholder, Daten, Anwendungen, Server, Standorte für die Notfallweiderherstellung usw.

Die wichtigste Frage ist das „Wie“

Die Antwort auf die Frage „Wie“ beginnt damit, dass Sie feststellen, wo ihr Unternehmen jetzt steht. Bei der Enterprise Architektur geht es darum, durch die Modellierung von Prozessen, Fähigkeiten, Ressourcen, Daten und technologischen Ressourcen, die unser Unternehmen aufrechtzuerhalten, anschaulich zu beschreiben, wo sich unser Unternehmen heute befindet, und zwar in einer Weise, die von mehreren Beteiligten verstanden wird. Das wird durch den mutliperspektivischen Ansatz erreicht, den die Enterprise Architektur bietet. Dieser Prozess wird erweitert , um die Vision der Zukunft des Unternehmens zu erfassen, wiederum durch die Modellierung der oben genannten Elemente. Die Unternehmensarchitektur ermöglicht auch die Modellierung von Golf-Zwischenzuständen zwischen dem aktuellen und dem zukünftigen Zustand unseres Unternehmens.

Die Unternehmens-Architektur bietet eine solide Grundlage für Planung, Analyse, Entscheidungsfindung und Strategieumsetzung.  Sie ist vergleichbar mit einem Puzzle , bei dem man zunächst herausfindet, welche Teile derzeit zur Verfügung stehen und wie sie zusammenpassen; danach entscheidet man, welche Teile noch fehlen, um das Puzzle, das man sich vorstellt, zu vervollständigen; dann macht man sich daran, diese Teile zu erstellen. 

Dies ist das Wesen der Unternehmensarchitektur und unterscheidet sie von der bloßen Entwicklung von Systemen: 

Das Unternehmen ist das Sytem!

Wie bei allen geschäftlichen und IT-Bestrebungen ist es wichtig , den Wert zu verstehen, der aus der Entwicklung einer Unternehmensarchitektur abgeleitet werden kann. Es gibt „sieben“ Gründe, warum die Entwicklung einer Unternehmensarchitektur einer entscheidender Schritt für jedes Unternehmen ist:

1. Gewinnen Sie einen Enblick in den aktuellen Zustand Ihres Unternehmens

2. das Unternehmen in die Lage zu versetzen, die Lücke zwischen dem Ist-Zustand und dem angestrebten Soll-Zustand zu messen

3. die Geschäftsprozesse und die sie unterstützenden IT-Prozesse genau aufeinander abzustimmen

4. Schnellere Umsetzung von unternehmensweiten Änderungen durch etablierte Standards und Governance

5. größere Verantwortlichkeit für und Kontrolle über IT-Kosten innerhalb des Geschäftskontextes

6. Eine gemeinsame Sprache für die unternehmensweite Entscheidungsfindung, insbesondere bei IT-Investitionen

7. Schaffung einer klar definierten und übersichtlichen IT-Landschaft.

Mir persönlich ist wichtig das die SAP Architektur in die Enterprise Architektur eingebunden ist den SAP ist ein Teil des Unternehmens ist.

Deswegen bietet es sich an das die Architektur mit einem gemeinsamen Framework durchgeführt wird.

TOGAF z.B bietet sich hier an.

Das SAP Enterprise Architektur Framework

Das SAP Enterprise Architektur Framework wurde im Jahr 2007 offiziell eingeführt und basiert auf dem The Open Group Architektur Framework (TOGAF).

Ähnlich  wie TOGAF bietet SAP EAF einen Rahmen für einen iterative Prozess für das gesamte Unternehmen, der speziell auf die SAP-Methodik abgestimmt ist. Das SAP EAF beschleunigt die Architekturerstellung durch die Bereitstellung von Best Practices und Artefakten, die für die Lösungen des Unternehmens relevant sind und normalerweise von Grund auf neu entwickelt werden müssten. Darüber hinaus bietet es die Struktur , um die Architektur so zu speichern und zu ordnen, dass sie sich am besten für SAP-Lösungen eignet und auch für die Darstellung der Architektur gegenüber den Beiteiligten geeignet ist.

SAP EAF ermöglicht es Unternehmen, durch maßgeschneiderte Implementierungen, die sich auf kleinere , schnelle Projekte konzentrieren , geschäftliche Veränderungen voranzutreiben.

Das SAP EAF umfasst insbesondere die folgenden Elemente:

Accelerators- Blaupausen und Beispiele, die einen schnellen Start für spezifische EA-Szenarien ermöglichen.

Roadmaps - Helfen bei der Optimierung des Geschäftsnutzens und der Rentabilität ihrer IT-Investitionen, indem sie beschreiben, wie die Funktionen einer SAP-Lösung im Laufe der Zeit weiterentwickelt werden sollen.

Referenzarchitekturdokumentation - Ein Entwurf der empfohlenen Strukturen und Integrationen von IT-Produkten und -Services zur Bildung einer Lösung.

Templates - Modelle und Prototypen zur Strukturierung der einzelnen Schritte des EA-Prozesses

EA-Modellierungswerkzeuge - Werkzeuge wie der SAP Enterprise Arhcitecture Designer, die zur Erfassung von Architekturschichten und Anforderungen verwendet werden.

Das sind die wichtigen Werkzeuge um gute Entscheidungen treffen zu können sie helfen um ein „Bild“ zu bekommen das sogenannte „Big Picture“ .

Schnittstellen nach ContentTypes bei SAP

 Hier sollen die Schnittstellentechnologien aufgeführt werden, sämtliche neue Schnittstellen, die auf SAP-Anwendungen bereitstellen, werden über den SAP API Business Hub veröffentlicht, da SAP eine einheitliche Strategie in der Bereitstellung verfolgt.

SAP API Business Hub

Dort finden Sie folgende Inhalte, die nach Kategorien (CONTENT TYPES) dargestellt werden:

API:

Schnittstellen, die von unterschiedlichen SAP-Anwendungen auf Standards wie REST (Representational State Transfer), OData und SOAP basieren.

Integration:

Fertige Schnittstellenpakete, die Sie direkt kopieren und aktivieren können. Momentan stehen Packages für SAP Cloud Integration  und SAP SuccessFactors Integration Center Packages bereit.

Events:

Ereignisse, die innerhalb von SAP-Anwendungen ausgelöst und verarbeitet werden können. Solche Ereignisse werden typischerweise über Nachrichten in Warteschlagen beretigestellt und können so in die Folgeverarbeitung integriert werden. Im SAP API Business Hub werden die Schemata bereitgestellt und dokumentieren den Aufbau dieser Nachrichten.

CDS Views

CDS Views beschreiben eine Datenbanksicht, die über das OData-Protokoll Zugriff auf SAP-Systeme ermöglichen, die auf den SAP-HANA-Datenbank basieren.

Business Processes

Die Kategorie Business Process beschreibt die Gesamtsicht auf die Integration verschiedener SAP-Cloud-Anwendungen untereinander und visualisiert das Verständnis im Prozessablauf. Es handelt sich dabei um die Prozesse Lead to Cash, Soruce to Pay , Hire to Retire und Travel to Reimburse.

Workflow Management

Die Kategorie Workflow Management enthält fertige Vorlagen für die Anlage von Processes, Business Rules und Visibility Scenarios als Teil von SAP Intelligent Business Process Management (SAP Intelligent BPM) in der SAP Business Technology Platform.

Es gibt auch noch weitere Bibliotheken z.B.:

IDocs finden Sie über Transaktion WE60

BAPIs finden Sie über Transaktion BAPI

Enterprise Services

Herausforderungen für das Schnittstellenmanagement ergeben sich nicht nur aus hybriden Landschaften, sondern auch ganz allgemein aus der Integration verschiedener Anwendungen. Klassische Fragestellungen sind z.B.: Welches Werkzeug ist für meinen Anwendungsfall der richtige ?

Wie betreibe ich meine Integrationsplattform? Wie sichere, kontrolliere und stürme ich die Integration?

Mitarbeiter , die im Umfeld Integration tätig sind, müssen eine Vielzahl von Aspekten im Blick behalten und sich permanent weiterbilden.

Container das Allheilmittel oder etwa doch nicht?

Der Container-Zug ist schon einige Jahre unterwegs - aber er ist nach wie vor Lichtjahre davon entfernt , die Universal-Lösung für alle IT-Probleme und Optimierung zu sein.

Viele Beratungsunternehmen preisen das nach wie vor völlig schmerzfrei an.

Container sollen doch alles verbessern, optimieren, beschleunigen ? Oder nicht?

Allgemeingültig betrachtet ganz sicher nicht . Diese Aussagen kommen von einem Spezialisten im RZ-/Cloud-/Großkunden-Bereich für  High-availability Cluster, Software Defined Storage, Verzeichnisdienste sowie hochskalierbare und vollautomatisierte Container-Cluster-Infrastrukturen Bereich.

Wenn man sie denn irgendwie versions-übergreifend in einem Sack mit tausenden Schrauben - deren Anzahl , Größe und Form sich im schnellen Release-Zyklen-Wahnsinn  permanent verändern - auch reproduzieren könnte. Das ist in Produktivumgebungen ein relativ sinnloses Zeit- und damit Geldverbrennungunterfangen, mit dem selbst OpenShift zu kämpfen hat.

Der Container-Hype läuft ungebremst weiter. Er wächst und skaliert sich selbst in unermessliche Komplexitätsgefilde. Und vor allem bleibt er die Gelddruckmaschine Nummer 1 aktueller IT-Landschaften. 

Das Buzzword Container stellt nach wie vor allerorten einen Freibrief für Kompatibilitätsbrüche dar, für die Architekten und Entwickler noch vor wenigen Jahren geteert und gefedert worden wären- Container-„Standards“ hin oder her.

Die ganzen kleinen Blackbox-Klötzchen - sprich die Container bzw die Pods des Control Planes und weiterer Komponenten wie Pipelines - einfach irgendwie funktionieren. 

Und wenn nicht … vielleicht funktioniert ja das nächste Klötzchen. Bis zum nächsten Upgrade. Sind ja eh meist nicht mal 100 Tage bis zum nächsten Kubernetes-Major-Release und vielleicht nur die Hälfte bis zur nächsten Pipeline - oder Mesh-Release, also was soll‘s….

Ist das wirklich der richtig Ansatz für Systeme die länger bestehen sollen??

Das US-Department of Defense (DoD) hat mittlerweile erkannt , dass es dringend notwendig ist, den ständigen, agil befeuerten Renewal-Wahn und der permanenten Verkomplizierung einen Riegel vorzuschieben.

Was ist mit der UNIX Regel Keep it stupid simpel ??

Bereits Ende 2018 veröffentlichte das DoD einen Draft namens Detecting Agile Bullshit (das ist absolut kein Scherz, so lautete der offizielle Name). 

Sein Ziel: das sinnlose Verbrennen finanzieller Ressourcen (wie in den konzepbedingt stark agil-„lästigen“ DevOps-/Containerisierungsbereichen) drastisch einzuschränken.

Siehe auch:

https://thenewstack.io/the-u-s-department-of-defense-on-how-to-detect-agile-bs/

Sowie ebenfalls als Direktlink:

https://media.defense.gov/2018/Oct/09/2002049591/-1/-1/0/DIB_DETECTING_AGILE_BS_2018.10.05.PDF

Im Grunde genommen spiegelt die Aufteilung in immer komplexer werdende, kleine und extrem kurzlebige Software-Häppchen auch die Entwicklung wider, die sich in unserer Gesellschaft - leider, muss man sagen - mehr und mehr erkennen lässt.

Häppchen müssen stets mundgerecht serviert werden, egal ob‘s hier und da mal nicht so schmeckt oder passt, wie es soll. 

Schnell - Schneller am Schnellsten

Das ist das Motto in der Software-Entwicklung die frage stellt sich hier ob nicht ein konzipieren und überdenken der Komponenten durchaus Sinn macht?

Aber dieser Geschwindigkeitswahn spiegelt sich in der Gesellschaft wieder , das alles so aufbereitet werden muss , dass auch Rezipienten mit einer maximalen Aufmerksamkeitsspanne von 30 Sekunden nicht sofort gelangweilt sind.

…die nach wie vor schmerzhafte Realität…

Egal , wie gut die Tools sind : Leider zeigen fast alle bisherigen Erfahrungen, dass er allerwichtigste Teil gern komplett übersprungen wird - nämlich der zwingend erforderliche und sehr sorgfältige durchzuführende Evaluierungsprozess, dessen Ergebnis darüber entscheidet, ob eine Container/Microservice-Landschaft für das eigene Unternehmen bzw bestimmte Produktionsbereiche überhaupt Sinn macht.

Oft wurden bestehende nicht Containerisierung  sehr gut funktionierende - Plattformen aufgrund von Präsentationen von Beratungsfirmen bezüglich wir skalieren mal auf Knopfdruck der kostspieligen Container-Abrissbirne übergeben.

Die traurige Bilanz, die selten in den Werbeblasen der Consulting-Unternehmen auftaucht , ist: Bis heute hat ein gutes Drittel der Firmen ihre Projekte zur Containerisierung in Teilen bzw. komplett wieder eingestellt. Und gerade mal ein Viertel der Firmen , die sich überhaupt mit Containern beschäftigen, setzen diese auch halbwegs produktiv ein. Für die anderen gilt: zu teuer, zu aufwendig, auf bestehende Strukturen nicht effizient anwendbar. Für ein zuvor gut funktionierendes Unternehmen kann eine im Vorfeld nicht sorgfältig evaluierte Umstellung auf Container das komplette finanzielle Aus bedeuten.

…und die Komplexitätsfalle

Ein zwangsläufiges Ergebnis , werden den Unternehmen doch oft - wie auch in der Vergangenheit das tolle Cloud-Thema - Technologien zu einem Zeitpunkt als reif verkauft , zu dem sie es lange noch nicht sind. Das Stichwort an dieser Stelle sei ein in einigen Unternehmen oft auf Biegen und Brechen durchgezogener Einsatz des permanently moving targets Vanilla Kubernetes . Noch dazu mit (den dann zwingend benötigten und) zahlreichen, angeflanschten 3rd-Party-Produkten wie Pipelines und Meshes. Natürlich mit - zu Kubernetes -meist völlig asynchronen Produktzyklen ebendieser Produkte.

Daher gilt nach wie vor bzw aktuell umso mehr: Der wichtigste Punkt vor jeder strategischen „Wir containerisieren jetzt einfach mal „ Entscheidung besteht darin, einfach mal das Hirn einzuschalten und dann eine sehr , sehr sorgfältige Evaluierung vorzunehmen, ob Container/Microservice-Landschaften für eine Optimierung des eigenen Unternehmens überhaupt geeignet sind.

Es sei denn, man hält sprechende Gummibärchen in der Werbung für echt.

Dann kann man sich diesen Punkt schenken.

… leider noch mal die traurige Realität

Umstrukturierungen waren in der Vergangenheit erfahrungsgemäß in den wenigsten Fällen tech-driven motiviert. Oder gar sorgfältig vorab evaluiert. Da geht es mehr um möglichst farbenfroh präsentierten Nonsens des jeweiligen Consulting-Unternehmens.

Und da wären wir wieder: Digitalisierung. Nachhaltigkeit. Container in der Cloud. Cloud-Native, KI und Machine-Learning-Systeme.

Na klar!

Irgendwann setzt die Realität und mit ihr die Ernüchterung ein. 

Und die Tech-,HR-und Buchhaltungsabteilungen stellen unter dem Strich fest, dass - neben der nach wie vor bedenklichen „Sicherheit „ von Container-Clustern in der Cloud - deutlich mehr Budget , Personal und Arbeitsstunden verpulvert wurden, als es die wunderschönen PowerPoint-Präsentationen doch ursprünglich gepriesen hatten. 

Aber dafür steckt das Unternehmen mittlerweile wenigstens im stahlharten Vendor-Lock 

des immer teurer werdenden Container-Cloud Hosters.

I-a-a-S, P-a-a-S, F-a-a-S , Serverless,NoOps Nach dem Hype ist vor dem Hype

Hey Leute wie wärs zur Abwechslung mal mit B-a-a-S: Brain as a Service?

Fazit: 

Fakt ist Conainer Cluster können mittlerweile viel . Richtig viel.

Aber eben nach wie vor nicht alles . Und sie passen nicht für jeden Einsatzzweck.

Die fünf Schlüsselworte sind und bleiben: Vorher sehr, sehr sorgfältig evaluieren . Punkt 

Meine Gedanken zum Endpoint - Schutz

 Endpunkte sind alle Elemente eines IIoT-Systems, die sowohl Rechen- als auch Kommunikationsfähigkeiten haben und funktionale Fähigkeiten zur Verfügung stellen. Dabei kann es sich um Edge-Geräte, Kommunikationsinftastruktur, Cloud-Server oder irgendwas dazwischen handeln. 

Jeder Endpunkt hat unterschiedliche Anforderungen und Hardware-Einschränkungen, die sich auf das erreichbare Schutzniveau auswirken. Die Sicherheitsmechanismen und- Techniken sollten auf die Endpunkte je nach ihren spezifischen Funktion und ihren Sicherheitsanforderungen angewendet werden.

Endpoint Protection stellt die Verfügbarkeit, Vertraulichkeit und Integrität der vom Endgerät ausgeführten Funktionen sicher.

Die Endpoint Protection sollte mindestens diese Sicherheitsfunktionen berücksichtigen:

Endpoint Physical Security bietet physischen Schutz des Endpunkts mit Mechanismen zum Schutz vor Manipulationen und Diebstahl, um unkontrollierte Änderungen oder das Entfernen des Endpunkts zu verhindern.

Endpoint Root of Trust bietet eine Grundlage für die Sicherung anderer Funktionen am Endpunkt, von der Hardware bis hin zu Anwendungen einschließlich Firmware, Virtualisierungsschicht , Betreibssystem, Ausführungsumgebung und Anwendung. Außerdem bietet sie Vertrauen in die Identität des Endpunkts.

Die Identität eines Endpunkt basiert auf den inhärenten Eigenschaften eines Endpunkts, die ihn von anderen Endpunkten unterscheiden. Die Identität muss mit Beweisen oder Zeugnissen untermauert werden, die die Identitätsbehauptung bestätigen und als Referenzen bezeichnet werden.

Endpoint Integrity Protection stellt sicher, dass sich der Endpunkt in der Konfiguration befindet, die für eine vorhersehbare Ausführung seiner Funktionen erforderlich ist.

Die Endpoint Access Control stellt sicher, dass eine ordnungsgemäße Identifizierung , Authentifizierung und Autorisierung durchgeführt wird, bevor Ressourcen oder Dienste gewährt werden.

Endpoint Secure Configuration and Management steuert die Aktualisierung von Sicherheitsrichtlinien und- Konfigurationen auf dem Endgerät, einschließlich Upgrades und Patches für bekannte Sicherheitslücken.

Die Überwachung und Analyse von Endgeräten umfasst Integritätsprüfungen, die Erkennung von bösartigen Nutzungsmustern, Denial-of-Service-Aktivitäten, die Durchsetzung von Sicherheitsrichtlinien und Analysen, die Sicherheitsleistungsindikatoren verfolgen.

Endpoint Data Protection bietet Kontrollen zum Schutz der Integrität, Vertraulichkeit und Verfügbarkeit der Daten.

Endpoint Security Model and Policy regelt die Implementierung von Sicherheitsfunktionen auf dem Endpunkt.

Sicherheitsbedrohungen und Schwachstellen auf Endgeräten

Endgeräte haben viele potenzielle Schwachstelle, die für böswillige oder unbeabsichtigte Fehler anfällig sind.

Wie in der Abbildung dargestellt gibt es in jedem der folgenden Bereiche ein breites Spektrum an Bedrohungen und Schwachstellen in verschiedenen Aspekten der Endgeräte.

1 => Änderungen an Hardwarekomponenten und Konfiguration

Die Integrität der Hardware muss während des gesamten Lebenszyklus des Endgeräts gewährleistet sein, um unkontrollierte Änderungen an den Hardwarekomponenten zu verhindern. Eine mögliche Schwachstelle der Hardware ist die Aneignung eines Teils der Hardwareressourcen. Der Endpunkt muss in der Lage sein, sich vor unbefugtem Zugriff und der Vereinnahmung von Schlüsselressourcen wie Speicher, Verarbeitungszyklen und privilegierten Verarbeitungsmodi zu schützen.

2,3 => Abfangen oder Überschreiben des System-Boot-Prozesses

Der Endpunkt-Boot-Prozess kann durch Änderung der Firmware-Schnittstelle zwischen der Hardware-Plattform-Firmware und dem Betriebssystem, wie z. B. dem Unified Extensible Firmware Interface (UEFI) oder dem Basic Input/Output System (BIOS), verändert werden. Änderungen an den Bootloads sind eine weitere Bedrohung, da sie die Integrität des Endgeräts gefährden könnten, indem sie nicht autorisierte oder unsichere Versionen des Betriebssystems starten. Angriffe auf dieser Ebene könnten auch den normalen oder sicheren Startvorgang des Endgeräts, die Erkennung aller Hardwareressourcen und die Schaffung einer soliden Vertrauensbasis für die Sicherung anderer Komponenten beeinträchtigen.

4,5 => Kompromisse bei Gastbetriebssystemen, Hypervisoren und Separationskerneln:

Diese Softwareschichten steuern die Zuweisung von Hardwareressourcen an Anwendungen. Angriffe auf diese Schichten können das Verhalten des Systems verändern, die Umgehung von Sicherheitskontrollen durch Informationsflüsse ermöglichen, das Verhalten des Systems verändern, die Umgehung von Sicherheitskontrollen durch Informationsflüsse ermöglichen und Angreifern einen privilegierten Zugriff auf Hardware- und Softwareressourcen von Endgeräten ermöglichen. Sobald der Angreifer Zugang zu dieser Ebene erlangt hat, hat er die Möglichkeit, den gesamten Software-Stack zu beeinflussen und die auf dieser Ebene eingebauten Sicherheitskontrollen weiter zu verändern.

7,8,9 => Unerlaubte Änderungen an der Anwendungssoftware oder der offengelegten Anwendungsprogrammierschnittstelle (API)

Endpunktanwendungen sind häufig das Ziel von Malware oder eines Angreifers, der versucht, den Endpunkt zu infiltrieren und zu kompromittieren. Die Ausführung bösartiger Anwendungen oder das Überschreiben von Anwendungs-APIs kann sich negativ auf die Vertrauenswürdigkeit des Endpunkts auswirken. Offengelegte APIs sollten auch gegen Denial-of-Service-Angriffe geschützt werden, bei denen der ständige Zugriff von nicht autorisierten Benutzern die Reaktionsfähigkeit und den Zugriff auf die offengelegten Funktionen einschränken könnte.

10 => Schwachstellen des Verteilungsprozesses

Fehler und potenzieller bösartiger Code können auch als Teil des Bereitstellungsprozesses in den Endpunkt eindringen, z. B. durch falsche oder bösartige Installationsskripte, abgefangene Kommunikation oder nicht autorisierte Ersetzung eines Pakets auf dem Update-Server. Die Verringerung möglicher Endpunktkonfigurationen bei umfangreichen Endpunktbereitstellungen ist wichtig, um die Komplexität und die Schwachstellen im Bereitstellungsprozess zu reduzieren.

11 => Unerwünschte Änderungen an Endpunktdaten

Daten auf dem gesamten Endpunkt, von der Low-Level-Firmware bis hinauf zum Software-Stack, stellen einen wichtigen Bereich für Schwachstellen dar. Zu diesen Schwachstellen gehört der unbefugte Zugriff auf unternehmenskritische oder private Daten. Angreifer können das Verhalten des Systems durch Einspeisung falscher Daten beeinträchtigen. Denial-of-Service-Angriffe auf den Datenzugriff können die rechtzeitige und genaue Ausführung der Endpunktfunktionalität behindern, was zu kostspieligen Ergebnissen führt.

12 => Verstoß gegen das Überwachungs- und Analysesystem

Ein Angreifer könnte sich Einblick in die Funktionen des überwachten Systems verschaffen. Beispielsweise könnte ein Angreifer Überwachungsdaten so verändern, dass es so aussieht, als ob ein bestimmtes Ereignis nicht eingetreten wäre. Die Modifizierung der Sicherheitsprotokolle und Überwachungsdaten kann zu unentdeckten Schwachstellen oder gefährdeten Zuständen führen. Infolgedessen würden Angreifer von einer Abdeckungslücke profitieren, indem sie die Hardware und Software von Endgeräten kompromittieren oder nach einem Angriff Beweise für ihre Aktivitäten vernichten.

13 => Schwachstellen in Konfiguration und Management

Eine Schwachstelle im Konfigurations- und Verwaltungssystem kann durch eine unsachgemäße Zugriffskontrolle auf das Konfigurationsverwaltungssystem, das Einfügen nicht autorisierter Änderungen in das System oder die Beschädigung von Aktualisierungsnutzdaten entstehen. Aktualisierungen der Endgeräte sollten so geplant und verwaltet werden, dass die Zahl der verschiedenen Betriebskonfigurationen begrenzt und die Fragmentierung der Flotte verringert wird.

14 => Unkontrollierte Änderungen der Sicherheitspolicy und des Modells

Änderungen der Sicherheitspolitik und der abgeleiteten Sicherheitsmodelle stellen eine ernsthafte Bedrohung für das System und seine Endpunkte dar. Ebenso sind Schwachstellen in der Sicherheitspolitik ein Bereich, der von potenziellen Angreifern ausgenutzt werden kann.

15 => Schwachstellen in der Entwicklungsumgebung

Die Einführung von Schwachstellen während des Lebenszyklus der Softwareentwicklung kann die IIoT-Systeme anfällig für Angriffe machen. Diese Schwachstellen können während der Architektur, des Entwurfs oder des Schreibens des Codes eingeführt werden. Die Verwendung anfälliger oder bösartiger Bibliotheken oder nicht vertrauenswürdiger Entwicklungs-Frameworks kann dazu führen, dass sie in den resultierenden Code des IIoT-Systems aufgenommen werden.