本部分概述了本产品提供的具体安全机制。
本安全指南的本部分内容将概括介绍系统设计用来应对的威胁，以及各项安全功能如何合作来阻止攻击。
提供这些保护的关键安全功能包括：
验证－确保只有经过授权才能访问系统和数据。
授权－对系统特权和数据的访问控制；这种访问控制建立在验证的基础上，可确保个体仅获得合适的访问权限
审计－使管理员可以检测到试图违反验证机制的违规行为以及试图或成功进行的访问控制违规行为。
有关 Oracle Key Manager 的安全性和验证方面的更多信息，请参阅《Oracle Key Manager Version 2.x Security and Authentication White Paper》，网址为：
Oracle Key Manager 体系结构可以针对用户操作在系统的所有元素之间进行相互验证：KMA 对 KMA、代理对 KMA 以及 Oracle Key Manager GUI 或 CLI 对 KMA。
系统的每个元素（例如，新的加密代理）都通过以下方式在系统中进行注册：在 OKM 中创建 ID 和密码短语，然后将其输入到要添加的元素中。例如，将磁带机添加到系统中时，代理和 KMA 会根据共享的密码短语自动运行质询/响应协议，从而使代理获得根证书颁发机构 (Certificate Authority, CA) 证书以及一个新的密钥对和经过签署的代理证书。通过实施根 CA 证书、代理证书和密钥对，代理可以针对与 KMA 的所有后续通信运行传输层安全 (Transport Layer Security, TLS) 协议。所有证书都是 X.509 证书。
OKM 充当根证书颁发机构来生成一个根证书，然后，KMA 使用该证书来派生（自签署）代理、用户和新 KMA 使用的证书。
访问控制有以下类型：
基于用户和角色的访问控制
法定保护。
Oracle Key Manager 允许定义多个用户，每个用户都有一个用户 ID 和密码短语。可为每个用户提供一个或多个预定义角色。这些角色决定了允许用户对 Oracle Key Manager 系统执行的操作。这些角色包括：
安全官－执行 Oracle Key Manager 设置和管理
操作员－执行代理设置和日常操作
合规官－定义密钥组并控制代理对密钥组的访问权限
备份操作员－执行备份操作
审计员－查看系统审计迹
法定成员－查看和批准待定的法定操作
安全官是在快速启动过程中定义的，该过程在 OKM 群集中设置 KMA。以后，用户必须以安全官的身份使用 Oracle Key Manager GUI 登录到群集才能定义其他用户。安全官可以选择向特定用户分配多个角色，也可以选择将特定角色分配给多个用户。
有关每个角色允许的操作以及安全官如何创建用户并向其分配角色的更多信息，请参阅 Oracle Key Manager 文档库中的《Oracle Key Manager 管理指南》，网址为：
http://www.oracle.com/technetwork/documentation/tape-storage-curr-187744.html#crypto
这种基于角色的访问控制支持采用美国国家标准与技术研究院 (National Institute of Standards and Technology, NIST) 特殊出版物 (Special Publication, SP) 800-60 操作角色来分隔操作职能。
有些操作足够重要，需要增加安全级别。这些操作包括将 KMA 添加到 OKM 群集、KMA 解锁、创建用户以及为用户添加角色。为实施此安全性，系统除了使用前述基于角色的访问权限外，还使用一组密钥拆分凭证。
密钥拆分凭证包含一组用户 ID 和密码短语对，以及系统为支持完成特定操作所必需的这些对的最少数量。密钥拆分凭证也称为“法定”，最少数量也称为“法定阈值”。
Oracle Key Manager 最多允许定义 10 个密钥拆分用户 ID/密码短语对和一个阈值。它们是在快速启动过程中在 OKM 群集中配置第一个 KMA 时定义的。密钥拆分用户 ID 和密码短语不同于用来登录到系统的用户 ID 和密码短语。当用户尝试需要法定审批的操作时，所定义的密钥拆分用户阈值和密码短语必须在系统执行此操作之前批准此操作。
每个 KMA 都会针对其执行的操作记录审计事件，包括由代理、用户以及 OKM 群集中的对等 KMA 发出的事件。代理、用户或对等 KMA 自身每次验证失败时，MKA 也会记录审计事件。将记录指示安全违规的审计事件。例如，验证失败就是指示安全违规的一个审计事件。如果在 OKM 群集中标识了 SNMP 代理，则在遇到安全违规时，KMA 还会将 SNMP INFORM 发送到这些 SNMP 代理。如果配置了远程 Syslog，则 KMA 还会将这些审计消息转发给所配置的服务器。请参见远程 Syslog。
用户必须正确地登录到 OKM 群集，并且必须分配有某个角色才能查看审计事件。
KMA 管理其审计事件。KMA 会根据保留期限和限制（计数）删除较旧的审计事件。安全官可根据需要修改这些保留期限和限制。
Oracle Key Manager 还提供了其他安全功能。有关这些功能以及其他 OKM 功能的更多信息，请参阅《Oracle Key Manager Overview》，网址为：
代理与 KMA 之间、用户与 KMA 之间以及 KMA 与对等 KMA 之间的通信协议是一样的。在每种情况下，系统都将使用发起通信的实体的密码短语来执行质询/响应协议。如果成功，将向实体提供证书及其对应的私钥。这个证书和私钥可以建立传输层安全 (Transport Layer Security, TLS)（安全套接字）通道。执行相互验证；任何连接的每一端都会对另一方进行验证。OKM 3.1+ KMA 将始终使用 TLS 1.2 执行其对等方复制通信。
KMA 有一个可用的硬件安全模块，该模块需要单独订购。此硬件安全模块是一个 Sun Cryptographic Accelerator (SCA) 6000 卡，通过了 FIPS 140-2 Level 3 认证，可提供高级加密标准 (Advanced Encryption Standard, AES) 256 位加密密钥（此证书已在 2015 年 12 月 31 日过期且没有续订，在后续版本中将提供替代 HSM）。该 SCA 6000 卡支持 FIPS 140-2 Level 3 操作模式，并且 OKM 始终以此方式使用该卡。当 OKM 群集以符合 FIPS 标准的模式运行时，加密密钥不会将 SCA 6000 卡的加密边界保留为未封装的形式。该 SCA 6000 卡使用经过 FIPS 认可的随机数生成器，按 FIPS 186-2 DSA 随机数生成器中指定的方式，使用 SHA-1 来生成加密密钥。
如果 KMA 未配置为使用 SCA 6000 卡，则会使用 Solaris 加密框架 (Solaris Cryptographic Framework, SCF) PKCS#11 软令牌执行加密。SCF 是在 FIPS 140 模式下按照最近发布的 Solaris FIPS 140-2 安全策略配置的。
在创建密钥、在 KMA 上存储密钥、将密钥传输到代理或者在密钥传输文件中时，Oracle Key Manager 使用 AES 密钥包装 (RFC 3994)；该包装采用 256 位密钥加密密钥来保护对称密钥。
初始化 OKM 群集的第一个 KMA 时，该 KMA 会生成一个很大的密钥池。当向群集添加其他 KMA 时，会将密钥复制到新 KMA，准备好用于加密数据。添加到群集中的每个 KMA 都会生成一个密钥池，并将它们复制到群集中的对等 KMA。所有 KMA 都将根据需要生成新的密钥来保持密钥池的大小，以便始终有准备好的密钥供代理使用。当某个代理需要新密钥时，该代理会与群集中的某个 KMA 通信，请求新密钥。该 KMA 会从其密钥池中提取一个准备好的密钥，并将该密钥分配到代理的默认密钥组以及数据单元。然后，该 KMA 会通过网络将这些数据库更新复制到群集中的其他 KMA。以后，代理可以与群集中的其他 KMA 通信来检索密钥。在任何时候都不会有任何明文材料通过网络传输。
2013 年 12 月，美国国家标准与技术研究院 (National Institute of Standards and Technology, NIST) 为 Solaris 11 中的 Oracle Solaris 内核加密框架模块颁发了编号为 2061 的 FIPS 140-2 Level 1 验证证书。2014 年 1 月，NIST 为 SPARC T4 和 SPARC T5 中的 Oracle Solaris Userland 加密框架颁发了编号为 2076 的 FIPS 140-2 Level 1 验证证书。Oracle Key Manager 3.1.0 KMA 现在基于仍在进行 FIPS 140-2 验证测试的 Solaris 11.3。 Oracle Key Manager 3.1.0 KMA 中的 Oracle Solaris 内核加密框架是按照 Oracle 内核加密框架安全策略配置的。同样，KMA 也是按照 SPARC T4 和 SPARC T5 中的 Oracle Solaris Userland 加密框架安全策略配置的。一旦推出较新的 Solaris 安全策略，OKM 就将更新到较新的安全策略。