架构安全模型开发方式探索

“架构安全”有“从上至下”和“从下至上”的两种模型。要想做出正确的选择，企业必须评估在它们自己的环境里应用这两种安全模型的难度，并且考虑到这两种模型对应用程序和中间件演进的影响。

[[149920]]

维护一个强大的安全模型，以及相关合规和管控的需求越来越重要，特别是在如今黑客和入侵几乎每天都会发生的情况下。根据安全规划师所言，最大的安全问题是企业都偏向于有了安全问题再解决，而不是在设计系统时就考虑到安全因素。

从上至下的安全和合规设计基于以下假定：应用安全和管控需求能够从所使用的业务框架里获得。显然，数据本身如何更加安全或者怎样的变化需要被跟踪并不困难。困难在于如何将有用的业务输入翻译成安全并且合规的模型。

一种方式是画出企业架构(EA)结果，将安全和管控需求映射到应用程序。所有现在流行的EA框架都有这个功能，并且每个模型都有很多来于用户的成功案例。EA链接意味着EA建模能够定义安全需求，来管控产品是否满足这些需求，因为它们支持所使用的模型。这是最纯粹的自上而下的做法，但是除非整个公司都能够全力为EA而努力，否则很难实施。

另一种方式有所不同，可能更容易实施。开发安全架构框架是一种问题驱动的模型，假定某个公司有IT组织，有可用的应用，并且有创建安全问题的业务驱动力。这种方式-和其他供应商，比如IBM和Microsoft那里兴起的方式——都意图在现有应用程序，服务和实践之上构建出超级结构，并且在这个框架之内让所有的东西和谐统一。通过关注于安全模型以及一直遵守的协调实践，企业能够引入IT的不同部分，而无需从头开始EA。

这种方式的困难在于假定识别出了企业所面临的问题。真正的EA驱动的模型从业务实践里继承安全和管控，确保其中不缺什么东西。问题驱动的方式无法解决还没有发现的风险。创建这些方法所需的超级结构也很困难，因为可能会涉及到各种各样的技术工具，特别是中间件。

问题驱动的自上而下的模型在安全和管控非常复杂的情况下可能很有用，这时涉及到客户和供应商的应用的整合。跨多个企业来协调EA实践(即使每个公司都有相应系统)非常困难，并且问题驱动的模型不要求这个。然而，由于跨企业集成的需求导致实现所面临的困难会很复杂。

自下而上的方式首先解决简单一致的实现的问题，然后假定可以采用灵活的方式来处理安全和管控需求。有些情况下要求使用业界最先进的安全和管控支持，这对于几乎大部分企业而言都足够了。

最激进的(也是最复杂的)做法是基于企业服务总线(ESB)。因为ESB通过满足接口规范的应用和业务规则将应用和组件链接到业务流程里，提供了强制安全和合规标准的良好架构。

表面上看，无论自上而下还是自下而上的安全模型要应用到现有IT环境里都不是容易的事情。对于自上而下的方式，相关问题是是否存在可用的EA框架，以及现有应用程序是否使用包含的多个工作流和接口工具来连接。对于自下而上的方式，问题则是采用ESB的难易程度，似乎取决于现有应用是否使用SOA。

最后的问题最为重要。如果现有应用程序既是服务也是基于SOA的，那么自下而上的模型很适合，也可能更容易部署。即使团队想要采用问题导向的自上而下方式，接口的一致性也会使得构建安全和管控的超级结构更为容易。如果现有应用程序更偏向RESTful，可能就很难改造成ESB方案，这时自上而下的模型会更好。企业就应该选择EA或者问题导向的方案，取决于他们是否已经确立了正式的EA实践。

从架构层面看，不管是控制信息流还是控制资源访问的模型都支持安全和管控。SOA框架支持第一种，Web和RESTful框架支持第二种。架构安全基于一种或另外一种原则会更为容易，但是除非企业已经准备好拥抱未来的微服务，云计算，容器以及Web的方向，否则还是很难做出决定。

因此，对于大部分用户而言，“最佳”方案很可能是问题驱动模型，期望工作关注于控制信息流和资源访问的领域。如今，安全和合规架构解决了这些问题，但是并没有形成实现的单一标准，这意味着用户不得不自己开发这些连接。主流软件供应商(IBM，Microsoft和Oracle)都有能力交付所需工具，但是在找到使用工具的最佳方式的效率上却因用户而异。直到问题导向方式的清晰实现出现，用户一直会面临自己集成或者依赖专业服务的问题。但是从今以后-它不会变得容易。