Sicurezza in SOA su larga scala

4

Supponiamo un'architettura orientata ai servizi (SOA) con centinaia di servizi. I servizi sono completamente isolati: ciò che è dietro le loro API è un dettaglio di implementazione.

Diversi servizi possono avere diverse politiche di sicurezza, ad esempio chi può accedere al servizio. Ad esempio, un servizio può essere completamente pubblico, accessibile a un sottoinsieme di dipendenti, accessibile a un sottoinsieme di altri servizi, ecc. Alcuni servizi potrebbero persino avere quello specificato a livello di API, ad esempio un servizio pubblico con alcune chiamate API interne ( è una cattiva idea?).

In che modo l'infrastruttura che interconnette i servizi riflette le politiche di sicurezza? Esistono approcci standard a questo? È noto come Amazon lo fa - sicuramente devono avere una soluzione automatizzata?

Ho cercato su Google un po ', ma non ho trovato alcuna buona risorsa su questo. I collegamenti sono assolutamente ok come risposta a questa domanda:)

    
posta fhucho 14.04.2014 - 21:44
fonte

2 risposte

1

Bene .. questa è una domanda abbastanza ampia, ma, fammi vedere quello che posso scoprire per te. Iniziamo con le tue domande:

  1. Alcuni servizi potrebbero persino avere quello specificato a livello di API, ad esempio un servizio pubblico con alcune chiamate API interne (è una cattiva idea?).

Non sono sicuro di capire cosa viene chiesto qui. Quando si dice "chiamata API interna", presumo che si stia facendo riferimento a un servizio privato a cui l'API pubblica sta accedendo. Questo è effettivamente "ok", assumendo che il servizio interno sia protetto da un firewall rigido.

  1. In che modo l'infrastruttura che interconnette i servizi riflette le politiche di sicurezza? Esistono approcci standard a questo?

Iniziamo con la creazione di un nuovo servizio. Consiglio vivamente di visualizzare questo libro , in particolare per i controlli di accesso. In sostanza, un servizio o soggetto appena creato dovrebbe assumere quanto segue:

  • Una politica di sicurezza sicura dovrebbe essere applicata a qualsiasi soggetto appena creato
  • Gli attributi del sistema non devono essere espressi in termini che possono essere facilmente falsificati come un indirizzo IP.
  • Un ID utente o ID servizio dovrebbe rimanere assegnato in modo permanente a un servizio / soggetto

Una volta creato, il servizio dovrà quindi comunicare con i servizi interni. In termini di sicurezza e politica, è piuttosto difficile rispondere in quanto dipende da cosa si sceglie per i protocolli di trasferimento / messaggistica / ecc ... Ad esempio, utilizzando un'architettura interna come ESB . Ecco alcuni articoli per delineare l'utilizzo di ESB:

e alcuni articoli incentrati sulla sicurezza che descrivono SOA ESB:

Tuttavia, so che Amazon non usa ESB tramite questo articolo , anche se ho trovato alcuni articoli che potrebbero aiutare pure:

Ancora una volta, le politiche di sicurezza rifletteranno ciò che il protocollo di trasferimento / protocollo di messaggistica, ecc. per il servizio al servizio. Ad esempio, servizi che comunicano tramite porte proprietarie (tutte dietro a un firewall).

Spero che qualcosa in là possa aiutarti!

    
risposta data 23.04.2014 - 20:32
fonte
1

Amazon e altri usano "Universal Description, Discovery and Integration" (UDDI) che ha è proprio standard. Le aziende si riuniscono sotto il gruppo OASIS per affrontare gli standard relativi a SOA, UDDI, WSDL , SOAP, ecc. Ci sono molte aziende che si rivolgono al software per estrapolandolo tuttavia, ci sono degli standard. Comincerei qui per un indice, quindi qui , seguito da una variazione di ricerche per qualcosa di più specifico (es .: UDDI, SOA, sito WSDL: aws.amazon.com o qualsiasi altra fornitore). Degno di nota: " Un approccio di verifica della sicurezza end-to-end per architetture orientate ai servizi "

    
risposta data 19.12.2014 - 23:36
fonte

Leggi altre domande sui tag