Organization might have need to migrate or move Cloud App Security (MCAS) instance to another datacenter. Reasons vary, company acquisitions in cases where organizations are located in different geo location or regions. Currently, in EU area ‘Brexit’ is driver for some organizations. For some organizations, it has been a bit surprising that MCAS instance has been located in UK even though other workloads are located in other datacenter. Currently, MCAS is located in the following datacenters based on Microsoft documentation:
- US1 – located in West US
- US2 – I don’t have detailed information
- US3 – West US2
- EU1 -West Europe
- EU2 – UK South
- US GOV1 – I don’t have detailed information
- GCC – I don’t have detailed information
Another consideration is, that we are not talking about traditional migration in cases like this. It is more of deleting the old instance and creating new one to different location in a code level. It means that you will loose ALL the collected data and configurations on the MCAS instance. This needs to be taken into account on preparation phase.
Disclaimer: There isn’t official documentation available about the procedure and all documentation is based on own experience during the instance transfer.
MCAS Datacenter Locations
To find out where your MCAS instance is located navigate to your MCAS portal and select question mark symbol from the top right corner and about underneath. From the windows that opens you can see the version number and datacenter location and portal URL.
MCAS has the following IP-address and DNS names defined for datacenter network access. Full list of services and network requirements is found here.
During the process, the organization will lose all the data MCAS has been collected during its lifetime. In our case, we decided that the following items needs to be covered in preparation phase:
- Activity Log
- Configuration data
In the past life, I did different migrations on weekly basis and I’ve learned that the more data you have the more options you have in case of failed migration. Taking also into account, that when moving MCAS to another datacenter you will lose ALL the data. This means that re-deployment, at least in some level, is needed.
Before the actual instance will be deleted and re-created we wanted to have all possible data in our own control, just in case. Even though, for example the Activity Log events are found from the ecosystem they are shattered across the environment. For that reason we wanted to have those ones also collected.
The following reports & data were taken out to have best possible coverage from MCAS:
- Cloud Discovery executive report
- Activity Log
- File report (was not in use in our case)
- Imported Groups (was not in use in our case)
- Identity Security posture
- OAuth apps
Record all connected apps (API connectors & Conditional Access apps) and their settings because you need to re-connect the apps to the new instance.
Inter-Connections with Other Security Solutions
Integrations are found underneath settings and these needs to be verified and if necessary, re-enabled after transfer.
At the time of writing is still unknown what data will be missing after the transfer and for that reason it’s important to get MCAS instance settings out from the portal. Settings are exported as json which helps a lot when comparing to data afterwards. As you can see from the picture below, setting export contains “policies, tags, IP ranges, internal domains & organization details”.
For comparison, we used PowerShell script made by my colleague Markus Pitkäranta. Script removed environment specific identifiers and did some other small modifications to make data comparison easier.
To get 180 days of activity log out is possible through MCAS API. When exported first 5000 row from the portal I got events from the last 30 minutes so that doesn’t help at all. Because of that, we decided to use MCAS API to get all events from the last 180 days out from the instance.
My colleague Markus Pitkäranta created a PowerShell script that takes 5000 events (limit for one query) and loops that out as long as “hasNext” value is false. In the demo environment script was running approx. 3 hours. In the customer environment the estimate was 31 days, whoooah. Script was running with the following statistics:
- 30min period
- Activities from the last 2,5 hours
- Events: 130k
- Events in hour: 52k
- Events in month: 20 million
It definitely meant that we needed another approach. In the latest MCAS release notes there was announcement of new feature, more richer integration with MCAS Activity Log and M365 Defender. Now, the MCAS sends events from most of the workloads to M365D, and same events are in Unified Audit Log (UAL). Of course, if you would have bunch of API connections I would recommend to ingest MCAS Activity Log to Azure Sentinel but that’s not the case with us.
The day when transfer happened was Sunday. The “migration” process took couple of hours and was ready on late Sunday evening. On Monday empty MCAS instance in different location was waiting for us. it meant that Monday was quite busy:)
High-level tasks after the datacenter transfer:
- Configure MCAS general settings
- Connect apps (App connectors, onboarding apps for app control)
- Create custom policies
- Fine-tune built-in policies based on your earlier configuration
- Create IP-address ranges & tags
- Set up Cloud Discovery
- Re-enable all security solutions integrations
- Azure AD Identity Protection
- Defender for Identity
- Defender for Endpoint
- Azure Sentinel
If you would like to automate MCAS deployment there are couple of resources which I would recommend:
Notes from post-migration
Those of you who have deploy MCAS are familiar that after creating app connector, fetching the data from the app might take some time and we are talking hours here.
- O365 & Azure
- First activities logged 1 hour after enabling the integration but it took still after 12 hours to get data from all O365 workloads. This is expected taking into account UAL latencies
- Third party app connectors
- Same as above
- “File Scanning” takes a lot of time as expected
M365 Defender integration
After 4 days of waiting the MCAS & MDI raw data was missing from the following M365 Defender tables:
MS support confirmed that this could take as much as seven (7) days to complete. So, we are waiting and I’ll update the blog next week about this.
Cloud Discovery service ingest the data from Microsoft Defender for Endpoint service and generates report that’s visible in MCAS dashboard. After datacenter transfer we could verify that data is ingested but report was not generated. Finally, on Thursday the report was generated so it took four (4) days totally.
More info of Cloud Discovery – Learn how to get started in Cloud Discovery from Microsoft Cloud App Security
Security Solutions Inter-connections
The best synergy advantages from the security solutions come with the integrations between the products. Luckily, most of the integrations worked out of the box without need to re-enable integration between MCAS and the solutions. If you want to have information how these solutions are interacting between each others take a look on my post – Azure and M365 Defender – Security Solutions Data Flows – Sam’s Corner (samilamppu.com).
Even though, Microsoft engineering does the MCAS instance deletion and creates new instance to a new location there are bunch of tasks you need to take care of especially in case where MCAS would be heavily used for security monitoring, governance actions and protecting the applications.
MCAS has API which could be used to automate some parts but in our case we, MCAS wasn’t running as ‘full steam mode’ and decided to do all the configuration & integrations manually from the portal.
Hope this helps if you are facing the same situation!