• Auteur: Thierry Lammers
• Datum: 29 apr 2019
• 6 min

|

Ben jij al begonnen met de voorbereidingen voor het migreren van de Android toestellen binnen je organisatie naar Android Enterprise? Nee? Dan wordt het hoog tijd want de klok tikt!

Waarom migreren naar Android Enterprise?

In Android versie 2.2 introduceerde Google de Android Device Administrator API’s. Hierdoor kan je Android toestellen beheren met een 3rd party EMM-oplossing zoals MobileIron en Microsoft Intune. Deze API’s konden prima worden gebruikt voor het tot op zekere hoogte beveiligen van een toestel. Het afdwingen van een Pincode of wachtwoord, wissen van een toestel op afstand of uitzetten van bepaalde functionaliteit, etc.. Maar bijvoorbeeld het automatisch configureren van de mail-applicatie op het toestel was niet mogelijk. Om meer beheermogelijkheden te bieden gingen diverse hardware leveranciers hun eigen API’s toevoegen aan Android. Zoals bijvoorbeeld de Samsung Knox API’s, maar ook andere leveranciers hebben (met wisselend succes) getracht hun eigen functionaliteit toe te voegen.

Diversiteit zorgt voor complexiteit

De enorme diversiteit in hardware- en softwareversies maakte het beheren/beveiligen van Android toestellen binnen bedrijven erg complex. Zeker wanneer Bring Your Own Device (BYOD) wordt toegestaan kan dit een interessante uitdaging zijn. Op Samsung en HTC-toestellen bestaat de mogelijkheid de mail applicaties van de fabrikant te kiezen. Voor alle andere merken was dit geenoptie en moest een aparte mail-applicatie worden geïnstalleerd. Daarnaast kon op Samsung toestellen een applicatie blacklist worden gebruikt, op alle andere merken niet.

Google zag al snel in dat dit de acceptatiegraad van Android binnen bedrijven enorm in de weg zat. Daarom hebben zij in Android 5.1 nieuwe API’s toegevoegd, de Android Enterprise API’s! Met deze nieuwe set van API’s zijn er veel nieuwe beheermogelijkheden voor Android toestellen beschikbaar gekomen op Android toestellen van alle leveranciers. Zo kunnen alle toestellen op dezelfde manier worden beheerd. Hierdoor is er geen aparte eindgebruikersdocumentatie meer nodig voor de diverse merken hardware. Daarnaast wordt het voor de supportafdeling een stuk eenvoudiger om problemen op te lossen.

Maar waarom MOET je migreren naar Android Enterprise?

Met de introductie van Android Enterprise in Android 5.1 (Lollipop) en de verplichting voor hardware fabrikanten om dit vanaf Android 6 (Marshmallow) standaard toe te voegen aan hun toestellen is Google aan het klaarstomen voor nog meer Android in het bedrijfsleven. Sterker nog: Google heeft aangegeven dat de ‘oude’ Device Administrator API’s op termijn gedeeltelijk gaan verdwijnen. De gevolgen hiervan gaan best ver! Een pincode of wachtwoord afdwingen via deze route is niet meer mogelijk, ook niet via een Enterprise Mobility Management product.

 

Android Q vs EMM producten

Android Q, is momenteel in beta en komt waarschijnlijk in najaar van 2019 algemeen beschikbaar. Dit is de bewuste versie van Android waarin de Device Administrator API’s gedeeltelijk verwijderd zijn. Zodra een EMM-leverancier besluit om de EMM-client (MobileIron@Work, Intune Company Portal, AirWatch MDM-agent, etc.) naar API-level 29 (=Android Q) te migreren kunnen toestellen die op Android Q draaien niet meer goed worden beheerd.

De verwachting is dat de meeste EMM-leveranciers dit snel na het beschikbaar komen van Android Q zullen doen zodat zij ook gebruik kunnen gaan maken van nieuwe EMM-functionaliteit van Android Q. Het is dus van belang om er voor die tijd voor te zorgen dat toestellen met Android Q kunnen worden beheerd op basis van Android Enterprise.

 

Android Enterprise, de keuze is reuze!

Met Android Enterprise kunnen toestellen op vier verschillende manieren worden beheerd zoals:

Work profile (BYOD)

Het work profile gebruik je voor het beheren van (Bring Your Own Device) privé toestellen van werknemers. Hiermee wordt er op het toestel een zakelijke container aangemaakt waarin de zakelijke applicaties en profielen worden geïnstalleerd. De gebruiker kan binnen de zakelijke container uitsluitend applicaties installeren die door de organisatie vanuit EMM worden aangeboden. In het privé gedeelte van het toestel kan de gebruiker iedere applicatie die hij/zij wil. De werkgever heeft verder geen enkele invloed op het privégedeelte van het toestel. Er is een volledige data-splitsing tussen het privé en zakelijk deel van het toestel. Vanuit de EMM oplossing kan, indien nodig, de zakelijke container van het toestel worden verwijderd maar het toestel kan vanuit EMM nooit volledig worden gewist.

Work-managed (COBO)

COBO (Company Owned Business Only) zet je in voor het volledig kunnen beheren van zakelijk uitgegeven toestellen. Hierbij kan de gebruiker uitsluitend applicaties installeren die door de organisatie vanuit EMM worden aangeboden. Dit is het Android Enterprise implementatiemodel met de meeste restricties.

Work profile on fully managed devices (COPE)

COPE (Company Owned Personally Enabled) zet je in voor het volledig kunnen beheren van zakelijk uitgegeven toestellen waarop, voor de eindgebruiker, ook een privé profiel wordt aangemaakt. In het privé profiel kan hij/zij dan zelf applicaties installeren maar in de zakelijke container uitsluitend applicaties die door de organisatie vanuit EMM worden aangeboden. Er is een volledige data-splitsing tussen het privé en zakelijk deel van het toestel. Omdat het toestel volledig vanuit EMM worden beheerd kan het toestel indien nodig ook volledig worden gewist. Dit laatste is dus echt een groot verschil met het Work profile.

Single use (COSU)

COSU (Company Owned Single Use) is een speciale configuratie die wij vaak terugzien in healthcare, retail en transport. We noemen dit ook wel kiosk-mode waarbij de gebruiker de beschikking heeft over 1 of enkele applicaties. Daarnaast heeft de gebruiker niet of heel beperkt toegang tot de systeeminstellingen van het apparaat. COSU-toestellen kunnen ook worden gebruikt door meerdere gebruikers waarbij iedere gebruiker na het inloggen de beschikking heeft over zijn/haar eigen applicaties en profielen.

 

Big Bang of gefaseerde migratie?

Als bedrijf zal je moeten bepalen welke manier van migreren naar Android Enterprise je hanteert. Ga je voor big-bang of een gefaseerde (‘coexistence’) migratie? Deze keuze wordt onder andere beïnvloed door voor welke Android Enterprise scenario, of scenario’s wordt gekozen. De hierboven beschreven varianten COBO, COPE en COSU vereisen namelijk een factory-reset van het toestel terwijl dat voor de BYOD niet nodig is.

Gefaseerde migratie

Je kan er voor kiezen om de migratie naar Android Enterprise gelijktijdig uit te voeren met vervanging van hardware of uitsluitend af te dwingen voor toestellen die geüpgraded worden naar Android Q. Het nadeel van een gefaseerde migratie is dat er ‘tijdelijk’ meerdere Android configuraties beheerd moeten worden vanuit de EMM-oplossing. Dit betekent meer beheer en complexere support inspanning.

Big Bang migratie

Een big-bang migratie, zeker als wordt gekozen voor COBO, COPE of COSU vergt meer werk en down-tijd voor de eindgebruiker. Wel levert dit direct een eenvoudiger te beheren en ondersteunen omgeving op.

De middenweg

Als tussenvariant kan ervoor worden gekozen om alle bestaande toestellen, ook de zakelijke uitgegeven toestellen, te migreren naar de BYOD-variant en zakelijke toestellen bij vervanging of uitlevering aan een andere gebruiker te migreren naar COBO, COPE of COSU.

 

Blijven alle applicaties gewoon werken?

Nee, helaas. Alle applicaties en bijbehorende configuraties zullen moeten worden gecontroleerd en waar nodig aangepast. Android Enterprise en in-house applicaties is een combinatie die niet meer zal werken. Maak je hier wel gebruik van? Dan zullen deze voor Android Enterprise toestellen aangeboden moeten worden vanuit de Google Play Store.

MicroVPN verbindingen zoals MobileIron AppConnect komen te vervallen

Specifieke applicatiefunctionaliteit van EMM-leveranciers, zoals bijvoorbeeld AppConnect van MobileIron, wordt niet ondersteund in Android Enterprise. Deze applicaties zullen dus moeten worden omgezet naar een native Android applicatie en indien nodig worden gecombineerd met een VPN-oplossing voor toegang tot on-premise back-end systemen.

Een goed voorbeeld is de veel gebruikte applicatie MobileIron Web@Work voor het ontsluiten van interne webpagina’s. Web@Work werkt niet in Android Enterprise en dient te worden vervangen door Google Chrome in combinatie met MobileIron Tunnel.

Hypergate als vervanging van Single Sign On met Kerberos

Daarnaast ondersteunt Android Enterprise standaard geen Kerberos (= een  single sign-on authenticatie). Dus maak je nu gebruik van Kerberos authenticatie voor websites via MobileIron Web@Work? Dan zal je naast Google Chrome en MobileIron Tunnel ook de applicatie Hypergate moeten aanschaffen en implementeren om single sign-on te kunnen blijven aanbieden. BLAUD kan je tijdig ondersteunen met de levering en implementatie van Hypergate.

Controleer je huidige EMM licentielandschap

Het is belangrijk om goed om te kijken of je huidige EMM licenties nog voldoen aan de functionaliteiten die binnen Android Enterprise wordt aangeboden. Zo volstaat bij het gebruik van Google Chrome in combinatie met MobileIron Tunnel een ‘gold’ licentie. Voor het gebruik van andere applicaties in combinatie met MobileIron Tunnel een ‘platinum’ licentie nodig.

Conclusie

Ben je nog niet begonnen met de voorbereidingen? Begin daar dan snel mee. Mocht je hulp nodig hebben bij het voorbereiden, of het uitvoeren van de migratie naar Android Enterprise. Laat het ons weten via onderstaand formulier. Wij nemen zo snel mogelijk contact met je op!

|