IT-Trends-Blog

IT-Trends-Blog

Die neuen IT-Gesetze: Ein Lob der Automatisierung

Kategorie: Trends am Horizont

Das IT-Sicherheitsgesetz und die kommende EU-Datenschutz-Grundverordnung (EU-DS-GV) geistern aktuell durch die Presse. Auch wenn sie ganz unterschiedlich heißen, haben die Gesetze viel miteinander zu tun. Sie betreffen trotz unterschiedlicher Schwerpunkte beide persönliche Daten. Treten wir einen Schritt zurück, sind noch andere Gemeinsamkeiten zu erkennen: Zum einen betreffen beide Themen direkt auch den Zuständigkeitsbereich des CIO und beinhalten, dass die Unternehmen selbst bei Verstößen das Risiko von Bußgeldern eingehen. Zum anderen, und das ist aus Sicht der IT besonders relevant, betreffen beide Themen die Entwicklungs- und Betriebsprozesse von IT-Anwendungen, indem Anforderungen an diese definiert werden.

Der Mensch als limitierender Faktor

Häufig werden Sicherheitslücken in der Software zum Beispiel durch menschliche Fehler verursacht. Dabei ist es irrelevant, ob dies wissentlich geschieht, durch Schlampigkeit oder schlicht durch Unwissenheit. Das gilt sowohl für die Software im Speziellen, aber auch für den gesamten Herstellungs- und Deployment-Prozess, der teilweise immer noch manuell ausgeführt wird. Wie schnell ist da eine alte Version einer Komponente eingebaut, die in Zusammenarbeit mit anderen Elementen einen unzulässigen Zugriff ermöglicht. Und wie schnell ist ein Testdaten-Abzug aus der Produktion gemacht, wenn die Grenzen zwischen Produktion und Entwicklung durch DevOps verschwimmen und diese Daten doch für das Testing und die Entwicklung „ach so wichtig“ sind?

Im Kontext der personenbezogenen Daten kommt dazu, dass es für die Entwickler oft schwer zu klären ist, welche Daten eigentlich im Zusammenhang mit Personen stehen und welche Regeln jeweils gelten. Ist es z.B. ein personenbezogenes schützenswertes Datum, welche Lieferanten-Rechnungen existieren? Schnell ist da der Name des Inhouse-Nutzers Meyer bekannt, der diese freigegeben hat. Und anders als im Kontext von Daten, die über Suchmaschinen im Internet gefunden werden, besteht hier wohl kein Recht auf Vergessen. Wie hoch ist folglich das Risiko, dass nicht so offensichtliche personenspezifische Daten an Stellen gelangen, wo sie eigentlich nichts zu suchen haben?

Qualität ist wichtiger denn je

Entsprechend müssen wir sicherstellen und nachweisen, dass die von uns entwickelte Software die Datenschutz-und Sicherheits-Richtlinien einhält. Also müssen wir uns für den Entwicklungsprozess noch expliziter und nachvollziehbarer speziell mit den personenbezogenen Daten, ihrer Nutzung, der Anonymisierung etc. auseinandersetzen. Wir müssen uns Gedanken dazu machen, dass nicht durch menschliche Schritte und damit verbundene Fehler Abweichungen auftreten. Und das gilt sowohl für den Entwicklungsprozess, als auch für die eigentliche IT-Anwendung. Aber nicht nur der Schutz der Daten muss berücksichtigt werden. Auch die „Nicht-funktionalen-Anforderungen“ wie Verfügbarkeit, Skalierbarkeit, Wiederherstellungsmöglichkeiten und Notfallpläne sind bereits während der Entwicklung zu berücksichtigen. Am Ende muss eine IT entstehen, die den Datenschutz einhält, aber daneben auch noch betreibbar und flexibel bleibt.

Wir stehen somit vor der Herausforderung nach immer mehr Qualitätssicherung und insbesondere auch nach Nachvollziehbarkeit. Und das in Anbetracht dessen, dass wir immer schneller liefern müssen und hoch flexible Geschäftsprozesse mit IT-Mitteln entwickeln sollen. Ein Widerspruch? Ich denke nein. Es ist eher eine Chance, nochmal zu schauen, wo die echten Innovationsfelder für das Geschäft liegen und in all den Bereichen, die für sich keinen eigenen Beitrag leisten, soviel wie möglich zu standardisieren und zu automatisieren. Das Recht auf Vergessen ist z.B. spätestens mit den neuen Regeln ein Muss, aber nichts, womit man sich am Markt differenzieren kann.

Build-in-Qualität, Automatisierung und kontinuierliche Qualitätsüberprüfung

Natürlich können wir Qualität nicht in Software hinein-testen. Normalerweise werden konzeptionelle Fehler später beim Test gefunden, aber sie verursachen trotzdem gerne erhebliche Aufwände in der Beseitigung. Gerade im Hinblick auf die hier betrachteten Fragestellungen müssen wir bekannte Fehlerklassen direkt dadurch verhindern, dass beim Bau der Software vorgefertigte Blaupausen (i.e. Komponenten) verwendet werden, die ihrerseits gründlich geprüft sind. Das schließt die Prüfung von Dritt-Software ein. In anderen Ingenieur-Disziplinen wird das schon länger mit Prüfsiegeln, zum Beispiel für Brandmelder, erreicht.

Ein weiteres probates Mittel für größtmögliche Qualität ist die Automatisierung, wenn es um den Bau von Anwendungen und ihr Deployment geht. Dadurch können wir sinnvoll ein Vier-Augenprinzip einführen, Abhängigkeiten explizit machen, etc.. So tragen die aktuellen DevOps Ansätze dazu bei, Teile der Anforderungen aus dem IT-Sicherheitsgesetz zu erfüllen. Für das Thema Testdaten kann dies parallel eine Automatisierungskette in die Gegenrichtung, also von den Operations in das Development, leisten. Auch hier macht die Verwendung von entsprechenden Tools und ihre durchgängige Verkettung viel Sinn.

Trotzdem reicht beides alleine nicht. Wir müssen außerdem im Rahmen dieser Automatisierung dauerhafte Kontroll-Prozesse installieren. Das kann bedeuten, dass die erstellte Software immer wieder auf Konformität geprüft wird (und das natürlich soweit sinnvoll automatisch), dass Standard-Tests z.B. zum Löschen von personenbezogenen Datensätzen existieren und ähnliches. Es kann aber auch bedeuten, zu prüfen, dass keine Veränderungen an der Software stattgefunden haben, die nicht durch eine Anforderung oder Fehler begründet sind, dass nur zugelassene Komponenten von Dritt-Anbietern verwendet werden, dass Sicherheitsmitteilungen zu solchen Komponenten, Verfahren usw. laufend auf Relevanz geprüft werden und dass keine ähnlichen, den Produktionsprozess betreffenden, Abweichungen stattgefunden haben. Alle diese Prüfungen betreffen nicht nur den Entwicklungsprozess, auch in Produktion muss laufend geprüft werden, dass keine unzulässigen Zugriffe stattfinden usw. Dabei können auch Verfahren zum Einsatz kommen, wie sie heute schon zum Beispiel im Kontext von Kreditkarten-Betrugsprävention sowie -Betrugerkennung verwendet werden und die massiv auf statistische und Regel-basierte Überwachung setzen.

Gerade wenn die Entwicklung immer schneller wird (Stichwort Microservices, time to run usw.), dann steigt in meinen Augen die Notwendigkeit, Mechanismen zur Verfügung zu stellen, die menschliche Fehler ausschließen bzw. früh feststellen und das möglichst automatisiert und standardisiert. Wie sehen Sie das? Sind solche Maßnahmen eher eine Hilfe oder unnötige Bürokratie, die die heute notwendige Agilität Ihres Business stört? 

Über den Autor

Kommentar hinterlassen

Ihre E-Mail-Adresse wird nicht veröffentlicht. Pflichtfelder sind mit einem * gekennzeichnet.