WEBVTT

00:00:00.000 --> 00:00:11.610
[MUSIK].

00:00:11.610 --> 00:00:13.680
>> Hallo, jeder, mein Name
ist Colin Murphy.

00:00:13.680 --> 00:00:16.065
Ich bin ein Produktmarketing
Manager bei Microsoft,

00:00:16.065 --> 00:00:17.865
und ich bin hier mit Rohit, um

00:00:17.865 --> 00:00:20.730
Besprechen der Konnektivität
für Azure SQL-Datenbank.

00:00:20.730 --> 00:00:24.200
Also willkommen, Rohit. So würde
Sie denken nur, uns zu sagen

00:00:24.200 --> 00:00:28.700
nur die Grundkonzepte, wie Sie
eine Verbindung mit der Azure SQL-Datenbank herstellen?

00:00:28.700 --> 00:00:31.250
>> Absolut. Hallo
jeder, mein Name ist Rohit.

00:00:31.250 --> 00:00:34.300
Ich bin Programmmanager in
sql-Datenbankteam.

00:00:34.300 --> 00:00:37.790
Heute mit Colin sind wir
gehen, um zu starten und nehmen Sie

00:00:37.790 --> 00:00:41.120
durch die Art und Weise, wie Sie sich verbinden
in Azure SQL-Datenbank.

00:00:41.120 --> 00:00:43.375
Also, lassen Sie uns beginnen.

00:00:43.375 --> 00:00:45.525
Also erste Frage.

00:00:45.525 --> 00:00:48.905
Lassen Sie uns ein wenig verstehen
über unsere Architektur, bevor wir

00:00:48.905 --> 00:00:52.370
gehen Sie zu der nitty-gritty, wie
Sie eine Verbindung herstellen.

00:00:52.370 --> 00:00:55.265
Also als Kunde, was
Sie müssen wissen, ist

00:00:55.265 --> 00:00:58.080
dass wir einen Haufen von
SQL-Gateways, die

00:00:58.080 --> 00:00:59.895
unsere Front-End-Maschinen, die

00:00:59.895 --> 00:01:02.060
Eingehende Verbindungen über
das Internet, wenn Sie

00:01:02.060 --> 00:01:06.825
Verbindung von vor Ort
oder außerhalb von Azure.

00:01:06.825 --> 00:01:08.710
>> Diese sind nur ein Teil
des vergangenen Dienstes.

00:01:08.710 --> 00:01:10.470
Sie können nur sehen, ob es leichtsinnig ist.

00:01:10.470 --> 00:01:13.510
>> Ja. Dann haben wir einen Haufen
von Back-End-Maschinen, bei denen

00:01:13.510 --> 00:01:20.195
Ihre eigentlichen SQL-Datenbanken sind
gehostet und Ihre Daten leben dort.

00:01:20.195 --> 00:01:21.610
>> Okay.

00:01:21.710 --> 00:01:27.450
>> Ich versuche, eine Verbindung herzustellen
myserver.database.windows.net,

00:01:27.450 --> 00:01:31.435
das ist das übliche Format
für alle Datenbankserver.

00:01:31.435 --> 00:01:34.045
In der Regel, wenn Sie
NsLookup dazu,

00:01:34.045 --> 00:01:36.370
es wird sich entschließt,
diese öffentliche IP-Adresse.

00:01:36.370 --> 00:01:38.680
Die 104.42 IP ist

00:01:38.680 --> 00:01:40.870
eine öffentliche IP-Adresse und Sie sind

00:01:40.870 --> 00:01:43.615
wird eine Verbindung herstellen
zu diesem an Der Hafen 1433,

00:01:43.615 --> 00:01:46.055
das ist, wo wir sind
Abhören von Verbindungen.

00:01:46.055 --> 00:01:48.885
Wenn Sie eine Verbindung herstellen,

00:01:48.885 --> 00:01:52.380
die gemeinsamen Dinge, die
geschieht, wir im Grunde,

00:01:52.380 --> 00:01:55.395
SQL Gateway forwards
Ihre Verbindung eingeschaltet,

00:01:55.395 --> 00:01:57.770
so haben Sie eine klebrige
Verbindung, die durchgeht

00:01:57.770 --> 00:02:00.545
Gateway und Verbinden
an den Back-End-Knoten.

00:02:00.545 --> 00:02:03.425
Dies wird als Proxy bezeichnet.
Verbindungsrichtlinie.

00:02:03.425 --> 00:02:05.570
Also alles, was das Gateway tut, ist, dass es

00:02:05.570 --> 00:02:09.110
ein Handbuch in der Mitte
Ihre Verbindung zum Back-End.

00:02:09.110 --> 00:02:10.670
>> Das ist gut, denn
wir nie entlarven

00:02:10.670 --> 00:02:13.130
die tatsächliche IP des SQL-Knotens.

00:02:13.130 --> 00:02:15.140
>> Ich habe es bekommen. So sind Sie also

00:02:15.140 --> 00:02:17.330
verbinden, wenn Sie eine Verbindung herstellen
von außerhalb von Azure.

00:02:17.330 --> 00:02:20.090
Nun, wenn Sie eine Verbindung herstellen,
aus dem Inneren von Azure,

00:02:20.090 --> 00:02:23.915
von einer VM aus, machen wir eine leicht
unterschiedliche Verbindungsweise.

00:02:23.915 --> 00:02:27.170
So verbinden wir uns mit dem
SQL Gateway und wir erhalten

00:02:27.170 --> 00:02:32.540
den tatsächlichen Standort Ihrer
SQL-Datenbank im Back-End.

00:02:32.540 --> 00:02:35.810
Sie werden also diese Adresse 13.93 sehen.

00:02:35.810 --> 00:02:37.535
Das ist eine private IP-Adresse.

00:02:37.535 --> 00:02:40.930
Es ist nicht etwas, das Benutzer
kann sich direkt verbinden,

00:02:40.930 --> 00:02:42.815
wie, sie wissen nicht
über diese IP-Adresse.

00:02:42.815 --> 00:02:43.325
>> Okay.

00:02:43.325 --> 00:02:46.385
>> Um es dann weiter zu randomisieren,

00:02:46.385 --> 00:02:52.250
Es gibt 11.000-11.999 Port-Bereich.

00:02:52.250 --> 00:02:53.575
>> Okay.

00:02:53.575 --> 00:02:58.885
>> So sql könnte zuhören
solche innerhalb dieses Bereichs.

00:02:58.885 --> 00:03:02.010
Hier ist, was
passiert ist dies als

00:03:02.010 --> 00:03:06.560
Die Umleitungsmethode oder Umleitung
ist die Verbindungsrichtlinie,

00:03:06.560 --> 00:03:08.615
aber wir leiten Sie zu diesem Knoten um.

00:03:08.615 --> 00:03:11.345
So verbinden Sie sich direkt
in die SQL-Datenbank,

00:03:11.345 --> 00:03:13.400
und das Gateway kommt nicht in

00:03:13.400 --> 00:03:17.040
das Bild immer wieder
dieser Verbindung.

00:03:17.090 --> 00:03:18.525
>> Okay.

00:03:18.525 --> 00:03:20.900
>> Das ist also die Grundarchitektur

00:03:20.900 --> 00:03:23.210
und Sie verstehen, wie man sich verbindet.

00:03:23.210 --> 00:03:24.920
Nun, lassen Sie mich Sie nehmen
durch das, was passiert

00:03:24.920 --> 00:03:27.410
wenn Ihre Verbindung tatsächlich
schafft es zum Gateway.

00:03:27.410 --> 00:03:28.345
>> Okay.

00:03:28.345 --> 00:03:32.235
>> Das ist sehr, sehr einfach
High-Level-Sachen, nichts Besonderes,

00:03:32.235 --> 00:03:36.520
und das gibt es schon seit Ewigkeiten.

00:03:36.520 --> 00:03:40.375
So haben Sie einen Kunden und Sie
haben die Gateway-Maschine,

00:03:40.375 --> 00:03:43.350
das erste ist
der Drei-Wege-Handshake,

00:03:43.350 --> 00:03:47.835
Standard-PCP-Material, [unhörbar]
Kommunikation mit dem Server.

00:03:47.835 --> 00:03:50.720
Interessante Sache, was
passiert als nächstes, ob Sie

00:03:50.720 --> 00:03:53.090
ein Prelogin-Paket
dass der Client sendet,

00:03:53.090 --> 00:03:55.840
und interessante Merkmale hier ist,

00:03:55.840 --> 00:03:57.900
wir wollen, dass Sie,

00:03:57.900 --> 00:04:00.820
als bewährte Methode, Verschlüsselung verwenden,

00:04:00.820 --> 00:04:03.425
die durch Setzen

00:04:03.425 --> 00:04:07.490
Verschlüsseln gleich wahr in der Verbindung
Zeichenfolge Ihrer Anwendung.

00:04:07.490 --> 00:04:10.640
Anderer Teil, den wir wollen,
als bewährte Methode

00:04:10.640 --> 00:04:13.415
ist TrustServerCertificate
gleich falsch.

00:04:13.415 --> 00:04:16.940
Dies zwingt den Client,

00:04:16.940 --> 00:04:21.890
das Zertifikat, das Sie
vom Gateway-Knoten.

00:04:21.890 --> 00:04:23.580
So haben Sie keine

00:04:23.580 --> 00:04:28.215
jede Chance auf Spoofing oder
Man-in-the-Middle-Angriffe.

00:04:28.215 --> 00:04:30.105
>> Okay, das macht durchaus Sinn.

00:04:30.105 --> 00:04:32.670
Dies sind also die best practices und

00:04:32.670 --> 00:04:34.860
Jeder Entwickler, der eine Verbindung herstellt
SQL findet

00:04:34.860 --> 00:04:37.285
dies auf unseren Docs-Seiten
oder wo der Ort?

00:04:37.285 --> 00:04:40.080
>> ja. In der Tat haben wir
einen Schritt weiter zu gehen.

00:04:40.080 --> 00:04:42.300
Wenn Sie in das Portal gehen und

00:04:42.300 --> 00:04:44.960
Ihre SQL-Datenbank und suchen
an der Verbindungsschnur,

00:04:44.960 --> 00:04:46.550
diese werden dort eingesetzt.

00:04:46.550 --> 00:04:47.735
>> All dies sind die Standardeinstellungen?

00:04:47.735 --> 00:04:49.340
>> Ja. Also setzen Sie sie in

00:04:49.340 --> 00:04:51.320
um sicherzustellen, dass
Sie geschützt sind.

00:04:51.320 --> 00:04:52.075
>> Okay.

00:04:52.075 --> 00:04:53.940
>> Dann von hier aus,

00:04:53.940 --> 00:04:55.110
das Prelog und die Antwort,

00:04:55.110 --> 00:04:57.600
das wieder Teil ist
des TDS-Protokolls,

00:04:57.600 --> 00:05:00.410
und dann haben Sie
dieser TLS-Handshake, der

00:05:00.410 --> 00:05:02.690
eine lange windige Art und Weise,

00:05:02.690 --> 00:05:04.820
einen sicheren Kanal zwischen
Client und Server.

00:05:04.820 --> 00:05:05.320
>> Okay.

00:05:05.320 --> 00:05:07.220
>> Also im Wesentlichen bei
das Ende dieses Prozesses,

00:05:07.220 --> 00:05:09.680
Sie sind sicher vor
die Protokollperspektive,

00:05:09.680 --> 00:05:14.500
und beginnt dann
das eigentliche Login-Paket, das

00:05:14.500 --> 00:05:16.020
Sie werden es als

00:05:16.020 --> 00:05:18.200
Login-Verkaufspaket, wenn

00:05:18.200 --> 00:05:20.270
Sie würden über Schock tun
oder so ähnlich.

00:05:20.270 --> 00:05:23.330
Dann, basierend auf dem, was Sie verwenden,

00:05:23.330 --> 00:05:26.720
wenn Sie eine Verbindung zu
uns aus dem proximalen,

00:05:26.720 --> 00:05:29.215
du wirst einfach
die Bestätigung zurück.

00:05:29.215 --> 00:05:31.985
Andernfalls erhalten Sie, was
als Umleitungstoken aufgerufen,

00:05:31.985 --> 00:05:33.485
das ist eine schicke Art zu sagen,

00:05:33.485 --> 00:05:35.000
wir teilen Ihnen die private IP-

00:05:35.000 --> 00:05:36.895
Adresse, die Sie sind
zu verbinden.

00:05:36.895 --> 00:05:39.290
>> Wow, es gibt viel Händeschütteln
rückwärts gehen [unhörbar].

00:05:39.290 --> 00:05:39.980
>> Ja.

00:05:39.980 --> 00:05:41.690
>> Ist das ein langer Prozess oder?

00:05:41.690 --> 00:05:44.075
>> Nein, es ist eine Frage von Millisekunden.

00:05:44.075 --> 00:05:45.170
>> Oh okay.

00:05:45.170 --> 00:05:48.530
>> ja, wir halten es schnell
auch und wir halten es sicher.

00:05:48.530 --> 00:05:50.870
>> Okay, das ist gut.
Schnell und sicher.

00:05:50.870 --> 00:05:52.720
>> ja. Als nächstes,

00:05:52.720 --> 00:05:55.100
jetzt, da wir über
die Architektur und wir wissen,

00:05:55.100 --> 00:05:58.460
über die Grundlagen der Konnektivität,

00:05:58.460 --> 00:06:00.395
lassen Sie uns darüber sprechen, wer eine Verbindung herstellen kann.

00:06:00.395 --> 00:06:03.055
So wollen Sie setzen
einige Kontrollen über,

00:06:03.055 --> 00:06:05.570
wie filtern Sie tatsächlich, wer

00:06:05.570 --> 00:06:08.345
kann eine Verbindung zu
Ihre Azure SQL-Datenbank.

00:06:08.345 --> 00:06:11.075
So ist dies, und ich werde
zeigen Sie dies in der Demo.

00:06:11.075 --> 00:06:16.055
Dies ist im Grunde die Firewall
Blade-Ordner im Azure-Portal.

00:06:16.055 --> 00:06:17.900
Das erste, was Sie hier bemerken werden

00:06:17.900 --> 00:06:19.430
ist dieser Abschnitt oben, der sagt:

00:06:19.430 --> 00:06:22.550
zugang zu ermöglichen
Azure-Dienste, ein- oder ausgeschaltet.

00:06:22.550 --> 00:06:25.340
Dies ist also eine sehr breite Kategorie

00:06:25.340 --> 00:06:26.855
der Erlaubnis, die
Sie geben hier.

00:06:26.855 --> 00:06:28.420
Es heißt im Grunde:

00:06:28.420 --> 00:06:32.065
können alle anderen Server, die
in Azure ausgeführt werden,

00:06:32.065 --> 00:06:35.915
wie eine Web-App sagen
oder eine andere Azure-VM,

00:06:35.915 --> 00:06:40.815
kann es sich mit Ihrem
SQL-Datenbankserver oder nicht?

00:06:40.815 --> 00:06:42.420
>> Wie überall in Azure?

00:06:42.420 --> 00:06:42.545
>> Ja.

00:06:42.545 --> 00:06:46.245
>> Wurde es von einer Region gesetzt
oder Zone oder Datencenter?

00:06:46.245 --> 00:06:47.205
>> Es spielt keine Rolle.

00:06:47.205 --> 00:06:47.940
>> Es spielt keine Rolle.

00:06:47.940 --> 00:06:49.910
>> Grundsätzlich ist das, was das tut,

00:06:49.910 --> 00:06:52.060
wenn Sie laufen
Dienste in Azure,

00:06:52.060 --> 00:06:57.605
jede Region oder jedes Rechenzentrum hat
eine Reihe fester IP-Adressen.

00:06:57.605 --> 00:07:00.710
Wir sind also im Grunde genommen eine Regel, die

00:07:00.710 --> 00:07:03.560
sagt alles, was
von einer Idee zu mir kommen.

00:07:03.560 --> 00:07:03.935
>> Von innerhalb von Azure.

00:07:03.935 --> 00:07:04.205
>> ja.

00:07:04.205 --> 00:07:05.165
>> Ein vertrauenswürdiges Rechenzentrum.

00:07:05.165 --> 00:07:05.675
>> Ja.

00:07:05.675 --> 00:07:07.460
>> Also akzeptiere ich? Haben Sie.

00:07:07.460 --> 00:07:10.100
>> Jetzt sind natürlich die Menschen
Vorbehalte gegen

00:07:10.100 --> 00:07:12.875
dies, weil dies
ein wenig breiterer Rahmen,

00:07:12.875 --> 00:07:15.215
aber in einigen Szenarien,

00:07:15.215 --> 00:07:16.280
Sie müssen dies tun.

00:07:16.280 --> 00:07:18.785
Beispielsweise ist die Web-App ein Beispiel.

00:07:18.785 --> 00:07:21.620
Aber nach und nach sind wir
mit Angeboten an

00:07:21.620 --> 00:07:25.295
wo Sie in der Lage sein werden,
dies bei aus und kommen.

00:07:25.295 --> 00:07:27.650
Ich werde dir zeigen
unterschiedliche Na-

00:07:27.650 --> 00:07:29.285
>> Ich werde es tun
Kaufen eines Servicetyps

00:07:29.285 --> 00:07:30.845
oder so etwas wie ein
Web-App oder so?

00:07:30.845 --> 00:07:31.465
>> Ja.

00:07:31.465 --> 00:07:32.985
>> Dann nur um zu klären,

00:07:32.985 --> 00:07:36.120
wenn Sie einen Dienst in Azure sagen,

00:07:36.120 --> 00:07:38.160
es ist in Ihrem eigenen
Beschreibung natürlich.

00:07:38.160 --> 00:07:38.925
>> Ja.

00:07:38.925 --> 00:07:41.115
>> Nur um das für die Menschen zu klären.

00:07:41.115 --> 00:07:44.420
>> ja. Die nächste Kontrollebene

00:07:44.420 --> 00:07:47.525
dass wir anbieten, ist, was
IP-basierte Firewall.

00:07:47.525 --> 00:07:55.080
Dies ist in der Regel, wenn Sie
Bereitstellung von Azure SQL Database-Server,

00:07:55.080 --> 00:07:58.080
die Standardliste hier ähnlich.

00:07:58.080 --> 00:08:01.430
So kann sich niemand daran verbinden, indem

00:08:01.430 --> 00:08:04.820
Verwendung einer IP-Adresse, es sei denn,
sie sind in dieser Liste.

00:08:04.820 --> 00:08:05.580
>> Sie haben sie.

00:08:05.580 --> 00:08:07.305
>> Also das Erste
Sie tun müssen, ist,

00:08:07.305 --> 00:08:09.195
wenn Sie zum Portal gehen,

00:08:09.195 --> 00:08:12.125
Es zeigt Ihnen die IP-Adresse
dass du kommst.

00:08:12.125 --> 00:08:14.690
Also, wenn ich von meinem Haus IP komme,

00:08:14.690 --> 00:08:17.945
das ist, wo es in
dieser Client-IP-Adressabschnitt,

00:08:17.945 --> 00:08:20.810
und ich muss auf die Whitelist setzen, dass
damit ich in der Lage bin,

00:08:20.810 --> 00:08:23.755
zum Herstellen einer Verbindung mit
Management Studio zum Beispiel.

00:08:23.755 --> 00:08:25.210
>> Okay. Ziemlich Standard-Sachen,

00:08:25.210 --> 00:08:26.840
wir haben alles standardmäßig erledigt.

00:08:26.840 --> 00:08:27.485
>> Genau.

00:08:27.485 --> 00:08:28.450
>> Okay.

00:08:28.450 --> 00:08:30.890
>> Jetzt haben wir
eine dritte interessante Art und Weise,

00:08:30.890 --> 00:08:33.845
Verbinden, das als
VNet-Firewall-Regeln.

00:08:33.845 --> 00:08:35.785
Das ist ziemlich viel zu sagen,

00:08:35.785 --> 00:08:37.985
Alle Azure-VMs zulassen

00:08:37.985 --> 00:08:41.390
innerhalb eines VNet zum Verbinden
in meine SQL-Datenbank.

00:08:41.390 --> 00:08:44.030
Nun könnte es Situationen geben, in denen
wo dies nützlich ist,

00:08:44.030 --> 00:08:46.370
Sagen Sie, dass Sie eine Legacy-App haben
oder Ihre App, sagen wir,

00:08:46.370 --> 00:08:47.900
Reporting-Services, die in

00:08:47.900 --> 00:08:51.060
eine VM und Sie möchten
Verbindung mit SQL-Datenbank herstellen,

00:08:51.060 --> 00:08:53.555
Dies ist ein granularer Weg
dies zu tun, um

00:08:53.555 --> 00:08:56.270
nur einen bestimmten Satz von VMs, die

00:08:56.270 --> 00:08:58.970
innerhalb eines Subnetzes
eine Verbindung mit der SQL-Datenbank herstellen.

00:08:58.970 --> 00:08:59.405
>> Okay.

00:08:59.405 --> 00:09:01.565
>> Diese sind also
die drei Arten, wie wir

00:09:01.565 --> 00:09:04.095
Steuerung, die verbindet
sql-Datenbank heute.

00:09:04.095 --> 00:09:05.570
>> ja. Ich kann sehen,
die in verschiedenen bisher

00:09:05.570 --> 00:09:07.430
durch Verschieben von Legacy-Anwendungen.

00:09:07.430 --> 00:09:07.940
>> Absolut.

00:09:07.940 --> 00:09:10.595
>> Wir haben VMs laufen lassen
alle innerhalb des einen VNet.

00:09:10.595 --> 00:09:12.140
>> Ja. Als nächstes,

00:09:12.140 --> 00:09:14.105
Ich werde dich durchführen
Details zu jedem einzelnen.

00:09:14.105 --> 00:09:18.215
Schauen wir uns also an, wie
die IP-basierte Firewall funktioniert.

00:09:18.215 --> 00:09:23.655
Angenommen, wir haben einen Server mit
einige Datenbanken DB1 und DB2,

00:09:23.655 --> 00:09:26.220
und hier ist eine eingehende Verbindung.

00:09:26.220 --> 00:09:30.080
Natürlich ist die eingehende Verbindung
kann Proxy oder Umleitung sein,

00:09:30.080 --> 00:09:31.535
es spielt diesen Punkt keine Rolle.

00:09:31.535 --> 00:09:34.100
Die Annahme ist, dass Sie
vorbei am Gateway und Sie

00:09:34.100 --> 00:09:36.740
tatsächlich kommen auf
SQL-Engine-Ebene.

00:09:36.740 --> 00:09:39.050
Das erste, was wir sind
gehen wir

00:09:39.050 --> 00:09:41.630
um gegen
Firewalls auf Datenbankebene.

00:09:41.630 --> 00:09:43.010
So wird dies in

00:09:43.010 --> 00:09:47.215
die Master-Datenbank und
sys.database_firewall_rules.

00:09:47.215 --> 00:09:49.590
Es ist eine DMV, und alles, was es enthält

00:09:49.590 --> 00:09:52.160
ist ein Bereich von IP-Adressen
die zulässig sind.

00:09:52.160 --> 00:09:55.100
Also, wenn Sie hier sind,
dann standardmäßig,

00:09:55.100 --> 00:09:58.100
Sie erhalten unseren Datenbankbereich
zugang zu

00:09:58.100 --> 00:10:01.790
welche Datenbank auch immer
Sie eine Verbindung herstellen möchten.

00:10:01.790 --> 00:10:05.390
Wenn Sie nicht in
firewallregeln auf Datenbankebene,

00:10:05.390 --> 00:10:08.735
dann die nächste Prüfung erfolgt
auf Serverebene,

00:10:08.735 --> 00:10:11.180
die leicht
verschiedene DMV genannt

00:10:11.180 --> 00:10:15.440
sys.firewall_rules und es ist
wieder in der Masterdatenbank.

00:10:15.440 --> 00:10:17.420
Wenn Sie hier Zugriff haben,

00:10:17.420 --> 00:10:19.160
dann haben Sie natürlich Zugang zu

00:10:19.160 --> 00:10:21.965
die Serverebene so
sobald Sie verbunden sind,

00:10:21.965 --> 00:10:24.635
Sie können in Management
Studio-Dropdown,

00:10:24.635 --> 00:10:26.725
wählen Sie sowohl DB1 als auch DB2.

00:10:26.725 --> 00:10:29.635
>> Okay. Wenn ich also
Konfigurieren mit

00:10:29.635 --> 00:10:33.395
SSMS zum Konfigurieren
meine Azure SQL-Datenbank.

00:10:33.395 --> 00:10:37.680
Wenn ich sage, dass Firewall
Regel auf der Serverebene,

00:10:37.680 --> 00:10:39.810
es könnte mir nur geben
Zugang zu allem.

00:10:39.810 --> 00:10:41.130
>> Haben Sie es.

00:10:41.130 --> 00:10:45.165
>> Also sollten wir wahrscheinlich zu
Dev-Test, aber nicht in Best Practices.

00:10:45.165 --> 00:10:48.180
>> Ja. Das heißt
eine große Frage, Colin,

00:10:48.180 --> 00:10:53.075
weil eines der Dinge ist, dass
Warum haben wir diese beiden Ebenen?

00:10:53.075 --> 00:10:55.560
Es ist, weil in der Produktion,

00:10:55.560 --> 00:10:59.045
wenn Sie verwenden möchten, was
als enthaltener Benutzer aufgerufen werden,

00:10:59.045 --> 00:11:01.595
dann ist die beste Praxis,

00:11:01.595 --> 00:11:06.515
enthaltenen Benutzer nur ermöglicht es Ihnen,
einen geschlossenen Benutzer für DB1 einrichten.

00:11:06.515 --> 00:11:11.340
Die ganze Idee des geschlossenen Benutzers
da ich nicht auf DB2 zugreifen kann.

00:11:11.410 --> 00:11:14.780
In Kombination mit
die Regeln der Datenbankfirewall,

00:11:14.780 --> 00:11:20.555
Ich kann auch die IP-Adresse einschränken
von wo aus sich Benutzer anmelden können.

00:11:20.555 --> 00:11:23.180
Also im Wesentlichen,
Firewall auf Datenbankebene

00:11:23.180 --> 00:11:25.010
ist ein nützliches Feature für Tiefendaten

00:11:25.010 --> 00:11:30.515
stehen für die Verwaltung des Umfangs der
schlechte Menschen können sich von verbinden.

00:11:30.515 --> 00:11:31.980
>> Okay.

00:11:32.260 --> 00:11:35.450
Also noch einmal, hilf mir hier einfach.

00:11:35.450 --> 00:11:37.430
Könnten Sie einige Details erweitern?

00:11:37.430 --> 00:11:42.650
Auf den Firewall-Regeln
sich innerhalb des SQL-Servers befinden und

00:11:42.650 --> 00:11:44.750
wie offensichtlich dann, was wir haben
früher abgedeckt wurde,

00:11:44.750 --> 00:11:48.215
die Firewall-Regeln für
das Netzwerk darin.

00:11:48.215 --> 00:11:50.630
>> ja. Das sind also
zwei unterschiedliche Konzepte.

00:11:50.630 --> 00:11:52.220
So zeigte ich in der vorherigen Folie

00:11:52.220 --> 00:11:54.155
Sie haben eine IP-Adresse
basierte Firewall.

00:11:54.155 --> 00:11:58.820
Das ist es, was das ist und
den Ort, an dem sie

00:11:58.820 --> 00:12:03.995
gespeichert sind, befindet sich innerhalb des Masters
Datenbank in Ihrem SQL Server.

00:12:03.995 --> 00:12:07.050
Sie werden über das Portal ausgesetzt.

00:12:07.870 --> 00:12:11.660
Natürlich, wenn Sie nicht treffen
eines dieser Kriterien dann

00:12:11.660 --> 00:12:15.870
Ihre Verbindung wird abgelehnt
worüber wir gesprochen haben.

00:12:16.090 --> 00:12:18.350
Schauen wir uns nun an

00:12:18.350 --> 00:12:21.875
der neue interessante Teil hier
dies sind die VNet-Firewall-Regeln.

00:12:21.875 --> 00:12:25.235
Lassen Sie mich also
das Szenario für Sie.

00:12:25.235 --> 00:12:27.830
Nehmen wir also an, Sie haben
eine virtuelle Maschine, die

00:12:27.830 --> 00:12:32.135
Ausführen einer Legacy-App
unter iOS oder was auch immer.

00:12:32.135 --> 00:12:37.100
Die virtuelle Maschine ist in der Regel
hat, können Sie einrichten, was als

00:12:37.100 --> 00:12:42.260
als öffentliche IP-Adresse
die 14.11 zu adressieren ist,

00:12:42.260 --> 00:12:45.200
und Sie können auch
eine private IP-Adresse, die

00:12:45.200 --> 00:12:48.305
stammt aus einem bestimmten Subnetz.

00:12:48.305 --> 00:12:51.020
So Best Practices
immer sicherstellen, dass

00:12:51.020 --> 00:12:53.600
Ihre privaten IPs sind
aus Subnetzen,

00:12:53.600 --> 00:12:55.490
hilft bei der Netzwerksegmentierung

00:12:55.490 --> 00:12:57.920
und das ist eine Vernetzung
bewährte Verfahren.

00:12:57.920 --> 00:13:00.305
Aber ich zeige Ihnen, wie es hilft.

00:13:00.305 --> 00:13:02.990
>> Sie sind in der Regel immer
diese Sache aufstellen oder

00:13:02.990 --> 00:13:05.270
ein Netzwerk-IT-Profi, um diese

00:13:05.270 --> 00:13:07.865
bis zu dem
eine andere Produktion.

00:13:07.865 --> 00:13:10.625
Sie möchten sicherstellen, dass
Sie haben genug IP.

00:13:10.625 --> 00:13:11.930
>> Ja, absolut.

00:13:11.930 --> 00:13:13.985
Es ist ein guter Punkt
die Sie aufziehen, ist

00:13:13.985 --> 00:13:16.985
wir wollen auf jeden Fall
Aufgabentrennung hier,

00:13:16.985 --> 00:13:20.390
es ist immer gut zu planen
Ihr Netzwerk im Voraus.

00:13:20.390 --> 00:13:22.790
So dass Sie nicht ausgehen
von IP-Adressen und

00:13:22.790 --> 00:13:26.495
dann nicht sie
wollen ein DBM-Messing

00:13:26.495 --> 00:13:32.030
rund um mit dem Einrichten und
die Größe falsch machen oder weil

00:13:32.030 --> 00:13:37.850
jedes dieser ist einfach
etwas hier zu verpassen.

00:13:37.850 --> 00:13:40.280
>> ja, und sobald Sie
diese Bereiche und

00:13:40.280 --> 00:13:42.995
Gestartete Installation von Dingen
ist, dass Sie nicht rückwärts gehen können.

00:13:42.995 --> 00:13:47.000
>> Haben Sie es. Es gibt also
die grundlegende Einrichtung.

00:13:47.000 --> 00:13:50.930
Ich habe eine VM, sie hat eine öffentliche
IP-Adresse und eine private IP-Adresse.

00:13:50.930 --> 00:13:54.020
Also lassen Sie mich Sie durchführen
Option Nummer eins, wie

00:13:54.020 --> 00:13:57.350
Verbinde ich eine Verbindung mit der SQL-Datenbank
nutzung der Öffentlichkeit,

00:13:57.350 --> 00:14:01.190
wir nennen dies in der Regel
die snatierte IP-Adresse.

00:14:01.190 --> 00:14:04.130
Option Nummer eins ist, dass wir von

00:14:04.130 --> 00:14:06.980
VM-Seite und wir können definieren, was

00:14:06.980 --> 00:14:09.230
als NSG-Regel aufgerufen, die

00:14:09.230 --> 00:14:12.455
im Grunde sagt, ich gehe
, um ausgehenden Datenverkehr zuzulassen.

00:14:12.455 --> 00:14:14.630
>> NSG, Netzwerksicherheitsgruppe?

00:14:14.630 --> 00:14:17.170
>> Netzwerksicherheitsgruppe
die auf

00:14:17.170 --> 00:14:21.120
die VM auf der virtuellen Maschine.

00:14:21.120 --> 00:14:24.305
Es ermöglicht Ihnen,
ein- und ausgehende Regeln.

00:14:24.305 --> 00:14:28.865
Hier definieren wir also eine ausgehende
Regel, um eine Verbindung mit der SQL-Datenbank herzustellen.

00:14:28.865 --> 00:14:31.880
Die Art und Weise, wie wir das tun werden
werden wir sagen, dass ich

00:14:31.880 --> 00:14:35.225
verbindung zu 1433 herstellen, da
das ist meine Initiale.

00:14:35.225 --> 00:14:37.460
Denken Sie zunächst daran, dass Sie
müssen eine Verbindung zu

00:14:37.460 --> 00:14:40.565
das Gateway, das
Investitionen in Hafen 1433.

00:14:40.565 --> 00:14:43.700
Dann brauche ich die 11.000 durch

00:14:43.700 --> 00:14:48.170
11.999 Bereich, weil ich
umleitung zu verwenden.

00:14:48.170 --> 00:14:50.990
Dann ist TCP mein Protokoll.

00:14:50.990 --> 00:14:54.425
Meine IP adressiert die 40.112-Adresse

00:14:54.425 --> 00:14:57.815
und weit über auf der rechten Seite
das interessanteste Stück.

00:14:57.815 --> 00:15:01.355
Ich sage, lassen Sie diese virtuelle Maschine

00:15:01.355 --> 00:15:04.415
verbindung zu allem in SQL herstellen. WestUS.

00:15:04.415 --> 00:15:08.615
Das ist also wieder eine weitere Vernetzung
Konzept, das als Service-Tag bezeichnet wird.

00:15:08.615 --> 00:15:12.935
Das heißt also, ich will
, um eine Verbindung mit der SQL-Datenbank herzustellen.

00:15:12.935 --> 00:15:15.410
Ich weiß, dass sich meine Datenbank in WestUS befindet,

00:15:15.410 --> 00:15:19.715
erlauben Sie mir nur Whitelist
Verkehr in die WestUS-Region.

00:15:19.715 --> 00:15:21.125
>> Das ist sehr gut.

00:15:21.125 --> 00:15:24.455
So könnte man einfach
benutze ich das als oder

00:15:24.455 --> 00:15:29.795
nur die Verwendungen, um mit zu helfen,
nur Ihre Latenz und Verkehr.

00:15:29.795 --> 00:15:32.390
>> Ja, ich meine
ein Fazit hier ist diese

00:15:32.390 --> 00:15:36.620
ist eine Möglichkeit, die
Konnektivität von der Netzwerkseite aus.

00:15:36.620 --> 00:15:38.450
So typischerweise Ihre
Netzwerkadministrator tut

00:15:38.450 --> 00:15:41.540
dies und es macht nur
Verwaltung einfacher

00:15:41.540 --> 00:15:42.770
für sie, denn wenn du sagst,

00:15:42.770 --> 00:15:46.940
Sql. WestUS müssen Sie nicht
Whitelist individuelle IP-Adresse.

00:15:46.940 --> 00:15:49.610
So können Sie
verbinden Sie sich mit irgendetwas in

00:15:49.610 --> 00:15:53.180
SQL-Datenbank, die
in der Region WestUS.

00:15:53.180 --> 00:15:55.850
Jetzt geht das auch

00:15:55.850 --> 00:15:57.845
ein zusätzlicher Overhead
in dem Sinne, dass

00:15:57.845 --> 00:15:59.990
sobald Sie mit
die Netzwerkeinstellung,

00:15:59.990 --> 00:16:02.000
Sie müssen kommen
DIE SQL-Datenbankseite

00:16:02.000 --> 00:16:04.655
und erinnern Sie sich wieder an unsere
IP-Adressfirewall.

00:16:04.655 --> 00:16:06.845
Sie müssen also hier eine IP-Adresse hinzufügen.

00:16:06.845 --> 00:16:08.975
Dies ist also ein zweistufiger Prozess.

00:16:08.975 --> 00:16:12.230
Die Nachteile sind ein

00:16:12.230 --> 00:16:15.440
müssen Sie die IP-Adresse verwalten.

00:16:15.440 --> 00:16:19.520
So zum Beispiel, wenn Sie
die öffentliche IP-Adresse für

00:16:19.520 --> 00:16:22.280
die VM sofort
Diese Konnektivität wird

00:16:22.280 --> 00:16:25.400
unterbrochen, da SQL nicht
diese IP-Adresse zu erkennen.

00:16:25.400 --> 00:16:27.200
>> ja, weil nicht [unhörbar].

00:16:27.200 --> 00:16:30.740
>> Ja. Die andere Sache
darüber, dass

00:16:30.740 --> 00:16:33.140
einige Kunden mögen es vielleicht nicht,

00:16:33.140 --> 00:16:36.155
Ein Service-Tag ist immer noch
ziemlich weit offen.

00:16:36.155 --> 00:16:37.805
Es heißt, erlauben Sie mir, mich mit

00:16:37.805 --> 00:16:41.840
Jede SQL-Datenbank in
der Region WestUS.

00:16:41.840 --> 00:16:44.090
Aber natürlich gibt es Verbesserungen

00:16:44.090 --> 00:16:46.130
kommen auf der Netzwerkseite
die es Ihnen ermöglichen,

00:16:46.130 --> 00:16:48.575
Beschränken Sie dies auf eine bestimmte Ressource

00:16:48.575 --> 00:16:51.035
aber die sind in
Fortschritte im Moment.

00:16:51.035 --> 00:16:52.820
Aber das ist es, was wir haben.

00:16:52.820 --> 00:16:58.775
Also jetzt lassen Sie uns die Richtung umkehren
von dem wir hierher kommen.

00:16:58.775 --> 00:17:02.720
Sie haben gesehen, wie wir uns von
VM-Seite zu SQL DB.

00:17:02.720 --> 00:17:05.240
Die Vnet-Firewallregel ist
etwas, das Sie festlegen

00:17:05.240 --> 00:17:07.400
ein Abschlussball der SQL-Datenbankseite wie

00:17:07.400 --> 00:17:11.330
dies zu sagen, erlauben Sie mir, von

00:17:11.330 --> 00:17:17.135
Meine SQL-Datenbank zu
ein bestimmtes Subnetz.

00:17:17.135 --> 00:17:21.005
Die Schönheit also
ist, dass Sie nicht brauchen

00:17:21.005 --> 00:17:25.280
zur Whitelist für alle IP-Adressen
oder so etwas zu tun.

00:17:25.280 --> 00:17:28.460
Alles, was Sie sagen, ist
Öffnen eines Pfads zwischen

00:17:28.460 --> 00:17:29.960
Ihre SQL-Datenbank und

00:17:29.960 --> 00:17:33.620
ein bestimmtes Subnetz und Sie sind
mit der privaten IP-Adresse.

00:17:33.620 --> 00:17:36.485
Es gibt also sogar
zusätzlichen Nutzen, der

00:17:36.485 --> 00:17:42.455
alles geht durch
das Azure-Backbonenetzwerk klug.

00:17:42.455 --> 00:17:43.970
>> Das ist ziemlich cool.

00:17:43.970 --> 00:17:50.750
>> Ein weiterer Vorteil ist, dass
keine Whitelisting erforderlich und ja,

00:17:50.750 --> 00:17:52.625
das ist so ziemlich alles.

00:17:52.625 --> 00:17:56.420
>> Cool. Also vielen Dank dafür.

00:17:56.420 --> 00:17:58.160
Das ist eine wirklich gute Erklärung für

00:17:58.160 --> 00:18:01.220
die Konnektivität zu
Azure SQL-Datenbank.

00:18:01.220 --> 00:18:03.780
Paar weitere schnelle Fragen,

00:18:03.790 --> 00:18:06.680
ist es nur für Azure
SQL-Datenbank wie alle

00:18:06.680 --> 00:18:08.780
sie die verschiedenen
Bereitstellungsoptionen.

00:18:08.780 --> 00:18:11.855
Ich denke, wir haben eine einzige elastische
Ziel wurde Instanz verwaltet.

00:18:11.855 --> 00:18:12.290
>> Absolut.

00:18:12.290 --> 00:18:15.360
>> Ist es für alle dieser
die von Ihnen erläuterten Optionen beeinflusst?

00:18:15.360 --> 00:18:18.530
>> Wenn wir also über
Azure SQL-Datenbank heute,

00:18:18.530 --> 00:18:23.180
ob Sie sich eine einzelne
SQL-Datenbanken, Pools für elastische Datenbanken,

00:18:23.180 --> 00:18:26.779
Data Warehouse und
auch die Open-Source-Datenbanken,

00:18:26.779 --> 00:18:30.200
wir haben eine gemeinsame Kontrolle
Ebene, was bedeutet,

00:18:30.200 --> 00:18:34.640
sagen Sie das SQL-Gateway, das Sie
sah, dass Komponente üblich ist.

00:18:34.640 --> 00:18:37.820
Diese Konnektivität gilt also für

00:18:37.820 --> 00:18:39.410
alle unsere Angebote, die unter

00:18:39.410 --> 00:18:41.525
den Schirm der Azure SQL-Datenbank.

00:18:41.525 --> 00:18:44.690
>> Das ist fantastisch. Nun, danke

00:18:44.690 --> 00:18:47.600
sehr viel für alle für
einstimmen und uns

00:18:47.600 --> 00:18:50.210
a like, wenn Sie möchten
Diese Art von Inhalt

00:18:50.210 --> 00:18:53.300
und abonnieren Sie uns und wir werden
später. Danke.

00:18:53.300 --> 00:19:06.000
[MUSIK]

