2024比较安全架构

比较安全架构定义和测试用于评估和分类安全性的模型架构框架©©第二页比较安全架构罗布·范·奥斯目录表二.致谢三、1要. 12 绍. 2ZACHMAN构. 2构. 2构. 3念. 3念. 3题. 7骤. 7型. 10点. 10构. 14型. 17析 32萨 32局 39OSA 44构. 52萨 52局 55OSA 60论. 657.1 括. 657.2 述. 657.3 论. 677.4 明. 687.5 究. ⋯⋯⋯⋯⋯⋯⋯⋯698结. 件述. 格. 74图. 74件献 献. 75献. 75第三页第三页©©一、缩略语列表5W1HADM少量比特币血压CDSACG国际空军CMMI科比特DODAFE2AMMEAFEAFHTTP(S)IFEAISRMISSS它ITIL莫斯科NAC欧空局OSAPDCAPEP

什么、哪里、谁、何时、为什么、如何通用数据安全架构Gemini扩展的企业架构成熟度模型企业架构企业信息安全架构企业安全架构联邦企业架构框架超文本传输协议（安全）身份管理信息技术基础设施库美国国家标准技术研究院开放式企业安全架构开放安全架构计划‑实施‑检查‑行动政策决策点政策执行点公钥基础设施政策管理机构RBAC SA 会 Sherwood构SAMLXML

安全断言标记语言软件产品质量要求与评价第四页第四页©©smsg)感谢您对研究问题的定义、本论文内容的正确科学基础以及为论文内容和结果提供指导的批判性见解。DanHarnesk博士在最初的截止日期之后很久。HansnDrunensTleNAFAPAGEPAGE576页©©本文创建的模型可用于评估和比较安全架构，因为它（）45637ITITIT缺乏概览和正规化导致基础设施方面很可能存在差距。ZachmanJohnAZachman1Zachman（总共5个）（）（（何处）。（谁）（（）2Zachman0（）（Zachman3Zachman（EA）框架的早期尝试。EA一词用于表示通过在组织目标和实现这些目标所需的步骤之间架起一座桥梁来努力支持公司决策的举措。AZachmanZachmanEA（SA也EASAEA（）A安全相关概念将不再详细解释。然而，为了确保充分理解信息安全架构的目标，提供了基本概念的简要定义。4SB9SB9SB9这些概念通常被称为CIA三元组。通常还包括其他概念，例如真实性（）（（）。将解释与架构相关的概念。这个解释可以作为论文参考的术语表。（5]（（）（）r为A“EAEAITEA6]7EA是一个自20世纪90年代初期和中期以来就备受关注的话题。这种关注已经积累到相当多的框架上。框架列表包括架构框架包括：(TOGAF)Zachman(DoD(DoDAF(FEAF)其中一些框架已经产生了最佳实践方法，这些方法被描述为使用该框架的方法。89]是本文的主要主题，但值得注意的是，每种架构都有自己的参考架构。[10]EA些级别中，架构工作进一步细分为专门的焦点或视图。这些视图被认为是架构域。例如，在TOGAF9.1企业架构框架中，区分了以下架构域[8]：[11]‧（为了正确分类，为每个术语和附加术语提供了定义。框架ISO/IEC/IEEE42010‑2011系统和软件工程架构描述为与架构相关的术语提供了许多定义。该标准定义了一个架构框架作为“描述在特定应用领域和/或利益相关者社区内建立的架构的惯例、原则和实践”[12]。这意味着一个框架必须：456和7章分类法分类法[13]模型（e方法论方法论是规[15]这些产品累积到所需的最终结果。过程方法论的一部分。实践(ITIL)就是此（可以整体或部分实施以标准化服务交付的工具（即服务管理流程）。最佳实践可提高效率和效果[16]。（（）和支持或缺乏与现有架构流程的集成。这种情况可能会导致企业和安全架构工作不一致，并可能导致高水平的安全问题。IT复杂性ITT本文试图回答的研究问题如下：“安全架构框架如何进行相互比较？”题，创建一个评估安全架构的模型并评估该模型是否能够提供适当的结果非常重要。本论文通过三个步骤来回答研究问题：架构来确定它们的工作方式以及它们具有哪些功能。PAGE876页©©3清单完成后，将定义一组用于比较的特征。这些特征代表了安全架构的定性和描述性特征。1SABSA。Sherwood(SABSAITSABSAZachman[17]SABSASABSA(TOGAF)‧（O由enp[18]OSA(OSA站A为了分析上述架构，将使用以下主要来源：13：9781578203185\hhttp://\h全;；\hhttp://\h比较安全架构比较安全架构PAGE1076©©此步骤中进行的评估是定性分析，其中一组质量属性是2完成这一步后，对比就完成了。所得矩阵将牢固地包含成立的声明。论文将以结论和讨论结束，其中讨论模型和模型的内容，以及模型的适用性和进一步研究的潜在步骤。本章详细描述了这些活动。在检查TOGAFTOGAF（‧A“BITTOGAF所有常规架构都有一个安全组件，架构师在其中处理安全方面的问题安全架构：分为：应用安全架构（1EAPAGE1276©©图A涵盖特定主题或观点。AFF9(ADMTOGAFADM[202BIT（3年7月6日）。图TGartner[21A（BIT“IT问题”。这种方法在某些情况下可能具有优势，特别是当技术架构是正在开发的主要架构时。T4(BITS)（EISA）图AGartnerEA[22]图AGartnerEA[22]（4图A企业安全架构作为一个独立领域的定位并未得到广泛采用。TOGAF的最新版本于2011年发布，仍然使用三个传统的BIT层。F（TOGAFF9TOGAF[23]TOGAFF和A如TOGAFADMSABSASABSATOGAFADM框架[24]EA14。在检查SABSA[25]时常见做法，并且与本论文的范围无关。本质上是技术性的，但也可以是业务解决方案，作用于层次结构的不同级别。PAGEPAGE1776©©1方法，有效地为组织内的所有安全激励措施提供指导。本指南是一种标准化形式，其中不同的安全解决方案在类似的事项和动作中实施。[26]IT立架企业。使用“企业安全架构”分类的架构示例是SABSA。AEA将自己命名为业务安全架构。SABSA是SherwoodAppliedBusinessSecurityArchitecture的缩写，但认为自己是“企业安全架构”。EAEAEATOGAFEA[28][29]IT参如前所述，尽管SABSA主要关注业务安全架构并将信息安全管理定位为业务支持流程，但找不到任何示例。EA信息系统安全架构师[30]：统的攻击向量。描述了其他任务，但上面的列表代表了最重要的任务。(TSA‧（A1EABIT技术安全架构师[32]：定4.2.6、4.2.7和4.2.8段中进一步阐述。（随着信息的关注，数据安全架构的共同主题是加密和逻辑访问控制。数据安全架构：（CDSA）。（建筑不应与设计混淆，尽管这两个学科是相关的。设计以架构为指导。在SABSA中，较低抽象层的架构称为设计。网络安全架构：组名为网络安全架构的架构的一个示例是GIAC的SANS网络安全架构[35]。的安全。这排除了可能在系统上运行的任何应用程序，因为它们是应用程序体系结构的一部分。它还排除系统安全架构师：（“Windows8[[37]。如果广泛实施，这些模块中引入的错误可能会成为常见的攻击媒介。应用安全架构：‧名为应用程序安全架构的架构的一个示例是SANS研究所应用程序安全架构[38]。模型来比较安全架构并对它们进行分类。这将使用模型来完成。该模型有四个特点：4.2这些特征需要统一到单个分类模型中。这些特性将在接下来的段落中进行更详细的研究。[26][39]Zachman抽象Zachman通过定义不同的级别将抽象引入到他的企业架构中。每个级别都代表适用于利益相关者或许多类似利益相关者的观点。（（由于这些原因，概念层也称为“规划者视图”，因为此活动概述了建筑师对结构或系统的意图（计划）。Zachman56（5W1H）。30(5x6独特的。随后，扎克曼为分类法制定了7条明确的规则：PAGEPAGE1976©©5W1HEAHZachman“what（“data）“where（）3（26日）。图5Zachman（\hZI_PIcsZF3.0.jpg年7月26日）。图A的Zachman详细检查图5时，有几件事值得注意：企业。在模型中，该层具有不同的颜色，因为它不关心信息系统的创建（这是Zachman绘制的与物理架构平行的原始目标）1[1由于本论文的重点是交付，而不是维护和运营，因此“企业视角”在本论文的背景下不被认为是有用的。其他抽象除了ZachmanEA（rA（6年）图rAGartner指出[40]Zachman（规则4）ZachmanSABSA模型SABSAAZachman[17]。该模型使用Zachman最初论文中概述的相同5个基本抽象层。ZachmanEAA和ZachmanA（ZachmanAA7（9年4月）。图AZachmanZachmanGartner3ZachmanrAZachmar（）选择Zachman模型而不是SABSA模型，因为它本质上是相同的。SABSAZachman（Zachman分）其他框架已经被检查过，但本质上与本段中概述的模型相似。这些模型可能使用稍微不同的属性或不同的命名约定，但本质是相同的。在模型中集成不同的观点也很重要。作为（BIT）TOGAFGartnerEA(TOGAF)（3）i（CG8GFZan在64图pi在检查观点和抽象层时，可以得出以下结论：ZachmanZachman（）GF（TOGAFGartnerEAFF[46]：PAGEPAGE2476©©此列表包含以下内容：42010‑2011[12这些描述表明了架构的重点和适用性，本质上不被认为是定性的。例如，方法并不被认为比实践更好。定性特征将在下一段中介绍，并且可能与此列表相关。（“‑‑）主要质量属性（安全属性）2.4NISTFIPSPUB1994ISO/IEC27000:2009[43]。然而，正如第2.4段所述，这些要素并未涵盖所有基本信息安全概念。因此，需要识别和考虑附加属性以获得信息安全架构质量的完整概述。这些附加要素存在争议。FIPSPUB199。CCIA[45]。相关技术和关键词包括日志记录、审计和身份管理。这些属性是大多数出版物之间的最大共同点。这也与为次要质量属性选择的框架非常一致，如下段落所述。次要质量属性[46][48]（即这些特征使得这些出版物作为本论文背景下的指导用处不大。EA[49]指PAGEPAGE2576©©EA上ISO25010图（‑)0（子图图O0（子（子这与架构无关，也很难以客观的方式建立。因此，一个应做出适合评估安全架构能力的选择。此选择显示在图10中。比较安全架构第比较安全架构第26页（共76页）©©图10中的质量属性将在下一段中讨论。请注意，为了保持一致性，属性使用标准中的美式拼写。安全架构能力质量属性（10PAGE3576©©可以获得有关如何最好地使用该架构的信息。这个属性有点类似于Sessions的指导属性：实践指导、治理指导和分区指导。该属性类似于Sessions使用的“供应商中立性”属性。关于“共存”属性的注释：安全架构可以与企业架构共存。然而，这要求架构变更管理和调整涵盖两种架构。因此，集成架构是首选。构保持其附加值。该属性类似于Sessions作品中的“治理指导”属性。莫斯科MoSCoWM‧‧为MoSCoW方法源于应用程序开发，其中使用不存在的需求来定义范围。表1显示了已识别功能的MoSCoW表示例。MoSCoW主要次要安全架构属性安全P.1机密性完整性可用性真实

V

连续波P.2页

性性 V性二 V性 VVV功能适用性S.1性性 V效率S.3

性S.2能 V用 VS.4易学性易于使用VS.5V兼容性S.6可替换性互操作性可维护VS.7 性V用 化S.8重V9S.10S.11可分析性可转移性VVVS.12可安装性V对MoSCoWMoSCoWMoSCoW表。有两个部分：可应用于框架的分类和其他属性（即定性和描述性特征）。这些属性已在前面的段落中概述，现在将放在本文的上下文中。分类模型分类模型使用三组不同的特征：图11显示了分类立方体，其中每个特征集被描绘为模型中的不同轴。图Zachman12GCIAF图（4.3.4（4.3.322表类法程类法程践型架# 征 估主要安全架构属性安全页P.2页

保密正直可用性真实性问责制不可否认性二级安全架构属性功能适用性S.1

适当性S.2S.3操作性S.4S.5兼容性

S.6可替换性S.7S.8S.9

互操作性模块化可重复使用性3.1.2将使用分类模型以及定性分析模板进行评估。目的是提供对功能的客观概述7第5章和第6章将重点介绍架构分析以及使用分类立方体和分析模板对架构进行评估。中的参考文献是使用页码或章节而不是尾注参考文献。这增加了内容的可读性和检查性。此规则的例外情况是当引用与该架构框架的主要信息源不同的文档时。SABSASherwood2005IT（即（第i–页）SABSASABSASABSA图A（第9章（第10章）图A（第9章（第10章）SABSA框架定位为最先定义的架构。其余的架构层取决于这两层的结果，因此应首先解决它们。ITSABSA提供了完整的风险管理方法，应用于15（451483SABSA哪IT附5.1.3设计SABSASABSA（7）（11）（12）（13SABSAA证后，即可实现上一步设计的架构。SABSA方法中也描述了此实现，但只是简单描述。8（148）；（页）；（152155）；（第156–159页）。SABSA（本书由4介”）第133页SABSA132（第156页）。1417SABSA管理和测量SABSA生命周期SABSA（4L（8999）SABSASABSAASABSA（“TOGAFAeASABSA（“TOGAFAen10FMA图FMA除了SABSA生命周期之外，还应该涵盖SABSA的另外两个重要特征：业务属性配置文件和SABSA矩阵。SABSASABSA是SABSA方法的主要特征之一。简介是最适合公司简介的一组特征。这些特征应该是业务属性配置文件的建立可以使用将所有利益相关者聚集在一起的研讨会技术来完成。安全架构师负责识别正确的（SABSA属性。SABSAA（“TOGAF和Aen1年10ICTSABSAICTTASABSASABSAZachmanSABSA（A9A图ASABSA方法是一项庞大的工作。然而，本章概述的部分构成了与本文背景相关的方法的核心。SABSASABSA保密A（第8页）（第7页（）（231（232（239244APAGEPAGE3976©©也被覆盖。例如，逻辑安全架构还处理相关的安全（第295页（第299页）（第303309页）（第303306307页（308311））（页）（页（页）。（第1–2页）HTTPHTTPS（第2页和（404完整性完SABSA（第228页）（第231PKI（251265（页）（页（页（第336页（第343–347页（第356–358页）（第1‑2页）可用性完整性没有被提及为保护应用程序中信息的“安全服务”之一（第228页）（第231页（（第233页（第236页）（第239页）（第295–297页（第313页（页）（第343–347页（第364–365页（第347页恢复和业务连续性。同样，前面提到的与访问控制相关的所有主题也适用。A7（第524）。真实性如前所述，真实性与完整性相关。它被单独提到为“安全”之一（第7页）IPKI（第251–265页）（页I（第7–8页）（295297）（348349）（350（第351358问责制问责制并未被提及为保护应用层信息的“安全服务”之一（第228页）。然而，提到了密切相关的概念不可否认性。(RBAC（241243）（297（310（319页（第0–0页C安全架构解决了事件记录和审计跟踪等主题中的责任问题（第344页）。RBACPKIA（第8页）I（251‑265）。PKI（299）（页）（344（第391‑392页（O（NAC于4C该指南已更新，以反映最新的发展，现在引用了ISO27000标准[xi]。然而，本质是一样的。该指南描述了一种企业方法PAGE4176©©O‑ESA指南描述了企业安全架构工作的几个方面或领域。因素安图图A公司IT治理和企业架构（第11页）。该指南主要关注与技术相关的安全架构产生的安全操作，如图18所示。O‑ESA指南中详细讨论了被确定为O‑ESA一部分的每个域，并在以下段落中进行了解释。分图A图A（第4页）自动执行策略，但未解决此类策略的创建问题。因此，没有关于创建适合自动化的策略的指导。5（（PMA）、（PDP）（PEP概念框架在O‑ESA架构中具有重要作用，因为它代表了可以创建概念架构的边界。图图A上下文。比较安全架构比较安全架构PAGE4576©©重点仍然是技术，并且没有关于管理应用程序复杂性和一致性的指导。SABSASABSASABSASABSA（AAAA具SABSA保密性保密性被提（第5页）（第8页（（的通过确保对对象的访问是受控的、真实的和授权的。这些技术涉及概念、逻辑和物理架构。4.6（66）（67）（67权服务（第68页）。然而，对保密性的主要贡献是在加密服务中解决的（第73–74页）。直接提及机密性保护作为加密服务的目标。完整性就像（第5页）（第8页4.6（66）（67）（67）、（68（7374）可用性就像机密性和完整性一样，可用性被认为是总体目标之一信息安全（第5页）。关于弹性的部分更明确地讨论了可用性（第27页）（真实性安全架构未解决此元素。该元素也没有被提及为信息安全的基本目标之一。责任该元素仅由安（不可否认性架构中没PKI（SABSA（量）（OSA（OSAA（）：“OSA提炼了安全架构社区的专业知识，并为您的应用程序提供易于使用的模式。OSA应是一个由社区开发和拥有的免费框架。”OSA2024419LOSAOSAOSAOSANIST800‑53OSA“OSAISO27001COBITOSA“OSA在接下来的段落中将更详细地研究这些构建块。在每个段落中，都会对内容的完整性和感知成熟度做出声明。AA.A21PAGE4676©©图A这种架构景观似乎表明了解决组织安全问题以及IT安全问题的广泛范围。但必须注意的是，景观只是一个提案和一个方案。OSA（）（）（（）。当前概述的基本设计原则也在“初始草案”版本中（第基础/设计原则）。没有任何模式或控件直接引用OSAOSAFoundations/osa‑taxonomy)图AOSAAAOSAOSANIST800‑531722012TODSST951（3）T（自2年起）控制目录没有定期更新。PAGEPAGE5176©©OSAOSA（p.l22测试模式、1个通用模式和3个为仍在创建的模式保留的空间。其中一些模式仍处于草案版本，在最终确定之前等待社区的评论。每个模式都提供了高级设计，其中详细阐述了主题。这些模式包含许多适用于该特定主题的控件。这些控件都是相连的直接访问控制库，如上一段所述。除了高级设计之外，每个模式都进行了额外的详细描述。所有模式的模式描述形式都是固定的。以下随附文本将添加到该模式中：其者。在某些情况下，附加信息可能适用，例如适用于架构模式的设计原则(p.library/patternlandscape/259‑pattern‑data‑security)。OSAOSAOSA(ISSS[52]OSA(p.library/threat_catalogue)。OSAOSAOSA保密性OSA将保密性描述为信息安全的主要目标之一（第定义/it‑security）。在控件库中，解决机密性的控件有：（SC‑09）。(SC‑13)o访问控制政策和程序(AC‑01)o访问强制(AC‑03)(AC‑02)(IA‑01(IA‑02)在模式库中，这些控件以多种模式实现，最重要的是：（SP‑010）（（）DMZ(SP‑016)O‑ESA(SP‑020)（）。完整性完整性也被OSA描述为信息安全的主要目标之一（第定义/it‑security）。在控件库中，解决完整性问题的控件有：(SC‑08)(SI‑01)(SI‑07)（）（）（）在模式库中，这些控件以多种模式实现，最重要的是：(SP‑013)（DMZ)可用性可用性是OSA描述的最后一项，作为信息安全的主要目标之一（第定义/it‑安全性）。在控件库中，解决信息可用性问题的控件有：(CP‑01)(CP‑02)(CP‑06(CP‑07信(CP‑09(CP‑10)(SC‑05)在模式库中，这些控件以多种模式实现，最重要的是：DMZ(SP‑016)IT(DDoS（SP‑008）（也真实性真实性并(SI‑10)（SC‑23）这些控件在模式景观中通过以下模式得到解决：DMZ(SP‑016(TLS(SP‑020)(SP‑013)问责制问责制并未被提及为信息安全的主要目标之一。然而，有一些专门针对问责制的控制措施：(AU‑01)(AU‑02)o审核记录内容(AU‑03)o(AU‑03（AU‑04AU‑11）这些控件在模式景观中得到解决，主要有以下模式：（S4（SO‑010）不可否认性不可否认（AU‑10）（SC‑12（SC‑17）。通用控制(SC‑12)是AU‑10控制按以下模式寻址：‑DMZ模块模式(SP‑013)。该模式解决了许多与审计和责任相关的PKI‑I（SC‑12和SABSA中，对SABSA架构分析的结果进行处理以填充模型以进行评估和分类。ZachmanSABSAZachman17SABSASABSA观点SABSA还涵盖所有领域或观点：SABSA是（416‑417）（231‑323（524（第6页（309‑313XML（第页）（页）HTT（S（401‑402（PKI3页）。23SABSAPAGEPAGE5576©©图ASABSA（）SABSA（SABSA）（）、（SABSA）（SABSAISO/IEC/IEEE42010‑2011A主要质量属性（安全属性）SABSA的安全属性已在前面第5.1.5段中讨论过。次要质量属性适当性。SABSA方法和框架通过使用业务属性分析技术来呈现强大的业务重点，从而确保适当性。SABSA（550555资源利用。没有关于实施所需努力的详细信息。SABSA（第2页）（SABSASABSASABSASABSA最后，重复使用用例作为实现示例也增加了这一属性。可替换性。这并未作为SABSA方法的一部分得到解决。也没有找到有关可替换性的支持文档。SABSAICT（图16）。SABSA–TOGAF（第8页）（第1–0页）。（SABSA可重复使用性。SABSA的安全架构采用分层方法，可实现可重用性。较低抽象层的变化不会自动导致较高抽象层的变化。这允许在更高的抽象层重用资源（工件）。可变性。SABSA生命周期支持架构的可变性。使用一套审计和保证方法来评估生命周期的实施。评估结果然后反馈到架构管理流程中，并可以在战略和规划阶段引发新的活动，从而完成SABSA生命周期。A（第6章）（第16章（第14章）。SABSA表3显示了根据本段概述的描述性和定性特征得出的评估矩阵。表A

商业导向企业安全架构类类#

维维维

XVV法程践法程践型架主要安全架构属性安全第1页保密是的P.2正直是的P.3可用性是的第4页真实性是的第5页问责制是的第6页不可否认性是的二级安全架构属性功能适用性S.1适当性可靠性是的S.2可用性（见P.3）见第3页性能效率S.3资源利用不操作性S.4易学性是的S.5使用方便是的兼容性S.6可替换性互操作性不S.7可维护性S.8模块化可重用是的S.9性S.10可变更是的性S.11性性 的S.12性 的对O‑ESA架构分析的结果进行处理，以填充模型以进行评估和分类。比较安全架构第比较安全架构第56页（共76页）©©O‑ESA在抽象层上提供了明确的观点。没有考虑业务驱动因素18中（适用于O‑ESA的抽象层现已建立。然而，由于O‑ESA不提供分类法，因此这些层内的属性并不是立即显而易见的。相反，它们必须来自提供的架构示例和随附的文本。为此，使用Zachman的属性定义[53]：该这些属性的存在是针对服务身份管理(IdM)和边界保护(BP)进行评估的。身份管理在概念层面，主要（）（）（受M（存储位置）。（页）CGIAF“how”。GF6（）（）（（）。CGIAF“withwhat”4.7(p57（）（）（）。边界保护BP服务在概念和逻辑层上与IdM类似，并且处理相同的属性。PM观点正如分析A（BIT1）PAGEPAGE6076©©图A（SABSA）。（）（）4.2.4（）（（）。主要质量属性（安全属性）这些属性已在第5.2.5段中进行了广泛讨论。次要质量属性适当性。O‑ESA通过关注安全政策来解决适当性问题。该安全策略应源自业务策略，因此应以业务为中心（第109页）。因为由于提到了这一业务重点，但并未确保这一点，因此认为质量属性仅得到部分解决。可用性。可用性被架构指定为信息安全的关键要素之一（第5页）。资源利用。该架构没有解决实施所需的工作。鉴于该架构是单一用途的事实，实现很可能只需相对较小的努力即可完成，但这是一个假设，而不是基于指南中的信息。因此，该属性被视为“未涵盖”。A（第6”）使用方便。由于整本书都提供了实现示例，因此该方法的使用得到了强有力的支持。可替换性。安全架构并未解决可替换性问题。由于该架构的用途非常具体，因此找到替代方案的可能性很低。TheOpenGroup（1（）LT（可分析性。指标在O‑ESA指南中定义，主要在安全操作部分（第17页）。96‑105）（在戴明PDCA可安装性。整本书通过提供示例和流程提供了实施指南，解释了业务策略如何转化为访问控制策略的自动化技术实施。表4显示了根据本段概述的描述性和定性特征得出的评估矩阵。表A

单一用途技术安全架构类类#

二十五

XVV法程践法程践型架第1页保密第1页保密VP.2正直VP.3可用性V第4页真实性X第5页问责制X第6页不可否认性X二级安全架构属性功能适用性

部分的（P.3）性能效率

见第3页不

性 的便 的性性 不性 的性S.10 不

性S.11 的性性 不不S.12性 的OSAOSAOSA构框架中涉及的抽象层和分类属性有些难以识别。这是因为该框架没有解决传统的抽象层，并且也是一项正在进行的工作。DMZ此外，对于其中的每一项，适用于该项目的控件也在模式中概述。Zachman属性（）（）（）（）21（）。A观点在分析形态20（Web（）。2信息安全管理体系。12ISMS意识被覆盖。因此，当前状态下的OSA架构框架被认为是一个技术框架。图23图25显示了从前面的指标导出的OSA分类立方体。仅列出了4个属性，此时只能识别1个抽象层。第PAGE第61页（共76页）©©图AOSA.AAOSAA（）OSAOSAOSA模式。实现本身以及将模式集成到现有体系结构中，必须使用其他体系结构方法或框架来指导。OSA没有提供具体的方法。AA主要质量属性（安全属性）次要质量属性适当性。OSA未解决适当性问题。如果整个预期的安全架构景观已在模式库中实现，那么某些PAGEPAGE6476©©治理领域中的人工制品可以增加适当性。事实上，该属性必须被视为“未涵盖”。可用性。控件库中的许多控件都满足了可用性要求。此类控制的示例是控制“备用处理站点”和“安全规划政策和程序”。AOSAOSA不提建筑学。AAA申请。互操作性。OSAOSA1和T程式。OSAT3可变性。架构未解决此属性。OSA不提供处理此类主题的方法、流程或生命周期。此外，模式和控制是静态的。模式描述没有描述架构的实现，也没有详细说明架构更改对模式的影响。因此，该属性被视为“未覆盖”。OSAOSA的范围仅限于模式和控制，因此可分析性目前被认为“未涵盖”。A表5显示了根据本段概述的描述性和定性特征得出的评估矩阵。架构类型建筑应用VXXVXX#特征评估类法程架构类型建筑应用VXXVXX#特征评估类法程践型架页机密性完整性可用VP.2性真实性VP.3责任性不可否V第4页认性二级安全架V第5页构属性V第6页V功能适用性S.1适当性可靠性不S.2可用性（见P.3）见第3页性能效率S.3资源利用不操作性S.4易学性不S.5使用方便是的兼容性S.6可替换性互操作性不S.7可维护性是的S.8性S.10 的S.9

性S.11 的性性 不不S.12性 不SABSAOSA语境。形式提供了分析概述。该表示是第6章结果的直观汇总。26‑‑A图因此，以下内容是通用的：（）图因此，以下内容是通用的：（）第第66页（共76页）©©类法程类法程践型架以下是SABSA独有的：‑（SABSAO‑ESA（）没有任何内容是OSA独有的，