Intro
European organizations are increasingly looking at alternatives to the large US-based cloud providers. Concerns about data sovereignty, US legislation such as the Cloud Act, and changes in the geopolitical environment have increased interest in European cloud providers.
For some organizations, this raises an obvious question: what are the alternatives, and what does moving to a European sovereign cloud mean in practical cybersecurity terms?
That’s why we wanted to take a more hands-on look.
Our aim isn’t to evaluate the overall security of the platforms or validate the presence of vulnerabilities within them. Instead, we are focusing specifically on the security services, features, and functionalities they provide. We wanted to understand what security capabilities are available today from European sovereign cloud providers, and how they compare to the basic functionality security teams have become used to in large hyperscaler platforms.
Three European providers, three different sizes
For this purpose, we selected three European sovereign cloud providers of different sizes for review. Together, they provide a useful cross-section of the European sovereign cloud landscape: one larger sovereign cloud provider and two smaller, established regional providers. We deliberately don’t name the providers in this review. The point isn’t to rank individual vendors, but to understand the security capabilities that organizations can expect from smaller European cloud platforms.
All three provide the basic services and functionality you would expect from a public cloud platform. But there is a significant difference in scale compared with the large hyperscalers. That difference matters because developing and maintaining cloud platforms requires substantial investment. The smaller providers simply don’t have the same resources as the global hyperscalers, and it’s therefore not surprising that they cannot match their service offering and feature set in every area.
However, it’s interesting to understand how this gap looks in practice: What functionality is missing? Which security controls are more limited? And what does that mean for organizations that are considering moving workloads to these platforms?
Five security categories
For the review, we defined five categories covering basic security features and services available across the major cloud providers that are important for securing workloads in modern environments. The categories don’t cover everything that could be evaluated on a cloud platform, but they provide a practical way to understand the security baseline of these European alternatives.
The categories we looked at were:
- IAM, including granular permissions, API access control and SSO
- Organization management, including workload isolation and centralized controls
- Networking, focusing on basic network security controls
- Logging, including control plane logs, central storage and SIEM integration, and
- Tooling, covering both native and third-party security tools
1. IAM
Identity and access management is one of the most important foundations of cloud security. Here, we looked at three things.
First, how granular the permission model is and whether it allows policies that follow the principle of least privilege. As a simple benchmark, we looked at whether it’s possible to create permissions for a single API call against a single resource. Second, API access control. Static API keys remain one of the major sources of cloud security breaches, so we wanted to see whether the providers offer alternatives. Third, whether standard SSO protocols are supported for user authentication.
The three providers take quite different approaches to IAM.
The larger provider uses principles, policies, scopes and conditions. Permissions can be relatively granular at the service level, but the minimum scope is often wider than a single resource. More tightly controlled resource-level policies are possible in principle, but support for them is currently limited to a few services.
One of the regional providers has a more capable policy model. Its IAM is based on users, roles and policies, and the policy language allows relatively complex and granular rules. It’s possible, for example, to allow read operations for a single bucket while denying everything else. On the other hand, each user can be associated with only one role, which can create challenges when the same role is used across users who need different combinations of permissions.
The other regional provider has a much simpler permission model based on three predefined access levels. Even the most restricted level allows users to create new resources, making the model overly permissive for many use cases. Overall, such a simple IAM system doesn’t support implementing permissions that follow the principle of least privilege in many scenarios. More granular permissions such as read-only access are on the provider’s roadmap.
The API authentication model is more consistent across all three. On all of the platforms, API keys are the only way to access the cloud provider APIs. There’s no equivalent of workload identities or IAM roles that can be attached directly to application workloads. Therefore, applications still require static API keys to access the platform, which means those credentials need to be managed separately. Two of the providers support controls such as automatic API key expiration, which improves the situation, but doesn’t remove the underlying limitation. For human users, all three support SAML or OIDC for authentication. One provider also supports SCIM, while the others still require manual user management even when an external identity provider is being used.
Overall, the biggest IAM gaps compared with the large hyperscalers are clear: static API keys are still required, permission granularity is limited on some platforms, and the lack of SCIM can make user lifecycle management more difficult.
These limitations also affect architecture decisions. If the IAM model doesn’t provide sufficiently granular permissions, organizations need to think carefully about which workloads and resources are placed within the same IAM boundary.
2. Organization management
The second category is organization management. The large cloud providers offer mechanisms to group and isolate resources and workloads and create hard security boundaries between them. They also provide centralized controls and guardrails that can be applied across the organization. We wanted to see how the European providers handle the same requirements.
All three have some form of organizational structure that can be used to separate workloads and environments.
One provider uses organizations as the main container for resources and provides organization-level policies that can act as a centralized guardrail. These policies are evaluated before role-based IAM policies and can therefore be used to define maximum permissions within the organization. There are limitations, however. The policies cannot be managed centrally across multiple organizations and must be configured separately in each one. There’s also a risk that someone who can escalate privileges within the organization could modify the policy.
The larger provider uses projects as resource containers and offers some organization-level security controls. These are, however, relatively limited compared with the centralized controls available in the large hyperscalers.
The third provider also provides a way to group resources and isolate workloads. However, it offers no centralized controls or guardrails that can be enforced across the organization.
Overall, the basic concept of workload isolation exists across all three platforms. The bigger gap is in centralized governance and controls. Only one of the three providers currently has a centralized guardrail mechanism, and even that is significantly more limited than what’s available on the major hyperscaler platforms. In larger environments, that difference can significantly affect how security is managed.
3. Networking
Cloud platforms offer a wide range of networking services, but for this review we focused on the basics: network traffic controls and the availability of private networks where workloads can be deployed without public interfaces.
All three providers have basic network security controls and private networks. The differences are more visible in their default configurations.
One provider offers private networks and instance-level firewalls, but when creating a new server through the console, the firewall is disabled by default. This means that all traffic is initially allowed until the firewall is manually enabled.
The larger provider uses security groups to control traffic to instances. The default security group, attached to new instances by default, is also permissive and allows all traffic unless you change the configuration. These defaults make it easy to get workloads running quickly, but they are not the most security-oriented starting point.
The third provider also uses security groups, but its default configuration is more restrictive: inbound traffic is denied by default.
Overall, the differences here are smaller than in some of the other categories. All three provide basic controls for network traffic and private networks. One common limitation is that the controls operate at the resource or instance level. None of the providers currently provide subnet-level traffic controls.
4. Logging
Logging is another area where the large cloud providers offer many different capabilities and integrations. Again, we focused on the basics.
Do the platforms provide the most important control plane logs? Can you export those logs to centralized storage? And can they be integrated with a SIEM?
All three providers have audit logs covering control plane activity, but they differ significantly in how those logs can be used.
One provider offers an audit trail, but without a paid support plan, the available logs are limited to the previous 30 days and only include mutating control plane actions. Exporting the logs to a bucket for centralized storage also requires the paid support plan.
Another provider provides audit logs for control plane activity, but there’s no automatic delivery to centralized storage. The platform provides an API for retrieving the logs, meaning organizations would likely need to build their own tooling to centralize the data or feed it into a SIEM.
The third provider has the most mature offering of the three, although some of the functionality was still in beta at the time of the review. Its audit logs can be exported to a bucket for long-term storage, and it’s the only provider of the three with documentation for integrating the logs with a centralized SIEM.
Another significant difference compared with the large hyperscalers is that none of the providers has built-in threat detection tools or services. To monitor the environment for threats, you need to build the detections yourself.
5. Tooling
This brings us to the final category: security tooling. The large cloud providers have extensive ecosystems of native and third-party security tools covering areas such as detection, monitoring, security posture management and other security use cases.
For the smaller European providers, the situation is very different.
None of the three has a significant native security tooling ecosystem. We found only a few third-party tools that specifically mention integrations with the providers we reviewed. Compared with the large hyperscaler ecosystems, the difference is substantial.
The platforms provide standard developer tooling, including SDKs, command-line interfaces, and Terraform providers. But the lack of off-the-shelf security tooling can become a practical challenge for security teams, particularly when an organization starts using the platform at a larger scale. In theory, organizations can use the available SDKs and APIs to build their own tooling. In practice, that’s unlikely to be realistic for most organizations, and it’s difficult to reproduce the depth of functionality available from major cloud providers and security vendors.
What does this mean in practice?
This review only scratches the surface of the security capabilities of three European sovereign cloud providers. Cloud platforms are also evolving quickly. During the review, several providers released new features, so parts of the assessment had to be updated.
So, view this as a snapshot rather than a permanent assessment. That said, some clear themes emerged.
The biggest differences aren’t necessarily in the basic cloud security services themselves. They are in the security controls and tooling that sit around them.
Centralized controls are limited or missing, which means organizations may need to put more effort into securing individual workloads rather than relying on centralized policies and guardrails.
Security tooling is also limited, reducing the visibility security teams can get from off-the-shelf solutions. In some cases, understanding the environment’s security posture may require more manual configuration review.
Threat detection is another gap. Without off-the-shelf detection capabilities, organizations that want to monitor these environments need to build much of that capability themselves.
None of this means that smaller European sovereign cloud providers cannot be used securely. It does mean that organizations need to understand the trade-offs before moving workloads onto them.
For some organizations, sovereignty requirements may be a strong enough reason to accept a different security and feature model. In other cases, the most practical approach may be a multi-cloud environment, where the most sovereignty-sensitive workloads are placed on European providers while other workloads remain on the large hyperscalers. The key is to make that decision based on an understanding of the actual security controls available, rather than assuming European and US cloud platforms provide equivalent capabilities.
Considering a European cloud?
Moving workloads to a new cloud platform isn’t simply a matter of migrating applications. When the underlying IAM model, organizational structure, logging or security tooling works differently or doesn’t exist, the architecture and security model may need to change as well.
At Reversec, we help organizations assess cloud security in practice, from architecture and identity and access management to configuration, logging, monitoring and detection.
If you are evaluating a European sovereign cloud provider or planning to move critical workloads to a new cloud environment, we can help you understand the security implications before making the move. And if you already have workloads deployed with a smaller provider, we can help you assess the environment’s current security posture and identify areas that may need further attention.
If you want to continue the discussion about our research or see how we can help you assess and secure your cloud environment, get in touch!
