GDPR compliance for Multiclient Use of Confluence

[Patrick Geering]

Hi All. 

Our company is in the outsourcing business, supporting over a hundred clients.

I'm now looking for a new internal approach on customer documentation such as operational manuals, technical configurations etc.

We're allready using confluence for internal documents and WINs. The idea would be, to use confluence also for customer documentation, since our staff is already familiar with confluence (and also with the Breeze DMS Plugin installed). It would have many advantages going down that road.

However, GDPR compliance, confidentiallity and access security topics are currently the main killer for that approach. Our internal IT department did an evaluation years ago and came to the conclusion, that Confluence can't be configured in such a way, that our clients can be fully separated from each other (even with separate spaces) to ensure data protection and confidentiallity. That was years ago, and I'm hopeful that this may have changed in the meantime, so that I can challenge our IT to take another potential look into such a migration.

The following requirements are a given must:

• Each of our customers must be configured in a separate space (check)
• That space must be accessible for ...
  1. our internal customer support teams (restricted)
  2. For registered (restricted) customer personell (external)
• As for confidentiality reasons and GDPR compliance, it is absolutely essential, that no customer can neither see nor access information on other customer spaces, which includes that they can't see ...
  1. any other spaces configured in our confluence setup: they can only see and access their own space
  2. any users assigned to other spaces (no names, emails, whatsoever)

In order to go ahead and initiate another internal assessment on the use of confluence for that purpose, I would need a statement from confluence that the stated requirements can be fullfilled.

Note: I'm not a confluence specialist, I'm only a (power) user which also happens to be responsible for internal Service Improvement. So please forgive me if I may ask things that may be obvious to the confluence specialists out there ;-)

Looking forward on qualified feedback on this topic.

Thanks in advance. Pat

[Kristian Klima · Accepted solution]

Hi @Patrick Geering 

There could be two solutions:

One

Multi-confluence setup within your Atlassian org. One micro-confluence per client. Admittedly, this would work better on Confluence Enterprise, but it's still doable on Standard, albeit with a mild discomfort.

Two

You remain on a single Confluence

• use an marketplace app to make client documentation accessible for reading
• use Confluence guest roles to allow your clients to access exactly ONE space. A single guest can access only one space at a time and they cannot '@mention' users, which means it's unlikely they'd come across users from other companies

So about that app - it's Scroll Viewport by K15t and, unlike pretty much all 'theme' apps, it has one magical property - it builts a documentation site OUTSIDE of Confluence and you can controll access to that site via SSO.

In other words, you can built a specific Viewport-based documentation site for each client and control access to the site via SSO configured in such a way that only users from Client A would be able to look at the Client A Viewport site. 

Select users from Client A would have Guest roles in the corresponding Client A's space on your Confluence.

Collateral benefits:

1. To view the viewport site behind SSO, users DO NOT NEED a Confliuence seat.
2. Viewport site for client could be on their own respective domains and design and branding.

This is our site built with Viewport from a Confluence space - https://docs.emplifi.io/ (our site is intentionally public but we do have an internal site behind SSO).

I think the second option would work best in your scenarios as it's easily scalable (you can create any number of Viewport sites). Happy to chat if you wanna learn more. 

(the only other app that can do that, to my best knowledge, is Instant Websites by Glintech.)

[Patrick Geering]

Hi Kristian. 

Thanks for your fast response. Sounds both interesting. However ...

Micro-Confluence per Client would be far too complex to handle, as we have some 150+ customers. Which means, we would have to manage as many confluence instances as we have customers. I don't believe that would be very practicable with that amount of instances. Beside the cost factor, which would (most likely?) increase substantially for such a solution, I assume? That wouldn't be something that I could sell internally, that would ruin the business case.

The second option sounds at the first glance promising. I will have a look into it. The obvious drawback with that option which strikes me right now is, that we'd loose our document management system if we don't handle the documentation within confluence. We have implemented the Breeze DMS Solution in order to manage our documents in compliance with the given quality requirements set forth internally and by our customers.  I assume that viewport solution doesn't include a document control/management system similar to breeze?

Regards, Pat

[Kristian Klima]

@Patrick Geering 

You will handle everything in Confluence, only the 'consumption' level will be in Viewport.

I actually tested Viewport with B1nary's Breeze and it works - I had it configured using the Breeze's option of the secondary space for edits (approvals etc.) and discussed the options with Adrian Hulsmann at length :) 

So you can keep conducting your workflow/DMS in Breeze

In this scenario, Viewport would use your primary space as a content source, you'd use Breeze's working space (secondary space) for updates).

This will assure that Viewport would only work with final, approved version.

I think Adrian would not mind jumping on a call to discuss the details of the configuration (especially as I haven't worked with Breeze for a couple of months now).

[Patrick Geering]

Hi Kristian.

Thanks for feedback. Sounds terrific indeed. And knowing Adrian, he certainly wouldn't mind to jump into a call. I had some very infusing calls with him in the past regarding Breeze :-)

However, before we do so, I need to include a few more internal stakeholders in developing the idea and a potential business case. Some of the topics I need to clarify are hosting topics, like do's and dont's etc.

1. Do you know by any chance, how/where the helpcenter websites of Viewport are hosted? (InstantWebsites are hosted on AWS as I've learned. And that in any case, regardless if you're planing with a local host, via CNAME)
2. We're actually using SNOW as a helpcenter solution, and are currently amidst an internal project to restructure/simplify SNOW from scratch. So idealy, I'd see to have the created websites tied to the customer portals in SNOW, that would ease admin efforts regarding access and confidentiality topics (if that's possible with viewport?). So I need to discuss it with the SNOW project team on one side, and clarify for Viewport

I'll get back to you as soon as possible

Regards, Pat

[Kristian Klima]

Hi @Patrick Geering 

Perhaps we can get some K15t folks on the call too :D 

AFAIK, it's on AWS. 

There are helpdesk integration options - https://help.k15t.com/scroll-viewport/help-desk-integrations

They're also launching a new iteration of Viewport, Scroll Sites, which is a major revamp of Viewport so there's definitely more to look into.

As for confidentiality, Scroll Documents can be expanded with Variants module which allows you to configure conditional content.

In my config, we have a single space for our product docs - from which we create two Viewport sites - public and internal.

The internal site is behind SSO and has about 200 pages more (some pages have both public and internal only content that only appears on the internal sites. I know they have customers who have a public site and then an SSO site that customers can access for non-public info.

So again, you can build multiple pairs of sites, each pair for a specific client.

Anyway, this is gonna be fun :D 

Attaching a couple of links:

https://help.k15t.com/scroll-viewport/how-secure-is-scroll-viewport

https://www.k15t.com/trust

https://help.k15t.com/scroll-viewport/connect-a-custom-domain

https://help.k15t.com/scroll-viewport/set-up-authenticated-access

[Laura Parraga -K15t-]

Hi @Patrick Geering

@Kristian Klimaalready did some great explanation about Scroll Viewport (and its upcoming new major version Scroll Sites)

To your questions specifically:

1. The Viewport sites are hosted on AWS (US West Region). More on How Viewport Accesses Your Content on Confluence 
2. I'm not familiar with SNOW customer portals but when it comes to managing access to your site, Viewport sites can either be fully public (available to anyone on the web) or protected behind a login.
   The login can either be an access token that you generate in our app or a Single Sign On using an identity provider of your choice. Maybe SNOW can be configured to use the same identity provider?
   You can read more about your Viewport site authentication options on Set Up Authenticated Access

We'll be happy to jump on a call to demo any of these options to you!

- Laura (K15t)

[Adrian Hülsmann - B1NARY]

Hi @Patrick Geering

@Kristian Klima informed me about your challenge and the potential solution to use Scroll Viewport. As you can see, we are all well-connected with each other. :) 

And yes, Scroll Viewport works fine with Breeze. Basically, Breeze takes care of the "doing" part (Confluence) while Scroll Viewport is for the consumption part (external website).

Of course, we are happy to further discuss your challenge in a video call. I'm sure, we can also have a mutual call with our partners from K15t - nothing is impossible. :-)

Meanwhile, we will also check on the @mentions problem stated below and see whether Confluence can be configured to truly separate users from different spaces in terms of GDPR.  

All the best,
Adrian from B1NARY

[Patrick Geering]

Hi @Laura Parraga -K15t- . Thanks for your feedback.

Public publishing is not a topic given the sensitivity of the information as mentioned in my initial post. I need to check with our IT department, if we potentially could extend our SSO solution to the AWS infra as you mentioned. Everything else wouldn't be feasible in regard of additional admin efforts. And after all, our compliance team has the last call on deciding, if we can place that kind of info onto an external hosting site such as AWS. as I correctly understand from your reply, there's no choice on where to publish the export: it's either AWS or none. There's no possiblity to select another target such as our own cloud infrastructure site.

So now I have some inputs together, that I can work with in regards of further internal analysis and in setting up a business case for our management.

If required, I'll come back on the offer to conduct a joint call with you and breeze.

In the meantime, thanks to everyone (especially @Kristian Klima ) for their great inputs.

Regards, Pat

[Adrian Hülsmann - B1NARY]

Hi @Patrick Geering

We further investigated your use case and think that the user guests feature of Confluence most likely fits your use case and could solve your problem.

👉 Read more about Confluence user guests here and here.

Using guests, you can separate external customers from each other and organize them into dedicated spaces. This should solve your GDPR problem since guests do not have access to the internal user info, including:

• @ mentions

• the Teams tab in the top nav bar

• user search

• user pickers.

However, a downside could be that guests cannot access Forge apps (such as Breeze) yet, which is a highly requested feature from us developers.

*Please note that here it says, "Just as guests have free access to Confluence, so will they have free access to all  Marketplace apps you’re using on Confluence.

However, this is not quite correct. This is true for "Connect apps" but not for "Forge apps", which are built on Atlassian's latest development technology, Forge.

For you, this would mean that your internal users can still use Breeze as usual for document review and approval workflows. However, external guests simply do not see the app.

[Kristian Klima]

@Adrian Hülsmann - B1NARY which would work for @Patrick Geering unless Guests (customers) are expected to contribute to the workflow-dependent content.

Well, they could edit articles in the workflow space (losing their access to the main space temporarily), but they wouldn't be able to interact with the Breeze workflow.

[Patrick Geering]

I believe this approach with the guest role could actually work out ...

1. as our customers are not supposed to create or edit the content which we want to share with them. If at all, they should have the possibility to comment on certain topics, but that's not a must criteria.
2. as our customers have access to the final customer site only (each customer with it's own), and not on any other space, not even on the working copy space
3. as the final customer space is declared as 'read only' for all internal users as all other spaces we have the DCM process enabled, in order to enforce them to use the Breeze document control process. The only means of changing documents for internal users is, to to this via working copy space. Ergo, potential guest users will also have no possibility of changing existing content nor will they be able to add any content such as new pages to their space etc. At least that's how I interpret the guest role in such a case ;-)

I'll point out that possible approach to our IT team. Thanks for the input

Regards, Pat

[Adrian Hülsmann - B1NARY]

Let's not mix things up, because guests can contribute to workflow-dependent content, depending on someone's understanding of "contribute". (PS: I know, you refer to the Breeze "working copies" feature, but this might confuse readers without knowing it in detail.)

To clarify: guests could work on their space depending on their given permissions. So they could be configured to only read content from "their" space or also to edit the content of this space. All of this while keeping them separate from the internal users (and other guests), which is what @Patrick Geering has requested and (I think) could solve his main problem.

I mentioned that guest users cannot (yet) use Forge apps, i.e., they cannot trigger any of the Breeze features. But should they? Or are review and approval only part of the internal team? That's the remaining question.

To be clear, guests can work on the content of "their" space, which underlies a review/approval workflow. While guests cannot trigger Breeze's functionality, they can nonetheless work with their content (which could be enough, aka the "remaining question"). To go one step beyond, guests can still benefit from Breeze, e.g., by accessing the Breeze reports created in "their" Confluence space. So there is still room for incorporating some of the Breeze functionality for guests, even if guests are not able to trigger the app functionality themselves. 

But this discussion will be worth a call. 🙂

[Kristian Klima]

I think we're all talking about the same thing but from three different perspectives :) 

[marc -Collabello--Phase Locked-]

One other thing: If you onboard your clients onto Confluence, all user data will be stored in the US, even if you enable data residency in Europe for your Confluence instance. See https://support.atlassian.com/security-and-access-policies/docs/understand-data-residency/ and especially look for the term "user account information".  This might have compliance implications for your business.

[marc -Collabello--Phase Locked-]

Once you are a user in Confluence, you can mention users in other spaces, and thus see that they are users in the Confluence installation.  That means once a customer of yours has access to a single space, they can check other users in other spaces, even if they have no access to the other spaces.

[Dam]

aaah yes true... I forget about that sorry 

this can be a problem in this case here. 

the other approach will be to have a dedicated Confluence site for each customers, but this can cost quite a lot of licence fees.

Dam.

[Patrick Geering]

Hi Marc and DAM.

Yes, that user mentioning is exactly one of the issues that I currently see. As we have a NDA with most of our clients, that would definitely work against the confidentiality part. And of course it would also be an issue in regard of GDPR compliance. I'm not sure if eMail aliasing would work, but as confluence itself sends the eMails, that is to my knowledge not supported in confluence.

And I'm not quite sure, if users, even thought they can't access any other workspaces, are not able to see the other workspaces in the confluence instance. That again would be the same issue as with the user visibility.

Using an instance per customer is not feasible as I explained in my answer to Kristian Klima (https://community.atlassian.com/forums/Confluence-questions/Re-Re-GDPR-compliance-for-Multiclient-Use-of-Confluence/qaq-p/2998309/comment-id/339236#M339236)

Regards, Pat

[Dam]

Hi @Patrick Geering 

Well this is a classic usage of Confluence and spaces... I don't see any problem fulfilling your need here. 

You just need to carefully configure customers accounts using groups, and base each customer space permissions based on the proper groups. Restricting space access by removing the global user group, and adding each group for each customer in the proper space permissions... 

Confluence allows to restrict access to a space with permissions since Confluence exist I think... 

To learn more about Space permissions: https://support.atlassian.com/confluence-cloud/docs/what-are-space-permissions/

I hope this helps.
Dam

[Patrick Geering]

Hi DAM.

As explained, the user mentioning is one of the issues, the other is the visibility of the spaces. Access can be restricted, correct, however not the visibility of it. At least that is what I experience in our current setup. (even thought I have no access to the HR Workspace, I can see that there is such a workspace. That is unfortunately not in line with the confidentiality requirements set forth). But maybe there's a solution to it by using another configuration approach. But keep in mind, we're talking about 150+ spaces, so potentially additional admin efforts coming with another setup, would have to be more or less reasonable.

Regards, Pat