安全性对于 CICS意味着什么?
CICS® 交易服务器本身具有安全设施,它还受益于集成到 操作系统和 硬件中的安全功能。 z/OS® IBM Z® 您可以根据组织的安全目标以及您运行的 CICS 环境和应用程序(包括第三方产品)的类型,选择如何应用这些功能。
喜欢视频?
CICS 视频中还举例说明了安全基础知识。 参见视频:安全对于 CICS 意味着什么?
你信任谁
安全性基于信任。 CICS Transaction Server 支持不同级别的安全性,具体取决于您的连接以及与其关联的信任。 信任度越低,所需的安全级别就越高。
如果 CICS 直接连接到企业外部的系统,那么需要更高级别的安全性。 如果 CICS 仅连接到企业内的可信系统,并且应用程序的用户是可信的 (例如,他们都是企业的员工) ,那么可以使用中等级别的安全性。 如果 CICS 是隔离的,只有受信任的系统和受信任的用户才能访问,则可以降低安全级别。
如果您正在操作 "零信任" 策略,那么您的目标是从不信任,始终验证的原则。 在这种情况下,访问权将最小化为仅满足用户对其角色的需求,并对用户访问的所有资源进行访问权检查。 此检查与对 CICS 的请求是在企业内部还是外部发出无关。
- 如何确保应用程序的用户已正确认证?
- 使用了哪些授权机制来保护对 CICS 系统的访问以及对资源 (例如事务,文件和数据库) 的访问?
- 如何保护在物理配置的不同层之间传输的数据的机密性?
- 如何满足审计和合规性法规要求?
安全原则
软件安全遵循一些基本的指导原则。 以下是 CICS 如何支持这些原则:
- 标识
标识是将身份分配给尝试访问系统的实体的能力。 通常,该身份用于控制对资源的访问和对审计请求的访问。 根据认证模型,身份可能来自认证凭证,也可能来自其他服务器。
CICS 旨在处理存储在 z/OS 用户注册表中的用户标识。 它还可以使用非z/OS 用户标识 (例如 X.500 标识) ,这些非z/OS 用户标识称为 分布式标识。 出于授权目的,可以将分布式标识映射到 CICS条目中的 z/OS 用户标识。 分布式标识还可能与 z/OS 用户标识一起流动,以便可供应用程序使用并可用于审计。
用户注册表 存储用户帐户信息,以便在认证和授权期间可以访问这些信息。 RACF® 是 的主要用户注册表,可通过 SAF 界面访问。 z/OS 某些其他类型的用户注册表也可以与 CICS配合使用,例如,如果您使用 CICS Liberty 和 LDAP。
请参阅 工作方式: 在 CICS 和 用户注册表 中进行标识,以获取更多信息。
- 认证
认证是验证访问实体所声明的身份的过程: 此实体是它所声称的实体吗? 通过验证随声明的身份一起提供的认证信息来完成认证。 认证信息通常称为存取器的 凭证。 认证通常是安全处理的第一步。 对其进行认证后,可以向下游安全处理 断言 身份,这意味着这些步骤信任该身份已通过上游步骤成功认证。
在 CICS中,如果断言的身份来自已认证用户的可信系统,那么可以省略认证。
CICS Transaction Server 支持以下类型的认证:- 基本认证,使用密码或口令形式的凭证。 密码或口令由用户注册表验证。 PassTicket是基本身份验证令牌的一个特殊版本,它是特定系统的有时间限制、一次性使用的密码。
- 多因子认证,要求用户提供多条信息: 你知道的东西,你有的东西,你有的东西。 此信息以 多因子认证 (MFA) 令牌的形式提供。 它们通常可以在 CICS 中与密码和口令相同的接口中使用。
- 客户机证书认证,要求用户提供数字证书,然后映射到用户标识。 证书必须由可信的第三方或认证中心颁发。
- 第三方认证,其中客户机向第三方认证服务器进行认证。 此服务器生成认证令牌,例如 JSON Web 令牌 (JWT) ,安全性断言标记语言 (SAML) 令牌或 Kerberos 令牌。 然后,使用认证令牌向 CICS进行认证。
从 CICS TS 6.3 开始,已移除对使用 CICS 安全令牌服务 6.3 SAML 的支持。
请参阅 工作方式: CICS中的认证 以获取更多信息。
- Authorization
授权是检查是否应该授予已认证的身份对其请求的资源的访问权的过程。 授权的典型实现是将包含已认证身份的安全上下文传递到访问控制机制。
CICS Transaction Server 支持不同类型的授权:- 运行 CICS 事务 (事务安全性)
- 访问资源 (资源安全性)
- 使用 CICS 系统编程命令 (命令安全性)
- CICS 系统之间的通信 (双向通信安全性)
- 控制对 Liberty 所提供的应用程序中资源的访问 (角色授权)。
- 完整性
完整性可确保在传输或存储期间不会以意外方式更改信息。 通过网络传输数据时,完整性会检查接收到的数据是否与发送的数据相同。
CICS Transaction Server 使用安全协议 (例如 SSL 或最近使用的 TLS , AT-TLS 或 JSSE) 以及基于消息的安全性来为数据传输提供数据完整性。 请参阅 工作方式: CICS中的机密性和完整性 以获取更多信息。
- 机密性
- 机密性或 隐私 可确保未经授权的参与方无法获取对数据的访问权。 通常,通过加密数据 (例如,使用 TLS 或 WS-Security) 来实现机密性。
请参阅 工作方式: CICS中的机密性和完整性 以获取更多信息。
- 审计
- 审计是安全基础结构的关键部分。 它涉及验证与安全性相关的事件 (例如用户的登录) ,以确保安全标准正确应用于请求的处理。
请参阅 工作方式: 在 CICS中审计 以获取更多信息。
- 不可抵赖性 (nonrepudiation)
- 不可抵赖性是指数据发送方和数据接收方能够向第三方提供证明发送方发送了该信息,并且接收方接收到相同的信息。 双方都不能否认发生了这种情况。
CICS 中可用的安全设施
图 1 汇总了 CICS Transaction Server中可用的选项。 如果 Liberty 随 CICS 一起安装以在 JVM 服务器中作为应用程序服务器运行,那么更多设施将变得相关,并且这些设施在图中以紫色显示。
CICS 安全性未涵盖的内容
- 外部访问
- 尽管 z/OS 提供了良好的安全性控制来阻止对数据集和文件的访问,但 CICS 本身不提供保护其自身资产免受外部访问的设施。 您必须限制对程序库, CICS 区域以及负责合并已核准的应用程序和系统更改的用户的访问权。 同样,CICS和CICS应用程序使用的数据集、数据库和zFS-based配置文件必须只能通过经批准的批处理和操作程序访问。
- 使用未记录或不受支持的接口的应用程序
- CICS 不会保护系统免受应用程序的保护,这些应用程序使用未记录或不受支持的接口来绕过 CICS 安全性。 您负责确保未在系统上安装此类程序。
- 应用程序源库
- 虽然 CICS 提供了一些设施来防止您运行未经授权的代码 (例如,通过限制对授权服务的访问以及仅通过 EXEC CICS API 将调用者的身份用于调用,以便可以使用 CICS 区域标识来保护对其他 z/OS API 的调用) ,但 CICS 不会直接保护应用程序源库。 确保您具有防止将未经授权或未经测试的应用程序引入到生产应用程序库中的过程。 您还必须通过对系统中安装的库进行控制以及对这些库的更改来保护系统的完整性。