Protezione dei servizi Web pubblici - Qual è la migliore pratica? [chiuso]

Come detto da Tom Leek, la sicurezza è un'area ENORME. Copre tutto da segreti di sicurezza, protocolli, risorse, alla privacy, ripudio, disponibilità, recupero di disastri ecc. So che hai iniziato la domanda sui protocolli, sto andando avanti un po 'di più perché non so se la tua percezione è quella solo aggiungerli sarà sufficiente per la sicurezza, o se hai già tutto il resto già protetto e questa è l'unica area rimasta.

Inoltre, la sicurezza è sull'intero stack, ovunque ci si assicuri che non si abbiano errori di codice (come buffer overflow) a tutte le patch di sicurezza applicate, alla progettazione globale sicura (come fanno gli utenti ad autenticarsi, controllo accessi, ecc. ).

Dovrai o restringere specificamente ciò che stai cercando di proteggere, o se stai cercando di migliorare la sicurezza in generale, prova questi:

• Guarda ISO 27034 e SDL di Microsoft che forniscono entrambe una guida prescrittiva su come spingere la sicurezza nel processo di sviluppo (Disclaimer: lavoro per Microsoft, e SDL è una delle mie fonti principali al lavoro e nei progetti personali .)
• Puoi anche consultare i libri di certificazione, come quelli per CISSP o CCSK di Cloud Security Alliance, che si concentrerà maggiormente sui vari principi di sicurezza applicabili. Certo, puoi cercare altre certificazioni e leggere le recensioni per scegliere quella migliore per il tuo scopo.

Entrambi questi, esp. SDL di Microsoft (solo perché ne ho una conoscenza approfondita) fornirà una guida molto prescrittiva e avrà dei collegamenti. Ho studiato CISSP, ma questo è più di un livello di capo ufficio di sicurezza. Entrambi sono comunque utili, ma se potessi fare solo uno, andrei con SDL, o con qualche risorsa che ha come target l'ISO 27034, o qualcosa di simile.

• Infine, non importa quanta parte di queste cose tu abbia letto, dovrai stare al corrente degli attuali problemi di sicurezza e assicurarti di continuare ad applicare le correzioni. Ad esempio, se si dispone di un sito Web, vi è una miriade di attacchi su XSS, XSRF, iniezione SQL, bombe XML, ecc. Che dovrete sapere e, a seconda di quali tecnologie utilizzate, dovrete garantire che non siano esposti il tuo servizio.
• Come questi attacchi, dovrai anche assicurarti di sapere quale software esterno stai utilizzando (incluso il sistema operativo), quali sono gli ultimi problemi di sicurezza e se hai applicato tutte le patch, ecc. Ciò significa che apache , IIS, Linux, Windows, lo chiami. Ad esempio, se hai usato OpenSSL (anche se non lo sapevi, ma per esempio l'installazione ce l'aveva), era meglio applicare una correzione per proteggersi dalla vulnerabilità di Heart Bleed.

Per quanto riguarda i protocolli, di solito si tratta del tuo progetto intorno a chi accederà, a cosa viene protetto, ecc., praticamente la maggior parte delle domande poste da Tom Leek. Tra alcuni protocolli (come OAUTH e SAML), non è tanto che differiscono per la sicurezza (a seconda delle esigenze), piuttosto che quelli diversi sono supportati da diverse parti con cui potresti voler integrare. Ad esempio, la maggior parte, se non tutti, gli IDP social (facebook, google, account Microsoft, linkedin, anche stackexchange) supportano OAUTH, e se si dovesse utilizzare uno di essi come provider di identità, si sarebbe costretti a consumare OAUTH e token formati supportati da uno di questi.

Tuttavia, se tu fossi il tuo IDP personale, avresti una scelta più ampia e dovresti considerare se vuoi usare una directory (specialmente se la tua organizzazione ne ha già una, come AD), o costruisci la tua . Una directory fornirà in genere un set di protocolli supportati per l'autenticazione. Se hai già un servizio di terze parti che la tua organizzazione sta utilizzando (ad es. SAP, Salesforce, Office online), potrebbe essere possibile utilizzare l'autenticazione da lì.

Spero che questo aiuti.

Chiedere la migliore pratica per garantire un servizio pubblico, senza altri dettagli, è come chiedere qual è la migliore auto. L'unica risposta può essere: dipende. Hai bisogno dell'auto per trasportare attrezzature pesanti? Per andare a lavorare in modo affidabile anche in una tempesta di neve? Percorrere le strade per ore come parte di un gruppo di vigilanti? Per conquistare potenziali compagni?

Dato che stiamo parlando di generalità, la prima cosa da fare è scrivere il modello di sicurezza :

• Quali risorse stai cercando di proteggere?
• Qual è l'estensione ipotizzata del potere, della motivazione e della pazienza degli aggressori?
• Qual è il valore di ciò che proteggi?

In particolare, per un servizio di rete pubblica, puoi o meno temere i seguenti casi (elenco non esaustivo):

• Un utente malintenzionato invia una richiesta al tuo servizio senza essere autorizzato a farlo.
• Un utente malintenzionato spia i dati scambiati tra il tuo servizio e un utente autorizzato.
• Un utente malintenzionato modifica una richiesta da un utente autorizzato al tuo servizio e / o modifica la risposta.
• Un utente malintenzionato si comporta come un falso clone del tuo servizio e parla con gli utenti senza che il tuo servizio venga mai messo al corrente.
• Un utente malintenzionato interrompe il servizio sovraccaricandolo.
• Un utente autorizzato spie su altri utenti autorizzati che accedono al servizio contemporaneamente.
• Le autorità legali ti chiedono di fornire l'identità dell'utente che ha inviato una richiesta specifica al tuo servizio e sei legalmente obbligato a conservare tali registri.
• Alcuni eventi locali (inondazioni, incendi, ...) riducono il tuo servizio e devi attivare un sito secondario per mantenere la disponibilità.
• Gli utenti ti citano per presunti framing e devi avere una prova, convincente per il giudice, che l'utente ti ha davvero inviato una richiesta specifica che non potresti aver fabbricato (un tipico contesto bancario).
• Un utente malintenzionato è riuscito a rubare una parte del database del server e lo utilizza per impersonare gli utenti.

Una varietà di strumenti sarà rilevante, a seconda della situazione. Nella maggior parte dei casi, utilizzare SSL per il tuo servizio sarà una buona idea (o, piuttosto, non usare SSL sarebbe una pessima idea). In molti casi, avrai bisogno di qualche forma di autenticazione dell'utente.