Memorizzazione dei certificati IDP SAML nella cartella APP_Data

0

Abbiamo fornito un provider di servizi SAML2 al nostro cliente, in modo che possano utilizzarlo per configurare il proprio provider di identità al nostro fornitore di servizi.

Le mie domande riguardano il nostro certificato client, sono preoccupato che se avessi archiviato il loro certificato nella nostra cartella APP_Data in modo che fosse possibile accedervi nella nostra base di codice per configurare sia il fornitore di servizi che il provider di identità. Quindi sto pensando di installare un nuovo bucket nel nostro AWS e archiviato il certificato in quel bucket. Qualche suggerimento a questo approccio o esiste un modo migliore per proteggere almeno i certificati?

    
posta rpmansion 01.03.2017 - 07:01
fonte

1 risposta

1

Quale certificato è questo? È solo la chiave pubblica utilizzata per convalidare il token?

Se è solo la chiave pubblica, l'unica cosa di cui devi preoccuparti è che qualcuno la sovrascriva con una chiave diversa.

Se sei interessato a questo, puoi invece archiviarlo nell'archivio dei certificati e ACL in modo tale da richiedere la modifica delle autorizzazioni di amministratore. Il problema pratico è che dovresti quindi memorizzare l'identificazione personale o l'oggetto del certificato da qualche parte in modo da poterlo consultare nel negozio. Archiviandola in AWS renderebbe leggermente più difficile per qualcuno giocarci. Vorresti renderlo di sola lettura dal tuo servizio in modo che un utente malintenzionato sulla scatola non possa utilizzare le stesse credenziali per sovrascriverlo.

D'altra parte, se stai parlando della chiave privata usata per decodificare un token crittografato ... questa è un'altra storia. Devi davvero considerare quale tipo di attacchi stai cercando di prevenire.

  • È possibile archiviarlo localmente su disco e chiunque abbia accesso in lettura può, beh, leggere la chiave.
  • Puoi archiviarlo come file PFX su disco con una password, ma hai bisogno della password per decrittografarlo, e questo deve essere memorizzato da qualche parte in modo sicuro, e in basso andiamo nella tana del coniglio.
  • Puoi ACL la chiave in modo che solo l'app Web possa leggerla, ma è probabile che sia in esecuzione come servizio di rete, quindi è abbastanza aperto.
  • Puoi cambiare l'app per utilizzare un account con nome e password e ACL il file in modo che solo quell'utente possa leggere la chiave, ma un amministratore può ancora leggerlo, perché: admin.
  • Puoi archiviarlo nell'archivio certificati, ma i 2 punti precedenti si applicano ancora.
  • Puoi archiviarlo in AWS, ma questo richiede una chiave per la connessione e quella chiave deve essere memorizzata da qualche parte in modo sicuro. Di nuovo giù nella tana del coniglio. Inoltre, questa chiave deve essere tirata giù per essere utilizzata, che può essere memorizzata su disco o in memoria. Su disco rende tutto questo mooolto.
  • Infine, è possibile memorizzarlo in un contenitore di chiavi adeguato come un HSM (vedi ad esempio Amazon HSM o Azure Key Vault) in cui la chiave non lascia mai l'archivio e invii comandi di crittografia / decrittografia. A questo punto hai ancora bisogno di un modo per collegarti, ma non puoi estrarre la chiave, anche se puoi inviare dati arbitrari per decrittografare.

È qui che entra in gioco un modello di minaccia. Esegui una valutazione dei rischi associati a ciascun metodo e solo in questo modo puoi determinare se il rischio giustifica lo sforzo e l'impatto del metodo.

    
risposta data 01.03.2017 - 15:13
fonte

Leggi altre domande sui tag