Situation
So I'm thinking about building ASP.NET Core website to host it on Linux based hosting provider. But I still want to use MSSQL database, so best choice for that would be Microsoft Azure.
My Question
Now my question is rather security based, since I know, that hosting them on different providers is totally possible (Regarding this question)
But if I'm about to do so, then how will be my data encrypted? If I'm about to use default HTTP protocol, then I asume, it's not, but if to use HTTPS protocol, it should be encrypted as well? Or how would it work, do I need to setup some other protocols or security for that matter?
My Thoughts
Since Client won't be directly connected with Web Site to Database connection, then there is not chance, that this connection would be listened, yet this "might not be listened" is rather not a far chance. And if HTTPS is included, then all connections should be encrypted, then it should work same with Web Server to Database connection.
You can access Azure SQL from anywhere as long as IP address is in the firewall rule. Since communication to Azure SQL is on SSL/TCP at all times, data is already encrypted.
Ideally, you want to host Azure SQL and web application in same region not to mention same provider. The main reason is your website will be dramatically slow due to network latency, if you host those in different location.
Recently, Azure offers App Service on Linux. It is definitely worth the try, before considering an alternative route.
FYI: Web Apps on Linux does not yet support deployment of .NET Core apps from uncompiled source. You need to publish/compile your .NET Core app locally first, and then push the published site bits to your app.
Related
This probably sounds like an 'out-there' idea, but I would like to host non-HTTP services inside Azure Websites. I would like my code to be able to respond to FTP or SMTP requests on port 80, in addition to HTTP. Specifically, I would like to take in files from a net camera via FTP, process them, and store them in blob storage, etc. I'm aware I could do a VM, but Websites appeals to me because it is cheaper. Is this even possible?
At this point in time it is not possible to host protocols other than HTTP or Web Sockets in Azure Websites - now known as Azure Web Apps.
You can do it in Cloud Services or in VMs, but not in Web Apps.
You can submit feature ideas or suggestions to http://feedback.azure.com/forums/34192--general-feedback .
Hope this helps. Healy in Tampa.
I have seen variations of this question but couldn't find any that dealt with our particular scenario.
We have an existing aps.net website that links to a SQL Server database.
The database has clr user-defined types, hence it can only be hosted in Azure VM since Cloud Services don't support said types.
We initially wanted to use a vm for the database and cloud service for the front-end, but then some issues arose:
We use StateServer for storing State, but Azure doesn't support that. We would need to configure either Table storage, SQL Databases, or a Worker role dedicated to State management (a new worker role is an added cost). Table storage wouldn't be ideal due to performance. The other 2 options are preferable but they introduce cost or app-reconfiguration disadvantages.
We use SimpleMembership for user management. We would need to migrate the membership tables from our vm instance sql server to Azure's SQL Databases. This is an inconvenience as we want to keep all our tables in the same database, and splitting up the 2 may require making some code changes.
We are looking for a quick solution to have this app live as soon as possible, and at manageable cost. We are desperately trying to avoid re-factoring our code just to accommodate hosting part of the app in Azure Cloud services.
Questions:
Should we just go the VM route for hosting everything?
Is there any cost benefit in leveraging a VM instance (for sql server) and a Cloud Service instance (for the front-end)?
It seems to me every added "background process" to a Cloud Service will require a new worker role. For example, if we wanted to enable smtp for email services, this would require a new role, and hence more cost. Is this correct?
To run SQL Server with CLR etc, you'll need to run SQL Server in a Virtual Machine.
For the web tier, there are advantages to Cloud Services (web roles), as they are stateless - very easy to scale out/in without worrying about OS setup. And app setup is done through startup scripts upon bootup. If you can host your session content appropriately, the stateless model will be simpler to scale and maintain. However: If you have any type of complex installations to perform that take a while (or manual intervention), then a Virtual Machine may indeed be the better route, since you can build the VM out, and then create a master image from that VM. You'll still have OS and app maintenance issues to contend with, just as you would in an on-premises environment.
Let me correct you on your 3rd bullet regarding background processes. A cloud service's web role (or worker role) instances are merely Windows Server VM's with some scaffolding code for startup and process monitoring. You don't need a separate role for each. Feel free to run your entire app on a single web role and scale out; you'll just be scaling at a very coarse-grain level.
Some things to consider...
If you want to be cheap, you can have your web/worker role share the same code on a single machine by adding the RoleEntryPoint. Here is a post that actually shows how to do what you are trying to do with sending email:
http://blog.maartenballiauw.be/post/2012/11/12/Sending-e-mail-from-Windows-Azure.aspx
Session management is painfully slow in SQL Azure DB, I would use the Azure Cache if you can..it is fast.
SQL Server with VMs is going to cause problems for you, because you will also need to create a virtual network between that and any cloud services. This is really stupid, but if you deploy a cloud service AND a VM they communicate over the PUBLIC LOAD BALANCER causing a potential security concern and network latency. So, first you need to virtual network them (that is an extra cost)..then you also need to host a DNS server to address the SQL Server VM. Yes this is really stupid, unless you are OK with your web/worker roles communicating with your SQL Server over the internet :)
EDIT: changed "public internet" to "public load balancer" (and noted latency)
EDIT: The above information is 100% correct contrary to the comment by David below. Please read the guidance from Microsoft here:
http://msdn.microsoft.com/library/windowsazure/dn133152.aspx#scenario
DIRECTLY FROM MICROSOFT GUIDANCE speaking about cross Cloud Service communication (VM->web/worker roles):
"We recommend that you implement the first option as the connection process would not need to go through the public Internet. Therefore, it would provide a better network performance."
As of today (8/29/2013) Azure VMs and Worker/Web Roles are deployed into DIFFERENT "Cloud Services". Therefore communication between them needs to be secured via a Virtual Network that exposes private IP addresses between the instances.
To follow up on David's point below, that about adding an ACL. You are still sending packets over the internet using TDS (SQL Server protocol). That can be encrypted, but no sane architect/enterprise governance/security governance would "allow" this scenario to happen in a production environment.
There is an intranet based ASP.NET application that is deployed to a server (IIS) and a group of clients (about ten). The end user can then decide to either connect to the local application (deployed to their local machine) or the server version. I do not understand the reasoning for doing this. My question is: is this common practice?
yes, it is a common practice to verify the performance of the application. Each client will have their own settings and as per process, application should not break in any kind of environment. it is always beneficial to put a server version and a local version.
If the clients are laptops, and the application supports disconnected data sets and synchronization, it would make sense. Typically you'd see something like this when the client machines are taken off-network to be used at a remote work site.
I was planning to have my web application on one server instance, my sql (express) on another instance and a separate domain controller on another. The purpose to allow the asp.net application to access sql server under windows security. This is hosted on a cloud server. Am I getting any security benefit doing this considering its on the cloud server? For example, each 'machine' will have Remote Desktop active.
If it is better than keeping it all on one server instance, what else can i do to maximize security?
Well, separating servers out such that if one is compromised it doesn't lead to a compromise of all your data is a good thing, definitely. That's the main advantage you are getting.
You need to make sure, with the separate layout, that your SQL box doesn't allow connections (to the SQL server) from just any old IP; only the Web server (And, obviously, your external firewall would block that port anyway).
As to what else you can do? Perhaps ask on the networking forums. Many, many things come to mind :)
I'm in a process of designing a multi-tier ASP.NET web application that is supposed to deal with sensitive information (say financial data).
I would like to identify all potential threats the application will face in real life and plan the countermeasures accordingly.
Some details:
The application will be hosted in customer's data center for both internal and external users
Target platform is Windows Server 2008 + IIS7 or Windows Server 2003 + IIS6
Target DB is MS SQL Server 2008
Phew! Where to start... Depends on how "secure" you need it to be. i.e. Difference between a personal blog and a large project for a large company/government dept. etc...
In no particular order
Secure your configuration files by encrypting them.
Ensure that your Database is behind some sort of DMZ and not on a publically accessible IP
Get a security company to give your site an overhaul for potential vulneribilities (Cross Site Scripting / Sql Injection)
Use SSL
Lock down everything port-wise on the server except for 80 HTTP & 443 HTTPS unless absolutely necessary
Make sure your Remote Desktop/VNC connections to the box are secure
If your storing passwords in the DB, hash & salt them and don't store plain text
Publish your code, and don't leave source code on the server
Build your code based on known standards, i.e. don't write your own Crypto Algorithms
If secure connections between the Site->DB or Site-MSMQs are available, use them
Microsoft have a good article on securing ASP.NET apps that i'll dig out.
Edit
And as Syed just posted in his reply, (+1 a credit to him)
Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication
http://msdn.microsoft.com/en-us/library/aa302415.aspx
for multi layer security.
http://msdn.microsoft.com/en-us/library/aa302415.aspx#secnetlp_part3
that is a very large (broad) question, there are complete books on security that can not answer that. Go to Borders and get a few security books and start reading.