Các phương pháp hay nhất về 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 và thiết bị Android cốt lõi.

Xác thực 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:

  • Chỉ định 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 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 khóa xác thực.
  • Yêu cầu phương thức xác thực chính cứ sau 72 giờ.
  • Sử dụng quy trình hoàn toàn an toàn cho tất cả dữ liệu sinh trắc học và xử lý.
  • Không bao giờ gửi dữ liệu sinh trắc học (bao gồm 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 giữ dữ liệu này trong môi trường cách ly an toàn, chẳng hạn như Môi trường thực thi tin cậy (TEE) hoặc Phần tử bảo mật.

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

Để biết thêm hướng dẫn sinh trắc học, hãy xem Hướng dẫn triển khai HAL sinh trắc học .

SELinux

SELinux cung cấp định nghĩa và thực thi phần lớn mô hình bảo mật của Android. Việc sử dụng SELinux đúng cách 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. Tất cả các thiết bị Android nên triển khai chính sách SELinux mạnh mẽ vì lý do này.

  • Thực hiện chính sách đặc quyền tối thiểu.
  • Tránh cấp các quyền CAP_DAC_OVERRIDE , CAP_SYS_ADMIN và CAP_NET_ADMIN .
  • Không ghi 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 các nhãn mặc định không được sử dụng và quyền truy cập không được cấp cho chúng.
  • Chính sách dành riêng cho thiết bị phải chiếm 5–10% chính sách tổng thể chạy trên thiết bị. Các tùy chỉnh trong phạm vi 20%+ 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 đã chết. Chính sách lớn không cần thiết sẽ gây lãng phí bộ nhớ, lãng phí dung lượng ổ đĩa do yêu cầu 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 động chính sách SELinux

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

  • Ngăn chặn việc chấp nhận các bản vá bảo mật quan trọng.
  • Tiết lộ khả năng root thiết bị thông qua việc tải lại các chính sách.
  • Phát hiện một vectơ cho các cuộc tấn công trung gian chống lại trình cập nhật chính sách.
  • Dẫn đến thiết bị bị brick do lỗi cập nhật chính sách.

Cửa sau

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

  • Quét tất cả các ứng dụng của bên thứ ba bằng công cụ quét lỗ hổng ứng dụng được ngành công nhận.
  • Thực hiện đánh giá 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 xuất bản lên Google Play.
  • Không tải trước các công cụ tập trung vào chẩn đoán hoặc sửa chữa trên các bản phát hành. Chỉ cài đặt những công cụ này theo yêu cầu để giải quyết các vấn đề cụ thể. Ngoài ra, những công cụ này không được hoạt động hoặc tải lên bất kỳ dữ liệu cụ thể nào của 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 tra 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 chúng hoạt động và dữ liệu mà chúng thu thập. Để đảm bảo rằng các công cụ phát triển không được đưa vào bản dựng sản xuất:

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

Dưới đây là một số gợi ý bổ sung để tham khảo khi thực hiện tiết lộ và chấp thuận:

Tiết lộ trong ứng dụng

  • Hiển thị mức sử dụng bình thường của ứng dụng trực tiếp trong ứng dụng. Không yêu cầu người dùng điều hướng vào menu hoặc cài đặt.
  • Mô tả loại dữ liệu được thu thập và giải thích cách dữ liệu sẽ được sử dụng.
  • Tốt nhất là không 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ụ. Không đưa thông tin này vào các tiết lộ khác không liên quan đến việc thu thập dữ liệu cá nhân hoặc nhạy cảm.
  • Sự đồng ý phải được khẳng định. Đừng coi việc điều hướng khỏi phần tiết lộ, bao gồm cả việc nhấn thoát hoặc nhấn nút quay lại hoặc nút home, là sự đồng ý.
  • Trình bày hộp thoại đồng ý một cách rõ ràng và rõ ràng.
  • Yêu cầu hành động khẳng định của người dùng, chẳng hạn như nhấn để chấp nhận hoặc nói lệnh để chấp nhận.
  • Không thu thập dữ liệu cá nhân hoặc nhạy cảm trước khi có được sự đồng ý rõ ràng.
  • Không sử dụng các tin nhắn tự động loại bỏ hoặc hết hạn.

Chức năng 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; tiến hành thận trọng.

  • Đảm bảo rằng người dùng được nhắc xem họ có muốn sử dụng các ứng dụng mặc định khác nhau hay không (ví dụ: công cụ tìm kiếm, trình duyệt web, trình khởi chạy) và tiết lộ 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 thử nghiệm hồi quy và ghi nhật ký thay đổi để xác định xem APK AOSP đã được thêm mã hay chưa.

Cập nhật bảo mật

Các thiết bị Android sẽ nhận được hỗ trợ bảo mật liên tục trong ít nhất hai 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 thường xuyên nhằm 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 của bạn, để đưa ra các thỏa thuận hỗ trợ phù hợp cho tất cả các thành phần trên thiết bị Android của bạn.
  • Đảm bảo rằng các bản cập nhật bảo mật có thể được cài đặt với sự tương tác tối thiểu của người dùng để tăng khả năng người dùng chấp nhận và cài đặt các bản cập nhật trên thiết bị Android của họ. Chúng tôi đặc biệt khuyến khích triển khai Cập nhật hệ thống liền mạch hoặc tính năng bảo mật tương đương.
  • Đảm bảo rằng bạn hiểu yêu cầu tích lũy 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 độ vá bảo mật 2018-02-01 phải bao gồm tất cả các vấn đề liên quan đến cấp độ 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 kernel động

Không tự động sửa đổi 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 kernel động giúp bảo vệ khỏi các mối đe dọa khẩn cấp, nhưng chi phí được đánh giá hiện cao hơn lợi ích. Thay vào đó, hãy tạo một phương pháp 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ý khóa

Duy trì các chính sách và thực tiễn quản lý khóa tốt để đảm bảo tính bảo mật của việc ký khóa.

  • Không chia sẻ khóa ký với các bên bên ngoài.
  • Nếu khóa ký bị xâm phạm, hãy tạo khóa mới và ký đúp vào tất cả các ứng dụng về sau.
  • Lưu trữ tất cả các khóa 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 rấ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 khóa được công khai.
  • Quản lý khóa ký thiết bị theo cách phù hợp với các thông lệ tiêu chuẩn ngành để xử lý các khóa nhạy cảm, bao gồm mô-đun bảo mật phần cứng (HSM) cung cấp quyền truy cập hạn chế, có thể kiểm tra được.

Bộ nạp khởi động có thể mở khóa

Nhiều thiết bị Android hỗ trợ mở khóa, 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 tùy 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à thực hiện phát triển cấp hệ thống trên thiết bị. Ví dụ: để mở khóa 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 này:

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

  • Sau khi người dùng xác nhận lệnh mở khóa, thiết bị phải bắt đầu xóa dữ liệu ngay lập tức. Cờ unlocked không được đặt cho đến khi quá trình xóa an toàn hoàn tất.
  • Nếu không thể hoàn tất việc xóa an toàn thì thiết bị phải ở trạng thái khóa.
  • Nếu được hỗ trợ bởi thiết bị khối cơ 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 Xóa an toàn hoặc Cắ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 Xóa hoặc Cắt thông thường, sau đó là thao tác Vệ sinh.
  • Nếu BLKSECDISCARD không được thiết bị khối cơ bản hỗ trợ thì ioctl(BLKDISCARD) phải được sử dụng thay thế. Trên các thiết bị eMMC, đây là thao tác Cắt bình thường.
  • Nếu BLKDISCARD không được hỗ trợ, việc ghi đè các thiết bị khối bằng tất cả số 0 có thể được chấp nhận.
  • Người dùng phải có tùy chọn yêu cầu xóa dữ liệu người dùng trước khi flash phân vùng. Ví dụ: thiết bị Nexus sử dụng lệnh fastboot oem lock để xóa dữ liệu người dùng.
  • Một thiết bị có thể ghi lại, thông qua eFuses hoặc cơ chế tương tự, xem thiết bị đã được mở khóa và/hoặc khóa lại hay chưa. Tuy nhiên, chúng tôi thực sự khuyên bạn rằng việc khóa lại bộ nạp khởi động sau khi khôi phục cài đặt gốc sẽ khôi phục toàn bộ chức năng của thiết bị.

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

Một thiết bị đã được mở khóa sau đó có thể được khóa lại bằng lệnh fastboot oem lock . Việc khóa bộ nạp khởi động cung cấp khả năng bảo vệ dữ liệu người dùng tương tự với hệ điều hành tùy chỉnh mới như đã có với hệ điều hành ban đầu của nhà sản xuất thiết bị (ví dụ: dữ liệu người dùng sẽ bị xóa nếu thiết bị được mở khóa lại).

Pentest thiết bị

Thiết bị phải được pentester có thẩm quyền xem xét trước khi vận chuyển. Việc kiểm tra Pentest phải chứng minh rằng thiết bị tuân theo hướng dẫn bảo mật được cung cấp tại đây cũng như hướng dẫn bảo mật nội bộ của OEM.

Kiểm tra bảo mật

Sử dụng các công cụ Kiểm tra bảo mật do AOSP cung cấp. Đặc biệt

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