La volta scorsa, ti ho spiegato quali rischi corri a condividere le chiavi di accesso a servizi cloud come Amazon AWS su repository di programmazione come GitHub e ti ho detto che c’è un metodo che può aiutarti a separare il codice depositato su GitHub dalle chiavi di accesso ai servizi che integri via API.
In realtà, potrebbe venirti spontaneo chiedere se puoi risolvere tutta la questione utilizzando il gitignore, ma vi sono alcune situazioni in cui questa valida alternativa potrebbe non funzionare correttamente. Inoltre, affidandoti solo a gitignore, se compi qualche errore di condivisione, potresti accorgertene troppo tardi.
Un altro approccio alternativo è quello di pagare un account GitHub premium per avere un repository privato. Se hai del budget a disposizione, questa opportunità ti garantisce una certa sicurezza, ma se lavori su progetti open source o decidi di aprire il tuo progetto ad altri collaboratori, usare un repository privato non è una buona idea.
Allo stesso tempo, devi imparare a seguire alcuni suggerimenti importanti, ossia:
- se usi il cloud di AWS o quello di Hosting Solutions, ricordati di impostare un budget di spesa massimo, di attivare eventuali alert per il superamento delle soglie di spesa o comunque usare il sistema a credito prepagato;
- non usare mai le credenziali di accesso AWS principali, ma usa sempre e solo le chiavi ad accesso limitato attraverso IAM;
- usa git-crypt che attiva un servizio di crittazione e decrittazione trasparente dei file depositati sul repository Git;
- non integrare le chiavi API, le password ed altri elementi di accesso direttamente nel codice, ma mantienili sempre separati. Questi dati devono andare in un file di configurazione separato e se tale file è parte di un progetto sviluppato in un IDE, ricordati di rimuovere questi dati sensibili prima di distribuire o condividere il progetto.
L’approccio alternativo valido anche per GitHub
L’approccio che ti voglio proporre prende le mosse proprio da quest’ultimo consiglio ed è abbastanza semplice. Invece che integrare le chiavi API e le credenziali direttamente nei file di programmazione, puoi usare un file di configurazione di cui viene effettuato il parsing durante l’inizializzazione degli script.
Inoltre, il file può essere posizionato in un file di configurazione ospitato all’esterno delle directory di pubblico accesso e gestito a parte rispetto al repository GitHub.
Insomma, quello che si vuole evitare è di trovare programmazioni simili a quella seguente:
<?php
…
// This is the main Web application configuration.
$options = array(
…
‘db’=>array(
‘connectionString’ => ‘mysql:host=localhost;dbname=mydatabase’,
‘emulatePrepare’ => true,
‘username’ => ‘jeff’,
‘password’ => ‘whitefoxesjumpfences’,
‘charset’ => ‘utf8’,
‘tablePrefix’=>’fox_’,
),
// application-level parameters that can be accessed
// using Yii::app()->params[‘paramName’]
‘params’=>array(
‘pushover’=> array(
‘key’=> ‘H75EAC19M3249!X2’,
),
‘google’=> array(
‘maps_api_key’ => ‘W69uHsUJZBPhsFNExykbQceK’,
),
),
…
);
…
?>
In un file del genere, sono presenti lo username, le password e le chiavi API in chiaro, subito disponibili a chiunque voglia usarli.
Invece di correre rischi, bisogna aggirare l’ostacolo in un altro modo.
Come? Lo vedremo nel corso del prossimo post.
Stay tuned!
