Explore features of Atlassian Guard

20 min

Advanced

By the end of this lesson, you'll be able to:

Differentiate standard and premium features
Leverage different methods of controlling user access
Identify features to monitor activity within your organization
Explain data classification and security policies
Describe the purpose of Guard detect

Which Atlassian Guard plan meets your needs?

Atlassian Guard is available under two subscription plans that provide slightly different features. Atlassian Guard premium is suitable for large organizations that have stringent security requirements and need to stay in control of their data.

👇 Click the tabs below to explore the features available in each plan.

Atlassian Guard Standard is included in Enterprise plans at no extra cost.

Control user access

If you have an identity provider and you subscribe to Atlassian Guard in your organization, you get user provisioning. It allows you to automatically update users and groups in your organization when they are updated in your identity provider.

User provisioning can save a lot of time for organization admins, allowing them to delegate user and group management to the IT team.

👉 For example: Offboarding a user is as simple as updating the identity provider. This will automatically reflect in your Atlassian organization.

Atlassian Guard supports Microsoft Azure Active Directory (AD), Okta, OneLogin, Google Workspace, and others.

Configure authentication policies

An authentication policy determines the necessary authentication requirements a set of users need to fulfill in order to access your products.

👉 For example: An org admin might enforce two-step verification for users based in a specific location.

Enabling Atlassian Guard in your organization will add a default policy where all provisioned managed accounts are added as members. The default policy contains login settings for its members.

When Atlassian Guard is enabled, org admins are able to set up multiple authentication policies for different user subsets within their organization.

Org admins can set any authentication policy as the default policy, however, a default authentication policy cannot be deleted.

Settings in an authentication policy include:

Single sign-on (SSO)
Enforced two-step verification (2SV)
Password policies such as password strength and expiry
Session duration

Org admins can set up a non-billable authentication policy grouping users where none of Atlassian Guard features apply. Users under this policy will not count toward the Atlassian Guard subscription.

Org admins can create up to twenty policies for their organization.

To create and configure an authentication policy:

Go to admin.atlassian.com and select your organization.
Under the Security tab, select Authentication policies.
Select Add policy.
From the drop-down menu, select the User directory.
Enter a policy name that describes the type of users it applies to (e.g. All users).
Configure your new policy by enabling or disabling the different authentication settings (e.g. Two-step verification).
Select Update.

To be able to set up authentication policies, you need to verify a domain and claim user accounts for that domain. Since authentication policies can have an impact on the ways users authenticate, it’s recommended to let users know of the changes.

Configure SAML single sign-on

Security Assertion Markup Language (SAML) is an open standard used for the communication of authentication data between different systems, such as an identity provider and a service provider. In our case, the identity provider and Atlassian Guard.

SAML for Single sign-on (SSO) enables users to authenticate through your company’s identity provider. This provides additional security and control for your users.

Single sign-on enables a user to authenticate once using a single set of login credentials and then access multiple products throughout their session.

You can set up single sign on to automatically create an Atlassian account for users when they log in for the first time with SSO.

You can set security policies from your identity provider that will apply when users log in to your Atlassian products.

An org admin can also enable SSO in the help center, in Jira Service Management.

When a customer logs in to your help center, they are redirected to the identity provider to log in. They will not have to sign up from the portal.
If a customer authenticates with the identity provider (👉 For example: following a link from within an authenticated environment), the help center recognizes them so they can bypass the login experience.

Before setting up SSO in an organization using Atlassian Guard, an org admin must make sure:

To add an identity provider directory.
To link verified domains to the identity provider directory.
To check that the Atlassian product and the identity provider use the HTTPS protocol to communicate.

To set up SSO in your organization:

Go to admin.atlassian.com and select your organization.
Select the Security tab then select Identity providers.
Select the identity provider you set up in your organization.
Select Set up SAML single sign-on.
Enter the SAML details, such as the Identity provider entity URL.
Save SAML configuration.
Copy the provided URLs, such as the service provider entity URL, to your identity provider.

You can test your SAML SSO configuration by enabling SSO in an authentication policy with a test account as members.

To enforce SAML SSO:

Go to admin.atlassian.com. Select your organization if you have more than one.
Select Security, then select Authentication policies.
Select Edit for the policy you want to enforce.
Select Enforce single sign-on.

Enforce two-step verification

You can enable two-step verification (2SV) for managed accounts in your organization to add an additional layer of security for user authentication. When you set up two-step verification, users must to enter a six-digit code along with their password when they log in to your organization. Two-step verification is particularly useful when your organization is not linked to an identity provider.

In order to enforce two-step verification with Atlassian Guard, you need to configure authentication policies to include it.

To enable two-step verification:

Go to admin.atlassian.com and select your organization.
Under the Security tab, select Authentication policies.
Select Edit for authentication policy you want to enforce the two-step verification.
In the Settings page, select the option to Require two-step verification.

When you have already enforced single sign-on in your authentication policy, you can configure two-step verification in your identity provider, through which users authenticate.

Mobile app management

An org admin has the ability to enforce a Mobile Application Management (MAM) mobile policy. This policy ensures that users' devices comply with your security standards before granting access to the mobile applications linked to your organization.

The mobile app policy is compatible with the Jira Cloud, Confluence Cloud, and Opsgenie mobile applications for both iOS and Android.

It is possible to apply a mobile policy to all users (managed and unmanaged), or specific users.

Examples of mobile policies you can set up are:

Disable sharing, saving or backing up content from the mobile app
Disable screenshots and screen recording of the mobile app
Require data encryption
Require a minimum OS version

Data security policies

With Guard premium, you can also apply data security policies to block data exfiltration actions such as exporting certain data. Org admins can do this by enabling policy rules associated to a specified data scope or coverage.

In order to set up data security policies, org admins must configure two items. They must select the scope of data they want to apply the security policy to. This is called the data coverage. They also must enable or disable policy rules that apply to the selected data coverage.

The available data coverage options as an org admin are:

Selected spaces and projects: Cover pages and work items in selected Confluence spaces and Jira projects.
Products: Cover pages and work items in entire products.

👇 Click the boxes below to explore the security policy rules.

Monitor your organization’s activity

Atlassian products offer the advantage of simple user onboarding, which may lead to the use of unmonitored products and services known as shadow IT. Users can easily create and sign up to cloud products using their work email accounts, without IT’s approval. Tracking and preventing such usage is necessary to protect the security of your organization’s users and data.

Shadow IT can lead to:

Unexpected costs: Admins can face unexpected costs when users create their own instances.
Security risks: Admins have no visibility or control over what users do in their own instances, which may include putting sensitive data into products when users are logged in with their work accounts.
Time-consuming: Admins have to spend a considerable amount of time chasing down users who created product instances outside of IT and finding out how they used those instances.

Products that users sign up to on their own, outside of your organization, are referred to as discovered products. When a managed account signs up for a product, org admins will be notified. Additionally, org admins can view a list of all discovered products for their managed accounts from the admin hub.

However, org admins cannot manage the accounts in those other organizations. They will need to contact the admins in those organizations and find out how they are being used.

You can monitor shadow IT by going to Discovered products page, under the Security tab.

Revoke API tokens

Users in your organization can create API tokens from their Atlassian account settings and use them to perform API calls to the products they have access to via scripts or external applications. When you enable Atlassian Guard, org admins can revoke API tokens created by users.

To revoke the API token:

Go to admin.atlassian.com and select your organization.
Under the Security tab, select API Tokens.
Locate the API token you want to revoke.
Select Revoke next to the token.

Use the audit log

The audit log is a page that org admins use to track important activities within their organization. The audit log is key in troubleshooting problems or addressing queries related to user details, product access, managed accounts, and organization settings.

Org admins can view, search or export audit logs. They can also configure the logs storage options. You can access the audit log from the Audit log section, under the Security tab in the admin hub.

Activities tracked in the audit log include:

Access logs: The audit log records actions affecting user access, such as granting users or groups product access.
Product logs: The audit log tracks product changes such as project creation in Jira or space permissions changes in Confluence.
User-created activities: The audit log records user-created activities such as creating a Confluence page or viewing a Jira work item.

User-created activities are only available in the audit log with enterprise cloud plans.

Use organization insights

Organization insights are charts that provide information about users' adoption of the Atlassian products in your organization and the security of your user accounts. It offers a set of analytics covering the Jira family products and Confluence cloud product associated with your organization.

Organization insights improve the visibility of Atlassian product usage in your organization. They help make data-driven decisions and assess the security of users.

Some of the charts in the organization insights are only available with a subscription to Atlassian Guard. The charts available for organization with an Atlassian Guard subscription:

Active users: This chart shows managed accounts who have used a product at least once a month.
Active users by product: This chart shows users that are active versus those who aren’t currently active, categorized by product.
Active Trello users: This chart shows managed accounts who are active in Trello at least once a month, broken down by pricing plan.

Data classification and security policies

With Guard Premium, org admins can identify sensitive information using data classification. They can create classification levels to distinguish between levels of sensitivity.

You can use data classification levels to classify Confluence content, Jira work items and customer requests.

👇 Click the boxes below to learn about some classification levels you can set up.

You can create up to 10 different classification levels.

Enforce data security policies by data classification

With Atlassian Guard Premium, you can configure Data security policies using data classification as the coverage type. This is not available in Atlassian Guard Standard.

👉 For example: Blair creates a policy called 'Block public sharing' which applies to data assigned to specific classification levels. The policy rule blocks anonymous access on Jira and blocks existing and future public links on Confluence.

👇 Here's how the policy would be displayed in Atlassian Guard Premium.

What is Guard detect?

Guard detect is a threat detection tool that is available with Atlassian Guard Premium. It allows to monitor suspicious activity and potentially sensitive data across your Atlassian organization.

It alerts your team about critical events and configuration changes across your organization.

👇Click the boxes below to learn about the suspicious activities across your Atlassian organization.

Guard detect also helps identify sensitive data within your products, such as text that may contain API tokens or private keys.

You can integrate alerts raised by Guard detect into Slack for faster response.

How was this lesson?

next lesson

Enable Atlassian Guard

Implement Atlassian Guard in your organization
Sync users with Atlassian Guard

Go to next lesson