 Zero Trust has become the gold standard for modern cybersecurity. The principle is simple: “Never trust, always verify.” Every request must be authenticated, authorized, and evaluated in real-time. But here’s the problem: databases were never built for Zero Trust. The Problem: Databases Assume Too Much Trust Traditional databases work on an all-or-nothing model: If a user can query a table, they can usually see every row in that table. Even with column-level permissions, once inside, the blast radius of a breach is massive. Least privilege — the core of Zero Trust — isn’t truly possible. That means if a credential is stolen, or an insider goes rogue, your sensitive data is wide open. The Gap Between Zero Trust and the Data Layer Organizations have firewalls, identity providers, and access gateways enforcing Zero Trust at the perimeter… but once someone reaches the database, it’s game over. This is the blind spot in most Zero Trust strategies: the data layer. The Fix: 00DB — A Zero Trust, Zero Trace Proxy Database This is where 00DB comes in. Instead of giving users direct access to your production database, 00DB acts as a proxy database that enforces governance, auditing, and self-destruction. Key features: 🔒 Row-level & Query-level Governance Limit not just what tables users can access, but also how many sensitive records they can retrieve. Example: only one Social Security Number per day across the entire database. 💣 Self-Destructing Instances Every 00DB database automatically destroys itself after a set period of inactivity (default: 15 minutes). Once gone, it’s gone for good — ensuring no stale attack surfaces remain. 🕵️ Celebrity Data Protection Mark certain fields as requiring executive approval before access (for example: celebrity or VIP records). 📜 Audit Everything Every query is logged — including who accessed what data, when, and the exact values retrieved. In short, 00DB lets you apply Zero Trust principles inside the database itself, not just around it. Why This Matters By using a proxy database like 00DB, you shrink your attack surface, reduce breach impact, and finally bring the data layer into alignment with your Zero Trust strategy. Because at the end of the day: Firewalls protect the perimeter. Identity providers protect the login. 00DB protects the data. ✍️ Want to see it in action? Try the K8s version here
0 Comments
 Think of docker as a tool that creates software installers, similar to .msi files. This “installer” includes both an operating system and a copy of your application. The operating system within the “installer” is a minimally viable OS, containing only the essential components needed to run your application.
Kubernetes takes the "installer" (known as a Docker image) and can install it to a server. It can also install the docker image multiple times on a single server or multiple times across multiple servers. You don't need to worry about the specifics of hard drive space, RAM, or CPU requirements—Kubernetes manages all of this for you. Hope this clears up the confusion.  What is SQL Simulator?
Can SQL Simulator integrate into existing workflows?Yes. All you need to do is issue 8 command line commands. What are the 8 command line commands?After you install the software(no registration required) and setup the data governance tables , here are the commands you need to issue to set up the database. These examples run from windows command line. They need to be modified slightly to run on linux. #1 - Setup port forwarding to the control panel. The control panel is used to create the pod that contains SQL Server and a copy of SQL Simulator.
#2 - Create the pod
#3 - Setup port forwarding to the pod.
#4 - Initialize the pod. This step adds an admin user to the database in the pod and changes the system password to match the password specified in the query string.
#5 - Add TSQL files to the pod. These are the files that SQL Simulator will scan in order to recreate a subsetted copy of production inside the database pod.
#6 - Add Data Source to the pod. There are 2 different data source that must be configured. The source data source and the simulated(pod) data source. You will need the username/password you created from step #4 for the simulated data source username/password.
#7 - Test Connection(this step is optional)
#8 - Execute a PreviewMerge. This step will create a subsetted copy of your production database based on the sql files you added in step #5. You can also execute a DryRun or PostviewMerge.
You can connect your favorite database IDE to the pod by using the username/password from step #4 and with this address. Remember that the database will self destruct after 15 mins of non use.
If you have any questions or issues please contact us or setup a no cost one on one zoom meeting.
 Let me guess, you've tried docker prune, optimize-vhd or disk part but that didn't work. You've read tons of blog posts and watched a bunch of YouTube video's but to no avail. It seems to be a big mystery as to why docker doesn't release all of the hard drive space that it uses.
There is a reason for this. Docker uses up a lot of RAM. It uses far more RAM than you have available. And will do this for long periods of time. When this happens your C:\Windows\Temp folder gets full. So what you must do is periodically empty your temp folder and that will give you back all the space it used. Hope this helps and reduces someone's frustration.  What is a dry run?According to chat gpt a dry run : "Refers to a rehearsal or practice session conducted in a simulated or controlled environment to test the execution of a process, system, or event without actually implementing it in its full operational capacity. It involves going through the motions and steps of a particular activity, such as a presentation, procedure, or software implementation, to identify potential issues, assess readiness, and familiarize participants with the expected workflow. Dry runs are typically employed to uncover and rectify any flaws, ambiguities, or inefficiencies before the actual implementation or live performance takes place, allowing for adjustments and improvements to be made, thereby enhancing the overall outcome and reducing the likelihood of errors or disruptions." What is the purpose of a SQL Dry Run?To verify if your SQL scripts will execute and that those SQL scripts are doing what you think they will do. So what is a SQL Simulator?SQL Simulator makes performing dry runs easy with just the click of a button. What is needed to setup and run the software?The setup process can take as little as 5 minutes. Here is what you need
How does SQL Simulator work?It is similar in concept to Redgate SQL Clone or Windocs. If you are not familiar with these tools they make clones of your database. The key difference with SQL Simulator is, it only makes a clone of the database objects affected by your sql script not the entire database. Nor does it copy the entire table (if your sql has where clauses). Once those database objects have been cloned, SQL Simulator then executes your script against the cloned database it created. For a more in-depth technical overview click here Can I see a demo?Here you go |
Tribal KnowledgeArchives
May 2024
Categories |
RSS Feed