企業(yè)移動管理技術的探索與分析

王川++牟琳++雷靈光++向繼

摘要：隨著移動設備在企業(yè)中的大批出現(xiàn)，不同設備、不同操作系統(tǒng)平臺、大量移動應用程序的管控讓IT部門捉襟見肘。為此，企業(yè)移動管理系統(tǒng)（簡稱，EMMS）應運而生。然而，從目前來看EMMS仍然是一個正在發(fā)展中的產(chǎn)業(yè)，相關的功能和技術仍然在不斷的探索和完善中。本文從技術層面，探索和分析iOS和Android平臺EMMS功能的發(fā)展現(xiàn)狀，包括產(chǎn)業(yè)模式、管控機制實施過程、功能支持程度等，并通過對比分析探討不同實現(xiàn)方案的優(yōu)勢和劣勢，以及其中可能存在的安全隱患，為iOS和Android平臺EMMS產(chǎn)品的設計和開發(fā)提供參考，也為選擇EMMS產(chǎn)品的企業(yè)提供客觀的了解。同時，期望能在總結中對EMMS的未來發(fā)展提供一些思考。

關鍵詞：企業(yè)移動管理；移動應用管理；移動設備管理；移動內(nèi)容管理；COPE設備；BYOD設備

中圖分類號：TP311

文獻標識碼：A

DOI：10.3969/j.issn.1003-6970.2015.08.010

0 引言

隨著移動設備的普及，越來越多的移動應用程序在企業(yè)的管理和辦公中發(fā)揮重要作用，為企業(yè)提供了高效和便利。然而，伴隨著移動設備在企業(yè)中的大批出現(xiàn)，不同設備、不同操作系統(tǒng)平臺、大量移動應用程序的管控讓IT部門捉襟見肘。為此，企業(yè)移動管理系統(tǒng)（簡稱，EMMS）應運而生，EMMS充分利用移動互聯(lián)網(wǎng)、智能移動終端，為企業(yè)提供集移動設備管理（簡稱MDM）、移動應用管理（簡稱，MAM）、移動內(nèi)容管理（簡稱MCM）于一體的全方位解決方案，從而更好的幫助企業(yè)解決COPE（企業(yè)下發(fā)設備）設備的統(tǒng)一綜合管控和BYOD（員工自帶設備）設備的安全應用。隨著EMMS需求的凸顯，許多大型IT產(chǎn)商也開始競相角逐企業(yè)移動管理市場，著手研制企業(yè)移動管理系統(tǒng)或斥巨資收購成熟的企業(yè)移動管理產(chǎn)品。比如，2014年1月，虛擬軟件巨頭VMware公司以15.4億美元的價格收購移動設備管理領域頂級公司AirWatch。然而，從目前來看，EMMS仍然是一個正在發(fā)展中的產(chǎn)業(yè)，相關的功能和技術仍然在不斷的探索和完善中。本文力圖從技術層面對EMMS的現(xiàn)狀作一個總結和分析，以期在總結中對EMMS的未來發(fā)展提供一些思考。

EMMS提供的管控功能主要是針對移動終端設備、設備上的應用、設備上的文檔等，必須依托于移動終端設備來完成，因此離不開移動終端操作系統(tǒng)的支持。主流的移動操作系統(tǒng)如iOS、Android等也逐漸在系統(tǒng)底層提供了EMMS相關功能的支持。比如Apple從iOS5開始提供MDM管控的相關功能，并且隨著iOS6、iOS7、iOS8的發(fā)布，可以實施的管控功能不斷增加；Google從Android2.2開始提供MDM管控功能，但是相比iOS，Android系統(tǒng)提供的管控功能非常有限。除了管控能力支持有差異，iOS和Android系統(tǒng)在EMMS功能的實現(xiàn)原理上也有很大不同。本文從技術層面，探索和分析iOS和Android平臺EMMS功能的發(fā)展現(xiàn)狀，包括產(chǎn)業(yè)模式、管控機制實施過程、功能支持程度等，并通過對比分析探討不同實現(xiàn)方案的優(yōu)勢和劣勢，以及其中可能存在的安全隱患，為iOS和Android平臺EMMS產(chǎn)品的設計和開發(fā)提供參考，也為選擇EMMS產(chǎn)品的企業(yè)提供客觀的了解。

1 iOS平臺企業(yè)移動管理技術

iOS平臺的企業(yè)移動管理采用Server-based機制，即所有關鍵的管控操作（比如設備功能的禁用和啟用）都是由服務器端發(fā)起的，客戶端能夠自主管控的功能非常有限。本節(jié)從產(chǎn)業(yè)模式、管控機制實施過程、功能支持程度等方面分析iOS平臺的企業(yè)移動管理技術。

1.1 產(chǎn)業(yè)模式

蘋果在運營上采用比較封閉的系統(tǒng)生態(tài)，不僅iOS源碼本身不開放，一般情況下，第三方系統(tǒng)想要接人iOS環(huán)境，都需要通過蘋果的認證和管控。比如，第三方開發(fā)的APP必須通過蘋果審核才能公開發(fā)布，而且只能通過iOS系統(tǒng)自帶的App Store進行下載和安裝（除非系統(tǒng)越獄）。在EMMS功能上，蘋果也沿襲了一貫的封閉模式：首先，對開發(fā)者進行限制，在開發(fā)EMMS系統(tǒng)之前，蘋果會對開發(fā)EMMS系統(tǒng)的企業(yè)資質(zhì)進行認證，認證通過并獲得企業(yè)開發(fā)證書之后才能著手開發(fā)iOS EMMS系統(tǒng)（具體參考0）；其次，對管控的實施進行限制，在EMMS系統(tǒng)的運行中，必須使用蘋果的推送服務器（簡稱APNS）下發(fā)管控策略，才能對iOS設備及設備上的應用實施管控，而且必須申請?zhí)O果頒發(fā)的APNS證書（具體參考0）；最后，對能夠進行的管控操作進行限制（具體參考0），企業(yè)開發(fā)的EMMS系統(tǒng)能夠進行的管控僅限于蘋果在MDM開發(fā)協(xié)議中定義和提供的。通過這些限制，蘋果很容易對產(chǎn)業(yè)整體生態(tài)環(huán)境的安全性進行掌控，比如一旦發(fā)現(xiàn)某個企業(yè)的證書被惡意使用，直接撤銷下發(fā)的企業(yè)證書或撤銷APNS證書即可使EMMS的管控失效。

1.2 管控機制實施過程

前文提到蘋果的EMMS管理采用Server-based機制，而且對開發(fā)者、管控流程進行了限制，這些可以在EMMS的管控機制實施過程中看到。總體來說，蘋果采用圖1所示EMMS管控框架，系統(tǒng)至少包含三部分，即被管控設備、執(zhí)行管控的服務器、APNS，設備注冊和管控的實施流程為：1）iOS客戶端通過有線或無線的方式安裝MDM管控配置文件（圖1所示的Mdm.mobileconfig文件），在該文件中指定一個設備注冊和管控指令獲取的URL地址（服務器地址）；2）iOS系統(tǒng)向所指定的設備注冊URL發(fā)送注冊請求，請求成功后設備進入監(jiān)管狀態(tài)；3）當需要下發(fā)管控操作（比如鎖屏）或設備策略（比如密碼策略、設備限制策略等）時，服務器端推送管控通知至APNS；4）APNS收到服務器端的管控通知，發(fā)送通知告知客戶端有新的管控命令（僅發(fā)送一個簡單的告知有新命令的消息，而不發(fā)送具體的命令）；5）被管控的設備接收到消息，連接至管控指令獲取URL，獲取管控指令，執(zhí)行管控操作并反饋執(zhí)行結果。從該流程可以看出，客戶端和服務器之間無需維護長連接，當需要下發(fā)管控指令時，服務器端只能通過APNS服務器喚醒設備，由設備主動連接服務器并獲取管控指令，當管控指令執(zhí)行完畢，客戶端和服務器之間斷開連接。而且iOS設備上無需安裝客戶端代碼，蘋果把執(zhí)行管控指令和策略的功能內(nèi)置到iOS系統(tǒng)底層。為此，蘋果提供了一套標準規(guī)范對管控操作的發(fā)起進行限定，企業(yè)移動管理服務器只能按照標準的格式組裝管控代碼并配置服務器，才能保證管控操作正確、安全的執(zhí)行。

首先，企業(yè)移動管理服務器只能通過蘋果的APNS服務器進行管控指令和策略的下發(fā)，并且策略和指令必須按照蘋果預先定義的格式進行組裝才能在客戶端正常執(zhí)行，即XML格式的plist文件，圖所示為iOS鎖屏命令對應的plist文件。

其次，企業(yè)移動管理服務器必須接受iOS設備和APNS的認證后，才能正常發(fā)起管控，具體為：1）企業(yè)移動管理服務器必須配置為SSL服務器（圖所示的SSL證書），iOS設備上通過安裝SSL服務器證書的根證書對企業(yè)移動管理服務器進行認證.該根證書包含在圖所示的Mdm.mobileconfig文件中（即圖所示的SSL根證書，當為多級證書時，需要包含所有證書鏈上的證書），iOS設備通過HTTPS方式獲取管控指令。可選地，企業(yè)管理服務器也可以對iOS設備進行認證，基于圖所示的Device證書，該證書包含在Mdm.mobileconfig文件中；2）APNS認證企業(yè)移動管理服務器的管控推送請求，企業(yè)移動管理服務器通過APNS下發(fā)的管控通知使用蘋果下發(fā)的一個推送證書（即圖所示的APSP.p12）進行簽名，認證通過后APNS才將管控通知轉發(fā)至對應的iOS設備。

iOS平臺的企業(yè)移動管理已經(jīng)形成了一套較為標準、規(guī)范的操作流程，作為Server-based的管控機制，在管控實施過程中，蘋果針對企業(yè)移動管理服務器提出了一套較為嚴格的安全要求，這在一定程度上保證了蘋果的企業(yè)移動管理生態(tài)系統(tǒng)整體的安全性。

1.3 功能支持程度

在移動管理功能的支持上，蘋果從iOS5開始引入MDM管控功能，在每次版本更新時就進一步豐富管控功能。總體來說，功能比較多，包含了設備設置、設備信息提取、設備管控、應用管控等，具體如表1所示。

2 Android平臺企業(yè)移動管理技術

與iOS平臺不同，Android平臺的企業(yè)移動管理采用API-based機制，即所有關鍵的管控操作都是由客戶端通過調(diào)用相關API實現(xiàn)的。為了對比分析方便，本節(jié)也從產(chǎn)業(yè)模式、管控機制實施過程、功能支持程度等方面分析Android平臺的企業(yè)移動管理技術。

2.1 產(chǎn)業(yè)模式

谷歌的Android系統(tǒng)采用非常開放的系統(tǒng)生態(tài)：首先，Android系統(tǒng)本身是開放的，由于源代碼開放，任何產(chǎn)商都可以修改并發(fā)布自己的Android系統(tǒng)及適配的移動終端；其次，Android應用發(fā)布是開放的，Android系統(tǒng)對第三方應用的發(fā)布沒有硬性要求，無論是發(fā)布在官方應用商店（GooglePlay），還是第三方應用商店，都可以正常在Android移動終端下載、安裝、運行，而且官方商店的應用發(fā)布無需通過像蘋果AppStore那樣嚴格的審核機制。在EMMS功能上，Android也采用比較開放的模式：首先，對開發(fā)者沒有限制，任何熟悉Android應用開發(fā)和服務器開發(fā)的技術人員都可以很容易的開發(fā)并搭建自己的EMMS系統(tǒng)；其次，管控的實施過程完全由開發(fā)者自己控制，Android開放了可以進行設備管控的API，管控服務器、客戶端、服務器和客戶端之間的通信機制完全由開發(fā)者自行設計和實現(xiàn)，Android系統(tǒng)不做限制和要求。在管控功能的支持方面，由于管控主要是針對設備進行，因此能夠進行的管控操作僅限于谷歌開放的管控API。但是理論上，由于Android系統(tǒng)本身是源代碼開放的，因此只要開發(fā)者技術足夠強，可以通過修改Android系統(tǒng)代碼實現(xiàn)所有管控功能。

2.2 管控機制實施過程

Android平臺EMMS功能采用API-based的實現(xiàn)方式，基于開放的設備管控API，開發(fā)者可以實現(xiàn)本地或遠程的設備管控。與iOS平臺不同，Android平臺管控功能的實現(xiàn)主要在于客戶端管控功能的激活和實現(xiàn)，對服務器端和通信機制不做要求，客戶端的管控功能實施流程如下：

1）客戶端應用程序需要注冊一個廣播服務類（繼承自DeviceAdminReceiver）組件，并在該組件中包含如下三個信息：

申請管控權限，即android.permission.BIND—DEVICE_ADMIN

聲明管控權限清單，下述方框為一個示例，聲明該應用程序會進行密碼限制、強制鎖屏、擦除數(shù)據(jù)等管控操作

將應用注冊為設備管理器，即在中添加

2）開發(fā)者選擇合適的時刻激活應用程序的設備管控功能，在激活時會彈出對話框提示用戶該應用申請為設備管理應用并能夠對設備進行清單所示的管控操作，只有用戶手動激活后應用才真正擁有設備管控權限。

3）通過用戶確認后，開發(fā)者可以通過DevicePolicyManager類的相關接口發(fā)起”管控權限清單”中聲明的管控操作。

在該流程中，管控權限的真正授予由用戶參與，并且用戶可以隨時進入“設備管理器”查看申請設備管理權限的應用列表，手動激活或取消特定應用的設備管控功能。

2.3 功能支持程度

Android平臺官方支持的管控功能比較有限，標準接口只提供少量MDM管控功能，通過DevicePolicyManager類的開放API接口實現(xiàn)，具體如表2所示：

3 對比分析

隨著企業(yè)對EMMS系統(tǒng)的需求越來越普遍和急迫，蘋果公司和谷歌公司也在其發(fā)布的新版本iOS和Android系統(tǒng)中不斷豐富對設備管控功能的支持，而且后期勢必會繼續(xù)完善對EMMS功能的支持。由于系統(tǒng)生態(tài)環(huán)境不同，二者采用完全不同的方案，iOS仍然保留其封閉策略，Android則繼續(xù)它的開放路線。本節(jié)從使用者和開發(fā)者兩個角度分別分析不同的實施方案對用戶的影響。

首先，從EMMS系統(tǒng)開發(fā)者的角度來看，二者存在以下幾個不同：1）門檻不同：iOS平臺EMMS系統(tǒng)的開發(fā)門檻比較高，蘋果對開發(fā)EMMS系統(tǒng)的開發(fā)者進行嚴格的身份審核，只有確認開發(fā)者為企業(yè)級用戶才會授予企業(yè)開發(fā)者權限并允許其開發(fā)EMMS系統(tǒng)；在Android平臺上，谷歌對開發(fā)者沒有限制，任何人（包括企業(yè)和個人）都可以開發(fā)和搭建EMMS系統(tǒng)。2）靈活性不同：iOS平臺采用Server-based的管控模式，Android平臺采用Device-based（或者API-based）的管控模式，由于EMMS主要是針對設備進行管控，因此Android平臺更容易實現(xiàn)一些細粒度的管控，比如特定時間打開相機功能、特定地點關閉網(wǎng)絡功能等；而iOS平臺，實現(xiàn)類似的管控需要客戶端和服務器端之間進行多次的網(wǎng)絡交互，因此需要保證較好的網(wǎng)絡連通性，對于特定地點（比如保密場所）禁用網(wǎng)絡功能等，由于沒有網(wǎng)絡則無法實現(xiàn)。3）開發(fā)難易程度不同：從0和0節(jié)的分析可以看出，iOS平臺提供的標準EMMS功能比較豐富，包括大量的設備管控和應用管控功能，開發(fā)者只需要遵循蘋果提供的標準MDM開發(fā)手冊進行EMMS系統(tǒng)的開發(fā)，而且客戶端硬件和軟件版本比較有限，在平臺兼容性實現(xiàn)方面也比較容易；而Android平臺的標準開放接口僅能夠進行相機管控、密碼策略配置等少量的設備管控功能，對藍牙、數(shù)據(jù)網(wǎng)絡、本地應用等大部分的設備管控和應用管控只能由開發(fā)者通過非常規(guī)的手段實現(xiàn)，因此要求開發(fā)者熟悉Android系統(tǒng)的相關底層機制（而不僅僅是開放的API接口），此外Android平臺從硬件到系統(tǒng)軟件差異非常大，實現(xiàn)平臺兼容性需要耗費較大精力。4）開發(fā)成本不同：iOS平臺開發(fā)EMMS系統(tǒng)需要繳納299美元/年的企業(yè)開發(fā)賬號費用，而Android平臺開發(fā)EMMS系統(tǒng)則完全免費。

其次，從EMMS系統(tǒng)使用者的角度來看，二者存在以下幾個不同：1）系統(tǒng)安全性：在iOS平臺上，蘋果對EMMS系統(tǒng)的開發(fā)者進行限制，而且要求開發(fā)者采用蘋果定義的一套安全認證機制來配置EMMS系統(tǒng)，并強制客戶端和服務器之間采用SSL協(xié)議進行通信，由此從整體上保證了EMMS系統(tǒng)的安全性；而Android平臺上，是否進行管控服務器的認證以及通信通道的安全保護完全由EMMS系統(tǒng)開發(fā)者決定，而且認證和安全保護的方案也由開發(fā)者自行設計，因此可能造成系統(tǒng)安全性參差不齊的情況。2）系統(tǒng)功能的規(guī)范性和穩(wěn)定性：iOS平臺提供的標準管控功能比較豐富，而且開發(fā)者只能遵循蘋果提供的標準MDM開發(fā)手冊進行EMMS系統(tǒng)的開發(fā)，因此可以確保功能的實現(xiàn)效果的一致性和規(guī)范性；Android平臺提供的標準管控功能非常有限，為了達到運營的目的EMMS系統(tǒng)提供商需要通過一些非常規(guī)手段實現(xiàn)更豐富的管控功能，比如瀏覽器、Email、設置等本地應用以及藍牙、移動網(wǎng)絡等設備功能的管控，由于平臺的差異性和實現(xiàn)方案的不同可能影響產(chǎn)品整體的規(guī)范性和穩(wěn)定性。3）平臺兼容性：iOS平臺的終端產(chǎn)品類型比較有限，而且都是蘋果研制的，加之蘋果對EMMS系統(tǒng)的實現(xiàn)制定了一套專門的標準，因此可以實現(xiàn)較好的平臺兼容性；而Android平臺首先在EMMS功能上很多管控無法通過標準的接口實現(xiàn)，加之Android平臺從硬件到系統(tǒng)差異性非常大，因此較難實現(xiàn)完全的平臺兼容性。

4 結束語

作為一個新興和正在發(fā)展中的產(chǎn)業(yè)，市場和企業(yè)對EMMS的功能需求仍在不斷完善，不同操作系統(tǒng)平臺對EMMS的功能支持也在不斷豐富。總體來看，由于系統(tǒng)生態(tài)的差異，不同平臺在EMMS功能的實現(xiàn)機制方面有較大差別，由此可能導致EMMS產(chǎn)品整體安全性、實現(xiàn)規(guī)范性上會有所不同。此外，當前不同平臺對EMMS功能的支持更多體現(xiàn)在MDM和MAM方面，對MCM功能的特別支持暫無體現(xiàn)，仍需進一步完善。