Aviso sobre IRISSECURITY no InterSystems IRIS 2025.2

O InterSystems IRIS 2025.2 apresenta o banco de dados IRISSECURITY, o novo lar para dados de segurança. Ao contrário do IRISSYS, o antigo lar para dados de segurança, o IRISSECURITY pode ser criptografado, o que protege seus dados confidenciais em repouso. Em uma versão futura, o IRISSECURITY será espelhado.

Esta versão também apresenta a função %SecurityAdministrator para tarefas gerais de administração de segurança.

As alterações descritas aqui afetam tanto as versões de entrega contínua (CD) quanto as de manutenção estendida (EM). Ou seja, a partir das versões 2025.2 (CD, lançada em 23 de julho de 2025) e 2026.1 (EM), o InterSystems IRIS incluirá o banco de dados IRISSECURITY, e todos os dados de segurança serão movidos automaticamente do IRISSYS para o IRISSECURITY ao atualizar.

Embora o lançamento do InterSystems IRIS 2025.2 esteja previsto para 23 de julho de 2025, estamos adiando o lançamento público do InterSystems IRIS for Health e do HealthShare Health Connect 2025.2 enquanto concluímos o trabalho em um plano de correção para um problema de espelhamento conhecido que afeta os dados de configuração do OAuth.

Antes de atualizar

IRISSECURITY faz várias mudanças potencialmente drásticas na maneira como os usuários interagem com dados de segurança:

• Os usuários não podem mais acessar diretamente os recursos globais de segurança e, em vez disso, devem usar as APIs fornecidas pelas diversas classes de segurança.
• Os recursos globais OAuth2 não podem mais ser mapeados para um banco de dados diferente.
• Os usuários não podem mais consultar tabelas de segurança arbitrariamente, mesmo quando a segurança SQL estiver desabilitada.
• Os bancos de dados do sistema agora usam recursos predefinidos que não podem ser alterados. No Unix, se você criou e atribuiu um novo recurso a um banco de dados do sistema em uma versão anterior, ele será substituído pelo recurso predefinido durante a atualização (embora, se alguma função fizer referência ao recurso não padrão, ela deverá ser alterada manualmente para usar o recurso padrão e manter o acesso ao banco de dados). No Windows, você deve alterar o recurso de volta para o padrão. Se você tentar atualizar no Windows enquanto os bancos de dados tiverem recursos não padrão, a atualização será interrompida (a instância não será modificada) e exibirá a mensagem de erro "O banco de dados deve ter um rótulo de recurso de..."

As seções a seguir detalham essas alterações e o que você deve fazer se depender do comportamento original, mas, em geral, antes de atualizar, você deve verificar e testar se seus aplicativos e macros:

• Utilize as APIs de segurança fornecidas para administrar a segurança (em vez do acesso global direto).
• Tenha as permissões necessárias (%DB_IRISSYS:R e Admin_Secure:U) para usar essas APIs.

Acesso Global

Anteriormente, quando os dados globais de segurança eram armazenados no banco de dados IRISSYS, os usuários podiam acessar os dados de segurança com os seguintes privilégios:

• %DB_IRISSYS:R: Lê informações globais de segurança diretamente e por meio de APIs de segurança.
• %DB_IRISSYS:RW: Lê e grava informações globais de segurança.
• %DB_IRISSYS:RW e Admin_Secure:U: Administra a segurança por meio de APIs de segurança.

No InterSystems IRIS 2025.2:

• Os usuários não podem mais acessar os globais de segurança diretamente.
• %DB_IRISSYS:R e %Admin_Secure:U são os privilégios mínimos necessários para acessar dados de segurança (por meio das APIs de segurança fornecidas) e administrar a segurança por meio das diversas classes de segurança.
• Para administração geral de segurança, você pode usar a nova função %SecurityAdministrator.
• O acesso somente leitura aos dados de segurança (anteriormente disponível por meio de %DB_IRISSYS:R) foi removido.

Local das Globais 

No InterSystems IRIS 2025.2, as seguintes globais de segurança foram movidos do IRISSYS para o global ^SECURITY localizado no IRISSECURITY:

• ^SYS("SECURITY")
• ^OAuth2.*
• ^PKI.*
• ^SYS.TokenAuthD

The following table lists the most notable globals that have been moved, their security classes, old locations, and new locations:

Mapeamento da global OAuth2

Anteriormente, era possível mapear globais OAuth2 para um banco de dados diferente, o que permitia o espelhamento das configurações OAuth2.

No InterSystems IRIS 2025.2, globais OAuth2 não podem mais ser mapeados e o IRISSECURITY não pode ser espelhado. Se você dependia desse comportamento para espelhamento, pode usar qualquer uma das seguintes soluções alternativas:

• Faça alterações manualmente no primário e no failover.
• Exporte as configurações do primário e importe-as para o failover (requer %ALL).

Para exportar dados de configuração do OAuth2:

set items = $name(^|"^^:ds:IRISSECURITY"|SECURITY("OAuth2"))_".gbl"
set filename = "/home/oauth2data.gbl"
do $SYSTEM.OBJ.Export(items,filename)

Para importar dados de configuração do OAuth2:

do $SYSTEM.OBJ.Import(filename)

Segurança SQL 

Anteriormente, a segurança do SQL era controlada pelo parâmetro DBMSSecurity do CPF. Quando o DBMSSecurity estava desabilitado, usuários com privilégios de SQL podiam consultar arbitrariamente todas as tabelas do banco de dados.

No InterSystems IRIS 2025.2:

 

• O parâmetro DBMSSecurity foi substituído pela propriedade de segurança SQL para todo o sistema. Você pode defini-la de várias maneiras:
  • Portal de Gerenciamento: Administração do Sistema > Segurança > Segurança do Sistema > Parâmetros de Segurança para todo o Sistema > Habilitar segurança SQL
  • SetOption: ##class(%SYSTEM.SQL.Util).SetOption("SQLSecurity", "1")
  • Security.System.Modify: ##Class(Security.System).Modify(,.properties), onde properties é properties("SQLSecurity")=1
• As tabelas de segurança agora só podem ser consultadas por meio das APIs de Detalhes e Listas, que exigem %DB_IRISSYS:R e %Admin_Secure:U mesmo quando a segurança SQL está desabilitada. 

Por exemplo, para obter uma lista de funções, você não pode mais consultar diretamente a tabela Security.Roles. Em vez disso, você deve usar a consulta Security.Roles_List():

SELECT Name, Description FROM Security.Roles_List()

Criptografando IRISSECURITY 

Para criptografar o IRISSECURITY, siga o seguinte procedimento:

1. Crie uma nova chave de criptografia. Acesse Administração do Sistema > Criptografia > Criar Novo Arquivo de Chave de Criptografia e especifique o seguinte:
   • Arquivo Chave – O nome da chave de criptografia.
   • Nome do Administrador – O nome do administrador.
   • Senha – A senha para o arquivo de chave.
2. Ative a chave de criptografia. Acesse Administração do Sistema > Criptografia > Criptografia do Banco de Dados e selecione Ativar Chave, especificando o Arquivo de Chave, o Nome do Administrador e a Senha da etapa 1.
3. Acesse Administração do Sistema > Criptografia > Criptografia do Banco de Dados e selecione Configurações de Inicialização.
4. No menu suspenso Ativação de Chave na Inicialização, selecione um método de ativação de chave. A InterSystems recomenda fortemente a ativação de chave interativa.
5. No menu suspenso Criptografar Banco de Dados IRISSECURITY, selecione Sim.
6. Reinicie o sistema para criptografar o IRISSECURITY.

Regras de acesso de classe %

Em versões anteriores do InterSystems IRIS, o procedimento para gerenciar o acesso de uma aplicação web a classes percentuais adicionais envolvia a gravação em globais de segurança. Você pode fazer isso no InterSystems IRIS 2025.2 por meio do Portal de Gerenciamento ou da rotina ^SECURITY.

Portal de Gerenciamento

Para criar uma regra de acesso de classe % com o Portal de Gerenciamento:

1. Acesse System Administration > Security > Web Applications. 
2. Selecione a sua aplicação web.
3. Na aba Acesso a Classe %, defina as seguintes opções: 
   • Tipo: Controla se a regra se aplica ao acesso do aplicativo apenas à classe percentual especificada (AllowClass) ou a todas as classes que contêm o prefixo especificado (AllowPrefix).
   • Nome da classe: A classe % ou prefixo ao qual o aplicativo terá acesso.
   • Permissão de acesso: Se deve ou não conceder ao aplicativo acesso à classe ou pacote percentual especificado.
   • Adicionar o mesmo acesso a TODAS as aplicações: Se a regra deve ser aplicada a todos os aplicativos

^SECURITY 

Para criar uma regra de acesso de classe com a rotina ^SECURITY:

1. No namespace %SYS, execute a rotina ^SECURITY:

   DO ^SECURITY

2. Escolha as opções 5, 1, 8 e 1 para entrar no prompt da regra de acesso à classe. 
3. Siga as instruções, especificando o seguinte:
   • Aplicação? – O nome da aplicação.
   • Tipo de permissão? – Se a regra se aplica à capacidade do aplicativo de acessar uma classe específica (AllowClass) ou todas as classes que contêm o prefixo especificado (AllowPrefix).
   • Classe or nome do pacote? – A classe ou prefixo ao qual o aplicativo terá acesso.
   • Permissão de acesso? – Se deve ou não conceder ao aplicativo acesso à classe ou pacote especificado.