The Linchpin Mobile application for Confluence Server and Data Center is a really cool concept. And one of its big differentiators from the upcoming Confluence Mobile for Server from Atlassian comes from the Gateway service that allows end users access to your Confluence system running inside of your firewall. This is important because your users don’t need to set up any kind of VPN on their mobile device to access Confluence. As a result, your team can now communicate with a portions of the workforce who have unmanaged devices. Their branding for it is pretty explicit:
The obvious downside of this is that it is essentially a backdoor into your Confluence system. So before we agree to put something like this into our infrastructure, we must understand how this is implemented, and whether it offers a level of security that is adequate for us.
The //SEIBERT/MEDIA team have published their technical security overview here.
After reviewing it carefully we found two areas of concern.
First is if a user loses control of a device, and someone gains access to it, that they will now have access to your Confluence system. Since it is an unmanaged device, you can’t enforce standard security practices like disk encryption or requiring a complex lock code with an auto wipe functionality. Users should obviously be trained to report a lost phone to the company, but we should also look for a technical option. To mitigate this, the //SEIBERT/MEDIA team will need to offer administrators some kind of dashboard which flags users with inconsistent behavior.
Second is that the Gateway service is controlled by //SEIBERT/MEDIA. In reviewing their docs, it seems like it’s implausible for them to perform a MITM. When we reached out to the team, they informed us that they are also offering a self hosted version of the Gateway service. This way, if you don’t trust their security docs, and their systems as a whole, you can go one step further and protect yourself.