Nếu bạn vận hành một công ty nhỏ trên Microsoft 365 và muốn email công việc có mặt trên điện thoại của mọi người, bạn sẽ vấp phải một câu hỏi trông có vẻ đơn giản mà lại không hề đơn giản: làm sao bảo vệ dữ liệu công ty trên một thiết bị bạn không sở hữu?

Câu trả lời là một chồng công cụ được định nghĩa rõ ràng, với những đánh đổi rõ ràng. Dùng đúng cách, chúng mang lại sự bảo vệ mạnh mẽ cho dữ liệu công ty và quyền riêng tư trọn vẹn cho dữ liệu cá nhân trên cùng một chiếc điện thoại. Đây là cẩm nang về các khái niệm, các đánh đổi, cấu hình chính xác mà chúng tôi đã dùng — và cả những vấn đề chúng tôi vấp phải trên đường đi, bởi vì có kha khá đấy.

Tại sao phải bận tâm — những sự thật

Vài lý do đơn giản cho thấy việc này đáng được làm cho tử tế:

Điện thoại vốn đã là đồ cá nhân. Một công ty nhỏ không phát phần cứng công ty cho nhân viên. Mọi người kiểm tra email và Teams trên chiếc máy trong túi mình, nên thiết bị đó đã nằm trong phạm vi rủi ro dù bạn có quản lý nó hay không.
Truy cập không được quản lý là một đường rò rỉ dữ liệu có thật. Nếu bỏ mặc, mail và file công ty nằm trong các app không có yêu cầu mã hóa, không PIN, không kiểm soát được dữ liệu bị sao chép đi đâu, và không có cách nào xóa nếu điện thoại bị mất hoặc nhân sự nghỉ việc.
Chúng tôi nắm giữ dữ liệu quan trọng. Chúng tôi vận hành một nền tảng có tiền của người chơi và thông tin cá nhân, nên quyền truy cập nội bộ của chính chúng tôi được giữ theo một chuẩn xác định (các biện pháp kiểm soát kiểu CIS/SOC 2), chứ không phải kiểu cố-hết-sức-là-được.
Quyền riêng tư là một yêu cầu bắt buộc, không phải có-thì-tốt. Dù chúng tôi làm gì đi nữa, IT cũng không được với tay vào app cá nhân, ảnh, tin nhắn hay vị trí của bất kỳ ai.

Mục tiêu rất cụ thể: mọi con đường dẫn tới dữ liệu công ty trên điện thoại phải đạt một chuẩn bảo mật xác định, mà không phải quản lý cả chiếc điện thoại cá nhân bao quanh nó.

Bài toán, phát biểu một cách chính xác

Hai yêu cầu áp dụng cùng lúc:

Dữ liệu công ty cần được bảo vệ — mã hóa, kiểm soát truy cập, và xóa được nếu điện thoại bị mất hoặc nhân sự rời đi.
Điện thoại cá nhân thuộc về cá nhân — ảnh, tin nhắn, app và vị trí phải riêng tư và nằm ngoài tầm với của IT.

Quản lý thiết bị di động chính là bộ công cụ được xây để thỏa mãn cả hai cùng một lúc. Phần còn lại của cẩm nang này là hộp đồ nghề và cách các mảnh ghép khớp với nhau.

Hộp đồ nghề: ba cách quản lý một chiếc điện thoại

Microsoft Intune cung cấp một dải lựa chọn, không phải một công tắc bật/tắt:

1. MAM — Mobile Application Management quản lý app. Bạn bảo vệ các app công việc và để yên phần còn lại của điện thoại. Không cần đăng ký (enroll) thiết bị.

2. MDM — Mobile Device Management quản lý thiết bị, theo hai kiểu khác biệt:

Hồ sơ công việc / User Enrollment — một vùng chứa công việc riêng biệt, được mã hóa, nằm trên điện thoại cá nhân. IT chỉ quản lý vùng chứa đó.
Quản lý toàn phần — IT quản lý toàn bộ thiết bị. Phù hợp cho phần cứng thuộc sở hữu công ty, không phải điện thoại cá nhân.

Đa số các team chỉ cân nhắc lựa chọn 1 và đầu "quản lý toàn phần" của lựa chọn 2, gạt bỏ cả hai, rồi chấp nhận một giải pháp lỏng lẻo. Lựa chọn hữu ích lại là cái nằm ở giữa.

Khái niệm 1: MAM / App Protection

Các App Protection Policy của Intune chính là lớp MAM. Một policy áp lên app như Outlook sẽ:

Mã hóa dữ liệu công ty bên trong app.
Yêu cầu PIN hoặc sinh trắc học để mở app.
Chặn copy, Save As và Open in từ dữ liệu công ty sang app cá nhân.
Cho phép xóa chọn lọc (selective wipe) — chỉ xóa dữ liệu công ty, để nguyên dữ liệu cá nhân.

Tất cả những điều này không đòi hỏi đăng ký thiết bị. Chiếc điện thoại vẫn hoàn toàn là của cá nhân; chỉ các app công việc được quản lý. Với nhiều trường hợp BYOD, vậy là đủ — và đó cũng chính là điểm khởi đầu của chúng tôi.

Khái niệm 2: Tuân thủ đồng nghĩa với đăng ký

Khái niệm buộc mọi thứ lại với nhau là tuân thủ thiết bị (device compliance).

Một thiết bị là "tuân thủ" khi nó đã được đăng ký vào hệ thống quản lý và đáp ứng các quy tắc "sức khỏe" do bạn định nghĩa — mã hóa ổ đĩa được bật, khóa màn hình được cài, hệ điều hành được vá, không bị root, v.v. Tuân thủ là một trạng thái mà thiết bị báo cáo và hệ thống quản lý xác minh.

Điểm mấu chốt: bạn không thể đánh giá mức tuân thủ trên một thiết bị chưa từng được đăng ký. Tiền đề của MAM là không đăng ký, nên một chiếc điện thoại chỉ dùng MAM được bảo vệ ở mức app nhưng không bao giờ có thể "tuân thủ" — chẳng có gì được đăng ký để mà kiểm tra. Require compliant device và "không đăng ký" loại trừ lẫn nhau ngay từ thiết kế.

Nếu bạn muốn một bảo đảm ở mức thiết bị, thiết bị phải được đăng ký vào một thứ gì đó. Điều đó dẫn thẳng tới lựa chọn nằm ở giữa.

Khái niệm 3: Hồ sơ công việc

Trên Android, lựa chọn ở giữa là hồ sơ công việc (Work Profile) (thông qua Android Enterprise). Trên iOS, cái tương đương là User Enrollment. Mô hình như sau:

Hồ sơ công việc là một vùng chứa riêng biệt, được mã hóa, nằm trên điện thoại cá nhân. IT chỉ quản lý những gì bên trong vùng chứa đó. Mọi thứ bên ngoài nó — app cá nhân, ảnh, tin nhắn, tài khoản — nằm trong một không gian mà IT không thể nhìn, chạm hay xóa.

Các app công việc xuất hiện thành một bộ có gắn huy hiệu bên cạnh màn hình chính cá nhân, được sandbox trong vùng chứa. Thiết bị trở thành đã đăng ký và tuân thủ, giới hạn trong phạm vi vùng chứa công việc. Dữ liệu cá nhân vẫn riêng tư. "Đăng ký" ở đây nghĩa là công ty quản lý một vùng chứa, không phải cả thiết bị.

Khái niệm 4: Truy cập có điều kiện

Truy cập có điều kiện (Conditional Access, CA) trong Microsoft Entra là cánh cổng kiểm soát truy cập. Trước khi cho phép một lượt đăng nhập, nó kiểm tra các điều kiện do bạn định nghĩa. Hai grant liên quan ở đây:

Require app protection — cho phép truy cập nếu app đã được áp policy MAM của bạn. Đi cặp với MAM.
Require compliant device — cho phép truy cập nếu thiết bị đã đăng ký và "khỏe mạnh". Đi cặp với MDM / hồ sơ công việc.

CA là nơi bạn thực thi mô hình mình đang dùng. Đổi grant là đổi luôn chuẩn để được truy cập.

Con đường chúng tôi đã đi

Khi mô hình đã rõ, việc dựng lên khá thẳng băng:

Bắt đầu với MAM. App Protection trên các app công việc, cộng thêm một rule CA yêu cầu app protection. Cách chạm nhẹ nhất.
Quyết định mức bảo đảm bạn cần. Nếu "app được bảo vệ" là đủ, dừng ở đây — hoàn toàn hợp lệ. Chúng tôi muốn bảo đảm ở mức thiết bị.
Bật Android Enterprise bằng cách liên kết Managed Google Play với tenant. Một kết nối làm một lần, mở khóa việc đăng ký hồ sơ công việc.
Đăng ký điện thoại dưới dạng Work Profile thuộc sở hữu cá nhân. Một không gian làm việc có huy hiệu, được mã hóa, được tạo ra; phía cá nhân không bị đụng tới; và thiết bị báo compliant chỉ trong vài phút.
Phân phối các app công việc từ Managed Google Play — duyệt Outlook, Teams, Edge và các app Office, gán chúng, và chúng sẽ cài vào vùng chứa.
Chuyển grant CA từ Require app protection sang Require compliant device — cùng một chuẩn đang dùng cho laptop.

Đó là phiên bản sạch đẹp. Còn đây là những gì đã thực sự xảy ra.

Những vấn đề chúng tôi gặp phải, và cách giải quyết

1. Mọi app được quản lý đều bị chặn với thông báo "device is not compliant". Policy App Protection MAM của chúng tôi mang theo một rule conditional-launch, appActionIfDeviceComplianceRequired, được đặt là block. Khi chúng tôi thử nới lỏng nó, Intune chỉ chấp nhận block hoặc wipe — API từ chối null và warn. Kết hợp với Khái niệm 2, đây là một vòng lặp khép kín: policy đòi thiết bị tuân thủ, điện thoại chỉ-MAM không bao giờ được đăng ký, nên không bao giờ tuân thủ, nên mọi app đều bị chặn và Company Portal cứ liên tục đòi đăng ký. Nó được thực thi phía client, nên không bao giờ hiện ra như một lỗi đăng nhập trong Entra — một chi tiết khiến việc chẩn đoán rất khó.

Cách khắc phục: đừng đánh nhau với cánh cổng nữa. Đăng ký thiết bị (hồ sơ công việc) để nó thực sự có thể tuân thủ, rồi rời khỏi MAM trên nền tảng đó (vấn đề 5).

2. Company Portal: "does not meet requirements to enroll". Trước khi Android Enterprise được kết nối, không hề tồn tại con đường đăng ký hồ sơ công việc nào, nên nỗ lực đăng ký chẳng có chỗ nào để đáp xuống.

Cách khắc phục: kết nối Managed Google Play để liên kết Android Enterprise. Chính kết nối duy nhất đó là thứ khiến việc đăng ký hồ sơ công việc trở nên khả dụng.

3. Xung đột tài khoản Google — bước ngốn nhiều thời gian nhất. Managed Google Play liên kết bằng một tài khoản Google, và tài khoản đó trở thành chủ sở hữu của enterprise. Email doanh nghiệp của chúng tôi đã gắn sẵn với một tài khoản Google cá nhân, và Google coi đó là một tài khoản xung đột — nó không cho bạn dùng cùng địa chỉ đó để tạo tài khoản admin của tổ chức/Workspace. Điều này rất dễ bỏ sót và nó làm mọi thứ đứng khựng lại.

Cách khắc phục: giải quyết xung đột trước. Hoặc giải phóng địa chỉ email qua quy trình xử lý tài khoản xung đột của Google (đổi tên hoặc đóng tài khoản Google cá nhân đang dùng địa chỉ đó), hoặc dùng một tài khoản chuyên biệt chưa từng đăng ký gì với Google. Hãy dành hẳn thời gian cho việc này — đây là thứ dễ chặn đứng một team nhỏ ngay ngày đầu tiên nhất, và nó chẳng liên quan gì tới Intune cả.

4. Hồ sơ công việc trống trơn sau khi đăng ký. App trong hồ sơ công việc không tự mang sang từ phía cá nhân. Một vùng chứa vừa được tạo chẳng có gì bên trong.

Cách khắc phục: duyệt các app trong Managed Google Play và gán chúng cho nhóm của bạn dưới dạng Required (tự động cài) hoặc Available (tự cài từ store trong hồ sơ công việc). Sau đó chúng sẽ xuất hiện thành các app có huy hiệu trong vùng chứa.

5. Vẫn "not compliant" — ngay cả sau khi thiết bị đã tuân thủ. Thiết bị giờ đã báo compliant, nhưng Outlook vẫn từ chối. Nguyên nhân: policy App Protection MAM vẫn đang áp lên chính app giờ đây đã được MDM quản lý trong hồ sơ công việc, và cái cổng kiểm tra tuân thủ thiết bị của policy đó xung đột với việc đăng ký. MAM và MDM không muốn đồng quản lý cùng một app.

Cách khắc phục: cam kết một mô hình cho mỗi nền tảng. Chúng tôi gỡ gán policy App Protection cho Android và chuyển grant Truy cập có điều kiện của Android từ Require app protection sang Require compliant device. Thiết bị có hồ sơ công việc thỏa mãn điều kiện đó một cách trực tiếp; không còn cổng MAM nào để xung đột nữa.

6. Chính policy của chúng tôi chặn luôn công cụ admin của chúng tôi — AADSTS530033. Khi tự động hóa các thay đổi Intune, một lượt đăng nhập admin bị từ chối: Truy cập có điều kiện từ chối một phiên đăng nhập kiểu device-code vì token đó không được gắn với một thiết bị tuân thủ.

Cách khắc phục: chạy các tác vụ đặc quyền từ một thiết bị vốn đã tuân thủ để token được gắn với thiết bị — ví dụ chạy Connect-MgGraph theo kiểu tương tác từ một máy được quản lý. Bài học rút ra lại mang tính tích cực: nếu Truy cập có điều kiện của bạn chặn được cả đăng nhập device-code, nghĩa là nó đang được cấu hình đúng.

Về chuyện xây dựng cùng AI

Chúng tôi xây dựng công khai, và chúng tôi xây dựng cùng AI, kể cả trong khâu vận hành. AI rất hiệu quả trong việc lần một cấu hình qua nhiều nhánh rẽ một cách nhanh chóng. Chúng tôi ghép nó với một quy tắc: AI đề xuất, con người quyết định — đặc biệt với bất cứ thứ gì chạm tới bảo mật. Sự phân công đó cho phép một team nhỏ vận hành với tốc độ của một team lớn hơn.

Những mô hình tư duy cần giữ lại

MAM quản lý app; MDM quản lý thiết bị. Chọn dựa trên mức bảo đảm bạn cần.
Tuân thủ đồng nghĩa với đăng ký. Bạn không thể xác minh một thiết bị chưa từng được đăng ký, nên Require compliant device và "không đăng ký" không thể cùng tồn tại.
Hồ sơ công việc là lựa chọn ở giữa. Nó quản lý một vùng chứa, không phải cả thiết bị — vừa có tuân thủ thiết bị vừa có quyền riêng tư cá nhân.
Một mô hình cho mỗi app. Đừng để policy MAM còn nằm trên app bạn đã chuyển sang MDM; chọn một làn mà đi.
Truy cập có điều kiện đặt ra chuẩn. Chọn grant khớp với mô hình của bạn và để nó thực thi.

Chúng tôi đặt mức độ kỹ lưỡng này vào vài hộp thư công việc, bởi vì chính thứ kỷ luật bảo vệ truy cập di động của chúng tôi cũng là thứ bảo vệ tài khoản, tiền và dữ liệu của bạn trên nền tảng. Bảo mật là một thói quen chạy xuyên suốt công việc nội bộ, chứ không chỉ ở những phần khách hàng nhìn thấy.

Hẹn gặp lại trên bàn poker.

BYOD đúng cách: Cẩm nang thực chiến bảo mật điện thoại cá nhân với Intune