Microsoft is a global leader in cloud storage and data protection. They prove that even the most respected cloud databases offer weak security.
Today’s microservice architecture is highly dependent on the fluid and interconnected transference of data. SQL is a coding language perfect for storing data in relational databases, rapidly and securely supplying data when asked. It’s also a highly reliable coding language, capable of maintaining the integrity of databases over the globe.
Unfortunately, the constant pressure to iterate and produce has forced many developers to rely on third-party platforms; cloud providers have also started over-optimizing, cramming multiple customers together on one cloud instance. This has opened up brand new attack surfaces within cloud data protection, as unknown and untrusted companies must rely only on thin walls of protection.
The Importance of PostgreSQL
PostgreSQL is the world’s most advanced open-source library for SQL, with a specific focus on stability, high availability, and scalability. Developed over 30 years ago, the database has the goal of streamlining and cleaning community-developed code. This is then published and re-usable with or without a commercial license.
This SQL code makes use of cloud-stored data; it only makes sense to store the code itself also on a cloud. This is where the Microsoft Azure platform is a godsend for many development firms; this platform is a (mostly) secure and managed database.
Cloud platform offerings are hassle-free foundations for applications and services. From this reliable foundation, app developers can rapidly design and create apps without the need to focus on nitty-gritty platform management. Microsoft offers the Azure Database for PostgreSQL service in three deployment variations: Single Server, Flexible Server, and Hyperscale.
Cloud storage is beneficial in a number of major ways; scalability is an inherent strength of the cloud, as businesses will only need to pay enough for their own storage. Any storage will require a set amount of computational power; however, from a business perspective, flexibility flies in the face of reliability.
Microsoft fixes this with an ingenious method: given a set amount of server space, multiple clients can ‘inhabit’ this cloud, optimizing both customer demand and computation power.
How Multi-Tenancy Architecture Works
This multi-tenant layout sees different customers share system resources like storage, memory, and operating systems. Bundled together, these are all powered by a single set of physical hardware.
Customer instances are separated by virtualization. The second layer of software encompasses the cloud environment, simulating hardware functionality to create a singular virtual computer system. There is one instance per client allowing for logical separation, and further helping to separate and track resource usage.
The PostgreSQL Attack
In 2022, researchers discovered a critical vulnerability within the PostgreSQL Microsoft Azure platform.
When validating the authorization of a server and validating a connection, Azure’s source code checks the client’s certificate. It searches for a predefined common name. However, an oversight in the validation process meant that slipping in extra characters between the beginning and end of the fake certificate allowed access anyway.
The next step in the attacker’s to-do list is to establish which elements of a user’s database contain valuable info.
External to every client’s virtual environment, the clients all share a level 3 memory cache. Put simply, this mirrors the system memory across all client instances. An attacker could manipulate this cache to a known state. When a user logs on and uses the platform, the attacker can then look at the changes present in the cache, pinpoint it to a victim’s activity, and trace it back to where the user stores their sensitive data.
With a chain of attack suitably established, the final step is to find a victim.
The researchers have clarified that this attack only works against databases from the same region. However, finding the region of a pre-existing database is a relatively easy task; it’s evident from the IP address of its hosting server. Once this is known, it’s a relatively simple task to set up an account and start exploiting other users on the same cloud.
So, how can you protect yourself from malicious neighbors?
Keeping Your Cloud Secure
Whereas many coding libraries are publicly shared and open source, multi-million-dollar companies have no such obligation to publish their own code and architectures. Though this makes complete sense from a patent perspective, it comes at the detriment of your own security choices.
More researchers are beginning to ask cloud providers to give a better overview of their isolation architectures; always ask for relevant documentation before choosing a provider.
CVE provides a global documentation process for vulnerabilities and misconfigurations. When code is mishandled and exploited, it is given a CVE ID. This aids in researching, tracking, and ultimately preventing those vulnerabilities.
However, the issue with cloud providers is that software security flaws and misconfigurations do not receive CVE IDs. This makes it far more difficult to establish a cloud provider’s track record. There is good news on this front, however – a hard-working team of security professionals is creating a Github database of cloud security incidents.
If you’re already in a multi-year contract with a cloud provider, then your options are slightly more limited. It’s important to remember that relying on the properties of a single program, or virtual machine is not sufficient; vulnerability in any component of service can compromise the security of the entire service. The bottom line is that – if data is exposed to the internet – then it is vulnerable.
Managing this risk is an important part of operating a secure company.
Any critical data – that is, data that could do irreparable damage if stolen from your organization – should not be stored in any third-party cloud environment; multi-tenant or not. Instead of relying on an un-transparent third party’s architecture, critical data should be stored on an ultra-secure local server. This should have no direct access to the public internet.
For your uncritical data, cloud storage is a convenient and scalable solution, as long as you put further barriers between any attackers and your data. Encrypting your data once it’s in the cloud means that – even if an attacker does gain access – the data is functionally useless for them.
