A new catalog crawler is configured with production database passwords stored in its admin UI and broad access to export connection secrets. What protection principle should stop that design?
Select an answer to reveal the explanation.
Short Explanation
A catalog that hoards production passwords is a skeleton key hung on a lobby hook. Harden the metadata platform—use vaulted secrets, least privilege, and no casual credential export. Convenience that creates a new vault of keys is not progress.
Full Explanation
A metadata platform that stores production database passwords in its admin UI and allows broad export of connection secrets has become a credential sprawl risk. Hardening the metadata platform so it does not become a vault of unprotected production secrets is the protection principle to apply. Storing production passwords in public wiki pages for convenience is malpractice. Granting the catalog unrestricted export of every credential it can reach expands blast radius. Disabling authentication on the metadata platform to speed crawling removes basic control. Exam theme: secure the metadata estate itself. Caveat: crawlers still need access—use vault-backed secrets, least privilege, encryption, and audited retrieval rather than embedding passwords in UI fields. Operationally, move connection secrets to an approved vault, remove plaintext from the catalog admin UI, restrict who can view integration configs, and penetration-test whether the metadata platform can exfiltrate production credentials. Include the metadata platform in the city’s privileged-access inventory and rotate any credentials it uses to crawl production civic systems. Stewards should confirm consumer-facing behavior in a controlled check before closing the change.