361971705 AP4 AA4 Ev1 Mecanismos de Control y Seguridad

AP4-AA4-Ev1-Mecanismos de control y seguridad

INFORME ESCRITO

PRESENTADO POR: JUAN DAVID BARONA

PRESENTADO A: DAIRO ALBERTO RODRIGUEZ BLANCO

ANALISIS Y DESARROLLO DE SISTEMAS DE LA INFORMACIÓN SENA

"EN EL CALL CENTER DE LA FUNDACION GENCERO EXITO"

Se tendrá en cuenta los siguientes factores para lograr un mejor avance en cada una de las dependencias que se tendrán y el usuario logre acceder fácilmente a nuestros servicios.

1. SEGMENTACIÓN DE PROCESOS, PERFILES Y ROLES: “Hoy en día la interconexión entre redes es más común de lo que parece, desde una simple conexión a internet, ya estamos sumergidos en un sin fin de conexiones, de las que muchas veces como usuarios ni nos damos cuenta de todo lo que acontece detrás de un simple cable de red. Precisamente para mantener un orden detrás de ese cable existe algo que permite la comunicación entre redes, que permite una mejor distribución de todos los datos que por allí viajan, permite un mejor manejo del ancho de banda utilizado por cada usuario en la red, a esa distribución la llamamos Segmentación de Redes.” Hay dos motivos fundamentales para dividir una red en segmentos. La primera es aislar el tráfico entre segmentos. La segunda razón es lograr más ancho de banda por usuario mediante la creación de dominios de colisión más pequeños. Sin la segmentación, las redes más grandes que un pequeño grupo de trabajo podría atascarse rápidamente con el tráfico y las colisiones. “Cabe destacar que el tipo de red común hoy en día es la red basada en IPV4, es la versión 4 del protocolo IP, debido a su implementación a gran escala, su crecimiento se desbordo al que inicialmente se esperaba en su diseño, cuyo límite en el número de direcciones de red admisibles está empezando a restringir el crecimiento de Internet y su uso, debido a este auge y dado que el requerimiento de grandes velocidades en internet en mayor dado el contenido que se maneja actualmente (multimedia, vos sobre ip, video sobre ip, telefonía por ip etc.), es que hoy en día le está dando paso a una versión mejorada que distribuye y maneja mejor el número de direcciones para el mejor uso de la Internet, el llamado IPV6, que no es más el reemplazo mejorado de su antecesor IPV4. Volviendo a IPV4 que es la usada actualmente en la mayoría de las redes mundiales, especialmente en redes LAN, esto hace que se requiera un buen diseño estructural de las redes, que permitan definir grupos, acceso y, por ende controlar el ancho de banda para cada nodo de la red, esto se hace por medio de la segmentación, la cual como hemos mencionado hace que esto sea posible.

2. MECANISMO DE AUTENTICACIÓN A IMPLEMENTAR EN EL SISTEMA: En nuestro call center se tendrán en cuenta los siguientes: Autenticación clásica En un sistema Unix habitual cada usuario posee un nombre de entrada al sistema o logan y una clave o password; ambos datos se almacenan generalmente en el fichero /etc./passwd. Este archivo contiene una línea por usuario donde se indica la información necesaria para que los usuarios puedan conectar al sistema y donar por medio del mismo, separando los diferentes campos mediante Al contrario de lo que mucha gente cree, Unix no es capaz de distinguir a sus usuarios por su nombre de entrada al sistema. Para el sistema operativo lo que realmente distingue a una persona de otra (o al menos a un usuario de otro) es el UID del usuario en cuestión; el login es algo que se utiliza principalmente para comodidad de las personas (obviamente es más fácil acordarse de un nombre de entrada como tono que de un UID como 2643, sobre todo si se tienen cuentas en varias máquinas, cada una con un UID diferente). Para cifrar las claves de acceso de sus usuarios, el sistema operativo Unix emplea un criptosistema irreversible que utiliza la función estándar de C crypt, basada en el algoritmo DES. Para una descripción exhaustiva del funcionamiento de crypt. Esta función toma como clave los ocho primeros caracteres de la contraseña elegida por el usuario (si la longitud de ésta es menor, se completa con ceros) para cifrar un bloque de texto en claro de 64 bits puestos a cero; para evitar que dos passwords iguales resulten en un mismo texto cifrado, se realiza una permutación durante el proceso de cifrada elegida de forma automática y aleatoria para cada usuario, basada en un campo formado por un número de 12 bits (con lo que conseguimos 4096 permutaciones diferentes) llamado Salt. El cifrado resultante se vuelve a cifrar utilizando la contraseña del usuario de nuevo como clave, y permutando con el mismo Salt, repitiéndose el proceso 25 veces. El bloque cifrado final, de 64 bits, se concatena con dos bits cero, obteniendo 66 bits que se hacen representables en 11 caracteres de 6 bits cada uno y que, junto con el Salt, pasan a constituir el campo password del fichero de contraseñas, usualmente /etc./passwd. Así, los dos primeros caracteres de este campo estarán constituidos por el salt y los 11 restantes por la contraseña cifrada. Otro método cada día más utilizado para proteger las contraseñas de los usuarios el denominado Shadow Password u oscurecimiento de contraseñas. La idea básica de este mecanismo es impedir que los usuarios sin privilegios puedan leer el fichero donde se almacenan las claves cifradas. Envejecimiento de contraseñas En casi todas las implementaciones de Shadow Password actuales se suele incluir la implementación para otro mecanismo de protección de las claves denominado envejecimiento de contraseñas (Password Aging). La idea básica de este mecanismo es proteger los passwords de los usuarios dándoles un determinado periodo de vida: una contraseña sólo va a ser válida durante un cierto tiempo,

pasado el cual expirará y el usuario deberá cambiarla. Realmente, el envejecimiento previene más que problemas con las claves problemas con la transmisión de éstas por la red: cuando conectamos mediante mecanismos como telnet, ftp o rlogin a un sistema Unix, cualquier equipo entre el nuestro y el servidor puede leer los paquetes que enviamos por la red, incluyendo aquellos que contienen nuestro nombre de usuario y nuestra contraseña. Sintaxis del archivo de configuración El archivo (/etc./pam.conf) está formado por una lista de reglas (típicamente una por línea). Cada regla es un conjunto de campos separados por espacios (los tres primero’s son case-sensitives): Service type control module-path module-arguments La sintaxis de los archivos bajo /etc./pam. d/ es igual salvo que no existe el campo "ser vice". En este caso "servicio" es el nombre del archivo en el directorio /etc./pam. d/ (el nombre del archivo debe estar en minúsculas) Usualmente servicio es el nombre del servicio o aplicación comúnmente usado, ejemplo de esto son login, su y ssh. type especifica a que grupo de administración está asociada la regla. Las entradas válidas son: account: este módulo maneja la cuenta sin basarse en autenticación. Típicamente se usa para restringir/permitir el acceso a un servicio basado en la hora o quizás desde donde se loguea el usuario (ej.: root solo se puede loguear desde consola auth: provee mecanismo de autenticación (el usuario es quien dice ser). password: este módulo es requerido para modificar la password del usuario. session: este módulo está asociado con hacer tareas previas y/o posteriores al inicio del servicio mismo (pueden ser cosas como montar un directorio, activar logueos, etc.). El tercer campo control especifica que hacer si falla el control aplicado. Existen dos sintaxis para este campo, una sencilla de un campo y otra que especifica más de un campo dentro de corchetes rectos [] Para la básica, las opciones son: required: indica que esta regla debe ser exitosa, de lo contrario el usuario no es autorizado a correr el servicio. Si falla se devuelve el control al programa, pero antes se ejecutan todos los módulos. requisite: es como el required, pero devuelve el control al programa enseguida de fallar. sufficient: Si este módulo se verifica, entonces (se devuelve) se le da el ok al programa y no se sigue verificando los otros módulos. optional: la falla o no de este módulo es solo importante si es el único existente. El cuarto campo module-path específica el path al módulo PAM asociado con la regla. Los módulos se encuentran en /lib/security. El quinto campo module-arguments es un conjunto de cero o más

argumentos pasados al módulo durante su invocación. Los argumentos varían según el módulo. La configuración de los archivos de configuración bajo /etc./pam. d/ resulta ser más flexible (se evita tener un archivo único enorme). Bajo este directorio se puede encontrar el archivo de configuración personal de un servicio particular como ser ssh. La única diferencia entre la sintaxis del archivo /etc./pam.conf es que no existe el campo ser vice. 3. CIFRADO DE DATOS: TIPO DE ALGORITMOS A IMPLEMENTAR. Un algoritmo de cifrado simétrico es una fórmula matemática que convierte el texto plano en una forma ininteligible, cifrada, y conocida como texto cifrado. La variable, o clave de cifrado, que se utiliza para conducir un algoritmo de cifrado simétrico es derivado de la contraseña dada cuando los datos están cifrados, y una clave única compartida es utilizada para cifrar y descifrar los datos. Existen varios tipos diferentes de algoritmos de cifrado simétricos y su fuerza depende, en gran parte, de la longitud, en bits (0 y 1), de su clave de cifrado. 3DES Triple DES (3DES) es una mejora del simple DES que aplica el método de cifrado DES a los mismos datos tres veces para aumentar el nivel de cifrado. Triple DES aumenta la longitud de la clave de cifrado de 192 bits, pero es más lento que otros métodos de cifrado. Sin embargo, 3DES reemplazó a DES como el algoritmo de cifrado simétrico en el año 1999, de acuerdo con Federal Información Processing Stand Ards (FIPS). AES Advanced Encryption Standard (AES), que en realidad es una implementación de un algoritmo de cifrado simétrica conocida como Rjindael, es el último estándar recomendado por el NIST. AES utiliza una clave de cifrado que varía en longitud de 128 bits a 256 bits y cifra los datos en bloques de 128 bits. El algoritmo AES es aplicado a los datos 10, 12, o 14 veces, conocido como "rondas", lo que es muy seguro. De hecho, sólo un ataque de fuerza bruta, en el que la atacante prueba todas las combinaciones posibles de la clave de cifrado, ha demostrado ser eficaz contra AES. Sin embargo, AES es rápido, flexible y puede ser implementado en una variedad de diferentes plataformas. 4. PROCEDIMIENTOS ADICIONALES DE SEGURIDAD A IMPLEMENTAR El tema de la creación de una aplicación Web segura es muy amplio ya que requiere realizar un estudio para comprender los puntos vulnerables de la seguridad. Protegerse contra entradas malintencionadas Como regla general, nunca se debe dar por sentado que la entrada proveniente de los usuarios es segura. A los usuarios malintencionados les resulta fácil enviar información potencialmente peligrosa desde el cliente a la aplicación. Para protegerse contra las entradas malintencionadas, siga estas instrucciones:

En las páginas Web ASP.NET, filtre la entrada de los usuarios para comprobar si existen etiquetas HTML, que pueden contener un script. Para obtener información detallada, vea Cómo: Proteger una aplicación Web frente a ataques mediante secuencias de comandos aplicando codificación HTML a las cadenas. Nunca repita (muestre) entrada de los usuarios sin filtrar. Antes de mostrar información que no sea de confianza, codifique los elementos HTML para convertir cualquier script potencialmente peligroso en cadenas visibles, pero no ejecutables. No almacene nunca información proporcionada por el usuario sin filtrar en una base de datos. Si desea aceptar algún elemento de código HTML de un usuario, fíltrelo manualmente. En el filtro, defina explícitamente lo que aceptará. No cree un filtro que intente eliminar cualquier entrada malintencionada, ya que es muy difícil anticipar todas las posibilidades. No dé por sentado que la información obtenida del encabezado de solicitud HTTP (en el objeto HttpRequest) es segura. Proteja las cadenas de consulta, cookies, etc. Tenga en cuenta que la información que el explorador envía al servidor (información del agente de usuario) puede ser suplantada, en caso de que resulte importante para la aplicación en cuestión. Si es posible, no almacene información confidencial en un lugar accesible desde el explorador, como campos ocultos o cookies. Por ejemplo, no almacene una contraseña en una cookie. Tener acceso seguro a bases de datos Normalmente, las bases de datos tienen sus propios sistemas de seguridad. Un aspecto importante de una aplicación Web protegida es diseñar un modo de que ésta pueda tener acceso a la base de datos de forma segura. Siga estas instrucciones:

Use el sistema de seguridad inherente de la base de datos para limitar quién puede tener acceso a los recursos de dicha base. La estrategia exacta dependerá de la base de datos y de la aplicación: Si resulta viable en la aplicación, use la seguridad integrada de forma que sólo los usuarios autenticados mediante Windows puedan tener acceso a la base de datos. La seguridad integrada es más segura que pasar las credenciales explícitas a la base de datos.

Si la aplicación utiliza el acceso anónimo, cree un único usuario con permisos muy limitados, y haga que las consultas se ejecuten conectándose como dicho usuario. No cree instrucciones SQL concatenando cadenas que contengan información aportada por los usuarios. En su lugar, cree una consulta parame rizada y use la entrada del usuario para establecer los valores de los parámetros. Si debe almacenar un nombre de usuario y su contraseña en algún lugar para utilizarlos como las credenciales de inicio de sesión de la base de datos, almacénelos en el archivo Web.config y asegure el archivo con configuración protegida. Para obtener información detallada, vea Cifrar información de configuración mediante una configuración protegida. Crear mensajes de error seguros Si no se es cuidadoso, un usuario malintencionado puede deducir información importante sobre la aplicación a partir de los mensajes de error que ésta muestra. Siga estas instrucciones: No escriba mensajes de error que presenten información que pudiera resultar útil a los usuarios malintencionados, como un nombre de usuario. Configure la aplicación para que no muestre errores detallados a los usuarios. Si desea mostrar mensajes de error detallados para la depuración, determine primero si quien los recibirá es un usuario local con respecto al servidor Web. Para obtener información detallada, vea Cómo: Mostrar mensajes de error seguros. Utilice el elemento de configuración customErrors para controlar quién ve las excepciones desde el servidor. Cree un sistema de administración de errores personalizado para las situaciones que sean propensas a los errores, como el acceso a las bases de datos. Para obtener más información, vea Control de errores en aplicaciones y páginas ASP.NET. Mantener segura la información confidencial Información confidencial es toda aquella información que se desea conservar privada. Un ejemplo de información confidencial es una contraseña o una clave cifrada. Si un usuario malintencionado consigue llegar a la información confidencial, los datos protegidos se verán expuestos. Siga estas instrucciones: Si la aplicación transmite información confidencial entre el explorador y el servidor, plantéese utilizar el protocolo SSL (Secure Sockets Layer). Para obtener detalles sobre cómo asegurar un sitio con SSL, vea el artículo

Q307267 end ingles, "HOW TO: Secure XML Web Services with Secure Socket Layer in Windows 2000" end Microsoft Knowledge Base en el sitio http://support.microsoft.com. Utilice configuración protegida para proteger la información confidencial en archivos de configuración como los archivos Web.config o Machine.config. Para obtener más información, vea Cifrar información de configuración mediante una configuración protegida. Si debe almacenar información confidencial, no lo haga en una página Web, ni siquiera en un formato que piense que la gente no podrá verlo (por ejemplo, código del servidor). Utilice los algoritmos de cifrado de alta seguridad proporcionados en el espacio de nombres System.Security.Cryptography.