Cloud technology is catching up in India and the considerations for adopting it have evolved too. Customers today are looking at deploying public and private cloud capabilities in one infrastructure. In fact, according to a recent Gartner report, the public cloud services market in India is estimated to grow at 38% in 2017 to $1.81 billion.

Infrastructure as a service (IaaS), projected to grow 49.2% in 2017, will be the highest growth driver, followed by software as a service (SaaS) at 33% and lastly platform as a service (PaaS) with 32.1%. This trend is a significant indicator that the migration of application and workloads from on premises data centres to the cloud, along with the development of cloud-ready and cloud-native applications, are triggering immense growth. While this may be on the rise, it also comes with some challenges and companies need to consider aspects like security, migration to new technologies, training for resources etc.

With this, the debate surrounding the security of cloud computing specifically whether data was more secure in the cloud or not has for the most part been settled. A growing number of organizations now view the cloud as secure and in many cases more so than an on-premises deployment. Beyond that, as each of the public cloud vendors point out, security in the cloud is ashared responsibility with the organization as the application owner being responsible for protecting applications, the OS, supporting infrastructure and other assets running in the cloud.

From a security standpoint, public cloud vendors management consoles are a key weak point and consequently an attractive target for an attacker, often via a phishing attempt. As such, its important to lock down and secure privileged credentials in a digital vault to secure the management console. As such, the enterprises responsibilities, specifically the functions above the hypervisor, include securing the privileged credentials used by applications and scripts accessing other applications and assets, such the enterprises customer database.

Unfortunately these credentials are all too often hardcoded. This is a particularly troubling vulnerability as there can be a large number of hardcoded credentials used throughout cloud and hybrid environments. Hard-coding and embedding credentials in the code or a script can initially make them easy to use but thisrepresents a significant vulnerabilitybecause attackers or malicious insiders can also easily access them, especially if the credentials are in clear text. But, even worse, when credentials are hard-coded or locally stored, they are nearly impossible to rotate, further making them a static and easy target for attackers.

The Risk Is Real

As part of the DevOps process developers often share source code theyve developed on code repositories such GitHub. While its part of the DevOps process, its an all too common example of how embedded passwords and credentials can become public if theyre hardcoded. Even if the code is only saved in the enterprises internal code repositories those passwords and credentials can easily be accessed by other developers and used either inadvertently or maliciously. It also becomes difficult, if not impossible, to fully identify which applications or scripts are interacting with other applications and other enterprise assets.

In the past, these mistakes might not have been so risky, exploitable and damaging within an on-premises environment. However, in a cloud environment, because of the rapid pace of change, the ability to quickly scale and the tools being used, these vulnerabilities are amplified and can pose unacceptable levels of risk.

To minimize risk and follow best practices, enterprises should avoid hardcoding passwords and credentials used by applications and scripts and instead secure credentials in a digital vault and rotate them according to policy. With this approach, just like with human users, enterprises can assign unique credentials to each application, code image or script, and then track, monitor and control access. IT administrators will know which applications access resources such as a customer database. Also, when an application or script is retired, the administrator or script can simply turn off the credentials.

A core business benefit of cloud is elasticity the ability to easily and instantaneously scale up and scale down the number of compute instances or virtual servers to meet the needs of the business at a specific point in time. With on-demand cloud computing, the business only pays for the compute, storage and other resources they use. No human intervention is required. The cloud automation tools are either built-in as a capability of the public cloud vendors offerings such as AWS Auto Scale, or as part of the orchestration and automation tools used with DevOps such as Puppet, Chef, Ansible, etc.

On-demand computing in the cloud, enabled by the automation tools, is a huge business benefit, but it also presents challenges and new potential risks when these new application instances are created and launched, they need privileges and credentials to access resources. The automation tools can provide the credentials, but these credentials also need to be secured.

Consequently, when a new application instance is created, as the compute environment dynamically scales, a best practice is to immediately secure the permissions and credentials assigned to the new instance in the secure digital vault. This ensures that the credentials can immediately be monitored, managed, secured and rotated according to policy. When the compute instances are retired, the associated credentials can also be removed. This is achieved with integrations between the various automation tools and the secure digital vault.

Whether the enterprise is fully in the cloud with IaaS or PaaS or is migrating to the cloud, it is critical to ensure applications, scripts and other assets use secure passwords and privileged credentials to access other applications and assets in the cloud.

Go here to see the original:

The Risks and Perquisites of Cloud Computing - DATAQUEST