Organizations are jumping on the cloud bandwagon in drove these days. The latest survey by RightScale Inc., a cloud portfolio control service, indicates more than 90% of agencies are using some form of cloud technology. They are concerned with the cloud security roadblocks that businesses face repeatedly.
Considering the wide interest in this cloud movement, cloud security is foremost on their minds. What’s stopping them from fully adopting cloud technology is the fear that cloud computing can’t be trusted because you aren’t in control of the data outside your network.
Questions like “how is my data stored? Is it encrypted? Are there access control methods in place, which will prevent unauthorized access.” and many more are on the minds of managers.
As per IDC, “by 2020 United States alone will generate 6.6 zettabytes of data, up from 898 exabytes in 2012”.
These figures clearly indicate that a lot of companies are now open to adding a Cloud component in their disaster recovery and backup strategy. Perhaps the era of tape backups and disks are on the verge of hitting rock bottom with the Cloud reaching its maturity.
Quite often a lot of our clients ask us why we always ask them to move to the cloud? Our answers are straight forward.
The cloud offers automated, third-party-administered, subscription-based services that let businesses either rely just on the cloud or employ a hybrid approach. Regardless of what method you use, not backing your files and apps can have drastic consequences.
Even though moving to the Cloud is a more sensible but debatable scenario, many enterprises are still set in their ways of using tapes and disks to back their critical data.
So why is this bad for your business going forward?
Tapes and disks mean manual administration. This means this system is prone to alot of errors resulting to greater risks.
We talked about 6.6 Zettabytes of data being generated by 2020. Can you imagine backing all this data on tapes? On a normal day, a mid sized company can take hours, days or even weeks to back all their systems. So how long would 6.6 Zettabytes of data take? A ridiculous amount of time. So use the cloud.
You cannot ignore the various cloud based services that most of the enterprises use on a daily basis. Some of these services use password authentication but many of them use public and private keys for authentication.
The use of public / private keys have increased, and is now being used by a number of protocols and applications. The primary reason for this is improving security, since the keys provide a much better security than a password that was chosen by a user. In order to provide cloud services, we have to ensure we’re properly protecting our public/private keys.
Some Business areas where public/private keys are used:
The most common use of the public/private key pairs are by the applications hosted on cloud based dedicated servers. You simply rent a dedicated server from cloud service providers such as Microsoft Azure or Amazon Web Service. All it requires is a bank account and a few simple mouse clicks to get a dedicated server up and running in matter of minutes.
The administrators use SSH daemon for interacting with them. The Secure Shell or SSH, is an cryptographic (encrypted) network protocol to allow remote login and other network services to operate securely over an unsecured network. You will use the public-private keys to secure your application while password authentication is disabled.
Often used in the banks and other kinds of financial institutions; the website application issues a new key for every user who are given access to this service.
Developers use the public-private keys to authenticate, via the private key to push or pull the source code in the cloud environment. The cloud tools simplify the installation and maintenance of the source code repositories.
Understanding Key Security
Asymmetric encryption uses the public and private keys, to authenticate the system or encrypt/decrypt the data, while in transit. The public key can always be shared with the public as it is used for data encryption while the private key can only decrypt data. Using specific commands the keys can be generated which can accept various arguments to fine-tune the key generation process.
Ways to improve security of public and private keys:
Use password-protected keys:
It is important to select a strong password when generating the private key, to protect it from an unlawful use. An attacker who has gained access to the machine that stores the private keys will eventually be able to access the private keys which in the unencrypted form can provide an attacker access to the cloud-based system.
The attacker can gain access to the machine through various techniques like uploading the shell through a web-based vulnerability in the web application. He will be able to gain partial access to the underlying file system or the access/directory where administrators often place the private keys for authenticating the other cloud-based systems.
This emphasizes the importance of encrypting the private keys with an additional strong password that prevents the attacker from gaining access to other systems.
Use a strong key.
When creating the private key, it is possible to instruct the ssh-keygen command, to create keys of the following size: 1024, 2048, 4096 and so on. The private keys are usually constructed from the product of two randomly generated prime number. The strength of the public/private key encryption lies in the fact that it’s very easy to calculate the product of two randomly chosen prime numbers, but it is difficult to determine which of the two prime numbers were used by knowing their product.
It is advisable to choose the 4096- bit key that is currently considered secure as it contains enough possibilities to prevent the attacker from using brute-force to gain the passwords in real time.
Reduce the login time.
Using the public and private keys, involves providing password for the private keys all the time. The ssh-agent which stores the decrypted private key in the cache for the duration of the session, can reduce the time it takes to authenticate the system.
The decrypted key can then be used to authenticate the cloud-service without providing the private key password. The decrypted version of the key is only available in the cache and only to the ssh-agent process, while the actual file in the file system remains encrypted. An attacker with access to the file system, will only be able to steal the encrypted version of the private key.
Back up your keys.
Creating backup is a good idea when you rely on a number of public/private key-pairs to authenticate the cloud-based services. Otherwise, if the keys are lost through hard drive failure or accidental file removal operation, the user would no longer be able to authenticate the cloud-based service.
Failing to back up the keys properly can result in getting locked of the cloud service. Contacting the cloud service provider can restore access to the system, but the process is long and cumbersome. In the worst-case scenario, access to the system is lost completely. This can happen if everything is encrypted in the cloud and the cloud-service provider doesn’t have any access to the system or files.
Usage of the public and private keys have increased and is now used by a number of cloud-based services instead of the passwords to authenticate the system, as it provides much better security. Therefore, properly securing the public and private keys are necessary to prevent the attackers from gaining access to the cloud service.
There are ways to protect the public and private keys on the client. So even if an attacker is able to compromise the client, he won’t be able to use the keys. Keep in mind that an attacker who has gained the private keys can authenticate the cloud service and perform a lot of malicious actions like stealing user data, decrypt sensitive information and disrupt the service, among others.
For more details or information, connect with us at info@sysfore.com or call us at +91-80-4110-5555. Website: www.sysfore.com
