上接：安全架构师工作方法论——企业，用户，安全架构师

IoT安全架构师因为IoT系统的特殊性需要在传统的安全设计的CIA（机密性，完整性，可用性）的基础上扩展属性和概念。

3.1 IoT安全架构师考虑的不仅仅是安全

由于IoT系统涉及到直接对物理世界的影响，不同于游戏系统，电子商务系统就是出现安全问题损失的只是虚拟资产或者是财产，不会直接影响到环境破坏和人身伤害甚至导致生命的消失。这就要求IoT系统对安全有特殊的考虑。

在ISO/IEC 30141中将IoT的安全性要求升级为对系统的可信赖的要求，可信赖属性见下图：

安全架构师需要从隐私性，防护性，可靠性，适应性和安全性5个方面考虑实现对环境扰动，而已攻击，人为错误以及系统故障4大类可能导致安全问题的场景做出预防和保护。

3.2 隐私权的7大基本原则

隐私权顾名思义这是一个来自法律的概念，而不是出之技术安全对抗的概念。这就需要将法律概念转换到系统的技术设计和要求中，目前业内主流的方案是基于设计的隐私

（Privacy by Design (PbD)[1]）是1995年由Ann Cavoukian博士开发，2010年，该框架获得了国际认可，当时国际隐私委员会和数据保护机构大会通过了一项关于设计的隐私决议，在其年度会议上将其确认为国际标准。后来引入PbD被引入到了GDPR中，让PbD的理念得到法律的背书和推进落地，虽然PbD本身的一些问题被业内批评，但是GDPR的背书从事实上认可了它的地位。

未来防止翻译的问题，以下是PbD的原文摘录，PbD的7大隐私基本原则如下：

1. Proactive not Reactive; Preventative not Remedial；
2. Privacy as the Default；
3. Privacy Embedded into Design；
4. Full Functionality – Positive-Sum, not Zero-Sum
5. End-to-End Security – Lifecycle Protection；
6. Visibility and Transparency；
7. Respect for User Privacy

具体每一项的内容大家可以直接去看原文《Privacy by Design The 7 Foundational Principles Implementation and Mapping of Fair Information Practices》Ann Cavoukian, Ph.D.，Information & Privacy Commissioner, Ontario, Canada。

3.3 两个安全性如何理解

IoT可信赖中包括了Security和Safety两个在中文中都勇安全来翻译的单词，这两个概念应该如何理解？首先需要认识到在英语世界里面Security和Safety也是非常相近的词，我们中文中的平安和Safety的内涵较为一致，安保与Security的内涵较为一致，当然处于技术上的习惯和技术人员文字功底的限制，统统翻译为安全，大部分情况下也是不影响交流的，不幸的是在IoT系统中这两个概念同时出现，这就有必要明确这两个概念的差别了。

Safety在IoT系统中的内涵使用了ISO 10795:2011的定义，指的是防止对人员和环境的物理损害和破坏。可见传统信息安全专家并不熟悉此领域，如果涉及到此领域的涉及，传统的信息安全架构师需要补充知识和引入相关领域的专家协助。

Safety的理念在安全架构师的工作中主要体现在系统的输入输出的设计上，输入的人体工程学尤其是长期使用的输入情况，需要考虑到对用户的慢性伤害，以及输入的阈值控制防止输入的异常引起输出的伤害。对于输出尤其是直接作用与人和环境的输出需要由阈值控制。在系统中嵌入Safety之外，有时候还需要为系统开发配套的Safety系统，通过系统性的保护来实现Safety的目的。关于Safety相关的内容可以学习IEC 61508的内容。

Security是信息安全领域中的原住民，它由信息安全管理系统（ISMS）和IoT系统和产品安全生命周期两大部分组成。

3.4 IoT系统需要全天候飞行并且要能快速恢复

现实世界很多事情是需要连续运作的，这就要求IoT系统满足此现实世界的要求，适应性和可靠性就是这个要求的两个等级的保障方案。可靠性指的是在可控的能力范围，适应性是对不可控的恢复能力。

3.5 IoT设备的身份标识（ID）的挑战

身份标识（ID）在系统设计中必不可少，通常开发在自己的命名空间内选择一个唯一性的足够长字符串作为ID就可以满足业务要求。在ID系统中由于设备的ID需要在多个命名空间中使用，并且用于不同的场景，面对不同的用户，这就导致了如果ID的设计不做系统化的规划会出现后期维护和升级的灾难，甚至在IoT系统的高兼容性的要求下，全面升级系ID几乎成为不可能的任务。

3.5.1 IoT设备生命周期中的多个ID场景

IoT设备的生命周期与ID相关的阶段见下表：

“无名，万物之始也；有名，万物之母也。”所有需要操作的场景都需要为被操作对象设定ID。那么在IoT系统中应该如何设计设备的ID？

3.5.2 IoT设备ID的一种高风险设计方式

本节我们不回答上一节提出的问题，我们来了解一种场景的设备ID的设计方式，一种高风险的设计方式。

根据上一节的表格我们可以看出在很多环节需要基于ID来工作，那么一种非常自然的设计思路就是设备的ID应该在设备制造之初就确定下来，所有环节都以此ID作为设备的唯一ID，一处生产到处使用，理论上挺完美的，现实中却隐藏着风险。

图3.5.2.1：ID的应用领域

如上图设备制造时设定的ID是用来标识设备的物理身份，标签上的ID是为了方便人工识别物理设备的ID，涉及设备物理ID的应用领域包括，设备售后，设备销毁等物理设备处置环节。物联网是虚拟的网络空间，如果直接使用设备的物理ID使用系统的角度来说一开始的确是方便了一些，比较不需要物联网平台来管理设备ID的事情了，并且通过一个ID打通了物理世界和物联网虚拟世界。

说到这里这种设计的风险在哪里？如果设备ID在生产制造的流程中出现了重复的号码，在物联网系统中就可能会出现A用户控制或者访问B用户的设备。

3.5.3 ID应该如何设计

综上所述ID的设计除了ID本身的一些要求（传统的ID设计要求，如容量空间，无特指性，等）外，在IoT领域需要实现不同领域之间的ID的隔离。可以隔离的领域需要实现自封闭的ID管理，每个外部实体进入该领域需要完成注册（分配ID），注销（撤销ID）的ID生命周期管理的过程。不同领域之间的ID使用映射关系来关联，而不是委托管理。

物联网系统需要实现自封闭的ID管理，不论设备本身是否有可以识别的ID，都需要通过物联网系统自身的ID管理来管理。当然这样的要求是需要IoT设备配合的，如果IoT设备无法保证稳定的记录有物联网平台下发的ID，那么这个要求可能就无法满足。这种场景通常发生在设备制造商起家，然后自建物理网平台的情况中。因为制造商可以控制设备制造的过程，也就是产线已经实现了对设备ID的管理，当公司在建设物联网平台的时候自然会想到以来现有的功能，因为之前一直是这样做的。还有一个原因就是IoT设备的flash写入的次数是有限的，导致设备生产部门不希望外部系统包括云平台写数据到自建的flash，他们会要求平台认可接受来自于设备的ID。这样的要求下，物联网平台就与产生的ID管理系统需要进行数据通信，同样产线的错误就会传染到物理网平台。

如果一开始就是做物联网平台的公司是不会遇到此类问题的，因为他们首先会碰到的问题就是不同的厂商的ID可能会冲突，所以ID一定要平台来管理，对于要接入平台的设备制造商而已这是一个不可以谈的准入要求。

3.5.4 物理ID出错的场景有哪些

IoT设备的物理ID通常在两个物理位置体现，一个是系统烧录的ID，另一个是印刷到表现上的ID信息，这两个信息可以是一致的也可以是不一致的，不一致的情况通常通过一个映射关系来维护设备和标签的对应关系。不论哪种方式设备制造商必须实现设备烧录的ID和标签上的ID的一一映射关系，目前的工艺情况下标签和设备的关联需要诸多的人工参与的操作这就会导致如下的错误矩阵。

由于设备生产时流水线的方式，烧录ID和标签ID的错误通常不是指ID本身的错误，而是流水线上的错位，也就是说只要发生错误至少是两台，当然可能出现多台设备使用相同的ID，最为灾难的就是引起整个流水线上产品的错位。

下接：安全架构师的政治工作