1) Sei corretto al 100%, perché? Se la macchina viene compromessa, l'utente malintenzionato sarà comunque in grado di recuperare la chiave di decodifica in quanto è necessario essere crittografia simmetrica per decodificare dall'app e il file chiave deve avere le stesse autorizzazioni di lettura dell'app in modo che l'app possa leggerlo.
Voglio dire che l'app deve ancora avere una directory di chiavi decrittografate e segrete in modo che l'attacker la cerchi: D, anche se l'app è un eseguibile binario
l'utente malintenzionato può facilmente scaricare file di directory e file.
Lo so perché l'ho fatto da un programma in linguaggio Go che avevo bisogno di eseguire il debug e non avevo il codice sorgente (una delle app client ospitate sul server):)
Overflow del buffer e così via gli attacchi funzioneranno se il foro è presente come
modi di app memorizza i dati in memoria per riutilizzarli ad esempio per l'autenticazione del database.
2) La soluzione migliore è avere un deposito centrale in cui ogni app richiede i suoi segreti e li affitta. Una soluzione di questo tipo è link e ulteriori dettagli su di essa link
La migliore prassi generale consiste nel ridurre al minimo i diritti di accesso e controllo di ciascun ruolo per ciascuna risorsa dell'app.
Esempio:
Se un'app utilizza solo un database, non ha i diritti dell'utente per visualizzarne altri
o per eseguire DML su altri, rimuovere i diritti della tabella di rilascio se l'app non esegue le migrazioni e così via.
Se non si usa il vault se lo script viene eseguito dall'utente root di esempio non si memorizzano i segreti con la proprietà di utenti con privilegi più limitati lasciare che il proprietario sia lo stesso utente, utilizzare le autorizzazioni di lettura, scrittura ed esecuzione solo ciò di cui si ha realmente bisogno.
Utilizza TLS quando puoi per le tue risorse come un tcp dump i dati di perdita se l'hacker riesce a ottenere la fase di autenticazione come mai hai archiviato i dati segreti.