Clear separation of responsibilities contributes to secure data protection

Public clouds offer increasingly valuable services for the construction of sophisticated web applications. But what about data protection?

Concerns about data protection have risen in recent years. In particular, companies with sensitive data such as banks, insurance companies or public clients must adhere to strict standards regarding the protection of any personal data they are using and minimize the risk of data leaks. We show a proven architectural approach that separates private and public data to meet the high demands of data protection.

Cloud services can challenge data protection

Services from public clouds such as CDNs, web searches, image and media processing, AI, push notifications or infrastructure services for operating applications are indispensable to modern web solutions. 

In specific cases, full on-premises or private cloud operation makes sense. This applies, for instance, to data-sensitive companies and public clients that must not expose any data to the outside world. However, public clients in particular are under constant pressure to manage their funding efficiently, which conflicts with the significant costs associated with on-premises solutions. For them, the question arises: How can we benefit from the high quality and cost-effectiveness of public cloud services while adhering to data protection requirements? 

Data protection through systematic service orientation

The key lies in a clear division of responsibilities and the decoupling of components, such that the overall solution is a composition of individual services. Here, we strive for coherence so that each business service is represented by a dedicated digital service. This results in clear service responsibilities with regard to data processing.

An illustrated chart depicting individuals using a web application for different services: editorial content, user services and personalization, user profile, video and image delivery/media.

For example, a User service may provide identity management (IAM), user profiles and may process personal data. Other services do not need to know the users but may receive anonymous information. This results in the need for only the User service to be operated on-premises or in a private cloud, while other services may stem from the public cloud, as they do not receive any data worth protecting.

A graphic depicting separation of connecting from a browser/native app for different services by users - IAM/Profile services are sent to a private cloud while content, media and delivery service users are sent to the public cloud.

This principle is particularly easy to implement if the data is composed in the user's client — for example, in a web browser or an app. This ensures that personal data is directly exchanged between users and the relevant services. 

The prerequisite for this composability is that the services are accessible via web interfaces (client facing). Furthermore, a portable, anonymizable authentication method should be used so the users can identify themselves directly to the services, eliminating the need for the services to exchange data with one another. Here, we usually rely on REST interfaces and JSON Web Token (JWT) as established standards. Following a successful sign-in, users will receive a “proof of identity information” in the form of a JWT token from the Identity Server and use this token to identify themselves to the remaining services, thus allowing for precise definition of the personal data shared with these services.

From a data protection point of view, service orientation offers significant advantages over traditional applications. The clear division of responsibilities within the service landscape leads to better control of the data flow and enables targeted investments to be made in security-relevant services. At the same time, adhering to the principles of data avoidance and data minimization, services only receive exactly the information they require.

Additional challenges arise in situations where the fact that a service is being accessed is in itself worth protecting. However, public cloud services can also be used here. Here, a proxy is placed in between the user and all public cloud services, hiding, for instance, the user's IP address, thus making service usage anonymous.

Flowchart depicting how users may connect to different services through a browser/native app: IAM/Profile service requests, as well as proxy services are sent to the private cloud, from where the proxy service redirects users to a public cloud for content, media and delivery serivces.

A similar solution pattern is the so-called Backend-For-Frontend (BFF) principle. Here, an application takes the place of the proxy. It responds dynamically to user requests and uses the corresponding services in the background. In this way, users only interact with one service — the BFF. This approach also makes sense when services cannot open their interfaces directly to users.

Practical example: SwissPass Smile

The above approach has already proven itself several times in practice. One example is the SwissPass Smile platform, a family and youth program of the Swiss Federal Railways SBB. 

This platform uses Contentful for its content layer. The content edited in the Contentful web app is generally intended for the public and, therefore, does not require protection. 

SwissPass Smile users can also register using the SwissPass login and save personal data — for example, their family constellation. For this purpose, the services of the public cloud are combined with containerized services in Unic’s ISO 27001-certified Swiss private cloud hosting.

Flowchart depicting users connecting through SwissPass, being directed to the private cloud for user services and account services, and then through there to the public cloud for the Contentful service.

The data flow of personal and public data is completely separated, since the data is only composed in the single-page application (SPA) of the user. Contentful does not know the user, but only receives the user segments (e.g. “family” or “youth”) in order to deliver content in a personalized manner.

Content that is individually adapted to the user is served via a dedicated service (referred to as a content service in the above image) in the private cloud. This ensures that user data never flows through the public cloud.

The solution benefits enormously from the direct use of the CMS APIs (Content Delivery API) for all public data, assets and videos. The single page application can build directly on an existing, well-documented cloud service without any backend effort, which translates into significant reduction of development effort and reduced complexity.

Secure — thanks to separate responsibilities 

The use of services from the public cloud is generally compatible with high data-protection standards and can even lead to a strengthening of data protection. A prerequisite is a clear division of responsibilities and the corresponding modeling of the solution in the form of public and non-public services, as well as the use of proven mechanisms for the decoupled authentication of users.

About the author
Don't miss the latest
Get updates in your inbox
A monthly newsletter to help you build better digital experiences with Contentful.
add-circle arrow-right remove style-two-pin-marker subtract-circle