Cloud computing costs money and should start systematically

For most companies the use of cloud services is initially often a step-by-step experiment. Based on individual accounts with one of the major cloud providers, various employees explore the possibilities and get an idea of what might be of interest to their company or department. Even these first explorations are usually subject to a fee. In order to keep an eye on where the journey is going financially, this initial option testing has to be tackled systematically. Such a plan is mandatory for a later widespread use of the cloud. Large providers such as AWS or Azure have usually planned the first steps for new customers diligently. With a Trusted Advisor, such as that found at AWS, the first steps are quickly and safely taken.

A tiered authorization model reduces the economic risks of the cloud test phase

The starting point for a company in the exploration phase is a base or root account for most providers, which has rights to everything. This account is especially secured - e. g. in addition to password protection with an RSA token. This is necessary, as the debit card is used here.

In the next step, a leading administration account is created. It has all authorizations, but no longer has access to the credit card data as an economic link between customer and provider. This account is also secured in detail.

This is where the user accounts for different employees come into play. With a larger group of people with their own access, the risk of generating costs uncontrollably and unintentionally increases. In the case of larger user groups, unlimited administrative full access cannot generally be granted to all users. By setting up billing alerts, undesired peaks in usage can be detected and reported at an early stage, but a graduated usage concept in advance and the corresponding assignment of rights to individual users provide more security.

First of all, the idea of not giving the "cloud pathfinders" in the company administrator rights, but rather sending them on an exploratory trip with largely unrighteous accounts and issuing authorizations if necessary, sounds sensible. In practice, however, this is almost impracticable, since the large cloud providers have set up the assignment of authorizations on an extremely small scale with a high degree of granularity. For the "Virtual Machines" area alone, AWS has over 230 different sub-permissions that can be assigned. With such an extraordinarily dense array of award policies and their interlinking, even the testing of cloud options becomes a science in itself, which tends to prevent quick discoveries.

The background to these complex procurement structures is that the large cloud providers have to meet the needs of large companies with often many hundreds of users and administrators. And this means that the division of work into small parts results in a correspondingly chiselled assignment of rights in cloud systems. Suitable for large usecases, this is often quite complicated and inflexible for smaller teams.

At the same time, it is also a great protection. Thousands of options and services in a global cloud computing network offer too many opportunities for waste or uncertainty from a data security and cost perspective.

Keeping an eye on strategy and implementation when developing an authorization concept

Documentation, experience reports, blog discussions and also the introductions of the large providers themselves together form a reservoir of important information that is often too large for the beginner to plan wisely into the cloud. The most important clues as to what needs to be considered, a guideline for your own first steps into the cloud, one often seeks in vain. Experienced IT architects and cloud experts can secure and point the way to the cloud in two ways:

• Viewing and evaluating existing infrastructures and mapping them in a cloud architecture.
• The step-by-step implementation of a cloud strategy in the environment of the major providers, development and testing of a customized authorization concept for the cloud.

A first set of rules for the experimental and exploration phase includes ideal freedom and limitation at the same time. You could do that, for example:

• Leave the options for activating systems and services largely unregulated, so as not to place unnecessary limits on the curiosity and resourcefulness of employees. Only a financial ceiling would be the control factor here.
• Establish a regional restriction for the beginning, e. g. cloud environments in defined national and international frameworks. In this way, the final "cleaning up" before the emergency would be clear and certain safety standards guaranteed.