Secure workloads with the cloud
Every decision to start workloads in the cloud is always a veiled question with regard to security. So, choosing to go with the cloud means giving up some control of a small part of “my” infrastructure. In plain terms, you need to trust someone else to keep your data secure and healthy, ensuring that it is readable and useable for you.
The reasons behind this may differ – maybe a hack or data leak, or something else – but the thought alone is reason enough to tackle the issue and deal with security. Cloud security is grouped in two different categories. On the one hand, there is cloud native security, which helps the infrastructure team to adhere to company guardrails and guidelines by using functions from the cloud provider. On the other hand, you have the self-managed level of security, let’s call it active security, where you can apply a set of logics and software to create additional trust in your environment.
Poor security is one of the core problems behind data breaches
An analysis of the most common data breaches since 2020[1] shows how they can be divided into three different categories: hacks, accidental publications, or poor security. In the same list, poor security has the biggest impact (Yahoo, Facebook (incl. Instagram), MongoDB, etc.), with billions of lost records. Losing data not only harms a company’s image, it is also very expensive: for example, fines for violating the GDPR[2] can be up to 4% of a firm’s annual revenue. This is where security come into place to avoid such fines and problems.
Cloud providers such as AWS, Azure, GCP, and Alibaba are working intensively with their customers to meet the highest security standards by using frameworks like the shared responsibility model. This means the responsibility for topics that include security is shared between parties, as shown in the following figure.
Cloud native security affects the part below the cloud provider, i.e. SMS digital or also SaaS & PaaS. We use cloud native security functions to secure the customer’s workloads in the cloud. These functions look different with each cloud provider; however, they ultimately have the same goal.
From a technical perspective, cloud native security have limitations, set by guardrails for instance, on how the cloud is used. One example of this would be protocol and IP limitations between two endpoints in the cloud.
In addition, there are continuous checks and automated guardrails that point out any breaches of the rules. To ensure the guardrails function in way you intended, you can either turn to cloud provider-issued services or use free/paid tools such as CloudCustodian[3] or PRISMA.
Security helps to avoid difficulties in the last mile
Security mechanisms cannot offer 100% confidence, though they can minimize their occurrence and the harmful effects of a possible leak. What’s more, a mixture of both, cloud native and self-managed security, can point you in the right direction, whereas choosing one extreme (too much security = not useable) or the other (no security = not secure) would cause issues.
At SMS digital, this is precisely the path we have chosen. Alongside cloud native functions, we are promoting additional security via guardrails and limitations as well as strict client-specific capability. In addition, we are already implementing build security with several types of testing including vulnerability checks on source code, libraries, and containers.
This gives us a full-scale overview that ensures maximum security while at the same time utilizing the power of the cloud.
References:
[1]en.wikipedia.org/wiki/List_of_data_breaches