Admin (portal user) Audit Logs and Activities

[Ali-Razmjoo]

⚠️ Please verify that this feature request has NOT been suggested before.

• I checked and didn't find similar feature request

🏷️ Feature Request Type

UI Feature, Other

🔖 Feature description

Hi,

Uptime Kuma does not currently support logs & audits for user activity within the portal. This is something that can add some value to the product, especially for the ones who seek security compliance. It would be great to have this.

Alternatively, I am exporting database and application logs while running the application in verbose mode; but it would be nice to have user activities in the portal somehow.

Bests, Ali.

✔️ Solution

The easy solution is to dump the logs in a file with user configured buffered size or with specified days of retention (to not get over the size limit) and provide an API to read it from the UI.

❓ Alternatives

Support the remote syslog protocol to be configured via dashboard settings. Something like: https://www.netiq.com/documentation/novelllogmanager11/log_manager_admin/data/bjzkhg5.html

📝 Additional Context

NIST 800-58 SP, SOC2, ISO27001 requires IT systems to have audit logs, and it's pain for companies to use this system and handle those controls.

[CommanderStorm]

• NIST SP 800-58 only targets VOIP => irrelevant
• SOC2+ISO27001 seem to have a form of audit trail requirement from what I can gleam of publicly accessible documents

All actions are currently written to the log
=> I don't have access to the specs, is this sufficient?
=> could you provide screenshots of the exact requirements in these documents?

Hottake:
Audit-logs are only relevant if more than one user can be present at one time
⇒ uptime-kuma can currently only ever be used by one user which does privileged actions.
⇒ imo only a feature which could become relevant if somebody gets around to implementing #128 or one of the duplicates like #3272

On the other hand, this Project is open source and open to PRs.
Here is our contribution guide: https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md

[Ali-Razmjoo]

NIST SP 800-58 only targets VOIP => irrelevant

@CommanderStorm, Sorry I meant NIST SP 800-92; it was a late night brain fart. It's not just that one security standard that requires logging in to the system, e.g., if you consider the Microsoft Threat Modeling (STRIDE) as the port of the SSDLC process in a company, not having logs enabled can cause repudiation as a threat.

SOC2+ISO27001 seems to have a form of audit trail requirement from what I can gleam of publicly accessible documents
could you provide screenshots of the exact requirements in these documents?

We follow NIST SP 800-53 to implement and build SOC2 controls/policies (as a general guideline), and we dig into more details on other standard releases (e.g., FIPS)

More information:
Some of the controls in NIST SP 800-53

• AU-2: Auditable Events
• AU-3: Content of Audit Records
• AU-6: Audit Review, Analysis, and Reporting
• AU-12: Audit Generation

and Some of ISO 27001 controls/requirements:

• A.12.4.1: Event Logging: This control requires that event logs recording user activities, exceptions, faults, and information security events should be produced, kept, and regularly reviewed.
• A.12.4.2: Protection of Log Information: This control requires that logging facilities and log information should be protected against tampering and unauthorized access.
• A.12.4.3: Administrator and Operator Logs: This control requires that system administrator and system operator activities should be logged and the logs protected and regularly reviewed.
• A.14.2.5: Secure System Engineering Principles: This control is about using secure engineering principles for developing and maintaining systems. While not specific to logging, it includes principles that could apply to logging.

more: https://infosavvy.home.blog/2021/04/22/iso-27001-annex-a-12-4-logging-and-monitoring/

Hottake:
Audit-logs are only relevant if more than one user can be present at one time
⇒ uptime-kuma can currently only ever be used by one user which does privileged actions.
⇒ imo only a feature which could become relevant if somebody gets around to implementing https://github.com/louislam/uptime-kuma/issues/128 or one of the duplicates like https://github.com/louislam/uptime-kuma/issues/3272

Naturally IRL, when this happens, we share the password in a shared team key vault or anywhere FIPS 140-2 Level 2 compliance and have an update process that we follow (e.g., RACI model) to make sure we minimize the possible risks. We have a process that privileged user follows to increase business continuity...

All actions are currently written to the log
=> I don't have access to the specs, is this sufficient?

but it's still good to have more meaningful portal-level logs rather than application and database levels.

On the other hand, this Project is open source and open to PRs. Here is our contribution guide: https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md`

Yeah, I thought of that as well, but not sure if I am a good JS/TS developer; I will try my best 👍