租赁合同起草中需注意的问题系列
——站在承租方之立场（下）
作者：仇少明律师 樊莹律师
单位：北京市隆安律师事务所上海分所
日期：2013年1月11日 星期五
摘要：通过上篇与中篇的分析，读者对房产租赁可能面对的风险有了框架性认知，了解了出租方有可能埋设陷阱的地方，明白了如何去填埋这些陷阱。在下篇中，笔者着重介绍两个常见条款——保证条款与优先续约条款。通过对此类条款的剖析与分享，力求为读者日后破除障碍及壁垒提供武器，知悉应思考及谨慎的要点，做到胸有成竹、进退自如。
关键词：出租方保证、承租方保证、优先续约
在以风险为导向的房产租赁交易过程中，当出租方与承租方就租赁房产概况、使用用途、房产交付、租期及租金等基本问题协商确定后，各方一般会将关注点转向出租方及承租方会作出怎样的保证，承租方能否以及如何优先续约等问题。针对此类问题，结合实战经验，请各位读者稍安勿躁，容笔者一一为您道来。
第一，保证条款。
也许有些读者会认为，保证条款是合同中次要的、非本质性的条款，对履行合同可能产生影响（反面想就是可能不产生影响，这符合大部分国人的侥幸心理常态），但并非决定性作用；如一方违反或撤销这些条款而不至于影响合同目的时，守约方要求违约方承担相应的违约责任即可，犯不着以此就取消合同条款或拒绝履行合同。如此看来，保证条款的作用就微乎其微了吗？
保证，就其基本含义，就是合同各方当事人关于与合同有关的各种事实与问题的声明，就种类而言一般可分为确认保证和承诺保证，前者是指保证方对过去或现在某一特定事实存在或不存在的声明，后者是指保证方对将来某一特定事项的作为或不作为的声明。
一个设计合理、内容全面、权义平衡的保证条款，不仅有利于当事人能够更加容易、迅速、充分地了解相对方的有关情况并作出是否最终订立协议的决策，便于提高办事效率，减少签约成本，而且从条款中折射出的诚意有利于为日后当事人的长期合作夯实基础。同时，一旦发现一方存在不实陈述，依据明确约定的协议条款来主张违约，就实践而言，比援引合同法的一般原则来得更为明晰和直接。
因此，结合笔者处理过的此类案件，建议承租方就出租方的保证内容可关注以下几点：
1. 主体资格及客体权属保证。
在与出租方的谈判过程中，承租方可根据实际情况填写下表，并根据表格内容形成条款文字，列于租赁合同之中。
序号 调查事项 YES OR NO 详情描述 备注
1 担保物权
2 违章建筑
3 消防验收及要求
4 环保手续及要求
5 卫生合格及标准
6 查封等强制性措施
…… …… …… …… ……
表格内容的详尽，有利于承租方核实出租方是否具备合法有效的对外租赁主体资格，辨别作为租赁关系客体的房产权属是否合法无争议，并确保承租方能够获得该房产的对外排他性合法使用权，避免因出租方主体资格不合格或房产客体状况不合法、不明确而导致租赁合同无效或房产不能被正常使用的悲惨性结局，进而造成承租方的重大损失。
对此，出租方须保证其“合法拥有房产的所有权及其土地使用权（或房产的转租权、使用权及经营管理权），保证房产不是违法建筑、无查封，其完全符合消防、环保、卫生等要求及标准，并已通过相关报批、施工及验收，手续齐备”，并确保“如租赁房产不符合上述保证内容，出租方应及时整改，包括但不限于取得相关许可证照、进行报批、组织验收，并赔偿由此所致的承租方全部损失”。
2. 维修保养保证。
虽然出租方对租赁房产及其附属设施提供维修保养服务是其法定义务，但在合同里进行明确的、详细的约定，有利于确认出租方对租赁房产及其附属设施进行维修保养的具体责任内容，明确各方执行维修保养工作的流程，避免约定不清而发生维修保养范围争议，进而导致维修延误、损失扩大，也可防止出租方以维修保养为名，经常干扰或妨碍承租方对房产的正常使用。
3. 技术条件保证。
实践中，常常出现出租方降低技术指标、推诿技术条件维护职责等情形，更有甚者竟发展到直接断水断电以此威胁承租方（俗话说，水是生命的源泉，切断“源泉”即可将承租方“毙命”，这般行之有效的方法，出租方怎会轻易放弃，可惜出租方却忘了抽刀断水水更流的道理啊）。
为防止出现此类严重影响承租方正常使用租赁房产的极端行为，以及日后矛盾的无限激化，在合同中对水、电、空调等技术条件进行详细约定，以有效明确出租方应提供的、应负责的、应确保的技术条件的范围、标准及要求，确认出租方对于正常供应与持续维继合格技术条件的责任，并可设定紧急自救措施及预救方案，以及出租方违约时的责任承担（包括但不限于租金减免、违约金支付等）。同时建议特别约定，“无论出租方与承租方就何种费用及其支付发生争议，或因合同项下其他事项产生纠纷，双方均应协商解决，出租方不得以任何理由断电、断水，否则由此给承租方造成的损失均由出租方赔偿”。
当然现实中也不乏很多粗鄙的出租方，无论合同条款如何约定，依然我行我素，一旦不能与承租方“英雄所见略同”，就采取停水停电的野蛮手段以及“株连式”与“突击式”并进的方法，公然叫嚣，视双方的约定于不顾。针对此类“智商无极限”的出租方，建议承租方不要“针尖对麦芒”，而是借鉴毛爷爷的“敌进我退，敌驻我扰，敌疲我打，敌退我追”的十六字战略，一方面稳住出租方竭斯底里的情绪，以尽快恢复水电供应为首要目标，以避免我方损失扩大，另一方面尽快固定证据、保留证据，核算已发生的损失，甄别并衡量主张损失赔偿的基础成本（当然可考虑鼓动其他租户一起行动，俗话说“人多力量大，蚁多咬死象”）、是继续在此租赁还是尽快搬迁以及获得赔偿的可能性与赔偿数额，并决策是对出租方采取法律行动，还是以此为由换来续租谈判的优惠条件（极端顽固的出租方不适用此项），或是退后一步海阔天空。当然，无论承租方如何决策，都别忘了关键，借用施乐公司首席执行官Anne的话就是“及时胜过完美”。
4. 房产使用协助保证。
对于租赁房产后将用于商业经营一类的承租方，建议提前了解当地政府对从事该类商业经营而使用房产时所要求办理的申报手续，以确定是否需在合同中增加要求出租方特别协助和配合的内容，包括但不限于提供房产平面图、经出租方签字的证明文件等，以明确出租方负有协助承租方办理某类商业经营相关报批手续的义务并明确包括哪些义务，同时强调出租方对该等协助工作不得另收费，以避免在报批过程中出租方不配合或懈怠协助导致承租方无法正常使用房产进行商业经营，以及防止届时出租方以此为由收取合同约定以外的费用。
5. 装修、改扩建通知及排除妨碍的保证。
对于房产使用过程中，出租方对租赁房产所在物业进行装修或改扩建工程时，常常使承租方爱恨交错，进退维谷。因为物业施工或多或少会影响对房产的正常使用，如果暂停使用，对商业经营类的承租方而言实在是心如刀割（餐饮类、美发类尤甚），而如果继续使用，在客流无法匹配经营条件或整体商圈受到严重扭曲的情况下，惨淡经营将成为挥之不去的梦魇。
因此，结合租赁房产所在的地理位置、建筑物状况、承租方将租赁房产用于商业经营的利润预估等因素，笔者建议在合同中约定出租方应保证承租方的正常使用权以及房产暂不能使用时的后续处理，以最大限度避免装修及改扩建施工导致人流减少、建筑物外观或结构变化产生对租赁房产正常使用的不利影响，进而妨碍承租方的商业经营。如下约定可供众读者参考：
“出租方对租赁房产所在物业进行装修及改扩建施工的，出租方应提前【】个月书面告知承租方（包括但不限于施工方案、施工时间等），并确保施工不得影响承租方对租赁房产的正常使用，若出租方或其委托的施工方造成承租方财产受损，出租方同意按承租方的要求全额赔偿。若施工导致承租方不能使用租赁房产或对承租方使用房产造成不便时，承租方有权自行选择：
（1） 暂停使用租赁房产。暂停期间租金全部免除，租期相应顺延。承租方暂停使用租赁房产而产生的损失，包括但不限于营业利润等，均由出租方承担。
（2） 继续使用租赁房产。若施工期间承租方的此处营业额比去年同期减少【】%以上时，出租方同意按【】标准减少该期间承租方的应付租金。”
第二，谨慎针对承租方的严苛要求（承租方的保证条款）。
出租方获得对价后让渡房产的使用权，当然会也必定会考虑到承租方在使用房产过程中的种种行为，预想到可能对其心爱房产的种种“摧残”。这种首先把承租方列为“恶人”的心态可以理解，但是从这种心态由此衍生成严格限制及要求承租方的苛刻条款，对于承租方后期将房产用于相关商业经营时，承租方将不得不面对跋前?后、左右为难的局面。
比如，“承租方保证合法经营，不因违法违规被政府部门查处，包括但不限于停业整顿、罚款、吊销营业执照等，不因违法违规或不道德的经营行为被新闻媒体负面报道，否则出租方有权解除本合同，承租方除应赔偿出租方因合同最终解除而遭受的损失，还应支付未履行租期内的全部租金”。
又如，“承租方保证，其所经营的行业、产品、商号、标识或提供的服务已需取得特殊行业或专项批准、代理权、海关以及政府批准手续、其他经营销售许可，以及相关所有权人（或使用权人）出具的授权、签订协议等，并确保该等手续、批准、许可、授权及协议在租赁期内保持合法有效，否则出租方有权立即解除本合同，且承租方应按上年度租金总额的三倍向出租方支付违约金”。
像这种为承租方经营量身而定的严苛条款，面对后期如出现第三方愿意支付高额租金而介入该房产租赁的诱惑，带有人类自身缺陷的出租方自然会选择华丽转身，以此充分的藉口来解约，不但不用承担违约责任，而且还能获得一笔不菲的违约补偿。
鉴于此类约定如定时炸弹，威力不小，建议承租方擦亮眼睛，谨慎分析其日后可能产生的冲击，充分设想这些冲击将带来的不利后果，以及己方能够应对并充分解决的可能性，经与出租方谈判后，可选择：
（1） 以其他商业条件作为删除或调整该类条款的对价。毕竟将房产租赁出去并从中获益是出租方的最终目的，紧扣该目的而抛出诱人的商业条件，在实践中还是有可能说服出租方作出相对妥协的。
（2）若不能删除或调整该等约定，可以为出租方设定同等内容或相似项目的条款，以对等限制出租方的自由。采取该策略的前提是承租方享有一定的优势，比如是大型集团或企业，经济实力雄厚，拟承租期限较长，拟承租的区域较大等。
（3）若恰逢负隅顽抗或不可端倪的出租方，实在无计可施时，笔者建议另行选择他处房产，即使再迫切也不要存侥幸心理，与其终日战战兢兢，不如即刻勇敢放手，因为饮鸩止渴只会带来更大的损失。
基于ＤＯＳ的信息安全产品评级准则
公安部
基于ＤＯＳ的信息安全产品评级准则
公安部
1998/06/01
【题注】（ＧＡ１７４－１９９８ Evaluation Criteria for DOS-based Information Security Products）
前言
为了贯彻《中华人民共和国计算机信息系统安全保护条例》的精神，并配合计算机信息系统安全专用产品的销售许可证制度的实施，公安部计算机管理监察司委托天津市公安局计算机管理监察处和海军计算技术研究所共同编写《基于ＤＯＳ的信息安全产品评级准则》。
本标准在技术上参照了美国ＤＯＤ５２００．２８－ＳＴＤ可信计算机系统评估准则。
本标准由公安部计算机管理监察司提出；
本标准由公安部信息标准化技术委员会归口；
本标准起草单位：天津市公安局计算机管理监察处
海军计算技术研究所
本标准主要起草人：张健，周瑞平，王学海，张双桥，高新宇
１．范围
本标准的适用对象为基于ＤＯＳ操作系统的信息安全产品。基于ＤＯＳ的信息安全产品是指保护ＤＯＳ操作系统环境下的信息免受故意的或偶然的非授权的泄漏、篡改和破坏的软件、硬件或软硬件结合产品，以及用于产品安装、执行、恢复的相关设施。在本标准中，对安全产品的评级等同于对加装了该安全产品的ＤＯＳ操作系统的安全性能的评级。
标准根据安全产品的性能将其分为三个等级。从最低级ｄ到最高级ｂ，其安全保护性能逐级增加。
２．引用标准
美国ＤＯＤ５２００．２８－ＳＴＤ可信计算机系统评估准则。
３．术语
３．１ 客体 Ｏｂｊｅｃｔ
含有或接收信息的被动实体。客体的例子如：文件、记录、显示器、键盘等。
３．２ 主体 Ｓｕｂｊｅｃｔ
引起信息在客体之间流动的人、进程或装置等。
３．３ 安全策略 Ｓｅｃｕｒｉｔｙ ｐｏｌｉｃｙ
有关管理、保护和发布敏感信息的法律、规章和技术标准。
３．４ 可信计算基 Ｔｒｕｓｔｅｄ ＣｏｍＰｕｔｉｎｇ Ｂａｓｅ－ＴＣＢ
操作系统中用于实现安全策略的一个集合体（包含软件、固件和硬件），该集合体根据安全策略来处理主体对客体的访问，并满足以下特征：
ａ．ＴＣＢ实施主体对客体的安全访问；
ｂ．ＴＣＢ是抗篡改的；
Ｃ．ＴＣＢ的结构易于分析和测试。
３．５ 安全策略模型 Ｓｅｃｕｒｉｔｙ Ｐｏｌｉｃｙ Ｍｏｄｅｌ
用于实施系统安全策略的模型，它表明信息的访问控制方式，以及信息的流程。
３．６ 敏感标记 Ｓｅｎｓｉｔｉｖｉｔｙ Ｌａｂｅｌ
表明一个客体的安全级并描述该客体中数据的敏感度（例如：密级）的一条信息。ＴＣＢ依据敏感标记进行强制性访问控制。
３．７ 用户访问级 Ｕｓｅｒ'ｓ Ｃｌｅａｒａｎｃｅ
用户访问敏感信息的级别。
３．８ 最小特权原理 Ｌｅａｓｔ Ｐｒｏｖｉｌｅｇｅ Ｔｈｅｏｒｅｍ
系统中的每个主体执行授权任务时，仅被授予完成任务所必需的最小访问权。
３．９ 关键保护元素 Ｐｒｏｔｅｃｔｉｏｎ Ｃｒｉｔｉｃａｌ Ｅｌｅｍｅｎｔ
有ＴＣＢ中，用来处理主体和客体间的访问控制的关键元素。
３．１０ 审计踪迹 Ａｕｄｉｔ Ｔｒａｉｌ
能提供客观证明的一组记录，用于从原始事务追踪到有关的记录，或从记录追踪到其原始事务。
３．１１ 信道 Ｃｈａｎｎｅｌ
系统内的信息传输路径。
３．１２ 可信信道 Ｔｒｕｓｔｅｄ Ｃｈａｎｎｅｌ
符合系统安全策略的信道。
３．１３ 隐蔽信道 Ｃｏｖｅｒｔ Ｃｈａｎｎｅｌ
违反系统安全策略的信道。
３．１４ 自主访问控制 Ｄｉｓｃｒｅｔｉｏｎａｒｙ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ
根据主体身份或者主体所属组的身份或者二者的结合，对客体访问进行限制的一种方法。具有某种访问权的主体能够自行决定将其访问权直接或间接地转授给其它主体。
３．１５ 强制访问控制 Ｍａｎｄａｔｏｒｙ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ
根据客体中信息的敏感标记和访问敏感信息的主体的访问级对客体访问实行限制的一种方法。
４．评级等级
本标准将安全产品分为局部保护级、自主保护级、强制保护级三个等级。为便于和可信计算机系统评估准则互为参照，又表示有别于该标准，用ｄ，ｃ，ｂ表示。
４．１ 局部保护级（ｄ）
提供一种或几种安全功能，但又未能达到ｃ级标准的产品。
４．１．１ 安全功能
必须明确定义每项安全功能预期达到的目标，描述为达到此目标而采用的ＴＣＢ的安全机制及实现技术。
４．１．２ 安全测试
必须对产品文档所述的安全功能进行测试，以确认其功能与文档描述相一致。
４．１．３ 文档
安全特征用户指南文档要清楚地描述产品的保护原理、使用方法、使用限制及适用范围。
要提供一个测试文档，描述该产品的测试计划、安全机制的测试过程及安全功能测试的结果。
４．２ 自主保护级（ｃ）
ｃ级主要提供自主访问控制功能，并通过审计手段，能对主体行为进行审查。
４．２．１ 安全策略
４．２．１．１ 自主访问控制
ＴＣＢ需定义并控制系统中主体对客体的访问机制，所采用的机制（如访问控制表）要明确规定特定主体对其它主体控制下的信息的访问类型。系统和用户设定的自主访问控制机制，能保证受保护的客体不会被未经授权的用户访问。对客体没有访问权限的用户，只有对该客体有授权能力的用户才能为其指定访问权限。
４．２．１．２ 客体再用
在将ＴＣＢ的空闲存储客体池中客体初始指定、分配或再分配给一个主体之前，所有对于存储客体所含信息的授权都必须被撤销。当主体获得对一个已被释放的存储客体的访问权时，由原主体活动所产生的任何信息对当前主体都是不可获得的。
４．２．２ 责任核查
４．２．２．１ 身份鉴别
用户在要求ＴＣＢ执行任何动作之前，必须首先向ＴＣＢ表明自己的身份；ＴＣＢ要使用保护机制（如：口令）来鉴别用户身份。为了防止任何未经授权的用户对鉴别数据进行访问，ＴＣＢ要对鉴别数据进行保护。ＴＣＢ需提供唯一标识每个系统用户的机制，并将用户的所有可审计行为与用户的标识联系起来。
４．２．２．２ 审计
ＴＣＢ必须能创建、维护由主体实施的操作（例如：读、删和改等）的审计记录。ＴＣＢ要记录下列类型的事件：使用身份鉴别机制；客体的引用；客体的删除；以及其它与安全有关的事件。对于每一个记录事件，审计记录需标识：事件发生的日期和时间、用户、事件类型及事件的成功和失败。由可信软件执行的单个操作，如果对用户是完全透明的，则不必进行审计。ＴＣＢ要保护审计数据，使得只有授权用户才能访问。
４．２．３ 保证
４．２．３．１ 操作保证
４．２．３．１．１ 系统体系结构
ＴＣＢ要在封闭的域中运行，使其不受外部干扰或篡改（例如：代码或数据结构的修改）。ＴＣＢ要隔离受保护资源，以满足访问控制和审计的需求。
４．２．３．１．２ 系统完整性
要提供相应的硬件或软件，用于定期确认ＴＣＢ中硬件或固件元素的正常运行。
４．２．３．１．３ 数据完整性
ＴＣＢ要提供控制机制，以保证多个主体对同一客体访问时客体中数据的正确性和完整性，并且不影响系统的正常运行。
４．２．３．２ 生命周期保证
４．２．３．２．１ 安全测试
必须对产品文档所述的安全功能进行测试，以确认其功能与文档描述相一致。测试要证实未经授权的用户没有明显的办法可以绕过或攻破ＴＣＢ的安全保护机制。测试还要搜索ＴＣＢ中明显的缺陷，这些缺陷可能导致ＴＣＢ中的外部主体能够违背资源隔离原则，或者对审计数据或鉴别数据进行未经授权的访问。
４．２．４ 文档
４．２．４．１ 安全特征用户指南
安全特征用户指南要描述ＴＣＢ提供的保护机制、使用指南、以及保护机制之间的配合方法，必须清楚地描述ＴＣＢ中安全机制之间的交互作用。
４．２．４．２ 可信设施手册
在可信设施手册中，要明确描述ＴＣＢ所支持的任何预定义用户或主体（例如：系统管理员），要对运行安全功能时必须受到控制的功能和特权提出警告，并清楚地描述上述受控功能和特权之间的关系。如果存在ＴＣＢ的安全操作的配置选项，应该予以标识。
要提供用于检查和维护审计文件的规程。对每类审计事件，还要提供详细的审计记录结构。
４．２．４．３ 测试文档
测试文档要描述安全保护机制的测试计划、测试步骤及其功能测试结果。
４．２．４．４ 设计文档
设计文档要描述产品的保护原理，并解释该原理在ＴＣＢ中的实现，如果ＴＣＢ由多个不同的模块组成，还应描述各模块间的接口。
４．３ 强制保护级（ｂ）
ｂ级的主要要求是：ＴＣＢ能维护敏感标记及其完整性，并利用敏感标记来实施强制访问控制规则，ｂ级的系统必须使系统中的主要数据结构带有敏感标记。系统开发者必须提供作为ＴＣＢ基础的安全策略实现模型以及ＴＣＢ的规约。
４．３．１ 安全策略
４．３．１．１ 自主访问控制
ＴＣＢ需定义并控制系统中主体对客体的访问控制，所采用的机制（如访问控制表）要明确规定特定主体对其它主体控制下的信息的访问类型。自主访问控制机制应限制访问权限的扩展。系统和用户设定的自主访问控制机制，能保证受保护的客体不会被未经授权的用户访问。对客体没有访问权限的用户，只有对客体有授权能力的用户才能为其指定访问权限。
４．３．１．２ 客体再用
在将ＴＣＢ的空闲存储客体池中客体初始指定、分配或再分配给一个主体之前，所有对于存储客体所含信息的授权都必须被撤销。当主体获得对一个已被释放的存储客体的访问权时，由原主体活动所产生的任何信息对当前主体都是不可获得的。
４．３．１．３ 标记
ＴＣＢ要维护与每一主体及其可能访问的系统资源相关的敏感标记，以此作为强制访问控制决策的基础。系统必须明确规定需要标记的客体（如文件、外部设备等）与不需要标记的客体（如：用户不可见的内部资源）。对于需要标记的客体，系统要明确定义客体标记的粒度。除了不需要标记的客体外，所有其它客体从ＴＣＢ外部观点看都要有明显标记。在输入未标记数据时，必须由授权用户向ＴＣＢ提供这些数据的安全级别，而且所有这些行为都可以由ＴＣＢ进行审计。
４．３．１．３．１ 标记完整性
敏感标记必须准确地表示出与其相关的具体主体或客体的安全级别。当ＴＣＢ输出敏感标记时，输出标记的外部表示要与其内部标记一致，并与输出的信息相关联。
４．３．１．３．２ 标记信息的输出
ＴＣＢ要能维护并审计与通信信道或Ｉ／Ｏ设备相关联的安全级别的任何变动。
４．３．１．３．３ 主体标记
在ＴＣＢ与用户交互期间，如果与用户有关的安全级发生任何变化，ＴＣＢ应立刻通知用户。
４．３．１．３．４ 设备标记
ＴＣＢ应能对所辖的物理设备指定最小和最大安全级。ＴＣＢ要使用这些安全级，在设备所处的物理环境中对设备的使用施加约束。
４．３．１．４ 强制访问控制
ＴＣＢ必须对所有可被ＴＣＢ外部主体直接或间接访问的资源（例如：主体、存储客体、物理设备等）实施强制访问控制策略。必须为这些主体和资源指定敏感标记（它们是级别和类别的组合），这些标记将作为强制访问控制决策的基础。所有由ＴＣＢ所控制的主体对客体的访问必须遵循以下规则：仅当主体的级别高于或等于客体的级别，且主体安全等级中的类别包含客体安全等级中的所有类别时，主体才能读客体；仅当主体的级别低于或等于客体的级别，且主体安全等级中的所有类别包含于客体安全等级中的类别时，主体才能写客体。ＴＣＢ要使用标识和鉴别数据来鉴别用户的身份，并确保用户的访问级和授权高于或等于代表该用户的ＴＣＢ外部主体的安全等级和授权。
４．３．２ 责任核查
４．３．２．１ 身份鉴别
用户在要求ＴＣＢ执行任何动作之前，必须首先向ＴＣＢ表明自己的身份。ＴＣＢ要使用保护机制（如：口令）来鉴别用户身份。ＴＣＢ必须保护鉴别数据，该数据不仅包含验证用户身份的信息（例如：口令），也包含确定用户访问级与授权的信息。ＴＣＢ要使用这些数据来鉴别用户的身份，并确保用户的访问级和授权高于或等于代表该用户的ＴＣＢ外部主体的安全等级和授权。为了防止任何未经授权的用户对鉴别数据进行访问，ＴＣＢ必须对鉴别数据进行保护。ＴＣＢ需提供唯一标识每个操作系统用户的机制，并将用户的所有可审计行为与用户的标识联系起来。
４．３．２．２ 可信路径
在对初始登录的用户进行鉴别时，ＴＣＢ要在它和用户之间维持一条可信信道。经由该路径的通信必须由专门用户或ＴＣＢ进行初始化。
４．３．２．３ 审计
ＴＣＢ必须能创建、维护由主体实施的操作（例如：读、删和改等）的审计记录。ＴＣＢ要记录下列类型的事件：使用身份鉴别机制；客体的引用；客体的删除；安全管理员的操作；以及其它与安全有关的事件。对于每一个记录事件，审计记录要标识：事件发生的日期和时间、主体、事件类型及事件的成功和失败。对于客体的引用及删除事件，审计记录还要包含客体名称。安全管理员应能够根据个体身份或个体安全等级有选择地审计一个或多个用户的行为。由可信软件执行的单个操作，如果对用户是完全透明的，则不必进行审计。ＴＣＢ必须保护审计数据，使得只有授权用户才能对它进行读访问。当发生与安全有关的事件时，ＴＣＢ要做到：（１）检测事件的发生；（２）记录审计踪迹条目；（３）通知安全管理员。
４．３．３ 保证
４．３．３．１ 操作保证
４．３．３．１．１ 系统体系结构
ＴＣＢ要在封闭的域中运行，使其不受外部干扰或篡改（例如：代码或数据结构的修改）。由ＴＣＢ控制的资源可以是系统中主体和客体的一个子集。ＴＣＢ要隔离受保护资源，以满足访问控制和审计的需求。ＴＣＢ要通过不同的地址空间来维护进程隔离。ＴＣＢ的内部要构造成定义良好的独立模块。ＴＣＢ的模块设计要保证使最小特权原理得以实现。ＴＣＢ需完整定义其用户接口，并且标识ＴＣＢ的所有元素。ＴＣＢ要有效地利用相关硬件把关键保护元素和非关键保护元素分隔开。
４．３．３．１．２ 系统完整性
要提供相应的硬件或软件，用于定期确认ＴＣＢ中硬件或固件元素的正常运行。
４．３．３．１．３ 可信设施管理
ＴＣＢ能支持独立的操作员和管理员功能。
４．３．３．１．４ 可信恢复
ＴＣＢ要提供诸如转贮和日志文件等机制，以保证在系统失效或其它中断发生后的数据恢复过程中不会导致任何安全泄漏。
４．３．３．１．５ 数据完整性
ＴＣＢ要定义及验证完整性约束条件的功能，以维护客体及敏感标记的完整性。
４．３．３．２ 生命周期保证
４．３．３．２．１ 安全测试
必须对产品文档所述的安全功能进行测试，以确认其功能与文档描述相一致。测试组应充分了解ＴＣＢ的安全功能的实现，并彻底分析其测试设计文档、源码和目标码，其目标是：发现设计和实现中的所有缺陷，这些缺陷会引起ＴＣＢ的外部主体能够实施违背强制或自主安全策略的某种操作；同时保证没有任何未授权主体能使ＴＣＢ进入一种不能响应其它主体发起的通讯的状态。ＴＣＢ应具有一定的抗渗透能力。必须消除所有被发现的缺陷，重新测试ＴＣＢ要证实这些缺陷已不再存在且没有引入新的错误。
４．３．３．２．２ 设计规约和验证
要证实ＴＣＢ所支持的安全策略模型符合其安全策略，并在产品运行的整个生命周期中维护这一模型。
４．３．３．２．３ 配置管理
在ＴＣＢ的整个生命周期期间，即ＴＣＢ的设计、开发和维护期间，要使用配置管理系统来控制对设计数据、实现文档、源代码、目标代码的运行版本、测试装置以及文档的任何更改。配置管理系统要保证与ＴＣＢ当前版本相关联的所有文档和代码之间的一致映射。要提供从源代码生成ＴＣＢ新版本的工具。要提供比较新版ＴＣＢ和原版ＴＣＢ的工具，只有在确定已按预期方案完成了修改后，才能启用新的ＴＣＢ版本。
４．３．４ 文档
４．３．４．１ 安全特征用户指南
安全特征用户指南要描述ＴＣＢ提供的保护机制、使用指南、以及保护机制之间的配合方法，必须清楚地描述ＴＣＢ中完全机制之间的交互作用。
４．３．４．２ 可信设施手册
在可信设施手册中，必须明确描述ＴＣＢ所支持的任何预定义用户或主体（例如：系统管理员），要对运行安全功能时必须受到控制的功能和特权提出警告，并清楚地描述上述受控功能和特权之间的关系。如果存在ＴＣＢ的安全操作的配置选项，应该予以标识。
要提供用于检查和维护审计文件的规程。对每类审计事件，还要提供详细的审计记录结构。
手册必须描述与操作员和管理员有关的安全功能，包括修改用户安全特征的方法。手册还要提供以下信息：如何一致地、有效地使用产品安全功能，安全功能之间的相互作用，以及操作规程、警告和特权。
４．３．４．３ 测试文档
测试文档要描述安全保护机制的测试计划、测试步骤及其功能测试结果。
４．３．４．４ 设计文档
设计文档要描述产品的保护原理，并解释该原理在ＴＣＢ中的实现方法，如果ＴＣＢ由多个不同的模块组成，还应描述各模块间的接口。应该具有ＴＣＢ所实施的安全策略模型的非形式化或形式化描述，并给出它足以实施该安全策略的理由。要标识特定的ＴＣＢ保护机制，并给出一个解释以证明它们满足模型。
