In the last several months we have seen security concerns are raised more and more. Volatility has become the new curse word. Companies are refocusing their efforts to an on premise data center. See here how confidential computing can help to implement and use case based usage of the public cloud with confidential computing as added security. ( https://www.opensourcerers.org/2025/01/20/the-on-premise-data-center-is-back-or-better-it-was-never-gone/ ).
Now as companies are focusing back to the on premise data center an old concept has reappeared where confidential computing can help to implement a layered approach to administration this architecture much easier and in a more secure way.
Creating a layered approach to add security layers to the on premise infrastructure.
Core of this concept is a Trusted Compute Base which consists of core components running a confidential computing environment. It could be called an Inner Sanctum. Here you will find the Key Management Services (KMS) and the Attestation Services. Only a special group of administrators ( Inner Sanctum Admins ) will have access to this environment. Actions will always need 4 eyes approval and are always audited. The necessary physical servers will also have a dedicated area which can only be accessed with 2 keys by Inner Sanctum Admins. This is because in the past physical access was needed to use an exploits for confidential computing. The other group of administrators can handle the daily business which consists of stopping starting servers and creating new instances and all of the other routine tasks. All those activities are executed in an automated and audited(-able) way. Upon start of the node or vm, during boot and the start of applications the keys to decrypt the data/pods is only possible via accessing the attestation service. The applications will be loaded from a registry where all of the components are stored in an encrypted way where the key is in the KMS in the secure zone. The mechanism of Attestation can also be used to access encrypted storage facilities from the environment or data on databases.
As most customers in the FSI business are running their infrastructure in a disconnected way, support for a disconnected environment needs to be used. Currently AMD and Intel have made such services available. So during Attestation when the CPU signs the evidence with the hardware providers proxy CA it can be created and verified by the Attestation service.
A problem persists when we are locking and logging inside the Trusted Execution Environment to analyze problems within. For this each of the application services should include an Anonymizer to create/change log files which can be used to investigate incidents without the release of internal data. Monitoring should only be initiated from the inside to publish events to an external monitoring service.
Lastly to prevent applications from being attacked by a Software Supply Chain attack a Trusted Software Supply Chain needs to be implemented to only allow components coming out of the automated pipeline to enter into the production systems and deployed into the TEE to access the encrypted data. One of the ways to do this can be found here ( https://developers.redhat.com/products/trusted-software-supply-chain/overview ).
To create this secure zone and to start a confidential computing environment you normally need an attestations service available. but we do not have an environment yet. This seems to be a hen and egg problem. To overcome this there are several options.
- You can assume that your Inner Sanctum administrators and your processes to create this are secure and therefor do not need an attestation. I personally would not opt for this approach.
- You use a root of trust laptop. This laptop will provide the initial TEE to run the Inner Sanctum. It is setup from scratch and does not have a connection to the internet and is only used for this single task. Or you use solution available in the market to provide a secure initiation environment.
- IBM provides with the secure execution and environment which does not need a runtime attestation component. It uses deployment time attestation. There for it can be the root of trust. This system is available using the mainframe and z/Linux. Have a look here ( https://www.ibm.com/docs/en/linux-on-systems?topic=execution-introduction )
What are the advantages of this approach?
With the establishment of the Inner Sanctum the company can minimize the interaction of administrators with data and business logic. There will always be a need for administrators to handle the chaotic events, the one offs which no automation can handle.This is for the Inner Sanctum Admins to initially handle, provide the needed logs hopefully in an automated way to the general group to find a solution. But the general group cannot see or interact with the data and the business logic used in the production infrastructure so this reduces the entry points for attacks considerably. Adding the 4eyes concepts to all interactions with the secured environment also increases the effort needed to attack the systems on a more personal/individual level.
When we look at the article from the beginning of this blog we also see that components running on premise and in the cloud would be handled in the same way. All the deployments use a confidential environment therefor the deployment into production is unified and complexity is reduced. This is also true for the use of AI. As it is increasing the usage and accessibility to GPUs for training and inference.
So overall adding a new layer of security to reduce complexity and reduce possible attack vectors.
There are several other use cases for Confidential Computing. If you are interested, have a look at this blog entry to discover where Confidential Computing can help your company to add a new level of security. ( https://www.opensourcerers.org/2024/05/20/confidential-computing-in-action/ )
And as always, I am interested to find out your use cases. Let us have a discussion.