Trends, Gesetze, Verschlüsselung

Es gibt aktuell drei große Trends in der Softwareindustrie. Der erste große Trend ist IOT. Das Internet der Dinge vernetzt alle Geräte und Maschinen, die Daten an Server oder sich gegenseitig senden. Das zweite große Trendthema ist die Blockchain. Ein Netzwerk, in dem kein Teilnehmer einer zentralen Organisation vertrauen muss, sondern sich auf das Netzwerk verlassen kann. Der dritte Megatrend ist die künstliche Intelligenz. Maschinen sind immer mehr in der Lage, Dinge zu erkennen, Korrelationen zu finden und Entscheidungen zu treffen.

Alle diese Trends haben eine Sache gemeinsam: Daten. Ohne Daten spielen IOT, Blockchain und KI keine Rolle. Manche behaupten sogar, dass Daten der wichtigste Rohstoff unserer Zeit ist. Jedenfalls sind Daten die Grundlage der Wortschöpfung unseres Jahrhunderts. Daten waren schon immer wichtig, aber zwei Dinge sind relativ neu. Zum einen wächst der Datenbestand weiterhin exponentiell. Zum anderen werden die Daten, die bis vor kurzem primär on-premise gespeichert wurden, in die Cloud migriert. Unternehmensdaten werden ohne großen Aufwand erfolgreich in der Cloud persistiert. Das Problem dabei ist, dass das Unternehmen dann nicht mehr alleiniger Besitzer der Daten ist. Die Daten werden einem Cloud Service Provider treuhänderisch anvertraut, der nun auch auf diese zugreifen kann.

Um die Daten in der Cloud zu schützen, hat die Regierung besondere Gesetze erlassen. Das wohl bekannteste Gesetz ist die Datenschutzgrundverordnung (DSGVO) und damit das Bundesdatenschutzgesetz (neu). Darüber wurde letztes Jahr viel berichtet. Dieses Gesetz reguliert, wie mit personenbezogene Daten umzugehen ist. Das betrifft alle Unternehmen, die europäische Kunden haben.

Es gibt allerdings auch Branchen, die mit Daten noch vorsichtiger umgehen müssen. Damit meine ich Berufsgeheimnisträger. Darunter fallen zum Beispiel Ärzte und Rechtsanwälte. Daten, die Rechtsanwälten anvertraut wurden und die von Rechtsanwälten generiert werden, müssen besonders gut geschützt werden. Dazu gibt es das “Gesetz zur Neuregelung des Schutzes von Geheimnissen bei der Mitwirkung Dritter an der Berufsausübung schweigepflichtiger Personen“. Seit November 2017 gilt dieses Gesetz und seitdem dürfen Anwälte überhaupt erst Cloud-Dienstleistungen in Anspruch nehmen. Eine Vorgabe aus diesem Gesetz ist zum Beispiel, dass Daten nur dann im Ausland verarbeitet oder gespeichert werden dürfen, wenn in diesem Land der Schutz des Geheimnisses vergleichbar ist mit dem Schutz des Geheimnisses in Deutschland.

Es gibt noch ein Gesetz, das in diesem Zusammenhang sehr wichtig ist: Der C.L.O.U.D. Act. Der C.L.O.U.D. Act ist ein Gesetz der Amerikaner. Er erlaubt es der amerikanischen Regierung jeden amerikanischen Cloud Service Provider dazu zu verpflichten, Kundendaten herauszugeben, egal wo auf der Welt diese gespeichert sind. Das hat natürlich eine dramatische Konsequenz für Daten, die besonders geschützt werden müssen. Rechtsanwälte können ihre Daten nicht einfach in ein beliebiges Rechenzentrum eines amerikanischen Betreibers in Frankfurt laden, weil die amerikanische Regierung den amerikanischen Konzern, dazu verpflichten kann, die Daten herauszugeben, obwohl die Daten in Deutschland gespeichert sind. Das ist ein echtes Problem und würde Lösungen auf Cloud-Angebote deutscher Konzerne reduzieren.

Es gibt noch eine andere Lösung: Verschlüsselung. Daten können verschlüsselt werden, bevor sie in die Cloud hochgeladen werden. Solange der Schlüssel nicht auch in der Cloud liegt, können die Daten gefahrlos weitergegeben werden. Jeder Empfänger, der den geheimen Schlüssel nicht hat, kann sie nicht lesen. Jetzt müssen nur noch die Schlüssel gut geschützt werden. Bei einer echten Ende-Zu-Ende Verschlüsselung, wie sie beispielsweise von WhatsApp oder Skype genutzt wird, kann ein Datensatz nur genau von der Person entschlüsselt werden, an die der Datensatz adressiert ist. Keine andere Person, Admin oder Regierung kann die Daten entschlüsseln, weil sie die nötigen Schlüssel nicht haben. In den letzten Jahren sind die dafür nötigen kryptographischen Routinen sogar nativ in unsere Browser eingebaut worden. Das W3C hat mit der Web Crypto API jede Web-App dazu befähigt, Daten zu verschlüsseln und wieder zu entschlüsseln. Es ist nicht mehr nötig, dazu eine eigene Software zu installieren.

Und dank dieser Verschlüsselung können wir unseren Kunden einen Sicherheitsstandard implementieren, der erstens die Gesetze berücksichtigt und zweitens Daten mit maximaler kryptographischer Sicherheit schützt.

Demo

Hier ist ein Beispiel für eine verschlüsselte Nachricht:

pzelMxzbY7p5x3OnU+7Lq0gzvSK3HV4LTBYwvtyqlpSNFtwKaXhyit3q0g8qu+QMtjD3pH4MDxzDuO0WXhrXv8E/nAYXV39b+L8OVZekxa/zszL+4sMBM2YlOt/BiMt/CA5ct8vh0b6kUDiv5pfv0kckfmiY7fq6S7dRWoP+4fCBbeNzcC2sI2HdjdcYYB9tv/yahlr+9GZ9Z3OYbaWaXX/4Lf3Q/rN9bCTmHNES//76ZjVnko2RC9cyRPKeRKnIRVC8OnGewFzPqMvBkkL6D3nRBd+f1FeyO1LkE1E2AAvqjWTvShASpnGkem5VXyoQzO4WgJQXJdx30SbNr0xMvRj7fzsK2F6Jl4MWqZAud+CjIUzqtkFWbBtBdojsek2LuM+D+EiA4lqwMXa64xZ5SWAFS6EEt4ZOkE9CcNGdDAmELj4IugSlea9/wDP3UsDx+4QX+FuV125wyigFkz+JFnbYg93LbqyvoPBP0Quay2IWno8lDo9NdM+1PCKRDHB++9kjT7t468qrdRqgKwuNlOb3W8WrJMLbAd8B3npHmHlIBxVUXrHZicACiAkcv8JAreguh47Bkp9a0OixYnShfeCi+aCo/oeA3XiddZANkO7oGHHPhAaguWaG3VHZ0spPO80FK6o4OUpvkaOF9QYf+rURUMxh96E9Z/aQwFyoVJw5/TcbUMJQdggiu2osszFFYCfWd3gOnVpe2LVZVM8bvQssH9k9AlRyH4j+jabzdYqrDDK8l4NQR3yRIcYbCoJyMbuWiPlSBy0jnLU5HOV8WfgnKxJKvtQdC+ykN3qXHM/uGYPmcp4fkVJwF1a3wkqkg7G610OAVTE0D0AK5a7pdOKWDuk78M6Hd+1+b6brMDhTyuB+LUD9dC4WnmGGi74TVvTQ2I8Oaa+TFDqreV2e+8eJCSgvZjSszKvOZ/vbXKhvJh0+7JNZuZQMyuvloiyjuS8m553RDgrgm5LRkp7xUFEXcXIkxmPUtWaOOVpcggtCm0o78iP2KLHNUz28EP/sAPWluucxCjCjggaJ9bJ7eOD56jBnlORYFQSTeVQXWlqIJta6rIVyW1WpY7mhhfNnOr5qFfa6uYOubBgwzs3knof88codUMe0lor/NQIKUkxIB5FNWEjbeNvnczJtsEfP86Bask1X35O/6I3Nwl0xKDctBQ834YWJk4+TLtFMf3Gaf3C4dYVGJPhoK7XWLZf0YbRaxcZ876bADQNH13aiK8TD6cWJ93Q45DFPQMDL0LyRgEWQjvIWHPc29QGXyyOZhDnQdTCOMjLGV7mdijnuKvCkc644yr3IANNWNb7D0lBuJC6wxbdeQ3lJgrilvTlzLvc14kIN48IvNAn9wxiXR1OIp9yeW7mXd158YDoTkW8S+PxCa4k/9qLW933LM9gTxpXqwKOnpby27sUCGrgb0Gu7NdN9NYtYQfS9ZDCWa1Oy39n9I7XIl8X0KaLI9MGCsrfTDZ7KTD1Zk9rWsRXIB+W11ftKzG8GN9ezO9u0RzHBA/5cCyyrs8i1nmgM4jLGKDwH5od6BHL8VbXgk8FPlF6zz8C1liN8RmHdrJ3edqtEA/rgcrXEOfkB2O9cqzJVm9ZwrVvQLalLQvLQcqG5Vhes28FGPSJH+kb/4XZ7Blx1sdsHEKBHc9IHNd8coUEgfgADSsez/ftww8OEPdrLeo1Lwipv6fUiMwJ31jaYDA2sthV6clEtQ4X9iWeprjEfQr1hWSqgyj6YKojZno1OuBwKGS+rqXbDqO97CpsyiXE+jbqYPw+uxCPBeiRf3cmh0BYoKJH83y19SUgqOqtkEjrho8Eme3OL0GcQDoflWG8DjzTZjp3xlwqOoVTa9zKeDWqYSBoMI73uxAe8kjgnIYRXhroh9j9gVKXGkdhN3ZLXJCUQt5d+ebKYJ8aFbfykE9WtSTbb8cmh8XNAbfI1i+vdQNvCHAVyWqNMT6y0KSUOR3uxQTRvXFXTvONNBqPJOb8hN/Io1iqGaBbADjUlu2xhcaZV4yApMDa02kzuslNfxY1hNu0lXlsJ4dJr4TidyCx5Io0jzUq9krxY3BmQ8asm/QElcGWEYkgroyvNvCZUYYriyCGORynXQOktgWdO0i/Z0N8JN3pm3WhTCOrh

Diese Nachricht ist mit den Verfahren Salsa20 (stream cipher developed by Daniel J. Bernstein) und Poly1305 (cryptographic message authentication code (MAC) created by Daniel J. Bernstein.) verschlüsselt worden. Diese Verfahren sind nicht Teil der Web Crypto API sondern können über die NACL-Bibliothek eingesetzt werden. Um die obige Nachricht zu entschlüsseln, kann die Beispielseite https://tweetnacl.js.org/#/secretbox verwendet werden. Dort dann der Cipher-Text in das Box-Feld kopiert werden. Gleichzeitig müssen auch noch folgende Nonce und folgender Schlüssel kopiert werden. Der Schlüssel müsste natürlich geheim gehalten werden.

Nonce
BjPvjG2ibzqnTayXhNCtxxo5J7t72Qfi

Schlüssel
8qsjT9mNMwXUEpkthvPP3JZPhwEuwg077sJV+IikwSo=

A service bus is not for querying or heavy data

Systems get more distributed these days. One way to provision communication between all components or services of a system is with a service bus. A service bus utilizes messages and queues to get information from component/service A to component/service B. But what do we need a service bus for? And what do we need the underlying queues for?

  • Communication to integrate services? No, communication between services can be achieved more easily with less overhead and much faster by using web services (WCF, SOAP, HTTP, …).
  • Service discovery? No, service discovery would be necessary if we wouldn’t know the services of the system. And if we don’t know them, there are better and more specialized solutions available, like Jini or UPnP.
  • Reliability and failure recovery? Yes, that is the main advantage a service bus gives us. Every single message must not get lost, even if services fail, are under high pressure or are down. That is what we need queues for.

Using reliable messaging has many advantages. But it also comes with a few pitfalls. In this post I am going to address two problematic uses of a service bus.

Querying

Queries or request/response style of communication is highly ephemeral and synchronous. All queries are initially triggered by a user and the queried service could query other services. A user will wait for a response but rarely more than about 7 seconds. He or she is likely to cancel the request if it takes longer [1]. If the user gets an error, he/she will simply request again. So first of all, there is no need for a reliable query and its overhead. A query does not need to be queued until the serving endpoint gets the chance to serve it. Instead, queries have to be fast, regardless of how stressed the rest of the system is. Messaging is asynchronous. If part of the system or the service bus itself is under pressure, query-messages would reliably queue up, even if the user canceled the request. If the user requests again, he or she will introduce new messages into the service bus and therefore increase the pressure for services and the bus. So second of all, queries are getting slower in a stressed system and reciprocally slow down the system even more. In the worst case, the queried service fails or cannot respond anymore at all. Then not only will the user not get a response, but all querying services stop working as well. The queried service becomes a single point of failure for all querying services and reliability is in jeopardy. This is especially dramatic if the queried service is something central, like user management.

A better way to do this is to query a cache directly and synchronously, without messaging [2, 3, 4]. Ideally all services store and keep the data they are working with for themselves. Then they would not need to query other services for data. They would notify other services about changes in their data with events over the service bus and those services would handle these events and refresh their data [5, 6]. A cache or backend for frontend would provide a read model for synchronous queries and update itself via received events coming in as messages. In a stressed system those events will reliably queue up but will get handled eventually. That grantees fast queries and high availability but the queried data might not be up to date to the second. But requested and displayed data is never truly current since it could have been changed a second later, while the user still looks at the requested data.
Use the service bus for events (1 publisher -> N subscribers) and commands (N publishers -> 1 subscriber) but not for queries or request/response scenarios [6].

There are messaging protocols for querying, like HTTP, but they are not optimized for reliability and they don’t use queues. HTTP is just taking advantage of TCP/IPs routing fault tolerance.

Sending much data

There is something worse than querying over a service bus: querying huge amounts of data over the service bus. But that could also be attempted with event or command messages as well. Many messaging transports have size limitations for messages so the services would have to exchange lots of them, which leads to coordination overhead and transaction handling spanning multiple messages.

Big amounts of data should be queried synchronously from a cache [7]. If the big amounts of data have to be transported with events or commands, like for image uploads, the services should put the data in a common location and just send a reference [8]. Much data flowing between services indicates unfavorable service boundaries [5].
Since services should be autonomous, loosely coupled and highly cohesive, the only data that is transported between services should be small events and commands, ideally containing only IDs and references.

There are buses for sending huge amounts of data, like USB, but they are not optimized for reliability and they don’t use queues. And even USB uses messages only for short and simple commands and events. The actual data is streamed over a separate pipe in the bus.

Conclusion

Querying and sending much data over a service bus can have drastic consequences when the services or the service bus itself is under pressure. Sure, we could expensively scale for that as well but in my opinion it is just not necessary. These problems can be solved much easier if a service bus is not used like a hammer to treat every kind of communication like a nail. Use messaging when the communication is inherently asynchronous and consider sending only IDs and references. Don’t try to use messaging for synchronous ephemeral communication.
Using a service bus for every kind of communication just because it is already there, is like writing all the code in the Main() method just because it is already there.


[1] 5 Reasons Visitors Leave Your Website http://www.websitemagazine.com/content/blogs/posts/archive/2014/03/21/5-reasons-visitors-leave-your-website.aspx
[2] Chris Patterson (the man behind MassTransit): “it is best to avoid request/response use in distributed applications” http://docs.masstransit-project.com/en/latest/usage/request_response.html
[3] Udi Dahan (the man behind NServiceBus): Clarified CQRS: query caches synchronously, no messaging http://www.udidahan.com/2009/12/09/clarified-cqrs/
[4] Udi Dahan (the man behind NServiceBus): querying “should be avoided” & “messaging is not for that” https://twitter.com/halllo/status/687701659653390336
[5] Udi Dahan (the man behind NServiceBus): Finding Service Boundaries
http://udidahan.com/2015/02/02/finding-service-boundaries-illustrated-in-healthcare/
[6] Chris Patterson (the man behind MassTransit): Messages for updates and asynchronous background processing https://www.dotnetrocks.com/default.aspx?showNum=798
[7] Udi Dahan (the man behind NServiceBus): Getting lots of data over the bus? “you usually shouldn’t – instead, query a cache.” https://twitter.com/UdiDahan/status/707960622726512641
[8] Particular (the company behind NServcieBus): “Messages are intended to be small.” http://docs.particular.net/nservicebus/messaging/databus