Isolated Storage en Business Central: cómo proteger tus claves y contraseñas correctamente

Cuando desarrollamos extensiones para Business Central, tarde o temprano necesitamos guardar información sensible: una API Key para conectar con un servicio externo, un client secret, una contraseña de acceso a otro sistema. 

La forma más rápida y también la más peligrosa, es meter ese dato directamente en un campo de una tabla. Al final, esa tabla vive en un SQL Server al que, con los permisos adecuados, se puede acceder de mil maneras. Ponerle una máscara al campo para que se vea con asteriscos ayuda a nivel visual, pero no protege realmente el dato.

Business Central tiene una solución pensada exactamente para esto: Isolated Storage. En este artículo vemos qué es, cómo funciona por dentro y cómo implementarlo en una extensión real.

El problema de guardar secretos en una tabla normal

Un campo de texto con ExtendedDatatype = Masked oculta el valor en la interfaz, mostrando asteriscos en lugar del contenido real. Es un buen primer paso, pero tiene un límite claro: cualquiera que cree una página nueva sobre esa misma tabla, sin aplicar la máscara, puede ver el dato en claro. Si alguien con malas intenciones construye su propia extensión apuntando a esa tabla, accede directamente a la clave o contraseña almacenada. La máscara protege la pantalla, no el dato.

Qué es Isolated Storage

Isolated Storage es una tabla del sistema, ya integrada en Business Central, diseñada específicamente para guardar información confidencial de forma segura. No la diseñamos nosotros: viene definida por la plataforma, y se accede a ella mediante unas funciones del sistema con cuatro métodos principales:

• Set: guarda un valor asociado a una clave.
• Get: recupera el valor guardado para una clave.
• Contains: comprueba si existe un valor guardado para una clave.
• Delete: elimina el valor asociado a una clave.

Cada entrada se almacena junto con metadatos de contexto: la extensión que la creó, la empresa y el usuario, además del propio par clave-valor. 

Dónde se nota la diferencia: inspección de página

Si abrimos el inspector de páginas (Ctrl+ALT+F1) sobre un campo enmascarado que apunta a una tabla normal, seguimos viendo asteriscos, lo cual está bien. Pero el problema, como decíamos, no es la interfaz: es que el dato sigue estando accesible desde el modelo de datos subyacente. Con Isolated Storage esto cambia de raíz, porque el valor ni siquiera vive en un campo de tabla estándar: en cuanto lo guardamos, desaparece de cualquier campo visible y pasa a estar gestionado exclusivamente por la codeunit del sistema.

Implementación paso a paso

Un patrón habitual de uso combina los cuatro métodos así:

1. Comprobar si ya existe una clave antes de guardar una nueva

Antes de escribir un valor nuevo conviene comprobar con Contains si ya existe una entrada previa con esa misma clave y, si es así, borrarla con Delete. De esta forma evitamos duplicados o conflictos al sobrescribir.

2. Guardar el valor con Set

Al guardar, el nombre de la clave puede ser algo descriptivo (por ejemplo, ABC External Service API Key), y el valor se recomienda envolverlo en un tipo SecretText en lugar de un texto normal. La ventaja de SecretText es que su contenido no se puede inspeccionar ni siquiera depurando la extensión paso a paso: el valor permanece oculto durante todo su ciclo de vida, no solo en la base de datos.

3. Leer el valor con Get

Cuando la extensión necesita usar la clave, por ejemplo, para autenticar una llamada HTTP a un servicio externo, primero comprueba con Contains que existe, y después recupera el valor con Get, idealmente también como SecretText, para que el dato siga sin poder visualizarse aunque alguien intente depurar el proceso.

Una capa extra de protección: procedimientos Internal

Guardar el dato en Isolated Storage no es suficiente si cualquiera puede crear una extensión que llame directamente a nuestros procedimientos de lectura. Por eso conviene declarar la codeunit que encapsula el acceso a Isolated Storage, o al menos sus procedimientos de lectura, como Internal. Así, ni siquiera una extensión que dependa de la nuestra podrá invocar esos métodos desde fuera y obtener el valor. Es una capa adicional que reduce la superficie de ataque incluso si alguien conoce la existencia de la clave.

Casos de uso típicos

Isolated Storage es especialmente útil para todo lo que hoy es habitual en el desarrollo de extensiones: API Keys de servicios externos, client secrets de integraciones OAuth, y credenciales para llamadas a servicios de IA como GPT o Azure AI. Con la cantidad de integraciones que conectamos hoy en día a Business Central, tener un mecanismo nativo y seguro para este tipo de datos deja de ser opcional.

Conclusión

Isolated Storage resuelve un problema real: cómo guardar credenciales dentro de una extensión de Business Central sin exponerlas en una tabla accesible desde SQL. Combinando los métodos Set, Get, Contains y Delete con el tipo SecretText y procedimientos declarados como Internal, conseguimos que ni la base de datos, ni el depurador, ni una extensión de terceros puedan leer directamente esa información. Si tu extensión maneja API Keys, client secrets o cualquier dato confidencial, este es el camino a seguir en lugar de un campo de texto con máscara.

Puedes ver el video aquí: