Create a Security audit handler

[pmlopes]

Given the current focus of the industry on security, We should create a new simple handler that allows auditing of security events as documented by OWASP:

• https://owasp.org/www-project-security-logging/
• https://owasp.org/www-project-security-logging/migrated_content

The code handler should create a formatted logging string, inspired by:

• http://audit.qos.ch/
• https://logging.apache.org/log4j-audit/latest/

Yet not relying on a specific logger.

The handler should be as simple as the LoggerHandler:

https://github.com/vert-x3/vertx-web/blob/master/vertx-web/src/main/java/io/vertx/ext/web/handler/LoggerHandler.java

Users interested in non-repudiation should add a logger of their choice to the end application and ensure that the logs from the new handler and the existing handler to ship the log entries to a secure remote.

For example, using the logback server, log4j backends, etc...

This design choice gives the user full control (the core pillar of vert.x) and avoids any extra dependencies to be added to the project.

Ideas of items to log:

• user Id
• timestamp
• resource
• verb
• client - source ip ?
• status - Success or Failure
• required scopes/permissions
• user scopes/permissions

Open questions

• Are we missing any important info?
• Can we reduce the fields?
• should we log user scopes? it could be a critical piece of info we should not leak?

[photomorre]

Considering the recommended security markers: log.info(SecurityMarkers.SECURITY_FAILURE, "Access control check just failed"); log.info(SecurityMarkers.SECURITY_AUDIT, "This must be saved in the audit log as well as the application log"); log.info(SecurityMarkers.SECRET, "This needs to be encrypted before it gets logged"); I feel that we are missing a specific tag for GDPR data - personal data and sensitive personal data: log.info(SecurityMarkers.GDPR_DATA, "One's name is logged"); log.info(SecurityMarkers.GDPR_SENSITIVE, "My sexual orientation or sickness history etc. are logged.");

[pmlopes]

After several discussions and planning the draft of this feature is:

1. In vertx-auth-common we shall have a AuditData type where we can only set data:
   • source IP
   • destination IP
   • http verb
   • request path
   • credentials
   • required authz
   • provided authz
   • user
   • status
2. In vertx web a new platform handler should initialize an instance of this object and define the encoding format
   • syslog
   • json
3. At specific handlers a .audit(eventType: String, success: boolean) shall be called so we get logs of:
   • authn success
   • authn failures
   • authz success
   • authz failures

An example of a request that covers both authn and authz could be seen as:

HTTP GET /api/foo

Logs:

[resource="HTTP/1.1 GET /api/foo" sourceIp="10.0.0.2" destIp="0.0.0.0" username="paulo" password="******"] authentication OK 
[resource="HTTP/1.1 GET /api/foo" sourceIp="10.0.0.2" destIp="0.0.0.0" subject="paulo" requiredAuthZ="READ" providedAuthZ="READ,WRITE"] authorization OK 
[resource="HTTP/1.1 GET /api/foo" sourceIp="10.0.0.2" destIp="0.0.0.0"] request OK

This solution can be used on all modules, however for performance/computing resources economy we could avoid the context and be only applicable to vertx-web

@photomorre what do you think?

The goal is that even though the AuditData can handle many information, the logging should only use what is available or relevant for the log marker. Currently AUTHN, AUTHZ and REQUEST will be provided.

[pmlopes]

A new iteration:

1. The audit event type should be a enum in order to avoid coding mistakes and define a explicit encoding format.
2. After reading on integrations with many SIEM/XDR tools, as these tools work in a internal network, it sounds very unlikely that this feature should be used from a client. Therefore, and to be more consistent with the vert.x model, we shall not use the vertx context but be explicit where we log. This means that we should add this functionality to: vertx-web, service-proxies, grpc-server and mqtt-server. But for the initial release only to vertx-web and maybe service-proxies.
3. There should not be a message string involved as this can introduce formatting problems like multiline, etc...
4. When the feature is disabled, it should have no performance impact, when enabled the formatting should be nimble