SOFTWARE AUDITABLE Fundamentos Teóricos, Técnicos y Regulatorios by Editorial Universidad Técnica del Norte UTN

Diego JavierTrejo España Diego Javier Trejo España Iván Danilo GarcíaSantillán Iván Danilo García Santillán

FundamentosTeóricos,TécnicosyRegulatorios

DiegoJavierTrejoEspaña

IvánDaniloGarcíaSantillán

FundamentosTeóricos,TécnicosyRegulatorios

DiegoJavierTrejoEspaña

IvánDaniloGarcíaSantillán

EditorialUniversidadTécnicadelNorte

Av.17deJulio,5-21.CampuslosOlivos

Ibarra–Imbabura-RepúblicadelEcuador

Telf.593(6)2997800

URL: www.utn.edu.ec

Editorial: editorial@utn.edu.ec

Paresrevisoresacadémicosexternos

Mgs.DarwinPilloGuanoluisa dmpillo@pucesi.edu.ec

PUCE-Ibarra

Mgs.SegundoPusdáChulde sepusda@pucesi.edu.ec

PUCE-Ibarra

Revisióndeestilo

Mgs.SilviaArciniegaHidrobo srarciniega@utn.edu.ec

UTN-Ibarra

Cómocitarlaobracompleta

Trejo-España,D.yGarcía-Santillán,I.(2026).Software auditable:Fundamentosteóricos,técnicosyregulatorios. EditorialUniversidadTécnicadelNorte(UTN).

Direccióndearteydiagramación

PedroDavidCarguaGualoto pdcarguag@utn.edu.ec

UniversidadTécnicadelNorte,Ecuador

Númerodepáginas

145

DOI: 10.53358/libfica/NYDE4146

ROR: https://ror.org/03f0t8b71

ImpresoenEcuador/PrintedinEcuador

Prohibidalareproduccióntotaloparcialdeestaobrasinlaprevia autorizaciónescritadelaEditorialUniversidadTécnicadelNorte.

Autores

DiegoJavierTrejoEspaña

UniversidadTécnicadelNorte,Ecuador

https://orcid.org/0000-0002-2973-4345

djtrejo@utn.edu.ec

IvánDaniloGarcíaSantillán

UniversidadTécnicadelNorte,Ecuador

https://orcid.org/0000-0001-6404-5185

idgarcia@utn.edu.ec

DIEGOJAVIER TREJOESPAÑA

AUTORES

MagísterenGerenciaInformática–Pontificia UniversidadCatólicadelEcuador. IngenieroenSistemasComputacionales.

DocenteaTiempoCompleto–CarreradeIngenieríaenSistemasComputacionales,UTN. Consultorentecnologíaygestióndeproyectos informáticos.

djtrejo@utn.edu.ec https://orcid.org/0000-0002-2973-4345

IVÁNDANILO GARCÍASANTILLÁN

IngenieroenSistemasInformáticos. Ph.D.enIngenieríaInformática–Universidad ComplutensedeMadrid,España. MaestríaenGerenciaInformática. DiplomaenDocenciaUniversitaria.

Profesorasociado–CarreradeSistemasInformáticos,UTN. InvestigadoracreditadoporSENESCYT.

Experienciaendocenciauniversitaria,desarrollodesistemasydireccióndeproyectos deinvestigaciónenIngenieríadeSoftwaree InteligenciaArtificial. Publicacionescientíficasenrevistasdealto impactoyparticipaciónencongresosinternacionales.

Áreasdeinterés:InteligenciaArtificial,MineríadeDatos,BigData,AprendizajeAutomático,AprendizajeProfundoyCienciadeDatos.

idgarcia@utn.edu.ec https://orcid.org/0000-0001-6404-5185

Notasobreherramientasdeasistencia

Laredaccióndeestedocumentoserealizóconasistenciade herramientasdeinteligenciaartificialparaoptimizacióndeestilo yestructuradetexto.Todoelcontenidotécnico,investigaciónde fuentes,verificacióndedatos,yargumentaciónsonpropiosdelos autores.Lasreferenciasbibliográficasfueronconsultadasyverificadas personalmente.

Resumen

Estelibroofreceunavisióngeneraldelconceptodesoftware auditable,desdelosantecedentesteóricos,eldiseñotécnico,los contextoslegalesynormativoshastasuimplementaciónprácticaenel entornodeproducción.Larevisiónbibliográficaincorporaresultados conceptualizacionesmásrecientesenelámbitodelainteligencia artificialylasaplicacionesdistribuidasnativasdelanube.

Enlosúltimosaños,elsoftwareauditablehapasadodeserun requisitodeseableaunanecesidadparaaplicacionesdealtoimpacto: porunlado,debidoalcrecientenúmerodeescándaloscorporativos masivos;yporotro,debidoalarecientepromulgacióndeleyes deproteccióndedatosanivelinternacionalynacional.Eneste sentido,segúnelmodelodeSieberyPartners,lostrescírculosde auditabilidadsedefinencomo:legibilidaddelcódigo,comprensibilidad arquitectónicaydocumentaciónexhaustiva,queseanalizaneneste libro.

Además,seanalizaelcontextonormativointernacional,basado enlanormaIEEE1028-2008yelmodelodecalidadISO/IEC25010. Asícomolaslimitacionestécnicasintroducidaspormarcoslegales comoelGDPR,laHIPAAylaLeySarbanes-Oxley.Finalmente,se proporcionaunmanualdeimplementaciónprácticaparaelmarco dedesarrollo.NET,dondeseaplicanlosconceptosteóricosen arquitecturasconcretasmediante:labibliotecaSerilogparaelregistro estructurado;EntityFrameworkCoreparalaauditoríaanivelde datos;ypatronesdediseñoparalatrazabilidadintegral.

Índicegeneral

1.1LaEraDigitalylaCrisisdeConfianzaComputacional 12

1.2Escándalosquemotivaronalsoftwareauditable ...14

1.3ElCasoEnron:FraudeFacilitadoporTecnología ..14

1.4EscándalosenAméricaLatina:ContextoRegional

1.6Petrobras(Brasil,2014) ................16

1.7CrisisEcuatoriana(1990-2020) ............17

1.7.1Crisisbancarias .....................17

1.7.2PetroecuadoryContratosconOdebrecht(2007-2016) 18

1.7.3SobreprecioenComprasPúblicasCOVID-19(2020) .19

1.8LeccionesparaSistemasAuditables ..........20

1.9LaRespuestaLegislativa:Sarbanes-OxleyActde2002 21

1.10EstructurayProvisionesClavedeSOX ........23

1.11LaRespuestaLegislativaEcuatoriana .........23

1.11.1LeyOrgánicadeEmpresasPúblicas ..........24

1.11.2ContraloríaGeneraldelEstado:NCI

1.11.3LaNorma500:InformaciónyComunicación .....26

1.11.4CódigoOrgánicoMonetarioyFinanciero(2014) ...26

1.12ElCasoporelSoftwareAuditable:EvidenciaEmpírica 27

2.1 DefiniciónOperacionaldeAuditabilidadySoftware

2.2 DefiniciónyMarcoConceptualdelRegistrosdeAuditoría

2.3AnatomíadeunRegistrodeAuditoría(AuditTrail)

2.3.1SistemasdeLoggingEstructurado

2.3.2Quién(Who)

2.3.3Qué(What)

2.3.7Porqué(Why)

2.4RequisitosdeIntegridadyNoRepudio

2.5RegistrosdeAuditoríaenBasesdeDatos

2.5.1Auditoríabasadaentriggers

2.5.2Auditoríamediantetransactionlogs

3.1ElEstándarIEEE1028-2008

3.2ISO/IEC25010:ModelodeCalidaddeSoftware

3.3 GDPR:ElReglamentoGeneraldeProteccióndeDatos

3.4HIPAAylosControlesdeAuditoría .........47

3.5 PrincipiosFundamentalesyelConceptodeAccountability ...........................47

3.6ProteccióndeInformacióndeSaludenEstadosUnidos 48

3.7ProteccióndeDatosPersonales(GDPR)enEcuador

3.7.1InfluenciadelGDPReuropeoenEcuador ......50

3.7.2RequisitosdeAuditoríayAccountabilitydelGDPR .51

3.7.3 MarcoConstitucionalEcuatorianodeProtecciónde Datos ..........................53

3.7.4 LeyOrgánicadeProteccióndeDatosPersonales(2021) 53

3.7.5ReglamentodelaLOPDP(2023) ...........56

Capítulo4

4.3 ClasificaciónPrimaria:EventosTécnicosversusEventosdeNegocio

4.3.1EventosTécnicos

4.6InmutabilidaddeRegistrosdeAuditoría

4.7ParadigmaAppend-OnlyparaRegistrosdeAuditoría

4.8 PrincipiodeMínimoPrivilegioparaAccesoaAuditoría

4.9Capturayenriquecimientodeeventos

4.11.3Log-StructuredStorageEngines

4.11.4EventStoresEspecializados

4.11.5ImplementaciónenBasesdeDatosRelacionales

4.11.6Trade-offsyconsideracionesderendimiento

4.12DesafíosyLimitaciones

4.14ImplementacióndeTrazasdeAuditoría

4.15ProtecciónCriptográficadeRegistrosdeAuditoría

4.15.1HashChainsparaDeteccióndeManipulación

4.15.2MerkleTreesparaVerificaciónEficiente

4.15.3FirmasDigitalesyNoRepudio

4.15.4TimestampingConfiable(RFC3161)

4.16Análisisforensederegistrosdeauditoría

4.16.1MetodologíadeInvestigaciónForenseDigital

4.16.3DeteccióndeAlteracióndeLogs

Capítulo5

5.1AnálisisdeDatosdeAuditoría

5.1.1Etapa1:RecolecciónyAgregación ..........88

5.2Etapa2:NormalizaciónyAnálisisSintáctico(Parsing)

5.3Etapa3:Enriquecimiento

5.4Etapa4:FiltradoyReducción .............91

5.5Etapa5:CorrelaciónyAgregación ..........92

5.6TécnicasdeAnálisis:DeDescriptivoaPredictivo ..93

5.6.1AnálisisDescriptivo:¿QuéOcurrió? ..........93

5.6.2AnálisisDiagnóstico:¿PorQuéOcurrió? .......94

5.6.3AnálisisPredictivo:¿QuéOcurrirá?

5.7PlataformasIntegradas

6.2SectorSalud:RegistrosMédicosElectrónicos

6.3FacturaciónElectrónicaenEcuador:SistemaSRI

6.3.1ArquitecturadelSistemadeFacturaciónElectrónica

6.3.2ImplementacióndeFirmaDigitalXAdES-BES ....102

6.3.3ProcesodeAutorizaciónyRastrodeAuditoría ....103

6.4 BANREDEcuador:SwitchInterbancarioyCompliancePCI-DSS

Capítulo7

7.1DiseñodeArquitecturaparaunSoftwareAuditable .107

7.2GuíadeImplementacióndeSerilogen.NETCore ..108

7.2.1 FundamentosdeConfiguraciónmediante appsettings.json .....................109

7.2.2InstalacióndePaquetesNecesarios ..........109

7.2.3IntegraciónenProgram.cs ...............110

7.2.4EstructuradeConfiguraciónenappsettings.json ...111

7.2.5ConfiguraciónEspecíficaporAmbiente ........114

7.2.6FormatoEstructuradomedianteJSONCompacto ..115

7.2.7RecargaDinámicadeConfiguración ..........116

7.2.8UsodeSerilogsegúnNiveldeVerbosidad ......117

7.2.9EjemplodeUsodeSerilogenunproyecto.NETCore 123

Capítulo8

CONCLUSIONES 133

Índicedefiguras

2 Figura2: Trazabilidaddeunatransaccióndeextremo aextremoenunsistemaauditable ...........31

3 Figura3: Mecanismodefirmadigitalparagarantía denorepudioenregistrosdeauditoría ........39

4 Figura4: Cadenadehashescriptográficosparaintegridadderegistros ....................40

5 Figura5: Arquitecturadeunaaplicación.NetCore usandoSerilog ......................124

6 Figura6: PipelinedeflujodeSerilog .........126

7 Figura7: ComponentesfundamentalesparalaimplementacióndeSerilogenaplicaciones.NET ......127

Índicedetablas

Capítulo1

INTRODUCCIÓNYCONTEXTO HISTÓRICO

EnlasprimerasdosdécadasdelsigloXXI,elsoftwarehapenetrado prácticamentetodoslosaspectosdelaactividadhumanaorganizada, convirtiéndoseenlainfraestructurainvisibleperoomnipresentesobre lacualseconstruyelasociedadcontemporánea.Hoyendía,los sistemasdeinformaciónmanejanmásde5billonesdedólaresen transaccionespordíaenlosmercadosfinancierosglobales,procesan informacióndesaluddemásde7milmillonesdepersonasen sistemasdesaluddigitales,controlangranpartedelainfraestructura críticaqueproporcionanuestraelectricidad,agua,transporteyotros serviciosvitales,yfacilitangranpartedelainteracciónyelcomercio entremilesdemillonesdepersonasqueutilizanplataformasdigitales queoperanaescalaplanetaria(BankforInternationalSettlements, 2025).

Estadependenciaubicuahageneradoloqueacadémicosllaman una“crisisdeconfianzacomputacional”(MacKenzie, 2001).A diferenciadesistemasfísicoscuyoscomportamientospuedenser verificadosmedianteinspeccióndirectaopruebasempíricasrepetibles, lossistemasdesoftwareoperanfrecuentementecomo‘cajasnegras’ cuyofuncionamientointernopermaneceopacoinclusoparaexpertos técnicosaltamentecapacitados.Estafaltadetransparenciaplantea riesgossistémicoscuandosoftwaredefectuosoomaliciososeejecuta enentornosdondelosfallospodríantenerefectosdevastadoresen personas,empresasoinclusosociedadesenteras.

Cabedestacarelconceptode“cajanegra”enlossistemasinformáticos.Dijstra(Dijkstra, s.f.)yMccloure(McClure, 2001)escriben: “Losnumerososelementosquecomponenunsistematecnológico sonfijos,enelsentidodequenoformanpartedeunanegociación socialnidaránlugaranuevasnegociacionessociales.Unbuen programaouncuerpoinquebrantablementerígidopuedenutilizarse, ensumayorparte,comocajasnegras;engeneral,unavezquela máquinafunciona,yanadietienequepreocuparseporella”.Enel ámbitodelsoftwaremoderno,existencajasnegrasencadacapa:el códigofuentesecompilaenbinariosinescrutables,lasaplicacionesde

microserviciosimplicanqueunasolatransaccióncomercialimplica llamaradocenasdeserviciosindependientes,yelentrenamiento demodelosdeaprendizajeautomáticopermitequelosmodelos descubranpatronesquesuspropioscreadoresnopuedenexplicar.

Elcostodelafaltadeauditabilidadtieneconsecuenciasdirectas yfácilmentemedibles.SegúnelestudiodelConsorcioparala InformaciónylaCalidaddelSoftware(CISQ)de2022,tansolo elproblemadelacalidaddelsoftwarelecuestaalaeconomía estadounidensealrededorde2,41trillonesdedólaresalaño.Estos nosonsololoscostesdirectosdelasfallasdesoftware(tiempode inactividaddelsistema,pérdidadedatostransaccionales,recuperaciónantedesastres),sinotambiénloscostesindirectos(pérdida deproductividad,pérdidadereputación,oportunidadesdenegocio perdidas)(Krasner, 2022).

Aúnmásalarmante,elinformeanualsobrefiltracionesdedatos deIBMde2023(Fantl, n.d.)ofreceunaideadelasconsecuenciasde nocontarconsistemasauditables.Elcostemediodeunafiltraciónde datoshaascendidoa4,45millonesdedólares,unincrementodel15% desde2020.Peroeldatomásreveladordelinformenoeselcostedela filtraciónensí,sinoladistribucióndelascausasraíz.Dosterciosde losincidentesdeseguridadfueroncausadosporaccionesinvoluntarias deusuariosinternosautorizados;noporhackersexternosmaliciosos, sinoporempleadosautorizadosquecometieronunerrorohicieron clicenuncorreoelectrónicodephishing.Aúnmáspreocupante,el 88%detodaslasbrechasdeseguridadfueroncausadasporerrores humanosenalgúnpuntodelacadenacausal.

Estosdatosmuestranclaramentequeelproblemanoradicaenla mayorsofisticacióndelosatacantes,sinoenlaimposibilidaddequelas organizacionesmonitoreen,comprendanocontrolenloquehacenlos usuariosautorizadosdentrodelossistemas.Sinregistrosdeauditoría adecuadosnideteccióndeanomalías,lasorganizacionesoperana ciegas,asumiendoquedecenasdemiles,odecenasdemillonesde accesosainformaciónconfidencialserealizancorrectamente,sin ningunaformadeprobarosiquieraverificarsiesasuposiciónes correcta.

1.2 Escándalosquemotivaronalsoftwareauditable

Lanecesidaddesoftwareauditablenosurgiódelvacíoacadémico, sinoquesecristalizódramáticamenteafinalesdelsigloXXconuna seriedecolapsoscorporativosespectacularesquerevelaronfallas sistémicasenlossistemasdeinformaciónfinancierayenlosprocesos deauditoríaexterna.Estosescándalosnosolodestruyeroncompañías individuales,sinoquesacudieronlaconfianzapúblicaenlosmercados decapitalyforzaronunareevaluaciónfundamentaldecómose auditanyregulanlasorganizaciones.

1.3 ElCasoEnron:FraudeFacilitadoporTecnología

EnronCorporationrepresentaelcasoparadigmáticodefraude corporativofacilitadoporsistemasdeinformacióninadecuadamente auditables.Fundadaen1985porKennethLaymediantelafusiónde HoustonNaturalGaseInterNorth,Enronsetransformódurantela décadade1990deunacompañíatradicionaldegasnaturalenun conglomeradodetradingenergéticoqueoperabaenmúltiplesmercadosglobales.Avanzandorápidamentehastaelaño2000:Enronerala séptimaempresamásgrandedeEstadosUnidosporcapitalización bursátil,con111000millonesdedólareseningresosyalrededorde 20,000empleados(Bondarenko, 2026).

Seconsiderabaunaempresainnovadorayseestudiabaamenudo enlasclasesdenegocioscomoejemplodecómomodernizarlas operacionescorporativas.Duranteseisañosconsecutivos,entre1996 y2001,fuenombrada“LaempresamásinnovadoradeEstados Unidos”porFortune.Elpreciodesusaccionesalcanzóunmáximo de90,75dólaresamediadosdeagostode2000.Sinembargo,todo estoerauncastillodenaipes,yaquesuéxitofinancierosebasabaen fraudescontables,facilitadosporsistemasdeinformacióndiseñados paraeludirloscontrolesnormales(LevinCenterforOversightand Democracy, n.d.).

Enronutilizódiversastécnicasparacometersufraude,unade lascualessedenominaba“contabilidadavalordemercado”.Este procesoconsistíaenvalorarloscontratosalargoplazobasándoseen

elvaloractualnetodelflujodepagosfuturosesperados.Estatécnica estápermitidaporlosPrincipiosdeContabilidadGeneralmente Aceptados(PCGA),peroenelcasodeEnronseimplementódeforma fraudulenta.Enronutilizóprevisionesdeingresosexcesivamente optimistasparainflarelvalordeloscontratosyluegoreconoceresos ingresosinmediatamente,enlugardedistribuirlosalolargodela vigenciadelcontrato.

Unasegundatécnicafueelusode“EntidadesdePropósitoEspecial” (EPE),esencialmentesociedadesfantasmas,creadasporEnronpara comprarpartedesudeudaoinversionesdebajorendimiento.En total,Enroncreóalrededorde3.000EPE,algunasdeellasconsede enunparaísofiscaldelCaribe.EnronutilizólasEPEparaocultarsu deudadesubalancegeneral,asícomoparavenderinversionesdebajo rendimientoyacometerelfraudecontable.Finalmente,eldirector financierodeEnron,AndrewFastow,controlabavariasdelasSPE ylasutilizabaparabeneficiarsepersonalmentedelastransacciones fraudulentasdeEnron(Bondarenko, 2026).

Enestecaso,lossistemasdeinformacióndeEnronestaban diseñadosparamanipularlastransaccionesqueinvolucrabanalas SPE,demodoquenoquedaraclaroqueenrealidadestabantratando consigomismas.Lossistemasdeinformesestabandiseñadospara quelainformacióngeneradacumplieraconlaletradelasnormas contables,peronoreflejaraelespíritudelasmismas.Loscontroles internoserandébilesoinexistentes,loquepermitióqueseprodujera elfraude.

Alfinal,elcastillodenaipesestabadestinadoaderrumbarse,yasí fue.Enoctubrede2001,Enronreportóunapérdidade$638millones engananciasnetasyunadisminuciónde$1.2milmillonesenelcapital socialdebidoatransaccionesrelacionadasconSPE.LaSECrespondió casideinmediatoconunainvestigación.Elpreciodelasaccionesse desplomócasideinmediato,pasandode$90.75amenosde$1en cuestióndesemanas.Enronsedeclaróenbancarrotael2dediciembre de2001,lamayorbancarrotaenlahistoriadeEstadosUnidos hastaesemomento.Losaccionistasperdieronaproximadamente$74 milmillonesenvalordemercado(LevinCenterforOversightand

1.4 EscándalosenAméricaLatina:ContextoRegional

AméricaLatinahaexperimentadomúltiplesescándalosdecorrupción,fraudefinancieroymalversacióndefondospúblicosquehan erosionadosignificativamentelaconfianzaciudadanaeninstituciones públicasyprivadas.Estosescándaloshanexpuestodebilidades sistémicasencontrolesinternos,supervisiónregulatoria,ytransparenciadesistemasdeinformación,subrayandolanecesidadcrítica desistemasauditablesensectorespúblicoyprivado.Acontinuación, secitanunoscasosemblemáticosregionales.

1.5 Odebrecht(2014-2016)

ElescándalodecorrupciónmásextensoenlahistoriadeAmérica LatinainvolucróalaconstructorabrasileñaOdebrecht(EFE, 2025), queadmitiópagarmásde$788millonesensobornosafuncionariosen 12paíseslatinoamericanosparaasegurarcontratosdeinfraestructura. LainvestigaciónrevelóqueOdebrechtoperabaun“Departamentode OperacionesEstructuradas”quegestionabapagosilícitosmediante sistemasoffshorecomplejos.Laausenciaderegistrosdeauditoría adecuadosensistemasgubernamentalesdecontrataciónfacilitóque estospagospermanecieranocultosporaños.Elcasoresultóen investigacionesenPerú,Ecuador,Colombia,México,Panamá,RepúblicaDominicana,Venezuela,Argentina,yotrospaíses,derribando gobiernosyencarcelandopresidentesyministros(Galero, 2024).

1.6 Petrobras(Brasil,2014)

Laoperación“LavaJato”(Guerrero, 2019)descubrióunesquema masivodecorrupciónenPetrobras,lapetroleraestatalbrasileña, dondeejecutivosaceptabansobornosdecontratistasacambiode contratosinflados.Seestimaqueelesquemadefraudómásde$2 milmillones.Lainvestigaciónexpusoquelossistemasdeauditoría internadePetrobrashabíansidocomprometidosdeliberadamente, conauditorescómplicesocoaccionadosparanoreportarirregulari-

dades.Lafaltadelogsinmutablesdeaprobacionesdecontratosy transaccionesfinancierasdificultórastrearelflujocompletodefondos (Guerrero, 2019).

1.7 CrisisEcuatoriana(1990-2020)

1.7.1 Crisisbancarias

Enlosaños1994al2000,Ecuadorsufrióunagravecrisisbancaria provocadaporlaLeyGeneraldeInstitucionesFinancierasde1994, quepermitiólosllamados“créditosvinculados”,préstamosquelos bancosotorgabanasuspropiosaccionistasyempresasdelgruposin garantíasreales.ElcasomásemblemáticofueFilanbanco,quequebró el2dediciembrede1998yrequirióunsalvatajeestatalde$849 millones(70%delareservamonetariadelpaís).Lainvestigación revelóqueFilanbancootorgabapréstamossininterésasuspropios accionistasmientrascobrabaanatocismo(interéssobreinterés)aclientesregulares.Laausenciadesistemaspararegistraradecuadamente losconflictosdeinterésylasaprobacionesdecréditosfacilitóestas prácticas.Lacrisisresultóenelcierrede18institucionesfinancieras yuncostodesalvatajeentre$5.000-6.000millones,equivalente aproximadamenteal8%delPIB(CarrilloMañayetal., 2019).

Alinvestigar,salieronalaluzvariascausas,comofallosenlos sistemasdeinformaciónyauditoríaquepermitieronpréstamosa parientessinchequearnada,estadosfinancierosmanipuladosyhasta fugadecapitales.Esodestruyólaconfianzaentodoelsistema, tambiéntrajocambiosgrandesenlasreglas,porejemplo,haciendo másfuertealaSuperintendenciadeBancosypidiendomásdetalles enlainformaciónylasauditorías.

EnelcasodeFilanbanco,seevidencióqueusabandoscontabilidadesalmismotiempo,unaoficialparalosreguladoresyotrarealque solounospocosconocían.Sincontrolesdeaccesooregistrosqueno sepudierancambiar,lasoperacionesrarasnoteníanunrastroclaro dequiénaprobabaqué,loquefacilitótodoelfraude(CarrilloMañay etal., 2019).

Lasconsecuenciasmacroeconómicasdeestaausenciadecontroles

fuerondevastadorasycuantificables.SegúnelBancoCentraldel Ecuador,lacrisisfinancieradefinalesdelosnoventagenerópérdidas estimadasenUSD6.170millonesparaelpaís(Telégrafo, 2014). En1999cerraron18entidadesfinancieras,entreellasFinancorp, Azuay,Finagro,BancodelProgreso,Bancomex,BancoPopular, BancoUnión,BancodeCréditoyFilanbanco(Erazo, 2022).El salvatajeestataldeFilanbanco,paraentonceselbancomásgrande delpaís,demandóUSD849millones,equivalentesal70%dela reservamonetariadelEcuadorenesemomento(Erazo, 2022). Adicionalmente,segúnelinformedeDeloitte&Touchede2001, aprobadoporlaJuntaBancaria,laspérdidaspropiasdeFilanbanco ascendieronaUSD661,5millones(Perdomo&Mogollón, 2019).Estos númerosilustranconprecisiónquéocurrecuandolossistemasde informaciónfinancieracarecenderegistrosinmutables,controlesde accesoauditablesyflujosdeaprobacióndocumentados:eldañono selimitaaunainstitución,sinoquesepropagaalconjuntodela economíanacional.

1.7.2 PetroecuadoryContratosconOdebrecht(2007-2016)

Ecuadorfueunodelospaísesafectadoporelescándalode Odebrecht(«ContraloríaGeneraldelEstado», 2017).Laconstructorabrasileñapagóunos33,5millonesdedólaresensobornosa funcionariosecuatorianosacambiodecontratosdePetroecuador (empresapetroleraestatal)valoradosenmásde116millonesde dólares.Lasvulnerabilidadesdetectadasincluyeronlossistemasde contrataciónpúblicadePetroecuador,quenoproporcionabanun registrodeauditoríacompletoparaelprocesodeevaluaciónde ofertas.Noexistíanregistrosdigitalesdequiénaccedióainformación restringidadelalicitación,quiénparticipóenlaevaluacióntécnica, quécriteriosdepuntuaciónseaplicaronniquiénaprobólasadendas contractualesqueincrementaronloscostos.Laausenciadesellado detiemposeguroyfirmaselectrónicasendocumentosclavepermitió lamanipulaciónretroactivadedocumentos.

Elalcancerealdeldañosolopudodimensionarseañosdespués, cuandolaContraloríaGeneraldelEstadoejerciósupotestadauditora. LaContraloríaemitió31informesfinalessobre15proyectosenlos

queparticipóOdebrecht,habiendoauditadoununiversodeUSD 4.409,4millonesencontratosyestablecidoglosasymultaspor USD144,7millones(«ContraloríaGeneraldelEstado», 2017).El exvicepresidenteJorgeGlasfuesentenciadoendiciembrede2017 aseisañosdeprisiónporeldelitodeasociaciónilícita,habiéndose acreditadoenjuicio.Desdelaperspectivadelaauditabilidadde sistemas,estecasoesparadigmático:lossistemasdecontrataciónde Petroecuadornogenerabantrazasinmutablesdelasdecisionesde adjudicación,locualhabilitabaqueunmismodocumentopudiera circularconversionesdistintasantedistintosactoresdelproceso,sin queningunaherramientatecnológicapudieradetectarladiscrepancia entiemporeal.

1.7.3 SobreprecioenComprasPúblicasCOVID-19(2020)

EnelcontextodelapandemiadelaCOVID-19,Ecuadorse havistoafectadoporlacorrupciónrelacionadaconlacompra desuministrosmédicosdeemergencia.LaContraloríaGeneral delEstadohareportadosobrepreciossuperioresal9.000%enla comprademascarillas,trajesdeprotecciónyotrossuministros.El usodeprocedimientosdeemergenciaqueeludíanloscontrolesde contrataciónpúblicasuprimiólaspistasdeauditoría.Lossistemas delPortaldeComprasPúblicasnoregistrabanjustificacionespara lacontratacióndirectanocompetitiva.Laausenciademecanismos deverificaciónautomatizadosquevalidaransiunproveedorestaba registradocomoempresaactivaconunatrayectoriacomprobada permitiólacontratacióndeempresasfantasma.Tampocosedisponía depanelesdemonitoreoentiemporealquealertaransobreprecios atípicosencomparaciónconlospreciosdemercado(deDerechos yJusticia, s.f.).

Lascifrasdeesteepisodiosonconcretasyverificables.ElGobierno NacionaldestinóUSD664,8millonesparaatenderlaemergencia sanitaria,deacuerdoconcifrasoficialesdisponiblesalcortede mayode2021(yPeriodismodeInvestigación, 2021).LaContraloría GeneraldelEstado,enejerciciodesumandatoconstitucional,inició 53auditoríasenapenastresmeses,entremarzoymayode2020, paraexaminarelusodeesosrecursosencontratacionesdeinsumos

médicos(«ContraloríaGeneraldelEstado», 2020).Losresultados fueronalarmantes:enelcasomásdocumentado,laspantallasfaciales deprotecciónadquiridasporelIESSfueroncotizadasaUSD21,53 porunidadfrenteaunpreciodemercadodeUSD0,23,loque representaunsobrepreciodel9.259%,segúnelinformeconindicios deresponsabilidadpenalaprobadoporelcontralorPabloCeliy remitidoalaFiscalíael6deabrilde2020(«ContraloríaGeneral delEstado», 2020).Paramayode2021,laFiscalíaGeneraldel Estadoreportómásde160investigacionesabiertasvinculadasaestas comprasdeemergencia(convoca2021).Desdeelpuntodevistade lossistemasdeinformación,esteescenarioevidencialaconsecuencia directadecarecerdevalidacionesautomatizadasentiemporeal:un sistemaauditableconreglasdenegociocorrectamenteimplementadas habríarechazadoautomáticamentecualquiercotizaciónquesuperara unumbralporcentualpredefinidorespectoalpreciodemercado registrado,sinnecesidaddeintervenciónhumanaposterior.

1.8 LeccionesparaSistemasAuditables

Losescándalosmencionados,tantoglobalescomodeEcuador,son ejemplosdelamaterializacióndesistemasdedatosnoauditables.A decir:

✓ Registrosinmutables: silosregistrospuedenmodificarse posteriormente,osilosregistrosnoexistenonoestáncompletos, puedeproducirsefraudeynosepuedenrealizarauditorías.Los registrosinmutablesdebenestarfirmadoscriptográficamente.

✓ cuandoldeacceso: sielaccesoaunsistemanosecontrolani registra(quiénaccedió,cuándoyporqué),noesposiblesaber cuándounusuariointernoutilizalosdatosparasupropiobeneficio.

✓ Flujodetrabajo: cualquieraprobaciónodecisión(porejemplo,uncrédito,uncontrato,unatransferencia)deberealizarse medianteunflujodetrabajo.Cadapasodeberegistrarse,con losaprobadoresysujustificación;sedebegenerarunregistrode evidenciadigital.

✓ Análisisentiemporeal: silosanálisissolosepuedengenerar

conundesfase(mensualotrimestral),puedeproducirseunfraude yaumentarhastaquesedetectelaanomalía.Debeestardisponible elanálisisentiemporeal,asícomolasalarmasparaexcepciones.

✓ Segregacióndefunciones: siquienesoperanlossistemasson losmismosqueadministranlosregistros,puedeproducirsefraude. Lossistemasdebensegregarfuncionesycontarconunsistemade auditoríaexterna

Estosejemplosofrecenunsólidoargumentoempíricoafavorde sistemassólidosyauditablestantoenelsectorpúblicocomoenel privado,enEcuadoryanivelglobal.

1.9 LaRespuestaLegislativa:Sarbanes-OxleyActde2002

Elgobiernoestadounidensereaccionórápidamentealacrisis.En juliode2002,elCongresoaprobólaLeydeReformaContablede lasEmpresasPúblicasyProteccióndelInversionista,másconocida comoLeySarbanes-Oxley(Tunggal&Ruan, 2026).Elproyectode leyfuepatrocinadoporelsenadorPaulSarbanes(demócratapor Maryland)yelrepresentanteMichaelOxley(republicanoporOhio).

ElproyectodeleyfueaprobadoenlaCámaradeRepresentantes por423votosafavory3encontra,yenelSenadopor99votosa favory0encontra.

ElpresidenteestadounidenseGeorgeBushpromulgólaleySOXel 30dejuliode2002,señalandoque“Laeradelosbajosestándaresy lasgananciasfalsashaterminado;ningunajuntadirectivaenEstados Unidosestáporencimaoalmargendelaley”.LaleySOXconsta de11seccionesqueabordanlasupervisióndelasempresaspúblicas, laadministraciónylasfirmasdecontabilidad(«Sarbanes-Oxley Act», n.d.).Lasprovisionesclaveconimplicacionesdirectaspara auditabilidaddesoftwareincluyen:

✓ TítuloI-PublicCompanyAccountingOversightBoard (PCAOB): EstablecióelPCAOBcomoorganismoindependiente supervisadoporlaSECparapromoverreportesdeauditoría precisos,independientesytransparentes.ElPCAOBregistra

firmasdeauditoría,estableceestándaresdeauditoríayética, inspeccionacumplimientodeSOXyhacecumplirreglasmediante penalidadesqueincluyensuspensiones,censurasymultasdehasta $2millonesporviolación.

✓ TítuloII-IndependenciadelAuditor: Fortalecelaindependenciadeauditoresexternoslimitandoconflictosdeinterés yrestringiendoserviciosqueauditorespuedenproporcionara clientes.Prohíbequelafirmaqueauditaloslibrosdeunacompañía públicatambiénhagalacontabilidad,auditevaluacionesde negocio,diseñeoimplementesistemasdeinformación,proporcione serviciosdeasesoríadeinversionesobanca,oconsultesobreotros temasdegestión.

✓ Sección302-CertificacióndeControlesyProcedimientos: RequierequeCEOyCFOcertifiquenpersonalmentelaprecisión dereportesfinancieros.Específicamente,debencertificarquehan revisadoelreporte,quenocontienedeclaracionesmaterialmente falsasniomitehechosmateriales,quelosestadosfinancieros reflejanfielmentelacondiciónfinanciera,yquesonresponsablesde establecerymantenercontrolesinternossobrereportesfinancieros.

✓ Sección404-EvaluacióndeControlesInternos: Esta esquizáslaprovisiónmáscontroversialeimpactantedeSOX. Requierequetodoslosreportesanualesincluyanunreportede ControlInternoquedelineeexplícitamentelaresponsabilidad delagerenciaparamantenerunaestructuradecontrolinterno adecuada,unaevaluacióndesuefectividad,ycualquierdeficiencia enesoscontroles.Losauditoresexternosindependientesdeben tambiénatestarlaprecisióndeladeclaracióndelacompañíade queloscontrolesinternosestánenlugarysonefectivos.

¿QuéimplicalaSección404paralossistemasdeinformación? SegúnelinformetécnicosobrelosrequisitosdeauditoríadeSOX, elaboradoporelproveedordeseguridaddedatosImperva,los auditoresdeSOXrevisanáreascomolagestióndeusuarios,la autenticación,lasegregacióndefunciones,elcontroldeaccesoy, quizáslomásimportante,losregistrosdeauditoríaenelentorno

delabasededatos.Lossistemasderecopilaciónymonitorización deregistrosdebenproporcionarunregistrodeauditoríaparatodo accesoyusodedatosempresarialesconfidenciales.

CumplirconSOXpuedesercostoso.Unaencuestarealizadaen 2008porlaSECadirectivosdeempresaspúblicasrevelóqueelcosto medioanualdirectofuede2,3millonesdedólares.

1.10 EstructurayProvisionesClavedeSOX

Sarbanes-Oxleyconstade11títulosqueestablecennuevosestándaresparajuntasdirectivasdecompañíaspúblicasestadounidenses, gerenciaejecutivayfirmasdecontabilidadpública.Laleyesextensa, aproximadamente66páginasdetextolegaldensoy,susprovisiones tocanprácticamentetodoslosaspectosdegobiernocorporativo yreportefinanciero.Parapropósitosdeentendersuimpactoen auditabilidaddesoftware,variostítulosyseccionesespecíficasson particularmenterelevantes:

✓ TítuloI-PublicCompanyAccountingOversightBoard (PCAOB): EstetítuloestablecióelPCAOBcomounorganismo nuevoeindependiente,supervisadoporlaSEC,perooperado comoentidadsinfinesdelucro.ElPCAOBtieneautoridadpara registrarfirmasdecontabilidadpúblicaqueauditancompañías públicas,establecerestándaresdeauditoríayética,inspeccionar firmasdeauditoríaregistradasparaevaluarcumplimientocon SOXyotrasleyes,yhacercumplirreglasmedianteinvestigacióny accionesdisciplinariasincluyendosuspensiones,censurasymultas dehasta$2millonesporviolaciónparaindividuosy$15millones parafirmas.

1.11 LaRespuestaLegislativaEcuatoriana

Comocontexto,setienequelaCrisisBancariafueelcatalizador delareforma,asícomoEstadosUnidosrespondióalosescándalos EnronyWorldComconlaSarbanes-OxleyActde2002,Ecuador experimentósupropiacrisissistémicaquecatalizóreformaslegislati-

vassignificativas.Lacrisisbancariaecuatorianade1999-2000,con elcolapsodelsistemafinanciero,yelferiadobancarioquecongeló ahorrosdemillonesdeciudadanos,expusodebilidadesfundamentales engobernanzacorporativaycontrolesinternos.

EnEcuador,adiferenciadelmodeloestadounidensedondela leySOXabordómúltiplessectoressimultáneamente,larespuesta legislativaecuatorianafuesectorialyevolutiva.Lareformamás análogaaSOXentérminosdeimponercontrolesinternosrigurosos yresponsabilidaddeejecutivosfuelaLeyOrgánicadeEmpresas Públicas(LOEP)promulgadael16deoctubrede2009,publicada enRegistroOficialSuplementoNo.48(«LeyOrgánicadeEmpresas Públicas», 2009).

1.11.1 LeyOrgánicadeEmpresasPúblicas

Artículo5:PrincipiosdeGestión,elArtículo5estableceprincipios quedebenregirgestióndeempresaspúblicas:

✓ Rendicióndecuentas: “Lasempresaspúblicasysusadministradoresestaránsujetosalescrutiniodelosorganismosdecontrol correspondientesydeberánimplementarsistemaspermanentesde rendicióndecuentas”.EstaprovisiónesanálogaaSOXSección 302dondeCEOyCFOdebencertificarpersonalmenteestados financieros.

✓ Transparencia: “Lasempresaspúblicasestaránsujetasalprincipiodetransparenciaquelesobligaasuministrarinformación veraz,suficienteyoportuna”.SimilaraSOXSección409que requiererápidadivulgacióndecambiosmateriales.

✓ Eficienciaycalidad: Requiere“sistemasdegestiónintegral basadosenprocesosdebidamentedocumentados”,análogoa requisitosdedocumentacióndecontrolesinternosdeSOXSección 404.

Artículo14:ResponsabilidadSolidariadelDirectorio “ElDirectorioresponderásolidariamenteporlasdecisionesadoptadas,salvoconstanciaexpresadelvotoparticularnegativodel

respectivomiembrodelDirectorio”.

EstaresponsabilidadsolidariaesmásestrictaqueSOX,mientras SOXimponeresponsabilidadespecíficamenteaCEOyCFO,LOEP imponeresponsabilidadsolidariaatodoslosmiembrosdeldirectorio portodaslasdecisionescorporativas.

Artículo19:FirmaSolidariadeEstadosFinancieros

“Suscribirlosestadosfinancierosenformasolidariaconelresponsablefinanciero,ypresentarlosalDirectorio”.

LafirmasolidariaentreGerenteGeneralyresponsablefinancieroes directamenteanálogaaSOXSección302,haciendoaambosejecutivos legalmenteresponsablesconjuntamenteporexactituddereportes financieros.

Artículo29:AuditoríaInternaIndependiente

“LasempresaspúblicascontaránconunaunidaddeauditoríainternaquedependeráadministrativayfuncionalmentedelDirectorio”.

EstaindependenciafuncionalrespectodelaadministraciónejecutivaesanálogaaSOXSección301querequierequeuncomitéde auditoríasuperviseauditoresinternos.

Artículo31:SistemasdeControlInterno

“Lasempresaspúblicasestableceránsistemaspermanentesde controlinterno,compuestosporpolíticas,normas,métodosyprocedimientosestructuradoseintegrados,afindeprevenirymitigar riesgosdegestión”.

EstaprovisiónesdirectamenteanálogaaSOXSección404que requiereevaluaciónyreportesobreefectividaddecontrolesinternos. Requierequecontrolessean“estructuradoseintegrados”,implicando sistemasdeinformaciónqueimplementencontrolesprogramáticamenteygenerenevidenciaauditable.

1.11.2 ContraloríaGeneraldelEstado:NCI

ElAcuerdo039-CG-2009emitiólas“NormasdeControlInterno (NCI)paraEntidadesdelSectorPúblico”,análogasfuncionalmente

alFrameworkCOSOutilizadoparaimplementacióndeSOX404.Las normasestablecencincocomponentesidénticosaCOSO:ambiente decontrol,evaluaciónderiesgos,actividadesdecontrol,información ycomunicación,ymonitoreo(ContraloríaGeneraldelEstado, n.d.).

1.11.3 LaNorma500:InformaciónyComunicación

Estanorma,enlasección500-01estableceloscontrolessobre sistemasdeinformación:“Sediseñarán,estableceránymantendrán controlesapropiadosdetecnologíadeinformaciónparaasegurarla confiabilidad,exactitudyvalidezdelainformaciónprocesada”.

Estanormaimplicarequisitosdeauditabilidad:sistemasdeben capturardatoscompletos,mantenerintegridad,ypermitirverificación deconfiabilidaddeinformaciónreportada(normascontrolinterno).

1.11.4 CódigoOrgánicoMonetarioyFinanciero(2014)

Paraelsectorfinancieroespecíficamente,elCOMYF(Asamblea NacionaldelEcuador, n.d.)consolidólasiguienteregulación:

✓ Artículo208: SistemasdeInformación:“Lasentidadesdel sistemafinancieronacionaldeberáncontarconsistemasde informaciónquepermitanmantenerregistrosprecisosycompletos delasoperaciones,garantizandosuintegridad,confiabilidady oportunidad”.Obligaciónlegalespecíficadesistemasauditables ensectorfinanciero.

✓ Artículo445: GestiónIntegraldeRiesgos:Requieresistemasde administraciónderiesgosqueincluyenriesgooperacional,definido como“deficienciasensistemasdeinformaciónocontrolesinternos”.

Paraunmejorentendimiento,enlasiguientetabla 1 constala comparacióndelCódigoSOXVs.elMarcoEcuatoriano.

Tabla1: ComparaciónSOXvs.MarcoEcuatoriano

AspectoSarbanes-Oxley(USA)MarcoEcuatoriano

TriggerEnron,WorldCom(2001-2002)Crisisbancaria(1999-2000)

LegislaciónSOXAct(2002)-leyúnica

Ámbito Todaslasempresaspúblicas (traded)

Responsabilidad ejecutiva

Controlesinternos

Sec.302:CEO/CFOcertifican

Sec.404:Managementevalúa controles

Auditoríainterna ImplícitoenSec.404

SupervisorSECyPCAOB

ElaboraciónPropia

LOEP(2009),COMYF(2014)sectorial

LOEP:empresaspúblicas; COMYF:financiero

Art.19:Gerente/responsablefinancierofirmansolidariamente

Art.31:Empresaspúblicasestablecencontrolesbajonormas CGE

Art.29:Explícitamenterequerido

CGEparapúblico;Superintendenciasparaprivado

1.12 ElCasoporelSoftwareAuditable:EvidenciaEmpírica

Frentealaevidenciadelosdañoscausadosporsistemasnoauditables,resultaigualmentepertinentedocumentarloquelaevidencia empíricamuestracuandoloscontrolessíexisten.Elbeneficiodel softwareauditablenoesteórico:semideenpérdidasevitadas,tiempos dedetecciónreducidosyrecursospúblicosrecuperados.

Elestudioglobalmáscitadoenlamateria, OccupationalFraud 2024:AReporttotheNations delaAssociationofCertifiedFraud Examiners(AssociationofCertifiedFraudExaminers, 2024),analizó 1.921casosrealesdefraudeen138paíseseidentificóquelasorganizacionespierdenenpromedioel5%desusingresosanualesporfraude ocupacional,loqueaescalaglobalrepresentaaproximadamenteUSD 5billonesalaño(AssociationofCertifiedFraudExaminers, 2024).El mismoestudiorevelaqueeltiempomedianoquetardaendescubrirse unesquemadefraudeesde12meses,yquemásdelamitadde

loscasosestáncorrelacionadosconausenciaodebilitamientode controlesinternos.ParaAméricaLatinayelCaribe,loshallazgosson especialmentepreocupantes:laregiónregistralapérdidamediana másaltaporcasoanivelmundial,conUSD250.000porincidente, superandoatodaslasdemásregionesanalizadas.

Lamismainvestigacióndemuestra,ensentidoinverso,elvalor deloscontrolesauditables:enorganizacionesquecontabancon líneasdereporteanónimasymecanismosformalesdedenuncia, laspérdidasporfraudefueronun50%menoresqueenaquellas quecarecíandeellos.Cuandoloscontrolesinternosfuncionancomo primeralíneadedetección,losfraudessedescubrenantesysuimpacto económicosereducedeformasignificativa.Desdelaperspectivadel sectorpúblicoecuatoriano,laContraloríaGeneraldelEstadoha demostradoesteprincipiodeformadirecta:susauditoríassobre contratosOdebrechtenEcuador,realizadasprecisamenteporque existíanregistrosauditablesquepodíanserexaminados,permitieron identificarglosasyresponsabilidadesporUSD144,7millonesen 15proyectosdeinfraestructura(«ContraloríaGeneraldelEstado», 2017).Sinsistemasquegenerentrazasverificables,esarecuperación habríasidoimposible.Elsoftwareauditable,endefinitiva,noesun costodecumplimientonormativo:eselmecanismoquehaceposible queelcontrolexternotengaalgosobrequéactuar.

Capítulo2

FUNDAMENTOSCONCEPTUALES

Laauditabilidaddelsoftwareserefiereaunparadigmafundamentaldeldiseño,desarrolloeimplementacióndesistemasdeinformación (SI),enelqueladisponibilidaddemecanismosquepermitanel seguimiento,elexamenolaverificacióndelcomportamientodel sistemaesunrequisitoestricto.Enunmundodondelasorganizaciones debencumplirconnormativasenconstanteevoluciónycadavez másexigentes,comolaLeySarbanes-Oxley(SOX),elReglamento GeneraldeProteccióndeDatos(GDPR),laLeydePortabilidad yResponsabilidaddelSeguroMédico(HIPAA)yvariasotras,la necesidaddequelossistemasdesoftwareseanauditableshapasadode serunacaracterísticadecalidaddelsoftwareaunrequisitoobligatorio paraelcumplimientonormativoyorganizacional.

SegúnlanormaISO/IEC25010(InternationalOrganizationfor Standardization, 2011),laauditabilidaddeunsistemadeinformación sedefinecomolacapacidadderegistrar,preservarypresentar evidenciaadecuadayapropiadadesusoperacionesparapermitir laverificaciónindependientedelcumplimientodelsistemaconsus especificaciones,políticasyrequisitosregulatorios.Aunqueestá estrechamenterelacionadaconotrosconceptoscomoelregistro,la monitorizaciónylaobservabilidaddelsistema,laauditabilidades unacaracterísticadistintivadelacalidaddelsoftwarequeabarca lasdimensionesarquitectónicas,dediseño,deimplementacióny operativas,yquedebeabordarsealolargodetodoelciclodevida deldesarrollodesoftware.

LaFigura 2 ilustracómooperalarastreabilidadenlapráctica. Considéreseunatransacciónordinariaenunsistemadeinformación: unusuarioautenticadoejecutaunaoperación,porejemplo,una transferenciabancaria,unaaprobacióncontractual,unamodificación dedatosmédicos,yesegesto,aparentementesimple,desencadena unacadenadeeventosqueatraviesamúltiplescapasdelsistema.En cadatransición,delusuarioalaaplicación,delaaplicaciónalabase dedatos,delabasededatosalregistrodeauditoría,elsistemadebe capturarevidenciasuficientepararesponderconprecisiónlasseis preguntasfundamentalesdelarendicióndecuentas:quiéninicióla acción,quéoperaciónserealizóyquévalorescambiaron,cuándo

ocurrióconprecisióntemporalverificable,desdedóndeseoriginó lasolicitud,mediantequémecanismotécnicoseejecutó,yconqué justificacióndenegociofueautorizada.

Figura2: Trazabilidaddeunatransaccióndeextremoaextremoenunsistema auditable

Nota:ElaboraciónPropia

Loquedistingueaunsistemaauditabledeunoquemeramente registraactividadesprecisamentelacompletitudylaintegridadde esacadena.Unlogquecapturael“qué”peroomiteel“quién”no permiteatribución;unoqueregistrael“quién”peronoel“cuándo”no permitereconstruccióntemporaldeeventos;unoquealmacenatodos loscampos,peropermitesumodificaciónposteriornoconstituye evidenciaadmisible.Larastreabilidad,ensentidoestricto,noesuna propiedaddeuncampoindividualdelregistro:esunapropiedaddela cadenacompleta,desdeelactorhastaelalmacenamientoinmutable, sinbrechasnipuntosdemanipulaciónposible.Cualquierrupturaen esacadena,seapordiseñodeficiente,poromisióneneldesarrollo oporvulnerabilidadoperativa,constituyeexactamenteeltipode vacíoqueloscasosdeFilanbanco,Petroecuadorylascomprasde emergenciaCOVID-19expusieronconconsecuenciasmediblesen cientosdemillonesdedólares.

SedefineunsistemadesoftwareauditablecomounSistemade Informacióndiseñado,desarrollado,implementadoyoperadocon característicasinherentesquefacilitan,permitenygarantizanla verificaciónindependiente,completayfiabledesucomportamiento, latomadedecisiones,elprocesamientodedatosylaconformidadcon lasespecificaciones,políticasynormativasaplicables.Estadefinición esintencionadamenteextensaydensa;porlotanto,esnecesario aclararelalcancedecadaunodesuscomponentes.

Diseñado,desarrollado,implementadoyoperadoimplicaquela auditabilidaddebeconsiderarseentodaslasetapasdelciclode vidadeldesarrollodesoftware.Porejemplo,enlafasedediseño, laauditabilidadpuedeimplicareldiseñodeunaarquitecturaque facilitelamonitorizacióndelsistema,latrazabilidad,laseparaciónde interesesylamodularización.Enlafasededesarrollo,laauditabilidad puedereferirsealaimplementacióndeprácticasdecodificaciónque promuevenlalegibilidad,mantenibilidadytestabilidaddelcódigo. Enlafasedeimplementación,significaestablecerunaconfiguración adecuadadelsistemaquepermitalarecopilaciónderegistrosy registrosdeauditoríasincomprometerelrendimientodelsistema. Enlafasedeoperación,puedeimplicaractividadesquegaranticen larecopilación,preservaciónyprotecciónderegistrosyregistrosde auditoría.

Enelmodelodecalidaddesoftwaredefinidoporlanorma ISOIEC25010delaño2011,laauditabilidadaparececomouna subcaracterísticadentrodelatributodeseguridad.Supropósitoes apoyarelprincipioderesponsabilidad,esdecir,lacapacidaddeun sistemaparadejarclaroquiénrealizócadaacción.Segúnlanorma,la responsabilidadserefierealgradoenquelasaccionesdeunaentidad puedenatribuirsedemaneraúnicaysinambigüedadesaesamisma entidad.Entérminosprácticos,estosignificaqueelsoftwaredebe permitirrastrearlasaccionesrealizadas,identificarasuautorycontar conevidenciassuficientesparaevitardudas,erroresonegaciones

sobreloocurrido.

EnlaTabla 2,seidentificantrespilaresfundamentalessobrelos quesesustentaelsoftwareauditable.

Tabla2:

PilaresFundamentalesdelSoftwareAuditable

PilarfundamentalConcepto

Rastreabilidad(Traceability)

Norepudio(Nonrepudiation)

Capacidaddeseguirelflujodeejecuciónylastransformacionesdedatosatravésdelsistema,estableciendo cadenasdecausalidadentreeventos,accionesyresultados(Gotel&Finkelstein, 1994).

Garantíacriptográficayprocedimentaldequelasaccionesregistradasnopuedensernegadasposteriormente porsusautores,proporcionandoevidenciairrefutable delaparticipaciónentransaccionesoeventos(Menezes etal., 1996).

Integridadderegistros (LogIntegrity)

ElaboraciónPropia

Proteccióndelosregistrosdeauditoríacontramodificación,eliminaciónofalsificación,asegurandoquela evidenciarecolectadamantienesuvalorprobatorioalo largodeltiempo(Schneier&Kelsey, 1999).

2.2 DefiniciónyMarcoConceptualdelRegistrosdeAuditoría

Elconceptode“AuditTrail”oRastrodeAuditoríaconstituye elmecanismotécnicofundamentalqueposibilitalaauditabilidad deunsistemadesoftware.Estaafirmación,aunquesimpleen superficie,implicaunacomplejidadtécnicayconceptualconsiderable quemereceanálisisexhaustivo.Unregistrodeauditoríanoes meramenteunarchivodelogounatabladebasededatosque registraeventos;esunaconstrucciónsociotécnicaquemediaentre requisitoshumanosderendicióndecuentasycapacidadestécnicas desistemascomputacionales.

ElInstitutoNacionaldeEstándaresyTecnología(NIST),es laagenciadelDepartamentodeComerciodelosEstadosUnidos encargadadeestablecerestándarestécnicos,ofrecelaquequizás

sealadefiniciónformalmásfrecuentementecitadadeunapistade auditoría,enlaPublicaciónEspecial800-92delNISTsobrelaGuía paralaGestióndeRegistrosdeSeguridadInformática.SegúnelNIST (NationalInstituteofStandardsandTechnology, 2024),unapistade auditoríaes:“Unconjuntoderegistrosqueproporcionanevidencia documentaldelasecuenciadeactividadesque,enalgúnmomento, hanafectadoaunaoperación,procedimiento,eventoodispositivo específico”.

Estadefinición,aparentementesimple,tienevarioscomponentes quemerecenunaexplicaciónmásdetallada.

Enprimerlugar,ladefiniciónde“conjuntoderegistros”implica queunapistadeauditoríanoesunsoloregistro,sinounacolección estructuradaderegistros.Estacoleccióndebecumplirconlaspropiedadesdeintegridad,nopuedehaberlagunasinexplicables;orden temporal,debeserposiblereconstruirlasecuenciacronológicade eventos;ycompletitud,debenregistrarsetodosloseventosrelevantes.

Ensegundolugar,elconceptode“evidenciadocumental”resalta lanaturalezaforensedelapistadeauditoría.Losregistrosnoson simplementeinformativos;sonevidenciaquepotencialmentepodría utilizarseenunentornolegaloregulatorio.Estotieneimplicaciones adicionales:losregistrosdebenserfiables,debensergeneradospor sistemasconfiablesyverificables,suintegridadpuededemostrarse; preservados,debenestarprotegidoscontraalteracionesodestrucción; einterpretables,debeserposiblecomprendersusignificadoincluso añosdespuésdesucreación.

Entercerlugar,lanociónde“secuenciadeactividades”apuntaa lanaturalezatemporalycausaldelregistrodeauditoría.Estedebe permitirnosoloreconstruirquésucedió,sinotambiéncuándoyen quéorden.Enlossistemasdistribuidosmodernos,dondeloseventos puedenocurrircasisimultáneamenteendiferentesnodos,mantener elordencausalsuponeundesafíotécnicosignificativo.Estedesafío hasidoobjetodeconsiderableinvestigaciónensistemasdistribuidos, desdeeltrabajodeLamportsobrecausalidad(Lamport, 1978)hasta losalgoritmoscontemporáneospararelojeslógicosyvectoresde

versión.

2.3 AnatomíadeunRegistrodeAuditoría(AuditTrail)

2.3.1

SistemasdeLoggingEstructurado

Lossistemasmodernosdelogginghanevolucionadosignificativamentedesdelossimplesarchivosdetextoplanohaciaarquitecturas deloggingestructuradoquepermiteneltratamientodeloslogs comoconjuntosdedatosestructuradosenlugardemerotexto.Esta evoluciónrespondealanecesidaddeanalizargrandesvolúmenesde eventosensistemasdistribuidosydealtacomplejidad.

Unregistrodeauditoríaindividualdebecapturarinformación suficientepararesponderlaspreguntasfundamentalesderendición decuentas:quién,qué,cuándo,dónde,cómoyporqué.LainvestigacióndeElmasriyNavathe(Elmasri&Navathe, 2004)ensu obrafundamentalsobresistemasdebasesdedatosproporcionaun frameworkútilparaentenderquéconstituyeunregistrodeauditoría efectivoenelcontextodesistemasdebasesdedatos,frameworkque segeneralizabienaotrostiposdesistemas.

2.3.2

Quién(Who)

Identidaddelactorqueiniciólaacción.Ensistemassimples, estopuedeserunnombredeusuario.Ensistemascomplejos,puede requeririnformaciónmásrica:elidentificadordeusuario,elrolbajo elcualoperaban,laaplicaciónoservicioqueusaron,elprocesoo threadespecífico,ypotencialmenteinformacióndesesiónquepermite correlacionarmúltiplesacciones.Escríticodistinguirentreidentidad real(lapersonaosistemaqueautorizólaacción)eidentidadefectiva (lacuentabajolacualseejecutólaacción),particularmenteen contextosdondeocurredelegaciónosuplantacióndeidentidad.

2.3.3 Qué(What)

Laacciónespecíficarealizada.Estodebeserlosuficientemente específicoparasersignificativo.Noessuficienteregistrar‘accesoadatos’;elRastrodeAuditoríadeberegistrarquédatosespecíficosfueron accedidos,quéoperaciónserealizó(lectura,escritura,actualización,

eliminación),quévalorescambiaron(antesydespuésparaupdates), ycuálfueelresultadodelaoperación(éxito,fallo,parcialmente exitosa).Ensistemastransaccionales,estopuedeincluirelIDde transacciónquepermiteagruparmúltiplesoperacionesrelacionadas.

2.3.4 Cuando(When)

Timestampprecisodelevento.Ensistemasdistribuidos,esto presentadesafíossutiles.Losrelojesdediferentesnodospuedenestar desincronizados;untimestampdeunsolonodopuedeserinsuficiente paradeterminarordenamientocausal.Solucionesmodernasutilizan NetworkTimeProtocol(NTP)parasincronizaciónderelojes,pero inclusoconNTP,precisiónestípicamentesoloenelrangode milisegundos.Paraordenamientomáspreciso,seutilizantécnicas comoLamporttimestampsovectorclocksquecapturancausalidad lógicaenlugardetiempofísicoabsoluto.

2.3.5 Dónde(Where)

Ubicacióndesdelacualseoriginólaacción.Ensistemastradicionales,estopuedeserdirecciónIPyhostname.Enambientescloud modernos,puedeincluirzonadedisponibilidad,regióngeográfica, identificadordeinstanciadecontenedor,yespaciodenombresde Kubernetes.Paraaccionesiniciadasporusuarios,puedeincluirinformacióndegeolocalización.Paraaccionesdesistemasautomatizados, debeincluiridentificadordeljoboservicioquelainició.

2.3.6 Cómo(How)

Elmecanismoométodomedianteelcualserealizólaacción.¿Fue atravésdeunainterfazdeusuarioweb?¿UnaAPIREST?¿Una llamadadirectaabasededatos?¿Unjobbatch?.Estainformación esrelevanteparainvestigacionesdeseguridadporquepatrones deaccesoanómalosfrecuentementeserevelanenel“cómo”,un usuarioquenormalmenteaccededatosatravésdelaaplicación webrepentinamentehaciendoconsultasSQLdirectaspuedeindicar compromisodecredenciales.

Porqué(Why)

Estaesladimensiónmásdifícildecapturarautomáticamente. Idealmente,unregistrodeauditoríacapturaríalajustificaciónde negocioparaunaacción.Enalgunossistemasregulados,particularmenteensalud,losusuariospuedenserrequeridosdeproporcionar unarazónexplícitaalaccederciertosdatossensibles.Sinembargo,en lamayoríadelossistemas,el“porqué”debeserinferidodelcontexto, elpropósitodenegociotípicodelaaplicaciónoservicioquegeneró laacción.

Enelecosistema.NET,elframeworkdeLogdenominadoSerilog (SerilogContributors, n.d.)representaelestadodelarteenlogging estructurado.Adiferenciadelasbibliotecastradicionalesdelogging quesebasanencadenasdeformatointerpoladas,Serilogutiliza messagetemplates,unDSL(DomainSpecificLanguage)queextiende lascadenasdeformatode.NETconparámetrosnombrados.Por ejemplo,enlugardeescribir:

1 log.Information(" Usuario " +userId+ " proces ó orden " +orderId);

Serilogpermiteescribir:

1 log.Information(" Usuario { UserId } proces ó orden { OrderId }" ,userId,orderId);

Estaaparentediferenciasintácticatieneimplicacionesprofundas.Enelsegundocaso,SerilogserializauserIdyorderIdcomo propiedadesestructuradasdeleventodelog,permitiendoconsultas posteriorescomo“mostrartodosloseventosdondeOrderId=12345” sinnecesidaddehacer“parsing”detextooexpresionesregulares.

LaarquitecturadeSerilogsebasaenelconceptode“sinks” (depósitososumideros)querepresentandestinosparaloseventosde log:archivos,consola,basesdedatos,serviciosenlanube,sistemas SIEM(SecurityInformationandEventManagement),entreotros. Estaarquitecturapermitequelamismaaplicaciónenvíelogsa múltiplesdestinossimultáneamentesinmodificarelcódigodenegocio

Sinembargo,unregistrodeauditoríasoloesútilsiesconfiable, enelsentidodequepuedeusarsecomoevidenciadeloquerealmente sucedió.Paraserconfiable,unregistrodeauditoríadebecumplircon laspropiedadesdeseguridaddeintegridadynorepudio.

Integridad: Laintegridaddeunregistrodeauditoríaserefierea lapropiedaddeque,unavezregistradoslosdatos,estosnopueden alterarse,eliminarsenifalsificarse.Estapropiedadesimportante porqueunatacanteopersonaconaccesointernoquepuedamodificar unregistrodeauditoríapuedeusarestacapacidadparaocultarsus huellas,enmascarandoasícomportamientosmaliciosos.

ImplementarlaintegridaddelRegistrosdeAuditoríanoessencillo. Elenfoquemássencilloconsisteenregistrarelregistrodeauditoría enmediosdeescrituraúnicaylecturamúltiple(WORM)(VeritasChain, n.d.).Sibienconceptualmentesimple,esteenfoquesueleser pocoprácticoporrazonesdecosteyoperativas.Unenfoquemás sofisticadoconsisteenutilizartécnicascriptográficasparadificultar lamanipulacióndelosdatosdelRegistrosdeAuditoría.Unesquema clásico,consisteenquecadaentradadelregistrodeauditoríaseauna funcióndelaentradaanterior;enconcreto,cadaentradacontieneun hashcriptográficodelaentradaanterior.Estocreaunacadenade entradasenlazadas:siunatacanteintentamodificarunaentrada,la cadenaserompe,yestehechoesdetectable(DataSunrise, 2025).

Figura3: Mecanismodefirmadigitalparagarantíadenorepudioenregistros deauditoría

Nota:ElaboraciónPropia

LaFigura 3 descomponeelmecanismomedianteelcualunsistema auditableconvierteunaacciónhumanaenevidenciairrefutable.El procesonocomienzaenelmomentodelregistro,sinoantes:enla verificacióndeidentidaddelactor.Sinautenticaciónrobustaen elpuntodeentrada,cualquierregistroposteriorcarecedevalor probatorio,porquenoesposiblevincularlaacciónaunapersonao entidadresponsabledeformainequívoca.

Unavezqueelactorautenticadoejecutalaoperación,elsistema generaunahuelladigitaldeleventomedianteunafunciónhash criptográfica,típicamenteSHA-256enimplementacionesmodernas, queproduceunvalorúnicoeirreproducibleapartirdelcontenido exactodelregistro.Lapropiedadmatemáticafundamentaldeestas funcionesesquecualquieralteracióndelcontenido,pormínimaque sea,produceunhashcompletamentedistinto.Estosignificaquela huellanopuedefalsificarsesinquelafalsificaciónseadetectable. Acontinuación,unsellodetiempocertificadoporunaAutoridad deSelladodeTiempo,bajoelestándarRFC3161,anclaelevento aunmomentocronológicoverificableporterceros,impidiendoque elregistroseaantedatadoopostdatado.Elresultadofinalesun registrofirmadoquegarantizasimultáneamentetrespropiedades:

autenticidad,entantosoloeltitulardelaclaveprivadapudogenerar esafirma;integridad,entantocualquiermodificacióndelcontenido invalidalafirma;ynorepudio,entantoelactornopuedenegar posteriormentehaberejecutadolaacciónsincontradecirlaevidencia criptográfica.

Estemecanismoesexactamenteelqueestabaausenteenlos sistemasdecontratacióndePetroecuadorduranteelcasoOdebrecht: sinfirmasdigitalesenlosdocumentosdeadjudicaciónnisellosde tiempocertificados,unmismocontratopodíacircularconversiones distintasantedistintosactoresdelproceso,yningunaherramienta técnicapermitíadeterminarcuálversióneralaoriginalniquiénhabía autorizadocadamodificación.

Figura4: Cadenadehashescriptográficosparaintegridadderegistros

Nota:ElaboraciónPropia

LaFigura 4 materializaelconceptoabstractodeintegridad mediantesuimplementaciónmásdirecta:lacadenadehashes criptográficos.Elprincipiodefuncionamientoeseleganteensu simplicidadyrobustoensusconsecuencias.Cadaregistrodeauditoría noesunaentradaindependiente,sinouneslabónqueincorporaensu propiocontenidolahuelladigitaldelregistroanterior.Deestemodo, elsistemaconstruyeunadependenciamatemáticaacumulativa:el

registroNsolopuedeexistirconesevalordehashsielregistroN-1 teníaexactamenteesecontenido,yelregistroN-1solopuedetener esehashsielN-2nofuealterado,yasísucesivamentehastaelprimer registrodelacadena.

Laparteinferiordelafigurailustralaconsecuenciainmediatade cualquierintentodemanipulación.Siunactorconaccesoprivilegiado modificalosdatosdelregistroN,suprimiendounatransacción comprometedora,alterandounmonto,cambiandounafecha,elhash queeseregistrorecalculayanocoincideconelhashqueelregistroN+1 almacenacomoreferenciadesupredecesor.Lacadenaserompeen esepuntodeformadetectableyobjetiva,sinnecesidaddetestimonio humanonidecomparacióncontraunacopiaexterna.Elsistemase auditaasímismo.

Estapropiedadtieneimplicacionesdirectasparaeldiseñode softwareauditableenelsectorpúblicoecuatoriano.Enelcasode Filanbanco,laexistenciadedoscontabilidadesparalelasfueposible precisamenteporquelosregistrospodíanmodificarsesindejarrastro verificabledelamodificación.Unesquemadecadenadehashes habríaconvertidocadaalteraciónenunaanomalíamatemáticamente demostrable,detectableporcualquierauditorconaccesoallog,sin dependerdetestigosinternosnideinvestigacionesposterioresde añosdeduración.Ladiferenciaentreunsistemaqueregistrayun sistemaquegarantizaintegridadnoesdegrado:esladiferenciaentre evidenciaymerainformación.

2.5 RegistrosdeAuditoríaenBasesdeDatos

Lasbasesdedatosmerecenatenciónespecialencualquierdiscusión deregistrosdeauditoríaporquecontienenfrecuentementelosactivos másvaliososdeunaorganizaciónysonobjetivoprincipaltantode atacantesexternoscomodeamenazasinternas.

Lossistemasdegestióndebasesdedatos(DBMS)mantienen inherentementeciertostiposdelogsparapropósitosderecuperación antefallos.Eltransactionlogowrite-aheadlog(WAL)(Mohan etal., 1992)esunmecanismoestándarenvirtualmentetodoslos

DBMSquesoportantransaccionesACID.Estelogregistratodas lasmodificacioneshechasalabasededatosdemaneraqueel DBMSpuederecuperarsedecrashesmediantereplayorollbackde transacciones.Sinembargo,lostransactionlogs(Grokipedia, 2026) estándiseñadospararecuperación,noparaauditoría,ytípicamente nocapturantodalainformaciónrequeridaparapropósitosdeRastro deAuditoría.

Paraauditoríaefectiva,losDBMSdebenextenderunlogging transaccionalbásicoconinformaciónadicional.Seproponentres enfoquesprincipalesparaimplementarregistrosdeauditoríaen basesdedatos,cadaunocondiferentestrade-offsentrecompletitud, performanceycomplejidaddeimplementación:

2.5.1 Auditoríabasadaentriggers

Esteenfoqueimplementadatabasetriggersqueautomáticamente sedisparancuandoocurrenoperacionesdeINSERT,UPDATE oDELETEentablasdesignadascomocríticas(IBM, n.d.).Los triggersregistraninformaciónrelevantedeauditoría,típicamente elusuarioquehizoelcambio,timestamp,losvaloresantiguos ynuevosdedatosmodificados,entablasdeauditoríaseparadas. Esteenfoquetienelaventajadesertransparenteparaaplicaciones; noserequieremodificacióndecódigodeaplicación.Sinembargo, tienevariasdesventajas.Primero,lostriggersañadenoverheada cadaoperaciónentablasauditadas,potencialmenteimpactando performancesignificativamente.Segundo,lostriggerspuedenser deshabilitadosporusuariosconprivilegiossuficientes,creandouna potencialvulnerabilidaddeseguridad.Tercero,lostriggerscapturan solocambiosqueocurrenatravésdeoperacionesDMLnormales;no capturannecesariamentecambioshechosmedianteoperacionesDDL, operacionesbulk,oaccesodirectoaarchivosdebasededatos.

2.5.2 Auditoríamediantetransactionlogs

EsteenfoqueextiendeeltransactionlogexistentedelDBMS (Grokipedia, 2026)paraincluirinformaciónadicionaldeauditoría comoelidentificadordeusuario,elterminaloaplicacióndesde elcualseejecutólatransacción,ypotencialmenteotrametadata

contextual.Esteenfoquetieneoverheaddeperformancerelativamente bajoporqueelDBMSyaestámanteniendountransactionlog.Sin embargo,presentadesafíos.Lostransactionlogssontípicamente escritosenformatobinariopropietariooptimizadopararecuperación rápida,noparalecturahumana.Extraerinformacióndeauditoría requiereherramientasespecializadasqueentiendanelformatode logespecíficodelDBMS.Además,transactionlogstípicamente searchivanoeliminandespuésdeciertoperíodoparagestiónde espacio,potencialmenteviolandorequisitosderetenciónderegistros deauditoría(IBM, n.d.).

2.5.3 Auditoríaaniveldeaplicación

Esteenfoqueimplementalógicadeauditoríaexplícitamenteenel códigodeaplicación.Cadavezquelaaplicaciónrealizaunaoperación crítica,tambiénregistraexplícitamenteuneventodeauditoría («Audittrail», n.d.).Esteenfoqueproporcionamáximaflexibilidad, laaplicaciónpuederegistrarexactamenteloqueesrelevantedesde perspectivadenegocio,puedecapturarcontextodenegocioricoque labasededatosnoconoce,ypuedeimplementarlógicadeauditoría sofisticadaquevamásalládesimplementeregistrarcambiosdedatos. Sinembargo,requieredisciplinayvigilanciarigurosaendesarrollo. Esfácilolvidaragregarloggingdeauditoríaanuevascaracterísticas opasarporaltoloscasosedge.Silaaplicaciónescomprometida,un atacantepuedepotencialmenteevitaromanipularauditoríaanivel deaplicación.

Enlapráctica,organizacionessofisticadasfrecuentementeutilizan combinacionesdeestosenfoques,implementandodefense-in-depth pararegistrosdeauditoría.Porejemplo,triggersdebasededatos podríancapturartodosloscambioscomofallback,mientrasque códigodeaplicaciónregistrainformacióncontextualmásricapara flujosnormales.

Capítulo3

MARCOSREGULATORIOSY NORMATIVOS

ElestándarIEEE1028-2008,tituladoformalmente“IEEEStandardforSoftwareReviewsandAudits”(InstituteofElectricaland ElectronicsEngineers, 2008),constituyeelmarconormativotécnico másampliamentereconocidoparalaconduccióndeauditoríasde software.PublicadoporelIEEEComputerSocietyyaprobadopor laIEEEStandardsBoardel16dejuniode2008,esteestándar representadécadasdeconocimientoconsolidadosobrecómoevaluar sistemáticamenteproductosyprocesosdesoftware.

IEEE1028-2008esunarevisióndeIEEEStd1028-1997(Institute ofElectricalandElectronicsEngineers, 1997),queasuvezrevisó IEEEStd1028-1988.Estagenealogíaderevisionesreflejalaevolución continuademejoresprácticaseningenieríadesoftwareylanecesidaddeactualizarestándaresparareflejarcambiosentecnologías, metodologíasycontextoregulatorio.Laversión2008hizocambios mayoresenestructuraycontenidocomparadaconlaversión1997, reflejandoexperienciaacumuladayretroalimentacióndelaindustria sobrelaaplicacióndelestándar.

ElpropósitodeclaradodeIEEE1028esproporcionarrequisitos mínimosaceptablespararevisionessistemáticasdesoftware,donde “sistemático”incluyeparticipacióndeequipo,resultadosdocumentados,yprocedimientosdefinidos.IEEE1028noespecificacómo determinarsiunarevisiónoauditoríaesnecesaria,esadecisión quedarelegadaalaorganización.Tampocoespecificaquéhacercon losresultadosdeunarevisiónoauditoría,elestándarseenfoca puramenteenelprocesodeconducirlarevisiónoauditoríamisma.

3.2 ISO/IEC25010:ModelodeCalidaddeSoftware

ElestándarISO/IEC25010(InternationalOrganizationfor Standardization, 2011),partedelaserieSQuaRE(Systemsand softwareQualityRequirementsandEvaluation),proporcionaun modelocomprensivodecalidaddesoftwareque,aunquenoenfocado exclusivamenteenauditabilidad,incluyecaracterísticasdecalidadque sonfundamentalesparasoftwareauditable.Publicadooriginalmente

en2011comoreemplazodeISO/IEC9126yactualizadoen2023, ISO/IEC25010reflejadécadasdeinvestigaciónacadémicaeindustrial sobrecómomediryevaluarcalidaddesoftware.

ISO/IEC25010organizacalidaddesoftwareendosmodelos complementarios:unmodelodecalidaddelproductoyunmodelode calidadenuso.Estadualidadreconocequelacalidaddebeevaluarse tantodesdeunaperspectivatécnica(propiedadesdelproductode softwaremismo)comodesdeunaperspectivadeusuario(efectividad delproductocuandoseusaencontextoreal).Parapropósitosde entenderlaauditabilidad,elmodelodecalidaddelproductoes primariamenterelevante.

3.3 GDPR:ElReglamentoGeneraldeProteccióndeDatos

ElReglamentoGeneraldeProteccióndeDatosdelaUnión Europea(GDPRporsussiglaseninglés)(EuropeanUnion, 2016a), queentróenvigenciael25demayode2018,representaquizásla regulacióndeprivacidadmáscompletaeinfluyentejamáspromulgada. Con99artículosy173considerandosqueabarcan88páginasde textolegaldenso,GDPRestableceunrégimenregulatorioqueha servidocomomodeloparalalegislacióndeprivacidadenmúltiples jurisdiccionesglobalesy,haforzadocambiosfundamentalesencómo lasorganizacionesalrededordelmundoprocesandatospersonales.

GDPRseaplicaacualquierorganizaciónqueprocesadatos personalesdeindividuosubicadosenlaUniónEuropea,independientementededóndeestéubicadalaorganizaciónmisma.Esta aplicaciónextraterritorialhadadoaGDPRinfluenciaglobal.Ejemplo, unacompañíaestadounidensequeoperaunsitiowebaccesibledesde Europa,ounaempresachinaquevendeproductosaconsumidores europeos,ounproveedordeservicioscloudquealmacenadatosde clienteseuropeos,todosestánpotencialmentesujetosaGDPR.Esta jurisdicciónextraterritorialesexplícitaenelArtículo3,queespecifica queGDPRseaplicaalprocesamientodedatospersonalesencontexto deactividadesdeunestablecimientodeuncontroladoroprocesador enlaUE,asícomoalprocesamientodedatospersonalesdeindividuos

queestánenlaUEporuncontroladoroprocesadornoestablecido enlaUE,dondelasactividadesdeprocesamientoestánrelacionadas conofrecerbienesoserviciosatalesindividuoso,monitorearsu comportamiento.

3.4 HIPAAylosControlesdeAuditoría

LaHIPAASecurityRule,específicamenteenelestándar45CFR 164.312(b)(U.S.DepartmentofHealthandHumanServices, n.d.a),establecerequisitosexplícitosparacontrolesdeauditoría.Las entidadescubiertasyasociadosdenegociodeben“implementar mecanismosdehardware,softwarey/oprocedimientosqueregistren yexaminenlaactividadenlossistemasdeinformaciónquecontienen ousaninformacióndesaludelectrónicaprotegida(ePHI)”.

ElArtículo33delGDPRimponeunplazode72horaspara notificarbrechasdedatosalasautoridadessupervisoras,mientras queHIPAArequierenotificacióndentrode60días.Estasdiferencias enlosplazosdenotificacióntienenimplicacionessignificativasparael diseñodesistemasdemonitoreoydeteccióndeincidentes,requiriendo capacidadesdeanálisisentiemporealocasitiemporeal.

3.5 PrincipiosFundamentalesyelConceptodeAccountability

Elartículo5delGDPR(EuropeanUnion, 2016b)enumeralos 7principiosclaveparaeltratamientodedatospersonales.Estos principiosnoconstituyendirectrices,sinoobligacioneslegales,ysu incumplimientopuedeconllevarmultascuantiosas.Los7principios son:licitud,lealtadytransparencia;limitacióndelafinalidad; minimizacióndedatos;exactitud;limitacióndelalmacenamiento; integridadyconfidencialidad;yrendicióndecuentas.

Elprincipioderendicióndecuentas(artículo5(2))esmuy interesantedesdelaperspectivadelaauditabilidaddelsoftware: “Elresponsabledeltratamientoseencargarádelcumplimiento delapartado1ypodrádemostrarlo.Elelementoclaveaquíes la“capacidaddedemostrar”.Nobastaconquesuorganización

cumplaconelGDPR;tambiéndebepoderdemostrarlomediante documentación,procesosysistemasauditables.

ElprincipioderendicióndecuentasseimplementaenelGDPR medianteelartículo30,queexigequelosresponsablesyencargados deltratamientomantenganregistrosdelasactividadesdetratamiento, quedebencontenerelnombreylosdatosdecontactodelresponsable deltratamiento,losfinesdeltratamiento,Unadescripcióndelas categoríasdeinteresadosydedatospersonales;lascategoríasde destinatariosaquienessehandivulgadoosedivulgaránlosdatos; cualquiertransferenciadedatospersonalesatercerospaíses;los plazosprevistosparalasupresióndelasdiferentescategoríasde datos;yunadescripcióngeneraldelasmedidasdeseguridadtécnicas yorganizativas.

Estosignificaquelosresponsablesdeltratamientoqueutilizan sistemasdesoftwarecomplejosnecesitanunregistrodeauditoría completo.Nobastacontenerregistrosestáticosdelosdatosquese procesan;losresponsablesdeltratamientodebenpoderdemostrar, basándoseenregistrosauditables,quéprocesamientoseharealizado, quiénlohaautorizado,bajoquébaselegalyquégarantíasseaplican.

3.6 ProteccióndeInformacióndeSaludenEstadosUnidos

EnEstadosUnidos,laLeydePortabilidadyResponsabilidad delSeguroMédico(HIPAA)de1996(U.S.DepartmentofHealth andHumanServices, n.d.-c),estableceestándaresnacionalesparala seguridaddelainformaciónsanitariaelectrónica.Sibienseadoptó másde20añosantesdelGDPR,laHIPAAfueigualmentepionera ensumomentoalexigirgarantíastécnicasparaprotegerlosdatos sensibles.Enelcontextodelaauditabilidad,laNormadeSeguridad delaHIPAArevisteespecialinterés.

Publicadaen2003,laNormadeSeguridadesunaregulación federalquedescribeunaseriedeestándaresyespecificacionesde implementaciónquedebenimplementarseparaprotegerlaconfidencialidad,integridadydisponibilidaddelainformaciónmédica electrónicaprotegida(ePHI),segúnloexigelaLeydePortabilidady

ResponsabilidaddelSeguroMédicode1996.Lasentidadescubiertas ysussocioscomercialesdebenadherirsealosestándaresquedetallan cómoprotegerlainformaciónmédicaelectrónicaprotegida(ePHI) segúnlaNormadeSeguridad.

45CFR164.312(b)(U.S.DepartmentofHealthandHumanServices, n.d.-b)eslaespecificaciónparalosControlesdeAuditoría.El textodelaespecificaciónesconciso,perosusignificadoessustancial: “Implementarhardware,softwarey/omecanismosdeprocedimiento queregistrenyexaminenlaactividadenlossistemasdeinformación quecontienenoutilizaninformaciónmédicaelectrónicaprotegida”. Estaesunaespecificacióndeimplementaciónabordable,peroenla práctica,casitodaslasorganizacioneslaimplementan.Sinregistros deauditoría,escasiimposibledemostrarqueseestáprotegiendo adecuadamentelaePHI.

LaguíadelDepartmentofHealthandHumanServicessobrela SecurityRulemencionasobrequédebencapturarloscontrolesde auditoría.LosregistrosdeauditoríadebenregistraraccesoaePHI, intentosdeaccesonegados,cambiosoeliminacionesdeePHI,yacceso alosregistrosdeauditoríamismos.Laguíaenfatizaquelosregistros deauditoríasontantoparadetectarbrechasdeseguridadcomopara investigarlasdespuésdequeocurren(U.S.DepartmentofHealthand HumanServices, n.d.-c).

ElReglamentoGeneraldeProteccióndeDatos(GDPR)dela UniónEuropeaintroducerequisitosespecíficosdeauditabilidaden susartículos30(registrosdeactividadesdeprocesamiento),33 (notificacióndebrechasdeseguridad)y35(evaluacionesdeimpacto enproteccióndedatos),estableciendoquelasorganizacionesdeben poderdemostrarelcumplimientomedianteevidenciadocumentaly técnica(EuropeanUnion, 2016b).

Enelcontextolatinoamericano,regulacionescomolaLeydeProteccióndeDatosPersonalesdeArgentina(Ley25.326),laLeyFederal deProteccióndeDatosPersonalesenPosesióndelosParticularesde México(2010)ynormativasespecíficasdeinstitucionesfinancieras comolaSuperintendenciadeBancosenEcuadorestablecenrequisitos

similaresdetrazabilidadyauditabilidadparasistemasqueprocesan datossensibles(Saltor, 2013).

3.7 ProteccióndeDatosPersonales(GDPR)enEcuador

LaproteccióndedatospersonalesenEcuadorbuscaquela informacióndelaspersonasseatratadaconrespetoyresponsabilidad. AunqueelGDPResunanormaeuropea,muchosdesusprincipios influyenenlalegislaciónecuatorianayenlaformaenquelas organizacionesmanejandatospersonales.Estoimplicarecopilarsolo lainformaciónnecesaria,usarlademaneratransparente,protegerla conmedidasdeseguridadadecuadasypermitirquelaspersonas conozcan,corrijanosolicitenlaeliminacióndesusdatos.Enla práctica,setratadegenerarconfianza,evitarabusosyasegurarque elusodelainformaciónestéalineadotantoconlaleylocalcomocon buenasprácticasreconocidasanivelinternacional.

3.7.1 InfluenciadelGDPReuropeoenEcuador

ElReglamento(UE)n.º 2016/679delParlamentoEuropeoydel Consejo,de27deabrilde2016,entróenvigorel25demayode2018 (EuropeanUnion, 2016b)yeselreglamentodeproteccióndedatos másamplioeimportanteanivelmundial.Apesardeserunaley europea,elGDPRtieneimplicacionesparalasentidadesecuatorianas quetratandatosderesidentesdelaUEoquetienenunaoficinao establecimientoenlaUE.

ElámbitodeaplicaciónterritorialdelGDPRsedefineenel artículo3.Elartículo3.1establecequeelGDPRseaplicaal tratamientodedatospersonales“enelcontextodelasactividades deunestablecimientodeunresponsableodeunencargadodel tratamientoenlaUnión,independientementedequeeltratamiento tengalugaronoenlaUnión”.ElArtículo3.2establecequeelGDPR tambiénseaplicaaltratamientodedatospersonalesdeinteresadosen laUniónporpartedeunresponsableoencargadodeltratamientono establecidoenlaUnión,cuandolasactividadesdetratamientoestén relacionadasconla“ofertadebienesoservicios,independientemente desiserequiereelpagodelinteresado,adichosinteresadosenla

Unión”oconla“supervisióndesucomportamiento,siemprequeeste tengalugardentrodelaUnión”.

Esteefectoextraterritorialimplicaqueunaempresaecuatoriana queofrezcaserviciosdecomercioelectrónicodirigidosalmercado europeo,quegestionedatospersonalesderesidentesdelaUEoque superviselaactividadeninternetdeusuariosresidentesenEuropa, estaráobligadaacumplirconelGDPRy,porlotanto,acumplir contodassusmedidasdeproteccióndedatos,queincluyenmedidas concretasdeauditoríayrendicióndecuentas.

3.7.2 RequisitosdeAuditoríayAccountabilitydelGDPR

UnodelosconceptosrelevantesenlosquesebasaelGDPRes eldelarendicióndecuentas(responsabilidadproactiva).Segúnel Artículo5(2):“Elresponsabledeltratamientodarácumplimientode lasdisposicionesestablecidasenelapartado1ypodrádemostrarlo (“rendicióndecuentasproactiva”)”.Enesencia,estosignificaquelas organizacionesnosolodeberánadherirsealosprincipiosdeprotección dedatos,sinoquetambiéndeberándemostrarloconpruebasquelo respalden.

Losregistrosdelasactividadesdetratamientosonahoraun requisitoformalsegúnelartículo30(1)delGDPR:cadaresponsable deltratamientoy,ensucaso,surepresentante,mantendránun registrodelasactividadesdetratamientobajosuresponsabilidad.El responsabledeltratamientoosurepresentantepondráesteregistro adisposicióndelaautoridaddecontrolpreviasolicitud.Dichos registroscontendrántodalainformaciónsiguiente:elnombrey losdatosdecontactodelresponsabledeltratamientoy,ensu caso,delcorresponsabledeltratamiento,surepresentanteyel delegadodeproteccióndedatos;losfinesdeltratamiento;una descripcióndelascategoríasdeinteresadosydelascategoríasde datospersonales;lascategoríasdedestinatariosalosquesehan comunicadoosecomunicaránlosdatospersonales,incluidoslos destinatariosentercerospaísesuorganizacionesinternacionales;en sucaso,lastransferenciasdedatospersonalesauntercerpaísouna organizacióninternacional,incluidalaidentificacióndedichotercer

paísuorganizacióninternacionaly,enelcasodelastransferenciasa queserefiereelartículo49(1),párrafosegundo,ladocumentación delasgarantíasadecuadas;cuandoseaposible,losplazosprevistos paralasupresióndelasdiferentescategoríasdedatos;cuandosea posible,unadescripcióngeneraldelosaspectostécnicosyMedidas deseguridadorganizativasaqueserefiereelArtículo32(1).

Estosdocumentosconstituyenregistrosadministrativosqueregistrancómounaorganizacióngestionalainformaciónpersonal.Deben serescritos,posiblementeelectrónicos,yponerseadisposiciónde lasautoridadesquelosoliciten(Artículo30.4).Esterequisitonose aplicaalasorganizacionesconmenosde250empleados,amenos queeltratamientoimpliqueunriesgoparalosderechosylibertades delosinteresados,noseaocasionaloincluyacategoríasespecialesde datos(Artículo30.5).

ElArtículo32abordalaseguridaddeltratamientoyestablece queelresponsableyelencargadodeltratamientodebenimplementar medidastécnicasyorganizativasapropiadasparagarantizarunnivel deseguridadadecuadoalriesgo.ElArtículo32(1)(d)estableceque estodebeincluir“procedimientosparalacomprobación,evaluación yvaloraciónperiódicasdelaeficaciadelasmedidastécnicasy organizativasparagarantizarlaseguridaddeltratamiento”.Esto implicaauditoríasdeseguridadperiódicas,pruebasdecontroly documentacióndelosresultados.

Elartículo33exigequelasnotificacionesdeviolacionesdedatos personalesseenvíenalaautoridaddecontrolenunplazode72horas desdesuconocimiento,siemprequeseaprobablequesupongaun riesgoparalosderechosylibertadesdelaspersonasfísicas.Elartículo 34exigequelasviolacionessecomuniquenalosinteresadossies probablequesuponganunaltoriesgoparasusderechosylibertades. Estosrequisitosdenotificaciónimplicanquelasorganizacionesdeben poderdetectarrápidamentelasviolacionesmediantesistemasde seguimiento,determinarsualcancemedianteelanálisisderegistros deauditoríaydocumentarexhaustivamenteelincidente(hechos, consecuenciasymedidasdemitigación)(artículo33(5)).

3.7.3 MarcoConstitucionalEcuatorianodeProtecciónde Datos

Ecuadorreconocelaproteccióndedatospersonalescomoderecho constitucional.LaConstitucióndelaRepúblicadelEcuadorde2008 (RegistroOficial, 2008),estableceensuArtículo66,numeral19,el derechoalaproteccióndedatosdecarácterpersonal,incluyendo accesoydecisiónsobreinformaciónydatosdeestecarácter,asícomo sucorrespondienteprotección.Elmismoartículoespecificaquela recolección,archivo,procesamiento,distribuciónodifusióndedatos oinformaciónpersonalrequierenautorizacióndeltitularomandato deley.

ElArtículo92delaConstituciónestablecelaaccióndehábeas data,mecanismoconstitucionalmedianteelcualtodapersonapuede conocerdelaexistenciayaccederadocumentos,datosgenéticos, bancosoarchivosdedatospersonaleseinformesquesobresímisma constenenentidadespúblicasoprivadas.Tambiénpuedesolicitar actualización,rectificación,eliminaciónoanulacióndedatosque fuerenerróneosoafectenilegítimamentesusderechos.

3.7.4 LeyOrgánicadeProteccióndeDatosPersonales (2021)

ÁmbitodeAplicación:Elartículo3delaLOPDP(RegistroOficial, 2021),establecequelaleyseaplicaráaltratamientoautomatizado oparcialmenteautomatizadodedatospersonales,asícomoal tratamientonoautomatizadodedatosdestinadosaformarparte deunarchivo.Laleyseaplicaráalosresponsablesyencargados deltratamientodedatosenEcuador,dondequieraqueserealiceel tratamiento(artículo3,apartadoa),asícomoalosresponsables yencargadosnoestablecidosenEcuador,cuandolaactividad detratamientotengaporobjetoofrecerbienesoserviciosalos interesadosenEcuadoroestérelacionadaconlavigilanciadesu comportamientoenterritorioecuatoriano(artículo3,apartadob). Ladisposiciónreproduceesencialmenteeltextosobrelaaplicación extraterritorialdelGDPRyloadaptaalajurisdicciónecuatoriana.

PrincipiosdeProteccióndeDatos: Elartículo8dela

LOPDP(RegistroOficial, 2021),detallalosprincipiosquedeben observarseeneltratamientodedatospersonales,como:(a)licitud (tratamientolícitoyrespetodelosderechosdelinteresado);(b)lealtad ytransparencia(transparenciadelainformaciónparaelinteresado); (c)limitacióndelafinalidad(finalidadespecífica,explícitaylegítima); (d)minimizacióndedatos(adecuada,pertinenteylimitadaalo necesario);(e)exactitud(exactayactualizada);(f)limitacióndel almacenamiento(duranteeltiemponecesario);y(g)seguridad (medidastécnicasyorganizativasadecuadas).

Elrequisitoclaveparalaauditoríaeselartículo8,apartadof), queexigealosresponsablesdeltratamiento:“aplicarprincipiosy directricesparagarantizarypoderdemostrarqueeltratamiento dedatospersonalescumpleconestaLeyyquepodrándemostrar dichocumplimientoantelaAutoridaddeProteccióndeDatos”.Al igualqueelartículo5.2delGDPR,esteartículoexigeclaramentela presentacióndepruebasdedichocumplimiento.

RegistrodeActividadesdeTratamiento: Losresponsables yencargadosdeltratamientodeberánmantenerregistrosdelas actividadesdetratamientobajosuresponsabilidad.

Elartículo35delaLOPDP(RegistroOficial, 2021),establece quecadaresponsableyencargadodeltratamientodebemantenerun registrodelasoperacionesdetratamientobajosuresponsabilidad.La informaciónquedebecontenerelregistroessimilaralaestablecida enelartículo30delGDPR:identidaddelresponsable,finesdeltratamiento,descripcióndelosinteresadosydelosdatos,destinatarios, transferenciasatercerospaíses,plazosdeconservaciónydescripción delasmedidasdeseguridad(artículo35,apartados1-8).

Elartículo35,apartado2,establecequeelregistrodebepresentarse alaAutoridaddeProteccióndeDatoscuandoselosolicite.Esta obligaciónrecaesobretodaslasorganizaciones,exceptoaquellascon menosdeveinteempleados(menorqueelGDPR),amenosqueel tratamientopresenteunriesgoparalosderechosdelosinteresados, noseaocasionaloincluyadatossensibles(artículo35,apartado3).

SeguridaddelTratamiento: Segúnelartículo34delaLOPDP

(RegistroOficial, 2021),losresponsablesyencargadosdeltratamiento debenadoptarmedidastécnicas,organizativasylegalesadecuadas paraprotegerlosdatospersonales.Enparticular,dichasmedidasdebenevitarlapérdida,alteración,tratamientooaccesonoautorizado; garantizarlaconfidencialidad,integridad,disponibilidadyresiliencia delossistemasdetratamiento;restablecerladisponibilidadyel accesoalosdatosdeformaoportunaencasodeincidente;yverificar, evaluaryvalorarperiódicamentelaeficaciadelasmedidastécnicas yorganizativas(artículo34,apartadosa-d).

Elapartadodestablecelosmismosrequisitosqueelartículo 32(1)(d)delGDPRy,porlotanto,exigequelasorganizacionesecuatorianastenganlaobligaciónlegaldemantenersistemasauditables,y quedichasauditoríassepuedanrealizarperiódicamenteparavalidar loscontrolesestablecidos.

NotificacióndeViolacionesdeSeguridad: Losartículos37y 38delaLOPDP(RegistroOficial, 2021),describenlasdisposiciones sobrenotificacióndeviolaciones,similaresalasdelGDPR.Elartículo 37estipulaquelosresponsablesdeltratamientodebennotificarala AutoridaddeProteccióndeDatoslaviolacióndedatosenunplazo de72horasdesdesuconocimiento,siestapudierasuponerunriesgo paralosderechosdelinteresado.Elartículo38estipulaquesedebe informaralinteresadoafectadodelaviolacióncuandoseaprobable querepresenteunaltoriesgoparasusderechos.

Paracumplirconestasobligacionesdenotificación,lasorganizacionesdeberánsercapacesde:identificarlasviolaciones(mediante sistemasdeseguimientoyanálisisderegistrosdeauditoría),evaluar elalcanceylosdañoscausadosporlasviolaciones(realizandoanálisis forensesderegistros)yregistrar:loshechosquerodeanlaviolación; lascategoríasyelnúmerodeinteresados(y,cuandoseaposible,los registros)afectados;losefectosdelaviolación;ylasmedidasya adoptadasopropuestas(artículo37,apartados1-4).

AutoridaddeProteccióndeDatosPersonales: Elartículo 55delaLOPDP(RegistroOficial, 2021),establecelaAutoridad deProteccióndeDatos,adscritaalaDefensoríadelPueblo,con

autonomíaadministrativa,operativayfinanciera.LaAutoridadde ProteccióndeDatostendrácompetenciasdesupervisión,investigaciónysanciónenmateriadeproteccióndedatospersonales,similares alasdelasautoridadeseuropeasdeproteccióndedatosprevistasen elGDPR.

Elartículo57definelasfuncionesdelaAutoridad,queincluyen:supervisarygarantizarlaaplicacióndelReglamento,atender reclamaciones,realizarinvestigaciones,imponermultasosanciones coercitivas,emitiradvertencias,órdenesyamonestaciones,aprobar certificacionesdeproteccióndedatos,aprobarnormascorporativas vinculantes,aprobaroaprobarloscriteriosdecertificación,establecer cláusulastipodeproteccióndedatos,prestarasesoramiento,mantener unalistadelasoperacionesdetratamientosujetasalrequisitode unaevaluacióndeimpactodelaproteccióndedatosyfomentarla elaboracióndecódigosdeconducta(artículo57,letrasaal).

Elartículo62defineelrégimendesancionesadministrativaspara lasinfracciones,quesecalificancomoleves,gravesymuygraves, segúnloscriteriosestablecidosenelartículo60.Estassanciones incluyenunaadvertencia;Multadel0,1%al4%delafacturación anualtotaldelejercicioanterior,hastaunmáximode250000USD; suspensióntemporaldelasactividadesdetratamientodedatos;y prohibiciónpermanentedeltratamientodedatos(artículo62).Este régimendesancionesesproporcionado,aunquemenosextensoque eldelGDPR(hasta20millonesdeeurosoel4%delafacturación anualtotal,lacantidadqueseamayor).

3.7.5 ReglamentodelaLOPDP(2023)

ElReglamentoalaLeyOrgánicadeProteccióndeDatosPersonalesfueemitidomedianteDecretoEjecutivoNo.678de30de marzode2023(RegistroOficial, 2023),publicadoenRegistroOficial Suplemento267de7deabrilde2023.ElReglamentodesarrolla aspectosoperativosdelaLOPDPyproporcionaguíamásdetallada sobreimplementacióndeobligaciones.

ElArtículo18delReglamentoespecificacontenidomínimodel registrodeactividadesdetratamientoconmayordetallequela

LOPDP.ElArtículo19establecequeelregistrodebeactualizarse almenosanualmenteocuandoocurrancambiossignificativosen actividadesdetratamiento.ElArtículo20especificaformatodel registro,permitiendoformatoelectrónicoofísico,perorequiriendo queseaaccesible,organizado,ycomprensible.

Losartículos23-27delReglamentosonmásespecíficosyserefieren alasmedidastécnicas,entreellas:laseudonimizaciónyelcifrado dedatospersonales,lacapacidaddegarantizarlaconfidencialidad, integridad,disponibilidadyresilienciapermanentesdelossistemasy serviciosdetratamiento,lacapacidadderestablecerladisponibilidad yelaccesoalosdatospersonalesdeformaoportunaencasode incidentefísicootécnico,yunprocedimientoparaprobar,evaluar yevaluarperiódicamentelaeficaciadelasmedidastécnicasy organizativasparagarantizarlaseguridaddeltratamiento(Registro Oficial, 2023)(artículo23).

Elartículo24secentraenlasauditoríasdeseguridad.Indica quelosresponsablesyencargadosdeltratamientodeben“evaluar periódicamentelaeficaciadelasmedidastécnicasyorganizativas implantadasyconservarladocumentaciónpertinente,queestaráa disposicióndelaAutoridad”.Proponequeserealicealmenosuna auditoríadeseguridadalaño,peroestafrecuenciapodráaumentar enfuncióndelriesgodeltratamiento.

3.8 ImplicacionesparaSistemasAuditablesenEcuador

Enestecontexto,elmarcolegalecuatorianoenmateriade proteccióndedatospersonales,particularmentelaLeyOrgánicade ProteccióndeDatosPersonalesysuReglamento,defineunconjunto deobligacionesespecíficasrelacionadasconlaauditabilidadparalos responsablesdeltratamientodedatospersonales.Estasobligaciones buscanasegurarquelasactividadesdetratamientopuedanser verificadas,trazadasyjustificadasanteautoridadescompetentes, garantizandoasílatransparencia,larendicióndecuentasyel cumplimientoefectivodelosprincipioslegalesestablecidos:

✓ ObligaciónLegaldeMantenerRegistrosdeTratamiento:

Sibienelregistrodelasactividadesdetratamientoesuna acciónrecomendada,elart.35delaLOPDPloexigeporley. Elresponsabledeltratamientodebeestablecerunmecanismo pararegistrarlasactividadesdetratamientodedatospersonales. Sedeberegistrartodalainformaciónsobrelosdatospersonales tratados,lafinalidad,elresponsabledeltratamientoylafecha.

✓ ObligacióndeAuditarSeguridadRegularmente: Elartículo 34(d)delaLOPDPyelartículo24delReglamentoestablecen explícitamentequelasmedidasdeseguridadseauditaránperiódicamente.Enotraspalabras,esunrequisitolegalcontarcon medidasparaverificaryprobarperiódicamenteestoscontroles yregistrarlosresultados.Lossistemasdeinformacióndeben diseñarseteniendoestoencuenta,enlugardedificultarloo imposibilitarlo.

✓ ObligacióndeDetectaryDocumentarViolaciones: Los artículos37y38delaLOPDPestablecenunplazode72horas paranotificarunaviolación.Estonosepuedelograramenos queunaorganizacióncuenteconunsistemacapazdedetectar unabrechadeseguridadatiempo,mediantelamonitorización yrevisióncontinuasdelosdatosdelaspistasdeauditoría.Las organizacionesdeberíaninvertirensistemasdeGestióndeEventos eInformacióndeSeguridad(SIEM)osimilaresqueanalicenlos registrosentiemporealyalertencuandoseproduzcaunaactividad sospechosa.

✓ ObligacióndeRendicióndeCuentas: Elartículo8(f)dela LOPDPpriorizalarendicióndecuentasdeformaproactiva,yse esperaquelasorganizacionesdemuestrensucumplimientoante laAutoridad,siasíselessolicita.Estoincluiríaelmantenimiento depistasdeauditoríacompletas;registrosdelasconsideraciones dediseñoparalaproteccióndedatos;registrosdelosconsentimientos;evidenciadelcumplimientodelosdiversosderechosde losinteresados(acceso,rectificación,supresión);yregistrosdelas evaluacionesdeimpactosobrelaprivacidadrealizadas.

✓ SeparacióndeDatosdeAuditoría:SibienlaLOPDPnolo exigedirectamente,elprincipioderendicióndecuentassugiereque

laintegridaddelaspistasdeauditoríatambiénesesencial.Puede serunabuenapráctica(yesposiblequelaAutoridadadoptemás adelanteestainterpretación)mantenerlosregistrosdeauditoría enunsistemaindependientequeimpongaunaccesolimitadoy garanticesuintegridadyencriptación.

ParaunentendimientomássucintoenlaTabla 3 constala ComparacióndeGDPRVsLOPDP.

Tabla3:

ComparaciónGDPRvs.LOPDP

AspectoGDPR(UE)LOPDP(Ecuador)

Entradaenvigor25mayo201826mayo2021

BaselegalReglamento(UE)2016/679

Accountability

Art.5(2)-responsabilidad proactiva

LeyOrgánica(RO459,26-may2021)

Art.8(f)-responsabilidad proactiva(idéntico)

RegistroactividadesArt.30-obligatorioArt.35-obligatorio

Umbralexcepciónregistro

Auditoríasseguridad

<250empleados(conexcepciones)

Art.32(1)(d)-verificaciónregular

<20trabajadores(conexcepciones)

Art.34(d)-verificaciónregular (idéntico)

NotificaciónviolacionesArt.33-72horasArt.37-72horas(idéntico)

Comunicaciónatitulares

Sancionesmáximas

Autoridadsupervisión

Extraterritorialidad

ElaboraciónPropia

Art.34-cuandoaltoriesgo

Art.38-cuandoaltoriesgo (idéntico)

€20Mo4%facturaciónglobal $250,000o4%facturaciónlocal

Autoridadesnacionalesindependientes

Art.3-ofertade bienes/serviciosomonitoreo enUE

AutoridaddeProtecciónde Datos(adscritaDefensoríadel Pueblo)

Art.3-ofertade bienes/serviciosomonitoreo enEcuador

Capítulo4

ARQUITECTURADESOFTWARE

AUDITABLE

4.1 ModelodeCincoCapasparaSistemasAuditables

Laconstruccióndesistemasdesoftwareverdaderamenteauditables requieremásquesimplementeagregarloggingaunaaplicación existente.Requiereunaaproximaciónarquitectónicasistemática queconsiderelaauditoríacomounapreocupacióndeprimeraclase quepermeatodaslascapasdelsistema.Elmodelodecincocapas propuestoenlaliteraturacontemporáneadeingenieríadesoftware proporcionaunframeworkconceptualrobustoparaentenderydiseñar sistemasauditablescompletos.

Estemodeloestratificalasresponsabilidadesdeauditoríaencinco capasfuncionalesdistintasperointerconectadas,mismasquese muestranenlaTabla 4:

Tabla4:

CapasdelosSistemasAuditables

Nro.Capa

1CapadeCaptura:InterceptacióndeEventosRelevantes

2CapadeEnriquecimiento:AñadiendoContextoSemántico

3CapadeAlmacenamiento:PersistenciaInmutableyAppend-Only

4CapadeProtección:GarantíasCriptográficas

5CapadeAnálisis:ConsultayForense

ElaboraciónPropia

Cadacapatieneresponsabilidadesespecíficas,interfacesbiendefinidasconcapasadyacentes,yrequisitosno-funcionalesparticulares. Laseparaciónclaraderesponsabilidadesentrecapasfacilitanosolo eldiseñoylaimplementaciónsinotambiénelrazonamientosobre propiedadesdeseguridad,laevolucióndelsistema,ylaverificación decumplimientoregulatorio.

4.2 TaxonomíadeEventosAuditables

Unadelasdecisionesarquitectónicasmáscríticaseneldiseñode sistemasauditablesconsisteendeterminarquéeventosespecíficos requierenserregistradosenelRastrodeAuditoría.Sinunmarco

metodológicosistemáticoparatomarestadecisión,losequipos dedesarrollofrecuentementeadoptanaproximacionesad-hocque resultanencoberturadeauditoríainconsistenteydesbalanceada.Este enfoqueimprovisadotípicamenteproducedosproblemasopuestos: ciertosaspectosdelsistemageneranvolúmenesexcesivosdelogs conbajovalorinformativo(sobre-auditoría),mientrascomponentes críticosparaseguridadocumplimientocarecendeloggingadecuado (sub-auditoría).Laconsecuenciaesruidoinformacionalqueobscurece eventosverdaderamenteimportantesygapsdecoberturaqueimpiden investigacionesforensesefectivasodemostracióndecumplimiento regulatorio.

Laliteraturaacadémicaeningenieríadesoftwareylasguíasde cumplimientoregulatoriohanpropuestomúltiplestaxonomíaspara clasificareventosauditablesdemanerasistemática.ElNISTSpecial Publication800-92“GuidetoComputerSecurityLogManagement” (Kent&Souppaya, 2006)proporcionaunadelastaxonomíasmás completas,categorizandoeventossegúnsufuentegeneradora(sistema operativo,aplicación,dispositivosdeseguridad,dispositivosdered) ysunaturalezafuncional.ElframeworkCOBIT2019deISACA (ISACA, n.d.)clasificaeventosauditablessegúnprocesosdegobierno deTIquerequierenevidenciadeejecución.ISO/IEC27001:2013 (InternationalOrganizationforStandardization, 2013)ensuAnexo A.12.4especificacategoríasdeeventosquedebensersujetodelogged paracontrolesdeseguridaddeinformación.

4.3 ClasificaciónPrimaria:EventosTécnicosversusEventosdeNegocio

Unacategorizaciónfundamentalampliamenteadoptadadistingue entredostiposprincipalesdeeventossegúnsuniveldeabstraccióny audienciaobjetivo:eventostécnicosyeventosdenegocio.

4.3.1 EventosTécnicos

Capturanoperacionesdeinfraestructuraysistemaabajonivelde abstracción.Estacategoríaincluye:

✓ Operacionesdebasededatos: SetratadeoperacionesDML queserealizaronenlosobjetosdelabasededatos(IBM, n.d.) (porejemplo,lasoperacionesINSERT,UPDATE,DELETEo SELECTqueaccedieronaunatablacondatossensiblesocríticos). ParacualquieroperaciónDML,uneventotécnicodebasede datospuedeproporcionarlasiguienteinformación:eltextode lasentenciaSQL(ysusparámetrosparaevitarquelosdatos sensiblesseincluyanenlosregistros,siesnecesario),elnombre delastablasycolumnasalasqueseaccedió,elnúmerodefilas afectadas,elIDdelatransaccióndelaqueformabapartela operación(paraquesepuedanvertodaslasoperacionesdentro delamismaunidadatómicadetrabajo),elniveldeaislamiento delatransacciónyeltiempoquetardóenejecutarselasentencia. Estossistemasdeauditoríadebasesdedatossuelenfuncionar condisparadores,funcionesnativasdeauditoríadebasesdedatos comolaAuditoríaUnificadadeOracleylaAuditoríadeSQL Server,ounsistemadeCapturadeDatosdeCambioqueleeel archivoderegistrodetransaccionesdeformaasíncrona.

✓ InvocacionesdeAPIsyserviciosweb: Estoincluyellamadas alasAPIREST(larutaURLyelmétodoHTTP),llamadasa procedimientosremotosmedianteSOAPogRPC(elnombredel procedimiento),llamadasamicroservicios(incluidaslasllamadas decomunicaciónentreprocesos),etc.Estoseventosincluyen informacióncomo:laAPIoelservicioespecíficollamado;los parámetrospasados(comoencabezadosHTTP,parámetrosde consulta,elcuerpodelasolicitudserializadoounhashdelcuerpo siesdemasiadograndeparatransmitirseenelevento);elcódigo deestadodelarespuesta(comoelcódigodeestadoHTTPoel códigodeestadodegRPC);eltiempodeprocesamientodela llamadaenmilisegundos;cualquiererroroexcepcióngenerada porlallamada,etc.Enlasarquitecturasdemicroservicios,estos eventossuelenincluiridentificadoresdecorrelaciónoseguimiento (comolosidentificadoresdecorrelaciónyseguimientoespecificados enelestándardecontextodeseguimientodelW3C)paraque puedarastrearlasllamadasenmúltiplesservicios.

✓

Cambiosdeconfiguracióndesistema: Seincluyen:Cambios enlosarchivosdeconfiguración(XML,JSON,YML),cambios enlasvariablesdeentorno,cambiosenlaconfiguraciónde laaplicación(datosdeconfiguración)enunabasededatoso servicio,cambiosenlaconfiguracióndeseguridad.Losregistros decambiosdeconfiguraciónincluyen:valoresantiguosynuevos deloselementosdeconfiguración(diferenciadeconfiguración), quiénaprobóelcambio,quiénloaplicó,aquéhoraseaplicó,si sereinicióunservicio.

✓ Actividadderedycomunicaciones: Comolasconexiones deredactivas(conexionesTCPconIPypuertodeorigeny destino),lassolicitudesHTTP/HTTPS,incluyendolosdetalles delprotocolodeenlaceTLS(versióndelprotocolo,conjuntode cifradonegociado,sielcertificadofuevalidado),latransferencia degrandescantidadesdedatos(númerodebytesenviadosy recibidos)yeventosrelacionadosconelfirewall(siunaconexiónfue permitidaodenegadasegúnunaregladeterminada).Alejecutar contenedoresenunclústerconunamalladeservicios,estetipode eventossuelesergeneradoporelproxysidecar,queactúacomo proxydeinterceptaciónparatodoeltráficoqueentraysale.

✓ Operacionesdeautenticaciónyautorización: Como:los intentosdeiniciodesesiónexitososofallidos,incluyendola direcciónIPdesdelaqueseintentólaconexiónyelagente deusuario(conlageolocalizaciónquesepuedeinferirdela direcciónIP),laelevacióndeprivilegios(comoejecutarsudoen LinuxosolicitarlaelevacióndelUACenWindows),loscambios enlapertenenciaagruposoroles,laemisiónyvalidaciónde tokensdeautenticación(comoJWT,asercionesSAMLotokens deaccesoOAuth)yelresultadodelaevaluacióndelaspolíticas deautorización(sielaccesosepermitióodenegósegúnRBAC, ABACuotrosmotorescomoOpenPolicyAgent).Lamayoría delassolucionesmodernasdegestióndeidentidadesyaccesos (I&A),comoAzureAD,OktaoAuth0,puedengenerarestetipo deeventosautomáticamenteyproporcionarAPIointerfacesde streamingparaexportarlosaunSIEM.

✓ Eventosdesistemaoperativo: Talescomo:lacreacióny finalizacióndeprocesos,incluyendolalíneadecomandoscompleta ylasvariablesdeentornodelproceso,cambiosenlospermisoso lapropiedaddearchivos,lainstalaciónoeliminacióndesoftware opaquetes,modificacionesdelkerneloeventosdesencadenados portareasprogramadasotrabajostipo“cron”.Existennumerosas herramientasespecializadasparalaauditoríaaniveldesistema operativo,comoLinuxauditd,elregistrodeeventosdeWindows oagentesEDR(DetecciónyRespuestadeEndpoints)como CrowdStrikeoSentinelOne,quepuedengenerarestetipode eventosconunaltoniveldedetalle.

Estetipodeeventosdeseguridadsontécnicosysolotienen sentidoparaingenierosdeinfraestructuraysistemas,arquitectos deseguridadynube,oanalistasdeunCentrodeOperacionesde Seguridad(SOC).Sinembargo,noexisteunacorrelacióndirectaentre estoseventosdebajonivelyactividadesquepuedancomprenderse anivelempresarial,comoaccionesquelosusuariosoanalistasde negociopuedancomprender.

4.3.2 EventosdeNegocio

Capturanoperacionessignificativasdesdelaperspectivadeldominiodenegociodelaaplicación,modelandoaccionesquetienen consecuenciasenprocesosdenegocio,estadodeentidadesdedominio, ocumplimientodereglasdenegocio.Estacategoríaincluye:Transaccionesfinancieras,operacionesdegestióndeórdenes,workflows deprocesosdenegocio,accesoainformaciónsensibleoconfidencial, operacionesdegestióndeusuariosycontroldeacceso,eventosde auditoríaregulatoria.

4.4 PrincipiosFundamentalesdeDiseño

Laconstruccióndesoftwareauditablerequiereadherenciaa principiosarquitectónicosespecíficosque,aunquecomplementan principiosgeneralesdediseñodesoftware,tienenénfasisymatices particularesenelcontextodeauditoría.Estosprincipiosdebenser consideradosdesdelasprimerasetapasdediseñoarquitectónicoy

mantenersevigilantementedurantetodoelciclodevidadelsistema.

4.5 SegregacióndeResponsabilidadesdeAuditoría

Enauditoría,lasegregaciónderesponsabilidadespartedeunaidea simple:ningunapersonanicomponentedelsistemadeberíapoder hacerlotodo.Noessolounabuenaprácticadediseñodesoftware, sinounaexigenciaparaquelosregistrosdeauditoríaseanrealmente confiables.Poreso,lastareasdegenerareventosauditables,almacenar losregistros,analizarlosyadministrarelsistemadeauditoríadeben estarrepartidasentrecomponentesdistintos,conresponsabilidades clarasyaccesosbiencontrolados.Deestaformaseevitaqueun mismoactorpuedaalterarevidencias,ocultaractividadoauditarse asímismo.

Ensistemasmonolíticostradicionales,escomúnqueelmismo códigodeaplicaciónqueimplementalógicadenegociotambiénsea responsabledegenerarlogs,determinarquéloggear,ypotencialmente inclusogestionardóndesealmacenanloslogs.Estaamalgamación deresponsabilidadescreariesgosdeseguridad:códigocomprometido puedemanipulartantolalógicadenegociocomolosregistrosde auditoríaquesesuponedebenrastrearesalógica.

Enarquitecturaverdaderamentesegregada,elcódigodeaplicación emiteeventosdeauditoríaatravésdeunainterfazbiendefinida(por ejemplo,un“messagebus”,unaAPIdeloggingcentralizada,oun “eventstream”)peronotieneconocimientonicontrolsobrecómoesos eventossonposteriormenteprocesados,almacenadosoanalizados.Un subsistemadeauditoríaseparado,potencialmenteejecutándoseen infraestructuracompletamenteseparada,administradoporequipos diferentes,conbasesdedatosseparadas,esresponsablederecibir estoseventos,validarlos,enriquecerlos,almacenarlosinmutablemente, yproporcionarcapacidadesdeanálisis.

Estasegregacióndebeextendersealainfraestructura.Basesde datosquealmacenanregistrosdeauditoríadebenestarenservidores separadosdebasesdedatostransaccionales.Storagedearchivospara logsdebeestarensistemasdearchivosseparadosconcontrolesde

accesoindependientes.Idealmente,lainfraestructuradeauditoría debeestarenunazonaderedseparadaconreglasdefirewallestrictas quepermitenflujounidireccionaldeeventosdeauditoríadesdeel sistemaprincipalhaciaelsistemadeauditoría,peronoviceversa.

4.6 InmutabilidaddeRegistrosdeAuditoría

Lainmutabilidadesunparadigmadediseñoensoftwareque establecequelosdatosescritosnuncasemodifican.Porlotanto, sehaconvertidoenunaopcióndediseñopopularparafacilitar elrazonamiento,lograrconcurrenciasinbloqueosyproporcionar reproducibilidad.Enelcasodelaauditoría,lainmutabilidadnoes unaopcióndediseño,sinounrequisitoquedebecumplirseparaque losregistrosdeauditoríaseanconfiables.

Elsiguientepasoesutilizarunalmacenamientodedatosmás duraderoeintrínsecamenteinmutable.Porejemplo,losdispositivos dealmacenamientoWORM(Write-OnceRead-Many),queseutilizan habitualmenteconfinesdecumplimientonormativo(comoenlos sectoresfinancieroysanitario),almacenandatosensoportesqueno sepuedenmodificarunavezescritos.Algunossistemasdealmacenamientoempresarialpuedenactivarseen“mododecumplimiento normativo”paragarantizarlainmutabilidad,inclusocontralos administradoresdealmacenamiento.Elalmacenamientoenlanube deAmazonS3ofrece“Bloqueodeobjetos”,quepermitequelos objetosseaninmutablesduranteuntiempodeterminado.

4.7 ParadigmaAppend-OnlyparaRegistrosdeAuditoría

Lainmutabilidadesequivalentealprincipiodesoloanexar.Sila inmutabilidadindicaquenosepuedecambiarnada,elmodelode soloanexiónindicaqueloúnicoquesepuedehaceresanexarnuevos datosalfinaldelalista,loqueprohíbelasinsercionesencualquier otropunto,aunquenoalterenelcontenidoanterior.

Elmodelodesoloanexiónpresentaalgunascaracterísticasinteresantespararazonarsobrelaprocedenciatemporaldeunregistrode auditoría.Suponiendounregistropuramentedesoloanexión,elorden

físicodelosregistrosdeberíacorresponderalordenlógicodeescritura deregistros.Estofacilitalaverificacióndequelasmarcasdetiempo dentrodelregistroseanmonótonas(oalmenosnodecrecientes,para tenerencuentaeventossimultáneos).

4.8 PrincipiodeMínimoPrivilegioparaAccesoaAuditoría

Elprincipiodemínimoprivilegio,queusuariosyprocesosdeben tenersololospermisosmínimosnecesariospararealizarsusfunciones legítimas,esfundamentalenseguridaddesistemas.Enelcontexto deauditoría,esteprincipiotieneaplicacionesespecíficas:minimizar quiénpuedegenerarregistrosdeauditoría,quiénpuedeleerlos,quién puedeconfigurarelsistemadeauditoría,yquiénpuedeadministrar retenciónyarchivado.

4.9 Capturayenriquecimientodeeventos

Ladeterminacióndequéeventosdebenserauditadosesquizás ladecisiónarquitectónicamáscríticaeneldiseñodeunsistema auditable.Auditarmuypocoresultaenregistrosdecoberturaque puedenserexplotadosoqueimpideninvestigacionesforensesefectivas. Auditardemasiadogeneravolúmenesmasivosdedatosconbajovalor informativo,obscureceeventosverdaderamenteimportantes,consume recursosdealmacenamientoyprocesamientoinnecesariamente,y puedeinclusocrearproblemasdecumplimientoconregulacionesde privacidadquerequierenminimizacióndedatos.

Losmarcosdecumplimientoproporcionanguíassobrecategorías deeventosquetípicamenterequierenauditoría.ElNISTSpecial Publication800-53ensufamiliadecontrolesAU(Auditand Accountability)(NationalInstituteofStandardsandTechnology, 2024)especificamúltiplescategoríasdeeventosauditables.ElGDPR ensuArtículo30requieremantenerregistrosdeactividadesde procesamiento,efectivamenterequiriendoauditoríadetodaslas operacionesqueinvolucrandatospersonales.

Sinembargo,estasguíassoninherentementegenéricas.Suaplicaciónaunsistemaespecíficorequiereanálisiscuidadosodeldominiode

negocio,amenazasdeseguridadanticipadas,requisitosregulatorios específicosdelsector,yobjetivosdeauditoríadelaorganización.

Esteanálisisdebesersistemático,documentado,ymantenidoalo largodelciclodevidadelsistema.

4.10 AlmacenamientoSegurodeRegistrosdeAuditoría

Elalmacenamientoderegistrosdeauditoríarequiereconsideracionesespecialesquevanmásalládelasbasesdedatostransaccionales convencionales.(Schneier&Kelsey, 1999)propusieronelconceptode “untrustedcomputerbaseauditlogging”,dondeinclusosielsistema auditadoescomprometido,losregistrosdeauditoríapermanecen íntegrosyverificables.

4.10.1 CapturadeContextoEnriquecido

Loseventosdeauditoríaensuformamásbásicacapturanqué ocurrió(unaoperaciónespecíficaseejecutó)ycuándo(timestamp). Sinembargo,paraquelosregistrosdeauditoríaseanverdaderamente útilesparaanálisisforense,investigacióndeincidentes,odemostración decumplimiento,debencapturarcontextomuchomásricosobrelas circunstanciasenlascualesocurrióelevento,nosololaoperación realizada,sinoelcontextocompletoenelqueocurrió.Estoincluye informaciónsobreelusuario,sesión,dispositivo,ubicacióngeográfica ycontextodenegocio(McCarroll&Rowley, 1979).

4.10.2

ContextodeIdentidadyAutenticación

Elcomponentemásfundamentaldelcontextodeauditoríaes identidad:quién(oqué)iniciólaacciónsiendoauditada.Enelnivel másbásico,estoeselidentificadordeusuariodelactorautenticado. Sinembargo,ensistemassofisticados,identidadtienemúltiplesfacetas quetodaspuedenserrelevantesparaauditoría.

Primero,hayladistinciónentreidentidadrealeidentidadefectiva. Laidentidadrealeslapersonaosistemaqueiniciólasesiónoriginal. Laidentidadefectivaeslaidentidadbajolacualseejecutóuna operaciónespecífica,quepuedediferirsiocurriósuplantación(impersonation)odelegación.Porejemplo,unadministradordesistema

podríaautenticarseconsuspropiascredenciales,peroluegoejecutar comandos“como”otrousuarioparatroubleshooting.Losregistrosde auditoríadebencapturartantolaidentidadrealdeladministrador comolaidentidadefectivadelusuariosiendoimpersonado.

Segundo,ensistemasqueimplementancontroldeaccesobasado enroles(RBAC)ocontroldeaccesobasadoenatributos(ABAC),el roloconjuntodepermisosbajoelcualoperabaelusuariocuando realizólaacciónesinformacióndeauditoríacrítica.Unusuariopuede tenermúltiplesroles;registrosdeauditoríadebenregistrarquérol estabaactivoparaunaoperaciónparticular.Estoesparticularmente importanteparadetectarescalacióndeprivilegios,situacionesdonde unusuarioabusedeunrolprivilegiadopararealizaraccionesno relacionadasconlasresponsabilidadesdeeserol.

4.11

4.11.1 ConceptoyPrincipiosFundamentales

Lasbasesdedatosappend-only(solo-añadir)representanun paradigmadealmacenamientodedatosqueimponeunarestricción arquitectónicafundamental:unavezquelosdatoshansidoescritosal almacenamiento,nopuedensermodificadosnieliminados.Lasúnicas operacionespermitidasson“append”(añadirnuevosregistrosalfinal delasecuenciadedatos)y“read”(leerregistrosexistentes).Esta restricción,aunqueaparentementelimitante,proporcionapropiedades valiosasparasistemasquerequiereninmutabilidad,auditabilidad,y rastreohistóricocompletodecambios.

Elconceptodeappend-onlynoesnuevoencienciasdela computación.Los“transactionlogs”debasesdedatosrelacionales tradicionales(write-aheadlogsenPostgreSQL,redologsenOracle, transactionlogsenSQLServer)hanoperadosiempreenmodo append-onlyporrazonesderendimientoyrecuperación(performance &recovery),escribirsecuencialmentealfinaldeunarchivoes significativamentemásrápidoqueactualizarregistrosenubicaciones específicasdeldisco,ymantenersecuenciainmutabledeoperaciones permiterecuperarseantefallosdelsistemamedianteel“replay”del

log.Loquediferencialasbasesdedatosappend-onlymodernases queelevanesteconceptodemecanismointernodeimplementacióna modelodedatosvisibleyexplotableporaplicaciones.

4.11.2 InmutabilidadyTemporalSemantics

Lainmutabilidadesunapropiedadmatemáticadondeunvalor, unavezcreado,nuncacambia.Encontextodeestructurasde datosinmutables,lasoperacionesqueconceptualmente“modifican” unaestructuraenrealidad“crean”unanuevaversión,dejandola versiónanteriorintacta.LoslenguajesdeProgramaciónFuncional comoHaskellyClojureconstruyensusmodelosdeprogramación enteramentesobreinmutabilidad,proporcionandobeneficiostales como:razonamientosimplificadosobrecomportamientodeprograma, sinefectoscolaterales,concurrenciasinnecesidaddebloqueos,nohay competenciadeacceso(raceconditions)silosdatosnuncacambiany, capacidaddemantenermúltiplesversionesdedatossimultáneamente paradiferentescontextosdeejecución.

LasbasesdedatosAppend-onlyaplicanestosprincipiosde inmutabilidadalniveldepersistenciadedatos.Enlugardelmodelo CRUDtradicional(Create,Read,Update,Delete),implementan elmodeloCRQ(Create,Read,Queryhistoricalstates).Cuando unaaplicaciónnecesita“actualizar”unregistro,labasededatos nomodificaelregistroexistente,sinoqueañadeunnuevoregistro querepresentaelnuevoestado,frecuentementeconmetadataque lovinculaalestadoanterior.Elestadoactualdeunaentidades simplementelaversiónmásrecienteenlasecuenciadeversiones.

Estaaproximaciónnaturalmentesoporta“temporalsemantics”, queeslacapacidaddeconsultarnosoloelestadoactualdedatos sinotambiénestadoshistóricosenpuntostemporalesespecíficos.Así, sedistinguedostiposprincipalesdedimensionestemporalesenestas basesdedatos:

✓ Transactiontime(tiempodetransacción): Registracuándo undatofuealmacenadoenlabasededatos.Escontrolado completamenteporelsistemadebasededatosyesinmutable, unavezqueunregistroescomprometido(committed)conun

sellodetiempodetransacción(transactiontimestamp),esesello nuncacambia.Estopermiteresponderpreguntascomo:“¿Qué informaciónteníalabasededatosensuestadodel15deenero de2026alas14:30?”

✓ Validtime(tiempoválidootiempodevigencia): Registra elperíododuranteelcualunhechoesverdaderoenelmundo realqueseestámodelando.Escontroladoporlaaplicación(la aplicaciónespecificadesdeyhastacuándoundatoesválido) ypuedediferirdeltransactiontime.El“Validtime”permite responderpreguntascomo:“¿Quéempleadostrabajabanenel departamentodeMarketingduranteelsegundotrimestrede2025?” independientementedecuándoesainformaciónfueregistradaen labasededatos.

Lasbasesdedatosbitemporalessoportanambasdimensiones simultáneamente,permitiendoconsultas(queries)complejasque combinancriteriosdetransactiontimeyvalidtime.Lasbasesdedatos Append-onlynaturalmentesoportantransactiontimeporquecada registrotienetimestampinmutabledecuándofueescrito.Soportar validtimerequierequelaaplicaciónincluyacamposdefechade inicio/findevalidezenregistros.

4.11.3 Log-StructuredStorageEngines

Losmódulosdealmacenamiento(storageengines)basadosen estructurasdelog(Log-StructuredMerge-TreesoLSM-trees)implementannaturalmentesemánticaappend-only.LosLSM-treesfueron propuestosoriginalmentepor(O’Neiletal., 1996)ensuartículo “TheLog-StructuredMerge-Tree(LSM-Tree)”yhansidoadoptados ampliamenteenbasesdedatosmodernasdiseñadasparaaltotráfico deescritura.

LaarquitecturadeLSM-treeoperaenmúltiplesniveles.Primero, lasescriturasentrantesseacumulanenmemoriaenunaestructura ordenadallamada“memtable”.Luego,cuandolamemtablealcanza untamañolímite,esenviadaaldiscocomoarchivoinmutablellamado “SSTable”(SortedStringTable).Estaoperacióndeescrituraendisco seconocecomo“flush”yesunaoperaciónappend-only,elarchivo

SSTableseescribesecuencialmenteynuncasemodificadespués.Las lecturasdebenconsultarlamemtableenmemoriamástodoslos SSTablesendisco,fusionandoresultadosparaencontrarlaversión másrecientedecadakey.

Periódicamente,elsistemaejecutaunprocesodecompactación dondemúltiplesSSTablessefusionanenSSTablesnuevosdenivel superior,eliminandoversionesobsoletasdekeysyreclamandoespacio. Aunquelacompactacióneliminaversionesantiguas,estoocurremediantecreacióndenuevosarchivosinmutables,losSSTablesoriginales permaneceninmutableshastaquesonreemplazadosatómicamente porSSTablescompactados.

Acontinuación,ejemplosdebasesdedatosqueutilizanLSM-trees:

✓ ApacheCassandra: BasededatosdistribuidaNoSQLdiseñada paraescalabilidadhorizontalmasiva.CassandrautilizaLSM-trees (implementadosensuCommitLogySSTables)ynaturalmente mantienemúltiplesversionesdedatosmediantetimestamps.Cada mutaciónenCassandraincluyetimestamphastaconmicrosegundos,ycuandoexistenmúltiplesversionesdeunamismacolumna, Cassandraretornalaversióncontimestampmásreciente.Para auditoría,Cassandrapuedeconfigurarsecon“TimeToLive” (TTL)muylargooinfinito,manteniendoversioneshistóricas indefinidamente.Lasconsultaspuedenespecificaruntimestamp pararecuperarestadohistóricodedatosenesepuntotemporal.

✓ ApacheHBase: BasededatosNoSQLorientadaacolumnas construidasobreHadoopDistributedFileSystem(HDFS).HBase mantienemúltiplesversionesdecadacelda(intersecciónderow key,columnfamily,columnqualifier)contimestamps.Elnúmero deversionesretenidasesconfigurableporcolumn-family.HBase permiteconsultascontimestampespecíficopararecuperarestado histórico.

✓ RocksDB: Bibliotecade“key-valuestore”desarrolladapor Facebook(ahoraMeta)comounforkoptimizadodeLevelDB deGoogle.RocksDBimplementaLSM-treeconoptimizaciones agresivasderendimiento.Aunqueensímismonoexponedirec-

tamentemúltiplesversionesaaplicaciones(pordefectoretorna soloversiónmásrecientedecadakey),esusadocomomotorde almacenamientopormúltiplessistemasdemásaltonivelquesí soportanversionamiento,incluyendoCockroachDByTiDB.

4.11.4 EventStoresEspecializados

Los“EventStores”sonbasesdedatosdiseñadasespecíficamente paraEventSourcingpattern,dondelaprimitividadfundamentales eleventoinmutable.Estossistemassoninherentementeappend-only porqueloseventos,unavezescritos,nuncadebenmodificarse.

EventStoreDBesunejemplodebasededatosdecódigoabierto diseñadaespecíficamenteparaEventSourcingPattern,fuedesarrolladaporEventStoreLtd.yorganizaeventosen“streams”,donde cadastreamesunasecuenciaordenadadeeventosrelacionados.Las operacionessoportadasson:

✓ Append: Consisteenañadirunoomáseventosalfinaldeun stream.Paramanejarconcurrencia,estaoperaciónpuedeincluir unaversiónesperadadelstream.Elappendsolosecompletacon éxitosilaversiónactualcoincideconesaversiónesperada,loque permiteimplementarcontroldeconcurrenciaoptimistayevita queescriturasconcurrentessetraslapenentresí.

✓ Read: Leereventosdeunstream,opcionalmentedesdeuna posiciónespecífica(alaquesepodríallamar“versión”)ycon direcciónhaciaadelante(forward)ohaciaatrás(backward).Por ejemplo,ReadStreamAsync(“order-123”,StreamPosition.Start, 100)indicaquedebeleerlosprimeros100eventosdelstream “order-123”.

✓ Subscribe: Suscribirseaunstreampararecibirnotificaciones cuandonuevoseventossonañadidos,permitiendounprocesamientoreactivo.EventStoreDBsoporta“catch-upsubscriptions”que primeroreproduceneventoshistóricosyluegocontinúanrecibiendo nuevoseventosentiemporeal.

EventStoreDBgarantizaqueloseventosseancompletamente

inmutables,noexisteAPIparamodificaroeliminareventos.El únicomecanismode“eliminación”eseltruncamientodestream,que eliminaeventosanterioresaunaposiciónespecífica,peroestorequiere permisosespecialesygeneraeventodemetadataquedocumentadicho truncamiento(proporcionandoRastrodeAuditoríadelaeliminación misma).

ApacheKafka (ApacheSoftwareFoundation, n.d.)aunque típicamentecategorizadocomoplataformadestreamingdistribuido, Kafkapuedeservirefectivamentecomobasededatosappend-only paracasosdeusodeauditoría.Kafkaorganizamensajesen“topics” particionados.Cadaparticiónesunasecuenciaordenadaappend-only deregistrosconoffsetsmonótonamentecrecientes.Losmensajesse escribenalfinaldelasparticionesysoninmutablesdespuésdesu escritura.

Kafkasoportacompactacióndelog,mecanismodonderetienesolo elvalormásrecienteparacadakeydentrodeuntopic,eliminando versionesantiguas.Sinembargo,paraauditoría,lacompactación típicamentesedeshabilita,manteniendotodoslosmensajesindefinidamente.Kafkapuederetenerterabytesopetabytesdedatos históricos,limitadosoloporcapacidaddealmacenamientodelcluster.

KafkaproporcionaAPIsquepermitenleermensajesdesdeoffset arbitrario,facilitandoreplayhistórico.Porejemplo,unaaplicación puederesetearsuposiciónaoffset0parareproducirtodoslos mensajesdesdeeliniciodeltopic,útilparareconstruirestadoo realizaranálisishistórico.

4.11.5 ImplementaciónenBasesdeDatosRelacionales

AunqueSQLtradicionalpermiteUPDATEyDELETEsinrestricción,esposibleimplementarsemánticaappend-onlysobrebases dedatosrelacionalesmediantepatronesdediseñoycontrolesde seguridadapropiados(IBM, n.d.).

TemporalTablesenSQLServer.SQLServer2016introdujo soportenativoparatablastemporalessystem-versionedconformeal estándarSQL:2011(Microsoft, 2025b).Unatablatemporalconsiste dedostablasfísicas:

✓ Currenttable(tablaactual): quecontienefilasactualescon doscolumnasadicionalesdetipodatetime2quedefinenelperíodo devalidez:“SysStartTime”(timestampcuandolafilasevolvió válida)y“SysEndTime”(timestampcuandolafiladejódeser válida,ovalormáximodedatetime2parafilaactual).

✓ Historytable(tabladehistorial): conesquemaidénticoque contieneversionesanterioresdefilasquehansidoactualizadaso eliminadas.Cuandounafilaencurrenttableseactualiza,SQL Serverautomáticamente:

a) Establece“SysEndTime”defilaactualaltimestampdetransacción

b) Copiafilaactualizadaahistorytable

c) Insertanuevaversiónencurrenttablecon“SysStartTime”establecidoatimestampdetransaccióny“SysEndTime”avalor máximo

Latablahistóricaesappend-onlypordiseñodeSQLServer,el sistemaprevieneUPDATEoDELETEdirectoenlatabla.SoloSQL Serverpuedeescribirmediantemecanismodesystem-versioning.Esto proporcionagarantíaenlainmutabilidaddedatoshistóricos.

4.11.6 Trade-offsyconsideracionesderendimiento

UnadelasventajasdelaarquitecturaAppend-Onlyesquetiene escrituraendiscooptimizado,puestípicamentesonmásrápidasque “updatesinplace”porque:

✓ Nohaynecesidaddebuscarunregistroexistente,leersucontenido actual,modificarlo,yescribirlodevuelta(read-modify-write cycle).

✓ Norequierecoordinarbloqueosentre“readers”y“writers”dado quelosreadersleenversionesinmutablesmientrasqueloswriters añadennuevasversionessininterferencia.

Tambiénsesimplificalaconcurrencia,dadoquelainmutabilidad eliminamuchosdesusproblemas:

✓ Nohaynecesidadparaunbloqueodetipo“pessimisticlocking” o“readers-writerlocks”porquelosreadersnuncabloqueanlos writersyviceversa.

✓ Elcontroldeconcurrenciaoptimistaesnatural,porquecuando seañadeunanuevaversión,severificaquelaversiónesperadaes todavíalaactual;sino,latransacciónsereintenta.

✓ Nohay“lostupdates”,“dirtyreads”,o“non-repeatablereads” porquelasversionessoninmutables.

Unenfoqueappendonlyofrecedeformanaturalunrastrode auditoríacompleto,yaqueelhistorialdecambiosquedapreservado sinnecesidaddeconstruirmecanismosadicionalesdeauditoría. Cadamodificacióngeneraunanuevaversióndelregistroyconserva informacióntemporalsobrecuándofueválida,loquepermite reconstruirconprecisiónlaevolucióndelosdatosalolargodel tiempo.

Estemismoprincipiosimplificanotablementelarecuperaciónante fallos(crashrecovery),alnoexistiractualizacionesnisobreescritura dedatos,larecuperaciónsereduceaunprocedimientodirecto:noes necesariorevertirtransaccionesparcialmenteaplicadassobrepáginas dedatos,sinoúnicamentetruncarellogappendonlyhastaelúltimo puntodeconfirmaciónconocidoycontinuardesdeahí.

4.12 DesafíosyLimitaciones

Crecimientodealmacenamiento: Eldesafíomásobvioesque losdatoshistóricosconsumenespaciodealmacenamientoindefinidamente,porejemplo,unafilaqueseactualiza1000vecesgenera1000 versiones.Paracontrarrestarestoexistenmitigacionesqueincluyen:

✓ Compactación: Eliminarversionesantiguasqueyanoson necesariassegúnpolíticaderetención.Sinembargo,estoviola laestrictainmutabilidadyrequieremecanismoscuidadosospara documentarquéfuecompactadoyporqué.

✓ Archivoenalmacenamientosecundario: Moverversiones

antiguasaunalmacenamientodebajocostocontiemposdeacceso máslentos,perocostoporgigabytesignificativamentemenor.

✓ Compresión: Lasversionessucesivasdeunamismaentidad frecuentementetienenaltasimilitud.Enesteescenariosepuede almacenarsolodiferenciasentreversiones,aloqueseconocecomo “DeltaEncoding”,outilizaralgoritmosdecompresióncomozstd ylz4,quepuedenreducirsignificativamenteelespacio.

Complejidaddelrendimientodelectura: Leerunestado actualpuederequerirfiltrarmúltiplesversionesparaencontrarlamás reciente.EnLSM-Trees,estosignificaconsultarmúltiplesmemtables, potencialmentegenerandolatencia.Paraestosetienelassiguientes mitigaciones:

✓ Bloomfilters: Sonestructurasdedatosprobabilísticasque permitendeterminarconcertezaqueunaclavenoexisteenuna SSTablesinnecesidaddeleerla.Estoreducesignificativamentelas operacionesdeentradaysalidaendiscoymejoraelrendimiento delasbúsquedas.

✓ Índicesoptimizados: Setratadeíndicesfiltradosenbases dedatosSQLquesoloincluyenlasfilasvigentes,porejemplo aquellasdondeelcampoValidToesnulo.Estopermitelocalizar rápidamenteelestadoactualdeunregistrosinrecorrerversiones históricas.

✓ Cachingagresivo: Lasversionesactualesdelosdatossuelen considerarseinformacióndeusofrecuente.Porellosemantienen enmemoriaoencapasdecachédealtavelocidad,comoRedis oMemcached,paraacelerarelaccesoyreducirlacargasobreel almacenamientopersistente.

Querycomplexityparaanálisishistórico: Puedenexistir queriesquenecesitenanalizarpatronesatravésdetiempo,tales como:trendinganalysis,time-seriesaggregations,peropuedenser complejosdeexpresaryoptimizar.Enestepunto,esdegranayuda el“SQLtemporalsyntax”juntoaunOptimizadordeQueriesque entiendalasemánticatemporalparagenerarplanesdeejecución

eficientes.

Incompatibilidadcon“derechoalolvido”: ElGDPRen suartículo17estableceelderechodelosindividuosasolicitarla eliminacióndesusdatospersonalesbajociertascircunstancias.Siendo así,laarquitecturaStrictappend-onlyesfilosóficamenteincompatible conesterequisito.Lassolucionespuedenser:

✓ Encryptionatrestconeliminacióndeclaves: Consisteen cifrarlosdatospersonalesutilizandoclavescriptográficasque puedendestruirsecuandounusuarioejercesuderechoalolvido. Aleliminarlaclave,lainformaciónquedairrecuperabledesdeel puntodevistapráctico,aunquelosdatoscifradossiganexistiendo físicamenteenelalmacenamiento.

✓ Pseudonimización: Implicasustituiridentificadoresdirectospor seudónimos,demodoquelosdatosnopuedanatribuirseauna personasininformaciónadicional.Aleliminarlarelaciónentre elseudónimoylaidentidadreal,esposibleconservarlosdatos pseudonimizadosparaanálisisofinesestadísticossinmantenerla identificacióndelindividuo.

✓ Aceptarqueciertosregistrosdeauditoríacríticosno soportanborradototal: Ensectorescomofinanzasysalud,la normativaexigelaconservaciónderegistrosdeauditoríadurante períodosprolongados,normalmenteentresieteydiezaños.En estoscasospuedesurgirunconflictodirectoentrelaobligación legalderetenciónyelderechoalolvido.Esteconflictosuele resolversemedianteunanálisisjurídicoyderiesgoenelque lasobligacionesderetenciónprevalecen,siemprequeexistauna justificaciónlegalclarayproporcional.

4.13 CasosdeUsoÓptimos

Lasbasesdedatosappendonlysonespecialmenteadecuadas enescenariosdondelainmutabilidadyelhistorialcompletodela informaciónnosonunaopción,sinounrequisito.Lossiguientesson algunoscasosdeuso:

✓ SistemasdeEventSourcing: Elmodelodedatossebasa enunasecuenciadeeventosinmutablesquerepresentancada cambiodeestadodelsistema.Enestecontexto,tecnologíascomo EventStoreDB,DatomicyKafkaencajandeformanatural,yaque estándiseñadasparaalmacenareventosdemaneraacumulativay ordenada.

✓ Registrosdeauditoríaycumplimientonormativo: Cuando lasregulacionesexigenconservarunhistorialinalterabledela actividaddelsistema,comoocurreensistemasfinancieros,de saludodegestiónderegistrosgubernamentales,elenfoqueappend onlygarantizatrazabilidadyevidenciaconfiable.

✓ Datosdeseriestemporales: Métricas,logsydatosdesensores segenerancomonuevasobservacionesqueseagregancontinuamente,mientrasquelosdatoshistóricosnuncasemodifican.Por estarazón,basesdedatoscomoInfluxDB,TimescaleDByAWS Timestreamsuelenimplementaralmacenamientoappendonly comoprincipiobásico.

✓ Blockchainydistributedledgers: Dondelainmutabilidadyel ordenamientocronológicosonpropiedadesfundamentales.Aunque blockchainañadeunmecanismoadicionaldeconsensodistribuido yhashingcriptográfico,enesenciafuncionancomobasesdedatos appendonly.

✓ Almacenamientodedocumentosversionados: Sistemasde gestióndecontenido,wikisyplataformasdeedicióncolaborativa requierenmantenerelhistorialcompletoderevisionescomoparte desufuncionalidad.Enestesentido,Gitpuedeentendersecomo unabasededatosappendonlyorientadaalcontroldeversiones decódigofuente.

4.14 ImplementacióndeTrazasdeAuditoría

Notodaslasoperacionesenunsistemarequierenauditoría exhaustiva.Ladeterminacióndequéeventosdebenregistrarsedebe basarseenunanálisisderiesgosyrequisitosdecumplimiento.La metodologíapropuestaporNIST(NationalInstituteofStandardsand

Technology, 2024)ensuSpecialPublication800-92sugiereclasificar eventosencategorías:

✓ Eventoscríticosdeseguridad: Autenticación,autorización, cambiosdepermisos,accesoadatossensibles.

✓ Eventosdemodificacióndedatos: Creación,actualizacióny eliminaciónderegistroscríticos.

✓ Eventosadministrativos: Cambiosdeconfiguración,gestión deusuarios,operacionesprivilegiadas.

✓ Eventosdecumplimientoregulatorio: Operacionesespecíficamenterequeridasporregulacionesaplicables.

4.15 ProtecciónCriptográficadeRegistrosdeAuditoría

Consisteenaplicarmecanismoscriptográficosparaqueloseventos registradosporunsistemaseanconfiablesyapruebademanipulaciones.Laideaesque,unavezqueuneventoquedaregistrado,no puedamodificarse,eliminarseoinsertarseinformaciónfalsasinque elloseaevidente.Paralograrloseempleantécnicascomofunciones hash,encadenamientoderegistros,firmasdigitalesysellosdetiempo (timestamps),quevinculancadaregistroconelanterioryconel momentoenquefuegenerado.Deestaforma,loslogsconservan suintegridad,susecuenciatemporalysuvalorcomoevidencia, inclusocuandosealmacenanoprocesanenentornosquenoson completamenteconfiables.

4.15.1 HashChainsparaDeteccióndeManipulación

Laproteccióncriptográficaderegistrosdeauditoríabuscagarantizarquecualquieralteración,eliminaciónoinserciónfraudulenta deregistrosseadetectableinclusosiunatacantetieneacceso completoalalmacenamientofísicodonderesidenlosregistros.La técnicafundamentalparalograrestapropiedadesel“hashlinking” o“chaining”,dondecadaregistrodeauditoríaincluyeunhash criptográficodelregistroanterior,creandounacadenavinculada criptográficamentedondealterarcualquierregistrorompelacadena demaneradetectable.

Elconceptode“hashchains”fueformalizadoporHabery Stornettaen1991ensutrabajosobreTimestampingdeDocumentos Digitales(Haber&Stornetta, 1991),yposteriormentefueaplicado específicamentealoggingseguroporSchneieryKelseyensupaperde 1998(Schneier&Kelsey, 1998).Laideaeselegantementesimplepero criptográficamenterobusta:paracadanuevoregistrodeauditoría generado,secalculaunhashcriptográficoqueincluyetodoel contenidodelregistroactualmáselhashdelregistroanterior.Este hashsealmacenacomopartedelregistroactual.

Formalmente,sisedenotaeli-ésimoregistrodeauditoríacomo Ri ysuhashcomo Hi,entonces Hi = Hash(Ri ∥ Hi 1),donde ∥ denota concatenacióny Hash esunafuncióndehashcriptográficacomoSHA256oSHA-3.Elprimerregistro(genesisrecord)requieretratamiento especialyaquenohayregistroanterior;típicamente H0 seestablece aunvalorconocidoypúblicamentedisponible,osederivadealgún valoraleatorioqueesalmacenadodemaneraverificable(Kent& Souppaya, 2006).

Lapropiedaddeseguridadclavedehashchainses:cuandosealtera cualquierregistrohistórico Rj requeriríarecalcularnosolo Hj sino todosloshashessubsecuentes Hj+1, Hj+2,..., Hn hastaelregistro másreciente.Sielhashdelregistromásreciente Hn hasidopublicado oalmacenadodemaneraverificable(porejemplo,entregadoaun serviciodetimestampingtercero,oescritoablockchain),entonces unverificadorpuededetectarqueocurrióunaalteracióncomparando el Hn almacenadoexternamenteconel Hn queresultaderecalcular lacadenadesdeelgenesisrecord.

4.15.2 MerkleTreesparaVerificaciónEficiente

Mientrasloshasheschainsproporcionandetecciónfuertede manipulación,tienenunalimitaciónpráctica:verificarlaintegridad delacadenacompletarequiereprocesartodoslosregistrosdesdeel origen(genesisrecord)hastaelregistromásreciente.Estoconlleva que,pararegistrosdeauditoríaconmillonesomilesdemillonesde registros,estaverificacióncompletapuedesercomputacionalmente prohibitiva.EntonceslosMerkletrees(tambiénllamadoshash

trees)(Merkle, 1979)proporcionanunaalternativaquepermitela verificacióneficientedesubconjuntosderegistrossinprocesartodo elárbol.

UnMerkletreeesunaestructuradeárbolbinariodondecada nodohojacontieneelhashdeunregistrodedatos,ycadanodo internocontieneelhashdelaconcatenacióndesusdosnodoshijos. Elnodoraízenlacimadelárbol(elMerkleroot)yrepresenta criptográficamentetodoslosregistrosenelárbol.RalphMerkle propusoestaestructuraen1979originalmenteparafirmasdigitales eficientes,perohaencontradoaplicacionesampliasincluyendoBitcoin, Git,ysistemasdearchivosdistribuidos(Merkle, 1979).

Paraunconjuntodenregistrosdeauditoría,éstossecolocan enlasnhojasdelárbol.Secalculanhashesparacadahoja,luego hashesparacadaniveldenodosinternosbasándoseensushijos,hasta llegaralaraíz(root).ElMerklerootpuedeentoncesserpublicadoo almacenadodemaneraverificable.

4.15.3 FirmasDigitalesyNoRepudio

LosHashChainsyMerkleTreesprotegencontralaalteración deregistros,peronoproporcionanelefectoNoRepudio,estoesla propiedaddequeelcreadordeunregistronopuedeposteriormente negarlocreado.Paranorepudio,serequierenfirmasdigitalesbasadas encriptografíadeclavepública.Unafirmadigitalsobreunregistro deauditoríaproporcionaevidenciacriptográficadequeelregistrofue generadoporunaentidadespecífica(elposeedordelaclaveprivada correspondientealaclavepúblicaverificadora)ynohasidoalterado desdesufirma.

Elprocesodefirmatípicamenteinvolucracalcularunhashdel registro,encriptaresehashconlaclaveprivadadelfirmante,y adjuntarlafirmaresultantealregistro.Unverificadorpuedeluego desencriptarlafirmausandolaclavepúblicadelfirmante,calcular elhashdelregistro,ycompararlosdos.Sicoinciden,elverificador tieneevidenciacriptográficaque:(a)elregistronohasidoalterado desdequefuefirmado,y(b)fuefirmadoporelposeedordelaclave privadacorrespondientealaclavepúblicausadaparaverificación.

Pararegistrosdeauditoría,lasfirmasdigitalespuedenaplicarse aregistrosindividualesoalotesderegistros.Firmarcadaregistro individualproporcionamáximagranularidaddenorepudio,perotiene altasobrecargacomputacional(overhead).Firmarlotesderegistros reduceeloverheadperosignificaqueelnorepudioaplicaallote completo,noaregistrosindividuales.

4.15.4 TimestampingConfiable(RFC3161)

Paramuchospropósitosdeauditoría,escríticonosoloregistrar quéocurriósinocuándoocurrióconcertezaverificable.Sinembargo, timestampsgeneradoslocalmenteporelsistemaquegeneraregistros deauditoríasoninherentementenoconfiables,unatacantecon controldelsistemapodríaretroactivamentealterarelrelojdel sistemayregenerarregistroscontimestampsfraudulentos.Trusted timestamping(selladodetiempoconfiable)resuelveesteproblema medianteintervencióndeunaterceraparteconfiable.

ElInternetEngineeringTaskForce(IETF)estandarizóunprotocoloparatrustedtimestampingenRFC3161,publicadoen2001 (Adamsetal., 2001).Elprotocolodefinecomounclientepuede enviarunhashdeundocumento(oenelpresentecaso,unregistro deauditoría)aunaTimeStampingAuthority(TSA)confiable,y recibirdevueltauntimestamptokenquecertificaqueeldocumento existíaenelmomentoespecificadoporlaTSA.

Eltimestamptokencontiene:elhashdeldocumentoconteniendo timestam,eltiempoprecisosegúnelrelojdelaTSA,unnúmeroserial único,yunafirmadigitaldelaTSAsobretodaestainformación. Relevantemente,laTSAmantieneunregistrodeauditoríapropio detodoslostimestamptokensquehaemitido,proporcionando evidenciaverificabledecuándofueronemitidos.Siposteriormentehay disputasobrecuándosecreóunregistrodeauditoría,eltimestamp tokenpuedeserverificadocriptográficamenteyproporcionaevidencia convincente.

4.16.1 MetodologíadeInvestigaciónForenseDigital

Elanálisisforensederegistrosdeauditoría,laprácticadeexaminar registrosdeauditoríaparareconstruireventos,identificarcausasde incidentes,ydesarrollarevidenciaparapropósitoslegalesoadministrativos,requieremetodologíarigurosaparaasegurarqueloshallazgos seandefendibles.Elcampodelaforensedigitalhadesarrollado frameworksmetodológicosque,aunquediseñadosoriginalmentepara análisisdesistemasdearchivosymemoria,seaplicanigualmentea análisisdelogs.

Elframeworkmásampliamentecitadoeselpropuestoporla DFRWS(Palmer, 2001)quedescribeunmodelodecuatrofases: colección,examen,análisisyreporte.Lafasedecoleccióninvolucra identificar,adquirirypreservarfuentesdeevidenciapotencial,en elpresentecaso,registrosdeauditoríarelevantes.Enestafasees importantemantenerlacadenadecustodiayasegurarlaintegridadde evidenciamediantehashingcriptográficoydocumentaciónmeticulosa decómofueronobtenidosloslogs.

Lafasedeexameninvolucraprocesarlosdatosrecolectadospara extraerinformaciónrelevante.Pararegistrosdeauditoría,estopuede involucrar“parsing”delogsenformatosestructurados,filteringpara remover“noise”,enriquecimientocondatoscontextualesdeotras fuentes,yorganizacióntemporaldeeventos.Lafasedeanálisises dondeocurreeltrabajoinvestigativoreal,desarrollandoyprobando hipótesissobrequéocurrió,correlacionandoeventosdemúltiples fuentes,identificandopatronesanómalos,reconstruyendosecuencias deactividad.

4.16.2 ReconstruccióndeLíneasdeTiempodeEventos

Unatécnicafundamentalenanálisisforensedelogseslaconstruccióndelíneasdetiempo,representacionescronológicasdeeventos relevantesquepermitenainvestigadoresvisualizaryrazonarsobre secuenciasdeactividad.Laslíneasdetiemposonparticularmente valiosascuandoseinvestiganincidentescomplejosqueinvolucran

múltiplesactores,múltiplessistemas,yperíodosextendidosde tiempo.

Construirunalíneadetiempoprecisaderegistrosdeauditoría presentavariosdesafíostécnicos.Primeroestáelproblemadesincronizacióndetiempo.Eventosenlalíneadetiempoprovienentípicamente demúltiplessistemasquepuedentenerrelojesdesincronizados. InclusoconNetworkTimeProtocol(NTP),lasincronizaciónde relojestípicamentetieneprecisiónsoloenelrangodemilisegundos asegundos.Paraeventosqueocurrenenrápidasucesiónocasi simultáneamenteendiferentessistemas,determinarordentemporal verdaderopuedeserimposiblebasándosesoloentimestampsfísicos.

4.16.3 DeteccióndeAlteracióndeLogs

Undesafíoparticularenanálisisforenseesdeterminarsilos mismosregistrosdeauditoríahansidomanipulados.Unatacante sofisticadoquehaganadoaccesosuficienteaunsistemapuedeintentar cubrirsushuellasalterandooeliminandoregistrosdeauditoríaque documentaríansuactividad.Detectartalmanipulaciónrequieretanto mecanismospreventivos(lasproteccionescriptográficasdiscutidas anteriormente)comotécnicasanalíticasparaidentificarindicadores demanipulación.

Latécnicamásrobustaeslaverificacióncriptográficamediante hashchainsoMerkletreescomosediscutiópreviamente.Silos registrosdeauditoríafueronprotegidosmedianteestastécnicasy loshashesdeverificaciónfueronalmacenadosdemaneraexterna, entonceslaalteraciónesalgorítmicamentedetectable.Sinembargo, enmuchasorganizaciones,especialmenteaquellasconmadurezde seguridadlimitada,losregistrosdeauditoríanotienenprotección criptográfica.Enestoscasos,losanalistasdebenconfiarenindicadores heurísticosdemanipulación.

Capítulo5

ANÁLISISYGENERACIÓNDEREPORTES

DEAUDITORÍA

Lossistemasdeauditoríamodernosgeneranvolúmenesmasivosde datos,puedenproducirgigabytesoterabytesdeeventosderegistro diariamente.Estevolumenpresentaundesafíofundamental:cómo transformarcantidadesmasivasdeeventosderegistrocrudosen informaciónaccionablequepermitadetectaramenazas,identificar problemasoperacionales,demostrarcumplimientoregulatorio,y soportarinvestigacionesforenses.

ElInstitutoNacionaldeEstándaresyTecnología(NIST)(National InstituteofStandardsandTechnology, 2024)ensuPublicación Especial800-92“GuíaparalaGestióndeRegistrosdeSeguridad Informática”estableceque“elanálisisefectivoderegistrosrequiere reducirgrandesvolúmenesdedatosderegistroaconjuntosmáspequeñosdeinformaciónrelevantemedianteprocesosautomatizadosde filtrado,normalización,agregaciónycorrelación”.Sinestosprocesos, laspistasdeauditoríasevuelveninútilesenlapráctica,lainformación existetécnicamenteperonopuedeserextraídaeficientementecuando senecesita.

Elanálisisdedatosdeauditoríatípicamentesigueunacadenade múltiplesetapasquetransformaprogresivamentedatoscrudosen inteligenciaaccionable:

5.1.1 Etapa1:RecolecciónyAgregación

Laprimeraetapaconsisteenrecolectareventosderegistrode fuentesdistribuidasycentralizarlosenrepositoriocomún.Comose discutióenelpatrónLogAggregation,estoinvolucraagentesde recolección(Filebeat,Fluentd,Logstash)queleenregistroslocalesy lostransmitenaunagregadorcentral.Laagregacióndebepreservar metadatoscríticos:marcatemporal(timestamp)originaldelevento (nosolomarcatemporalderecolección),fuentequegeneróelevento (nombredeservidor,direcciónIP,servicio,componente),severidado criticidaddelevento,ycontextoadicionalespecíficodedominio.

Eldesafíodeagregaciónensistemasdistribuidoseslasincronizacióntemporal,diferentesservidorespuedentenerrelojescon

desviacióndesegundosominutos.ElProtocolodeTiempode Red(NTP,NetworkTimeProtocol)debeconfigurarseentodos losnodosparamantenersincronizacióntemporaldentroderangos aceptables(típicamentemenosde1segundodedesviación).NIST SP800-92recomiendaque“todaslasfuentesderegistroenuna organizacióndebenutilizarmismafuentedetiempodereferenciay estarconfiguradasparaajustarautomáticamentesusrelojessegún seanecesarioparamantenersesincronizados”(NationalInstituteof StandardsandTechnology, 2024).

5.2 Etapa2:NormalizaciónyAnálisisSintáctico(Parsing)

LoseventosderegistroLoglleganenformatosheterogéneos, syslog,JSONestructurado,XML,textoplanosinestructura,formatos propietariosdeaplicacionesespecíficas.Lanormalizaciónconvierte estosformatosdiversosaesquemacomúnquepermiteprocesamiento uniforme.

Elanálisissintácticoextraecamposestructuradosdetextono estructurado.Porejemplo,unalíneaderegistrodelservidorweb Apache:

1 192.168.1.100-usuario123[09/Ene /2026:14:30:45+0000] " GET / api / ordenes /123 HTTP /1.1 " 2001234

Debeanalizarseparaextraercampos:direcciónIPdelcliente(192 .168.1.100),usuarioautenticado(usuario123),marcatemporal(09/E ne/2026:14:30:45),métodoHTTP(GET),rutasolicitada(/api/orde nes/123),códigodeestado(200),bytestransferidos(1234).

5.3 Etapa3:Enriquecimiento

Elenriquecimientoañadecontextoadicionalaeventosmediante consultaenfuentesdedatosauxiliares.Ejemplosdeenriquecimiento incluyen:

✓ Resolucióndeidentidad: Elidentificadornuméricodeusuario

oGUIDseenriquececonsultandoporejemploundirectorio corporativo(ActiveDirectory,LDAP)paraañadirlenombre completo,correoelectrónico,departamento,supervisor,roles organizacionales,etc.Estoconvierte“IDUsuario:12345”en informaciónmásútilparaanalistas:“JuanPérez,Departamento Financiero,rol:ContadorSenior”.

✓ GeolocalizacióndedireccionesIP: LasdireccionesIPpúblicas seenriquecenmediantebasesdedatosdegeolocalización(Ejemplo: MaxMindGeoIP2,IP2Location)paraañadirpaís,ciudad,coordenadasgeográficas,númerodesistemaautónomo,tipodeconexión. Estopermitedetectaranomalíasgeográficas,porejemplo,cuando unusuarionormalmenteconectándosedesdeEcuadorsúbitamente tieneiniciodesesióndesdeRusia.

✓ Fuentesdeinteligenciadeamenazas: Seutilizanparadetectar siuneventodeseguridadestárelacionadoconactividadesmaliciosasyaconocidas.Paraello,secontrastanindicadorestécnicostales como:direccionesIP,nombresdedominioohashesdearchivos, contrarepositoriosespecializadosdeinteligenciadeamenazas, entreellosAlienVaultOTX,Abuse.chyMISP.Cuandoalgunode estosindicadorescoincideconregistrospreviamenteasociadosa actividadesmaliciosas,porejemplo,unadirecciónIPidentificada comoservidordecomandoycontroldeunabotnet,eleventose clasificaautomáticamentecomodealtaprioridad,yaqueexiste evidenciaconcretadecompromiso.

✓ Inventariodeactivos: Permitedarcontextoaloseventos deseguridadalenriquecerinformaciónbásicacomoelnombre delservidoroladirecciónIPmedianteconsultasalaBasede DatosdeGestióndeConfiguración.Apartirdeestasconsultasse incorporandatosrelevantesdelactivo,comosuniveldecriticidad, elresponsabledelsistema,laversióndelsoftwareylaclasificación delainformaciónqueprocesa.Estecontextohaceposiblepriorizar adecuadamentelosincidentes.Porejemplo,uneventoqueafectaa unsistemaqueprocesadatosdetarjetasdepagobajoelestándar PCIDSSresultamáscríticoqueelmismoeventoocurridoenun entornodedesarrollo.

✓ Detallesdetransaccionesdenegocio: Identificadoresde transaccionesseenriquecenconsultandosistemasoperacionales paraañadirdetallesdenegocio.Porejemplo,“IDOrden:98765” seenriquececonmontodeorden,cliente,productos,estado, permitiendoanalizarpatronesaniveldenegocioenlugarde soloniveltécnico.

Tomarencuentaqueelenriquecimientodebebalancearsecontra latencia,puesconsultarmúltiplessistemasexternosporcadaevento puedeintroducirretrasossignificativos.Siendoasí,lasestrategias deoptimizaciónincluyenalmacenamientoencachédeconsultas frecuentes,agrupacióndemúltiplesconsultas,yenriquecimiento asíncronodondeuncontextoadicionalseañadedespuésdeuna ingestainicialsinbloquearprocesamiento.

Notodosloseventostienenigualvalorparaanálisis.Elfiltrado eliminaeventosdebajovalororuido,reduciendovolumendedatos quedebealmacenarseyanalizarse.NISTSP800-92identificavarios tiposdefiltrado:

✓ Filtradoporprioridad: Retenersoloeventosqueexcedenun umbraldeseveridad.Porejemplo,retenersoloeventosADVERTENCIA,ERROR,CRÍTICO;descartareventosDEPURACIÓN eINFORMACIÓNparasistemasnocríticos.Estoreduceel volumen,peromantieneinformaciónsobreeventospotencialmente problemáticos.

✓ Filtradoporrelevanciadeseguridad: Enuncontextode monitoreodeseguridad,filtrarpararetenersoloeventoscon implicacionesdeseguridad.Porejemplo,retenertodosloseventos deautenticación(éxitosyfallos),accesoarecursossensibles, cambiosdeconfiguración,elevacióndeprivilegios;descartar eventosoperacionalesrutinariossinimplicacionesdeseguridad.

✓ Eliminacióndeduplicados: Cuandounmismoeventosegenera repetidamente(porejemplo,servidorintentandoconectaraun

5.4 Etapa4:FiltradoyReducción

recursonodisponiblegeneraerrorcadasegundo),laeliminaciónde duplicadossepuedecontraerenunaentradaúnicaconcontadorde cuántasvecesocurrió.Estopreservainformacióndequeproblema ocurriósinalmacenarmillonesdecopiasdelmismomensaje.

✓ Muestreo: Parasistemasconvolúmenesextremadamentealtos, elmuestreoestadísticoretienesolounporcentajedeeventos(por ejemplo,1decada100solicitudesHTTP)mientrasmantienerepresentatividadestadísticadepatrones.Elmuestreoreducevolumen dramáticamente,peropierdegranularidadparainvestigaciones forensesespecíficas.

Elfiltradodebeaplicarsecuidadosamente,filtradoexcesivamente agresivopuedeeliminarevidenciacrítica.Porejemplo,elPCIDSS Requisito10.5(PCISecurityStandardsCouncil, 2022)específicamenteprohíbelaalteraciónoeliminaciónderegistrosdeauditoría sinmecanismosapropiadosdeprotecciónyretención.Lasdecisiones defiltradodebendocumentarseenpolíticaderegistroyrevisarse periódicamente.

5.5 Etapa5:CorrelaciónyAgregación

Lacorrelacióncombinaeventosrelacionadosdemúltiplesfuentes paraidentificarpatronescomplejosquenoseríanvisiblesexaminandoeventosindividualesaisladamente.Existenmúltiplestiposde correlación:

✓ Correlacióntemporal: Eventosqueocurrendentrodeuna ventanadetiempoespecíficasepuedenagrupar.Porejemplo, iniciodesesiónexitososeguidodentrode2segundosporaccesoa archivosensible,seguidodentrode5segundosportransferencia deredgrandepuedeindicarexfiltracióndedatos.

✓ Correlaciónporentidad: Todosloseventosrelacionadoscon unamismaentidad(usuario,direcciónIP,sesión,transacción)se agrupan.Estopermiterastrearactividadcompletadelaentidad atravésdeltiempo.Porejemplo,agrupartodosloseventosde usuarioespecíficodurantesusesióndetrabajopermitedetectar

anomalíasenpatróndecomportamientodelusuario.

✓ Correlaciónentrefuentes: Eventosdediferentessistemasse correlacionancuandorepresentandiferentesperspectivasdeuna mismaactividad.Porejemplo:registrodefirewallsmostrando conexiónpermitida,registrodeservidorwebmostrandosolicitud HTTP,registrodeaplicaciónmostrandoconsultadebasede datos,registrodeauditoríadebasededatosmostrandoejecución deconsulta.Correlacionarestoseventosproporcionaunavista completadeextremoaextremodelatransacción.

✓ Correlaciónmediantereglas: Reglaspredefinidasespecifican patronesdeeventosqueindicancondicionesdeinterés.Por ejemplo,regladedeteccióndeataquedefuerzabruta:“Sise observan10omásintentosdeiniciodesesiónfallidosdesdeuna mismadirecciónIPparaunamismacuentadentrode5minutos,se debegenerarunaalertadeseveridadalta”.LossistemasdeGestión deInformaciónyEventosdeSeguridad(SIEM)implementan motoresdecorrelaciónbasadosenreglasqueevalúanmilesde reglascontraflujosdeeventosentiemporeal.

5.6 TécnicasdeAnálisis:DeDescriptivoaPredictivo

Elanálisisdedatosdeauditoríaabarcaunespectrodesdeelanálisis descriptivoretrospectivohastaelanálisispredictivoprospectivo:

5.6.1 AnálisisDescriptivo:¿QuéOcurrió?

Elanálisisdescriptivoexaminaeventoshistóricosparaentender quéocurrióeneltiempo.Seincluyenlassiguientestécnicas:

✓ Tablerosyvisualizaciones: Sonrepresentacionesgráficasde métricasclavequeproporcionanunavistarápidadelestadodel sistema.Lostablerostípicamenteincluyen:gráficosdelíneas mostrandovolumendeeventosatravésdeltiempo,gráficosde barramostrandodistribucióndeeventosporcategoríaofuente, mapasdecalormostrandoactividadporhoradeldíaydíade semana,indicadoresmostrandométricasclavecontraumbrales,y tablasmostrandolosNusuarios,direccionesIP,orecursosmás

activos.

Alrespecto,lasherramientasdesoftware:Kibana,Grafana,y Splunk,proporcionancapacidadesricasdecreacióndetableros. Eldiseñoefectivodetablerossigueprincipiosdevisualización estandarizados,maximizanlaproporcióndeelementosdedicadosa mostrardatosversusdecoración,evitanelementosdecorativosque noañadeninformación,yusancodificacionesvisualesapropiadas paratiposdedatos(posiciónparavalorescuantitativosprecisos, colorparacategorías,tamañodeáreaparamagnitudesrelativas).

✓ Consultasespecíficas: Búsquedasespecíficaspararesponder preguntaspuntuales.“¿CuántasveceselusuarioXaccedióal sistemalasemanapasada?”“¿Quéarchivosfueronmodificados enelservidorYel5deenero?”.Paraelefecto,laherramienta Elasticsearchproporcionalenguajedeconsultaeinterfazvisual (Kibana)paraconsultasespecíficas.Splunk,proporcionaun LenguajedeProcesamientodeBúsqueda(SPL)paraexpresar consultascomplejas.

✓ Informesprogramados: Informesquesegeneranautomáticamenteencadenciaregular(diariamente,semanalmente,mensualmente)ysedistribuyenalosinteresados.Losinformesde cumplimientotípicamentedocumentanmétricasrequeridaspor regulaciones,ejemploparaPCIDSS:númerodeintentosde accesoadatosdetarjetas,cambiosaconfiguracióndesistemasen alcance,accesosdecuentasprivilegiadas.ParaHIPAA:accesosa InformacióndeSaludProtegida,divulgaciónaterceros,accesos deemergencia.

5.6.2 AnálisisDiagnóstico:¿PorQuéOcurrió?

Elanálisisdiagnósticoinvestigacausasraízdeeventosopatrones observados.Sustécnicasincluyen:

✓ Análisisdeprofundización: Partirdeunamétricaagregaday progresivamentedescomponerencomponentesmásgranulares paraidentificarfuentedeanomalía.Porejemplo,untablero muestraquelatasadeerrorglobaldeinterfazdeprogramación aumentó500%,laprofundizaciónporpuntodeaccesorevela

específicamentequelainterfaz“/api/pagos”tiene95%deerrores. Laprofundizaciónporcódigodeerrorrevelaquetodosson503 ServicioNoDisponible.Laprofundizaciónpormarcatemporal revelaquecomenzóexactamentealas14:30.Lacorrelacióncon registrosdedesplieguerevelaquenuevaversióndeserviciode pagosfuedesplegadaalas14:28.Conclusión:nuevodespliegue introdujoerrorquecausaindisponibilidaddeservicio.

✓ Análisisdecausaraízmediantecorrelación: Cuandoun incidentecomplejoocurre,sedebecorrelacionareventosde múltiplessistemasparareconstruirunacadenacausal.Porejemplo, lainterrupcióndeunaaplicaciónwebpuederastrearsehaciaatrás: registrosdeaplicaciónmuestrantiemposdeesperaconectandoa basededatos,losregistrosdebasededatosmuestranconsultas bloqueadasesperandobloqueos,lasmétricasderendimientode basededatosmuestranpicoenesperadeentrada/salida,los registrosdearreglodealmacenamientomuestranfallosdedisco, lasalertasdemonitoreomuestranquemododegradadodeRAID comenzó10minutosantesdelosprimerossíntomasvisiblesa usuarios.

✓ Análisiscomparativo: Compararperíodosdiferentespara identificarquécambió.Porejemplo,lalatenciadeinterfazde programaciónaumentóestasemanacomparadaconlasemanapasada.Elanálisiscomparativorevelaqueelvolumendesolicitudes aumentó40%,peroesosoloexplicaunapartedelaumentode latencia.Entoncessepuedeampliarydescubrirqueladistribución detiposdesolicitudescambió,laproporcióndesolicitudesdetipo “consulta_compleja”aumentóde10%a30%.Lainvestigación podríarevelarquelanuevafuncionalidadlanzadaesasemana generómásconsultascomplejas.

5.6.3 AnálisisPredictivo:¿QuéOcurrirá?

Elanálisispredictivoutilizatécnicasdeaprendizajeautomático yestadísticaparapredecireventosfuturosbasándoseenpatrones históricos;asísetiene:

Deteccióndeanomalías: Losalgoritmosdedetecciónde

anomalíasaprendenpatronesnormalesdecomportamientodedatos históricosygeneranalertascuandoobservandesviacionessignificativas.Técnicasincluyen:

✓ Detecciónestadísticadeanomalías: Modeladistribución estadísticademétrica(porejemplo,númerodeiniciosdesesión porhora)ydetectavaloresqueestánmásdeNdesviaciones estándardelamedia.

✓ Pronósticodeseriestemporales: ModeloscomoARIMA (MediaMóvilIntegradaAutoRegresiva),Prophet(desarrollado porFacebook),oredesneuronalesLSTM(MemoriadeCortoy LargoPlazo)predicenunvaloresperadodeserietemporalenuna marcatemporalfuturabasándoseenhistórico.Lasanomalíasson valoresobservadosquedifierensignificativamentedelapredicción.

✓ Deteccióndeanomalíasbasadaenagrupamiento: AlgoritmoscomoDBSCAN(AgrupamientoEspacialBasadoenDensidad deAplicacionesconRuido)oBosquedeAislamientoagrupan eventossimilaresengrupos.Loseventosquenopertenecena ningúngrupodenso(valoresatípicos)semarcancomoanomalías.

Yasehamencionadoantessobrelaherramientadesoftware Elasticsearch,éstaincluyecaracterísticasdeaprendizajeautomático queautomáticamentedetectananomalíasenseriestemporales.ElKit deHerramientasdeAprendizajeAutomáticodeSplunkproporciona algoritmosparaanálisisderegistros.HayotrosproductosespecializadoscomoAnodot,queseenfocanexclusivamenteendetección automáticadeanomalíasenmétricasdenegocioysistemas.

AnálisisdeComportamientodeUsuariosyEntidades (UEBA): UEBAaplicaaprendizajeautomáticoparaconstruir perfilesdecomportamientonormaldeusuariosyentidades(servidores, aplicaciones,cuentasdeservicio)ydetectardesviacionesquepueden indicarcompromisodecuentaoamenazainterna.Porejemplo,UEBA puededetectar:

✓ Usuarioquenormalmentetrabajade9am-5pmsúbitamentetiene actividadalas3am.

✓ Usuarioquenormalmenteaccedea10-20archivospordíasúbitamenteaccedea5,000archivos.

✓ UsuarioquenormalmenteseconectadesdeEcuadorsúbitamente tieneiniciodesesióndesdeChina.

✓ CuentadeservicioquenormalmenteejecutaconsultasSELECT súbitamenteejecutaDROPTABLE.

Mantenimientopredictivoyplanificacióndecapacidad:

Elanálisisdetendenciasenmétricasoperacionalespredicecuándo losrecursosalcanzaránunacapacidadocuándosuscomponentes probablementefallarán.Porejemplo,elanálisisdecrecimientode usodediscopredicequéservidoralcanzará90%decapacidad en3semanas,permitiendoaprovisionaralmacenamientoadicional proactivamente.Elanálisisdetasadeerroresenunarreglode almacenamientoprediceprobabilidaddefallodediscoenlospróximos 30días(basándoseenmétricasSMART),permitiendounreemplazo proactivoantesdelapérdidadedatos.

5.7 PlataformasIntegradas

LossistemasdenominadosSIEM,sonmódulosintegradospara laGestióndeInformaciónyEventosdeSeguridad,éstosintegran funcionalidadderecolección,normalización,correlación,análisis,y generacióndealertasenplataformaunificada.UnaarquitecturaSIEM típicaconstadelossiguientescomponentes:

✓ Capaderecoleccióndedatos: Conectoresparamúltiples fuentesderegistro(syslog,RegistrodeEventosdeWindows, interfacesdeprogramacióndeproveedoresdenube,agentes instaladosenpuntosfinales,datosdeflujodereddecortafuegos yenrutadores,registrosdeaplicaciones).

✓ Motordenormalización: Analizadorqueconvierteformatos heterogéneosaunmodelodedatoscomún(CEF,LEEF,esquema propietariodelproveedor).

✓ Motordecorrelación: Motordereglasqueevalúaeventoscontra

unabibliotecadereglasdecorrelaciónparadetectarpatronesque indicanincidentesdeseguridad.Lasreglastípicamenteseexpresan como:SI(condición_1Ycondición_2Y...)DENTRO_DE (ventana_temporal)ENTONCES(generar_alerta).

✓ Generacióndealertasygestióndecasos: Sistemadegestión dealertasquepriorizaalertasbasándoseensuseveridad,agrupa alertasrelacionadasencasos(incidentes),asignacasosaanalistas, yrastreaestadodeinvestigaciónyremediación.

✓ Informesdecumplimiento: Informespredefinidosmapeados arequisitosderegulacionescomunes(PCIDSS,HIPAA,SOX, GDPR,ISO27001)quedocumentancumplimientoconcontroles específicos.

LosproveedoresprincipalesdeSIEMincluyena:SplunkEnterpriseSecurity,IBMQRadar,LogRhythm,ArcSight(MicroFocus), MicrosoftAzureSentinel(SIEMnativodenube),GoogleChronicle (SIEMnativodenube),ysolucionesdecódigoabiertocomoOSSEC, AlienVaultOSSIM,yWazuh.

Capítulo6

CASOSDEUSOVERTICALES

Elsectorfinancierosemuevedentrodealgunosdelosmarcos regulatoriosmásexigentesdelmundoenloquerespectaaauditoría ytrazabilidad.EnEstadosUnidos,distintosreguladorestalescomo laFederalReserve(SistemadelaReservaFederal),laOfficeofthe ComptrolleroftheCurrency(OficinadelContralordelaMoneda), laSecuritiesandExchangeCommission,SEC(ComisióndeBolsa yValores),laFinancialIndustryRegulatoryAuthority,FINRA (AutoridadReguladoradelaIndustriaFinanciera)ylaCommodity FuturesTradingCommission,CFTC(ComisióndeComerciode FuturosdeProductosBásicos)entreotros,establecenobligaciones estrictasdeconservaciónderegistrosyauditoría.Estasexigencias noselimitanalaproteccióndelconsumidor:tambiénrespondena lanecesidaddepreservarlaestabilidaddelsistemafinancieroensu conjuntoydecombatirdeformaefectivaelcrimenfinanciero.

Unáreaparticulardeenfoqueeslaauditoríadesistemasde trading.LasregulacionesMiFIDIIenEuropayRegNMSen EstadosUnidosimponenrequisitosestrictosde“orderaudittrail”,la capacidadderastrearcadaordendesdesucreaciónhastalaejecución, capturandotodaslasmodificaciones,cancelaciones,ycoincidencias. Lossistemasdetradingdebencapturartimestampsconprecisiónde microsegundos,permitiendoareguladoresreconstruirexactamente quéocurriódurantecondicionesvolátilesdemercado.

Otrorequisitocríticoesauditoríaparaprevencióndelavadode dinero(AML-Anti-MoneyLaundering).ElBankSecrecyActy regulacionessubsecuentesrequierenquelasinstitucionesfinancieras mantenganprogramascompletosdeAMLqueincluyenmonitoreo detransaccionesparapatronessospechosos.Lossistemasdeauditoríadebencapturarsuficienteinformaciónsobrecadatransacción parapermitiranálisisdepatrones,originador,beneficiario,monto, frecuencia,relaciónconotrastransacciones,ycualquierflagderiesgo identificadoporsistemasautomáticos.

Lossistemasderegistrosmédicoselectrónicos(EHR-Electronic HealthRecords)presentanrequisitosparticularmentedesafiantespara auditoríadebidoalasensibilidadextremadelosdatosdesalud,el númerograndedeusuariosconaccesolegítimo(médicos,enfermeras, técnicos,personaladministrativo),yescenarioscomplejosdeacceso comoemergenciasdondeelaccesonormalbasadoenrolespuede necesitarserdecaracterística“override”.

LaHIPAASecurityRulerequiereespecíficamentequelasentidades cubiertasimplementen“hardware,software,y/omecanismosproceduralesqueregistrenyexaminenactividadensistemasdeinformación quecontienenousanelectronicprotectedhealthinformation”.Los registrosdeauditoríadeEHRtípicamentedebencapturar:quién accedióalregistrodequépaciente,cuándo,desdedónde,qué informaciónespecíficamentefuevistaomodificada,eidealmente elpropósitoclínicoorazóndenegocioparaelacceso.

Unescenarioparticularmentecomplejoesel“break-glassAccess”, dondeensituacionesdeemergenciaelpersonalclíniconecesita accesoinmediatoaunregistrodelpacientesintiempoparaobtener autorizacionesnormales.LossistemasEHRauditablesdebensoportar esteaccesodeemergenciamientrascapturancuidadosamentecada instanciapararevisiónposterior.ElRastrodeAuditoríadeberegistrar queocurrióunbreak-glassaccess,quiénloinvocó,paraquépaciente, enquécircunstancias,ydebealertarapersonalencargadodeuna revisiónretrospectivaqueverificaqueelaccesofueapropiado.

6.3 FacturaciónElectrónicaenEcuador:SistemaSRI

ElServiciodeRentasInternas(SRI)delEcuadorimplementóun sistemaobligatoriodefacturaciónelectrónicaquepresentarequisitos específicosdeauditoríaytrazabilidad.Estesistema,vigentedesde 2015ymandatorioparavirtualmentetodosloscontribuyentesdesde 2018,representaunodelosregímenesdefacturaciónelectrónicamás completosenAméricaLatinayproporcionauncasodeestudiovalioso sobreimplementacióndeauditabilidadencontextosdegobierno.

6.3.1 ArquitecturadelSistemadeFacturaciónElectrónica

ElsistemadefacturaciónelectrónicadelSRIestábasadoen varioscomponentestécnicosclave.Primero,lasfacturaselectrónicas debengenerarseenformatoXMLsiguiendoesquemasXSDespecíficos publicadosporelSRI,quedefinenlaestructuraexactadediferentes tiposdecomprobantes(facturas,notasdecrédito,notasdedébito, guíasderemisión,comprobantesderetención).Estosesquemasson extremadamentedetallados,especificandocadacampoquedebeestar presente,formatosdedatos,validaciones,ycódigosválidospara clasificacióndeproductosyservicios.

Segundo,cadacomprobanteelectrónicodebeserfirmadodigitalmenteusandoelestándarXAdES-BES(XMLAdvancedElectronic Signatures,BasicElectronicSignature).XAdES-BESesunformato defirmadigitalqueextiendeXMLSignatureparaproporcionar propiedadesadicionalesrequeridasparapropósitoslegalesenEuropa yadoptadosenEcuador.Lafirmadebesergeneradausandoun certificadodigitalemitidoporunaentidadcertificadoraautorizada porelSRI,típicamenteobtenidomedianteunprocesodeverificación deidentidaddelcontribuyente.

6.3.2 ImplementacióndeFirmaDigitalXAdES-BES

LaimplementacióndefirmaXAdES-BESparafacturaciónelectrónicarequierecomprensióntantodelosestándaresXMLSignature comodelasextensionesespecíficasdeXAdES.En.NET,esto típicamenteseimplementausandolaclaseSignedXmldelnamespace System.Security.Cryptography.XmljuntoconbibliotecasespecializadasparaXAdEScomoFirmaXadesNetoXades.Net.

ElprocesodefirmacomienzaconelXMLdelcomprobanteelectrónicocompleto.EsteXMLdebeprimerosercanonicalizadousando algoritmodecanonicalizaciónespecificado(típicamenteCanonical XML1.0),calculándosesudigestusandoSHA-256oSHA-1.Eldigest seincluyeenunelementoReferencedentrodelaestructuradefirma, juntoconinformaciónsobreelalgoritmousado.

LaestructuradefirmaXAdESincluyevarioselementosespecíficos. ElelementoSignedPropertiescontienepropiedadesfirmadascomo

eltimestampdefirmayelcertificadodelfirmante.Elelemento SignedSignaturePropertiescontienemetadatasobrelafirmamisma. ElelementoSignedDataObjectPropertiespuedecontenermetadata sobreelobjetosiendofirmado.Todosestoselementosestánincluidos enelcálculodelafirma,asegurandoquenopuedenseralteradossin invalidarlafirma.

6.3.3 ProcesodeAutorizaciónyRastrodeAuditoría

Unavezqueuncomprobanteelectrónicohasidogeneradoy firmado,debeserenviadoalSRIparasuautorización.Esteproceso ocurreentiemporealoenmodooffline,ygeneraunregistrode auditoríacompletodetodoelciclodevidadelcomprobante.El contribuyenteemisorenvíaelXMLfirmadoalserviciowebdelSRI medianteSOAPoRESTAPI.

ElSRIrealizamúltiplesvalidaciones:esquemaXMLcontraelXSD oficial,firmadigital,validezdelcertificadodigital,secuencialidadde númerosdecomprobante,existenciayestadodelRUCdelemisor yreceptor,códigosdeproductosyservicios,cálculodevalores (subtotales,IVA,total),ymás.Sitodaslasvalidacionespasan,el SRIgeneraunaclavedeaccesoúnicade49dígitosqueidentificael comprobanteylomarcacomoAUTORIZADO.

ElRastrodeAuditoríacompletodeesteprocesodebeincluir: timestampdegeneracióndelcomprobante,timestampdefirmadigital, hashdelXMLfirmado,timestampdeenvíoalSRI,respuestadelSRI (autorizado,rechazado,devuelto),clavedeaccesosifueautorizado, cualquiermensajedeerrorsifuerechazado,timestampdeemisión delRIDE(RepresentaciónImpresadelDocumentoElectrónico),y registrosdecualquieranulaciónposterioronotadecrédito/débito relacionado.

6.4 BANREDEcuador:SwitchInterbancarioyCompliance PCI-DSS

BANREDS.A.,fundadaen1984,eslaredinterbancariamás grandedeEcuador.Operamásde7,400cajerosautomáticosinterconectados,procesaaproximadamente1,200millonesdetransacciones

anuales(proyección2024)yconectaa44clientesdirectosymás de100clientesindirectos.BANREDmantienecertificaciónPCIDSS(PaymentCardIndustryDataSecurityStandard)desde2014, recertificándoseanualmente.Entrelosaños2022y2023,renovó completamentesuinfraestructuratecnológicaactualizandosucore transaccionalyswitchparamejorarlavelocidadyseguridad.Se tomaestecasodadosucomplejidadtecnológicaycumplimiento estrictodeestándaresinternacionalesrespectodesuinfraestructura, operatividad,seguridadyauditabilidad.

Respectodelosdesafíosdeauditabilidad,BANREDnosolamente involucraCompliancePCI-DSS,ademásmantieneunainteroperabilidadmultibancoyunvolumentransaccionalmasivodevarios servicios.Detallando,comoswitchinterbancario,conectainstituciones financierasdiversas(bancosprivados,cooperativasdeahorroycrédito, mutualistas),cadatransaccióninvolucraalmenosdosinstituciones: emisorayadquirente.Losregistrosdeauditoríadebenpermitir rastreartransaccióncompletadesdeelorigenhastaeldestino,identificandoresponsabilidadesencasodedisputas.Procesatransacciones queinvolucrandatosdetarjetasdedébitoycréditodemúltiples emisores,PCI-DSSRequisito10exigeregistrosdeauditoríacompletos detodoaccesoadatosdetarjetas,operacionesadministrativasen sistemasdeprocesamiento,yaccesofísicoacentrosdedatospara 1,200millonesdetransaccionesanuales.

BANREDprocesaaproximadamente38transaccionesporsegundo enpromedio,elsistemadeauditoríadebecapturareventosaesta escalasindegradarperformancetransaccionalaloperarmúltiples servicios:reddecajerosautomáticos,PagoDirecto(transferencias interbancariasentiemporeal),WIP(plataformadepagosmóviles lanzada2024),reddecobrosypagosparaentidadespúblicas/privadas, ygestióndepagosdelBonodeDesarrolloHumano.BANREDademás operacámaradecompensaciónparaliquidartransaccionesentre institucionesparticipantes.Cadaserviciotienerequisitosespecíficos deauditoría.

Adicional,laSuperintendenciadeBancosySeguros,asítambiénla SuperintendenciadeEconomíaPopularySolidaria,soninstituciones

reguladorasdelasoperacionesfinancierasenEcuadorquesupervisan alasinstitucionesfinancierasconectadasaBANRED,portanto, sucapacidaddeproporcionarregistrosdeauditoríadetallados facilitaauditoríasregulatoriasdebancosparticipantes.Duranteuna auditoría,unbancopuedenecesitardemostrarquesustransacciones procesadasatravésdeBANREDfueronmanejadasapropiadamente, entoncesBANREDproporcionaevidenciamediantelogs.

LacertificaciónPCIDSSdeBANREDconstituyeunrequisito esencialparaquelosbancosecuatorianospuedanaceptaryprocesar pagoscontarjetasderedesinternacionalescomoVisa,Mastercardy AmericanExpress.Estacertificacióngarantizaquelainfraestructura quesoportalastransaccionescumpleconestándaresestrictosde seguridadyauditoría.EncasodequeBANREDpierdadicha certificación,lasredesinternacionalespodríansuspendersuconexión, loquetendríacomoconsecuenciadirectalaimposibilidaddeutilizar tarjetasdepagoenelpaís.Esteescenarioafectaríatantoausuarios comoaentidadesfinancieras.Porello,elcumplimientorigurosode losrequisitosdeauditoríaporpartedeBANREDresultacríticopara laoperacióncontinuaylaestabilidaddelsistemafinancieronacional.

Capítulo7

IMPLEMENTACIÓNPRÁCTICAEN

ENTORNOS.NET

7.1 DiseñodeArquitecturaparaunSoftwareAuditable Laimplementacióndesoftwareauditableenelecosistema.NET (Microsoft, 2025a)requieredecisionesarquitectónicasdesdelasetapas tempranasdeldiseño.Laarquitecturatípicadeunsistemaauditable en.NETincluyealmenoslossiguientescomponentes:

✓ Loggerconfiguradocentralmente:Serefiereaunainstanciade labibliotecaSerilog(SerilogContributors, n.d.)configuradaal iniciodelaaplicación,típicamenteenelmétodoProgram.csde aplicacionesASP.NETCore.Laconfiguracióndebeespecificar múltiples“sinks”quesondestinosderegistrodeLog,quepueden ser:archivolocal,basededatoscentralizadaparaauditoría, servicioSIEMparamonitoreodeseguridad.

✓ Middlewaredeauditoría:EnaplicacioneswebASP.NETCore, unmiddlewarepersonalizadopuedecapturarautomáticamente informacióndecadarequestHTTP,quepuedeincluirinformación como:usuarioautenticado,direcciónIP,endpointinvocado,parámetrosdeentrada,timestampdeinicioyfin,códigoderespuesta HTTP.

✓ Interceptoresaniveldedatos:LalibreríaEntityFramework Core,eselORMestándardefactoen.NET,proporciona“hooks” parainterceptaroperacionesdebasededatos.Paraelefecto seimplementaSaveChangesInterceptor,quepermitecapturar automáticamentetodaslasoperacionesdeINSERT,UPDATE, DELETE,registrandoelestadoanterioryposteriordelasentidadesafectadasenlabasededatos.

✓ Serviciosdeauditoríaespecializados:Usadosparaoperacionesde negociocríticasquerequierenregistrosdeauditoríadetallados,es recomendableimplementarestosserviciosdedicadosqueencapsulenlalógicadeauditoríayasegurenconsistenciaenelregistrode eventos.

Unprincipioarquitectónicofundamentalesquelasoperaciones deauditoríadebenejecutarsedemaneraasíncronasiempreque seaposible,paraminimizarelimpactoenelrendimientodelas

operacionesdenegocioprincipales.

Enestecapítuloúnicamenteseabordalaimplementacióndel componenteLoggerusandolalibreríaespecializadaSerilog.

7.2 GuíadeImplementacióndeSerilogen.NETCore

Serilogpara.NETCoreesunalibreríaqueseespecializaen generacióndeRegistrosdeAuditoríaatravésdelogging(Serilog Contributors, n.d.),paraelloimplementa“buffering”y“batching” automáticosparalamayoríadesussinks,reduciendosignificativamentelalatencia.Bufferingserefiereamantenertemporalmentelos eventosdelogenmemoriaantesdeenviarlosasudestinofinal,conel objetivodedesacoplarlageneracióndelogsdelprocesodeescritura yevitarimpactosderendimientocuandoeldestinoeslentooestá momentáneamenteindisponible.Batching,encambio,consisteen agruparvarioseventosyaalmacenadosenelbufferyenviarlosjuntos enunasolaoperación,reduciendollamadasdeI/O,usoderedocostos deescritura.Enlapráctica,Serilogprimerobufferizaloseventos yluegolosdespachaenlotessegúntamañoointervalodetiempo configurado.Además,esdeconfiguraciónsencillayeficientetrabajo entodaslascapasdeunsistemaauditable:Captura,Enriquecimiento, Almacenamiento,ProtecciónyAnálisis.

Parasuimplementación,primeramente,sedebedefinirelcontenido estructuraldelloggingpriorizandoEventosdeNegociovs.Eventos Técnicos,porejemplo,distinguirentreeventosquetienensignificado denegocio(“Usuarioaprobóordendecomprapor$50,000”)yeventos puramentetécnicos(“Conexiónabasededatosestablecida”).Los primerossonesencialesparaauditoría;lossegundossonútilespara debugging,perodebenregistrarseanivelesdelogdiferentespara evitarcontaminacióndelosregistrosdeauditoría.

Ademásderegistrareleventoensí,esimportanteaportarcontexto medianteelenriquecimientodedatosatravésde“enrichers”.En Serilog,estospermitenagregardeformaautomáticainformación contextualatodosloseventosdelog,comoelnombredelamáquina, elidentificadordelprocesoodelhilo,ydatosdelentornode

ejecución.Enaplicacionesweb,tambiéneshabitualusarenrichers personalizadosparaincluirinformaciónrelevantedelcontextodela solicitud,comoelidentificadordecorrelacióndelrequest,elusuario autenticado,eltenantenescenariosmultitenantodatosdesesión.

Porotrolado,paraqueloslogsseanrealmenteútilesalanalizarlos, esrelevanteusarpropiedadesestructuradasenlugardeconcatenar valoresdentrodecadenasdetexto.Registrarlosdatoscomopropiedades,porejemplo,usandoplantillascomo{OrderId},permite realizarbúsquedasyconsultaseficientesenlasplataformasdeanálisis delogs,algoquenoesposiblecuandotodalainformaciónqueda mezcladaenuntextoplano..

7.2.1 FundamentosdeConfiguraciónmedianteappsettings.json

Serilog,originalmentefuediseñadoparaconfigurarsemedianteAPI fluidaencódigoC#comopartedelProgram.csdeunproyecto.NET Core,perotambiénpuedeconfigurarsecompletamentemediantearchivosJSONgraciasalpaquetenugetSerilog.Settings.Configuration. Estepaqueteimplementaunproveedordeconfiguraciónquelee desdeMicrosoft.Extensions.Configuration,permitiendoquetoda laconfiguracióndeloggingresidaenarchivosappsettings.jsonsin necesidaddemodificarcódigocompilado.

Laventajaprincipaldelaconfiguracióndeclarativaradicaenla capacidaddemodificarelcomportamientodeloggingenambientes deproducciónsinrecompilaciónniredesplieguedelaaplicación.Los cambiosanivelesdelogging,destinosdeescritura,oformatosde salidapuedenaplicarsemedianteedicióndearchivodeconfiguracióny, opcionalmente,conrecargaencalientesisehabilitareloadOnChange: trueenconfiguracióndelproveedorJSON.

7.2.2 InstalacióndePaquetesNecesarios

LaimplementaciónbásicarequiereelpaqueteNuGetSerilog.AspNetCorecuyainstalaciónestádisponiblemediantecomando CLIde.NET:

ElpaqueteSerilog.AspNetCoreincluyeautomáticamentecomo dependenciaalpaqueteSerilog.Settings.Configuration,queproporcionaelmétododeextensiónReadFrom.Configuration().Para funcionalidadadicionaldeescrituraoenriquecimiento,seinstalan paquetesespecíficosdesinksoenricherssegúnlanecesidad.Por ejemplo,paraescribiraarchivos.logserequiereSerilog.Sinks.File, paraconsolaconcoloresseusaSerilog.Sinks.Console,yparaformato JSONcompactoesnecesarioSerilog.Formatting.Compact.

7.2.3 IntegraciónenProgram.cs

LaconfiguraciónyelusodeSerilogenaplicacionesASP.NETCore serealizanprincipalmenteatravésdellamadasalaclaseestática Serilog.Log,lacualactúacomopuntocentralparainicializarellogger, definirlossinks,establecernivelesdeloggingyaplicaropcionesde enriquecimiento.ElcódigomínimonecesarioenProgram.cses:

EstecódigodelegacompletamentelaconfiguracióndeSerilogal sistemadeconfiguracióndeASP.NETCore,queleeautomáticamente deappsettings.jsonyappsettings.{Environment}.json.Elmétodo ReadFrom.Configuration()interpretalasecciónSerilogdelarchivo JSONytraducesusvaloresallamadasequivalentesdeAPIfluida.

7.2.4 EstructuradeConfiguraciónenappsettings.json

LaconfiguraciónresideenlasecciónraízllamadaSerilogdel archivodeconfiguraciónappsettings.json.Laestructurabásica contienecincosubseccionesprincipales:“MinimumLevel”paracontrol deverbosidad,“WriteTo”paradefinirdestinosdeescritura,“Enrich” paraañadirpropiedadescontextuales,“Using”paraespecificar ensambladosdesinksyenrichers,y“Properties”paraadjuntar propiedadesglobalesatodosloseventos.

Unejemplodeconfiguracióncompletaperoconcisasería:

ConfiguracióndeNivelesdeLogging:LasubsecciónMinimumLevel controlaquéeventosseregistransegúnsuseveridad.Serilogdefineseis

nivelesenordencrecientedeseveridad:Verbose,Debug,Information, Warning,Error,yFatal.ElnivelDefaultestableceelmínimoglobal, mientrasqueOverridepermiteespecificarnivelesdiferentespara namespacesespecíficos.

Laconfiguracióndeoverrideesparticularmenteútilparasuprimir ruidodeframeworkscomoASP.NETCoreoEntityFramework, quegeneranvolúmenessignificativosdeeventosinformativosde bajovalorparaauditoríadeaplicación.Porejemplo,establecer “Microsoft”:“Warning”eliminaeventosinformativosdetodoel namespaceMicrosoft.*,conservandosoloadvertencias,erroresy fatales.Losoverridesseaplicanmediantematchingdeprefijo,por loque“Microsoft.EntityFrameworkCore”:“Error”esmásespecífico que“Microsoft”:“Warning”ytieneprecedencia.

ConfiguracióndeSinksmedianteWriteTo:Lossinksdefinen destinosdondeloseventosdelogseránescritos.LasecciónWriteTo aceptaunarraydeobjetos,cadaunoespecificandounsinkmediante lapropiedadName.Sielsinkrequiereparámetros,estosseespecifican enobjetoArgs.

Parasinkdearchivoconrotacióndiariaylímitedetamaño,la configuraciónsería:

ElparámetrorollingInterval:“Day”causaqueelarchivoserote diariamente,generandonombrescomolog-20260111.log.Elparámetro

fileSizeLimitBytesestableceuntamañomáximode10MBporarchivo, yrollOnFileSizeLimit:truecausalacreacióndeunnuevoarchivo cuandolímiteesalcanzado.ElparámetroretainedFileCountLimit:31 mantienesololosúltimos31archivos,eliminandoautomáticamente archivosmásantiguos.

Laplantilladesalida(outputTemplate)controlaelformatode cadalíneadelog.Lostokensentrellavessonpropiedadesdelevento delog:{Timestamp}esmarcatemporalconformatoespecificado despuésdedospuntos,{Level:u3}esnivelenmayúsculascontres caracteresdeancho,{Message:lj}esmensajeconformatoJSON paravaloresestructurados,y{Exception}esexcepciónsiestuviere presente.

EnriquecimientodeEventos:Losenrichersañadenpropiedades adicionalesacadaeventodelog.Algunosenricherscomunesincluyen FromLogContextquehabilitacontextodeloggingdinámico,WithMachineNamequeañadenombredemáquina,WithThreadIdque añadeidentificadordethread,yWithEnvironmentNamequeañade nombredeambientedeASP.NETCore.

Parautilizarenrichers,primeroseinstalanotrospaquetescorrespondientesmedianteelCLIde.NET:

OdesdeelPackageManagerConsole:

Install-PackageSerilog.Enrichers.Environment

Install-PackageSerilog.Enrichers.Thread

Luegoseespecificanenconfiguraciónmediantearraydenombres quecorrespondenamétodosdeextensión(sinprefijoEnrich.):

Laspropiedadesañadidasporenrichersestándisponiblesen plantillasdesalidaysonincluidasautomáticamenteenformatos estructuradoscomoJSON.Porejemplo,conestosenrichersactivos, cadaeventodelogtendrápropiedadesMachineName,ThreadId,y EnvironmentNamequepuedenreferenciarseenoutputTemplatecomo {MachineName},{ThreadId},y{EnvironmentName}.

PropiedadesGlobales:LasecciónPropertiespermiteadjuntar propiedadesconstantesatodosloseventos.Estoesútilparaidentificar aplicación,versión,oambientecuandologsdemúltiplesfuentesse agreganensistemacentralizado.Porejemplo:

ASP.NETCoresoportamúltiplesarchivosdeconfiguración cargadosencascadasegúnambientedeejecución.El archivoappsettings.jsoncontieneconfiguraciónbase,mientras appsettings.Development.json,appsettings.Staging.json,y appsettings.Production.jsoncontienenoverridesespecíficosde ambiente.

Paralogging,estopermiteconfigurarverbosidadmayorendesarrolloqueenproducción.Porejemplo,appsettings.Development.json podríatener:

ParaintegraciónconsistemasdeagregacióndelogscomoElasticsearchoSeq,espreferibleescribireventosenformatoJSON estructuradoenlugardetextoplano.Enestecaso,elpaquete Serilog.Formatting.Compactproporcionaunformatterqueserializa eventosaJSONcompacto,unalíneaporevento.

LaconfiguraciónespecificaelformateadordeJSONcompacto mediantelapropiedadformatterdelasecciónSerilog/WriteTo/ Args:

CadalíneaLogdelarchivoresultanteesunobjetoJSONválido conlasiguienteestructura:

1 {" @t ":" 2026-01-11 T15 :30:45.1234567 Z" , " @l ":" Information " , " @mt ":" Usuario { UserId } accedi ó a recurso { ResourceId }" , " UserId " :123, " ResourceId ":"DOC -456 "}

Laspropiedadesconprefijo@sonmetadatadeSerilog:@tes timestampISO8601,@lesnivel,@mtesplantillademensaje.Las propiedadessinprefijosonvaloresestructuradosdelevento.

7.2.7 RecargaDinámicadeConfiguración

Parahabilitarlarecargadeconfiguraciónsinreiniciarlaaplicación, seespecificaelparámetroreloadOnChange:truecuandosecargael archivoJSON,nóteseelejemplomínimodecódigoenProgram.cs:

//====================================================== 2 //ConfigurarSerilogleyendodesde appsettings.json

Conestaconfiguración,loscambiosavaloresenseccionesMinimumLevel.Default,MinimumLevel.Override,yswitchesdenivelson detectadosyaplicadosautomáticamente.Sinembargo,loscambios asinks(secciónWriteTo)noseaplicandinámicamente,requieren reiniciodelaaplicación.

7.2.8 UsodeSerilogsegúnNiveldeVerbosidad

Serilogsoportaseisnivelesdeloggingenordencrecientede severidad:Verbose,Debug,Information,Warning,Error,yFatal.La eleccióndelnivelapropiadoescríticaparaqueelfiltradomediante MinimumLevelfuncionecorrectamenteyparamantenerutilidadde loslogssingenerarvolumenexcesivo.

Existendosformasdeescribireventosdelog:mediantelaclase estáticaSerilog.Log,omediantelainterfazILogger<T>deMicrosoft.Extensions.Logginginyectadapordependencia.Ambasinterfaces utilizanlamismainfraestructurasubyacentedeSerilogconfigurada, perodifierenensusmétodosdelogging.

Log.Fatal(exception, " mensaje " ,params);

APIdeILogger<T>deMicrosoft.Extensions.Logging:

1 _logger.LogTrace(" mensaje " ,params);

2 _logger.LogDebug(" mensaje " ,params);

3 _logger.LogInformation(" mensaje " ,params);

4 _logger.LogWarning(" mensaje " ,params);

5 _logger.LogError(exception, " mensaje " ,params) ;

6 _logger.LogCritical(exception, " mensaje " , params);

LadocumentaciónoficialrecomiendautilizarILogger<T>enlugar delaAPIestáticadeSerilogcuandosetrabajaenASP.NETCore, porquehaceelcódigomásestándaryportableentrediferentes proveedoresdelogging.Sinembargo,ambasAPIssonfuncionalmente equivalentescuandoSerilogestáconfiguradocomoproveedorde logging.Conesteantecedente,acontinuación,semuestranejemplos deusoparaambosescenarios,segúnniveldeverbosidad.

Verbose:DiagnósticoExhaustivo

ElnivelVerboseeselmásdetalladodetodosyestápensadopara situacionesdeanálisisprofundo,comotareasdetracingodepuración anivelinternodelaaplicación.Seutilizacuandoesnecesarioentender conprecisióncómoseestáejecutandoelcódigo,yaqueregistracada pasorelevantedelflujodeejecuciónylosvaloresintermediosdelas variables.Talcomoindicaladocumentaciónoficial,estenivelofrece unavisibilidadcompletadelcomportamientointernodelsistema, perodebeusarseconcauteladebidoalgranvolumendeinformación quegenera.

Ejemploconloggerestático:

1 Log.Verbose(" Validaci ón para UserId : { UserId }" ,userId);

2 Log.Verbose(" Regla { rId } evaluada : { Result }" , rId,result);

ConILogger<T>:

1 _logger.LogTrace(" Validaci ón para UserId : { UserId }" ,userId);

2 _logger.LogTrace(" Regla { rId } evaluada : { Result }" ,rId,result);

Debug:InformacióndeDesarrollo

ElnivelDebugseutilizapararegistrarinformaciónorientadaal desarrolloyaldiagnósticodeproblemas.Capturaeventosinternos delsistemaquenormalmentenosonvisiblesdesdeelexterior,pero queresultanútilesparaentendercómoseejecutóunaoperacióno porquéseprodujodeterminadocomportamiento.Estenivelpermite analizarelflujointernodelaaplicaciónsinllegaralniveldedetalle extremodelmodoVerbose.

Ejemploconloggerestático:

1 Log.Debug(" Usuario { UserId } autenticado . Roles : { Roles }" ,userId,string.Join(" , " ,roles) );

3 Log.Debug(" Query ejecutado en { ElapsedMs } ms " , elapsed.TotalMilliseconds);

ConILogger<T>:

1 _logger.LogDebug(" Usuario { UserId } autenticado . Roles : { Roles }" ,userId,string.Join(" , " , roles));

3 _logger.LogDebug(" Query ejecutado en { ElapsedMs } ms " ,elapsed.TotalMilliseconds);

Information:EventosdeNegocioNormales

ElnivelInformationseutilizapararegistrarloseventoshabituales delsistema,aquellosquereflejanelfuncionamientonormaldela aplicaciónyelcumplimientodesusresponsabilidadesdenegocio. Incluyeaccionesesperadascomoelinicioofinalizacióndeprocesos,

operacionescompletadasconéxitooflujosdetrabajoestándar. Estesueleserelnivelmínimopredeterminadocuandonosedefine unaconfiguraciónexplícita,yaqueofreceunbuenequilibrioentre visibilidadyvolumendeinformación.

Ejemploconloggerestático:

1 Log.Information(" Orden { OrderId } creada por usuario { UserId }. Monto : { Amount :C}" , orderId,userId,amount);

3 Log.Information(" Pago procesado . TransactionId : { TransactionId }, Status : { Status }" , transactionId,status);

ConILogger<T>:

1 _logger.LogInformation(" Orden { OrderId } creada por usuario { UserId }. Monto : { Amount :C}" , orderId,userId,amount);

3 _logger.LogInformation(" Pago procesado . TransactionId : { TransactionId }, Status : { Status }" ,transactionId,status);

Warning:DegradaciónoSituacionesAnómalas

ElnivelWarningseutilizaparaseñalarcondicionesquenoson críticas,peroqueindicanqueelsistemanoestáfuncionandode formaideal.Reflejasituacionesanómalas,comportamientosfuerade losparámetrosesperadosoestadosdedegradaciónque,aunqueno detienenelservicio,requierenatenciónparaevitarqueevolucionen enproblemasmásgraves.

Ejemploconloggerestático:

1 Log.Warning(" Intento de acceso a recurso { ResourceId } denegado para usuario { UserId }" ,resourceId,userId); 2

3 Log.Warning(" API externa { ApiName } respondi ó {

StatusCode }. Reintentando " ,apiName, statusCode);

1 _logger.LogWarning(" Intento de acceso a recurso { ResourceId } denegado para usuario { UserId }" ,resourceId,userId);

3 _logger.LogWarning(" API externa { ApiName } respondi ó { StatusCode }. Reintentando " , apiName,statusCode);

Error:FallosdeFuncionalidad

ElnivelErrorseempleacuandounaoperaciónofuncionalidad noseejecutacomoseesperabayelresultadonopuedeconsiderarse correcto.Aunquelaaplicaciónpuedeseguirfuncionando,elevento registradoindicaclaramentequealgofallóenesecontextoespecífico, proporcionandoinformaciónclaveparaelanálisisylacorreccióndel problema.

Log.Error(ex, " Fall ó procesamiento de pago para orden { OrderId }. Gateway : { Gateway }" ,

_logger.LogError(ex, " Fall ó procesamiento de pago para orden { OrderId }. Gateway : { Gateway }" ,

Fatal:ErroresCatastróficos

ElnivelFatalrepresentalasfallasmásgravesquepuedeexperimentarunsistema.Seutilizacuandoocurreunerrorcríticoque provoca,oestáapuntodeprovocar,laterminacióndelaaplicación. EnelcontextodeILogger<T>,estenivelsedenominaCriticaly sueleindicarcondicionesquerequierenintervencióninmediata,ya quecomprometenporcompletolacontinuidaddelservicio. Ejemploconloggerestático:

_logger.LogCritical(ex, " Fall ó inicializaci ón de { DependencyName }. Aplicaci ón no puede continuar " ,

dependencyName);

throw;

}

LoggingEstructuradoconMessageTemplates

Serilogutilizamessagetemplatespararegistrarinformaciónde formaestructuradaynosolocomotextoplano.Enestostemplates, losnombresdelaspropiedadesseescribenentrellavesylosvalores realessepasancomoparámetrosadicionalesalmétododelogging. Deestamanera,elmensajesiguesiendolegibleparalaspersonas, peroalmismotiempolosdatosquedancapturadoscomocampos independientes,loquefacilitasuposteriorbúsqueda,filtradoyanálisis ensistemasdealmacenamientoymonitoreodelogs.

Correcto-Loggingestructurado:

1 Log.Information(" Usuario { UserId } modific ó configuraci ón. Cambios : { @Changes }" ,

2 userId,changesObject);

Incorrecto-Concatenacióndestrings:

1 Log.Information(" Usuario " +userId+ " modific ó configuraci ón");

Elprefijo@en{@Changes}indicadestructuracióndelobjeto, capturandosuspropiedadesenlugardesoloinvocarToString(). Estopermitequeriessobrepropiedadesindividualesensistemasde agregacióndelogs.

7.2.9 EjemplodeUsodeSerilogenunproyecto.NETCore

Seiniciadefiniendolaarquitecturadelproyecto,paraellosirve deapoyolaFigura 5,dondeserepresentalaintegracióndeSerilog dentrodeunaaplicaciónASP.NETCore,mostrandoelflujocompleto degeneración,procesamientoyalmacenamientodeloslogs.

EnelextremoizquierdoseencuentralaaplicaciónASP.NET Core,específicamentesuscomponentesprincipales:controladoresy middleware.Estossonlospuntosdondesegeneranloseventosde logging,yaseadeformaexplícita(mediantellamadasaILogger)o implícita(comoenelcasodelmiddlewarederegistrodesolicitudes HTTP).

EstoseventossondirigidoshacialaconfiguracióncentraldeSerilog, lacualsecargadesdeelarchivoappsettings.json.Estaconfiguración defineelcomportamientodelsistemadelogging,incluyendoniveles deseveridad,destinosdesalidayreglasespecíficasparadistintos componentes.Esteenfoquepermitemodificarelcomportamientosin necesidadderecompilarlaaplicación.

Figura5:

Arquitecturadeunaaplicación.NetCoreusandoSerilog

Nota:ElaboraciónPropia

Apartirdeestaconfiguración,seinstanciaelnúcleodelsistema:el loggerdeSerilog.Enestaetapaseaplicanlosdenominadosenrichers, queañadeninformacióncontextualacadaeventodelog,como

elnombredelamáquina,elidentificadordelhilodeejecucióno datosadicionalesdelcontextodelaaplicación.Esteenriquecimiento transformaloslogseninformaciónestructuradayaltamenteútilpara análisisposteriores.

Finalmente,loseventosprocesadossondistribuidoshaciamúltiples destinosdesalida,conocidoscomosinks.Enlafigurasedestacan tresprincipales:

✓ Laconsola,utilizadaprincipalmenteenentornosdedesarrolloo monitoreoentiemporeal.

✓ Archivosdelog,conrotaciónautomática,quepermitenpersistencialocalytrazabilidadhistórica.

✓ Sistemasexternos,comobasesdedatosoplataformasdeobservabilidad(porejemplo,SeqoKibana),quefacilitananálisisavanzado, visualizaciónycentralizacióndelogs.

Esteflujoevidenciaunaarquitecturadesacoplada,dondela generacióndeeventos,suprocesamientoysualmacenamientoestán claramenteseparados,permitiendoescalabilidad,mantenibilidad yflexibilidadenlagestióndelregistrodeeventosdentrodela aplicación1,

Adicionalmente,elflujodeprocesamientodeeventosenSerilog, talcomoseilustraenlaFigura 6,respondeaunmodelosecuencialy declarativoenelquecadaetapacumpleunafunciónespecíficadentro delciclodevidadellog.

Elpuntodeentradadelpipelineestáconstituidoporlaaplicación, dondesegeneranloseventosmedianteinvocacionesamecanismos delogging,típicamenteatravésdelaabstracciónILogger.Cada invocaciónproduceuneventoquecontieneunmensaje,unnivelde severidady,opcionalmente,datosestructuradosasociados.

Unavezgenerado,eleventoesdirigidohaciaelsistemadeconfiguración,elcualhasidopreviamentedefinidoenelarchivoappsettings.jsonycargadomedianteelmétodoReadFrom.Configuration(). Estaetapanotransformaeleventoensí,sinoqueestablecelasreglas

quegobernaránsuprocesamientoalolargodelpipeline.

Figura6: PipelinedeflujodeSerilog

Nota:ElaboraciónPropia

ElprimerfiltroaplicadocorrespondealbloqueMinimumLevel. Enestafase,elsistemaevalúalaseveridaddeleventoydeterminasi debecontinuarsuprocesamientooserdescartado.Estemecanismo permitecontrolarlacantidaddeinformaciónregistrada,evitandola sobrecargadelogsconeventosirrelevantesypriorizandoaquellosde mayorimportanciaoperativa.

Superadoelfiltrodenivel,eleventoingresaalaetapade enriquecimiento(Enrichers).Aquíseincorporandatoscontextuales adicionalesquenoestabanpresentesenelmomentodelageneración delevento.Estospuedenincluirinformacióndelentornodeejecución, comoelnombredelamáquina,elidentificadordelhiloopropiedades delcontextodelasolicitud.Elresultadoesuneventomáscompleto, conmayorvalorsemánticoparaanálisisposteriores.

Finalmente,eleventoenriquecidoesdistribuidohaciaunoovarios destinosdesalida,definidosenlasecciónWriteTodelarchivode configuración.Estosdestinos,conocidoscomosinks,representanlos

puntosfinalesdelpipeline.Enelescenariomostrado,seincluyenla consolayarchivosconrotaciónautomática.Cadasinkrecibeelevento deformaindependiente,permitiendomúltiplesformasdepersistencia ovisualizaciónsininterferenciaentreellas.

Estepipelineevidenciaundiseñobasadoenresponsabilidades claramenteseparadas:generación,filtrado,enriquecimientoypersistencia.Laconfiguraciónexternamedianteappsettings.jsonpermite modificarelcomportamientodecadaetapasinalterarelcódigo fuente,consolidandounenfoqueflexibleyalineadoconlasmejores prácticasdeobservabilidadenaplicacionesmodernas.

Laimplementaciónsefundamentaentreselementosesenciales: lainclusióndedependencias,laconfiguracióndeclarativamediante archivoexternoylaintegraciónenelciclodevidadelaaplicación.

VerFigura 7.

Figura7: ComponentesfundamentalesparalaimplementacióndeSerilogen aplicaciones.NET

Enprimerlugar,seincorporanlasdependenciasnecesariasen elarchivodeproyecto.Estasincluyenelpaqueteprincipalde integraciónconASP.NETCore,asícomoextensionesquepermiten leerconfiguracionesdesdearchivosJSONydefinirdestinosdesalida, talescomolaconsolayarchivospersistentes.Esteenfoquemodular permiteextenderfácilmenteelsistemadeloggingsinalterarlalógica denegocio.

Lossiguientessonloscomandosparaincluirlasdependencias:

1 dotnetaddpackageSerilog.AspNetCore-version8.0.0

2 dotnetaddpackageSerilog.Settings. Configuration--version8.0.0

3 dotnetaddpackageSerilog.Sinks.Console-version5.0.1

4 dotnetaddpackageSerilog.Sinks.File-version5.0.0

Acontinuación,seestablecelaconfiguraciónenelarchivoappsettings.json.Estemecanismodesacoplaladefinicióndelcomportamientodelsistemaderegistrodelcódigofuente,favoreciendo lamantenibilidadylaadaptabilidadadistintosentornos.Enesta configuraciónsedefinenaspectosclavecomoelnivelmínimode registro,quedeterminalaseveridaddeloseventosacapturar,así comoreglasespecíficasparareducirlaverbosidaddecomponentes internosdelframework.Asimismo,seespecificanlosdestinosdesalida mediantelasecciónWriteTo,dondeseconfiguratantolaemisión deeventosalaconsolacomosupersistenciaenarchivosrotativos diarios.Elusodeplantillasdesalidapermiteestandarizarelformato delosregistros,facilitandosuposterioranálisis.

Elsiguienteeselcontenidomínimodelarchivoappsetting.json:

Posteriormente,laintegraciónserealizaenelpuntodeentrada delaaplicación,específicamenteenelarchivoProgram.cs.Allíse construyeunainstanciadelloggerapartirdelaconfiguraciónpreviamentedefinida,asegurandoquetodaslascaracterísticasestablecidas enelarchivoJSONseanrespetadas.Estainstanciaseregistraenel hostdelaaplicación,reemplazandoelsistemadeloggingpordefecto. Deestemodo,cualquiercomponentequedependadelaabstracción deloggingproporcionadaporelframeworkutilizaráautomáticamente Serilogcomoproveedorsubyacente.

Adicionalmente,seincorporaunmiddlewareespecializadoque permiteregistrarautomáticamentelassolicitudesHTTPentrantes. Estafuncionalidadresultaespecialmenteútilparaelmonitoreodel

interaccióncliente-servidor.

Finalmente,enloscontroladoresdelaaplicación,seempleala interfazdelogginginyectadapordependenciapararegistrareventos deinterés.Enelejemplopresentado,seilustratantoelregistrode informacióngeneralcomolacapturadeerroresmediantebloques demanejodeexcepciones.Esteenfoquegarantizaqueloseventos relevantesquedendocumentadosconsuficientecontexto,locuales esencialparatareasdedepuraciónyauditoría.

ElsiguienteeselcontenidodelarchivodelcontroladorTestController.cs:

privatereadonlyILogger<TestController> _logger;

TestController>logger)

_logger.LogInformation(" Endpoint GET ejecutado Ok ");

_logger.LogError(ex, " Ocurri ó un error de prueba ");

Ok(" Revisa consola y archivo de logs ");

Finalmente,sedebeentenderquelaimplementacióndeunsistema deregistroestructuradomedianteSerilogenaplicacionesASP.NET Corerepresentaunpasodecisivohacialaconstruccióndesoluciones observables,manteniblesypreparadasparaentornosproductivos. Alolargodeestecapítulosehaevidenciadocómo,atravésde unaadecuadaincorporacióndedependencias,unaconfiguración

declarativacentralizadayunaintegracióncoherenteenelciclode vidadelaaplicación,esposibleestablecerunmecanismodelogging robustosinintroducircomplejidadinnecesariaenelcódigo.

Elenfoqueadoptadopermitenosolocapturareventos,sino enriquecerlosydirigirlosdemaneraflexiblehaciamúltiplesdestinos, facilitandosuanálisisyexplotación.Estacapacidaddeadaptación, sustentadaenlaconfiguraciónexterna,garantizaqueelsistema puedaevolucionarconformecambianlosrequerimientosoperativos, sinafectarlaestabilidaddelaaplicación.

Deestamanera,elregistrodeeventosdejadeserunelemento accesorioparaconvertirseenuncomponenteestratégicodentrodela arquitecturadelsoftware,habilitandoprácticascomolatrazabilidad, laauditoríayelmonitoreocontinuo.Lacorrectaimplementaciónde estascapacidadessientalasbasesparanivelessuperioresdemadurez, dondelaobservabilidadseintegradeformanaturaleneldiseñoy operacióndelossistemas.

Capítulo8 CONCLUSIONES

Alolargodeestelibro,sehaexploradoelconceptodesoftware auditabledesdemúltiplesperspectivas,teórica,técnica,regulatoria ypráctica.Sehavistocómolaauditabilidadnoesmeramente unacaracterísticatécnicaquepuedeserañadidasuperficialmentea sistemasexistentes,sinounapropiedadfundamentalquedebeser consideradadesdelasprimerasetapasdediseñoarquitectónicoy mantenidadisciplinadamenteatravésdetodoelciclodevidadel software.

Losfundamentosteóricosestablecenqueelsoftwareverdaderamenteauditablerequierearquitecturaencapasquesepararesponsabilidadesdecapturadeeventos,enriquecimientodecontexto, almacenamientoinmutable,proteccióncriptográfica,yanálisisforense. Elprincipiode“separationofduty”aplicadoaauditoríadictaquelos sistemassiendoauditadosnodebentenercontrolsobresuspropios registrosdeauditoría,requiriendocomponentesindependientesque actúancomoregistradoresconfiables.

Laimplementaciónefectivadeauditabilidadrequiereunenfoque sistemáticoqueabarquemúltiplesdimensiones:arquitecturade sistemasquefacilitelacapturadeeventosrelevantesmediante patronescomointerceptoresyeventsourcing,almacenamientoseguro einmutablederegistrosutilizandobasesdedatosappend-onlyy estructurasdedatosprotegidascriptográficamente,mecanismosde protecciónquegaranticenintegridadynorepudiomediantefirmas digitalesytimestamping,capacidadesdeanálisisyconsultaque permitaninvestigacionesforensesydeteccióndeanomalías,ypolíticas deretenciónyarchivadoquesatisfaganrequisitosregulatorios.

Losmarcosregulatorios:GDPR,HIPAA,SOX,PCI-DSS,establecenrequisitoslegalmentevinculantesparaauditoríaydemostraciónde cumplimiento.Organizacionesqueoperanenmúltiplesjurisdicciones osectoresdebencumplirobligacionessuperpuestasyocasionalmente conflictivas.Sinembargo,estosmarcostambiénproporcionanuna guíavaliosasobreloqueconstituyeauditoríaefectiva.

Loscasosdeusoverticalesilustrancómorequisitosdeauditoríase manifiestanencontextosespecíficos.Elsectorfinancierorequiere

ordenderegistrosdeauditoríaconprecisióndemicrosegundos. Healthcarerequierecapacidadderastrearcadaaccesoainformación sensibledepacientes.LafacturaciónelectrónicaenEcuadorrequiere firmadigitalconXAdES-BESytrazabilidadcompletadelciclode vidadecomprobantes.Cadadominiotienematicesúnicosquedeben sercomprendidosyabordados.

Mirandohaciaelfuturo,variosinvolucradosestánmoldeando laevolucióndesoftwareauditable.Laproliferacióndesistemasde inteligenciaartificialpresentadesafíosúnicosparalaauditabilidad debidoalaopacidaddemodelosdemachinelearning.Laadopción crecientedearquitecturasdemicroserviciosyserverlessaumentala complejidaddemantenertrazabilidadend-to-end.Lasregulaciones emergentescomoelAIActeuropeoestánexpandiendoelalcancede requisitosdeauditabilidadmásalládedominiostradicionales.

Elmensajefundamentalesqueenunmundodondeelsoftware persistecrecientementeentodaactividadhumanaorganizada,la capacidaddeauditaryverificarelcomportamientodesoftware noeslujosinonecesidad.Elsoftwarequenopuedeserauditado efectivamentenopuedeserconfiadoparaoperarencontextoscríticos. Comodesarrolladores,arquitectosylíderestecnológicos,setienela responsabilidadprofesionalyéticadeconstruirsistemasqueseanno solofuncionalesyeficientes,sinotambiéntransparentes,trazablesy auditables.

Elsoftwareauditablehaevolucionadodeserunaconsideración secundariaeneldesarrollodesistemasaconstituirunrequisitofundamentaleneldiseñodeaplicacionesmodernas.Estaevoluciónrefleja lacrecientemadurezdelaindustriadelsoftwareyelreconocimiento dequelatransparenciaylarendicióndecuentassonaspectostan críticoscomolafuncionalidadyelrendimiento.

LosmarcosregulatorioscomoGDPRyHIPAAhanelevado significativamenteelniveldeexigencia,requiriendonosolola implementacióndecontrolesdeauditoríasinolacapacidaddedemostrarcumplimientodemaneraproactiva.Estatendenciaregulatoria probablementeseintensificará,particularmenteconlaemergenciade

regulaciónespecíficaparasistemasdeinteligenciaartificial.

Enelcontextodelecosistema.NET,herramientascomoSerilog paraloggingestructurado,lascapacidadesdeauditoríanativasde SQLServeryEntityFrameworkCore,ylosframeworksdeASP.NET Coreproporcionanunabasetécnicasólidaparaimplementarsoftware auditable.Sinembargo,latecnologíaporsísolaesinsuficiente;se requiereunacomprensiónprofundadelosprincipiossubyacentesy uncompromisoorganizacionalconlatransparencia.

Bibliografía

Adams,C.,Cain,P.,Pinkas,D.,&Zuccherato,R.(2001). Internet X.509PublicKeyInfrastructureTime-StampProtocol(TSP) (inf.téc.N.o RFC3161).IETF. https://doi.org/10.17487/RFC3161

ApacheSoftwareFoundation.(n.d.). KafkaLogImplementation. https://kafka.apache.org/39/implementation/log/

AsambleaNacionaldelEcuador.(n.d.).CódigoOrgánicoMonetario yFinanciero,LibroI[Ecuador].

AssociationofCertifiedFraudExaminers.(2024). Occupational Fraud2024:AReporttotheNations. https://www.acfe.com/report-to-the-nations/2024/ Audittrail.(n.d.).Wikipedia.

https://en.wikipedia.org/wiki/Audit_trail

BankforInternationalSettlements.(2025). GlobalFXtradinghits 9.6trillionperdayinApril2025andOTCinterestratederivatives surgeto7.9trillion:TriennialSurvey. https://www.bis.org/press/p250930.htm

Bondarenko,P.(2026).Enronscandal. https://www.britannica.com/event/Enron-scandal

CarrilloMañay,V.,ManceroMosquera,H.,&ManceroRivera,D.S. (2019).Análisisdelacrisisbancariaprivadaecuatoriana(1994-2000) ysusefectossocioeconómicos. CofinHabana. http://scielo.sld.cu/sci elo.php?script=sci_arttext&pid=S2073-60612019000300017

ContraloríaGeneraldelEstado.(2017).ContraloríaGeneraldel Estado.

https://www.contraloria.gob.ec/CentralMedios/PrensaDia/15946

ContraloríaGeneraldelEstado.(2020).ContraloríaGeneraldel Estado.

https://www.contraloria.gob.ec/CentralMedios/SalaPrensa/23824

ContraloríaGeneraldelEstado.(n.d.).NormasdeControlInterno [Estado:Vigente]. https://www.lexis.com.ec

DataSunrise.(2025).¿Paraquéseutilizalaauditoríadedatos? Aspectosesencialesdeseguridad.

https://www.datasunrise.com/es/informacion-profesional/para-qu e-se-utiliza-la-auditoria-de-datos/?utm_source=chatgpt.com deDerechosyJusticia,O.(s.f.).CORRUPCIÓNENTIEMPOSDE COVID:LAOTRAPANDEMIAENECUADOR. http://sacc.corteconstitucional.gob.ec/storage/api/v1/10 _DWL_FL/e2NhcnBldGE6J3RyYW1pdGUnLCB1dWlkOidlM

Dijkstra,E.W.(s.f.). TheHumbleProgrammer(EWD340). https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx /EWD340.html

EFE.(2025).Odebrecht,unalargalistadepaísesypolíticos latinoamercanosrelacionadosconsobornos. https://www.swissinfo.c h/spa/odebrecht,-una-larga-lista-de-pa%C3%ADses-y-pol%C3 %ADticos-latinoamercanos-relacionados-con-sobornos/89173496

Elmasri,R.,&Navathe,S.B.(2004). FundamentalsofDatabase Systems (4.a ed.).Addison-Wesley.

Erazo,V.(2022). 23añosdelferiadobancarioenEcuador.Wambra MedioComunitario. https://wambra.ec/23-anos-feriado-bancario-ecuador/

EuropeanUnion.(2016a).Reglamento(UE)2016/679del ParlamentoEuropeoydelConsejo(GDPR). https://eur-lex.europa.eu/legal-content/ES/ALL/?uri=uriserv: OJ.L_.2016.119.01.0001.01.SPA

EuropeanUnion.(2016b).Reglamento(UE)2016/679del ParlamentoEuropeoydelConsejo(GDPR). https://eur-lex.europa .eu/legal-content/ES/TXT/?uri=CELEX:32016R0679 Fantl,J.(n.d.).120922JustinFantlWorkingWorldGS3663834.

Galero,C.G.(2024).El’casoOdebrecht’,unahidradela corrupciónenAméricaLatina. https://www.publico.es/internaciona l/caso-odebrecht-hidra-corrupcion-america-latina.html

Gotel,O.C.Z.,&Finkelstein,A.C.W.(1994).AnAnalysisofthe RequirementsTraceabilityProblem. ProceedingsoftheFirst InternationalConferenceonRequirementsEngineering,94-101. Grokipedia.(2026).Transactionlog.

https://grokipedia.com/page/Transaction_log

Guerrero,C.L.(2019).InvestigandoLavaJato:elmayorescándalo decorrupciónunióalosperiodistasenAméricaLatina.

https://gijn.org/es/articulos/investigando-lava-jato-el-mayor-esca ndalo-de-corrupcion-unio-a-los-periodistas-en-america-latina/

Haber,S.,&Stornetta,W.S.(1991).HowtoTime-StampaDigital Document. JournalofCryptology, 3(2),99-111. https://doi.org/10.1007/BF00196791

IBM.(n.d.). Db2forLinux,UNIXandWindowsDocumentation. https://www.ibm.com/docs/en/db2/11.5.x

InstituteofElectricalandElectronicsEngineers.(1997).IEEEStd 1028-1997-IEEEStandardforSoftwareReviews.

https://ieeexplore.ieee.org/document/663254

InstituteofElectricalandElectronicsEngineers.(2008).IEEEStd 1028-2008-IEEEStandardforSoftwareReviewsandAudits. https://standards.ieee.org/ieee/1028/4402/

InternationalOrganizationforStandardization.(2011). ISO/IEC 25010:2011-Systemsandsoftwareengineering—Systemsand softwareQualityRequirementsandEvaluation(SQuaRE)—System andsoftwarequalitymodels. https://www.iso.org/standard/35733.html

InternationalOrganizationforStandardization.(2013).ISO/IEC 27001:2013Informationtechnology—Securitytechniques—

Informationsecuritymanagementsystems—Requirements. https://www.iso.org/obp/ui/#iso:std:iso-iec:27001:ed-2:v1:en

ISACA.(n.d.). COBIT:ControlObjectivesforInformationand RelatedTechnologies. https://www.isaca.org/resources/cobit

Kent,K.,&Souppaya,M.(2006). GuidetoComputerSecurityLog Management:RecommendationsoftheNationalInstituteof StandardsandTechnology (inf.téc.N.o NISTSpecialPublication 800-92).NationalInstituteofStandardsyTechnology. https://nvlp ubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-92.pdf

Krasner,H.(2022).CostofPoorSoftwareQualityintheU.S.:A 2022Report. https://www.it-cisq.org/the-cost-of-poor-quality-soft ware-in-the-us-a-2022-report/

Lamport,L.(1978).Time,Clocks,andtheOrderingofEventsina DistributedSystem. CommunicationsoftheACM, 21,558-565. https://doi.org/10.1145/359545.359563

LevinCenterforOversightandDemocracy.(n.d.).Congressandthe EnronScandal.Consultadoel31demarzode2026,desde https://levin-center.org/what-is-oversight/portraits/congress-andthe-enron-scandal/

LeyOrgánicadeEmpresasPúblicas[Ecuador,16deoctubrede 2009].(2009).

MacKenzie,D.A.(2001). MechanizingProof:Computing,Risk,and Trust.

McCarroll,G.D.,&Rowley,B.A.(1979).AnInvestigationofthe ExistenceofElectricallyLocatedAcupuncturePoints. IEEE TransactionsonBiomedicalEngineering, BME-26(3),177-181. https://doi.org/10.1109/TBME.1979.326392

McClure,R.M.(2001).NATOSoftwareEngineeringConference 1968.

Menezes,A.J.,vanOorschot,P.C.,&Vanstone,S.A.(1996). HandbookofAppliedCryptography.CRCPress.

Merkle,R.C.(1979). MethodofProvidingDigitalSignatures [US Patent].

Microsoft.(2025a). OverviewofASP.NETCore. https://learn.micro soft.com/en-us/aspnet/core/overview?view=aspnetcore-10.0

Microsoft.(2025b). TemporalTables-SQLServer. https://learn.microsoft.com/en-us/sql/relational-databases/tables /temporal-tables?view=sql-server-ver17

Mohan,C.,Haderle,D.,Lindsay,B.,Pirahesh,H.,&Schwarz,P. (1992).ARIES:ATransactionRecoveryMethodSupporting Fine-GranularityLockingandPartialRollbacksUsingWrite-Ahead Logging. ACMTransactionsonDatabaseSystems(TODS), 17, 94-162.

https://doi.org/10.1145/128765.128770;WGROUP:STRING:ACM

NationalInstituteofStandardsandTechnology.(2024). ElMarcode SeguridadCibernética(CSF)2.0delNIST (inf.téc.).U.S. DepartmentofCommerce.

https://doi.org/10.6028/NIST.CSWP.29.spa

O’Neil,P.,Cheng,E.,Gawlick,D.,&O’Neil,E.(1996).The Log-StructuredMerge-Tree(LSM-Tree). ActaInformatica, 33(4), 351-385. https://doi.org/10.1007/s002360050048

Palmer,G.(2001).ARoadMapforDigitalForensicResearch [DigitalForensicResearchConference]. ProceedingsoftheDigital ForensicResearchWorkshop(DFRWS).

PCISecurityStandardsCouncil.(2022).PaymentCardIndustry DataSecurityStandard(PCIDSS)[Version4.0]. https://www.pcisecuritystandards.org/document_library

Perdomo,D.Z.,&Mogollón,M.J.(2019).Filanbanco-Hermanos Isaías. https://www.observatorioanticorrupcion.ec/casos-de-corrupci on/filanbanco-hermanos-isaias

RegistroOficial.(2008).ConstitucióndelaRepúblicadelEcuador. https://esacc.corteconstitucional.gob.ec/storage/api/v1/10

_DWL_FL/e2NhcnBldGE6ICJub3RhaXAyMDIzIiwgdXVpZDoi ODJiZWZiNjctZmUxNC00MDRmLTgzMmItYjFjM2RjM2Fi ODA5LnBkZiJ9

RegistroOficial.(2021).LeyOrgánicadeProteccióndeDatos Personales[Ecuador].

RegistroOficial.(2023).ReglamentoalaLeyOrgánicade ProteccióndeDatosPersonales[DecretoEjecutivoNo.904, Ecuador]. https://www.telecomunicaciones.gob.ec/wp-content/uplo ads/2023/11/Decreto-Ejecutivo-No.-904.pdf

Saltor,C.E.(2013). Laproteccióndedatospersonales:estudio comparativoEuropa-Américaconespecialanálisisdelasituación argentina [Tesisdoctoral].UniversidadComplutensedeMadrid. https://eprints.ucm.es/22832/1/T34731.pdf

Sarbanes-OxleyAct.(n.d.).Sarbanes-OxleyComplianceProfessionals Association(SOXCPA). https://www.sarbanes-oxley-act.com/

Schneier,B.,&Kelsey,J.(1998).CryptographicSupportforSecure LogsonUntrustedMachines. Proceedingsofthe7thUSENIX SecuritySymposium. https://www.usenix.org/legacy/publications/li brary/proceedings/sec98/full_papers/schneier/schneier.pdf

Schneier,B.,&Kelsey,J.(1999).SecureAuditLogstoSupport ComputerForensics. Proceedingsofthe1999USENIXWorkshopon IntrusionDetectionandNetworkMonitoring.

SerilogContributors.(n.d.). SerilogWiki. https://github.com/serilog/serilog/wiki

Telégrafo,E.(2014).Lacrisisbancariade1999costóalpaís6.170 millones. https://www.eltelegrafo.com.ec/noticias/informacion/1/lacrisis-bancaria-de-1999-costo-al-pais-6-170-millones

Tunggal,A.T.,&Ruan,C.(2026).WhatisSOXCompliance?2026 Requirements,ControlsandMore|UpGuard.

https://www.upguard.com/blog/sox-compliance

U.S.DepartmentofHealthandHumanServices.(n.d.-a).45CFR§ 164.312-TechnicalSafeguards.

https://www.law.cornell.edu/cfr/text/45/164.312

U.S.DepartmentofHealthandHumanServices.(n.d.-b).45CFR§ 164.312-TechnicalSafeguards. https://www.ecfr.gov/current/title45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312

U.S.DepartmentofHealthandHumanServices.(n.d.-c). Summary oftheHIPAASecurityRule. https://www.hhs.gov/hipaa/for-profes sionals/security/laws-regulations/index.html

VeritasChain.(n.d.). BuildingaTamper-EvidentAuditLogwith SHA-256HashChains(ZeroDependencies).DEVCommunity. https://dev.to/veritaschain/building-a-tamper-evident-audit-logwith-sha-256-hash-chains-zero-dependencies-h0b

yPeriodismodeInvestigación,R.G.(2021).Covid-19:Ecuador asignómásdeUS664millonesparalapandemiayseinvestigan160 casosdepresuntacorrupción.

https://convoca.pe/investigacion/covid-19-ecuador-asigno-mas-deus-664-millones-para-la-pandemia-y-se-investigan-160