G Audit

Functional Requirements|

The full platform we planned is about a sistem what develop an audit/loging platform to save ,erase, modify , check and compress, store some logs. GAudit or named also GLog serves as the centralized audit backbone of the G platform. By providing immutable, secure, and standardized logging for every integrated service, it enables organizations to maintain complete visibility into platform activity while supporting security, compliance, operational monitoring, and future ecosystem growth.

Designed as a cloud-native, API-first service, GLog integrates naturally with components such as GConnect, GNotify, GAuth, GSign, GFiles, and other platform services, creating a unified and trustworthy audit infrastructure for the entire ecosystem.

GLog – Centralized Audit & Logging Platform

Overview

GLog is the centralized audit and logging service of the G ecosystem. It provides secure, immutable, and standardized event logging across all connected applications, services, and infrastructure.

The platform acts as the system of record for operational events, user activities, administrative actions, security events, and data access across the entire ecosystem. Its primary objective is to ensure accountability, transparency, security, and compliance while providing a complete audit trail for every significant action performed within the platform.

Unlike traditional application logs, GLog is designed as a centralized, tamper-resistant audit platform that can be integrated into any service within the ecosystem.

Core Principles

Centralized Logging

All platform components send audit events to a single centralized logging service instead of storing critical audit information locally.

This creates:

A single source of truth
Consistent audit records
Easier monitoring
Simplified compliance
Cross-service event correlation

Immutable Audit Records

GLog follows Write Once, Read Many (WORM) principles.

Once an audit event has been accepted:

it cannot be modified;
it cannot be deleted;
historical integrity is preserved;
every event remains permanently traceable.

Even platform administrators cannot alter previously stored audit events.

Data Integrity

Every event receives a unique cryptographic hash.

Events may optionally be chained using cryptographic hashing, making unauthorized modifications immediately detectable.

This guarantees:

integrity of stored events;
protection against tampering;
reliable forensic investigations;
trustworthy audit history.

Security

Security is a fundamental design principle.

Features include:

encrypted communication;
authenticated API access;
signed requests (optional);
role-based access control;
immutable storage;
complete audit traceability.

Transparency

Every operation performed by users, administrators, services, or automated processes can be traced.

Authorized users can review the complete history of actions performed on specific resources, allowing organizations to maintain full operational visibility.

Audit & Compliance

GLog provides a reliable audit trail suitable for:

compliance requirements;
security investigations;
operational monitoring;
incident response;
regulatory reporting.

Functional requirements

Platform must have:

logs can be represented as a json object and it could be saved in db and in file storage.
logs will be stored in db like postgresql (relational one ) but also it should be stored in the file form in order to have it, easy export , import and soo one.
logs should be better to be save as some files like in compressed form maybe, it gonna be connected to the GStorage ( for dev sstage it will be a simple minio locally )
each workers will be responsable for writing into a specific file or maybe db based on the incoming producers
we are gonna have multiple queue in order tp get logs
one important thing will be the Searching for the logs, like it should give us the possibility to filter lgos from a SaaS/PaaS but also all the logs from the services and platforms what are corelated.
Search by specific key-words
filter by date time , warting messages, errors and soo one like any needed filter.
Connection to Gnotify of course in order to notify admins, specific clients and so one.
Also posibility to filter between date time like start date/time end date/time
performance metrics like warnings, eroors code , errors , ip what give this error o n specific service what was connecte everyuthing in a graph format ( ggraphs will be general one but in a pretty form )
CONNECTION between many SaaS and PaaS-es , gov organizations and soo one. everything could be get from gRegistry where we save the interconection between modules , SaaS. PaaS and soo one.
General search will provide the logs not only from the service itself, but also from any corelated ones like we have gregistry it is connected to GPass, Gnotify, GPay GLog, we should see the logs from all the platforms then we search in a general porpose, like we search a problem but we are not sure where it is and how to fgind it. the platform give the possibility to review all the stuff in some windows ( but it should be a specific page with corelated search ) like i seach why in gregistry i dont see the payment of some user, but maybe its admin and it should be visible into the logs of GPass/GSSO, maybe the payment was not processed cause is a poroblem into the Gpay platform , maybe GNotify just doesn’t send the actual notification.
So data about the interconnection is stored in GRegistry and there they would be modified soo we should have it , btw there is just a data about the PaaS and SaaS waht are interconnected.
Pages should be present, general one, search for the simple users like it’s described a bit later in this file, also a search between interconection, a search into some specific logs or platforms/services. some admin bord stuff for configuration and soo one just for the admin users like in pother gstack PaaS
menu should be in the right side of the app
tables should expand the row, each row should have tabs to view and editing stuff.
logs as i think will be same as some tables with main message what was stored and some stuff like also column about them, but the word search and sooo one should be based on the text what’s inside.

Platform Architecture

High-Level Architecture

+--------------------+
| Client Applications|
+---------+----------+
          |
          |
          v
      GConnect
          |
          |
+---------+----------+
|      API Gateway   |
+---------+----------+
          |
          |
          v
+--------------------+
|       GLog API     |
+--------------------+
          |
          |
          v
+--------------------+
| Validation Layer   |
+--------------------+
          |
          |
          v
+--------------------+
| Processing Queue   |
+--------------------+
          |
          |
          v
+--------------------+
| Immutable Storage  |
+--------------------+
          |
          |
          +----------------+
          |                |
          v                v
 Audit Search        Monitoring
      API             & Analytics

Logs storage / audit and soo one

Hybrid Architecture (Recommended)

The recommended architecture combines both approaches.

Application
      │
      ▼
 Message Queue
(Kafka / RabbitMQ)
      │
      ▼
     GLog
      │
      ├──────────────► PostgreSQL
      │               (Searchable Audit Store)
      │
      ├──────────────► Object Storage
      │               (Original JSON Archive)
      │
      └──────────────► Monitoring & Analytics

Event Processing Flow

An application generates an audit event.
The event is sent to GLog through a message queue or API.
GLog validates the event.
A cryptographic hash is generated.
The event is stored in PostgreSQL.
The original JSON payload is archived in object storage.
The event becomes searchable through the audit API.

This architecture provides:

Fast queries
Immutable archival
Disaster recovery
Long-term retention
High scalability

Recommended Database Design - ( it’s not the mandatory one just take into a count )

Rather than storing the entire event as a single JSON document, separate frequently queried fields into dedicated database columns.

Column	Type	Description
id	UUID	Event identifier
timestamp	TIMESTAMPTZ	Event timestamp
service	VARCHAR	Originating service
module	VARCHAR	Service module
operation	VARCHAR	Event type
actor_id	UUID	User or system identifier
actor_type	VARCHAR	USER, SYSTEM, SERVICE
tenant_id	UUID	Tenant identifier (optional)
resource_id	TEXT	Resource identifier
resource_type	VARCHAR	Resource category
ip	INET	Client IP address
session_id	UUID	Session identifier
status	VARCHAR	SUCCESS / FAILURE
metadata	JSONB	Additional event data
hash	TEXT	Event integrity hash
previous_hash	TEXT	Previous event hash (optional)
created_at	TIMESTAMPTZ	Storage timestamp

Instead of storing everything as one large JSON object:

{
    "service": "gnotify",
    "operation": "EMAIL_SENT",
    "user": "...",
    "metadata": {
        ...
    }
}

Store commonly queried values in dedicated columns:

service = "gnotify"

operation = "EMAIL_SENT"

timestamp = 2026-07-22

metadata = {
    "email": "john@example.com",
    "template": "welcome"
}

This allows the database to efficiently use indexes.

Example query:

SELECT *
FROM audit_logs
WHERE service = 'gnotify'
AND timestamp > NOW() - INTERVAL '24 HOURS';

Recommended Technologies

Database

PostgreSQL
JSONB support
B-Tree indexes
GIN indexes for metadata

Message Broker

Choose one of:

Apache Kafka
RabbitMQ
NATS
Azure Service Bus
AWS SQS

Used for asynchronous audit event processing.

Object Storage

Recommended options:

MinIO
Amazon S3
Azure Blob Storage
Google Cloud Storage

Object storage keeps the original immutable JSON events for archival and compliance purposes.

Search & Analytics (Optional)

For large-scale deployments:

OpenSearch
Elasticsearch

These systems provide:

Full-text search
Dashboards
Security analytics
Real-time monitoring
SIEM integration

Recommended Storage Strategy

Storage	Purpose
PostgreSQL	Primary searchable audit database
Object Storage	Immutable archive of original JSON events
Message Queue	Asynchronous event ingestion
OpenSearch (optional)	Fast analytics and full-text search

Final Recommendation

For a production-grade GLog platform, the recommended architecture is:

Applications
      │
      ▼
Message Queue
(Kafka / RabbitMQ)
      │
      ▼
     GLog
      │
      ├────────────► PostgreSQL
      │              Primary Audit Database
      │
      ├────────────► Object Storage
      │              Immutable JSON Archive
      │
      └────────────► OpenSearch (Optional)
                     Search, Dashboards & Analytics

This hybrid architecture provides:

Fast querying and reporting
Flexible JSON metadata
Immutable long-term storage
Horizontal scalability
Compliance and audit readiness
Reliable disaster recovery
Efficient monitoring and analytics

Integration with the G Ecosystem

GLog is designed to integrate seamlessly with every platform service.

Typical integrations include:

GConnect – interoperability and secure service communication
GAuth – authentication events
GNotify – notification delivery events
GSign – digital signature events
GPay – payment operations
GFiles – document operations
GIdentity – identity verification
Any custom business service

Every service can produce audit events using the same standardized API.

Event Flow

A typical event lifecycle consists of:

A user or system performs an action.
The application creates an audit event.
The event is sent asynchronously to GLog.
GLog validates the request.
Metadata is enriched.
A cryptographic hash is generated.
The event is stored in immutable storage.
The event becomes searchable through the audit API.

Applications continue operating even if audit processing occurs asynchronously, minimizing impact on user experience.

Event Structure

Every audit event should contain standardized metadata.

Example:

{
  "eventId": "UUID",
  "timestamp": "2026-07-22T12:30:00Z",
  "service": "gfiles",
  "module": "documents",
  "userId": "user-12345",
  "actorType": "USER",
  "operation": "DOCUMENT_UPDATED",
  "resourceId": "doc-56789",
  "ipAddress": "192.168.1.10",
  "sessionId": "session-xyz",
  "status": "SUCCESS",
  "metadata": {
    "documentType": "contract"
  }
}

Integration Process

Every application integrating with the platform follows a standardized process.

1. Service Registration

The service is registered within the ecosystem and receives authentication credentials.

2. Event Definition

Each application defines the events it will produce.

Examples:

User Login
User Logout
Password Changed
Record Created
Record Updated
Record Deleted
Document Viewed
Payment Processed
Notification Sent
API Access

3. API Integration

Developers integrate the GLog SDK or REST API.

Audit events are generated automatically or manually whenever important business operations occur.

4. Validation

Incoming events are validated for:

required fields;
schema compliance;
authentication;
timestamp validity;
event uniqueness.

5. Storage

Validated events are permanently stored in immutable storage.

API Design

Typical operations include:

Method	Endpoint	Purpose
POST	`/logs/events`	Submit audit events
GET	`/logs/events/{id}`	Retrieve event
GET	`/logs/search`	Search audit records
GET	`/logs/services`	List registered services
GET	`/logs/statistics`	Platform metrics

Event Categories

GLog supports logging across multiple domains.

Authentication

Login
Logout
MFA Verification
Failed Authentication

Authorization

Permission Granted
Permission Revoked
Role Changed

User Activity

Profile Updated
Resource Accessed
Settings Modified

Business Operations

Orders
Payments
Contracts
Requests
Workflow Events

System Events

Service Started
Service Stopped
Configuration Updated
Deployment Completed

Security Events

Access Denied
Suspicious Activity
Token Revoked
Privilege Escalation

Citizen & User Transparency

One of GLog’s key objectives is to provide transparency regarding data access and system activity.

Authorized users should be able to:

review who accessed their information;
see when access occurred;
understand what action was performed;
identify which service initiated the action;
verify whether the access was authorized.

This promotes trust, accountability, and responsible use of sensitive information.

Monitoring & Analytics

In addition to audit storage, GLog enables:

real-time dashboards;
operational monitoring;
anomaly detection;
security alerts;
usage statistics;
service health metrics;
audit reporting.

These capabilities support both operational teams and security personnel.

Scalability

The platform is designed for high-volume environments and supports:

horizontal scaling;
asynchronous processing;
distributed storage;
message queues;
high availability;
fault tolerance.

This architecture allows millions of events to be processed daily without impacting application performance.

Design Goals

The GLog platform is built around several core objectives:

Centralized audit management
Immutable event storage
Strong security and integrity
Standardized event model
Seamless ecosystem integration
High scalability
Transparency and accountability
Reliable compliance support
Efficient monitoring and analytics