At Scale Computing, hyperconvergence means owning and managing the whole stack as one system: compute, storage, networking, and management. That ownership directly improves security. There are no pluggable hypervisors, no third-party storage layers, and no extra controllers to track or patch on their own. A cluster running SC//HyperCore™ HyperVisor has as few packages as possible, which shrinks the attack surface. The packages that are present are monitored for CVEs and updated in a timely way.
This page covers the platform features that work together to keep your clusters secure in normal use. They are the embedded hypervisor, the SCRIBE storage layer, the AIME automation engine, and the isolated network model.
Hypervisor security
Some hyperconverged products let admins plug in their own hypervisor and its management tools. That choice has a security cost. Each added part brings another supply chain, another patch schedule, and another set of credentials to manage.
The SC//HyperCore software takes the opposite approach. The hypervisor and management tools are embedded in the platform, reachable only through the web interface and REST API, and protected by a built-in firewall. The whole virtualization layer is part of the appliance. No “controller” VM, virtual storage appliance, or external management server is required to access or manage the cluster.
As a result, the system does not rely on third-party software or high-overhead helper VMs to store and manage cluster state. Nor does it rely on an easily reached (and exploitable) file system. This removes whole classes of attack that target the management plane in typical virtualization stacks.
Custom-built storage layer (SCRIBE)
The Scale Computing Reliable Independent Block Engine (SCRIBE) is the storage management layer that Scale Computing conceived, designed, and embedded inside the SC//HyperCore software. SCRIBE treats all storage in the cluster as one logical pool, which makes it simple to manage and scale. It then spreads blocks across the cluster with redundancy, to get the most availability and performance for virtual machines.
For security, SCRIBE is purpose-built rather than a reused file system. It avoids the performance and security overhead of local files or file system layers. One example is virtual hard disk files that act as block devices. Several properties follow directly from that design:
- The underlying operating system and command line can’t access or mount virtual disks holding customer data. External users can’t reach them through standard storage protocols.
- The SC//HyperCore software exposes no iSCSI, NFS, SMB, or similar external storage protocol for use against VM data.
- Data is spread across the cluster with redundancy. So only limited information could be retrieved from any single cluster hard drive in isolation.
These properties make SCRIBE more resistant to common storage-layer attacks by design. They also lower the risk when you dispose of or replace single disks.
AI orchestration and management (AIME)
The Autonomous Infrastructure Management Engine (AIME) is the orchestration and management engine that powers the SC//HyperCore software. AIME greatly cuts the effort needed to deploy, secure, manage, and maintain on-premises infrastructure. It also plays a direct role in keeping clusters in a known-good state.
AIME keeps a model of the cluster’s state and uses it to:
- Handle daily operational and admin tasks on its own, to cut the chance of human error.
- Watch for hardware, software, and security issues, and fix them where possible.
- Find root causes and limit the impact when an issue can’t be fixed on its own. It then tells you the specific problem and the action to take. You don’t get a raw stream of events to sort through.
- Keep firmware, drivers, and operating system versions current across the cluster for security and stability.
AIME constantly enforces and checks the desired state. So the cluster tends to return to a secure baseline even after disruptive events.
Isolated networking
Nodes running the SC//HyperCore software take part in two separate networks: a public LAN network and a private backplane network. Each has a specific role and its own set of limits.
The LAN network carries traffic to the management interface and virtual machine traffic. That includes tagged VLAN packets sent only to specified virtual NICs. This keeps workloads isolated on the virtual network while they still share physical infrastructure. The internal firewall drops any traffic that tries to reach the node directly. The only access allowed on the LAN is to the SC//HyperCore web interface. No traditional external storage protocols (such as iSCSI or NFS) are available to access virtual machine data. So no needless ports are exposed, and the cluster is not opened to protocol-level exploits.
The backplane network is reserved for traffic within the cluster. It has protections beyond the internal firewall:
- The backplane bond can’t be given an IP in the LAN’s subnet range, so backplane addresses stay isolated.
- On nodes with four network ports, two ports are reserved to physically separate the backplane network from the public LAN.
- On nodes with one or two network ports, the backplane network uses a tagged VLAN for logical isolation of backplane traffic.
Together, the embedded hypervisor, SCRIBE storage layer, AIME orchestration, and isolated networking form the platform-level baseline. Every workload running on an SC//HyperCore cluster inherits it.