The 2024 IBM report highlights the growing cost of data breaches in the business domain. Here are some of its findings:
- The average cost of data breaches rose to $4.88 million – a 10% increase from the previous year.
- One in every 3 data breaches involved shadow data, thus making it challenging to monitor and protect.
In particular, traditional data warehouses are vulnerable to data breaches due to their centralized approach to data storage. Besides that, companies continue to rely on outdated security practices, which are no longer effective in this age. Instead, enterprises need a proactive approach to cybersecurity to secure their sensitive data.
What’s driving the latest infiltrations?
In most of these security incidents, cybersecurity teams observed unauthorized access to the legacy warehouse system. Hackers effectively exploit authentication-related vulnerabilities, which help them bypass traditionaal security controls and gain unauthorized data access.
A Google Cloud study found that 80% of compromised customer accounts expose their user credentials. How did these hackers obtain the user credentials? Through a series of info stealer malware campaigns, which allowed them to export sensitive customer data from Snowflake customer instances.
These malware campaigns were successful primarily because of the following 3 factors:
- Compromised customer accounts are not secured with multi-factor authentication (MFA), thus primarily relying on username/password as the only form of user authentication.
- Stolen user credentials from previous infostealer campaigns are still valid (after many years) – and have not been updated since.
- The affected customer instances don’t have any “network allow” lists that allow access only from trusted locations.
Comparatively, modern warehouses like Snowflake and Google BigQuery are better equipped for data security and management. For instance, both these systems offer high-grade data encryption in compliance with AES-256 standard.
How BigQuery works for enterprise security and data management
With Google BigQuery, enterprises can adopt a more proactive approach to data security and management. Among its notable features, Google BigQuery has a “decoupled” serverless architecture that segregates data storage from its computing.
Here are 3 reasons why Snowflake users must migrate to BigQuery to secure their data and other resources:
-
Identity and Access Management (IAM)
With effective IAM, Google BigQuery facilitates granular access to specific cloud resources. This security feature follows the “least privilege” principle, which does not grant users more permission than what they need.
With BigQuery, enterprises can configure their IAM policies at various levels of the resource hierarchy – with each resource inheriting the policies of its parent resource.
With its predefined roles and responsibilities, BigQuery grants permissions at the user, group, and service account levels. Each of these entities can be granted permissions using predefined or custom roles.
Here are the various BigQuery resource levels where user permissions can be granted (or denied) access:
- Organizational level – or for individual projects and folders
- Datasets
- Connections
- Database tables or views
- BigQuery data policies, row access, or policy tags
-
Security through data classification
Google BigQuery applies security through data classification – along with row-level and column-level security. Through row-level security, BigQuery can restrict data filtering and generate shared views among its users. By applying the “least privilege” principle, enterprises can apply row-level access to a data subset in the database table.
Through column-level security, BigQuery ensures grained access to critical database columns using policy tags or data types. With this level of security, enterprises can create policies that check the user’s access during the query process.
-
Data loss prevention (DLP)
For data discovery and loss prevention, Google BigQuery provides a few exceptional services. For instance, by using data catalogs, enterprises can derive and sustain the data lineage. With these services, enterprises can also scan personally identifiable information (PII) and add security tags to BigQuery tables.
With DLP, Google Cloud users can detect and protect sensitive data using two methods:
- Sensitive data profiles containing metadata and metrics of database tables can help in identifying high-risk and sensitive data.
- On-demand inspection of a specific database table or subset of columns, along with reporting the findings of this inspection.
-
Data encryption
As a managed service of GCP, Google BigQuery offers encryption for data at rest and in transit. BigQuery offers the following types of data encryption:
- Google-managed encryption automatically encrypts (and decrypts) all data before writing it to the disk and before it’s read by any authorized user. Google manages all the necessary encryption keys for data protection.
- Customer-managed encryption allows Google customers to manage their encryption keys for Google BigQuery. They can control and manage their keys using Google Cloud’s key management service.
How Onix can help you migrate from Snowflake to BigQuery
Enterprises facing challenges in data security and management can consider migrating from Snowflake to Google BigQuery. That said, they can face a host of underlying challenges in making this migration smooth and effective. Some of the key challenges include differences in:
- Object hierarchy and mapping
- Data types
This is where you need the expertise of a cloud migration and modernization partner like Onix. Here’s how Onix can help you in data migration to Google BigQuery. Read about how Onix enabled a major retailer to achieve data modernization on BigQuery.
Our latest eBook titled “Migrating from Snowflake to BigQuery” discusses the challenges and solutions to common migration-related challenges. Download this eBook now.
Reference links:
https://medium.com/google-cloud/data-security-and-governance-with-gcp-bq-
42bf651e346ahttps://cloud.google.com/bigquery/docs/access-control