A new security feature for Cloud Migration Assistants helps you audit domains during your migration

[#1]

What do I need to know?

• To help you decrease the possibility of malicious actors obtaining access to your cloud instance and causing a security incident, we’ve introduced a new feature into the Jira & Confluence Cloud Migration Assistants (JCMA & CCMA) to proactively audit the email domains associated with users you’re planning to migrate to the cloud.

• Currently migrating? We recommend updating your CMA and reviewing your domains as soon as possible. For migrations < 6 weeks you can use your current version of the CMAs to migrate but we recommend additional steps to check your domains. For additional details please see “What if I’m close to executing my production migration?” below.

• Already migrated? Please follow our recommendation below in “What if I have already migrated to cloud?”

Security is a moving target; today's threats are often not tomorrow's. With thousands of cyberattacks daily, Atlassian is always thinking about what those threats will be and how we can fortify our cloud products to protect your data. And data is at the center of how we think about security, whether it’s:

• What can products do with your data?

• How data flows within a product?

• How it flows between products?

• Or who has access to it?

Our top priority is your data, which is why the Cloud Migration Assistants (CMAs) are built on top of Atlassian’s trusted cloud platform and use the same security measures as our Marketplace Apps. To further protect your data we’re evolving the CMAs to bring deeper visibility into who will have access to your data before you migrate to the cloud.

What’s new?

In our latest version of JCMA/CCMA, we introduced a new feature to help you proactively audit the email domains associated with the users you’re planning to migrate to the cloud. The goal is to ensure that you’ve assessed these domains and concluded that they can be trusted with the help of your security team. By ensuring that only users from trusted domains are migrated to the cloud, you decrease the possibility of malicious actors obtaining access to your cloud instance and causing a security incident.

In the CMAs, you’ll see a new card labeled “Review all domains” that will bring you to the Trusted Domains assessment screen.

Before

After

Here you’ll see all the domains associated with users in your Server or Data Center instance today, and you’ll be able to review each domain to ensure it should be trusted. If a domain isn’t trusted, please see “I’ve found a domain that can’t be trusted what do I do?” below.

This new feature will add a mandatory step before kicking off your migration plans. We recommend assessing your email domains as early as possible in your migration journey.

What email domains can be trusted*?

Email domains should be classified “not trusted“ only if your security team is concerned about the following:

• not knowing the origin of a domain and user emails using it

• not being able to trust the organization that creates emails using that domain

If your security team has no concerns about the domain, it should be considered “Trusted. “

The classification of domains as being “Trusted” or “Not Trusted” should not be taken lightly. If you find a user with an email domain in your Server or Data Center instance that your security team does not trust, you should work with them to investigate why that user still has access to your instance and what the user did in the system. Therefore, the “Not Trusted” classification should be used only for domains that present a security risk. For further details please see the documentation for Jira or for Confluence.

What if I’m close to executing my production migration?

Though we recommend that everyone assess their Server and Data Center domains using this new feature, we understand it may not be possible for some customers in the midst of a migration. To ensure you hit your planned migration date you can stay on your current version of the CMAs if you’ve successfully tested your migration and your production migration date is <6 weeks away. However, we suggest that you obtain a list of domains by carrying out the following steps Auditing user email domains by querying the application database and reviewing your domains before your production migration.

What if I have already migrated to the cloud?

Even if you’ve already migrated to the cloud, we recommend you audit your users regularly. To audit your users in the cloud, you can export a site by following this guide Auditing user email domains in the Cloud. If you find any domains that can't be trusted, you can suspend the user in the cloud until your security team can investigate further.

I’ve found a domain that can’t be trusted what do I do?

If you’re migrating to Cloud identified a domain that can’t be trusted, please see https://support.atlassian.com/migration/docs/review-users-to-trust-email-domains/

[Amine]

Will definitely use it. Thanks @Renan Battaglin 

[JG Meillaud _]

Thank you Atlassian for having me to manually go through 210 domains this morning, most of them with 1 deactivated user!

With no options to bulk assess the domains of course!

What's even better is that those users are already in my cloud site from a previous migration! (and again, last time I checked, no options to bulk suspend access)

Good one!

[Renan Battaglin]

Hi @JG Meillaud _

Thanks for the feedback!

We are evaluating options to make the domain assessment faster, including bulk operations options.

If you are confident that all the user email domains can be trusted, but the total number of items makes it impossible to do the assessment manually, you can contact our support team and ask for options to bulk mark all items as "Trusted".

Overall, we want to ensure that the domain assessment is not taken lightly, but we know that we can still make the experience much better.

Cheers,

Renan

[Tim Eddelbüttel]

Hi @Renan Battaglin

We are evaluating options to make the domain assessment faster, including bulk operations options.

that should be implemented from the beginning or minimum having a dark feature to disable this.

The product team should have colleagues that at least know how a Jira & Confluence user base can grow over time and that it's not just 20 domains that would be fine to update individually.

Just a number from my instances: 410 unique domains

Can you share the mechanism how the data is persisted so that we can bypass this by database?

Kind Regards,
Tim

[Terry Child]

Hi @Renan Battaglin 

I have a Confluence Server installation that uses a Jira Server for a its user directory.

The Jira server runs Jira Service Management which allows anyone to raise service requests via email.

This means that we have hundreds of external customers in Jira with huge numbers of email domains in our Jira directory.

Do I now have to go through all of those email domains and 'trust' them?

How am I supposed to make a meaningful decision to trust a Service Management customer's email domain?

The only way I can see to proceed is to just trust all of the email domains.

This means I have to go through hundreds of domains and manually set them to trusted,

Is that what I am supposed to do?

If not, how do you suggest that I decide which Service Management customer email domains to trust?

Thanks

Terry Child

[Renan Battaglin]

Hi @Tim Eddelbüttel 

Thanks for your comment.

I agree that changing the status of hundreds of domains manually is not a great experience.

An option to select all domains as trusted already exists. While the bulk option is not available on the UI, we are asking customers with high number of domains to contact our support team as they will be able to give you the steps to achieve the bulk operation.

However, before applying the operation, please make sure that the domains were reviewed and that they can be trusted.

Thanks for your patience while we work on the bulk options on the UI.

Regards,

Renan

[Renan Battaglin]

Hi @Terry Child 

Thanks for describing how your user management is setup.

When JSM is being used, the JCMA "Review all email domains" page will list only the email domains of licensed JSM users (agents and admins), not "help seekers". So, you should be able to see less domains in JSM. We do not expect JSM customers to review the domains of "help seekers" since these users, by default, do not have permissions besides creating and updating tickets via the portal. In Confluence however, CCMA will be listing all users.

With this in mind, I can suggest these steps:

1-) While the bulk option is not available on the UI (we are working on it), please contact our support team and ask them for the steps to run the bulk operation to trust all domains.

2-) Start the assessment of domains from JCMA, as you should be seeing less domains (only licensed users will have their email domains listed). If you are sure that you trust those, mark them as trusted.

3-) In CCMA, since it will be listing all domains, and you have already assessed licensed uses via in JCMA, you can use the bulk solution to mark all domains as trusted.

I'll make sure that we document this use case asap. It is more complex and i believe we can do a better job at the feature it self to support this type of setup.

Regards,

Renan

[Terry Child]

Thanks @Renan Battaglin 

That's really helpful.

It's good to know that what I'm seeing is correct.

I'll will go through and manually set them to all to trusted for now - as it's a one-off exercise.

Regards

Terry

[Darryl Lee]

Ugh. We have 300+ domains. We're just testing our migration. I didn't want to click 300 times, so I generated a list of domains (thanks ScriptRunner) and then ran this cli within a for loop:

acli jira --action renderRequest --requestType PUT --request '/rest/migration/latest/email/domain-rules' --requestParameters '{\"domainName\":\"$x\",\"rule\":\"NOT_TRUSTED\"}' --contentType JSON

When I went back to the Review all email domains screen everything was "trusted", so then I was able to click Done.

Yeesh. Some kind of "security".

[Patrick Schneider]

I wrote a small  Python Script which includes @Darryl Lee Request for those who don't have Bob CLI:

https://github.com/packhack/python-scripts/blob/main/jira/domainReview.py

import requests
import json

jiraURL = "https://<your-instance-url>/rest/migration/latest/email/domain-rules"

#Generate this from Database (PSQL)
# 
#select right(cwd_user.email_address, strpos(reverse(cwd_user.email_address), '@') - 1)
#        from cwd_user
#                 inner join cwd_directory cd on cd.id = cwd_user.directory_id
#        where cd.active = 1
#group by 1;

domainFile = "C:\\99-temp\\jiraDomainReview.txt"

headers = {
    "Accept": "application/json",
    "Authorization": "Bearer <Jira PAT>"
}

with open(domainFile, mode="r") as lists:
    for line in lists:
        trustDomain = {"domainName": line.replace('\n',''), "rule": "TRUSTED"}
        response = requests.put(jiraURL, json=trustDomain,headers=headers)
        print(trustDomain)
        print(response)

[sweixelbaumer]

So what am I supposed to do, trying to migrate a project with 3.4k email domains - that are of course not going to be migrated but still blocking a server to cloud migration @Renan Battaglin ?

Atlassian Support is ignoring my request.

This “security feature” is a non thought through patchwork at best. There is still no bulk handling of email domains offered - and JCMA is failing even though the user groups affected would not be migrated at all.

[sweixelbaumer]

Bump @Renan Battaglin : You were mentioning that support can give guidance - but I am getting no response from tech support for 5+ days now. Thanks in advance

[sweixelbaumer]

@Darryl Lee Could you elaborate further on the steps you took please? Thanks in advance

[Darryl Lee]

Hi @sweixelbaumer --

Sorry that Support has not been able to assist, as 3400 domains would indeed be a LOT of clicking.

To clarify, what @Patrick Schneider and I did is:

1. Export list of all user's email addresses
   1. Patrick used a direct SQL database commands in Postgres
   2. I used a ScriptRunner script from @Ravi Sagar (Sparxsys) 
2. Extract just the unique domains from all of those addresses
3. Review the list of those domains
4. Run either a Python script (which Patrick kindly provided) or Bob Swift's CLI within a "for loop" to "approve" (or not approve) all of those domains

So our lists of domains would look something like:

google.com
roku.com
netflix.com

And for me, the "for loop" (in a Mac terminal) would look like:

for x in `cat domainlist.txt`
do
acli jira --action renderRequest --requestType PUT --request '/rest/migration/latest/email/domain-rules' --requestParameters '{\"domainName\":\"$x\",\"rule\":\"NOT_TRUSTED\"}' --contentType JSON

done

It is... a tiny bit technical, but what we're basically doing is using scripts to do the same thing as selecting Trusted or Not Trusted for ALL of the domains in our domain list files. 

The key bit is which rule we select. In my case, since I was just doing a proof-of-concept, I chose "NOT_TRUSTED". Patrick chose "TRUSTED". 

You'll need to decide what you want to do for ALL of the domains on the list.

Alternately, you or maybe a team, could look at the domains and split it into two lists: TRUSTED and NOT_TRUSTED, and then run two different scripts.

Either way using scripts to automate this process will be far more error-proof than manually clicking and selecting 1000s of times.

[sweixelbaumer]

@Darryl Lee Kudos. Thanks a bunch for that extensive description. Very much appreciated 

[Greg Johnson]

Argh.  I'm trying to run JCMA and found I have >600 domains that need to be 'trusted' - all but one of them are actually old Jira Service Desk customers who never logged in but simply sent an email.

I don't see how this tedious clicking does anything at all to improve security.

And why did the UI designer not add a 'select all' button at the top?

@Renan Battaglin this visibility of JSD customers seems to contradict what you mentioned above over 5 months ago.  Also, I don't know when the promised UI improvements will be made - but I'm going to have to run @Patrick Schneider 's helpful SQL and then python to see if I can fix this.