Securely separating Service Desk instances

[Kyle Hughes]

We're looking to start using Service Desk but we would like to create multiple instances on the same server, one being internal one being external.  I know there is a way to securely separate the sites into different projects, but due to regulations is it possible to only expose one project externally while keeping another site strictly internal facing (not accessible from outside)?

Would we create multiple network interfaces and point the NAT translation to a specific port where external project is communicating from?

Thanks

[Cathi Chanslor]

@Kyle Hughes 

Did you get your internal / external projects working as you describe here? What was your final solution? 

My company is looking to do something similar but I have yet to find a definitive answer as to its "doability". 

Thanks!

Cathi

[Kyle Hughes]

The answer is yes/no.  We did complete the project but we ended up purchasing another instance of JSD to make sure it was completely separate and there was no chance of bleeding over to other Jira instances due to our ePHI requirements.

Ultimately the design is no longer valid regardless as they are no longer supporting on-prem deployments in the next year or so and everything will be forced to move to their cloud.

[Cathi Chanslor]

Thanks for the reply. I was afraid that would be the case.

[Gary Fitzgerald]

Cathi,

Due to our security requirements, we also bought another SD license and set-up an External Instance. We used a Jira add-on Exalate to sync the External SD instance with an internal SD instance. In our case, the external SD required much less licenses than the internal SD. We have found this solution to work well.

Gary

[Matthias Gaiser _K15t_]

I can back what @Gary Fitzgerald said.

I'm working for the team behind Backbone Issue Sync (similar to Exalate) and we see many customers using our product in such a scenario. I'd say the benefits are:

• You can have different license tiers for the internal and external Jira.
• You can choose which fields you want to synchronize from the internal to the external (and back). E.g. you might want to synchronize the summary and description, but not your worklogs.
• You can choose to have different workflows for your internal/external projects - one internally including e.g all quality/review steps and a simple one for the external project.

If you want to discuss any of these requirements in regards to solving them with Backbone, happy to chat via help@k15t.com.

Cheers,
Matthias

PS: Here's a full list of issue sync solutions which can help in such a scenario.

[KellyW]

Hi Kyle,

Every project has it's own permission scheme that manages user access:

• JSD Project settings >> Permissions: To gain access to the project, users need to be added to Browse Projects permission.
• JSD Project settings >> Customer permissions: Limit who can raise requests

On system level, you can enable public signup.

With public signup enabled, agents can invite new customers to a service desk project, and new customers can create accounts on the customer portal and through email. Enabling public signup for your service desk project also enables a honeypot technique which helps prevent spambots from creating accounts through the customer portal.

You must first enable public signup at the system level:

1. Log in as a user with the 'JIRA Administrators' global permission.
2. JIRA Administration > Applications. Scroll down to the JIRA Service Desk section and choose Configuration.
3. In the Public signup section, enable the setting.

You or a service desk project administrator can then open a service desk at the project level:

1. Go to Project administration > Request security.
2. Select Anyone can sign up for a customer account on my Customer Portal.

New customers will be added to the Service Desk Customers project role. Note that customer accounts created via public signup do not count towards a service desk license.

Regards,
Kelly

[Kyle Hughes]

Thanks for the response Kelly.  Unless i'm just being dense and not seeing the answer if I have "server a" running Jira Service Desk it's going to run multiple projects as you said "SD internal" and "SD external".  In order for the public to access "SD External" we would need to expose "Server A" to the public internet, likely a NAT rule on the firewall.  That basically puts the entire server out into the DMZ which includes "SD Internal" which we don't want exposed.

Is there a way to say "SD Internal" runs on this IP or port while "SD External" runs on a different IP/port? That way we can route the firewall rules to only expose "SD External" vs exposing the entire server?

[Nic Brough -Adaptavist-]

You would need to be running two services to make that split.

[Kyle Hughes]

By services, do you mean different instances or physical servers? For example put "SD internal" on Server A and put "SD External" on Server B?

[Gary Fitzgerald]

Kyle,

I'm looking to do the same. Did you use two instances and get this working?

We have the SD agents also create a Jira ticket for product issues. How did you handle this i.e. did you also have an external Jira instance?

[Kyle Hughes]

Gary,

We having finalize our external Service Desk project yet, but we are getting close.  We were told by support that it is possible to do this on a single instance of Jira so that's the route we are going.  We have our internal service desk project up and running and have built out the second "external" facing project but just haven't finalized the security rules to present it outside of our network.