Access management

For anything but personal use, monitoring services is not enough. Identity and Access Management (IAM) comes into play instantaneously when there are several pairs of hands working within the same cloud environment. In short, IAM is a traditional framework that aids in managing electronic identities. In a traditional environment, this boils down to managing users and their access to different network drives, applications and sites within the company infrastructure. It is key to have some level of control on what the users should or should not be able to do. Different people are given different levels of access. Users are often grouped to ease the management and individuals are given additional access upon request. These access rights are reviewed periodically as users leave the company,

organi-55

zational changes occur, and policies and roles change. Johnson (2013) suggests that this should not change in the cloud. IAM strategy should be consistent all across the company.

The traditional strategy needs to change to adjust into the way that the cloud works. There can no longer be periodic, weekly reviews, but instead the user activity monitoring should be real-time. The services can accidentally be left on overnight even though there is no one using them, and for this there should be automatic processes for shutting services down, or there should be an individual responsible for managing usage. This is critical especially if a company is, for example, sharing its cloud resources with a consultancy agency in a devel-opment project as the consultants are likely to not be responsible of the used resources.

(Johnson 2013, p. 34-35)

Large cloud service providers offer their own IAMs which can then be integrated to the company’s own governance model. These IAM services often support identity federation through an API or some other way so that the company can, for example, use external identities from Microsoft Active Directory (Microsoft 2014). This really eases some of the governance issues that come from the new external service type of cloud. (Amazon 2014) While the company can use technology to integrate on-premises identity and access man-agement with cloud IAM, there still has to be somebody to oversee all of this. This respon-sibility generally falls on the enterprise IT teams. However, with on-premises systems, public cloud systems and private cloud systems the IT team responsibility will sky rocket and this will soon become a bottleneck as the services need different levels of manage-ment. To divide this responsibility into more easily manageable parts, the idea of cloud-service brokering has become reality. A third party individual, a piece of software or an in-house person who acts as an intermediary between the cloud user and the cloud provider will draw away the complexity of managing multiple vendors, billing and provisioning. As the cloud industry is expanding at a rapid pace, with for example Amazon doubling its ser-vice catalogue within a year, this broker will be tasked to make sure the company is deal-ing with the most up to date services with the best prices. Also, the broker will make sure the providers are functioning according to SLAs and the needed security levels are met.

The broker could also provide a more simplified interface for acquiring and shutting down cloud resources. (Preimesberger 2014a, p. 1)

Figure 15 illustrates how a cloud service broker software would work. The figure is a

sim-56

pler variation of a solution D’Agostino et al. (2012) have presented in their brokering tool architecture figure.

Figure 15. Cloud broker tool architecture (D'Agostino et al., 2012, pp. 99)

The key point in the figure above is that the user uses a brokering interface from which he or she is prompted to select – for example – the duration of the service and some of the specifications needed for the task the instance is acquired to do. The broker scheduler will then use parameters sent by the user to acquire the resources from the CSP linked to the software. In order to get to the CSP, the broker goes through the company firewall and uses the API provided by the CSP to operate within the cloud. The broker is also connected to a database from which it gathers user information regarding access rights. Figure 16 is a view from a pilot project cloud brokering system initiated within Fortum. (D’Agostino et

57 al. 2012, pp. 97-99)

Figure 16. Magical management system for cloud service brokering (Haikonen, 2013) The magical management system was used by users to acquire cloud resources from AWS.

The user had the capability to define if the instance should run during office hours only, which would mean it would automatically start in the morning and shut down in the even-ing. Further improvements would empower the user to select an instance to run for a cer-tain duration and to choose the instance according to its specifications. (Haikonen 2013) According to the pilot project at Fortum, having a cloud manager - or a cloud broker as defined by Preimesberger (2014a) - is set as a requirement. The cloud services need some-one to manage the security groups, and somesome-one responsible as the first line of contact with the cloud service provider. This person’s responsibility is to oversee that the services are used according to set regulations. The cloud manager is also responsible for overseeing the cloud management interface used within the company. This means that even though there could be automatic scheduling regarding the used cloud instances, there is someone to make sure instances are not run when not needed and working as a failsafe for securing that the instances are indeed running and not running when supposed to. (Haikonen 2013)

58

4 THE TRADING ENVIRONMENT