We have developed ASP.NET Application using SQL Server Database & hosted in our Company Intranet Server. The Application using Forms Authentication which checks user in the Active Directory. We have not concentrated much on Security checks due to its in Intranet. Now our question is what are the possible security risk we need to concentrate on our Application If we host in Amazon Server. Also Can we get separate Account like VPN to access our Application in the Amazon Server?
Yes, you have to concentrate on security as the AWS are for internet. Check if you can encrypt the data. Also, it differs from organization perspective. Check with your IT department first.
Related
I am creating an ASP web form hosted on a public Microsoft web host. I need it to access a SQL database located locally on our internal network. I have developed a web service that talks to the ASP web form, but I don’t know where the web service should be located and how to get the data from the ASP web form to the local SQL database on our network.
So it's really two questions:
Where should the web service be located? On the public Microsoft host or on the internal network host?
How would the web service get the information from the public ASP web form to the internal SQL database?
Regarding the first question:
I guess you mean that the web server contacts the web service, not the other way around.
My guess would be to have the service at your company network if you want to contact the database for more than one application.
If there is no need for the database over there, i would place the service, database and web server to the cloud you are using, since this is better for availability and performance.
Regarding the second question:
You could look into some basic database interaction code like in ADO.NET or Entity Framework. Use MSDN as a starting point.
Do you mean Azure, when you say MS web host? Azure (and other cloud services) allow you to create a site to site virtual network e.g on Azure: https://azure.microsoft.com/en-us/documentation/articles/vpn-gateway-site-to-site-create/
If not Azure, but something like Rackspace they often have similar functionality: http://www.rackspace.com/knowledge_center/article/configure-a-site-to-site-vpn-using-the-vyatta-network-appliance
With this network configured, you could connect securely to your local SQL instance.
Latency and line speed will limit performance, obviously. You would need to experiment. Ultimately it would probably be better as suggested in the other answer to host your database in the cloud too.
I deployed my MVC 4 application on Azure, installed own CA, create self-signed certificate and certificate for server (https working good). How can I activate require client certificates signed by my CA and working only with it?
The two viable options you have, you already described in your comments.
One is to use Azure VM and IIS (I don't like it) - there you know what to do.
The other one is to use a Web Role (Cloud Service) and do the things described in the link you refer to. I advise you to take the Web Role path.
Or third option, is to wait until (if ever) Windows Azure Web Sites to unlock the required property in application host config. Check this SO question and it's answer on what you need to do in your web.config in order to achieve your goal. The catch is that access section under system.webServer/security is locked at application host config level, and can only be unlocked when you have Azure Web Role.
Just fyi, here is a list of overridable sections in your web.config when you use Azure Web Sites.
I have an existing VS2010 ASP.NET webforms site that I am trying to get running on Azure as a POC for a client.
I migrated the site to a VS2012 project, added an Azure Cloud Service Project, and have deployed the site as well as the back end DB to a 3 month trial account.
I've added the IP address of my dev machine to the firewall rules for the Azure db, and I can run the project locally and connect to the Azure db without incident.
On the firewall rules for the website, I have Windows Azure Services set to yes under Allowed services. I have no other rules in place other than the one for my dev machine.
When trying to access the site from the site deployed to Azure, I get the following exception:
Cannot open server requested by the login. Client with IP address '137.135.65.13' is not allowed to access the server.
To enable access, use the SQL Azure Portal or run sp_set_firewall_rule
on the master database to create a firewall rule for this IP address
or address range. It may take up to five minutes for this change to
take effect.
Login failed for user .
This session has been assigned a tracing ID of . Provide this tracing ID to customer support when you need assistance.
The site works normally if I add a firewall rule for the azure server IP address, but doesn't this defeat the whole purpose of Azure? Shouldn't allowing Azure services handle this? Is there an additional config item necessary or am I missing something basic in the design? I'm not sure if this is related but the site was deployed by VS2012 as a cloud service instead of a website, is this the issue? I also added the db as a linked resource in the cloud service but that didn't seem to have any effect.
Adding the DB as a linked resource for the WebSite will fix the problem w/out having to muck about with firewall settings.
Go to your website in m.anage.windowsazure.com.
Go to the LINKED RESOURCES tab.
Press the LINK button on the bottom of the page
Select your DB from the modal dialog
This is a bug in Azure. Newer IP ranges aren't included in their boiler plate "Azure Services" configuration, or something like that.
Been happening for a long time (at least ~3 years), unfortunately.
Happens with Web Roles, Worker Roles, and VMs as well - NOT specific to Web Sites. We regularly hit this with our Web and Worker Roles in US East but never saw it once in US North.
Our work-around is to add the range: 10.0.0.0-10.255.255.255. Probably not the most secure work-around but fortunately, this has so far only hit our Dev environments and not any of our Production environments.
Here's the situaiton. I'm working on developing a new website to access an old database. This is a DoD installation so there's lots of security around.
The current application is written in classic ASP, VBScript and some javascript. The new systems is ASP.NET.
Accessing the database in the old system meant hitting the server with your own credentials (domainname\username). Now I'm trying to test some of the early development I've done. When I used Cassini (under VS2008), I had no trouble getting to the database because ourdomain\myusername registered with the SQL Server instance as a trusted connection. Due to security aspects that I have to write, Cassini can't serve as a test server anymore - I have to use IIS (we have security card readers here). Cassini can't handle them.
So when I went through all the problems of getting the appropriate accounts added to Administrators on my local pc so that I could debug in VS2008 while using IIS, I tried to connect to the database and I was rejected because MYPC\ASPNET was not a trusted connection.
Altering the existing database is out of the question. Hard coding usernames and passwords for access to the database is out of the question.
I asked the DBA if he could add MYPC\ASPNET to of the domain groups so that SQL Server could see it as a trusted connection (since MYDOMAIN\MYNAME was in a group that was seen as a trusted connection). He tells me that is not technically possible.
In the end there are going to be three or four machines (mine, another developer, the eventual live web server and a future test web server) who's ASPNET accounts are going to be hitting our two SQL servers (live and test).
What do I have to do to make the existing SQL server see me as Friend and not Foe? I looked at impersonation but I get the impression it's not compatible with our system - the business rules make a call to a common routine to create a SqlConnection object and open it (maybe even a SqlTransaction object to go with it) and this object is used for the rest of the business rules and data-access layer until it's done. It didn't look like impersonation would persist once the SqlConnection was opened (and passed, ByRef back to the calling routine)
Thanks in advance for any advice.
You have two options:
Run your web application in an application pool configured to run in the context of a domain account
Use impersonation and configure your web application to use windows authentication only
Use Impersonation
As has already been suggested you should use impersonation.
However if your SQL Server is running on a different machine than your web server then impersonation will not suffice as the credentials of the user will not be delegated to the SQL Server (server hop). In that case you will have to either enable delegation in the AD or create a non-Windows login on your SQL Server and use that instead (this will not work if your SQL Server actually uses the Windows login for access control to tables etc.).
Sounds like you want to impersonate the client who is accessing your web site correct? Have you tried to use impersonation or are you assuming it won't work?
Edit
As Albert points out, impersonation requires the user to be authenticated using Windows authentication. You will want to disable Anonymous Access, and enable Windows Authentication in IIS Management tool.
Best practice says to keep my web app and database on separate machines, but when doing that it seems I can't get a clear explanation on how best to make this connection. Whil windows auth is the recommended authentication, I don't see how to make a trusted connection . Must I use impersonation to have my application connect to a db server?
Are most people simply using SQL authentication in this case?
Both machines are on a virtual cloud network.
If both computers are in the same domain, I'd use Windows Authentication for the SQL connection. To set it up:
Create a domain account to use for the app.
Give the id the absolute minimum priveleges necessary to host the site on the web server. For example, it must have read access to the web site itself, write access only to folders updated by the web site, etc.
Change IIS so that the domain account is used to run the app. In IIS6 & IIS7, you do this through the application pool. In IIS5, you have to change the settings in the machine.config or in the web.config for the ProcessModel.
All calls to the database will be done through this domain account; you won't have to setup impersonation. In fact, if you are using SQL authentication today, the only change you need to make is to the database connection string; no code changes are needed.