WEBVTT

00:00:00.000 --> 00:00:11.610
[MUSICA].

00:00:11.610 --> 00:00:13.680
>> Ciao, tutti, il mio nome
è Colin Murphy.

00:00:13.680 --> 00:00:16.065
Sono un Product Marketing
Manager presso Microsoft,

00:00:16.065 --> 00:00:17.865
e sono qui con Rohit per

00:00:17.865 --> 00:00:20.730
discutere la connettività
per il database SQL di Azure.

00:00:20.730 --> 00:00:24.200
Benvenuto, Rohit. Così sarebbe
ti dispiace solo dicendoci

00:00:24.200 --> 00:00:28.700
solo i concetti di base di come si
connettersi al database SQL di Azure?

00:00:28.700 --> 00:00:31.250
>> Assolutamente. ciao
tutti, mi chiamo Rohit.

00:00:31.250 --> 00:00:34.300
Sono un Program Manager in
il team del database SQL.

00:00:34.300 --> 00:00:37.790
Oggi con Colin, siamo
intenzione di iniziare e prendere voi

00:00:37.790 --> 00:00:41.120
attraverso il modo in cui ci si connette
nel database SQL di Azure.

00:00:41.120 --> 00:00:43.375
Quindi, con questo, cominciamo.

00:00:43.375 --> 00:00:45.525
Quindi prima domanda.

00:00:45.525 --> 00:00:48.905
Cerchiamo di capire un po'
sulla nostra architettura prima di

00:00:48.905 --> 00:00:52.370
andare al nocciolo di come
si stabilisce una connessione.

00:00:52.370 --> 00:00:55.265
Quindi, come cliente, che cosa
è necessario sapere è

00:00:55.265 --> 00:00:58.080
che abbiamo un mucchio di
I gateway SQL che sono

00:00:58.080 --> 00:00:59.895
le nostre macchine front-end che hanno preso

00:00:59.895 --> 00:01:02.060
connessioni in entrata su
Internet quando si è

00:01:02.060 --> 00:01:06.825
connessione da locale
o al di fuori di Azure.

00:01:06.825 --> 00:01:08.710
>> Questi sono solo parte
di quel servizio passato.

00:01:08.710 --> 00:01:10.470
Si può solo vedere se è sconsiderato.

00:01:10.470 --> 00:01:13.510
>> Sì. Poi abbiamo un gruppo
di macchine di back-end dove

00:01:13.510 --> 00:01:20.195
i database SQL effettivi sono
ospitati e i vostri dati vi risiedono.

00:01:20.195 --> 00:01:21.610
>> Ok.

00:01:21.710 --> 00:01:27.450
>> Sto cercando di connettersi a
myserver.database.windows.net,

00:01:27.450 --> 00:01:31.435
questo è il formato usuale
per tutti i server di database.

00:01:31.435 --> 00:01:34.045
In genere, se si
NsLookup su questo,

00:01:34.045 --> 00:01:36.370
si risolverà a
questo indirizzo IP pubblico.

00:01:36.370 --> 00:01:38.680
L'IP 104.42 è

00:01:38.680 --> 00:01:40.870
un indirizzo IP pubblico e si sta

00:01:40.870 --> 00:01:43.615
sta per essere la connessione
a quella sulla porta 1433,

00:01:43.615 --> 00:01:46.055
che è dove siamo
in ascolto delle connessioni attivate.

00:01:46.055 --> 00:01:48.885
Quando ci si connette, uno dei

00:01:48.885 --> 00:01:52.380
le cose comuni che
accade è, fondamentalmente,

00:01:52.380 --> 00:01:55.395
il gateway SQL inoltra
la connessione attivata,

00:01:55.395 --> 00:01:57.770
in modo da avere un appiccicoso
connessione passando attraverso

00:01:57.770 --> 00:02:00.545
gateway e la connessione
sul nodo back-end.

00:02:00.545 --> 00:02:03.425
Questo è chiamato proxy
politica di connessione.

00:02:03.425 --> 00:02:05.570
Quindi tutto il gateway sta facendo è che è

00:02:05.570 --> 00:02:09.110
un manuale nel mezzo passando
connessione al back-end.

00:02:09.110 --> 00:02:10.670
>> Questo è un bene perché
non esponiamo mai

00:02:10.670 --> 00:02:13.130
l'IP effettivo del nodo SQL.

00:02:13.130 --> 00:02:15.140
>> Ho capito. Quindi è così che si

00:02:15.140 --> 00:02:17.330
connettersi quando ci si connette
dall'esterno di Azure.

00:02:17.330 --> 00:02:20.090
Ora, quando si collega
dall'interno di Azure,

00:02:20.090 --> 00:02:23.915
dire da una VM, facciamo un po'
modo diverso di connessione.

00:02:23.915 --> 00:02:27.170
Quindi ci colleghiamo al
gateway SQL e otteniamo

00:02:27.170 --> 00:02:32.540
la posizione effettiva del
SQL nel back-end.

00:02:32.540 --> 00:02:35.810
Quindi vedrete questo indirizzo 13.93.

00:02:35.810 --> 00:02:37.535
Questo è un indirizzo IP privato.

00:02:37.535 --> 00:02:40.930
Non è qualcosa che gli utenti
può connettersi direttamente,

00:02:40.930 --> 00:02:42.815
come, non sanno
su questo indirizzo IP.

00:02:42.815 --> 00:02:43.325
>> Ok.

00:02:43.325 --> 00:02:46.385
>> Poi per randomizzare ulteriormente,

00:02:46.385 --> 00:02:52.250
c'è 11.000-11.999 gamma di porte.

00:02:52.250 --> 00:02:53.575
>> Ok.

00:02:53.575 --> 00:02:58.885
>> Così SQL potrebbe essere in ascolto su
uno qualsiasi di quelli all'interno di tale intervallo.

00:02:58.885 --> 00:03:02.010
È qui che ciò che
accade è questo chiamato

00:03:02.010 --> 00:03:06.560
il metodo di reindirizzamento o il reindirizzamento
è la politica di connessione,

00:03:06.560 --> 00:03:08.615
ma vi reindirizziamo a quel nodo.

00:03:08.615 --> 00:03:11.345
Così si collega direttamente
al database SQL,

00:03:11.345 --> 00:03:13.400
e il gateway non entrano

00:03:13.400 --> 00:03:17.040
l'immagine mai più
di tale connessione.

00:03:17.090 --> 00:03:18.525
>> Ok.

00:03:18.525 --> 00:03:20.900
>> Quindi questa è l'architettura di base

00:03:20.900 --> 00:03:23.210
e si capisce come connettersi.

00:03:23.210 --> 00:03:24.920
Ora, lascia che ti porti
attraverso ciò che accade

00:03:24.920 --> 00:03:27.410
quando la connessione in realtà
verso il Gateway.

00:03:27.410 --> 00:03:28.345
>> Ok.

00:03:28.345 --> 00:03:32.235
>> Questo è molto, molto semplice
roba di alto livello, niente di speciale,

00:03:32.235 --> 00:03:36.520
e questo è stato intorno per secoli.

00:03:36.520 --> 00:03:40.375
Così avete un cliente e si
avere la macchina Gateway,

00:03:40.375 --> 00:03:43.350
prima cosa è
la stretta di mano a tre vie,

00:03:43.350 --> 00:03:47.835
roba PCP standard, [non udibile]
comunicare con il server.

00:03:47.835 --> 00:03:50.720
La cosa interessante, che cosa
accade dopo è che avete

00:03:50.720 --> 00:03:53.090
un pacchetto di pre-accesso
che il cliente invia,

00:03:53.090 --> 00:03:55.840
e caratteristiche interessanti ecco,

00:03:55.840 --> 00:03:57.900
vogliamo che tu lo sappia,

00:03:57.900 --> 00:04:00.820
come procedura consigliata, utilizzare la crittografia,

00:04:00.820 --> 00:04:03.425
che è impostato mettendo

00:04:03.425 --> 00:04:07.490
crittografa è uguale a true nella connessione
stringa dell'applicazione.

00:04:07.490 --> 00:04:10.640
Altra parte che ti vogliamo
da fare come una best practice

00:04:10.640 --> 00:04:13.415
è TrustServerCertificate
è false.

00:04:13.415 --> 00:04:16.940
Quindi questo costringe il cliente a verificare

00:04:16.940 --> 00:04:21.890
il certificato che si
ottenere dal nodo gateway.

00:04:21.890 --> 00:04:23.580
In questo modo, non avrete

00:04:23.580 --> 00:04:28.215
qualsiasi possibilità di spoofing o
attacchi man-in-the-middle.

00:04:28.215 --> 00:04:30.105
>> Ok, questo ha perfettamente senso.

00:04:30.105 --> 00:04:32.670
Quindi queste sono le migliori pratiche e

00:04:32.670 --> 00:04:34.860
qualsiasi sviluppatore che si connette
SQL troverà

00:04:34.860 --> 00:04:37.285
questo sulle nostre pagine docs
o ovunque il posto?

00:04:37.285 --> 00:04:40.080
>> sì. Infatti, abbiamo
fare un passo avanti.

00:04:40.080 --> 00:04:42.300
Se vai nel portale e guardi

00:04:42.300 --> 00:04:44.960
database SQL e guardare
alla stringa di connessione,

00:04:44.960 --> 00:04:46.550
questi sono messi in là.

00:04:46.550 --> 00:04:47.735
>> Tutti questi sono i valori predefiniti?

00:04:47.735 --> 00:04:49.340
>> Sì. Così li metti in

00:04:49.340 --> 00:04:51.320
lì per assicurarsi che
sei protetto.

00:04:51.320 --> 00:04:52.075
>> Ok.

00:04:52.075 --> 00:04:53.940
>> Poi da qui in poi,

00:04:53.940 --> 00:04:55.110
la prelog e la risposta,

00:04:55.110 --> 00:04:57.600
che è ancora una parte
del protocollo TDS,

00:04:57.600 --> 00:05:00.410
e poi hai
questa stretta di mano TLS che è

00:05:00.410 --> 00:05:02.690
un lungo modo ventoso di ottenere

00:05:02.690 --> 00:05:04.820
un canale sicuro tra
il client e il server.

00:05:04.820 --> 00:05:05.320
>> Ok.

00:05:05.320 --> 00:05:07.220
>> Quindi essenzialmente, a
alla fine di questo processo,

00:05:07.220 --> 00:05:09.680
sei al sicuro da
la prospettiva del protocollo,

00:05:09.680 --> 00:05:14.500
e poi inizia
l'effettivo pacchetto di login che

00:05:14.500 --> 00:05:16.020
lo vedrete come

00:05:16.020 --> 00:05:18.200
login pacchetto vendita se

00:05:18.200 --> 00:05:20.270
si farebbe per shock
o qualcosa del genere.

00:05:20.270 --> 00:05:23.330
Quindi, in base a ciò che si sta utilizzando,

00:05:23.330 --> 00:05:26.720
se ci si connette a
noi dal prossimale,

00:05:26.720 --> 00:05:29.215
si otterrà solo
il riconoscimento.

00:05:29.215 --> 00:05:31.985
In caso contrario, si otterrà ciò che è
chiamato come token di reindirizzamento,

00:05:31.985 --> 00:05:33.485
che è un modo elegante di dire,

00:05:33.485 --> 00:05:35.000
vi diremo l'IP privato

00:05:35.000 --> 00:05:36.895
indirizzo che si è
si connetterà.

00:05:36.895 --> 00:05:39.290
>> Wow, c'è un sacco di handshaking
tornare indietro [non udibile].

00:05:39.290 --> 00:05:39.980
>> Sì.

00:05:39.980 --> 00:05:41.690
>> È un processo lungo o?

00:05:41.690 --> 00:05:44.075
>> No, è una questione di millisecondi.

00:05:44.075 --> 00:05:45.170
>> Oh va bene.

00:05:45.170 --> 00:05:48.530
>> Sì, lo teniamo veloce
anche e lo teniamo al sicuro.

00:05:48.530 --> 00:05:50.870
>> Ok, va bene.
Veloce e sicuro.

00:05:50.870 --> 00:05:52.720
>> sì. Quindi il prossimo,

00:05:52.720 --> 00:05:55.100
ora che sappiamo
l'architettura e sappiamo

00:05:55.100 --> 00:05:58.460
sulle basi della connettività,

00:05:58.460 --> 00:06:00.395
parliamo di chi può connettersi.

00:06:00.395 --> 00:06:03.055
Quindi si vuole mettere
alcuni controlli su,

00:06:03.055 --> 00:06:05.570
come si fa effettivamente filtrare chi

00:06:05.570 --> 00:06:08.345
può connettersi a
database SQL di Azure.

00:06:08.345 --> 00:06:11.075
Quindi questo è, e io
mostrarlo nella demo.

00:06:11.075 --> 00:06:16.055
Questo è fondamentalmente il firewall
cartella blade nel portale di Azure.Blade folder in the Azure portal.

00:06:16.055 --> 00:06:17.900
Quindi la prima cosa che noterete qui

00:06:17.900 --> 00:06:19.430
è questa sezione in alto che dice:

00:06:19.430 --> 00:06:22.550
consentire l'accesso a
Servizi di Azure attivati o disattivati.

00:06:22.550 --> 00:06:25.340
Quindi questa è una categoria molto ampia

00:06:25.340 --> 00:06:26.855
di permesso che
si sta dando qui.

00:06:26.855 --> 00:06:28.420
In pratica sta dicendo:

00:06:28.420 --> 00:06:32.065
può qualsiasi altro server che è
in esecuzione all'interno di Azure,

00:06:32.065 --> 00:06:35.915
dire come un app web
o un'altra macchina virtuale di Azure,

00:06:35.915 --> 00:06:40.815
può collegarsi al tuo
Server di database SQL o no?

00:06:40.815 --> 00:06:42.420
>> Come in qualsiasi parte in Azure?

00:06:42.420 --> 00:06:42.545
>> Sì.

00:06:42.545 --> 00:06:46.245
>> È stato impostato da una regione
o zona o datacenter?

00:06:46.245 --> 00:06:47.205
>> Non importa.

00:06:47.205 --> 00:06:47.940
>> Non importa.

00:06:47.940 --> 00:06:49.910
>> Fondamentalmente, ciò che fa è,

00:06:49.910 --> 00:06:52.060
quando si esegue
servizi in Azure,

00:06:52.060 --> 00:06:57.605
ogni area o data center ha
un insieme di indirizzi IP fissi.

00:06:57.605 --> 00:07:00.710
Quindi fondamentalmente, questa è una regola che

00:07:00.710 --> 00:07:03.560
dice tutto ciò che è
venire da me da un'idea.

00:07:03.560 --> 00:07:03.935
>> Dall'interno di Azure.

00:07:03.935 --> 00:07:04.205
>> sì.

00:07:04.205 --> 00:07:05.165
>> Un datacenter di fiducia.

00:07:05.165 --> 00:07:05.675
>> Sì.

00:07:05.675 --> 00:07:07.460
>> Quindi ho intenzione di accettare? Ti ho preso.

00:07:07.460 --> 00:07:10.100
>> Ora, naturalmente, la gente
hanno riserve contro

00:07:10.100 --> 00:07:12.875
questo perché questo è
un po' più ampio,

00:07:12.875 --> 00:07:15.215
ma in alcuni scenari,

00:07:15.215 --> 00:07:16.280
è necessario eseguire questa operazione.

00:07:16.280 --> 00:07:18.785
Ad esempio, l'app Web ne è un esempio.

00:07:18.785 --> 00:07:21.620
Ma a poco a poco, siamo
in arrivo offerte per

00:07:21.620 --> 00:07:25.295
dove sarete in grado di mettere
questo a fuori e venire.

00:07:25.295 --> 00:07:27.650
Vi mostrerò
diversi modi in cui-

00:07:27.650 --> 00:07:29.285
>> Ho intenzione di fare
acquistare un tipo di servizio

00:07:29.285 --> 00:07:30.845
o qualcosa di simile a un
un'app web o qualcosa del genere?

00:07:30.845 --> 00:07:31.465
>> Sì.

00:07:31.465 --> 00:07:32.985
>> Quindi solo per chiarire,

00:07:32.985 --> 00:07:36.120
quando si pronuncia qualsiasi servizio in Azure,

00:07:36.120 --> 00:07:38.160
è all'interno del proprio
descrizione, naturalmente.

00:07:38.160 --> 00:07:38.925
>> Sì.

00:07:38.925 --> 00:07:41.115
>> Giusto per chiarire che per le persone.

00:07:41.115 --> 00:07:44.420
>> sì. Quindi il livello successivo di controllo

00:07:44.420 --> 00:07:47.525
che offriamo è ciò che è
firewall basato su IP.

00:07:47.525 --> 00:07:55.080
Quindi questo è in genere quando si
eseguire il provisioning del server di database SQL di Azure,

00:07:55.080 --> 00:07:58.080
l'elenco predefinito qui simile.

00:07:58.080 --> 00:08:01.430
Così nessuno può connettersi ad esso da

00:08:01.430 --> 00:08:04.820
utilizzando un indirizzo IP a meno che
sono in questa lista.

00:08:04.820 --> 00:08:05.580
>> Ti ho preso.

00:08:05.580 --> 00:08:07.305
>> Quindi la prima cosa
che devi fare è,

00:08:07.305 --> 00:08:09.195
quando vai al portale,

00:08:09.195 --> 00:08:12.125
vi mostrerà l'indirizzo IP
da cui vieni.

00:08:12.125 --> 00:08:14.690
Quindi, se vengo da casa mia IP,

00:08:14.690 --> 00:08:17.945
è lì che si presenterà in
questa sezione relativa all'indirizzo IP del client,

00:08:17.945 --> 00:08:20.810
e ho bisogno di whitelist che
in modo che io sia in grado

00:08:20.810 --> 00:08:23.755
per connettersi utilizzando
Management StudioManagement Studio, ad esempio.

00:08:23.755 --> 00:08:25.210
>> Ok. Roba piuttosto standard,

00:08:25.210 --> 00:08:26.840
abbiamo fatto tutto per impostazione predefinita.

00:08:26.840 --> 00:08:27.485
>> Esattamente.

00:08:27.485 --> 00:08:28.450
>> Ok.

00:08:28.450 --> 00:08:30.890
>> Ora, abbiamo
un terzo modo interessante di

00:08:30.890 --> 00:08:33.845
collegamento che si chiama
Regole del firewall della rete virtuale.

00:08:33.845 --> 00:08:35.785
Questo è più o meno dicendo,

00:08:35.785 --> 00:08:37.985
consentire tutte le macchine virtuali di AzureAllow all Azure VMs

00:08:37.985 --> 00:08:41.390
all'interno di una rete virtuale per la connessione
al mio database SQL.

00:08:41.390 --> 00:08:44.030
Ora, ci potrebbero essere situazioni
dove questo è utile,

00:08:44.030 --> 00:08:46.370
dire che si dispone di un'applicazione legacy
o la tua app, diciamo,

00:08:46.370 --> 00:08:47.900
reporting services in esecuzione in

00:08:47.900 --> 00:08:51.060
una macchina virtuale e si desidera
connettersi al database SQL,

00:08:51.060 --> 00:08:53.555
questo è un modo granulare
di farlo per consentire

00:08:53.555 --> 00:08:56.270
solo un set specifico di macchine virtuali che

00:08:56.270 --> 00:08:58.970
sono all'interno di una sottorete per
connettersi al database SQL.

00:08:58.970 --> 00:08:59.405
>> Ok.

00:08:59.405 --> 00:09:01.565
>> Quindi questi sono
i tre modi in cui abbiamo

00:09:01.565 --> 00:09:04.095
controllare chi si connette
al database SQL oggi.

00:09:04.095 --> 00:09:05.570
>> sì. Riesco a vedere
che in vari finora

00:09:05.570 --> 00:09:07.430
spostando le applicazioni legacy.

00:09:07.430 --> 00:09:07.940
>> Assolutamente.

00:09:07.940 --> 00:09:10.595
>> Abbiamo ottenuto macchine virtuali in esecuzione
tutto all'interno di una rete virtuale.

00:09:10.595 --> 00:09:12.140
>> Sì. Quindi il prossimo,

00:09:12.140 --> 00:09:14.105
Ti porterò attraverso
dettagli di ciascuno.

00:09:14.105 --> 00:09:18.215
Quindi diamo un'occhiata a come
il firewall basato su IP funziona.

00:09:18.215 --> 00:09:23.655
Quindi supponiamo di avere un server con
un paio di database DB1 e DB2,

00:09:23.655 --> 00:09:26.220
ed ecco una connessione in entrata.

00:09:26.220 --> 00:09:30.080
Naturalmente, la connessione in entrata
potrebbe essere proxy o reindirizzare,

00:09:30.080 --> 00:09:31.535
non importa questo punto.

00:09:31.535 --> 00:09:34.100
L'ipotesi è che tu sia arrivato
passato il gateway e si

00:09:34.100 --> 00:09:36.740
sono in realtà arrivando a
livello del motore SQL.

00:09:36.740 --> 00:09:39.050
La prima cosa che siamo
intenzione di fare è che stiamo andando

00:09:39.050 --> 00:09:41.630
per verificare contro
firewall a livello di database.

00:09:41.630 --> 00:09:43.010
Quindi questo è memorizzato in

00:09:43.010 --> 00:09:47.215
il database master e
di sys.database_firewall_rules.

00:09:47.215 --> 00:09:49.590
Si tratta di una DMV, e tutto ciò che contiene

00:09:49.590 --> 00:09:52.160
è un intervallo di indirizzi IP
consentite.

00:09:52.160 --> 00:09:55.100
Quindi, se siete qui,
quindi per impostazione predefinita,

00:09:55.100 --> 00:09:58.100
si ottiene il nostro ambito di database
l'accesso a

00:09:58.100 --> 00:10:01.790
qualsiasi database
che si desidera connettere.

00:10:01.790 --> 00:10:05.390
Se non si è in
le regole del firewall a livello di database,

00:10:05.390 --> 00:10:08.735
poi successivo controllo avviene
è a livello di server,

00:10:08.735 --> 00:10:11.180
che è leggermente
diversa DMV chiamata

00:10:11.180 --> 00:10:15.440
sys.firewall_rules ed è
nel database master.

00:10:15.440 --> 00:10:17.420
Se avete accesso qui,

00:10:17.420 --> 00:10:19.160
poi, naturalmente, si ha accesso a

00:10:19.160 --> 00:10:21.965
il livello del server in modo
una volta che si è connessi,

00:10:21.965 --> 00:10:24.635
è possibile in Gestione
menu a discesa Studio,

00:10:24.635 --> 00:10:26.725
scegliere sia DB1 che DB2.

00:10:26.725 --> 00:10:29.635
>> Ok. Quindi, se fossi
configurazione tramite

00:10:29.635 --> 00:10:33.395
SSMS per configurare
database SQL di Azure.

00:10:33.395 --> 00:10:37.680
Se dico che il firewall
regola a livello di server,

00:10:37.680 --> 00:10:39.810
potrebbe semplicemente darmi
l'accesso a tutto.

00:10:39.810 --> 00:10:41.130
>> L'ho ottenuto.

00:10:41.130 --> 00:10:45.165
>> Quindi probabilmente dovremmo andare a
Test di sviluppo ma non nelle procedure consigliate.

00:10:45.165 --> 00:10:48.180
>> Sì. Cioè
una grande domanda, Colin,

00:10:48.180 --> 00:10:53.075
perché una delle cose è che
perché abbiamo questi due livelli?

00:10:53.075 --> 00:10:55.560
È perché nella produzione,

00:10:55.560 --> 00:10:59.045
se si desidera utilizzare ciò che è
chiamato come utente indipendente,

00:10:59.045 --> 00:11:01.595
allora la migliore pratica è,

00:11:01.595 --> 00:11:06.515
utente indipendente consente solo di
impostare un utente indipendente per DB1.

00:11:06.515 --> 00:11:11.340
L'intera idea di utente indipendente
non riesco ad accedere a DB2.

00:11:11.410 --> 00:11:14.780
In combinazione con
le regole del firewall del database,

00:11:14.780 --> 00:11:20.555
Posso anche limitare l'indirizzo IP
da dove gli utenti possono accedere.

00:11:20.555 --> 00:11:23.180
Quindi, essenzialmente,
firewall a livello di database

00:11:23.180 --> 00:11:25.010
è una funzione utile per i dati di profondità

00:11:25.010 --> 00:11:30.515
gestire l'ambito di
persone cattive possono connettersi da.

00:11:30.515 --> 00:11:31.980
>> Ok.

00:11:32.260 --> 00:11:35.450
Quindi, di nuovo, aiutami qui.

00:11:35.450 --> 00:11:37.430
Potresti espandere alcuni dettagli.

00:11:37.430 --> 00:11:42.650
Quindi, sulle regole del firewall questi
sono all'interno del server SQL e

00:11:42.650 --> 00:11:44.750
come ovviamente poi quello che abbiamo
coperto in precedenza è stato

00:11:44.750 --> 00:11:48.215
le regole del firewall per
la rete al suo interno.

00:11:48.215 --> 00:11:50.630
>> sì. Quindi quelli sono
due concetti distinti.

00:11:50.630 --> 00:11:52.220
Così nella diapositiva precedente ho mostrato

00:11:52.220 --> 00:11:54.155
c'è un indirizzo IP
firewall basato su firewall.

00:11:54.155 --> 00:11:58.820
Questo è ciò che è e
il luogo in cui

00:11:58.820 --> 00:12:03.995
sono memorizzati è all'interno del master
database all'interno di SQL Server.

00:12:03.995 --> 00:12:07.050
Sono esposti attraverso il portale.

00:12:07.870 --> 00:12:11.660
Naturalmente se non si incontrano
uno di questi criteri poi

00:12:11.660 --> 00:12:15.870
la connessione verrà rifiutata
che è quello di cui abbiamo parlato.

00:12:16.090 --> 00:12:18.350
Ora, diamo un'occhiata a

00:12:18.350 --> 00:12:21.875
la nuova parte interessante qui
che è le regole del firewall VNet.

00:12:21.875 --> 00:12:25.235
Quindi mi permetta di impostare
lo scenario per voi.

00:12:25.235 --> 00:12:27.830
Quindi supponiamo di avere
una macchina virtuale

00:12:27.830 --> 00:12:32.135
in esecuzione dire un'applicazione legacy
su iOS o qualsiasi altra cosa.

00:12:32.135 --> 00:12:37.100
La macchina virtuale in genere
ha è possibile impostare ciò che si chiama

00:12:37.100 --> 00:12:42.260
come un indirizzo IP pubblico per esso
che è il 14.11 per affrontare,

00:12:42.260 --> 00:12:45.200
e si può anche avere
un indirizzo IP privato che

00:12:45.200 --> 00:12:48.305
proviene da una particolare sottorete.

00:12:48.305 --> 00:12:51.020
Quindi le migliori pratiche
sempre fare in modo che

00:12:51.020 --> 00:12:53.600
i tuoi IP privati sono
provenienti da sottoreti,

00:12:53.600 --> 00:12:55.490
aiuta nella segmentazione della rete

00:12:55.490 --> 00:12:57.920
e questa è una rete
le migliori pratiche.

00:12:57.920 --> 00:13:00.305
Ma vi mostrerò come aiuta.

00:13:00.305 --> 00:13:02.990
>> In genere sempre
impostare quella cosa o ottenere

00:13:02.990 --> 00:13:05.270
un professionista IT di rete per impostare tali

00:13:05.270 --> 00:13:07.865
prima di andare a
una produzione diversa.

00:13:07.865 --> 00:13:10.625
Si desidera assicurarsi
hai abbastanza IP.

00:13:10.625 --> 00:13:11.930
>> Sì, assolutamente.

00:13:11.930 --> 00:13:13.985
È un buon punto
che si porta in su è

00:13:13.985 --> 00:13:16.985
vogliamo sicuramente
separazione dei doveri qui,

00:13:16.985 --> 00:13:20.390
è sempre bene pianificare
la rete in anticipo.

00:13:20.390 --> 00:13:22.790
Così non si esaurisce
di indirizzi IP e

00:13:22.790 --> 00:13:26.495
allora certamente non lo fanno
vogliono un DBM pasticcio

00:13:26.495 --> 00:13:32.030
intorno con l'impostazione di questi e
sbagliare la taglia o perché

00:13:32.030 --> 00:13:37.850
ognuno di questi è facile
per perdere le cose qui.

00:13:37.850 --> 00:13:40.280
>> sì, e una volta che hai
impostare quegli intervalli e

00:13:40.280 --> 00:13:42.995
iniziato a installare le cose
è che non si può tornare indietro.

00:13:42.995 --> 00:13:47.000
>> L'ho ottenuto. Quindi c'è
l'impostazione di base.

00:13:47.000 --> 00:13:50.930
Ho una macchina virtuale, ha un
l'indirizzo IP e un indirizzo IP privato.

00:13:50.930 --> 00:13:54.020
Lasciate che vi porti attraverso
opzione numero uno che è come

00:13:54.020 --> 00:13:57.350
mi connetto al database SQL
utilizzando il pubblico,

00:13:57.350 --> 00:14:01.190
in genere lo chiamiamo
l'indirizzo IP strappato.

00:14:01.190 --> 00:14:04.130
Opzione numero uno è cominciamo da

00:14:04.130 --> 00:14:06.980
il lato VM e siamo in grado di definire ciò che è

00:14:06.980 --> 00:14:09.230
chiamato come regola NSG che

00:14:09.230 --> 00:14:12.455
fondamentalmente dice che sto andando
per consentire il traffico in uscita.

00:14:12.455 --> 00:14:14.630
>> Gruppo di sicurezza di rete, gruppo di sicurezza di rete?

00:14:14.630 --> 00:14:17.170
>> Gruppo di sicurezza di rete
che esistono su

00:14:17.170 --> 00:14:21.120
la macchina virtuale nella macchina virtuale.

00:14:21.120 --> 00:14:24.305
Consente di definire
regole in entrata e in uscita.

00:14:24.305 --> 00:14:28.865
Quindi qui definiremo un in uscita
per la connessione al database SQL.

00:14:28.865 --> 00:14:31.880
Il modo in cui lo faremo
è che diremo che ho bisogno di

00:14:31.880 --> 00:14:35.225
connettersi a 1433 perché
questa è la mia iniziale.

00:14:35.225 --> 00:14:37.460
Ricordate inizialmente che
bisogno di connettersi a

00:14:37.460 --> 00:14:40.565
il gateway che è
investire sulla porta 1433.

00:14:40.565 --> 00:14:43.700
Poi, ho bisogno dei 11.000 attraverso

00:14:43.700 --> 00:14:48.170
11.999 gamma perché sono
intenzione di utilizzare il reindirizzamento.

00:14:48.170 --> 00:14:50.990
Allora TCP è il mio protocollo.

00:14:50.990 --> 00:14:54.425
I miei indirizzi IP l'indirizzo 40.112

00:14:54.425 --> 00:14:57.815
e sulla destra
il pezzo più interessante.

00:14:57.815 --> 00:15:01.355
Sto dicendo lasciare che questa macchina virtuale

00:15:01.355 --> 00:15:04.415
connettersi a tutto in SQL. WestUS.

00:15:04.415 --> 00:15:08.615
Quindi questo è di nuovo un altro networking
concetto chiamato un tag di servizio.

00:15:08.615 --> 00:15:12.935
Quindi ciò significa che voglio
per connettersi al database SQL.

00:15:12.935 --> 00:15:15.410
So che il mio database è in WestUS,

00:15:15.410 --> 00:15:19.715
mi permetta solo whitelist
traffico verso la regione di WestUS.

00:15:19.715 --> 00:15:21.125
>> Questo è molto buono.

00:15:21.125 --> 00:15:24.455
Così si potrebbe semplicemente lasciare
me uso che come un o

00:15:24.455 --> 00:15:29.795
solo gli usi per aiutare con
solo la latenza e il traffico.

00:15:29.795 --> 00:15:32.390
>> Sì, voglio dire
una linea di fondo qui è questo

00:15:32.390 --> 00:15:36.620
è un modo per abilitare il
connettività dal lato della rete.

00:15:36.620 --> 00:15:38.450
Quindi, in genere il vostro
amministratore di rete farà

00:15:38.450 --> 00:15:41.540
questo e rende solo
gestione più facile

00:15:41.540 --> 00:15:42.770
per loro, perché quando dici

00:15:42.770 --> 00:15:46.940
Sql. WestUS non è necessario
whitelist indirizzo IP individuale.

00:15:46.940 --> 00:15:49.610
Così ti permette di
connettersi a qualsiasi cosa in

00:15:49.610 --> 00:15:53.180
qualsiasi database SQL che
nella regione di WestUS.

00:15:53.180 --> 00:15:55.850
Ora anche questo incorre

00:15:55.850 --> 00:15:57.845
un sovraccarico aggiuntivo
nel senso che

00:15:57.845 --> 00:15:59.990
una volta che hai finito con
l'impostazione di rete,

00:15:59.990 --> 00:16:02.000
è necessario venire su
il lato database SQL

00:16:02.000 --> 00:16:04.655
e ancora una volta ricordare il nostro
firewall degli indirizzi IP.

00:16:04.655 --> 00:16:06.845
Quindi è necessario aggiungere l'indirizzo IP qui.

00:16:06.845 --> 00:16:08.975
Quindi questo è un processo in due fasi.

00:16:08.975 --> 00:16:12.230
I lati negativi di questo sono uno dei

00:16:12.230 --> 00:16:15.440
è necessario gestire l'indirizzo IP.

00:16:15.440 --> 00:16:19.520
Così, per esempio, in qualsiasi momento se si
concatenare l'indirizzo IP pubblico per

00:16:19.520 --> 00:16:22.280
la macchina virtuale immediatamente
questa connettività sarà

00:16:22.280 --> 00:16:25.400
rotto perché SQL non
riconoscere tale indirizzo IP.

00:16:25.400 --> 00:16:27.200
>> Sì, perché non [incomprensibile].

00:16:27.200 --> 00:16:30.740
>> Sì. L'altra cosa
su questo che

00:16:30.740 --> 00:16:33.140
alcuni clienti potrebbero non piace è poi

00:16:33.140 --> 00:16:36.155
un tag di servizio è ancora
abbastanza spalancata.

00:16:36.155 --> 00:16:37.805
Dice mi permette di collegarmi a

00:16:37.805 --> 00:16:41.840
qualsiasi database SQL in
regione di WestUS.

00:16:41.840 --> 00:16:44.090
Ma, naturalmente, ci sono miglioramenti

00:16:44.090 --> 00:16:46.130
in arrivo sul lato della rete
che vi permetterà di

00:16:46.130 --> 00:16:48.575
limitarlo a una risorsa specifica

00:16:48.575 --> 00:16:51.035
ma quelli sono in
progressi in questo momento.

00:16:51.035 --> 00:16:52.820
Ma questo è ciò che abbiamo.

00:16:52.820 --> 00:16:58.775
Quindi ora capovolgiamo la direzione
da cui veniamo qui.

00:16:58.775 --> 00:17:02.720
Hai visto come abbiamo impostato da
il lato VM al database SQL.

00:17:02.720 --> 00:17:05.240
La regola del firewall Vnet è
qualcosa che si imposta

00:17:05.240 --> 00:17:07.400
un ballo di prom il lato database SQL come

00:17:07.400 --> 00:17:11.330
questo per dire mi permettono di collegare da

00:17:11.330 --> 00:17:17.135
il mio database SQL per
una particolare sottorete.

00:17:17.135 --> 00:17:21.005
Quindi la sua bellezza
è che non è necessario

00:17:21.005 --> 00:17:25.280
per bianchersi tutti gli indirizzi IP
o fare qualcosa di simile.

00:17:25.280 --> 00:17:28.460
Tutto quello che stai dicendo è
l'apertura di un tracciato tra

00:17:28.460 --> 00:17:29.960
database SQL e

00:17:29.960 --> 00:17:33.620
una particolare sottorete e si sta
utilizzando l'indirizzo IP privato.

00:17:33.620 --> 00:17:36.485
Quindi c'è che anche
beneficio aggiunto che

00:17:36.485 --> 00:17:42.455
tutto sta attraversando
la rete backbone di Azure in modo saggio.

00:17:42.455 --> 00:17:43.970
>> Questo è abbastanza fresco.

00:17:43.970 --> 00:17:50.750
>> Altro vantaggio di questo è
nessuna whitelist necessaria e sì,

00:17:50.750 --> 00:17:52.625
questo è più o meno.

00:17:52.625 --> 00:17:56.420
>> Cool. Quindi grazie per questo.

00:17:56.420 --> 00:17:58.160
Questa è davvero una buona spiegazione di

00:17:58.160 --> 00:18:01.220
la connettività a
Database SQL di Azure.Azure SQL Database.

00:18:01.220 --> 00:18:03.780
Un paio di altre domande veloci,

00:18:03.790 --> 00:18:06.680
è solo per Azure
database SQL come tutti

00:18:06.680 --> 00:18:08.780
loro il diverso
opzioni di distribuzione.

00:18:08.780 --> 00:18:11.855
Penso che abbiamo un singolo elastico
l'obiettivo è stato gestito.

00:18:11.855 --> 00:18:12.290
>> Assolutamente.

00:18:12.290 --> 00:18:15.360
>> È per tutti loro questo
influenzate le opzioni spiegate?

00:18:15.360 --> 00:18:18.530
>> Così, quando si parla di
Database SQL di Azure oggi,

00:18:18.530 --> 00:18:23.180
se si guarda a un singolo
Database SQL, pool elastici,

00:18:23.180 --> 00:18:26.779
data warehouse e
anche i database open source,

00:18:26.779 --> 00:18:30.200
condividiamo un controllo comune
piano che significa

00:18:30.200 --> 00:18:34.640
dire il gateway SQL che si
visto che componente è comune.

00:18:34.640 --> 00:18:37.820
Quindi questa connettività si applica a

00:18:37.820 --> 00:18:39.410
tutte le nostre offerte che sono sotto

00:18:39.410 --> 00:18:41.525
l'ombrello del database SQL di Azure.

00:18:41.525 --> 00:18:44.690
>> È fantastico. Beh, grazie

00:18:44.690 --> 00:18:47.600
molto tutti per
sintonizzare e darci

00:18:47.600 --> 00:18:50.210
un like se ti piace
questo tipo di contenuto

00:18:50.210 --> 00:18:53.300
e sottoscrivere a noi e faremo
ci vediamo più tardi. Grazie.

00:18:53.300 --> 00:19:06.000
[MUSICA]

