Cloud application data is vulnerable and exposed to many risks:
- during transfer to and from the data center
- in the storage system / in the database
- during processing
Protection is provided by encryption, e. g. SSL with 2048 bit encryption length, today’s norm and standard practice.
Data in the database and/or storage system is also encrypted. This is not the norm but considered best practice and implemented by highly demanding cloud systems. Common technical solutions encrypt the data in databases and/or storage systems on block level with one or very few system-wide valid keys. The one or more keys are then stored in key storage systems.
Sealed Cloud goes much further. Its Implementation is already put into effect via the web privacy service IDGARD. This is where, during logon, a user specific key is generated through logon data (user name, password and, if applicable, other data) and a special algorithm. With this key, application data is found, encrypted and loaded into the central memory. The data is re-encrypted and stored upon logoff. The user specific key is subsequently destroyed. In other words, the database has n different user datasets for n users, each encrypted pursuant to AES256, respectively. Since the keys do not exist in the system, the hurdle for internal and external attackers is extraordinarily high. An attacker would have to crack the AES256 and do this for every single user dataset, respectively.
This leaves the servers’ central memory as a potentially vulnerable object of insider attacks, since that is where the data is located in plain writing during an active session. An administrator could, for example, drag a memory dump off and calmly analyze all the content at a later point in time. That is why the Sealed Cloud’s system servers are protected by a number of further measures. To name only a few examples:
- All application servers are locked in electromechanically sealed rack systems.
- The servers dispose of volatile memory only, i.e., once the power is cut off, they are in “delivery status”.
- What’s more, the applied system software is hardened additionally and blocks all external access.
- The system indeed reports status information. However, it does not accept external administrative commands. Any kind of administration requires that the respective segment of a rack be opened.
Administrative activity is conducted per work order by authorized appointment through a so-called Trust Center. The work order is forwarded to the respective IT employee with a valid access token via his Bluetooth device. Access to a rack segment may then be requested through the system Bluetooth interface. The Sealed Cloud controller then closes all currently active sessions in this segment, deactivates the servers and cuts off the power. After a waiting period of about 15 seconds, to guarantee that all server data has been cleared, the controller opens the rack lock.
Once maintenance is completed, the segment is again locked and the server activated. When booted, the software stack is verified, i.e., the system searches for possible deviations from the approved, certified software, in both the systems software and the application. Detection of deviations turns the power to the respective segment off immediately, to exclude manipulation.
Once the system is running again, it is continuously verified that there are no deviations from the defined normal behaviour during operation. Here, too, any deviation sets off an alarm and causes the concerned segments’ power to be cut off automatically.
The combination of the described measures ensures that no access to unencrypted data is possible in the data center.
