1. Classificare ciò che descrive il calcolo e ciò che concede un accesso
Inizia dalle informazioni che il tuo programma consuma davvero. La dimensione del batch, il nome del modello e la modalità di elaborazione descrivono un'esperienza. Un token che autorizza un download o una chiave che apre uno storage forniscono un accesso. Il primo insieme deve essere spiegabile; il secondo deve restare disponibile solo dove è necessario.
Il confine non si riduce ai nomi delle variabili. Un percorso può rivelare un cliente, un URL può contenere un identificatore e un piccolo campione di dati può essere riservato. Valuta quindi anche il contenuto dei parametri condivisibili. Pubblicare la configurazione e pubblicare tutti i suoi percorsi assoluti non sono la stessa decisione.
La tabella propone una classificazione di lavoro. Non descrive i servizi installati su una macchina Kernodeck. Definisci per il tuo progetto chi può leggere ogni elemento, in quale momento e in quale copia; non lasciare questa decisione all'ultimo export di un notebook.
Scorri la tabella per leggere tutte le colonne.| Elemento | Ruolo | Elaborazione proposta |
|---|---|---|
| Dimensione del batch, modalità, soglia | Parametri del calcolo | Versionare e validare i loro valori. |
| Token, chiave privata, password | Mezzi di accesso | Fornire separatamente e non includere negli output. |
| Percorso, URL, identificatore di corpus | Contesto potenzialmente sensibile | Verificare prima di condividere; preferire un identificatore logico. |
| Risultati e log | Prove di esecuzione | Scegliere i campi conservati e controllare la cartella trasmessa. |
2. Scegliere un'unica regola di priorità
Un parametro presente nel codice, in un file e in un'opzione di avvio diventa ambiguo se nessuno sa quale prevalga. Stabilisci una regola semplice, ad esempio: valori predefiniti documentati, poi file di configurazione, poi opzioni pubbliche del comando. È un contratto della tua applicazione, non una priorità universale fornita da Python.
Valida dopo questa risoluzione. Rifiuta una chiave sconosciuta affinché un errore come batch_szie non venga silenziosamente sostituito da un valore predefinito. Distingui un intero, una stringa che rappresenta un intero e un booleano. Aggiungi poi i vincoli utili: valore positivo, modalità consentita, combinazione di parametri coerente.
Infine registra una configurazione effettiva limitata ai campi autorizzati. Spiega cosa ha utilizzato il programma, anche quando un'opzione ha sostituito il file. Non ottenere questo documento serializzando l'intero oggetto di configurazione prima di rimuovere alcune password note: scegli prima cosa può figurarvi.
3. Lavorare su un esempio senza connettere servizi
L'esempio seguente è didattico e non eseguito. Descrive un'operazione fittizia di produzione di vettori con un batch di otto elementi. La parola embedding è qui una scelta di interfaccia; nessun modello viene caricato e nessuna dipendenza GPU si presume installata. Nessun segreto è necessario per leggere o validare questo file.
Il modulo standard tomllib, disponibile a partire da Python 3.11, legge il formato TOML. Trasforma i valori del documento in oggetti Python; non decide che un batch di zero sia vietato nella tua applicazione. Il controllo di dominio resta esplicito dopo la lettura.
Questo estratto accetta esattamente due chiavi e due modalità. Per utilizzarlo in un progetto, collega poi gli argomenti, la gestione degli errori e i percorsi di output. I rifiuti attesi sono facili da ragionare: batch_size a zero, batch_size sotto forma di stringa o aggiunta di una chiave token. Sono casi da verificare da te, non risultati misurati qui.
batch_size = 8
mode = "embedding"import tomllib
with open("config.toml", "rb") as source:
config = tomllib.load(source)
if set(config) != {"batch_size", "mode"}:
raise ValueError("CONFIG_KEYS")
if type(config["batch_size"]) is not int or config["batch_size"] <= 0:
raise ValueError("CONFIG_BATCH_SIZE")
if config["mode"] not in ("embedding", "classification"):
raise ValueError("CONFIG_MODE")
public_config = {
"batch_size": config["batch_size"],
"mode": config["mode"],
}4. Fornire il segreto solo alla fase che ne ha bisogno
Un passaggio che lavora su un file già presente non deve richiedere un token di download. Richiedi il segreto alla frontiera dove l'accesso diventa necessario. Se questo passaggio è attivo ma il suo accesso manca, fermalo con un messaggio che indichi il canale atteso, senza mostrare il valore ricevuto né ricopiare l'intera richiesta.
Il canale dipende dall'ambiente disponibile: gestore di segreti, file di credenziali ad accesso ristretto o meccanismo di iniezione previsto dalla tua organizzazione. Una variabile d'ambiente può servire da interfaccia, ma resta un dato accessibile al processo e suscettibile di comparire nelle diagnostiche. Non confondere la comodità di iniezione con una protezione completa.
Limita l'accesso al perimetro utile e prevedine la sostituzione. Una richiesta di preparazione software non garantisce la presenza di un gestore di segreti. Verifica il meccanismo effettivamente disponibile prima di costruire il tuo avvio attorno a esso, poi evita di trasmettere il segreto a sottoprocessi che non ne hanno bisogno.
5. Progettare un log utile senza copiare l'input
Definisci alcuni eventi: configurazione accettata, file controllato, partizione completata, output validato. Associa a essi un identificatore di esecuzione, un passaggio e un contatore. Un errore CONFIG_BATCH_SIZE è sufficiente per ritrovare la regola interessata; non ha bisogno di contenere il file completo.
OWASP raccomanda di escludere in particolare password, token di accesso e chiavi dai log. Applica questa regola anche alle eccezioni, agli oggetti mostrati per il debug e agli output delle celle. Una mascheratura applicata all'ultima schermata non rimuove ciò che è già stato scritto in un file o in uno screenshot.
Per condividere un incidente, prepara una piccola selezione: versioni utili, parametri autorizzati, errore ed esempio sintetico che riproduce il problema. Evita l'archiviazione automatica dell'intera cartella. Rileggi anche URL, intestazioni, percorsi e righe vicine all'errore; un messaggio apparentemente innocuo può essere circondato da dati sensibili.
6. Verificare la separazione prima di condividere
Prepara tre prove: configurazione valida senza passaggio remoto, configurazione non valida e passaggio che richiede un accesso assente. La prima deve poter arrivare alla sua frontiera funzionale senza segreti inutili; le altre due devono dare errori distinti. Verifica anche che una modifica pubblica della dimensione del batch compaia nella configurazione effettiva.
Per controllare la tua procedura di condivisione, usa una stringa sentinella manifestamente fittizia e senza potere di accesso. Fallo passare nello stesso punto di un segreto durante un esercizio isolato, poi cercala nei log, negli export e nei file selezionati. La sua assenza è un controllo limitato di questo percorso, non una prova che tutte le fughe siano impossibili.
Aggiungi i file privati appropriati alle tue esclusioni Git, ma verifica anche i file già tracciati. La documentazione di Git specifica che gitignore riguarda i file non tracciati; aggiungere un pattern non rimuove un segreto già registrato. Esamina ciò che stai per trasmettere, non solo le regole che dovrebbero escluderlo.
7. Reagire a una diffusione e conservare una traccia utilizzabile
Se un accesso è stato esposto, smetti di riutilizzarlo e fallo revocare o sostituire presso il sistema che lo ha rilasciato. Eliminare una riga dal file corrente non rende innocue le copie precedenti. Identifica le posizioni interessate per rimuovere ciò che è possibile e comprendere il perimetro della diffusione.
La tua cartella riproducibile può poi conservare il nome del canale utilizzato e i parametri autorizzati, senza conservare il segreto stesso. Un avvio futuro richiederà un accesso valido al momento giusto. Ottieni così una procedura trasmissibile senza trasformare l'archivio dell'esperimento in un portachiavi di accessi.
Questo metodo riguarda la tua applicazione e i suoi deliverable. Non garantisce né l'isolamento di tutto l'ambiente né l'assenza di tracce tecniche altrove. Per passare all'esecuzione, associalo a un ambiente documentato, a dati controllati e a un monitoraggio che distingua avanzamento e risultato validato.