A2K学习笔记34.docVIP

第三部分 Architect 2004 technical section 第二十集 系统安全设计 系统安全的设计流程 分析潜在的威胁 评估威胁并设定优先级 针对威胁进行分类 根据威胁选择安全技术 设计对应的安全服务 针对系统安全性的威胁 标识欺骗（Spoofing identity） 篡改数据（Tampering with data） 可否认性（Reputability） 信息泄露（Information disclosure） 拒绝服务（Denial of service） 特权升级（Elevation of privilege） 设计的基本原则 使用成熟的安全系统 以小人之心度输入数据 外部系统是不安全的 最小授权 减少外部接口 缺省使用安全模式 安全不适似是而非 从Stride思考 在入口处检查 从管理上保护好你的系统 常用安全技术 认证 授权 标识流 审计 减少STRIDE威胁 系统安全的五个角度 认证 授权 安全通讯 属性管理 审计 第二十一集 系统安全的五个角度 系统安全的五个角度 认证 授权 安全通讯 属性管理 审计 认证 什么是认证 认证操作应该在哪里实现 认证的设计目标是什么 如何进行认证设计 标识流 常用传递标识流的方法 传递用户信息，重新认证 传递认证凭证 单一认证解决方案 运行在同一上下文中 异构的认证环境 单一认证服务 支持系统间交换 支持异构平台和不同的认证方法 自定义凭证 认证信息映射 认证机制 成熟的认证系统（活动目录； Novell NetWare） 自定义认证系统 自定义标识对象 应用中不要保存密码，保持凭证 审计所有的失败认证 提供访问认证凭证的方法 界面层的认证 在用户界面组件中 对于Web应用，可采用（匿名，NTLM，Form， 基本/摘要，证书，Passport） Windows应用，可采用（Windows集成认证，自定义认证） 注意：不需要在界面流程组件中实现认证 业务组件的认证 业务组件必须要认证，也可以通过服务接口认证 主要调用者包括（用户界面组件，界面流程组件，业务流程组件，其它业务组件） 调用者标识包括（具体的用户，服务帐号，外部应用标识） 业务实体的认证 访问内部业务实体无需认证 访问外部业务实体必须认证 通过辅助的认证组件实现认证过程 数据访问组件的认证（服务帐号） 服务帐号 使用情况： 不能使用扮演方式 对帐号缺少控制 应用系统和存储系统采用不同的认证机制 性能和扩展性要求 如下情况不建议使用服务帐号方式： 无法可靠的保存凭证 不同的用户具有不同的访问权限 审计需求 数据访问组件的认证（扮演） 扮演 使用情况： 数据存储需要根据用户信息进行授权 审计每个用户的活动 如下情况不能使用扮演： 需要很高的性能和扩展性 扮演方式： 平台的扮演服务 单一认证服务 授权 授权的两个方面： 用户的权限 代码的执行权限 基本方法 系统授权 .NET的代码访问权限机制 应用本身的授权管理 用户访问权限 访问控制列表（ACLs） 分级：（高级覆盖低级；同级类Deny优先） 基于角色的授权 减少代码的修改 减少维护工作量 角色可交叉 代码访问权限 从代码属性来设定代码的执行权限： 安装目录 加密方式 数字签名 站点 链接 区域 自定义应用系统的授权 Principal对象 经过认证的授权数据访问 授权信息中不要包含凭证和认证信息 使用缓存技术提高性能 提供离线功能 可扩展的架构 同时使用代码访问权限 用户界面组建的授权 当需要 显示或者隐藏域 激活或者关闭控件 方式 传递必须的信息 利用个性化技术 利用代码访问权限 流程控制组件的授权 当需要 控制交互流程 自定义交互流程中的步骤 方式 主动避免启动无权的交互流程 使用Principal对象 利用代码访问权限（只有用户界面组件会访问流程控制组件） 业务组件的授权 业务组件应该进行授权检查 方式 业务流程授权独立于用户环境 使用基于角色的授权机制 同时检查认证类型 业务实体的授权 业务实体组件应该进行授权检查 方法： 确保使用业务实体组件的物理层具有相同的Principal对象 .NET中可以利用权限检查定义 利用代码访问权限 服务代理和服务接口的授权 服务代理和服务接口都必须做授权操作 方式： 尽量使用系统提供的授权机制（iis授权，windows的访问控制） 数据访问组件的授权 当需要： 在不可信任的环境中共享数据访问对象 保护数据存储提供的其它功能 方式： 利用系统提供的授权机制：Enterprise Services角色或者Principal Permission定义 设置服务帐号集 扮演 代码范围权限（需要考虑用户界面、流程控制、业务、业务实体组件） 类别检查 安全通讯 针对信道的安全 SSL IPSec 自定义加密信道 VPN