A data warehouse or lakehouse concentrates the organisation's most sensitive data behind a login, so a single stolen password or over-privileged service account can expose everything at once. In 2024 Mandiant and the platform provider notified around 165 organisations whose cloud data warehouse instances were potentially exposed after attackers logged in with credentials stolen by infostealer malware, on accounts with no MFA and no network allow lists. The platform you choose decides which of those controls you can enforce, how finely you can restrict sensitive columns and rows, who holds the keys, and whether you can see what was queried. This vendor-neutral guide sets out the security requirements to write into a warehouse or lakehouse selection, for data platform architects, security and privacy reviewers and procurement leads. For securing a platform you already run, see Securing the data warehouse and lakehouse itself.
Key takeaways
- Authentication enforcement is the first filter. Require the ability to block password-only sign-in for every human, to give service workloads non-password credentials, and to prove both are enforced, not optional.
- Fine-grained access must be native and consistent. Column masking, row filtering and tag-based policies that apply across every engine and API, with documented exceptions, decide whether you can share data safely.
- Know who can decrypt your data. Ask for customer-managed keys, what happens when you revoke them, and which provider staff can reach data in plain text.
- Query and access logs are evidence. You need complete, exportable logs of logins, queries, data exports and permission changes, retained long enough to investigate a breach found months later.
- Data leaves through sharing, not only theft. Evaluate data sharing, external tables, unload to storage and connectors as exfiltration paths that need their own controls.
Define requirements
Classify the data first, then the platform. Write down:
- Data classes: personal data, special category data, payment card data, health records, financial results before publication, or intellectual property. Each class drives masking, residency and logging needs. See the Data Classification Tools guide.
- Architecture: a managed warehouse with proprietary storage, a lakehouse over open table formats in your own object storage, or both. In a lakehouse, the storage buckets are a second access path that must be governed as tightly as the SQL layer.
- Consumers: analysts, BI tools, data engineering pipelines, machine learning and AI agents, partners receiving shared data. Each consumer type needs an authentication method and a policy model.
- Regulatory obligations: data residency, processor terms, breach notification support, sector rules such as PCI DSS for card data. See the Data Sovereignty and Residency Guide.
- Key ownership: provider-managed keys, customer-managed keys in a cloud KMS, or keys held outside the provider.
- Network model: public endpoints with allow lists, private connectivity only, or both for different user groups.
- Retention and recovery: how long query logs, time travel and backups must be kept, and how quickly you must restore after deletion or ransomware.
Capability areas
Architecture choices and their security trade-offs
| Model | Where data lives | Security strengths | Watch for |
|---|---|---|---|
| Managed cloud warehouse | Provider-managed storage | One policy layer, built-in encryption, provider handles storage hardening | All access through the platform's identities; key control depends on edition; data sharing features enabled by default in some products |
| Lakehouse on open table formats | Your object storage, governed by a catalog | Data stays in your account; one catalog can govern several engines | Direct storage access can bypass catalog policies; external engines may not honour row filters or masks |
| Self-managed warehouse (on-premises or IaaS) | Your infrastructure | Full control of network, keys and logs | You own patching, backup and hardening; harder to keep pace with security features |
| Hybrid (warehouse plus lake) | Both | Fit for mixed workloads | Two policy models to keep in step; copies of sensitive data in both |
Fine-grained controls come with conditions that matter at selection. One lakehouse vendor documents that tables with row filters or column masks cannot be read through certain open catalog APIs or path-based file access, and that older compute runtimes return no data rather than expose it. One cloud warehouse applies column-level access through policy tags that need a dedicated fine-grained reader role per tag, on top of dataset permissions. Ask each bidder for its list of engines, APIs and features where its fine-grained policies do not apply.
Security requirements by area
| Area | Requirement | Maps to |
|---|---|---|
| Human authentication | SAML or OIDC SSO, enforceable MFA for all human users with no password-only fallback, SCIM provisioning and deprovisioning | SP 800-53 IA-2, AC-2 |
| Workload authentication | Distinct non-human user type that cannot use passwords, key-pair or OAuth client credentials, workload identity federation, credential expiry and last-used reporting | IA-5, IA-9 |
| Network controls | Network policies or allow lists per user and per account, private connectivity to your cloud network, ability to disable public endpoints | SC-7, AC-17 |
| Authorisation model | Role-based access with role hierarchies, attribute or tag-based policies, separation of security admin from data owner roles | AC-3, AC-5, AC-6 |
| Fine-grained controls | Column masking, row filters, tag propagation, consistent enforcement across SQL, notebooks, APIs and shared data | AC-3, AC-4 |
| Encryption and keys | Encryption at rest by default, customer-managed keys in your KMS, documented revocation behaviour, rotation, TLS 1.2 or later in transit | SC-12, SC-13, SC-28, SC-8 |
| Logging | Login, query, data export, sharing and grant change logs, exportable to your SIEM, retained at least 12 months (an NHI Mgmt Group recommendation) | AU-2, AU-6, AU-11, AU-12 |
| Exfiltration controls | Ability to restrict unload to approved storage, control external stages and integrations, govern data sharing and marketplace listings | AC-4, SC-7 |
| Recovery | Time travel or point-in-time recovery, deletion protection, backups that a compromised admin cannot erase | CP-9, CP-10 |
| Provider assurance | Independent audit reports, provider staff access controls and logging, breach notification terms, sub-processor list | SR-3, SA-9 |
Evaluation criteria
Weights are an NHI Mgmt Group suggestion for a platform holding personal or regulated data.
| Criterion | Weight | What good evidence looks like |
|---|---|---|
| Authentication enforcement | 20% | Account-level policy blocking password-only human sign-in, service user type without passwords, demonstrated in the trial |
| Fine-grained access control | 20% | Masks and row filters shown working in every engine you will use, documented exceptions, tag-based policies at scale |
| Logging and detection | 15% | Log catalogue, latency to SIEM, retention options, vendor detection guidance |
| Encryption and key control | 15% | Customer-managed key support by edition, revocation behaviour, provider access to plaintext |
| Network isolation | 10% | Private connectivity, per-user network policies, ability to disable public access |
| Exfiltration and sharing controls | 10% | Restrictions on unload, external stages, sharing and integrations |
| Recovery and resilience | 5% | Recovery windows, deletion protection, tested restore times |
| Provider assurance | 5% | Audit reports, sub-processors, notification commitments |
Read key revocation behaviour carefully. Amazon documents that if a customer managed KMS key for a Redshift warehouse is disabled, the warehouse can enter an inaccessible state for 14 days and is deleted if the key is not re-enabled in that time. Revocation is a strong control, but you need to know its consequences before you rely on it. See the Cloud Customer-Managed Keys and BYOK/HYOK Decision Guide.
Lessons from the 2024 warehouse credential campaign
Mandiant attributed the 2024 campaign to UNC5537 and found that the attackers used credentials harvested by infostealer malware, some from infections dating back to November 2020 and never rotated; at least 79.7% of the accounts used had prior credential exposure. The accounts had no MFA and no network allow lists, and Mandiant stated that the provider's own enterprise environment was not breached. See the Snowflake Breach 2024 page and the UNC5537 threat actor profile. The selection lessons:
- Enforceable, not available: MFA that each user can choose to skip is not a control. Require an account-wide policy and evidence that it cannot be bypassed by older drivers or BI connectors.
- Service users need their own type: one platform has since introduced user types that separate people from services and is phasing out password sign-in, with existing legacy service users due to move to a type that cannot use passwords during August to October 2026. Ask every bidder how it distinguishes service users and how it blocks passwords for them.
- Network allow lists matter: a stolen credential used from an unexpected network should fail.
Where identity fits
Most warehouse activity is non-human: ETL pipelines, orchestration tools, BI service accounts, reverse ETL, data sharing integrations and, increasingly, AI agents that run queries. These identities often hold broad read access and long-lived credentials. Require that the platform lets you inventory every service user with owner, credential type, last use and privileges, that it supports key-pair, OAuth or workload identity federation instead of passwords, and that agent access can be scoped to specific schemas and logged per agent. See Service Accounts in Snowflake Guide and Databricks Service Principals and Token Security Guide.
Decision guidance
- Managed warehouse versus lakehouse: choose a managed warehouse when you want one policy layer and minimal storage governance; choose a lakehouse when data must stay in your own storage or be read by several engines, and budget to govern the storage layer as well as the catalog.
- Edition matters: customer-managed keys, private connectivity and longer log retention often sit in higher editions. Price the edition that meets your security requirements, not the entry edition.
- Small organisations: favour platforms with secure defaults (MFA enforced, no public sharing by default) and native masking, so a small team does not need extra tools.
- Large or regulated estates: require tag-based policies, separate security administration, customer-managed keys, private connectivity and integration with a data security posture tool. See the DSPM Buyer's Guide.
- Masking in the platform or a separate tool: native masking is simpler; a separate tokenisation service suits data that must be protected across several platforms. See the Data Masking and Tokenisation Buyer's Guide.
Questions to ask vendors
- Can we enforce MFA for every human user at account level, and which drivers, connectors or legacy paths can still sign in with a password alone?
- How are service users distinguished from people, which non-password credentials do they support, and can we report last use for each?
- Can we restrict access by network per user or per role, and disable public endpoints entirely?
- Which engines, APIs and features do not enforce row filters and column masks?
- Which editions include customer-managed keys, what happens to the service when we revoke a key, and which of your staff can access our data in plain text?
- Which logs cover logins, queries, data unloads, sharing and permission changes, how long are they retained, and how do we stream them to our SIEM?
- How can we prevent data being unloaded to storage locations or shared with accounts we have not approved?
- What detection guidance and indicators did you publish during your last customer security incident?
- How do recovery features protect against deletion by a compromised administrator?
- Which independent audit reports and sub-processor lists will you provide, and what are your breach notification commitments?
Red flags
- MFA that can be enforced only per user, or that BI and driver connections routinely bypass.
- Service accounts that can only authenticate with passwords.
- Fine-grained policies that silently do not apply through some APIs or engines, with no documentation.
- Query logs retained for only days, or available only through a console.
- Data sharing or unload to external storage enabled by default with no account-level restriction.
- Customer-managed keys available only on request, with no documented revocation behaviour.
- Reluctance to describe provider staff access to customer data.
Proof of concept
Use synthetic or masked data that has the same structure as production, and keep the existing platform in place until results are accepted.
- Configure SSO, enforce MFA at account level and try to sign in with a password alone through the console, a JDBC or ODBC driver and your BI tool. All must fail.
- Create a service user for a pipeline with key-pair or federated credentials and confirm it cannot use a password. Report its last use.
- Apply a network policy and confirm sign-in from an unapproved network fails and is logged.
- Apply column masks and row filters to a table of sample personal data, then query it through SQL, notebooks, the API, shared data and any external engine you plan to use. Record every path where policies did not apply.
- Configure a customer-managed key, rotate it, then disable it in a non-production account and record the behaviour.
- Run a bulk export and an unload to an unapproved storage location and confirm the second is blocked and both are logged in your SIEM.
- Delete a table as an administrator and restore it from recovery features within your target time.
- Agree go-live metrics: human users without enforced MFA (target zero), service users with password credentials (target zero), sensitive columns without a masking policy, query log delivery delay, and time to restore a deleted table.
After selection, plan the move with the Data warehouse and lakehouse migration playbook and review regularly with the Data warehouse and lakehouse health check.
Primary sources used here: Mandiant: UNC5537 Snowflake data theft and extortion campaign, Snowflake: MFA rollout and single-factor password deprecation, Databricks: Row filters and column masks, Google Cloud: Introduction to BigQuery column-level access control, AWS: Amazon Redshift database encryption, CISA: Secure by Demand Guide and NIST: SP 800-53 Rev. 5. Products are named only to illustrate documented features or a published incident; this is not a recommendation.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support. Browse vendors in our NHI and AI products directory or contact us.
Related NHI Mgmt Group resources: Data Lake Security Guide · Snowflake Security Guide · BigQuery Security Guide · Databricks Security Guide · Database Activity Monitoring