I want to implement column level and row level access control on data stored in my MySQL database. I am using NodeJS on my server, what's the way to go for this ?
I see SAP Hana allows that but want to keep MySQL.
There are three approaches you could take:
Do it within the app
Do it between the app and the db, inside a db proxy
Do it inside the database
The first option wouldn't really qualify as row-level access control since the application logic is the one responsible for the filtering / masking. (Filtering is row-level access control whereas masking is cell-level).
The second option, using a proxy, is an approach that is increasingly being taken. There are dedicated solutions such as:
GreenSQL
Informatica DDM, and
Axiomatics Data Access Filter.
These solutions typically intercept the SQL traffic and modify it such that only authorized data is returned. This is called dynamic data masking. It is explained a little bit more on Wikipedia.
The third option is to use the database's native capabilities. For instance Oracle has something called Virtual Private Database (VPD) which lets you configure advanced row filtering capabilities.
In your case (MySQL), there is something called fine-grained access control (FGAC). There is a great article on the topic here. Google that term for more resources.
Related
Can someone explain to me why you can't connect to a MySQL DB directly through dart from a security point of view?
There is no hard guideline on whether to connect frontend directly to backend or not. It is just a design practice that has been widely accepted and evolved over many years.
Typical app structure consists of
FRONTEND -> SOME MIDDLE LAYER -> BACKEND
Where your middle layer handles all the interactions/processing with the database and the frontend uses this functionality with some sort of API structure. Having this layer is extremely helpful when the application goes to scale, it gives an added abstraction to the frontend.
It is not advisable to directly fuse your frontend(your flutter app), to the DB(MySQL) because any efficient hacker might use basic man-in-middle attack to know your DB structure/connections/queries(There are some pretty effective decompilers present out there), and alter your data and you might not even get to know what caused the data to update unless you've applied some checks on DB layer.
Also, your frontend logic needs to be more of end-user centric than to handle the data of the user. Any backend system(java, node, etc) gives you added functionality & freedom to parse and present the data from either side.
You can use the sqlite package available to store basic data, like your session tokens, your app configurations etc, but it is advisable to keep the main user data like the logins, etc in a separate place, or better yet, you can use the firebase plugin to store data in document structure in the cloud.
I'm currently building a react native application that involves sharing data between multiple clients. I already have a Web-app with a MySQL database near completion. I need to know how to use RealM with react native in order to provide offline local storage while including functionality to update the MySQL database when online.
Does anyone have any useful tips or resources on how to accomplish this?
Thank you
You essentially have two options, and you aren't going to like either one of them:
Throw away the application you've written and start over.
Don't use Realm.
Realm isn't a component which can integrate with an existing application an its database. Instead, it's a replacement for a traditional SQL database -- the expectation is that you use Realm as the primary storage for all your data. Its synchronization features depend on it having full control over how objects are stored in the database.
I'm looking to use SSRS for multi-tenant reporting and I'd like the ability to have runtime-chosen Shared Data Sources for my reports. What do I mean by this? Well, I could be flexible but I think the two most likely possibilities are (however, I'm also open to other possibilities):
The Shared Data Source is dictated by the client's authentication. In my case, the "client" is a .NET application and not the user, so if this is a viable path then I'd like to somehow have the MainDB (that's what I'm calling it) Shared Data Source selected by the Service Account that the client logs in as.
Pass the name of the Shared Data Source as a parameter and let that dictate which one to use. Given that all of my clients are "trusted players", I am comfortable with this approach. While each client will have its own representative Service Account, it's just for good measure and should not be important. So instead of just calling the data source MainDB, we could instead have Client1DB and Client2DB, etc. It's okay if a new data source means a new deployment but I need this to scale easily enough as well to ~50 different data sources over time.
Why? Because we have multiple/duplicate copies of our production application for multiple customers but we don't want to duplicate everything, just the web apps and databases. We're fine with some common "back-end" things. And for SSRS, because of how expensive licenses are (and how rarely reports are ran by our users), we really want to have just a single back-end for all of our customers (I actually have a second one on standby for manual disaster recovery situations - we don't need to be too fancy here as reports are the least important DR concern we have).
I have seen this question which points to this post but I was really hoping there was a better way than this. Because of all of those additional steps/efforts/limitations/etc, I'd rather just use PowerShell to script duplicate deployments of the reports with tweaked hardcoded data sources instead of standardizing on the steps in that post. That solution feels WAY too hacky to me and doesn't seem to scale very well at all.
I've done this a bunch of terrible ways (usually hardcoded in a dynamic script), and then I discovered its actually quite simple.
Instead of using Shared Connection, use the Embedded Connection and create your Connection string based on params (or any string manipulation code)....
So I'm moving from MS Access to MySQL:
In MS Access you can store certain INSERT, DELETE, and UPDATE queries as objects alongside your tables. Thus for anyone who don't understand computers that well, they can click on the objects and automatically run the queries to alter the master table for various business functions.
In MySQL, where and how do you store these queries, I seem to be only able to make tables. When I write a piece of code using the SQL editor, I can only save it to a remote location (such as my local desktop) and not onto the MySQL database, where it's accessible for my coworkers.
If you can't save it onto the server, how would I write a piece of code and execute it within the database that would be easily usable by others.
Thanks
The answer to this question is going to depend on your environment, your users, and your bandwidth to support any given solution. You are gaining a lot by making the switch from Access to MySQL, however you are losing some of the the WYSIWYG features. (e.g., Access forms that can bind directly to your data source.)
There are many approaches:
If your users are more advanced, simply having access to the database using MySQL Workbench may suffice. From there they would have access to run views, stored procedures, or to create their own custom queries.
Another option would be to script your objects using Python and provide a simple gui using TkInter. Python is generally thought of as an easy to use language; with built in suppport for MySQL and TkInter is its "default" interface.
Using the LAMP architecture is another largely popular paradigm using MySQL as the backend database.
There is also nothing stopping you from using Access to link to your MySQL db using MySQL as an external data source.
I hope this provides enough info to help you begin whittling down your options.
In my application, the entity database schema is created after application deployment based on inputs captured from end user, using a tool. I cannot use Entity Framework in this situation, since modeling is not possible without development environment (Visual Studio). The 'Code First' approach is also ruled out since it would require code generation which may lead to needless complexity.
Anyhow I need a Data Access Layer. I am therefore planning to introduce Data Access Application Block (DAAB) into my solution. Using SQL Management Objects (SMO) I can carry out the DDLs and for Data access I will use DAAB.
Now here is my confusion. Can I use LINQ for SQL technology on top of DAAB? I want DAAB to abstract all data access related complexities and then use LINQ to query. I also have a situation where I need to expose entity data through RESTful interface (read as OData). Would I be able to expose my data using WCF Data Services via DAAB?
LINQ is not supported in DAAB. DAAB is based on the good old DataSet and DataReader approach. This post has much more detailed answer with respect to role of DAAB.
LINQ support in Enterprise Library Data Access Application Block
I don't yet fully understand your scenario. If your database schema is created after deployment, then hows your front end application being developed against (as there wont' be any schema, if I get your question right).
If the schema is created after deployment what functionality is in your deployed application. Are you creating user interfaces on the fly using the dynamic schema that end user modelled?
Please do correct my understanding also good if you can give in some more info about your scenario.