Mine relates to the behind-the-scenes element of this, using queries against the Confluence database I've built a centralized log myself which works perfectly, but if there are multiple macros on the page the current database schema doesn't allow you to identify WHICH one on a page you're referring to, so you'd have to consider everything on a page compromised. My idea involves creating an additional link in the database tables for the plugin to allow the identification of specific macros so where there's more than one on a page you can be specific in which ones have been compromised.
Immanuel Siagian
Absolutely agree. This is also heavily related to my own suggestion:
https://ideas.atlassian.servicerocket.com/ideas/SEC-I-47
Mine relates to the behind-the-scenes element of this, using queries against the Confluence database I've built a centralized log myself which works perfectly, but if there are multiple macros on the page the current database schema doesn't allow you to identify WHICH one on a page you're referring to, so you'd have to consider everything on a page compromised. My idea involves creating an additional link in the database tables for the plugin to allow the identification of specific macros so where there's more than one on a page you can be specific in which ones have been compromised.
Attachments Open full size
Absolutely necessary feature for an admin.
We use your addon to securely distribute passwords to employees. We have more than 30 secure-macros across our Confluence instance.
When an employee leaves the company, we need to review the audit logs one by one to find out which passwords they had access to and then change them.
This is a really painful process, where a centralised audit log would make wonders!
Attachments Open full size
Totally makes sense for Confluence-admin to at least see what happens with the Secure-Macro-Blocks
Attachments Open full size