I have a requirement to create a tablet application for use in restaurants. It will all be on a private internal network so security is not an issue. The question is which will cause the least network traffic? I can either connect directly to SQL using entity framework or I can connect to web services I create on the SQL server in IIS and the tablets communicate with that.
I guess to simplify it, does a standard SQL connection transfer more data than is necessary?
It's difficult to give a general rule, as network architecture plays into the answer quite heavily.
As a general guideline i would suggest to make web services or php "interfaces" on the server, it would give you a easier and more controllable data flow, besides you could handle transactions easier, as all of them would go thorugh one interface, all db accesses coming from one machine. It makes also debugging and errorhandling easier (log the interface and you see everything that's happening, so you don't ahve to check logs on devices) than if every client connects directly to the DB, gives you more control.
Just a general suggestion, a kind of web services/interface or whatsoever is always worth the investment, sooner or later you will go anyway this direction.
My humble oppinion
Related
I am running a MS Access app using a few tables hosted on our native SQL server to facilitate easy integration with PowerBI and other apps. I am an intermediate MS Access user and new the SQL Server. I don't store anything critically sensitive in any tables and am happy with our normal security for data at rest. However, when my app or PowerBI requests data from the server, how is that data protected? I don't want the increased complexity that comes w/ certificate management and processing time associated with encrypting data. However, I don't want to be low hanging fruit for attacks when I request data from the server (i.e. attacks in transit).
Thanks!
First of all - security is about three things. Confidentiality, integrity and availability. Confidentiality means, that people are not supposed to see data that is not meant for them. Integrity means, that the data is what you expect it to be (no third party is able to manipulate it). And availability means, that the server is always up and running.
This is a simplification, but just to make the point that security is more than many of us believe. If your server is down, then the security is equal to zero.
Having said that, you wanted to know how to protect the communication channel. Sorry to say that, but the best thing we have right now is TLS, which requires certificate management. Look into this page to understand, how this can be configured: http://dba-datascience.com/ssl-or-tls-encryption-on-sql-server/
If you want to know how to protect your SQL Server even more (beyond the communication channel), look into the CIS Benchmarks available here: https://www.cisecurity.org/cis-benchmarks/. They are very technical (which is good), but may be also confusing a bit when you see it for the first time.
Background:
Our team is building an inhouse Intranet web application. We are using a standard three layer approach. Presentation layer (mvc web app), Business layer and data access layer.
Sql database is used for persistence.
Web app / iis handles user authentication (windows authentication). Logging is done in business and data access layer.
Question service account vs user specific Sql accounts:
Use service / app account:
Dev team is proposing to set up service account (set up for application only). This service account needs write & read access to db.
Vs
Pass on user credentials to SQL
IT ops is saying that using a service account (specifically created for app only) for db access is not deemed best practice. Set up Kerberos delegation configured from the web server to the SQL server so that you can pass on the Windows credentials of the end users & create a database role that grants the appropriate data access levels for end users
What is the best practice for setting up accounts in sql where all request to db will come through the front end client (ie via bus layer and then data layer)
The Best Practice here is to let the person/team responsible for the database make the decision. It sounds like the dev team wants to forward (or impersonate) some credentials to the DB which I know that some small teams like doing, but yes that can leave things a bit too open. The app can do whatever it likes to the database, which is not much of a separation if you're into that kind of thing.
Personally, if I understand what you're saying above, I do more of what the IT team is thinking about (I use Postgres). In other words my app deploys over SSH using a given account (let's say it's the AppName account). That means I need to have my SSH keys lined up for secure deployment (using a PEM or known_keys or whatever).
In the home root for AppName I have a file called .pgpass which has pretty specific security on it (0600). This means that my AppName account will use local security to get in rather than a username/password.
I do this because otherwise I'd need to store that information in a file somewhere - and those things get treated poorly pushed to github, for instance.
Ultimately, think 5 years from now and what your project and team will look like. Be optimistic - maybe it will be a smashing success! What will maintenance look like? What kinds of mistakes will your team make? Flexibility now is nice, but make sure that whomever will get in trouble if your database has a security problem is the one who gets to make the decision.
The best practice is to have individual accounts. This allows you to use database facilities for identifying who is accessing the database.
This is particularly important if the data is being modified. You can log who is modifying what data -- generally a hard-core requirement in any system where users have this ability.
You may find that, for some reason, you do not want to use your database's built-in authentication mechanisms. In that case, you are probably going to build a layer on top of the database, replicating much of the built-in functionality. There are situations where this might be necessary. In general, this would be a dangerous approach (the database security mechanisms probably undergo much more testing than bespoke code).
Finally, if you are building an in-house application with just a handful of users who have read-only access to the database, it might be simpler to have only a single login account. Normally, you would still like to know who is doing what, but for simplicity, you might forego that functionality. However, knowing who is doing what is usually very useful knowledge for maintaining and enhancing the application.
I am planning to make a VB.Net application that is hard coded to access an MS SQL database hosted remotely on a web server. Is there a way for someone using some packet sniffing (I think it is called) program on the client PC to somehow know what password was used to access the database? I don't need to know how it is done, I just need to know if it can be done so that I know if my approach is safe enough.
Thanks!
If you only care about protecting the login to the database, then you're OK, according to this MSDN article:
Credentials (in the login packet) that are transmitted when a client application connects to SQL Server are always encrypted.
But if you also care about protecting the data, then you should read the rest of the above MSDN link to learn about enabling SSL to protect the rest of the data stream.
Note also this older article which gives a caution on using ODBC connection (rather than the native tyep). I doubt you would be doing that, but just thought I'd mention it.
From a client machine, it is unlikely that your database information can be sniffed. However, if your application "leaks" information, it is possible for an outsider to get sensitive information about your database. For example, if you have the CustomErrors parameter set to "Off", and your database is inaccessible for any reason, users may see your database's address and can then proceed to attack it using brute force or known exploits. There are other ways you can leak sensitive information this is just one example.
In general, it is not ideal to have your database open to the internet -- it is generally advised that your database be behind one (or two in case of a DMZ) firewalls. If you can control this, you should move it somewhere more secure. Or else even without your application leaking its address, a port scanning "war dialer" will eventually find it and alert the "bad guys" to its existence.
I am developing a framework for various in-house CRUD apps. I've considered several MS technologies (WPF, Access, WinForms, ASP.NET) and have settled on ASP.NET MVC with HTA+Jquery for the client. My reason for doing so is that I need a way to write and deploy quick one-off GUI apps as well as maintaining more robust apps that are expected to have a long life time.
Firstly, I would appreciate some thoughts on the relative merits of using ADODB on the client side versus ADO.NET on the server side. I'm leaning towards ADODB since I'll have client side access to the SQL Server (I've already written a js library that handles interacting with ADODB). However, I can see how developing a RESTful service may eventually be useful.
Secondly, I need to incorporate reporting capability into the system. I can use SQL Server reporting services or crystal reports but the users have grown accustomed to some older applications that use VBA to write reports in Word; so I'm considering using WordML to write the reports.
Thanks.
Database Access
If you need a thin client, then it's probably better to stay away from directly accessing the database from within the client.
The main issue is that you will introduce a high dependency on a specific network architecture and both your ASP.Net application and the HTA will be highly dependent on the database.
Instead I would prefer to sever the dependency on direct line of sight to the DB and have the data to be handled by the server.
This has a few advantages:
for many small changes to the db, you're probably only going to have to update the ASP app.
if you ever need your client app to be functional over the internet (say because some users are going to an outside meeting, need to work from work or your company open a new branch) then you won't have to rewrite your thin client.
you keep better control over access to the resources: only let the ASP app talk to the database and filter what comes in/out of it.
This will saves you having to implement all security on the client: the ASP app becomes the guardian of the database. It's a much better way to secure information and it gives you a lot more control.
Reporting
For reporting I'd use the server again rather than implement complex reporting capabilities in the client itself.
The problem is that you'll always going to get limited on the client if you're using an HTA and don't want to start having to install dependencies on each user's machine.
You'll end-up building a thick client in no time...
If you're using ASP.Net there are plenty of really good reporting tools that will make your life much easier and allow your users to get nice reports in Excel, Word, PDF, etc without you having to code these features yourself.
Crystal Reports is ok, but there are better and simpler alternatives, for example the Developer Express Report engine is pretty easy to use.
We need to make our enterprise ASP.NET/NHibernate browser-based application able to function when connected to or disconnected from the customer's server. Has anyone done this? If so, how did you do it? (Technology, architecture, etc.)
Background:
We develop and sell an enterprise browser-based application used by construction field personnel to enter timesheet information. Currently, it requires a connection to the server back in the customer's office and we'd like to build an occasionally-connected version of the application for those clients without wireless Internet availability.
Our application is an ASP.NET application using NHibernate for O/R mapping. Being a Microsoft shop, the Microsoft Sync Framework is attractive, but we don't know whether it "plays well" with NHibernate.
Any insight would be greatly appreciated.
Dave T
Maybe you could operate some kind of offline version using a small version database (I hear good things about vistadb - http://www.vistadb.net/ which I believe does play well with NHibernate). With a syncing tool to copy data in when they are back on line. A click-once launcher could handle installation and integration.
Want to be careful with anything involving syncing though - if it is just single user timesheets that might be OK - but if there are any chances of conflicts in the online-offline data you might be better considering the problem from a different angle for pain-avoidance...
Why not couple it with Google Gears? People put their data in while offline, and then they can sync it when they reconnect to the server.
In a modern world, using the HTML5 data store:
http://www.webreference.com/authoring/languages/html/HTML5-Client-Side/