Curious about security in Cloud?

Probing Atlassian Access is a vital step when moving to a cloud-first strategy. It is the only security you need as it covers the entire service and not individual sites as it mounts to the organisation. Using Atlassian Access, you would pay one Atlassian Access seat per product-licensed user, regardless of how many sites and products one user have access to. When you deploy Atlassian Access, you essentially deploy security policies to your users’ way of signing in and how they are handling their accounts.

Why bother with Atlassian Access?

This question is perfectly reasonable and requires an answer. We will therefore try to break down the product into components to decrypt it for you. It’s not really “rocket science”, but rather the opposite – an incredibly flexible interface that makes the whole IdP (Identity provider) matter a joy to handle.

If you do not have an IdP solution in place, Atlassian Access is still highly relevant to you as it adds 2FA, which is a must to secure the cloud service.

First and foremost – Atlassian Access is not a standard app you install from Atlassian Marketplace. If you have been dealing with Server or Data Center, you have probably paid for various SSO apps that you’ve had to install per product, i.e., one for Jira, Confluence and maybe even Bitbucket. You can forget these products when you move to Atlassian Cloud. Atlassian has, to our delight, taken safety into their own hands, and the set-up is very smooth.

Things you must do and should consider 

When you install Atlassian Access, the product ends up in your administration interface under admin.atlassian.com. You can only access the product from the administration if you are an org-admin, i.e., the highest level of administrator. Once you have installed the product, you will have access to new functionality, including:

• Connect your IdP solution with Atlassian
  • SAML single sign-on
  • User provisioning
• 2FA
• Audit logs for account events that affect your users
• Manage user API tokens
• User insights for product use for all sites

Although the interface and management of Atlassian Access itself are smooth, there are a few things you should get sorted before you start paying for the product. You could undoubtedly download and start paying for the product at once, but if you have not taken these steps, you may have to wait for possible lead times in your organisation.

1. Verify your domain and claim your accounts 

If you have not done this yet, it’s time for you to act – no matter how small your user base is. You have virtually no grasp of your cloud strategy if you miss this step. In practice, this means you take ownership of the domain (in our case stretch.se) and collect all Atlassian accounts with an email address containing @stretch.se. This action proves to Atlassian that you own these accounts and are the proper organisation to manage them.

There are clear instructions on how to go through this step on Atlassian’s website.

Once you have verified your domain and claimed accounts related to your organisation, you have unlocked additional functionality in your administration interface. More particularly:

Source: https://support.atlassian.com/organization-administration/docs/what-is-an-atlassian-organization/

As you might notice from the table above, you get quite a lot of functionality just by verifying your domain and claiming ownership of Atlassian accounts. Even though this might feel like a lot, you still lack some of the essential parts of the security aspects you’ll get from Atlassian Access. Make sure you are informed about your organisation’s policies to get the proper level of security set up.

2. Setting up your organisation with Atlassian Access

Once you’ve arranged with domain verification and claiming of accounts, you are well on your way to securing your Atlassian products. The next step is to choose which functionality you want/can use. As mentioned earlier, you do not have to have an IdP to take advantage of Atlassian Access – but you get the most out of the service if you have it. You will find all Atlassian Access functions under the Security tab in the administration interface.

Running Atlassian Access with IdP 

If you have an IdP set up with your organisation, your first move should consider connecting with Atlassian Access for JIT (Just In Time) provisioning. Before doing this, you should figure out which groups to synchronise to Atlassian. It is also worth considering how policies should work for different types of accounts. You do this through Security → Authentication Policies.

When starting out with Atlassian Access, there will only be one Authentication Policy by default that applies to all users. In practice, when syncing users to Atlassian, these will be created with the same jurisdictions for login and password. Our suggestion is to create different policies depending on what kind of accounts you’ve got.

For instance, in addition to employees, there could be service accounts or external consultants who may not need to log in with SSO or where the password should not expire every 30 days. As soon as you’ve set up the policies, you can start to configure your user provisioning to ensure that different accounts get the proper security measures.

In addition to a solid login policy with SSO, you can turn on two-factor authentication (2FA). Note that if you’ve configured to use SSO, 2FA is managed through the IdP solution and not through Atlassian.

Running Atlassian Access without IdP 

If you do not yet require IdP, it is still a good idea to get Atlassian Access. Without IdP, your Atlassian environment is vulnerable as unauthorised people can easily log in if they crack someone’s password. As you might be responsible for the aspect of “end-point compromise”, you should ensure that security lives up to your organisation’s requirements. With the help of 2FA, you can take a big step towards a safe environment, and as we mentioned earlier, 2FA is part of Atlassian Access.

Today, 2FA (two-factor authentication) is a vital asset by many services and essentially give you an extra layer in addition to a password. You verify that it’s you logging in by entering the six-digit code you receive via SMS. As a result, this provides an extra step that plays a significant role in whether you ultimately manage to limit exposure of sensitive data or not.

Do we need the extra security? 

Of course, there are cases where you only leverage your Atlassian tools with generic information that is not sensitive, but can you vouch for your users and that data handling is adequate? The short answer to that question is no. You can never protect yourself enough. Human factors cannot be regulated and controlled to the extent we want. Exposure of data is usually unintended and by accident which makes it tricky.

Gartner predicts that as many as 90% of all companies that fail to regulate  public cloud usage by 2025 will inappropriately share sensitive data.

Gartner’s prediction talks about controlling and regulating cloud use, which you take responsibility for when choosing to implement Atlassian Access. You take ownership of all Atlassian accounts spawned from your organisation, and consequently, the cloud sites in circulation that you did not know. In addition, you also decide how different types of accounts should impose different levels of security. In other words, you take control of your Atlassian strategy and create the means to manage and regulate the continued use of the products. Worth the extra investment if you ask us!