XÂY DỰNG hệ THỐNG QUẢN lý THIẾT bị DI ĐỘNG NHẰM TĂNG CƯỜNG bảo mật dữ LIỆU của DOANH NGHIỆP

DANH MỤC CÁC THUẬT NGỮ ANH VIỆT Bring Your Own Device Là thiết bị cá nhân của riêng nhân viên, sau khi enroll vào hệ thống MDM Server sẽ được quyền truy cập vào các dữ liệu của công ty C

Trang 1

ĐẠI HỌC QUỐC GIA TP HỒ CHÍ MINH

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN

Trang 2

LỜI CẢM ƠN

Trước hết, em xin gửi lời cảm ơn chân thành đến thầy - TS Đàm Quang Hồng Hải

đã giúp đỡ, người đã tận tình hướng dẫn và tạo mọi điều kiện tốt nhất cho em trong quá trình định hướng, nghiên cứu và xây dựng đề tài khóa luận này

Em xin chân thành cảm ơn các thầy cô, cũng như tất cả các cán bộ nhân viên trường Đại Học Công Nghệ Thông Tin – Đại Học Quốc Gia Thành Phố Hồ Chí Minh đã tận tình giảng dạy, tạo điều kiện tốt nhất cho em trong suốt quá trình học tập và nghiên cứu tại trường, giúp em học hỏi và tiếp thu được kiến thức một cách vững vàng cũng như định hướng nghiên cứu của em trong thời điểm hiện tại và tương lai sau này Cuối cùng em xin bày tỏ lòng biết ơn đến gia đình, người thân và bạn bè đã giúp đỡ, động viên, khích lệ em trong quá trình nghiên cứu để hoàn thành khóa luận này

TP Hồ Chí Minh, ngày 25 tháng 11 năm 2016

Học viên Nguyễn Thường Kiệt

Trang 3

LỜI CAM ĐOAN

Em, Nguyễn Thường Kiệt xin cam đoan tất cả nội dung trình bày trong khóa luận tốt nghiệp này có được dựa trên việc nghiên cứu, tổng hợp kiến thức lý thuyết trong quá trình học tập, tự nghiên cứu và vận dụng kinh nghiệm trong quá trình làm việc thực

tế của em Mọi thông tin trích dẫn đều được chú thích và liệt kê rõ ràng trong danh mục các tài liệu tham khảo

Em xác nhận khóa luận này là sản phẩm của em xây dựng dưới sự hướng dẫn của TS Đàm Quang Hồng Hải và sự giúp đỡ của những người khác đã được ghi nhận trong báo cáo này

TP Hồ Chí Minh, ngày 25 tháng 11 năm 2016

Học viên Nguyễn Thường Kiệt

Trang 4

MỤC LỤC

LỜI CẢM ƠN 1

LỜI CAM ĐOAN 2

NHẬN XÉT CỦA GIẢNG VIÊN HƯỚNG DẪN 3

NHẬN XÉT CỦA GIẢNG VIÊN PHẢN BIỆN 4

MỤC LỤC 5

DANH MỤC HÌNH ẢNH 8

DANH MỤC CÁC CHỮ VIẾT TẮT 10

DANH MỤC CÁC THUẬT NGỮ ANH VIỆT 11

CHƯƠNG 1 TỔNG QUAN 12

1.1 Giới thiệu chung 12

1.1.1 Giới thiệu về giải pháp quản lý thiết bị di động (Mobile Device Management-MDM) 12

1.1.2 Xu hướng sử dụng thiết bị cá nhân riêng (Bring Your Own Device) 13

1.1.3 Giao tiếp giữa MDM Server và các thiết bị cá nhân riêng được sử dụng trong doanh nghiệp 15

1.2 Mục tiêu, đối tượng và phạm vi nghiên cứu 16

1.2.1 Mục tiêu 16

1.2.2 Đối tượng và phạm vi nghiên cứu 17

1.3 Nội dung, phương pháp dự định nghiên cứu 18

1.3.1 Nội dung nghiên cứu 18

1.3.2 Phương pháp nghiên cứu 19

1.4 Các thách thức trong nghiên cứu MDM Server 19

1.5 Dự kiến kết quả đạt được 20

1.6 Bố cục của khóa luận 20

1.7 Kế hoạch bố trí thời gian nghiên cứu 20

CHƯƠNG 2 KHẢO SÁT VÀ PHÂN TÍCH CÁC CÔNG NGHỆ LIÊN QUAN TRONG HỆ THỐNG MDM-SERVER 22

2.1 Công nghệ sử dụng trong hệ thống MDM-Server 22

Trang 5

2.1.2 Đăng ký (enroll) thiết bị di động và ứng dụng ở thiết bị (Client App)

với MDM Server 27

2.1.3 Các giao thức và các lệnh của MDM 30

2.1.4 Các công nghệ khác sử dụng trong hệ thống MDM Server 43

2.2 Các công nghệ liên quan 47

2.2.1 Công nghệ GPS 47

2.2.2 Near Field Communication (Công nghệ NFC ) 47

2.2.3 Beacon/iBeacon 49

CHƯƠNG 3 XÂY DỰNG HỆ THỐNG QUẢN LÝ THIẾT BỊ DI ĐỘNG FLEXBA-MDM SỬ DỤNG CÔNG NGHỆ GEOFENCING 51

3.1 Phân tích yêu cầu của hệ thống MDM cho doanh nghiệp lớn 52

3.2 Sơ đồ tổng thể của hệ thống quản lý thiết bị di động “FlexBA-MDM” 53

3.2.1 Nhóm tính năng chung 54

3.2.2 Nhóm quản lý thiết bị 54

3.2.3 Nhóm quản lý người dùng 55

3.2.4 Nhóm quản lý ứng dụng 56

3.3 Xây dựng cơ sở dữ liệu cho hệ thống FlexBA-MDM 57

3.3.1 Mô hình dữ liệu 57

3.3.2 Chi tiết cơ sở dữ liệu của hệ thống FlexBA-MDM 57

3.4 Ứng dụng đa nền tảng cài đặt trên thiết bị di động (Client App) 62

3.4.1 Chức năng đăng nhập 62

3.4.2 Màn hình ứng dụng chính của ứng dụng đa nền tảng 63

3.5 Hệ thống quản lý thiết bị di động FlexBA-MDM 63

3.5.1 Menu chính của hệ thống FlexBA-MDM 64

3.5.2 Chức năng quản lý danh sách các thiết bị di động 64

3.5.3 Màn hình chi tiết 65

3.5.4 Màn hình Dashboard 66

3.5.5 Màn hình để cấu hình profile cho thiết bị 67

3.5.6 Màn hình quản lý lịch sử hoạt động của thiết bị 67

3.5.7 Màn hình quản lý các device tương ứng với từng người dùng 68

3.6 Chức năng quản lý theo vị trí địa lý (Geofencing) 68

Trang 6

3.7 Kết quả và khả năng ứng dụng thực tế 69

CHƯƠNG 4 THỰC NGHIỆM, KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN 70

4.1 Chi tiết thực nghiệm 70

4.1.1 Giới thiệu về Apache Jmeter 70

4.1.2 Lợi ích của Apache Jmeter đối với performance testing 70

4.1.3 Các bước thực hiện 71

4.2 Đánh giá kết quả đạt được 76

4.3 Những khó khăn và hạn chế 77

4.4 Hướng phát triển 77

DANH MỤC TÀI LIỆU THAM KHẢO 78

Trang 7

DANH MỤC HÌNH ẢNH

Hình 1.1 Kiến trúc tổng thể của một MDM Server dành cho doanh nghiệp 13

Hình 1.2 Cách nhìn chung về BYOD 14

Hình 1.3 Sơ đồ tương tác giữa MDM Server và thiết bị cá nhân 14

Hình 1.4 Trình tự giao tiếp giữa MDM Server và BYOD 15

Hình 1.5 Sơ đồ tổng quan về giao tiếp giữa MDM Server và thiết bị cá nhân riêng 17

Hình 1.6 Mô tả việc xóa dữ liệu trên thiết bị 19

Hình 2.1 Dịch vụ gởi thông báo đến các thiết bị 23

Hình 2.2 Sơ đồ hoạt động của Push Notification trên Android 24

Hình 2.3 Sơ đồ hoạt động của Push Notification trên Windows Phone 26

Hình 2.4 Đăng ký thiết bị iOS và Android với MDM server 28

Hình 2.5 Sơ đồ cơ chế làm việc của Push Notification trên Windows Phone 29

Hình 2.6 Mô phỏng hoạt động của Geofencing 43

Hình 2.7 Bảng so sánh tầm vực hoạt động và tốc độ truyền dữ liệu 48

Hình 2.8 Ví dụ về ứng dụng NFC trong thương mại điện tử 49

Hình 2.9 Ví dụ về cách thức hoạt động của Beacon 50

Hình 3.1 Mô phỏng công nghệ Geofencing 52

Hình 3.2 Nhóm các chức năng chung 54

Hình 3.3 Nhóm các chức năng quản lý thiết bị 55

Hình 3.4 Nhóm các chức năng quản lý người dùng 56

Hình 3.5 Nhóm các chức năng quản lý ứng dụng 56

Hình 3.6 Mô hình dữ liệu của hệ thống quản lý thiết bị di động 57

Hình 3.7 Chức năng login của ứng dụng đa nền tảng 62

Hình 3.8 Màn hình chính của ứng dụng đa nền tảng 63

Hình 3.9 Menu chính của hệ thống quản lý thiết bị di động 64

Hình 3.10 Chức năng quản lý thiết bị 65

Hình 3.11 Chức năng quản lý chi tiết các thiết bị 66

Hình 3.12 Chức năng thống kê 66

Hình 3.13 Chức năng quản lý cấu hình 67

Hình 3.14 Chức năng quản lý lịch sử hoạt động 67

Hình 3.15 Chức năng quản lý yêu cần đăng ký 68

Hình 3.16 Chức năng Geofencing 69

Trang 8

Hình 4.1 Mô phỏng việc thực hiện test performance trên JMeter 71

Hình 4.2 Các bước thực hiện performance test trên JMeter 71

Hình 4.3 Cách tạo Thread/User Group 72

Hình 4.4 Cách tạo HTTP Request 73

Hình 4.5 Cách đọc kết quả test dựa vào thống kê bằng hình ảnh 74

Hình 4.6 Biểu đồ kết quả theo thời gian “Respond” 75

Hình 4.7 Bảng kết quả tổng hợp của toàn bộ quá trình test 75

Trang 9

DANH MỤC CÁC CHỮ VIẾT TẮT

API Application Programming Interface

APNS Apple Push Notification Service

APP Application

BLE Bluetooth Low Energy

BYOD Bring Your Own Device

C2DM Cloud to Device Messaging

CA Certificate Authority

GCM Google Cloud Messaging

GPS Global Positioning System

MDM Mobile Device Management

NFC Near-Field Communications

OTP One Time Password

PNS Push Notification Service

SCEP Simple Certificate Enrollment Protocol UDID Unique Device Identifier

URI Uniform Resource Identifier

URL Uniform Resource Locator

UUID Universally Unique Identifier

XML Extensible Markup Language

XMPP Extensible Messaging and Presence Protocol WLAN Wireless Local Area Network

WWAN Wireless Wide Area Network

Trang 10

DANH MỤC CÁC THUẬT NGỮ ANH VIỆT

Bring Your Own

Device

Là thiết bị cá nhân của riêng nhân viên, sau khi enroll vào

hệ thống MDM Server sẽ được quyền truy cập vào các dữ liệu của công ty

Client App Là ứng dụng được cài đặt ở thiết bị, chịu sự quản lý của

MDM Server

Device Token Là một chuỗi định danh cho thiết bị, tương tự như ID, mỗi

thiết bị có duy nhất một token ID Idle Status Là trạng thái chờ nhận lệnh từ MDM Server của thiết bị Latitude Vĩ độ

Longitude Kinh độ

One Time Password

Là password chỉ sử dụng một lần Khi đăng ký thiết bị với MDM Server, hệ thống sẽ gởi thông tin password này thông qua email để chứng thực người dùng

Private-key Là mã số riêng bí mật, được sử dụng để ký vào thông điệp

Public-key

Là một dạng mật mã mà một nhóm người dùng có thể biết, thường dùng để kết hợp với private-key để mã hóa/giải mã thông tin nào đó

Third Party Công ty thứ 3, muốn xây dựng MDM

Trang 11

Với quy mô khoảng 25.000 thiết bị và vấn đề bảo mật nêu trên thì các công nghệ thường dùng như VPN, Remote Desktop sẽ gặp nhiều khó khăn trong công tác xử lý

dữ liệu Do vậy chúng tôi đã lựa chọn giải pháp MDM để quản lý thiết bị di động dựa trên nền web (MDM Server) mà các doanh nghiệp, tổ chức muốn sử dụng để quản lý các thiết bị của chính các nhân viên khi truy cập vào mạng doanh nghiệp để làm việc hoặc sử dụng các nguồn tài nguyên của doanh nghiệp [1] [2] [3] [4]

Đây là giải pháp cho doanh nghiệp lớn hỗ trợ BYOD (Bring Your Own Device) – Sử dụng thiết bị cá nhân riêng để giải quyết công việc được đánh giá là có thể giúp tiết kiệm thời gian và chi phí cho doanh nghiệp Hiện nay, các thiết bị di động là một trong số các mối đe dọa an ninh dữ liệu lớn nhất của một doanh nghiệp Vì thế, các doanh nghiệp cần một giải pháp an toàn để có thể vừa bảo mật dữ liệu vừa phát huy được hết lợi ích của xu hướng này

1.1 Giới thiệu chung

1.1.1 Giới thiệu về giải pháp quản lý thiết bị di động (Mobile Device

Management-MDM)

MDM Server dành cho doanh nghiệp này sẽ vận hành song song với MDM Server mặc định của các nhà cung cấp về nền tảng di động như Apple, Google, Microsoft Mục đích chính là doanh nghiệp sẽ quản lý được thông tin của mình trên thiết bị cá

Trang 12

CHƯƠNG 1 TỔNG QUAN

nhân riêng của nhân viên, phòng khi nhân viên bị mất máy hoặc nghỉ việc thì mọi thông tin liên quan đến doanh nghiệp sẽ bị xóa sạch để đảm bảo an toàn về dữ liệu cho doanh nghiệp Bên cạnh đó vẫn bảo đảm an toàn cho dữ liệu riêng tư của nhân viên như danh bạ, tin nhắn, lịch sử cuộc gọi…[5] [6] [7]

Hình 1.1 Kiến trúc tổng thể của một MDM Server dành cho doanh nghiệp

1.1.2 Xu hướng sử dụng thiết bị cá nhân riêng (Bring Your Own Device)

Khi một doanh nghiệp muốn triển khai BYOD, thì việc nghiên cứu về bảo mật các

dữ liệu của doanh nghiệp là cần thiết khi triển khai cho nhân viên sử dụng các thiết

bị cá nhân riêng [8] [9] [10] Việc bảo mật này cần phải đảm bảo được 2 yếu tố quan trọng sau đây:

❖ Bảo mật thông tin của doanh nghiệp khi xảy ra sự cố như mất máy, nhân viên nghỉ việc, nhân viên đi ra khỏi khu vực cho phép

❖ Bảo mật thông tin cá nhân của nhân viên, thông tin cá nhân được quản lý độc lập với dữ liệu của doanh nghiệp

Trang 13

Hình 1.2 Cách nhìn chung về BYOD

Trong đó thông tin về vị trí địa lý của thiết bị (location) là một trong những yếu tố quan trọng trong việc tăng cường đảm bảo an toàn cho dữ liệu trên thiết bị cá nhân riêng Chẳng hạn như phân quyền sử dụng ứng dụng dựa vào vị trí hiện tại của thiết

bị (location-based services) hoặc gởi cảnh báo nếu thiết bị khi chuyển tới những khu vực không cho phép [11] [12] [13]

Việc quản lý vị trí của thiết bị (location tracking) không chỉ dựa vào mạng nội bộ không dây nữa (WLAN – Wireless Local Area Network) [14] mà được áp dụng với quy mô lớn hơn, đa dạng hơn như WWAN (Wireless Wide Area Network), 3G hay 4G…

Hình 1.3 Sơ đồ tương tác giữa MDM Server và thiết bị cá nhân

❖ Người quản trị sẽ gởi yêu cầu (invite) tới nhân viên sở hữu thiết bị di động (smartphone, tablet) thông qua mail

Dữ liệu của doanh nghiệp

Dữ liệu

cá nhân

Trang 14

❖ Nhân viên sẽ mở mail bằng thiết bị di động, truy cập vào đường link trong mail

để cài đặt ứng dụng cho phía người dùng (còn gọi là “Client App”)

❖ Sau khi cài xong Client App, MDM Server sẽ nhận được thông tin xác thực của thiết bị và Client App đã cài đặt trên thiết bị đó Quá trình đăng ký (Enroll) hoàn tất Sau đó MDM Server và thiết bị di động có thể tương tác với nhau

Sau khi enroll, MDM Server có thể quản lý thiết bị này từ xa như: lock device, unlock device, wipe data, remote wipe data, config VPN, reset passcode … Tuy nhiên MDM Server chỉ quản lý thiết bị này thông qua Client App, nên cũng chỉ quản lý được dữ liệu phát sinh trong Client App này mà thôi, còn mọi thông tin riêng tư khác như mail, tin nhắn, danh bạ của nhân viên vẫn được bảo mật tối đa

1.1.3 Giao tiếp giữa MDM Server và các thiết bị cá nhân riêng được sử dụng

trong doanh nghiệp

Mỗi nhà sản xuất như Apple với iOS hoặc Google với Android hoặc Microsoft với Windows Phone đều cung cấp API (Application Programming Interface) để cho doanh nghiệp (third-party) có thể tự triển khai MDM Server cho riêng mình với mục đích kiểm soát được các thiết bị cá nhân riêng khi muốn sử dụng tài nguyên của doanh nghiệp Nhưng mỗi nền tảng có những quy định cũng như những giới hạn riêng trong việc cho phép bên thứ 3 triển khai nó

Hình 1.4 Trình tự giao tiếp giữa MDM Server và BYOD

Trang 15

Trong đó:

① File cấu hình có chứa thông tin về MDM Server được gửi tới thiết bị tương ứng của người dùng Người dùng sẽ được giới thiệu qua toàn bộ thông tin về những

gì sẽ được quản lý hoặc truy vấn từ phía server

② Người dùng sẽ cài đặt các Profile tương ứng với các ứng dụng được quản lý

③ Quá trình Enrollment của thiết bị diễn ra cùng thời điểm với Profile được cài đặt Sau đó, server sẽ phải xác nhận tính “hợp pháp” của thiết bị và cho phép truy cập

④ Tiếp theo, server sẽ gửi đi thông tin yêu cầu Push để thiết bị kiểm tra về quá trình xác nhận hoặc truy vấn

⑤ Thiết bị sẽ tiến hành kết nối trực tiếp tới server qua cơ chế HTTPS, sau đó server gửi lại thông tin về câu lệnh hoặc yêu cầu tương ứng

1.2 Mục tiêu, đối tượng và phạm vi nghiên cứu

1.2.1 Mục tiêu

❖ Xây dựng server quản lý thiết bị di động cho doanh nghiệp (MDM Server for Third-party), vận hành song song với MDM Server mặc định của Apple/Google/Microsoft với các chức năng sau đây:

✓ Location tracking/GeoFencing (Lưu vết để xử lý xóa dữ liệu nhằm bảo mật thông tin nếu thiết bị đó ra khỏi vùng cho phép)

✓ Đăng ký thiết bị với MDM Server (Enroll)

✓ Hủy đăng ký (Un-Enroll)

✓ Xóa data của doanh nghiệp thông qua Client App (Remote wipe data)

✓ Khóa thiết bị khi xảy ra sự cố (Lock device)

✓ Mở khóa thiết bị (Unlock device)

✓ Thiết lập lại password cho thiết bị (Reset passcode)

❖ Xây dựng ứng dụng phía thiết bị di động (Client App)

✓ Gởi thông tin location định kỳ về cho MDM Server

✓ Xử lý các request và trả về kết quả cho MDM Server

Trang 16

✓ Các thông tin cá nhân của nhân viên vẫn được đảm bảo tuyệt đối bí mật

✓ Dữ liệu của doanh nghiệp được lưu trên thiết bị cá nhân riêng cũng được bảo mật khi xảy ra sự cố nhờ chức năng “Remote wipe data”

Hình 1.5 Sơ đồ tổng quan về giao tiếp giữa MDM Server và thiết bị cá nhân riêng

1.2.2 Đối tượng và phạm vi nghiên cứu

❖ MDM Server sẽ được quản lý thông qua một ứng dụng web (được viết bằng PHP, PostgreSQL, Bootstrap, Google Maps)

❖ MDM Server sẽ xây dựng trên 3 nền tảng phổ biến hiện nay là iOS, Android và Windows Phone

❖ Nghiên cứu trên các thiết bị di động gồm smartphone và tablet

Trang 17

1.3 Nội dung, phương pháp dự định nghiên cứu

1.3.1 Nội dung nghiên cứu

Nội dung nghiên cứu 1: Xây dựng hệ thống MDM Server hỗ trợ cho 3 nền tảng là

iOS, Android và Windows Phone 8.1

❖ Triển khai hệ thống MDM Server để ứng dụng thực tiễn

❖ Phía server: xây dựng 1 website để người quản trị được phép phân quyền, cấu hình, điều khiển các thiết bị từ xa…

❖ Phía Người dùng (thiết bị cá nhân riêng): Viết 1 ứng dụng (Client App) để cài đặt vào thiết bị của nhân viên, người quản trị sẽ tương tác với thiết bị thông qua ứng dụng này để đảm bảo bảo mật dữ liệu cho doanh nghiệp và cho cả nhân viên

❖ Phát triển các chức năng chính để quản lý thiết bị cá nhân riêng thông qua website quản trị ở phía server:

✓ Lấy thông tin vị trí địa lý hiện tại của thiết bị (Location tracking/GeoFencing)

✓ Xóa data của doanh nghiệp thông qua Client App (Selective wipe data)

✓ Khóa thiết bị khi xảy ra sự cố (Lock device)

✓ Mở khóa thiết bị (Unlock device)

✓ Thiết lập lại password cho thiết bị (Reset passcode)

Nội dung nghiên cứu 2: Tích hợp với định vị thiết bị (location tracking) để triển

khai các tính năng bảo mật dữ liệu

❖ Ứng dụng Client App sẽ có chức năng tự động xóa các dữ liệu liên quan đến doanh nghiệp trên thiết bị, nếu thiết bị đó bị mang ra khỏi công ty (hoặc một khu vực do công ty quyết định)

❖ Tự động xóa các dữ liệu liên quan đến doanh nghiệp trên thiết bị, nếu thiết bị đó đang ở ngoài khu vực cho phép (đối với các thiết bị được quyền truy cập từ xa)

❖ Admin có thể chủ động xóa tất cả thông tin liên quan doanh nghiệp ngay lập tức nếu nhân viên nghỉ việc, bị mất máy hoặc bị nghi ngờ về bảo mật thông tin

Trang 18

Hình 1.6 Mô tả việc xóa dữ liệu trên thiết bị

1.3.2 Phương pháp nghiên cứu

Một số phương pháp nghiên cứu được thực hiện trong đề tài:

Phương pháp thu thập thông tin: thu thập các tài liệu liên quan tới MDM, BYOD

và Geofencing, các phương pháp biểu diễn tri thức, các khái niệm trong lĩnh vực bảo mật, thu thập số liệu liên quan đến dự án trước đây

Phương pháp nghiên cứu tài liệu, phân tích và tổng hợp tài liệu: nghiên cứu các

tài liệu về MDM của các nền tảng phổ biến như Android, iOS và Windows Phone 8.1 Từ đó đề xuất mô hình, phương pháp, kỹ thuật thích hợp để áp dụng vào đề tài

Phương pháp chuyên gia: tham vấn từ các chuyên gia về cách dự toán cho dự án

MDM và BYOD, từ đó hoàn thiện các giải pháp đã đề xuất

1.4 Các thách thức trong nghiên cứu MDM Server

❖ Việc tích hợp công nghệ Geofencing với MDM trong việc tăng cường bảo mật là hoàn toàn mới, do đó các nghiên cứu, bài báo, đề tài tham khảo cũng như các ứng dụng mẫu cũng rất hạn chế

❖ Triển khai thực tế trên 3 nền tảng với số lượng lớn khoảng 25,000 thiết bị Do đó yêu cầu về thiết kế xử lý cũng như thiết kế lưu trữ (Database và các hình thức lưu trữ các file quản lý) cũng đòi hỏi phải rất tối ưu để bảo bảo về hiệu năng

❖ Khi thực hiện lệnh (command) được gởi từ Server cho Client, một số lệnh sẽ không hỗ trợ sẵn trong các API của các nhà cung cấp (đặc biệt là API của nền

Trang 19

1.5 Dự kiến kết quả đạt được

❖ Xây dựng thành công hệ thống quản lý thiết bị cá nhân riêng gồm MDM Server

và Client App

❖ Đáp ứng được các tính năng quản lý thiết bị và các tính năng về bảo mật thông tin theo mục tiêu và nội dung nghiên cứu đã đặt ra

1.6 Bố cục của khóa luận

Bố cục khóa luận gồm 4 chương như sau:

❖ Chương 4: Kết luận và hướng phát triển

❖ Danh mục tài liệu tham khảo

1.7 Kế hoạch bố trí thời gian nghiên cứu

❖ Thời gian bắt đầu: 01/06/2016

❖ Thời gian hoàn thành: 01/10/2016

Trang 20

Trang 21

CHƯƠNG 2 CÔNG NGHỆ SỬ DỤNG TRONG HỆ THỐNG MDM-SERVER

Tuy nhiên bảo mật là vấn đề đáng lo ngại nhất Các thiết bị di động là một trong những mối đe dọa an ninh dữ liệu lớn nhất của doanh nghiệp vì dữ liệu của công ty luôn được lưu giữ ở thiết bị của nhân viên

Với khóa luận lần này sẽ nghiên cứu và xây dựng một hệ thống quản lý thiết bị di động cho doanh nghiệp cỡ vừa và lớn để tăng cường bảo mật cho dữ liệu của doanh nghiệp với các công nghệ chính sau: Dịch vụ gởi thông báo đến thiết bị (Push Notification Sevices), Check-in (hay còn gọi là Enrollment), Geofencing

2.1 Công nghệ sử dụng trong hệ thống MDM-Server

2.1.1 Dịch vụ gởi thông báo đến thiết bị (Push Notification Sevices)

Dịch vụ gởi thông báo (Push notification service) là một chức năng mà các nhà cung cấp nền tảng di động (iOS, Android, Windows Phone) hỗ trợ các nhà phát triển để đưa ra những thông báo hay những cập nhật thay đổi từ nhà phát triển, tới thiết bị cài đặt ứng dụng Nó giúp cho nhà phát triển sử dụng nó làm công cụ để tiếp cận người dùng nhanh nhất

Push Notification là nền tảng đặc biệt và do đó các nhà cung cấp nền tảng chỉ sử dụng

nó để hỗ trợ một số tính năng nhất định

Trang 22

❖ Google/Android - Push Notification hoạt động với Google Cloud Messaging (GCM) GCM có thể cung cấp các notifications với các dữ liệu nhúng

❖ Apple/iOS - Apple Push Notification Service (APNS) chịu trách nhiệm cung cấp các notifications đến các thiết bị iOS APNS cũng hỗ trợ cung cấp các dữ liệu nhúng

❖ Mirosoft/Windows Phone – Có Microsoft Push Notification Service (MPNS)

Hình 2.1 Dịch vụ gởi thông báo đến các thiết bị

Các tính chất đặc trưng của dịch vụ gởi thông báo

❖ Cho phép hệ thống quản lý thiết bị của các doanh nghiệp gửi thông báo đến từng thiết bị hoặc từng ứng dụng của thiết bị

❖ Phía ứng dụng không cần thiết phải chạy chức năng nhận tin nhắn liên tục Dịch

vụ gởi thông báo sẽ đánh thức các thiết bị và để gởi thông báo đến thiết bị

❖ Không cung cấp các giao diện người dùng hay các thư viện xử lý thông tin mà đơn thuần chỉ gửi tin nhắn đến thiết bị Các doanh nghiệp sẽ tự phát triển giao diện quản lý theo nhu cầu riêng

2.1.1.1 Nền tảng Android (Google Cloud Messaging – GCM)

GCM cho phép chúng ta gửi các tin nhắn có dung lượng nhỏ từ hệ thống MDM tới tất cả các thiết bị khi có kết nối mạng Điều này sẽ giúp thiết bị bảo vệ pin khi không phải request liên tục lên server để yêu cầu dữ liệu mới nhất Server ở đây có thể là

Trang 23

Android, và cũng có thể là Web server Các kiểu dữ liệu có thể là các message nhỏ hoặc các dữ liệu có dung lượng nhỏ hơn hoặc bằng 4Kb GCM xử lý dữ liệu theo kiểu hàng đợi (queue) các message và chuyển tới các ứng dụng android dạng Push notification GCM thay thế cho phiên bản beta C2DM (Cloud to Device Messaging)

Để cài đặt GCM, cần ba thành phần sau:

❖ GCM Connection Servers: Google server liên quan đến việc gửi tin nhắn giữa

app server và client app

❖ Client app: Một GCM client app cho phép ứng dụng giao tiếp với App server

❖ App Server: Một App server để gửi dữ liệu tới client app thông qua GCM

connection server Nếu app server sử dụng giao thức XMPP (Extensible Messaging and Presence Protocol), nó cũng có thể nhận tin nhắn được gửi từ client apps

Hình 2.2 Sơ đồ hoạt động của Push Notification trên Android

① Ứng dụng đăng kí với GCM server

② Nếu đăng kí thành công, GCM sẽ trả về thiết bị một token, token này riêng biệt với mỗi thiết bị

③ Thiết bị gửi token lên app server để lưu trữ, quản lý

④ Khi app server muốn gửi một tin nhắn xuống thiết bị, nó gửi một request lên GCM server kèm token của thiết bị đó

Trang 24

⑤ GCM xác định thiết bị từ token, sau đó gởi tin nhắn xuống thiết bị Thiết bị nhận được tin nhắn có thể hiện thông báo hoặc xử lý theo chức năng

Thông tin nhận diện thiết bị - Credentials:

❖ Sender ID: Số Project ID khi cấu hình project API của trên Google Cloud Số ID

này sau đó sẽ đăng ký với app server của third-party để cam kết rằng server sẽ gửi

dữ liệu tới đúng Client app của thiết bị

❖ API Key: Một API key được lưu trên App server để app server xác thực quyền

truy cập tới Google service Trong HTTP, API key bao gồm trong phần Headed của phương thức POST được yêu cầu gửi tin nhắn Với XMPP, API key dùng để xác thực yêu cầu như mật khẩu kết nối

❖ Appication ID: Đây là ID của app client được đăng ký để nhận dữ liệu từ server

2.1.1.2 Nền tảng iOS (Apple Push Notification Service – APNS)

Quy trình hoạt động cũng giống với Android, nhưng để gởi notification đến các thiết

bị iOS, cần thêm hai tham số bổ sung:

❖ content_available: true

❖ priority: “high” – với Android thì logic về priority hơi khác một chút so với iOS

Mặc định priority được đặt là “normal” (mặc định của Google), nếu set là “high” thì nó sẽ bật app lên bất chấp máy người dùng đang khoá để người dùng có thể tương tác được liền (trường hợp có cuộc gọi skype chẳng hạn)

Căn bản về tin nhắn push trong iOS:

Apple sử dụng các “public-key” để xác thực các yêu cầu tin nhắn từ ứng dụng iOS trong device của nhân viên, nên trước tiên admin cần phải tạo ra các khóa xác thực

và đăng ký chúng với Apple

Tiếp theo, cần nhận diện mỗi thiết bị đã cài đặt ứng dụng và chọn nhận các tin nhắn push cho ứng dụng Trình tự hoạt động như sau:

① Một hộp thoại cảnh báo trong ứng dụng iOS yêu cầu giấy phép của người dùng

để nhận các tin nhắn push

② Nếu người dùng chấp nhận giấy phép, ứng dụng iOS tiếp xúc với Dịch vụ tin nhắn push của Apple (Apple Push Notification - APN) để lấy một chuỗi mã định

Trang 25

danh (ID) là ID duy nhất nhận biết ứng dụng này đã cài đặt trên thiết bị này (Có thể hình dung ID này giống như số điện thoại của người nhận trong việc gửi tin nhắn truyền thống)

③ Ứng dụng IOS tải ID đó lên ứng dụng máy chủ của third-party

④ Khi ứng dụng máy chủ cần gửi một tin nhắn push, nó xác thực dựa vào các máy chủ tin nhắn push của Apple và sau đó sử dụng ID từ bước 2 và 3 để chỉ rõ người nhận tin nhắn

⑤ Nếu thiết bị của người nhận đang nối mạng, nó sẽ nhận và xử lý tin nhắn đó Nếu thiết bị đang tắt mạng, tin nhắn sẽ được xếp hàng và sau đó được chuyển giao cho thiết bị trong lần nối mạng tới

Các dịch vụ tin nhắn push của Apple (APN) cũng cho phép các ứng dụng máy chủ của third-party xác nhận hợp lệ danh sách các ID của ứng dụng đã lưu của theo định

kỳ Điều này giúp loại bỏ các ID của những người dùng mà sau này họ xóa ứng dụng hoặc thay đổi trạng thái lựa chọn tin nhắn push

2.1.1.3 Nền tảng Windows Phone (Microsoft Push Notification Service – MPNS)

2.1.1.3.1 Quy trình hoạt dộng

Microsoft Notification Service trong Windows Phone cung cấp cho chúng ta một kênh thông báo mạnh mẽ, mềm dẻo, chuyên dụng và đảm bảo dữ liệu được gửi tới ứng dụng Windows Phone một xuyên suốt, liên tục

Hình 2.3 Sơ đồ hoạt động của Push Notification trên Windows Phone

Trang 26

① Ứng dụng của chúng ta sẽ request một push nofitication URI từ Push Client Service

② Push Client Service sẽ làm việc với Microsoft Push Notification Service (MPNS) và sau đó MPNS sẽ gửi về cho Push Client Service một notification URI

③ Push Client Service cấp phát cho ứng dụng một notification URI vừa trả về

④ Khi đã được cấp phát notification URI thì ứng dụng trên thiết bị đã có thể trực tiếp làm việc với MDM Server

⑤ Khi phía MDM Server có thông tin để gửi tới ứng dụng, thì trước tiên MDM Server sẽ gửi thông tin tới MPNS thông qua notification URI của ứng dụng

⑥ Cuối cùng là thông báo sẽ gửi tới ứng dụng trên thiết bị của chúng ta

2.1.1.3.2 Các loại Push Notification

Tùy thuộc vào định dạng Push Notification mà cách thông báo sẽ hiển thị tương ứng,

có các loại Push Notification như:

❖ Toast Notification: Hiển thị thông báo ở trên top của màn hình điện thoại, giống

như các thông báo khi có tin nhắn, hay email mới

❖ Tile Notification: Hiển thị các nội dung mới nhất - thời tiết (up-to-date), lịch, sự

kiện,

❖ Raw Notification: Thường dùng để nhận mẫu tin khi đang chạy ứng dụng

2.1.2 Đăng ký (enroll) thiết bị di động và ứng dụng ở thiết bị (Client App) với

MDM Server

Tiếp theo, khi MDM Server và hệ thống mạng được cấu hình chuẩn xác, thì bước đầu tiên trong việc giám sát, quản lý thiết bị là gán những thiết bị đó vào danh sách riêng biệt trong server MDM Điều này sẽ tạo ra mối liên hệ khá đặc biệt giữa thiết bị sử dụng và hệ thống server, cho phép người sử dụng quản lý, giám sát và thực hiện nhiều tác vụ khác nhau

❖ Xác nhận tài khoản người dùng:

Trang 27

Quá trình này có chức năng đảm bảo rằng toàn bộ yêu cầu xác nhận được xuất phát

từ tất cả các tài khoản người dùng đã được xác thực, và những thông tin đó sẽ được

xử lý cùng với quá trình giám sát Certificate của Enrollment

❖ Certificate Enrollment:

Sau khi quá trình xác nhận tài khoản người dùng, các nhà cung cấp sẽ tạo ra các yêu cầu về Certificate Enrollment sử dụng Simple Certificate Enrollment Protocol – SCEP Những yêu cầu này sẽ liên lạc trực tiếp tới doanh nghiệp Certificate Authority – CA, sau đó kích hoạt tính năng nhận Certificate đã được xác nhận trả về từ CA tới thiết bị

❖ Cấu hình, thiết lập thông số kỹ thuật:

Tiếp theo, khi Certificate đã được cài đặt thì những thiết bị đó có thể nhận được bất

kỳ thông tin thiết lập nào đã được mã hóa một cách nhanh chóng Và những thông tin, dữ liệu này chỉ có thể được cài đặt trên thiết bị tương ứng nếu có chứa dữ liệu thiết lập tương ứng, cần thiết để kết nối tới server MDM

2.1.2.1 Đăng ký thiết bị iOS và Android (Enrollment)

Hình 2.4 Đăng ký thiết bị iOS và Android với MDM server

Trang 28

① Dựa vào link đăng ký trên Portal hoặc được gởi qua email, người dùng sẽ dùng thiết bị của mình để truy cập đăng ký với Provisioning server

② Provisioning server sẽ gởi profile cho thiết bị

③ Thiết bị sẽ cài đặt profile này và gởi lại các thông tin đăng ký cần thiết lên Provisioning server

④ Provisioning server sẽ gởi lại cho thiết bị 1 payload để tạo ra key sử dụng SCEP (Simple Certificate Enrollment Protocol)

⑤ Sau khi tạo key xong, thiết bị tiếp tục gởi key này đến MDM server để xin cấp xác nhận enrollment (certificate)

⑥ MDM server enroll thiết bị và gởi ngược lại certificate cho thiết bị

⑦ Thiết bị sẽ ký xác nhận certificate này và gởi certificate đã ký cho Provisioning server

⑧ Provisioning sẽ tạo lại 1 payload đã mã hóa cùng với thông tin của certificate

mà thiết bị đã ký, sau đó gởi lại cho thiết bị

⑨ Thiết bị gởi payload đã mã hóa cho MDM server để yêu cầu enroll (cài đặt MDM payload cho thiết bị)

⑩ MDM server sẽ cài đặt lại payload, chính thức quản lý thiết bị này

2.1.2.2 Đăng ký thiết bị Windows Phone 8.1

Trang 29

① Dựa vào link đăng ký trên Portal hoặc được gởi qua email, người dùng sẽ dùng thiết bị của mình để truy cập đăng ký với Provisioning server

② Thiết bị sẽ gởi yêu cầu enroll đến Provisioning server, trong đó có chứa thông tin domain của email

③ Provisioning server sẽ gởi lại cho thiết bị một URL để quản lý các dịch vụ và một authenticate policy

④ Thiết bị sẽ gởi các thông tin ở bước 3 cho MDM Server để yêu cầu tạo chứng nhận (certificate) cho thiết bị

⑤ MDM server sẽ tạo và gởi lại chứng nhận cho thiết bị

⑥ Dựa vào certificate này và thông tin authenticate ở bước 3, thiết bị sẽ gởi yêu cầu enrollment đến MDM server

⑦ MDM Server sẽ tạo “Phone certificate” và “DM client settings” và gởi lại cho thiết bị Thiết bị sẽ cài đặt các certicate này => Enroll thành công

⑧ Thông báo với người dùng đã enroll thành công

2.1.3 Các giao thức và các lệnh của MDM

Các giao thức và các lệnh được gọi từ Client trong quá trình enrollment để đăng ký thiết bị và ứng dụng với Server Giao thức này sẽ gởi các thông tin cần thiết đến Server của nhà cung cấp MDM, sau đó server sẽ trả kết quả về cho Client với cấu trúc cụ thể như sau:

a) Đối với thiết bị iOS

Giao thức truyền tải: HTTPS

URL client dùng để liên lạc với mdm server: https://{hostname:443}/mdm/server Content-Type : application/x-apple-aspen-app

Định dạng dữ liệu: XML

Thông tin và cấu trúc được Client gởi lên (Request) Server

Key Type Value

Command Dict

CommandUUID String A random UUID

Trang 30

Thông tin và cấu trúc được Server trả về (Response) cho Client

Khóa chính Loại Giá trị

CommandUUID String

ErrorChain dict Trong trường hợp có lỗi

Trang 31

b) Đối với thiết bị Android và Windows Phone

Giao thức truyền tải: HTTPS

URL client dùng để liên lạc với mdm server: https://{hostname:443}/mdm/server Định dạng dữ liệu: JSON

Command Object

CommandUUID String Command universally unique

identifier, it is a random UUID

Cấu trúc Command

Trang 32

RequestType String Chuỗi các lệnh cần thực hiện như:

DeviceLock, DeviceInformation, [Thêm thông số nếu cần

Thông tin và cấu trúc được Server trả về (Response) cho Client

CommandUUID String Set by CommandUUID of command Status integer 0: success, 1: error

Error Object Error data if any

UDID String Device's universal device identifier

(imei in case Android)

Trong trường hợp xử lý thành công:

Trang 33

2.1.3.1 Giao thức check-in (Đăng ký)

The MDM Check-In Protocol Lets a Device Contact Your Server

Giao thức Check-In được gọi từ Client trong quá trình enrollment để đăng ký thiết bị

và ứng dụng với Server Giao thức này sẽ gởi các thông tin cần thiết đến Server của nhà cung cấp MDM, sau đó server sẽ trả kết quả về cho Client với cấu trúc cụ thể như sau:

2.1.3.1.1 Đối với thiết bị iOS

Key Type Value

MessageType String AppDeviceToken

DeviceToken Data Token of application, data must be

base64-encoded Username String

UDID String Device UDID

Trang 34

2.1.3.1.2 Đối với thiết bị Android

Thông tin và cấu trúc được Client gởi lên(Request) Server như sau:

Key Type Value

MessageType String Authenticate

Username String Username

UserToken String User token

RegistrationID String RegistrationID for push notification

Trang 35

UDID String Device's universal device identifier (imei in case

Android) Manufacturer string Manufacturer

DeviceName string Device name

Model string Device's model

2.1.3.1.3 Đối với thiết bị Windows Phone

Key Type Value

Trang 36

MessageType String Authenticate

Username String Username

ChannelURI String ChannelURI

HardwareId String HardwareId of device

2.1.3.2 Cấu trúc của lệnh Push Notification

Thông tin và cấu trúc được Server gởi tới Client

Key Type Value

Trang 37

Nếu Client đang ở trạng thái chờ lệnh từ server (idle) thì client sẽ gởi idle message

về cho Server để server biết status và gởi lệnh thực thi tương ứng

Key Type Value

Status String Idle

2.1.3.2.2 Đối với thiết bị Android và Windows Phone

Thông tin và cấu trúc được Server gởi tới Client

Key Type Value

Mdm String Notification

{

"Mdm": "Notification"

}

Nếu Client đang ở trạng thái chờ lệnh từ server (idle) thì client sẽ gởi idle message

về cho Server để server biết status và gởi lệnh thực thi tương ứng

Key Type Value

UDID String Device's universal device identifier (imei in case

Android) Status integer 2: idle

Trang 38

{

"UDID":"",

"Status":"2"

}

2.1.3.3 Cấu trúc chung của các lệnh khác trong hệ thống MDM

Key Type Value

RequestType String <lệnh thực thi>

Trang 39

2.1.3.3.2 Đối với thiết bị Android và Windows Phone

Key Type Value

RequestType String Unenroll

Định dạng
Số trang	79
Dung lượng	8,56 MB