perhaps this isn't the best place to ask this, but I wanted to be educated.
I would like to have a Google sheet interact with data on an oracle server.
I have been reading the Google Apps Script guide for setting up JDBC connections, and note that I would need to whitelist a range of IP addresses in order for this to work.
I was told by our infosec department that our db is only allowed to be accessed by onsite servers or through VPN connection, which negates using Google apps script JDBC.
My question is: what is the risk of whitelisting these IP address ranges, is spoofing a google app script IP address within the range plausible or overly cautious? What other factors am I not aware of that I should be considering?
You are correct in that Apps Script needs you to allow your database to accept connections from Apps Script in order to use JDBC with that database. There is no reasonable workaround that would not also violate the rules your infosec department has put in place.
As for whether those rules are overzealous, bare in mind that security folks need to be very cautious as a rule. This discussion on StackExchange may be helpful.
Related
So, I've been reading about security in relation to desktop applications and database servers. Previously when I've built applications that are linked to a database, I've taken the easy route and simply stored the connection string hard coded in the source code directly. This has worked since the binaries were not distributed to third parties. However, now I'm working on a project whose binaries are bound for third party use, and in this case the communication with the server becomes a security issue that I need to deal with.
Since it is a priority that there be no direct connection to the remote database from the client machine, I understand that a server/client database service is a good choice. In this case, the client machine sends requests using TCP to a server, which then processes the request using stored procedures and responds accordingly to the client.
My questions in relation to this are:
i. Would this setup be an advisable one, or are other setups of which I am unaware more advisable for the kind of project I am working on?
ii. How does one go about securing such a connection? I can easily set up an SSL connection to the server using a security certificate generated by OpenSSL, however I'm not sure whether this is the correct way of securing the connection for a desktop application, or whether this method is primarily used for HTTPS. And WHEN should one in general secure the connection (are there instances where this wouldn't matter, for instance if all I do is send booleans back and forth?)? Any good resources that discuss these issues? For instance, I have a lot of application installed on my Windows PC that are networked, but I don't see many of them installing a security certificate on my PC. What gives?
Full disclosure: I'm a C++ (hobbyist) programmer using Boost libraries for my network programming needs and OpenSSL for my SSL cryptography. However, I hope this can be answered without paying too much attention to these facts :)
Answers:
i. Having your application talk to a web service that then talks to the database is a better setup. This abstracts the database away from the clients (and therefore direct access from the internet).
ii. This depends on what the threats to your system are. If the data you are vending from the web service mentioned above is data that is not sensitive, and is not user specific (say an app that allows searching of public photo galleries, so your web service simply returns a result set with URLs) then you might be able to get by with simply using SSL. Other apps get around installing their own cert in a myriad of ways. They can either get a cert from a CA like verisign, so your computer already trusts it. Or they can deploy the public cert with the binary of their app, and handle it inside of their app (this is a form of certificate pinning).
ii part 2. If you need the clients to authenticate, for reasons of either wanting to make sure that not just anyone can use your web service, or to support a more advanced authorization model, then you would need to implement some sort of authentication. That would be a much bigger question to address.
Make sure you use CA-signed certificates, and not self-signed. You might also want to consider mutual authentication between your service and the database.
it might be a simple question but as I couldn't find the best answer on google I would like to know your thoghts.
I'm thinking of changing a software I've made in WPF accessing its data from a local server to a cloud server (maybe Azure).
What's the best way, connect directly to the database or access through a service in the clould (that would have to be developed by me I guess).
Thanks!!!
In general, I would guard against directly accessing a database hosted in the cloud via a client application. You'll be exposing your database endpoint through the public internet providing a significant attack vector.
By using a service, you can limit that attack vector. The service itself is also 'exposed' but can be locked down (typically more effectively/easily) with authentication/authorization protocols like OAuth, AD, etc. AND the service itself would expose only the operations necessary for the client application, versus access to the complete database schema (should someone crack the password when the database is on the open internet).
You didn't mention if you were planning to use Windows Azure SQL Azure or your own database in IaaS. You can, of course, implement your own security via firewall, etc. on VMs hosted in Windows Azure, but that's another infrastructure task you'll need to accommodate, and if your client IPs change, etc., then managing that is not insignificant.
I think the answer to the question would be the same whether you'd be on Azure or not.
A service adds an abstraction layer between the application and the database, which may help with maintenance in the long term, but it does have a cost associated with it (in terms of initial effort) and some potentially performance penalties (although this does not have to be significant) so in the end you'll have to weight it according to the application.
I really do not think there's a one-size-fits-all answer to this.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Does Google have to make significant infrastructure costs to support SSL on custom domains? Does it have to buy IPv4 address space or something? I'm not very familiar with this technology, and I don't understand why SNI/VIP costs $120/$1200 per year.
This post http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html claims that it's not CPU or network costs of SSL, and I believe you have to provide your own SSL certificate. So why is it so expensive to provide HTTPS support for GAE?
Edit: This questions seems to be quite popular, but as yet has not had a satisfying answer. I'm interested in the technology behind providing SLL on custom domains, and I don't think the answer is "Google likes money", given their enormous push towards SSL on many of their products, and encryption built-in to SPDY.
Further edit: A related/extended question would be "Why does the cost of SSL on custom domains not scale with the size of the app?". All other costs (bandwidth, number of instances, data storage etc.) scale as you grow. SSL on CD is all up front, and prohibitively expensive for small apps, though as people point out, fixed and therefore a very good deal for large apps. Does anyone know why they chose to charge like this?
We announced the new pricing for SSL VIP at:
http://googleappengine.blogspot.jp/2012/09/announcing-new-pricing-for-virtual-ip.html
Now VIP based SSL costs only $39/month.
We also say the following in the post:
Google App Engine SSL for Custom Domains goes above and beyond the basics of SSL by offering globally distributed SSL endpoints and built-in load balancing. Like App Engine in general, there is no need for ongoing system administration and maintenance.
Google App Engine SSL is not just a certificate storage, it also provides distributed endpoints and built-in load balancing. In other words, it is not one single server running apache with your certificate.
Hope this answer helps.
I think that Google has had to make significant infrastructure changes in order to support SSL on GAE. This has been a long standing feature request so I for one am happy that it is finally here.
SSL was always supported on *.appspot.com URLs. Just not on your own domain name. The reason is not the 'computational' cost but the fact that for SSL to work the server that handles the requests for your app will need that SSL certificate.
So how does that scale when you've got a million of those machines? Not to mention the fact that you need to distribute the certificate everywhere. Then there is the problem that its not just your SSL certificate but one certificate per app that wants SSL and the fact that they will need to allow app owners to purchase, upload and replace the certificate.
The SNI/TLS option is cheaper but requires OS's and Browsers etc. to support it because this solution uses an extension called Server Name Indication (SNI) that allows Google to 'select' the SSL certificate dynamically based on that 'server name'. Older implementations of SSL will probably not support this.
The VIP option is more expensive because it assigns a dedicated IP address to your application. This solution does not require SNI.
So I guess that if you want to be absolutely sure SSL will work everywhere, then go for VIP.
The cost of any feature is just another thing to consider in your business plan. I am not convinced that the amount you are referring to is going to be a show stopper for those that would really benefit from the feature.
Foremost Google offers two kinds of SSL for custom domains.
Server Name Indication (SNI). This is an extension of SSL where multiple domain can share the same IP but it's not supported by old broswers or windows XP (Not recomended for commercial applications) however this option is cheaper.
Virtual IP (VIP). SSL certificates basically links a Domain to one IP, and two domains cant have the same IP, so yes google has to buy a Range of IP to support this feature.
But the more important reason for that prices is that SSL in custom domains is a "must to" for commercial applications so they take advantage of that.
It's just a business: cool optional features for cloud hosting are always expensive.
And
Yes, certificate price is not included
I'm not sure how does Google Frontend (their web server) works and how does it expensive in terms of CPU/memory certificate usage, especially as high load solution.
It took some time for them to implement the feature. And time is money, so maybe they just want their money back.
I'm looking to develop an application for Mac and iOS-devices. The application will rely on information stored in a remote database. It needs both read (select) and write (insert, update, delete) access to the database. The application will be a multi-user application.
Now I'm looking at two different approaches to access the database:
- via web service: the application accesses the web service (REST, JSON) which accesses the database. Authentication will be done via HTTP authentication over SSL (https).
- access the remote database directly over a VPN.
The app will be used by a maximum of let's say 100 people and is aimed at small groups/organizations/businesses.
So my question is: what would be the best approach to access the database? What about security and performance? What would a typical implementation for a small business look like?
Any advice will be appreciated.
Thanks
Using web services adds a level of indirection between the clients and the database. This has several advantages that are all due to the fact that the clients need to have no knowledge of the database, only of your web service interface. Since client applications are more complicated to control and update than your server side code, it pays to add a level of business logic on the server that lets you tweak your system without pushing updates to the clients. Main advantages:
Flexibility - you can change the database configuration / replace the data layer altogether and change nothing on the client apps as long as you keep the same web service interface.
Security - implement some authentication mechanism for your web services, and avoid giving clients access credentials to your database engine.
There are some disadvantages too: you pay for that flexibility by adding a level of complexity - it'd probably be faster to just code the database access into the clients and get done with it. Consider the web services layer as an investment that might pay dividends down the road. Whether it's worth it really depends on your business requirements and outlook.
Given the information you have provided, the answer is almost certainly web services, unless the VPN is fast.
If the VPN is fast enough to handle the traffic, you will save a lot of time, effort and expense by accessing the database directly from your application.
You can also provide remote access to virtual PC sessions, if that's your thing.
So it's all going to depend on what your requirements are. There are a lot of ways to do this, and each has its advantages and disadvantages. Making the right decision will require a fair amount of systems analysis, probably beyond the scope of a question posted on StackOverflow.
From my last question, I have new idea for database protection. The following ports will be connected via SSL only. Is it possible to hack this database server?
Http Port for sending & receiving data via WCF Services or Web Services.
Ftp Port for updating above services.
PS. This question is not include SQL injection problem.
Thanks,
In practice, you can never make your server hacker-proof. As long as hackers have some means to send data to the server, they can potentially exploit security vulnerabilities to do bad things. Limiting the server's surface area, using encryption, and so on all help and make it less likely you'll get hacked, but you're never 100% safe.
It's possible to hack just about anything. Your HTTP or (especially) your FTP server could have security bugs in it which open a backdoor. These could be anything from arbitrary code execution under root/Administrator or full filesystem access.
I assume also that your database server is also not bug-free, and could expose all your data.
Obviously, though, having as few ports as possible open is better.
Everything is possible, but sure this decrease the possibilities.
you can still guess/predict/keylog the username/password and get in
I always tell people the only hack-proof server is the one that is unplugged and powered down in the closet.
It is important, when presenting a security solution, do identify what kind of intrusion you are attempting to guard against. Even with only three ports open, even with one for that matter, a successful dictionary attack against accounts accessing the server via FTP port could do some damage.
As a general rule, we do not expose our databases directly outside the network/firewall. Only web or user application servers have exposed ports but nothing that isn't behind the firewall can directly touch the database servers.
This is still vulnerable several ways:
Man in the middle attack against SSL if you don't have proper certs set up
Input handling exploits in your httpd, ftpd and operating system
Social engineering
That doesn't mean it's not a good idea to do things this way, but it's dangerous to think this, or anything really, is "hack proof". I'll spare you the typical wisecrack about windows security.