<p>Las actividades que se pueden realizar para hacer las pruebas de seguridad son diversas y se orientan a varios ámbitos, especialmente en lo relativo a asegurar el funcionamiento y disponibilidad de los servicios web y contenidos publicados. En general nos referimos a Sitios Web cuyo contenido es público y que no incluye información estratégica o de seguridad instucional, por este motivo, la correcta configuración de servidores y servicios debe incluir verificación de al menos los siguientes temas:</p>
<ul>
<li><a href="#t03dns">Manejo de DNS</a></li>
<li><a href="#t03estructura">Protección de la Estructura Interna del Sitio Web</a></li>
<li><a href="#t03robots">Protección Contra Robots</a></li>
<li><a href="#t03privacidad">Manejo de Privacidad</a></li>
<li><a href="#t03canalesseg">Canales Seguros</a></li>
<li><a href="#t03acceso">Mecanismos de Control de Acceso</a></li>
<li><a href="#t03protprog">Protección de Programas</a></li>
<li><a href="#t03hosting">Hosting Externo vs. Sitio Propio</a></li>
<li><a href="#t03roles">Roles Mínimos a Asegurar</a></li>
</ul>
<p>A continuación se entrega información para cada uno de ellos.</p>
<h3><a name="t03dns" id="t03dns"></a>Manejo de DNS</h3>
<p>Un aspecto que se debe cuidar es el de utilizar un nombre de dominio adecuado y relacionado con la identidad y misión de la institución. No obstante, gracias a la forma de operación del&nbsp;<strong>Domain Name Service</strong>&nbsp;(DNS o Servicio de Nombre de Dominio) es posible asignar más de un nombre de dominio a un mismo Sitio Web. De esta manera es posible incorporar otras denominaciones, bajo el dominio&nbsp;<strong>.CL</strong>&nbsp;u otro, que permitan generar&nbsp;<strong>alias </strong>adicionales para el sitio y así permitir utilizar las denominaciones más coloquiales con la cual la institución es conocida por los ciudadanos.</p>
<p>No obstante, sin importar cuántos alias tenga un sitio, se recomienda que todos los dominios sean redirigidos para que la primera pantalla, en cualquier caso, corresponda a la portada&nbsp;<strong>oficial</strong>&nbsp;del Sitio Web y que el cada uno de los dominios sea configurado para que responda usando o no la nomenclarura "www".</p>
<p>Ejemplo: si el dominio primario es www.misitio.gob.cl, se pueden configurar ALIAS como misitio.gov.cl; www.misitio.gov.cl; misitio.cl; y www.misitio.cl, en todos estos casos, el dominio debe apuntar y responder siempre redirigiendo al usuario al dominio primario (www.misitio.gob.cl).</p>
<div class="stressed">
<p>Recuerde que sobre los nombres de dominio existe una normativa obligatoria definida en el Oficio No. 485, del 10 de noviembre de 2000, en relación con el Decreto Supremo No. 5996, donde se especifica claramente que los sitios del Estado deben registrar su dominio bajo la denominación&nbsp;<strong>.GOB.CL</strong>&nbsp;y&nbsp;<strong>.GOV.CL</strong>. Adicionalmente pueden hacerlo bajo el dominio&nbsp;<strong>.CL</strong>&nbsp;en forma directa. Dicha operación, en cuanto a procedimientos y alcance, está definida en su totalidad en el sitio&nbsp;<a href="http://nic.gob.cl/" title="Sitio web del Sistema de Información de la jerarquía gov.cl y gob.cl.">http://nic.gob.cl</a>&nbsp;y mayores referencias se pueden encontrar en<a href="http://nic.gob.cl/reglinscr.html" title="Normativa sobre inscripción de sitios gubernamentales en dominios GOB.CL y GOV.CL."> http://nic.gob.cl/reglinscr.html</a>.</p>
</div>
<h3><a name="t03estructura" id="t03estructura"></a>Protección de la Estructura Interna del Sitio Web</h3>
<p>Uno de los mecanismos que permite proteger la estructura interna del sitio (especialmente para casos de intentos de ataques externos y/o intentos de violación de confidencialidad), es disminuir la cantidad de información contenida en las&nbsp;<a href="/glosario/U#/url" title="Ver término en glosario." class="glossaryTerm">URL</a>&nbsp;que se muestran en el programa visualizador. Esto es importante respecto de directorios y nombres de programas, pero especialmente en lo que se refiere a la entrega de parámetros de sesión, datos de usuario u otro mecanismo de transferencia de información entre páginas y/o secciones de código.</p>
<p>Se recomienda que los mecanismos de traspaso de información entre páginas sea a nivel de objetos del servidor, asociados a la sesión, sin que la interacción con el lado cliente deba hacerse responsable de la transferencia de datos y/o información entre sesiones de ejecución del servidor.</p>
<p>De igual forma, se recomienda evitar que el acceso a elementos del servidor web esté asociado a&nbsp;<strong>direccionamientos relativos por sesión</strong>&nbsp;o asociados al&nbsp;<strong>UserId</strong>&nbsp;o&nbsp;<strong>SessionId</strong>; esto se debe a que mediante simples pasos se puede conocer&nbsp;<strong>token</strong>&nbsp;de sesión y gracias a eso simular que es el mismo usuario que regresa al sitio. Para evitar el problema se recomienda incorporar protecciones de dirección relativas a la&nbsp;<a href="/glosario/I#/ip" title="Ver término en glosario." class="glossaryTerm">Dirección IP</a>&nbsp;de origen.</p>
<p>Otro método de protección de estructura interna consiste en deshabilitar (excepto para casos excepcionales, como repositorios públicos de archivos) la navegación sobre directorios mediante el servidor web. Esta protección se hace para todos los directorios desde la configuración del software del servidor web. Otra forma de hacerlo consiste en incorporar un archivo por omisión del servidor web en todos los directorios, aun cuando no sea directamente referenciado por otras páginas para que se muestre su contenido cuando un usuario intente revisar el contenido existente en el directorio. En el caso de habilitar la navegación sobre directorios, se debe evitar el acceso a ciertos directorios protegidos.</p>
<div class="stressed">
<p>Junto con estas protecciones de lectura, se recomienda realizar periódicamente una revisión de los esquemas de permisos otorgados a directorios y archivos. Las permanentes actualizaciones del software de un servidor web, generalmente provocan un problema de control del acceso a nivel de archivos, lo cual requiere procedimientos claros de supervisión.</p>
</div>
<h3><a name="t03robots" id="t03robots"></a>Protección Contra Robots</h3>
<p>No todos los directorios del sitio deben estar disponibles para que los robots de búsqueda (conocidos más popularmente como&nbsp;<strong>arañas</strong>&nbsp;o&nbsp;<strong>spiders</strong>&nbsp;de los buscadores) entren en ellos. Para impedirlo, se debe utilizar el archivo <a href="/glosario/R#/robotstxt" title="Ver término en glosario." class="glossaryTerm">robots.txt</a>&nbsp;o las instrucciones específicas en los&nbsp;<code>meta-tags</code>&nbsp;de la página de inicio, para impedir su ingreso.</p>
<p>El archivo&nbsp;<strong>robots.txt</strong>&nbsp;es un archivo de texto plano (no de HTML) ubicado en directorios el servidor web que contiene instrucciones precisas respecto de qué hacer en ellos. Cada vez que un robot visita un sitio, primero revisa si existe ese archivo.</p>
<p>Si no lo encuentra, indexa la página en el sistema buscador que lo haya enviado; si lo encuentra, analiza su contenido buscando la siguiente información:</p>
<p class="code">User-agent: * disallow: /</p>
<p>La primera línea&nbsp;<code>User-agent</code>&nbsp;indica que es válida para todos los robots que lleguen (porque tiene un asterisco; puede restringirse a un robot, indicando su nombre), mientras que la segunda indica con&nbsp;<code>disallow</code>&nbsp;que no está permitido avanzar por los enlaces de la página ya que&nbsp;<code>/</code>&nbsp;hace referencia a la raíz del sitio.</p>
<p>En otro caso, si se quiere evitar el acceso de todos los robots a un directorio determinado (por ejemplo&nbsp;<strong>cgi-bin</strong>, donde están los archivos más sensibles), se puede indicar esa información de la siguiente manera:</p>
<p class="code">User-agent: * disallow: /cgi-bin/</p>
<p>Adicionalmente se puede usar el commando&nbsp;<code>allow</code>&nbsp;que permite incluir directorios específicos, gracias a lo cual ciertos contenidos sí son indexados. Por ejemplo:</p>
<p class="code">User-agent: * disallow: /imagenes/ allow: /imagenes/logotipo-institucion.jpg</p>
<p>En este caso la segunda línea indica con&nbsp;<code>disallow</code>&nbsp;que no está permitido ingresar al directorio de&nbsp;<code>imagenes</code>, pero que sí se puede indexar un archivo específico, que corresponde al Logotipo institucional.</p>
<p>Otra forma de impedir el acceso de un robot es poniendo marcadores específicos en los&nbsp;<code>meta-tags</code>&nbsp;de las páginas. No obstante, este mecanismo no es soportado por todos los robots, por lo que su alcance es más limitado.</p>
<p>La forma precisa de incluir dicho&nbsp;<strong>meta-tag</strong>&nbsp;es la siguiente:</p>
<p class="code">&lt;html&gt; &lt;head&gt; &lt;meta name="robots" content="noindex,nofollow"&gt; &lt;meta name="description" content="Este sitio...."&gt; &lt;title&gt;...&lt;/title&gt; &lt;/head&gt; &lt;body&gt;</p>
<div id="suprobots" class="supplement">
<h3>Más información en:</h3>
<ul>
<li><a href="http://www.robotstxt.org/wc/robots.html" title="Información general sobre el estándar robots.txt.">http://www.robotstxt.org/wc/robots.html</a></li>
</ul>
</div>
<p>Las cuatro posibles combinaciones de este&nbsp;<strong>meta-tag</strong>&nbsp;son las siguientes:</p>
<dl><dt><code>&lt;meta name="robots" content="index,follow"&gt;</code></dt><dd>Indica que la página puede ser indexada y sus enlaces seguidos</dd><dt><code>&lt;meta name="robots" content="index,nofollow"&gt;</code></dt><dd>Indica que la página puede ser indexada, pero sus enlaces no pueden ser seguidos</dd><dt><code>&lt;meta name="robots" content="noindex,follow"&gt;</code></dt><dd>Indica que la página no puede ser indexada, pero sus enlaces pueden ser seguidos</dd><dt><code>&lt;meta name="robots" content="noindex,nofollow"&gt;</code></dt><dd>Indica que la página no puede ser indexada ni sus enlaces seguidos</dd></dl>
<h3><a name="t03privacidad" id="t03privacidad"></a>Manejo de Privacidad</h3>
<p>Mantener la privacidad de los usuarios debe ser un objetivo permanente del sitio. Para ello se requiere de contar con una Política de Privacidad formal y explícita en el sitio y, además, deben existir mecanismos de seguridad concretos para proteger los datos de sus usuarios.</p>
<p>Entre estos, se debe contar con protecciones físicas y lógicas sobre dicha información.</p>
<p>En el caso de disponer de arquitecturas multicapas reales, se recomienda proteger la información de clientes en servidores físicos distintos de almacenamiento de datos, incluyendo interfaces idealmente separadas de consulta de datos. Además, incorporar mecanismos de&nbsp;<a href="/glosario/E#/encriptacion" title="Ver término en glosario." class="glossaryTerm">encriptación</a>&nbsp;de los datos para información sensible.</p>
<p>Se recomienda que la información, si es almacenada para efectos de que los usuarios la recuperen desde el Sitio Web, sea encriptada con claves administradas por ellos mismos (por ejemplo, su clave de&nbsp;<a href="/glosario/A#/autenticacion" title="Ver término en glosario." class="glossaryTerm">autenticación</a> (identificación) frente al sitio).</p>
<p>Una decisión de arquitectura que disminuye el riesgo de robo de información de clientes o cuentas de acceso, consiste en evitar que desde la Base de Datos sea posible generar parejas UserId/Clave que permitan autenticarse frente al sitio. La forma de hacerlo es incorporar mecanismos que almacenen un valor de índice de la clave en la Base de Datos, en vez de almacenar la clave propiamente tal. Gracias a esto, cuando un cliente se autentica frente al sitio, la comparación de claves se realiza sobre los valores de índice y se evita conocer directamente esa información.</p>
<p>Es importante destacar además que un buen diseño de los mecanismos de autenticación junto con mecanismos de auditoría, almacenamiento y recuperación posterior, son adecuados para la implementación de la&nbsp;<strong>Firma Electrónica Simple</strong>, requisito definido como suficiente para múltiples interacciones del Estado, de acuerdo con la&nbsp;<strong>Ley 19.799</strong>&nbsp;y su reglamento (analizar recomendaciones asociadas al&nbsp;<a href="/documentos-oficiales#recurso-142" title="[PDF] Reglamento de Ley 19.799 sobre Documentos Electrónicos." class="file pdf">Uso del Documento y Firma Electrónica al interior del Sector Público</a>&nbsp;[PDF; 127Kb]).</p>
<p>Finalmente, se recomienda un control particular de todos los procesos de respaldo, recargas, manejo de medios removibles y generación de copias de información, por ser mecanismos internos de fugas o compromiso de confidencialidad de la información.</p>
<h3><a name="t03canalesseg" id="t03canalesseg"></a>Canales Seguros</h3>
<p>Es importante incorporar mecanismos de encriptación del canal de comunicaciones (como el protocolo&nbsp;<a href="/glosario/S#/ssl" title="Ver término en glosario." class="glossaryTerm">Secure Socket Layer</a>&nbsp;o&nbsp;<acronym title="Secure Socket Layer" lang="en">SSL</acronym>), para la transferencia de información privada entre los usuarios y el Sitio Web, a través de la red Internet. Hacerlo no requiere de programación adicional a las funcionalidades de interacción, y asegura la protección de toda la información intercambiada entre el servidor y los usuarios.</p>
<p>Desde un punto de vista de desempeño, si bien el inicio (<strong>hand shaking</strong>) del proceso de establecimiento del canal&nbsp;<strong>SSL</strong>&nbsp;puede significar un pequeño retardo en la conexión inicial, posteriormente no provoca un aumento significativo del ancho de banda utilizado en la conexión, ni tampoco obliga a un aumento significativo de recursos del servidor.</p>
<div class="stressed">
<p>Es importante considerar que la seguridad asignada a un Sitio Web debe ser correspondiente con la inversión y la importancia de los datos almacenados, siendo estas capacidades obligatorias para el caso de los sitios transaccionales.</p>
</div>
<h3><a name="t03acceso" id="t03acceso"></a>Mecanismos de Control de Acceso</h3>
<p>Otro aspecto que genera mejoras en la protección de la privacidad de los usuarios y de la información contenida en el Sitio Web, es la incorporación de mecanismos modernos de generación de claves y autenticación, como los que se plantean a continuación.</p>
<dl><dt>Firma Electrónica Simple y Avanzada:</dt><dd>es un sistema que identifica al usuario cuando realiza trámites a través de Internet o redes cerradas. Existe una ley y el correspondiente reglamento que la regula y empresas que las ofrecen en el mercado (más información en&nbsp;<a href="http://www.entidadacreditadora.cl/" title="Sitio web de la Entidad Acreditadora de Firma Electrónica.">http://www.entidadacreditadora.cl</a>). Ambas firmas constituyen las bases legales para que ciudadanos y empresas puedan identificarse virtualmente y de esa manera enviar comunicación y hacer negocios de manera más segura y confiable. Se trata de un mecanismo de complejidad media, aunque incluye funcionalidades de seguridad y criptografía. No obstante, la incorporación de este mecanismo en forma única dependerá del control absoluto que se tenga de la comunidad de usuarios de la solución. Para comunidades abiertas es preferible establecer dos mecanismos de autenticación: uno fuerte, mediante Firma Electrónica (usando certificados digitales) y otro, mediante autenticación de Usuario y Clave. Por otro lado, la Firma Electrónica Simple podría ser usada para las comunicaciones oficiales enviadas por la institución a sus usuarios. El uso de la Firma Electrónica debe definirse al momento de determinar la arquitectura de solución del Sitio Web.</dd><dt>Autenticación con par Usuario y Clave:</dt><dd>si se emplea esta solución, debe existir un procedimiento concreto para los casos en que un usuario pierda o no recuerde su clave. Se recomienda ofrecer mecanismos de<strong>regeneración de clave</strong>, mediante la entrega de respuestas a preguntas predefinidas por los usuarios, en lugar de hacer el&nbsp;<strong>envío de la clave por e-mail</strong>&nbsp;. En el caso de contar con mecanismos de Ayuda, se debe ofrecer apoyo para la regeneración de las claves, sin que el personal de la institución tenga acceso a la información de seguridad del cliente. Se debe evitar el uso de mecanismos de autenticación administrados por terceros, en caso de que puedan comprometer la confidencialidad o la suplantación del usuario.</dd><dt>Sistemas de Hardware para Autentificación:</dt><dd>para sistemas de seguridad que requieren una autenticación absoluta del usuario, es preferible considerar mecanismos de autenticación fuerte. Para ello, se deben incorporar mecanismos que incluyan elementos de hardware que deben estar en posición del usuario, tales como tarjetas u otros similares (security token) que permiten el acceso a las áreas de autenticación. Allí el usuario debe ingresar su identificación de Usuario (security challenge response) y se le genera una clave de sesión que al ser digitada en pantalla, le permite acceder al sistema. Dicha clave cambia frecuentemente para aumentar la seguridad de acceso.</dd></dl>
<h3><a name="t03protprog" id="t03protprog"></a>Protección de Programas</h3>
<p>Es fundamental proteger los códigos y programas internos del servidor web, particularmente evitando la transferencia de parámetros o información a través de la dirección de acceso a las páginas (por ejemplo, al usar el método&nbsp;<code>GET</code>&nbsp;para la entrega de parámetros), los cuales son mecanismos frecuentes de&nbsp;<strong>hackeo</strong>&nbsp;o robo de información.</p>
<p>De igual forma, se debe evitar la lectura de ejecutables desde los directorios del servidor, controlando los permisos adecuados de acceso a éstos, con el fin de evitar desensamblaje y/o ingeniería reversa para analizar accesos internos.</p>
<p>En cuanto a los&nbsp;<strong>scripts</strong>&nbsp;ubicados en el lado del cliente, en caso de ser críticos, se recomienda utilizar compactadores de código y eliminar documentación de apoyo que permita su fácil comprensión a partir de la lectura del código.</p>
<p>Es importante que estas medidas sean incluidas junto a las acciones de seguridad informática normales de la institución.</p>
<h3><a name="t03hosting" id="t03hosting"></a>Hosting Externo vs. Sitio Propio</h3>
<p>Sin entrar en profundidad en cuanto al detalle de los elementos a considerar para esta decisión, la principal recomendación es hacer una evaluación objetiva basada en los siguientes aspectos:</p>
<ul>
<li>Evaluar las reales capacidades disponibles para la operación permanente del sitio, desde un punto de vista técnico.</li>
<li>Evaluar los requerimientos de control y seguridad necesarios.</li>
<li>Evaluar el nivel de soporte efectivo que el personal técnico del servicio puede realizar sobre los servidores.</li>
</ul>
<p>Con estos parámetros se debe definir la mejor opción, no sólo desde el punto de vista del interés de las áreas técnicas, sino que mediante una evaluación de impacto global de la decisión asociada.</p>
<p>La amplia oferta disponible permite realizar combinaciones de servicios e infraestructura de muy diversos tipos, lo cual facilita configurar una solución óptima en términos del costobeneficio asociado (por ejemplo, hosting compartido, dedicado, collocation, housing, red administrada, monitoreo de seguridad, administración de seguridad perimetral, control de aplicaciones, fulfillment, etc.).</p>
<p>En caso de que se decida externalizar esta área, es importante contar con altos estándares de parte del proveedor en todo lo referido a tiempo de desempeño (<strong>uptime</strong>), respaldos y recuperación, actualizaciones de software, etc.</p>
<h3><a name="t03roles" id="t03roles"></a>Roles Mínimos a Asegurar</h3>
<p>Un último aspecto considerado en esta área de recomendaciones, consiste en definir los diversos roles profesionales dentro de la definición y diseño de un Sitio Web para una institución.</p>
<p>Desde un punto de vista exclusivamente técnico, es fundamental considerar al menos los siguientes roles, identificando tanto sus responsabilidades como el personal más competente que pueda cumplirlos.</p>
<p>Si bien más de uno de estos roles funcionales puede ser desarrollado simultáneamente por una persona o área de la organización, es importante que dichas áreas sean cubiertas no sólo durante la puesta en marcha de la solución sino también durante su etapa de producción.</p>
<dl><dt>Arquitecto:</dt><dd>encargado de hacer las configuraciones de trabajo de los servidores y aplicaciones.</dd><dt>Administrador de Aplicaciones:</dt><dd>encargado del funcionamiento del software operativo.</dd><dt>Administrador de Control de Calidad:</dt><dd>encargado del cumplimiento de las políticas de calidad.</dd><dt>Administrador de Seguridad:</dt><dd>encargado de hacer generar y hacer cumplir las directivas de seguridad.</dd><dt>Administrador de Operaciones:</dt><dd>encargado de los aspectos operativos relacionados con el hardware.</dd><dt>Administrador de Contenidos:</dt><dd>encargado de las informaciones contenidas en el Sitio Web.</dd><dt>Administrador de HelpDesk y Soporte:</dt><dd>encargado de dar soporte a usuarios sobre las funcionalidades del Sitio Web.</dd><dt>Administrador de Contingencias:</dt><dd>encargado de enfrentar en primera línea los problemas que se generen en la operación.</dd><dt>Auditor / Contralor:</dt><dd>encargado de llevar registro de las operaciones realizadas, con el fin de apoyar la revisión de procedimientos.</dd></dl>
<p>Finalmente, aunque los roles del área Informática pueden estar muy claros, es necesario que se entienda que la operación del Sitio Web es una tarea conjunta en la que participan funcionarios de diversas áreas de la institución.</p>