T4.2: Writes Secure Code

Resumen

InterSystems IRIS proporciona dos niveles de encriptación: nivel de base de datos (encriptando archivos IRIS.DAT enteros) y nivel de elemento de datos (encriptando propiedades específicas programáticamente).

Encriptación de Base de Datos

Usa AES (Advanced Encryption Standard) en modo CBC (Cipher Block Chaining). Claves son creadas a través de la página "Create New Encryption Key File" del Management Portal, especificando longitud de clave (128, 192, o 256-bit), ubicación de archivo, y credenciales de administrador. La clave se almacena en un archivo de clave encriptado. Claves deben activarse antes de uso vía la página "Database Encryption". Al crear una nueva base de datos, establecer "Encrypt database" a "Yes" y seleccionar la clave activada. Encriptación es transparente a aplicaciones.

Encriptación de Elemento de Datos

Para control granular, usar métodos de clase %SYSTEM.Encryption:

• `$SYSTEM.Encryption.AESCBCManagedKeyEncrypt(plaintext, keyID)` - encripta datos, embebiendo el ID de clave en ciphertext
• `$SYSTEM.Encryption.AESCBCManagedKeyDecrypt(ciphertext)` - desencripta datos (ID de clave extraído automáticamente de ciphertext)
• `$SYSTEM.Encryption.AESCBCManagedKeyEncryptStream(stream, keyID)` - para streams de datos grandes
• `$SYSTEM.Encryption.AESCBCManagedKeyDecryptStream(stream)` - para desencriptar streams

Gestión de Clave

IRIS soporta hasta 256 claves activadas simultáneamente. Métodos de ciclo de vida de clave:

• `$SYSTEM.Encryption.CreateEncryptionKey()` - genera nuevas claves
• `$SYSTEM.Encryption.ActivateEncryptionKey()` - hace claves disponibles
• `$SYSTEM.Encryption.DeactivateEncryptionKey()` - remueve claves de memoria
• `$SYSTEM.Encryption.ListEncryptionKeys()` - muestra claves activadas

Claves pueden almacenarse vía KMIP (Key Management Interoperability Protocol) para gestión de clave empresarial, o en archivos de clave locales protegidos con múltiples capas de algoritmo de wrap de clave AES con claves derivadas de PBKDF2. El ID de clave se almacena automáticamente con ciphertext, habilitando re-encriptación en tiempo real sin tiempo de inactividad de sistema.

Resumen

Conexiones seguras a sistemas externos son esenciales para proteger datos en tránsito y asegurar comunicación confiable. InterSystems IRIS proporciona soporte completo TLS/SSL a través de configuraciones TLS nombradas gestionadas en el Management Portal bajo System Administration > Security > SSL/TLS Configurations. Estas configuraciones especifican versiones de protocolo (TLS 1.2, TLS 1.3), suites de cifrado, archivos de certificado, y requisitos de verificación.

Conexiones HTTPS

Para conexiones HTTPS salientes, desarrolladores usan la clase %Net.HttpRequest con la propiedad SSLConfiguration establecida a una configuración TLS nombrada. El certificado de servidor SSL es automáticamente verificado contra certificados CA confiables instalados en la configuración. Para TLS mutuo (mTLS), donde el cliente también debe presentar un certificado, configurar el certificado de cliente y clave privada en la configuración TLS. Ejemplo: Set httpRequest.SSLConfiguration = "MyTLSConfig" antes de llamar httpRequest.Get().

Seguridad de Servicios Web (WS-Security)

Seguridad de servicios web extiende más allá de encriptación de capa de transporte. Servicios web basados en SOAP pueden implementar estándares WS-Security para seguridad a nivel de mensaje, incluyendo encriptación XML, firmas digitales, tokens de nombre de usuario, y aserciones SAML. Esto se configura a través de credenciales SOAP en el Management Portal y políticas WS-Security adjuntas a definiciones de servicio web. Seguridad a nivel de mensaje asegura protección end-to-end incluso cuando mensajes atraviesan múltiples intermediarios.

Conexiones de Base de Datos (ODBC/JDBC)

Conexiones de base de datos vía ODBC y JDBC soportan encriptación SSL/TLS cuando apropiadamente configuradas. Cadenas de conexión JDBC incluyen parámetros sslConnection=true y sslServerName. Conexiones ODBC configuran SSL a través de configuraciones del driver ODBC InterSystems. Conexiones SQL Gateway a bases de datos externas también soportan TLS cuando conectan a sistemas remotos que requieren conexiones encriptadas.

Conexiones TCP/IP Personalizadas

Para conexiones TCP/IP personalizadas usando I/O de dispositivo ObjectScript, desarrolladores usan el parámetro de dispositivo /TLS y configuran la conexión usando %Net.SSLConfig. Los métodos $SYSTEM.Encryption.SSLServer() y $SYSTEM.Encryption.SSLClient() establecen canales encriptados. Siempre verificar certificados, usar suites de cifrado fuertes (evitar cifrados deprecados como RC4 y 3DES), y preferir TLS 1.2 o superior. Nunca deshabilitar verificación de certificado en entornos de producción.

Resumen

Inyección SQL es una de las vulnerabilidades de seguridad más críticas en aplicaciones de base de datos, ocurriendo cuando entrada de usuario no confiable es concatenada directamente en sentencias SQL sin sanitización apropiada. Atacantes pueden inyectar código SQL malicioso para acceder datos no autorizados, modificar contenido de base de datos, o ejecutar operaciones administrativas. InterSystems IRIS proporciona mecanismos de protección robustos cuando desarrolladores siguen prácticas de codificación segura.

SQL Embedded con Variables Host

La defensa primaria contra inyección SQL es consultas parametrizadas usando variables host. En SQL embedded, variables host son prefijadas con dos puntos y manejadas automáticamente como parámetros: &sql(SELECT Name FROM Person WHERE ID = :id). El compilador SQL IRIS trata :id como placeholder de parámetro, asegurando que el valor es apropiadamente escapado y no puede alterar la estructura de consulta. Nunca concatenar entrada de usuario: INCORRECTO: &sql(SELECT * FROM Person WHERE Name = '"_userName_"') - esto es vulnerable a inyección.

SQL Dinámico con %SQL.Statement

Para SQL dinámico, usar la clase %SQL.Statement con placeholders de parámetro. El método Prepare() acepta SQL con placeholders ?, y Execute() recibe un array de valores de parámetro: Set stmt = ##class(%SQL.Statement).%New() | Do stmt.%Prepare("SELECT * FROM Person WHERE Name = ?") | Set result = stmt.%Execute(userName). El driver maneja escapado apropiado y conversión de tipo automáticamente. Este patrón previene inyección porque valores de parámetro nunca son interpretados como código SQL.

Validación de Entrada y Defensa en Profundidad

Validación de entrada proporciona defensa en profundidad. Validar tipos de datos (asegurar que IDs numéricos son realmente números), aplicar límites de longitud, usar listas blancas para valores enumerados, y rechazar caracteres sospechosos. Para entradas de cadena usadas en cláusulas LIKE, escapar caracteres wildcard (% y _) si deberían tratarse literalmente. Usar %SYSTEM.SQL.ValidateIdentifier() para validar nombres de tabla y columna cuando SQL dinámico debe usar identificadores variables.

Mejores Prácticas Críticas

1) Nunca construir consultas SQL usando concatenación de cadena con entrada de usuario. 2) Siempre usar consultas parametrizadas con variables host o placeholders ?. 3) Validar y sanitizar toda entrada de usuario. 4) Usar lista blanca para identificadores dinámicos (nombres tabla/columna). 5) Aplicar principio de privilegio mínimo - cuentas de base de datos deberían tener permisos mínimos necesarios. 6) Registrar y monitorear intentos de inyección SQL. 7) Usar procedimientos almacenados cuando posible para encapsular lógica de base de datos y reducir superficie de ataque.

Resumen

Vulnerabilidades de ejecución de código remoto (RCE) permiten a atacantes ejecutar código arbitrario en el servidor, potencialmente llevando a compromiso completo de sistema. En InterSystems IRIS, riesgos RCE surgen principalmente del uso inapropiado de características de ejecución de código dinámico como XECUTE, indirection (@), y SQL dinámico. Desarrolladores deben comprender estos riesgos e implementar salvaguardas apropiadas.

Riesgos del Comando XECUTE

El comando XECUTE evalúa y ejecuta una cadena como código ObjectScript en runtime. Mientras poderoso para metaprogramación legítima, XECUTE es extremadamente peligroso cuando usado con entrada proporcionada por usuario. NUNCA hacer esto: XECUTE userInput. Un atacante podría inyectar comandos maliciosos como "Do $SYSTEM.Security.Users.Modify()" o "Kill ^GlobalData". Si ejecución de código dinámico es absolutamente necesaria, usar enfoque de lista blanca estricto donde entrada de usuario selecciona de bloques de código seguro predefinidos, nunca ejecuta cadenas de usuario directamente.

Riesgos del Operador Indirection

El operador indirection (@) evalúa una cadena como nombre de variable, referencia global, o expresión. Uso inapropiado con entrada de usuario puede llevar a acceso a datos no autorizado o ejecución de código. Ejemplo de vulnerabilidad: Set @userInput = value. Un atacante podría establecer userInput a "^%SYS" o expresiones maliciosas. Mitigación: validar que entrada coincida con patrones esperados usando regex o listas blancas, usar $SYSTEM.SQL.ValidateIdentifier() para identificadores, y preferir acceso directo a variable sobre indirection cuando posible.

Seguridad de Aplicación Web

Aplicaciones web enfrentan riesgos RCE adicionales. Páginas CSP ejecutan ObjectScript del lado del servidor, por lo que parámetros de consulta o entradas de formulario no sanitizadas pueden ser explotadas. Siempre validar tipos de entrada, longitudes, y formatos. Usar métodos de seguridad %CSP.Page como %CheckCSRFToken() para prevenir falsificación de solicitud entre sitios. Sanitizar salida para prevenir cross-site scripting (XSS), que puede llevar a secuestro de sesión y escalación de privilegio. Usar $ZCVT(string, "O", "HTML") para codificar caracteres especiales HTML en salidas.

Seguridad ClassMethod

Seguridad ClassMethod es crítica cuando métodos son expuestos a través de servicios web, REST APIs, o procedimientos SQL. Aplicar control de acceso basado en recursos usando keyword [%Method] con parámetro Resources: Method SensitiveOperation() [ SqlProc, Resources = "AdminResource" ]. Validar todos los parámetros de método - no asumir que llamadores proporcionan entradas seguras. Usar verificación de tipo, validación de rango, y restricciones de lógica de negocio. Registrar operaciones relevantes de seguridad para trazas de auditoría.

Mejores Prácticas de Configuración

1) Habilitar seguridad a nivel de aplicación en aplicaciones web. 2) Configurar seguridad SQL para restringir generación SQL dinámica. 3) Usar control de acceso basado en recursos para operaciones sensibles. 4) Implementar validación completa de entrada en todas las entradas externas. 5) Aplicar codificación de salida para prevenir ataques de inyección en interfaces web. 6) Habilitar logging de auditoría para eventos de seguridad. 7) Testing de seguridad regular incluyendo testing de penetración y revisión de código enfocándose en patrones de ejecución de código dinámico.

Resumen

InterSystems IRIS implementa un modelo completo de control de acceso basado en roles (RBAC) que proporciona control granular sobre acceso y operaciones de sistema. Comprender e implementar apropiadamente este modelo de seguridad es esencial para desarrollo de aplicación segura. El modelo consiste de usuarios, roles, recursos, y privilegios, con aplicaciones sirviendo como límites de seguridad.

Usuarios y Roles

Usuarios son cuentas individuales que autentican al sistema. Cada usuario es asignado uno o más roles que determinan sus permisos. Roles son colecciones nombradas de privilegios y pueden incluir otros roles (roles jerárquicos). Privilegios otorgan capacidades específicas: acceso a base de datos (leer/escribir/ejecutar), acceso a servicio (SQL, REST, CSP), permisos de recursos, y funciones administrativas. El principio clave es otorgar privilegios a roles, luego asignar roles a usuarios, nunca otorgar privilegios directamente a usuarios. Esto simplifica administración y asegura conjuntos de permisos consistentes.

Recursos y Permisos

Recursos son entidades protegidas definidas en IRIS, incluyendo bases de datos, aplicaciones, servicios, y recursos definidos personalizadamente. Cada recurso tiene un nivel de permiso asociado (Use, Read, Write). Recursos de base de datos controlan acceso a bases de datos específicas - usuarios deben tener recursos de base de datos apropiados en sus roles para consultar o modificar datos. Recursos de aplicación protegen aplicaciones web, servicios REST, y rutinas. Recursos personalizados protegen operaciones de negocio específicas, útil para implementar verificaciones de autorización a nivel de aplicación.

Seguridad a Nivel de Aplicación

Seguridad a nivel de aplicación integra autenticación y autorización en aplicaciones web. Aplicaciones web configuran métodos de autenticación (Password, Kerberos, LDAP, OAuth 2.0), roles requeridos (Allowed Roles), y roles de escalación de privilegio (Dispatch Class). Escalación de privilegio permite a aplicaciones realizar operaciones en nombre de usuarios que los usuarios mismos no podrían realizar directamente. Esto se configura a través de la pestaña "Matching Roles" donde asigna roles que la aplicación puede usar. Siempre usar esto cuidadosamente ya que evita permisos de usuario normales.

Seguridad de Servicio

Seguridad de servicio controla qué servicios InterSystems IRIS están habilitados y quién puede accederlos. Servicios incluyen SQL (JDBC, ODBC), REST APIs, servicios web SOAP, Telnet, y CSP. Cada servicio puede habilitarse/deshabilitarse globalmente y restringirse por rol. Para sistemas de producción, deshabilitar servicios no usados para reducir superficie de ataque. Habilitar servicios solo para roles que los requieren. El servicio %Service_Login controla acceso al Management Portal y debería restringirse a administradores.

Auditoría

Auditoría proporciona logging completo de eventos relevantes de seguridad. Habilitar logging de auditoría en el Management Portal bajo System Administration > Security > Auditing. Configurar eventos a auditar: login/logout de usuario, cambios de rol/privilegio, acceso a base de datos, operaciones SQL, y eventos de aplicación personalizada. Logs de auditoría son resistentes a manipulación y almacenados en la base de datos IRISAUDIT. Usar APIs %SYS.Auditing para crear eventos de auditoría personalizada para eventos de seguridad específicos de aplicación. Revisión regular de log de auditoría detecta intentos de acceso no autorizado y violaciones de política.

Pautas de Implementación Práctica

1) Diseñar una jerarquía de rol coincidiendo con estructura organizacional y funciones de trabajo. 2) Crear recursos personalizados para operaciones de negocio sensibles. 3) Implementar verificaciones de autorización a nivel de aplicación usando $SYSTEM.Security.Check() en código. 4) Usar roles de escalación con moderación y documentar su necesidad. 5) Habilitar auditoría completa, especialmente para operaciones sensibles. 6) Revisiones de acceso regulares - verificar que usuarios tengan roles apropiados y remover privilegios innecesarios. 7) Implementar privilegio mínimo - otorgar permisos mínimos necesarios para funciones de trabajo. 8) Separar funciones administrativas de funciones de aplicación a través de diferentes roles y aplicaciones.