My database is hosted in Cloud SQL, and how can I secure my database to from unauthorised entities to access.
How should I protect my database??
PS: I have seen suspicious activity on my database.
Google has written an extensive blog post on how to secure a database here.
One of the most important things that you should consider is going by the Least Access principle. This can be achieved easily by the IAM tool that Google Cloud Platform has for this.
Also, if your Cloud SQL instance has a public IP, you should consider using SSL/TLS to encrypt your data.
Last but not least, if your database was deployed with a default login, you should make it a top priority to change or disable that account.
Related
I have an existing API connected to an AWS PostgreSQL database that uses AWS Cognito for User authentication.
The goal is for users to insert data via the API with some field mapped to their Cognito id, and retrieve the same data. The idea would be for each user to only have access to the data 'owned' by them. Similarly to the way row level access works.
But I do not want to create a role for each user which seems to be necessary.
The idea would be that I need to somehow setup a connection to the PostgreSQL DB with the user_id without creating a user and handle the accessible data via a policy, or somehow pass the data to the policy directly.
What would be an ideal way to do this, or is creating a PG user for each user a necessity for this setup?
Thanks in advance
EDIT: I am currently querying the database through my backend with custom code. But I would rather have a system where instead of writing the code myself, the PostgreSQL system handles the security itself using policies(or something similar). I fully understand how PostgreSQL row-level-access works with roles and policies and I would prefer a system where PostgreSQL does the major work without me implementing custom back-end logic and preferably not creating thousands of PostgreSQL roles for the users.
You should not allow users to make a direct connection to the database.
Instead, they should make requests to your back-end, where you have business logic that determines what each user is permitted to access. Your back-end then makes the appropriate calls to the database and returns the response to the user.
This is a much 'safer' response because it prevents users having direct access to your database and it is also a better architecture because it allows you to swap-out the database engine for another one without impacting your service.
The database is for your application, not for your users.
use case
in icCube
one server instance
icCube users only need to access the reporting
icCube is used to for a standard reporting solution for an industry vertical and can be used by multiple clients, each having their own (copy of the) structures that work with their own data
a client can grant one or more users access to their own dashboards in icCube
authorization requirement
it should be possible to link authorization to the client's identity
management system (such as AD)
for others, it should be possible to assign a local admin at the client that can give access to their own environment to whom they wih
for the rest, it should be possible for a centralized admin to maintain access
a perfect job for ...
keycloak
keycloak needs for each of the requirements a seperate realm with client (see picture)
The icCube documentation only makes mention of one Realm & client.
the question
Is it possible to use multiple keycloak realms & clients with one instance of icCube?
See also icCube documentation on keycloak integration
Right now this is not possible.
The keycloak.json file is used to connect to a Keycloak server that is going to authenticate the HTTP request. So you would need somehow a way to determine which keycloak.json file to use based on the HTTP request before using it meaning having different URL and/or URLs with a specific parameter.
Possibly the multi-tenant support could be extended to be able to configure an authentication logic per tenant with the same constraint about the URL value.
Hope that helps.
I have a client-side react app that I need to fetch information from a MongoDB Atlas collection that is being populated directly to the source by another individual. When I went to check out the connection string I noticed that the user password for db access would need to be present in the code:
(Not enough rep to post images sorry)
https://i.imgur.com/5Vs23WJ.png
Now obviously if I include this right in my front-end code anybody will be able to see my password and that's no good. But I need this app to be self-contained and I don't want to have to host a server just to reroute the single Get request that is called upon loading the site.
If I create a new user with read-only privileges, is it safe to keep that user's (super generic obviously) password in the front-end code for access to the db? Is there any harm in this? Am I correct in assuming that non-whitelisted IP addresses aren't able to make requests to the Atlas db? The only address that is going to be whitelisted is the IP where the web-app will be hosted, so I'd imagine I don't need to worry about someone spamming requests to rack up charges on my Atlas account or doing anything else malicious?
I'm a recent grad so I don't have much experience with secure deployment but I'm hoping I can change that this summer.
Thanks :)
I'm not sure about "best" practices, but I'll try to answer according to what I would do:
is it safe to keep that user's (super generic obviously) password in the front-end code for access to the db?
Yes you can create a read-only user. It's generally not a good idea to use a super-user to do your reads. I would only give as much access as the job requires.
Am I correct in assuming that non-whitelisted IP addresses aren't able to make requests to the Atlas db?
Correct. Only whitelisted IPs will be able to connect to the Atlas instance.
Having answered that, I personally would either:
create an API layer on top of the database to prevent direct access to the database by a client application, or
(If applicable) create a Stitch Webhook that provides a Stitch-based REST API layer on top of the Atlas deployment.
The idea is to provide security by limiting access to the database from the outside world. Using a whitelist is one layer of security. Using a REST API is further security layer that essentially forces anything that needs database access to go through a guarded gate that is under your control.
Some additional benefits of a REST API gateway:
Should your Atlas URI changes in the future, you don't need to redeploy the client applications everywhere again. You just reconfigure the REST API gateway to point to the new Atlas URI, while your client application can still use the existing REST API address with no change.
Limiting client connections to the database itself. Since only your API gateway can connect directly to the database, there is little chance that the database can get accidentally DDOSed when you have a lot of clients active at the same time.
Note that I would not consider the above to be "best" practice by any means. It's just how I would do it.
I'm building a mobile front-end for my customer's CRM system. CRM data is stored in a SQL Server database in their local network. What will be the best practice to make this data available to mobile app users. Mobile app will be distributed using Enterprise key, not via App Store.
I'm thinking about making a WCF service running on a local server and having access to the SQL server via ethernet. This service will provide basic authentication. But I'm not sure if it's the best way in terms of security.
How to provide access to SQL server data?
A WCF web service can definitely be used as a SQL front end. Windows or JavaScript-based client applications running on hand-held devices have no trouble accessing WCF applications, and there's plenty of sample code out there about using a WCF app as a front-end to databases. Here's a sample project from CodeProject.
Security wise, there are several options: you could create a Login(ID, PWD) function that all non-authenticated user requests would have to pass through before getting to your SQL server. Once the user authenticates, you can create a persistant session or send back to the client a SessionID he/she can use to re-authenticate on subsequent requests. You can also use more exotic and complex methods for authentication/authorization like client certificates and Forms, though on a iOS or Android device that will certainly take some extra work.
Since a public web service, accessing company core data, is a hacker's dream, you can always set up your web service so that it can only be accessed from inside the company firewalls via VPN. If not that, then you can use SSL or message-level encryption.
I am developing a Rest service with Web API. The service only requires one login credential as it is used by an application developed by a third party. If I use the project template with "Individual User Accounts", I have to have a SQL server running(?), which is an overkill to support a single username and password. How about the LocalDB comes with VS 2013 ?
"Windows Authentication" cannot be used because the service is accessed from the Internet.
What is the proper way to authenticate ?. Are there any "in memory" or config file providers that come with Web API ? I know there is Asp.net Identity package, but It uses entity framework as a provider. Can anyone please suggest ?
You can create a custom store for ASP.NET Identity and it could be memory or a config file. Here is a tutorial on creating a custom store in ASP.NET Identity. I would not put it in memory because you will most likely want to change the password and that would require a recompile and redeploy. Personally I would just use SQL Express or SQL Compact as they take minimal resources and rewriting the data store seems like a lot of work for little benefit in this scenario.
No matter how do you want to authorize the call, the users has to be present in a database or cache to check the validity of the provided user. Microsoft will offer you out of the box a solution based on SQL server or some of their own products.
If you want to implement you own user check, you will probably have to take care of the authentication by yourself. This means that you will have to check the HTTP header by yourself and reject or accept the request by yourself.
My question is, why do you want to use some "in memory" provider? The users has to be somewhere. Why not a SQL express?