Seguridad de los
Sistemas Operativos
Seguridad Física
Luego de ver como
nuestro sistema puede verse afectado por la falta de Seguridad
Física, es importante recalcar que la mayoría
de los daños que puede sufrir un centro de cómputos no será sobre los medios
físicos sino contra información por él almacenada y procesada.
Así, la Seguridad
Física, sólo es una parte del amplio
espectro que se debe cubrir para no vivir con una sensación ficticia de
seguridad. Como ya se ha mencionado, el activo más importante que se posee es
la información, y por lo
tanto deben existir técnicas, más allá de la seguridad física, que la aseguren.
Estas técnicas las brinda la Seguridad Lógica.
Es decir que la Seguridad Lógica consiste en la
"aplicación de barreras y procedimientos que resguarden el acceso a los
datos y sólo se permita acceder a ellos a las personas autorizadas para hacerlo."
Existe un viejo dicho en
la seguridad informática que dicta que "todo lo que no está permitido debe
estar prohibido" y esto es lo que debe asegurar la Seguridad Lógica.
Los objetivos que se
plantean serán:
- Restringir
el acceso a los programas y archivos.
- Asegurar
que los operadores puedan trabajar sin una supervisión minuciosa y no
puedan modificar los programas ni los archivos que no correspondan.
- Asegurar
que se estén utilizados los datos, archivos y programas correctos en y por
el procedimiento correcto.
- Que la
información transmitida sea recibida sólo por el destinatario al cual ha
sido enviada y no a otro.
- Que la
información recibida sea la misma que ha sido transmitida.
- Que
existan sistemas alternativos secundarios de transmisión entre diferentes
puntos.
- Que se
disponga de pasos alternativos de emergencia para la transmisión de
información.
Qué es la seguridad funcional?
Hubo un momento en que la
seguridad en la electrónica, en particular en el mercado doméstico, significaba
poco más que el riesgo de descargas eléctricas y fijar la potencia nominal para
evitar el sobrecalentamiento y que se quemaran los componentes. Por ejemplo, no
hace mucho el único equipo electrónico de un coche era la radio y no era
necesario que fuese “funcionalmente segura”. Si la radio dejaba de funcionar,
no generaba un problema de seguridad. Por otro lado, unos resultados extraños e
inesperados del sistema de control dinámico de la estabilidad o del sistema de
distribución de la fuerza de frenado es probable que tengan consecuencias
fatales. De ahí la obligación de cumplir con las normas del estándar IEC 61508,
o las versiones más específicas de la aplicación, como el ISO 26262 para
vehículos. El ISO 26262 acaba de entrar en vigor y los desarrolladores de
sistemas de automoción deben asegurarse de que sus productos cumplen con sus
disposiciones.
Las
implicaciones del cumplimiento
La seguridad no es barata. Al
embarcarse en un proyecto para desarrollar y fabricar un sistema que debe ser
funcionalmente seguro, se debe entender que la norma de seguridad pertinente se
debe cumplir en todo momento, desde el diseño inicial hasta las pruebas
finales. Cuando se trabaja con un diseño embebido, resulta tentador interpretar
la declaración de cumplimiento de la norma ISO 61508 SIL 3 del fabricante de
chips micro controladores como que el uso de este dispositivo hará que todo el
sistema cumpla con la norma. No es así en absoluto: el sistema completo debe
cumplir con la norma, no solo los componentes individuales, es decir también el
hardware y el software. Un software correctamente diseñado no “se desgasta” ni
sufre fallos aleatorios. Un software que se ha probado de manera inadecuada
presenta a menudo fallos aleatorios aparentes una vez en servicio, a veces,
meses más tarde, causados muchas veces por desbordamientos de pila. Las normas
proporcionan orientación sobre el nivel de pruebas sistemáticas necesario para
lograr una calificación de seguridad concreta.
Las disposiciones de las normas de seguridad
funcional
Proporcionar procesos para
valorar los riesgos y asignar los objetivos de seguridad.
Ayudar a reducir los fallos
sistemáticos proporcionando orientación sobre las mejores prácticas de
desarrollo.
Proporcionar marcos de trabajo
para analizar las tasas de fallos aleatorios.
Proporcionar marcos de trabajo
para analizar la efectividad de los diagnósticos.
Proporcionar procedimientos para
garantizar que los niveles de seguridad se mantienen una vez que se entrega el
sistema.
Seguridad
administrativa
La seguridad administrativa
determina si se utiliza seguridad alguna, el tipo de registro en el que tiene
lugar la autenticación y otros valores, muchos de los cuales actúan como
valores predeterminados. Se debe planificar antes, ya que si no se habilita
correctamente la seguridad administrativa, se puede bloquear la consola
administrativa o provocar la terminación anormal del servidor.
· Se
recomienda encarecidamente que permita que la instalación predeterminada
instale la seguridad administrativa de manera predeterminada.
La seguridad
administrativa se puede considerar un "gran conmutador" que activa
una amplia variedad de valores de seguridad de WebSphere Application Server.
Estos valores se pueden especificar previamente, pero no se aplicarán hasta que
se active la seguridad administrativa. Los valores incluyen la autenticación de
usuarios, el uso de SSL (Secure Sockets Layer) y la opción de repositorio de
cuentas de usuario. En concreto, la seguridad de las aplicaciones, incluida la
autenticación y la autorización basada en roles, no se aplica a menos que esté
activada la seguridad administrativa. La opción de seguridad administrativa
está habilitada de forma predeterminada.
· Es
necesario que la seguridad administrativa no esté activada para que las
aplicaciones WebSphere utilicen los métodos JSSE para cifrar las comunicaciones
en los sitios remotos.
La seguridad global
administrativa representa la configuración de seguridad que es eficaz para todo
el dominio de seguridad. Un dominio de seguridad está formado por todos los
servidores configurados con el mismo nombre de reino de registro de usuarios.
En algunos casos, el reino puede ser el nombre de la máquina de un registro del
sistema operativo local. En este caso, todos los servidores de aplicaciones
deben residir en la misma máquina física. En otros casos, el reino puede ser el
nombre de la máquina de un registro LDAP (Lightweight Directory Access
Protocol) autónomo.
Se da soporte a una
configuración de varios nodos debido a que puede acceder remotamente a registros
de usuario que dan soporte al protocolo LDAP. Por lo tanto, puede habilitar la
autenticación desde cualquier lugar.
El requisito básico de
un dominio de seguridad es que el ID de acceso devuelto por el registro o
repositorio desde un servidor dentro del dominio de seguridad sea el mismo ID
de acceso que el devuelto desde el registro o repositorio en otro servidor
dentro del mismo dominio de seguridad. El ID de acceso es la única
identificación de un usuario, y se utiliza durante la autorización para determinar
si se permite el acceso al recurso.
La configuración de
seguridad administrativa se aplica a todos los servidores dentro del dominio de
seguridad.
¿Por
qué se activa la seguridad administrativa?
La activación de la
seguridad administrativa activa los valores que protegen al servidor de
usuarios no autorizados. La seguridad administrativa está habilitada de forma
predeterminada durante el tiempo de creación de perfiles. Hay algunos entornos
en los que no se necesita seguridad como, por ejemplo, los sistemas de
desarrollo. En estos sistemas puede elegir inhabilitar la seguridad
administrativa. No obstante, en la mayoría de entornos debe impedir que los
usuarios no autorizados accedan a la consola administrativa y a las
aplicaciones empresariales. La seguridad administrativa debe estar habilitada
para restringir el acceso.
¿Qué
protege la seguridad administrativa?
La configuración de la
seguridad administrativa de un dominio de seguridad requiere la configuración
de las siguientes tecnologías:
Autenticación de
clientes HTTP
Autenticación de
clientes IIOP
Seguridad de la consola
administrativa
Seguridad de nombres
Uso de transportes SSL
Comprobaciones de
autorización basada en roles de servlets, enterprise beans y mbeans
Propagación de
identidades (RunAs)
Comprobaciones CBIND
Registro de usuarios
común
Mecanismo de
autenticación
Otra información de
seguridad que define el comportamiento de un dominio de seguridad incluye:
Protocolo de
autenticación (seguridad RMI/IIOP (Remote Method Invocation over the Internet
Inter-ORB Protocol))
Otros atributos varios
· Antes
de registrar un nodo con un proceso de agente administrativo, se recomienda
tener habilitada la seguridad administrativa en el agente administrativo y el
perfil base. Una vez que haya registrado un perfil con el agente
administrativo, el estado de habilitación de la seguridad administrativa no
podrá modificarse.
No hay comentarios:
Publicar un comentario