#Segurança

A auditoria é uma capacidade crítica que garante a segurança do seu servidor e, há algum tempo, incluímos a capacidade de auditar instruções SQL executadas no servidor.

Com a v2024.3 já disponível, estamos fornecendo opções com granularidade mais refinada para definir esses eventos a serem auditados.

Anteriormente, você podia decidir auditar instruções SQL de acordo com o mecanismo de acesso, por exemplo, executando instruções via JDBC/ODBC vs. SQL embarcado (ex: usando &sql em seu código) vs. SQL Dinâmico (ex: usando %SQL.

Existe uma Master Table dentro do IRIS que estou preenchendo a partir do Epic, mas quero compartilhá-la com nossa equipe de Enterprise Application Development (Web). Como teste, consegui usar _SYSTEM a partir do Postman para executar o seguinte.

POST /api/atelier/v1/xxxx/action/query HTTP/1.1
Host: xxxxxxxx
Content-Type: application/json
Authorization: ••••••
Cookie: CSPSESSIONID-SP-443-UP-api-atelier-=00f0000000000AKyLjBfUvU$MpFD8UT8y$EoNKNw1ixZeXN4_Q; CSPWSERVERID=hzZAT5rb
Content-Length: 86

{"query": "SELECT * FROM osuwmc_Epic_Clarity.DepartmentMaster WHERE ID = '300000000'"}

Foi encorajador ver mais pessoas criando extensões do VS Code para o concurso recente. No entanto, notei que, das três extensões que exigem credenciais para realizar suas conexões, apenas a de @John Murray, gj :: dataLoader, aproveita a extensão InterSystems Server Manager
, amplamente estabelecida e oficialmente suportada, para obter as definições de conexão e gerenciar as credenciais de forma segura.

Se você olhar o arquivo values.yaml do Helm chart do IKO, você encontrará:

useIrisFsGroup:false

Vamos detalhar o que isso é e em quais situações você pode querer configurá-lo como true.

FsGroup se refere ao grupo do sistema de arquivos.

Por padrão, os volumes do Kubernetes pertencem ao usuário root, mas precisamos que o IRIS seja o dono de seus arquivos (o IRIS em containers é instalado sob o usuário irisowner). Para contornar isso, utilizamos um de dois métodos:

1) initContainers

Os initContainers são executados antes dos containers da aplicação (como o IRIS) em um pod.

Também nas versões anteriores era possível configurar o seu servidor FHIR para aceitar requisições via OAuth 2.0 (por exemplo, para um cliente SMART on FHIR), mas atualmente, com a versãov2024.3, lançada a algum tempo— existe um novo recurso que torna isso mais fácil: o OAuth FHIR Client QuickStart.

A versão 2025.3 do InterSystems IRIS® data platform, InterSystems IRIS^® for Health, e HealthShare^® Health Connect já estão disponíveis para o público em geral (GA). Esta é uma versão de distribuição contínua (CD).

Destaques do Lançamento::

• Carteira Segura: Uma nova estrutura criptografada para gerenciamento de dados sensíveis, construída sobre o banco de dados IRISSECURITY, que aprimora a segurança do sistema e o controle de acesso.

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.

Depois que implementamos um novo container baseado em containers.intersystems.com/intersystems/irishealth:2023.1 esta semana, percebemos que nosso FHIR Repository começou a responder com um Erro 500. Isso aconteceu devido a violações de PROTECT no novo namespace e banco de dados HSSYSLOCALTEMP utilizado por essa versão dos componentes FHIR do IRIS for Health.

A solução para isso é adicionar a permissão "%DB_HSSYSLOCALTEMP" nas Aplicações Web que processam as requisições FHIR.