Many companys desire a communication medium that keeps their employees connected. To achieve this, they often install a company-specific communication app. This can be done either by providing a new dedicated device to the employee or by implementing a bring your own device (BYOD) policy, where the company asks employees to use their personal devices.
Under the BYOD policy, companies require employees to install a mobile device management (MDM) app and activate a work profile.
Before, I had a basic understanding of work profiles and MDM apps, but I was somewhat skeptical and confused about their implications. Installing an MDM app on a personal device essentially grants control of the device to the company. The company can view or modify data on a device where an MDM app is installed. This raised concerns about the role of the MDM app and the extent to which it could access my personal data, such as contacts and photos. This prompted me to investigate further into what an MDM app is and its scope of data access on a device.
What is an MDM App?
Companies need to have control over a large number of devices distributed to employees. MDM software allows IT administrators to manage remote devices through a common console.
Companies aim to ensure:
- Proper security policies are enforced
- The exact location of the device
- The security of work-related data
- In the case of lost devices, the data can be remotely wiped out
MDM solutions provide these functionalities in a convenient way. They can be offered through an in-house server, a cloud-based MDM server, or as a software as a service (SaaS) solution. MDM servers are responsible for checking policies and enforcing them over the air through installed MDM apps.
LINE doesn't create MDM apps; instead, it utilizes this service to a certain extent.
While there are multiple solutions for MDM apps, one widely used and natively provided solution is Android Enterprise.
Android Enterprise
The Android ecosystem encompasses a wide variety of devices such as phones, tablets, watches, kiosks, point of sale systems, signage, and other personalized dedicated devices. Regardless of the device manufacturer or the installed OS version, all distributed devices can be easily managed with Android Enterprise.
The solution used for such a vast ecosystem must be trustworthy and easy for everyone to adopt. Companies should feel comfortable using it due to the wide range of features it provides. Also, users should find it reassuring enough to install MDM apps, knowing that their personal data stored on the device will not be accessed.
Let's delve into this from different perspectives.
Security
Android Enterprise is based on a defense-in-depth strategy.
Defense-in-depth is a security strategy primarily used in a cybersecurity context to ensure that the security system has multiple layers of protection. A zero-trust policy is utilized, meaning that the security of the entire system can't be reliant on the security of a single layer. Multiple layers of security are implemented to protect against various vulnerabilities, potential harmful apps, human errors, and other threats.
Android Enterprise also incorporates multiple layers of security.
Let's delve into each layer in greater detail.
Hardware Security
Android supports devices produced by a multitude of manufacturers. As a result, it becomes crucial to permit hardware that meets certain standards.
Hardware utilized for Android Enterprise should comply with the enterprise mobility management (EMM) API policies.
Devices are equipped with a trusted execution environment (TEE) for PIN verification and hardware-backed cryptographic key storage.
It's also advised to employ the StrongBox Keymaster, which utilizes hardware-backed tamper-evident storage to store keys.
Devices should support Android's verified boot to ensure that the device's OS or any other partition has not been compromised during or prior to the actual booting process.
Apps can use the verified boot status to determine whether the device on which they are running has been compromised or not.
OS platform security
Android offers the following methods of security by default in its OS:
Default storage system encryption
Up until Android version 7.0, partition-based encryption was employed. With this method, the entire storage block is encrypted with a single cryptographic key.
Starting with version 7.0, Android OS introduced file-based encryption, where each file can be encrypted individually using a different cryptographic key. This is why file-based encryption is considered more secure than the earlier partition-based encryption. By making encryption granular to the file level, it gives users and the system more control over which storage location is accessible and with what permissions.
From Android 10 onwards, file-based encryption became mandatory on all devices.
App sandboxing
Android OS utilizes Linux's UID-based mandatory access control. App sandboxing allows each app to run based on the permissions assigned to the user, and the app has restrictions on making system calls and accessing the file system.
This offers the advantage of isolating different users and profiles on the same device. Each user can have their own apps installed and their app storage space is completely isolated unless permissions are granted through content providers.
Google Play Protect
Google Play Protect plays a crucial role in managing apps installed on a device and mitigating potential threats. Every app released on the Play Store undergoes rigorous safety checks.
Play Services regularly scans the device to detect any harmful apps that may be present.
It also restricts permissions and either prompts the user or automatically revokes unused permissions that were previously granted to apps.
Furthermore, Google Play Protect alerts the user, deactivates, or removes any potentially harmful apps from the device.
Enterprise Management Mobility APIs
Enterprise Mobility Management APIs are a set of tools provided to simplify the management of distributed devices. With just a few clicks, multiple devices can be configured effortlessly.
These APIs assist in the following ways:
- Enforcing company-wide or department-specific policies on devices.
- Checking device compliance against various parameters such as the OS version, security patch level, etc.
- Temporarily or permanently locking devices.
- Remotely tracking devices.
- Remotely wiping out device data.
Types of devices
The classification of devices depends on the ownership and the extent of control the company has over the device.
The criteria used to decide the device type are as follows:
- Who owns the device?
- Who manages the data on the device?
- Who pays the bills?
- Who pays for the device?
- Who maintains the device?
The devices are categorized as follows:
Bring your own device (BYOD) refers to devices that are bought and maintained by the users themselves. Users grant the company permission to install an MDM app and a work profile, thus allowing the device to be used for company-related tasks. This setup enables users to use the device for both personal and work-related purposes concurrently, with no data overlap between the two profiles.
Company owned, personally enabled (COPE) refers to devices that are purchased and maintained by the company, but the company allows the user to use them for personal purposes up to a certain extent. These devices need to have both personal and work profiles installed.
Company owned, business only (COBO) refers to devices that are purchased and maintained by the company and are permitted to be used only for business purposes. The company has complete control over these types of devices.
Company owned, single use (COSU) refers to dedicated devices that are owned by the company and serve a specific purpose only. This category includes kiosks and personalized dedicated devices used in warehouses or healthcare facilities. These devices have very limited functionality, and the company has complete control over them.
Both BYOD and COPE devices require separate work and personal profiles. This separation allows the same device to be used for both work and personal purposes.
The device maintains these two profiles independently to ensure that their data and permissions do not overlap, unless expressly permitted by the user.
Work profiles
A work profile is a method to separate work-related apps from personal apps.
Companies wishing to manage a device install a work profile on the user's device. After installing the work profile and the MDM app, the company gains control over which apps can be installed in the work profile and what permissions are granted to it.
Since there is a clear separation between the work profile and the personal profile, the company can't access the user's personal data. Additionally, apps in the work profile can't read or modify the user's personal data.
The same app installed in both the personal and work profiles functions separately, without intermingling its data with each other, unless the user gives permission.
The work profile was first introduced in Android 5.1. Users can activate it by scanning a QR code provided by their company from
Device Settings > Google > Set up & Restore > Set up your Work Profile.
Companies can manage apps installed in the work profile remotely. They can also remotely wipe out the entire work profile without affecting the personal profile.
This eliminates the need to factory reset the entire device when the user or company decides to stop supporting the work profile.
Are work profile apps different?
Apps developed for the work profile are identical to other Android apps developed for the personal profile.
Developers are advised to follow guidelines and best practices, along with several additional considerations:
- Resolve activity before launching
- Given that the work profile is entirely controlled by the company, there's a possibility that certain apps may be installed at any time, depending on the company's policy. Therefore, it's recommended to resolve the activity before launching it to prevent crashes.
- Use content provider
- The storage space is partitioned between the personal and work profiles. A file accessible in one profile may not be accessible in the other. Furthermore, a URL specified with "file://" and file path might not be valid for an app in the other profile. Therefore, it's recommended to use content provider URLs instead of specifying file paths.
- CrossProfileApps for switching profiles within the app
- Apps installed in both profiles display data depending on which profile opened the app. Such apps can switch between different profiles within the app using the CrossProfileApps system service. This convenient feature allows users to switch between different profile data without having to open the other profile.
For more information on how to develop work profile apps, you can refer to this codelab.
Conclusion
Indeed, the work profile feature in Android creates a distinct boundary between personal and work data.
The storage space and data access are completely separate, and one profile can't access the other's data without user consent.
Even the same app installed in both personal and work profiles uses different storage space and doesn't mix data. It's akin to having two virtual devices within a single physical device.
References
Android Enterprise
Android Enterprise - Overview
Android Developers - Work profiles