Consejos para asegurar los clusters de Elasticsearch de forma gratuita con encripción, usuarios y más
Con el lanzamiento del Elastic Stack 6.8 y 7.1, hemos ampliado a todos la disponibilidad de varias características de seguridad de Elasticsearch haciéndolas gratuitas en la distribución predeterminada. Estamos muy entusiasmados por compartir esto, pero uno de los desafíos nuevos ahora es actualizar toda la documentación y orientación sobre cómo asegurar el Elastic Stack. Quedaron atrás los días en que confiábamos solo en un servidor proxy adelante del Stack para asegurarlo.
Revisamos la mayoría de nuestros antiguos blogs populares enfocados en la seguridad y actualizaremos la orientación, disiparemos algunos mitos, plantearemos algunas ideas nuevas y garantizaremos que puedas asegurar tu Stack mejor que nunca.
No incluiremos enlaces a artículos antiguos; en algunos se brindan consejos que ahora consideramos peligrosos debido a los cambios que se han hecho en el Elastic Stack con los años. (Ten cuidado con los consejos de seguridad de blogs antiguos, los cambios suceden rápido). Reenviaremos todos esos enlaces a esta página, pero si encuentras otro sitio con versiones en memoria caché de esos artículos, reenvíale un enlace a este.
Encripción TLS
La encripción TLS ahora es parte de nuestra seguridad gratuita de Elasticsearch y Kibana en la distribución predeterminada. La finalidad de TLS es encriptar las comunicaciones de red. Encriptamos la comunicación entre los nodos en tu cluster, entre los clientes y el cluster, y las conexiones de Kibana con los usuarios.
También usamos certificados TLS para asegurar que se permita a un nodo unirse a un cluster. Sin TLS, cualquiera puede agregar un nodo a un cluster. Aunque un atacante podría aprovecharse de esto para varios propósitos nefastos, el caso más habitual es cuando un nodo se une accidentalmente al cluster equivocado. TLS puede ayudar a evitar estos problemas porque, sin el certificado adecuado, un nodo no puede unirse al cluster.
Antes de las versiones 6.8 y 7.1, si necesitabas TLS para tu Elastic Stack con una licencia Basic, debías confiar en algún tipo de proxy, lo que agrega una cantidad importante de configuración. TLS ya es bastante difícil de configurar incluso sin tener que configurar un proxy entre los nodos y los clientes. Agregar un proxy habría complicado todavía más un problema difícil. Ahora podemos aprovechar el soporte de TLS directamente en el Elastic Stack.
Tenemos bastante documentación sobre cómo configurar TLS. Si trabajaste con TLS, sabes que nunca resulta sencillo configurar certificados, pero tenemos herramientas integradas que ayudan a generar autoridades de certificados y certificados para todo el cluster para facilitar las cosas. Mantente atento a este espacio, en los próximos blogs entraremos en detalles sobre la mejor manera de configurar TLS en todos los componentes del Elastic Stack. ¿Cuáles son las dos opciones más sencillas para dar los primeros pasos hoy? Echa un vistazo a este blog Primeros pasos con la seguridad de Elasticsearch o a nuestro Kubernetes Operator oficial.
Autenticación
Con las versiones 6.8 y 7.1, la autenticación nativa está disponible para todos. La finalidad de la autenticación es permitir a los clientes identificarse en el Elastic Stack. Esto habitualmente se conoce como el nombre de usuario y la contraseña que usas para iniciar sesión en un sistema. Por lo general, es una mala idea dejar un cluster lleno de datos abierto a todo el mundo. Es particularmente peligroso si el cluster está conectado directamente a internet, donde cualquiera puede conectarse sin usar una contraseña.
Anteriormente, se aconsejaba usar un servidor Nginx con autorización básica habilitada entre el cliente y el cluster. Lograr la configuración correcta podría ser increíblemente difícil. Como todos los nodos pueden atender solicitudes externas, si olvidaste proteger con firewall un nodo, cualquiera podría conectarse al cluster sin autenticación.
Ahora permitimos la autenticación usando los realms nativo y de archivo de forma gratuita. El realm de archivo almacena información del usuario en un archivo en todos los nodos. Debes mantener los archivos sincronizados en todos los nodos. El realm nativo es una experiencia más optimizada y hace lo que uno esperaría: Los datos del usuario se almacenan en un índice en el cluster al que todos los nodos tienen acceso. Agregas nombres de usuario y contraseñas a través de una API REST, y luego esas cuentas pueden iniciar sesión. Consulta el blog Primeros pasos con la seguridad de Elasticsearch para ver más detalles.
Si tienes necesidades de autenticación más complejas, como LDAP, Active Directory, SAML u otra, ofrecemos un servicio Cloud (SaaS) con algunas de estas características comerciales y otras incorporadas, o puedes ponerte en contacto con nosotros para analizar posibles soluciones en las instalaciones. Para ver las distintas opciones de autenticación que ofrecemos, asegúrate de consultar los documentos sobre autenticación.
Autorización
La autorización y la autenticación tienden a ir de la mano, el Elastic Stack no es la excepción. Tenemos un sistema muy flexible que puede definir reglas de autorización para el cluster y los índices, incluidos documentos y campos. Incluso contamos con un motor de autorización en el que puedes crear tu propio plugin de autorización.
Históricamente, los consejos en este espacio han sido bastante imprecisos. Anteriormente, se han sugerido ciertas formas de escribir reglas de filtrado bastante complejas con un proxy como Nginx para luego intentar aprovechar los alias filtrados y lograr algo que casi se parezca a una autorización. Recomendamos a todos que eviten usar estos métodos para autorización. No son características de seguridad, probablemente no hagan lo que tú desees y su mantenimiento es increíblemente frágil. Estas soluciones ya no harán lo que realmente deseas porque, con el tiempo, la cantidad de API de Elasticsearch creció sustancialmente. Existen muchas maneras de acceder a los índices y los datos que contienen, y realizar búsquedas en ellos. No hay manera de asegurar que hayas bloqueado o restringido cada una de las solicitudes. La segunda razón está relacionada con la primera, porque hay tantos endpoints que proteger, y agregamos nuevos todo el tiempo. Mantener esos filtros actualizados requerirá una gran cantidad de trabajo.
Afortunadamente, ya no debes preocuparte por esto. En las versiones 6.8 y 7.1, tienes acceso a una gran cantidad de características de autorización. Son demasiadas para describirlas en este blog, pero encontrarás excelentes explicaciones de todos los privilegios existentes en los documentos de seguridad del Elastic Stack. Dedicaremos tiempo en los futuros blogs a explicar algunas de las soluciones que pueden crearse con nuestro modelo de permisos.
Al igual que la autenticación, tenemos más características de autorización avanzadas que pueden aplicarse a documentos y campos individuales. Puedes crear tus propios plugins de autenticación y autorización, y hasta registrar los eventos de seguridad en el cluster. Puedes usarlos como parte de tu servicio Cloud o ponerte en contacto con nosotros para analizar tus opciones en las instalaciones.
Coloca tu Stack detrás de un VPN o firewall
Anteriormente se aconsejó bastante que coloques el Elastic Stack detrás de un firewall o VPN. Este consejo, en gran medida, se debía a que sin TLS y autenticación podía ser difícil proteger un cluster usando solo un proxy, por lo que simplemente bloquear el acceso a todos era más sencillo que intentar que todos los componentes involucrados estuvieran correctamente configurados.
Si aún deseas hacer esto, incluso con TLS y autenticación habilitados, puede ser una gran idea. La seguridad funciona mejor cuando hay varias capas. La parte buena de esto ahora es que el VPN y el firewall no son la única capa.
Scripts restringidos
En una ocasión, hace tiempo, publicamos un blog sobre la restricción de scripting en Elasticsearch. Con la creación del lenguaje de scripting Painless, es mucho más difícil derribar un cluster, incluso con scripts malintencionados. Sin embargo, no es imposible, y contamos con algunas mejores prácticas en los documentos de seguridad de scripting en los que se analiza nuestra posición actual sobre este tema. Nuevamente, siempre debes revisar tu entorno y tomar las medidas que tengan más sentido en tu caso. La seguridad funciona mejor en capas, por lo que no hay una sola mejor opción.
Aislamiento
Se ha mencionado varias veces el aislamiento de tu cluster y tus nodos por seguridad. Esto incluye desde contenedores y firewalls hasta filtrado IP.
Sigue siendo un excelente consejo; aislar todo lo que puedas es un buen consejo de seguridad. En los últimos años, hemos hecho mucho para facilitar esto más que nunca. Puedes usar nuestras imágenes de contenedor oficiales publicadas en Docker Hub. Puedes aprovechar Elasticsearch Service, y nosotros nos encargaremos del trabajo pesado. Y acabamos de anunciar un Kubernetes Operator oficial al que puedes darle una oportunidad.
Haz una copia de seguridad de tus índices (especialmente de .kibana, porque puede cambiarse con facilidad)
Hacer una copia de seguridad de tus datos sigue siendo tan importante como siempre. La seguridad no cambia esto de ninguna manera, pero sí podemos hacer algunas otras modificaciones.
La principal ventaja es que podemos usar Kibana Spaces para restringir quién puede modificar ciertos dashboards. Esta característica también se lanzó de forma gratuita como parte de las versiones 6.8 y 7.1. Anteriormente, si podías acceder a Kibana, probablemente podías cambiar todo lo que quisieras. No era poco habitual que alguien estropeara los dashboards o incluso que los borrara todos accidentalmente, en algunos casos. Se aconsejaba hacer una copia de seguridad de tus índices .kibana con frecuencia para poder recuperarte de errores con rapidez. Restaurar un índice es mucho más rápido que reconstruir todos tus dashboards. Hacer copias de seguridad de .kibana sigue siendo importante, pero no debería ser necesario restaurarlas con frecuencia gracias a los espacios y la autorización.
Otra gran ventaja de la seguridad es la capacidad de controlar quién puede tomar una snapshot, crear un índice y modificar los datos. Sin la seguridad, un usuario que solo debería ser capaz de leer podría hacer cambios catastróficos en los datos. Con la seguridad habilitada, podemos tomar algunas medidas para prevenir, con suerte, cambios accidentales en datos importantes.
¿Y ahora?
La finalidad de este blog era repasar algunos de nuestros consejos anteriores sobre cómo asegurar tus despliegues del Elastic Stack. En el universo de la seguridad, lo único constante es el cambio. Incluso los consejos de este blog serán antiguos e incorrectos algún día. La seguridad en el Elastic Stack puede ser desalentadora debido a la cantidad de opciones posibles. (Es una característica, no un error). Asegúrate de hacer preguntas en los foros y lee nuestros blogs y documentación.
Si preferirías un método sencillo para asegurar tu Elastic Stack, tenemos algunas opciones. Nuestro Elasticsearch Service incluye TLS configurado para todos los clusters, autenticación y autorización habilitadas, y nuestras características de seguridad de Enterprise habilitadas de forma predeterminada. Si la nube no es lo tuyo, puedes obtener muchas de las mismas características de Elasticsearch Service en tu propio datacenter con Elastic Cloud Enterprise (ECE). También contamos con un Kubernetes Operator que puede ocuparse de algunas tareas pesadas, como habilitar TLS y configurar la autenticación por ti de manera predeterminada. Y, por supuesto, si eres un cliente Enterprise que ejecuta su propio Stack, puedes recurrir a nuestro fantástico equipo de soporte para que te ayuden a solucionar cualquier problema que pueda surgir.
Mantente atento a todo lo que tenemos para el futuro. Tenemos muchos instructivos planificados e incluso muchas características de seguridad nuevas que verás en el futuro. Es un momento muy emocionante para usar el Elastic Stack.