How to Move 3,000 Employees to a Corporate VPN Without Going Crazy (Well, Almost)

Vulnerabilities in Jira and Confluence are an inevitable evil. We've all gotten used to them and learned to deal with them: we've set up an additional password, updated to a secure version, and are living well, drinking juice.

And then it turned out that from the third quarter of 2024 Kina There will be no Atlassian updates. And soon any serious vulnerability would become fatal for us.

What does it mean?

1. Jira and Confluence could go down. And not to rest and come back to us with fresh strength, but for good.

Even if we raised them, there would still be a severe downtime of business processes.

2. Our data could have been taken away. In about a year, the confidential information and everything else would have ended up on the darknet or in other unauthorized places.

And so we decided to roll it out his — cool corporate VPN.

What's all the fuss about?

Twice in the last year we have encountered critical vulnerabilities. We urgently hung windows with additional passwords and protected the unfortunate Confluence. But if it happened again – for example, with a different type of vulnerability – the rescue mission could fail.

We decided to remove the leaky magnificence behind the corporate VPN, and the Infra team very opportunely finished the new version. The program became safer, faster and more productive, it is easier to scale it to the entire company – not a VPN, but the son of a mother's friend.

Although it works via the annoying two-factor, from a security point of view it's super cool. And we started thinking about how to issue access.

It will be humane, it will be out of love

We had 3,000 employees, a bunch of bots and freelancers… It's not that the infosec team lacked challenges, but once you thoughtfully start moving the company to a corporate VPN, you have to go all the way.

We could have sent out logins and passwords to everyone, said “Connect” and the next day removed Confluence and Jira behind a VPN. But we decided to be humane and set up systems so that no one would panic and the business would not stop.

To do this, we launched a whole event and granted access gradually – over the course of two months.

Trap plan

Task: prevent business process downtime and promptly help those who are stuck (who were unable to connect).

Solution: connect such a number of employees so that after transferring Jira and Confluence over VPN, the support team won’t be drowned in lost requests.

How did you determine the required amount of support?

We estimated that every fifth user logs in daily and calculated what percentage of the total number of Confluence and Jira users that is.

Based on this data, we determined a corridor of users that could be left unconnected. Once we reached this corridor, we could “pull the switch” with peace of mind and know that no one would drop out.

Powerful preparation

Instructions

Before connecting the commands, we compiled the most user-friendly instructions possible – such that even a shrimp could understand (spoiler: it helped, but not for everyone).

Access Granting Forms

We have updated the access request forms on the internal portal so that colleagues do not have to search for information about the old VPN.

Technical support until systems are transferred behind a VPN

Sad but true: We don't have any organized internal support in our company. The guys who were supposed to support the transition to VPN were swamped with other work, so the team had to be modified and changed twice.

Support: v. 1.0

Two office support staff – these guys can process up to 40 requests per day.

We understood that applications could come in in shoals hundreds. Moreover, their complexity will vary:

– from serious problems associated with the specifics of specific regions (in this case, engineers will have to be involved);

— to questions like “Where are the instructions?” and so on.

And the link to it is highlighted, damn, in caps in the message with the instructions! Sorry, it went off the rails…

Let's get ahead of ourselves

Despite all the instructions and pushes, in total, two support teams processed more than 1000 requests.

To prevent the guys from choking under the weight of applications, we went to the top managers for help.

Support: v. 2.0. This is suppoort!

The tops gave us another support team. We trained it, and 300 Spartans joined the two heroes.

We assigned teams with weak technical skills to the new support. As planned, there were more requests — every second one contacted. But the support team also became larger and could handle 120–150 requests.

We calculate according to the formula and get: 120 (150) x 2 x 5 = 1200 (1500).

We are targeting 1200 users in teams with high turnover.

User corridor for support v. 2.0

450 users in the first support corridor + 1200 in the second = 1650 (that's 55%).

So we calculated that 45% of connected users is enough to move Jira and Confluence behind a VPN.

Providing VPN access

Step 1: Assess the employee base that uses Confluence and Jira

At this stage, we looked at who in the company had access to Atlassian. We revoked access for those who had not logged into Confluence and Jira for a long time.

This reduced security risks and the burden on support and information security teams.

Step 2: Distribute access at the network level

Teams with high turnover do not use most infrastructure services, so they do not need network-level access to them.

After all, even if the guys don't have access to the end applications, it's not a fact that their devices can't be used to penetrate the network. For example, sports betting fans can catch a virus on their work computer and open up access to our system to attackers.

That's why we limited access to such teams.

Step 3. Grant access

We did it gradually – by teams. We agreed with the managers on support: team leaders additionally pushed their guys and controlled the task.

The logic was this:

To track the dynamics, we created a board in Grafana. In it, we saw the logins of everyone who had ever connected to the VPN, and calculated the percentage of those who connected.

Push. And push again. And push again. And push again.

We must have tortured everyone before switching to VPN. Because from every channel they were shouting: “Connect, or your work will stop!”

It was important to convey the changes to everyone, so we sent reminders in the corporate messenger and on the Home portal, agreed on support with managers and came to them with lists so that team leaders could carefully poke their guys.

Interns vs. Confidentiality

We have a lot of interns in our company, and they all worked in Confluence and Jira under the same account (yes, that's wrong).

What's the trick?

• There is always a high turnover among interns, so giving them full access to company documents is not safe.

• Creating an account for everyone in Confluence is long and complicated.

• Supporting interns' VPN connections is even more difficult—the guys' technical literacy is usually low.

• Even if we gave interns access to Confluence, we would be forced to shield them from confidential information.

We analyzed the knowledge base that interns work with and realized that it does not contain any confidential information. That's why we decided to put all the information for interns on a separate landing page – it's accessible without a VPN.

It was necessary to make the mirror as similar as possible because:

• Given their level of technical literacy, interns might not recognize buttons and sections even in a different color – it is important that everything in the interface matches.

• Many interns eventually become employees. We wanted to simplify their onboarding and train them on Confluence.

We set up synchronization so that all changes in the Atlassian system are immediately displayed on the interns' landing page. To get to the landing page, interns only need to enter their login and password.

The final chord

Over the course of two months, enough employees connected to the VPN. We clicked that very button and set up access via two-factor authentication to all Atlassian systems.

Everything went smoothly, except for one thing.

The guys were planning to roll out the corporate VPN at 8:00 PM, and I was planning to have a drink for them at that time.

In the end, they pulled the switch at one in the morning, and I had to… drink to them while watching Game of Thrones the whole time.

And what happened next?

Of course, after Atlassian moved to VPN, we again received many requests for support. New ones came, something glitched with the old ones — and so the third support team appeared.

It was the guys who created our corporate VPN. Of course, it wasn't without a new training cycle, but we already had experience.

Some problems were solved manually, but there was no downtime.

The active phase of granting access to latecomers has passed. We have responded to all requests and caustic comments, conducted a security check and made sure that no one else has access to our systems.

Dynamics of metrics when switching to a corporate VPN:

Yes, it was scary, but we did it:

We had planned for more than two quarters of work, but the active phase took only a little over two months.

There was a risk that the idea would fail. But we were not afraid and rolled up We rolled out VPN to the entire company.

After all, now the system and accesses are already configured.

God, how good we are!

A VPN with access via two-factor authentication is much more secure than our patched Jira and Confluence, and access segmentation further reduces risks.

Ask questions in the comments, use our case and get ready to hiccup a lot. Because you will be remembered with a kind (but this is not exact) word often!