security does not mean or necessitate over-restrictive control, rather
it is about understanding basic principles, following secure and safe
practices
Questa è una dichiarazione ragionevolmente vera, specialmente quando descrivi un ambiente di sviluppo. Ma tieni presente che la definizione di "restrittiva" della sicurezza / amministratore differirà dalla definizione dello sviluppatore!
the Linux kernel firewall matters
In un ambiente di sviluppo Intranet, non così tanto. Tali sistemi richiedono spesso un accesso porto flessibile e flessibile. In qualsiasi ambiente, la manutenzione delle regole del firewall locale su qualsiasi numero di macchine è scoraggiante (leggi: interrompe la funzionalità in anticipo e spesso, impedisce all'amministratore di allentarlo).
the intranet's firewall matters even more
Assolutamente. Con un ambiente di sviluppo, spesso deve essere libero e aperto internamente, quindi il confine deve essere più restrittivo, sicuramente in entrata, ma anche in uscita.
remote root access should not be allowed, rather use of ssh key authentication
Ci sono un paio di buone pratiche in quest'area che, combinate, equivalgono a ciò di cui stai parlando.
- Il login root remoto diretto è scoraggiato a causa di problemi di attribuzione. Gli utenti, anche gli amministratori, devono accedere come se stessi e
su o sudo a root in modo che le loro azioni possano essere attribuite a una persona, non a una folla di persone con le credenziali necessarie per accedere come root.
- Gli accessi root remoti, se permessi (forse per il software di gestione della configurazione) dovrebbero richiedere chiavi SSH per renderli impraticabili e forzarli bruscamente.
Are the above and the following questions the appropriate points to
discuss and ask, when it comes to security and safety inside a large
intranet?
Sono tutti buoni punti. Tuttavia, ti sei perso le due parti più importanti di questa avventura:
-
Patching . Le patch dovrebbero essere automatizzate, centralizzate e vigorosamente
spesso.
-
Gestione della configurazione . Qualcosa come Puppet dovrebbe essere usato per gestire centralmente la configurazione delle macchine e del software comune.
Il patching è abbastanza ovvio. La gestione della configurazione, anche se meno ovvia, è altrettanto importante. Gestione della configurazione significa:
- Quando hai bisogno di modificare la configurazione, succede in tutto il tuo
sistemi senza fare affidamento su di te per andare in giro a farlo ovunque.
- Gli sviluppatori che modificano la propria configurazione (spesso con sicurezza
implicazioni) sono rapidamente superati e riportati in
la conformità.
- Quando porti un nuovo sistema online, viene rapidamente introdotto
conformità ai tuoi standard e non viene "mancato" o escluso.
Is it a necessity or best practice to restrict a Linux user from
having "sudo" rights in his "own" system, for the sake of security and
safety, for protecting from outside threats?
Ci deve essere equilibrio tra sicurezza e necessità aziendali. Gli sviluppatori hanno spesso una legittima necessità di accesso privilegiato. Per bilanciare questo bisogno, la sicurezza limiterà spesso i privilegi (ad esempio, sudo a particolari comandi ma non una shell di root), registra per audit (ad esempio, bash su syslog, disponibile in 4.1+ ) e limita i danni al pool (ad esempio, l'accesso in uscita restrittivo attraverso il firewall).
Can security and protection from outside threats be performed with a
good set of rules for iptables and adequate maintenance of the
intranet's firewall?
No, più di quello necessario, come descritto sopra.
Per citare Gary Larson:
