Some operating systems are designed for cloud implementations. Others are not. When an Operating System (OS) is designed for cloud-based operation, security for the cloud based operating system is quite complex. However, executing a secure operating system that is not intended for cloud based implementation within the cloud has some disastrous effects. Most secure operating systems require a user login to execute and the user login is required locally, on the local system. Clearly, having to connect to an OS console for attended boot is not desirable in cloud implementations as it requires manual operation by trusted personnel to provide a secret credential each time a virtual machine (VM) boots up. Alternatively, the operating system can be executed locally, in which case it is not cloud based. Finally, the operating system can be executed without security, in which case it is not a secure operating system. Another known solution is for the operating system to execute and then at some point after booting to request for authentication, which provides a lower and sometimes unacceptable standard of security.
Presently, there is a large IT push to cloud based infrastructure, but many of the applications that are in use require existing operating systems that do not support cloud based execution. There are known Windows® systems where the pre-boot environment can get an authentication code from another entity on a local area network. The known Windows® systems utilize optional DHCP parameters and therefore require network support for broadcast or multicast. The cloud environment does not allow systems to use either broadcast or multicast, which makes this solution unusable in a cloud environment. There are no known Linux® systems having an ability to get an authentication code from another entity on a local area network.
There is a need for another method of booting secure operating systems in the cloud that overcomes the issues caused by operating system security implementations.
USPTO Backgrounds
USPTO Backgrounds