Atlassian stack architecture

[Surevine]

Hi,

I'm wondering if there is a generic architecture suggestion for the atlassian stack. Although I don't know how useful it would be, I think we're already going a bit "off book".
We started with JIRA on a public network, then added Fisheye in a DMZ, talking to our repositories on an "internal" network.

Now, we've got Confluence (internal network) and want to connect it to Jira.

To talk, Confluence/JIRA seem to need a direct connection, so we can't use a DMZ.
Along with Confluence, I also decided to go for Crowd, which I'm guessing is going to need direct access from JIRA too. 

Is it common to install all this on an "internet" facing network? Crowd in particular seems highly risky. Or is there a way to proxy connections through a DMZ gateway somehow?

(Of course, I can firewall the applications, but if there is a zero-day exploit in JIRA and I've allowed it to get to 443 on Confluence, a lot of Atlassian apps use the same Java components, so likely, we've just allowed one 0-day attack direct access from the internet to our internal LAN. I'm not sure how much value the DMZ with Fisheye is giving us either...)

[rrudnicki]

Hi Max, 

I’m afraid we don’t have a “book” very specific related to DMZ or network architecture for one reason. Customers has different network topology and needs. For example, for someone a two-legged DMZ might be enough while others go to three-legged and Tag VLan. 

As I could see, you are looking for information related to security. On the link below you can find some helpful information: 

https://www.atlassian.com/security

However, we can think on this way. If do you have sensitive data, avoid to put this directly on the internet. And on this point the DMZ, Two-Factor Authentication, VPN, Reverse Proxy, SSL, Honeypot, etc starting. A security network is not related only to have a firewall or DMZ, but also trusted configuration into your policy network. For example, doesn’t matter if do you have a DMZ to increase your security level if your users are allowed to create weak passwords like 1234. Since Confluence and JIRA use email to notify some interactions, you also need to pay attention to your Email Server Security as well once a Hacker can use your email credentials to try to find for credentials on Confluence and JIRA. 

But returning to Atlassian Stack, I think on this way (and this is my personal opinion). 

If you don’t have any sensitive data, I don’t see why you should concern to much about Confluence, since this is like a Wiki. With JIRA, you can allow your users or customers to raise tickets. If you are concerned to security, you can create an Intranet/VPN for your customers to be allowed to authenticate on Atlassian Products. 

Your idea about proxy is good. If is possible, try to use less Valid IP Address as you can. Use a Reverse proxy and Load Balancers to manage the access to your internal system. Of course, this might increase the complexity of your network infrastructure. 

I hope this helps.

Regards, 

Renato Rudnicki