The Doppler Quarterly (DEUTSCHE) Sommer 2016 | Page 74

Hardware hingegen wird als Ware behandelt und es wird erwartet , dass sie ausfällt . Architektur in der Cloud bedeutet , Software zu entwickeln , die unabhängig von jeglicher Hardware ist und automatisch wiederhergestellt werden kann , wenn Rechenknoten offline gesetzt und neue Knoten implementiert werden . Dies wird oft als unveränderliche Infrastruktur bezeichnet .
Die Schwierigkeit liegt darin , eine Veränderung bei Verstand und Denkweise herbeizuführen .
Dies ist nicht nur eine drastisch veränderte Vorgehensweise von Architekten und Entwicklern bei der Softwareentwicklung , sondern gleichermaßen eine noch drastischere Veränderung in der Art und Weise , wie Anwendungen überwacht , verwaltet , gesichert und überprüft werden . Die Konzentration auf die Technologie allein und das Ignorieren der politischen und sozialen Aspekte dieses Wandels bildet jedoch den Boden für eine katastrophale Entwicklung . Die Umstellung auf eine unveränderliche Infrastruktur und verteilte Architekturen wirkt sich gravierend auf traditionelle Unternehmensstrukturen und Verantwortlichkeiten aus .
Kontrolle oder Agilität ?
Stark regulierte Unternehmen nutzen häufig sehr strenge Kontrollen , um das Unternehmen gegen Sicherheitsbedrohungen und Schwachstellen zu schützen . Viele dieser Kontrollmechanismen werden ( oft manuell ) mit einer Reihe von Prozessen implementiert , die den SDLC drastisch verlangsamen . In einer Welt , in der alle drei bis sechs Monate etwas geliefert wird , können Entwickler innerhalb dieser Begrenzungen durchaus arbeiten . In der neuen Welt von heute , in der in immer kürzeren Abständen neue Releases gefordert werden , muss die Implementierung solcher Kontrollen neu bewertet werden .
Ich kann den Aufschrei der Sicherheits- und Complianceverantwortlichen bei dieser Aussage förmlich hören . Um es klar zu sagen : Ich stelle nicht in Frage , warum ein Unternehmen die bestehenden Kontrollen und Richtlinien benötigt . Was ich jedoch in Frage stelle , ist , wie die Unternehmen diese Kontrollen umgesetzt haben . Sehr oft werden bei der Umsetzung der Kontrollen und Richtlinien nur die Forderungen der Sicherheits- und Complianceverantwortlichen berücksichtigt . In der neuen Welt der häufigen Releases müssen Entwickler gleichermaßen als wichtige Beteiligte gesehen werden .
Es muss ein Gleichgewicht zwischen Kontrolle und Agilität bestehen . Ein Unternehmen kann sowohl sicher als auch agil sein , wenn es für diese Konstellation offen ist . Beispielsweise nutzen viele Unternehmen für ihre Anwendungen ein manuelles Zeitfenster für Sicherheitsprüfungen . Wenn diese Methode nur wenige Male im Jahr eingesetzt wird , kann sie funktionieren . Wenn Sie jedoch von mehreren Anwendungsteams mehrfach pro Monat genutzt wird , funktioniert das zum einen nicht und zum anderen ist auch keine Skalierbarkeit möglich . Die vielen Mitarbeiter , die Sie für die manuelle Prüfung der Implementierungen in einer ausgereiften Cloud-Umgebung bräuchten , können Sie gar nicht einstellen .
Die Lösung basiert auf Automatisierung und Vertrauen . Viele Sicherheitskontrollen lassen sich in die zugrundeliegenden Infrastrukturentwürfe einbinden . Da Entwickler die genehmigten , permanent ge spei cherten Images verwenden , sind viele der Sicherheitskontrollen , die früher eine manuelle Überprüfung erforderten , bereits vorhanden . Beim Build-Prozess muss ein Sicherheitscode-Scan durchgeführt werden , auf dessen Basis die Sicherheitsexperten Richtlinien durchsetzen und potenzielle Sicherheitslücken auffinden können . Der Build kann dann so konfiguriert werden , dass er fehlschlägt , wenn das Scanergebnis nicht hoch genug ist , um den etablierten Sicherheitsstandard zu erfüllen . Dies ist eine weitere Möglichkeit , um manuelle Prüfungen zu vermeiden .
Aus technologischer Sicht ist dies sehr einfach zu realisieren . Die Herausforderung besteht eher darin , die Beteiligten aus den Bereichen Sicherheit und Compliance dazu zu bewegen , sich diesem Ansatz anzuschließen .
Rechenzentrumstools und Cloud-Tools – ein Vergleich
„ A Fool with a Tool is still a Fool “. Zu oft sehe ich Leute , die mit einem Tool oder einem Anbieter verheiratet zu sein scheinen . Oder Anbieter verlangen , dass ihr bevorzugtes lokales Tool in der Cloud verwendet wird . Viele dieser Tools wurden nie für den Betrieb außerhalb der Firewall oder in einer unveränderlichen Infrastruktur entwickelt . Diese Tools bringen in der Cloud nicht nur einen geringen Nutzen , sondern verzögern auch die Bereitstellung , da sie unnötigen Aufwand für die Integration in die Cloud verursachen .
Unternehmen müssen ihre Toolauswahl neu bewerten , wenn sie auf die Cloud umstellen . Wählen Sie das beste Tool für den Job und nicht das Tool , mit dem sich jeder wohl fühlt . Eine weitere Herausforderung in diesem Bereich besteht darin , dass Entwickler mehr Transparenz bei der Überwachung und Protokollierung von Daten benötigen als je zuvor . Zu oft sind Entwickler gezwungen , Tools zu verwenden , mit denen sich die Anwender wohlfühlen . Stattdessen sollten sie Tools nutzen , die sie bei ihrer Arbeit effizienter machen .
Um es noch einmal zu erwähnen : Aus technologischer Sicht ist dies sehr einfach . Die Schwierigkeit
72 | THE DOPPLER | SOMMER 2016