论坛公告:应用容器安全指南(SP800-190)中文版   美国政府宣布禁用卡巴斯基软件   《中华人民共和国网络安全法》讨论帖   新手报到专用帖   【论坛公告】关于本站广告贴泛滥问题的整理通知   

当前时区为 UTC + 8 小时


发表新帖 回复这个主题  [ 1 篇帖子 ] 
作者 内容
 文章标题 : 身份,授权和访问管理建议
帖子发表于 : 2013-10-30 10:05 
离线
高级用户

注册: 2010-01-29 11:13
最近: 2014-08-07 09:30
拥有: 241.00 安全币

奖励: 0 安全币
在线: 1051 点
帖子: 203
联邦建议
o 云计算使用者(consumer)、云计算实施者(implementer)、云计算提供者(providers)应该在内容和“联邦”的定义上达成一致;
o 实施者应该理解什么是信任关系、已有的信任传递和双向信任关系的需求
o 可能的情况下,实施者应该基于开源的标准如安全断言标记语言(SAML)和OAuth协议
o 如果使用“桥接”或“联邦枢纽”,实施者应当理解已经存在于枢纽内不同成员之间的信任的本质与关系。当新成员接入云或与其他桥结盟时,要理解其对自身授权规则的影响。
o 实施者应该明白公开身份认证提供商如Facebook、Yahoo或Google提供了没有担保的身份认证资源,这些认证低等级、通常自我断言(self-asserted),而且将来他们不会联邦其他的提供商。
o 实施者应该反对不好的方案设计,诸如从与云方案访问管理连接的数据集抽取身份信息等。这样的例子如内网中虚拟专用网和网外专业线路。
开通和治理建议
o 所有的属性应该来源于尽可能权威或优异的资源
o 作为一条规则,云服务或应用自身应该避免成为优质认证资源
o 云服务或应用自身应该只是优质的属性直接控制资源
o 所有属性的消费应该有一个已知的信任等级
o 所有属性的消费应该与身份认证衔接
o 一个确定实体的识别器应该标记所有的属性消费
o 任何一个属性应该有一个符合目标生命周期
o 任何一个身份(及相关识别器)应该有一个符合目标的生命周期.
权限(entitlement)建议
o 权限过程中的各部分应该清晰定义
o 应该为同意与认可权限规则清晰地指派责任
o 审计权限规则的频率应该清晰的定义
o 权限过程应该聚焦在使用最小特权原则设计产生简单最小化的权限规则
o 权限过程应该聚焦在设计暴露最少的身份信息或者避免一起消费身份信息的权限规则
o 短暂的属性(如位置定位)需要通过交易的有效期重新使得授权规则生效而实现实时属性检查
o 权限规则应该由某个过程进行触发(或者某个初始化意图,例如针对环境外的钱财转移)。在某些环境中,最优的权限规则需要采取屏蔽这些功能的措施。在其他的环境,最好的措施需要额外的身份或属性信息,期望确保实体在某点有权执行这个过程
o 实施者(implementer)应该确保双向的信任关系以确定交易中最优的安全关系,这需要在权限过程中进行定义。
o 权限规则的设计应该包括经过委托(Delegation) 122 才能被间接实体访问的部分(不是所有的)信息,而直接实体能访问所有信息的规则。
o 尽管权限规则的设计者需要考虑系统、组织和涉及实体的司法管辖,权限的设计应该包括访问的没收(包括司法占有)。在实现任何访问没收之前,应该听取法务方面的意见。
o 在实际的接口管理、工具或其他可视化技术方面,需要使用它们帮助权限管理,帮助确保互操作满足商业需求或规范(如SOX的职责分离)。
授权(authorization)和访问建议
o 实施者应该确保服务有一个入口或出口功能符合标准如可扩展访问控制标记语言(OASIS XACML:eXtensible Access Control Markup Language)
o 当在云计算环境中使用策略决策点(PDP),为把握访问的整体状况实施者应该知道如何将授权决定日志抽取或整合到一个组织日志中


o 实施者应该确保现有(遗留)服务能够使用策略决策点(PDP) 和策略执行点(PEP) 进行交互
o 实施者应该确保任何策略决策点(PDP)能恰当的解释在授权过程中定义的授权规则
o 如果需要中心策略服务器时,实施者应该考虑使用策略即服务(policy-as-a-service)作为策略服务器 (例如,云混搭cloud mashups).
架构建议
o 实施者应该确定任何云服务提供商能够提供授权(Authorization)管理PEP /PDP,这些可通过权限(Entitlement)规则来配置
o 实施者应该确定身份、权限(Entitlement)、授权(Authorization)及访问管理(IdEA123)的所有组件能够正确的协同工作
o 实施者应该确定策略决策点(PDP) 和策略执行点(PEP)是使用的标准协议(如可XACML124),而避免使用专用的协议(如直接网络服务或者中间件呼叫)
o 实施者应该确定任何强认证服务都是遵从OATH 125的。使用与符合OATH规定的解决方案,组织能够避免被锁在一家认证服务上的凭证里面
o 云服务和应用应该具有支持来自使用SAML的权威资源的消费认证的能力
o 实施者应该确保服务有一个导入或导出功能符合标准如XACML
o 实施者应该确定服务能够通过安装在云基础设施上的PEP /PDP和用于实践检测或审计的策略检测点交互
o 实施者应该确定关于授权决定和接入的记录能够被允许以一种常见的格式使用标准安全协议登陆。
权限(entitlement)建议
o 实施者应该确定权限过程中定义的每一个身份和属性匹配相应的信任级别,这些不仅身份/属性自身需要,而且要与所提供的资源相匹配
o 实施者应该确定所有的身份/属性提供组织的身份信息
o 实施者应该确定无论何时尽可能充分高效的利用属性信息
o 实施者应该确定属性的使用能够正确地推导出正确的结论(你的上下文可能和提供属性的源不一样)
o 实施者应该确定身份/属性源既要在数据质量的标准上,又要在治理机制上满足你的需求
o 消费者应该明白信誉是信任机制的重要资源。通过权限定义,消费者应意识到细小的价值转变也会引起交易信任度的增加,这可能会使得随后的大规模交易出现欺诈。.
开通(provision)建议
o 提供商应该理解无论SPML 或SCIM可能会是规定中的切实可行选项
o 当准备账户时,实施者应该遵循最小特权(least privilege)的规则,在像计算机设备的实体案例中,到组织机构资产注册表的链接(link)是不错的做法
o 大多数系统和应用在用户和接入上有一对一的关系,没有代表的概念
o 实施者应该确定开通(provisioning)和取消(de-provisioning)对于用户身份而言没有限制,架构必须包括所有实体类型的授权
o 实施者应该确定provisioning 和de-provisioning应该实时操作
o 如果要求权限必须很精确,那么提供商对身份和属性的维护工作非常关键

身份合规与审计建议
o 实施者应该确定来自权限规则或授权过程的可用日志可被利用
o 实施者应该确定日志能被整合进一个更为广泛系统,已确保日志的可用、及时、格式和传输安全是合适的
o 当记录登录决定时,实施者应该将属性与在作决定时的授权逻辑一起组合,结果也应该记录
o 所有云参与者应该记住,在会话的整个生命周期中,那些具有临时组件的属性需要重新确认(revalidated)和重新记录重登录得
o 当记录PII或SPI时,只要有可能,实施者在记录时应该使用属性变形(derivation)以最小化PII或SPI的暴露
o 消费者应该意识到包含PII或SPI的记录也将适用于数据保护法规.
应用设计建议
o 实施者应该使用ITU X.805关于用户、系统和管理层的三层定义以确保隔离
o 在应用设计时,实施者应该使得对身份和属性的需要最小化
o 可能的情况下,设计云系统时尽量使用外部资源的身份和属性
o 实施者应该确保云系统支持标准SSO联邦格式,如SAML和OAuth


o 实施者应该采取整体策略解决安全,将身份和属性的使用贯穿系统全层
o 实施者应当了解,互认证在所有的层次都很关键,在云环境中甚至更重要。正如云环境需要实体和其他系统去验证一样,云系统也同样需要反向的验证。
数据保护建议
o 实施者应该最小化使用和存储PII或SPI,在授权过程的设计阶段应该这样做,确保在只在身份和属性的关键过程才使用
o 实施者应该考虑下述技术,以最小化PII或SPI的暴露的程度
加密•
令牌•
o 实施者应该考虑使用最佳的方法去保护SPI,如使用双密钥方法,一个被主体拥有(或密钥反抗其他人登录),另外一个供系统处理过程使用
o 实施者应该理解如何约束或停止管理者访问PII和SPI
o 实施者应该理解在被委托的合法时间期限内如何处理“主体访问请求127”,尤其是当数据被云系统保有(held),而不被已收到请求的组织拥有(owned)或管理(managed)
o 如果需要分享PII或SPI,消费者需要理解如何获得PII/SPI的主体的同意
o 实施者应该减少存储PII/SPI,尤其是非权威的资源, 只参考那些来自于权威资源,而不是存储它们
o 实施者应该理解PII/SPI(不管是身份或是属性)在维护工作中及时处理的流程
身份认证实现建议
o 实施者应该从身份重用的原则开始,而不是新用户或设备唯一注册
o 消费者应该理解现有的身份资源能提供足够的信任级别和重用
o 提供商应该理解什么样的用户和设备的属性可被断言(asserted)为足够信任级别以用于进行交易
o 在适当的时候,消费者应该允许低级别认证下做低风险交易。只在交易价值/风险的增加时,逐步升级(escalate)所需的身份
o 当考虑用户和用户设备时,在授权(entitlement)过程中,提供商应该提供所需身份和属性的关键评估
o 提供商应该理解能够用于用户设备以增加保障水平的技术,尤其是可后台运行的技术
o 消费者应该理解用户设备管理可能不被执行的地方,及其提供的保障级别,保障级别有可能从根本无保障到有很好的保障
o 消费者应该理解在某种保障级别和法律责任存在时,用户设备交易是否会导致问题(issue)出现

如需了解更多云计算安全管理知识,欢迎加入我们信息安全学习的大家庭http://www.sitc.net.cn/ccsk_if.aspx,SITC的大平台让您不仅学到知识,更能收获良师益友。
联系人:Yvone.qiu
联系电话:021-62126633-6025
E-Mail:qiuyj@shic.gov.cn
微博:@4C学习圈_SITC乐友


回到顶部
 奖励本帖 用户资料  
 
显示帖子 :  排序  
发表新帖 回复这个主题  [ 1 篇帖子 ] 

当前时区为 UTC + 8 小时


在线用户

正在浏览此版面的用户:没有注册用户 和 2 位游客


不能 在这个版面发表主题
不能 在这个版面回复主题
不能 在这个版面编辑帖子
不能 在这个版面删除帖子
不能 在这个版面提交附件

前往 :  
华安信达(CISPS.org) ©2003 - 2012