Debido a soluciones orientadas a servicios se componen típicamente de servicios agregados, cada componente dentro de una arquitectura de composición de servicios puede convertirse en un blanco potencial de violación de seguridad. Las arquitecturas de servicios necesitan ser provistas de controles adicionales que les permiten soportar las formas más comunes de ataques de consumidores maliciosos.
Patrón de Subsistema de Confianza
Problema
Cuando los recursos subyacentes de servicios, tales como bases de datos, se puede acceder directamente por los programas de los consumidores, la seguridad de los recursos puede verse comprometida por atacantes maliciosos y/o programas de los consumidores que pueden formar dependencias no óptimas en los componentes de una arquitectura de servicios que pueden conducir a formas negativas del consumo de servicios acoplados. Este problema se puede esquematizar en la siguiente figura:
Solución
El servicio actúa como un subsistema de confianza de sus recursos subyacentes. Los consumidores sólo pueden acceder a los recursos a través del servicio y el servicio utiliza sus propias credenciales en lugar de las credenciales de los consumidores para llevar a cabo el acceso a los recursos.
Varios enfoques y tecnologías pueden ser utilizados para implementar este modelo:
- Utilización de cuentas de servicio se en el subsistema de confianza. Un método común de implementación de verificación es el protocolo Kerberos es utiliza una cuenta de servicio dentro del subsistema de confianza.
- Utilización de Cuentas locales en cada host. Cuando no sea posible realizar la autenticación de las cuentas de servicio mediante Kerberos, se puede crear una cuenta local en cada equipo en el subsistema de confianza. Este tipo de cuentas son como "cuentas espejos", donde cada uno tendrá el mismo nombre de usuario y contraseña. Estas"cuentas espejo", requieren contraseñas complejas que necesitan ser cambiadas con regularidad.
- Utilizando un método de autenticación como PKI (Infraestructura de Clave Pública) y el estandar X.509 se utiliza para la autenticación en el subsistema de confianza. PKI X.509 puede generar un certificado para cada aplicación dentro de un subsistema de confianza. Para acceder a los recursos del servicio debe utilizar un certificado X.509, como base para la autenticación. Además, el certificado debe estar en la lista de certificados que están autorizados a acceder al recurso.
- Utilizar IPSec entre equipos en el subsistema de confianza para que la comunicación sea segura. IPSec asegura mensajes entre dos equipos en la capa de red para proporcionar confidencialidad e integridad de datos. Puede ser configurado para iniciar una comunicación segura con el protocolo Kerberos, certificados X.509, o una clave previamente compartida. IPSec funciona considerablemente mejor que la seguridad en la capa de mensajes, pero no permite un control granular de los recursos. Esto se debe a que, con IPSec, un subsistema de confianza sólo se puede establecer entre los equipos que participan en el subsistema de confianza y no en un programa específico para acceder a un recurso específico. La solución a este problema se puede esquematizar en la siguiente figura:
Impactos
Si un servicio de implementación del Subsistema de confianza está en peligro, que puede ser utilizado para explotar los recursos indirectos que tiene acceso. Por esta razón, los servicios que actúan como subsistemas de confianza a menudo se vuelven los principales objetivos de los atacantes de la sonda en busca de vulnerabilidades dentro de la empresa.
Patrón de Servicio de Seguridad Perimetral
Problema
Los consumidores externos necesitan tener acceso a uno o más servicios desplegados en una red privada. Al proporcionar un acceso directo a la red privada los servicios son expuestos a los atacantes externos que pueden obtener la información interna y utilizarla para comprometer los servicios y la red. Este problema se puede esquematizar en la siguiente figura:
Solución
Colocar un servicio de intermediación en el perímetro de la red privada y se establece como el punto de contacto único para los consumidores externos para que pueden acceder a servicios internos.
Este tipo de servicio suele ser desplegados en una red perimetral (también conocida como DMZ o zona desmilitarizada), que tiene acceso a los recursos de la red privada a través de un firewall. Funciona en la capa de aplicación y su objetivo es trabajar en conjunto con las tecnologías de firewall existentes (y no para sustituirlos). Un consumidor externo enviará un mensaje de solicitud dirigida zona externa del servicio perimetral, que a su vez reenvía a los servicios internos. Del mismo modo, cuando un servicio interno responde, los servicios del tipo Relay de la zona perímetral da una respuesta a los consumidores externos. A lo largo de este intercambio, la ubicación y el contrato del servicio interno permanece oculto a los consumidores externos.
Una de las principales ventajas del servicio perimetral de seguridad es que se puede establecer el proceso de seguridad centralizada en nombre de otros servicios. Esto permite una arquitectura que se construirá en torno a un perímetro de servicios capaz de implementar otros modelos de seguridad. La solución a este problema se puede esquematizar en la siguiente figura:
Impactos
El uso de los servicios de perímetrales pueden agregar complejidad y la sobrecarga de procesamiento y además puede presentar problemas de rendimiento cuando sea necesario dirigir y aplicar el proceso de seguridad a un gran número de mensajes. Como el único punto de entrada para una red privada, este tipo de servicio también puede convertirse en un objetivo principal para los atacantes. Esto requiere que los servicios perimetrales sean lo suficientemente robustos para soportar ataques masivos. Además, el uso de este patrón no reduce la necesidad de asegurar los servicios internos, especialmente en relación con la comunicación que debe producirse entre servicios interior y servicios perimetrales.
