I am creating accounting/invoicing software and my database is in postgreSQL. Should I create a separate database for each user since the data is sensitive financial data? Or is having a user foreign key secure enough? If I am hosting the database on aws I understand that I could have a few db servers across multiple availability zones and regions so that if one is compromised it wouldn't effect everyone even if many users have info stored in a single database. Is this safe enough? Thanks!
In general no. Encrypt the data so that if someone exfiltrates a dump they can't actually use it without the decryption key. If you're worried that someone with admin access can see the user's information then you might want to consider a user-level encryption for all fields related to personally identifiable information.
There are few ways you could go about it but I wouldn’t create a new DB for every customers. It will be too expensive and a pain to maintain and evolve.
To me, this sounds like you are creating a multi-tenant application.
I’d personally use the row-level security feature in Postgres (see this article) or create a separate Schema for each Customer.
You can add an extra layer of protection with encryption at rest. AWS support it (link)
Related
I'm setting up a blockchain database using bigchaindb for an ecommerce platform. Although, it's more like a secure backup. My application already runs on a SQL database. The blockchain database saves data in the form of assets and transactions in mongodb. The bigchaindb also provides all it's data via a public API. Later, I also want to query this database.
I tried searching for it, but didn't get a dedicated discussion on database design for e-commerce on blockchain. If you know any such article out there, let me know, it'll be helpful.
As per my personal assertions:
Every information like, the user_profile, order, products, reviews etc can be saved in the form of assets. Moreover, operations like transferring product from the seller to the customer can be saved as transactions. Also, a customer creates a review as an asset, while putting the review on the product will be a transaction.
Of course, I will need to create Key-Pairs as identities for individual users, but I think I shouldn't save it in the blockchain, as it's data is accessible by the public API. So, I can save it in the actual SQL database of the application.
Do you think it's the best way? Any suggestions from your side?
I am not sure you can have a "schema" in a / any blockchain. For your purpose, which I believe is little strange https://github.com/ssbc/ssb-db should be enough.
For example I have 2 databases. One of them is called ecommerce which contains real customer information. Another is called ec1 which basically contains only views from tables of ecommerce.
We use our ec1 database to connect to our website or apps. How secure is this method in terms of back end security?
Only exposing ec1 is better than exposing ecommerce because you can reset ec1 using your "safe" values in case of corruption and you can keep some secret data only stored in ecommerce if it doesn't need to be used by your website or your app.
However, this is only a small portion of backend security. Having two different databases with real data and data views doesn't matter a lot if someone can access your server OR can corrupt your data.
I mean, if someone found a way to get some data he should be not authorized to read, it is bad even if it comes from ec1 and not from ecommerce
So yeah, exposing only views is a BETTER solution, but nothing can be said on the overall security because it mainly doesn't depend on that
EDIT: A detailed explaination of backend security is way beyond the possibility of a simple stackoverflow answer (and probably i am not the best teacher) but for basic server security you must take care of:
- Firewall to stop every request but your webapps ones.
- Updated software
- good database passwords
- The user you use for your application queries must only be able to perform operations on ecl1 database, while the views should be generated with a cron and using a different user
These are the main security enhancement tips that comes to my mind
Previously I was using databases from BaaS (Backend as a Service) - Parse, Backendless, Firebase - this services has everything I need to manage users of my webapps: tokens handling, owner policies etc.
How do I manage webapp users in own database? (PostgreSQL 9.4)
Is it suppose to be just a regular table, which will contain columns "login", "password" etc. or there are specific tools to implement that?
How should I handle tokens? Should I store it somehow in database, or tokens suppose to be stored in my server and are not bind to database at all?
How do I implement owner policies? Are there some specific tools in Postgres for this, or I should simply create the column "ownerId" in each table and use it as Foreign Key?
If you know good articles on this topic - please, post a links - it will be very helpful!
I would search for it in google, but I've found nothing but articles about database users handling. I assume, this is not what I'm looking for.
Regular table or postgrsql ROLE system
Usually tokens are on application side
Postgres 9.5 have row security policies but you can implement owner policy by yourself. Hard to say what database features you have to use without
assumptions of the project.
I plan to design a system with Dreamfactory as the user management server while a separate REST server for social feed. Dreamfactory will have its own MySQL database for storing user info while the social feed will use MongoDB.
Is this a good system design? I'm new to this as I'm using both open source platform for two different purposes; social feed and user management.
It's difficult to answer your question without knowing requirements to the system. I was going to ask you why storing users in MySQL, but all the same I can ask why using MongoDB or product XXX ;)
There is no silver bullet in programming. Tool is chosen from requirements, not vice versa.
If you do not need to relate data, do not need transactions and does not care about data consistency at all, why go why relational databases? Solutions like AeroSpike or just Redis (yes, it can be persistent too) can give you much higher read/write rate.
Well, I suggest you go write a document, containing your system description, think of load this system is going to have. May be you will decide, that storing data in CSV files is ok for you (joking ;) )
I need some opinions.
I'm going to develop a POS and inventory software for a friend. This is a one man small scale project so I want to make the architecture as simple as possible.
I'm using Winform to develop the GUI (web interface doesn't make sense for POS software). For the database, I am using Postgresql.
The program will control access based on user roles, so either I have to develop a middle tier, using a web server, to control user access or I can just set user priveleges directly in Postgresql.
Developing a middle tier will be time consuming, and the maintenance will be more complex. So I prefer to set access control directly in the database.
Now it appears that using database to control user access is troublesome. I have to set priveleges for each role. Not to mention that for some tables, the priveleges are at column level. This makes reasoning about the security very hard.
So what I'm doing now is to set all the tables to be inaccessible except by superusers. The program will connect to the database using public role. Because the tables are inaccessible by public, I'm going to make publicly accessible stored functions with SECURITY DEFINER (with superuser role). The only way to access the tables is by using these functions.
I'll put the user roles and passwords in a table. Because the user table itself is inaccessible by non-superuser, I'll make a login function, let's call it fn_login(username, password). fn_login will return a session key if login is successful.
To call other functions, we need to supply session key for the user, e.g.: fn_purchase_list(session_key), fn_purchase_new(session_key, purchase_id, ...).
That way, I'm treating the stored functions as APIs. Adding new user will be easier as I only need to add new rows in the user table rather than adding new Postgresql roles. I won't need to set priveleges at column level. All controls will be done programmatically.
So what do you think? Is this approach feasible and scalable? Is there a better way to do it?
Thanks!
I believe there is a better way to do it. But since you haven't discussed what type of security you need, I cannot elaborate on specifics.
Since you are developing the application code in .NET, that code needs to be trusted (unlike a web application). Therefore, why don't you simply implement your roles and permissions in the application code, rather than the database?
My concern with your stated approach is the human overhead of stored procedures. Would much rather see you write the stated functions in C#, rather than in PostgreSQL. Then, standard version control and software development techniques could apply.
If you wait until somebody has at your database to check security, I think you'll be too late. That's a client/server mentality that went out at the end of the 90s. It's part of the reason why n-tier architectures came into vogue. Client/server can't scale horizontally as well as an n-tier solution.
I'd advise that you take better advantage of the middle tier. Security should be a cross-cutting concern that's further up the stack than your persistence layer.
If the MANAGEMENT of the database security is the issue, then you should add the task of automating that management. That means that you can store higher level data with the database tables, and then your application can convert that data in to the appropriate details and artifacts that the database requires.
It sounds like the database has the detail that you need, you just need to facilitate the management of that detail, and roll that in to your app.
My honest advice: Do not invent POS and inventory software. Take one of existing projects and make it better.