Object buckets holding citizen PII must block public ACLs, and municipal file shares must require authenticated access only. Which storage security stance is correct?
Select an answer to reveal the explanation.
Short Explanation
PII buckets are not a public bulletin board—lock down ACLs and make people authenticate. Same story for file shares: no anonymous free-for-all. Open writes and world-readable SSNs are how a data breach writes itself.
Full Explanation
Object stores holding citizen PII must deny public ACLs, and municipal file shares must require authenticated access only. That stance keeps personally identifiable information and internal files from anonymous internet or guest exposure—core storage security for public-sector cloud. Public-by-default buckets are a frequent cause of civic data breaches.
Enabling anonymous write on every bucket so citizens can upload without accounts invites abuse and data poisoning. Publishing Social Security numbers in world-readable objects for open-data portals is a serious privacy violation. Removing all access controls from NFS exports to simplify desktop mapping exposes file shares broadly.
Exam caveat: block public access features, private ACLs/policies, and authN for file shares are complementary; encryption and logging still apply. Open data must be intentionally curated—not accidental PII.
Operational check: enable account-level public-access blocks on PII buckets, audit existing ACLs for public grants, require AD/IAM auth on file shares, and alert on policy changes that reintroduce public access. Include bucket privacy checks in the city’s continuous compliance scans.
Separate open-data publishing accounts from PII custodial accounts so a mistaken public ACL on a marketing bucket cannot accidentally expose citizen identity stores in the same control plane context.