“架構安全”有“從上至下”和“從下至上”的兩種模型。要想做出正確的選擇，企業必須評估在它們自己的環境里應用這兩種安全模型的難度，并且考慮到這兩種模型對應用程序和中間件演進的影響。

[[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)都有能力交付所需工具，但是在找到使用工具的最佳方式的效率上卻因用戶而異。直到問題導向方式的清晰實現出現，用戶一直會面臨自己集成或者依賴專業服務的問題。但是從今以后-它不會變得容易。