Tarsis.net — Agencia Web y Marketing Digital — Tel: (+34) 911 413 259 EN

Tarsis.net › Agencia Web y Marketing Digital

Securización de una intranet

Tarsis.net

Una de las cosas que se aprenden con la experiencia de años de diseñar, poner en marcha, hacer crecer y mantener intranets –o quizá sería más correcto decir herramientas privadas de colaboración empresarial— es que la seguridad debe ser un elemento presente desde el minuto uno. No vale acordarse de ella a posteriori, y no se pueden tomar atajos.

Para el usuario común, que utiliza servicios Internet de diferentes proveedores ya sea a través de su navegador o de aplicaciones móviles, la seguridad es algo que tiene que ver principalmente con cómo utiliza sus claves de acceso y, quizá, con mantener actualizado su sistema operativo y aplicaciones.

El panorama para los que administramos sistemas es muy diferente. Un examen rutinario del tráfico que atrae nuestro sistema revela información interesante –y a veces terrible– sobre el origen e intenciones de los visitantes. Los ataques contra sistemas son una circunstancia permanente, no episodios aislados. Cualquier sistema conectado a Internet es atacado de forma automatizada y de manera frecuente y permanente.

Pero, dejando aparte los numerosos ataques automáticos –generalmente poco sofisticados y dirigidos a sistemas mal configurados y gestionados–, hay también ataques menos frecuentes, más refinados, y que aspiran a ganar un acceso permanente y silencioso a un sistema en producción, a exfiltrar información valiosa y, finalmente, a dañar la reputación de la organización titular del sistema.

A nadie se le puede escapar que una intranet, que alberga información interna de una empresa referente a sus operaciones del día a día, pero que también puede alojar información estratégica, datos de clientes, de empleados y de proveedores, es por su propia naturaleza un blanco en el que se posan muchas miradas. Por tanto, la seguridad de la instalación debe formar parte de la misma desde su concepción.

La seguridad de un sistema es un concepto que tiene muchas facetas. Un sistema puede ser atacado de muchas formas distintas, a diferentes niveles de la pila de comunicación (¿alguien se acuerda del Modelo OSI?), y por esa razón las medidas que hay que adoptar tienen que cubrir un amplio espectro de posibles tipos de vulnerabilidad. El funcionamiento del sistema puede ser comprometido desde usando fuerza bruta (p. ej. utilizando un ataque de denegación de servicio, DoS o DDoS), hasta mediante el descubrimiento de una clave de usuario demasiado débil y, entre medias, a través de una miríada de posibles puntos débiles de los que es necesario ser consciente en todo momento.

Sin pretender hacer un recuento exhaustivo, sirvan de referencia diferentes elementos importantes que van a entrar en juego cuando se trata de asegurar una intranet:

  • Sistema operativo, que debe estar siempre actualizado a la última versión estable.
  • Configuración. Configuración correcta del sistema operativo y servicios del servidor.
  • Asignación de recursos. El servidor tiene que estar dimensionado para hacer frente a los picos de demanda de los usuarios de la intranet.
  • Filtrado de tráfico. Elementos de filtrado de tráfico (IP, UDP, ICMP), medidas de mitigación de ataques de denegación de servicio.
  • Orígenes de contenido. Configuración correcta de orígenes de tráfico (Content Security Policy), en el caso de servicios web, para impedir la inyección de código hostil desde orígenes no deseados (XSS, Cross-site scripting).
  • Aplicaciones. Medidas de seguridad de aplicación, que impiden que un usuario, autenticado o no, pueda utilizarla para ejecutar código en el servidor, incluida la posibilidad de exfiltración de datos.
  • Claves. Políticas de claves de usuarios (longitud, composición, periodo de validez). Una medida completamente básica y, sin embargo, ampliamente desatendida. También es importante educar a los usuarios para evitar malas prácticas en la custodia de claves, como por ejemplo apuntarlas en post-it a la vista de todo el mundo o compartir la clave con otra persona. Es necesario también hacerles conscientes de la posibilidad de que sean abordados por alguien malintencionado que practique sobre ellos la ingeniería social, para ganar acceso a sus cuentas (por ejemplo, pero no sólo, mediante la técnica conocida como spear phising).
  • ACL. Mecanismos de control de acceso a los contenidos (ACL, Access Control Lists), que autorizan/niegan acceso a según que parte de la intranet en función de quién sea el usuario y los permisos que tenga.
  • API. Es posible también que, dependiendo de la plataforma que hayamos utilizado como base de nuestra intranet, tengamos también que tomar medidas para asegurar la API (Application Program Interface) con la que están dotadas muchas de ellas.
  • Datos. Seguridad de los datos, que deben ser frecuentemente salvaguardados de una forma completa y segura, para el caso en que se produzca una situación de desastre. Piénsese que el software es reemplazable, pero los datos no lo son.
  • Plan de contingencia. ¿Qué vamos a hacer si el sistema tienen una caída grave? ¿Podremos reemplazar sus subsistemas más prioritarios? ¿Tenemos copia de seguridad de los datos? ¿En cuánto tiempo podemos restaurar el servicio y por qué medios?

A pesar de que siempre hay que tomar estas medidas, nunca tendremos la completa seguridad de que no pueda ocurrir algo: malas prácticas o errores humanos, vulnerabilidades no públicas (zero-day) o errores de hardware son posibilidades siempre presentes, y hay que estar en situación de hacerlas frente, porque el trabajo de una organización depende de ello.

Precisamente por eso la vigilancia permanente de administrador es el colofón a todas las medidas que se adopten. No es suficiente con que las medidas estén implantadas, porque existen situaciones en las que esas medidas van a verse desbordadas. La monitorización de los registros de las diferentes partes del sistema para asegurarnos de que el conjunto está funcionando como debe es siempre imprescindible.

Podemos ayudarle. Si su empresa puede beneficiarse con la creación de una intranet/extranet corporativa, contacte con nosotros y estudiaremos su caso, sin compromiso.

Cómo adaptar nuestra web al nuevo Reglamento General de Protección de Datos

Tarsis.net

El Reglamento General de Protección de Datos que entra en vigor el 25 de mayo está siendo un dolor de cabeza para muchos administradores de sitios web que no saben ni por dónde empezar. Afortunadamente, no es tan difícil adaptar nuestro sitio web al nuevo RGPD si prestamos atención a un par de puntos clave.

Pensando frente al ordenador

Foto de NordWood Themes en Unsplash

Para muchas pequeñas empresas o microempresas que tienen recursos limitados, tener que prestar atención al nuevo Reglamento General de Protección de Datos distrae su atención de otras tareas de negocio, más perentorias o rentables. Hay muchos aspectos de la empresa que hay que adaptar al nuevo RGPD, pero, como por algo hay que empezar, hoy vamos a proponer a nuestros lectores que se centren en su sitio web. Es lo más sencillo y nos aportará optimismo para seguir con el resto.

Como cada adaptación depende de las peculiaridades de cada empresa, repetimos: en este artículo hablaremos sólo del sitio web, no de otros procesos. Así que no olvide leerse el Reglamento por si tiene usted que hacer algo más.

Para ir abriendo boca…

… vayamos por partes. Lo primero es hacernos con el texto del Reglamento, cuyo título completo es “Reglamento (UE) 2016/679 del Parlamento Europeo y del Consejo, de 27 de abril de 2016, relativo a la protección de las personas físicas en lo que respecta al tratamiento de datos personales y a la libre circulación de estos datos y por el que se deroga la Directiva 95/46/CE (Reglamento general de protección de datos)”. En algunos sitios veremos que se refieren a él por sus siglas en inglés GDPR o General Data Protection Regulation.

Después de adoptar un rictus de disgusto tras ver que se compone de nada menos que 88 páginas, nos olvidaremos de todo excepto de adaptar nuestro sitio web, y nos dirigiremos directamente a la Sección 2, Artículo 13: Información que deberá facilitarse cuando los datos personales se obtengan del interesado.

¿Por qué nos debe interesar este artículo antes que cualquier otro? Porque nuestro sitio web, si es como la mayoría, tendrá un formulario de contacto y puede que además, en el caso de una tienda, un formulario para darse de alta como comprador. En cualquiera de los casos lo más probable es que la intención sea obtener los datos del interesado, y no que alguien introduzca los datos de una tercera persona. Si su caso es diferente, entonces tendrá que seguir en el Artículo 14.

Ahora bien: el reglamento, en el Artículo 6, nos indica cuál es un tratamiento lícito de los datos, y por lo tanto en qué casos podemos, como empresa o autónomo, tratar datos personales de los visitantes a nuestra web (o de otras fuentes). Para que el tratamiento de los datos sea lícito debe cumplir al menos una de las condiciones impuestas por el Artículo 6, pero para nuestro propósito vamos a dar por hecho que se cumple una de las dos primeras, que son:

a) el interesado dio su consentimiento para el tratamiento de sus datos personales para uno o varios fines específicos;
b) el tratamiento es necesario para la ejecución de un contrato en el que el interesado es parte o para la aplicación a petición de este de medidas precontractuales.

Si no fuera ese su caso, consulte la ley para ver en qué punto o puntos se puede amparar.

Ahora nos concentraremos en los dos elementos que vamos a tratar en este artículo, y que son el formulario por un lado y la página de privacidad por el otro.

Formulario de recogida de datos

Cualquier formulario que tenga en su sitio web es susceptible de suponer una recogida de datos del visitante: un formulario de contacto, un formulario de contratación, un registro como usuario o comprador, una suscripción a un boletín, etc.

Como una de las condiciones posibles a las que apunta el Artículo 6 del RGPD es el consentimiento del interesado, si queremos basarnos en esta condición para hacer el tratamiento de los datos una de las cosas que le tenemos que pedir al usuario, además del correo electrónico, nombre, etc. que sea que necesitemos, es su consentimiento. He aquí la forma de hacerlo: añadir al formulario una casilla sin marcar pero que sea obligatorio marcar para que se ejecute la acción del formulario. El texto junto a la casilla ha de ser claro, del tipo: “Confirmo que he leído la información sobre privacidad y protección de datos y que consiento en enviar mis datos para el uso indicado.”

Atención con esta casilla, porque es importante que, tanto si el formulario se procesa mediante el envío de un mensaje de correo electrónico como mediante la escritura de un registro en una base de datos, quede constancia de que el usuario ha dado su consentimiento. Si cuando se rellena el formulario usted recibe un mensaje de correo electrónico, asegúrese de que el hecho de que esta casilla esté marcada va a generar una línea en el mensaje que inequívocamente diga que ese usuario ha dado su consentimiento. Sirve con un “Consiente: Sí”. Esto no nos lo hemos inventado nosotros; lo dice el Artículo 7 del RGPD en su punto 1. Así que asegúrese de que guarda esas pruebas de consentimiento en lugar seguro y con copia de seguridad.

Pero el usuario ha dado su consentimiento “para el uso indicado”. ¿Y cómo sabe el usuario cuál es el uso indicado? La forma más fácil para este usuario es tener la información delante, sin tener que navegar a otra página. Por eso es útil poner en la misma página del formulario un resumen de la información que necesita para dar un consentimiento informado, y un enlace a una página (que llamaremos “página de privacidad”) para poder obtener más información.

Este resumen debe estar claramente visible en la página del formulario: antes del botón de envío o accesible desde el texto de la casilla de confirmación mediante un enlace dentro de la misma página. Eso va a gustos.

La información mínima que debemos proporcionar sin que el usuario tenga que visitar otra página es:

  • quién es el Responsable de esos datos una vez se envíen (es decir, el responsable de la web en la mayoría de los casos);
  • cuál es la Finalidad para la que se van a usar esos datos (responder a una solicitud de contacto, suscribir al usuario a un boletín, etc.);
  • cuál es la Legitimación que nos permite tratar esos datos (que será el consentimiento del interesado en el caso de que le obliguemos a marcar la casilla, o una obligación contractual en caso de que sea un formulario de contratación);
  • cuáles van a ser los Destinatarios de esos datos (si por ejemplo se los vamos a enviar a una tercera empresa para que sean ellos quienes los gestionen);
  • cuáles son los Derechos que tiene el interesado (a saber qué datos tenemos suyos, a que le demos de baja, etc.);
  • si existe información adicional que podamos darle y dónde está (por ejemplo, en la página de privacidad).

Y allí encontraremos nuestra siguiente parada.

Página de privacidad

La ley no le obliga a tener una página en su sitio web dedicada exclusivamente a sus políticas de privacidad, pero sí que éstas estén en la web. Puede por ejemplo incluir la información sobre privacidad y tratamiento de datos personales en su página de políticas de empresa, o en las condiciones de uso de la web. La cuestión es que tenga esa información y que el enlace a información adicional que ha incluido en su formulario de toma de datos se dirija exactamente a la información sobre privacidad, sin que el usuario tenga que buscar por una larga página para encontrar lo que busca.

El RGPD es muy claro respecto de qué información debemos poner a disposición del interesado en el momento de facilitarnos sus datos personales. Le remitimos de nuevo al Artículo 13, que para los responsables de un sitio web debe ser tratado como el Santo Grial.

Pero como para jerga legal ya tiene usted el texto del Reglamento, que se lo habrá descargado nada más empezar a leer este artículo, aquí se lo vamos a poner en nuestras propias palabras. Insistimos en que su guía ha de ser el propio Reglamento, pero esto le servirá para ir entrando en calor:

  • quién es el responsable y sus datos de contacto;
  • con qué fin se van a tratar esos datos;
  • por qué tiene usted derecho a tratar esos datos (porque el usuario le ha dado su consentimiento, porque los necesita para cumplir su parte del contrato…);
  • cuáles van a ser los destinatarios de esos datos;
  • si va a enviar esos datos a un país fuera de la Unión Europea que no haya sido considerado adecuado por la Comisión Europea en cuanto al cuidado que se tiene allí tratando los datos personales;
  • por cuánto tiempo va usted a conservar esos datos;
  • cuáles son los derechos que tiene el usuario respecto de sus datos (acceso, rectificación, supresión, portabilidad y limitación al tratamiento de sus datos o su oposición a este tratamiento);
  • el derecho que tiene el interesado de reclamar ante una autoridad de control, que en España es la Agencia Española de Protección de Datos;
  • si el interesado está obligado a facilitar estos datos por obligación contractual o de otro tipo y las consecuencias que puede tener el hecho de que no los facilite;
  • si se van a usar esos datos para tomar decisiones automatizadas que le afecten, como la creación de perfiles (por ejemplo, usar un algoritmo para cobrarle más o menos en el momento de suscribir un seguro y cosas así).

Asegúrese de que su página sobre privacidad contiene esa información y lo más probable es que, junto con la casilla para pedir el consentimiento en todos los formularios, su web pueda llegar al 25 de mayo en estado de revista.

Lo justo y necesario

Unas notas antes de despedirnos.

El Artículo 5 del reglamento dice muy claramente que “Los datos personales serán: a) […] b) recogidos con fines determinados, explícitos y legítimos, y no serán tratados ulteriormente de manera incompatible con dichos fines [… y] c) adecuados, pertinentes y limitados a lo necesario en relación con los fines para los que son tratados («minimización de datos») […]”.

No tiene sentido pedirle a un posible cliente la fecha de nacimiento en un formulario de contacto y que además sea un campo obligatorio, pero es que además bajo el RGPD esto es ahora ilegal. Si es necesario que para alguna acción disparada por un formulario el interesado sea mayor de edad, es suficiente con una casilla de declaración de mayoría de edad. Piense siempre en alternativas cuando crea que debe pedir más datos, porque con cada información extra que le pida al usuario está usted comprometiéndose a tener que defender su necesidad ante un tribunal. Si no está seguro de poder hacerlo, es mejor abstenerse de pedir la información.

Hemos dicho antes que la legitimidad para tratar los datos del interesado cuando hay un contrato de por medio es el cumplimiento del propio contrato. Visto así, en un formulario de contratación no sería necesario incluir la casilla de consentimiento. Desde nuestro punto de vista, más vale ser precavido y hacer declarar al usuario que ha leído la política de privacidad (aparte de los términos de contratación aplicables al caso). Al fin y al cabo, usted tiene que velar por sus propios intereses, y dormirá más tranquilo teniendo la prueba de consentimiento de todos sus usuarios, sean clientes o no.

Aparte de estos requisitos legales, técnicamente la información enviada a través de un formulario debería estar encriptada para que nadie pueda interceptarla en el camino hacia su buzón de correo electrónico o hacia su base de datos. Por eso debería proteger su web con un certificado SSL (lo que hace que algunas webs tengan una dirección https://... en lugar de http://...) y así dar a sus visitantes todas las garantías de confidencialidad posibles.

Y ya por último, si tiene un blog que acepte comentarios de los visitantes, no olvide que eso también es un formulario y que está usted recogiendo direcciones de correo electrónico y puede que hasta nombres reales. Existen plugins o módulos para los gestores de contenido más utilizados, como WordPress, que le pueden ayudar a añadir la casilla de consentimiento también en este caso. Aprovéchelos.

Cómo estructurar un sitio web con WordPress

Tarsis.net

WordPress es un popular gestor de contenidos que permite disponer de un blog de forma casi inmediata. Sin embargo, sus características, su potencia y sus posibilidades de personalización nos permiten usarlo como base para casi cualquier tipo de sitio web. Siempre y cuando lo estructuremos de forma correcta y pensando en nuestros usuarios.

Foto de Andrew Neel en Unsplash

Una de las primeras tareas a las que se enfrenta el administrador de un sitio web en WordPress es pensar en cómo organizar el contenido.

La empresa que elige WordPress como gestor de contenidos (CMS o Content Management System) para su web corporativa lo hace por varias razones, siendo las más comunes de ellas las siguientes:

  • Es fácil de usar, no necesita conocimientos técnicos y, una vez instalado y bien configurado por un profesional, se puede usar durante mucho tiempo sin que surjan importantes problemas siempre y cuando se mantenga actualizada la aplicación y sus plugins.
  • El usuario, por lo tanto, no depende de una agencia para hacer cualquier cambio cotidiano en los contenidos: añadir contenido, editar el existente, etc.
  • Permite tener un sitio web funcionando en relativamente poco tiempo, salvo que la puesta en marcha implique el diseño desde cero de temas o plantillas.
  • Posibilita el que se combinen un sitio web de contenido imperecedero con la gestión de un blog empresarial.

Este último punto es el que nos interesa ahora, puesto que la estructura del contenido dependerá del uso que le demos al CMS: web, blog o ambas cosas.

Tengo un blog

Profesionales y pequeñas empresas que deseen tener una presencia web que les permita posicionarse como expertos en su materia pueden querer usar un WordPress en su función original de blog: artículos que se publican periódicamente como si de un diario se tratara.

Son lo que en el vocabulario de WordPress se denominan “entradas”, y a las que también se le llaman artículos o posts. Normalmente llevan un sello de tiempo (la fecha del día en que se publicaron) y, en la configuración más habitual del CMS, aparecerán automáticamente listados en la página principal a medida que se van publicando.

Pero aunque sea el blog la función principal del sitio web, es inevitable tener otro tipo de contenidos que no son en sí artículos relacionados con el tema principal de la web. Para cada profesional o empresa pueden ser distintas, pero casi siempre se repiten las mismas páginas básicas:

  • quiénes somos
  • información legal y/o términos de uso
  • formulario de contacto

El tipo de contenido de estas páginas en el vocabulario de WordPress no es “entrada”, sino (¡sorpresa!) “página”.

La forma de estructurar el contenido en un WordPress así usado es fácil: basta con elegir un formato de enlace permanente para las entradas (posts o artículos), que puede incluir o no la fecha, y establecer un menú o pie de página con las pocas páginas fijas que haya en la web.

Además podemos establecer una taxonomía de las entradas a base de categorías y etiquetas, pero eso no es objeto de este artículo.

Tengo una web

Si en lugar de tener un blog donde publicar periódicamente artículos lo que queremos es tener una web de empresa con páginas fijas distribuidas en secciones, también es posible con WordPress. Podemos usarla para mostrar la información sobre la empresa, qué ofrecemos y un catálogo de productos o servicios.

En este caso, todo el contenido de la web está hecho a base de “páginas” y no habrá por tanto publicaciones tipo “entrada”.

Como las páginas serán el grueso del contenido y no sería útil darles a todas la misma importancia, debemos dedicarle una especial atención a la estructura de la web.

WordPress permite ordenar las páginas siguiendo una estructura de árbol, de manera que una página puede depender de otra que es su superior.

Veamos un ejemplo. Supongamos que mi empresa fabrica material de papelería, así que mi catálogo podría tener este aspecto (en este artículo no vamos a cubrir venta online, únicamente a mostrar características de productos para el ejemplo que nos ocupa):

  • Material de escritura
    • Útiles de escritura
      • Bolígrafos
    • Cuadernos
      • DINA4
  • Material de oficina
    • Consumibles
      • Clips
    • Utensilios
      • Grapadoras

Puedo crear las dos páginas superiores (“Material de escritura” y “Material de oficina”) y luego hacer depender las páginas de segundo nivel de cada una de ellas. Las de segundo nivel serían a su vez la página superior de cada una de las de tercer nivel, y así sucesivamente para todos los niveles de catálogo que tuviéramos.

Las páginas que tuvieran otras por debajo podrían además ser dinámicas, de manera que automáticamente listaran las páginas que dependen de ellas. Eso se puede hacer mediante programación de una plantilla adecuada.

Llegado a este punto, podrían surgirme algunas preguntas:

  • Las dos categorías superiores, ¿deberían además depender de una página superior a ellas que fuera la cabecera del catálogo de productos o servicios? Seguramente sí, porque inevitablemente en la web tendremos otras páginas (información legal, formulario de contacto, quiénes somos…) que están fuera del catálogo. Así podría crear una página principal para la oferta de mi empresa aparte de otras páginas necesarias en la web.
  • ¿Son estas categorías las que van a usar los visitantes a mi web? En este caso parecería que sí: si un señor busca una grapadora, quiere llegar a una página donde le muestre grapadoras. Pero para muchos administradores es fácil perderse en la propia nomenclatura interna de la empresa y no ponerse en el lugar de un visitante cualquiera. En ocasiones encontramos webs con los productos categorizados por su nombre comercial en lugar de por su nombre genérico, y así no hay forma de encontrar lo que se va buscando. El que quiere comprar un taladro busca poder elegir entre “taladro eléctrico”, “taladro hidráulico” o “taladro neumático”, pero no entre “Serie AxtraMax”, “Serie AxtraPlus” y “Serie AxtraPro”. ¿Qué sabe él qué es cada cosa, y por qué tendría que saberlo?
  • ¿Cómo organizar visualmente esta información? Al haber creado una página principal de producto, puedo elaborar con esta información un menú que constituya la navegación principal del sitio web. Las otras páginas de contacto, legal, etc. podrían estar enlazadas desde una zona secundaria, como el pie de página.

Como vemos, la forma en que queremos organizar la información en la web es algo prioritario en la creación de la misma. Ahora estamos hablando de WordPress, pero esta fase es necesaria para cualquier sitio web que queramos crear. Nuestros clientes agradecen que le dediquemos tiempo a este punto y nos sentemos, aunque sea virtualmente, con ellos para estructurar correctamente sus contenidos. Merece la pena dedicarle atención, dedicación e imaginación.

Si no lo hacemos, y si ignoramos la mentalidad de los usuarios de la web, tendremos una penalización directa en forma de abandono. El visitante no tiene tiempo que perder, y si le hacemos perder el tiempo, abandonará y se irá a la web de la competencia. En la era del “a un clic” no se puede estar tratando de adivinar cuál es la organización de un sitio web; ésta debe ser evidente y accesible.

El nombre que le demos a nuestras páginas (tanto el título como la dirección web) además nos ayudará, si lo elegimos bien, a posicionarnos en los buscadores por nuestros productos o servicios. Ésa es otra razón de peso para categorizar las páginas de forma genérica y no por nombres comerciales.

Lo tengo todo

Si hemos dedicado el esfuerzo que se merece a la estructura del sitio web de la que hablábamos anteriormente, añadirle, ahora o en el futuro, un blog a nuestro WordPress es fácil.

Como todo el contenido del sitio web está jerarquizado, basta con configurar una dirección dentro de nuestro dominio o en un subdominio para poder acceder desde ella a los artículos (“entradas”) publicados en el blog.

En definitiva…

Crear la estructura de un sitio web es ponerse en los zapatos del visitante anónimo, y pensar en sus términos y no en los de nuestra empresa.

La forma en que estructuremos el contenido de nuestro sitio web nos ayudará a sacarle todo el partido posible a nuestro WordPress, a posicionar mejor en los buscadores, a mantener la web actualizada con más facilidad y, lo que es más importante, a que nuestros visitantes encuentren lo que buscan… y nos lo compren a nosotros y no a la competencia.

Podemos ayudarle. Si su empresa necesita crear un sitio web, contacte con nosotros y estudiaremos su caso, sin compromiso.

Publicado en: Empresa Web

Etiquetas: