Seguridad en los datos vía Internet
Estoy desarrollando una tienda virtual, ya se que mi seguridad será con IIS, pero exactamente no se cómo se realizará esto, ¿es decir cuando me pregunten cómo será la seguridad en los datos? Ahí exactamente ahí estoy un poco perdid@, puede ayudarme
1 respuesta
Respuesta de luzbel6666
1
Claro amigo estoy a tu ordenes:
Esto que te mando es por si piensas utilizar el IIS ver5
Un poco de teoría
La criptografía es una disciplina compleja en la que se halla involucrada una enorme cantidad de matemática. En resumen, el objetivo de las técnicas criptográficas es codificar mensajes de manera que cuando estos tienen que transmitirse por medios de comunicación no resistentes a intrusiones, sólo puedan ser interpretados (desencriptados) por el interlocutor, que conocerá las técnicas para deshacer la codificación llevada a cabo por el originador del mensaje. El mensaje que se encripta, y que en adelante denominaremos cifrado, no tiene porque contener texto ASCII exclusivamente, sino que puede ser un archivo binario de bases de datos, o cualquier otra información.
Cuando se encripta un mensaje en las técnicas de encriptación utilizadas en el ámbito de este artículo, se utiliza una determinada llave criptográfica que debe ser conocida por el destinatario del mensaje para proceder a su desencriptación. De este modo, los mecanismos, esto es, los algoritmos de encriptación/desencriptación, son del dominio público, con lo que cualquier desarrollador o empresa puede generar programas que lleven a cabo las tareas citadas. En resumen, si no dispongo de la llave (en adelante clave), no puedo abrir el mensaje cifrado que aparecerá como un galimatías sin ningún sentido. De esta manera, existen dos claves: la utilizada por el remitente para cifrar el mensaje, y la utilizada por el destinatario para descifrarlo. Las claves del destinatario y el remitente pueden ser diferentes o iguales. Cuando son iguales, decimos que el algoritmo de encriptación es simétrico, mientras que cuando son diferentes decimos que son asimétricos o de clave pública. Los primeros son más eficientes desde el punto de vista de rapidez del proceso pero resultan más difíciles de usar por su falta de flexibilidad. Si utilizásemos algoritmos simétricos en las transmisiones web deberíamos distribuir a todos los potenciales receptores una clave secreta, algo prácticamente inabordable. Es por ello que los más utilizados en es este ámbito son los algoritmos asimétricos.
Para que todo lo anterior tenga sentido, es necesario que el destinatario y el remitente del mensaje se conozcan entre sí inequívocamente, o de otro modo, que la identidad del propietario de la clave pública pueda ser conocida sin ninguna duda. Es decir, es preciso que se produzca una conexión autentificada en la que el intercambio de las claves pueda llevarse a cabo.
Evidentemente, este el segundo punto flaco de nuestra comunicación y Windows 2000 Certificate Services vienen en nuestro auxilio para permitirnos solventar los problemas. El servidor, que adopta el papel de la autoridad de certificación (CA Certification Authority) tiene el papel de otorgar certificados de autenticidad a los participantes en una comunicación a través del web en la que se transfieren claves públicas. Estos certificados (Digital Certificates) son los que dan precisamente su nombre al servidor.
Los certificados son expedidos por autoridades certificadoras reconocidas por los dos sujetos de la comunicación. Un ejemplo de autoridad certificadora es Verisign, pero cualquier servidor Windows que tenga instalados Certificate Services está facultada para crear certificados digitales.
La autoridad certificadora crea certificados que identifican al sujeto de la comunicación, una vez se comprueba su identidad. Los certificados incluyen la clave pública. Una vez el certificado ha sido creado, el sujeto certificado podrá enviar el mensaje que desee, cifrado con su clave privada, y paralela o previamente, enviará o pondrá a disposición del destinatario un certificado con su clave pública con la que podrá descifrar el mensaje.
IIS 5 incorpora un conjunto de tecnologías en las que se utiliza encriptación y certificados que no voy a comentar de manera exhaustiva, sino en sus aspectos más reseñables, y que hacen más seguro a Windows 2000.
Protocolos
En este ámbito IIS soporta dos protocolos: SSL 3.0 y TLS (Transport Layer Security). El primero de ellos es el empleado para encriptar páginas web utilizando certificados, y es comúnmente conocido y utilizado desde IIS 4. En cuanto a TLS, se basa en SSL, y es empleado para encriptaciones a nivel más bajo que el de aplicación, es decir, por debajo del HTTP utilizado para la visualización de las páginas Web.
Certificados
Los certificados digitales son una especie de DNI digitales que permiten identificar de manera inequívoca bien al cliente, bien al servidor en las comunicaciones entre ellos. SSL, PKCS #7 y PKCS#10, son protocolos en los que se utiliza de una u otra manera los certificados digitales. Los certificados suelen incluir información sobre nuestra compañía y la que generó el certificado, la autoridad certificadora.
Modos de validación
Además de la autentificación Windows y la autentificación básica ya conocidas y utilizadas en IIS 4, IIS 5 incorpora un nuevo método de autentificación denominado Digest Authentication.
Una de las principales carencias de IIS 4 radicaba en la existencia de sólo dos métodos de autenticación: Basic Authentication y Windows NT Challenge Response. La primera de ellas enviaba el nombre del usuario y su contraseña como texto sin encriptar en el proceso de autentificación. El segundo, por su parte, exigía de la utilización de Internet Explorer y, además era un auténtico infierno cuando debía utilizarse en servidores web ubicados en el interior de una red corporativa que se conectaba a Internet a través de un cortafuegos o proxy inverso. La idea es que, o perdíamos seguridad, o perdíamos flexibilidad.
IIS 5 incorpora un nuevo tipo de autentificación: Digest, que utiliza algoritmos de hashing para encriptar la contraseña pero que funciona a través de proxies y que sólo requiere que el navegador sea compatible HTTP 1.1.
Aunque no me lo pediste te mando este extra por si vas a trabajar con sQL He aquí un resumen de los pasos que puede llevar a cabo para optimizar la seguridad y la conectividad de SQL Server:
1. Utilice con SQL Server únicamente la autentificación de Windows.
2. Emplee conexiones de confianza en lugar de cadenas que pasen los nombres de usuario y las contraseñas de SQL Server.
3. Coloque los objetos de conexión en archivos DLL y ubíquelos en Microsoft Transaction Server (MTS).
4. Si está utilizando ADO, establezca el código para que utilice OLE DB en lugar de ODBC. Con ADO, ODBC llama a OLE DB, así que utilizar directamente OLE DB mejora el rendimiento al eliminar una capa de proceso.
5. Si IIS y SQL Server se encuentran en equipos diferentes, utilice TCP/IP entre los equipos que ejecutan estas aplicaciones, en lugar de los conductos con nombre que se utilizan de manera predeterminada. Como indica el artículo de Microsoft «PRB: 80004005 ConnectionOpen (CreateFile()) Error Accessing SQL», que puede encontrarse en la dirección http://support.microsoft.com/support/kb/articles/q175/6/71.asp, «cuando se utilizan conductos con nombre (named pipes) para acceder a SQL Server, IIS intenta suplantar al usuario autentificado, pero no tiene la capacidad necesaria para probar su identidad».
6. Coloque las conexiones y las llamadas a procedimientos almacenados en archivos DLL codificados con Visual Basic (VB), instálelos en MTS, que agrupará las conexiones automáticamente, y cree objetos de servidor en VBSCript para que utilicen las conexiones.
7. Si necesita ayuda a la hora de utilizar código basado en ADO para comunicarse con SQL Server, pregunte al departamento de Microsoft correspondiente. El servicio de soporte técnico de Microsoft también dispone de expertos en conexiones entre ADO y SQL Server, además de expertos en IIS y SQL Server.
Esto que te mando es por si piensas utilizar el IIS ver5
Un poco de teoría
La criptografía es una disciplina compleja en la que se halla involucrada una enorme cantidad de matemática. En resumen, el objetivo de las técnicas criptográficas es codificar mensajes de manera que cuando estos tienen que transmitirse por medios de comunicación no resistentes a intrusiones, sólo puedan ser interpretados (desencriptados) por el interlocutor, que conocerá las técnicas para deshacer la codificación llevada a cabo por el originador del mensaje. El mensaje que se encripta, y que en adelante denominaremos cifrado, no tiene porque contener texto ASCII exclusivamente, sino que puede ser un archivo binario de bases de datos, o cualquier otra información.
Cuando se encripta un mensaje en las técnicas de encriptación utilizadas en el ámbito de este artículo, se utiliza una determinada llave criptográfica que debe ser conocida por el destinatario del mensaje para proceder a su desencriptación. De este modo, los mecanismos, esto es, los algoritmos de encriptación/desencriptación, son del dominio público, con lo que cualquier desarrollador o empresa puede generar programas que lleven a cabo las tareas citadas. En resumen, si no dispongo de la llave (en adelante clave), no puedo abrir el mensaje cifrado que aparecerá como un galimatías sin ningún sentido. De esta manera, existen dos claves: la utilizada por el remitente para cifrar el mensaje, y la utilizada por el destinatario para descifrarlo. Las claves del destinatario y el remitente pueden ser diferentes o iguales. Cuando son iguales, decimos que el algoritmo de encriptación es simétrico, mientras que cuando son diferentes decimos que son asimétricos o de clave pública. Los primeros son más eficientes desde el punto de vista de rapidez del proceso pero resultan más difíciles de usar por su falta de flexibilidad. Si utilizásemos algoritmos simétricos en las transmisiones web deberíamos distribuir a todos los potenciales receptores una clave secreta, algo prácticamente inabordable. Es por ello que los más utilizados en es este ámbito son los algoritmos asimétricos.
Para que todo lo anterior tenga sentido, es necesario que el destinatario y el remitente del mensaje se conozcan entre sí inequívocamente, o de otro modo, que la identidad del propietario de la clave pública pueda ser conocida sin ninguna duda. Es decir, es preciso que se produzca una conexión autentificada en la que el intercambio de las claves pueda llevarse a cabo.
Evidentemente, este el segundo punto flaco de nuestra comunicación y Windows 2000 Certificate Services vienen en nuestro auxilio para permitirnos solventar los problemas. El servidor, que adopta el papel de la autoridad de certificación (CA Certification Authority) tiene el papel de otorgar certificados de autenticidad a los participantes en una comunicación a través del web en la que se transfieren claves públicas. Estos certificados (Digital Certificates) son los que dan precisamente su nombre al servidor.
Los certificados son expedidos por autoridades certificadoras reconocidas por los dos sujetos de la comunicación. Un ejemplo de autoridad certificadora es Verisign, pero cualquier servidor Windows que tenga instalados Certificate Services está facultada para crear certificados digitales.
La autoridad certificadora crea certificados que identifican al sujeto de la comunicación, una vez se comprueba su identidad. Los certificados incluyen la clave pública. Una vez el certificado ha sido creado, el sujeto certificado podrá enviar el mensaje que desee, cifrado con su clave privada, y paralela o previamente, enviará o pondrá a disposición del destinatario un certificado con su clave pública con la que podrá descifrar el mensaje.
IIS 5 incorpora un conjunto de tecnologías en las que se utiliza encriptación y certificados que no voy a comentar de manera exhaustiva, sino en sus aspectos más reseñables, y que hacen más seguro a Windows 2000.
Protocolos
En este ámbito IIS soporta dos protocolos: SSL 3.0 y TLS (Transport Layer Security). El primero de ellos es el empleado para encriptar páginas web utilizando certificados, y es comúnmente conocido y utilizado desde IIS 4. En cuanto a TLS, se basa en SSL, y es empleado para encriptaciones a nivel más bajo que el de aplicación, es decir, por debajo del HTTP utilizado para la visualización de las páginas Web.
Certificados
Los certificados digitales son una especie de DNI digitales que permiten identificar de manera inequívoca bien al cliente, bien al servidor en las comunicaciones entre ellos. SSL, PKCS #7 y PKCS#10, son protocolos en los que se utiliza de una u otra manera los certificados digitales. Los certificados suelen incluir información sobre nuestra compañía y la que generó el certificado, la autoridad certificadora.
Modos de validación
Además de la autentificación Windows y la autentificación básica ya conocidas y utilizadas en IIS 4, IIS 5 incorpora un nuevo método de autentificación denominado Digest Authentication.
Una de las principales carencias de IIS 4 radicaba en la existencia de sólo dos métodos de autenticación: Basic Authentication y Windows NT Challenge Response. La primera de ellas enviaba el nombre del usuario y su contraseña como texto sin encriptar en el proceso de autentificación. El segundo, por su parte, exigía de la utilización de Internet Explorer y, además era un auténtico infierno cuando debía utilizarse en servidores web ubicados en el interior de una red corporativa que se conectaba a Internet a través de un cortafuegos o proxy inverso. La idea es que, o perdíamos seguridad, o perdíamos flexibilidad.
IIS 5 incorpora un nuevo tipo de autentificación: Digest, que utiliza algoritmos de hashing para encriptar la contraseña pero que funciona a través de proxies y que sólo requiere que el navegador sea compatible HTTP 1.1.
Aunque no me lo pediste te mando este extra por si vas a trabajar con sQL He aquí un resumen de los pasos que puede llevar a cabo para optimizar la seguridad y la conectividad de SQL Server:
1. Utilice con SQL Server únicamente la autentificación de Windows.
2. Emplee conexiones de confianza en lugar de cadenas que pasen los nombres de usuario y las contraseñas de SQL Server.
3. Coloque los objetos de conexión en archivos DLL y ubíquelos en Microsoft Transaction Server (MTS).
4. Si está utilizando ADO, establezca el código para que utilice OLE DB en lugar de ODBC. Con ADO, ODBC llama a OLE DB, así que utilizar directamente OLE DB mejora el rendimiento al eliminar una capa de proceso.
5. Si IIS y SQL Server se encuentran en equipos diferentes, utilice TCP/IP entre los equipos que ejecutan estas aplicaciones, en lugar de los conductos con nombre que se utilizan de manera predeterminada. Como indica el artículo de Microsoft «PRB: 80004005 ConnectionOpen (CreateFile()) Error Accessing SQL», que puede encontrarse en la dirección http://support.microsoft.com/support/kb/articles/q175/6/71.asp, «cuando se utilizan conductos con nombre (named pipes) para acceder a SQL Server, IIS intenta suplantar al usuario autentificado, pero no tiene la capacidad necesaria para probar su identidad».
6. Coloque las conexiones y las llamadas a procedimientos almacenados en archivos DLL codificados con Visual Basic (VB), instálelos en MTS, que agrupará las conexiones automáticamente, y cree objetos de servidor en VBSCript para que utilicen las conexiones.
7. Si necesita ayuda a la hora de utilizar código basado en ADO para comunicarse con SQL Server, pregunte al departamento de Microsoft correspondiente. El servicio de soporte técnico de Microsoft también dispone de expertos en conexiones entre ADO y SQL Server, además de expertos en IIS y SQL Server.
