Los principios del diseño que computa seguro

Share

|

Los principios del diseño seguro discutidos en esta sección expresan comu'n-detectan usos de la simplicidad y de la restricción en términos de computar.

Principio de menos privilegio

Este principio restringe cómo se conceden los privilegios.

El principio de menos privilegio indica que un tema se debe dar solamente esos privilegios que necesite para terminar su tarea.

Si un tema no necesita una derecha de acceso, el tema no debe tener eso a la derecha. Además, la función del tema (en comparación con su identidad) debe controlar la asignación de las derechas. Si una acción específica requiere que las derechas de acceso de un tema estén aumentadas, las esas derechas adicionales se deben abandonar inmediatamente en la terminación de la acción. Éste es el análogo de la "necesidad de saber" regla: si el tema no necesita el acceso a un objeto realizar su tarea, no debe tener la derecha de tener acceso a ese objeto. Más exacto, si un tema necesita añadir a un objeto, pero no alterar la información contenida ya en el objeto, debe ser dada añade las derechas y no escribir las derechas.

En la práctica, la mayoría de los sistemas no tienen el granularity de los privilegios y de los permisos requeridos para aplicar este principio exacto. Los diseñadores de los mecanismos de la seguridad entonces aplican este principio como pueden lo más mejor posible. En tales sistemas, las consecuencias de los problemas de la seguridad son a menudo más severas que las consecuencias para los sistemas que adhieren a este principio.

EJEMPLO: El sistema operativo de UNIX no aplica controles de acceso a la raíz del usuario. Que el usuario puede terminar cualquier proceso y leer, escribe, o suprime cualquier archivo. Así, los usuarios que crean reservas pueden también suprimir archivos. La cuenta del administrador en Windows tiene las mismas energías.

Este principio requiere que los procesos sean confinados como a pequeño un dominio de protección como sea posible.

EJEMPLO: Un mail server acepta el correo del Internet y copia los mensajes en un directorio spool; un servidor local terminará entrega. El mail server necesita las derechas de tener acceso al puerto apropiado de la red, de crear archivos en el directorio spool, y de alterar esos archivos (así que él puede copiar el mensaje en el archivo, reescribe la dirección de entrega si está necesitado, y agrega las líneas "recibidas" apropiadas). Debe entregar la derecha de tener acceso al archivo tan pronto como haya acabado el escribir del archivo en el directorio spool, porque no necesita tener acceso a ese archivo otra vez. El servidor no debe poder tener acceso a los archivos de ningún usuario, o cualquier archivo con excepción de su propia configuración archiva.

Principio de defectos a prueba de averías

Este principio restringe cómo se inicializan los privilegios cuando se crea un tema o un objeto.

El principio de los estados de defectos a prueba de averías que, a menos que un tema se dé el acceso explícito a un objeto, debe ser negado a acceso a ese objeto.

Este principio requiere que el acceso del defecto a un objeto no sea ninguno. Siempre que el acceso, los privilegios, o una cierta cualidad seguridad-relacionada no se conceda explícitamente, debe ser negado. Por otra parte, si el tema no puede terminar su acción o tarea, debe deshacer esos cambios que realizó en el estado de la seguridad del sistema antes de que termine. Esta manera, iguala si el programa falla, el sistema sigue siendo segura.

EJEMPLO: Si el mail server no puede crear un archivo en el directorio spool, debe cerrar la conexión de red, publica un mensaje de error, y para. No debe intentar almacenar el mensaje a otra parte o ampliar sus privilegios de ahorrar el mensaje en otra localización, porque un atacante podría utilizar que capacidad de sobreescribir otros archivos o de llenar para arriba otros discos (una negación del ataque del servicio). Las protecciones en el directorio spool del correo sí mismo deben permitir crean y escriben el acceso solamente al mail server y leen y suprimen el acceso solamente al servidor local. Ningún otro usuario debe tener acceso al directorio. En la práctica, la mayoría de los sistemas permitirán un acceso del administrador al directorio spool del correo. Por el principio de menos privilegio, ese administrador debe poder tener acceso solamente a los temas y a los objetos implicados en hacer cola y entrega del correo. Como hemos visto, este constreñimiento reduce al mínimo las amenazas si se compromete la cuenta de ese administrador. El sistema del correo puede ser dañado o ser destruido, pero nada puede estar.

Principio de la economía del mecanismo

Este principio simplifica el diseño y la puesta en práctica de los mecanismos de la seguridad.

El principio de la economía del mecanismo indica que los mecanismos de la seguridad deben ser tan simples como sea posible.

Si un diseño y una puesta en práctica son simples, pocas posibilidades existen para los errores. El proceso de comprobación y de prueba es menos complejo, porque pocos componentes y casos necesitan ser probados. Los mecanismos complejos hacen a menudo asunciones sobre el sistema y el ambiente en los cuales funcionan. Si estas asunciones son incorrectas, los problemas de la seguridad pueden resultar.

EJEMPLO: El protocolo de la identificación envía el nombre del usuario asociado a un proceso que tenga una conexión del TCP a un anfitrión alejado. Un mecanismo en el anfitrión A que permite el acceso basado en los resultados de un resultado del protocolo de la identificación hace la asunción que el anfitrión el originar es digno de confianza. Si el anfitrión B decide a atacar el anfitrión A, puede conectar y después enviar cualquier identidad que elija en respuesta a la petición de la identificación. Éste es un ejemplo de un mecanismo que hace una asunción incorrecta sobre el ambiente (específicamente, ese anfitrión B se puede confiar en).

Los interfaces a otros módulos son particularmente sospechados, porque los módulos hacen a menudo asunciones implícitas sobre los parámetros de la entrada o de salida o el estado actual del sistema; si cualesquiera de estas asunciones son mal, las acciones del módulo pueden producir inesperado, y erróneo, resultados. La interacción con las entidades externas, tales como otros programas, sistemas, o los seres humanos, amplifica este problema.

EJEMPLO: El protocolo del dedo transmite la información sobre un usuario o un sistema. Muchas puestas en práctica del cliente asumen que la respuesta del servidor es bien formada. Sin embargo, si un atacante creara un servidor que generó una corriente infinita de caracteres, y un cliente del dedo debía conectar con ella, el cliente imprimiría todos los caracteres. Consecuentemente, los ficheros de diario y los discos se podían llenar para arriba, dando por resultado una negación del ataque del servicio contra el anfitrión que preguntaba. Éste es un ejemplo de asunciones incorrectas sobre la entrada al cliente.

Principio de la mediación completa

Este principio restringe depositar de la información, que conduce a menudo a puestas en práctica más simples de mecanismos.

El principio de la mediación completa requiere que todos los accesos a los objetos estén comprobados para asegurarse de que estén permitidos.

Siempre que un tema procure leer un objeto, el sistema operativo debe mediar la acción. Primero, se determina si se permite al tema leer el objeto. Si es así proporciona los recursos para leídos ocurre. Si el tema intenta leer el objeto otra vez, el sistema debe comprobar que todavía se permita al tema leer el objeto. La mayoría de los sistemas no harían el segundo cheque. Depositarían los resultados del primer cheque y basarían el segundo acceso en los resultados depositados.

EJEMPLO: Cuando un proceso de UNIX intenta leer un archivo, el sistema operativo se determina si el proceso se permite leer el archivo. Si es así el proceso recibe un descriptor del fichero que codifica el acceso permitido. Siempre que el proceso desee leer el archivo, presenta el descriptor del fichero al núcleo. El núcleo entonces permite el acceso. Si el dueño del archivo rechaza el permiso de proceso de leer el archivo después de que se publique el descriptor del fichero, el núcleo todavía permite el acceso. Este esquema viola el principio de la mediación completa, porque el segundo acceso no se comprueba. El valor depositado se utiliza, dando por resultado la negación del acceso que es ineficaz.

EJEMPLO: El servicio del Domain Name (DNS) deposita la información traz nombres de anfitrión en direcciones del IP. Si un atacante puede "envenenar" el escondrijo implantando registra asociar un IP address falso a un nombre, un anfitrión encaminará conexiones a otro anfitrión incorrectamente.

Principio del diseño abierto

Este principio sugiere que la complejidad no agregue seguridad.

El principio del diseño abierto indica que la seguridad de un mecanismo no debe depender del secreto de su diseño o puesta en práctica.

Los diseñadores y los ejecutores de un programa no deben depender del secreto de los detalles de su diseño y puesta en práctica para asegurar seguridad. Otros pueden ferret fuera de tales detalles con medios técnicos, tales como desmontaje y análisis, o con medios no técnicos, tales como buscar a través de los receptáculos de la basura para los listados de código de fuente (llamados "dumpster-salto"). Si la fuerza de la seguridad del programa depende de la ignorancia del usuario, un usuario bien informado puede derrotar ese mecanismo de la seguridad. El término "seguridad con oscuridad" captura este concepto exactamente.

Esto es especialmente verdad de software y de sistemas criptográficos. Porque la criptografía es un tema altamente matemático, las compañías que ponen la criptografía criptográfica del software o del uso para proteger datos del usuario con frecuencia mantienen sus algoritmos secretos. La experiencia ha demostrado que tal secreto agrega poco si cualquier cosa a la seguridad del sistema. Peor, da una aureola de la fuerza que es toda que carece demasiado a menudo en la puesta en práctica real del sistema.

Manteniendo llaves criptográficas y las contraseñas secretas no viola este principio, porque una llave no es un algoritmo. Sin embargo, guardando los algoritmos de codificación y que descifran secretos la violaría.

Las aplicaciones el software propietario y los secretos comerciales complican el uso de este principio. En algunos casos, las compañías pueden no desear sus diseños hechos público, a fin de sus competidores los utilicen. El principio entonces requiere que el diseño y la puesta en práctica estén disponibles para la gente barrada de divulgarlo fuera de la compañía.

EJEMPLO: El sistema contento el revolver (CSS) es un algoritmo criptográfico que protege discos de la película de DVD contra el copiado desautorizado. El disco de DVD tiene una llave de la autentificación, una llave de disco, y una llave del título. La llave del título se codifica con la llave de disco. Un bloque en el DVD contiene varias copias de la llave de disco, de cada uno codificadas por una diversa llave del jugador, y de una suma de comprobación de la llave de disco. Cuando un DVD se inserta en un jugador de DVD, el algoritmo lee la llave de la autentificación. Entonces descifra las llaves de disco usando la llave única del jugador de DVD. Cuando encuentra una llave descifrada con el picadillo correcto, él las aplicaciones que afinan a la descifración la llave del título, y él utiliza la llave del título para descifrar la película. La autentificación y las llaves de disco no están situadas en el archivo que contiene la película, así que si una copia el archivo, un alambique necesita el disco de DVD en el jugador de DVD poder jugar la película. En 1999, un grupo en Noruega adquirió a (software) DVD que jugaba el programa que tenía unenciphered llave. También derivaron un algoritmo totalmente compatible con el algoritmo del CSS del software. Esto les permitió descifrar cualquier archivo de la película de DVD. El software que podría realizar estas funciones rápidamente llegó a estar disponible a través del Internet, mucho al malestar de la asociación del control del copyright de DVD, que demandó puntualmente para evitar que el código sea hecho público. Como si para acentuar los problemas de proporcionar seguridad encubriendo algoritmos, los abogados del demandante archivaran un declaración que contenía el código de fuente de una puesta en práctica del algoritmo del CSS. Cuando realizaron esto, solicitaron que el declaración esté sellado de la visión pública. Para entonces, el declaración había sido fijado en varios sitios de Internet, incluyendo uno que tenía más de 21.000 transferencias directas del declaración antes de que la corte lo sellara.

Principio de la separación del privilegio

Este principio es restrictivo porque limita el acceso a las entidades del sistema.

El principio de la separación del privilegio indica que un sistema no debe conceder el permiso basado en una sola condición.

Este principio es equivalente a la separación del principio del deber. La compañía comprueba para saber si hay más de $75.000 se deben firmar por dos oficiales de la compañía. Si cualquiera no firma, el cheque es inválido. Las dos condiciones son las firmas de ambos oficiales.

Semejantemente, los sistemas y los programas que conceden el acceso a los recursos deben hacer tan solamente cuando se resuelve más de una condición. Esto proporciona un control de grano fino sobre el recurso así como aseguramiento adicional que el acceso está autorizado.

EJEMPLO: En las versiones Berkeley-basadas del sistema operativo de UNIX, no se permite a los usuarios cambiar de sus cuentas a la cuenta de la raíz a menos que se resuelvan dos condiciones. La primera condición es que el usuario sabe la contraseña de la raíz. La segunda condición es que el usuario está en el grupo de la rueda (el grupo con GID 0). Resolver cualquier condición no es suficiente adquirir el acceso de la raíz; se requiere resolver ambas condiciones.

Principio de menos mecanismo común

Este principio es restrictivo porque limita compartir.

El principio de menos mecanismo del campo común indica que los mecanismos usados para tener acceso a recursos no deben ser compartidos.

Compartir recursos proporciona un canal a lo largo de el cual la información pueda ser transmitida, y así que el tal compartir debe ser reducido al mínimo. En la práctica, si el sistema operativo proporciona la ayuda para las máquinas virtuales, el sistema operativo hará cumplir este privilegio automáticamente a un cierto grado. Si no, proporcionará una cierta ayuda (tal como un espacio de la memoria virtual) pero no terminará la ayuda (porque el sistema de ficheros aparecerá según lo compartido entre varios procesos).

EJEMPLO: Un sitio del Web proporciona los servicios electrónicos del comercio para una compañía importante. Los atacantes desean privar a la compañía del rédito que obtiene de ese sitio del Web. Inundan el sitio con los mensajes y atan para arriba los servicios electrónicos del comercio. Los clientes legítimos no pueden tener acceso al sitio del Web y, consecuentemente, tomar su negocio a otra parte. Aquí, el compartir del Internet con los sitios de los atacantes hizo el ataque tener éxito. Las contramedidas apropiadas serían restringir el acceso de los atacantes al segmento del Internet conectado con el sitio del Web. Las técnicas para hacer esto incluyen los servidores del poder tales como sofocar del intermediario o del tráfico de Purdue SYN. Las conexiones sospechadas de las blancos anteriores; el último reduce la carga en el segmento relevante de la red indistintamente.

Principio de la aceptabilidad psicologica

Este principio reconoce el elemento humano en seguridad de la computadora.

El principio de la aceptabilidad psicologica indica que los mecanismos de la seguridad no deben hacer el recurso más difícil de tener acceso que si los mecanismos de la seguridad no estaban presentes.

El configuración y ejecutar de un programa deben ser tan fáciles y tan intuitivos como sea posible, y cualquier salida debe ser clara, directa, y útil. Si el software seguridad-relacionado se complica también para configurar, los administradores de sistema pueden instalar inintencionalmente el software de una manera del nonsecure. Semejantemente, los programas de usuario seguridad-relacionados deben ser fáciles de utilizar y deben hacer salir mensajes comprensibles. Si se rechaza una contraseña, el programa que cambia de la contraseña debe indicar porqué fue rechazado más bien que dando un mensaje de error secreto. Si un archivo de la configuración tiene un parámetro incorrecto, el mensaje de error debe describir el parámetro apropiado.

EJEMPLO: El programa del ssh permite que un usuario instale un mecanismo dominante público para codificar comunicaciones entre los sistemas. Los mecanismos de la instalación y de la configuración para la versión de UNIX permiten que una arregle que la llave pública esté almacenada localmente sin ninguna protección de contraseña. En este caso, uno no necesita proveer una contraseña para conectar con el sistema alejado, pero inmóvil obtendrá la conexión codificada. Este mecanismo satisface el principio de la aceptabilidad psicologica.

Por otra parte, la seguridad requiere que los mensajes no impartan ninguna información innecesaria.

EJEMPLO: Cuando un usuario provee la contraseña incorrecta durante la conexión, el sistema debe rechazar la tentativa con un mensaje que indica que la conexión falló. Si dijera que la contraseña era incorrecta, el usuario sabría que el nombre de cuenta era legítimo. Si el "usuario" fuera realmente un atacante desautorizado, ella entonces sabría el nombre de un explicar que ella podría intentar para conjeturar una contraseña.

En la práctica, el principio de la aceptabilidad psicologica se interpreta para significar que el mecanismo de la seguridad puede agregar una cierta carga adicional, pero que la carga debe ser mínima y razonable.

EJEMPLO: Un sistema del chasis permite que los usuarios pongan contraseñas en archivos. Tener acceso a los archivos requiere que la fuente del programa la contraseña. Aunque este mecanismo viola el principio según lo indicado, se considera suficientemente mínimo ser aceptable. En un sistema interactivo, donde está más frecuente y más transitorio el patrón de los accesos del archivo, este requisito sería una carga demasiado grande a ser aceptable.