系統安全性最佳做法

本節提供建議，協助您確保核心 Android 作業系統和裝置的安全性。

生物特徵辨識驗證

請謹慎取得、儲存及處理用於使用者驗證的生物特徵資料。您應：

  • 在使用任何其他形式的驗證 (包括生物特徵辨識) 之前，請先要求使用主要驗證方法。
  • 對於涉及驗證綁定金鑰的交易 (例如付款)，如果使用臉部辨識等被動生物特徵辨識模式，請要求使用者明確確認意圖。
  • 每隔 72 小時就要求使用主要驗證方法。
  • 使用完全安全的管道處理所有生物特徵辨識資料。
  • 請勿將生物特徵辨識資料 (包括原始感應器測量值和衍生功能) 傳送至裝置外。盡可能將這類資料保留在安全的隔離環境中，例如受信任的執行環境 (TEE) 或安全元件。

支援生物特徵辨識的裝置應支援 BiometricPrompt API，這個 API 可提供常見且一致的介面，讓應用程式開發人員在應用程式中充分運用以生物特徵辨識為基礎的驗證機制。只有強式生物特徵辨識可與 BiometricPrompt 整合，且整合作業必須遵循 Android 相容性定義說明文件 (CDD) 的規範。

如需更多生物特徵辨識指南，請參閱生物特徵辨識 HAL 實作指南。

SELinux

SELinux 可定義並強制執行大部分 Android 安全模型。正確使用 SELinux 對 Android 裝置的安全性至關重要，而且有助於減輕安全漏洞的影響。因此，所有 Android 裝置都應實作完善的 SELinux 政策。

  • 實施最低權限政策。
  • 避免授予 CAP_DAC_OVERRIDE、CAP_SYS_ADMIN 和 CAP_NET_ADMIN 權限。
  • 請勿將系統資料記錄到 SD 卡。
  • 使用提供的類型進行驅動程式存取，例如 gpu_device、audio_device 等。
  • 為程序、檔案和 SELinux 類型使用有意義的名稱。
    • 請確認未使用預設標籤，也未授予預設標籤存取權。
  • 裝置專屬政策應占裝置上執行的整體政策的 5% 至 10%。在 20%以上範圍內的自訂項目幾乎一定包含權限過高的網域和無效政策。不必要的大型政策會浪費記憶體，並需要更大的開機映像檔，因此會浪費磁碟空間，並對執行階段政策查詢時間造成負面影響。

動態載入 SELinux 政策

請勿在 Android 裝置上動態載入 SELinux 政策。否則可能會導致問題，例如：

  • 避免接受重大安全性修補程式。
  • 透過重新載入政策，提供取得裝置 root 權限的功能。
  • 讓政策更新器暴露在攔截式攻擊的攻擊向量中。
  • 導致政策更新發生錯誤，導致裝置無法使用。

後門

Android 應用程式不應有任何後門，或可用於存取系統或資料的任何方式，以便繞過一般安全機制。這包括由開發人員所知的密鑰所控管的特殊存取權，用於診斷、偵錯、開發或保固維修。如要避免後門，請採取下列做法：

  • 使用業界認可的應用程式安全漏洞掃描工具掃描所有第三方應用程式。
  • 針對所有具有敏感存取權的程式碼 (包括第三方程式庫) 進行程式碼審查。
  • 將應用程式上傳至 Google Play 進行掃描，以便使用 Google Play 安全防護服務。您可以上傳應用程式供掃描，而無須發布至 Google Play。
  • 請勿在發布子版本中預先載入診斷或修復工具。請只在需要解決特定問題時安裝這些工具。 此外，這些工具不得處理或上傳任何帳戶專屬資料。

開發工具

偵錯、測試和診斷工具等開發工具，經常會揭露其運作方式和收集的資料，因此可能會在裝置上造成意外的安全漏洞。如要確保開發工具不會納入正式版：

  • 開發內部偵錯和測試工具雜湊的黑名單，並在使用系統映像檔前掃描這些 APK 的版本。
  • 使用業界認可的應用程式安全漏洞掃描工具，掃描所有第一方應用程式。
  • 在進行任何重大更新前，請聘請第三方應用程式安全性測試公司評估所有重要的裝置上診斷應用程式，特別是如果應用程式是由第三方開發的話。
  • 請確認在支援工作階段中，只有使用者可以透過語音或即時通訊啟用工具。收集必要的診斷資訊後，請儲存同意聲明的構件，並停用該工具。
  • 將這項工具的使用記錄儲存在使用者可透過其電信業者帳戶存取的記錄檔中。
  • 確保工具收集的任何個人識別資訊 (PII) 或裝置遙測資料，都會遵守與該國家/地區相關的去識別化、保留和刪除做法。請僅收集與支援通話相關的資料。這項資料應在每次呼叫後刪除。
  • 請確認未經使用者明確同意，就不會使用可用於間諜軟體的技術，例如記錄按鍵輸入內容、使用麥克風或相機。應用程式若採用這些可能侵犯隱私權的做法，應清楚揭露相關資訊，並提供使用者必須同意的隱私權政策。這類應用程式應在取得使用者明確同意後，才可啟用。

以下是實施揭露和同意聲明時的額外建議：

應用程式內揭露事項

  • 直接在應用程式內顯示應用程式的正常使用情境，不必讓使用者前往選單或設定頁面才能查看。
  • 說明收集的資料類型，以及資料用途。
  • 建議您不要將這項資訊嵌入隱私權政策或服務條款中。請勿將其納入與個人或機密資料收集行為無關的其他揭露事項中。
  • 同意聲明必須明確表示同意。請勿將使用者離開揭露事項的操作 (包括輕觸其他位置關閉揭露事項，或輕觸返回/主畫面按鈕) 視為同意。
  • 以清楚明確的方式呈現同意聲明對話方塊。
  • 要求使用者做出確認動作，例如輕觸項目表示接受，或說出指令。
  • 在取得明確同意前，請勿收集個人或機密資料。
  • 請勿使用會自動關閉或設有期限的訊息。

Android 開放原始碼計畫中的嵌入式功能

在 AOSP 中嵌入其他功能通常會產生非預期的行為和後果，請謹慎操作。

  • 請務必在使用者想要使用其他預設應用程式 (例如搜尋引擎、網路瀏覽器、啟動器) 時，向他們顯示提示，並揭露資料傳送至裝置外的行為。
  • 請確認 AOSP APK 已使用 AOSP 憑證簽署。
  • 執行回歸測試並保留變更記錄，以判斷 AOSP APK 是否已新增程式碼。

安全性更新

Android 裝置應從上市起至少獲得兩年的持續安全性支援。包括定期接收可解決已知安全漏洞的更新。

  • 請與硬體合作夥伴 (例如 SoC 供應商) 合作，為 Android 裝置上的所有元件簽訂適當的支援協議。
  • 請確保安全性更新可在使用者不必太多互動情況下安裝，提高使用者接受並在 Android 裝置上安裝更新的可能性。強烈建議您導入無縫系統更新或同等安全性功能。
  • 請務必瞭解 Android 安全性公告中宣告的 Android 安全性修補程式等級累積要求。舉例來說，如果裝置使用 2018-02-01 安全性修補程式等級，就必須納入該安全性修補程式等級涵蓋的所有相關問題，以及先前安全性公告中所有回報問題適用的修正程式。

動態核心更新

請勿動態修改重要系統元件。雖然有些研究指出，動態核心更新可協助防範緊急威脅，但目前評估的成本大於效益。請改為建立完善的 OTA 更新方法，快速發布漏洞防護措施。

金鑰管理

落實完善的金鑰管理政策和做法，確保簽署金鑰的安全性。

  • 請勿與外部人士分享簽署金鑰。
  • 如果簽署金鑰遭到入侵，請產生新的金鑰，並為日後所有應用程式進行雙重簽署。
  • 將所有金鑰儲存在高安全性模組硬體或需要多重因素驗證才能存取的服務中。

系統映像檔簽署

系統映像檔的簽章對於判斷裝置完整性至關重要。

  • 請勿使用公開金鑰為裝置簽署。
  • 管理裝置簽署金鑰時，請遵循業界標準的機密金鑰處理方式，包括提供可稽核的有限存取權的硬體安全性模組 (HSM)。

可解鎖的系統啟動載入程式

許多 Android 裝置都支援解鎖功能，可讓裝置擁有者修改系統分區或安裝自訂作業系統。常見的用途包括安裝第三方系統映像檔，以及在裝置上執行系統層級開發作業。舉例來說，如要解鎖 Google Nexus 或 Pixel 上的系統映像檔，使用者可以執行 fastboot oem unlock，系統會顯示以下訊息：

最佳做法是，可解鎖的 Android 裝置必須在解鎖前，安全地清除所有使用者資料。如果無法妥善刪除解鎖時的所有資料，可能會讓附近的攻擊者未經授權存取機密的 Android 使用者資料。為避免洩漏使用者資料，支援解鎖功能的裝置必須正確實作這項功能。

  • 使用者確認解鎖指令後，裝置必須立即開始資料清除程序。安全刪除作業完成後，才能設定 unlocked 標記。
  • 如果無法完成安全刪除作業，裝置必須保持鎖定狀態。
  • 如果底層區塊裝置支援，則應使用 ioctl(BLKSECDISCARD) 或等效項目。對於嵌入式多媒體卡 (eMMC) 裝置，這表示使用安全擦除或安全修剪指令。對於 eMMC 4.5 以上版本，這表示使用一般清除或修剪作業，接著執行 Sanitize 作業。
  • 如果基礎區塊裝置不支援 BLKSECDISCARD，則必須改用 ioctl(BLKDISCARD)。在 eMMC 裝置上，這是正常的修剪作業。
  • 如果不支援 BLKDISCARD，則可以使用全零值覆寫區塊裝置。
  • 使用者必須有選項，要求在刷新分割區之前先清除使用者資料。舉例來說，Nexus 裝置會使用 fastboot oem lock 指令來抹除使用者資料。
  • 裝置可能會透過 eFuses 或類似機制記錄裝置是否已解鎖和/或重新上鎖。不過，我們強烈建議您重新鎖定系統啟動載入程式，並在之後恢復原廠設定，以便還原裝置的完整功能。

這些規定可確保在解鎖作業完成後，所有資料都會遭到銷毀。未實施這些防護措施會被視為中度安全漏洞。

解鎖的裝置之後可能會使用 fastboot oem lock 指令重新上鎖。鎖定引導程式後，新的自訂 OS 將提供與原始裝置製造商 OS 相同的使用者資料保護機制 (例如，如果裝置再次解鎖，使用者資料就會遭到清除)。

裝置滲透測試

裝置應由專業的滲透測試人員審查，才能出貨。滲透測試應確認裝置是否遵循本文提供的安全性指南，以及內部原始設備製造商 (OEM) 安全性指南。

安全性測試

使用 AOSP 提供的安全測試工具。具體而言