防止系统支离破碎的安全构架

防止系统支离破碎的安全构架

原著 佐藤庆浩（日本HP） 翻译 东北藏

IT构架师的安全定位

IT设计的时候安全性问题应该站在构架的高度来考虑的吧。没有单纯模仿一般的安全技术，与系统的业务要求没有达成完美融合或更有甚者项目后期才考虑安全问题吧？

IT构架师是负责IT体系构建的。IT构架师的不适当设计往往造成系统支离破碎，漏洞百出，安全薄弱部分的暴露导致了安全性的低下。除了这部分的不足，也有太偏重别的部分造成大量冗余的情况。设计不当，系统各部分失去平衡，完成的系统从整体上很难把握。防止这种系统的漏洞和没必要的冗余就是IT构架师的职责。系统设计，IT构架师除了考虑设计的整体性，安全性上也是必不可少的。

尽管如此，客户对安全上的要求没有明确的规格，所以就没有考虑相关的费用。这样，担心过安全问题的人在实际的构架上没有充分考虑安全问题的情况很多吧。

最近信息安全问题作为社会问题被提上了日程，同时也迎来了攻克安全性技术的最佳时期。反之，即便有了客户重视安全问题的这个好时机不学习的话，就失去了学习技术的好机会。所以要成为IT构架师的人从安全的角度进行的系统设计是认识构架重要性的具体学习课题。涉及异常处理的安全领域是能体现IT构架师能力和经验差别的领域。

从SLA的安全定位

注重安全性的IT构架可以从“基础”“信赖性”“控制机构”三个部分来考虑问题（下图）。

三个基本部分（系统技术，系统运用及管理）

从整体上涉及“基础”“信赖性”“控制机构”三个部分，本文对系统开发者关系较大的信赖性部分作详细说明。

※注 其它部分请参考，http://yosihiro.com/go/security-architecture。

信赖性必须考虑的就是“安心使用IT”的事情，可以从三个关键词考虑，性能，可用性和安全（下图）。性能就是在期望的应答时间内得到处理结果能力，可用性指服务停止时间能控制在期望时间内等。这些在开发现场客户通常作为SLA（Service/Level/Agreement）而提及。

系统开发者关系紧密的信赖性部分的思考方法

关于安全很多情况下并没有被明确，可能仅仅停留在“充分考虑安全对策的实施”这样的描述上。但是IT除了功能上的实现，在强调服务的重要性的同时安全问题也备受关心。正因如此，SLA也包含了安全的含义。

就来整理一下安全和其它课题的特点吧。SLA本来包括了很多要素，这里着重性能及可用性与安全的差别。

性能和可用性

安全

・达到的等级易于定量

・达到的等级难于定量

・客户易于阐明达到的等级目标

・客户难于阐明达到的等级目标

・等级的提高可以通过硬件的性能扩展来达到的情况多

・等级的提高不是通过扩展性而是通过功能追加的情况多

・等级的提高与功能服务的提高关联性大

・等级的提高与功能服务的提高关联性小

性能和可用性可通过设定处理件数或停止时间等量化尺度为目标，容易测量达成度，而安全达成度的定量化比较困难。

由于需求难以定量，很难表明客户的服务级别。也只能是“充分采取安全对策”吧。但近期对信息安全的重视，这已经不能满足要求了。客户并没有足够的知识，所以客户应该是给出提案，IT构架师应具有在满足功能的基础上理解并整理业务服务安全需求的能力。

性能和可用性的提高虽然离不开软件的设计，但软件的设计手法通常比较成熟，要是按照这些设计理论，性能和可用性的提高就主要依赖硬件的扩展性能了。当初的目标即使日后有改动，由硬件构成的改变也是很容易对应的。相比之下，安全在很大程度上依赖IT构架，系统设计时的疏忽往往造成不能满足安全需求的可能，一般来说建立体系的构架是非常必要的。

今年除了瀑布型软件开发方法，也出现了RAP（Rapid Application Prototype）和RAD（Rapid Application Development）等螺旋型手法。开发手法的改善伴随着性能和可用性上IT功能和业务服务的提高，开发过程中这一切都可以得到积极的反馈。但从性能，可用性或其他便利性及管理性的角度，有时安全的提高并非只带来积极的一面。初期的设计作的不充分的话往往到后来影响到服务的级别。

从以上可以看出，安全问题的解决离不开构造的体系化的设计，这就体现了IT构架师的价值。

安全需求的5A

安全需求分析体系话的方法可以从不同的侧面考虑，这里介绍5A方法。

・Authentication：权限确认（确认本人的正当性）

・Access Control：访问控制（事先许可的访问控制）

・Administration：权限管理（管理上述的2A）

・Auditing：监查（上述3A的记录等的管理）

・Assurance：保证（确保满足上述4A需求）

※注 笔者的观点是，5A中的前3A是一般项。但是跟本文说法相同的有（1）Authentication、（2）Access Control、（3）Authorization及（1）Authentication、（2）Authorization、（3）Administration两种说法。Authorization在不同场合的出现很容易造成误解，文本的解说不使用Authorization。

以下对5A进行说明。

权限确认（Authentication）

第一个的权限确认，就是对访问系统的人通过识别（identification）名字确定是否是本人。

注：Authentication 的日语翻译使用“认证”的较多。但认证是要证明什么的人和出示证明的人通过第三者确认证明的正当性满足两者的要求。认证要有第三者为前提，Authentication则无需第三者。实际上，担任这个作用的Certification Authority的翻译是“认证局”。为了避免和认证局的混淆，文本将Authentication表示为“权限确认”。

权限确认的实现可能的技术包括三个：知识确认（对只有本人知道的信息的确认：密码等），所有确认（对只有本人持有的物品的确认：磁卡等），人身特征确认（对只有本人拥有的身体特征的确认：指纹，声音，笔迹等）。

权限确认的强度，可通过提高各要素的严密性或各要素的组合来决定。IC卡的认证具有知识确认和所有确认的两种组合，两种要素的确认方式从技术的观点，一般认为具有了较高的确认强度。

正当的本人以外的人进行识别（ID等）时，将被认可或被视为“诈称”。要防止这些问题就必须采取充分的对策。

密码的再次设定或发行IC卡的时候，这样必须事先确立本人正当性的确认方法。

服务器端必须充分考虑本人确认信息的操作。若将这些秘密信息保存在服务器就增加了风险。因为一旦服务器遭到攻击，通过获取控制权，可能盗走本人确认信息。要解决这些问题，要使用PKI（Public Key Infrastructure：公共密钥基础设施）等技术。由此，并非只是服务器权限确认信息的保存，而是可以进行确认。系统使用PKI的意义在于，服务器不保存秘密信息。

访问控制（Access Control）

第二个的访问控制，对经过了权限确认的用户确定其可以访问那些信息，同时控制访问。

一般非法访问包括无许可访问（Unauthorized access）和许可的乱用（Abuse of authorization）两种情况。这两种情况一并作为非法访问就难以理解问题的本质，有必要将这两种情况加以区分。无许可访问的对策主要是通过技术手段，避免没有许可的访问被系统许可。

许可乱用的对策在技术上很难实现，即很难对得到许可的用户控制他的访问许可范围。为什么呢，这有业务上的必要。因为给了他许可，控制他的权限的话就会产生业务问题。从技术角度作为许可乱用的对策之一是，最少特权功能。即许可的范围在可能的情况下进行限定，通过许可的细化达到精度的提高。比如虽然有权限访问某信息，而这种访问在夜间则没有必要，所以可以通过访问的时间带的限制提高许可范围精度。或者从某种倾向的把握来处理，异常访问（anomaly access）的控制和检查功能是很有效的。比如，某人通常一天的访问量为100次的话，突然访问量在1000次以上的话便视为异常访问对其进行控制或作出检查报告。

系统设计的时候，很有必要设计出能够实现这些功能的结构。由此，对许可乱用的情况除了技术手段，有必要实施制度对策。比如，惩罚或监视的强化等就是制度对策的例子。

除此之外还有许可的误用（misuse of authorization）的情况。许可的乱用通常含有恶意，而误用通常指误解或过失，是得到许可的用户引起的问题。许可误用的制度对策为，教育和训练。

权限管理（Administration）

第三个是权限管理，对权限确认的个人识别信息（ID等）和个人确认信息（密码等）的设定以及访问控制的许可信息的设定进行管理。

这里，保证权限确认信息的机密性（confidentiality）和访问控制信息的整体性（integrity）是对技术的最低要求，同时要考虑相应对策。

比如，安全的管理者所提倡的性善说不足以成为安全对策。只性善说是避免不了非法访问的。受保护信息的安全度不是很高且考虑到运用费用，也有冒着风险遵循性善说的做法。

回避这种风险虽然比较困难，访问控制里介绍的最小特权功能方式的利用可以减少风险。

除此之外有使用双重锁定功能的，双重锁定功能就是保证至少要两名操作者才能完成特定行为。即使使用双重锁定功能两名操作者要使同谋的话一样可以达到非法访问的目的。这虽然在技术上很难实现，却能保证只要不共谋就不能单独访问的效果。

下图是新注册用户登录时使用双重锁定功能的示意。这种简单的模型保证包括本人的单独登录非法。双重锁定功能一般在安全OS上使用，即使在应用程序中采用这种结构也可以达到强化安全性的作用。

安全OS的详细介绍请参考：http://yosihiro.com/go/secure-os

使用双重锁定功能的新增用户登录

通常不建议为管理设置管理用户ID。像UNIX的root用户，Windows的administrator用户。访问系统的所有用户应特定为个人。UNIX中一般用户登录后使用su命令成为特权用户也并非上策。管理者也不该有例外，理由的说明请见下一节的监查。

监查（Auditing）

第四个是监查，是管理权限确认，访问控制，权限管理记录等的技术。本文不解释监查的原理，只考察实现监查的技术。

通过彻底监查，所管理的权限确认，访问控制和权限管理的记录被作为监查记录。

监查记录的保管对一旦发生事故确定原因及访问用户很有必要。而且确保了访问系统（什么时候谁做了什么）的记录具有系统最大抑制非法访问的价值。

系统安全的强度也可以从确保系统监查记录的强度来考虑。

强度的增加可以考虑由安全OS强制访问控制进行的监查日志保护。没用利用强制访问控制的系统可以考虑将电子署名记录到文件来检知窜改，或通过将文件发送到别的远程系统来防止本地的窜改。

这也并非是防止的对策，通过确凿的证据达到“没有不透风的墙”的心理抑制效果。

监查记录作为确凿的东西迫使日后会暴露的人产生“还是不能做坏事呀”的想法。这些人一般并非是无许可用户而是许可乱用的用户，可以控制这样的用户。对许可乱用用户的抑制很难采取技术手段，而监查记录技术却可以做到这一点。这就是备受关注的被称为computer forensic（计算机法科学，计算机证据论，计算机犯罪调查论）的研究。

computer forensic请参照（http://www.cyberpolice.go.jp/）的安全解说第3回“computer forensic”。

将监查作为确凿的东西，权限确认和权限管理是很重要的。这两方面做得充分的话，监查证据的信赖性就低。信赖性低就没有很好的非法访问控制效果。监查证据的完整性由访问控制来。这么说来，4A之间有着密切的相互依赖关系。

从技术上即使安全侵害不可避免，对安全问题有比较好的抑制效果的话，从结果上还是能大大减少侵害的发生的。相反，没用这种抑制效果就很容易遭到攻击，是很危险的。

保证（Assurance）

第五个是保证，就是保证权限确认，访问控制，权限管理及监查按既定的基准动作。保证虽然基本上是制度或运用层面上的东西，系统相关基准有时作为可测（measurable）技术嵌入到系统。

被保证的系统在建立之前，基准一般就被确定了。然后按照基准进行设计，开发，运用，否则事后追加保证是非常困难的。

并且，应考虑到保证是很难做到绝对安全的。安全上的保证只能保证是否按既定的基准行事，很难保证覆盖全部基准。

虽然这点上不能满足绝对安全的需要，但是什么手段能得到绝对的安全呢。不作为绝对的保证本身，而从安全对策的实施状况测试的角度，保证具有继续改善的作用价值的高度来看问题。

开头部分也说了安全的定量化很困难，也有ISO/IEC 15408（JIS X 5070）这样的评价方法，但IT构架师的观点是，这些很不现实。

ISO/IEC 15408中有作为需求规格的PP（Protection Profile）的表述，但一般客户从这样的表述来表明安全需求还需要时间。但是虽然没取得认定，ISO/IEC 15408的PP及ST（Security Target）对安全需求的定量化很有价值，IT构架师理解这些内容还是大有裨益的。

若设计时考虑到以上5A，很易于整理出体系化的安全需求吧。

一致性管理（Identity Management）

5A的说明中第一个A的权限确认是一切的基础，这种重要性也作了介绍。权限确认不确定的话之后的各个A就不确定了。为此最近针对这个问题，出现了一致性管理的方法。

与以往不同的是，作为个人的本人特定处理成为了重点。换句话说，以往的系统只能考虑到某访问所使用的ID。所以只能从信息访问的日志中得到线索，比如，由分配给佐藤的ID登录，所以是“佐藤”的可能性比较大。从这个意义上看，很难严格确定这个人到底是谁。这个问题虽然很难彻底解决，例如，同一个ID从东京和大阪同时登录的话，很容易理解其中一个不是本人。这样按顺序解决问题以确认本人的技术就叫一致性管理。

如此说来，以往的方法只是单纯的ID管理（Identification Management）。如下图。

与以往不同的是，作为个人的本人特定处理成为了重点

一致性管理方法的确立需要有与以往不同的设计思考方式。例如，在刚才的例子中，本人在东京登录，别人从大阪也试图登录时，需要向双方警告这个事实。如果只是拒绝了来自大阪的登录，就只能告诉大阪的人别人正在登录中。如果与权限确认一致的话，来自大阪的登录也被承认，将此事实同时通知给在东京和大阪的双方。为什么也需要警告大阪的人呢。因为系统判断不了那个才是正当的。通过警告双方，告诉正当方权限确认正在被不正当的人使用，也告诉不正当的人这已被告知本人，应该做些什么。一致性管理观点的重要性在于，不威胁到权限确认的情况下，有至少告诉本人这种不确定情况的机会。

由此可见，一致性管理除了技术上的组成，郑重地通知系统用户本人，权限确认信息及装置需要妥善管理。

供给（Provisioning）

一旦权限确认得到有力保障，接下来的重要问题就是，权限确认设定等权限管理的安全问题。这个问题备受关注，被称作供给。英语单词Provisioning的意思是，持续不断地给要旅游的人在必要时候提供必要的资料。在信息系统领域给访问用户提供必要的识别信息（用户ID）和访问许可，这就是供给。供给处理不当，随后的权限确认即使使用再高级的技术也难以进行一致性管理。

这同时意味着有很多不容乐观的情况，“管理者要是滥用真没办法”。供给还有一个比较重要的方面，尽量减少管理者，减少不必要的人员的介入以防止人为的安全事故。这同时也降低了运用费用。但是最终也必须有人存在，只能靠双重锁定来对应这种情况。

一致性管理，访问控制及供给关联性很强，综合处理好这些技术能大大提高安全对策。正因为如此，最近结合这些技术提出了一致性访问管理（IAM：Identity & Access Management）的概念。

◇

以上5A主要是围绕信息的访问来介绍的。安全需求体系化的方法，不仅仅局限于本文介绍的分层构造。例如，信息通过应用处理，应用在服务器上运行，服务器通过网络与客户端PC相连，用户通过客户端PC来访问。像这样可以从空间的体系上考虑信息的处理，应用，服务器，网络，客户端PC与5A之间怎样的组合才是最佳对策呢。而且安全对策要想象会发生什么样的事故，考虑对这些事故的对策。比如，虽然对非法访问进行了保护，要检查这种保护是否被破坏了，根据检查结果采取对策。可考虑这种安全侵害时一系列的系统的思考方式。这样的话，从空间的组成部分的保护-检查-对应中，总结出必要的软件设计上的需求。

这种5A的考察手法可作为设计系统，组件以及系统整体等各种场合时最基本的构想。这里列举的5A的思维方式如能对IT构架师在系统的安全构架上有所参考价值的话，我将非常荣幸。

 

 

（译者注：1．文章虽发表于2004/4/29，还是挑选了这篇精彩的文章，以飨大家。

2．这方面的技术还请大家多了解一下LDAP：Lightweight Directory Access Protocol等。）