Cómo crear medidas de seguridad sólidas para proteger sus servidores

Introducción

Al trabajar en infraestructura en la nube, su principal preocupación es asegurarse de que sus aplicaciones estén completamente operativas. Una inclusión importante de su proceso de configuración e implementación es incorporar medidas de seguridad efectivas, exhaustivas y robustas en sus aplicaciones o sistemas antes de que se ofrezcan al público. En lugar de implementar medidas de seguridad de forma retroactiva después de la implementación, es importante asegurarse de que haya una configuración base segura integrada en su infraestructura.

Este tutorial le ayudará en este sentido. Destacará ciertas medidas prácticas de seguridad que se pueden implementar mientras se establece y configura la infraestructura de su servidor. Aunque esta no es una lista exhaustiva de protocolos de seguridad para servidores, es un punto de partida útil. A medida que trabaje y comprenda mejor las necesidades específicas de su entorno y aplicaciones, podrá desarrollar medidas de seguridad adicionales para ayudar a construir sobre su base.

Claves SSH (Secure Shell)

Mientras trabaja con su servidor, pasará la gran mayoría de su tiempo trabajando en una conexión SSH con su servidor en una sesión de terminal. Las claves de Secure Shell (SSH) proporcionan un método de inicio de sesión en el servidor más seguro que los inicios de sesión basados en contraseñas. Para fines de autenticación, con el uso de claves SSH, se preparan dos claves de acceso. La primera es una clave secreta (privada), mientras que la otra es una clave pública que se puede compartir.

La autenticación mediante clave SSH debe configurarse primero. Esto se logra colocando la clave pública SSH en el directorio adecuado del servidor. Cuando su cliente se conecte inicialmente al servidor, se le pedirá una prueba de posesión de la clave privada. Esto se hace mediante la generación de un valor aleatorio que luego se enviará a su cliente SSH. El cliente SSH, a su vez, utilizará la clave privada para cifrar una respuesta. Esta respuesta se enviará al servidor. A continuación, el servidor descifrará el mensaje del cliente utilizando su clave pública. Si el servidor descifra el valor aleatorio, esto indica que el cliente tiene la clave privada. En ese caso, se confirma la autenticación y se puede establecer una conexión con el servidor sin contraseña.

Mejora de la seguridad con claves SSH

Aunque la autorización por contraseña o cualquier autenticación con SSH está completamente cifrada, los usuarios maliciosos pueden intentar acceder al servidor. Especialmente si han llegado a poseer la dirección IP pública del servidor. Al probar cada combinación posible de teclas, la informática moderna permite los inicios de sesión basados en contraseñas y, a menudo, los usuarios maliciosos lo intentan. Si se automatizaran estos intentos de acceso, sería posible, probando diferentes combinaciones de forma sistemática, acceder finalmente a la contraseña correcta.

Al aprovechar la autenticación cifrada de SSH, no es necesario habilitar contraseñas para iniciar sesión. Las claves SSH suelen contener una cantidad significativa de combinaciones posibles que un atacante tendría que probar. El mayor número de bits multiplica el potencial de diferentes combinaciones necesarias para descifrar el cifrado. Por lo tanto, probar tantas combinaciones posibles del algoritmo de clave SSH requeriría una inmensa cantidad de tiempo. De este modo, se convierte en una empresa que no merece el tiempo de un atacante malicioso. Es por esto que el cifrado SSH se considera típicamente 'indescifrable'.

Implementación de claves SSH

Iniciar sesión en cualquier servidor remoto Linux debería utilizar claves SSH. Se puede generar una clave en la máquina local y transferir la clave pública al servidor en cuestión de minutos. Con este tutorial, obtendrá una idea básica sobre cómo usar SSH para conectarse a un servidor remoto en Ubuntu.  También puede seguir nuestro detallado tutorial sobre cómo configurar su servidor Linux para usar la autenticación basada en claves SSH.

En general, no permitir que el usuario root inicie sesión directamente a través de SSH es una práctica recomendada de uso común, mientras que se inicia sesión como un usuario sin privilegios y se utiliza una herramienta como sudo para escalar privilegios según sea necesario. Esto se conoce como el principio de mínimo privilegio: un método para limitar los permisos de acceso. Una vez que se ha verificado el inicio de sesión como una cuenta sin privilegios con SSH, los inicios de sesión de root se pueden deshabilitar configurando la directiva PermitRootLogin no en /etc/ssh/sshd_config en su servidor. Luego, el servidor se puede reiniciar con un comando de proceso SSH sudo systemctl restart sshd.

Cortafuegos

Un software (o dispositivo de hardware) que regula la exposición de los servicios a la red se conoce como un cortafuegos. Un cortafuegos, configurado de manera óptima, garantiza que solo los servicios permitidos estén disponibles públicamente y se les permita entrar y salir del servidor en particular.

Varios servicios pueden estar ejecutándose de forma predeterminada en un servidor y estos se pueden categorizar en los siguientes grupos:

• Servicios internos: Solo se debe acceder a estos internamente desde el propio servidor. Esto evita la exposición de los servicios a la accesibilidad pública de internet (ej: una base de datos accesible solo a través de conexiones locales).
• Servicios públicos: Servicios a los que cualquiera puede acceder, a menudo de forma anónima, en internet. Estos incluyen servidores web que permiten que los visitantes accedan a su sitio.
• Servicios privados: Solo las cuentas autorizadas de un conjunto exclusivo de ubicaciones pueden acceder a estos servicios (ej: panel de control de base de datos phpMyAdmin).

Mientras que los servicios públicos pueden dejarse disponibles para ser accedidos desde internet, los servicios privados pueden restringirse según los parámetros de acceso (como los tipos de conexión), y los servicios internos se desconectan por completo de cualquier acceso basado en internet. El acceso a estos servicios, junto con la granularidad con la que se permite, está controlado en su totalidad por el cortafuegos. Los puertos no utilizados se configuran comúnmente para bloquear el acceso a ellos por completo.

Mejora de la seguridad con el uso de cortafuegos

Un cortafuegos es una línea base para la protección del servidor. Sirve para limitar la conexión hacia y desde los servicios antes de que la aplicación maneje el tráfico. Por supuesto, puede implementar características de seguridad adicionales para sus servicios y restringirlos a las interfaces deseadas.

Solo los servicios que elija mantener abiertos no estarán restringidos por un cortafuegos configurado correctamente. Esto limita los elementos vulnerables a la explotación, ya que las piezas de software disponibles son mucho más limitadas y, por lo tanto, es menos probable que experimenten un ataque.

Implementación de cortafuegos

Hay muchos cortafuegos disponibles para sistemas Linux. Algunos de ellos son bastante complejos. Sin embargo, la configuración típica de un cortafuegos solo debería realizarse en el momento de la configuración inicial del servidor cuando se implementan cambios en los servicios del servidor. Esto solo debería tomar unos minutos de su tiempo. A continuación se presentan algunas opciones a considerar para configurar y activar el cortafuegos:

• Para CentOS, puede seguir nuestra guía de Configuración de un cortafuegos con FirewallD en CentOS 7.
• Nuestra guía de Iptables puede guiarlo a través de la lista y eliminación de reglas de cortafuegos de Iptables.

Lo más importante, independientemente del tutorial, debe asegurarse de que el cortafuegos de su elección bloquee el tráfico desconocido de sus servidores para evitar que cualquier servicio recientemente disponible quede expuesto en internet de forma inadvertida. Al tener que autorizar explícitamente el acceso, se le pedirá que evalúe por completo cómo se accede a un servicio, cómo se ejecuta y quién tiene permitido acceder a él.

Redes de Nube Privada Virtual (VPC)

Los recursos de su infraestructura’ necesitan operar dentro de una red privada conocida como la VPC. Estas redes son más seguras ya que evitan el acceso desde otras redes VPC basadas en la nube. Por lo tanto, hacen que las interfaces de la red sean inaccesibles desde el internet público.

Mejora de la seguridad con redes VPC

Las redes privadas son preferibles a sus contrapartes de redes públicas para la comunicación interna. VPC permite el aislamiento de grupos de recursos en redes privadas particulares. Debido a que las redes VPC se conectan solo a través de conexiones privadas, el tráfico de la red está protegido contra la exposición a la internet pública, donde esa información podría ser vulnerable a la interceptación o exposición. Las redes VPC también se pueden utilizar para aislar entornos de ejecución, así como inquilinos. Las puertas de enlace de internet también se pueden configurar como un único punto de acceso entre la internet pública y los recursos en su red VPC.

Además, una gran parte de la seguridad implica analizar nuestros sistemas y proteger todos los componentes lo mejor posible. La auditoría de servicios nos permite conocer los protocolos aceptables de los sistemas, los servicios en ejecución y qué puertos se están utilizando para la comunicación. Conocer esta información puede ayudar a tomar las mejores decisiones con respecto a la configuración. Dichas decisiones podrían ser la configuración del cortafuegos, el monitoreo y las alertas del sistema, y qué servicios deberían ser accesibles públicamente.

Aprovechar la auditoría para mejorar la seguridad

Cada servicio puede utilizarse para atender a clientes externos o para fines internos. Independientemente de la intención, todos estos servicios son puntos de vulnerabilidad para usuarios maliciosos. A medida que aumenta el número de servicios en ejecución, también lo hace el potencial de explotación de vulnerabilidades.

Puede comenzar a analizar los servicios una vez que tenga una idea clara de qué servicios está ejecutando una máquina. Al realizar una auditoría de servicios, es beneficioso hacerse las siguientes preguntas:

• ¿Debería estar ejecutándose activamente el servicio en particular?
• ¿Se está ejecutando en las interfaces de red óptimas?
• ¿Es el servicio más adecuado para una interfaz de red pública o privada?
• ¿Están las reglas del cortafuegos configuradas correctamente para permitir el tráfico legítimo a este servicio?
• ¿Está bloqueado el tráfico ilegítimo con mis reglas de cortafuegos?
• ¿Hay algún sistema de alerta sobre vulnerabilidades de seguridad habilitado?

Al agregar un nuevo servidor a la infraestructura, lo anterior deberían ser prácticas estándar en su proceso de configuración. Un beneficio adicional de las auditorías de servicios es que permitirán identificar cualquiera de las configuraciones que hayan cambiado involuntariamente.

Realización de auditorías de servicios

Para auditar los servicios en ejecución, use el comando ss para enumerar todos los puertos UDP y TCP activos en un servidor. Aquí hay un ejemplo del uso del comando ss con un nombre de programa PID, buscando puertos TCP y UDP en escucha:

Se devolverá algo similar a lo siguiente:

Su enfoque principal debe estar en las columnas Netid, Local Address:Port y Process:

• Si el valor de Local Address:Port es 0.0.0.0, significa que el servicio está aceptando activamente todas las conexiones en todas las interfaces de red IPv4. Si la dirección es [::], entonces todas las conexiones IPv6 están aceptando tráfico.
• En el ejemplo anterior, tanto Nginx como SSH están escuchando en todas las interfaces públicas en ambas pilas de red (IPv4 e IPv6).

Con el ejemplo anterior, podría elegir si necesita permitir que SSH y Nginx escuchen en las dos interfaces, o solo en una de ellas. Generalmente, querrá deshabilitar cualquier servicio que no se use para evitar que se ejecute. Por ejemplo, si solo se debería poder acceder a su sitio a través de IPv4, ayudaría apagar las interfaces IPv6 para limitar la exposición.

Mantenerse al día con las actualizaciones desatendidas

Las actualizaciones desatendidas reducen el nivel de esfuerzo requerido para mantener seguros sus servidores y ayudan a disminuir el tiempo que permanecen expuestos a errores conocidos. Cuanto más tarde en ejecutar las actualizaciones en su servidor, más tiempo permanecerá expuesto a vulnerabilidades conocidas. Las actualizaciones desatendidas se asegurarán de que, tan pronto como estén disponibles los paquetes de corrección, se puedan instalar automáticamente en el servidor para limitar el tiempo de vulnerabilidad.

Además de la auditoría del servidor, las actualizaciones desatendidas pueden reducir enormemente la exposición a los ataques. También reducirán en gran medida el tiempo dedicado al mantenimiento del servidor.

Cómo se activan las actualizaciones desatendidas

Las actualizaciones desatendidas son ahora una función opcional en la mayoría de las distribuciones de servidores. En Ubuntu, por ejemplo, la administración puede ejecutar el siguiente comando:

Para obtener información adicional sobre la implementación de actualizaciones desatendidas, consulte la sección de Actualizaciones automáticas aquí. Para Fedora, las instrucciones se pueden encontrar aquí. Tenga en cuenta que las actualizaciones automáticas solo instalarán el software que se haya instalado inicialmente a través del sistema de gestión de paquetes de su sistema. Cualquier aplicación complementaria, como las basadas en web, deberá comprobarse por separado para buscar actualizaciones de forma manual o configurarse individualmente para actualizaciones automáticas.

Índices de directorio

Cuando un directorio carece de un archivo de índice, la mayoría de los servidores están configurados para mostrar los índices del directorio de forma predeterminada. En otras palabras, si se creara un directorio llamado 'downloads' en su servidor web, cualquiera que navegue por ese directorio podrá ver todos los archivos que contiene. Aunque esto no siempre representa un riesgo de seguridad, sí deja información confidencial visible para personas ajenas. Como ejemplo, considere que su servidor web puede tener un archivo que contenga las credenciales de acceso a la página de inicio de su sitio web y un archivo con todas las configuraciones del back-end de la base de datos del sitio. Si los índices de directorio no están deshabilitados, cualquiera que navegue por ese directorio podrá ver estos archivos.

Aumento de la seguridad mediante la desactivación de los índices de directorio

Aunque los índices de directorio son útiles, pueden dejar archivos expuestos de forma involuntaria. Para mitigar dicha exposición involuntaria y cualquier riesgo asociado, los índices de directorio en el servidor deben estar deshabilitados de forma predeterminada. Aunque los visitantes aún pueden acceder a los archivos, la exposición a la visualización involuntaria de datos se limita significativamente.

Desactivación de los índices de directorio

En la mayoría de los casos, basta con añadir una sola línea más a la configuración de su servidor web para desactivar los índices de directorio.

• Siga estos pasos para desactivar estos listados de directorios en la Wiki de Apache. Asegúrese de que Options -Indexes figure en los bloques de configuración de Apache Directory.
• Los índices están desactivados por defecto en Nginx, por lo que no se requiere ninguna otra acción a este respecto.

Copias de seguridad frecuentes

Aunque las copias de seguridad no son una medida de seguridad, son imperativas para salvaguardar los datos y sistemas enteros en caso de que el sistema se vea comprometido. También ayudan a analizar cómo pudo haber sido atacado el sistema. Considere un escenario desafortunado en el que su sistema es atacado por ransomware (un virus o herramienta de malware que cifra los archivos de su sistema y solo los descifra si paga dinero al hacker). Si no hay copias de seguridad de los datos, su única opción es pagar el dinero para recuperar el acceso a sus datos. Si se realiza una copia de seguridad de los datos de forma segura, seguirá teniendo acceso a ellos y podrá recuperarlos sin necesidad de acceder al sistema comprometido.

Mejora de la seguridad mediante copias de seguridad frecuentes

Las copias de seguridad frecuentes ayudan a recuperar información a causa de un ataque, corrupción o incluso pérdida involuntaria (eliminación). No importa qué tipo de evento negativo provoque la pérdida de datos, el riesgo se reduce al conservar copias de los datos del servidor.

Aparte de los ataques de ransomware, las copias de seguridad frecuentes pueden ayudar con la investigación medible de asaltos al sistema a largo plazo. Si no almacena sus datos de forma segura en un formato de copia de seguridad, determinar el origen del ataque y qué datos se vieron comprometidos puede resultar difícil o incluso imposible.

Implementación de copias de seguridad frecuentes

Tratar la recuperación verificable de datos dañados, comprometidos o eliminados como el objetivo de sus esfuerzos de recuperación al realizar copias de seguridad de sus sistemas es primordial. Para plantearlo de la mejor manera, considere qué acciones requerirían la menor cantidad de trabajo para volver a ponerlo en funcionamiento si su servidor desapareciera mañana.

Aquí hay algunos otros puntos a considerar al pensar en un plan de recuperación ante desastres:

• Si opera con datos que cambian dinámicamente, es probable que sus copias de seguridad deban ser más frecuentes. En caso de pérdida de datos, si su última copia de seguridad fue hace demasiado tiempo, podría verse obligado a volver a datos obsoletos.
• Piense en el proceso real de restauración de la copia de seguridad. ¿Será necesario añadir un nuevo servidor para ello o se puede restaurar el existente?
• ¿Cuál es el período de tiempo más largo que puede tener el servidor fuera de servicio?
• ¿Es la copia de seguridad externa una solución necesaria?

Para obtener más información sobre las soluciones de recuperación ante desastres de CloudSigma, consulte nuestra publicación de blog que detalla por qué nuestro Disaster-Recovery-as-a-Service es el compañero perfecto para la nube. Y aquí puede encontrar más información sobre las características de seguridad & continuidad del negocio de CloudSigma. También tenemos una guía detallada sobre cómo configurar fácilmente la funcionalidad de copia de seguridad de CloudSigma.

Redes privadas y VPN

Una red privada es aquella que solo está disponible para el acceso y uso de usuarios o servidores particulares. Una conexión segura entre dispositivos remotos que permite que la conexión funcione como si estuviera en una red privada es una VPN (una red privada virtual). Le brinda la capacidad de asegurar conexiones en una red privada y conectar servidores remotos.

¿Cómo mejoran la seguridad las redes privadas?

Cuando se puede elegir entre utilizar redes públicas o privadas para la comunicación interna, esta última siempre es la opción preferible. Tenga en cuenta, sin embargo, que otros usuarios dentro del centro de datos aún pueden acceder a la misma red. Esto significa que se deben aplicar medidas de seguridad complementarias para garantizar que la comunicación entre servidores sea segura.

Básicamente, utilizar una VPN es un enfoque para delimitar lo que los trabajadores de su organización pueden ver. La correspondencia será completamente segura y privada. Las configuraciones de las aplicaciones permitirían que el tráfico de la interfaz virtual pase a través de la VPN. Al hacerlo, solo se permitirá que los servicios destinados a la interacción con el cliente a través de Internet se expongan a una red pública.

¿Qué tan difícil es implementar una VPN?

Aprovechar las redes privadas es tan sencillo para su centro de datos como configurar sus aplicaciones y el firewall para usar una red privada y habilitar la VPN durante la creación de su servidor. Es importante recordar que otros servidores comparten el mismo espacio de red que las redes privadas de todo el centro.

La configuración inicial de una VPN es un poco más compleja. Sin embargo, la seguridad adicional que esto aporta vale la pena para la mayoría de los casos de uso. Los datos de configuración y la seguridad compartida deben instalarse y configurarse en cada servidor de la red. Para obtener información más detallada sobre cómo funciona una VPN y una descripción general de la configuración de OpenVPN en Ubuntu, siga esta guía. También puede seguir este tutorial que le guiará a través de los pasos para conectar una red VPN a la infraestructura de CloudSigma.

Cifrado SSL/TLS e infraestructura de clave pública

La generación, gestión y validación de certificados para identificar personas y el cifrado de comunicaciones se denominan Infraestructura de Clave Pública (PKI). Diferentes entidades pueden autenticarse entre sí mediante el uso de SSL o TLS certificados. Después de eso, también se pueden utilizar para establecer una comunicación cifrada.

Cómo mejoran la seguridad los certificados

Para cifrar el tráfico y validar las identidades de los miembros en un servidor, es vital establecer una autoridad de certificación (CA) y poder ver todos los certificados de su red. Esto puede ayudar a prevenir ataques de tipo 'man-in-the-middle' (intermediario), en los que un hacker imita al servidor y el tráfico se desvía.

La configuración de cada servidor se puede establecer para confiar en una CA centralizada. Cualquier firma de certificado posterior se puede confiar de forma implícita. Si el cifrado SSL/TLS es compatible con los protocolos y aplicaciones que utiliza su servidor, puede proteger su sistema sin la sobrecarga del túnel VPN. Para obtener más información, siga nuestro tutorial sobre cómo automatizar las renovaciones de certificados SSL de LetsEncrypt para Nginx.

Dificultad de implementación

Puede haber un gran esfuerzo inicial para configurar una autoridad de certificación y luego establecer la PKI restante. Además, cuando sea necesario crear, revocar o firmar nuevos certificados, se requerirá un esfuerzo de administración adicional.

Debido a que la mayoría de las infraestructuras necesitan crecer, implementar una PKO completa es el enfoque más sensato. Hasta que llegue a un punto en el que la PKI valga los costos de administración adicionales, utilizar una VPN para proteger los componentes del sistema puede servir como una medida provisional adecuada.

Detección de intrusiones en el sistema y uso de la auditoría de archivos

La auditoría de archivos es un proceso utilizado para comparar los archivos y sus atributos de su sistema en un estado completamente seguro y óptimo con los de su sistema actual. Este es un buen método para encontrar y aislar cambios no autorizados en el sistema.

Un IDS, sistema de detección de intrusiones, se refiere al software de monitoreo que vigila cualquier actividad no autorizada en el sistema. Generalmente, utiliza métodos de auditoría de archivos para buscar cambios inesperados en el sistema.

Mejora de la seguridad mediante IDS/auditoría de archivos

Más allá de la simple auditoría a nivel de servicio, realizar auditorías a nivel de archivos es esencial para garantizar la seguridad de su sistema. Esto puede hacerse mediante un proceso IDS automatizado o ser realizado periódicamente por el administrador del sistema.

Las auditorías de archivos y los IDS son los únicos procesos verdaderos para asegurarse de que el sistema no haya sufrido alteraciones imprevistas. La mayoría de los intrusos quieren explotar los servidores que invaden durante largos períodos de tiempo y, para hacerlo, deben mantener la capacidad de que sus acciones sean encubiertas. Podrían reemplazar binarios con versiones vulnerables o comprometidas. Cualquier archivo que haya sido alterado en el sistema será detectado por una auditoría del sistema de archivos. Esto le brinda la tranquilidad de saber muy rápidamente si la integridad del sistema se ha visto comprometida.

Nivel de dificultad de implementación

La implementación de IDS y la auditoría de archivos puede ser un proceso muy intenso. Al principio, el sistema debe configurarse para definir las rutas a excluir y establecer los cambios no estándar que se hayan realizado en el sistema para crear una lectura de línea base del sistema.

Las operaciones del día a día también se vuelven más engorrosas, ya que los procedimientos deberán volver a verificar el sistema antes de que se ejecute cualquier actualización. La línea base de las mediciones del sistema también deberá recrearse o restablecerse para incorporar los cambios de versión de software como parte de la nueva línea base del sistema. Los informes de auditoría también deberán trasladarse a una ubicación alternativa. Esto se debe a que debe evitar que un intruso del sistema altere la auditoría para permanecer oculto al encubrir sus huellas.

Si bien esto ciertamente aumenta la carga administrativa de su sistema, es una de las únicas formas infalibles de garantizar que ninguno de los archivos haya sido alterado sin su conocimiento. Algunos de los sistemas de detección de intrusiones y auditoría de archivos más populares son Aide y Tripwire.

Entornos aislados

Cualquier método en el que los componentes individuales se ejecutan en su propio espacio dedicado se denomina entornos de ejecución aislados.

Esto podría significar que componentes particulares de la aplicación se alojarán en sus propios servidores dedicados, o que sus servicios pueden configurarse para operar en entornos chroot (o contenedores). Qué tan aislado esté el entorno depende principalmente de las realidades de su infraestructura y de los requisitos de su aplicación.

Mejora de la seguridad con entornos aislados

Al aislar sus procesos en entornos individuales, también está aislando qué procesos podrían verse afectados por fallas de seguridad. Al igual que los compartimentos y los mamparos ayudan a contener las vías de agua en los barcos, cuando separa las partes y componentes individuales de su sistema, si un intruso obtiene acceso a uno de ellos, no habrá podido acceder a todo el sistema de red interconectado.

Dificultad de implementación

La complejidad de aislar sus aplicaciones varía según los tipos de contención que haya decidido utilizar. Docker no considera el aislamiento como una característica de seguridad. Sin embargo, cuando sus componentes se dividen entre diferentes contenedores, el aislamiento se logra con mucha más facilidad. Puede seguir este tutorial para instalar Docker en nuestra infraestructura.

Cuando se configuran entornos chroot, también se ofrece cierto grado de aislamiento. Sin embargo, este no es un método completamente impenetrable, ya que existen métodos para salir de dicho entorno. Las máquinas dedicadas para los distintos componentes suelen ser la mejor y más sencilla forma de lograr el aislamiento. Sin embargo, es más costoso debido a la necesidad de máquinas adicionales.

Reflexiones finales

Las estrategias proporcionadas son solo algunas de las medidas que puede tomar para aumentar la seguridad de su sistema. Vale la pena señalar que cuanto más espere para implementar las funciones de seguridad, menor será su eficacia. Con esto en mente, es importante asegurarse de que la seguridad no sea algo que deba esperar. En su lugar, debe implementarse como una de las primeras disposiciones al construir la infraestructura. Una vez que su sistema sea lo suficientemente seguro con protecciones básicas, puede comenzar a activar servicios y agregar aplicaciones, sabiendo que se ejecutarán de forma predeterminada en un entorno seguro.

La seguridad no es un proceso estático, sin embargo, sino uno fluido. Debe mantenerse y repetirse. Debe abordarse con una mentalidad de conciencia constante y vigilancia persistente. Cuestione siempre cuáles son las implicaciones de seguridad involucradas en cualquier cambio del sistema.  Asegúrese de que los entornos operativos y las configuraciones predeterminadas siempre optimicen la seguridad y funcionen con software suficientemente defensivo.

¡Feliz computación!