Câu hỏi hiếm khi là liệu việc quản lý thiết bị Apple có cần mã hóa hay không, vì nó cần. Câu hỏi thật sự là liệu đội thiết bị của bạn có cần một VPN đa dụng trước khi một chiếc Mac hay iPad có thể được quản lý hay không, và với phần lớn các triển khai được quản lý qua internet thì câu trả lời là không. Apple cho phép thiết bị tự đến một dịch vụ quản lý theo lịch trình của riêng nó, và lưu lượng quan trọng là một kênh lệnh có chữ ký, không phải một phiên máy tính để bàn. Điều đó có hiệu quả với bạn hay không phụ thuộc vào ba điều kiện, và rất dễ nhầm lẫn chúng vì từ bên ngoài tất cả đều trông giống truy cập từ xa.

Đặt tên cho nhu cầu trước khi chọn phương thức truyền tải

Lệnh quản lý và cấu hình là một nhu cầu, chia sẻ màn hình tương tác là nhu cầu thứ hai, và đến được một ứng dụng nội bộ riêng là nhu cầu thứ ba. Chúng có chủ sở hữu khác nhau, xác thực khác nhau và thường mức phơi bày chấp nhận được rất khác nhau. Gộp chúng lại với nhau chính là cách một đội thiết bị kết thúc với danh sách cổng công khai mà không ai có thể bảo vệ.

Ba nhu cầu không dùng chung một phương thức truyền tải:

NeedWhat actually carries it
Management commands and profilesThe enrolled device pulls from a service it can reach; APNs only wakes it
Interactive screen sharingA remote-support tool or private desktop path with its own authentication
Private application accessThat application's permitted network path, which may well be a VPN

Sự nhầm lẫn thường bắt đầu từ một danh sách kiểm tra máy chủ cũ. Một tài liệu lịch sử về OS X Server liệt kê một tập cổng dài, và ai đó chuyển tiếp tất cả ở biên vì dịch vụ quản lý nằm đâu đó bên trong. Đó không phải kiến trúc quản lý, và nó mở rộng bề mặt phơi bày vượt xa mặt phẳng điều khiển mà bạn đang cố công bố.

Thông báo push thực sự làm gì

Trong luồng được Apple ghi nhận, máy chủ quản lý gửi một thông báo APNs để báo cho thiết bị rằng có công việc đang chờ. Thiết bị sau đó mở kết nối tới máy chủ quản lý và yêu cầu các lệnh của mình. Push là một chuông cửa, không phải đường hầm: nó không mang theo tải trọng tùy ý, không mang phiên máy tính để bàn từ xa và không mang lưu lượng của ứng dụng khác.

Vì vậy thiết bị phải được ghi danh với dịch vụ dự định, tin tưởng các điểm cuối mong đợi và có thể đến được cả dịch vụ quản lý lẫn các dịch vụ Apple mà luồng phụ thuộc. Hướng dẫn chuẩn bị mạng của Apple liệt kê các phụ thuộc đó, và chúng không phải những phần có thể thương lượng của luồng. Một máy chủ quản lý chỉ tồn tại bên trong mạng của bạn vẫn cần một đường dẫn được hỗ trợ mà thiết bị thực sự có thể dùng. Gọi nó là MDM không làm cho một điểm cuối không thể đến được trở nên đến được.

Giữ các đường dẫn được phép rõ ràng, bao gồm mọi chính sách proxy và kiểm tra TLS ở giữa. Một thiết bị kiểm tra phá vỡ chuỗi chứng chỉ mong đợi sẽ trông giống hệt một lần ghi danh bị hỏng.

Khi VPN là câu trả lời sai

Nếu dịch vụ quản lý của bạn được công bố trên internet với chứng chỉ đúng và thiết bị khởi tạo mọi kết nối, VPN chỉ thêm một bước nhảy mà không thêm một kiểm soát. Thiết bị đã xác thực bằng danh tính ghi danh của nó, và máy chủ đã quyết định những lệnh nào nó sẽ chấp nhận. Một đường hầm phía trước điều đó thay đổi đường mạng, không thay đổi quyết định tin cậy.

Cùng mặt phẳng điều khiển đó cũng có thể phân phối chính hồ sơ VPN. Thứ tự đó quan trọng: một cấu hình VPN được quản lý đến như chỉ là một tải trọng nữa, vì vậy thiết bị không cần đường hầm phải tồn tại trước khi nhận được hồ sơ tạo ra nó.

Khi VPN là câu trả lời đúng

Có những đội thiết bị mà điểm cuối quản lý không bao giờ nên đến được từ internet, và đó là thiết kế chính đáng chứ không phải thiếu can đảm. Môi trường bị quản chế, các nhóm CNTT nội bộ nhỏ và những máy chủ cũng lưu trữ các giao diện quản trị khác thường kết thúc ở đó. Trong trường hợp đó, một đường truy cập được bảo vệ phía trước dịch vụ quản lý là kiến trúc có chủ đích, không phải cách lách.

Chia sẻ màn hình và truy cập ứng dụng riêng thường cũng thuộc về phía đó của ranh giới. Cả hai đều phơi bày nhiều hơn một kênh lệnh rất nhiều, và cả hai đều xứng đáng có xác thực riêng thay vì đi nhờ danh tính ghi danh.

Cái bẫy khởi tạo phá vỡ khả năng phục hồi

Đây là sự cố mà tôi sẽ thiết kế để phòng ngừa: đường duy nhất tới dịch vụ quản lý đi qua một VPN, và hồ sơ hoặc thông tin đăng nhập VPN trên thiết bị đã hết hạn. Thiết bị không thể đến máy chủ để lấy một lệnh thay thế, và máy chủ không thể đẩy bất cứ thứ gì qua một đường hầm không chịu khởi động. Việc phục hồi giờ phụ thuộc vào một người dùng có thể ở cách xa hàng trăm dặm.

Giữ một đường thứ hai, độc lập để phục hồi, dù đó là kênh quản lý ngoài băng, một quản trị viên cục bộ hay một dịch vụ quản lý vẫn đến được mà không cần đường hầm. Hãy thử nó khi mọi thứ đang chạy, vì bạn sẽ không có một bài kiểm tra sạch trong lúc có sự cố.

Sau đó ghi lại đường nào phục vụ nhu cầu nào trong ba nhu cầu, và xóa các chuyển tiếp cổng không phục vụ nhu cầu nào. Một đội thiết bị có thể được quản lý mà không cần đường hầm chung, và vẫn có thể sửa được khi chính đường hầm là thứ bị hỏng, là kết quả đáng để thiết kế.

Bài viết liên quan