There is a trend called "hyperconvergence" where computation, storage and network are all in the same system. I think that this is a step back (everything again in the same machine, like old times) but it is supposed to be better for maintenance.
What are the new security risks or threats that we have to take into account when using this technology?
I disagree with @JulianKnight's comment there is a different set of risks introduced by the new converged infrastructure. Last time we had converged infrastructure the network aspect of computing was in its early stages, and the main security issues were around privilege escalation. We changed that in the '90s with the layered design: often with the frontend layer, application layer and database layer.
Now, the frontend layer is often the only one exposed to the external network. Other layers are behind a NAT+firewall and, therefore, more-or-less protected. Discounting firewall hole puncturing vulnerabilities, and ignoring passive fingerprinting for network mapping, we can say that the internal layers are bubbled inside a more-or-less safe haven.
This produces a lot of bad practice such as open, unauthenticated, database listeners. For example, by assuming that the database servers are safe from the external world, system administrators drop the authentication between the application and database layers. That gives a boost in performance but exposes the database to an attacker that can cross the firewall.
OK, but I haven't talked about converged infrastructure yet. Our new trend (converged architecture/hyperconvergence) pushes all layers back into a single machine. But we are not in the '80s or early '90s anymore, we are pushing all the infrastructure layers onto a machine that is heavily interconnected to the network and often visible from the internet. I can see two huge implications:
When configuring converged infrastructure and using documentation that was written with layered infrastructure in mind you may fall prey of false security. There is a lot of documentation (blog posts, tutorials, even official manuals) that assumes that internal layers of infrastructure are protected by a firewall and make decisions based on that.
Leaving an unauthenticated database port open in the database layer behind a firewall is bad, but may be compensated by the performance increase. Leaving the port open on a machine that is visible from the internet is outright terrible.
But is bad documentation a big risk? For converged infrastructure it certainly is. Most converged infrastructure is constructed in IaaS/PaaS/SaaS, which in turn are used by "quick-and-dirty" startups which often have inexperienced developers or developers that would blindly follow a guide to do things faster.
Solution? Do not trust documentation, use your own common sense. In other words, it requires developer conscientisation.
But not in the same form as before. Before (during the golden time of priv escalation on first multiuser OSes) the privilege escalation needed to go through the quirks of the OS (e.g. overflowing a setuid program). The difference is that now we are running machines that are heavily connected, including connections on the loopback interface.
Since we are running a converged infrastructure, where is the firewall running? On the same machine.
This firewall will (very likely) be very permissive to any traffic on the loopback interface. If you have a user with low privileges inside the machine he is still free to explore the loopback interface. If you leave network based communications between what was previously the layers of the application to run on the loopback interface, any unprivileged user can play with it. And look back at point 1 (misleading documentation) above to see why the communication between the pieces of infrastructure would be going through the loopback interface.
Solution? Use shared memory to communicate between the infrastructure layers on the same machine (just like people did before the layered approach), shared memory has permissions set by the OS.
