Kolumne: Stropek as a Service

Dokumentation ist nicht alles: Wir Entwicklungsteams müssen der DSGVO Leben einhauchen
Keine Kommentare

Das Internet ist angesichts der Datenschutz-Grundverordnung (DSGVO) in Aufruhr. Jeden Tag flattern E-Mails in mein Postfach, in denen mir von allen möglichen Organisationen in blumigen Worten versichert wird, wie sehr ihnen Datenschutz am Herzen liegt und dass ich mit nur einem Klick dafür sorgen kann, dass mir keine wichtigen Informationen in den diversen Newslettern entgehen.

Zwischen diesen Nachrichten finden sich auch immer wieder welche von Beratern, die vor drakonischen Strafen bei Datenschutzvergehen warnen und mir gleichzeitig ihre Hilfe anbieten. Natürlich wenden sich auch unsere Kunden an uns. Schließlich sind wir SaaS-Anbieter und sie müssen daher eine Vereinbarung über eine Auftragsverarbeitung nach Artikel 28 DSVGO abschließen.

Dokumentation als heilige Kuh

Meiner Ansicht nach ist die DSGVO vom Grundsatz her eine gute Sache. Eine Vereinheitlichung der Richtlinien zum Schutz personenbezogener Daten in der EU schätze ich persönlich als positiv ein. Mein Problem mit der Umsetzung der DSGVO ist aber, dass für die meisten Unternehmen der Dokumentationsaspekt das Ein und Alles ist. Statt darüber nachzudenken, welche Daten man tatsächlich speichern will und wie man diese schützen kann, macht man sich „fit für die DSGVO“, indem man möglichst viele Listen und ausgefeilte Verträge erstellt. Kunden gaukelt man vor, sie hätten Kontrolle, indem man sie um ihre Zustimmung zur Verarbeitung ihrer Daten bittet. Wenn sie den entsprechenden Service in Anspruch nehmen wollen, haben sie aber keine wirkliche Wahl.

BASTA! 2018

Testing in production

mit Nico Orschel (AIT GmbH & Co. KG)

Microservice Collaboration (Part 1 + 2)

mit Sam Newman (Independent Consultant)

Legacy mit Domain-Driven Design verbessern (Teil 1 + 2)

mit Dr. Carola Lilienthal (Workplace Solutions)

Als SaaS-Anbieter nehme ich in der Beziehung zu unseren Kunden leider den gleichen Trend wahr. Mit den Kunden, die sich bei uns wegen einer entsprechenden Auftragsverarbeitungsvereinbarung melden, muss ich z. B. darüber diskutieren, ob wir ihnen eine Kopie unseres Verarbeitungsverzeichnisses nach Artikel 30 DSGVO zur Verfügung stellen oder nicht. Wieder geht es nur um Dokumentation. Unsere technischen Schutzmaßnahmen wurden nicht einmal stichprobenartig hinterfragt.

DSGVO als Chance

Als Entwicklungsteams haben wir aus meiner Sicht die Verantwortung, über die Dokumentation der Datenverarbeitung hinauszugehen. Wir müssen dafür sorgen, dass unsere Systeme tatsächlich sicherer werden. Als Technikerinnen und Techniker wissen wir, dass das kein einfacher und billiger Prozess ist. Datensicherheitsmaßnahmen sind oft komplex. Eine besondere Herausforderung ist es, Sicherheit zu erhöhen, ohne den Benutzern den Umgang mit den IT-Systemen zu erschweren. Wir sollten die DSGVO als Chance wahrnehmen. Das Rauschen im Blätterwald hat Aufmerksamkeit auf das Thema gelenkt und dafür gesorgt, dass bei vielen Gremien, die für die Budgetvergabe verantwortlich sind, Geld für sicherheitsbezogene Projekte lockerer sitzt als früher.

Cloud-basierte PaaS-Dienste

Das zweite große Problem, das ich mit der DSGVO-Diskussion habe, ist das ständige „Cloud-Bashing“. Cloud-Computing wird nicht selten pauschal als unsicher und nicht DSGVO-konform dargestellt. Meiner Erfahrung nach ist das genaue Gegenteil der Fall, insbesondere wenn es um kleine und mittelgroße Organisationen geht. Dort ist das IT-Budget naturgemäß limitiert. Das Geld, das vorhanden ist, muss in funktionale Anforderungen gesteckt werden. Investitionen in Hard- und Softwaresysteme zum Datenschutz sowie in die sicherheitsbezogene Konfiguration und Wartung der eingesetzten Komponenten kommen da meistens zu kurz.

Bei den großen Cloud-Computing-Anbietern für den geschäftlichen Bereich, wie Microsoft, Amazon und Google, sieht die Sache anders aus. Sie können Skaleneffekte nutzen, also hohen Aufwand in die Entwicklung standardisierter Sicherheitsprodukte und -prozesse stecken und aufgrund der riesigen Anzahl an Kunden den Preis dafür trotzdem niedrig halten. Organisationen, die selbst nicht das Budget für Datensicherheitsmaßnahmen auf Weltklasseniveau haben, sind in der Cloud meistens besser aufgehoben, als im eigenen Rechnerraum.

Ein konkretes Beispiel

Ich möchte diese Aussage nicht nur allgemein halten, sondern an einem Beispiel konkretisieren. Eine grundlegende Sicherheitsmaßnahme ist der richtige Umgang mit Zugriffsschlüsseln, Connection-Strings, API-Keys und anderen Geheimnissen. Eigentlich gehört das zum kleinen Einmaleins der Sicherheitstechnik und jedes Entwicklungsteam sollte dafür etablierte Prozesse und Tools haben. In meiner Praxisarbeit mit Kunden sehe ich leider das genaue Gegenteil. Geheimnisse, Verschlüsselungsschlüssel und Zertifikate liegen unverschlüsselt auf Festplatten, sind im Quellcode zu finden oder landen in der – im Extremfall extern zugänglichen – Quellcodeverwaltung. Zugangsdaten zu Produktionssystemen sind leicht zu erraten, stehen einer großen Anzahl an Teammitgliedern zur Verfügung und werden praktisch nie verändert.

Stellen wir uns als erstes die Frage, wie es eigentlich sein sollte:

  • Geheimnisse, Schlüssel und Zertifikate sollten nie im oder beim Quellcode gespeichert werden.
  • Der Kreis an Personen und Systemen, die Zugriff auf diese Daten haben, muss so klein wie möglich gehalten werden.
  • Wenn Menschen auf diese sicherheitskritischen Daten zugreifen, sollten wir uns nicht auf Benutzernamen und Passwörter verlassen. Multi-Factor Authentication (MFA) in Verbindung mit einer Risikoabschätzung in Echtzeit auf Basis von Benutzeraktivität, Ort des Benutzers, Art des Endgeräts etc. ist wünschenswert.
  • Wenn Software auf die sicherheitskritischen Daten zugreift, sollte dies über Geheimnisse (z. B. Client Secret, Zertifikat) erfolgen, die automatisch generiert werden, für keinen Menschen zugänglich sind und regelmäßig rotiert werden.
  • Gespeichert werden sicherheitskritische Daten in einem dafür optimierten Hard- und Softwaresystem, das besonders hohen Sicherheitsstandards entspricht. Außerdem muss es Funktionen bereitstellen, mit denen Zugriffsschlüssel einfach, robust und ohne Systemausfall rotiert werden können, damit mit in falsche Hände geratenen Geheimnissen nicht langfristig Schaden angerichtet werden kann.

Wer diese Anforderungen in einem eigenen Rechenzentrum erfüllen will, hat ein größeres Projekt vor sich. Ich kenne kein kleines oder mittelständisches Unternehmen, das so weit geht. Fast alle Teams wissen, dass man es so machen sollte. Der Zeit- und Budgetdruck der täglichen Arbeit lenkt den Fokus aber in eine andere Richtung und man geht gefährliche Kompromisse ein.

Azure Key Vault

Was könnte beispielsweise Microsofts Azure-Cloud in diesem Bereich für uns tun? Azure Key Vault ist dort der ideale Platz, um Geheimnisse (z. B. Connection-Strings, API-Keys etc.), Verschlüsselungsschlüssel und Zertifikate zu speichern. Man kann sich Key Vault wie einen Passwortmanager vorstellen, den man selbst benutzt (z. B. KeePass), nur eben für die Verwendung durch Software mit Hilfe entsprechender APIs. Key Vault ist FIPS 140-2 Level 2 zertifiziert, Hardware Security Modules (HSMs) sind verfügbar, der Zugriffsschutz erfolgt über Azure Active Directory und das System enthält umfangreiche Funktionen zum Protokollieren aller Zugriffe. Damit erfüllt Key Vault alles, was man von einer professionellen Lösung in diesem Bereich erwartet.

Besonders interessant finde ich aber den preislichen Aspekt: Key Vault ist ein sogenannter Serverless Service. Als Mitglied eines Entwicklungsteam brauche ich also nicht über VMs, Patches, Skalierung etc. nachzudenken. Ich lege meine Geheimnisse ab und bezahle auf Basis der Anzahl der Zugriffe und Schlüssel. Die dabei entstehenden Kosten sind für durchschnittliche Geschäftsanwendungen minimal. 10 000 Zugriffe auf ein Secret (z. B. Connection-String) kosten in der Summe 0,026 €. Ich habe noch nie ein Projekt gesehen, bei dem die Nutzung von Key Vault an den Cloud-Kosten gescheitert wäre.

Azure Managed Service Identities

Die Frage, die noch bleibt, ist, wie man auf Key Vault zugreift. Eine Entwicklerin, die während des Testens auf Key Vault zugreifen will, braucht dafür einen Zugriffsschlüssel oder ein Zertifikat. Gleiches gilt für eine Software, die auf einem Server läuft und etwas von Key Vault braucht. Wir haben hier ein klassisches Henne-Ei-Problem.

Microsoft hat dieses Problem erkannt und bietet mit Managed Service Identities (MSI) eine Lösung. Am Entwicklungsarbeitsplatz verwendet das MSI-API einen der folgenden Wege, um zu einem Accesstoken für Key Vault zu kommen (standardmäßig werden alle drei durchprobiert, dieses Verhalten ist aber steuerbar).

  • Nutzung des Azure-Accounts, der in Visual Studio eingerichtet ist
  • Nutzung des aktuellen Azure-Accounts des Azure CLI
  • Verwendung des Azure-AD-Kontos der Entwicklerin, wenn das lokale AD mit Azure synchronisiert wird und sie an einem Entwicklungsarbeitsplatz arbeitet, der zur AD-Domäne gehört

In jedem Fall muss sich die Entwicklerin bei Azure anmelden und kann dafür MFA nutzen. Am Server (VM, Azure App Service) reduzieren sich die Konfiguration und der Code für das Erhalten eines Accesstokens auf ein Minimum. Der notwendige Service Principal wird in Azure AD automatisch gewartet (inklusive Rotation der Secrets). Für den .NET-Code gibt es das NuGet-Paket Microsoft.Azure.Services.AppAuthentication, das die Aufgabe auf einen Zweizeiler reduziert (Listing 1). Für andere Sprachen steht unter anderem ein Web-API zur Verfügung. In keinem Fall braucht man sich um irgendwelche Geheimnisse im Quellcode oder in Konfigurationsdateien zu kümmern.

MSIs sind als kostenlose Services in Azure Active Directory (auch in der kostenfreien Variante) enthalten.

public async Task Get()
{
  // Get MSI token provider
  var azureServiceTokenProvider = new AzureServiceTokenProvider();

  // Get access token for Key Vault
  var token = await azureServiceTokenProvider
    .GetAccessTokenAsync("https://vault.azure.net"); 

  // Use MSI to get a KeyVaultClient
  using (var kvClient = new KeyVaultClient(
    new KeyVaultClient.AuthenticationCallback(
      azureServiceTokenProvider.KeyVaultTokenCallback)))
  {
    var secret = await kvClient.GetSecretAsync(
      "https://msi-demo-vault.vault.azure.net/secrets/API-Key"); 

    // Do something with returned secret
  }
}

Cloud zur Verbesserung der Datensicherheit

Man sieht, dass die großen Cloud-Anbieter für uns SaaS-Entwicklungsteams in Sachen Datensicherheit eine Menge zu bieten haben. Ich finde, dass wir als Entwicklerteams mit tieferem Verständnis für die Technik im Hintergrund, die Verantwortung haben, auf die sicherheitstechnischen Möglichkeiten hinzuweisen. Wir sollten nicht kritiklos in den Chor derjenigen einstimmen, die die Cloud pauschal ablehnen, nur weil die Computer dann nicht im eigenen Keller stehen. Wer große Kontrolle über die IT haben will, muss meiner Meinung nach auch bereit sein, die damit verbundene Verantwortung zu übernehmen und offen über die Kostennachteile und/oder Funktionseinschränkungen bei lokaler IT informieren.

Lesen Sie alle Ausgaben der Kolumne „Stropek as a Service„!
In der Kolumne greift Rainer Stropek spannende Aspekte wie die Finanzierung, den Customer Lifetime Value, aber auch wichtige Themen wie Billing, Kundenbindung durch Qualität oder APIs auf – alles aus der Sicht eines Unternehmers, der seit 20 Jahren in der IT-Branche tätig ist und seit fünf Jahren intensive Erfahrungen mit SaaS gesammelt hat.
Unsere Redaktion empfiehlt:

Relevante Beiträge

X
- Gib Deinen Standort ein -
- or -