Google cam kết thúc đẩy công bằng chủng tộc cho các cộng đồng Đen. Xem thế nào.
Trang này được dịch bởi Cloud Translation API.
Switch to English

Thực tiễn tốt nhất về bảo mật ứng dụng

Phần này chứa các đề xuất để đảm bảo tính bảo mật của ứng dụng trên thiết bị Android.

Xem lại mã nguồn

Đánh giá mã nguồn có thể phát hiện một loạt các vấn đề bảo mật, bao gồm cả những vấn đề được xác định trong tài liệu này. Android khuyến khích mạnh mẽ cả đánh giá mã nguồn thủ công và tự động.

  • Thực hiện theo hướng dẫn bảo mật toàn diện khi tiến hành đánh giá để đảm bảo bảo hiểm. Sử dụng các tiêu chuẩn nội bộ hoặc bên ngoài có liên quan để đảm bảo đánh giá nhất quán và đầy đủ.
  • Chạy một kẻ nói dối, chẳng hạn như kẻ nói dối Android Studio , trên tất cả các mã ứng dụng bằng SDK Android và sửa bất kỳ vấn đề nào được xác định.
  • Phân tích mã gốc bằng cách sử dụng một công cụ tự động có thể phát hiện các sự cố quản lý bộ nhớ, chẳng hạn như lỗi tràn bộ đệm và lỗi do lỗi một.
  • Xây dựng hệ thống Android hỗ trợ rất nhiều các chất vệ sinh LLVM, chẳng hạn như AddressSanitizerUndefinedBehaviorSanitizer , có thể được sử dụng để phân tích thời gian chạy của các vấn đề bộ nhớ có liên quan. Kết hợp với làm mờ, được hỗ trợ trong Android thông qua libFuzzer , các nhà vệ sinh có thể phát hiện ra các trường hợp cạnh bất thường cần điều tra thêm.
  • Một người đánh giá bảo mật có kiến ​​thức nên xem xét mã rủi ro cao hơn, chẳng hạn như tiền điện tử, xử lý thanh toán và xử lý PII.

Kiểm tra tự động

Kiểm tra tự động có thể giúp phát hiện một loạt các vấn đề bảo mật và nên được thực hiện thường xuyên.

  • Chạy phiên bản CTS mới nhất thường xuyên trong suốt quá trình phát triển để phát hiện sớm các sự cố và giảm thời gian khắc phục. Android sử dụng CTS như một phần của tích hợp liên tục trong quy trình xây dựng tự động của chúng tôi, công cụ này sẽ xây dựng nhiều lần mỗi ngày.
  • Tự động kiểm tra bảo mật các giao diện, bao gồm kiểm tra với các đầu vào không đúng định dạng (kiểm tra fuzz). Hệ thống xây dựng của Android hỗ trợ libFuzzer để viết các bài kiểm tra fuzz.

Quét lỗ hổng

Quét lỗ hổng có thể giúp đảm bảo rằng các ứng dụng được cài đặt sẵn không có lỗ hổng bảo mật đã biết. Phát hiện nâng cao có thể giảm thời gian và chi phí cần thiết khi giải quyết các lỗ hổng này và ngăn ngừa rủi ro cho người dùng và thiết bị.

  • Quét tất cả các ứng dụng được cài đặt sẵn bằng công cụ quét lỗ hổng ứng dụng được công nhận trong ngành và giải quyết các lỗ hổng được phát hiện.

Ứng dụng có hại

Điều quan trọng là đảm bảo rằng các ứng dụng được cài đặt sẵn trên thiết bị của bạn không phải là Ứng dụng có hại tiềm tàng (PHAs). Bạn chịu trách nhiệm về hành vi của tất cả các ứng dụng được bao gồm trên thiết bị của bạn. Trước khi khởi chạy thiết bị, hãy quét tất cả các ứng dụng được tải sẵn để tìm lỗ hổng.

Để biết thêm thông tin về PHA và cách Google kết hợp chúng trong cửa hàng Play, hãy xem tài liệu dành cho nhà phát triển Google Play Protect .

Cài đặt ứng dụng và quyền

Quyền quá mức cho các ứng dụng được cài đặt sẵn có thể tạo ra rủi ro bảo mật. Hạn chế các ứng dụng được cài đặt sẵn ở các quyền cần thiết tối thiểu và đảm bảo chúng không có quyền truy cập vào các quyền hoặc đặc quyền không cần thiết. Quyền ứng dụng được mô tả trong AndroidManifest.xml .

  • Không cấp quyền hoặc đặc quyền không cần thiết cho các ứng dụng được cài đặt sẵn. Xem xét kỹ lưỡng các ứng dụng có đặc quyền hệ thống vì chúng có thể có các quyền rất nhạy cảm.
  • Đảm bảo rằng tất cả các quyền được yêu cầu có liên quan và cần thiết cho chức năng của ứng dụng cụ thể đó.
  • Đảm bảo có tiết lộ người dùng cho tất cả các ứng dụng được cài đặt sẵn sử dụng quyền INSTALL_PACKAGES .
  • Đảm bảo rằng nhà phát triển có nghĩa vụ theo hợp đồng không cài đặt bất kỳ ứng dụng nào dưới dạng UID 0.
  • Đánh giá các quyền được khai báo trong bảng kê khai của tất cả các ứng dụng sẽ được cài đặt thông qua mạng của nhà phát triển.
  • Đảm bảo rằng nhà phát triển có nghĩa vụ theo hợp đồng để quét tất cả các URL tải xuống của ứng dụng trình cập nhật và cài đặt tự động bằng API duyệt web an toàn của Google trước khi phân phát ứng dụng cho thiết bị.

Ký ứng dụng

Chữ ký ứng dụng đóng một vai trò quan trọng trong bảo mật thiết bị và được sử dụng để kiểm tra quyền và cập nhật phần mềm. Khi chọn một khóa để sử dụng để ký ứng dụng, điều quan trọng là phải xem xét liệu một ứng dụng sẽ chỉ khả dụng trên một thiết bị duy nhất hay phổ biến trên nhiều thiết bị.

  • Đảm bảo rằng các ứng dụng không được ký với một khóa được biết đến công khai, chẳng hạn như khóa nhà phát triển AOSP.
  • Đảm bảo rằng các khóa được sử dụng để ký ứng dụng được quản lý theo cách phù hợp với thực tiễn 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.
  • Đảm bảo rằng các ứng dụng không được ký với khóa nền tảng. Làm như vậy cho phép ứng dụng truy cập vào các quyền chữ ký nền tảng, rất mạnh mẽ và chỉ được sử dụng cho các thành phần của hệ điều hành. Ứng dụng hệ thống nên sử dụng quyền đặc quyền.
  • Đảm bảo rằng các ứng dụng có cùng tên gói không được ký bằng các khóa khác nhau. Điều này thường xảy ra khi tạo một ứng dụng cho các thiết bị khác nhau, đặc biệt là khi sử dụng khóa nền tảng. Nếu ứng dụng độc lập với thiết bị, hãy sử dụng cùng một khóa trên các thiết bị. Nếu ứng dụng dành riêng cho thiết bị, hãy tạo tên gói duy nhất cho mỗi thiết bị và khóa.

Ứng dụng và quy trình cách ly

Mô hình hộp cát Android cung cấp bảo mật bổ sung xung quanh các ứng dụng và quy trình khi được sử dụng đúng cách.

Cô lập các quy trình gốc

Root process là mục tiêu thường xuyên nhất của các cuộc tấn công leo thang đặc quyền; giảm số lượng các quy trình gốc làm giảm nguy cơ leo thang đặc quyền.

  • Đảm bảo rằng các thiết bị chạy mã tối thiểu cần thiết là root. Nếu có thể, hãy sử dụng quy trình Android thông thường chứ không phải quy trình root. Nếu một quy trình phải chạy bằng root trên thiết bị, hãy ghi lại quy trình trong yêu cầu tính năng AOSP để có thể xem xét công khai.
  • Khi có thể, mã gốc nên được tách biệt khỏi dữ liệu không tin cậy và được truy cập thông qua giao tiếp giữa các quá trình (IPC). Ví dụ: giảm chức năng root cho một Dịch vụ nhỏ có thể truy cập qua Binder và hiển thị Dịch vụ với quyền chữ ký cho ứng dụng có mức độ thấp hoặc không có đặc quyền để xử lý lưu lượng mạng.
  • Quá trình root không được nghe trên một ổ cắm mạng.
  • Các quy trình gốc không được bao gồm thời gian chạy có mục đích chung, chẳng hạn như máy ảo Java).

Ứng dụng hệ thống cách ly

Nói chung, các ứng dụng được cài đặt sẵn không nên chạy với mã định danh duy nhất của hệ thống dùng chung (UID). Nếu ứng dụng cần sử dụng UID chung của hệ thống hoặc dịch vụ đặc quyền khác (ví dụ: điện thoại), ứng dụng không được xuất bất kỳ dịch vụ, máy thu quảng bá hoặc nhà cung cấp nội dung nào có thể được truy cập bởi ứng dụng của bên thứ ba do người dùng cài đặt .

  • Đảm bảo các thiết bị chạy mã tối thiểu cần thiết như hệ thống. Nếu có thể, hãy sử dụng quy trình Android với UID của chính nó thay vì sử dụng lại UID hệ thống.
  • Khi có thể, mã hệ thống nên được cách ly khỏi dữ liệu không tin cậy và chỉ hiển thị IPC cho các quy trình đáng tin cậy khác.
  • Các quy trình hệ thống không được nghe trên một ổ cắm mạng. Đây là một yêu cầu CTS.

Quá trình cô lập

Sandbox ứng dụng Android cung cấp cho các ứng dụng một kỳ vọng tách biệt khỏi các quy trình khác trên hệ thống, bao gồm các quy trình gốc và trình gỡ lỗi. Trừ khi gỡ lỗi được kích hoạt cụ thể bởi ứng dụng và người dùng, không ứng dụng nào vi phạm mong đợi đó.

  • Đảm bảo các quy trình gốc không truy cập dữ liệu trong các thư mục dữ liệu ứng dụng riêng lẻ, trừ khi sử dụng phương pháp gỡ lỗi Android được ghi lại.
  • Đảm bảo các quy trình gốc không truy cập vào bộ nhớ của các ứng dụng, trừ khi sử dụng phương pháp gỡ lỗi Android được ghi lại.
  • Đảm bảo các thiết bị không bao gồm bất kỳ ứng dụng nào truy cập dữ liệu hoặc bộ nhớ của các ứng dụng hoặc quy trình khác.