Autenticazione per uno script batch

2

Sembra incredibile che non ci sia ancora nessuna best practice accettata dal settore per questo problema (o forse solo uno di cui non sono a conoscenza):

Qual è il modo più sicuro per uno script batch, un programma che deve connettersi a una risorsa (database E.g.) tramite un'interazione non guidata dall'utente per l'autenticazione? Le risposte agnostiche della tecnologia sono le migliori, ma se c'è un grande differente basato sul sistema operativo (Windows, Unix, Mainframe ecc.), Database o linguaggio di programma che è anche utile sapere.

Sarebbe positivo se si potesse indicare il motivo per cui la soluzione (o le opzioni in ordine di preferenza) è sicura (ad es. protegge contro utenti interni malintenzionati, aggressori esterni, malware in questi modi). Anche perché ha un basso impatto operativo (cambio, manutenzione ecc.)

es. la mia lista:

IMO migliore preferenza (più sicura) al minimo:

  • Autenticazione basata su certificato in cui il certificato è archiviato in un HSM
  • Autenticazione basata su certificato in cui il certificato è memorizzato in un modulo crittografico software
  • Autenticazione basata su certificato in cui il certificato è l'archivio certificati del sistema operativo - in genere richiede root per ottenere l'accesso in modo che il gioco sia attivo se ciò avviene
  • Autenticazione esternalizzata basata su un LDAP
  • Password in cui la password viene crittografata e archiviata in un server diverso o in un deposito di password. Solo l'account di servizio è autorizzato a connettersi, decrittografare e recuperare la password tramite trasporto sicuro (in pratica come funziona TDE con Oracle Wallet)
  • Password basata su dove la password è crittografata e archiviata sul server. L'account di servizio può decodificare solo.
  • Password basata su dove la password è memorizzata sul server ma protetta da perms del sistema operativo ed è esclusa dal backup (backup manuale nel vault della password).

Il certificato è di gran lunga il migliore e il metodo defacto per qualsiasi cosa come Amazon EC2, Github ecc.

Chiudi e reindirizza se ti è già stata data una risposta. Non sono riuscito a trovarlo quando ho cercato.

    
posta Rakkhi 10.05.2012 - 05:17
fonte

1 risposta

1

La risposta dipende dal modello di minaccia e da quali minacce stai tentando di impedire.

Un metodo strong standard consiste nell'utilizzare l'autenticazione basata su chiave pubblica, come i seguenti esempi:

  • Il client si connette tramite SSH. Il client si autentica utilizzando la sua chiave DSA personale (non protetta da alcuna passphrase). Oppure,
  • Il client si connette su SSL. Il client si autentica utilizzando un certificato client adatto. Il client controlla il certificato del server per assicurarsi che stia parlando con il server con cui si prevede di parlare.

Questo approccio è abbastanza buono per la maggior parte delle impostazioni. È sicuro contro gli attacchi a livello di rete. Naturalmente, la chiave privata del cliente vive in chiaro sulla macchina client. (È praticamente necessario.) Di conseguenza, qualsiasi utente malintenzionato che si intrufola nel computer client può rubare la chiave privata del client.

Se è necessario rilevare la minaccia di un compromesso del computer client, è possibile memorizzare la chiave privata in un HSM o una smartcard collegata al computer client e farla autenticare in questo modo. Ciò fornisce modesti vantaggi per la sicurezza: un utente malintenzionato che compromette la macchina client non può più rubare la chiave privata del client, ma l'utente malintenzionato può comunque effettuare connessioni arbitrarie al server come client e inviare dati arbitrari, finché l'autore dell'attacco mantiene il proprio controllo sul cliente. Se questo è un miglioramento della sicurezza o meno (rispetto alla semplice memorizzazione della chiave privata in chiaro sul client) dipende strongmente dall'applicazione. Inoltre, se questo vale il costo aggiuntivo e la seccatura dell'HSM o della smartcard dipende anche dall'applicazione.

Ci sono anche altri approcci con alcuni lievi vantaggi e svantaggi rispetto a quanto sopra, ma niente di ciò che è in modo schiacciante superiore.

    
risposta data 10.05.2012 - 08:28
fonte

Leggi altre domande sui tag