#Seguridad

Hola Comunidad!

¿Necesitas un modo de almacenar de forma segura tus passwords, API keys y otras credenciales? Mira como el Secure Wallet en InterSystems IRIS® data platform te puede ayudar:

¿Qué es el InterSystems Secure Wallet?

También en versiones anteriores podíais definir vuestro servidor FHIR para aceptar solicitudes mediante OAuth 2.0 (por ejemplo, para un cliente SMART on FHIR), pero hoy en día, con la versión v2024.3, que se lanzó hace ya un tiempo, existe una nueva funcionalidad que permite hacerlo de forma más sencilla: el OAuth FHIR Client QuickStart.

Fue alentador ver a más personas creando extensiones de VS Code para el concurso reciente. Sin embargo, noté que de las tres extensiones que requieren credenciales para realizar sus conexiones, solo la de @John Murray, gj :: dataLoader, aprovecha la extensión InterSystems Server Manager, ampliamente establecida y oficialmente soportada, para obtener las definiciones de conexión y gestionar las credenciales de manera segura.

La versión 2025.3 de la plataforma de datos InterSystems IRIS, InterSystems IRIS for Health y HealthShare Health Connect ya está disponible de forma general. Esta es una versión de entrega continua o CD  (Continuous Delivery).

Aspectos destacados de la versión:

• Secure Wallet: Un nuevo marco cifrado para gestionar datos sensibles, basado en la base de datos IRISSECURITY, que mejora la seguridad del sistema y el control de acceso.

InterSystems se complace en anunciar la disponibilidad general (GA) de la versión 2025.2 de la plataforma de datos InterSystems IRIS®. Esta es una versión de Entrega Continua (CD). Tened en cuenta que las versiones GA de InterSystems IRIS for Health™ y HealthShare® Health Connect™ 2025.2 se han retenido temporalmente debido a limitaciones en la replicación introducidas por actualizaciones de seguridad (más detalles a continuación).

Aspectos destacados de la versión

Esta versión introduce mejoras significativas en seguridad, experiencia del desarrollador, operaciones e interoperabilidad.

La inyección SQL sigue siendo una de las vulnerabilidades más críticas en las aplicaciones basadas en bases de datos, ya que permite a los atacantes manipular consultas y, potencialmente, acceder o comprometer datos sensibles. En InterSystems IRIS, los desarrolladores tienen acceso tanto a SQL Dinámico como a SQL Embebido, cada uno con características distintas. Comprender cómo usarlos de forma segura es esencial para prevenir la inyección SQL.

El problema: SQL Dinámico y la inyección SQL

El SQL Dinámico construye consultas como cadenas durante la ejecución.

En los hackatones en los que participó InterSystems y en los que dimos soporte, muchos estudiantes preguntaban cómo podían hacer para que todos los miembros de su equipo usaran la misma base de datos IRIS que habían levantado en un contenedor. Sugerí usar ngrok para exponer su instancia local de IRIS y me di cuenta de que no tenemos documentación al respecto. Por eso pensé que sería una gran idea dar a conocer esta técnica tan útil para mejorar la colaboración durante el desarrollo y las pruebas.

Buenas a todos,

en capítulos anteriores, vimos como "Proteger los datos: Se un mejor cerrajero", en el que explicábamos como proteger nuestros recursos aplicando un control extra al acceso mediante OAUTH2 que nos ofrece Intersystems. Y como no hay 2 sin 3, aquí tenemos un tercer articulo, en el cual vamos a explicar como "avisar a la policía" de que alguien malicioso está intentando acceder a nuestros datos.

Después de que desplegáramos un nuevo contenedor basado en containers.intersystems.com/intersystems/irishealth:2023.1 esta semana, notasteis de repente que el Repositorio FHIR empezó a responder con un Error 500. Esto se debe a violaciones de PROTECT en el nuevo espacio de nombres y base de datos HSSYSLOCALTEMP, utilizado por esta versión de los componentes FHIR de IRIS for Health.

La solución consiste en añadir "%DB_HSSYSLOCALTEMP" a las Aplicaciones Web que gestionan las solicitudes FHIR.

Con el lanzamiento de InterSystems IRIS Cloud SQL, recibimos cada vez más preguntas sobre cómo establecer conexiones seguras mediante JDBC y otras tecnologías de drivers. Aunque contamos con una documentación resumida y detallada sobre las tecnologías de los drivers, nuestra documentación no describe herramientas cliente individuales, como nuestra favorita personal, DBeaver. En este artículo, describiremos los pasos para crear una conexión segura desde DBeaver a vuestra implementación de Cloud SQL.

Pregunta:

¿Cómo podéis crear, modificar, etc., configuraciones de seguridad como Usuarios y Roles programáticamente?

Respuesta:

Podéis usar las clases del paquete Security en el NAMESPACE %SYS. Por ejemplo Security.Roles o Security.Users.

Por supuesto, para llevar a cabo estas acciones, necesitaréis la autorización correspondiente.

Aquí tenéis un pequeño ejemplo usando Security.Roles:

 
 // Create a Role
%SYS>Set status = ##class(Security.Roles).Create("testRole","a test Role","%Development:U,%DB_USER:R")
 

// Creation was successful
%SYS>Write status
1

// Now lets examine the Role created
%SYS>Set status = ##class(Security.Roles).Get("testRole",.properties)  

// We got the properties correctly         
%SYS>Write status
1

// The properties were returned by reference
%SYS>ZWrite properties
properties("Description")="a test Role"
properties("GrantedRoles")=""
properties("Resources")="%DB_USER:R,%Development:U"
 

// Now we want to add another permission
%SYS>Set properties("Resources")=properties("Resources")_",%DB_SAMPLES:RW"
 

// And modify our Role
%SYS>Set status = ##class(Security.Roles).Modify("testRole",.properties)
 
%SYS>Write status
1

// Let's verify this worked
%SYS>Set status = ##class(Security.Roles).Get("testRole",.latestProperties)
 
%SYS>ZWrite latestProperties
latestProperties("Description")="a test Role"
latestProperties("GrantedRoles")=""
latestProperties("Resources")="%DB_SAMPLES:RW,%DB_USER:R,%Development:U"