>> Welcome back. We've shown you some architecture diagrams of how
network security for Azure SQL Database
and Azure SQL Managed Instance works.
Now we're going to take a look at how you actually implement
and verify each of those different options.
Here I'm in the Azure portal and I've
navigated to my logical SQL Server,
so my logical SQL database server.
If I scroll down on the left,
I see a lot of options,
but the one I want to look at is firewalls and virtual networks.
Now you'll see a few options that are selected by default here.
One to point out is the connection policy we've
talked about recently is set at the default,
and the other that we set up during deployment is allow
Azure services and resources access to the server to On,
and we also added our client IP address.
This is currently how we're connecting,
and like we learned,
turning this to No or Off is a more secure configuration.
Now since I've already added
the IP address of the VM I'm connecting with,
I should just be able to set this to No,
save it, and still be able to connect.
We're just going to run that and do a quick test in
Management Studio to make sure I can connect.
So I'm going to do a New Query,
looks like we're able to connect and run a query.
Now what you're seeing down here is the client net address.
Basically from dm_exec_connections I'm able to identify
what IP address I'm connecting to Azure SQL Database with,
and this matches the public IP address of my virtual machine,
which I'm using right now,
which is what you're seeing on your screen.
Now, the next option that we talked about is
actually using virtual network rules.
I could actually delete
this firewall rule and add an existing virtual network.
Now to make it easy,
I'm going to call this VmVNet and I'm going to connect
it to the virtual network that
this virtual machine is deployed in.
If you remember the architecture from before,
this is just going to make it easier for me to connect.
I'm not going to have to add anything else.
The other thing you'll notice is I had to enable the
Microsoft.sql service endpoint on that virtual network.
That's just going to let the virtual network
know that this is going to be something that's allowed,
that we're going to be able to connect to
SQL services from this virtual network.
I'm going to hit Okay and it's going to validate
that and then we'll be able to save what we've added.
Now it is done, I can go ahead and save my changes and ideally,
even though we've turned firewall rules off,
or we deleted all our firewall rules,
we should still be able to connect
because we're in this virtual network.
I can switch back to SSMS and I'm
just going to create a new query,
and we see we're still able to connect.
Now the difference that we're seeing is now I
ran this same command to get the client net address,
and it's coming back as 10.0.0.4.
Now you might have an idea of what this IP address is,
but what it is is it's actually the private IP address of
this virtual machine I'm connecting with Azure SQL Database.
That means, now my connections went from coming through
a public IP address to coming from a private IP address.
This is really a step in the right direction,
but the other thing that we can use is this thing called NSlookup.
An NSlookup is going to be able to
tell us for a given database logical server,
what the DNS hierarchy looks like from a public standpoint.
When I run that, you'll see a few things.
One is the name and so what you're seeing here is
actually pretty interesting information
about where this database is deployed.
So cr5 might indicate control ring five.
We're getting indication of the region where it's deployed,
as well as a public IP address and some information about
the data slice within the control ring
of where this database might be located.
Now this is a lot of information that we
might not want to be publicly available.
Even though we're connecting from a private IP address,
information about the public DNS hierarchy
is available on our server.
The next thing I can do is set up private Link.
To do this, I can simply go into
the Azure portal and search for private link,
and what you're going to see is there are
several services that support this idea of a private endpoint.
This is not just an Azure SQL Database thing,
this is available for other types of resources as well.
I'm going to go into Private endpoints
and I'm just going to select Add.
Similar way to deploying an Azure SQL Database,
I'm going to be given a similar blade to follow.
Now I'm going to call this my aw server,
just the name of the server,
and then pe for private endpoint.
I'm going to put it in the same region as my Azure SQL Database,
but I could technically put it in another region as well,
because it's just going to be a pointer to the database.
From here I can specify which resource to connect to.
You're seeing all the different options available,
but I'm going to select SQL,
I'm going to select the server we want to
do and that it is a SQL Server,
and that's really my only option here.
Next, in configuration I'm going to specify
the virtual network I want this deployed in,
and just for ease of use,
I'm going to put it into
the same virtual network that
my virtual machine we're connecting to now is.
That's just going to make it so I don't have
to add any additional rules,
my virtual machine and
this private endpoint will be in the same virtual network.
I can also choose to integrate it with a private DNS zone,
which I've gone ahead and created here.
Finally, I can add tags like we learned
about in an earlier module,
and I'll do this again to my development environment.
I can hit Review and Create,
and go ahead and spin off that private endpoint.
Now this is going to take a minute or so while it deploys.
Once it's deployed, you'll see a similar screen as to what you see
after you deploy something like a database or a managed instance.
But I can go ahead and go to that resource.
Sure enough, what we'll see is that it's linked to
my Azure SQL Database logical server,
and it now has its own private IP address.
Now if I go back to SSMS,
I should be able to refresh
my connection and still be able to connect.
Sure enough, we see that I can do that and I can
even run the same query that we ran before.
But I'm not going to see anything different here,
and the reason is,
we're still connecting from inside our virtual network,
similar to our virtual network rules.
Since my virtual machine and
my private endpoint are in the same virtual network,
they can communicate using things like a private endpoint here.
Where we are going to see a change is if I switch back
over to the command prompt and run that same NSlookup.
Notice I'm not changing anything from the previous one,
we are going to see something very different.
What we're seeing here is we're definitely
seeing less of the public DNS hierarchy.
We're not seeing that control ring,
the data size, rocketing,
any information related to that and we're even only getting
a private IP address which isn't going to do us much use here.
One of the beautiful things about private link is
that there's no change to be your connection string.
You notice that we set this up and we didn't have to start
connecting to private link in the name or an IP address.
In fact, you can not connect,
you can only connect using the standard way to connect,
even if you weren't using private links to begin with.
In this video, you are able to see a survey
of the options that are available for you,
for Azure SQL Database,
and your Network Security,
as well as how to configure them.
See you in the next video.