Seguridad Técnica de
Bases de Datos
Implementación especializada de controles de seguridad sobre SQL Server y Oracle para proteger datos personales sensibles y cumplir la Ley 21.719.
Un equipo técnico certificado que trabaja directamente sobre tu infraestructura de bases de datos. No solo asesoría — implementación real, validada y documentada.
El servicio técnico que la normativa exige
La Ley 21.719 no solo exige documentación y políticas. Exige controles técnicos
reales implementados sobre las bases de datos donde vive la información de las personas.
IDATA Chile opera directamente sobre tu infraestructura con un equipo especializado en SQL Server y Oracle, activando las herramientas nativas de cada plataforma para cumplir los requisitos técnicos de la ley sin necesidad de cambiar tus sistemas.
Implementación real
No solo recomendaciones escritas. Trabajamos sobre tus bases de datos en producción y ambientes controlados.
Plataformas nativas
Usamos las herramientas propias de SQL Server y Oracle. Sin software adicional innecesario.
Evidencias para la Agencia
Cada control implementado queda documentado con evidencias técnicas formales lisas para fiscalización.
Equipo certificado
Profesionales con certificaciones en SQL Server (DP-300, AZ-500) y Oracle (OCP) con experiencia real.
4 capas de seguridad sobre tus bases de datos
Cada capa responde a un artículo específico de la Ley 21.719
TDE — Transparent Data Encryption
Cifrado en reposo · AES-256TDE cifra los archivos físicos de la base de datos con AES-256 de forma completamente transparente para las aplicaciones. Cualquier intento de acceso directo al filesystem, robo del disco, copia de backup no autorizada o acceso al almacenamiento físico, devuelve datos completamente ilegibles sin la clave maestra.
Jerarquía de cifrado
Alcance de la protección
TDE protege
TDE no protege
Comandos clave de implementación
-- 1. Crear clave maestra de base de datos (instancia) USE master; CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'P@ssw0rd!Seguro2026'; -- 2. Crear certificado protector de la DEK CREATE CERTIFICATE TDE_IDATA_Prod WITH SUBJECT = 'TDE Certificate - Produccion 2026', EXPIRY_DATE = '2028-12-31'; -- 3. Crear la Database Encryption Key en cada BD sensible USE [BD_Pacientes]; CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_256 ENCRYPTION BY SERVER CERTIFICATE TDE_IDATA_Prod; -- 4. Activar TDE — el cifrado ocurre en background ALTER DATABASE [BD_Pacientes] SET ENCRYPTION ON; -- 5. Verificar estado de cifrado SELECT name, encryption_state, percent_complete FROM sys.dm_database_encryption_keys; -- 6. CRÍTICO: respaldar el certificado FUERA del servidor BACKUP CERTIFICATE TDE_IDATA_Prod TO FILE = '\\backup-seguro\TDE_Cert.cer' WITH PRIVATE KEY (FILE = '\\backup-seguro\TDE_Cert.key', ENCRYPTION BY PASSWORD = 'BackupKey!2026');
Lo que implementamos
- Service Master Key y certificado TDE por instancia
- DEK en cada BD que contiene datos personales o sensibles
- Cifrado de backups automático verificado
- Backup del certificado en ubicación externa segura
- Rotación programada de certificados
- Oracle: configuración de Keystore (wallet) y cifrado de tablespaces
- Documentación de procedimiento de emergencia para pérdida de clave
DDM — Dynamic Data Masking / Oracle Data Redaction
Minimización de exposición · Transparente para apps
DDM intercepta los resultados de consultas SELECT y aplica enmascaramiento en tiempo real según el rol del usuario que realiza la consulta. Los datos residen sin modificación en disco (complementa TDE, no lo reemplaza). Un analista de BI que ejecuta SELECT * FROM Pacientes ve XXXXXXXXXXX donde debería aparecer el RUT, mientras que el sistema clínico con el rol adecuado sigue viendo el dato real sin ningún cambio de código.
Funciones de enmascaramiento — ejemplos en datos chilenos
| Campo | Dato real | Enmascarado | Función DDM / Redaction | |
|---|---|---|---|---|
| RUT | 12.345.678-9 | → | 1X.XXX.XXX-X | partial(1, 'X.XXX.XXX-', 1) |
| juan@clinica.cl | → | jXXX@XXXX.cl | email() | |
| Teléfono | +56 9 8765 4321 | → | +56 9 XXXX XXXX | partial(6, 'XXXX XXXX', 0) |
| Salario | 1.850.000 | → | 0 | default() |
| Diagnóstico | Diabetes tipo 2 | → | XXXX | default() / FULL (Oracle) |
Implementación — SQL Server T-SQL
-- Aplicar mascaramiento sobre columnas sensibles existentes ALTER TABLE dbo.Pacientes ALTER COLUMN RUT ADD MASKED WITH (FUNCTION = 'partial(1, "X.XXX.XXX-", 1)'); ALTER TABLE dbo.Pacientes ALTER COLUMN Email ADD MASKED WITH (FUNCTION = 'email()'); ALTER TABLE dbo.Pacientes ALTER COLUMN Diagnostico ADD MASKED WITH (FUNCTION = 'default()'); -- Otorgar permiso de ver datos reales a usuarios autorizados -- (SQL Server 2022 permite a nivel de columna) GRANT UNMASK ON dbo.Pacientes(RUT) TO [rol_medico_tratante]; GRANT UNMASK ON dbo.Pacientes(Diagnostico) TO [rol_medico_tratante]; -- Verificar máscaras activas SELECT t.name AS tabla, c.name AS columna, c.masking_function FROM sys.masked_columns c JOIN sys.tables t ON t.object_id = c.object_id;
Lo que implementamos
- Identificación y clasificación de columnas PII y sensibles en todas las tablas
- Función de máscara adecuada para cada tipo de dato (RUT, email, IBAN, diagnóstico)
- Definición de roles con permiso UNMASK para usuarios autorizados
- Oracle: políticas DBMS_REDACT por tabla y columna con tipos FULL / PARTIAL
- Validación en ambientes no productivos de que el enmascaramiento es efectivo
- DDM aplicado también a vistas y stored procedures que exponen datos
db_owner o permiso CONTROL. Por eso DDM se combina con RLS (capa 3) y una RBAC estricta.
RLS — Row-Level Security / Oracle VPD
Control granular a nivel de fila · Predicados de filtro y bloqueo
RLS implementa un WHERE clause automático e invisible que el motor de base de datos agrega a cada consulta sin que la aplicación lo sepa ni lo controle. El mecanismo garantiza que un ejecutivo de sucursal nunca pueda acceder —ni accidentalmente ni por consulta directa— a registros de otra sucursal, aunque ejecute un SELECT * FROM Clientes sin filtros.
Tipos de predicados en SQL Server
Implementación — caso clínico (paciente por médico tratante)
-- 1. Función de predicado (Inline TVF) -- Devuelve 1 (permitido) si el médico en sesión atiende al paciente CREATE FUNCTION dbo.fn_FiltroMedicoTratante(@MedicoID INT) RETURNS TABLE WITH SCHEMABINDING AS RETURN SELECT 1 AS resultado WHERE -- Médico autenticado en la aplicación (via SESSION_CONTEXT) @MedicoID = CAST(SESSION_CONTEXT(N'MedicoID') AS INT) -- O usuario con rol administrativo explícito OR IS_ROLEMEMBER('rol_jefatura_medica') = 1 OR IS_ROLEMEMBER('db_owner') = 1; GO -- 2. Crear la Security Policy asociando la función a la tabla CREATE SECURITY POLICY dbo.Policy_PacientesPorMedico ADD FILTER PREDICATE dbo.fn_FiltroMedicoTratante(MedicoID) ON dbo.Pacientes, ADD BLOCK PREDICATE dbo.fn_FiltroMedicoTratante(MedicoID) ON dbo.Pacientes AFTER INSERT WITH (STATE = ON); -- 3. La aplicación establece el contexto de sesión al autenticar EXEC sys.sp_set_session_context 'MedicoID', @id_medico_autenticado;
Equivalente Oracle — Virtual Private Database (VPD)
-- Función que retorna el predicado WHERE dinámico CREATE OR REPLACE FUNCTION fn_vpd_medico( p_schema VARCHAR2, p_object VARCHAR2) RETURN VARCHAR2 IS BEGIN RETURN 'MEDICO_ID = SYS_CONTEXT(''USERENV'', ''CLIENT_IDENTIFIER'')'; END; / -- Asociar la política VPD a la tabla BEGIN DBMS_RLS.ADD_POLICY( object_schema => 'SALUD', object_name => 'PACIENTES', policy_name => 'POL_PACIENTE_MEDICO', function_schema => 'SALUD', policy_function => 'FN_VPD_MEDICO', statement_types => 'SELECT, INSERT, UPDATE, DELETE', policy_type => DBMS_RLS.CONTEXT_SENSITIVE ); END;
Lo que implementamos
- Análisis del modelo de negocio y mapa de «quién debe ver qué»
- Función de predicado personalizada por caso de uso (paciente/médico, cliente/sucursal, empleado/empresa)
- FILTER PREDICATE para SELECT y BLOCK PREDICATE para escrituras
- Oracle: políticas VPD tipo CONTEXT_SENSITIVE para máxima flexibilidad
- Integración con el sistema de autenticación de la aplicación (SESSION_CONTEXT / CLIENT_IDENTIFIER)
- Pruebas de penetración de BD para validar que la política no puede ser bypasseada
SQL Server Audit / Oracle Unified Auditing
Trazabilidad completa · Evidencia forenseLa auditoría de BD es la única fuente de verdad para responder en 72 horas a la Agencia de Protección de Datos: ¿qué datos fueron accedidos, por quién, cuándo, desde qué IP y con qué operación? Sin ella, una brecha no puede ser cuantificada y la notificación legal es imposible. El registro de auditoría también es el principal instrumento forense ante una investigación.
Action Groups que configuramos en SQL Server Audit
Configuración — SQL Server Server Audit
-- 1. Crear el destino de auditoría (archivo rotativo) CREATE SERVER AUDIT [IDATA_PII_Audit] TO FILE ( FILEPATH = 'D:\Audits\PII\', MAXSIZE = 200 MB, MAX_ROLLOVER_FILES = 24, -- 24 archivos = ~12 meses RESERVE_DISK_SPACE = ON ) WITH ( ON_FAILURE = CONTINUE, AUDIT_GUID = '...' ); ALTER SERVER AUDIT [IDATA_PII_Audit] WITH (STATE = ON); -- 2. Especificación de BD — acceso granular a tablas PII CREATE DATABASE AUDIT SPECIFICATION [Spec_PII_Access] FOR SERVER AUDIT [IDATA_PII_Audit] ADD (SELECT, INSERT, UPDATE, DELETE ON dbo.Pacientes BY PUBLIC), ADD (SELECT ON dbo.DatosFinancieros BY PUBLIC), ADD (EXECUTE ON dbo.sp_ExportarPacientes BY PUBLIC), ADD (DATABASE_OBJECT_ACCESS_GROUP), ADD (DATABASE_CHANGE_GROUP) WITH (STATE = ON); -- 3. Consulta forense ante incidente SELECT event_time, server_principal_name, database_name, object_name, action_id, statement, client_ip FROM sys.fn_get_audit_file('D:\Audits\PII\*.sqlaudit', DEFAULT, DEFAULT) WHERE object_name = 'Pacientes' AND event_time BETWEEN '2026-05-01' AND '2026-05-31' ORDER BY event_time DESC;
Cómo la auditoría activa habilita el cumplimiento de 72 horas
Lo que implementamos
- Server Audit con destino a archivo rotativo (mínimo 12 meses retención)
- Database Audit Specification para cada tabla y SP con datos PII
- Alertas automáticas por exportaciones masivas (> N registros en una sesión)
- Alerta por accesos fuera de horario laboral y desde IPs no autorizadas
- Oracle: Unified Audit Policy con ACTIONS SELECT/INSERT/UPDATE/DELETE sobre tablas críticas
- Dashboard de monitoreo con revisión mensual documentada
- Procedimiento forense 72h: guía paso a paso para uso del log ante una brecha real
Compatibilidad técnica por plataforma y versión
Cada control disponible según la versión y edición de tu base de datos
| Técnica | SS 2016 | SS 2019 | SS 2022 | Ora 12c EE | Ora 19c EE | Ora 21c EE | Ora 23c EE |
|---|---|---|---|---|---|---|---|
| TDE nativo | ⚠️ Solo EE | ✅ SE+EE | ✅ SE+EE | ⚠️ Con ASO | ⚠️ Con ASO | ⚠️ Con ASO | ⚠️ Con ASO |
| Dynamic Data Masking | ✅ | ✅ | ✅ | ✅ Data Redaction | ✅ | ✅ | ✅ |
| Row-Level Security | ✅ | ✅ | ✅ | ✅ VPD | ✅ VPD | ✅ VPD | ✅ VPD |
| Always Encrypted | ✅ | ✅ AE v2 | ✅ AE v2 | N/A | N/A | N/A | N/A |
| Unified Auditing | N/A | N/A | N/A | ✅ | ✅ | ✅ | ✅ |
| SQL Server Audit | ✅ | ✅ | ✅ | N/A | N/A | N/A | N/A |
| Data Classification | ⚠️ Manual | ✅ Nativo | ✅ Nativo | ⚠️ Manual | ✅ | ✅ | ✅ |
| AE con Secure Enclaves | ❌ | ⚠️ SGX (hardware especial) | ✅ VBS nativo | N/A | N/A | N/A | N/A |
| UNMASK granular por columna | ❌ | ❌ Solo UNMASK global | ✅ SS 2022+ | N/A | N/A | N/A | N/A |
| Transport Encryption (TLS) | ✅ TLS 1.2 | ✅ TLS 1.2 | ✅ TLS 1.3 | ✅ | ✅ | ✅ | ✅ |
| Oracle Database Vault | N/A | N/A | N/A | ⚠️ DVA option + EE | ⚠️ DVA option + EE | ✅ Incluido en EE | ✅ Incluido en EE |
| Ledger / Blockchain Tables | ❌ | ❌ | ✅ Ledger Tables | N/A | N/A | ⚠️ Blockchain Tables | ✅ Nativo |
EE = Enterprise Edition · SE = Standard Edition · ASO = Oracle Advanced Security Option · VPD = Virtual Private Database · AE = Always Encrypted
Equipo certificado en SQL Server y Oracle
Profesionales con experiencia real en implementación, no solo consultoría
Especialidad: TDE, Always Encrypted, RLS, SQL Audit
Versiones: SQL Server 2016 / 2019 / 2022
Especialidad: TDE (ASO), VPD, Unified Auditing, Data Redaction
Versiones: Oracle 12c / 19c / 21c / 23c Enterprise Edition
Especialidad: Pseudonimización, anonimización, pipelines de datos seguros
Herramientas: Python, T-SQL, PL/SQL, SSIS
Especialidad: Diseño de arquitecturas de seguridad de datos, KMS, gestión de claves
Foco: Entornos mixtos Oracle + SQL Server
Especialidad: Ley 21.719, GDPR, RAT, EIPD, documentación de cumplimiento
Rol: DPO externo para sector salud y financiero
Especialidad: Validación de controles, pruebas de penetración en BD, auditoría independiente
Foco: Verificación de evidencias para la Agencia de Protección de Datos
8 módulos de implementación técnica
- Inventario automatizadoIdentificación de todos los servidores y bases de datos en tu infraestructura.
- Columnas con datos personalesIdentificación de columnas con datos personales y sensibles (RUT, salud, biometría, financiero).
- Estado actual de controlesEvaluación de TDE activo, auditoría configurada, DDM y RLS presentes.
- Análisis de versiones y edicionesDeterminación de controles disponibles sin costo adicional según tu licenciamiento actual.
- Impacto en aplicacionesEvaluación de aplicaciones conectadas y su compatibilidad con los controles a implementar.
Entregables
- Scripts T-SQL y PL/SQLEnmascaramiento personalizado por tipo de dato para SQL Server y Oracle.
- Tokenización con integridad referencialPreservación de relaciones entre tablas durante el proceso de enmascaramiento.
- Pipeline Producción → Dev/QAAutomatización del refresh de ambientes con datos enmascarados.
- DDM en ambientes no productivosDynamic Data Masking configurado en todos los ambientes secundarios.
- Validación de exposiciónVerificación de que ningún dato real queda expuesto en ambientes de desarrollo.
Entregables
- Técnicas estándark-anonimato, generalización, supresión y perturbación aplicadas según el tipo de dato.
- Diseño del modelo de anonimizaciónPreservación de utilidad estadística para análisis de negocio.
- Pipeline automatizado de datasetsGeneración automática de conjuntos de datos analíticos sin información de identificación personal.
- Test de re-identificaciónValidación con metodología estándar de que los datos son verdaderamente anónimos.
Entregables
- TDE según sensibilidadActivación de TDE en producción diferenciada por nivel de sensibilidad de cada BD.
- Always Encrypted para datos críticosCifrado de columnas de salud, biometría y datos financieros de alta sensibilidad.
- Oracle Advanced Security / alternativas SEImplementación según edición disponible, con alternativas documentadas para Standard Edition.
- Gestión centralizada de claves (KMS)Rotación, custodia y procedimiento de emergencia para todas las claves de cifrado.
- Cifrado de backups y exportsProtección de copias de respaldo en todas las plataformas.
Entregables
- Auditoría completa de usuarios y privilegiosRevisión de cuentas, roles y permisos existentes en todos los servidores.
- Eliminación de accesos innecesariosDesactivación de cuentas inactivas y revocación de privilegios excesivos.
- Matriz RBAC alineada al organigramaDiseño e implementación de roles alineados al principio de mínimo privilegio.
- Row-Level Security / Oracle VPDControl de acceso a nivel de fila según identidad y rol del usuario.
- Procedimiento formal de gestión de accesosProceso documentado de alta, baja y modificación de accesos a bases de datos.
Entregables
- SQL Server Audit completoEspecificaciones de servidor y base de datos para todos los objetos con datos personales.
- Oracle Unified AuditingConfiguración de Oracle Unified Auditing (12c+) o Fine-Grained Auditing en versiones anteriores.
- Alertas ante accesos anómalosNotificaciones automáticas por accesos fuera de horario, exportaciones masivas o patrones inusuales.
- Retención de logs configuradaPolítica de retención mínima de 12 meses recomendada, según requerimientos legales.
- Dashboard de monitoreoPanel de control de accesos a datos personales para el equipo de seguridad.
Entregables
- Registro de Actividades de Tratamiento (RAT) técnicoInventario formal de todos los tratamientos de datos personales sobre BD corporativas.
- Informe de Cumplimiento Ley 21.719Evidencias técnicas formales de cada control implementado, listo para presentar a la Agencia.
- Manual de Respuesta ante BrechasProtocolo de 72 horas con árbol de decisión para notificación a la Agencia y a los titulares.
- Política de Privacidad TécnicaPolítica interna y procedimientos documentados para el tratamiento de datos en BD.
Entregables
- Taller equipo técnico — 8 horasPara DBAs, desarrolladores y analistas: controles implementados, operación y mantenimiento.
- Taller DPO / Encargado de Privacidad — 4 horasMarco legal, controles técnicos, lectura de auditorías y protocolos de respuesta.
- Simulacro de brecha de seguridadTabletop exercise: ejercicio de respuesta ante un incidente real para validar el protocolo de 72 horas.
Entregables
Inversión según escala de infraestructura
El precio fijo definitivo se determina tras el diagnóstico técnico gratuito.
1–2 servidores · Hasta 5 BD · Hasta 500K registros PII
- Duración: 10 – 14 semanas
- Equipo: 3 especialistas
- Hasta 5 bases de datos
- 8 módulos completos
- Diagnóstico gratuito incluido
3–6 servidores · 6–20 BD · Hasta 5M registros PII
- Duración: 16 – 22 semanas
- Equipo: 5 – 6 especialistas
- 6 a 20 bases de datos
- 8 módulos completos
- Entornos mixtos SQL Server + Oracle
- Diagnóstico gratuito incluido
7+ servidores · 21+ BD · +5M registros PII
- Duración: 24 – 36 semanas
- Equipo: 8 – 10 especialistas
- 21 o más bases de datos
- 8 módulos completos
- Multi-plataforma y ambientes cloud
- Diagnóstico gratuito incluido
Sectores donde implementamos este servicio
Salud y clínicas
Datos de pacientes, fichas clínicas, historial médico. Datos sensibles según Art. 16 de la Ley 21.719.
Datos sensibles Art. 16Sector financiero y seguros
Datos bancarios, RUT, historial crediticio e información patrimonial de clientes y contratantes.
Mutual y seguridad laboral
Datos de accidentes, enfermedades profesionales e historiales de trabajadores en mutualidades.
Datos sensibles Art. 16Retail y e-commerce
Bases de clientes, historial de compras y datos de pago a gran escala.
Recursos humanos y outsourcing
Datos laborales, remuneraciones y evaluaciones de desempeño de trabajadores.
Salud estética y bienestar
Fichas clínicas estéticas, fotografías de evolución e historial de tratamientos.
Datos sensibles Art. 16¿Cuál servicio necesitas?
Diferencias entre nuestro servicio de Protección de Datos para PYMEs y este servicio técnico de BD
| Protección de Datos (PYMEs) | Seguridad de BD (Corporativo) | |
|---|---|---|
| Enfoque | Normativo-legal | Técnico-implementación |
| Dirigido a | PYMEs, comercios, clínicas pequeñas | Organizaciones con BD corporativas |
| Plataformas | Sistemas generales | SQL Server y Oracle específicamente |
| Entregables | Políticas, procedimientos, capacitación | Scripts, configuraciones, controles activos |
| Equipo | Consultor de privacidad + DPO | DBA Senior + Arquitecto + Ing. de Datos |
| Precio | Desde 25 UF | Desde 220 UF |
¿No estás seguro cuál necesitas? Contáctanos y te orientamos sin costo.
Consulta orientativa gratuitaPreguntas frecuentes
Dic 2026 · Ley 21.719
¿Listo para proteger tu infraestructura de datos?
Agenda una sesión técnica gratuita. Revisamos tu infraestructura actual
y en 5 días hábiles tienes un precio fijo y un plan de acción.
Sin compromiso. Sin acceso a datos reales.