1.3　经典原则

信息安全的指导原则可以追溯到计算机行业早期，彼时计算机还保存在上锁的机房里，房间中还安装着高架地板和空调，这些计算机也才刚刚开始连接到网络当中。这些传统信息安全原则简直就是当代信息安全领域的“经典物理学”：很多应用适用这些信息安全模型，但并不是所有应用都适用，新开发的应用尤其不适合这些传统模型。譬如在现代数据保护方面，人们对信息机密性那些巨细靡遗的思考和处理，在传统信息安全原则中就难觅踪迹。

基本原则可以轻而易举地分为两组，每组三项原则。第一组的三项原则可以称为CIA原则，这三项原则定义了访问数据的要求；第二组的三项原则关注的则是如何控制和监测数据访问，我们称之为黄金标准（gold standard）。这两套原则相互依存，它们只有作为一个整体时才能有效地保护数据资产。

除了防止未经授权的数据访问，还有一个问题是哪些组件和系统有权发起访问。这是一个更加复杂的信任问题，它的复杂程度已经超出了信息安全的范围。不过，为了保护数字系统，人们无法回避这个问题。

1.3.1　信息安全的CIA

传统上，软件安全都构建在信息安全的三大基本原则之上，即机密性（confidentiality）、完整性（integrity）和可用性（availability）。围绕着数据保护的基本概念，这三大基本原则的意义其实都很直观。

机密性：不会泄露信息——只允许已授权的数据访问。

完整性：准确维护数据——不允许未经授权的数据修改或者删除。

可用性：保障数据的可用性——不允许出现严重延迟或者未经授权的数据访问关闭。

这些简单的定义都对它们的目标和防御措施进行了描述。在审视设计方案时，我们应该考虑有哪些破坏信息安全的可能因素，同时考虑如何采取对应的防御措施。

CIA的三大组成部分代表的都是理想模型，而人们一定要避免在安全问题上追求完美。比如，即使是那些经过了可靠加密的网络流量，只要窃听者下定决心，那么他/她也能从这些流量中得出一些信息，比如双方交换的数据量。从技术上看，端点之间的数据交换本身就会削弱交互的机密性。但是从实用角度上讲，除非我们采取极端措施，否则这个问题无法解决，同时这个风险又实在太小，小到忽略它也不会对安全构成影响（隐藏通信数据量的一种方法是让端点始终交换恒定数量的数据。在实际流量较低的时候，则让端点发送虚拟数据包（dummy packet）来维持恒定的数据量）。哪些行为和数据量息息相关，攻击者又会如何对这些信息加以利用？本书第2章会具体解释类似的威胁评估方法。

读者也许已经注意到：授权是CIA各项原则中都固有的元素，它规定数据只能由合法的人员进行访问、修改，数据可用性也只能交由合法人员进行管理。界定哪些行为“合法”非常重要，而授权策略恰恰就是为此而生的，但授权策略并不包含在这些基本的数据保护概念中。授权策略相关内容会在后文的“黄金标准”部分进行探讨。

1．机密性

维护机密性意味着按照一种仅授权者可读的方式来保护隐私信息。这听起来很容易，但是实践起来就涉及很多复杂的问题。

首先，我们必须认真判断哪些信息属于隐私信息，这一点十分重要。设计文档应该明确地对此加以区分。虽然乍看之下，哪些信息属于敏感信息显而易见，但是人们在这方面的看法常常大相径庭，因此如果没有明确的标准就会导致误解。最安全的做法是把所有从外部收集到的信息都默认为隐私信息，直到有明确的策略来进行界定，并且解释清楚为什么可以对这样的设计方法进行适度的松绑。

下面是把数据视为隐私数据的一些原因，这些原因常常为人们所忽视。

● 一位终端用户可能会理所当然地希望他们的数据是隐私数据（即使这些信息被泄露也无伤大雅），除非他们明确告知某些数据并非隐私。

● 人们可能会把敏感数据输入不同用途的文本字段中。

● 信息的收集、处理和保存有可能需要满足各类法律法规的要求，而很多人往往对这些法律法规一无所知（如果欧洲用户访问你的站点，这次访问行为可能就需要符合欧盟的法律法规，例如《通用数据保护条例》）。

在处理隐私信息的时候，我们应该判断哪些访问属于合理的访问行为。判断人们何时、通过何种方式披露隐私信息就属于信任决策范畴。我们不仅应该明确说出访问规则，还应该解释这些规则背后的主观判断。

机密性泄露也有一个频谱。完全的信息泄露是指攻击者获取到了完整的数据集，其中包括元数据。这个频谱的另一端则是程度相当轻微的信息泄露，比如内部错误消息或者其他不会造成什么后果的信息被泄露了出去。以部分信息泄露为例，我们可以设想一下给新的客户分配序列号：心怀不轨的友商可以不断注册新客户，从而获取客户的序列号，然后计算这些客户编号的数值差来判断各个时间段内企业的新客户数量。所有泄露受保护数据详情的行为，在某种程度上都属于机密性遭到破坏的情形。

人们经常对那些看似无关痛痒的信息泄露付之一笑。然而，攻击者利用信息的方式很有可能与开发人员的初衷大相径庭。不仅如此，攻击者也可以把多个信息片段组合起来，从而获得远比其中任何只言片语多得多的内容。仅仅获取某个人的地址邮编或许用处不大，但是如果你还知道对方大致的年龄，同时也知道对方是一位医学博士，你就可以把这些信息组合起来，在一个人口密度不高的区域中定位到这个人的位置。这个过程如今称为去匿名化（denonymization）或者重标识（reidentification）。研究人员通过分析一个貌似由网飞公司发布的匿名数据集，就能在大量用户账户与IMDB账户之间建立匹配关系。这说明了一个道理：你钟爱的那些电影就足以出卖你的个人身份。

2．完整性

在信息安全这个语境里，完整性就是指数据的真实性和准确性，其宗旨是防止数据被随意删改。除了通过技术手段防止数据遭到未经授权的篡改，一份准确的数据来源记录（包括最初数据源，以及之后授权的数据源变更）也是相当重要、强大的完整性保障。

保存重要数据的版本并且记录它们的来源，这本身就是防止篡改攻击的典型手段。这说起来十分简单，就是保留一份良好的备份数据。执行增量备份是一种理想的攻击预防手段，因为增量数据保存简单，同时又以一系列快照的形式翔实地记录了哪些数据执行过变更，以及它们在何时执行过变更。不过，完整性的需求不只是保护数据这么简单，它还包括确保组件、服务器日志、软件源代码与版本，以及其他取证信息的完整性。这些取证信息可以在问题真的发生时，帮助我们判断并找出遭到篡改之前的原始信息源。除了限制管理访问之外，安全摘要（类似于校验和）和数字签名都可以用来执行强有力的完整性校验，这些内容会在本书第5章进行介绍。

读者应当切记，篡改包括很多不同的方式，并不一定是修改存储设备当中的数据。比如在Web应用中，篡改可能发生在客户端一侧，也可能发生在客户端和服务器之间；手段包括欺骗其中某一方修改数据，也包括在页面上修改脚本，等等。

3．可用性

针对可用性的攻击是网络世界无法回避的现实问题，也是最难防御的攻击方式之一。这类攻击最简单的形式是攻击者向服务器发送过量的数据，通过看似合法的手段占用海量服务资源，导致服务资源耗竭。这表明信息会偶尔不可用。虽然永久丢失的数据也属于不可用的数据，但是这类数据一般会被认为属于完整性受到彻底破坏的情况。

匿名的拒绝服务（Denial of Service，DoS）攻击（一般都是为了索取赎金）几乎可以威胁到一切互联网服务，所以防御这类攻击是非常艰巨的挑战。为了更好地防御这类攻击，我们需要利用有能力承受大量负载的基础设施来承载大规模的服务，同时维护系统的灵活性，确保在事件发生时基础设施能够迅速实现迁移。谁也不知道DoS攻击的频率和成本，因为很多受害者都是自行解决问题的。但毫无疑问的是，我们应该提前制定好详细的计划，为应对这类情况做好准备。

很多其他类型的可用性威胁的原理与此类似。对于一台Web服务器来说，攻击者创建的恶意请求可以触发错误，导致崩溃或者无限循环，最终破坏服务器的服务。此外，其他的攻击方式可以导致应用的存储、计算或者通信出现超载，或者使用破坏缓存有效性的模式，这些都可以导致相当严重的问题。对软件、配置或者数据进行未经授权的破坏都可能对可用性产生负面的影响（甚至对备份数据进行破坏，也有可能导致延迟）。

1.3.2　黄金标准

如果CIA是安全系统的目标，那么黄金标准描述的就是达到这个目标的方式。在拉丁语中，Aurum是黄金的意思，因此黄金的化学符号就是Au，碰巧信息安全的重要原则也都是以这两个字母作为首字母的。

● 认证（authentication）：用高度可靠的方式来判断主体的身份。

● 授权（authorization）：仅允许通过认证的主体执行操作。

● 审计（auditing）：为主体所执行的操作维护一份可靠的记录，以便进行监控。

提示：这几个单词不仅长，而且长得差不多，读者可能会遇到一些简写，即用authN代指认证、用authZ代指授权。这样可以通过一种简短的方式来清晰地区分这些术语。

所谓主体是指一切通过了可靠认证的实体，包括一个人、一家企业或单位、一个政府实体，以及一个应用、服务、设备或者其他有权执行操作的对象。

认证的过程，是指通过可靠的方式来建立主体证书可靠性的过程。系统往往会要求用户证明自己了解用户账户所对应的密码，以此为注册用户执行认证。不过，认证的概念也可以更加宽泛。证书包括主体了解之事（如密码）、所有之物（如令牌）或者主体自身的属性（如生物数据）。在后文中，我们会详细对证书进行探讨。

认证后的主体在执行数据访问时，也会受到授权结果的限制。授权会根据预先设定的规则允许或拒绝用户的行为。例如，设置了访问控制规则的文件系统可能会针对某些用户把一部分文件设置为只读。这就像在一家银行中，柜员可能会把达到某个额度的交易记录下来，但是如果额度过大，这次交易就需要得到经理的批准。

如果一项服务保留了一个安全日志，而这个日志可以准确地记录主体执行的操作（包括那些因为授权失败而没有成功执行的操作），那么接下来管理员可以执行审计来对系统的操作进行监控，确保所有操作都是合理的。如果希望实现强大的安全性，准确的审计日志至关重要，因为它们提供了对真实事件的可靠记录。详细的日志可以为我们提供一份历史记录，揭示发生异常情况或者可疑事件时的准确情况。如果读者发现某份重要的文件不见了，那么日志在理想情况下应该对此提供各类详细信息，包括谁删除了这份文件、何时删除了这份文件等，以便技术人员以这份日志为依据，对此事进行深入调查。

黄金标准充当的是一种实现机制，旨在对CIA提供保护。本书此前把机密性和完整性定义为防止未经授权地泄露或篡改信息的行为原则，而可用性则会受到授权管理员的控制。真正兑现授权决策的唯一方法，是确保使用系统的主体都是正常通过认证的主体。审计则负责提供可靠的日志，记录谁、何时执行了什么操作，再由技术人员定期审查违规行为，并保留追究违规者责任的权利。

安全设计方案应该明确地把认证和授权这两者分开，因为把认证和授权结合在一起往往会导致混乱。如果能够把两者明确地分开，审计追踪工作也会变得更加清晰。我们通过下面两个现实生活中的例子，解释为什么认证和授权应该分开。

● “你为什么把那个家伙放进保险库？”“我也不知道，但是他一看就是合法人员啊。”

● “你为什么把那个家伙放进保险库？”“他的ID卡上写着Sam Smith，他还拿着支行经理手写的纸条。”

第二种答复比第一种明显要更加完整，因为第一种答复基本上一文不值，只能证明安保人员没动脑子。即使保险库被人入侵了，第二种答复可以提供详细的信息以供人们进行调查：支行经理有权限放某人进入保险库吗？那个纸条是支行经理写的吗？如果安保人员保留了ID卡的复印件，这份复印件也可以帮助人们找到Sam Smith。如果支行经理写的纸条上只是显示“让持条者进入保险库”（相当于仅做了授权，没有做认证），调查人员就很难弄清楚发生的情况，也很难调查出入侵者的真实身份。

1．认证

认证的目的是，根据能够证明主体真实身份的证书，测试该主体的真实身份与其所声称的身份是否一致。认证服务也可能会使用一种更强形式的证书，譬如数字签名或者挑战码。这些证书的形式可以证明主体拥有与其身份相关联的私钥，浏览器就是这样通过HTTPS来认证Web服务器的。数字签名是一种更加理想的认证形式，因为数字签名可以让主体在不泄露密码的情况下证明自己掌握密钥。

证书提供的认证信息包括下面这几类。

● 所知之事（something you know）：如密码。

● 所有之物（something you have）：如安全令牌。在虚拟世界中，所有之物也包括某种类型的证书、密码或者签名文档，这些信息必须是无法伪造的。

● 自身属性（something you are）：即生物特征（如指纹、虹膜等）。

● 所处之地（somewhere you are）：经过验证的所在地，如与安全场所中私有网络建立的连接。

在这些认证方法中，有很多方法都是相当简单的。你的所知之事可能泄露，你的所有之物可能失窃，你的所处之地有很多方法可以加以操纵，就连你的自身属性都有可能被伪造（甚至如果遭到盗用，我们连修改都很困难）。在当今网络世界，认证基本上已经在网络中得到了普及，认证行为几乎每时每刻都在发生，甚至有时认证这项任务比现实世界中的身份认证都要复杂。例如，在网络中，浏览器会充当信任代理的主体。浏览器会首先在本地执行认证，并且浏览器只有在认证成功的前提下才会把加密的证书发送给服务器。系统通常会使用多个认证要素来避免认证信息遭到盗用的问题，同时频繁地进行审计也是认证的一大重要后盾。用户使用两项认证要素总比使用一项认证要素要好（但也好不了太多）。

不过，当人们加入一家公司、建立自己的账户，或者在忘记密码后请技术支持团队恢复自己的访问时，组织机构必须能够判断人员的真实身份，才能为他们分配证件。

比如，在我入职谷歌公司的时候，所有新员工在周一上午集合，我们对面是几位IT管理员。他们按照新员工名册一一检查了我们的护照或者其他身份证件。检查无误之后，他们才发给我们工牌和公司的笔记本电脑，并让我们设置自己的登录密码。

IT团队检查我们的证书（也就是我们的身份证件等），就是为了判断我们提供的材料是否能够准确无误地证明我们的身份。这份证书所提供的安全性取决于很多因素，包括官方证件及其支持文件（如出生证明）的完整性和准确性、伪造这些证件的难度、非法获得这些证件的难度等。在理想的情况下，一份从出生时注册身份一直更新至今的信息链，应该在我们的一生中都能够保存完整，这样才能唯一地标识我们的身份信息。安全地标识一个人的身份的难度很高。因此，为了保留一些隐私和自由，人们宁愿在日常生活中选择不那么严格的措施。本书的重点并不是如何鉴别一个人的身份，而是前文刚刚提到的黄金标准。身份管理这个更加复杂的问题这里不赘述。

只要条件允许，我们就应该依靠现成、可靠的认证服务，而不应该动辄“自力更生”。哪怕是简单的密码认证也很难安全地落实。如何安全处理自己已经忘掉的密码更是一个麻烦的问题。一般来说，认证的过程应该包括对证书进行校验，并给出认证通过或者认证失败的响应消息。不要采用认证“部分成功”的做法，这样等于在暗示黑客可通过不断试错来破解密码。如果希望降低暴力破解密码的风险，常见的做法是让认证密码从根本上很难通过计算破解，或者在认证流程中引入一些延迟（详见本书第4章介绍的“避免可预测性”）。

在对用户进行认证之后，系统必须找到一种方式来安全地绑定主体身份。一般来说，认证模块会给主体颁发一个令牌，主体在认证中使用令牌即可，这样就可以避免后续被要求执行完整的认证过程。这里的关键在于，主体可以借助代理（如浏览器），直接把认证令牌作为一种证明自己身份的信物，为未来的身份认证请求提供一种安全的方式。这种方式会代表认证主体来绑定存储的令牌，在未来收到请求的时候提供令牌即可。网站往往会通过浏览会话所关联的安全Cookie来达到这个目的。不过，针对其他主体和界面，也有很多不同的方法。

安全绑定认证实体后可以用两种基本方式进行入侵。第一种方式显而易见，那就是攻击者可以盗用受害者的身份。此外，接受认证的主体也有可能与其他人相勾结，把自己的身份信息泄露给别人，甚至把自己的身份强加给别人。几个人分享同一个付费订阅的节目就属于这种入侵方式。网站对这种方式基本上无能为力，因为主体和令牌之间的绑定关系本来就是比较松散的，何况这种关系还取决于主体自己是否愿意合作。

2．授权

到底应该允许还是应该拒绝重要的操作行为？这类问题应该根据主体在认证时确立的身份来决定。各类系统会通过业务逻辑、访问控制列表或者其他正式的访问策略来实现授权功能。

匿名授权（即不进行认证的授权）适用的场合可以说寥寥无几。在现实生活中，匿名授权相当于拿着车站公共储物柜的钥匙存取个人物品。根据时间设置访问限制（比如，仅允许员工在工作时间访问数据库）也是匿名授权的一个示例。

针对一项资源，应该通过一项单一的要素来实施授权，不要让授权代码散布在整个代码库中，否则这会是运维和审计人员的一场噩梦。因此，应该依靠某一项公共框架来唯一地提供访问授权。精良的设计方案可以帮助开发人员正确地处理系统。总之，无论何时何地，都建议从众多标准的授权模型中选择其一，而不是使用混搭的方案。

基于角色的访问控制（Role-based Access Control，RBAC）可以在认证和授权之间建立起一座桥梁。RBAC会根据分配给认证主体的角色（role）来提供访问授权，这样就可以通过统一的框架简化访问控制。比如一家银行，柜员、经理、贷款专员、保安、财务审计师和IT管理员等占了一半的角色。RBAC并不会为每个人单独定义访问权限，而会根据每个人的职责指定一个或者多个角色，从而为人们自动分配相关联的唯一权限。在更高级的RBAC模型中，一个人可以拥有多个角色，人们可以为不同的访问主动选择使用不同的角色。

授权机制远比传统操作系统提供的简单读/写访问控制要细致得多。人们可以设计更加强大的授权机制，以便在不损失重要功能的前提下对访问进行限制，提升安全性。这些更高级的授权模型包括基于属性的访问控制（Attribute-based Access Control，ABAC）、基于策略的访问控制（Policy-based Access Control，PBAC）等。

读者想想银行柜员的例子，就可以发现对授权进行精细化可以达到收紧策略的目的。

限速：一位柜员每小时可能最多处理20笔交易。如果超出了这个数量，这些交易就很可疑了。

每日时间：交易必须在工作时间内完成。

不服务自己：禁止柜员用他们的个人账户进行交易。

多个主体：超过10000美元的交易需要经理批准（以此消除一个坏人一次性就可以转走大量资金的风险）。

最后，对于某些数据来说，只读访问的访问级别依然过高，密码就属于这类数据。系统往往会通过比较明文密码的摘要的方式来校验密码，以免泄露明文密码。用户名和密码都会被发送给一台前端服务器，由前端服务器计算密码的摘要值，然后把摘要值发送给认证服务，同时迅速摧毁这个明文密码的一切痕迹。认证服务无法从证书数据库中读取明文密码，但是它可以读取摘要值，它会用这个值来与前端服务器提供的值进行比较。通过这种方式，认证服务就可以对证书进行校验了，但认证服务永远无法访问任何密码。因此，即使认证服务遭到入侵，也不会导致密码被泄露出去。除非界面设计能够提供这类安全方案，否则它们会失去这样一个减少数据泄露可能性的机会。本书会在4.2.2节进一步探讨这个话题。

3．审计

为了让组织机构能够对系统的行为进行审计，系统必须基于所有对运维安全至关重要的信息生成一份可靠的日志。日志中包括认证和授权事件、系统启动与关闭、软件更新、管理访问等。审计日志也同样必须能够抗篡改。在理想情况下，最好是连管理员也无法插手修改这些日志，这样可以将其视为绝对可靠的记录信息。审计是黄金标准中的一个重要环节，因为网络中总是会发生这样或那样的事件，认证和授权策略的漏洞也总是难免的。审计可以自始至终为人们提供必要的信息。在工作中，当授权主体做出与人们信任相悖的行为时，审计信息可以帮助人们规避由此带来的风险。

如果处理得当，审计日志可以为日常检测、系统性能级别评测、错误和可疑行为检测带来巨大帮助，也可以在事件发生后用于判断攻击实际发生的时间和评估攻击带来的损失。切记，要想对一个数字系统进行彻底的保护，不仅要正确地实施策略，还要成为一位负责任的信息资产管家。审计可以确保可靠的、通过了认证的主体在自己的权限范围内采取的操作都是合理的。

在2018年5月，推特[1]公布了一个让人尴尬的bug：他们发现在不经意地修改了一段代码之后，原始登录密码就直接显示在他们的内部日志当中。虽然这件事导致密码遭到滥用的可能性不高，但是它会打击用户的信心，因此绝对不应该发生。日志应该记录操作的细节，但是不存储任何实际的隐私信息，这样才能把信息泄露的可能性降到最低，毕竟技术人员中有很多人日常就会查看这些日志。关于如何满足这样的需求，本书附录A中的设计文档示例详细列出了满足标准的日志记录工具。

---

[1]　已更名为“X”。

系统也必须有能力阻止人们通过篡改日志来掩饰那些恶意的操作，如果攻击者有能力修改日志，他们当然会把自己的操作痕迹清除得干干净净。对于那些特别敏感的高风险日志，应该由不同管理和操作团队负责的独立系统来管理其审计日志，以防内部肇事者掩盖自己的操作痕迹。虽然做不到尽善尽美，但是独立系统的存在本身就会对那些“耐人寻味”的业务产生强大的抑制作用，这就像一排高度有限的栅栏和一处位置显眼的视频监控摄像头就可以有效地防御入侵一样。

此外，任何尝试规避独立系统的行为都会显得相当可疑，每一项错误的操作都会给攻击者造成严重的影响。一旦被发现，他们也很难对自己的罪行进行抵赖。

不可抵赖性（non-repudiability）是审计日志的一项重要的属性。如果日志显示，一位有名有姓的管理员在某个时间点允许了一条命令，之后系统立刻就崩溃了，那么这次系统崩溃的责任就很难推卸给别人。反之，如果一家单位让多名管理员分享同一个账户（千万不要这样做），这家单位就无法判断谁执行了哪些操作，每个人也就都有了抵赖的口实。

最后，审计日志只有在人们监控日志内容时才能发挥作用，因此务必认真地分析那些异常事件，然后不断跟进，并且在必要情况下采取合理的行动。为了达到这样的目的，我们应该遵循Goldilocks原则，即日志记录的数量和规模应当适宜。一方面，日志数量过大就会让人们更容易忽视日志的内容，毕竟人们很难从大量嘈杂无序的日志中提取出有用的信息。另一方面，缺少细节的日志则有可能遗漏关键的信息。因此，找到一个合理的平衡点会是一项长期且艰巨的任务。

1.3.3　隐私

除了信息安全的基础（即CIA和黄金标准）之外，本书要介绍的另一基本话题与信息隐私这个领域有关。安全和隐私的边界很难清晰地界定，它们既紧密相关又大不相同。在本书中，我会把重点放在它们的共同点上，但也不会去统一这两个概念，而是把安全和隐私都包含在构建软件的流程这个话题中。

为了尊重人们的数字信息隐私，我们必须考虑其他人为因素，对机密性原则进行扩展。这些因素包括：

● 客户希望人们采用的信息收集与使用方式；

● 明确界定如何合理使用和披露信息的策略；

● 与收集和使用各类信息相关的法律法规；

● 与处理个人信息有关的政治、文化和心理等因素。

随着软件在人们生活中所扮演的角色愈发重要，人们和软件之间的联系也变得越来越紧密。软件开始涉足人们生活的敏感领域，这就催生了很多复杂的问题。过去发生的那些信息事故和滥用导致的事故让人们越来越清醒地认识到其中存在的风险。随着社会开始通过法律的方式来应对这些新的挑战，妥善处理个人信息的难度也水涨船高。

在软件安全领域，人们对从业者提出了下列要求：

● 要考虑到收集和共享数据会给客户和相关人员带来哪些影响；

● 要把可能的问题都标记下来，并且在必要的时候请教相关专家；

● 应该针对隐私信息的使用方式建立明确的策略和指导方针并严格遵守；

● 要把这些策略和指导方针转化成强制执行的软件代码；

● 要维护一份准确的记录，包括获取、使用、共享和删除数据的历史信息；

● 对数据访问授权和特殊访问行为进行审计，确保这些行为符合安全策略。

如果说对系统控制进行维护、为人们提供合法访问是一份既简单又枯燥的安全工作，那么涉及隐私信息的工作就很难找到一个合适的字眼来形容了。随着社会开始通过收集数据来深入探索人们的未来，我们仍然坚定捍卫人们维护自己隐私的愿望，并且制定保障人们隐私的规范。保护隐私殊非易事，明智的做法是让使用数据的行为尽可能透明。这就包括让所有人都能轻而易举地读懂我们的策略、收集尽可能少的数据，尤其是涉及个人身份的数据信息。

收集信息必须拥有明确的目标，保留信息必须保证信息确有价值。除非设计方案中就规划好了合规的用法，否则应该避免提前收集这样的信息。不要因为信息“将来有可能用到”就随随便便收集，这样做的风险很高，绝不是什么好做法。如果未来合法使用某些数据的必要性不高，最合理的做法就是安全地删除这些数据。针对那些特别敏感的数据，或者为了实现最大程度的隐私保护，我们应该采用直截了当的手段：只要数据泄露的风险超过了保留这些数据的益处，我们就应该删除这些数据。有时候，保留几年前的电子邮件确实比较方便，但是这种做法恐怕难以满足任何清晰的商业需求。反之，内部电子邮件如果通过某种方式泄露了出去，有人就可能需要为此承担责任。所以，最好的策略往往就是删除这样的邮件，而不是想着“说不定哪天用得到”，于是就一直保留着所有的数据。

处理信息隐私的完整流程超出了本书的范畴，但是对任何系统（只要这个系统的目的是收集人们的数据）的设计来说，隐私和安全性都是两个紧密相关的属性。毕竟，人是操作几乎所有数字系统的主体，虽然操作的方式不一而足。采用强大的隐私保护方式是建立强大安全性的必经之路，所以本章的目标就是唤起人们的意识，即把保护隐私融入软件的设计之中。

虽然保护隐私是一个复杂的问题，但是解决隐私问题的一大最佳实践却是人尽皆知的：人们必须明确表达出自己对隐私问题的关注。隐私策略和安全性不同，隐私策略能够在一定程度上权衡信息服务会在多大程度上利用客户的数据。“我们会反复使用你们的数据，还会把这些数据卖给别人”，这当然是隐私保护的一个极端，但“早晚有一天我们不会再给你们的数据提供保护”也称不上是合理的安全立场。当用户的期望和实际的隐私策略相脱节时，或者当用户违反了明确的安全策略时，隐私问题就会暴露出来。用户的期望和隐私策略脱节是因为安全人员没有向用户主动解释他们处理数据的方式。用户违反安全策略则是因为安全策略仍然不够清晰，或者负责人对其熟视无睹，又或者这些安全策略在一场安全事故中遭到了破坏。

提示：本书附录D包含CIA和黄金标准的汇总表格，以兹读者参考。