Security
- Microsoft BitLocker encryption
- Microsoft Sensitivity Labels
- Certificate usage
- Restore Portal authentication process
- Permission Types - Application vs Delegated
Microsoft BitLocker encryption
Using BitLocker encryption on volumes used as a target repository for Veeam Backup for Microsoft 365 is supported. The time for backup and restore processes was not impacted during tests. Please be aware that the BitLocker processing time to encrypt or decrypt a volume can be increased during backup and restore tasks.
Microsoft Sensitivity Labels
Veeam Backup for Microsoft 365 supports backup and restore of documents and emails associated with a specific sensitivity label in M365. If a sensitivity label is applied to an email or document, Veeam Backup for Microsoft 365 backs up this document with this information and can restore it.
Sensitivity labels themselves (configuration in security and compliance admin center) are not supported for backup/restore.
Backup and restore of information about labels that are applied to a site collection are not supported at the moment.
Certificate usage
The following diagram shows the different certificates used by Veeam Backup for Microsoft 365
- Defined in General options/Security -> Backup server certificate (can be trusted or untrusted)
- Defined in Add organization -> Azure Application certificate (can be trusted or untrusted)
- Defined in General options/Authentication -> Restore operator authentication certificate (can be trusted or untrusted)
- Defined in General options/Restore Portal -> Azure Application certificate (can be trusted or untrusted)
- Defined in General options/REST API -> REST API service certificate (trusted is recommended)
Restore Portal authentication process
The process of user authentication for the restore portal is done in four phases:
- Portal is getting loaded from Rest API
- User logs on through OAuth2
- Authorization is getting verified
- Tokens for restore operations are provided
The following diagram shows the details of each phase.
Permission Types - Application vs Delegated
Microsoft knows two types of permissions for Azure AD applications (apps), which are Application and Delegated.
An Application type permission is given to the app itself. The app can act without a signed-in user present with the given permissions. Application permissions for an app are also it’s effective permissions. The Application type permissions are used when authenticating with an Application Certificate.
The Delegated type permission is also given to the app, but they require a signed-in user on who’s behalf the app will act. The app can only gain a given permission of the type Delegated when the user using the app also has this permission. The effective permissions of the app are based on the permissions of the user and an app can never have more permissions than the user using it. The Delegated permissions are the ones used for the Device Workflow.
More background details can be found in the Microsoft Documentation. The required permissions for each type used by VB365 can be found in the Help Center.
Why Write Permissions for Backup?
Some of the data Veeam needs to read is only available with write permissions. Though only read operations are performed, the read permissions are not enough to use some API calls.
An example for this is: Sites.ReadWrite.All is required to query the Azure AD for a list of SharePoint Online sites and getting a list of download URLs for files and their versions.