Analista de middleware
Los analistas de middleware son ingenieros de software informático especializados en productos que conectan dos sistemas informáticos diferentes. Estos productos pueden ser de código abierto o de propiedad exclusiva. Como lo indica el término, el software, las herramientas y las tecnologías que utilizan los analistas de middleware se encuentran "en el medio", entre dos o más sistemas; el propósito es permitir que dos sistemas se comuniquen y compartan información.
Roles y responsabilidades
Los analistas de middleware [1] analizan el sistema de sistemas . [2] Resuelven problemas técnicos que involucran objetivos interdisciplinarios a gran escala con múltiples sistemas distribuidos y heterogéneos que están integrados en redes en múltiples niveles. [3] Los analistas de middleware tienen y mantienen la competencia en tecnologías de middleware. El middleware es un software de computadora que conecta componentes de software o aplicaciones. Un tema central en la mayoría de los roles de analista de middleware es poder articular por qué la Arquitectura Orientada a Servicios ( SOA ) es importante para el negocio. [4]
Mejores prácticas para implementaciones
 | Esta sección puede resultar confusa o poco clara para los lectores . ( Septiembre de 2013 ) |
Las mejores prácticas de middleware promueven la usabilidad y la facilidad de mantenimiento entre los sistemas atendidos. Aquí se incluyen algunos ejemplos de mejores prácticas para brindar una idea de cómo el middleware aborda los principios clave de la computación basada en estándares .
Un problema común del middleware es la forma en que se configuran las aplicaciones definidas por el usuario para que las referencias de colas eviten las definiciones de alias de cola que hacen referencia directamente a la definición de cola local o cola remota. Esta omisión de alias de cola se aparta de las mejores prácticas y debería corregirse cuando el administrador o el programador puedan hacerlo dentro de los parámetros de tiempo y alcance. Todas las referencias de las aplicaciones definidas por el usuario deberían apuntar a alias de cola. A continuación, los alias de cola deberían apuntar a la cola local o la cola remota definidas.
Los alias de cola [5] permiten a los administradores de middleware tener flexibilidad para resolver o aliviar problemas de producción rápidamente. Al utilizar alias de cola, los administradores de middleware pueden redirigir el flujo de mensajes , en caso de un problema de servicio, sin realizar cambios en la aplicación definida por el usuario. Por ejemplo, si una cola local se desbordara, un administrador de middleware podría cambiar el alias de cola para que apunte a una cola local temporal, lo que permitiría que la aplicación definida por el usuario continúe su procesamiento sin interrupciones mientras se corrige la causa raíz subyacente.
Al apuntar todas las referencias de aplicaciones definidas por el usuario a alias de cola, se conserva la flexibilidad que tendrían los administradores de middleware para ayudar con los problemas de producción que pudieran surgir. Si no se siguieran las prácticas recomendadas de los alias de cola, se vería obstaculizada la capacidad de un administrador de middleware para ayudar con una interrupción de la producción.
Habilidades
La cola de mensajes (“MQ”) es una tecnología de middleware que simplifica enormemente la comunicación entre los nodos de un sistema y entre los nodos que conectan los sistemas entre sí. Los consultores de sistemas de información utilizan la cola de mensajes como base de sus habilidades. Sobre esta base, los consultores de sistemas de información añaden gestión de flujo de trabajo, intermediación de mensajes e implementaciones J2EE mediante máquinas virtuales Java ( JVM ) y Message Driven Beans (MDB).
Se podría decir que la habilidad más importante que utiliza un analista de middleware no es técnica, sino cultural. La SOA requiere que las personas piensen en los negocios y la tecnología de manera diferente. En lugar de pensar primero en la tecnología, los analistas de middleware deben pensar primero en términos de funciones o servicios comerciales. Se espera que la adopción de SOA cambie los departamentos de TI de las empresas, creando organizaciones de TI orientadas a los servicios (en lugar de a la tecnología). Los analistas de middleware realizan una importante labor de difusión de este concepto.
El bus de servicios empresariales es un elemento central de cualquier SOA . Los ESB proporcionan la conectividad "de cualquier tipo" entre los servicios dentro de una empresa y más allá de esa empresa para conectar con los socios comerciales de la empresa. Por lo tanto, los analistas de middleware deben ser expertos en los conceptos de SOA y bus de servicios empresariales, en primer lugar. Los analistas de middleware se basan en una arquitectura de referencia SOA para diseñar un entorno SOA que satisfaga las necesidades y prioridades de la empresa. El ESB es parte de esta arquitectura de referencia y proporciona la columna vertebral de una SOA, pero no se considera una SOA en sí mismo.
Preocupaciones de seguridad
Prácticas comunes genéricas
Dado que el middleware es una herramienta multiplataforma, se espera que los analistas de middleware sean muy sofisticados. Las personas que diseñan e implementan el flujo de mensajes del middleware deben comprender completamente cómo funciona el modelo de seguridad en cada plataforma de destino. Esto puede incluir Windows , Unix , z/OS o IBM i .
El middleware protege los datos en tránsito mediante tecnología PKI y SSL . Los certificados de seguridad se obtienen de una autoridad de certificación y se implementan y actualizan periódicamente en los servidores. Esto protege los datos mientras están en tránsito, desde que salen de un servidor hasta que llegan al siguiente servidor de la cadena. No protege los datos mientras están en reposo.
La seguridad de transmisión complementaria puede complementar las medidas SSL principales que existen en su servidor. Estas son la autenticación de cliente SSL, el filtrado de DN, la verificación de CRL por LDAP y el hardware criptográfico (cifrado a nivel IPSEC). Este tipo de seguridad se denomina "seguridad a nivel de frontera" porque solo protege los datos desde que salen de sus fronteras hasta que llegan a las fronteras de su socio comercial. No protege los datos una vez que han ingresado a la frontera. IPSEC es el método de protección más eficiente y menos costoso. SSL es el término medio, con un equilibrio entre flexibilidad, consumo de recursos y tiempo de transmisión.
Cuando los datos se encuentran en reposo en colas, no están protegidos por MQ. Es decir, los datos están en "texto simple". Por lo tanto, si los datos contenidos en los mensajes son confidenciales, es esencial que se utilice el cifrado de datos a nivel de aplicación . Algunos ejemplos de datos que podrían protegerse con esta estrategia incluyen datos bancarios (números de cuenta, transacciones bancarias, etc.). La seguridad de transacciones a nivel de aplicación es la forma de protección más segura, pero también la más costosa en términos de consumo de CPU y ancho de banda de E/S tanto de los servidores de envío como de recepción. También es la menos eficiente.
Los canales de datos de middleware se pueden configurar para proporcionar distintos grados de protección. Se puede configurar un par de canales de remitente/receptor para proporcionar seguridad a nivel de transporte IPSEC sin utilizar SSL. Se puede configurar un segundo par de canales de remitente/receptor para proporcionar seguridad a nivel de borde a borde SSL sin utilizar IPSEC. Se puede configurar un tercer par de canales de remitente/receptor para proporcionar cifrado a nivel de aplicación. Con este esquema, se proporciona una amplia selección de mecanismos de protección entre los que las aplicaciones pueden elegir en tiempo de ejecución. Esto ofrece a las aplicaciones la capacidad de lograr la mejor seguridad cuando sea necesario o una seguridad más eficiente cuando los datos no sean tan sensibles.
Consideraciones específicas de HIPAA
Si su empresa maneja datos ePHI de HIPAA , entonces sus analistas de middleware necesitan conocer y comprender los requisitos establecidos por la ley . [6] La falta de protección de los datos en reposo puede exponer a su organización a multas y sanciones impuestas por el gobierno federal u otra autoridad. [7] Esto requiere el cifrado de datos a nivel de aplicación antes de entregar los datos al sistema de colas para su transporte. [8]
Los administradores de sistemas, incluidos los analistas de middleware, no pueden ver datos de ePHI sin protección. Por lo tanto, siempre que haya datos de ePHI en cualquier sistema de información, deben protegerse de la posibilidad de que un administrador los vea. No está permitido permitir que los datos de ePHI se mantengan en una cola sin protección.
Véase también
Referencias
- ^ "Analista de middleware, tecnología emergente". Archivado desde el original el 20 de agosto de 2010. Consultado el 4 de septiembre de 2009 .
- ^ Agrawal, M.; Graba, L. (2005). "Requisitos de middleware distribuido para software de control y aviónica dispar". 24.ª Conferencia sobre sistemas de aviónica digital . Vol. 2. págs. 8.B.4-1-8.B.4-5. doi :10.1109/DASC.2005.1563466. ISBN 0-7803-9307-4. Número de identificación del sujeto 23776303.
- ^ Tai, Stefan; Lamparter, Steffen (2008). "Servicios de modelado: una perspectiva interdisciplinaria". Comunicaciones en informática y ciencias de la información . 8 : 8–11. doi :10.1007/978-3-540-78999-4_2. ISBN 978-3-540-78998-7.
- ^ "Eliminado".
- ^ "Guía de administración del sistema". Archivado desde el original el 27 de septiembre de 2003. Consultado el 4 de septiembre de 2009 .
- ^ "Copia archivada" (PDF) . Archivado desde el original (PDF) el 19 de abril de 2009. Consultado el 4 de mayo de 2009 .
{{cite web}}: CS1 maint: copia archivada como título ( enlace ) - ^ "HIPAA: Ley de Portabilidad y Responsabilidad del Seguro Médico". Archivado desde el original el 22 de abril de 2009. Consultado el 4 de mayo de 2009 .
- ^ "Nosotros-en_software_HP". 9 de noviembre de 2020.
