This content originally appeared on DEV Community and was authored by KILLALLSKYWALKER
Previously i share with you the usage of PostgreSQL Anonymizer .
At that time, the way we added the rules is manual. When the schema is small, this approach worked fine with few fields, few changes and still easy to maintain.
But in reality, database schemas never stay static.Day by day, new fields get added or modified. This introduces a serious risk where newly added columns might expose raw PII if we forget to declare anonymization rules and also maintaining a growing set of SECURITY LABELs quickly becomes error prone and hard to track.
Automating the Anonymization Rules
The easier way actually you can just use this , but it will never work properly because you need to remember that we might have constraint in our table . So this is not the one that we can use .
ALTER DATABASE postgres SET anon.privacy_by_default = true;
So , you still need to write your own rules , where this rules will always getting bigger day by day .
SECURITY LABEL FOR anon ON COLUMN candidates.last_name IS 'MASKED WITH FUNCTION anon.dummy_last_name()';
So when i mention manually , we track this rules in a repo whenever we add or change . Change track in git , but here the catch , since this is like a different repo , the team always kind of ignore this and disconnected . So the rules sometime is really outdated also .
Solution
Since the project is using laravel , as you know laravel got a solid migration , i use laravel migration to add the new rules or remove the rules whenever we add or remove column, so all the dev that working on this job portal know what added , remove and need to be sync with the anonymizer rules . This is example how i do it at that time .
/**
* Run the migrations.
*/
public function up(): void
{
Schema::table('users', function (Blueprint $table) {
$table->string('identification_number')->nullable()->after('email');
});
DB::statement("SECURITY LABEL FOR anon ON COLUMN users.identification_number IS 'MASKED WITH FUNCTION anon.partial(identification_number,2,$$******$$,2)'");
}
/**
* Reverse the migrations.
*/
public function down(): void
{
DB::statement("SECURITY LABEL FOR anon ON COLUMN users.identification_number IS NULL");
Schema::table('users', function (Blueprint $table) {
$table->dropColumn('identification_number');
});
}
With this approach we can keep track everything in the migration and if someone miss out , we can remind it in pr review . We don't need seperate rules repo anymore . I know this not sexy enough , but we can make it more cleaner using helper or trait to write the statement for security label .
This content originally appeared on DEV Community and was authored by KILLALLSKYWALKER
KILLALLSKYWALKER | Sciencx (2025-09-10T16:00:00+00:00) The Dark Side : Manual Rules. Retrieved from https://www.scien.cx/2025/09/10/the-dark-side-manual-rules/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.