| <html devsite><head> |
| <title>系统安全性最佳做法</title> |
| <meta name="project_path" value="/_project.yaml"/> |
| <meta name="book_path" value="/_book.yaml"/> |
| </head> |
| <body> |
| <!-- |
| Copyright 2018 The Android Open Source Project |
| |
| Licensed under the Apache License, Version 2.0 (the "License"); |
| you may not use this file except in compliance with the License. |
| You may obtain a copy of the License at |
| |
| //www.apache.org/licenses/LICENSE-2.0 |
| |
| Unless required by applicable law or agreed to in writing, software |
| distributed under the License is distributed on an "AS IS" BASIS, |
| WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| See the License for the specific language governing permissions and |
| limitations under the License. |
| --> |
| <p>本部分包含可确保核心 Android 操作系统和设备的安全性的建议。</p> |
| |
| <h2 id="biometric-authentication">生物识别身份验证</h2> |
| |
| <p>仔细获取、存储和处理<a href="/security/biometric">生物识别数据</a>以进行用户身份验证。您应该： |
| </p> |
| |
| <ul> |
| <li>在使用任何其他形式的身份验证（包括生物识别）之前，指定主要的身份验证方法。</li> |
| <li>在使用被动生物识别模式（例如面部识别）进行涉及身份验证绑定密钥的交易（例如，付款）时，必须提供明确的确认以指明 intent。</li> |
| <li>必须每 72 小时使用一次主要身份验证方法。</li> |
| <li>为所有生物识别数据和处理使用完全安全的管道。</li> |
| <li>切勿在设备外发送生物识别数据（包括原始传感器测量和衍生特征）。如果可能，请将此数据保存在安全的隔离环境（例如<a href="/security/trusty">可信执行环境 (TEE)</a> 或安全元件）中。</li> |
| </ul> |
| |
| <p>具有生物识别技术的设备应该支持 <a href="https://developer.android.com/preview/features/security#fingerprint-auth" class="external">BiometricPrompt API</a>，此 API 为应用开发者提供了一个通用且一致的接口，以便在他们的应用中利用基于生物识别的身份验证。只有<a href="/security/biometric/#strong-weak-unlocks" class="external">极为安全的生物识别技术</a>才能与 <code>BiometricPrompt</code> 集成，并且集成必须遵循 <a href="/compatibility/cdd">Android 兼容性定义文档</a> (CDD) 指南。</p> |
| |
| <p>有关更多生物识别指南，请参阅<a href="/security/biometric#hal-implementation">生物识别 HAL 实施准则</a>。</p> |
| |
| <h2 id="selinux">SELinux</h2> |
| |
| <p>SELinux 提供了 Android 大部分安全模型的定义和强制执行。正确使用 SELinux 对于 Android 设备的安全性至关重要，并有助于减轻安全漏洞的影响。出于此原因，所有 Android 设备都应该实现<a href="/security/selinux/device-policy#granting_the_dac_override_capability">可靠的 SELinux 政策</a>。</p> |
| |
| <ul> |
| <li>实现最小特权政策。</li> |
| <li>避免授予 <code>CAP_DAC_OVERRIDE</code>、<code>CAP_SYS_ADMIN</code> 和 <code>CAP_NET_ADMIN</code> 权限。</li> |
| <li>不要将系统数据记录到 SD 卡。</li> |
| <li>使用提供的类型访问驱动程序，例如 <code>gpu_device</code>、<code>audio_device</code> 等。</li> |
| <li>对进程、文件和 SELinux 类型使用有意义的名称。 |
| <ul> |
| <li>确保未使用默认标签，并且没有向其授予访问权限。</li> |
| </ul> |
| </li> |
| <li>设备专用政策应占设备上运行的所有政策的 5-10%。如果自定义政策所占的比例超过 20%，则几乎肯定会包含超特权域和 Dead 政策。过大的政策会浪费内存，因需要较大的启动映像而浪费磁盘空间，并对运行时政策查询时间产生负面影响。 |
| </li> |
| </ul> |
| |
| <h3 id="dynamic-loading-selinux-policy">动态加载 SELinux 政策</h3> |
| |
| <p>请勿在 Android 设备上动态加载 SELinux 政策。这样做可能会导致出现问题，例如：</p> |
| |
| <ul> |
| <li>阻止接受重要的安全补丁程序。</li> |
| <li>通过重新加载政策公开对设备进行 Root 操作的功能。</li> |
| <li>公开针对政策更新程序的中间人攻击的矢量。</li> |
| <li>由于政策更新错误导致砖砌设备。</li> |
| </ul> |
| |
| <h2 id="backdoors">后门程序</h2> |
| |
| <p>Android 应用不得通过任何后门或其他方式来访问可绕过正常安全机制的系统或数据。这包括由开发者已知的密钥把关的诊断、调试、开发或保修修复特殊权限。要阻止后门程序，请执行以下操作：</p> |
| |
| <ul> |
| <li>使用行业认可的应用漏洞扫描工具来扫描所有第三方应用。</li> |
| <li>对具有敏感访问权限的所有代码（包括第三方库）执行代码审核。</li> |
| <li>通过将要扫描的应用上传到 Google Play 来利用 Google Play 保护机制。您可以上传要扫描的应用，而无需发布到 Google Play。</li> |
| <li>请勿在发布版本上预加载侧重于诊断或修复的工具。仅按需安装这些工具以解决特定问题。此外，这些工具不得处理或上传任何特定于帐号的数据。</li> |
| </ul> |
| |
| <h2 id="development-tools">开发工具</h2> |
| |
| <p>开发工具（如调试、测试和诊断工具）通常可以揭示所收集的数据的处理方式，从而在设备上产生意外的安全漏洞。要确保开发工具不会进入正式版，请执行以下操作：</p> |
| |
| <ul> |
| <li>在使用系统映像之前，制作内部调试和测试工具哈希的黑名单并扫描这些 APK 的构建。</li> |
| <li>使用行业认可的应用漏洞扫描工具扫描所有第一方应用。</li> |
| <li>雇用第三方应用安全测试公司在任何重大更新之前评估设备上的所有关键诊断应用，尤其是应用是由第三方开发时。</li> |
| <li>确保只有用户可以在支持会话期间以口头或聊天方式启用该工具。存储同意的软件工件并在收集必要的诊断信息后停用该工具。</li> |
| <li>将此工具的使用记录存储在用户可通过其运营商帐号访问的日志中。</li> |
| <li>确保该工具收集的任何个人身份信息 (PII) 或设备遥测数据受到与相应国家/地区相关的匿名、保留和删除惯例的约束。只能收集与支持服务相关的数据。每次致电后都应删除这些数据。</li> |
| <li>确保未经用户明确同意，不得使用可用于间谍软件的技术（例如击键记录、麦克风使用或相机使用）。应将利用这些可能侵犯隐私的方法的应用以及用户必须同意的隐私权政策明确告知用户。未经用户明确同意，不得启用此类应用。</li> |
| </ul> |
| |
| <p>以下是在实现披露和同意时要参考的一些其他建议：</p> |
| |
| <h3 id="in-app-disclosure">应用内披露</h3> |
| |
| <ul> |
| <li>直接在应用内显示应用的正常使用情况。无需用户打开任何菜单或设置就能查看。</li> |
| <li>向用户说明所收集数据的类型以及数据的使用方式。</li> |
| <li>理想情况下，请勿将此信息嵌入隐私权政策或服务条款中。请勿将其包含在其他与个人数据或敏感数据收集无关的披露声明中。</li> |
| </ul> |
| |
| <h3 id="request-consent">征求用户同意</h3> |
| |
| <ul> |
| <li>同意必须是明确的。请勿将用户离开披露页面的操作（包括点按其他位置离开或者按返回或主屏幕按钮）视为同意。</li> |
| <li>征求同意的对话框必须以清楚明确的方式呈现。</li> |
| <li>必须要求用户执行明确的确认操作（例如点按接受或说出命令）来给予授权。</li> |
| <li>在征得用户明确同意之前，请勿收集个人或敏感数据。</li> |
| <li>请勿使用会自动关闭或设有期限的消息。</li> |
| </ul> |
| |
| <h2 id="embedded-functionality-in-aosp">AOSP 中的嵌入式功能</h2> |
| |
| <p>在 AOSP 中嵌入其他功能往往会产生意外行为和后果；因此请谨慎行事。</p> |
| |
| <ul> |
| <li>确保用户在要使用其他默认应用（例如，搜索引擎、网络浏览器、启动器）并披露从设备外发送数据时会收到提示。</li> |
| <li>确保 AOSP APK 使用 AOSP 证书进行签名。</li> |
| <li>运行回归测试并保留更改日志以确定 AOSP APK 是否已添加代码。</li> |
| </ul> |
| |
| <h2 id="security-updates">安全更新</h2> |
| |
| <p>Android 设备应在至少两年（从发布之日算起）内获得持续的安全支持。这包括接收可解决已知安全漏洞的定期更新。</p> |
| |
| <ul> |
| <li>与硬件合作伙伴（如 SoC 供应商）合作，针对 Android 设备上的所有组件制定适当的支持协议。</li> |
| <li>确保可以在用户交互最少的情况下安装安全更新，以提高用户在其 Android 设备上接受和安装更新的可能性。强烈建议实现<a href="/devices/tech/ota/ab/">无缝系统更新</a>或等效的安全功能。</li> |
| <li>确保您了解 <a href="/security/bulletin/">Android 安全公告</a>中声明的 Android 安全补丁程序级别 (SPL) 的累积要求。如果设备使用的是 2018-02-01 这一安全补丁程序级别，则必须包含该安全补丁程序级别涵盖的所有问题以及之前的安全公告中报告的所有问题的修复程序。</li> |
| </ul> |
| |
| <h3 id="dynamic-kernel-updates">动态内核更新</h3> |
| |
| <p>请勿动态修改关键系统组件。虽然有一些研究表明动态内核更新有助于防范紧急威胁，但收益目前赶不上评估费。建议创建一个强大的 OTA 更新方法来快速分发漏洞保护。</p> |
| |
| <h2 id="key-management">密钥管理</h2> |
| |
| <p>保持良好的密钥管理政策和做法，以确保签名密钥的安全性。</p> |
| |
| <ul> |
| <li>不要与外部方共享签名密钥。</li> |
| <li>如果签名密钥受到攻击，请生成新密钥并在以后对所有应用进行双重签名。</li> |
| <li>将所有密钥存储在需要多重认证才能访问的高度安全的模块硬件或服务中。</li> |
| </ul> |
| |
| <h2 id="system-image-signing">系统映像签名</h2> |
| |
| <p>系统映像的签名对于确定设备的完整性至关重要。</p> |
| |
| <ul> |
| <li>请勿使用已公开的密钥对设备进行签名。</li> |
| <li>按照与处理敏感密钥方面的业界标准做法一致的方式管理用于为设备签名的密钥，包括使用能够提供有限、可审核访问权限的硬件安全模块 (HSM)。</li> |
| </ul> |
| |
| <h2 id="unlockable-bootloaders">可解锁的引导加载程序</h2> |
| |
| <p>许多 Android 设备都支持解锁引导加载程序。解锁引导加载程序后，设备所有者将能够修改系统分区和/或安装自定义操作系统。常见用例包括在设备上安装第三方只读存储器 (ROM) 以及进行系统级开发。例如，Google Nexus 设备所有者可以运行 <code>fastboot oem unlock</code> 来启动解锁过程，该过程会向用户显示以下消息：</p> |
| |
| <aside class="caution"> |
| <p><strong>解锁引导加载程序吗？</strong></p> |
| |
| <p>如果您解锁引导加载程序，则可以在此手机上安装自定义操作系统软件。</p> |
| |
| <p>自定义操作系统未经过与原始操作系统相同的测试，可能会导致您的手机和已安装的应用停止正常工作。</p> |
| |
| <p>为防止未经授权访问您的个人数据，解锁引导加载程序还将删除您手机上的所有个人数据（“恢复出厂设置”）。</p> |
| |
| <p>按音量调高按钮/音量调低按钮可选择“是”或“否”，然后按电源按钮即可继续。</p> |
| |
| <p><strong>是</strong>：解锁引导程序（可能会使保修无效）</p> |
| |
| <p><strong>否</strong>：不解锁引导加载程序并重启手机。</p> |
| </aside> |
| |
| <p>作为最佳做法，在解锁之前，可解锁的 Android 设备必须先安全地清除所有用户数据。如果未能适当删除所有数据便进行解锁，能够接触到这些设备的攻击者便可以在未经授权的情况下获取机密的 Android 用户数据。为了防止用户数据泄露，支持解锁的设备必须正确实现解锁。</p> |
| |
| <ul> |
| <li>在用户确认解锁命令后，设备必须立即开始擦除数据。在安全删完数据之前，不得设置 <code>unlocked</code> 标记。</li> |
| <li>如果无法安全删完数据，则设备必须保持锁定状态。</li> |
| <li>如果底层块设备支持 <code>ioctl(BLKSECDISCARD)</code> 或等同命令，则应使用此类命令。对于嵌入式 MultiMediaCard (eMMC) 设备，这意味着使用 Secure Erase 或 Secure Trim 命令。对于 eMMC 4.5 及更高版本，这意味着先使用常规的 Erase 或 Trim 命令，然后再执行 Sanitize 操作。</li> |
| <li>如果底层块设备不支持 <code>BLKSECDISCARD</code>，则必须改用 <code>ioctl(BLKDISCARD)</code>。在 eMMC 设备上，这是一个常规的 Trim 操作。</li> |
| <li>如果 <code>BLKDISCARD</code> 不受支持，可以将块设备中的数据重写为全零。</li> |
| <li>用户必须能够要求在刷写分区之前先清除用户数据。例如，Nexus 设备使用 <code>fastboot oem lock</code> 命令擦除用户数据。</li> |
| <li>无论设备处于解锁还是重新锁定状态，都可以通过 eFuses 或类似机制进行记录。不过，我们强烈建议重新锁定引导加载程序并随后恢复出厂设置，这样应该能恢复完整的设备功能。</li> |
| </ul> |
| |
| <p>这些要求旨在确保在完成解锁操作时所有数据都已被销毁。未能实现这些保护措施会被视为存在<a href="/security/overview/updates-resources#severity">中级安全漏洞</a>。</p> |
| |
| <p>将设备解锁后，可以使用 <code>fastboot oem lock</code> 命令重新将其锁定。使用新的自定义操作系统时，锁定引导加载程序能够为用户数据提供的保护与原始设备制造商操作系统提供的保护相同（例如，如果设备被再次解锁，用户数据将会被清除）。</p> |
| |
| <h2 id="device-pentesting">设备测试</h2> |
| |
| <p>设备应在装运前由具备资质的测试员进行审核。测试应确认设备是否遵循此处提供的安全指导以及内部 OEM 安全指导。</p> |
| |
| </body></html> |
