Leserbriefe November 2024

AI Act: Trügerische Sicherheit

(IT-Recht: AI Act: Auswirkungen in der Praxis; iX 9/2024, S. 114)

Es war leider zu befürchten: Ähnlich wie bei der DSGVO versucht die EU ihre Bürger durch (Über-)Regulierung in einer vermeintlichen digitalen Sicherheit zu wiegen.

Nach meinem Verständnis wird die KI-VO dafür sorgen, dass die EU blind gegenüber Hochrisiko-KIs werden wird. Ich vergleiche es mit Computerviren, die man nicht in der EU herstellen darf: Da man keine Computerviren herstellen darf, wird man auch nicht in der Lage sein, Antivirusprogramme gegen Computerviren zu schreiben – wie will man etwas bekämpfen, was man nicht kennt oder wo man kein Testobjekt hat?

Mit der KI-VO dürften EU-Bürger sich eigentlich nicht mehr auf Webseiten im Ausland bewegen, weil es KI-Systeme sein könnten, die nicht KI-VO-konform sind. Und wir werden sie nicht erkennen, weil wir nicht gelernt haben, solche Systeme zu erkennen.

Meine Prognose ist: Die EU hat sich mit ihrer KI-VO schutzlos gegenüber KI-Systemen aus den USA, China und anderen Technologieländern gemacht. Die EU wird irgendwann von feindlichen KI-Systemen infiltriert werden, ohne dass wir es merken. Und wenn wir es merken, wird es zu spät sein und höchstwahrscheinlich systemkritische Infrastruktur komplett übernommen haben.

Woran liegt es, dass die EU so blind, naiv oder sogar dumm ist? Meine These: In den EU-Kommissionen sitzen nur Berufspolitiker ohne nennenswerten technischen Background – und beraten werden sie von starken Lobbyverbänden.

Gerade bei der KI wäre es in meinen Augen der bessere Weg, die Bevölkerung entsprechend zu schulen, damit diese die Gefahren oder Risiken in einer digitalisierten Welt selber erkennt. Der jetzige Weg schafft nur Abhängigkeiten und eine (sicher gewünschte) Obrigkeitsgläubigkeit.

Die KI-VO und auch die DSGVO entmündigen die EU-Bürger und sedieren gegenüber den Risiken des Lebens!

Karsten Himmer, aus dem iX-Forum

Alternativen sind gut, aber Know-how fehlt

(Software-defined Storage: Open-Source-Alternativen zu NetApp und Co.; iX 10/2024, S. 94)

Nette Wünsche – aber businesstauglich? Also ich weiß nicht.

Ein bisschen wird hier ja vermischt. iSCSI ist nett – in vielen Firmen fehlt aber das Geld, dedizierte iSCSI-Netzwerktechnik anzuschaffen. Und nicht jeder Storage-Admin möchte, dass ein Netzwerker mal eben – aus Versehen – das Storage (ganz oder teilweise) lahmlegen kann. Würde man auf dedizierte Netzwerktechnik für iSCSI setzen, stellt sich die Frage nach einem Kostenvorteil gegenüber einer Fibre-Channel-Infrastruktur.

Unsere ältesten FC-Switche (8 GBit) liefen zehn Jahre ausfallfrei durch, inklusive Support. Da ist Stabilität noch was ganz anderes als bei den heutigen Netzwerkswitchen.

Bei den Storage-Partnern gab es zudem einige Leute, die einem auch mal auf den FC-Switchen helfen konnten bei Fragen oder Problemen. Sobald das Wort iSCSI fällt, wird das auf den Inhouse-Netzwerker abgetreten – der davon aber nichts wissen will …

Was das Vendor Lock-in angeht, so hat man das Problem mit NetApp doch nur, wenn man den Filer mit NDPM einsetzt. Darauf setzen dann diverse weitere Produkte auf, zum Beispiel das Backup. Wenn man das nicht eingeht, hat man mit einem Wechsel wenig Probleme.

Neues Storage daneben hinstellen, über Virtualisierungslösung die Maschinen, Speichertöpfe migrieren – fertig. Ich verstehe die Problematik nicht.

Am Ende des Tages sind Alternativen natürlich gut, um die großen Hersteller bei ihren Preissteigerungen einzubremsen. Wenn für Open-Source-Storage-Lösungen aber die Fachkraft de facto fehlt – wem ist dann damit geholfen? Am Ende findet man nur Know-how für die großen Hersteller (NetApp, HDS, Dell/EMC). Und alles auf externe Dienstleister abzuwälzen, fällt nur dem typischen Rotstift-BWLer ein.

mastermind1, aus dem iX-Forum

Tückische Gültigkeitsdauer

(Verteilte Dateisysteme: Gluster-Tutorial, Teil 2: Snapshots und TLS; iX 10/2024, S. 142)

Aus leidvoller Erfahrung kann ich berichten, dass die Erzeugung eines selbstsignierten Zertifikats mit den Kommandos aus der Doku nicht nachhaltig ist.

Je nach Default-Einstellung kann es passieren, dass das Zertifikat nur 30 oder 365 Tage lebt, danach steht das GlusterFS ohne Vorwarnung (und das gegebenenfalls sehr unerwartet).

Vorsichtshalber würde ich da eher einen Zeitraum zwischen 10 und 30 Jahren empfehlen:

# Create certificate (30 years)
openssl req -days 10950 -new -x509 ...

Dr. Peter Bieringer, via E-Mail

Bei der Einrichtung der Verschlüsselung ist darauf zu achten, dass die Zertifikate nicht ablaufen, da sonst der gesamte Cluster stoppt. Entweder erneuert man die Zertifikate regelmäßig oder man wählt eine sehr lange Gültigkeit, zum Beispiel 10 Jahre. (Stefan Kania)

Ergänzungen und Berichtigungen

Managed SOCs: Angriffserkennung durch Dienstleister; iX 10/2024, Seite 78

In der abgedruckten Tabelle der Marktübersicht fehlt der deutsche SOC-Dienstleister OEDIV. Die Daten sind in Kürze in einer aktualisierten Tabelle unter ix.de/zzsx einzusehen. Auch in den Digitalausgaben des Artikels findet sich eine aktualisierte Tabelle.

Die iX-Redaktion behält sich Kürzungen und auszugsweise Wiedergabe der Leserbriefe vor. Die abgedruckten Zuschriften geben ausschließlich die Meinung des Einsenders wieder, nicht die der Redaktion.