| 通过战略思维确保组织的安全性
为了能在体系结构层次保持实力，成功的 IT 专家都会从战略、系统、策略和过程的角度思考问题。从编程的圈子跳出来，了解从较高的应用程序架构级别处理安全性的新方法。跑在安全违规行为的前面，帮助确保您企业的高度安全性。
大部分软件安全性的讨论都集中在应用程序本身或其中包含的数据上。例如，大家经常讨论在将信息发送到数据库前对用户提交的
GET 和 POST 变量进行验证。类似地，大家对可用的加密系统也进行了大量的讨论。
不过大多数时候，如果能将所关注的内容提升一下，考虑应用程序架构级别的安全性，将颇有裨益。为什么呢？因为在此级别，并不是最令人讨厌的家伙才能继续存在，而是从战略、策略和过程的角度考虑问题的人将成为赢家。例如，假定您在网站上有个联系表。用户将填写表单，并单击
Submit，此操作将告知邮件服务器向指定的电子邮件帐户发送电子邮件。在战术级别，您的开发人员可能会绞尽脑汁来保护此表单的安全。他们可能会验证每个表单字段，以删除电子邮件注入命令、嵌入式超文本标记语言（Hypertext
Markup Language，HTML）标记和其他不当信息。他们甚至会按照传入 IP 地址对请求进行筛选，或设置
Cookie 来控制对表单的访问。
不过安全性措施到此为止。任何有能力的黑客都可以在每次访问表单时伪装其 IP
地址，因此能够非常容易地让简单的安全检查失效。如果恶意用户决定在一天内提交 10,000 次此表单，会发生什么情况呢？您的邮件服务器将接受
10,000 个请求，并非常尽职地完成其任务。问题在于，邮件服务器无法区分伪造请求和真实请求。邮件服务器被所有这些假请求所包围，无法处理真正的电子邮件，而其中一些邮件可能是销售线索或支持请求。处理此问题的一个方法是，对每个表单使用全自动人机识别系统（Completely
Automated Public Turing test to tell Computers and Humans
Apart，CAPTCHA）设备来区分人和计算机。
是否有些 CAPTCHA 设备比其他设备更好？是否有些可能会失效？当然，选择正确的
CAPTCHA 设备是一个实现细节。在应用程序架构级别考虑的是，是否已经考虑了此问题。
通过这个简单的例子我们可以了解到，要从应用程序架构级别处理安全性，需要采用战略思维方式。您不能仅仅考虑防御点，还必须确定基础系统的缺陷，并评估其面临的威胁（即攻击的可能性）、不采取任何措施的后果以及随后的防御系统的应用。
技能和能力
安全架构师的角色需要哪些技能？您将需要以抽象的方式进行思考，了解关系、设置策略并从一开始就从“敌人”的角度考虑问题。简单说来，您将必须获得一套全新的战略工具。
抽象思维
在应用程序架构级别工作，要求您将思维方式从具体的编码、质量保证和硬件转向更为抽象的层次。您不再直接处理代码或硬件，而将要考虑系统以及系统之间如何交互。您将需要知道各种企业系统（如内容管理和企业资源规划（Enterprise
Resource Planning，ERP））如何一起工作；您还要处理外部的供应商及其应用程序，如自动系统和其他专门数据库。
了解关系和策略
不幸的是，安全体系结构全部讨论的都是“政治”。在理想的情况下，所有信息技术（Information
Technology，IT）资产将供任何人在任何时间任何地点自由使用。不过，这不是我们眼前的这个世界，因此必须定义哪些人能访问哪些内容，以及何时/何地/为什么/如何访问。这样做需要进行一些困难的决策，例如，要求使用单点登录
(SSO) 的所有应用程序都必须简化对常用参考资料的访问。这些规则通常编码在安全策略中。
好的安全体系结构（以及普通安全性）都从好的策略开始。知道所拥有的系统、这些系统上的内容以及哪些用户需要访问这些内容。确保所有信息都得到了恰当的记录，因为没有文档，就无法执行任何规则。例如，您可能在策略级别决定您的应用程序用户能够上载文件，但只允许小于
500 KB 的图像、可移植文档格式 (PDF) 文件和 Microsoft? Word 文档。这种类型的策略可以在系统体系结构和应用程序业务逻辑的所有级别执行。
好的安全策略是什么样子的呢？具体取决于您的组织。这可以是存储在公司内部网上的非正式的文档，也可以是 IT
部门中的临时契约。无论是何种形式，都必须是一个充满活力的实体，能方便地进行更新和引用。否则，没有人将使用它，也没有人会遵守它。
这个等式的另一部分可以大概归入“如何应对压力”类别。在某些时候，您将遇到安全违规或某种恶意攻击。将会有一些您从来没有想过的事情。配备了什么样的系统和流程来应对这些情况？在压力很大的情况下，您的行为方式与第一时间针对问题进行规划同样重要。
从“敌人”的角度思考问题
您的角色负责安全性，完成您工作的唯一办法就是真正深入敌后，即了解尝试破坏安全性的人员的想法。这种想法会体现在您完成的所有工作上：您的安全策略中、安全测试计划中、质量保证计划中。如果您知道您的应用程序中某种特定的关键应用程序有
500 个可能被利用的点，您必须在投入使用前对所有这 500 个点进行测试（或至少测试所有可能导致灾难性问题的点）。
如果您在构建典型的 Web 应用程序，通常需要一个名为 /admin 或
/admintool 的部分，用于包含所有允许实际控制和操作数据的管理。例如，对于内容管理系统，您将提供允许用户创建和更新新闻稿、页面、二进制文档和其他信息资产的部分和屏幕。也就是说，从安全的角度而言，此类区域的存在为任何希望破坏
Web 应用程序的人提供了一个极大而且非常容易攻击的目标。常识会让您对这些目标进行处理，对吧？
在这种情况下最好的方法是将管理界面从承载 Web 应用程序的服务器删除。的确如此：创建次要管理服务器，以承载此管理功能。但这不是唯一应考虑的事项。不仅要将管理界面移动到其他服务器，还要确保此服务器仅能在私有网络上访问。这当然要求管理界面从远程位置恰当地将数据库和文件存储库填充到主
Web 应用服务器。
如果您无法将管理区域移动到其他服务器，请将其移动到主服务器上的其他端口。例如，仅通过高编号随机
TCP 端口（不是 8080）提供管理界面。毕竟有 64,000 个左右的端口可供使用。另外，将安全套接字层（Secure
Sockets Layer，SSL）安全机制添加到整个登录流程中，并以加密形式存储用户的密码，以防止被窃听。最后，不要对
Web 应用程序的这个部分使用 admin 之类的常见名称（据我所知，我们有时候都会采用此类名称）。/manage
or /sitecontrol 之类的如何呢？
此处要记住的关键是，您可能不会捕获所有信息。毕竟您必须每次都正确，而黑客在耐心攻破您的防御时，只需要对一次就行了。因此您必须做两件事：像黑客一样思考问题，并在良好流程方面进行投资，以实现抢先一步的优势。
深度防御
深度防御 背后的理念很简单：永远不要仅依赖于一种安全方法。不要仅使用护城河，而要同时使用护城河和城墙。然后在墙内添加随机巡逻队，以验证人员的身份。对每个建筑的门和窗户上锁。在前门栓一只狗（最好是叫声洪亮、凶猛的狼狗）。每隔数小时就让邻里之间互相检查，以确保平安无事。
和任何事情一样，深度防御也是安全性和适用性之间的平衡。如果安全措施太多，会给普通用户造成障碍。如果安全措施太少，您唯一的防御系统将会失效，从而让外人能够访问检查点之后的所有数据。
深度防御的具体例子有哪些？例如，在处理表单中用户的输入时，您通常会检查提交的每个表单，以确保其中提供的是预期的内容（数字、邮政编码、字母字符等等）。可以将此检查与客户端的最大大小检查（以防止缓冲区过载攻击）一起运行，但由于有人能够使这些措施失效，因此还要在服务器端进行检查。不仅如此，还要确保没有人添加恶意
HTML 代码、可上载文件或结构化查询语言（Structured Query Language，SQL）注入。
这番清理之后，您将确保通过 HTTP 程序员熟悉的 mysql_real_escape_string()
之类的数据库安全函数的等效函数传递所有数据。为什么在对数据进行清理之后还这样做呢？因为您永远不知道何时会出现比您更聪明的人，这就是原因。
还要进行其他步骤吗？当然。如果发出了 create 或 update 之类的数据库命令，填充临时表并在最终提交前要求管理员批准更改的做法将非常明智。如果数据是对数据库行发出
delete 命令，请确保在语句最后添加 limit 1，以尽可能减少损失。（您还可以将受影响的行复制到备份表，以防万一！）
工具和技术
您可能已经习惯埋头创建系统，但现在您的角色是向其他人解释您所需要的东西。为此，您将需要采用一些新工具，如统一建模语言（Unified
Modeling Language，UML）。
UML 和角色
如果您曾经从事过计算机安全方面的工作，则应该习惯于关于任何应用程序的以下类型的问题：
1.您应用程序是否有任何部分（如管理界面）需要用户登录？如果是，如何处理身份验证？
2用户是否可以注册，以创建自己的用户名，或者名称基于用户的电子邮件地址或其他可能已知的构造（名的第一个字母加上姓）？
3.密码是由系统随机选择的，还是用户可以自行选择密码？如果是后者，系统是否检查常见的安全性弱的密码，如：
长度少于七个字符的密码？
与用户名或用户名反写相同的密码？
不包含大小写、数字和特殊字符的密码？
是常见的术语或小说和电影中角色的名字的密码？
这些问题都值得考虑，不应该出于“更高的出发点”而忽略这些问题。不过，在应用程序架构级别，必须上升到另一个层次考虑问题。您必须首先考虑您的用户、其角色以及他们由于其角色能够访问哪些内容。
我认为处理这种讨论的最佳工具就是角色 (persona)。例如，如果我在为客户设计企业内容管理系统，我总是要确定用户是哪些以及他们需要完成什么工作。对于每个用户，我都构建一个角色，如：
1.Tina，营销经理。Tina 是具有 15 年高科技营销领域丰富经验的营销老手。她手下有五位营销专家。Tina
必须能够对站点上发布的所有内容进行审批，但她并不自行从头创建内容。她可以查看网站上的所有内容。
2.Tom，公共关系 (PR) 撰稿人。Tom 只能创建和编辑新闻稿和新闻条目。他没有权力发布内容，也不能从运行的站点上删除任何内容。
3.Jill，营销项目经理。Jill 负责网站的两个部分：产品和解决方案。她可以创建新内容和更新已经发布的内容，但必须获得最终批准才能将新内容发布到网站。
4.Tony，活动经理。Tony 负责活动日程和网站的联系人表单。他可以直接将内容发布到活动日程而不用进行审批。
5.Ruth，文档撰稿人。Ruth 负责为网站的任意部分撰写文稿，她通常每天会接受不同的任务分配，对网站的内容进行改进。她可以从头创建内容和编辑现有内容，但必须首先通过
Bill 才能发布内容。
6.Bill，编辑。Bill 通常对所有内容进行检查，然后将其发送给 Tina
进行最终发布审批。
请注意，这些角色完全都是非技术性的。您此处所进行的工作只是讨论一些概念和行为。您在其中标识了每个角色以及该角色能对不同类型的数据进行什么处理。稍后，您将进行更为详细的工作，讨论他们可以进行的数据库类型的操作（例如，Tina
可以对 Page、Pr 和 Images 表运行 select(*)）。
但您如何决定哪些人访问哪些内容呢？请遵循最低权限原则。向用户提供完成其工作所需的最低功能和模块访问权限，并在不需要时尽早收回。如果您为他们提供了其他权限，将这些额外的权限限制在其安全概要中，然后在完成工作后收回这些权限。
信任，但要验证并记录
并不会因为您设计系统时考虑了营销经理 Tina，Tina 就会进行她应该进行的工作，或者不会选择很容易就被破解的简单密码。将每个用户进行的操作记录到日志中，从登录开始一直到退出为止。将其记录到平面文件、数据库、非现成磁带备份中或采用任何其他方式——但一定要记录。
到底为什么要进行日志记录呢？因为您希望能够在以后再现已经发生的操作。您希望了解用户的“轨迹”，从最初登录到在系统上执行的每个操作。这不仅在取证的角度有意义，而且还可以通过其了解用户使用系统的方式。例如，您可能会发现每个人在您的应用程序中经常进行大量的跳转操作。或许更好的搜索引擎或更好的交叉链接就能够缓解这种情况。
加密
在传输或存储时的数据安全是讨论中一个非常重要的部分。在您之前担任开发人员时，通常首先从加密方法、SSL
证书等等开始整个讨论。从应用程序架构级别而言，您同样要考虑概念和行为。
例如，如果存储数据，会将数据存储在何处？存储在平面文件中，还是存储在数据库中？存储在
Web 服务器根级别以上，Web 服务器根中、专用的介质或文件服务器上或共享加载点？这些问题的答案实际上都是考虑需要访问数据的用户及其访问方式。如果他们需要通过执行详细的搜索来检索数据，则采用某种类型的数据库比较明智。如果需要快速检索数据，也应该如此。
既然已经考虑了一些谁需要访问数据，以及如何检索，然后就可以考虑安全性的问题了。我最喜欢的方式就是将可下载二进制文件放置在
Web 服务器根级别之上的位置，然后仅仅通过获取程序提供对其的访问。获取程序可以不采用安全措施，也可以要求提供某种用户登录、Cookie
或会话变量才能检索这些文件。可以在进程最后附加一个简单的日志记录系统，以跟踪所涉及的项目的每次下载操作。这实现起来非常简单，但必须事先进行充分的考虑才能正常工作。
数据通信的安全是要考虑的另一个重要方面。同样，也要从较高的角度进行考虑。首先问您自己这些问题：我们的应用程序在哪里与自身及其他系统进行通信？是否可以对所有这些点进行保护？是否值得这样做？例如，处理电子商务、银行交易或金融的任何应用程序部分都需要所能提供的最高级别的安全性和加密。任何时间，只要处理敏感客户或用户信息（从生日到私人医疗信息），只要可能，都不要使用纯文本消息。很多应用程序平台都支持通过使用公钥加密相对容易地对消息进行加密、发送和解密。如果您的组织不能在进行消息传递前添加此功能，请在消息中包含尽可能少的信息，并要求接收者登录某个位置来查看其余数据。
里程碑
对于任何应用程序架构安全工作，都要考虑以下技能和能力里程碑：
应用程序安全策略。这里的预期目标是要开发一个文档，确定应用程序各个部分的规则。将如何使用和访问数据？网络上将遵循哪些规则？应用程序如何与其他应用程序和系统进行协作？应用程序如何融入到整个企业安全策略中？从策略维护的角度而言，您还必须确定您策略文档的格式，哪些人提供文档输入信息，哪些人进行此文档的维护。
定义角色和工作流。获得安全策略后，就要定义角色和工作流。您必须知道应用程序在何处如何与安全机制进行交互。例如，如果您知道某些用户具有类似的要求，则可以考虑向应用程序添加分组的概念，从而更方便地进行用户管理。如果您知道特定的用户子类增加了对应用程序特定部分的责任，则可能还要重新考虑权限模型。如果您不首先进行相应的映射工作，就不会知道这些。
定义安全范围。 您将需要在某些位置将所有这些艰难工作应用到应用程序架构中。因为这可能是由很多人一起定义的，因此您需要确定如何划定整个讨论的范围。（还记得我们前面讨论过“政治”吧？）很多时候安全性都是空口承诺，到最后才会真正添加。尽早包含您关于系统及其用户所知的信息，从而让您的团队避免受到这方面的影响。
总结
在应用程序架构级别工作，意味着要采用全新的思维方式。您考虑的东西要更为战略化，需要更为抽象地考虑问题，并使用沟通工具和技术（如
UML）来全面描述希望团队实现的目标。您还必须从更高的角度考虑安全性，而不只是从战术的角度考虑。希望本文能帮助您走上正轨，那将是我无限的荣幸。
|
