My organisation has historically used Server editions of Jira and Confluence on-prem for quite some time now. During this time they have been exclusively considered to be internal-only systems not accessible from outside of the network or domain, and and such there have been no data security standards or efforts made to regulate or remove sensitive data from various Jira and Confluence pages. So we've organically accumulated a lot of pages which contain a lot of information that is not safe to share externally, because it was always expected that these systems won't be made externally accessible.
We recently began to prepare for a need to collaborate with external partners, and have been setting up Confluence Cloud for this purpose, with partner access granted via Azure AD 'external user' accounts as per https://learn.microsoft.com/en-us/azure/active-directory/external-identities/what-is-b2b
We now face emerging requirements to integrate Confluence Cloud with our on-prem Jira server to better serve the collaborative needs of various projects. However, I'm concerned that this pretty much puts us back at square one in terms of wanting to isolate the historic internal data from any risks of accidental over-sharing.
I've been reading up on the Confluence Cloud "Application Links" feature as it seems that's how we'd facilitate the system-level connection between Confluence Cloud and our Jira Server. https://confluence.atlassian.com/applinks/link-atlassian-applications-to-work-together-785449117.html
But this reads to me as an "all or nothing" system integration, and I've not (yet) found any reference to any sort of access controls to limit the scope of the integration to just bind specific Confluence space(s) to specific Jira project(s) without making the entire server instance available to Confluence Cloud.
Ideally I'd like to steer the solution design towards creation of a new Jira project on-prem for each project requiring external collaboration, connect only that/those project(s) to Confluence Cloud, and publish some reasonable data security guidelines for project leads to ensure their teams maintain awareness that these pages are not internal-only, so an appropriate degree of caution should be exercised when using them.
It's entirely possible that the Application Link feature just isn't designed with B2B collaboration as a primary use case.
But this is all somewhat new territory to us so I'm hoping others in this community might be able to share similar experiences, and offer more insight into what sort of regulations and controls exist within the Application Link feature.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.