When utilising a Cloud Service in a large-scale Enterprise, don’t just “agree to the terms and conditions”. Think through what the service brings along in terms of value and risk and make an informed decision for usage.
Cloud Service Providers offer a smorgasbord of services to consume. As a consumer, they’re available through the click of a button. But if you’re an enterprise consuming the service, there are typically several factors to consider before you can utilise a Cloud Service.
Read on to learn how SEB works with Cloud Service Reviews to maximise reliable and valuable usage of Cloud Services. This is part one of a two-part series on Cloud Service Review at SEB. This article covers the need for, and most critical controls of a service review process, while the second part covers strategical considerations and the SEB way of working with the process.
What’s in a Cloud Service? The major Cloud Providers offer various different capabilities through different services. Examples range from analytical tooling such as Google BigQuery, to self-service Virtual Machines – Amazon Elastic Compute Cloud (EC2) for instance, or database services (e.g. Azure Cosmos DB), and lots more. Each service provides its own benefits and configuration options in order to maximise the value that you can bring out of your cloud environment.
Aside from the benefits that they provide, each enabled service, within an enterprise context, actually presents risk. How so? We’ll get to that in a little bit, but first, let’s try to understand the lifecycle of using a Cloud Service.
The service landscape is complex and constantly changing. As stated above, there are various categories of services, and each service is typically continuously updated; and new services are continuously being introduced. It is expected that developers and engineers that are interested in leveraging the latest capabilities and creating new solutions are also interested in utilising said services.
So, what’s the problem? As a developer it’s natural not to consider what goes into enabling a service. As someone stated “I AGREE TO THE TERMS AND CONDITIONS” is the biggest lie on the internet. But if you’re an enterprise business, the bandwagon fallacy is not really sufficient evidence for action. What we’re saying is, when you enable a Cloud service as an enterprise, have you really checked the terms and conditions of that service?
In essence, we can imagine the following procedure:
1. A Cloud Provider offers a Cloud Service
2. A consumer/developer/engineer desires to utilise the Cloud Service
3. Someone approves the terms and conditions (or similar) for using the Cloud Service
4. Service is utilised by consumer
The image is showing the process for utilising a Cloud Service in four listed steps.
Seems straightforward enough. The intention of this article is to dive slightly more into the details and rationale of step 3.
We said that enabling a Cloud Service poses a risk. How so? There are actually multiple ways to think about this. Each consideration essentially boils down to weighing the value being granted by the service against the effort of making it available. While there are many ways to think about service risks, in this article we consider the different requirements in terms of Information Security, Contractual and Legal terms. In the next part, we’ll look into Architectural and Technical details of a service and consider how we work with the service review process at SEB.
One of the most critical assets an institution owns is its information. In other words, the (useful) data it maintains. It should therefore come as no surprise that a service that processes this data must comply with certain standards in accordance with the requirements of the data type. The classical example would be GDPR or a similar framework. So, it is important that the enterprise defines necessary controls and compliance regimes that shouldn't be adhered to by a given Cloud Service. (It is worth noting that the data outlined above is typically called Customer Data by Cloud Service Providers.)
If we keep things even simpler, a common fear in Information Security is that data in the Cloud is unsafe simply because it is now on the public internet, and not within the confines of a closed corporate network. While this is easily refuted, the risk of a misconfigured access policy in the cloud is real. It is therefore critical to consider the risk of a developer misconfiguring their Cloud environment with catastrophic IP leakage as a result.
An example mitigation to this risk is to work with Cloud Policies (preferably through Policy-as-code). For example, in Google Cloud, misconfiguration of access policies can be mitigated through the Domain Restricted Sharing Organisation Policy.
Among other things, criteria for operating Cloud Services through security policies, and adherence to particular compliance standards should be considered for a given service in light of the data the service processes.
Perhaps this is typically what’s referred to when we consider the biggest lie on the internet. Have you actually read the terms? In general, Cloud Service Providers make adherence to the terms of a Cloud Service feasible by bundling all Cloud Services under an “Enterprise Agreement” that defines the services that fall under the service schedule of the Cloud Provider. This is one of the perks of working with Cloud technology, because a comparable feature set of services may require negotiations with dozens of Independent Software Vendors rather than one major Cloud Provider. (Note that the current discussion on Service Review already assumes an Enterprise Agreement has been established.)
But a given service can still come with its own set of caveats. As an example, a particular service may not fall under the agreement service schedule, potentially because the service is partially provided by a third party, making an additional review of terms necessary. Services that fall under the agreement may also include Service Specific Terms, which may or may not be compatible with your company policy.
In short, contractual considerations are a major part of a Cloud Service Review Process.
At SEB, we started the Google Cloud journey with a Cloud Core Team of between five and ten people and now have more than 1,000 active users in our Google Cloud environment. In this article we will explain more about how we set the foundation for our cloud transformation.
This is not a post on how to use Terraform or Infrastructure as Code, it is more of a summary on why we have found it to work well for us.
Cloud. Once it was only a fancy buzzword. Now it is already on the spotlight for most companies. Replacing “traditional” infrastructure. Even more – becoming the new traditional infrastructure.
Do you have feedback or thoughts about future blog articles? Get in contact with us at the e-mail address below.