With the advent of the SmartPhone, access to a user’s data has never been easier. Teachers are able to grade papers from iPads. Students are able to turn in assignments from their phones. The nature of having an account that is persistently signed in is a key feature of the mobile platform. Whether it’s a personal account or a managed one, users can add accounts in one place on the phone, and any information associated with that account becomes accessible to any authorized application on the phone. With this persistent access in mind, Google has provided mobile settings to help protect data stored in Google.
Sync settings
When it comes to mobile management, Google splits identifies three categories: Android, iOS, and Google Sync. Each of these can be disabled individually, which would prevent users from being able to sign-in and sync data from Google using that type of device on their managed device.
Android and iOS are pretty straightforward in understanding what disabling this sync feature would do. “Google Sync” is a bit more ambiguous as the name has been reused by Google for other services. To help clarify what leaving this enabled allows users to sync, Google has provided this article. Google Sync is primarily used for older devices, Windows (mobile), and Microsoft Outlook. Its general availability has been end of lifed since 2013 but is available for G Suite customers. During this discussion, we are mainly focussed on iOS and Android devices.
Why is protection important, even on personal devices?
When an application is installed on a mobile device, it requests access to certain scopes of data. Many times the application only wants to know who a user is. However, some applications ask for the ability to know information about the user. When these scopes are requested, the application is not installed until the user has granted the requested access to the application. This means that whether on a personal device or one provided by the school, the data is associated with the user.
Location data, Drive file management, Calendar management, and Microphone access are just a few of the permissions that an application may ask a user permission for before the user is able to install the application. App distribution teams like the Play Protect team (Google) or App Store team (Apple) work to ensure that bad actors don’t get through, but not all malicious apps get caught. Doing a basic search for “malicious android apps” or “malicious ios apps” returns news reports of unfriendly apps which have slipped past the distribution teams. And if one of these malicious apps is granted access, it doesn’t take long for them to perform their designed task, whether that’s to collect data or to send out an email pretending to be the person who installed it.
Basic management
The first level of protection administrators can deploy is a screen-lock on user devices, while not requiring any sort of management installation. This is available with “basic” management, and really doesn’t protect the school data from anything other than an individual with physical access to a device. It will not protect against any rogue applications or limit an authorized user’s ability to install or authorize an application.
With Basic management, data protection is also limited. Administrators can only administratively wipe the managed account data from the device, and not any apps. Admins cannot see which apps are installed for users, or apply security policy on phones which users would have signed in to using their managed devices. Basic management also doesn’t apply any policy settings for iOS devices, aside from being able to force iOS devices to have some sort of lock screen configured.
Play Store service
The next step an administrator can take leverages the Google Play additional service. This was originally a solution proposed by Google support for preventing managed users on Android from being able to install any application. The idea was that if a user added their managed Google Workspace account to a personal device, and then later went to the Play store to install an application, if the Google Play additional service was disabled users could only install applications using their personal accounts.
The emphasis on this solution is understanding the difference between installing and authorizing. With this setup, the personal account can install anything, and then when authorizing (granting permission) to the application, they could choose any account, including managed Google Workspace accounts. This would make sure that any application which was installed on a phone with a managed account wasn’t accidentally given access – it was always deliberate. It also worked without having any client side application installed.
This solution only supports Android devices – iOS is completely unmanaged. It also relies on the end user’s knowledge of the applications that they were installing.
Advanced management
Advanced management is the direction that Amplified IT and Google have been moving people that want to have greater control of their data. Advanced management has received significant recent development activity, reducing the effort required by end users. In early revisions, users would receive a notification that they needed to install an application named “device policy” and grant it permission to wipe the phone before data would sync from their managed account to their phones. The user’s experience with advanced management will vary based on their OS version, but generally require installation of an app/certificate before settings are applied.
With advanced management, administrators get a lot better control of what users are able to do with their managed accounts on mobile platforms. If you are wanting to manage iOS devices, you will need to setup a push certificate, and remember to renew this before it expires each year.
Forcing work profiles
Use of work profiles on Android or security profiles on iOS is the ideal solution for schools. This setting allows administrators the ability to create Sandbox for their users, isolating the managed accounts from the personal account that are on a device. The default setting for this is a user Opt-in, however it can be forced by an administrator. As with advanced management, the user’s experience will vary based on their operating system version with newer versions having smoother transitions between profiles.
With a work profile, app management becomes much more intuitive as well. Configuring the mobile whitelisted apps will limit the applications that users can install on their phones using their work profile. Although this feature is available when using only advanced management without a work profile, the sandboxed nature of work profiles ensures that apps installed by a personal account cannot be authorized by a work account.
With a work profile configured, users only see the apps which you permit them to in their work Play Store. This is configurable on a per OU basis, and admins can configure each OrgUnit with their own app store, just like with ChromeApps or the Play Store on ChromeOS.
If you are unable to configure an app with Per-OU permissions, you can locally edit the source code of the Admin console to allow you to make the appropriate selections.
Education Plus
With the release of Education Plus, Google has promised additional reporting for mobile devices as well as the ability to automate tasks related to mobile device management performed by users. The full list of Advanced Mobile Management functionality that Google is offering for Education Plus customers can be found here.
Advanced mobile device management is only the tip of the iceberg with the enhancements that come with Education Plus. If you would like to know more about the additional features which are available in the Education Plus suite, you can book a call with Amplified IT’s partner manager, Catherine Weers, who will be happy to get the answer to any questions you may have.
Mobile management is all about protecting data owned regardless of where it is accessed. As users are on their personal devices accessing potentially sensitive work content, it’s important that administrators maintain a balance of accessibility and security when determining how they are going to let users access data.
FAQ:
Q: Where are Android devices located in my OrgUnit structure?
A: Since the majority of settings are User based settings, the settings you apply will be based on where the Users are located in the OrgUnit structure. Device settings currently cannot be configured for K-12 Education domains, and don’t presently live in the OU structure.
Q: Can I push out mobile networks to my Android devices?
A: No, this requires a mobile device license which is not available to K-12 education domains.
Q: Where can I find a full list of the differences between mobile management options?
A: Google has provided this list of feature comparisons between basic and advanced management.
If you would like assistance with managing your settings or training your team, book some time in with our technical services team by reaching out to support@amplifiedit.com. Learn more about the various ways we can help your team.
-
Stephen Gale
Technical Support Analyst -
About the Author:
Stephen lives in Utah and enjoys the puzzle of investigating users’ problems and finding potential solutions. A recovering/reformed gamer, Stephen throws himself into his passion for staying on top of all things Chrome OS and Chromebook related. Prior to joining Amplified IT, Stephen served as a network admin in a therapeutic boarding school and an IT director, where he implemented Google Workspace for Education. Stephen has studied computer science and security at Weber State University, Western Governors University. A self-anointed honor, Stephen likes Chromebooks more than almost anyone else in the world.