La sicurezza dei gestionali nel 2013


fail-owned-fence-security-failOggi sto lavorando all’installazione di un gestionale che gira su Linux. Il software in questione gestisce le paghe dei dipendenti, fra le altre cose. Usandolo tramite la sua interfaccia client (che parla con un servizio di qualche tipo sul server) richiede ovviamente uno username e una password (lunga almeno 8 caratteri) per identificare gli utenti che accedono.

Purtroppo pero`, su specifiche precise del fornitore del software, e` richiesto che sul server sia installato FTP e anche telnet, e che ci sia un unico utente “di gestione” che puo` accedere via FTP e telnet per poter leggere o modificare arbitrariamente  ogni file di dati e di programma del gestionale. Ssh, invece, non e` richiesto.

Infine, per essere assolutamente sicuri che anche un utente inesperto e privo di cattive intenzioni possa comunque fare il massimo danno anche involontariamente  e`  inoltre necessario che la directory di installazione del gestionale (che contiene programmi e dati) sia accessibile da uno share SMB, ovviamente configurato con permessi 777 per tutti gli utenti.

Che dire?


7 risposte a “La sicurezza dei gestionali nel 2013”

  1. Ne ho visti piu’ d’uno di gestionali (e non solo) che nelle “specifiche” di funzionamento richiedevano birra Peroni e rutto libero per tutti. Tra l’altro quelli che si basano su MSSQL e usano sa per collegarsi (con password vuota o banale) non si contano.

    • … e quelli che usano come user ‘sa’ e come password … quella che ho appena scritto!
      Poi si lamentano …
      Della serie “chiudi la porta che i buoi sono scappati!” 😉
      Z

  2. Vabbe`, ma quello e` il gestionale con i dati da far vedere alla finanza. La contabilita` vera la tengono in un posto piu` sicuro 🙂

  3. Ma non saprei cosa dire. I gestionali coni quali ho lavorato sino ad ora erano custom e tutti WIN MSSQL, dove l’utente non è sa e ha ben una password anche complessa… Per quel gestionale linux based a parte i sui limiti non credo sia messo così male come altri suoi ricchissimi concorrenti vedi SAP o AS400, dove la sicurezza è isita solo nella conoscenza. Nel senso che nessuno al di fuori dei tecnici delle case madri che paghi fior di milaeuro, sanno dove stanno gli inghippi. Tu che lo usi in casa, non puoi neanche sapere le credenziali per accedere ai file di sistema dell’applicativo (che sanno solo loro per sicurezza). A volte e meglio non sapere di avere delle scoperture che essere sicuri di non averne.

    • AS400? Ho udito AS400???
      Intrinsecamente è una bestia piuttosto sicura, ma anche in questo caso tutto dipende dal prodotto installato.

      Se per esempio (caso assolutamente ipotetico :-)) la software house del gestionale vi dice che per non avere problemi bisogna dare permessi ALLOBJ* a tutti gli utenti e mantenere un livello di riservatezza=20 talmente basso che qualunque utente autenticato può tramite ODBC fare più o meno quello che vuole??
      Certo gli utenti non sanno usare ODBC di loro iniziativa quindi stiamo tranquilli!!!
      Ovviamente si tratta di un caso ipotetico 🙂

      • Ma nooh!.. La sicurezza è *sempre* strettissima nei prodotti basati su AS/400…
        “Che credenziali devo usare?”
        “QSECOFR/QSECOFR” (1)
        Strettissima, vi dico.

        Una volta su due mi è capitato quanto sopra, sia su installazioni nuove che pre-esistenti.

        (1) Utente e password di default dell’ufficiale della sicurezza, l’equivalente del root di Linux.

  4. Non e` questione di OS o di database server…. gli OS decenti e i database server decenti (non access, insomma) sono intrinsecamente sicuri. Il problema e` che chi scrive il software non capisce una cippa di sicurezza, e quindi lascia tutto aperto come una cozza, cosi` e` piu` comodo lavorarci.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *