Este artículo también está disponible en:
Este artículo está traducido utilizando un traductor automático. Podría contener algunos errores o traducciones extrañas. De todos modos, creemos que es valioso que puedas leer este artículo de ayuda en tu idioma materno. Déjanos tu comentario al final del artículo si este artículo te resultó útil o si tienes algún otro comentario.

Este documento contiene los principios rectores de cómo en Easy LMS mantenemos la seguridad y la privacidad de nuestros clientes.

La seguridad viene en capas y tenemos cinco principios rectores que nos permiten tener más y mejores capas de seguridad dentro de nuestra organización y nuestro producto. Cada uno de estos cinco principios será discutido por separado en este documento. Nuestros cinco principios de seguridad principales son

Principio de prioridad de la seguridad
Principio de discusión de la seguridad
Principio de no mantener el software
Principio de al menos 4 + 2 ojos
Principio de acceso menos privilegiado

Principio de priorización de la seguridad

Cualquier cosa que hagamos, arreglamos la seguridad primero.

Ninguna pieza de software está exenta de errores, y aunque hacemos nuestro mejor esfuerzo para tener la mayor calidad posible de nuestro producto, no somos una excepción a esto. Esto significa que a veces encontramos problemas (potenciales) de seguridad en nuestro sistema. Siempre que el problema esté presente dentro de nuestra instalación de producción, se le da la máxima prioridad al fallo registrado para garantizar que no exista una acumulación de problemas de seguridad sin resolver. Si se encuentran varios problemas de seguridad, se da prioridad al problema de seguridad de mayor gravedad.

En el caso de que se detecte un problema de seguridad antes de que llegue a nuestro entorno de producción, existe un proceso para garantizar que se impidan más despliegues del código vulnerable hasta que se resuelva la seguridad. Dado que podría impedirnos el despliegue de nuevas funciones, también se da prioridad a estos problemas para su corrección.

A menudo decimos que es mejor prevenir que lamentar. Creemos que garantizar un producto seguro no consiste en poner parches a los problemas que se encuentran, sino en asegurarse de que estos problemas nunca existan en primer lugar. Por lo tanto, creemos que la seguridad debe ser una prioridad desde las primeras etapas de desarrollo para diseñar la seguridad en nuestro producto en lugar de parchear las cosas después.

Discutir el principio de privacidad/seguridad

Si no pensamos y discutimos sobre cómo mejorar, nunca lo haremos

Aunque la seguridad se discute y se implementa en el corazón de nuestro software, pensamos que siempre se puede mejorar. Mantener una conversación nos ayuda a mantenernos centrados y afinados en nuestra forma de enfocar la seguridad. Además, una conversación es una forma de transformar las buenas ideas en grandes ideas, y los buenos diseños en grandes diseños. Y lo que es más importante, dado que siempre se puede mejorar, una conversación puede permitirnos descubrir lo que necesitamos mejorar en lugar de lo que podemos mejorar. La seguridad es siempre tan fuerte como la parte más débil y, cuando se trata de mejorar la seguridad, sólo las mejoras en la parte más débil mejorarán realmente la seguridad. Por ello, creemos que siempre hay que mantener viva la conversión en curso sobre cuál es nuestra parte más débil y cómo podemos mejorarla.

Principio de no mantenimiento/no seguridad del software

Nuestro software no es seguro si la plataforma en la que se ejecuta no lo es

No hemos inventado la rueda, y desde luego no hemos escrito nuestro propio sistema operativo. Así que, sí, dependemos del código de terceros. Esto significa que también tenemos que asegurarnos de que este código es seguro. Para el sistema operativo (un sabor linux), el entorno del lenguaje de programación (php / node), nuestro servidor http (apache), y los sistemas de base de datos (MariaDB), nos aseguramos de que siempre usamos una versión que al menos sigue recibiendo parches de seguridad. Esto significa que nuestro software se actualiza regularmente para que funcione con una versión actualizada. Además, se asegura que permanecemos seguros en todo momento, ya que para estos componentes, requerimos que los parches de seguridad se instalen automáticamente.

Para las bibliotecas que utilizamos en nuestro código, utilizamos herramientas automatizadas siempre que es posible para asegurarnos de que tienen una versión actualizada, pero sobre todo una versión segura. En la práctica, utilizamos 'npm audit' para asegurarnos de que nuestros paquetes de node.js están actualizados. Y utilizamos 'roave/security-advisors' para asegurarnos de que nuestras librerías php son seguras.

Al menos 4 + 2 ojos principio

Cada cambio, no importa lo trivial que pueda parecer, debe ser verificado para la calidad

Para mantener la calidad que pretendemos, creemos que, sean cuales sean las circunstancias, nuestro software nunca debe precipitarse. Esto significa que se requiere un ciclo de revisión completo para cada cambio que hagamos en nuestro producto. Esto significa que el código debe ser visto y aprobado por al menos dos desarrolladores y, a continuación, probado por uno de nuestros equipos de pruebas. Este principio está anclado en nuestro flujo de trabajo. Antes de que el código pueda desplegarse en un entorno de preparación o producción, tiene que pasar una solicitud de extracción. Las solicitudes de extracción deben ser revisadas por al menos otro desarrollador. La fusión real es realizada por alguien de nuestro equipo de pruebas. Por lo tanto, un desarrollador no puede, en principio, fusionar una solicitud de extracción. La seguridad es (obviamente) parte del ciclo de revisión. El otro desarrollador evaluará el código para ver si hay problemas relacionados con la seguridad. El revisor también comprueba los errores de seguridad más comunes para evitar filtraciones innecesarias en nuestro sistema.

Hay que hacer una mención especial a la infraestructura/administración del sistema. Dado que el ciclo de desarrollo del código permite evaluar la seguridad y la calidad antes de que llegue a producción, nos esforzamos por gestionar toda nuestra infraestructura como código. Esto nos permite automatizar la mayoría de las funciones, lo que significa que cometemos menos errores humanos. Además, un solo administrador del sistema puede realizar cambios sin notificación que podrían afectar a la seguridad de nuestro sistema.

Principio de acceso menos privilegiado

Cada persona debe tener acceso sólo a lo que necesita y cada programa debe poder acceder sólo a lo que necesita.

La forma más fiable de evitar cualquier forma de fuga de datos, es asegurarse de que no hay datos que filtrar en absoluto. Lo siguiente mejor es asegurarse de que nadie pueda acceder a la información no necesaria. Por ejemplo, un desarrollador no necesita acceder a nuestros datos de producción para desarrollar nuevas funciones. Del mismo modo, un traductor sólo necesita ver lo que se puede traducir en nuestro sistema, y no necesita acceder a nuestra base de código o a la información de los clientes. Nuestro objetivo es asegurarnos de que cualquier persona de nuestra organización sólo pueda ver y realizar las tareas necesarias para su función.

El principio de acceso menos privilegiado se aplica a las personas, pero también a los sistemas y servicios. Si una parte de nuestro sistema se ve comprometida, nuestro objetivo es minimizar el impacto que puede tener. Por lo tanto, tratamos de separar los servicios que sólo pueden acceder a la información que necesitan. Por ejemplo, no necesitamos procesar la información de pago al mostrar los contenidos de aprendizaje. Por lo tanto, los sistemas responsables de los contenidos de aprendizaje no deberían tener acceso a nuestro sistema de pago. Además, esto también es posible para otros servicios. Nuestro objetivo es desconectar los servicios de la Internet pública si es posible. Esto se hace preferentemente colocando los servicios en una red privada, desde la cual sólo se puede acceder a ellos desde esa red. Si el servicio no está destinado a un uso público, sino que se pretende acceder a él a través de Internet, trabajamos con una lista blanca de direcciones IP, para minimizar la exposición.

Notas finales

Creemos que es necesario un esfuerzo continuo para mantener un alto nivel de seguridad. Este esfuerzo significa que no debe quedarse en los principios, sino que estos principios deben estar integrados en todos nuestros procesos de trabajo. De esta manera, podemos asegurarnos de que la seguridad tiene prioridad dentro de nuestra organización.
¿Este artículo te resultó útil?
Cancelar
¡Gracias!