| <html devsite><head> |
| <title>组织和运营安全性</title> |
| <meta name="project_path" value="/_project.yaml"/> |
| <meta name="book_path" value="/_book.yaml"/> |
| </head> |
| <body> |
| <!-- |
| Copyright 2017 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 |
| |
| http://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>从您的组织内部开始为良好的安全做法奠定基础。</p> |
| |
| <h3 id="create-a-team">组建安全与隐私权团队</h3> |
| |
| <p>组建一个专门的安全和隐私权团队，并为该组织安排一位领导者。</p> |
| |
| <ul> |
| <li><strong>组建安全团队。</strong> |
| <ul> |
| <li>确保至少有一名员工负责安全、隐私权和事件响应。</li> |
| <li>为这个团队指定任务和职责范围。</li> |
| <li>为以下人员制定组织结构图和职位描述：安全经理、安全工程师、事件管理员。</li> |
| <li>雇用员工或外部承包商来担任这些角色。</li> |
| </ul> |
| </li> |
| <li><strong>定义安全开发生命周期 (SDL)</strong>。您的 SDL 应涵盖以下方面： |
| <ul> |
| <li>产品的安全要求。</li> |
| <li>风险分析和威胁建模。</li> |
| <li>对应用和代码的<a href="/devices/tech/debug/fuzz-sanitize">静态和动态分析</a>。</li> |
| <li>产品的最终安全审核流程。</li> |
| <li>事件响应。</li> |
| </ul> |
| </li> |
| <li><strong>评估组织风险</strong>。创建风险评估并制定计划以消除或化解这些风险。</li> |
| </ul> |
| |
| <h3 id="build-verification">创建验证流程</h3> |
| |
| <p>评审现有内部构建验证和批准流程中的问题。</p> |
| |
| <ul> |
| <li>指出当前构建验证流程中可能导致在构建中引入<a href="/security/reports/Google_Android_Security_PHA_classifications.pdf">潜在有害应用</a> (PHA) 的所有问题。</li> |
| <li>确保您制定了代码审核和批准流程，即使是对 <a href="https://android.googlesource.com/" class="external">AOSP</a> 的内部修补也是如此。</li> |
| <li>通过在以下方面实施控制来提高构建完整性： |
| <ul> |
| <li><strong>跟踪更改</strong>。跟踪软件工程师；保留更改日志。</li> |
| <li><strong>评估风险</strong>。评估应用使用的权限；需要对代码更改进行手动审核。</li> |
| <li><strong>监控</strong>。评估对特权代码所做的更改。</li> |
| </ul> |
| </li> |
| </ul> |
| |
| <h3 id="source-code-change-tracking">源代码更改跟踪</h3> |
| |
| <p>监控源代码或第三方应用/二进制文件/SDK 的意外修改行为。</p> |
| |
| <ul> |
| <li><strong>评估合作伙伴关系</strong>。按照以下步骤评估与技术合作伙伴进行合作的风险： |
| |
| <ul> |
| <li>针对如何评估与特定供应商合作的风险制定相关标准。</li> |
| <li>制作一个表单，询问供应商如何解决事件并管理安全性和隐私权。</li> |
| <li>通过定期审核验证他们的声明。</li> |
| </ul> |
| </li> |
| <li><strong>跟踪更改</strong>。记录哪些公司和员工修改了源代码并定期进行审核，以确保只进行适当的更改。</li> |
| <li><strong>保留记录</strong>。记录哪些公司将第三方二进制文件添加到您的版本中，并记录这些应用执行的功能及其收集的数据。</li> |
| <li><strong>计划更新</strong>。确保您的供应商按照要求在产品的整个生命周期内提供软件更新。不可预见的漏洞问题可能需要供应商提供支持才能解决。</li> |
| </ul> |
| |
| <h3 id="validate-source-code">验证源代码完整性和起源</h3> |
| |
| <p>检查并验证原始设备制造商 (ODM)、无线下载更新 (OTA) 或运营商提供的源代码。</p> |
| |
| <ul> |
| <li><strong>管理签名证书</strong>。 |
| <ul> |
| <li>将密钥存储在硬件安全模块 (HSM) 或安全云服务中（不要共享它们）。</li> |
| <li>确保控制和审核对签名证书的访问权限。</li> |
| <li>要求在编译系统中完成所有代码签名。</li> |
| <li>撤消丢失的密钥。</li> |
| <li>使用最佳做法生成密钥。</li> |
| </ul> |
| </li> |
| <li><strong>分析新代码</strong>。使用安全代码分析工具测试新添加的代码，以检查是否引入了新漏洞。此外，还要分析整体功能以检测新漏洞的表现形式。</li> |
| <li><strong>在发布前进行审核</strong>。在将源代码和第三方应用推送到生产环境之前，查找其中的安全漏洞。例如： |
| <ul> |
| <li>要求应用使用安全通信。</li> |
| <li>遵循最小权限原则并授予应用运行所需的最小权限集。</li> |
| <li>确保通过安全通道存储和传输数据。</li> |
| <li>确保服务依赖项保持最新状态。</li> |
| <li>将安全补丁程序应用于 SDK 和开源库。</li> |
| </ul> |
| </li> |
| </ul> |
| |
| <h2 id="incident-response">事件响应</h2> |
| |
| <p>Android 相信可以借助强大的安全社区发现问题。您应该为外部各方创建并公布一种方法，方便相应人员可以就设备特有的安全问题与您联系。</p> |
| |
| <ul> |
| <li><strong>建立联系</strong>。创建一个电子邮件地址（例如 security@<var>your-company</var>.com）或制作一个网站，并清晰地说明如何报告与您的产品相关的潜在安全问题（<a href="https://security.samsungmobile.com/securityReporting.smsb" class="external">示例</a>）。</li> |
| <li><strong>向上游贡献更改</strong>。如果您发现某个安全问题会影响 Android 平台或多个设备制造商的设备，请通过提交<a href="g.co/AndroidSecurityReport" class="external">安全错误报告</a>与 Android 安全团队联系。 |
| </li> |
| <li><strong>宣传良好的安全做法</strong>。主动评估为您的设备提供服务、组件和/或代码的硬件和软件供应商的安全做法。让供应商负责维持良好的安全态势。</li> |
| </ul> |
| |
| </body></html> |
