Posts

Row-Level Security, Done Right: My Oracle Label Security Rollout Across Nepal's 7 Provinces

Image
Row-Level Security, Done Right: My Oracle Label Security Rollout Across Nepal's 7 Provinces Oracle Label Security | Case Study Row-Level Security, Done Right: My Oracle Label Security Rollout Across Nepal's 7 Provinces How I used Oracle Label Security to enforce province- and department-level data access across Nepal's 7 provinces Munish Kumar Karna - DBA The Business Problem A national organization operating across all 7 provinces of Nepal needed a single, shared database — but with very different visibility rules depending on who was looking at it. Executive leadership needed a complete, nationwide view. Province-level managers needed full visibility into their own province, but nothing outside it. And functional staff (HR, IT, Marketing, Finance) needed to see only their own department's records within their own province. Rather than maintaining separate schemas, views, or application-level filters for every combination of role and province, ...

Oracle VPD in Action: Building Role-Based Row-Level Security from Scratch

Row-level security is one of those requirements that shows up in almost every enterprise database — Finance shouldn’t see HR’s salary data, HR shouldn’t see Finance’s, and no team should see another’s unless explicitly authorized. Most teams solve this at the application layer, hard-coding WHERE clauses into every query. It works — until someone connects directly through SQL Developer or a reporting tool and bypasses the app entirely. Oracle’s Virtual Private Database (VPD) , also known as Fine-Grained Access Control (FGAC) , solves this properly: it enforces row-level and column-level security inside the database engine itself , so it’s enforced everywhere, every time — no exceptions. In this post, I’ll walk through how I implemented it, mapping database roles to departments on a sample emp_test table. How VPD Works Policy Association – A security policy is bound to a table or view using the DBMS_RLS ...

Building a Highly Available MySQL 8 InnoDB Cluster

Image
A 3-node Group Replication cluster with MySQL Router, tested end-to-end for automatic failover and manual switchover By Munish Kumar Karna | Oracle DBA Over the past few days I set up and stress-tested a production-style MySQL 8.0 InnoDB Cluster from scratch — 3 database nodes running Group Replication behind MySQL Router, with a full failover and switchover drill at the end. Sharing the walkthrough here in case it helps anyone building HA MySQL on-prem or in a private cloud. Architecture Three MySQL 8.0.46 nodes in single-primary Group Replication, fronted by MySQL Router for transparent read/write and read-only routing: Node IP Address (example) mysql01 10.0.10.11 mysql02 10.0.10.12 mysql03 10.0.10.13 mysqlrouter 10.0.10.20 1. Host Prep & Firewall Configured /etc/hosts on all three nodes for name resolution, verified with ping and getent hosts Installed MySQL 8.0 Server + MySQL Shell ( mysqlsh ) on all nodes Opened the required ports: 3306 (MySQL...