DIA 22, Taller Seguridad en Arquitecturas Orientadas a Servicios (SOA): SOA Seguro con Oracle

Transcripción

1 DIA 22, Taller Seguridad en Arquitecturas Orientadas a Servicios (SOA): SOA Seguro con Oracle PACO BERMEJO SOA TEAM LEADER ORACLE 22/11/07 1º ENCUENTRO NACIONAL DE LA INDUSTRIA DE SEGURIDAD

2 Índice 1. La Necesidad de Seguridad en SOA Definir Una Vez, Aplicar en Cualquier Sitio 2. Características de Seguridad en SOA 3. Seguridad SOA con Oracle: Oracle Web Services Manager 2

3 Índice 1. La Necesidad de Seguridad en SOA Definir Una Vez, Aplicar en Cualquier Sitio 2. Características de Seguridad en SOA 3. Seguridad SOA con Oracle: Oracle Web Services Manager 3

4 Compartir Servicios Tipos de Servicios a Compartir Fuente: InfoWorld Research

5 El Principal Obstáculo Sigue Siendo la Seguridad Fuente: InfoWorld Research

6 Nuestra Visión... La seguridad en SOA es un objetivo fácilmente alcanzable... 6

7 Nuestra Visión siempre que se cuente con las herramientas adecuadas 7

8 Necesidades de Seguridad en SOA Acceso a recursos y servicios por HTTP (principalmente) Puerto 80 no seguro Mensajes legibles (XML): seguridad requerida en el nivel del mensaje Seguridad declarativa No más seguridad hard-coded Definición centralizada de la seguridad Políticas en un punto único de control y administración Aplicación localizada de la seguridad Los puntos de aplicación de políticas se distribuyen por todo el entorno Entornos heterogéneos Estándares de la industria para integración e interoperabilidad Despliegue flexible (soporte multiplataforma) 8

9 Caso de Uso 1 Aplicación SOA 9

10 Caso de Uso 1 Vulnerabilidades de Seguridad 10

11 Caso de Uso 1 Ejemplo de Seguridad 11

12 Caso de Uso 2 Aplicación Web Invocando Web Services 12

13 Índice 1. La Necesidad de Seguridad en SOA Definir Una Vez, Aplicar en Cualquier Sitio 2. Características de Seguridad en SOA 3. Seguridad SOA con Oracle: Oracle Web Services Manager 13

14 Requisitos Autenticación Verificar que el usuario es quién dice ser Autorización-Control de Acceso Verificar que el usuario autenticado tiene derechos de acceso a los servicios invocados Confidencialidad Ocultar todo o parte de un documento usando encriptación Integridad, no repudio Firma digital de un documento por parte de una autoridad Mediación de credenciales Intercambiar tokens de seguridad en un entorno de confianza Capacidades y restricciones de los servicios Definir qué puede hacer un servicio, y bajo qué circunstancias 14

15 Seguridad de Servicios Capas de implementación 15

16 Seguridad de Servicios La Mejor Opción es Seguridad en la Capa de Mensajes 16

17 Frameworks de Seguridad Estándares de la Industria 17

18 Seguridad de aplicación Complementa la seguridad de transporte (SSL) Basada en frameworks XML Confidencialidad, Integridad, Autenticidad XML Encryption, XML Signature Estructura del Mensaje, Seguridad del Mensaje SOAP, WS-Security Trust Management / Federación WS-Trust WS-SecureConversation Metadatos WS-Policy, WS-PolicyAttachment WS-MetadataExchange 18

19 Confidencialidad, Integridad, Autenticidad XML Encryption, XML Signature XML Encryption (confidencialidad de datos) Como se encripta y desencripta el contenido digital Como se pasa la información de la clave de encriptación a un receptor Como se identifican los datos encriptados para facilitar la desencriptación XML Signature (integridad de datos, autenticidad) Enlazar la identidad del emisor ( entidad de firma ) a un documento XML La firma y verificación de firma se puede hacer usando claves simétricas o asimétricas Asegurar el no-repudio de la entidad firmante Prueba que los mensajes no han sido alterados desde la firma 19

20 Estructura y Seguridad del Mensaje SOAP, WS-Security WS-Security define cómo adjuntar cabeceras XML Signature y XML Encryption a mensajes SOAP WS-Security proporciona perfiles para 5 tokens de seguridad: Nombre de usuario (password opcional) Certificados X.509 Ticket Kerberos Aserción SAML Documento REL (rights markup) 20

21 Índice 1. La Necesidad de Seguridad en SOA Definir Una Vez, Aplicar en Cualquier Sitio 2. Características de Seguridad en SOA 3. Seguridad SOA con Oracle: Oracle Web Services Manager 21

22 Oracle Fusion Middleware 22

23 Oracle Identity Management Access Manager Web Access Control/Single Sign-On Web Services Manager SOA Security esso Suite Desktop/Legacy Single Sign-On Auditing & Reporting Compliance & Attestation Identity Federation Cross Domain Single Sign-On Identity Manager Enterprise User Provisioning Systems Mgmt Monitoring & Management Directory Services Identity Virtualization, Synch & Storage 23

24 Oracle SOA Suite BPA Suite GESTIÓN y MONITORIZACIÓN Herramientas de Análisis JDeveloper Framework Desarrollo Aplicaciones BAM ENRUTADO Monitorización Eventos y ORQUESTACIÓN Análisis de Negocio BPEL Process Manager BPEL Nativo EVENTOS y CONECTIVIDAD Enterprise Service Bus Multi Protocolo Workflow Humano Transformación XSLT BI Reglas de Negocio Enrutado Enterprise Manager Monitorización GOBIERNO de Sistema Web Services Manager Políticas Seguridad Adaptadores B2B SES Registry Apps DB Legacy Partners RFID UDDI Mensajería Servidor de Aplicaciones J2EE Oracle AS, JBoss, WebLogic, WebSphere 24

25 Gestión de Identidades y SOA Gestión Id. Oracle Internet Directory Oracle Access Manager OWSM SOA OC4J / UDDI Registry / OLite Oracle BPEL Process Mgr Oracle Ent. Service Bus Entornos de terceros - Infraestructuras de gestión de identidades - Directorios LDAP - Registros UDDI - Aceleración XML 25

26 La realidad de seguridad en SOA Clientes portal Servicios.Net CICS wrap AuthN AuthZ SAML Servicios J2EE J2EE AuthN LDAP AuthN LDAP AuthZ Routing Legacy LDAP AuthZ XSLT Traducción Protocolo J2EE AuthZ Partners B2Bi AD AuthN AD AuthZ WS-Security SAML XMLEncrypt Traducción Protocolos SLA Procesos BPM WS AuthN Enrutado CRM Biz service DBMS AuthZ WS-Security Failover B2B FRONT OFFICE SERVICIOS DE INTEGRACIÓN BACK OFFICE Arquitectos Seguridad Operaciones 26

27 Evitar acoplamiento en SOA Clientes portal Servicios.Net CICS wrap AuthN AuthZ SAML Servicios J2EE J2EE AuthN LDAP AuthN LDAP AuthZ Routing Legacy LDAP AuthZ XSLT Traducción Protocolo J2EE AuthZ Partners B2Bi AD AuthN AD AuthZ WS-Security SAML XMLEncrypt Traducción Protocolos SLA Procesos BPM WS AuthN Enrutado CRM Biz service DBMS AuthZ WS-Security Failover B2B FRONT OFFICE SERVICIOS DE INTEGRACIÓN BACK OFFICE Arquitectos Seguridad Operaciones 27

28 Gestión Proactiva de Políticas Customers portal Lógica.NET CICS wrap OWSM PEP Lógica J2EE OWSM PEP Legacy OWSM PEP OWSM PEP Trading Partners B2Bi OWSM PEP Lógica BPM OWSM PEP CRM Lógica App OWSM PEP B2B Exchanges FRONT OFFICE SERVICIOS DE INTEGRACIÓN BACK OFFICE OWSM Monitor OWSM Policy Manager Arquitectos Seguridad Operaciones 28

29 Oracle Web Services Manager OWSM Proporciona una plataforma descentralizada para la definición y aplicación de políticas operativas en aplicaciones y web services Gestiona las mejores prácticas de seguridad y administración a lo largo de todas las aplicaciones (SSL, XML Encryption, XML Signature, WS-Security, WS-Policy, SAML) No requiere modificaciones en las aplicaciones o servicios (no hay necesidad de seguridad programática) Proporciona soporte declarativo de políticas de seguridad a lo largo de todos los sistemas en un un único punto de control (OWSM Policy Manager) Proporciona herramientas para la definición y monitorización de contratos de seguridad, acuerdos de nivel de servicio (SLA) y calidad de servicio (QoS) Dispone de herramientas para la construcción y monitorización de políticas operativas Dispone de agentes y gateways para la ejecución de las políticas en tiempo real Utiliza infraestructuras de gestión de identidades, como Oracle Access Manager, para la autenticación y autorización 29

30 Soporte de Estándares de Seguridad Encriptación: AES-128, AES-256, 3-DES Message Digest: MD5, SHA-1 Estructura del mensaje: XML / SOAP / WS-Security 1.0 Perfiles de tokens de seguridad: Username, X.509, SAML Integridad del mensaje: XML Signature Confidencialidad del mensaje: XML Encryption PKI Encriptación de clave: RSA OAEP-MGF1P, RSA V1.5 Algoritmos de firma: RSA (PKCS #1) (1024-, 2048-bit keys), DSA Almacén de credenciales, wallets: PKCS#12 30

31 Arquitectura Policy Enforcement Points (PEPs) Cliente Web Service Cliente Web Service Agente Contenedor J2EE o Servidor Web Contenedor J2EE Gateway SOAP sobre HTTP/S o RMI Proveedor Web Service Proveedor Web Service Agente Los PEPs pueden desplegarse tanto en el lado del proveedor (Agentes), como del cliente (Gateways) Consola de Administración Policy Mgr Monitor Componentes del Servidor OWMS (en Contenedor J2EE) 31

32 Consola 32

33 Monitorización Cuadros de mando de las actividades 33

34 Monitorización Eventos de Autenticación y Autorización 34

35 Monitorización Análisis de Tráfico 35

36 Monitorización Cumplimiento SLAs 36

37 Casos de Uso Típicos Protección del acceso a los servicios a través de un Gateway Protección del acceso a los servicios a través de un Agente en el servidor Protección del acceso a los servicios a través de un Agente en el cliente Acceso externo a servicios utilizando un Gateway como proxy inverso Mapeo de credenciales utilizando un Gateway y Agentes en el servidor Mediación entre distintos protocolos de transporte utilizando un Gateway Virtualización de los servicios utilizando un Gateway 37

38 Protección del acceso a servicios Usando un Gateway El pipeline de petición especifica la secuencia de pasos de políticas que deberían ejecutarse para peticiones entrantes Cliente Web Service 1 4 Gateway 2 3 Proveedor Web Service El pipeline de respuesta especifica la secuencia de pasos de políticas que deberían ser ejecutados para respuestas salientes El Gateway securiza el acceso a uno o más web services en el lado del proveedor de servicios Paso 1: El cliente realiza una petición a un web service Paso 2: El Gateway intercepta la petición, aplica políticas de seguridad (ej. desencriptación, verificación de firma, autenticación), y reenvía la petición al web service Paso 3: El web service devuelve una respuesta Paso 4: El Gateway intercepta la respuesta, aplica las políticas de seguridad (ej. encriptación) y reenvía la respuesta al cliente 38

39 Protección de acceso a los servicios Usando un Agente en el Cliente 2 Cliente Web Service 1 4 Agente Proveedor Web Service 3 El Agente OWSM protege el acceso al web service en el lado del proveedor de servicios (Agente de Servidor) Paso 1: El cliente realiza una petición a un web service Paso 2: El Agente intercepta la petición, aplica las políticas de seguridad (ej. desencriptación, verificación de firma, autenticación, autorización), y pasa la respuesta al web service Paso 3: El web service devuelve una respuesta Paso 4: El Agente intercepta la respuesta, aplica las políticas de seguridad (ej. encriptación) y pasa la respuesta al cliente 39

40 Solicitud de acceso a los servicios Usando un Agente en el Cliente 1 Cliente Web Service Agente 2 3 Proveedor Web Service 4 El Agente de Cliente OWSM aplica las políticas de web services desde la misma aplicación que el servicio cliente Paso 1: El cliente realiza una petición a un web service Paso 2: El Agente intercepta la petición, aplica las políticas de seguridad (ej. encriptación, etc.), y pasa la respuesta al web service Paso 3: El web service procesa la petición y devuelve una respuesta Paso 4: El Agente intercepta la respuesta, aplica políticas de seguridad (ej. desencriptación), y envía la respuesta al cliente 40

41 Acceso a Servicios Externos Usando un Gateway (como Proxy Inverso) Intranet Internet Cliente Web Service 1 4 Gateway 2 3 Proveedor Web Service El propósito es el de permitir el acceso a web services externos sólo para clientes específicos que realizan la petición desde la intranet corporativa Paso 1: El cliente (dentro de los límites de la intranet corporativa) realiza una petición a un web service externo Paso 2: El Gateway intercepta la petición, aplica las políticas de seguridad (autenticación, autorización) y reenvía la petición al web service Paso 3: El web service devuelve una respuesta Paso 4: El Gateway intercepta la respueta, aplica las políticas de seguridad, y reenvía la respuesta al cliente 41

42 Mapeo de Credenciales Usando Gateways y Agentes en el Servidor Cliente Web Service 1 2 Gateway 6 3 Agente 4 Proveedor Web Service 5 Id Usuario: fbermejo Creación aserción SAML con id usuario fbermejo Validación aserción SAML El cliente y el proveedor del servicio no soportan el mismo tipo de credenciales Paso 1: El cliente realiza una petición al servicio usando credenciales básicas ( fbermejo ) Paso 2: El Gateway intercepta y autentifica la petición Paso 3: Ante una autenticación correcta, el Gateway inserta una aserción SAML en una cabecera WS-Security que envía al proveedor del servicio como parte del mensaje SOAP Paso 4: El Agente valida la aserción SAML y pasa la petición al web service Paso 5: El web service devuelve una respuesta interceptada por el Agente para mayor seguridad Paso 6: El Agente devuelve la respuesta al cliente del servicio directamente o a través del Gateway 42

43 Mediación entre protocolos Utilizando un Gateway Internet Intranet 1 Cliente Web Service HTTP Gateway JMS Proveedor Web Service 2 Cliente Web Service JMS Gateway HTTP Proveedor Web Service El cliente y el proveedor del servicio no soportan el mismo protocolo En el caso 1, el Gateway reside en la intranet, y traduce la petición saliente HTTP a JMS En el caso 2, el Gateway reside fuera de la intranet, y proporciona acceso a servicios HTTP desde peticiones JMS 43

44 Virtualización de los servicios Utilizando un Gateway Cliente Web Service HTTP Gateway Los web services reales 123 y 456 se registran en el Gateway y se enlazan con el web service virtual ABC JMS HTTP Proveedor Web Service Web Service real 123 Nota: Por claridad, en este caso no se representan las respuestas Web service virtual ABC Ante el registro de un web service real, el Gateway genera un mapeo de URLs entre los web services virtual y real, permitiendo la aplicación de políticas diferentes para cada web service real Web Service Provider Web Service real 456 El Gateway OWSM proporciona virtualización de servicios Los web services reales se enlazan con servicios virtuales (en el Gateway) Los usuarios acceden primero al servicio web virtual, y, basándose en sus roles, los usuarios pueden acceder a web services reales seleccionados El protocolo de transporte también puede virtualizarse; por ejemplo, todos los usuarios acceden un web service virtual a través de un protocolo (ej. HTTP), y el servicio virtual puede pasar la petición a un web service real utilizando un protocolo diferente (ej. JMS) Los usuarios pueden crear múltiples versiones de un web service virtual y redirigir una versión más antigua del web service virtual a una nueva versión 44

45 En resumen La seguridad de web services debería ser externalizada No incluir seguridad programada en los web services Seguridad declarativa en un punto único de control La seguridad debería ser administrada Acuerdos de nivel de servicio (SLA) Calidad de servicio (QoS) Oracle proporciona una plataforma (Oracle Web Services Manager) que cumple los requisitos de seguridad y administración para entornos SOA 45

46 Para más información Web Services Manager o 46