When you're creating an SQL server on Azure, there is the option to
"ALLOW WINDOWS AZURE SERVICES TO ACCESS THE SERVER."
Does this mean that some other application (other than my own applications) hosted on Azure, like a website, can access my sql server?
There is username password, of course, but I'm afraid they can be brute forced.
Is this a legitimate concern?
Yes, "Allow access to Azure services" is a shortcut that allows any Azure-hosted service through the firewall (though the other service still needs to know the server name and a SQL Authentication username/password, as you mention). This shortcut is for convenience, since your app's IP address can change if the VMs in your cloud service fail over or shut down.
To avoid using this shortcut, you could create a reserved virtual IP address (VIP) for your cloud service. This allows your app to have a persistent public IP address, which you can specifically and selectively allow through the server firewall for your SQL Database.
Related
I deployed a web app on Azure App Services. When web app tries to connect to the Azure SQL Database connection failed.
I downloaded the event log from Kudu, I found the following error message:
Cannot open server 'servername' requested by the login. Client with IP
address '**************' is not allowed to access the server. To
enable access, use the Windows Azure Management 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..
On Azure portal I found how to set server firewall by adding a range of client IP addresses (with lower bound and upper bound) according your client IP address. For instance, if client IP address is 00.000.000.09 the range of IP addresses is: low bound (00.000.000.0) and upper bound (00.000.000.255).
I set the server firewall for the IP address assigned to my Azure App Services account and also for my local machine to connect to Azure SQL Database from SQL Server Management Studio. After setting firewall, I can connect to Azure SQL Database with SQL Server Management Studio. Unfortunately unable to connect from web app. When I download event log from Kudu I find the same message error.
Someone could help to solve that issue.
Thanks.
Go to your SQL Server in Azure Portal.
Go to "Firewall and Virtual Network".
Turn on "Allow Azure Service and resources to access this server".
Allowing Azure Service and resources to access this server may not be the correct approach. This may be a security issue in many cases. We have to create managed identity and assign to webapp or sql server where required.
We are building a client solution that will be hosted on servers in a data-centre. It consists of several servers all related to providing the client solution. There is no internal network to protect but for some reason our UAT environment has the notion of a DMZ in the server diagram.
We have an IIS box which will have a public IP. Then we have two servers DB(Sql Server) and APP that are only on the internal lan with no public IPs. You can only RDP to these servers via VPN. Our IIS server needs sql access so port 1433 is open from IIS box(DMZ) to the sql server. We are also opening several ports from the IIS server to the APP server which hosts WCF services.
My understanding was that a DMZ was meant to protect internal private networks and that these networks should not be accessible from the DMZ but we are now opening up ports to both our APP and DB servers so they are accessible from the DMZ. In the end most of our servers are accessible from the IIS server via certain ports.
We originally wanted to setup our SQL server for AD authentication only but since our IIS server is in the DMZ and has no AD access we will be forced to enable mixed mode authentication in SQL server. This might be another security issue in it's own since we are now forced to store passwords somewhere on the IIS server to be able to auth against sql server.
Are we not perhaps missing the idea of a DMZ?
So with a system where you have a DMZ, there is also a firewall involved.
So your system should look like this I think:
SQL-server hosting internal data
Other servers needed for the company
---- firewall ----
SQL-server hosting data for web solution
AD-server (if needed)
Web-server
FTP-server (could be on the web server also)
With this setup you don't expose company-sensitive database to the outside world and you also don't open up a port in the firewall making it possible for attackers to (maybe) get access to the internal database which has company sensitive data...
Just my suggestion based on the information provided.
I am setting up a system that runs on Azure but needs to access an on-premises SQL Server. I've built it out as detailed in this article. This calls for me opening port 1433 to the world which looks like a serious security problem. Is there any way to open that port and still have it secure (I know that I can have complex user ids and passwords and everything, but is there a better way to secure SQL Server)
The connection between your on-premises DB and Windows Azure Connect will be secure by default via the IPSEC protocol
"Windows Azure Connect uses industry-standard end-to-end IPSEC
protocol to establish secure connections between on-premise machines
and roles in the cloud. Unlike a traditional Virtual Private Network
(VPN), which establishes secure connectivity at gateway level, Windows
Azure Connect offers more granular control by establishing secure
connections at a machine and role level."
http://blogs.msdn.com/b/usisvde/archive/2012/03/14/windows-azure-security-best-practices-part-6-how-azure-services-extends-your-app-security.aspx
Your DB won't be publicly available, only VM's on the Azure Connect will be able to see it.
Your traditional firewall and on-premises security policies and procedures will still hide your DB in your Enterprise Environment, all you are doing is giving Windows Azure VM (Roles) the ability to see it.
I saw the comment discussion on #user728584's answer about opening port 1433. Port 1433 has nothing to do with Azure Connect, which is essentially a VPN tunnel between on-prem boxes and a collection of Windows Azure role instances. Azure Connect requires an agent to be installed on any on-prem server you're adding to the Connect Group and doesn't require an inbound port to be opened. In your case, you'd add the agent to your SQL Server box, which would then be part of the connect group and accessible directly from your Windows Azure Role instances (for the roles you add to the group). The Connect Agent then establishes the tunnel.
The Connect Agent has a special key baked in, generated for you, making it unique. But even if someone somehow obtained the installer for your specific Connect Agent, it wouldn't help at all, as you still need to add that node to the Connect Group. So, this is a secure setup.
I am trying to use IIS 7.5 Application Pool identity as login on SQL Server 2008 R2 so that my ASP.NET web app can connect to the database...
Using this approach worked fine on my local dev machine (IIS 7.5 and SQL Server 2008 R2 on same machine).
However, when I try to set up the same on production (IIS and SQL servers are separate) I am unable to add "IIS APPPOOL\MyAppAppPool" login to SQL Server 2008 R2.
Notice that in either case you cannot use "Browse..." when creating a login in SQL Server since "IIS APPPOOL\MyAppAppPool" user identity is dynamic (or "special")...
Any ideas?
Update:
For more info on Application Pool Identities see here.
From article:
Whenever a new Application Pool is
created, the IIS management process
creates a security identifier (SID)
that represents the name of the
Application Pool itself. For example,
if you create an Application Pool with
the name "MyNewAppPool," a security
identifier with the name
"MyNewAppPool" is created in the
Windows Security system. From this
point on, resources can be secured by
using this identity. However, the
identity is not a real user account;
it will not show up as a user in the
Windows User Management Console.
That articles states (under "Accessing the Network") you still use the <domainname>\<machinename>$ aka machine account in the domain.
So if both servers are in "foobar" domain, and the web box is "bicycle", the login used to the SQL Server Instance is foobar\bicycle$
If you aren't in a domain, then there is no common directory to authenticate against. Use a SQL login with username and password for simplicity
Edit, after comment
If the domains are trusted then you can use the machien account still (use domain local groups for SQL Server, into which add a global groups etc)
As for using app pool identities, they are local to your web server only as per article. They have no meaning to SQL Server. If you need to differentiate sites, then use proper domain accounts for the App Pools.
You can't have it both ways...
I have a web service that stores data in a local SQL Server 2008 database. If I run the web service under my account the web service can successfully access the database. However, if I use the DefaultAppPool (IUSR) account then accessing the database from the web service fails.
How do I set security on SQL Server to allow access to a specific database via IIS?
The specific error message I am getting is:
Login failed for user 'IIS APPPOOL\DefaultAppPool'
You have two options (obvious maybe!):
Instead of using Windows Integrated
Security use SQL Authentication
instead.
If you can't or don't want to, then you have
to create a new user in SQL Server
that relates to that Windows account.
Or (third option) you can change the web service to run under an account that you know works.
I generally run the app pool under a domain user account, that way you control the specific user for each site on your server.
If I can't use a domain account, I'll run the site as "Network Service" - and the user that would correspond to that in SQL would be the machine account (MACHINENAME$ - replace "machinename" with your IIS server name").
If you plan to use the new IIS7 IIS users - which are not windows users - you'll have to use SQL Authentication instead of Windows authentication for your SQL database access.