La protección de datos en Microsoft Dynamics 365 Business Central SaaS es un pilar fundamental en cualquier implementación empresarial moderna. No se trata únicamente de cumplir con normativas como GDPR, sino de garantizar la integridad, confidencialidad y disponibilidad de la información en un entorno multi-tenant altamente distribuido.

En Business Central, los datos sensibles incluyen:

  • información financiera
  • datos personales (clientes, empleados)
  • credenciales e identificadores
  • información fiscal
  • datos de transacciones

El desafío no es solo proteger estos datos en almacenamiento, sino también durante:

  • procesamiento
  • transmisión
  • exposición a través de APIs
  • acceso desde extensiones personalizadas

El desarrollador tiene un rol crítico en este proceso, ya que muchas vulnerabilidades surgen en la capa de aplicación (AL) y no en la infraestructura.

Problema Link to heading

Los errores más comunes en protección de datos incluyen:

  • almacenamiento de datos sensibles en texto plano
  • exposición innecesaria en APIs
  • logs con información confidencial
  • falta de control de acceso en código
  • uso incorrecto de tablas temporales
  • no limpiar datos en memoria

Un caso típico:

  • guardar tokens o contraseñas en tablas personalizadas sin cifrado
  • exponer campos sensibles en una API sin filtrado

Resultado:

  • riesgo de fuga de información
  • incumplimiento normativo
  • vulnerabilidades explotables

Principios de protección de datos Link to heading

1. Minimización de datos Link to heading

Solo almacenar lo estrictamente necesario.

Evitar:

  • duplicación de datos sensibles
  • almacenamiento redundante

2. Principio de menor exposición Link to heading

No exponer datos si no es necesario.

3. Protección en tránsito Link to heading

Toda comunicación externa debe usar HTTPS.

4. Protección en reposo Link to heading

Evitar almacenar información sensible sin protección.

5. Control de acceso Link to heading

Validar permisos en cada operación crítica.

Estrategias en AL Link to heading

Evitar almacenar datos sensibles en texto plano Link to heading

Incorrecto:

table 50100 UserSecrets
{
    fields
    {
        field(1; Password; Text[100]) { }
    }
}

Correcto: usar hashing o almacenamiento externo.

Uso de Isolated Storage Link to heading

var
    IsolatedStorage: Codeunit "Isolated Storage";
    Key: Text;
    Value: Text;
begin
    Key := 'API_KEY';
    Value := 'secure-token';

    IsolatedStorage.Set(Key, Value);
end;

Esto evita exponer datos directamente en tablas.

Lectura segura Link to heading

var
    Value: Text;
begin
    if IsolatedStorage.Get('API_KEY', Value) then
        // usar valor
end;

Protección de APIs Link to heading

Evitar exponer campos sensibles:

page 50100 CustomerAPI
{
    PageType = API;
    SourceTable = Customer;

    layout
    {
        area(Content)
        {
            field(Name; Name) { }
            field("E-Mail"; "E-Mail") { }
        }
    }
}

No incluir campos como:

  • crédito
  • datos fiscales sensibles

Validación de permisos Link to heading

if not Customer.ReadPermission() then
    Error('Access denied');

Enmascaramiento de datos Link to heading

procedure MaskEmail(Email: Text): Text
begin
    exit(CopyStr(Email, 1, 3) + '***');
end;

Logs seguros Link to heading

Evitar:

Message('User token: %1', Token);

Usar:

Message('Operation completed');

Manejo de datos en memoria Link to heading

Evitar mantener datos sensibles en variables globales.

Limpiar después de uso:

Clear(Token);

Uso de Azure Key Vault Link to heading

Para escenarios avanzados:

  • almacenar secretos fuera de BC
  • acceder mediante servicios externos

Protección en integraciones Link to heading

Nunca enviar:

  • credenciales en texto plano
  • tokens sin cifrado

Ejemplo:

HttpClient.DefaultRequestHeaders.Add('Authorization', 'Bearer ' + Token);

Asegurar:

  • uso de HTTPS
  • expiración de tokens

Anti-patterns críticos Link to heading

  • guardar contraseñas en tablas
  • exponer APIs sin validación
  • logs con datos sensibles
  • no limpiar variables
  • permisos excesivos

Estrategias avanzadas Link to heading

Data classification Link to heading

Usar clasificación de datos en campos:

field(1; Email; Text[100])
{
    DataClassification = CustomerContent;
}

Esto ayuda en cumplimiento normativo.

Auditoría Link to heading

Registrar accesos a datos críticos.

Segregación de datos Link to heading

Separar datos sensibles en tablas específicas.

Buenas prácticas Link to heading

  • cifrar o externalizar datos sensibles
  • validar acceso siempre
  • minimizar exposición
  • usar clasificación de datos
  • auditar accesos
  • evitar logs sensibles

Conclusiones Link to heading

La protección de datos en Business Central no es opcional. Es un requisito fundamental para cualquier solución empresarial.

El desarrollador debe asumir responsabilidad activa en:

  • cómo se almacenan los datos
  • cómo se procesan
  • cómo se exponen

Un diseño correcto permite:

  • seguridad
  • cumplimiento
  • confianza

Mientras que un diseño incorrecto puede comprometer todo el sistema.

La protección de datos no es una funcionalidad, es una disciplina.