YPCad
Italiano
Richiedi una dimostrazione

Sicurezza

Questa pagina dice che cosa proteggiamo e che cosa non possiamo proteggere. Un racconto di sicurezza che salta la seconda parte invita chi legge a scambiare un elenco per una garanzia.

Il punto di partenza

Pubblicare un pacchetto significa eseguire codice sulla macchina di ogni progettista che lo installa. Ogni decisione di sicurezza di questo prodotto è stata pesata prima contro una domanda: questo cambiamento rende più facile pubblicare senza autorizzazione?

  • I pacchetti sono firmati (ECDSA P-256)

    Il file di firma viaggia dentro il pacchetto. Firma un manifesto che contiene le impronte dei file, l’identità del pacchetto e la versione — non una semplice impronta dell’archivio.

    Se si firmasse solo l’impronta, un archivio vecchio ma firmato correttamente potrebbe comparire sotto un numero di versione nuovo: la firma risulterebbe valida e l’utente installerebbe come «aggiornamento» uno strumento con una vulnerabilità nota.

  • La chiave privata NON sta sul server

    Il server si limita a verificare. La firma avviene sulla macchina di chi pubblica, con uno strumento separato.

    Se la chiave stesse sul server, chi se ne impadronisse potrebbe modificare un pacchetto e rifirmarlo — il che renderebbe la firma inutile.

  • Verifica anche il client

    Il componente installato sulla macchina del progettista controlla la firma per conto proprio, e l’elenco di chiavi attendibili che usa non arriva dal server.

    La firma esiste proprio perché il server non può essere creduto sulla parola. Prendere l’elenco di fiducia da quello stesso server annullerebbe in silenzio il presupposto di partenza.

  • Un registro di controllo che non si può cancellare

    Ogni pubblicazione, ogni cambio di abilitazione e ogni decisione di canale viene scritta in modo permanente. Non esiste, di proposito, alcuna via di modifica o cancellazione, e la pulizia per conservazione non lo tocca.

    «Come è arrivato qui questo strumento» di solito viene chiesto mesi dopo. Quel giorno, una registrazione che si sarebbe potuta cancellare è una registrazione che non è mai esistita.

  • Regola dei quattro occhi, facoltativa

    Promuovere una versione a un canale più ampio può richiedere l’approvazione di un secondo amministratore, e chi la richiede non può approvare la propria richiesta. Tornare indietro non richiede mai approvazione.

    È disattivata di serie. In un team di tre persone il controllo diventa nel giro di settimane un messaggio approvato senza leggerlo; un controllo che si crede protegga senza proteggere è peggio di nessun controllo.

  • Estrarre un archivio è di per sé una superficie d’attacco

    Gli archivi caricati vengono controllati contro i percorsi malevoli (zip-slip) e le bombe di decompressione, e la dimensione estratta è limitata.

    Estrarre un archivio sembra innocuo. Uno costruito apposta può scrivere file fuori dalla cartella di destinazione o riempire il disco del server.

  • Accesso senza password

    Gli utenti accedono con un codice monouso inviato al loro indirizzo e-mail. La sessione viaggia su un token di breve durata; il token di rinnovo non è mai visibile al codice del browser.

    Se non c’è un insieme di password da gestire, non c’è un archivio di password che possa essere sottratto. E il riutilizzo di un token di rinnovo già revocato viene trattato come segnale di furto: la sessione viene chiusa.

  • Può vedere che cosa sta installando

    La cartella di installazione contiene una distinta base leggibile da macchina (SBOM CycloneDX) e gli script di migrazione per entrambi i motori di database.

    Il suo reparto IT deve poter esaminare che cosa finirà sul server prima che ci finisca. Quando viene resa nota una vulnerabilità in una dipendenza, «ce l’abbiamo?» diventa una ricerca fra i file.

Che cosa non possiamo proteggere

Queste non sono lacune, sono limiti. Discendono dalla struttura, e sostenere il contrario non sarebbe vero.

  • Due amministratori che agiscono insieme. La regola dei quattro occhi ferma uno, non due.
  • L’amministratore di sistema del server. Per chi ha accesso al database e al file system, nessun controllo a livello di applicazione è un ostacolo.
  • La postazione su cui sta la chiave di firma. La chiave non è sul server, ma da qualche parte è; se quella macchina cade, cade la firma.
  • Il comportamento malevolo nascosto di proposito. La nostra ispezione dei pacchetti è euristica e non sosteniamo che intercetti codice che cerca di nascondersi.
  • L’esfiltrazione di dati. Uno strumento installato gira con i permessi propri del progettista e può leggere tutto ciò che quei permessi raggiungono. A limitarlo sono i controlli del sistema operativo e della rete, non questo prodotto.
  • La sicurezza dei suoi backup. Il backup del database è nelle sue mani, e tutto ciò che contiene vale esattamente quanto il sistema in funzione.

Segnalare una vulnerabilità

Se ne ha trovata una, ci scriva. Prendiamo sul serio le segnalazioni, non escludiamo dal processo chi le fa e le diciamo quando esce la correzione.

security@ypcad.com