fdsonne schrieb:
[...] Es ist reichlich sinnbefreit derartige Updates erst in X Phasen gestaffelt und dann noch pro Phase vorab in Gruppen getestet zu verteilen, bei der Häufigkeit im teilweise Stundentakt oder noch geringer kommst du aus dem Testen nicht mehr hinaus.
Bei uns schimpft sich das
Release Management. Mit der Unterscheidung zwischen Standard Usern und Key Usern sowie der Organisation in Testringen können wir die Risiken etwaiger Rollouts von Patches, Fixes und sonstiges Releases in verschiedenen Dunstkreisen testen, bevor das große Rollout stattfindet.
Wenn ein kleiner Fix an einer zentralen Komponente dazu führt, dass eine geschäftskritische Anwendung und damit der halbe Betrieb lahmgelegt wird, was zur Folge hat, dass kostspielige Sonderschichten an Wochenenden geschoben und Vertragsstrafen gezahlt werden müssen, weil eine zentralisierte Infrastruktur einfach anfälliger ist, dann ist das Release Management meiner Meinung nach die einzig sinnvolle Lösung, wenn der Hersteller in seinem Qualitätsmanagement teilweise versagt oder dieses schlichtweg nicht existiert.
fdsonne schrieb:
Die Konsequenz aus einem solchen Versagen der Sicherheitslösung ist die schwindende Reputation des Produktes bzw. des Herstellers. Das wird sich rumsprechen und es werden sich Kunden auch nach Alternativen umsehen. [...]
Ja gut, man sieht bei Microsoft hervorragend, dass so viel passieren kann und trotzdem kein Umdenken stattfindet, weil man der Überzeugung zur "Alternativlosigkeit" folgt. Dazu musst du dir nur mal den Umgang der EU-Kommission rund um Microsoft 365 ansehen... Was interessieren einen schon Gesetze... Da ist der eigene Datenschutzbeauftrage schon mal lästig.
fdsonne schrieb:
Was haben VLANs jetzt damit zu tun?
Das klingt mir nach Buzzwordbingo. Das ist eine simple Segmentierung von Netzen, bringt dir exakt gar nix wenn die Systeme untereinander dennoch kommunizieren müssen.
Die Netzwerksegmentierung ist nur ein kleiner Teil eines ganzen Maßnahmenpaketes. Es ist tatsächlich auch so, dass gewisse Unternehmensbereiche nicht direkt miteinander kommunizieren können. Da kommen dann schon mal nette Anfragen an, ob man den Client für bestimmte Netze freischalten könne, damit man nicht in Bereich B latschen muss, um dort einen Zugriff auf die Maschinensteuerung vorzunehmen. Wird halt konsequent abgelehnt..., aber erst, nachdem die Firma schmerzlich lernen musste.
fdsonne schrieb:
Siehe oben, man kann vieles machen, auch praktisch aber der Aufwand und der Nutzen müssen im Verhältnis stehen und es muss bezahlbar sein.
"Bezahlbar" ist tatsächlich ein wunderschönes Buzzword in Diskussionen. Wie oft hat die Abteilungsleitung die Vorschläge damit abgewehrt... Wie oft hat die Geschäftsführung gesagt: "
Nö, machen wir nicht. Wir brauchen bezahlbare Lösungen.".
Gut, dann suchen wir mal "bezahlbare Lösungen":
Wir schaffen das teure ERP-System ab, ersetzen das minderwertige CRM-System, die Schrottkiste namens Telefonanlage fliegt raus, die Tools 10 bis gefühlt 100 fliegen raus, Prozesse hier und da werden umgekrempelt, die Belegschaft für Self-Services befähigt, diese in komplexeren Anwendungen ordnungsgemäß geschult, Führungskräfte weitergebildet und, und, und.
Selbstverständlich wurde viel abgelehnt. "
Wir haben für so etwas keine Zeit.". Bis zu jenem Tag, wo die Firma wieder schmerzvoll lernen musste und die Gesellschafter dann doch langsam unruhig werden, dass hier und da, und die IT-Abteilung war Spitzenreiter, viel Geld verbrannt wird.
fdsonne schrieb:
Am Ende wird der KRITIS Ausfall mehr Impact haben als irgendwelche Testsysteme. Die Frage ist, ob man im Test alle möglichen Dinge auch bedacht hat.
Lasse deinen Key Usern freien Lauf und finde es heraus. Dafür gibt es neben Produktiv- eben auch Testsysteme und neben produktiven Datenbanken auch Testdatenbanken. Let's go.
fdsonne schrieb:
[...] Weiterhin kommt noch die Unbekannte dazu, dass ein Testsystem selbst bei Bedacht darauf selten 100% dem Livesystem entspricht, einfach weil es teilweise utopischer Aufwand ist, alles zu 100% nachzubauen. [...]
Da sind wir wieder beim Release Management...
fdsonne schrieb:
[...] Man benötigt hierfür dann im Zweifel einfach den Plan B, Wiederherstellungskonzepte, Wiederanlaufpläne, IT Notfallhandbuch usw. und selbst das arbeitet noch mit Annahmen und Eintrittswahrscheinlichkeiten.
Es gibt in vielen Fällen keinen "Plan B", wenn deine Prozesse nahezu vollständig IT-gestützt sind. Einen alternativen Plan zu haben, hieße, deine Anwendungen zu diversifizieren, also mehrere Hersteller für denselben Zweck einzusetzen. Das erhöht die Sicherheit nicht, sondern schwächt sie. Warum? Schon mit Standardlösungen hadern viele Unternehmen, weil ihnen oft das tiefergehende Verständnis fehlt. Das erklärt auch, warum viele IT-Abteilungen und IT-Dienstleister einen mittelmäßigen bis schlechten Ruf haben. Lösungen implementieren? Kein Problem. Hier und da bisschen Support, aber mal da und dort um die Ecke denken? "
Sorry, keine Zeit.".
fdsonne schrieb:
Ich behaupte, diesen Zustand gibt es nicht, denn das würde bedeuten, jeden erdenklich Umstand abdecken zu können. Das wäre der perfekte Betrieb. MMn unmöglich zu erreichen.
Diese Argumentation kenne ich allzu gut aus dem Katastrophenschutz. Sinngemäß:
"
Das war unvorhersehbar."
"
Damit konnte niemand rechnen."
"E
in solches Ausmaß war nicht absehbar.".
Klar, wenn man vor allem mit Best-Case-Szenarien arbeitet und seine Fantasien nicht entfalten kann, dann kommt eben so etwas raus wie im Ahrtal. War natürlich nicht vorhersehbar... Konnte ja keiner ahnen, dass sich Wasser seine Wege sucht, wenn der Boden auf engstem Raum massiv versiegelt wurde... Und natürlich kann man so etwas nicht berechnen, schon gar nicht, wenn es Vorlagen aus anderen Szenarien gibt. Niemals. 😉
fdsonne schrieb:
Btw. was die OnPrem vs. Cloud Thematik meint, versteh ich nicht, ich zumindest kenne dieser Tage kein Unternehmen, was nicht wenigstens irgendwo auch Clouddienste nutzt. Und ich müsste lügen ob ich IT Landschaften mit Cloud only Lösungen je gesehen habe? [...]
Die hybride Infrastruktur, wo also ein Teil On-Premises und häufig der größte Teil Off-Premises extern läuft, ist die teuerste Variante. Viele Unternehmen vergessen, dass sie für die Risiken und Sicherheit in Rechenzentren (btw: nichts anderes ist "Cloud Computing") verantwortlich sind. So ein Tenant ist schnell registriert, aber die Einrichtung ist dann noch mal ein anderes Thema.
Ich gebe dir ein Praxisbeispiel:
Mein Arbeitgeber (Logistik mit mehreren Standorten in DE) hat darüber diskutiert, wie man das hauseigene "Rechenzentrum" (ein Serverraum am Hauptstandort mit vielen alten Systemen und Redundanz am zweitgrößten Standort > entsprechend mit Personal) auflösen könnte, weil "
zu teuer". Man ließ sich von windigen Beratern und Dienstleistern überzeugen, dass das Outsourcing die "
wirtschaftlich beste Lösung" sei.
Jetzt ging es noch um das technische
Wie. Zu diesem Zeitpunkt stieß ich in das Unternehmen und bekam natürlich mit, worum es ging. Auf dem Tisch lag zunächst nur ein Konzept: Alles outsourcen und rein in diverse Cloud-Lösungen und alle Standorte per MPLS anbinden, wobei ein RZ-Betreiber gleichzeitig der Knotenpunkt zum öffentlichen Teil des Internets darstellen sollte. Die Standorte sollten alle eine zweite Leitung bekommen. Wo es technisch nicht ging, LTE als Fallback.
Mein Vorschlag war das "Edge Computing", bei dem der Großteil im hauseigenen "RZ" betrieben wird, durch Digitalisierung und Transformation auslaufende IT-Services (Drucker, Großformatdrucker, Plotter, ...) outgesourct, Prozesse analysiert und optimiert, diverse alte Tools ersetzt, bestimmte Server virtualisiert und die Standorte via SD-WAN angebunden werden. Alle Standorte sollten dazu ein Fallback für die Netzwerkkonnektivität erhalten, ob nun mit zweiter Leitung oder LTE+ oder 5G+.
Entschieden hat man sich für Variante 1, um bereits nach einem Jahr festzustellen, dass sich die ursprünglich geplanten Kosten bereits verdreifacht haben. Wiederum ein Jahr später ging ein Dienstleister pleite, sodass man sich einen neuen und vor allem deutlich teureren Dienstleister dazukaufen musste, nachdem man das eigene Personal teilweise entlassen hatte. Kosten haben sich auch da nochmal verdoppelt. Dann knapp ein dreiviertel Jahr später lief der Vertrag mit dem externen RZ aus. Der neue Vertrag verursachte eine Vervierfachung der Kosten. Man konnte ja nicht erahnen, dass so viele Daten anfallen, die verarbeitet werden wollen.
Zwischenzeitlich schränkte das externe RZ die angemieteten Leitungen ein, um die Dienstequalität für alle Kunden gewährleisten zu können.
Nebenbei kämpft man mit hohen Latenzen und Datenverlusten, fehlenden Ressourcen, Unzufriedenheit in der Belegschaft und Folgekosten, die natürlich "
niemand vorhersehen konnte". Dabei hatten schon diverse Wirtschaftsprüfer die betriebswirtschaftlichen Entscheidungen klar und deutlich bemängelt und der IT-Abteilung ein miserables Zeugnis ausgestellt. Selbst die ersten beiden IT-Risikomanager bezeugten die Missstände in der IT zu Entscheidungen, die allein von den Führungskräften, aber teilweise auch von den Fachkräften angetrieben wurden. Hier und da habe ich mir auch keine Freunde gemacht, als ich Entscheidungen hinterfragte... Nun ja, man kann nicht alles haben.
Im ersten Halbjahr 2024 gab es 5 Störungen bei MPLS mit dem Ergebnis, dass alle Standorte zeitweise lahmgelegt wurden. Die Folge: Sonderschichten, Vertragsstrafen, vermeidbare Rufbereitschaften für die IT und immense Kosten, die das Unternehmen zusätzlich tragen muss. Jetzt dämmert den Verantwortlichen langsam, dass sie umdenken müssen...