Securing the wiki and knowledge base itself: admin roles, service accounts, keys, logs and lifecycle

The internal wiki is where an organisation writes down how everything works, which makes it one of the first places an intruder searches for architecture diagrams, runbooks and the credentials someone pasted into a setup page. Wikis and knowledge bases grow by inheritance and sharing: spaces copy their parent's permissions, pages get public links for a supplier, integrations hold API tokens, and page history keeps a secret long after someone deletes it from the current version. This guide is for collaboration platform owners, IAM teams and security engineers responsible for an enterprise wiki, whether SaaS or self-hosted. It covers admin roles, permission inheritance, public and external sharing, the platform's service accounts and tokens, secrets in content, AI assistants that index the wiki, logging, and the lifecycle through to archiving. It is vendor-neutral: confirm exact setting names in your platform's documentation. For one widely used product in depth, see the Confluence Data Center Hardening Guide.

Key takeaways

• Treat the wiki as a credential store until proven otherwise. ATT&CK lists testing and development credentials, network diagrams and system documentation among the data adversaries mine from information repositories.
• Control inheritance, not individual pages. Most exposure comes from a space or parent page opened too widely; set restrictive defaults at the top of the tree and review them.
• Close anonymous and public access by default. Public links and guest access should be off at tenant level and enabled only per space, with an owner and an expiry.
• Every integration gets its own scoped token. Bots, migration tools, search connectors and AI assistants each need a named service identity, least privilege, an owner and an expiry.
• Deleting a secret from a page is not remediation. Revoke and rotate the credential first, then purge it from page history, attachments, exports and search indexes.

What the wiki holds and why it is a target

MITRE ATT&CK technique T1213 Data from Information Repositories describes collaboration repositories as holding policies and procedures, network and architecture diagrams, technical documentation, testing and development credentials, source code snippets, links to internal resources and personal data about partners and customers. It also notes that adversaries may abuse external sharing features to send documents outside the organisation. A wiki therefore serves three attacker goals at once: reconnaissance, credential access and data theft. The T1213 Data from Information Repositories Defensive Guide covers the technique; this guide covers the platform owner's controls.

The component table reflects a common architecture and is NHI Mgmt Group's view; your platform may name, merge or split these differently.

Admin roles and permission design

The NCSC SaaS security guidance asks that a service separate privileged administrator or owner accounts, which change configuration and manage users, from standard users, and that admin interfaces use modern authentication. The NCSC secure system administration principles add protected admin interfaces, tiered administration, privileged access management and logging of admin activity.

• Tenant or site administrators: a small number of named accounts, separate from daily accounts, behind SSO with phishing-resistant MFA. Site admin often bypasses page restrictions, so treat it as privileged access. See the Tiered Administration and Enterprise Access Model Guide.
• Space administrators: owned by the team lead of each space, not by whoever created it. Review the list quarterly (an NHI Mgmt Group suggestion) and on team changes.
• App or integration administrators: who can install apps, approve OAuth connections and create API tokens. Keep this separate from content administration where the platform allows.
• Default space permissions: new spaces should start restricted to their team, with organisation-wide read granted deliberately. Grant to directory groups synced by SCIM rather than individuals, so movers and leavers lose access automatically. See the SCIM Provisioning Guide.
• Restricted spaces: security, HR, legal, incident and M&A spaces get explicit membership, no inheritance from organisation-wide groups, and are excluded from broad search connectors.

Public links, guests and external sharing

External sharing is the setting most likely to move data out without any attack at all, and ATT&CK specifically notes abuse of sharing features.

NIST SP 800-53 Rev. 5 AC-22 Publicly Accessible Content expects designated individuals to review content before it is posted publicly and to remove non-public information if found; apply that to public spaces and public links. Label spaces by classification so the sharing defaults follow the label; see the Data Classification Guide.

Service accounts, API tokens and integrations

The NCSC SaaS guidance expects APIs that return protected data to require authentication. On a wiki, that authentication is usually a personal API token, a bot account or an OAuth app, and these are the non-human identities that most often outlive their purpose.

• One identity per integration: search connector, chat bot, migration tool, backup service and AI assistant each get their own service account or app registration, never a shared admin's personal token.
• Scope: read-only where possible, limited to the spaces the integration needs, and never site admin. OWASP's Secrets Management Cheat Sheet applies least privilege at the level of individual secrets and recommends secrets that expire.
• Expiry and rotation: set token expiry (90 days is a reasonable NHI Mgmt Group default for personal tokens; automated integrations should use short-lived OAuth tokens) and store long-lived integration credentials in a secrets manager. See the Secrets Management Guide.
• Ownership: each token and app has a named human owner and a business purpose recorded in your NHI inventory. See NHI Discovery Across Cloud, SaaS, CI/CD and On-Premises Environments.
• Third-party apps and macros: require admin approval for installation and OAuth consent, review requested scopes, and remove unused apps. Consent abuse is covered in the Consent Phishing and Illicit OAuth Grants Guide, and a product-specific walkthrough is in How to audit Jira and Confluence app links and OAuth.

Stolen tokens map to ATT&CK T1528 Steal Application Access Token, and misuse of valid tenant accounts to T1078.004 Cloud Accounts.

Secrets and sensitive data in content

Runbooks and onboarding pages attract credentials: database connection strings, shared admin passwords, API keys in example commands, private keys pasted for "just this migration". ATT&CK classes these under T1552 Unsecured Credentials. OWASP's Secrets Management Cheat Sheet says documentation should record who has access to a secret, how it is rotated and whom to contact, without recording the secret itself.

1. Prevent: publish a content rule (no credentials, private keys or tokens in pages, comments or attachments; link to the vault entry instead) and provide a sanctioned store: a secrets manager for machine credentials and the enterprise password manager for shared human logins.
2. Detect: scan pages, comments, history and attachments on a schedule and on change, covering the types OWASP lists (API keys, connection strings, passwords, private keys, session tokens), and use more than one detection method. The How to find secrets in Jira and Confluence guide shows the method on one platform.
3. Remediate in order: OWASP describes containment as revocation, rotation and deletion, plus logging. Revoke or rotate the credential first, because it may already have been read; then purge it from the current page, every historical version, attachments, exports and the search index.
4. Record: log who could read the page while the secret was present, from the platform's access logs, to scope the incident.

AI assistants and search over the wiki

Enterprise search and AI assistants answer from indexed wiki content. They do not create new exposure if they enforce the reader's permissions, but they make existing over-sharing far easier to find, and they add a new risk: content written to steer the assistant. MITRE ATLAS tracks reconnaissance of RAG-indexed sources as AML.T0064 Gather RAG-Indexed Targets and poisoning of indexed content as AML.T0070 RAG Poisoning.

• Permission-aware retrieval: confirm the assistant queries as the user, not as a service account that can read everything.
• Clean up before indexing: run the permission review and secrets scan before connecting an assistant, not after.
• Exclude restricted spaces: leave security, HR and legal spaces out of the index unless there is a reviewed need.
• Edit rights are write access to answers: broad edit permissions let anyone change what the assistant tells colleagues. If poisoning is suspected, follow the RAG Knowledge Base Poisoning Response Playbook.

How to implement: a phased programme

1. Inventory (weeks 1 to 2): list admins, spaces with organisation-wide or anonymous access, live public links, guests, installed apps, OAuth grants and API tokens with their owners.
2. Quick wins (weeks 2 to 4): enforce SSO and MFA, reduce site admins, turn off tenant-level anonymous access where no public space exists, and expire public links older than your agreed age after notifying owners.
3. Secrets sweep (weeks 3 to 6): scan content, history and attachments; rotate and purge findings; publish the content rule.
4. Restructure permissions (weeks 4 to 10): move grants to SCIM groups, restrict default space permissions, isolate sensitive spaces. Pilot with two spaces first, and keep a record of previous permissions so you can restore a space if a team loses access it genuinely needs.
5. Integrations (weeks 6 to 10): replace personal tokens used by automation with dedicated service identities, set expiry, remove unused apps.
6. Logging and review (ongoing): stream audit logs to the SIEM, schedule quarterly space admin and guest reviews, and rerun scans continuously.

Small versus large: a small organisation on a SaaS wiki can complete steps 1 to 3 in a fortnight using the admin console and built-in reports. A large or regulated organisation, or one running a self-hosted platform, also needs host hardening, backup encryption, a formal app approval process and log retention that satisfies audit; the self-hosted product guide above covers the host layer for one platform.

Logging, detection and measurement

The NCSC SaaS guidance expects security-critical logs (authentication attempts, configuration changes and resource access) that customers can export to their own monitoring tools. Collect and alert on:

• Admin role grants, permission changes on spaces with restricted labels, and changes to anonymous access or sharing settings.
• Creation of public links and guest invitations, especially into restricted spaces.
• API token creation, app installation and OAuth consent.
• Bulk page views, bulk downloads of attachments and site or space exports by one identity, a pattern consistent with T1213 collection.
• Access from an integration identity outside its usual spaces or source addresses.

Protect the audit trail itself: forward it to a store wiki administrators cannot alter, in line with NIST SP 800-53 AU-9 Protection of Audit Information.

Lifecycle: onboarding, archiving and decommissioning

• New spaces: created from a template with restricted defaults, a classification label and a named owner.
• Owner departure: spaces whose owner leaves are reassigned, not left ownerless; the leaver's personal tokens are revoked with their account.
• Archiving: archived spaces stay permission-controlled and searchable only by their team; delete per your retention schedule rather than keeping everything.
• Migration: exports used to move platforms are full copies of the wiki; encrypt them, restrict who holds them, and delete them when the migration is signed off. Revoke migration tool tokens on completion.
• Decommissioning: revoke every integration identity and OAuth grant, confirm the provider's data deletion, and keep the audit logs for your retention period.

Framework mapping

Common failure patterns

• Organisation-wide read on the root: one grant at the top of the tree makes HR, security and incident pages readable by every employee and every compromised account.
• Delete and forget: a pasted password removed from the page but not rotated, and still present in page history and the search index.
• Personal tokens running automation: a migration script or bot uses an administrator's personal API token, which keeps working after that person moves on and carries their full permissions.
• Immortal public links: links created for a supplier years ago still resolve, with no owner and no report of their existence.
• Connecting the AI assistant first: an assistant indexed before the permission review turns quiet over-sharing into answers anyone can request.
• Unreviewed apps: diagram, export and automation apps installed by users with read access to every space and no record of who approved them.

Practitioner checklist

• Enforce SSO and MFA for all users, and phishing-resistant MFA for site and app administrators.
• Reduce site administrators to named, separate accounts and review space admins quarterly.
• Set restrictive default space permissions and grant through SCIM-managed groups.
• Turn off tenant-level anonymous access and require expiry and owners for public links and guests.
• Give every integration and AI assistant its own scoped, expiring identity with a named owner.
• Require admin approval for app installation and OAuth consent; remove unused apps.
• Scan pages, history and attachments for secrets; rotate first, then purge everywhere.
• Stream audit logs to a store administrators cannot alter and alert on sharing, token and export events.
• Handle owner departure, archiving, migration exports and decommissioning as defined lifecycle steps.

Standards and references

• MITRE ATT&CK: Data from Information Repositories (T1213)
• NCSC: SaaS security
• NCSC: Secure system administration
• OWASP: Secrets Management Cheat Sheet
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0
• MITRE ATLAS: RAG Poisoning (AML.T0070)

Related NHI Mgmt Group resources: Confluence Data Center Hardening Guide, How to find secrets in Jira and Confluence, T1213 Data from Information Repositories Defensive Guide, SaaS Security Guide.