Seguridad en SOA a gran escala

4

Supongamos una arquitectura orientada a servicios (SOA) con cientos de servicios. Los servicios están completamente aislados, lo que está detrás de sus API es un detalle de implementación.

Los diferentes servicios pueden tener diferentes políticas de seguridad, es decir, quién puede acceder al servicio. Por ejemplo, un servicio puede ser completamente público, accesible para un subconjunto de empleados, accesible para un subconjunto de otros servicios, etc. Algunos servicios pueden incluso tener eso especificado en el nivel de API, por ejemplo, un servicio público con algunas llamadas internas de API ( ¿Es esa una mala idea?).

¿Cómo debe la infraestructura que interconecta los servicios reflejar las políticas de seguridad? ¿Hay algún enfoque estándar para esto? ¿Se sabe cómo lo hace Amazon? Seguramente deben tener una solución automatizada?

Busqué un poco en Google pero no encontré ningún buen recurso sobre esto. Los enlaces están absolutamente bien como respuestas a esta pregunta :)

    
pregunta fhucho 14.04.2014 - 21:44
fuente

2 respuestas

1

Bueno ... esa es una pregunta bastante amplia, pero, déjame ver qué puedo descubrir para ti. Comencemos con sus preguntas:

  1. Algunos servicios pueden incluso tener eso especificado en el nivel de la API, por ejemplo, un servicio público con algunas llamadas internas a la API (¿es una mala idea?).

No estoy seguro de entender lo que se pregunta aquí. Cuando dices "llamada a la API interna", asumo que te refieres a un servicio privado al que la API pública está accediendo. Esto es de hecho "ok", suponiendo que el servicio interno está detrás de un firewall estricto.

  1. ¿Cómo debe la infraestructura que interconecta los servicios reflejar las políticas de seguridad? ¿Hay algún enfoque estándar para esto?

Comencemos con la creación de un nuevo servicio. Recomiendo encarecidamente ver este libro , especialmente para los controles de acceso. Esencialmente, un servicio o tema creado recientemente debe asumir lo siguiente:

  • Se debe aplicar una política predeterminada segura a cualquier tema creado recientemente
  • Los atributos del sistema no deben expresarse en términos que puedan falsificarse fácilmente, como una dirección IP.
  • Una ID de usuario o una ID de servicio deben permanecer asignadas permanentemente a un servicio / asunto

Una vez creado, el servicio deberá comunicarse con sus servicios internos. En términos de seguridad y políticas, esto es bastante difícil de responder ya que depende de lo que elija para transferir los protocolos / messaging / etc ... Por ejemplo, usar una arquitectura interna como ESB . Aquí hay algunos artículos para describir el uso de ESB:

y algunos artículos centrados en la seguridad que describen SOA ESB:

Sin embargo, sí sé que Amazon no usa ESB a través de este artículo , aunque sí encontré algunos artículos que pueden ayudar también:

Nuevamente, las políticas de seguridad reflejarán el protocolo de transferencia / protocolo de mensajería, etc., de servicio a servicio. Por ejemplo, los servicios que se comunican a través de puertos propietarios (todos detrás de un firewall).

Espero que algo allí pueda ayudar!

    
respondido por el dperconti 23.04.2014 - 20:32
fuente
1

Amazon y otros utilizan "Descripción Universal, Descubrimiento e Integración" (UDDI) que tiene es propio estándar . Las compañías se unen bajo el quitarlo , sin embargo, existen normas. Comenzaría aquí para obtener un índice, luego here , seguido de una variación de las búsquedas de algo más específico (por ejemplo: UDDI, SOA, sitio WSDL: aws.amazon.com o cualquier otro) proveedor). También digno de mención: " Un enfoque de auditoría de seguridad de principio a fin para arquitecturas orientadas a servicios "

    
respondido por el munkeyoto 19.12.2014 - 23:36
fuente

Lea otras preguntas en las etiquetas