应用程序架构本质，第 7 部分: 应用程序架构安全性

为了能在体系结构层次保持实力，成功的 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 设备是一个实现细节。在应用程序架构级别考虑的是，是否已经考虑了此问题。

通过这个简单的例子我们可以了解到，要从应用程序架构级别处理安全性，需要采用战略思维方式。您不能仅仅考虑防御点，还必须确定基础系统的缺陷，并评估其面临的威胁（即攻击的可能性）、不采取任何措施的后果以及随后的防御系统的应用。

 本文转自：IBM developerWorks 中国

请点击此处查看全文