>> One of the first lines of defense is your network security.
We're going to spend
some time talking about the different options,
and how networking works for
Azure SQL Database and Azure SQL Managed Instance.
What you're seeing here is something
that might be a typical scenario where you
have a virtual machine in one virtual network.
Each of those dotted lines represents
a virtual network so this would be US East on the right.
You might have another virtual network with other things like
Azure VMs in US East but in a different virtual network,
and that's on your top left.
In the bottom left,
you might have another virtual machine or an application or
another service running in West US in its own virtual network.
Additionally, you might try to connect from On-prem,
and ultimately you're trying to connect
to the database on the right,
which doesn't technically sit in a virtual network.
Right now, we're just talking about Azure SQL Database.
There are a few options, four main options for setting up
connectivity from a network security standpoint.
The first is allowing access to Azure services.
This is the easiest and what this
is going to do is just by default,
allow any Azure service,
whether it's in your subscription,
another person subscription outside
of your organization or just a different service in Azure,
if they have the credentials to login, they'll be able to.
That's the first way,
and as you might guess,
this is probably of all the ways,
the least secure because you're opening up your database
for other opportunities for people to try to connect to it.
Now the second thing you can do is you can apply firewall rules.
What this is going to do as you see,
we allowed all the same things
except we can also now enable On-premises,
which is something you couldn't enable with just
allowing Azure service access to services.
Now, one other thing you'll note
here is that I'm going to have to create
a firewall rule for
every single service that I want to be able to connect to it.
If I have applications and virtual machines with dynamic IP,
this is going to pose somewhat of a challenge.
In addition to that,
when I connect to my SQL database,
I'm coming through the public IP address,
in this case VMs,
but it could be applications or other services as well.
If what you see on the right is how you're going to be
able to view the DNS hierarchy,
you're going to be able to see the region,
someone with the control ring,
and an IP address.
The next level of security that you can do,
which also helps from a management perspective,
is virtual network rules.
Now, a few things that you'll notice have changed here.
I'm no longer connecting directly from a service to a database.
The reason is I've given a virtual network rule to
this main virtual network in East US on the right,
and basically said, anything in
this virtual network can connect to that logical database server.
That's going to allow my Azure Virtual Machine that's in there,
and it's also going to allow it to connect from
the private IP address of the virtual machine.
This is a subtle change,
but this means that we're one step closer to
getting a fully private connection to the database server.
Now, I've only added a virtual network rule,
in this case to that single virtual network in East US.
However, I can use
other virtual network tools which are
commonly known like Virtual Network Peering,
VNet to VNet, VPN or ExpressRoute from On-prem,
and VNet gateways to basically
connect to these virtual networks together.
Now, we don't want you to get bogged
down on these types of details.
Really, the thing to see is
that by adding access to virtual network,
I can add access to all of the things in the virtual network,
as well as take into account things like dynamic IP addresses.
This can make managing easier, and again,
it's slightly more secure because we're going through
the private endpoint of these various services.
Now at the end of the day, over on the right,
you still see the public DNS hierarchy.
Anyone can run an NS Lookup and
find out more information about your database,
and try to connect to it.
The most recent thing that we've done,
and this went GA earlier in 2020,
is add this thing called Private Link.
What that allows us to do is actually deploy
a private endpoint into a virtual network.
In this case, you see I have deployed a private endpoint
into that main virtual network in East US we've been using,
and this is going to allow me to connect
directly to that logical server,
but it's the only way that I'm going to be able to
connect to that logical server.
This means that for anything
to be able to access that logical database server,
they're going to need access to this virtual network.
From a configuration standpoint,
it doesn't require much more than Virtual Network rules,
but it does give you this added layer of security because now
there's only a private endpoint for your logical database.
Even if you tried to hid the public DNS hierarchy,
you're only going to get private type of
endpoints which aren't going to help you connect to the database.
That's a high-level overview of
the various options that you have in Azure SQL Database.
Now, when we think about
Azure SQL Managed Instance, it's very similar,
but instead of having this idea of a private endpoint or
private link from the beginning when you deploy Managed Instance,
you're going to deploy one or multiple
Managed Instances into its own subnet.
A subnet is basically
a grouping of items within a virtual network.
You're able to deploy your MIs into the subnet,
and access them right after that through a private endpoint.
There are some options for Azure SQL Database,
for Azure SQL Managed Instance,
this is required to get started.
>> As you've seen, the architecture,
how you can connect and setup
networking for Azure SQL Database and Managed Instance,
let me break down possible steps you can take
for you to make your choices on how to
setup and configure this network security.
First of all, for Azure SQL Database,
as Anna just described,
private link is your most secure option,
so we recommend that to be
your first choice to set up
network security for Azure SQL Database.
There could be reasons for that's not possible, so it's not,
even though allow access to Azure services is an easy way,
it is a very least secure way,
so we recommend turning that off.
Then configure a specific set of firewall rules
or virtual network rules to allow your different resources,
whether that be inside Azure or that be On-prem,
connected to your Azure database.
Now for Azure SQL Managed Instance, as Anna described,
there already is a concept of virtual network connectivity,
but what we recommend to do,
even though you could do it during deployment,
is set up your virtual network configuration and
subnets before you deploy Azure SQL Managed Instance,
because you're probably defining the resources and those VNets are
going to want access to your Azure SQL Managed Instance.
Now, we realize this can seem complex,
especially if you're a SQL Server person and
it's not to spent a lot of time in security.
We want you to follow your standard networking practices,
and talk to networking people in
your organization about how is there might the most secure way,
and the best way to get your applications and
your tools connected to Azure SQL Database and Managed Instance.
We've seen some options, Anna has done a very good job visually
showing how things interact for network security,
whether that's using Private Link,
Firewall Rules or Virtual Networks,
both with database and Managed Instance.
Again, we recommend that you talk to network experts in
your organization or look
these various options to get the most security you need,
balanced with the way to get up and running,
and connecting to Azure SQL Database or Managed Instance.
Look forward to seeing you in our next video.