PHI Access for Three Business Units and a Contractor
CareShield Health has 250 watsonx.data users across cardiology, oncology, and claims. The Iceberg tables contain PHI: member_id, ssn, date_of_birth, diagnosis_code, and claim_amount. Today every user is a member of a group with SELECT on the entire catalog, and queries run through a shared Presto engine. Internal audit found that oncology analysts can read cardiology claims and that contractors can see SSNs. A 30-day contractor team must analyze de-identified claims only. Compliance requires minimum-necessary access, quarterly access reviews, and evidence that access to PHI is logged. The identity provider supports SAML groups; watsonx.data is integrated with IBM Cloud IAM. The security team wants to avoid copying data into a separate warehouse but accepts creating governed views. They also need to detect a user who tries to bypass a view and query a base table directly. The platform team can create catalogs, schemas, views, and groups but cannot change the source tables' contents.
1. Design the group, role, and grant model. Where should catalog-level SELECT be removed?
Read the worked answer
Groups: create IdP-backed groups per business unit and per function: cardiology_analyst, oncology_analyst, claims_analyst, contractor_deid, and platform_admin. Map them to platform roles with the least privilege needed to run queries, not to administer engines or catalogs. Grants: remove SELECT on the entire catalog. Grant USAGE on the needed schema and SELECT only on the specific tables or, better, on governed views. Cardiology gets cardiology tables; oncology gets oncology tables; claims gets claims tables; contractors get only the de-identified view. Contractors: no direct base-table grant. Make access time-bound through the identity provider group membership and expire it automatically after 30 days. Admin: keep a small platform admin group separate from data-reader groups. Review: export group membership and grants quarterly; compare against the approved access matrix. The key judgment is that catalog-level SELECT is the root cause, because it makes every downstream view control optional and lets any user bypass restrictions by querying the base table.
2. Where should row and column restrictions be enforced, and what are the limits of that approach?
Read the worked answer
Enforce restrictions with governed views that filter rows and project only allowed columns, then grant SELECT on the view instead of the base table. For example, a cardiology view applies WHERE specialty = 'cardiology'; a contractor view excludes ssn, truncates date_of_birth to year, and applies a de-identification rule. Revoke base-table privileges from all data-reader groups so the view is the only path. Verify that the view executes with the intended definer rights and that users cannot see the underlying SQL or access the base table. Limits: view-based row filters are only as strong as the grant model. A user with base-table access bypasses them. Complex or changing rules become many views and are hard to audit. Column masking in a view can still leak through joins or aggregate inference. For stricter separation, place each business unit in a separate catalog or schema and use separate storage locations. Test with a contractor account that attempts a direct base-table query; it must fail and generate an audit event.
3. What monitoring and governance evidence would you present to prove compliance?
Read the worked answer
Query audit: retain query history with user, SQL text, referenced tables, rows scanned, and timestamp. Alert when a contractor or business-unit user references a base table outside their approved views, and when a query fails authorization. Access audit: log grant changes, group membership changes, and failed logins; review them quarterly with business owners. Governance: use IBM Knowledge Catalog or the platform's catalog integration to classify PHI columns, record lineage from source to view, and attach business terms. Network and keys: show private connectivity and encryption evidence if PHI leaves the engine boundary. Evidence pack: an access matrix signed by each business owner, the contractor's 30-day expiration record, sample query logs for a PHI table, and the results of a bypass test. The point is not to collect logs; it is to show that minimum-necessary access is enforced, reviewed, and detectable when someone attempts to exceed it.