WEBVTT

00:00:00.000 --> 00:00:02.070
>> SQL Server grande
cluster di dati forniscono

00:00:02.070 --> 00:00:03.960
meccanismi di sicurezza per assicurarsi

00:00:03.960 --> 00:00:06.150
l'accesso ai dati è sempre sicuro.

00:00:06.150 --> 00:00:08.220
Nellie è qui per raccontare
noi tutto di

00:00:08.220 --> 00:00:10.350
oggi su Data Exposed.

00:00:10.350 --> 00:00:21.210
[MUSICA]

00:00:21.210 --> 00:00:24.165
>> Ciao e benvenuto a un altro
episodio di Data Exposed.

00:00:24.165 --> 00:00:27.570
Sono Jeroen il tuo ospite e
abbiamo Nellie oggi con

00:00:27.570 --> 00:00:30.990
noi a parlare di sicurezza per grandi
cluster di dati. Salve, Nellie.

00:00:30.990 --> 00:00:31.860
>> Ciao, Jeroen.

00:00:31.860 --> 00:00:32.700
>> Come stai?

00:00:32.700 --> 00:00:33.750
>> Sto bene. grazie.

00:00:33.750 --> 00:00:36.930
>> Ok. Quindi la sicurezza
per i cluster di Big Data,

00:00:36.930 --> 00:00:38.340
che deve sembrare importante.

00:00:38.340 --> 00:00:41.355
Quindi può dirci come funziona?

00:00:41.355 --> 00:00:44.970
>> Certo. Quindi, se siete
familiarità con SQL Server,

00:00:44.970 --> 00:00:47.735
probabilmente sapete che
sicurezza è sempre

00:00:47.735 --> 00:00:49.820
una priorità assoluta per noi

00:00:49.820 --> 00:00:53.540
ed è la stessa cosa
con i cluster di Big Data.

00:00:53.540 --> 00:00:56.180
Diamo priorità a questo lavoro

00:00:56.180 --> 00:00:59.015
e notare quanto sia importante
è per i nostri clienti.

00:00:59.015 --> 00:01:04.340
Quindi ho intenzione di evidenziare alcuni
cose intorno alla sicurezza di oggi.

00:01:04.340 --> 00:01:06.485
Non stiamo andando a
coprire tutti i dettagli,

00:01:06.485 --> 00:01:10.430
ma stiamo fondamentalmente andando a coprire

00:01:10.430 --> 00:01:12.080
ad alto livello in modo da sapere

00:01:12.080 --> 00:01:15.170
le capacità di sicurezza
del cluster di Big Data.

00:01:15.170 --> 00:01:16.220
>> Ok.

00:01:16.220 --> 00:01:17.870
>> Come sapete, un sacco di

00:01:17.870 --> 00:01:20.440
i nostri clienti SQL Server
sono clienti aziendali,

00:01:20.440 --> 00:01:23.720
grandi imprese che
eseguire Active Directory.

00:01:23.720 --> 00:01:27.125
Dobbiamo assicurarci che tutti i
applicazioni, tra cui

00:01:27.125 --> 00:01:29.420
SQL Server e Big Data
cluster e tutti i

00:01:29.420 --> 00:01:32.525
queste soluzioni possono
integrare bene con AD.

00:01:32.525 --> 00:01:33.515
>> sì.

00:01:33.515 --> 00:01:36.680
>> Questa è la chiave
capacità che siamo

00:01:36.680 --> 00:01:40.355
l'abilitazione nei cluster di Big Data nel 2019

00:01:40.355 --> 00:01:44.060
è quello di effettivamente per
di essere in grado di fare

00:01:44.060 --> 00:01:47.945
questo in modo semplice e senza soluzione di continuità.

00:01:47.945 --> 00:01:51.425
Ora vi dirò perché
Ho sottolineato facile e

00:01:51.425 --> 00:01:56.150
senza soluzione di continuità perché in genere quando
avete a che fare con le applicazioni,

00:01:56.150 --> 00:01:58.070
diciamo che qualsiasi tipo di applicazione,

00:01:58.070 --> 00:02:01.220
aggiunta di un'applicazione ad Active Directory
non è un grosso problema, giusto?

00:02:01.220 --> 00:02:04.280
Si supponga che qualsiasi applicazione
supporta l'integrazione di AD.

00:02:04.280 --> 00:02:04.730
>> Certo.

00:02:04.730 --> 00:02:07.640
>> Ora per i cluster di Big Data,
è la stessa cosa.

00:02:07.640 --> 00:02:09.185
Dovrebbe funzionare.

00:02:09.185 --> 00:02:11.090
E 'solo che dobbiamo

00:02:11.090 --> 00:02:13.890
evidenziare che siamo
in esecuzione in una sorta di completamente

00:02:13.890 --> 00:02:18.255
completamente containerizzato
soluzione qui dove

00:02:18.255 --> 00:02:20.240
tutti i servizi sono in esecuzione in

00:02:20.240 --> 00:02:22.160
contenitori e tutti i
servizi di supporto

00:02:22.160 --> 00:02:23.470
sono in esecuzione in contenitori,

00:02:23.470 --> 00:02:25.370
e questo è in esecuzione
in cima a Kubernetes.

00:02:25.370 --> 00:02:25.955
>> Destra.

00:02:25.955 --> 00:02:30.200
>> Quindi abbiamo speso un sacco di lavoro
per fare in modo che si ottiene

00:02:30.200 --> 00:02:33.200
un sistema completamente automatizzato e
un'esperienza senza soluzione di continuità

00:02:33.200 --> 00:02:37.130
questo completamente containerizzato
soluzione di Big Data

00:02:37.130 --> 00:02:39.560
in cima a Kubernetes.

00:02:39.560 --> 00:02:41.600
>> Quindi, fondamentalmente, questo tutto
viene eseguito in contenitore in modo che sia

00:02:41.600 --> 00:02:43.820
perché l'integrazione è interessante.

00:02:43.820 --> 00:02:45.170
Quindi, cosa significa avere

00:02:45.170 --> 00:02:47.360
un sistema completamente automatizzato
integrazione f? Cosa ottengo?

00:02:47.360 --> 00:02:50.510
>> Sì. Quindi, per questo,

00:02:50.510 --> 00:02:52.415
potrebbe essere necessario un po'
po 'di sfondo.

00:02:52.415 --> 00:02:52.530
>> Ok.

00:02:52.530 --> 00:02:55.700
>> Così, quando si sta unendo
sorta di un servizio per

00:02:55.700 --> 00:02:58.099
Active Directory o Kerberos

00:02:58.099 --> 00:03:00.410
che è in esecuzione all'interno
un contenitore Linux,

00:03:00.410 --> 00:03:03.320
per esempio, è
assolutamente possibile.

00:03:03.320 --> 00:03:04.670
E 'solo che si deve applicare

00:03:04.670 --> 00:03:07.655
alcuni passaggi manuali per
farlo funzionare.

00:03:07.655 --> 00:03:10.430
Ora immaginate di avere un
soluzione con centinaia

00:03:10.430 --> 00:03:14.255
di questi contenitori con centinaia
dei servizi in esecuzione in là.

00:03:14.255 --> 00:03:16.580
Per eseguire questa operazione manualmente
ovviamente non sarebbe

00:03:16.580 --> 00:03:19.730
realistico e non vogliamo
per chiederlo ai nostri utenti.

00:03:19.730 --> 00:03:22.130
Quindi, completamente automatizzato,

00:03:22.130 --> 00:03:23.795
In pratica voglio dire che siamo

00:03:23.795 --> 00:03:25.970
prendersi cura del
complessità per voi.

00:03:25.970 --> 00:03:29.105
Abbiamo un servizio che si chiama
servizio di supporto alla sicurezza.

00:03:29.105 --> 00:03:30.695
Quindi, come parte della distribuzione,

00:03:30.695 --> 00:03:32.090
che il servizio sta per prendere

00:03:32.090 --> 00:03:34.430
alcune informazioni da voi
come utente che sta distribuendo

00:03:34.430 --> 00:03:39.005
il cluster e quindi il servizio
sta per eseguire fondamentalmente

00:03:39.005 --> 00:03:41.480
tutti questi passaggi per ogni
singolo servizio nel cluster

00:03:41.480 --> 00:03:44.045
per assicurarsi che
tutto è ad AD unito.

00:03:44.045 --> 00:03:46.850
>> Wow, che è impressionante.
È molto figo.

00:03:46.850 --> 00:03:48.890
Quindi, in pratica, posso semplicemente lasciare

00:03:48.890 --> 00:03:51.410
il cluster lo configura
ed eccoci qua, giusto?

00:03:51.410 --> 00:03:52.475
>> Sì, esattamente.

00:03:52.475 --> 00:03:53.005
>> Cool.

00:03:53.005 --> 00:03:55.145
>> Ora in aggiunta a questo,

00:03:55.145 --> 00:03:58.370
abbiamo anche spendere un sacco di tempo per

00:03:58.370 --> 00:04:01.100
fare in modo che otteniamo un
un'esperienza di sicurezza integrata.

00:04:01.100 --> 00:04:04.730
Con questo, voglio dire che, per esempio,

00:04:04.730 --> 00:04:07.864
quando si sta passando un
una query da Spark a HDFS,

00:04:07.864 --> 00:04:10.060
perché nei big data
cluster abbiamo Spark,

00:04:10.060 --> 00:04:12.090
è possibile eseguire query sui dati in HDFS.

00:04:12.090 --> 00:04:15.920
Questi componenti già
giocare abbastanza bene insieme.

00:04:15.920 --> 00:04:19.700
Quindi questi componenti sono
parte dello stesso stack,

00:04:19.700 --> 00:04:22.440
si può dire, parte di
la pila Apache.

00:04:23.620 --> 00:04:27.260
Quindi c'è un sacco di funzionalità
possiamo già fare leva lì.

00:04:27.260 --> 00:04:29.780
Ma quando si tratta di SQL
Server e SQL Server

00:04:29.780 --> 00:04:32.965
nativamente parlando con un
componente come HDFS,

00:04:32.965 --> 00:04:35.480
che è in realtà una nuova funzionalità

00:04:35.480 --> 00:04:37.250
che stiamo introducendo dove

00:04:37.250 --> 00:04:41.280
hanno la capacità per SQL
Scenari di query server,

00:04:41.280 --> 00:04:43.110
Devo sottolineare, che se io

00:04:43.110 --> 00:04:45.495
passare una query al codice SQL
Istanza master server,

00:04:45.495 --> 00:04:47.540
è solo una query SQL
che esegue query

00:04:47.540 --> 00:04:49.970
su una tabella esterna
seduto in HDFS, giusto?

00:04:49.970 --> 00:04:52.295
Quindi quando lo faccio,

00:04:52.295 --> 00:04:57.020
ci assicuriamo che il mio
identità come una persona che è

00:04:57.020 --> 00:05:01.070
l'emissione di questa query scorre fino in fondo

00:05:01.070 --> 00:05:03.410
attraverso tutti questi
diversi componenti

00:05:03.410 --> 00:05:05.600
sulla strada verso il basso per
HDFS in cui i dati

00:05:05.600 --> 00:05:10.400
è in modo che possiamo fare un'autorizzazione
controllare i dati effettivi,

00:05:10.400 --> 00:05:12.590
ed è quello che voglio dire
con sicurezza integrata.

00:05:12.590 --> 00:05:14.615
È integrato attraverso
tutti questi componenti.

00:05:14.615 --> 00:05:16.760
Quindi, non importa dove emetto la query,

00:05:16.760 --> 00:05:18.515
da Spark o SQL Server,

00:05:18.515 --> 00:05:20.450
l'identità dell'utente è sempre in corso

00:05:20.450 --> 00:05:22.895
di fluire attraverso tutti
la strada per la fonte.

00:05:22.895 --> 00:05:25.640
>> Ok. Questo è molto impressionante
e molto importante per

00:05:25.640 --> 00:05:27.560
qualsiasi impresa che lavora con questo tipo

00:05:27.560 --> 00:05:29.570
di roba perché si vuole
sa che i tuoi dati sono al sicuro.

00:05:29.570 --> 00:05:31.430
>> Esattamente. Voglio dire
si dispone di controllo,

00:05:31.430 --> 00:05:33.860
si dispone dei registri di controllo per rendere
assicurarsi che siano aggiornati,

00:05:33.860 --> 00:05:36.425
e non si vuole un po 'di servizio
conto per apparire in quelli.

00:05:36.425 --> 00:05:37.190
>> Esattamente.

00:05:37.190 --> 00:05:40.940
>> Quindi è uno dei requisiti chiave
anche dai nostri clienti.

00:05:40.940 --> 00:05:42.860
In aggiunta a questo,

00:05:42.860 --> 00:05:49.340
abbiamo anche l'integrato
esperienza in forme di come si,

00:05:49.340 --> 00:05:51.305
ad esempio, interagire
con il cluster.

00:05:51.305 --> 00:05:53.150
Abbiamo Azure Data
Studio che si può

00:05:53.150 --> 00:05:56.370
utilizzare per connettersi a grandi
cluster di dati, giusto?

00:05:56.540 --> 00:05:59.480
Vogliamo dare il
esperienza di un singolo

00:05:59.480 --> 00:06:03.110
sign-on per il maggior numero di
scenari possibili.

00:06:03.110 --> 00:06:05.295
Così, quando mi collego a
un cluster di Big Data,

00:06:05.295 --> 00:06:07.345
In realtà mi connetto a
l'istanza master,

00:06:07.345 --> 00:06:11.030
ma i nostri strumenti faranno in modo
che ho anche accesso a Spark,

00:06:11.030 --> 00:06:12.590
in HDFS, e tutti questi altri

00:06:12.590 --> 00:06:15.010
componenti interessanti
nel cluster di Big Data.

00:06:15.010 --> 00:06:16.895
>> Quindi questo è tutto gestito
in modo trasparente per me?

00:06:16.895 --> 00:06:18.185
>> Sì, esattamente.

00:06:18.185 --> 00:06:19.250
>> Ok. Bello.

00:06:19.250 --> 00:06:22.375
>> Sì. Ultimo ma non meno importante

00:06:22.375 --> 00:06:24.650
abbiamo la crittografia e

00:06:24.650 --> 00:06:27.125
crittografia è molto importante
per i nostri utenti, giusto?

00:06:27.125 --> 00:06:27.890
>> Naturalmente.

00:06:27.890 --> 00:06:30.965
>> Abbiamo fatto in modo che
tutta la comunicazione,

00:06:30.965 --> 00:06:33.950
anche interno e
comunicazione esterna,

00:06:33.950 --> 00:06:39.290
con il cluster di Big Data
è crittografato con SSL o TLS.

00:06:39.290 --> 00:06:41.285
In aggiunta a ciò,

00:06:41.285 --> 00:06:43.325
si può, naturalmente, leva

00:06:43.325 --> 00:06:45.635
i molti diversi
funzionalità di crittografia di

00:06:45.635 --> 00:06:48.470
SQL Server che abbiamo
e tutti loro che sono

00:06:48.470 --> 00:06:49.985
supportato su SQL Server su Linux

00:06:49.985 --> 00:06:52.430
perché stiamo correndo su
Contenitori Linux qui.

00:06:52.430 --> 00:06:57.485
Stiamo anche lavorando per espandere
queste funzionalità e aggiungere

00:06:57.485 --> 00:07:00.710
Crittografia HDFS presto
in modo che abbiamo anche

00:07:00.710 --> 00:07:04.745
tali funzionalità per i dati
che è criptato a rischio.

00:07:04.745 --> 00:07:07.920
>> Ok. Bello. Così si può

00:07:07.920 --> 00:07:09.410
spiegarci un po'
po 'di più su come

00:07:09.410 --> 00:07:11.570
questo funziona sotto Kerberos?

00:07:11.570 --> 00:07:16.070
>> Assolutamente. Quindi cerchiamo di
concentrarsi sull'autenticazione

00:07:16.070 --> 00:07:18.770
prima perché è
importante per voi di

00:07:18.770 --> 00:07:20.485
sapere che differenza o

00:07:20.485 --> 00:07:22.785
punti di ingresso ci sono
al cluster, giusto?

00:07:22.785 --> 00:07:26.360
Qui vedete i cinque
endpoint diversi

00:07:26.360 --> 00:07:28.490
o punti di ingresso al cluster.

00:07:28.490 --> 00:07:30.485
Ora abbiamo questo cluster Kubernetes,

00:07:30.485 --> 00:07:32.660
quindi dobbiamo fondamentalmente specificamente

00:07:32.660 --> 00:07:35.360
esporre determinati endpoint che gli utenti

00:07:35.360 --> 00:07:37.430
o strumenti client o
qualsiasi applicazione può

00:07:37.430 --> 00:07:40.865
interagire con il cluster.

00:07:40.865 --> 00:07:44.475
Quindi, se iniziamo con il controller,

00:07:44.475 --> 00:07:46.685
come potresti avere familiarità con,

00:07:46.685 --> 00:07:48.860
controller è il
cervello del cluster.

00:07:48.860 --> 00:07:52.715
Controller è quello che
tiene traccia di tutto,

00:07:52.715 --> 00:07:54.229
che distribuisce il cluster,

00:07:54.229 --> 00:07:55.775
e tutte queste cose.

00:07:55.775 --> 00:07:58.580
Ora per raggiungere il
endpoint del controller,

00:07:58.580 --> 00:08:02.500
si può vedere qui che il principale
metodo di interazione

00:08:02.500 --> 00:08:04.885
con esso sarebbe
attraverso l'interfaccia della riga di comando azdata

00:08:04.885 --> 00:08:06.850
ma anche attraverso i nostri strumenti.

00:08:06.850 --> 00:08:11.860
E 'principalmente l'endpoint che
un amministratore userebbe,

00:08:11.860 --> 00:08:14.005
ad esempio, per interagire
con il cluster.

00:08:14.005 --> 00:08:16.180
Ma il controller ha anche poteri magici.

00:08:16.180 --> 00:08:20.470
Si può dire controller può ordinare
di raggiungere altri endpoint.

00:08:20.470 --> 00:08:23.890
Così, per esempio, è possibile accedere a

00:08:23.890 --> 00:08:27.485
controller tramite azdata e da

00:08:27.485 --> 00:08:29.920
ci emettere comandi che

00:08:29.920 --> 00:08:32.710
passare al master di SQL ServerSQL Server master
istanza e basta iniziare a correre

00:08:32.710 --> 00:08:35.380
T-SQL o è possibile eseguire comandi HDFS

00:08:35.380 --> 00:08:38.665
direttamente in una shell HDFS
in questo tipo di cose.

00:08:38.665 --> 00:08:42.470
Ecco, questo è ciò che l'endpoint permette
di fare tra le altre cose.

00:08:42.470 --> 00:08:43.275
>> Ok. Molto figo.

00:08:43.275 --> 00:08:45.830
>> sì. Successivamente, un endpoint

00:08:45.830 --> 00:08:47.690
potrebbe aver sentito parlare se hai

00:08:47.690 --> 00:08:49.860
cluster di Big Data utilizzati
è il gateway.

00:08:49.860 --> 00:08:52.055
Ora, il gateway è
in realtà la stessa cosa.

00:08:52.055 --> 00:08:53.885
Il dettaglio di attuazione alla base di questo

00:08:53.885 --> 00:08:56.735
è che è il gateway Apache Knox.

00:08:56.735 --> 00:08:59.900
Si tratta di un gateway che in genere
protegge, si può dire,

00:08:59.900 --> 00:09:06.210
i componenti Apache come
fondamentalmente sul lato Hadoop.

00:09:06.210 --> 00:09:06.510
>> Destra.

00:09:06.510 --> 00:09:07.980
>> Quindi abbiamo Spark, Livy,

00:09:07.980 --> 00:09:11.999
YARN se si desidera collegare
HDFS tramite web HDFS,

00:09:11.999 --> 00:09:13.705
questo è l'endpoint che si utilizza,

00:09:13.705 --> 00:09:17.165
nonché da Azure Data Studio.

00:09:17.165 --> 00:09:19.160
Ecco, questo è bene sapere quando

00:09:19.160 --> 00:09:21.505
stiamo parlando del
gateway quello che intendiamo lì.

00:09:21.505 --> 00:09:23.990
Poi abbiamo il
proxy di gestione che

00:09:23.990 --> 00:09:28.070
è il gateway per le metriche
e strumenti di registrazione,

00:09:28.070 --> 00:09:31.490
e poi abbiamo ovviamente
Istanza master di SQL Server.

00:09:31.490 --> 00:09:33.830
È solo SQL. E 'solo
un endpoint TDS in cui

00:09:33.830 --> 00:09:37.025
connettersi a da qualsiasi strumento
che hai familiarità con.

00:09:37.025 --> 00:09:39.200
Il proxy dell'app, ultimo
ma non meno importante,

00:09:39.200 --> 00:09:41.780
che è il modo in cui si può

00:09:41.780 --> 00:09:43.310
accedere alle applicazioni che

00:09:43.310 --> 00:09:45.290
è stato distribuito all'interno
cluster di Big Data.

00:09:45.290 --> 00:09:47.820
Ora, tutti questi diversi
endpoint durante l'esecuzione,

00:09:47.820 --> 00:09:49.305
ad esempio, in modalità sicura,

00:09:49.305 --> 00:09:50.760
quando il cluster è
in esecuzione in modalità sicura,

00:09:50.760 --> 00:09:53.175
Intendo la modalità di integrazione AD,

00:09:53.175 --> 00:09:58.210
tutti questi endpoint sono
consentendo l'autenticazione AD.

00:09:58.210 --> 00:10:00.200
Quindi questo è quello che volevo
da evidenziare qui.

00:10:00.200 --> 00:10:02.510
Quindi, quando stiamo parlando
sull'autenticazione AD,

00:10:02.510 --> 00:10:06.740
si tratta di una completa integrazione con
ACTIVE Directory per tutti gli endpoint.

00:10:06.740 --> 00:10:08.645
>> Destra. Davanti a uno dei
cinque endpoint su tutta la linea.

00:10:08.645 --> 00:10:09.335
>> Esattamente.

00:10:09.335 --> 00:10:11.490
>> Wow. ok.

00:10:12.740 --> 00:10:16.590
>> sì. Quindi questa è l'autenticazione
fondamentalmente per voi.

00:10:16.590 --> 00:10:19.755
Andando avanti, abbiamo anche
avere l'autorizzazione.

00:10:19.755 --> 00:10:21.290
È molto importante proteggere

00:10:21.290 --> 00:10:23.780
i tuoi dati una volta che è
all'interno del cluster,

00:10:23.780 --> 00:10:26.720
una volta che si riesce effettivamente a
accedere e autenticarsi.

00:10:26.720 --> 00:10:30.675
sì. Così le parti chiave che ho
ha voluto evidenziare qui,

00:10:30.675 --> 00:10:31.920
e questo è ancora di alto livello.

00:10:31.920 --> 00:10:33.485
Sono sicuro che stiamo andando ad avere

00:10:33.485 --> 00:10:35.660
ulteriori discorsi sul
dettagli di queste cose.

00:10:35.660 --> 00:10:37.335
Ma ad alto livello,

00:10:37.335 --> 00:10:38.510
ci sono due livelli di

00:10:38.510 --> 00:10:42.050
controlli di autorizzazione che si
nei cluster di Big Data.

00:10:42.050 --> 00:10:44.750
Se iniziamo con SQL
Server, ad esempio,

00:10:44.750 --> 00:10:48.050
se sto emettendo una query di SQL Server,

00:10:48.050 --> 00:10:50.420
prima di tutto, ci sono
controlli di autorizzazione

00:10:50.420 --> 00:10:52.100
sugli oggetti di SQL Server.

00:10:52.100 --> 00:10:54.920
Ho bisogno di avere accesso al
tabelle su cui si desidera eseguire una query,

00:10:54.920 --> 00:10:58.730
per esempio, in modo che possiamo fare
assicurarsi di poter accedere ai dati.

00:10:58.730 --> 00:11:00.860
>> Ma questo è lo stesso
controlli di autorizzazione

00:11:00.860 --> 00:11:02.330
come avevamo in precedenza
rilasci con SQL?

00:11:02.330 --> 00:11:02.780
>> Sì, è SQL.

00:11:02.780 --> 00:11:03.530
>> Che non è cambiato?

00:11:03.530 --> 00:11:04.280
>> Questo è solo SQL.

00:11:04.280 --> 00:11:04.610
>> Ok.

00:11:04.610 --> 00:11:07.160
>> Quindi, fondamentalmente, il
modello di autorizzazione di

00:11:07.160 --> 00:11:08.945
SQL Server è lo stesso

00:11:08.945 --> 00:11:11.285
se è in esecuzione in grande
cluster di dati o in qualsiasi altro luogo.

00:11:11.285 --> 00:11:13.490
Così si può ancora concedere le autorizzazioni su

00:11:13.490 --> 00:11:16.950
tabelle specifiche e specifiche
oggetti in SQL Server, giusto?

00:11:16.950 --> 00:11:17.915
>> Ok.

00:11:17.915 --> 00:11:19.945
>> Ma in aggiunta a questo,

00:11:19.945 --> 00:11:21.845
ora prendiamo lo scenario quando sono

00:11:21.845 --> 00:11:23.990
emissione di una query sui dati che è

00:11:23.990 --> 00:11:26.060
seduto in HDFS e sto interrogando

00:11:26.060 --> 00:11:28.715
una tabella esterna su
HDFS in questo caso.

00:11:28.715 --> 00:11:31.790
Non solo ho bisogno di avere
l'accesso a questa tabella,

00:11:31.790 --> 00:11:34.025
al database in cui
questo tavolo si siede,

00:11:34.025 --> 00:11:36.320
Ho anche bisogno di avere accesso a

00:11:36.320 --> 00:11:39.905
i file e i dati effettivi
che è seduto in HDFS.

00:11:39.905 --> 00:11:40.145
>> Certo.

00:11:40.145 --> 00:11:43.430
>> Questo è quello che volevo dire con il
controlli di autorizzazione a due livelli.

00:11:43.430 --> 00:11:45.035
Quindi, in questo caso, c'è un check-in

00:11:45.035 --> 00:11:48.620
SQL Server e c'è un
controllo aggiuntivo in HDFS.

00:11:48.620 --> 00:11:48.920
>> Ok.

00:11:48.920 --> 00:11:50.510
>> Sul lato Spark,

00:11:50.510 --> 00:11:53.660
fondamentalmente la Scintilla
le query fluiranno e

00:11:53.660 --> 00:11:56.000
il controllo dell'autorizzazione HDFS

00:11:56.000 --> 00:11:58.505
assicurarsi che il
le autorizzazioni vengono rispettate.

00:11:58.505 --> 00:12:00.200
>> Ok. Quindi, con tutto questo,

00:12:00.200 --> 00:12:01.820
Posso essere sicuro che

00:12:01.820 --> 00:12:04.370
l'utente originale
identità passa attraverso

00:12:04.370 --> 00:12:06.590
SQL Server in cui si trova
i dati sono, giusto?

00:12:06.590 --> 00:12:09.455
HDFS o comunque io vi accedo, giusto?

00:12:09.455 --> 00:12:15.390
>> Esattamente. sì. Poi, come noi
una sorta di toccato prima,

00:12:15.390 --> 00:12:18.825
avremo questa identità pass-through

00:12:18.825 --> 00:12:22.670
il che significa che l'originale
l'identità dell'utente scorrerà

00:12:22.670 --> 00:12:26.810
tutta la strada fino al
dati in modo che possiamo effettivamente

00:12:26.810 --> 00:12:27.980
verificare tutto il modo

00:12:27.980 --> 00:12:31.730
che questo era l'utente che
desiderava accedere ai dati.

00:12:31.730 --> 00:12:32.800
>> Ok.

00:12:32.800 --> 00:12:38.820
>> sì. In modo che
fondamentalmente è un riassunto su

00:12:38.820 --> 00:12:41.390
alto livello sulla sicurezza
capacità intorno

00:12:41.390 --> 00:12:44.780
le integrazioni AD in modo specifico
per i cluster di Big Data.

00:12:44.780 --> 00:12:47.710
>> Quindi dove posso scoprire
di più se voglio immergermi più a fondo?

00:12:47.710 --> 00:12:50.420
>> sì. Quindi, se

00:12:50.420 --> 00:12:52.580
vuoi saperne di più su
cluster di Big Data in generale

00:12:52.580 --> 00:12:56.495
e abbiamo documenti di sicurezza

00:12:56.495 --> 00:12:59.675
che copre i dettagli di ciò che
Ho appena spiegato oggi,

00:12:59.675 --> 00:13:04.280
si dovrebbe andare a questo
collegamento breve: aka.ms/sqlbdc.

00:13:04.280 --> 00:13:05.615
>> Ok.

00:13:05.615 --> 00:13:09.455
>> Se si va lì, si può imparare
tonnellate di cluster di Big Data.

00:13:09.455 --> 00:13:10.835
>> Tutto ciò che c'è da imparare, giusto?

00:13:10.835 --> 00:13:11.255
>> sì.

00:13:11.255 --> 00:13:12.560
>> Fantastico. Quindi va bene.

00:13:12.560 --> 00:13:14.210
Quindi, in pratica, ho bisogno di andare lì

00:13:14.210 --> 00:13:16.750
e iniziare ad imparare e
avviare il download.

00:13:16.750 --> 00:13:18.810
Posso esportarlo in un grande PDF e

00:13:18.810 --> 00:13:21.990
poi leggerlo nel
notte per imparare?

00:13:21.990 --> 00:13:25.095
>> sì. In realtà, penso
si può fare. sì.

00:13:25.095 --> 00:13:27.120
>> Non stamparlo,
anche se. Solo PDF, giusto?

00:13:27.120 --> 00:13:27.300
>> Sì.

00:13:27.300 --> 00:13:29.390
>> Ok. Bello. Quindi grazie mille.

00:13:29.390 --> 00:13:31.295
Questo è stato molto utile.
Grazie mille per la condivisione.

00:13:31.295 --> 00:13:32.030
>> Grazie.

00:13:32.030 --> 00:13:33.950
>> Grazie per la visione.

00:13:33.950 --> 00:13:35.960
Per favore, come, iscriviti,
e commentare

00:13:35.960 --> 00:13:37.940
il video e spero di
Alla prossima. grazie.

00:13:37.940 --> 00:13:52.600
[MUSICA]