WEBVTT

00:00:00.000 --> 00:00:02.070
>> Servidor SQL grande
os clusters de dados fornecem

00:00:02.070 --> 00:00:03.960
mecanismos de segurança para garantir

00:00:03.960 --> 00:00:06.150
seu acesso a dados é sempre seguro.

00:00:06.150 --> 00:00:08.220
Nellie está aqui para contar
nós tudo sobre

00:00:08.220 --> 00:00:10.350
hoje em Dados Expostos.

00:00:10.350 --> 00:00:21.210
[MÚSICA]

00:00:21.210 --> 00:00:24.165
>> Oi e bem-vindo a outro
episódio de Dados Expostos.

00:00:24.165 --> 00:00:27.570
Eu sou Jeroen seu anfitrião e
temos Nellie hoje com

00:00:27.570 --> 00:00:30.990
nós para falar sobre segurança para grande
clusters de dados. Então, oi, Nellie.

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

00:00:31.860 --> 00:00:32.700
>> Como você está?

00:00:32.700 --> 00:00:33.750
>> Estou bem. Thansk.

00:00:33.750 --> 00:00:36.930
>> Ok. Então, segurança
para clusters de big data,

00:00:36.930 --> 00:00:38.340
que deve soar importante.

00:00:38.340 --> 00:00:41.355
Então, você pode nos dizer como funciona?

00:00:41.355 --> 00:00:44.970
>> Claro. Então, se você é
familiarizado com o servidor SQL,

00:00:44.970 --> 00:00:47.735
você provavelmente sabe disso
segurança é sempre

00:00:47.735 --> 00:00:49.820
uma prioridade para nós

00:00:49.820 --> 00:00:53.540
e é a mesma coisa
com clusters de big data.

00:00:53.540 --> 00:00:56.180
Priorizamos este trabalho

00:00:56.180 --> 00:00:59.015
e note o quão importante
é para os nossos clientes.

00:00:59.015 --> 00:01:04.340
Então eu vou destacar alguns
coisas em torno da segurança hoje.

00:01:04.340 --> 00:01:06.485
Nós não vamos.
cobrir todos os detalhes,

00:01:06.485 --> 00:01:10.430
mas basicamente vamos cobrir

00:01:10.430 --> 00:01:12.080
em alto nível para que você saiba

00:01:12.080 --> 00:01:15.170
as capacidades de segurança
do cluster de big data.

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

00:01:16.220 --> 00:01:17.870
>> Como você sabe, um monte de

00:01:17.870 --> 00:01:20.440
nossos clientes do Servidor SQL
são clientes corporativos,

00:01:20.440 --> 00:01:23.720
grandes empresas que
dirigir diretório ativo.

00:01:23.720 --> 00:01:27.125
Precisamos ter certeza de que todos
suas aplicações, incluindo

00:01:27.125 --> 00:01:29.420
Servidor SQL e big data
clusters e todos os

00:01:29.420 --> 00:01:32.525
estas soluções podem
integrar bem com a AD.

00:01:32.525 --> 00:01:33.515
>> Sim.

00:01:33.515 --> 00:01:36.680
>> Essa é a chave
capacidade de que estamos

00:01:36.680 --> 00:01:40.355
habilitação em clusters de big data em 2019

00:01:40.355 --> 00:01:44.060
é realmente para
você para ser capaz de fazer

00:01:44.060 --> 00:01:47.945
isso de uma forma perfeita e fácil.

00:01:47.945 --> 00:01:51.425
Agora eu vou te dizer por quê
Eu enfatizei fácil e

00:01:51.425 --> 00:01:56.150
sem costura, porque normalmente quando
você está lidando com aplicativos,

00:01:56.150 --> 00:01:58.070
digamos qualquer tipo de aplicativo,

00:01:58.070 --> 00:02:01.220
adesão a um pedido de daa
não é nada demais, certo?

00:02:01.220 --> 00:02:04.280
Nós apenas assumimos que qualquer aplicativo
apoia a integração da AD.

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

00:02:04.730 --> 00:02:07.640
>> Agora para clusters de big data,
É a mesma coisa.

00:02:07.640 --> 00:02:09.185
Deve funcionar.

00:02:09.185 --> 00:02:11.090
É que temos que fazer isso.

00:02:11.090 --> 00:02:13.890
destacar que estamos
executando em uma espécie de totalmente de

00:02:13.890 --> 00:02:18.255
completamente emcontêinerida
solução aqui onde

00:02:18.255 --> 00:02:20.240
todos os serviços estão em execução em

00:02:20.240 --> 00:02:22.160
recipientes e todos os
serviços de apoio

00:02:22.160 --> 00:02:23.470
estão funcionando em contêineres,

00:02:23.470 --> 00:02:25.370
e isso está sendo executado
em cima de Kubernetes.

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

00:02:25.955 --> 00:02:30.200
>> Então, nós gastamos muito trabalho
para ter certeza de que você começa

00:02:30.200 --> 00:02:33.200
um totalmente automatizado e
experiência perfeita de

00:02:33.200 --> 00:02:37.130
isso é completamente emcontêinerdo
solução de big data

00:02:37.130 --> 00:02:39.560
em cima de Kubernetes.

00:02:39.560 --> 00:02:41.600
>> Então, basicamente, tudo isso
corre em recipiente de modo que é

00:02:41.600 --> 00:02:43.820
por que a integração é interessante.

00:02:43.820 --> 00:02:45.170
Então, o que significa ter

00:02:45.170 --> 00:02:47.360
um totalmente automatizado
Integração? O que é que eu recebo?

00:02:47.360 --> 00:02:50.510
>> Sim. Então, para isso,

00:02:50.510 --> 00:02:52.415
você pode precisar de um pouco
pouco de fundo.

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

00:02:52.530 --> 00:02:55.700
>> Então, quando você está se juntando
uma espécie de serviço para

00:02:55.700 --> 00:02:58.099
Diretório ativo ou Kerberos

00:02:58.099 --> 00:03:00.410
que está correndo para dentro
um recipiente Linux,

00:03:00.410 --> 00:03:03.320
por exemplo,
absolutamente possível.

00:03:03.320 --> 00:03:04.670
É que você tem que aplicar

00:03:04.670 --> 00:03:07.655
algumas etapas manuais para
conseguir que isso funcione.

00:03:07.655 --> 00:03:10.430
Agora imagine que você tem um
solução com centenas

00:03:10.430 --> 00:03:14.255
destes contentores com centenas
de serviços que funcionam lá.

00:03:14.255 --> 00:03:16.580
Para fazer isso manualmente
obviamente não seria

00:03:16.580 --> 00:03:19.730
realista e não queremos
para pedir isso aos nossos usuários.

00:03:19.730 --> 00:03:22.130
Assim, por totalmente automatizado,

00:03:22.130 --> 00:03:23.795
Eu basicamente quero dizer que estamos

00:03:23.795 --> 00:03:25.970
cuidar do
complexidade para você.

00:03:25.970 --> 00:03:29.105
Temos um serviço que se chama
o serviço de apoio à segurança.

00:03:29.105 --> 00:03:30.695
Então, como parte da implantação,

00:03:30.695 --> 00:03:32.090
que o serviço vai levar

00:03:32.090 --> 00:03:34.430
algumas informações de você
como um usuário que está implantando

00:03:34.430 --> 00:03:39.005
o cluster e, em seguida, o serviço
é basicamente executar

00:03:39.005 --> 00:03:41.480
todas estas etapas para cada
serviço único no cluster

00:03:41.480 --> 00:03:44.045
para se certificar de que
tudo é aD juntou-se.

00:03:44.045 --> 00:03:46.850
>> Uau, isso é impressionante.
Isso é muito legal.

00:03:46.850 --> 00:03:48.890
Então, basicamente, eu posso deixar

00:03:48.890 --> 00:03:51.410
o cluster configurá-lo
e lá vamos nós, certo?

00:03:51.410 --> 00:03:52.475
>> Sim, exatamente.

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

00:03:53.005 --> 00:03:55.145
>> Agora, além disso,

00:03:55.145 --> 00:03:58.370
também gastamos muito tempo para

00:03:58.370 --> 00:04:01.100
certifique-se de que temos um
experiência de segurança integrada.

00:04:01.100 --> 00:04:04.730
Com isso, quero dizer que, por exemplo,

00:04:04.730 --> 00:04:07.864
quando você está passando um
consulta do Spark ao HDFS,

00:04:07.864 --> 00:04:10.060
porque no big data
cluster temos Spark,

00:04:10.060 --> 00:04:12.090
você pode consultar dados no HDFS.

00:04:12.090 --> 00:04:15.920
Esses componentes já
jogar muito bem juntos.

00:04:15.920 --> 00:04:19.700
Então, esses componentes são
parte da mesma pilha,

00:04:19.700 --> 00:04:22.440
você pode dizer, parte de
a pilha Apache.

00:04:23.620 --> 00:04:27.260
Portanto, há muita funcionalidade
já podemos alavancar lá.

00:04:27.260 --> 00:04:29.780
Mas quando se trata de SQL
Servidor e servidor SQL

00:04:29.780 --> 00:04:32.965
nativamente falando com um
componente como hdfs,

00:04:32.965 --> 00:04:35.480
isso é realmente uma nova funcionalidade

00:04:35.480 --> 00:04:37.250
que estamos apresentando onde estamos

00:04:37.250 --> 00:04:41.280
tem a capacidade para sql
Cenários de consulta do servidor,

00:04:41.280 --> 00:04:43.110
Eu tenho que destacar, que se eu

00:04:43.110 --> 00:04:45.495
passar uma consulta para o SQL
Instância mestre do servidor,

00:04:45.495 --> 00:04:47.540
é apenas uma consulta sql
que está consultando

00:04:47.540 --> 00:04:49.970
sobre uma tabela externa
sentado no HDFS, certo?

00:04:49.970 --> 00:04:52.295
Então, quando eu faço isso,

00:04:52.295 --> 00:04:57.020
temos certeza de que o meu
identidade como uma pessoa que é

00:04:57.020 --> 00:05:01.070
emissão desta consulta flui todo o caminho

00:05:01.070 --> 00:05:03.410
através de todos estes
diferentes componentes

00:05:03.410 --> 00:05:05.600
no caminho para baixo para
HDFS onde os dados

00:05:05.600 --> 00:05:10.400
é para que possamos fazer uma autorização
verificar os dados reais,

00:05:10.400 --> 00:05:12.590
e é isso que quero dizer.
com segurança integrada.

00:05:12.590 --> 00:05:14.615
É integrado através
todos esses componentes.

00:05:14.615 --> 00:05:16.760
Então, não importa onde eu emitir a consulta,

00:05:16.760 --> 00:05:18.515
de Spark ou SQL Server,

00:05:18.515 --> 00:05:20.450
a identidade do usuário está sempre indo

00:05:20.450 --> 00:05:22.895
para fluir através de tudo
o caminho para a fonte.

00:05:22.895 --> 00:05:25.640
>> Ok. Isso é muito impressionante.
e muito importante para

00:05:25.640 --> 00:05:27.560
qualquer empresa que trabalha com este tipo

00:05:27.560 --> 00:05:29.570
de coisas, porque você quer
saiba que seus dados estão seguros.

00:05:29.570 --> 00:05:31.430
>> Exatamente. Eu quero dizer
você tem auditoria,

00:05:31.430 --> 00:05:33.860
você tem seus registros de auditoria para fazer
claro que estão atualizados,

00:05:33.860 --> 00:05:36.425
e você não quer algum serviço
conta para aparecer nesses.

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

00:05:37.190 --> 00:05:40.940
>> Então é um dos principais requisitos
de nossos clientes também.

00:05:40.940 --> 00:05:42.860
Além disso,

00:05:42.860 --> 00:05:49.340
temos também o integrado
experiência em formas de como você,

00:05:49.340 --> 00:05:51.305
por exemplo, interaja
com o cluster.

00:05:51.305 --> 00:05:53.150
Temos dados do Azure
Estúdio que você pode

00:05:53.150 --> 00:05:56.370
usar para se conectar a grande
Cluster de dados, certo?

00:05:56.540 --> 00:05:59.480
Queremos dar o
experiência de um único

00:05:59.480 --> 00:06:03.110
logon para tantos
cenários possível.

00:06:03.110 --> 00:06:05.295
Então, quando eu me conecto a
um cluster de big data,

00:06:05.295 --> 00:06:07.345
Eu realmente me conecto a
a instância mestre,

00:06:07.345 --> 00:06:11.030
mas nossas ferramentas vão ter certeza
que eu também tenho acesso ao Spark,

00:06:11.030 --> 00:06:12.590
em HDFS, e todos estes outros

00:06:12.590 --> 00:06:15.010
componentes que são interessantes
no cluster de big data.

00:06:15.010 --> 00:06:16.895
>> Então tudo isso é tratado
transparente para mim?

00:06:16.895 --> 00:06:18.185
>> Sim, exatamente.

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

00:06:19.250 --> 00:06:22.375
>> Sim. Por último, mas não menos importante

00:06:22.375 --> 00:06:24.650
temos criptografia e

00:06:24.650 --> 00:06:27.125
criptografia é muito importante
para os nossos usuários, certo?

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

00:06:27.890 --> 00:06:30.965
>> Nós nos certificamos de que
toda a comunicação,

00:06:30.965 --> 00:06:33.950
mesmo interno e interno
comunicação externa,

00:06:33.950 --> 00:06:39.290
com o cluster de big data
É SSL ou TLS criptografado.

00:06:39.290 --> 00:06:41.285
Além disso,

00:06:41.285 --> 00:06:43.325
você pode, naturalmente, alavancar

00:06:43.325 --> 00:06:45.635
os muitos diferentes
recursos de criptografia de

00:06:45.635 --> 00:06:48.470
Servidor SQL que temos
e todos eles que são

00:06:48.470 --> 00:06:49.985
suportado no SQL Server no Linux

00:06:49.985 --> 00:06:52.430
porque estamos correndo em
Recipientes Linux aqui.

00:06:52.430 --> 00:06:57.485
Também estamos trabalhando na expansão
estas capacidades e

00:06:57.485 --> 00:07:00.710
Criptografia HDFS em breve
para que também tenhamos

00:07:00.710 --> 00:07:04.745
essas capacidades de dados
isso é criptografado em risco.

00:07:04.745 --> 00:07:07.920
>> Ok. Fresco. Então, você também pode

00:07:07.920 --> 00:07:09.410
explicar-nos um pouco
pouco mais sobre como

00:07:09.410 --> 00:07:11.570
isso funciona com Kerberos?

00:07:11.570 --> 00:07:16.070
>> Absolutamente. Então, vamos
foco na autenticação

00:07:16.070 --> 00:07:18.770
primeiro porque é
importante para você

00:07:18.770 --> 00:07:20.485
saber que diferença ou

00:07:20.485 --> 00:07:22.785
pontos de entrada existem
para o cluster, certo?

00:07:22.785 --> 00:07:26.360
Aqui você vê os cinco
diferentes pontos finais

00:07:26.360 --> 00:07:28.490
ou pontos de entrada para o cluster.

00:07:28.490 --> 00:07:30.485
Agora temos este cluster Kubernetes,

00:07:30.485 --> 00:07:32.660
portanto, temos que, basicamente, especificamente

00:07:32.660 --> 00:07:35.360
expor certos pontos finais que os usuários

00:07:35.360 --> 00:07:37.430
ou ferramentas do cliente ou
quaisquer aplicações podem

00:07:37.430 --> 00:07:40.865
interagir com no cluster.

00:07:40.865 --> 00:07:44.475
Então, se começarmos com o controlador,

00:07:44.475 --> 00:07:46.685
como você pode estar familiarizado com,

00:07:46.685 --> 00:07:48.860
controlador é o
cérebro do aglomerado.

00:07:48.860 --> 00:07:52.715
Controlador é o único que
mantém o controle de tudo,

00:07:52.715 --> 00:07:54.229
que implanta o cluster,

00:07:54.229 --> 00:07:55.775
e todas essas coisas.

00:07:55.775 --> 00:07:58.580
Agora, para chegar ao
pontos finais do controlador,

00:07:58.580 --> 00:08:02.500
você pode ver aqui que o principal
método que você interagiria

00:08:02.500 --> 00:08:04.885
com ele seria
através do CLI azdata

00:08:04.885 --> 00:08:06.850
mas também através de nossas ferramentas.

00:08:06.850 --> 00:08:11.860
É principalmente o ponto final que
um administrador usaria,

00:08:11.860 --> 00:08:14.005
por exemplo, interagir
com o cluster.

00:08:14.005 --> 00:08:16.180
Mas o controlador também tem poderes mágicos.

00:08:16.180 --> 00:08:20.470
Você pode dizer que o controlador pode classificar
de chegar a outros pontos finais.

00:08:20.470 --> 00:08:23.890
Assim, por exemplo, você pode fazer login

00:08:23.890 --> 00:08:27.485
controlador através de azdata e de

00:08:27.485 --> 00:08:29.920
lá emitir comandos que

00:08:29.920 --> 00:08:32.710
levá-lo ao mestre do servidor SQL
exemplo e você começa a correr

00:08:32.710 --> 00:08:35.380
T-SQL ou você pode executar comandos HDFS

00:08:35.380 --> 00:08:38.665
diretamente em um escudo de HDFS
neste tipo de coisas.

00:08:38.665 --> 00:08:42.470
Então é isso que esse ponto final permite
você para fazer, entre outras coisas.

00:08:42.470 --> 00:08:43.275
>> Ok. Muito legal.

00:08:43.275 --> 00:08:45.830
>> Sim. Em seguida, um ponto final que você

00:08:45.830 --> 00:08:47.690
poderia ter ouvido falar se você já ouviu falar

00:08:47.690 --> 00:08:49.860
clusters de big data usados
é a porta de entrada.

00:08:49.860 --> 00:08:52.055
Agora, a porta de entrada é
na verdade, a mesma coisa.

00:08:52.055 --> 00:08:53.885
O detalhe de implementação por trás disso

00:08:53.885 --> 00:08:56.735
é que é o Apache Knox Gateway.

00:08:56.735 --> 00:08:59.900
Esta é uma porta de entrada que normalmente
protege, você pode dizer,

00:08:59.900 --> 00:09:06.210
os componentes Apache, tais como
basicamente do lado hadoop.

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

00:09:06.510 --> 00:09:07.980
>> Então temos Faísca, Livy,

00:09:07.980 --> 00:09:11.999
YARN se você quiser se conectar
para HDFS através da web HDFS,

00:09:11.999 --> 00:09:13.705
este é o ponto final que você usa,

00:09:13.705 --> 00:09:17.165
bem como do Azure Data Studio.

00:09:17.165 --> 00:09:19.160
Então, isso é bom saber quando

00:09:19.160 --> 00:09:21.505
estamos falando sobre o
porta de entrada que queremos dizer lá.

00:09:21.505 --> 00:09:23.990
Então temos o
procuração de gestão que

00:09:23.990 --> 00:09:28.070
é a porta de entrada para métricas
e ferramentas madeireiras,

00:09:28.070 --> 00:09:31.490
e então temos, obviamente,
Instância mestre do servidor SQL.

00:09:31.490 --> 00:09:33.830
É só SQL. É só.
um ponto final TDS onde você

00:09:33.830 --> 00:09:37.025
conectar-se a partir de quaisquer ferramentas
que você está familiarizado com.

00:09:37.025 --> 00:09:39.200
O proxy do aplicativo, por último
mas não menos importante,

00:09:39.200 --> 00:09:41.780
que é a maneira que você pode

00:09:41.780 --> 00:09:43.310
acessar os aplicativos que

00:09:43.310 --> 00:09:45.290
você implantado dentro
o cluster de big data.

00:09:45.290 --> 00:09:47.820
Agora, todos estes diferentes
pontos finais quando você está correndo,

00:09:47.820 --> 00:09:49.305
por exemplo, em um modo seguro,

00:09:49.305 --> 00:09:50.760
quando o cluster é
rodando em modo seguro,

00:09:50.760 --> 00:09:53.175
Quero dizer modo de integração de anúncios,

00:09:53.175 --> 00:09:58.210
todos estes pontos finais são
permitindo a autenticação de anúncios.

00:09:58.210 --> 00:10:00.200
Então era isso que eu queria.
para destacar aqui.

00:10:00.200 --> 00:10:02.510
Então, quando estamos conversando
sobre a autenticação de anúncios,

00:10:02.510 --> 00:10:06.740
é uma integração total com
AD para todos os pontos finais.

00:10:06.740 --> 00:10:08.645
>> Certo. Na frente de um dos
cinco pontos finais em toda a linha.

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

00:10:09.335 --> 00:10:11.490
>> Uau. OKEY.

00:10:12.740 --> 00:10:16.590
>> Sim. Então isso é autenticação
basicamente para você.

00:10:16.590 --> 00:10:19.755
Seguindo em frente, nós também
ter autorização.

00:10:19.755 --> 00:10:21.290
É muito importante proteger

00:10:21.290 --> 00:10:23.780
seus dados uma vez que é
dentro do aglomerado,

00:10:23.780 --> 00:10:26.720
uma vez que você realmente consegue
entrar e autenticar.

00:10:26.720 --> 00:10:30.675
Sim. Assim, as partes-chave i
queria destacar aqui,

00:10:30.675 --> 00:10:31.920
e isso ainda é de alto nível.

00:10:31.920 --> 00:10:33.485
Tenho certeza que vamos ter

00:10:33.485 --> 00:10:35.660
palestras adicionais sobre o
detalhes dessas coisas.

00:10:35.660 --> 00:10:37.335
Mas em um nível elevado,

00:10:37.335 --> 00:10:38.510
existem dois níveis de

00:10:38.510 --> 00:10:42.050
autorização verifica que você
fazer nos clusters de big data.

00:10:42.050 --> 00:10:44.750
Se começarmos com sql
Servidor, por exemplo,

00:10:44.750 --> 00:10:48.050
se eu estou emitindo uma consulta de servidor SQL,

00:10:48.050 --> 00:10:50.420
em primeiro lugar, há
verificações de autorização

00:10:50.420 --> 00:10:52.100
em objetos do servidor SQL.

00:10:52.100 --> 00:10:54.920
Eu preciso ter acesso ao
tabelas que eu quero consultar,

00:10:54.920 --> 00:10:58.730
por exemplo, para que possamos fazer
tenho certeza de que eu posso acessar os dados.

00:10:58.730 --> 00:11:00.860
>> Mas é o mesmo
verificações de autorização

00:11:00.860 --> 00:11:02.330
como tínhamos em anteriores
lançamentos com SQL?

00:11:02.330 --> 00:11:02.780
>> Sim, é SQL.

00:11:02.780 --> 00:11:03.530
>> Isso não mudou?

00:11:03.530 --> 00:11:04.280
>> Isto é apenas SQL.

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

00:11:04.610 --> 00:11:07.160
>> Então, basicamente, o
modelo de permissão de

00:11:07.160 --> 00:11:08.945
O servidor SQL é o mesmo

00:11:08.945 --> 00:11:11.285
se ele está funcionando em grande
cluster de dados ou em qualquer outro lugar.

00:11:11.285 --> 00:11:13.490
Assim, você ainda pode conceder permissões em

00:11:13.490 --> 00:11:16.950
tabelas específicas e específico
objetos no servidor SQL, certo?

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

00:11:17.915 --> 00:11:19.945
>> Mas além disso,

00:11:19.945 --> 00:11:21.845
agora vamos tomar o cenário quando eu estou

00:11:21.845 --> 00:11:23.990
emitir uma consulta contra dados

00:11:23.990 --> 00:11:26.060
sentado em HDFS e eu estou consultando

00:11:26.060 --> 00:11:28.715
uma tabela externa sobre
HDFS neste caso.

00:11:28.715 --> 00:11:31.790
Não só eu preciso ter
acesso a esta tabela,

00:11:31.790 --> 00:11:34.025
para o banco de dados onde
esta mesa senta-se,

00:11:34.025 --> 00:11:36.320
Eu também preciso ter acesso a

00:11:36.320 --> 00:11:39.905
os arquivos e dados reais
que está sentado em HDFS.

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

00:11:40.145 --> 00:11:43.430
>> Isso é o que eu quis dizer com o
verificações de autorização de dois níveis.

00:11:43.430 --> 00:11:45.035
Então, neste caso, há um check-in

00:11:45.035 --> 00:11:48.620
SQL Server e há um
check-in adicional no HDFS.

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

00:11:48.920 --> 00:11:50.510
>> No lado da faísca,

00:11:50.510 --> 00:11:53.660
basicamente o Spark
as consultas fluem e

00:11:53.660 --> 00:11:56.000
a verificação de autorização do HDFS

00:11:56.000 --> 00:11:58.505
certifique-se de que o
as permissões são honradas.

00:11:58.505 --> 00:12:00.200
>> Ok. Então, com tudo isso,

00:12:00.200 --> 00:12:01.820
Posso ter certeza de que

00:12:01.820 --> 00:12:04.370
o usuário original
identidade é passada através

00:12:04.370 --> 00:12:06.590
Servidor SQL para onde quer que
os dados são, certo?

00:12:06.590 --> 00:12:09.455
HDFS ou como eu acessá-lo, correto?

00:12:09.455 --> 00:12:15.390
>> Exatamente. Sim. Então, como nós
Tipo de tocou antes,

00:12:15.390 --> 00:12:18.825
teremos essa identidade de passagem.

00:12:18.825 --> 00:12:22.670
o que significa que o original
a identidade do usuário fluirá

00:12:22.670 --> 00:12:26.810
Todo o caminho até o
dados para que possamos, na verdade,

00:12:26.810 --> 00:12:27.980
verificar todo o caminho

00:12:27.980 --> 00:12:31.730
que este era o usuário que
queria acessar os dados.

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

00:12:32.800 --> 00:12:38.820
>> Sim. De forma que
basicamente é um resumo sobre

00:12:38.820 --> 00:12:41.390
alto nível na segurança
capacidades em torno de

00:12:41.390 --> 00:12:44.780
as integrações da AD especificamente
para clusters de big data.

00:12:44.780 --> 00:12:47.710
>> Então, onde posso descobrir
mais se eu quiser mergulhar mais fundo?

00:12:47.710 --> 00:12:50.420
>> Sim. Então, se

00:12:50.420 --> 00:12:52.580
você quer aprender mais sobre
grandes clusters de dados em geral

00:12:52.580 --> 00:12:56.495
e temos docs de segurança

00:12:56.495 --> 00:12:59.675
cobrindo detalhes do que
Acabei de explicar hoje,

00:12:59.675 --> 00:13:04.280
você deve ir para isso
link curto: aka.ms/sqlbdc.

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

00:13:05.615 --> 00:13:09.455
>> Se você for lá, você pode aprender
toneladas sobre clusters de big data.

00:13:09.455 --> 00:13:10.835
>> Tudo o que há para aprender, certo?

00:13:10.835 --> 00:13:11.255
>> Sim.

00:13:11.255 --> 00:13:12.560
>> Impressionante. Tudo bem.

00:13:12.560 --> 00:13:14.210
Então, basicamente, eu preciso ir lá

00:13:14.210 --> 00:13:16.750
e começar a aprender e
começar a baixar.

00:13:16.750 --> 00:13:18.810
Posso exportá-lo para um grande PDF e

00:13:18.810 --> 00:13:21.990
em seguida, lê-lo no
noite para aprender?

00:13:21.990 --> 00:13:25.095
>> Sim. Na verdade, eu acho que
você pode fazer isso. Sim.

00:13:25.095 --> 00:13:27.120
>> Não imprimi-lo,
Embora. Apenas PDF, certo?

00:13:27.120 --> 00:13:27.300
>> Sim.

00:13:27.300 --> 00:13:29.390
>> Ok. Fresco. Então, muito obrigado.

00:13:29.390 --> 00:13:31.295
Isso foi muito útil.
Muito obrigado por compartilhar.

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

00:13:32.030 --> 00:13:33.950
>> Obrigado por assistir.

00:13:33.950 --> 00:13:35.960
Por favor, assine, inscrevam-se,
e comentar sobre

00:13:35.960 --> 00:13:37.940
o vídeo e espero
até a próxima vez. Thansk.

00:13:37.940 --> 00:13:52.600
[MÚSICA]