Skip to main content

Cloud Risk Mitigation Strategies

 Due-diligence on Various Cloud Solutions

Cloud computing leads to a higher dependence on cloud-based vendors and thus demands that clients ask for an evaluation of their capabilities beforehand. Optimised security measures, industry- recognised compliance standards and the ability to support the unique requirements of an expanding organisation must be analysed to mitigate the risk potential in a cloud project.

Adopting Encryption Standards

Encryption of data is the act of converting sensitive data into indecipherable text by using relevant algorithms. The encrypted data is called ciphertext, and the level of encryption depends on the sensitivity of the data. Encryption solutions are of two types:
Provider-side cloud encryption: The cloud service provider encrypts the data received from clients and adds an extra layer of protection from potential threats. Many leading cloud vendors in the market, such as Amazon, Microsoft and EMC, offer these solutions to their clients.
Client-side cloud encryption: Companies dealing with multiple cloud vendors make use of cloud encryption gateways to turn their plain text data into ciphertext. Encryption makes the text unreadable without a special key.

Secure Third Party Validation

Cloud security is better said than done. Not every cloud service provider is successful in keeping up with the security demands of the customer. This makes third party validation a must for cloud solutions. Independent technology auditors assess the solutions to ensure that they are capable of delivering the desired results.

User Access Controls

The risk of unauthorised access to critical information exists in both private and public cloud environments. As opposed to the application-based access control in the traditional system of computing, cloud environments work better with Role-Based Access Control (RBAC). In this method, users of the system are assigned a specific role and can perform a precise set of functions based on this role. By restricting access to cloud resources, unauthorised access, accidental manipulation of data and sharing of credentials can be prevented.

 Service Level Agreements and SSO Solution

A robust service level agreement holds the key to the performance levels of every element of the service provided by the cloud vendor. It affirms the ownership of data and lays the foundation for the security measures to be adopted during implementation.
The Single Sign-On (SSO) is one way of mitigating risk when it comes to protecting user data. The user logs in using his/her email id or any id that has been created along with the password to a particular application through the web browser. Once he/she logs in, the sessions starts, and all user information is encrypted and stored using specific protocols. After the user logs in, he/she may use any of the connected systems or applications without having to login multiple times. For example: Gmail and all other applications of Google. In a browser, if the user has signed into Gmail or Youtube once, then there is no need to sign in again and again for other Google applications. He/she can access Google Docs, Drive, PlayStore etc. without having to login to each of these applications. The SSO technique eliminates the need for multiple re-authentications while using the system or a set of applications and thus prevents authentication requests to be made to the server back and forth every time the user wants to use a particular application.

 Hybrid Approach

A recent study conducted by Avanade, a business technology and managed services provider revealed that more than 60% of the participants believed that the hybrid approach (the blending of private and public cloud) was a safer way to conduct business in the cloud. This model of cloud computing allows organisations to host their most sensitive data internally while allowing the other secondary functions to reside on the public infrastructure. It offers the highest level of flexibility with no additional capital expense. With more business-critical applications moving to the cloud, hybrid offers the best of both worlds.

Comments

Popular posts from this blog

Special Permissions in linux

The setuid permission on an executable file means that the command will run as the user owning the file, not as the user that ran the command. One example is the passwd command: [student@desktopX ~]$ ls -l /usr/bin/passwd -rw s r-xr-x. 1 root root 35504 Jul 16 2010 /usr/bin/passwd In a long listing, you can spot the setuid permissions by a lowercase s where you would normally expect the x (owner execute permissions) to be. If the owner does not have execute permissions, this will be replaced by an uppercase S . The special permission setgid on a directory means that files created in the directory will inherit their group ownership from the directory, rather than inheriting it from the creating user. This is commonly used on group collaborative directories to automatically change a file from the default private group to the shared group, or if files in a directory should be

The Seven-Step Model of Migration

Irrespective of the migration approach adopted, the Seven-step Model of Cloud Migration creates a more rational point of view towards the migration process and offers the ability to imbibe several best practices throughout the journey Step 1: Assess Cloud migration assessments are conducted to understand the complexities in the migration process at the code, design and architectural levels. The investment and the recurring costs are also evaluated along with gauging the tools, test cases, functionalities and other features related to the configuration. Step 2: Isolate The applications to be migrated to the cloud from the internal data center are freed of dependencies pertaining to the environment and the existing system. This step cuts a clearer picture about the complexity of the migration process. Step 3: Map Most organisations hold a detailed mapping of their environment with all the systems and applications. This information can be used to distinguish between the

RequestsDependencyWarning: urllib3 (1.24.1) or chardet (3.0.4) doesn't match a supported version

import tweepy /usr/lib/python2.7/dist-packages/requests/__init__.py:80: RequestsDependencyWarning: urllib3 (1.24.1) or chardet (3.0.4) doesn't match a supported version!   RequestsDependencyWarning) Traceback (most recent call last):   File "<stdin>", line 1, in <module>   File "/usr/local/lib/python2.7/dist-packages/tweepy/__init__.py", line 14, in <module>     from tweepy.api import API   File "/usr/local/lib/python2.7/dist-packages/tweepy/api.py", line 12, in <module>     from tweepy.binder import bind_api   File "/usr/local/lib/python2.7/dist-packages/tweepy/binder.py", line 11, in <module>     import requests   File "/usr/lib/python2.7/dist-packages/requests/__init__.py", line 97, in <module>     from . import utils   File "/usr/lib/python2.7/dist-packages/requests/utils.py", line 26, in <module>     from ._internal_utils import to_native_string   File "/usr/lib/python2.

tag