DIY编程器网

标题: 保障访问IT和门禁系统的安全方案的探讨 [打印本页]
作者: admin    时间: 2014-10-12 14:26
标题: 保障访问IT和门禁系统的安全方案的探讨
越来越多的机构采用新的业务模型，在这些模型中，单一证卡或智能手机可以支持多种门禁方式及用于多种场景和多种身份融合。用户携带独立证卡或其他设备既可用于开门、登录电脑和基于云端应用，同时也能够实现其他高价值的应用，包括电子支付、考勤管理和安全打印管理等。
       
        在这一套流程中，为单一证卡或智能手机提供IT和门禁系统凭证卡的需求日益增加。除了便利性外，将凭证卡融合到单一证卡或设备也可以显著提高安全性并降低运营成本。此外，还可以集中管理身份和门禁，整合任务，使机构快速、有效地在其基础设施内使用强大的身份验证，以保护所有重要的门禁和IT资源。
       
        新的集成凭证卡管理模型使组织朝四个重要方向发展：从证卡到智能手机；从读卡器到更方便的“轻触”式门禁；从公开密钥基础设施（Public Key Infrastructure，简称PKI）到更安全的简化解决方案；以及从传统PKI到真正融合的强大身份验证门禁。
       
        本白皮书专注于与IT和门禁融合解决方案相关的促成因素、挑战、部署选择和结果，也介绍了使用云端应用及服务、数据访问和门禁应用时，无缝用户体验的价值所在。此外，本白皮书还解释了将集中用户身份用于多个IT安全应用和门禁系统的统一注册流程的优势。
       
        了解融合的促成因素
       
        以前，各个机构专注于在周边建立强大的安防系统，以保护他们的门禁和IT资源。传统的门禁方法依靠用户出示ID卡进入大楼，然后在大楼内部，使用静态密码验证身份以访问IT资源。鉴于目前的高级持续性威胁（Advanced Persistent Threat）的性质以及与自带设备（Bring Your Own Device）相关的所有内部风险，这些安全访问方法存在不足。
       
        机构要求能够在他们的基础设施内更好地控制访问和使用强大的身份验证，以作为他们多层安全策略的一部分。但是，为企业数据保护选择有效的身份验证通常非常困难。市面上可用的绝大部分解决方案，或者在安全性方面存在问题，或者为机构带来的成本和复杂度问题，或者为用户带来体验方面的不足。
       
        员工希望方便地使用单一证卡或设备即可快速、轻松地访问其业务所需的资源。而为了实现该目标，机构必须部署一个可以保障从出入到访问公司计算机、数据、应用和云端的整体安全解决方案。他们必须将传统上独立的门禁和IT安全整合到一起，以协调管理用户的身份和门禁。
       
        融合门禁的价值
       
        真正融合的门禁包括一个安全策略、一个身份凭证卡和一个审核日志。一些组织通过定义门禁和资源使用权限的单一策略、单一主用户库以及用于简化报告和审计的单一日志记录，已经成功地实现了用户管理的融合。该方法可帮助企业：
       
        ●提供便利性——替换一次性密码（One Time Password，简称OTP）设备应用，用户无需携带多个设备或重新输入OTP，即可访问他们所需的所有门禁和IT资源。
       
        ●提高安全性——在整个IT基础设施的关键系统、应用甚至大门上实现强认证（而不是仅仅在周边）。
       
        ●降低成本——减少对多种门禁解决方案的投资，集中管理，并且将任务整合到包括发证、换证和注销证件的整套管理和流程中。
       
       
       
        探索多种部署方案
       
        在融合的门禁模式中，身份凭证卡可通过多种形式颁发，例如射频卡、智能卡（如ID卡），甚至智能手机。根据企业的要求和现有基础设施，建立该解决方案有多种方法。以下是三种最常见的模式：
       
        传统非接触式证卡：使现有的基于证卡的门禁系统利用iCLASS、iCLASS Seos MIFARE和MIFARE DESFire等技术，将身份验证扩展到企业网络和应用。软件需部署到最终用户的工作站，并将非接触式读卡器连接至或嵌入到该工作站，由此无需实际插入读卡器即可“读取”该证卡。这为用户带来了便利，他们可以使用相同的证卡开门、轻触登录个人电脑或便携式电脑，从而访问他们的计算机、公司应用程式和云端服务。
       
       
       
        该方法不使用通过证书授权将公开密钥和用户身份捆绑到一起的PKI.用于美国联邦机构的PKI强认证，是各个联邦机构及其承包商的计算机桌面登录和数字文档签名的关键元素。数字证书包括用户公开密钥，其保存在个人身份验证（Personal Identification Verification，简称PIV）卡上，该证卡利用了智能卡和生物识别技术（一种数字签名的指纹模板），并且支持多因子验证方法。除了依赖共享的身份验证密钥，也可以使用一对公开密钥和私人密钥，这些密钥联系到一起，以便一个密钥拥有的信息只能使用另一个密钥进行解码或验证。Federal Bridge用于建立相互认证机构的PKI之间的互信渠道（即，单独和独立的基础设施，每个拥有自身的根证书授权），从而保障参与Federal Bridge的政府机构之间安全交换数字签名和证书。
        传统的非接触式方法解决了PKI的许多关键管理挑战，但是该方法支持的应用有限，并且无法提供与PKI解决方案一样的安全强度。非接触式PKI模型正部署到医院、学校和其他应用环境中，在这些环境中，多个用户需要快速接连访问相同的工作站。此外，该模型还被用于过渡解决方案，法令要求工作站和应用受到强认证的保护，例如刑事司法信息系统（CJIS）。
       
        双芯片证卡：在智能卡上嵌入非接触式芯片用于物理门禁，嵌入接触式芯片用于计算机桌面登录。使用卡管理系统（Credential Management System，简称CMS），可以在接触式芯片上管理PKI证书和OTP密钥等凭证卡。
       
       
       
        双芯片证卡模型在内部网络拥有敏感的知识产权或有客户数据的大中型企业中广受欢迎，因为该模型可以提供强大的安全性。此外，该模型使企业能够简化IT安全基础设施的管理，并利用现有的门禁投资，因为在许多情况下，CMS可以直接集成到门禁管理系统（通常被称为门禁头端）中。
       
        双接口芯片证卡：利用单一的PKI芯片，拥有接触式和非接触式接口，以支持门禁和计算机桌面登录。该证卡可以支持接触式读卡器，用于计算机桌面登录应用，例如登录计算机或为电子邮件签名，也支持PKI身份验证，用于门禁。
       
       
       
        双接口证卡模型主要适用于美国联邦政府组织，OMB-11-11法令要求将FIPS 201规定的PIV凭证卡用于门禁。默认情况下，非接触式接口上的PKI用于门禁会导致效率降低。为了解决该问题，FIPS 201-2计划允许使用有关身份验证和密钥商定协议的隐私访问控制身份和票务开放协议（OPACITY），这将使关键任务的效率提高大约四倍。它还将提供安全的无线通信，从而允许用户在非接触式接口使用PIN和生物识别技术。这将进一步加强门禁和计算机桌面登录的身份验证。
       
        为大门增加强身份验证
       
        融合的一项重要优势是，组织能够利用现有的身份凭证卡投资，在公司网络、系统和大门上，建立完全互操作的多层安全解决方案。强认证不仅越来越多地用于远程登录，而且还用于桌面计算机、关键应用、服务器、云端系统和设施。这将要求为出入口增加强身份验证。
       
        实施强大身份验证的场所之一是用户持有PIV卡的联邦机构。为了使用PIV卡进入大楼，根据认证中心提供的证书撤销列表检查PIV卡的数字证书。PKI身份验证是一种非常高效且可互操作的方法，不仅用于计算机桌面登录以保护数据，而且用于门禁以保护设施，后者被称为“出入口PKI”。
       
        随着预算的批准，联邦机构正在分阶段实施出入口PKI.为了确保实现该目标，他们正在配置基础设施，以便当条件就绪时，使基础设施快速、轻松地升级到PKI强大身份验证方式，以用于门禁。例如，他们首先将PIV持卡人注册到前端系统中，然后部署美国总务管理局（General Services Administration）规定的过渡性读卡器。该读卡器无需使用任何FIPS-201身份验证技术，即可读取证卡的唯一识别符，并且将其与注册的持卡人匹配。以后，可以现场重新配置这些过渡性读卡器，以支持多因子身份验证。
       
        随着FIPS 201的发展以及越来越多的产品的支持，预计出入口PKI将被广泛采用。此外，将有机会使用商业身份验证（Commercial Identification Verification，简称CIV）卡以较低的成本部署PKI.CIV卡在技术上与PIV卡相似，但是不包括与联邦政府所信任的额外要求。与联邦机构不同，CIV卡用户不需要从可信方购买证书，或支付年度维护费用，而是生成自身的证书。虽然为证书存储增加额外空间使证卡增加少量成本，但该少量成本将带来有价值的额外优势——更强大的出入身份验证。以城市机场为例，该场所将能够同时使用CIV证卡和联邦交通安全管理局（Transportation Security Administration）员工携带的PIV证卡。机场管理层将能够建立单一的门禁系统，以同时支持机场员工和在机场工作的联邦机构员工，并且通过强认证确保更高的安全性。
       
        在整个门禁和计算机桌面登录基础设施中扩展强认证，对企业至关重要。机构需要一系列的身份验证方法，以及轻松支持不同用户并保护不同资源的灵活性。通过简单易用的解决方案，企业可以从托管设备和非托管设备，安全访问企业资源。企业无需建立或维护多个身份验证基础设施，即可使用单一的解决方案安全访问从设施、大门、复印机到VPN、终端服务、云端应用的所有企业资源。
       
        移动设备何去何从？
       
        众所周知，用户越来越多的使用移动设备，并且将自带设备（BYOD）带入机构环境中，使用智能手机、笔记本计算机和平板电脑访问所需的企业资源。根据ABI的统计，截止2015年，将有70亿台无线设备接入网络，这接近于全球每人一部移动设备。
       
        各个组织正在努力支持这些移动设备的接入，同时寻找将用户的移动设备作为携带门禁和计算机桌面登录凭证卡平台的方法。目前已有试点单位（例如亚利桑那州立大学的一个设施）证明了使用手机携带门禁凭证卡的可行性。联邦政府也正在考虑移动门禁。FIPS-201-2预计包括一些扩充部分，例如，可以在手机安全元件（SE，与证卡使用相同的加密服务）中携带的派生凭证卡概念。
       
        移动门禁要求重新考虑如何管理门禁凭证卡以及如何将他们移植到智能手机的问题，以便机构可以选择在他们的门禁系统中使用智能卡或移动设备。为此，HID Global为其iCLASS SE平台建立了一个新的数据模型，称为Secure Identity Object （SIO），该数据模型可以在任何设备上代表多种形式的身份信息，这些设备能够在公司的Trusted Identity Platform （TIP）安全边界和中央身份验证管理生态系统内进行工作。TIP使用安全信道在通过验证的手机、手机安全元件、其他安全介质和设备之间传输身份信息。TIP和SIO的集成不仅提高了安全性，而且提供了适应未来需求的灵活性，例如为卡添加新的应用。它旨在提供可靠的安全性，因此在BYOD环境中特别具有吸引力。
       
        通过移动门禁模型，智能手机可以支持任何门禁数据，包括用于门禁、电子支付、生物识别、PC登录以及许多其他应用的数据。身份验证凭证卡将存储到移动设备的安全元件上，而云身份提供模型将消除凭证卡被复制的风险，同时使发行临时凭证卡、取消挂失凭证卡、监控和修改安全参数更轻松。用户将能够在手机上携带多种门禁凭证卡以及OTP电脑登录密钥，这样他们只需轻触个人平板电脑，即可完成身份验证登录网络。通过将手机上的移动密钥和云应用单点登录能力集成到一起，可以将传统的双因子身份验证和精简的多个云应用登录整合到用户很少丢失或遗忘的单一设备上。此外，同一部手机也可以用于开门和许多其他应用。
       
        由于用于门禁和计算机桌面登录的手机和其他移动设备通常不属于机构，因此需要解决一些挑战。例如，当学生从大学毕业时，不会向学校上交手机，同样当员工辞职时，员工也不会向公司上交手机。在保护企业数据和资源的同时，保障BYOD用户的个人隐私也非常关键。IT部门无法有效控制这些自带设备，或者设备所携带的具有潜在危险的个人应用，并且也不太可能将带有杀毒软件和其他防护软件的标准镜像加载到自带设备中。我们需要寻找解决这些挑战以及其他挑战的创新途径。尽管存在风险，使用配备安全元件或类似保护设备的手机，为建立强大的新身份验证模型提供了机会，使手机成为凭证卡的安全、便携的存储库，这样手机既可以应用于远程数据访问的轻触强认证，也可以应用于大楼或公寓的门禁，应用前景非常广阔。
       
        移动性正推动融合，门禁安全小组和IT安全小组针对移动性合作提出新的解决方案。最终提出的解决方案以高性价比的方式轻松管理手机上门禁卡和IT访问凭证卡，同时提供与使用实体证卡相同的安全性。
       
        实现真正融合的优势
       
        将门禁和IT资源访问集成到单一设备上，可以用于许多应用，因而改善了用户体验，同时提高了安全性并降低了部署和运营成本。未来将不再需要多个提供和注册IT和门禁身份的独立流程。取而代之的是在单一身份管理中采用一个统一工作流程，从而实现机构的融合。各个机构将能够保障大楼和IT资源的无缝安全访问，例如计算机、网络、数据和云端。一个有效的解决方案将能根据需要扩展以保障其他资源的安全访问，以支持完全互操作的多重安全策略，并可在当前和未来保护机构的大楼、网络、系统和应用的安全。



欢迎光临 DIY编程器网 (http://diybcq.com/) Powered by Discuz! X3.2