a2k学习笔记3.4

上传人:小** 文档编号:89121873 上传时间:2019-05-18 格式:DOC 页数:15 大小:401.50KB
返回 下载 相关 举报
a2k学习笔记3.4_第1页
第1页 / 共15页
a2k学习笔记3.4_第2页
第2页 / 共15页
a2k学习笔记3.4_第3页
第3页 / 共15页
a2k学习笔记3.4_第4页
第4页 / 共15页
a2k学习笔记3.4_第5页
第5页 / 共15页
点击查看更多>>
资源描述

《a2k学习笔记3.4》由会员分享,可在线阅读,更多相关《a2k学习笔记3.4(15页珍藏版)》请在金锄头文库上搜索。

1、第三部分 Architect 2004 technical section第二十集 系统安全设计系统安全的设计流程分析潜在的威胁评估威胁并设定优先级针对威胁进行分类根据威胁选择安全技术设计对应的安全服务针对系统安全性的威胁标识欺骗(Spoofing identity)篡改数据(Tampering with data)可否认性(Reputability)信息泄露(Information disclosure)拒绝服务(Denial of service)特权升级(Elevation of privilege)设计的基本原则使用成熟的安全系统以小人之心度输入数据外部系统是不安全的最小授权减少外部接

2、口缺省使用安全模式安全不适似是而非从Stride思考在入口处检查从管理上保护好你的系统常用安全技术l 认证l 授权l 标识流l 审计减少STRIDE威胁系统安全的五个角度认证授权安全通讯属性管理审计第二十一集 系统安全的五个角度系统安全的五个角度认证授权安全通讯属性管理审计认证什么是认证认证操作应该在哪里实现认证的设计目标是什么如何进行认证设计标识流常用传递标识流的方法l 传递用户信息,重新认证l 传递认证凭证l 单一认证解决方案l 运行在同一上下文中异构的认证环境单一认证服务l 支持系统间交换l 支持异构平台和不同的认证方法l 自定义凭证l 认证信息映射认证机制成熟的认证系统(活动目录; N

3、ovell NetWare)自定义认证系统l 自定义标识对象l 应用中不要保存密码,保持凭证l 审计所有的失败认证l 提供访问认证凭证的方法界面层的认证在用户界面组件中对于Web应用,可采用(匿名,NTLM,Form, 基本/摘要,证书,Passport)Windows应用,可采用(Windows集成认证,自定义认证)注意:不需要在界面流程组件中实现认证业务组件的认证业务组件必须要认证,也可以通过服务接口认证主要调用者包括(用户界面组件,界面流程组件,业务流程组件,其它业务组件)调用者标识包括(具体的用户,服务帐号,外部应用标识)业务实体的认证访问内部业务实体无需认证访问外部业务实体必须认证通

4、过辅助的认证组件实现认证过程数据访问组件的认证(服务帐号)服务帐号 使用情况:l 不能使用扮演方式l 对帐号缺少控制l 应用系统和存储系统采用不同的认证机制l 性能和扩展性要求如下情况不建议使用服务帐号方式:l 无法可靠的保存凭证l 不同的用户具有不同的访问权限l 审计需求数据访问组件的认证(扮演)扮演 使用情况:l 数据存储需要根据用户信息进行授权l 审计每个用户的活动如下情况不能使用扮演:l 需要很高的性能和扩展性扮演方式:l 平台的扮演服务l 单一认证服务授权授权的两个方面:l 用户的权限l 代码的执行权限基本方法l 系统授权l .NET的代码访问权限机制l 应用本身的授权管理用户访问权

5、限访问控制列表(ACLs)l 分级:(高级覆盖低级;同级类Deny优先)基于角色的授权l 减少代码的修改l 减少维护工作量l 角色可交叉代码访问权限从代码属性来设定代码的执行权限:l 安装目录l 加密方式l 数字签名l 站点l 链接l 区域自定义应用系统的授权Principal对象经过认证的授权数据访问授权信息中不要包含凭证和认证信息使用缓存技术提高性能提供离线功能可扩展的架构同时使用代码访问权限用户界面组建的授权当需要l 显示或者隐藏域l 激活或者关闭控件方式l 传递必须的信息l 利用个性化技术l 利用代码访问权限流程控制组件的授权当需要l 控制交互流程l 自定义交互流程中的步骤方式l 主动

6、避免启动无权的交互流程l 使用Principal对象l 利用代码访问权限(只有用户界面组件会访问流程控制组件)业务组件的授权业务组件应该进行授权检查方式l 业务流程授权独立于用户环境l 使用基于角色的授权机制l 同时检查认证类型业务实体的授权业务实体组件应该进行授权检查方法:l 确保使用业务实体组件的物理层具有相同的Principal对象l .NET中可以利用权限检查定义l 利用代码访问权限服务代理和服务接口的授权服务代理和服务接口都必须做授权操作方式:l 尽量使用系统提供的授权机制(iis授权,windows的访问控制)数据访问组件的授权当需要:l 在不可信任的环境中共享数据访问对象l 保护

7、数据存储提供的其它功能方式:l 利用系统提供的授权机制:Enterprise Services角色或者Principal Permission定义l 设置服务帐号集l 扮演l 代码范围权限(需要考虑用户界面、流程控制、业务、业务实体组件)l 类别检查安全通讯针对信道的安全l SSLl IPSecl 自定义加密信道l VPNs针对数据的安全l 数字签名l 加密信息(全部,敏感信息)界面层的安全通讯用户界面组件中的敏感信息需要安全通讯流程控制组件不需要于界面组件间的安全通讯方法:l 不要显示或者传输敏感信息l 队Web应用采用SSLl 对Windows应用采用加密数据并签名的手段中间层的安全通讯服

8、务代理(建立安全的通讯信道)服务接口(验证通讯的安全)数据层的安全通讯数据访问组件通常依靠数据访问辅助组件进行连接和传输数据访问辅助组件实现安全通讯方式:l 选择合适的安全通讯方式l 实现加密机制l 建立安全信道属性管理属性管理的数据包括l 用户的系统配置l 用户数据相关技术l 缓冲技术l 加密和Hashing存储方式l 活动目录l 数据库l 本地文件审计审计可以看作是“安全的日志”l 用户操作l 业务活动审计考虑的安全重点l 反抵赖和防篡改l 安全的存储常用技术l 数字签名l 基于平台的认证l 代码访问权限l 可利用Principal对象实现接口界面层审计用户界面组件,仅针对全局事件进行用户

9、操作审计(登录,注销,密码修改,安全方面的异常)通常不需要对流程控制组件进行审计业务层的审计业务流程组件是主要的业务活动审计目标审计重点:操作者;发生时间;业务活动数据层的审计数据层可进行细节的审计注意:对性能的影响;可能需要结合数据存储提供的审计功能第二十二集 应用层的通讯设计通讯策略三要素:同步性、格式和协议模式l 无连接:基于消息l 有连接:DCOM/.NET Remoting考虑因素:l 扩展性l 可用性l 可管理性通讯选择应用间通讯:l 建议采用消息方式(Web Service Message Queuing)应用内通讯:l 尽量使用基于消息机制的层间通讯l 例外:事务/身份流建议:

10、l 尽量使用Queue和Cache技术l 在UI、SI和SA上使用异步技术l 评估封装异步操作实现同步操作总线模型消息总线同时应用于层间和外部应用优点l 模块化提高集成性l 异构平台问题l 业务层依赖UI层的信息l 消息总线要支持多种通讯l 消息总线要实现满足层间和外部应用的灵活性和可用性总线模型消息总线只应用与外部应用之间优点l 系统效率l 设计和实现简单问题l 降低了系统的扩展能力异步消息通讯机制的优点扩展性和可用性更短的响应时间更容易实现负载均衡和容错可实现透明的服务定位更符合现实的业务模式更容易定义SLA传输协议的无关性异步消息通讯机制的缺点无状态无消息匹配机制消息延迟没有事务处理可能

11、存在重复性消息无消息序列异步处理需要考虑的问题状态通知和轮询处理超时情况创建和执行补偿操作基于消息的应用核心应用大型分布式系统对外的服务应用需要离线操作的应用可能需要处理同步冲突异步通讯基于消息的技术(Message Queue, XML Web Service) 基于连接的技术(.Net Remoting DCOM)Message Queue优点和特点l 基于Internet的存储转发机制l 确保顺序和可靠性的通讯机制l 可以利用群技术实现高可靠性设计要点l 发送和接收方式l 消息格式其它异步技术Queued ComponentMessage Queuing triggersCustom R

12、eceiversXML Web service proxyNET Remoting channels同步技术Channel技术l 端点l 协议l 格式同步技术需要事务流或者安全认证信息DCOM ,XMLWebService需要认证调用者以IIS为Hosting的.NET Remoting Channel通讯的格式、构架和协议决定因素:l 发送和接收的可控性l 对性能和安全的要求l 与企业外应用的交互要求第二十三集 应用系统的运营管理应用系统得运营管理异常管理系统监控业务监控元数据管理配置管理服务定位异常管理异常管理的基本概念:l 检测异常l 记录和报告异常l 异常监控每个应用都必须考虑异常管理

13、异常的捕获和处理最好在层边界上进行异常处理流程异常的信息异常可以分为两种l 业务异常l 技术异常异常的信息通常包括l 发生时间、计算机名l 应用信息(Domain、 Assembly名、Assembly版本等)l 异常发生源、信息、类型l 异常栈、调用栈l 进程ID、线程ID、用户ID等异常的传递异常向上逐层传递l 封装的异常应该包含原异常异常需跨层传递。除非:l 服务接口无需将异常返回调用者l 用户界面组件应该将异常转换为适当的消息对于单向的通讯信道,需要实现异常信息的传递机制异常的传递方式通常有三种异常传递方式l 自动传递l 捕获然后重新Throwl 捕获、封装然后产生新的封装异常发布异常信息通过用户界面组件发布系统日志文件数据库界面层的异常处理流程控制组件的异常通常来自l 业务流程组件l 数据访问组件异常的处理l 重试l 将问题提交给用户l 停止、重启、继续界面流程注意:l 不要将异常信息直接暴露给用户l 由用户界面组件发布异常信息业务组件的异常处理业务组件的异常通常来自l 数据访问组件。包括技术异常和业务异常业务组件要向上传递异常l 业务组件产生新的异

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 商业/管理/HR > 管理学资料

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号