WEBVTT

00:00:00.000 --> 00:00:11.610
[MÚSICA].

00:00:11.610 --> 00:00:13.680
>> Oi, todos, meu nome
é Colin Murphy.

00:00:13.680 --> 00:00:16.065
Eu sou um marketing de produto
Manager na empresa Microsoft,

00:00:16.065 --> 00:00:17.865
e eu estou aqui com Rohit para

00:00:17.865 --> 00:00:20.730
Discutir conectividade
para o banco de dados SQL do Azure.

00:00:20.730 --> 00:00:24.200
Seja bem-vindo, Rohit. Assim seria
Você mente apenas dizendo-nos

00:00:24.200 --> 00:00:28.700
Apenas os conceitos básicos de como você
conectar ao banco de dados SQL do Azure?

00:00:28.700 --> 00:00:31.250
>> Absolutamente. Olá
todo mundo, meu nome é Rohit.

00:00:31.250 --> 00:00:34.300
Sou gerente de programas em
a equipe de banco de dados SQL.

00:00:34.300 --> 00:00:37.790
Hoje com Colin, estamos
vai começar e levá-lo

00:00:37.790 --> 00:00:41.120
através de como você se conecta
para o banco de dados SQL do Azure.

00:00:41.120 --> 00:00:43.375
Então, com isso, vamos começar.

00:00:43.375 --> 00:00:45.525
Então, primeira pergunta.

00:00:45.525 --> 00:00:48.905
Vamos entender um pouco
sobre nossa arquitetura antes de

00:00:48.905 --> 00:00:52.370
ir para o nitty-gritty de como
estabelecer uma ligação.

00:00:52.370 --> 00:00:55.265
Assim, como um cliente, o que
Você precisa saber é

00:00:55.265 --> 00:00:58.080
que temos um monte de
Gateways SQL que são

00:00:58.080 --> 00:00:59.895
nossas máquinas front-end que tomaram

00:00:59.895 --> 00:01:02.060
conexões recebidas ao longo
a Internet quando você está

00:01:02.060 --> 00:01:06.825
conexão do local
ou fora do Azure.

00:01:06.825 --> 00:01:08.710
>> Estes são apenas parte
do serviço passado.

00:01:08.710 --> 00:01:10.470
Você pode apenas ver se é imprudente.

00:01:10.470 --> 00:01:13.510
>> Sim. Então temos um monte
de máquinas de back-end onde

00:01:13.510 --> 00:01:20.195
seus bancos de dados SQL reais são
hospedado e seus dados de vida lá.

00:01:20.195 --> 00:01:21.610
Está bem.

00:01:21.710 --> 00:01:27.450
>> Eu estou tentando se conectar a
myserver.database.windows.net,

00:01:27.450 --> 00:01:31.435
Esse é o formato usual
para todos os servidores de banco de dados.

00:01:31.435 --> 00:01:34.045
Normalmente, se você fizer
NsLookup sobre isso,

00:01:34.045 --> 00:01:36.370
Ele vai resolver para
Este endereço IP público.

00:01:36.370 --> 00:01:38.680
O IP 104,42 é

00:01:38.680 --> 00:01:40.870
um endereço IP público e você está

00:01:40.870 --> 00:01:43.615
vai estar se conectando
para que na porta 1433,

00:01:43.615 --> 00:01:46.055
que é onde estamos
para ouvir as ligações.

00:01:46.055 --> 00:01:48.885
Quando você se conecta, um dos

00:01:48.885 --> 00:01:52.380
as coisas comuns que
acontece é que, basicamente,

00:01:52.380 --> 00:01:55.395
o gateway SQL encaminha
sua conexão,

00:01:55.395 --> 00:01:57.770
Então você tem um pegajoso
conexão passando

00:01:57.770 --> 00:02:00.545
o gateway e conectando
para o nó de back-end.

00:02:00.545 --> 00:02:03.425
Isso é chamado de proxy
política de conexão.

00:02:03.425 --> 00:02:05.570
Assim, todo o gateway está fazendo é que é

00:02:05.570 --> 00:02:09.110
um manual no meio passando
sua conexão com o back-end.

00:02:09.110 --> 00:02:10.670
>> Isso é bom, porque
Nunca estamos expondo

00:02:10.670 --> 00:02:13.130
o IP real do nó SQL.

00:02:13.130 --> 00:02:15.140
>> Eu tenho isso. Então é assim que você

00:02:15.140 --> 00:02:17.330
conectar quando você estiver conectando
de fora do Azure.

00:02:17.330 --> 00:02:20.090
Agora, quando você se conecta
de dentro do Azure,

00:02:20.090 --> 00:02:23.915
dizer de uma VM, fazemos um pouco
forma diferente de conexão.

00:02:23.915 --> 00:02:27.170
Então, nos conectamos ao
SQL gateway e obtemos

00:02:27.170 --> 00:02:32.540
a localização real do seu
Banco de dados SQL no back-end.

00:02:32.540 --> 00:02:35.810
Então você verá este endereço 13,93.

00:02:35.810 --> 00:02:37.535
É um endereço IP privado.

00:02:37.535 --> 00:02:40.930
Não é algo que os usuários
pode se conectar diretamente,

00:02:40.930 --> 00:02:42.815
como, eles não sabem
sobre este endereço IP.

00:02:42.815 --> 00:02:43.325
Está bem.

00:02:43.325 --> 00:02:46.385
>> Então, para randomizar ainda mais,

00:02:46.385 --> 00:02:52.250
Há 11000-11999 intervalo de porta.

00:02:52.250 --> 00:02:53.575
Está bem.

00:02:53.575 --> 00:02:58.885
>> Então SQL poderia estar ouvindo
qualquer um desses dentro desse intervalo.

00:02:58.885 --> 00:03:02.010
É aí que o que
acontece é este chamado

00:03:02.010 --> 00:03:06.560
o método de redirecionamento ou redirecionamento
é a política de conexão,

00:03:06.560 --> 00:03:08.615
Mas nós redirecioná-lo para esse nó.

00:03:08.615 --> 00:03:11.345
Então você se conecta diretamente
ao banco de dados SQL,

00:03:11.345 --> 00:03:13.400
e o gateway não entram em

00:03:13.400 --> 00:03:17.040
a imagem nunca mais
dessa conexão.

00:03:17.090 --> 00:03:18.525
Está bem.

00:03:18.525 --> 00:03:20.900
>> Então, essa é a arquitetura básica

00:03:20.900 --> 00:03:23.210
e você entende como se conectar.

00:03:23.210 --> 00:03:24.920
Agora, deixe-me levá-lo
através do que acontece

00:03:24.920 --> 00:03:27.410
Quando sua conexão realmente
o torna para o gateway.

00:03:27.410 --> 00:03:28.345
Está bem.

00:03:28.345 --> 00:03:32.235
>> Isso é muito, muito básico
coisas de alto nível, nada de especial,

00:03:32.235 --> 00:03:36.520
e isso tem sido em torno de idades.

00:03:36.520 --> 00:03:40.375
Então você tem um cliente e você
tem a máquina de gateway,

00:03:40.375 --> 00:03:43.350
primeira coisa é
o aperto de mão de três vias,

00:03:43.350 --> 00:03:47.835
material PCP padrão, [inaudível]
comunicar ao servidor.

00:03:47.835 --> 00:03:50.720
Coisa interessante, o que
acontece em seguida é que você tem

00:03:50.720 --> 00:03:53.090
um pacote de pré-login
que o cliente envia,

00:03:53.090 --> 00:03:55.840
e características interessantes aqui é,

00:03:55.840 --> 00:03:57.900
Queremos que você,

00:03:57.900 --> 00:04:00.820
como uma prática recomendada, use criptografia,

00:04:00.820 --> 00:04:03.425
que é definido colocando

00:04:03.425 --> 00:04:07.490
criptografar é igual a true na conexão
seqüência de caracteres do seu aplicativo.

00:04:07.490 --> 00:04:10.640
A outra parte nós queremos você
fazer como uma prática recomendada

00:04:10.640 --> 00:04:13.415
é TrustServerCertificate
é igual a false.

00:04:13.415 --> 00:04:16.940
Portanto, isso obriga o cliente a verificar

00:04:16.940 --> 00:04:21.890
o certificado que você
obter do nó de gateway.

00:04:21.890 --> 00:04:23.580
Então, dessa forma, você não terá

00:04:23.580 --> 00:04:28.215
qualquer chance de falsificação ou
ataques de homem no meio.

00:04:28.215 --> 00:04:30.105
>> Ok, isso faz sentido perfeito.

00:04:30.105 --> 00:04:32.670
Portanto, estas são as melhores práticas e

00:04:32.670 --> 00:04:34.860
qualquer desenvolvedor conectando
SQL irá encontrar

00:04:34.860 --> 00:04:37.285
isso em nossas páginas docs
ou onde quer que seja o lugar?

00:04:37.285 --> 00:04:40.080
>> Sim. Na verdade, nós
dar um passo adiante.

00:04:40.080 --> 00:04:42.300
Se você entrar no portal e olhar para

00:04:42.300 --> 00:04:44.960
seu banco de dados SQL e procure
na cadeia de conexão,

00:04:44.960 --> 00:04:46.550
Estes são colocados lá.

00:04:46.550 --> 00:04:47.735
>> Todos estes são os padrões?

00:04:47.735 --> 00:04:49.340
>> Sim. Então você colocá-los em

00:04:49.340 --> 00:04:51.320
lá para se certificar de que
Você está protegido.

00:04:51.320 --> 00:04:52.075
Está bem.

00:04:52.075 --> 00:04:53.940
>> Então a partir de aqui,

00:04:53.940 --> 00:04:55.110
o Prelog e a resposta,

00:04:55.110 --> 00:04:57.600
que é novamente parte
do protocolo TDS,

00:04:57.600 --> 00:05:00.410
e então você tem
Este handshake TLS que é

00:05:00.410 --> 00:05:02.690
uma maneira longa prolixo de obter

00:05:02.690 --> 00:05:04.820
um canal seguro entre
o cliente e o servidor.

00:05:04.820 --> 00:05:05.320
Está bem.

00:05:05.320 --> 00:05:07.220
>> Então, essencialmente, em
o fim deste processo,

00:05:07.220 --> 00:05:09.680
Você está seguro de
a perspectiva do protocolo,

00:05:09.680 --> 00:05:14.500
e, em seguida, inicia
o pacote de login real que

00:05:14.500 --> 00:05:16.020
Você vai vê-lo como

00:05:16.020 --> 00:05:18.200
login vendendo pacote se

00:05:18.200 --> 00:05:20.270
Você faria através de choque
ou algo parecido.

00:05:20.270 --> 00:05:23.330
Então, com base no que você está usando,

00:05:23.330 --> 00:05:26.720
Se estiver a ligar a
nos do proximal,

00:05:26.720 --> 00:05:29.215
Você só vai ficar
o reconhecimento de volta.

00:05:29.215 --> 00:05:31.985
Caso contrário, você terá o que é
chamado como o token de redirecionamento,

00:05:31.985 --> 00:05:33.485
que é uma maneira extravagante de dizer,

00:05:33.485 --> 00:05:35.000
Nós vamos dizer-lhe o IP privado

00:05:35.000 --> 00:05:36.895
endereço que você está
vai se conectar.

00:05:36.895 --> 00:05:39.290
>> Uau, há um monte de aperto de mão
indo para trás [inaudível].

00:05:39.290 --> 00:05:39.980
>> Sim.

00:05:39.980 --> 00:05:41.690
>> É que um processo longo ou?

00:05:41.690 --> 00:05:44.075
>> Não, é uma questão de milissegundos.

00:05:44.075 --> 00:05:45.170
>> Oh ok.

00:05:45.170 --> 00:05:48.530
>> Sim, nós mantê-lo rápido
mesmo e nós mantê-lo seguro.

00:05:48.530 --> 00:05:50.870
>> Ok, isso é bom.
Rápido e seguro.

00:05:50.870 --> 00:05:52.720
>> Sim. Então, a seguir,

00:05:52.720 --> 00:05:55.100
Agora que sabemos sobre
a arquitetura e sabemos

00:05:55.100 --> 00:05:58.460
sobre as noções básicas de conectividade,

00:05:58.460 --> 00:06:00.395
Vamos falar sobre quem pode se conectar.

00:06:00.395 --> 00:06:03.055
Então você quer colocar
alguns controles sobre,

00:06:03.055 --> 00:06:05.570
como você realmente filtrar quem

00:06:05.570 --> 00:06:08.345
pode se conectar a
seu banco de dados SQL do Azure.

00:06:08.345 --> 00:06:11.075
Então isso é, e eu vou
mostrar isso na demo.

00:06:11.075 --> 00:06:16.055
Este é basicamente o firewall
pasta Blade no portal do Azure.

00:06:16.055 --> 00:06:17.900
Então, a primeira coisa que você vai notar aqui

00:06:17.900 --> 00:06:19.430
é esta seção de cima que diz,

00:06:19.430 --> 00:06:22.550
permitir o acesso a
Serviços do Azure, ativado ou desativado.

00:06:22.550 --> 00:06:25.340
Portanto, esta é uma categoria muito ampla

00:06:25.340 --> 00:06:26.855
de permissão que
Você está dando aqui.

00:06:26.855 --> 00:06:28.420
É basicamente dizer,

00:06:28.420 --> 00:06:32.065
pode qualquer outros servidores que é
em execução no Azure,

00:06:32.065 --> 00:06:35.915
dizer como um aplicativo Web
ou outra VM do Azure,

00:06:35.915 --> 00:06:40.815
Ele pode se conectar ao seu
Servidor de banco de dados SQL ou não?

00:06:40.815 --> 00:06:42.420
>> Como em qualquer lugar no Azure?

00:06:42.420 --> 00:06:42.545
>> Sim.

00:06:42.545 --> 00:06:46.245
>> Foi definido por uma região
ou zona ou Datacenter?

00:06:46.245 --> 00:06:47.205
>> Não importa.

00:06:47.205 --> 00:06:47.940
>> Não importa.

00:06:47.940 --> 00:06:49.910
>> Basicamente, o que isso faz é,

00:06:49.910 --> 00:06:52.060
Quando você estiver executando
serviços no Azure,

00:06:52.060 --> 00:06:57.605
cada região ou Datacenter tem
um conjunto de endereços IP fixos.

00:06:57.605 --> 00:07:00.710
Então, basicamente, esta é uma regra que

00:07:00.710 --> 00:07:03.560
Diz qualquer coisa que é
vindo a mim de uma idéia.

00:07:03.560 --> 00:07:03.935
>> De dentro do Azure.

00:07:03.935 --> 00:07:04.205
>> Sim.

00:07:04.205 --> 00:07:05.165
>> Um datacenter confiável.

00:07:05.165 --> 00:07:05.675
>> Sim.

00:07:05.675 --> 00:07:07.460
>> Então eu vou aceitar? Apanhei-te.

00:07:07.460 --> 00:07:10.100
>> Agora, é claro, as pessoas
ter reservas contra

00:07:10.100 --> 00:07:12.875
Isso porque este é
um pouco de um escopo mais amplo,

00:07:12.875 --> 00:07:15.215
Mas em alguns cenários,

00:07:15.215 --> 00:07:16.280
Você precisa fazer isso.

00:07:16.280 --> 00:07:18.785
Por exemplo, o aplicativo Web é um exemplo.

00:07:18.785 --> 00:07:21.620
Mas, gradualmente, estamos
chegando com ofertas para

00:07:21.620 --> 00:07:25.295
Onde você vai ser capaz de colocar
isso em off e vir para cima.

00:07:25.295 --> 00:07:27.650
Eu vou te mostrar
diferentes formas de

00:07:27.650 --> 00:07:29.285
>> Eu vou fazer
comprar um tipo de serviço

00:07:29.285 --> 00:07:30.845
ou algo parecido com um
aplicativo Web ou algo assim?

00:07:30.845 --> 00:07:31.465
>> Sim.

00:07:31.465 --> 00:07:32.985
>> Então só para esclarecer,

00:07:32.985 --> 00:07:36.120
Quando você diz qualquer serviço no Azure,

00:07:36.120 --> 00:07:38.160
é dentro de seu próprio
Descrição do curso.

00:07:38.160 --> 00:07:38.925
>> Sim.

00:07:38.925 --> 00:07:41.115
>> Só para esclarecer que para as pessoas.

00:07:41.115 --> 00:07:44.420
>> Sim. Então, próximo nível de controle

00:07:44.420 --> 00:07:47.525
que oferecemos é o que é
Firewall baseado em IP.

00:07:47.525 --> 00:07:55.080
Então, isso é tipicamente quando você
provisionar o servidor do banco de dados SQL

00:07:55.080 --> 00:07:58.080
a lista padrão aqui se assemelhando.

00:07:58.080 --> 00:08:01.430
Então ninguém pode se conectar a ele por

00:08:01.430 --> 00:08:04.820
usando um endereço IP, a menos
Eles estão nesta lista.

00:08:04.820 --> 00:08:05.580
Te peguei.

00:08:05.580 --> 00:08:07.305
>> Então, a primeira coisa
Você precisa fazer é,

00:08:07.305 --> 00:08:09.195
Quando você vai para o portal,

00:08:09.195 --> 00:08:12.125
Ele irá mostrar-lhe o endereço IP
de que você está vindo.

00:08:12.125 --> 00:08:14.690
Então, se eu estou vindo do meu IP em casa,

00:08:14.690 --> 00:08:17.945
que é onde ele vai aparecer em
Esta seção de endereço IP do cliente,

00:08:17.945 --> 00:08:20.810
e eu preciso de whitelist que
para que eu possa

00:08:20.810 --> 00:08:23.755
para se conectar usando
Management Studio, por exemplo.

00:08:23.755 --> 00:08:25.210
Está bem. Coisas muito padrão,

00:08:25.210 --> 00:08:26.840
Nós fizemos tudo por padrão.

00:08:26.840 --> 00:08:27.485
>> Exatamente.

00:08:27.485 --> 00:08:28.450
Está bem.

00:08:28.450 --> 00:08:30.890
>> Agora, temos
uma terceira maneira interessante de

00:08:30.890 --> 00:08:33.845
Conectando que é chamado
Regras de firewall VNet.

00:08:33.845 --> 00:08:35.785
Isso é muito bonito dizer,

00:08:35.785 --> 00:08:37.985
permitir que todas as VMs do Azure

00:08:37.985 --> 00:08:41.390
dentro de uma VNet para se conectar
ao meu banco de dados SQL.

00:08:41.390 --> 00:08:44.030
Agora, pode haver situações
onde isso é útil,

00:08:44.030 --> 00:08:46.370
dizer que você tem um aplicativo legado
ou seu aplicativo, digamos,

00:08:46.370 --> 00:08:47.900
Reporting Services que está sendo executado em

00:08:47.900 --> 00:08:51.060
uma VM e você deseja
conectar ao banco de dados SQL,

00:08:51.060 --> 00:08:53.555
Esta é uma maneira granular
de fazer isso para permitir

00:08:53.555 --> 00:08:56.270
apenas um conjunto específico de VMs que

00:08:56.270 --> 00:08:58.970
estão dentro de uma subrede para
conectar ao banco de dados SQL.

00:08:58.970 --> 00:08:59.405
Está bem.

00:08:59.405 --> 00:09:01.565
>> Então, estes são
as três formas em que

00:09:01.565 --> 00:09:04.095
controle que conecta
para o banco de dados SQL hoje.

00:09:04.095 --> 00:09:05.570
>> Sim. Eu posso ver
que em vários até agora

00:09:05.570 --> 00:09:07.430
movendo aplicativos herdados.

00:09:07.430 --> 00:09:07.940
>> Absolutamente.

00:09:07.940 --> 00:09:10.595
>> Temos VMs rodando
tudo dentro de uma VNet.

00:09:10.595 --> 00:09:12.140
>> Sim. Então, a seguir,

00:09:12.140 --> 00:09:14.105
Eu vou levá-lo através
detalhes de cada um.

00:09:14.105 --> 00:09:18.215
Então vamos ver como
o firewall baseado em IP funciona.

00:09:18.215 --> 00:09:23.655
Então, suponha que temos um servidor com
par de bancos de dados DB1 e DB2,

00:09:23.655 --> 00:09:26.220
e aqui está uma conexão de entrada.

00:09:26.220 --> 00:09:30.080
Claro, a conexão de entrada
pode ser proxy ou redirecionar,

00:09:30.080 --> 00:09:31.535
Não importa este ponto.

00:09:31.535 --> 00:09:34.100
A suposição é que você ficou
após o gateway e você

00:09:34.100 --> 00:09:36.740
estão realmente chegando em
o nível do mecanismo SQL.

00:09:36.740 --> 00:09:39.050
A primeira coisa que estamos
vai fazer é que vamos

00:09:39.050 --> 00:09:41.630
para verificar contra
firewalls de nível de banco de dados.

00:09:41.630 --> 00:09:43.010
Portanto, isso é armazenado em

00:09:43.010 --> 00:09:47.215
o banco de dados mestre e
sys. database_firewall_rules.

00:09:47.215 --> 00:09:49.590
É um DMV, e tudo o que contém

00:09:49.590 --> 00:09:52.160
é um intervalo de endereços IP
que são permitidos.

00:09:52.160 --> 00:09:55.100
Então, se você está aqui,
em seguida, por padrão,

00:09:55.100 --> 00:09:58.100
Você obter o nosso escopo de banco de dados
o acesso a

00:09:58.100 --> 00:10:01.790
qualquer banco de dados
que pretende ligar.

00:10:01.790 --> 00:10:05.390
Se você não estiver em
as regras de firewall de nível de banco de dados

00:10:05.390 --> 00:10:08.735
Então a próxima verificação acontece
está no nível do servidor,

00:10:08.735 --> 00:10:11.180
que é ligeiramente
DMV diferente chamado

00:10:11.180 --> 00:10:15.440
sys. firewall_rules e é
novamente no banco de dados mestre.

00:10:15.440 --> 00:10:17.420
Se você tem acesso aqui,

00:10:17.420 --> 00:10:19.160
Então é claro que você tem acesso em

00:10:19.160 --> 00:10:21.965
o nível do servidor para
uma vez que você está conectado,

00:10:21.965 --> 00:10:24.635
Você pode em gestão
Estúdio suspenso,

00:10:24.635 --> 00:10:26.725
escolha DB1 e DB2.

00:10:26.725 --> 00:10:29.635
Está bem. Então, se eu fosse
Configurando usando

00:10:29.635 --> 00:10:33.395
SSMS para configurar
meu banco de dados SQL do Azure.

00:10:33.395 --> 00:10:37.680
Se eu disser que o firewall
regra no nível do servidor,

00:10:37.680 --> 00:10:39.810
Ele poderia apenas me dar
acesso a tudo.

00:10:39.810 --> 00:10:41.130
Tenho.

00:10:41.130 --> 00:10:45.165
>> Então, devemos provavelmente ir para
Teste de desenvolvimento, mas não nas melhores práticas.

00:10:45.165 --> 00:10:48.180
>> Sim. Isto é
uma grande pergunta, Colin,

00:10:48.180 --> 00:10:53.075
Porque uma das coisas é que
Por que temos esses dois níveis?

00:10:53.075 --> 00:10:55.560
É porque na produção,

00:10:55.560 --> 00:10:59.045
Se você quiser usar o que é
chamado como um usuário contido,

00:10:59.045 --> 00:11:01.595
Então a melhor prática é,

00:11:01.595 --> 00:11:06.515
usuário contido só permite que você
configurar um usuário contido para DB1.

00:11:06.515 --> 00:11:11.340
Toda a idéia de usuário contido
sendo não consigo acessar o DB2.

00:11:11.410 --> 00:11:14.780
Em combinação com
as regras de firewall do banco de dados,

00:11:14.780 --> 00:11:20.555
Eu também posso restringir o endereço IP
de onde os usuários podem fazer login.

00:11:20.555 --> 00:11:23.180
Então, essencialmente,
o firewall de nível de banco de dados

00:11:23.180 --> 00:11:25.010
é um recurso útil para dados de profundidade

00:11:25.010 --> 00:11:30.515
para gerir o âmbito de aplicação
pessoas ruins podem se conectar.

00:11:30.515 --> 00:11:31.980
Está bem.

00:11:32.260 --> 00:11:35.450
Então, novamente, apenas me ajude aqui.

00:11:35.450 --> 00:11:37.430
Você poderia expandir alguns detalhes.

00:11:37.430 --> 00:11:42.650
Assim, nas regras de firewall estes
estão dentro do servidor SQL e

00:11:42.650 --> 00:11:44.750
como, obviamente, então o que temos
coberto anteriormente foi

00:11:44.750 --> 00:11:48.215
as regras de firewall para
a rede dentro dela.

00:11:48.215 --> 00:11:50.630
>> Sim. Então, esses são
dois conceitos distintos.

00:11:50.630 --> 00:11:52.220
Então, no slide anterior eu mostrei

00:11:52.220 --> 00:11:54.155
Você há um endereço IP
firewall baseado em.

00:11:54.155 --> 00:11:58.820
Isso é o que é e
o lugar onde eles

00:11:58.820 --> 00:12:03.995
são armazenados está dentro do mestre
banco de dados dentro do SQL Server.

00:12:03.995 --> 00:12:07.050
Eles são expostos através do Portal.

00:12:07.870 --> 00:12:11.660
Claro que se você não encontrar
qualquer um destes critérios, em seguida,

00:12:11.660 --> 00:12:15.870
sua conexão será rejeitada
que é o que falamos.

00:12:16.090 --> 00:12:18.350
Agora, vamos ver

00:12:18.350 --> 00:12:21.875
a nova parte interessante aqui
que é as regras de firewall VNet.

00:12:21.875 --> 00:12:25.235
Então deixe-me configurar
o cenário para você.

00:12:25.235 --> 00:12:27.830
Então, vamos supor que você tem
uma máquina virtual que é

00:12:27.830 --> 00:12:32.135
execução dizem que um aplicativo legado
no iOS ou qualquer outro.

00:12:32.135 --> 00:12:37.100
A máquina virtual normalmente
Você pode configurar o que é chamado

00:12:37.100 --> 00:12:42.260
como um endereço IP público para ele
que é o 14,11 para abordar,

00:12:42.260 --> 00:12:45.200
e você também pode ter
um endereço IP privado que

00:12:45.200 --> 00:12:48.305
vem de uma sub-rede específica.

00:12:48.305 --> 00:12:51.020
Assim, as melhores práticas
Certifique-se sempre de que

00:12:51.020 --> 00:12:53.600
seus IPs privados são
proveniente de sub-redes,

00:12:53.600 --> 00:12:55.490
ajuda na segmentação de rede

00:12:55.490 --> 00:12:57.920
e isso é uma rede
melhores práticas.

00:12:57.920 --> 00:13:00.305
Mas eu vou te mostrar como isso ajuda.

00:13:00.305 --> 00:13:02.990
>> Você normalmente sempre
definir essas coisas ou obter

00:13:02.990 --> 00:13:05.270
uma rede de ti pro para definir os

00:13:05.270 --> 00:13:07.865
antes de ir para a
uma produção diferente.

00:13:07.865 --> 00:13:10.625
Você quer certificar-se
Você tem IP suficiente.

00:13:10.625 --> 00:13:11.930
>> Sim, absolutamente.

00:13:11.930 --> 00:13:13.985
É um bom ponto
que você traz para cima é

00:13:13.985 --> 00:13:16.985
Nós definitivamente queremos
separação de deveres aqui,

00:13:16.985 --> 00:13:20.390
é sempre bom planejar
sua rede antes do tempo.

00:13:20.390 --> 00:13:22.790
Então você não corre para fora
de endereços IP e

00:13:22.790 --> 00:13:26.495
Então você certamente não
Quer um DBM mexer

00:13:26.495 --> 00:13:32.030
ao redor com a criação destes e
obtendo o tamanho errado ou porque

00:13:32.030 --> 00:13:37.850
cada um deles é fácil
perder coisas aqui.

00:13:37.850 --> 00:13:40.280
>> Sim, e uma vez que você
definir esses intervalos e

00:13:40.280 --> 00:13:42.995
começou a instalar coisas
é que você não pode ir para trás.

00:13:42.995 --> 00:13:47.000
Tenho. Então, há
a configuração básica.

00:13:47.000 --> 00:13:50.930
Tenho uma VM, tem um público
Endereço IP e um endereço IP privado.

00:13:50.930 --> 00:13:54.020
Então deixe-me levá-lo através
opção número um que é como

00:13:54.020 --> 00:13:57.350
Eu conecto ao banco de dados SQL
usando o público,

00:13:57.350 --> 00:14:01.190
normalmente chamamos isso
o endereço IP arrebatado.

00:14:01.190 --> 00:14:04.130
A opção número um é vamos começar a partir de

00:14:04.130 --> 00:14:06.980
o lado da VM e podemos definir o que é

00:14:06.980 --> 00:14:09.230
chamado de regra NSG que

00:14:09.230 --> 00:14:12.455
basicamente diz que eu vou
para permitir o tráfego de saída.

00:14:12.455 --> 00:14:14.630
>> NSG, grupo de segurança de rede?

00:14:14.630 --> 00:14:17.170
>> Grupo de segurança de rede
que existem em

00:14:17.170 --> 00:14:21.120
a VM na máquina virtual.

00:14:21.120 --> 00:14:24.305
Ele permite que você defina
regras de entrada e saída.

00:14:24.305 --> 00:14:28.865
Então, aqui vamos definir uma saída
regra para se conectar ao banco de dados SQL.

00:14:28.865 --> 00:14:31.880
A forma como faremos isso
é que vamos dizer que eu preciso

00:14:31.880 --> 00:14:35.225
conectar-se a 1433 porque
Essa é a minha inicial.

00:14:35.225 --> 00:14:37.460
Lembre-se inicialmente você
precisa se conectar a

00:14:37.460 --> 00:14:40.565
o gateway que é
investindo na porta 1433.

00:14:40.565 --> 00:14:43.700
Então, eu preciso do 11.000 através

00:14:43.700 --> 00:14:48.170
11.999 gama porque eu sou
vai usar o redirecionamento.

00:14:48.170 --> 00:14:50.990
Em seguida, TCP é o meu protocolo.

00:14:50.990 --> 00:14:54.425
Meu IP endereça o endereço 40,112

00:14:54.425 --> 00:14:57.815
e caminho mais à direita
a peça mais interessante.

00:14:57.815 --> 00:15:01.355
Eu estou dizendo que deixe esta máquina virtual

00:15:01.355 --> 00:15:04.415
conectar-se a tudo em SQL. WestUS.

00:15:04.415 --> 00:15:08.615
Então, que é novamente outra rede
conceito chamado uma etiqueta de serviço.

00:15:08.615 --> 00:15:12.935
Então o que isso significa é que eu quero
para se conectar ao banco de dados SQL.

00:15:12.935 --> 00:15:15.410
Eu sei que meu banco de dados está em WestUS,

00:15:15.410 --> 00:15:19.715
Permitam-me apenas whitelist
tráfego para a região WestUS.

00:15:19.715 --> 00:15:21.125
>> Isso é muito bom.

00:15:21.125 --> 00:15:24.455
Então você poderia apenas deixar
me usar isso como um ou

00:15:24.455 --> 00:15:29.795
Apenas os usos para ajudar com
apenas a sua latência e tráfego.

00:15:29.795 --> 00:15:32.390
>> Sim, quero dizer
uma linha de fundo aqui é esta

00:15:32.390 --> 00:15:36.620
é uma forma de permitir a
conectividade do lado da rede.

00:15:36.620 --> 00:15:38.450
Então, tipicamente o seu
administrador de rede fará

00:15:38.450 --> 00:15:41.540
isso e ele só faz
gestão mais fácil

00:15:41.540 --> 00:15:42.770
para eles, porque quando você diz

00:15:42.770 --> 00:15:46.940
Sql. WestUS você não tem que
Endereço IP individual de whitelist.

00:15:46.940 --> 00:15:49.610
Por isso, permite-lhe
conectar-se a qualquer coisa em

00:15:49.610 --> 00:15:53.180
qualquer banco de dados SQL que
na região de WestUS.

00:15:53.180 --> 00:15:55.850
Agora isso também implica

00:15:55.850 --> 00:15:57.845
uma sobrecarga adicional
no sentido de que

00:15:57.845 --> 00:15:59.990
uma vez que você é feito com
a configuração de rede,

00:15:59.990 --> 00:16:02.000
Você precisa vir em
o lado do banco de dados SQL

00:16:02.000 --> 00:16:04.655
e lembre-se novamente o nosso
Firewall de endereço IP.

00:16:04.655 --> 00:16:06.845
Então você precisa adicionar o endereço IP aqui.

00:16:06.845 --> 00:16:08.975
Então, este é um processo de duas etapas.

00:16:08.975 --> 00:16:12.230
Os desvantagens deste são um

00:16:12.230 --> 00:16:15.440
é que você tem que gerenciar o endereço IP.

00:16:15.440 --> 00:16:19.520
Assim, por exemplo, a qualquer momento se você
encadear o endereço IP público para

00:16:19.520 --> 00:16:22.280
a VM imediatamente
Esta conectividade será

00:16:22.280 --> 00:16:25.400
quebrado porque o SQL não
reconhecer esse endereço IP.

00:16:25.400 --> 00:16:27.200
>> Sim, porque não [inaudível].

00:16:27.200 --> 00:16:30.740
>> Sim. A outra coisa
sobre isso que

00:16:30.740 --> 00:16:33.140
alguns clientes podem não gostar é então

00:16:33.140 --> 00:16:36.155
uma etiqueta de serviço ainda está
bem abertos.

00:16:36.155 --> 00:16:37.805
Ele diz que me permita ligar para

00:16:37.805 --> 00:16:41.840
qualquer banco de dados SQL em
região WestUS.

00:16:41.840 --> 00:16:44.090
Mas, claro, há melhorias

00:16:44.090 --> 00:16:46.130
vindo no lado da rede
que lhe permitirá

00:16:46.130 --> 00:16:48.575
restringir que a um recurso específico

00:16:48.575 --> 00:16:51.035
Mas aqueles estão em
progresso no momento.

00:16:51.035 --> 00:16:52.820
Mas isto é o que temos.

00:16:52.820 --> 00:16:58.775
Então agora vamos virar a direção
a partir do qual estamos vindo aqui.

00:16:58.775 --> 00:17:02.720
Você viu como nós configurar a partir de
o lado da VM para o SQL DB.

00:17:02.720 --> 00:17:05.240
A regra de firewall vnet é
algo que você definir

00:17:05.240 --> 00:17:07.400
um baile do lado do banco de dados SQL como

00:17:07.400 --> 00:17:11.330
isso para dizer permitir-me a conexão de

00:17:11.330 --> 00:17:17.135
meu banco de dados SQL para
uma sub-rede específica.

00:17:17.135 --> 00:17:21.005
Então a beleza disso
é que você não precisa

00:17:21.005 --> 00:17:25.280
para whitelist todos os endereços IP
ou fazer qualquer coisa assim.

00:17:25.280 --> 00:17:28.460
Tudo que você está dizendo é
abrindo um caminho entre

00:17:28.460 --> 00:17:29.960
seu banco de dados SQL e

00:17:29.960 --> 00:17:33.620
uma sub-rede em particular e você está
usando o endereço IP privado.

00:17:33.620 --> 00:17:36.485
Então, há que mesmo
benefício acrescentado que

00:17:36.485 --> 00:17:42.455
Tudo está passando
a rede de backbone do Azure sábia.

00:17:42.455 --> 00:17:43.970
>> Isso é muito legal.

00:17:43.970 --> 00:17:50.750
>> Outra vantagem disso é
sem whitelisting exigido e sim,

00:17:50.750 --> 00:17:52.625
Isso é muito bonito.

00:17:52.625 --> 00:17:56.420
>> Cool. Então, obrigado por isso.

00:17:56.420 --> 00:17:58.160
Essa é uma explicação muito boa de

00:17:58.160 --> 00:18:01.220
a conectividade para
Banco de dados SQL do Azure.

00:18:01.220 --> 00:18:03.780
Algumas outras perguntas rápidas,

00:18:03.790 --> 00:18:06.680
é apenas para o Azure
Banco de dados SQL como todos os

00:18:06.680 --> 00:18:08.780
lhes os diferentes
opções de implantação.

00:18:08.780 --> 00:18:11.855
Acho que temos um único elástico
objetivo foi a instância gerenciada.

00:18:11.855 --> 00:18:12.290
>> Absolutamente.

00:18:12.290 --> 00:18:15.360
>> É para todos eles este
afetou as opções que você explicou?

00:18:15.360 --> 00:18:18.530
>> Então, quando falamos sobre
Banco de dados SQL do Azure hoje,

00:18:18.530 --> 00:18:23.180
Se você olhar para um único
Bancos de dados SQL, pools elásticos,

00:18:23.180 --> 00:18:26.779
armazém de dados e
mesmo os bancos de dados de código aberto,

00:18:26.779 --> 00:18:30.200
Partilhamos um controlo comum
plano que significa

00:18:30.200 --> 00:18:34.640
dizer o gateway SQL que você
viu que o componente é comum.

00:18:34.640 --> 00:18:37.820
Portanto, essa conectividade se aplica a

00:18:37.820 --> 00:18:39.410
todas as nossas ofertas que estão

00:18:39.410 --> 00:18:41.525
o guarda-chuva do banco de dados SQL do Azure.

00:18:41.525 --> 00:18:44.690
Isso é fantástico. Bem, obrigado

00:18:44.690 --> 00:18:47.600
muita gente para
sintonizar e dar-nos

00:18:47.600 --> 00:18:50.210
um como se você gosta
Esse tipo de conteúdo

00:18:50.210 --> 00:18:53.300
e subscrever-nos e nós vamos
Vejo você mais tarde. Obrigado.

00:18:53.300 --> 00:19:06.000
MÚSICA