seguridad no significa ni requiere un control demasiado restrictivo, sino
Se trata de entender los principios básicos, siguiendo seguro y seguro.
prácticas
Esa es una afirmación razonablemente verdadera, especialmente cuando estás describiendo un entorno de desarrollo. ¡Pero tenga en cuenta que la definición de seguridad / administrador de "restrictivo" va a diferir de la definición del desarrollador!
el firewall del kernel de Linux importa
En un entorno de desarrollo de intranet, no tanto. Tales sistemas a menudo requieren acceso a puertos sueltos y flexibles. En el entorno cualquier , el mantenimiento de las reglas del cortafuegos local en cualquier número de máquinas es desalentador (lea: rompe la funcionalidad antes y, a menudo, ata al administrador y lo afloja).
El firewall de la intranet importa aún más
Absolutamente. Con un entorno de desarrollo, a menudo es necesario que esté suelto y abierto internamente, por lo que la frontera debe ser más restrictiva: definitivamente entrante, pero también saliente.
no se debe permitir el acceso remoto a la raíz, en lugar de usar la autenticación con clave ssh
Hay un par de buenas prácticas en esta área que, combinadas, equivalen a lo que estás hablando.
- Se desaconseja el inicio de sesión remoto remoto directo debido a problemas de atribución. Los usuarios, incluso los administradores, deben iniciar sesión en como ellos mismos y
su o sudo en la raíz para que sus acciones puedan atribuirse a una persona, no a una multitud de personas con las credenciales necesarias para iniciar sesión como raíz.
- Los inicios de sesión raíz remotos, si están permitidos (tal vez para el software de administración de la configuración) deben requerir claves SSH para que no sea obligatorio forzarlos.
¿Son las preguntas anteriores y las siguientes los puntos apropiados para
discutir y preguntar, cuando se trata de seguridad y protección dentro de un gran
intranet?
Todos son buenos puntos. Sin embargo, te has perdido las dos partes más importantes de esta aventura:
-
Parches . Los parches deben ser automatizados, centralizados y vigorosos.
a menudo.
-
Gestión de la configuración . Debería utilizarse algo como Puppet para administrar de forma centralizada la configuración de las máquinas y el software común.
El parcheo es bastante obvio. La administración de la configuración, aunque menos obvia, es igual de importante. Gestión de la configuración significa:
- Cuando necesita modificar la configuración, esto sucede en todos sus
sistemas sin confiar en ti para que lo ejecutes en todas partes.
- Desarrolladores que modifican su configuración (a menudo con seguridad
implicaciones) son rápidamente anuladas y devueltas a
cumplimiento.
- Cuando traes un nuevo sistema en línea, se introduce rápidamente en
cumpla con sus estándares y no se "pierda" ni se deje de lado.
¿Es una necesidad o la mejor práctica restringir a un usuario de Linux de
tener derechos "sudo" en su sistema "propio", por razones de seguridad y
¿Seguridad para proteger de amenazas externas?
Debe haber un equilibrio entre la seguridad y la necesidad empresarial. Los desarrolladores a menudo tienen una necesidad legítima de acceso privilegiado. Para equilibrar esa necesidad, la seguridad a menudo restringirá los privilegios (por ejemplo, sudo a comandos particulares pero no un shell raíz), registro para auditoría (por ejemplo, bash a syslog, disponible en 4.1+ ), y limitar el daño al conjunto (por ejemplo, acceso restringido de salida a través del firewall).
¿Se puede realizar la seguridad y la protección contra amenazas externas con un
buen conjunto de reglas para iptables y mantenimiento adecuado de la
El firewall de la intranet?
No, se necesita más que eso, como se describe anteriormente.
Para citar a Gary Larson:
Es el acceso raíz remoto a una máquina Linux, desde dentro de la intranet, un
práctica segura?
Es más inseguro que el acceso raíz local, simplemente porque se pierde la autenticación del usuario responsable de ejecutar los comandos (o se eliminan los pasos 1+). Requerir que los comandos privilegiados se vinculen a un usuario, y que se registren de esa manera, es necesario tanto en el contenido (ahora lo sabe) como en la consecuencia (los desarrolladores a los que se responsabiliza personalmente son menos propensos a hacer cosas que no deberían).