The signed audit service provides a one-stop framework for signing data i.e. creating an immutable data entry to track activities of an entity. Whenever an entity is created/updated/deleted the operation is captured in the data logs and is digitally signed to protect it from tampering.
Infra configuration -
Number of concurrent users - 15000
Duration of bombarding service with requests ~ 17 minutes
Number of signed audit pod(s) - 1
The objective of the audit service is listed below -
To provide a one-stop framework for signing data i.e. creating an immutable data entry to track activities of an entity. Whenever an entity is created/updated/deleted the operation is captured in the data logs and is digitally signed to protect it from tampering.
Prior knowledge of Java/J2EE
Prior knowledge of SpringBoot
Prior knowledge of PostgreSQL
Prior knowledge of REST APIs and related concepts like path parameters, headers, JSON etc.
The audit service will be parsing all the persister configs so that it can process data received by the persister and create audit logs out of it.
Step 1: Add the following metrics to the existing persister configs -
Step 2: If a custom implementation of ConfigurableSignAndVerify interface is present, provide the signing algorithm implementation name as a part of audit.log.signing.algorithm property. For example, if the signing algorithm is HMAC, the property will be set as follows -
Step 3: Set egov.persist.yml.repo.path this property to the location of persister configs.
Step 4: Run the audit-service application along with the persister service.
Definitions
Config file - A YAML (xyz.yml) file which contains persister configuration for running audit service.
API - A REST endpoint to post audit logs data.
When audit-service create API is hit, it will validate request size, keyValueMap and operationType.
Upon successful validation, it will choose the configured signer and sign entity data.
Once audit logs are signed and ready, it will send it to audit-create topic.
Persister will listen on this topic and persist the audit logs.
Add the required keys for enabling audit service in persister configs.
Deploy the latest version of the Audit service and Persister service.
Add Role-Action mapping for APIs.
The audit service is used to push signed data for tracking each and every create/modify/delete operation done on database entities.
Can be used to have tamper-proof audit logs for all database transactions.
Replaying events in chronological order will lead to the current state of the entity in the database.
To integrate, the host of the audit-service module should be overwritten in the helm chart.
audit-service/log/v1/_create should be added as the create endpoint for the config added.
audit-service/log/v1/_search should be added as the search endpoint for the config added.
1. URI: The format of the API to be used to create audit logs using the audit service is as follows: audit-service/log/v1/_create
Body: The body consists of 2 parts: RequestInfo and AuditLogs.
Sample Request Body -
2. URI: The format of the API to be used to search audit logs using audit-service is as follows: audit-service/log/v1/_search
Body: The body consists RequestInfo and search criteria is passed as query params.
Sample curl for search -
Postman Collection - Audit Service Postman Collection
Play around with the API's : DIGIT-Playground