Menciona J. Boria. (1987) que los sistemas operativos proveen algunos mecanismos de protección para poder implementar políticas de seguridad. Las políticas definen qué hay que hacer (qué datos y recursos deben protegerse de quién; es un problema de administración), y los mecanismos determinan cómo hay que hacerlo. Esta separación es importante en términos de flexibilidad, puesto que las políticas pueden variar en el tiempo y de una organización a otra. Los mismos mecanismos, si son flexibles, pueden usarse para implementar distintas políticas.
Postula J.Boria. (1987) los objetivos para la protección de los sistemas operativos.
Objetivos de la Protección
• Inicialmente protección del SO frente a usuarios poco confiables.
• Protección: control para que cada componente activo de un proceso sólo pueda acceder a los recursos especificados, y sólo en forma congruente con la política establecida.
• La mejora de la protección implica también una mejora de la seguridad.
• Las políticas de uso se establecen:
- Por el hardware.
-Por el administrador / SO.
-Por el usuario propietario del recurso.
• Principio de separación entre mecanismo y política:
-Mecanismo.- con qué elementos (hardware y/o software) se realiza la protección.
- Política.- es el conjunto de decisiones que se toman para especificar cómo se usan esos elementos de protección.
6.2 Funciones del sistema de protección.
H. Deitel (1987) define que dado que los sistemas de cómputo se han venido haciendo cada vez más sofisticados en sus aplicaciones, la necesidad de proteger su integridad, también ha crecido.
H. Deitel (1987) Menciona que los aspectos principales de protección en un Sistema Operativo son:
1. Protección de los procesos del sistema contra los procesos de usuario.
2. Protección de los procesos de usuario contra los de otros procesos de usuario.
3. Protección de Memoria.
4. Protección de los dispositivos.
6.3 IMPLANTACION DE MATRICES DE ACCESO.
A. Tanenbaum. (1993) postula que un modelo de protección puede ser visto abstractamente como una matriz, llamada matriz de derecho. Los renglones de la matriz representan dominios y las columnas representan objetos. Cada entrada en la matriz contiene un conjunto de derechos de acceso. Dado que los objetos son definidos explícitamente por la columna, se puede omitir el nombre del objeto en el derecho de acceso. La entrada "Matriz[i, j]" define el conjunto de operaciones que un proceso ejecutándose en el dominio "Dj" puede realizar sobre el objeto "Oj".
A. Tanenbaum. (1993) Considero la siguiente matriz de acceso:
Dominio \ Objeto
A1
A2
A3
COM1
LPT1
D1
Leer
Leer
D2
Leer
Imprimir
D3
Leer
Ejecutar
D4
Leer Escribir
Leer Escribir
.
6.4 Protección Basada en Lenguaje
Explica A. Tanenbaum. (1993) que la protección que se ofrece en los sistemas de computación existentes casi siempre se ha logrado con la ayuda del núcleo de un sistema operativo, que actúa como agente de seguridad que inspecciona y valida cada intento por acceder a un recurso protegido. Puesto que la validación de todos los accesos puede dar pie a un gasto extra considerable, debemos apoyarla con hardware para reducir el costo de cada validación o bien debemos aceptar que el diseñador del sistema podría inclinarse por sacrificar los objetivos de la protección. Es difícil satisfacer todos estos objetivos si los mecanismos de soporte con que se cuenta restringen la flexibilidad para implementar diversas políticas de protección.
Outra deficinion mencionada por Silberschantz. (1999). Las políticas para el uso de recursos también podrían variar, dependiendo de la aplicación, y podrían cambiar con el tiempo. Por estas razones, la protección ya no puede considerarse como un asunto que sólo concierne al diseñador de un sistema operativo; también debe estar disponible como herramienta que el diseñador de aplicaciones pueda usar para proteger los recursos de un subsistema de aplicación contra intervenciones o errores.
Silberschantz. (1999). Menciona que este enfoque tiene varias ventajas importantes:
1. Las necesidades de protección se declaran de forma sencilla en vez de programarse como una secuencia de llamadas a procedimientos de un sistema operativo.
2. Las necesidades de protección pueden expresarse independientemente de los recursos que ofrezca un sistema operativo en particular.
3. El diseñador de un subsistema no tiene que proporcionar los mecanismos para hacer cumplir la protección.
4. Una notación declarativa es natural porque los privilegios de acceso están íntimamente relacionados con el concepto lingüístico de tipo de datos.
6.5 Concepto de seguridad
H.Deitel. (1987) Menciona que un concepto de seguridad está definido como el un conjunto de medidas tomadas para protegerse contra robos, ataques, crímenes y espionajes o sabotajes. La seguridad implica la cualidad o estado de estar seguro, es decir, la evitación de exposiciones a situaciones de peligro y la actuación para quedar a cubierto frente a contingencias adversas.
H.Deitel. (1987) Declara que la seguridad, no solo requiere un sistema de protección apropiado, sino también considerar el entorno externo en el que el sistema opera. La protección interna no es útil si la consola del operador está al alcance de personal no autorizado, o si los archivos se pueden sacar simplemente del sistema de computación y llevarse a un sistema sin protección. Estos problemas de seguridad son esencialmente de administración, no problemas del sistema operativo.
H.Deitel. (1987) Redacta en su libro introducción al los sistemas operativos que la información almacenada en el sistema, así como los recursos físicos del sistema de computación, tienen que protegerse contra acceso no autorizado, destrucción o alteración mal intencionado, y la introducción accidental de inconsistencia.
6.6 Clasificaciones de la seguridad
Schwinmmer. (2006) señala que la clasificación de los sistemas de computación según sus requisitos de seguridad ha sido un tema ampliamente discutido desde los años setenta. La disparidad de criterios existentes se ha ampliado más con la conexión de las computadoras para formar redes de computación que pueden compartir recursos.
Señala Schwinmmer. (2006) que en la clasificación especifica, hay cuatro niveles de seguridad: a, b, c y d… a continuación, se describen estos niveles de seguridad y las características de cada uno.
Nivel D es el Sistemas con protección mínima o nula no pasan las pruebas de seguridad mínima. MS-DOS y Windows 3. 1 son sistemas de nivel d. Puesto que están pensados para un sistema mono proceso y mono usuario, no proporcionan ningún tipo de control de acceso ni de separación de recursos.
Nivel C a la Capacidad discrecional para proteger recursos, La aplicación de los mecanismos de protección depende del usuario, o usuarios, que tienen privilegios sobre los mismos. Entonces esto significa que un objeto puede estar disponible para lectura, escritura o cualquier otra operación. Y entonces casi todos los sistemas operativos comerciales de propósito general, como Unix, Linux o Windows NT se clasifican en este nivel.es decir dos son:
1. Control de acceso por dominios.
2. Control de acceso individualizado.
Nivel B es el Control de acceso obligatorio en este nivel, los controles de acceso no son discrecionales de los usuarios o los dueños de los recursos, que deben existir obligatoriamente. Esto significa que todo objeto controlado debe tener protección sea del tipo que sea. Es decir que son tres y son:
1. Etiqueta de seguridad obligatoria.
2. Protección estructurada.
3. Y el dominio de seguridad.
Nivel A es el Sistemas de seguridad certificados para acceder a este nivel, la política de seguridad y los mecanismos de protección del sistema deben ser verificados y certificados por un organismo autorizado para ello.es decir dos tipos:
1. Diseño verificado.
2. Desarrollo controlado.
6.7 Validación y amenazas al sistema
H.Deitel. (1993) menciona las siguientes amenazas muy importantes para un sistema y algunas técnicas de prevención y detección de intrusos:
Amenazas a la seguridad en el acceso al sistema:
· Intrusos.
· programas malignos.
Intrusos:
· Piratas o hackers: individuos que acceden al sistema sin autorización.
· Los sistemas presentan agujeros por donde los hackers consiguen colarse.
· Técnicas de intrusión:
- Averiguar contraseñas (más del 80% de las contraseñas son simples).
- Probar exhaustivamente.
- Descifrar archivo de contraseñas.
- Intervenir líneas.
- Usar caballos de Troya.
Técnicas de prevención de intrusos:
Establecer una buena estrategia de elección de contraseñas:
ü Contraseñas generadas por ordenador (difícil memorización).
ü Inspección activa (proceso periódico de averiguación).
ü Inspección proactiva (decidir si es buena en su creación.
Tipos de amenazas:
· Amenazas pasivas:
- Revelación del contenido del mensaje.
- Análisis del tráfico:
- En caso de que los mensajes vayan encriptados.
· Amenazas activas:
- Alteración del flujo de mensajes.
- Privación del servicio:
- Impide el uso normal de los servicios de comunicaciones.
- Suplantación:
- Cuando una entidad finge ser otra diferente.
H.Deitel. (1993) Señala en un diagrama la clasificación de programas malingnos.
Clasificación de programas malignos:
Programas malignos que necesitan anfitrión:
· Trampillas:
- Punto de entrada secreto a un programa.
- Se usan para depuración y prueba.
- Pueden usarse para acceso no autorizado.
· Bomba lógica:
- Se ejecutan cuando se cumplen ciertas condiciones.
· Caballo de Troya:
- Código dañino incrustado en programa que se ejecuta cuando se ejecuta el programa.
Programas malignos que no necesitan anfitrión:
· Gusanos:
- Programas independientes.
- Se reproducen a través de la red.
- Además de propagarse pueden causar daños.
· Bacterias:
- No dañan explícitamente.
- Su único objetivo es reproducirse.
· Virus:
- Código incrustado en un programa.
- Se reproducen e insertan en otros programas.
.
6.8 Cifrado
Menciona S, Williams. (2001). que la criptografía es el uso de la transformación de datos para hacerlos incomprensibles a todos, excepto a los usuarios a quienes están destinados.
El problema de la intimidad trata de cómo evitar la obtención no autorizada de información de un canal de comunicaciones.
El problema de la autentificación trata sobre cómo evitar que un oponente:
Modifique una transmisión.
Le introduzca datos falsos.
S, Williams. (2001). Señala que un problema de la disputa trata sobre cómo proporcionar al receptor de un mensaje pruebas legales de la identidad del remitente, que serían el equivalente electrónico de una firma escrita.
REFERENCIAS BIBLIOGRAFICAS.
J. Boria. “Construcción de Sistemas Operativos” (1987) Prentice-Hall, 1987. [España]
H. M. Deitel. Introducción a los Sistemas Operativos. Addison-Wesley Iberoamericana, 1987, 1993. [Mexico]
William Sistemas Operativos – Cuarta Edición. Madrid, Prentice-Hall, 2001. [España]
W. Stallings. Data and Computer Communications - Fifth Edition. Prentice Hall, 1997. [Estados Unidos]
A. Tanenbaum. Sistemas Operativos Modernos. Prentice Hall Hispanoamericana, S.A., 1993. [Mexico]
A. Tanenbaum. Operating Systems: Design And Implementation. Prentice Hall, 1987. [Estados Unidos]
A. Silberschatz. Operating Systems Concepts. Addison-Wesley, 1991 [Estados Unidos]
No hay comentarios:
Publicar un comentario