You will find some gossips going swimming the team inside my company will quickly be utilising web services for those future database integration. The architecture should be something similar to this:
Application --> Web Service --> Database
The mentioned reasoning behind it's security. This seems like an enormous total waste of time for minimum benefit. My real question is, with what ways does an internet service build your data safer than the usual database? I'd believe that if the attacker desired to get all of your data coupled with already become to the application server, it might be fairly trivial to determine the way the application gets it's data.
Please bear in mind these web services could be purely for data, and might have minimum business/validation logic, and would be also outdoors the applying designers control (a minimum of this is the way it's labored with all of previous programs which have used web services).
If so there won't be any business logic or validation on the internet services, then there's merely a limited security help to adding the extra layer of abstraction. I only say limited since the interface involving the application and also the database continues to be more limited than when they were directly speaking to one another.
Should you add validation and business logic towards the equation, there's a substantial security benefit, as anybody who can access the applying account are only able to perform the database exactly what the application is capable of doing. Furthermore, this can be a better design since it reduces coupling involving the application and implementation particulars of methods the information is saved within the database. Should you desired to alter the database schema, you only have to update the net services, and never entire programs.
One important factor about Web Services is interoperability to ensure that different programs from different platforms later can make use of the services and data. Your organization may benefit a great deal in so doing. And you're simply right concerning the security, it's certainly among the top reasons to use web service instead of expose a public endpoint from the database, it's harmful!
Overall, go for this, that's the best approach.
If you are using a webservice hopefully additionally, you will be utilising some type of queue when delivering the information towards the database. If you work with a webservice and queue combo then your security enter into place with less possibility of lost data. If you don't possess a webservice and queue combo should you send data towards the database also it never will get there you've got no were for this to visit it simply vanishes.
You're correct though if a person really wants to enter the body a webservice is not likely to help contrary it could worsen it if one makes the webservice public plus they discover the title of the webservice because they can just query your DB while using webservice and then any security measures in your servers will just believe it is you programs obtaining the information.
the safety argument is questionable authenticating to some web services are the same as authenticating towards the database
you will find legitimate causes of moving db procedures to web services and SOA generally, but security is not one of these