DIA 22, Taller de Seguridad en SOA Web Services Security. Primera línea en Seguridad SOA. Jesús Fernández Pérez Jesus.fdez.perez@accenture.com Vocal de La comisión de Seguridad AUTELSI Gerente de Seguridad en Accenture Technology 22 de Noviembre de 2007 1º ENCUENTRO NACIONAL DE LA INDUSTRIA DE SEGURIDAD
Índice 1. Retos y Tendencias de la Seguridad en SOA 2. Áreas Generales en que se debe aplicar la Seguridad 3. Primera Línea de Defensa. Web Services 4. Recomendaciones para la Seguridad en SOA Logo empresa, inamovible y de este tamaño 2
Retos y Tendencias de la Seguridad en SOA La Seguridad, Riesgo Clave para obtener Beneficios en SOA Security was the #1 SOA show stopper for UK and Netherlands respondents who were unable to implement some part of their SOA strategy as a result of security concerns and product shortcomings. - IDC SOA Adoption in U.K. and Netherlands - Survey Results at IDC SOA Conferences, April 2006 May 2006 50% of respondents to a global AMR survey ranked security issues as the No. 1 risk they face as they implement SOA. Establishing good governance processes and meeting user service level agreements were also ranked highly. - AMR Research Global SOA Survey: Patterns in Adoption February 08, 2007 Security was the 2nd most often cited reason for enterprises not adopting SOA. Feared exposing applications signals vulnerability and that the flexibility of SOA may come with the expense of reduced security. - Datamonitor The adoption of SOA among US and Western European enterprises (Customer Focus) April 2006 3
Retos y Tendencias de la Seguridad en SOA La propia naturaleza de SOA convierte en inadecuados muchos de los métodos tradicionales para la evaluación y la aplicación de seguridad en aplicaciones. Subscriber Business Objects Data Client Componentes fuertementes enlazados son más fáciles de securizar. Component Application Architecture Subscriber Services Business Objects Data Client Service 1 Service 2 Los servicios débilmente enganchados son más díficiles de securizar, teniendo que llegar a compromisos. Service Oriented Architecture 4
Indice. Seguridad en SOA Retos y Tendencias de la Seguridad en SOA Áreas Generales en que se debe aplicar la Seguridad Primera Línea de Defensa. Web Services Recomendaciones para la Seguridad en SOA 5
Áreas Generales en que se debe aplicar la Seguridad Áreas comunes que deben ser evaluadas para determinar los controles de seguridad apropiados que deben ser implantados. Las transacciones complejas entre varias partes, requieren métodos detallados que aseguren resultados correctos de extremo a extremo Puedo asegurar que habrá controles/registros apropiados para garantizar los resultados de una transacción realizada? La multiplicidad de protocolos de transporte, así como la naturaleza sin estado de las transacciones requiere nuevos métodos para la identificación de los cliente Puedo garantizar que las transacciones se realizan sólo por partes de confianza (envío y recepción? Autenticación Los cambios en las políticas de seguridad tienen mayor impacto en una arquitectura SOA Puedo desplegar rápidamente nuevos servicios sin comprommeter mis procesos internos de negocio? Los interfaces autodescriptivos posibilitan que todo el mundo en internet pueda ver las transacciones en texto en claro Puedo asegurar la privacidad de las transacciones (cumplimiento regulatorio sobre los datos confidenciales de clientes/negocios, etc.)? No-repudio Autorización Confidencialidad Integridad Administración La transacciones son invisibles para los mecanismos de filtrado y de control de acceso tradicionales Puedo asegurar que sólo se realizan transacciones autorizadas en el sistema? Puedo garantizar que las transacciones no son manipuladas? 6
Áreas Generales en que se debe aplicar la Seguridad Estándares y mecanismos de seguridad comunes que pueden ser aprovechados para imponer controles de seguridad apropiados a nivel de mensaje XML-Signature WS-Security XKMS Autenticación SAML XKMS WS-Security SSL/TLS WS-Security WS-Federation Liberty Alliance WS-Policy WS-Trust SPML XKMS WS-Privacy WS-SecureConversation WS-ActiveProfile WS-PassiveProfile XML-Encryption WS-Security SSL/TLS XKMS No-repudio Autorización Confidencialidad Integridad Administración WS-Authorization SAML XACML XML-Signature WS-Security SSL/TLS XKMS 7
Áreas Generales en que se debe aplicar la Seguridad Estas capacidades de seguridad podrían ser implementadas dentro de cada servicio. No obstante, a medida que los clientes tienden hacia arquitecturas SOA a escala empresarial, Se recomienda una solución a nivel de arquitecura. 8
Indice. Seguridad en SOA Retos y Tendencias de la Seguridad en SOA Áreas Generales en que se debe aplicar la Seguridad Primera Línea de Defensa. Web Services Recomendaciones para la Seguridad en SOA 9
Qué son los Web Services? Los Web services son aplicaciones autocontenidas, modulares, distribuidas y dinámicas, que pueden ser descritas, publicadas, localizadas o invocadas a través de la red, para crear productos, procesos, o cadenas de suministro. Pueden ser locales, distribuidos o basados en Web. Los Web services se construyen sobre estándares abiertos como TCP/IP, HTTP, Java, HTML y XML. Usan nuevos estándares tecnológicos como SOAP (Simple Object Access Protocol) para los mensajes y UDDI (Universal Description, Discovery and Integration) y WSDL (Web Service Description Language) para la publicación. El protocolo SOAP (Simple Object Access Protocol) define un modelo para el uso de mensajes simples de petición y respuesta, escritos en XML, como protocolo básico la comunicación electrónica. La mensajería SOAP es un mecanismo RPC independiente de la platafomas, pero puede ser usado para el intercambio de cualquier tipo de información XML. WSDL (Web Services Description Language) es un vocabulario XML que define los interfaces software para los web services. Organiza todos los detalles técnicos necesarios para la integración automática a nivel de programación. Se utiliza para la publicación del colaboraciones IBM WebSphere como web services. WSDL es a los web services como IDL es a los objetos CORBA. 10
Requerimientos de Seguridad en el Diseño de Web Services La seguridad es una parte importante de la infraestructura de Web Services, pero no siempre está incluida: Por defecto no hay integridad Quién puede interceptar mis llamadas a web services? Podría ser vulnerable a ataques de Denegación de Servicio Quién puede sobrecargar mi servidor web? Por defecto, no hay identificación Quién está utilizando mis servicios web? Por defecto, no hay confidencialidad Quién puede leer mis llamadas a servicios web? 11
Los Web Services son vulnerables Todo lo Fácil es peligroso! Uno de los aspectos más tentadores de los servicios web, es que gran parte de la complejidad se oculta al desarrollador, haciendo que los servicios web sean muy fáciles (y baratos) de desarrollar. La herramientas IDE avanzadas permiten una publicación casi instantánea. El procesamiento de peticiones, la serialización y el parseo de los datos es invisible al desarrollador. La capa SOAP se encarga de todo. Desarrollar un web service es tan sencillo que es fácil olvidar que la seguridad no forma parte del stack SOAP: No hay atenticación o autorización. Los datos de entrada no son validados aunque está disponible a través de objetos listos para usar. Se permite nuevamente el acceso a gran funcionalidad desde fuera del firewall. 12
Web Service Security (WSS) Web Service Security es la tarea de securizar los web services: Seguridad en la capa de Transporte proporcionando confidencialidad e integridad en el tránsito. Seguridad en la capa de Mensajes garantizando que los mensajes están conformes a la especificación. Gestión de Identidades y Acceso proporcionando autenticación, autorización e identificación. Administración de Seguridad de los Web Services permitiendo las trazas de auditoría y la administración de seguridad. Detección y Prevención de Intrusiones protegiendo contra las amenazas comunes a los web services 13
Arquitecturas de Web Service Security Las arquitecturas se pueden combinar, teniendo tanto gateways como agentes Enfoque de Agentes Distribuidos Los clientes y los servidores tienen agentes embedidos gestionados de forma centralizada No existe un punto único de fallo Enfoque Gateway Todo el tráfico se encamina a través de un gateway central. Un único objeto a gestionar 14
Diagrama general de una arquitectura de ejemplo Identity Source Internal Application SOAP / HTTP Auth² SOAP / HTTP Application Server #1 (.NET) HTML / HTTP SOAP / HTTP SOAP / HTTP Internal User HTML / HTTPS Internal Web Application SOAP / HTTPS Security Gateway SOAP / HTTPS SOAP / HTTP Application Server #2 (J2EE) Web User 3 rd Party Web Application Application Server #3 (Proprietary) 3 rd Party Application 15
Demo Item SAML Assertion Identity Source Trust 1. HTML / HTTP 3. SOAP / HTTP 5. SOAP / HTTP 3 rd Party User 3 rd Party Web Application Security Gateway Application Server 1. El usuario accede al sitio web. Se autentica. 2. La aplicación web autentica al usuario y genera un SAML Assertion en nombre del usuario. 3. La aplicación web autentica contra el Gateway de Seguridad, usando el SAML Assertion del usuario en la capa de mensaje. 4. El Gateway de Seguridad comprueba la validez del SAML Assertion. Se produce la autorización. 5. El mensaje SOAP es firmado por el Gateway de Seguridad y se pasa al Servidor de Aplicación para su procesamiento. 16
Retos pendientes Los productos de Web Service Security están madurando poco a poco pero no siempre permiten todo lo que se espera de ellos. Falta de integración nativa con infraestructuras PKI y de Gestión de Identidades y Acceso. La industria, en general, no tiene experiencia con entornos SOA con web services complejos securizados. Experiencia principalmente en securizar servicios individuales. Falta de patrones y arquitecturas de ejemplo, especialmente aquellas que involucren Enterprise Service Buses (ESB). 17
Indice. Seguridad en SOA Retos y Tendencias de la Seguridad en SOA Áreas Generales en que se debe aplicar la Seguridad Primera Línea de Defensa. Web Services Recomendaciones para la Seguridad en SOA 18
Recomendaciones 1. Seguir los estándares 2. No hacerlo más difícil de lo necesario 3. Asegurarse que los stacks WSS con los que nos debemos integrar soportan nuestro diseño No todos los stacks tiene todas las funcionalidades ni siquiera los del estándar básico WSS 1.0 Podríamos acabar teniendo un diseño no implementable 4. Reducir el uso de encriptación, firmas y certificados al mínimo posible El mantenimiento de certificados es costoso en tiempo Se debe contruir y mantener la infraestructura que los soporte Las operaciones criptográficas disminuyen la velocidad de la infraestructura 19
Recomendaciones 5. Establecer adecuadamente los requisitos. No plantear funcionalidad innecesaria. 6. Seguir las recomendaciones WS-I respecto a: Seguir especificaciones bien definidas: Ratificadas en OASIS, con perfiles en WS-I (p.ej. WS-Security Username, X509, SAML) Amplio soporte de la industria Elegir bien el token: Username: requiere un directorio X509: requiere PKI; autenticación organizativa SAML: el token mas extendido, permite declaraciones sobre usuarios individuales Kerberos: No es siempre operativo para procesos de autenticación cross-organizacional 20