Overview
To address the situation where our discussed break-glass system is unavailable, instead of adding another system higher upstream from it, which would require us to rely on that new system to access the OCI break-glass credential, we will discuss a low-tech solution.
A solution
In our third post, we mentioned that the break-glass system authenticates its calls to the OCI API using an API key associated with the initial Administrator user of the account. Only the break-glass system can access this key. However, we didn’t provide details on how an implementation of the break-glass service might secure this key/credential.
A good approach is to have the break-glass service stores the key in an encrypted keystore that uses password-derived encryption. This encrypts the keys in the store. Furthermore, the key that rge break-galss system itself uses to authorize access to the OCI APIs that is generated during the bootstrap process we discussed in the third blog post is also encrypted using password-derived encryption.
This layered encryption scheme, where the key is stored in a password-derived encrypted file, and the key itself is encrypted with password-derived encryption before being placed in the store, enables us to implement a Separation of Duties (SoD) control. This control requires two separate individuals to obtain the unencrypted break-glass service key. Furthermore, disaster recovery only requires a straightforward backup of the encrypted keystore.
Our break-glass service is down. Now what?
To successfully execute the breakglass procedure, we must assemble the keystore and the two personas with their respective passwords in a secure environment, such as a physical or virtual war room. Within this war room, we will establish a system that securely hosts the keystore and is managed by a third trusted individual.
To initiate the process, the individual with the password to the keystore accesses the system. They export the encrypted breakglass API key using the keystore password. Next, the persona with the password for the key decrypts the key. At this point, all three personas must coordinate their actions to use the key for its designated OCI breakglass purpose.
After the key has served its purpose, we can initiate the security bootstrap process again to create a new encrypted key that will replace the used key in the keystore.
Conclusion
Attentive readers will notice that this method, though less automated and convenient, can in iteself provide a reliable break-glass system without the need to create the services described in the previous blog posts.
In the next post, we will continue to address any remaining issues and discuss the necessary changes within the OCI account to ensure that the break-glass system cannot be bypassed.