Buenas prácticas y seguridad de un validador
Con esta guía pretendemos dar recomendaciones orientadas a las buenas prácticas de seguridad tanto en los servidores, como en el software de configuración de un validador; llegando hasta la perspectiva de operación de las consolas de nuestros proveedores de servicio (cloud providers).
Recomendaciones de seguridad.
Cuando se habla de seguridad en servidores casi siempre lo referenciamos con reglas de Firewall, sistemas anti DDOS, credenciales de acceso, puerto, etc. Pero olvidamos la administración de la consola de logueo al proveedor de nuestros servicios. Es decir, cuando utilizamos proveedores como amazon, google cloud, ovh ó cualquier otro; una vez estamos registrados tenemos unas credenciales de acceso en sus consolas las cuales nos dan total administración de los recursos (crear máquinas, redimensionar hardware, eliminar, conectarnos y hasta restaurar estos recursos a su punto de origen).
Aquí es muy importante elementos como:
Perfiles de los usuarios, con sus niveles de privilegios.
Doble factor de autenticación 2FA.
Almacenamiento de las credenciales de acceso.
Tiempos de vigencia de las contraseñas y estándar de las mismas.
La forma de acceder a la consola. Dejando los accesos registrados para evitar ataques phishing.
Se recomienda también tener algún antivirus y hacer análisis periódicamente del sistema, así como no descargar softwares pirata o que requieran algún crack para su activación en la máquina utilizada para estas conexiones, ya que estos son famosos por siempre tener algún tipo de malware en su interior, como puede ser:
keyloggers.
Troyanos.
Spyware.
Wallet fría.
Las Wallet frías están basadas en hardware y sirven para almacenar las claves privadas que nos permiten acceso a los activos de una manera mucho más segura, esta wallet solo estará en línea cuando se requiera su uso y todas las autorizaciones se aprueban desde el dispositivo físico. Hay distintas marcas de wallet frías en el mercado, entre las más conocidas son:
Ledger.
Trezor.
Estas billeteras se recomiendan para almacenar las claves privadas de los validadores, ya que son mucho más seguras y no tienen que estar todo el tiempo en línea en los servidores que prestan el servicio de validación como las billeteras calientes.
Actualización de información.
Los proyectos blockchain al ser una tecnología emergente y con mucho desarrollo detrás, constantemente están sacando actualizaciones para sus cadenas, estas actualizaciones son con el fin de mejorar la cadena y hacerla más robusta. Los validadores tienen un deber de estar enterados de las nuevas actualizaciones y el curso que está tomando cada proyecto.
Para estar constantemente enterados de las novedades se recomienda tener una rutina diaria de revisión a los proyectos en sus canales más usados, estos canales pueden ser:
Discord.
Twitter.
Chat de telegram.
Blog.
Medium.
Gobernanza.
Una buena pŕactica de un validador es siempre estar pendiente de las propuestas de gobernanza de cada cadena, estas se encargan de tomar decisiones frente al camino del proyecto en todos sus aspectos; económico, técnico, social, etc. Las blockchains permiten tener un sistema participativo de votaciones en las decisiones de todos los holders del token, cada validador puede votar sobre cualquier propuesta de gobernanza activa en la red y su poder de votación será el total de sus tokens más los tokens que tiene delegados por todos sus delegadores. Cuando un delegador vota sobre una misma propuesta que ha votado su validador, el voto que hizo el validador se sustituye en el poder de votación de dicho delegador.
Archivo Config.toml
Es importante que un nodo de validación comparta la menor cantidad de datos importantes por la red P2P ya que esta puede llegar a ser llamativa para personas mal intencionadas, en el archivo config.toml hay una configuración llamada Moniker el cual por defecto, al instalar el validador es necesario correr el comando “init <Moniker> –chain_id <Id de la cadena>” esto hará que el valor de moniker se registre en el archivo config.toml, pero esta información al momento de tener el nodo corriendo queda expuesta, y puede ser de mucho interés para mal intencionados, ya que al saber la identidad de un nodo de validación, pueden enfocarse en intentar vulnerar al validador.
Descentralización de las llaves
En el ecosistema de Cosmos, con una misma llave se pueden tener una wallets de distintas redes, una muy mala práctica es usar la misma llave para diferentes validadores, es decir, un validador en juno, uno en stargaze, uno en cosmos hub, etc y todos con la misma llave, esto es centralizar la seguridad, lo que hará que si en algún momento se ve comprometida la llave, todos los validadores estarán comprometidos.
Para solucionar esto se recomienda usar una llave diferente para cada validador, esto descentraliza la seguridad y en caso de riesgo el daño será mucho menor.
Módulo Authz
Algo recomendable es firmar la mínima cantidad de veces con la key del validador, es decir, con la llave con la que está creada el validador, ya que esta muy importante y no puede estar expuesta a vulnerabilidades, esto debido a que esta no se puede modificar, si por algún motivo la key del validador es expuesta, este validador quedará totalmente inservible, para solucionar esto dentro del SDK de cosmos existe la funcionalidad Authz, esta permitirá delegar a otras llaves los permisos de rewards y de gobernanza, esto con el fin de no estar firmando cada propuesta y cada envío de recompensas con la llave del validador.
Authz Recompensas:
Para otorgar permisos de recibir recompensas a otra billetera se usan los siguientes comandos:
Para utilizarla y reclamar recompensas con la billetera nueva:
Authz Gobernanza:
Para otorgar permisos de gobernanza a otra billetera se usa el siguiente comando:
y para utilizarla:
Last updated