可再生能源安全性编码
重要
这是 Azure Sphere(旧版)文档。 Azure Sphere(旧版)将于 2027 年 9 月 27 日停用,用户此时必须迁移到 Azure Sphere(集成)。 使用位于 TOC 上方的版本选择器查看 Azure Sphere(集成)文档。
支持可再生能源安全是高度安全设备的七个属性之一。 在 Azure Sphere 中,这意味着设备上的所有软件(包括你自己的应用程序)都可以根据需要进行更新,以解决新发现的漏洞。 安全性是 Azure Sphere 存在的原因,它不能过于强调,始终确保设备安全至关重要。 无法编写完全安全的代码,但具有良好的编码做法、响应新发现的漏洞的极端勤奋以及对可再生能源安全性的承诺,可以确保高级应用程序代码尽可能安全。 Azure Sphere 应用程序隔离模型提供了许多功能,以确保满足以下条件:
- 必须先对所有应用进行适当签名,然后才能安装或运行它们。
- 只有应用程序 的应用清单 文件中指定的硬件功能和 Internet 地址才能由应用程序访问。
- Azure Sphere SDK 提供的 API 包括标准 C 库的大幅减少子集,省略潜在的安全漏洞,例如用户帐户和 shell 访问。
- 可以使用 Azure Sphere 安全服务安全地更新 Azure Sphere OS 和客户应用程序,因为已识别并解决安全问题。
但是,代码签名和攻击面最小化仅使你走得很远。 遵循一组安全软件开发最佳做法有助于确保你签名的应用程序尽可能安全。 本文介绍 Azure Sphere 团队在其自己的开发实践中使用的一些工具。
计划常规部署
Azure Sphere OS 和 Azure Sphere SDK 至少每季度更新一次。 应针对自己的应用程序的部署制定类似的计划。
确保工具链保持最新状态
Azure Sphere OS 和 SDK 构成了 Azure Sphere 工具链的大部分内容,但你可能拥有单独管理的其他组件。 请务必定期检查这些组件的更新。
常见漏洞和暴露 (CVE) 是公共报告,用于描述系统中的安全漏洞,包括在 Azure Sphere 中。 Azure Sphere OS 更新定期解决 CVE 的问题,并帮助保护设备的安全。 如果可能,请在生成管道中包含对 CVE 的检查。 为跟踪安全更新的 CISA 主页等 网站 添加书签。 更新工具链时重新生成和重新部署应用程序。
传播并遵守编码标准
遵循已知标准的代码更易于维护、更易于查看和更易于测试。 C 有公开可用的编码标准。 MISRA 已建立良好, CERT 也具有 C 编码标准。除了这些基本标准,我们建议尽可能使用 安全开发生命周期 。
确保使用基本安全标志进行编译
所有 Azure Sphere 应用都是使用 Gnu 编译器集合(GCC)中的 C 语言编译器生成的。 C 编译器 gcc 提供了数百个 编译器和链接器标志。 在 Azure Sphere 中,默认使用以下标志:
-fstack-protector-strong
:生成代码以防止 堆栈粉碎攻击。pie
:生成独立于位置的可执行文件。fPIC
:生成独立于位置的代码。
该 -fstack-protector-all
标志提供的保护比更高 -fstack-protector-strong
,但会增加内存堆栈使用率。 由于当前 Azure Sphere 硬件上的内存有限, -fstack-protector-all
默认情况下不使用。
Azure Sphere 还使用许多警告标志 -- 这些标志可用于在编译期间识别代码问题,可以在部署之前修复这些标志:
-Wall -Wswitch -Wempty-body -Wconversion -Wreturn-type -Wparentheses -Wno-format -Wuninitialized -Wunreachable-code -Wunused-function -Wunused-value -Wunused-variable -Wstrict-prototypes -Wno-pointer-sign -Werror=implicit-function-declaration
为了提高安全性, -Wl,-z,now
或者 -Wl,-z,relro
可以添加,但同样,默认情况下不会使用这些安全性,因为它们会导致额外的内存使用量。
查看所有代码
代码评审是确保高质量代码的简单但有效的工具。 建议在未经合格审阅者进行代码评审的情况下,不签入任何代码。 一对一代码评审,其中开发人员与另一个开发人员一起浏览新代码,通常帮助原始开发人员阐明生成代码的想法。 这可以揭示设计弱点或错过分支点,即使没有评审开发人员的输入。
使用自动测试
自动测试框架(如 gtest)使你能够在每次生成项目时运行测试函数套件。 最佳做法是确保所有签入代码至少附带一个测试函数:更多通常是更好的。 重要的测试类型包括:
- 基本单元测试 运行每个代码片段,以验证它是否按设计工作。 测试用例应设计为在边缘测试代码;角用例和边缘事例通常是一个富有成效的 bug 来源。
- 模糊测试 通过提供不同类型的意外输入来练习代码,以确保函数正确响应。
- 渗透测试 可用于识别允许攻击者渗透应用程序的漏洞。
使用静态代码分析器
静态代码分析器可帮助查找许多常见的代码问题。 大多数侧重于特定类型的错误。 以下免费开源工具是 Azure Sphere 开发团队和一些 Azure Sphere 用户使用的工具之一:
- clang-tidy
- AddressSanitizer (ASan)
- MemorySanitizer (MSan)
- UndefinedBehaviorSanitizer (UBSan)
- Valgrind
运行其中一些工具可能需要为其他目标操作系统重新编译应用程序(或部分)。
删除不需要的代码
Azure Sphere SDK 提供标准 C 开发库的剥离版本;在可能的情况下,你应该寻找机会,将自己的代码剥离到其裸露的基本内容。 代码行越少,攻击面越小,可能会面临潜在威胁。 有关无法访问或未使用的代码的警告可用于标识不需要的代码。