I have a SharePoint application that needs to integrate with very sensitive databases. The data required is from multiple databases; almost 40 different databases on different servers.
The suggested design was to have a web service to integrate with, which will then connect to the required database based on the required business logic. However the concern is, if someone somehow got access to the server hosting this web service, all the database connections will be there.
Another suggestion was to have a dedicated web service for each database. This way even if someone got access to this web service, only one database connection will be there.
The question is, is there any known design that can work for this situation to add more security to the database connections?
The answer really depending on your specific requirements. an easy way of doing so is to use "Open Data Protocol" OData. and then secure it with windows directory login, or perhaps ASP.NET login.
take a look at http://www.odata.org/ and http://msdn.microsoft.com/en-us/library/ff478141.aspx
Related
I apologize if this question is not appropriate; however, I personally do not have Microsoft Access installed on my machine, so I am not able to test it first hand.
To my understanding, an Access database is a local database that is stored on a personal machine rather than a remote server. I am in the planning phase of a project will involve two basic interfaces - one for a regular user and another for the admin who will be running reports and the like. Personally, I would rather just use either an SQL Server or MySQL database all the way and just write some stored procedures or whatever is necessary to do the reporting.
However, the end administrative user may want to use Access. With this is mind, I am curious how I should approach the problem. As I stated earlier, I am not familiar with Access databases; however, I do not believe it is realistic to host one on a server and allow many users to access this database through a web interface. Is this correct or not? If it is possible, what is the general procedure for setting such an application up?
If not, what are my alternatives? Is there an easy way to sync a remote SQL server or MySQL database with Access database hosted on one's PC?
Thanks much.
I do not believe it is realistic to host one on a server and allow
many users to access this database through a web interface. Is this
correct or not?
You have a number of options including hosting the access database in a network folder.
https://support.office.com/en-us/article/Ways-to-share-an-Access-desktop-database-03822632-da43-4d8f-ba2a-68da245a0446
See also "Using Access Data on an ASP.NET Web Page"
https://msdn.microsoft.com/en-us/library/445z2s49(v=vs.100).aspx
My organisation (a small non-profit) currently has an internal production .NET system with SQL Server database. The customers (all local to our area) submit requests manually that our office staff then input into the system.
We are now gearing up towards online public access, so that the customers will be able to see the status of their existing requests online, and in future also be able to create new requests online. A new asp.net application will be developed for the same.
We are trying to decide whether to host this application on-site on our servers(with direct access to the existing database) or use an external hosting service provider.
Hosting externally would mean keeping a copy of Requests database on the hosting provider's server. What would be the recommended way to then keep the requests data synced real-time between the hosted database and our existing production database?
Trying to sync back and forth between two in-use databases will be a constant headache. The question that I would have to ask you is if you have the means to host the application on-site, why wouldn't you go that route?
If you have a good reason not to host on site but you do have some web infrastructure available to you, you may want to consider creating a web service which provides access to your database via a set of well-defined methods. Or, on the flip side, you could make the database hosted remotely with your website your production database and use a webservice to access it from your office system.
In either case, providing access to a single database will be much easier than trying to keep two different ones constantly and flawlessly in sync.
If a webservice is not practical (or you have concerns about availability) you may want to consider a queuing system for synchronization. Any change to the db (local or hosted) is also added to a messaging queue. Each side monitors the queue for changes that need to be made and then apply the changes. This would account for one of the databases not being available at any given time.
That being said, I agree with #LeviBotelho, syncing two db's is a nightmare and should probably be avoided if you can. If you must, you can also look into SQL Server replication.
Ultimately the data is the same, customer submitted data. Currently it is being entered by them through you, ultimately it will be entered directly by them, I see no need in having two different databases with the same data. The replication errors alone when they will pop-up (and they will), will be a headache for your team for nothing.
Is it efficient using a web service to access database objects?
I'm developing a win phone app and a web app. Both of them will use the same db. Should I create one web service for two apps?
A shared webservice is definitely the right way to go. That's really the point of a service, to be able to access the same business and data logic from multiple places (assuming both places are doing the same thing of course). It also acts as a natural security buffer between your app and database - so your database only needs to accept connections from the service, as opposed to multiple client applications.
As far as the technology, since both of your clients are Microsoft, you can use WCF as your service as opposed to a traditional SOAP service. Or you can go with something more universally accepted, like WebAPI with JSON. Lots of options there.
We have a few projects that we put all the data access in a separate web service project and the parent project will call the web service for everything data related. The web service will only accept connections from the web project server. My assumption is that the web service would be less susceptible to intrusion this way. I'm not really sure this is correct.
Is this more secure than just putting the data access in a class or dll within the parent project?
NOTE
Developers above me made this decision.
I don't see that as an effective way of securing your database. Of all the various ways that exist to protect your data layer, I don't think that moving calls from a class library to a web service is an effective way to protect yourself.
A better approach would be to make sure that you use parameterized queries or stored procedures to prevent SQL injection, and limit the privileges of your logins to only the operations that they need to perform.
However, there would be other arguments for having data access in a separate web service... such as re-usability, or a service-oriented architecture. If the same data access layer is needed from a variety of projects on multiple servers, by having the web service you wouldn't need to have the same class library duplicated all over the place... which would cause you to worry about which project has which version of your data access layer.
So, more secure? I don't think so... Other benefits? Probably...
Short answer: Yes
Longer answer: My assumption is that the web server that is exposing the services is behind its own firewall. Doing it this way insulates the database from intrusion by forcing hackers to go through another layer if they were able to compromise your application servers. Since the database connection strings do not exist on the app server, and a firewall prevents direct connections from that server to the database, the hackers would need to somehow puncture that firewall and gain access to the server that is hosting your data services.
Now, I also assume that the web services are not simply exposing methods like
execute(string sqlCommand)
if that's the case, then this solution might actually less secure than simply using a database without the web services. For this solution to truly be more secure you would want to create operation-specific methods on the web service server.
A DLL can't be accessed and executed from the Web, so far as I know. A Web service can. If that's true, the class library referenced by a Web project (or even a Web Service) is more secure than a Web service encapsulating that logic directly.
Further, there's the whole notion of Separation of Concerns. In my mind, data access logic belongs on a separate tier, completely separate from business logic. In a well designed architecture, Web services expose discrete methods that represent business transactions--not necessarily data transactions. Business transactions encapsulate one or more data transactions, which are represented by separate classes that encapsulate the data access logic and provide the security to ensure that SQL injection never occurs.
Others, naturally, may disagree. We're developers. It's our nature to disagree. :)
We’ve got a back office CRM application that exposes some of the data in a public ASP.NET site. Currently the ASP.NET site sits on top of a separate cut down version of the back office database (we call this the web database). Daily synchronisation routines keep the databases up-to-date (hosted in the back office). The problem is that the synchronisation logic is very complex and time consuming to change. I was wondering whether using a SOAP service could simply things? The ASP.NET web pages would call the SOAP service which in tern would do the database calls. There would be no need for a separate web database or synchronisation routines. My main concern with the SOAP approach is security because the SOAP service would be exposed to the internet.
Should we stick with our current architecture? Or would the SOAP approach be an improvement?
The short answer is yes, web service calls would be better and would remove the need for synchronization.
The long answer is that you need to understand the technology available for you in terms of web services. I would highly recommend looking into WCF which will allow you to do exactly what you want to do and also you will be able to only expose your services to the ASP.NET web server and not to the entire internet.
There would be no security problem. Simply use one of the secure bindings, like wsHttpBinding.
I'd look at making the web database build process more maintainable
Since security is obviously a concern, this means you need to add logic to limit the types of data & requests and that logic has to live SOMEWHERE.