Các phương pháp hay nhất để bảo mật hệ thống

Phần này chứa các đề xuất để đảm bảo tính bảo mật của hệ điều hành Android và thiết bị cốt lõi.

Xác thực bằng sinh trắc học

Thu thập, lưu trữ và xử lý dữ liệu sinh trắc học để xác thực người dùng một cách cẩn thận. Bạn nên:

  • Bắt buộc phải sử dụng phương thức xác thực chính trước khi sử dụng bất kỳ hình thức xác thực nào khác (bao gồm cả sinh trắc học).
  • Yêu cầu xác nhận rõ ràng để cho biết ý định khi sử dụng các phương thức sinh trắc học thụ động, chẳng hạn như nhận dạng khuôn mặt, cho các giao dịch (ví dụ: thanh toán) liên quan đến khoá liên kết với thông tin xác thực.
  • Yêu cầu phương thức xác thực chính mỗi 72 giờ.
  • Sử dụng quy trình xử lý hoàn toàn an toàn cho tất cả dữ liệu sinh trắc học.
  • Không bao giờ gửi dữ liệu sinh trắc học (bao gồm cả các phép đo cảm biến thô và các tính năng phái sinh) ra khỏi thiết bị. Nếu có thể, hãy lưu trữ dữ liệu này trong một môi trường biệt lập và an toàn, chẳng hạn như Môi trường thực thi đáng tin cậy (TEE) hoặc Secure Element.

Các thiết bị có tính năng sinh trắc học phải hỗ trợ API BiometricPrompt. API này cung cấp một giao diện chung và nhất quán để nhà phát triển ứng dụng tận dụng tính năng xác thực dựa trên sinh trắc học trong ứng dụng của họ. Chỉ dữ liệu sinh trắc học mạnh mới có thể tích hợp với BiometricPrompt và các hoạt động tích hợp phải tuân thủ nguyên tắc trong Tài liệu định nghĩa về khả năng tương thích với Android (CDD).

Để biết thêm nguyên tắc về sinh trắc học, hãy xem Nguyên tắc triển khai HAL sinh trắc học.

SELinux

SELinux cung cấp định nghĩa và biện pháp thực thi cho phần lớn mô hình bảo mật của Android. Việc sử dụng đúng cách SELinux là rất quan trọng đối với tính bảo mật của thiết bị Android và có thể giúp giảm thiểu tác động của các lỗ hổng bảo mật. Vì lý do này, tất cả thiết bị Android đều phải triển khai một chính sách SELinux mạnh mẽ.

  • Triển khai chính sách đặc quyền tối thiểu.
  • Tránh cấp quyền CAP_DAC_OVERRIDE, CAP_SYS_ADMIN và CAP_NET_ADMIN.
  • Không ghi nhật ký dữ liệu hệ thống vào thẻ SD.
  • Sử dụng các loại được cung cấp để truy cập trình điều khiển, chẳng hạn như gpu_device, audio_device, v.v.
  • Sử dụng tên có ý nghĩa cho các quy trình, tệp và loại SELinux.
    • Đảm bảo không sử dụng nhãn mặc định và không cấp quyền truy cập cho nhãn đó.
  • Chính sách dành riêng cho thiết bị phải chiếm từ 5 đến 10% chính sách tổng thể chạy trên một thiết bị. Các tuỳ chỉnh trong phạm vi từ 20%trở lên gần như chắc chắn chứa các miền có đặc quyền quá mức và chính sách không còn hiệu lực. Chính sách quá lớn không cần thiết sẽ lãng phí bộ nhớ, lãng phí dung lượng ổ đĩa do cần đến hình ảnh khởi động lớn hơn và ảnh hưởng tiêu cực đến thời gian tra cứu chính sách thời gian chạy.

Tải chính sách SELinux một cách linh động

Không tự động tải chính sách SELinux trên thiết bị Android. Việc này có thể dẫn đến các vấn đề, chẳng hạn như:

  • Ngăn việc chấp nhận các bản vá bảo mật quan trọng.
  • Cho thấy khả năng can thiệp vào hệ thống của thiết bị thông qua việc tải lại các chính sách.
  • Tiết lộ một vectơ cho các cuộc tấn công xen giữa vào trình cập nhật chính sách.
  • Khiến thiết bị bị hỏng do lỗi cập nhật chính sách.

Cửa hậu

Ứng dụng Android không được có bất kỳ cửa sau hoặc cách nào để truy cập vào hệ thống hoặc dữ liệu mà bỏ qua các cơ chế bảo mật thông thường. Bao gồm quyền truy cập đặc biệt để chẩn đoán, gỡ lỗi, phát triển hoặc sửa chữa bảo hành do các bí mật mà nhà phát triển biết đến kiểm soát. Cách ngăn chặn cửa sau:

  • Quét tất cả ứng dụng bên thứ ba bằng một công cụ quét lỗ hổng ứng dụng được công nhận trong ngành.
  • Thực hiện quy trình xem xét mã của tất cả mã có quyền truy cập nhạy cảm, bao gồm cả thư viện của bên thứ ba.
  • Sử dụng Google Play Protect bằng cách tải ứng dụng lên Google Play để quét. Bạn có thể tải ứng dụng lên để quét mà không cần phát hành lên Google Play.
  • Không tải trước các công cụ tập trung vào việc chẩn đoán hoặc sửa chữa trên bản phát hành. Chỉ cài đặt các công cụ này theo yêu cầu để giải quyết các vấn đề cụ thể. Ngoài ra, các công cụ này không được hoạt động hoặc tải lên bất kỳ dữ liệu nào dành riêng cho tài khoản.

Công cụ phát triển

Các công cụ phát triển, chẳng hạn như công cụ gỡ lỗi, kiểm thử và chẩn đoán, thường có thể tạo ra các lỗ hổng bảo mật ngoài ý muốn trên thiết bị của bạn bằng cách tiết lộ cách hoạt động và dữ liệu mà các công cụ này thu thập. Để đảm bảo các công cụ phát triển không được đưa vào bản dựng chính thức:

  • Phát triển danh sách đen gồm các hàm băm công cụ kiểm thử và gỡ lỗi nội bộ, đồng thời quét các bản dựng cho các tệp APK này trước khi sử dụng hình ảnh hệ thống.
  • Quét tất cả ứng dụng của bên thứ nhất bằng một công cụ quét lỗ hổng ứng dụng được công nhận trong ngành.
  • Thuê một công ty kiểm thử bảo mật ứng dụng bên thứ ba để đánh giá tất cả các ứng dụng chẩn đoán quan trọng trên thiết bị trước khi có bất kỳ bản cập nhật lớn nào, đặc biệt là nếu ứng dụng do bên thứ ba phát triển.
  • Đảm bảo rằng chỉ người dùng mới có thể bật công cụ này, bằng lời nói hoặc qua tính năng trò chuyện, trong phiên hỗ trợ. Lưu trữ các cấu phần phần mềm về sự đồng ý và tắt công cụ sau khi thu thập thông tin chẩn đoán cần thiết.
  • Lưu trữ bản ghi sử dụng của công cụ này trong nhật ký mà người dùng có thể truy cập trong tài khoản của nhà mạng.
  • Đảm bảo rằng mọi thông tin nhận dạng cá nhân (PII) hoặc dữ liệu đo từ xa của thiết bị mà công cụ này thu thập đều tuân theo các phương pháp ẩn danh, giữ lại và xoá dữ liệu liên quan đến quốc gia. Chỉ thu thập dữ liệu liên quan đến cuộc gọi hỗ trợ. Bạn nên xoá dữ liệu này sau mỗi lệnh gọi.
  • Đảm bảo rằng các kỹ thuật có thể dùng cho phần mềm gián điệp, chẳng hạn như ghi lại thao tác nhấn phím, sử dụng micrô hoặc sử dụng máy ảnh, không được dùng khi chưa có sự đồng ý rõ ràng của người dùng. Ứng dụng sử dụng các phương thức có thể xâm phạm quyền riêng tư này phải được công bố rõ ràng cùng với chính sách quyền riêng tư mà người dùng phải đồng ý. Bạn không được bật các ứng dụng như vậy nếu người dùng chưa đồng ý rõ ràng.

Sau đây là một số đề xuất bổ sung để tham khảo khi triển khai thông tin công bố và sự đồng ý:

Thông tin công bố trong ứng dụng

  • Hiển thị cách sử dụng ứng dụng bình thường ngay trong ứng dụng. Không yêu cầu người dùng chuyển đến một trình đơn hay chế độ cài đặt.
  • Mô tả loại dữ liệu đang được thu thập và giải thích cách dữ liệu đó được sử dụng.
  • Tốt nhất là bạn không nên nhúng thông tin này vào chính sách quyền riêng tư hoặc điều khoản dịch vụ. Đừng đưa thông tin này vào thông tin công bố khác không liên quan đến việc thu thập dữ liệu cá nhân hoặc dữ liệu nhạy cảm.
  • Sự đồng ý phải là đồng ý rõ ràng. Không coi việc rời khỏi trang thông tin công bố (bao gồm cả thao tác nhấn nút thoát, nút quay lại hoặc nút màn hình chính) là hành động thể hiện sự đồng ý.
  • Trình bày hộp thoại đồng ý một cách rõ ràng và không mơ hồ.
  • Yêu cầu người dùng thực hiện thao tác xác nhận, chẳng hạn như nhấn để chấp nhận hoặc nói một lệnh, để chấp nhận.
  • Không thu thập dữ liệu cá nhân hoặc dữ liệu nhạy cảm trước khi có được sự đồng ý rõ ràng.
  • Không sử dụng thông báo tự động đóng hoặc tự động hết hạn.

Chức năng được nhúng trong AOSP

Việc nhúng chức năng bổ sung vào AOSP thường có thể gây ra hành vi và hậu quả không mong muốn; hãy tiến hành thận trọng.

  • Đảm bảo người dùng được nhắc nếu họ muốn sử dụng các ứng dụng mặc định khác (ví dụ: công cụ tìm kiếm, trình duyệt web, trình chạy) và công bố việc gửi dữ liệu ra khỏi thiết bị.
  • Đảm bảo rằng APK AOSP được ký bằng chứng chỉ AOSP.
  • Chạy kiểm thử hồi quy và ghi nhật ký thay đổi để xác định xem tệp APK AOSP có được thêm mã hay không.

Bản cập nhật bảo mật

Các thiết bị Android phải được hỗ trợ bảo mật liên tục trong ít nhất 2 năm kể từ khi ra mắt. Điều này bao gồm việc nhận các bản cập nhật định kỳ để giải quyết các lỗ hổng bảo mật đã biết.

  • Làm việc với các đối tác phần cứng, chẳng hạn như nhà cung cấp SoC, để đưa ra các thoả thuận hỗ trợ phù hợp cho tất cả các thành phần trên thiết bị Android.
  • Đảm bảo người dùng có thể cài đặt bản cập nhật bảo mật mà không cần tương tác nhiều để tăng khả năng người dùng chấp nhận và cài đặt bản cập nhật trên thiết bị Android của họ. Bạn nên triển khai tính năng Cập nhật hệ thống liền mạch hoặc một tính năng bảo mật tương đương.
  • Đảm bảo rằng bạn hiểu rõ yêu cầu tích luỹ của Cấp bản vá bảo mật Android (SPL) như đã khai báo trong Bản tin bảo mật Android. Ví dụ: các thiết bị sử dụng cấp bản vá bảo mật ngày 1/2/2018 phải bao gồm tất cả các vấn đề liên quan đến cấp bản vá bảo mật đó, cũng như các bản sửa lỗi cho tất cả các vấn đề được báo cáo trong tất cả các bản tin bảo mật trước đó.

Cập nhật nhân động

Không sửa đổi linh động các thành phần hệ thống quan trọng. Mặc dù có một số nghiên cứu cho thấy rằng các bản cập nhật nhân động giúp bảo vệ khỏi các mối đe doạ khẩn cấp, nhưng chi phí được đánh giá hiện lớn hơn lợi ích. Thay vào đó, hãy tạo một phương thức cập nhật OTA mạnh mẽ để nhanh chóng phân phối các biện pháp bảo vệ lỗ hổng.

Quản lý khoá

Duy trì các chính sách và phương pháp quản lý khoá hiệu quả để đảm bảo tính bảo mật của khoá ký.

  • Không chia sẻ khoá ký với các bên bên ngoài.
  • Nếu khoá ký bị xâm phạm, hãy tạo khoá mới và ký hai lần tất cả ứng dụng trong tương lai.
  • Lưu trữ tất cả khoá trong phần cứng hoặc dịch vụ mô-đun bảo mật cao yêu cầu nhiều yếu tố để truy cập.

Ký hình ảnh hệ thống

Chữ ký của hình ảnh hệ thống là yếu tố quan trọng để xác định tính toàn vẹn của thiết bị.

  • Không ký thiết bị bằng khoá đã biết công khai.
  • Quản lý khoá ký thiết bị theo cách nhất quán với các phương pháp tiêu chuẩn của ngành để xử lý khoá nhạy cảm, bao gồm cả mô-đun bảo mật phần cứng (HSM) cung cấp quyền truy cập có giới hạn và có thể kiểm tra.

Trình tải khởi động có thể mở khoá

Nhiều thiết bị Android hỗ trợ tính năng mở khoá, cho phép chủ sở hữu thiết bị sửa đổi phân vùng hệ thống hoặc cài đặt hệ điều hành tuỳ chỉnh. Các trường hợp sử dụng phổ biến bao gồm cài đặt hình ảnh hệ thống của bên thứ ba và phát triển ở cấp hệ thống trên thiết bị. Ví dụ: để mở khoá hình ảnh hệ thống trên Google Nexus hoặc Pixel, người dùng có thể chạy fastboot oem unlock để hiển thị thông báo sau:

Cách tốt nhất là các thiết bị Android có thể mở khoá phải xoá toàn bộ dữ liệu người dùng một cách an toàn trước khi mở khoá. Việc không xoá đúng cách tất cả dữ liệu khi mở khoá có thể cho phép kẻ tấn công ở gần có được quyền truy cập trái phép vào dữ liệu mật của người dùng Android. Để ngăn việc tiết lộ dữ liệu người dùng, thiết bị hỗ trợ tính năng mở khoá phải triển khai tính năng này đúng cách.

  • Sau khi người dùng xác nhận lệnh mở khoá, thiết bị phải bắt đầu xoá dữ liệu ngay lập tức. Bạn không được đặt cờ unlocked cho đến khi quá trình xoá an toàn hoàn tất.
  • Nếu không thể hoàn tất quá trình xoá an toàn, thiết bị phải ở trạng thái khoá.
  • Nếu thiết bị khối cơ bản hỗ trợ, bạn nên sử dụng ioctl(BLKSECDISCARD) hoặc tương đương. Đối với các thiết bị MultiMediaCard (eMMC) được nhúng, điều này có nghĩa là sử dụng lệnh Xoá an toàn hoặc Cắt bớt an toàn. Đối với eMMC 4.5 trở lên, điều này có nghĩa là sử dụng thao tác Xoá hoặc Cắt thông thường, sau đó là thao tác Làm sạch.
  • Nếu thiết bị khối cơ bản không hỗ trợ BLKSECDISCARD, bạn phải sử dụng ioctl(BLKDISCARD). Trên các thiết bị eMMC, đây là thao tác Cắt thông thường.
  • Nếu BLKDISCARD không được hỗ trợ, bạn có thể ghi đè các thiết bị khối bằng toàn bộ số 0.
  • Người dùng phải có lựa chọn yêu cầu xoá dữ liệu người dùng trước khi cài đặt ROM cho một phân vùng. Ví dụ: các thiết bị Nexus sử dụng lệnh fastboot oem lock để xoá dữ liệu người dùng.
  • Thiết bị có thể ghi lại, thông qua eFuses hoặc cơ chế tương tự, liệu thiết bị có được mở khoá và/hoặc khoá lại hay không. Tuy nhiên, bạn nên khoá lại trình tải khởi động bằng cách đặt lại về trạng thái ban đầu để khôi phục toàn bộ chức năng của thiết bị.

Các yêu cầu này đảm bảo rằng tất cả dữ liệu sẽ bị huỷ sau khi hoàn tất thao tác mở khoá. Việc không triển khai các biện pháp bảo vệ này được coi là một lỗ hổng bảo mật ở mức trung bình.

Sau đó, bạn có thể khoá lại một thiết bị đã mở khoá bằng lệnh fastboot oem lock. Việc khoá trình tải khởi động sẽ bảo vệ dữ liệu người dùng bằng hệ điều hành tuỳ chỉnh mới giống như cách bảo vệ dữ liệu người dùng bằng hệ điều hành của nhà sản xuất thiết bị ban đầu (ví dụ: dữ liệu người dùng sẽ bị xoá nếu thiết bị được mở khoá lại).

Kiểm thử xâm nhập thiết bị

Thiết bị phải được một chuyên gia kiểm thử xâm nhập có năng lực xem xét trước khi vận chuyển. Quy trình kiểm thử xâm nhập phải xác nhận rằng thiết bị tuân thủ hướng dẫn bảo mật tại đây cũng như hướng dẫn bảo mật nội bộ của nhà sản xuất thiết bị gốc (OEM).

Kiểm thử bảo mật

Sử dụng các công cụ Kiểm thử bảo mật do AOSP cung cấp. Cụ thể

  • Sử dụng các công cụ bảo mật bộ nhớ trong quá trình phát triển: sử dụng MTE nếu được hỗ trợ (ARMv9 trở lên) và sử dụng HWASan nếu không được hỗ trợ. Chạy nhiều kiểm thử nhất có thể khi bật các công cụ này.
  • Sử dụng GWP-ASan và KFENCE trong bản phát hành công khai để phát hiện các vấn đề về an toàn bộ nhớ theo xác suất.