Este artículo también está disponible en:
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 se discutirá por separado en este documento. Nuestros cinco principios de seguridad principales son:

Priorizar el principio de seguridad
Discutir el principio de seguridad
No hay principio de software no mantenido
Al menos el principio de 4 + 2 ojos
Principio de acceso menos privilegiado

Priorizar el principio de seguridad

Lo que sea que hagamos, arreglamos la seguridad primero.

Ninguna pieza de software está libre de errores, y aunque hacemos nuestro mejor esfuerzo para tener la mayor calidad posible de nuestro producto, no somos una excepción. Esto significa que a veces encontramos (potenciales) problemas de seguridad dentro de nuestro sistema. Siempre que el problema está presente dentro de nuestra instalación de producción, se le da la máxima prioridad al error registrado para asegurarnos de que no existe ningún atraso de problemas de seguridad sin resolver. Si se encuentran múltiples problemas de seguridad, entonces se da prioridad al problema de seguridad de mayor gravedad.

En el escenario en el que se encuentra un problema de seguridad antes de que aterrice en nuestro entorno de producción, existe un proceso para asegurarse de que se impida la continuación del despliegue del código vulnerable hasta que se resuelva la seguridad. Dado que podría impedirnos desplegar nuevas características, estos problemas también tienen prioridad para las correcciones.

A menudo decimos que es mejor prevenir que lamentar. Pensamos que asegurar un producto seguro no se trata de parchar los problemas que se encuentran, sino de asegurarse de que estos problemas nunca existirían en primer lugar. Por lo tanto, pensamos que la seguridad debe ser una prioridad desde las primeras etapas de desarrollo para diseñar el derecho de seguridad en nuestro producto en lugar de parchar 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 e implementa en el corazón de nuestro software, creemos que siempre hay espacio para mejorar. Tener una conversación nos ayuda a mantenernos enfocados y perspicaces en la forma de enfocar la seguridad. Además, una discusió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, ya que siempre hay espacio para mejorar, una discusión puede permitirnos descubrir lo que necesitamos mejorar en lugar de lo que podemos mejorar. La seguridad siempre es tan fuerte como la parte más débil y cuando se trata de mejorar la seguridad, sólo las mejoras en su parte más débil mejorarán realmente su seguridad. Por lo tanto, creemos que la conversión en curso debe mantenerse siempre viva sobre cuál es nuestra parte más débil, y cómo podemos mejorarla.

No hay principio de software no mantenido/no asegurado

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

No inventamos la rueda, y ciertamente no escribimos 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 a linux), el entorno del lenguaje de programación (php / nodo), nuestro servidor http (apache), y los sistemas de bases de datos (MariaDB), nos aseguramos de usar siempre una versión que al menos siga recibiendo parches de seguridad. Esto significa que nuestro software se actualiza regularmente para funcionar con una versión actualizada. Además, se asegura de que permanezcamos seguros durante todo el proceso, ya que para estos componentes, requerimos que los parches de seguridad se instalen automáticamente.

Para las bibliotecas que usamos en nuestro código, utilizamos herramientas automatizadas siempre que es posible para asegurarnos de que éstas tengan una versión actualizada, pero más importante aún, una versión segura. En la práctica usamos 'npm audit' para asegurarnos de que nuestros paquetes node.js están actualizados. Y usamos 'roave/security-advisores' para asegurarnos de que nuestras librerías php son seguras.

Al menos el principio de 4 + 2 ojos

Cada cambio, por más trivial que parezca, debe ser verificado en cuanto a su calidad.

Para mantener la calidad a la que aspiramos, creemos que no importa las circunstancias, nuestro software nunca debe ser apresurado. Esto significa que se requiere un ciclo completo de revisión para cada cambio que hacemos a nuestro producto. Esto significa que el código debe ser visto y aprobado por al menos dos desarrolladores y luego probado por uno de nuestro equipo de pruebas. Este principio está anclado en nuestro flujo de trabajo. Antes de que el código pueda ser desplegado en un entorno de producción o puesta en escena, necesita pasar una solicitud de extracción. Las solicitudes de extracción deben ser revisadas por al menos otro desarrollador. La fusión real de vuelta es hecha por alguien de nuestro equipo de pruebas. Por lo tanto, un desarrollador no es capaz, en principio, de 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 probador también comprueba si hay errores de seguridad comunes para evitar fugas innecesarias en nuestro sistema.

Cabe 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 la producción, nos esforzamos por administrar toda nuestra infraestructura como código. Esto nos permite automatizar la mayoría de las características, lo que significa que cometemos menos errores humanos. Además, un único administrador del sistema puede hacer cambios sin notificación que podrían afectar a la seguridad de nuestro sistema.

Principio de acceso menos privilegiado

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

La forma más fiable de prevenir cualquier forma de fuga de datos, es asegurarse de que no hay ningún dato que filtrar. Lo mejor es asegurarse de que nadie pueda acceder a la información innecesaria. Por ejemplo, un desarrollador no necesita acceder a nuestros datos de producción para desarrollar nuevas características. Del mismo modo, un traductor sólo necesita ver lo que puede ser traducido en nuestro sistema, y no requiere acceso a nuestra base de códigos o a la información del cliente. Nuestro objetivo es asegurarnos de que cualquier persona de nuestra organización sólo pueda ver y realizar las tareas que se requieren para su función.

El principio de acceso menos privilegiado se aplica a los seres humanos, pero también se aplica a los sistemas y servicios. Si una parte de nuestro sistema se ve comprometida, intentamos minimizar el impacto que puede tener. Por lo tanto, nos proponemos separar los servicios que sólo pueden acceder a la información que necesitan. Por ejemplo, no necesitamos procesar la información de pago cuando se muestra el contenido de aprendizaje. Por lo tanto, los sistemas responsables del contenido de aprendizaje no deben 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 está pensado para ser accedido a través de Internet, trabajamos con una lista blanca de direcciones IP, para minimizar la exposición.

Notas finales

Creemos que se requiere 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 ser incorporados en todos nuestros procesos de flujo 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!