Shared service-account passwords for city integrations are stored in a wiki editable by dozens of staff. What credential-management change is required?
Select an answer to reveal the explanation.
Short Explanation
A wiki full of service passwords is a public bulletin board for keys. Put those secrets in a real vault with checkout, rotation, and logs—not a bigger font, a share called secrets, or an all-staff email CC. Shared cleartext pages are how integrations get hijacked.
Full Explanation
Shared service-account passwords for city integrations must leave editable wikis and similar broad collaboration spaces. Store and check out those credentials through a managed vault or credential-management system that enforces access control, rotation, and audit logging. Vaulting limits who can retrieve a secret, records each checkout, supports automated rotation after use or on a schedule, and often brokers sessions so humans never need standing knowledge of production integration passwords. That change is the core credential-management control when dozens of staff can currently read the same wiki page of keys.
Moving the same passwords into a world-readable network share labeled “secrets” only relocates the exposure and may widen it. Increasing wiki font size so on-call staff can read passwords across the room maximizes shoulder-surfing and treats secrecy as optional. Emailing the wiki page weekly to the all-staff distribution list as a “backup” broadcasts credentials into mailboxes, archives, and forwards far beyond any need-to-know boundary.
Exam caveat: CISSP IAM expects privileged and service secrets in controlled vaults with accountability—not documentation systems used as key rings. Operational check: migrate integration service passwords into a vault with ACLs, checkout, and rotation; remove secrets from wikis and shares; revoke broad edit rights; enable audit logs for retrieval; and verify on-call procedures use vault workflows instead of emailed or posted cleartext.