Esta seção descreve os mecanismos específicos de segurança oferecidos pelo produto.
Estas são as principais preocupações dos clientes que têm agentes habilitados para criptografia:
Divulgação de informações, violando a política
Perda ou destruição de dados
Atraso inaceitável na restauração de dados em caso de uma falha catastrófica (por exemplo, em um site de continuidade de negócios)
Modificação de dados não detectada.
O objetivo das funcionalidades de segurança do Oracle Key Manager são:
Proteger os dados criptografados contra divulgação.
Minimizar a exposição a ataques.
Oferecer um nível de confiabilidade e disponibilidade suficientemente alto.
Esta seção do guia de segurança deve apresentar uma visão geral de alto nível das ameaças que o sistema deve combater e de como as funcionalidades de segurança individuais são combinadas para impedir os ataques.
As funcionalidades de segurança que oferecem essas proteções são:
Autenticação – Garante o acesso somente de indivíduos autorizados ao sistema e aos dados
Autorização – Controla o acesso aos privilégios e aos dados do sistema; esse controle baseia-se na autenticação para garantir que os indivíduos tenham somente o acesso apropriado
Auditoria – Permite que os administradores detectem tentativas de violação do mecanismo de autenticação e tentativas ou violações bem-sucedidas do controle de acesso.
Para obter mais informações sobre a segurança e a autenticação do Oracle Key Manager, consulte o Oracle Key Manager Version 2.x Security and Authentication White Paper em:
A arquitetura do Oracle Key Manager permite a autenticação mútua entre todos os elementos do sistema: entre KMA e KMA, entre agente e KMA e entre GUI ou CLI do Oracle Key Manager e KMA para operações do usuário.
Cada elemento (por exemplo, um novo agente de criptografia) é inscrito no sistema por meio da criação de um ID e de uma frase-senha no OKM, os quais são inseridos no elemento a ser adicionado. Por exemplo, quando uma unidade de fita é adicionada ao sistema, o agente e o KMA executam automaticamente um protocolo de desafio/resposta baseado na frase-senha compartilhada. Como resultado, o agente obtém o certificado da Autoridade de Certificação (CA) raiz, bem como um novo par de chaves e um certificado assinado. Após obter o certificado da CA raiz, o certificado de agente e o par de chaves, o agente poderá executar o protocolo TLS (Transport Layer Security) para todas as comunicações subsequentes com os KMAs. Todos os certificados são certificados X.509.
O OKM se comporta com uma autoridade de certificação raiz para gerar um certificado raiz que os KMAs, por sua vez, utilizam para derivar (autoassinar) os certificados usados pelos agentes, pelos usuários e pelos novos KMAs.
Estes são os tipos de controle de acesso:
Controle de Acesso Baseado em Atribuição e Usuários
Proteção por Quorum.
O Oracle Key Manager permite definir vários usuários, cada um com um ID de usuário e uma frase-senha. Cada usuário tem uma ou mais atribuições predefinidas. Essas atribuições determinam quais operações o usuário tem permissão de executar em um sistema Oracle Key Manager. As atribuições são:
Oficial de Segurança – Executa a configuração e o gerenciamento do Oracle Key Manager
Operador – Executa a configuração de agentes e as operações diárias
Oficial de Conformidade – Define os Grupos de Chaves e controla o acesso dos agentes a esses grupos
Operador de Backup – Executa operações de backup
Auditor – Exibe as trilhas de auditoria do sistema
Membro do Quorum – Exibe e aprova operações pendentes do quorum
Um Oficial de Segurança é definido durante o processo QuickStart, que configura um KMA em um Cluster do OKM. Posteriormente, um usuário deverá fazer log-in no Cluster como Oficial de Segurança utilizando a GUI do Oracle Key Manager para definir outros usuários. O Oficial de Segurança poderá designar várias atribuições a determinado usuário, bem como designar uma atribuição específica a vários usuários.
Para obter mais informações sobre as operações permitidas por cada atribuição e como o Oficial de Segurança cria usuários e designa atribuições a eles, consulte o Oracle Key Manager Administration Guide incluído nas bibliotecas de documentação do Oracle Key Manager em:
http://www.oracle.com/technetwork/documentation/tape-storage-curr-187744.html#crypto
Esse controle de acesso baseado em atribuição suporta as atribuições operacionais do NIST (National Institute of Standards and Technology) SP (Special Publication) 800-60 para segregação de funções operacionais.
Algumas operações são extremamente críticas e exigem um maior nível de segurança. Exemplos dessas operações incluem a adição de um KMA a um Cluster do OKM, o desbloqueio de um KMA, a criação de usuários e a adição de atribuições a usuários. Para implementar essa segurança, o sistema usa um conjunto de credenciais de divisão de chaves, além do acesso baseado em atribuição descrito anteriormente.
As credenciais de divisão de chaves consistem em um conjunto de pares de ID de usuário e frase-senha, juntamente com o número mínimo desses pares necessário para que o sistema permita que certas operações sejam concluídas. Essas credenciais também são denominadas "o quorum" e o número mínimo é chamado "o limite do quorum".
O Oracle Key Manager permite até 10 pares de ID de usuário/frase-senha de divisão de chaves e um limite a ser definido. Eles são definidos durante o processo QuickStart quando o primeiro KMA é configurado em um Cluster do OKM. Os IDs de usuário e as frases-senhas de divisão de chaves são diferentes dos utilizados para fazer log-in no sistema. Quando o usuário tentar executar uma operação que exige a aprovação do quorum, o limite definido de usuários e frases-senhas de divisão de chaves deve aprovar essa operação para que o sistema a execute.
Cada KMA registra os eventos de auditoria referentes às operações que ele executa, incluindo os emitidos por agentes, usuários e KMAs correspondentes no Cluster do OKM. Os KMAs também registram eventos de auditoria sempre que ocorre falha na autenticação de um agente, usuário ou KMA correspondente. Os eventos de auditoria que indicam uma violação de segurança são anotados. Uma falha na autenticação é um exemplo de evento de auditoria que indica uma violação de segurança. Se Agentes SNMP forem identificados no Cluster do OKM, os KMAs também enviarão SNMP INFORMs a esses agentes SNMP caso encontrem uma violação de segurança. Se o Syslog Remoto tiver sido configurado, o KMA também encaminhará essas mensagens de auditoria aos servidores configurados. Consulte Syslog Remoto.
Para que possam exibir os eventos de auditoria, os usuários devem fazer log-in de maneira adequada no Cluster do OKM e ter uma atribuição designada a eles.
Os KMAs gerenciam os respectivos eventos de auditoria. Os KMAs removem os eventos de auditoria mais antigos com base nos termos e nos limites (contagens) de retenção. O Oficial de Segurança poderá modificar esses termos e limites conforme necessário.
O Oracle Key Manager fornece outras funcionalidades de segurança. Para obter mais informações sobre essas e outras funcionalidades do OKM, consulte o documento Oracle Key Manager Overview em:
O protocolo de comunicação entre um agente e um KMA, um usuário e um KMA, e um KMA e um KMA correspondente é o mesmo. Em cada um desses casos, o sistema usa a frase-senha da entidade que inicia a comunicação para executar um protocolo de desafio/resposta. Se a execução for bem-sucedida, a entidade receberá um certificado e a chave privada correspondente. Esse certificado e a chave privada podem estabelecer um canal TLS (Transport Layer Security) (soquetes seguros). A autenticação mútua é executada; cada extremidade de uma conexão autentica a outra. Os KMAs a partir da versão OKM 3.1 em diante, sempre utilizarão o TLS 1.2 para seu tráfego de replicação correspondente.
Os KMAs têm um Módulo de Segurança de Hardware disponível, que é encomendado separadamente. Esse Módulo de Segurança de Hardware – uma placa SCA (Sun Cryptographic Accelerator) 6000 – foi certificado pelo FIPS 140-2 Nível 3 e fornece chaves de criptografia AES (Advanced Encryption Standard) de 256 bits (este certificado expirou em 12/31/2015 e não está sendo atualizado; um HSM alternativo será fornecido em uma release subsequente). A placa SCA 6000 suporta o modo de operação FIPS 140-2 Nível 3, e o OKM sempre a utiliza dessa maneira. Quando o Cluster do OKM opera no modo compatível com FIPS, as chaves de criptografia não ultrapassam o limite criptográfico da placa SCA 6000 em um formato não encapsulado. A placa SCA 6000 usa o gerador de números aleatórios aprovado pelo FIPS, conforme especificado no FIPS 186-2 DSA Random Number Generator usando o SHA-1 para geração das chaves de criptografia.
Quando um KMA não é configurado com uma placa SCA 6000, a criptografia é executada com o token de software SCF (Solaris Cryptographic Framework) PKCS#11. O SCF é configurado no modo FIPS 140 de acordo com as políticas de segurança Solaris FIPS 140-2 publicadas mais recentemente.
O Oracle Key Manager usa o Encapsulamento de Chaves AES (RFC 3994) com chaves de criptografia de 256 bits para proteger as chaves simétricas quando elas são criadas, armazenadas no KMA, transmitidas para agentes ou nos arquivos de transferência de chaves.
Quando o primeiro KMA de um Cluster do OKM é inicializado, o KMA gera um grande pool de chaves. Quando outros KMAs são adicionados ao Cluster, as chaves são replicadas para os novos KMAs e podem ser usadas para criptografar dados. Cada KMA adicionado ao Cluster gera um pool de chaves e replica-os para os KMAs correspondentes no Cluster. Todos os KMAs gerarão novas chaves, conforme necessário, para manter o tamanho do pool de chaves de forma que haja sempre chaves prontas disponíveis para os agentes. Quando um agente necessita de uma nova chave, ele entra em contato com um KMA do Cluster e a solicita. O KMA extrai uma chave pronta de seu pool de chaves e a atribui ao grupo de chaves padrão do agente e à unidade de dados. Em seguida, o KMA replica essas atualizações do banco de dados na rede para os demais KMAs do Cluster. Posteriormente, o agente poderá entrar em contato com outro KMA do Cluster para recuperar a chave. Nenhum material de chaves com texto não criptografado é transmitido pela rede em momento algum.
Em dezembro de 2013, o NIST (National Institute of Standards and Technology) premiou o módulo Oracle Solaris Kernel Cryptographic Framework do Solaris 11 com o certificado de validação número 2061 do padrão FIPS 140-2 Nível 1. Em janeiro de 2014, o NIST (National Institute of Standards and Technology) premiou o módulo Oracle Solaris Kernel Cryptographic Framework baseado nos processadores SPARC T4 e SPARC T5 com o certificado de validação número 2076 do padrão FIPS 140-2 Nível 1. O KMA do Oracle Key Manager 3.1.0 agora se baseia no Solaris 11.3, que ainda está passando pelos testes de validação do FIPS 140-2. O Oracle Solaris Kernel Cryptographic Framework em um KMA do Oracle Key Manager está configurado de acordo com a Política de Segurança do Oracle Kernel Cryptographic Framework. Da mesma forma, o KMA também está configurado com a Política de Segurança do Oracle Solaris Userland Cryptographic Framework baseado nos processadores SPARC T4 e SPARC T5. O OKM será atualizado com as políticas de segurança mais recentes do Solaris, à medida que elas forem disponibilizadas.