All software will be federated and e2e encrypted (EA Principle)
This will be a very short blog.
To all Enterprise Architects and Software Architects:
- All software will be federated.
- All software will be designed around end-to-end encryption.
Easy as that. The End.
This blog was originally posted on Sogetilabs at 2019 Mar 22
End-to-end means end-to-end
End-to-end encryption (E2EE) is an easy principle. It is almost a must when you want to comply with GDPR. As a company doesn’t want to think about which data is in transit and you also want to make use of untrusted media like public cloud. You know that harvesting data in a big data lake without specific applications, processes, and goals attached to it, is not allowed.
This would imply that you need to know the identity behind the data request to allow access to specific data(set). The model that applies to this problem is that of Public Key Infrastructure (PKI)., which is roughly the combination of Identity and Access Management (IAM) and encryption.
For true end-to-end encryption data stored in the database (data storage) should also be encrypted. So this makes Slack a really bad software architecture for a company that wants to comply with high data confidential requirements. Solutions such as matrix.org, Signal, and Protonmail are more interesting for corporate communication when encrypted storage is important. For IoT, The Things Network (TTN) as a global open IoT communication network support by design from the beginning end-to-end encryption between the device (node) and the application that should communicate with the device. The E2EE strength of Matrix.org has made it possible that the French Government is going to base their governmental communication on matrix.org. And the E2EE by design attribute of TTN made it possible to scale worldwide in a decentralized way. Everybody can make their own part of the TTN network without being certified or authorized by a central company, thanks to E2EE.
If you want to build an IT solution that can scale global without central access and control management as a possible attack vector, then you need to make sure your solution is End-to-End Encryption by design. Tip: E2EE including the data storage is also labeled as “Zero Knowledge”.
All tribes unit using federation
Part of Identity and access management (IAM) is Identity Federation.
“As the name implies, identity federation comprises one or more systems that federate user access and allow users to log in based on authenticating against one of the systems participating in the federation. This trust between several systems is often known as “Circle of Trust”. — Wikipedia IAM
Federation is not only about letting people in that did not register themselves in your application. It is also a way of thinking. When you want your solution to be always accessible and not vulnerable for a hack of one main system or censorship by a government then Federation should be part of your design. When applying federation to your application architecture then you are designing a distributed application. This implies that the network as a whole delivers value to your end-users and that a (random) node in the network is not essential to the functioning of the network.
For example, the bittorrent network consists of “nodes” since every application that downloads data from the other bittorrent applications, also uploads data. The benefit of this is that the more bittorrent installations are downloading, the faster downloading will be. This also implies that when my computer is turned down by for example a power outage, the bittorrent network is still functioning. The predecessor of bittorrent were Peer-to-Peer (P2P) networks. The design of P2P was decentralised and not distributed. In those days there where “supernodes” in the network and when a supernode did stop working because of an power outage, the network would stop functioning. In bittorrent, the functions needed for the network to function are automatically divided by the nodes in the network. By design, every node can do everything and optimizes while it is running what is needed of the node to keep the network functioning.
Also, the previous mentioned matrix.org is federated (or distributed) by design. For the French government, this is an extra reason to adopt this solution, since now they know that when a government of another country wants to block communication it cannot do this.
Look beyond communication apps.
These patterns are not only for communication solutions (for example Signal) but also if you build microservices. IAM should support federation and communication between the microservices. Communication with the microservices should be end-to-end encrypted. The benefit of this would be that it doesn’t matter on which technology platform (GCP, AWS, Azure, etc) the services are running. There are already some mortgage back office solutions that are using these patterns to be able to run on AWS public cloud while servicing the full mortgage back office process for mortgage service providers (aka banks).
Design organizations with the same patterns.
For the enterprise architects: what if we designed business units within an enterprise in such a way that it is federated? In a classical designed company, it would not be possible to remove a staff function like finance from the enterprise. Imagine the effect if you remove the central finance at HQ in an organization that consists of 90% franchise entrepreneurs?
Have fun hacking!
