Tag: Sicurezza Bitcoin

  • La sicurezza come disciplina continua: protezione e responsabilità nell’infrastruttura Bitcoin

    La sicurezza di un’infrastruttura Bitcoin non si esaurisce nella sua configurazione iniziale. È una disciplina permanente, fondata su prevenzione, aggiornamento, controllo e responsabilità.

    Firewall, autenticazione a più fattori e strumenti di protezione costituiscono elementi essenziali di un sistema di pagamento. La loro efficacia dipende, tuttavia, dal contesto nel quale vengono adottati: procedure definite, autorizzazioni proporzionate ai ruoli e una gestione consapevole delle risorse critiche.

    Nel precedente approfondimento, La sicurezza è una scelta architetturale: perché non custodiamo le vostre chiavi, abbiamo illustrato la decisione di escludere gli hot wallet dall’istanza pubblica. Questo articolo ne sviluppa il seguito operativo: preservare nel tempo la separazione tra infrastruttura di pagamento, controllo delle chiavi e responsabilità dell’utilizzatore.

    Sicurezza BTCPay Server: dalla progettazione alla gestione continuativa

    Un’architettura prudente definisce le condizioni iniziali di protezione. La manutenzione ne sostiene il valore nel tempo. L’evoluzione del software, l’emergere di vulnerabilità e i cambiamenti organizzativi richiedono un riesame costante delle condizioni operative.

    La sicurezza dell’infrastruttura Bitcoin deve quindi essere affrontata come un insieme coordinato di attività:

    • Gestione degli aggiornamenti. Valutare gli avvisi dei progetti e mantenere aggiornati BTCPay Server, sistemi operativi, componenti e dipendenze.
    • Principio del minimo privilegio. Attribuire a ogni ruolo esclusivamente le autorizzazioni necessarie alle funzioni assegnate.
    • Revisione degli accessi. Riesaminare periodicamente account, permessi e privilegi, con particolare attenzione alle funzioni amministrative.
    • Riduzione della superficie di attacco. Limitare servizi, componenti e funzionalità a quanto effettivamente necessario.
    • Monitoraggio operativo. Esaminare log, eventi anomali e segnalazioni rilevanti per la sicurezza.
    • Preparazione agli incidenti. Definire responsabilità, riferimenti e modalità di intervento in presenza di vulnerabilità o attività sospette.

    Queste pratiche concorrono alla riduzione del rischio. Nessuna, considerata singolarmente o insieme alle altre, costituisce una garanzia di invulnerabilità.

    Escludere gli hot wallet: un confine architetturale preciso

    BTCPay Server Italia ha scelto di non consentire agli utenti la configurazione di hot wallet sulla propria istanza pubblica. La finalità è mantenere fuori dal server le chiavi private necessarie alla firma, riducendo la concentrazione di funzioni sensibili nello stesso ambiente.

    La distinzione terminologica è essenziale. Non custodial indica chi controlla le chiavi private; hot wallet e cold wallet descrivono invece le condizioni nelle quali tali chiavi vengono conservate e utilizzate. Un wallet non custodial può essere anche un hot wallet, se le chiavi risiedono in un ambiente connesso a Internet.

    Il modello promosso mantiene distinti i compiti:

    • L’infrastruttura pubblica gestisce le funzioni di pagamento attraverso informazioni pubbliche compatibili del wallet.
    • Le chiavi private restano sotto il controllo dell’utente, al di fuori del server pubblico.
    • La firma viene effettuata in un dispositivo o ambiente separato e protetto, preferibilmente offline.
    • L’utilizzatore conserva la responsabilità delle procedure di accesso, backup e recupero.

    Le differenze tra configurazioni non custodial, watch-only e cold wallet sono approfondite nel precedente articolo sulla separazione delle chiavi private.

    L’assenza di chiavi sul server limita uno specifico rischio, ma non rende irrilevante la sicurezza dell’istanza. Un’infrastruttura compromessa potrebbe esporre informazioni, interrompere il servizio o alterare gli indirizzi presentati per i pagamenti futuri. La protezione delle chiavi private Bitcoin deve pertanto essere accompagnata dalla verifica delle informazioni di pagamento e dalla cura dell’ambiente operativo.

    Sicurezza dei wallet Bitcoin: autonomia e procedure di recupero

    Il controllo diretto delle chiavi comporta una responsabilità altrettanto diretta sulla loro conservazione. La custodia Bitcoin richiede attenzione non soltanto agli accessi non autorizzati, ma anche alla perdita dei dispositivi, al deterioramento dei supporti e all’effettiva possibilità di recupero.

    BTCPay Server Italia raccomanda di adottare precauzioni proporzionate alle esigenze operative e agli importi gestiti:

    1. Conservare il seed offline, in un luogo protetto.
    2. Non condividere la frase di recupero con terzi e non inserirla sul server pubblico.
    3. Evitare copie in chiaro su servizi cloud, email e dispositivi connessi.
    4. Proteggere i backup da accessi non autorizzati e danni fisici.
    5. Verificare il recupero in condizioni controllate, prima di affidare alla configurazione importi significativi e senza esporre il seed a dispositivi non fidati.
    6. Valutare un hardware wallet e un’organizzazione della custodia coerente con le responsabilità dell’impresa.

    Tra gli strumenti software considerati nel precedente approfondimento figura Sparrow Wallet. Può supportare una configurazione che separa osservazione e firma, ma non rende automaticamente offline le chiavi. La protezione dipende dall’ambiente nel quale queste vengono conservate e utilizzate.

    Anche le informazioni pubbliche estese richiedono riservatezza: pur non consentendo da sole di spendere i fondi, possono rivelare elementi dell’attività finanziaria.

    Privilegi e responsabilità: la dimensione organizzativa della sicurezza

    La separazione dei ruoli contribuisce a contenere gli effetti di errori operativi e compromissioni degli account. Non ogni utilizzatore deve poter modificare le impostazioni dell’infrastruttura, né ogni funzione richiede privilegi amministrativi.

    Nelle istanze condivise, questa distinzione assume particolare rilievo. È necessario individuare chi può intervenire sui sistemi, quali autorizzazioni siano ancora giustificate e come procedere alla loro revoca quando cambiano incarichi o collaborazioni.

    La qualità della sicurezza dipende quindi anche dalla chiarezza organizzativa: responsabilità riconoscibili, accessi proporzionati e procedure comprensibili a chi è chiamato ad applicarle.

    Continuità operativa e consapevolezza aziendale

    Per un’impresa che accetta Bitcoin, la sicurezza non è una funzione da delegare senza conservarne la comprensione. È parte della continuità operativa e della capacità di assumere decisioni informate.

    Conoscere dove risiedono le chiavi, chi può accedere ai sistemi, come sono protetti i backup e quali riferimenti attivare in caso di incidente permette di distinguere le competenze del gestore dalle responsabilità che rimangono interne all’organizzazione.

    Il valore dell’infrastruttura non risiede soltanto nelle funzionalità disponibili, ma anche nella chiarezza del modello operativo che le accompagna.

    L’approccio di BTCPay Server Italia

    BTCPay Server Italia considera la sicurezza una responsabilità continuativa. L’esclusione degli hot wallet dall’istanza pubblica esprime una scelta di separazione delle funzioni e riduzione dell’esposizione, non una promessa di assenza di rischio.

    Aggiornamenti, revisione dei privilegi, controllo delle autorizzazioni e protezione dei backup sono le pratiche che devono accompagnare questo modello. La loro descrizione illustra l’approccio operativo: non costituisce un’attestazione di audit né una verifica della configurazione corrente dell’istanza.

    In qualità di partner italiano per l’adozione concreta dei pagamenti Bitcoin nelle imprese, BTCPay Server Italia promuove un rapporto consapevole tra tecnologia, autonomia e responsabilità.

    La sicurezza si costruisce nelle scelte, si verifica nei processi e si preserva nella continuità della gestione.

    Un percorso editoriale, due prospettive complementari

    Il primo approfondimento definisce il confine architetturale: mantenere le chiavi private al di fuori dell’infrastruttura pubblica. Questo contributo ne sviluppa la dimensione operativa: preservare quel confine attraverso manutenzione, controllo degli accessi e procedure di recupero.

    Per approfondire il fondamento di questo modello: La sicurezza è una scelta architetturale: perché non custodiamo le vostre chiavi.


    BTCPay Server Italia
    Infrastruttura, integrazione e supporto per l’adozione di Bitcoin nelle imprese.

    Open Source. Self-Hosted. Non-Custodial.

    Un confronto dedicato all’infrastruttura Bitcoin della Sua impresa

    Per approfondire l’integrazione dei pagamenti Bitcoin e la separazione tra operatività, chiavi private e responsabilità organizzative, è possibile richiedere un incontro con il team di BTCPay Server Italia.

    Il confronto consente di presentare le esigenze dell’impresa e valutare un percorso di infrastruttura, integrazione e supporto coerente con il contesto operativo.

    Prenota una videocall

    Per richieste e informazioni: team@btcpayserver.it
    Canale di contatto Telegram: BTCPay Server Italia.

    Non trasmettere seed, chiavi private o credenziali di accesso attraverso i canali di contatto.

  • La sicurezza è una scelta architetturale: perché non custodiamo le vostre chiavi

    La protezione dei fondi comincia prima di una transazione. Comincia dal modo in cui viene progettata l’infrastruttura e da una scelta essenziale: chi deve poter disporre delle chiavi private.

    Per BTCPay Server Italia, accompagnare le imprese nell’adozione dei pagamenti Bitcoin significa anche definire con chiarezza il confine tra servizio tecnologico e controllo dei fondi. La nostra posizione è precisa: sull’istanza pubblica non consentiamo agli utenti di configurare hot wallet. L’infrastruttura gestisce i pagamenti; le chiavi private devono rimanere sotto il controllo dei legittimi proprietari, al di fuori del server pubblico.

    La sicurezza non si esaurisce in un aggiornamento

    Gli avvisi di sicurezza pubblicati dal progetto BTCPay Server ricordano quanto sia importante mantenere aggiornato ogni componente di un’infrastruttura di pagamento. Il progetto ha documentato un incidente nel quale una vulnerabilità ha consentito di ottenere le credenziali amministrative di nodi LND collegati alle istanze interessate, con conseguente sottrazione di fondi ad alcuni utenti.

    È importante distinguere i diversi ambiti: nell’avviso relativo alla versione 2.4.2, il rischio descritto riguarda le credenziali LND e non i wallet on-chain gestiti da BTCPay Server. La versione 2.4.7, rilasciata il 29 ottobre 2026, dichiara la correzione di 85 rilievi di sicurezza: 1 critico, 13 di gravità alta, 52 media e 19 bassa, secondo le classificazioni del rapporto originale. Le note di rilascio raccomandano l’aggiornamento, in particolare per i server condivisi da più esercenti.

    Questi dati riguardano il software del progetto e non costituiscono un’attestazione della versione installata sulla nostra istanza. Nessun aggiornamento deve essere interpretato come una garanzia di invulnerabilità.

    La lezione è più ampia di una singola versione software: aggiornare è indispensabile, ma ridurre preventivamente l’esposizione delle chiavi private è una scelta architetturale distinta e altrettanto importante.

    La nostra scelta: nessun hot wallet sull’istanza pubblica

    Un hot wallet conserva le chiavi private in un ambiente connesso a Internet. È una configurazione che può rispondere a specifiche esigenze operative, ma introduce un rischio che richiede valutazioni, controlli e responsabilità adeguati.

    Quando le chiavi sono presenti su un server, la compromissione dell’infrastruttura o di un account con i privilegi necessari può esporre anche la capacità di spendere i fondi. Su un servizio condiviso, questa concentrazione di funzioni merita particolare attenzione.

    Per questo abbiamo scelto di non rendere disponibile la configurazione di hot wallet sulla nostra istanza pubblica. Non è una limitazione commerciale: è il confine che abbiamo deciso di mantenere tra l’operatività dei pagamenti e la custodia delle chiavi.

    Non custodial, watch-only e cold wallet: ruoli distinti

    Non custodial significa che il controllo delle chiavi private rimane all’utente. Non significa, da solo, che un wallet sia offline. Anche un wallet gestito direttamente dal proprietario può essere un hot wallet.

    Watch-only descrive invece una configurazione che utilizza informazioni pubbliche per osservare indirizzi e transazioni, senza possedere le chiavi private necessarie alla spesa. Cold wallet indica una configurazione nella quale le chiavi di firma sono mantenute offline. Watch-only e cold wallet non sono sinonimi: possono essere componenti complementari della stessa architettura.

    Nel modello che promuoviamo, BTCPay Server utilizza sul server pubblico soltanto le informazioni pubbliche compatibili del wallet, mentre la firma rimane in un ambiente separato. La configurazione raccomandata mantiene le chiavi offline, attraverso un dispositivo di firma dedicato o un ambiente offline adeguatamente protetto.

    Sparrow Wallet: osservare online, firmare separatamente

    Tra gli strumenti che consigliamo per questo approccio c’è Sparrow Wallet. La sua documentazione distingue i wallet software che contengono chiavi private, i wallet xpub/watch-only e le configurazioni con hardware wallet connessi o air-gapped.

    Il modello da promuovere è preciso: BTCPay Server in modalità watch-only sull’infrastruttura pubblica; Sparrow su una postazione dell’utente per la gestione operativa; chiavi private conservate nel dispositivo o nell’ambiente di firma offline. Anche Sparrow può essere configurato con sole informazioni pubbliche, senza importare il seed.

    In una configurazione air-gapped, i dati necessari alla firma vengono scambiati tramite i metodi supportati dal dispositivo, per esempio codici QR o scheda SD. La transazione viene autorizzata dal dispositivo che custodisce le chiavi, non dal server pubblico.

    Sparrow non diventa un cold wallet per il solo fatto di essere installato. Se le chiavi sono conservate e utilizzate su un computer connesso a Internet, rimangono esposte ai rischi di quell’ambiente. La protezione dipende dalla configurazione concreta, non dal nome del software.

    Il seed di recupero non deve essere inserito sul server pubblico. Anche le informazioni pubbliche estese del wallet richiedono attenzione: non consentono, da sole, di spendere i fondi, ma possono rivelare informazioni sensibili sull’attività finanziaria.

    Ridurre il rischio non significa dichiarare immunità

    Mantenere le chiavi fuori dal server riduce uno specifico rischio: che una compromissione dell’istanza renda direttamente disponibili anche le chiavi necessarie a sottrarre i fondi già ricevuti dal wallet.

    Non elimina le vulnerabilità dell’istanza, gli accessi non autorizzati, i rischi relativi ai dati o le interruzioni del servizio. Un’infrastruttura compromessa potrebbe inoltre alterare le informazioni mostrate o gli indirizzi utilizzati per i pagamenti futuri. L’assenza di chiavi private sul server non rende quindi irrilevante la fiducia nel gestore.

    La verifica degli indirizzi tramite un dispositivo fidato, la protezione degli account e il monitoraggio restano parte integrante di un uso consapevole. Allo stesso modo, la sicurezza del dispositivo di firma e dei backup rimane determinante per la protezione del wallet.

    Un’infrastruttura di pagamento, non un deposito di Bitcoin

    Utilizzare un’infrastruttura esterna per ricevere pagamenti non dovrebbe essere confuso con affidarle la custodia dei propri Bitcoin. Il nostro modello mantiene distinte queste responsabilità: il servizio supporta i processi di pagamento; l’utente conserva il controllo delle chiavi e delle operazioni di firma.

    Per le imprese, il valore di questa impostazione è la chiarezza: sapere quali funzioni svolge il servizio, quali responsabilità rimangono interne e dove si trova effettivamente il potere di autorizzare una transazione.

    La sicurezza come disciplina continua

    Un’architettura prudente è un punto di partenza, non un traguardo definitivo. Un’infrastruttura di pagamento richiede aggiornamenti tempestivi, privilegi amministrativi limitati, controllo delle autorizzazioni, riduzione dei servizi non necessari e attenzione costante agli eventi rilevanti per la sicurezza.

    Allo stesso modo, chi utilizza un wallet deve proteggere il seed, predisporre backup adeguati e verificare le procedure di recupero prima di affidare alla configurazione importi significativi.

    La scelta di escludere gli hot wallet dalla nostra istanza pubblica si inserisce in questa visione: limitare il materiale sensibile presente sul server e mantenere separati i ruoli che non è necessario concentrare nello stesso ambiente.

    Sovranità digitale, responsabilità concreta

    Bitcoin offre alle imprese la possibilità di ripensare il rapporto tra pagamenti, controllo e autonomia. Rendere questa possibilità operativa richiede competenze tecniche, processi comprensibili e scelte esplicite sul rischio.

    BTCPay Server Italia si propone come partner italiano per questa adozione concreta: infrastruttura, integrazione e supporto, senza confondere l’assistenza tecnologica con la custodia delle chiavi private.

    Non promettiamo un’infrastruttura immune da ogni attacco. Scegliamo invece un modello che riduce l’esposizione delle chiavi e rende più chiaro il confine delle responsabilità.

    Le chiavi restano tue. Sempre.

    È il principio della nostra scelta non custodial: il servizio non deve detenere le tue chiavi private. Non è una promessa di assenza di rischio, ma un impegno sul modello di custodia che promuoviamo.


    BTCPay Server Italia
    Infrastruttura, integrazione e supporto per l’adozione di Bitcoin nelle imprese.

    La sovranità digitale comincia dal controllo delle proprie chiavi.

    Fonti e approfondimenti