Postgres (Database)

Mask (Redact) sensitive data in PostgreSQL (Relational Databases)

Book a Demo

Postgres (Database)

Table of Contents

TL;DR: In a Nutshell: Strac for Postgres Data Masking

Sensitive data in databases should be masked to protect privacy and security.
Masking can help with compliance, security, privacy, and risk management.
Tokenization, format-preserving pseudonyms, and masking are methods to mask data in a database table.
Strac is a tool that connects to a database instance and masks data based on supplied configuration.
Strac helps protect sensitive data in both Relational and NoSQL Databases.

Identifying the Challenge of Data Masking in Postgres

One should mask sensitive data from database tables to protect the privacy and security of that data. When sensitive data, such as personal identification numbers, passwords, or credit card numbers, is stored in a database, it is vulnerable to unauthorized access or disclosure. Masking the data can help prevent this from happening by making it unreadable or unusable to anyone who does not have permission to access it.

There are several reasons why one might choose to mask sensitive data in a database:

Compliance: Many industries have regulations that require the protection of sensitive data, such as HIPAA for healthcare data, PCI DSS for payment card data, and GDPR for personal data. Masking sensitive data can help ensure compliance with these regulations.
Security: Masking sensitive data can help prevent unauthorized access to the data, either by malicious actors or by employees who do not have a legitimate need to access it.
Privacy: Masking sensitive data can help protect the privacy of individuals whose data is stored in the database. By masking the data, you can ensure that even if the database is breached, the sensitive information will be unreadable and therefore useless to the attacker.
Risk management: Masking sensitive data can help reduce the risk of data breaches or other security incidents. By limiting the amount of sensitive data that is stored in the database in its original form, you can reduce the potential impact of a security incident.

Masking sensitive data from database tables is an important step in protecting that data's privacy and security and ensuring compliance with industry regulations and best practices.

This problem exists in both Relational and NoSQL Databases.

How Strac Offers a Solution for Postgres Data Masking

There are many ways to mask data in a database table:

Tokenization is a method that replaces sensitive data with a meaningless and unique identifier called a token. For example: a credit card number "1234 5678 9012 3456" may be replaced with a token such as "tkn_T4Ngz9sLsZ", which is meaningless outside of the payment processing system.‍
Format-Preserving Pseudonyms: Format-preserving pseudonyms are synthetic identifiers derived from sensitive data that preserve the original data's format and length. For example: name "John Doe" can be replaced with "Charles Smith" or date of birth "12/01/1923" can be replaced with "02/13/1982"
Masking: Masking would reveal only some parts of data and rest of the data will be replaced with either * or X. For example: email address "johndoe@example.com" could be masked as "*****@example.com" or "j******e@e*****.com"

Strac will connect to database instance and mask based on the supplied configuration.

Let's check out an example: Below is a table that has 5 fields: user_id, name, email, company_name and phone

‍

On the above table, we will apply different redaction experiences:

user_id: we will keep user_id as-is. So, values of user_id will be the same after redaction
name: we will generate a pseudonym, so it will be fake data that will be format preserving
email: we will mask the username and keep the domain name. Note: we will not apply length preserving on user-name
company_name: we will keep only the first character and mask remaining while also length preserving.
phone: we will tokenize the phone number and generate a token

‍

Sharepoint DLP Use Cases

Practical Scenario

A hospital’s billing and administrative teams use SharePoint Online to store patient invoices, medical reports, and insurance forms. While collaborating with external insurance providers, a staff member accidentally updates the permissions on a SharePoint document library to “Anyone with the link,” exposing potentially thousands of patient files containing PHI.

How Strac's Sharepoint DLP Helps

Continuous Data Discovery: Strac automatically scans existing and newly uploaded documents, identifying PHI (e.g., medical record numbers, Social Security Numbers).
Classification & Labeling: Once identified, files are labeled (e.g., “HIPAA Sensitive”), ensuring that administrators know which documents require the highest level of protection.
Visibility into Access: Strac provides real-time insight into who has access to these sensitive documents. Administrators can instantly see if unauthorized users or broad groups have viewing rights.
Revoke Public Links: If a file is publicly accessible, Strac immediately revokes those links and restores restricted access.
Alerts & Quarantines: When someone attempts to share PHI externally, Strac can alert admins, quarantine the file for review, or completely block the action.
Audit-Ready Reports: All actions are logged, enabling quick incident response and demonstrating HIPAA compliance for audits.

Practical Scenario

A mid-sized investment firm uses SharePoint to collaborate on various client files, including:

Credit card statements (subject to PCI-DSS)
ID documents (Driver’s Licenses, Passports, etc.) used for KYC (Know Your Customer) verification
Banking information such as account and routing numbers

An associate accidentally shares a SharePoint folder containing these files with a newly onboarded client who does not require access to all confidential documents. This folder is also accessible to several internal teams outside the immediate project, creating multiple potential exposure points.

How Strac's Sharepoint DLP Helps

Comprehensive Data Discovery: Strac scans both existing and newly uploaded documents in SharePoint for sensitive information such as credit card numbers, bank account details, and ID documents (Driver’s License, Passport formats).
Classification & Automated Labeling: Once identified, Strac applies meaningful labels (e.g., “PCI-DSS Sensitive,” “PII – ID Documents,” “Banking Info”) to ensure these files stand out and are subject to stricter security rules.
Visibility into Access: Strac provides an immediate view of who currently has access to these sensitive files. This allows admins to spot situations where external clients or internal teams unnecessarily have permissions.
Public Access Revocation: If a labeled document (e.g., containing card data or ID scans) is found to be publicly shared or too broadly accessible, Strac automatically revokes these links or permissions, aligning access with the principle of least privilege.
Alerts, Quarantines, and Blocks: When a user attempts to share a labeled document with outside domains—or with an entire department—Strac alerts administrators or quarantines/blocks the file share, depending on policy settings.
In cases where the share is intentional but needs review, admins can approve or deny the request within Strac’s dashboard.
Audit & Compliance: Every sharing event, label assignment, and access revocation is logged, creating a detailed audit trail. This helps demonstrate compliance with PCI-DSS, KYC, AML, and other regulatory requirements.
Automatic reporting simplifies any regulatory or internal compliance audit, reducing the administrative burden on security and compliance teams.

Practical Scenario

A software company keeps source code, product roadmaps, and design specs in SharePoint. Several teams—including external contractors—use the same SharePoint site. A developer accidentally grants a large group, including some non-disclosure–exempt contractors, access to a folder containing patent-pending code.

How Strac's Sharepoint DLP Helps

Holistic File Scanning: Strac inspects documents, PDFs, and archives for code snippets, system designs, and proprietary business terms to detect potential IP.
Intelligent Labeling: Documents identified as containing IP or trade secrets are automatically classified (e.g., “Proprietary IP”), reinforcing the need for restricted sharing.
Real-Time Access Insights: With Strac, administrators can instantly see who has access to IP-tagged files, enabling them to remove unauthorized users or reduce permission scopes.
Immediate Link Removal: If a contractor or external partner is mistakenly granted access to IP, Strac revokes public or unauthorized sharing before the files can be downloaded.
Alerts & Blocking: Strac’s policies can be configured to alert security teams or block external sharing attempts for files containing proprietary content.
Incident Response & Auditing: Detailed logs of every share request, label change, and access revocation aid in quick incident resolution and help prove due diligence if legal issues arise.