WEBVTT

00:00:08.020 --> 00:00:12.480
Y ya estamos dentro. Pues muy
buenas tardes, Borja Rooks.

00:00:12.520 --> 00:00:13.840
¿Qué tal estás? Borja Rooks.

00:00:13.880 --> 00:00:16.540
Qué bien, muy bien. Encantado
de estar por aquí charlando.

00:00:16.580 --> 00:00:18.840
Muy bien. Pues mira, estamos empezando.

00:00:18.900 --> 00:00:22.860
Eres el episodio 1 de la quinta
temporada del podcast de Café Database.

00:00:23.620 --> 00:00:29.340
Y para los que se entren aquí, nos oigan
por primera vez y para contar un poquito la

00:00:29.340 --> 00:00:33.980
dinámica, estamos en directo en el
servidor de Discord de Café Database.

00:00:33.980 --> 00:00:41.400
La gente que nos está escuchando en
directo puede participar, puede escribir

00:00:41.400 --> 00:00:46.460
en el chat, puede subir a la audiencia,
puede preguntarnos lo que quieran.

00:00:46.500 --> 00:00:52.840
Si nos hacen alguna pregunta o lo que sea,
podemos hacerles participar sin problemas.

00:00:52.840 --> 00:00:56.520
Y para aquellos que nos estén escuchando
en diferido o aquellos que lleguen tarde o lo

00:00:56.560 --> 00:01:00.420
que sea, pues cuando terminemos el podcast
lo subiremos a las plataformas de podcast,

00:01:00.460 --> 00:01:04.400
Spotify, Apple Podcasts,
iVoox y todas estas.

00:01:05.020 --> 00:01:10.620
Así que, primer episodio de la primera
temporada, Borja Rooks, te voy a presentar, ¿vale?

00:01:12.080 --> 00:01:17.360
Mira, experto en ciberseguridad, y me mola
muchísimo la frase que te presentas que dices,

00:01:17.500 --> 00:01:24.180
¿cómo lo has dicho? Ayudo a las empresas
a protegerse de criminales, ¿no?

00:01:24.740 --> 00:01:29.573
Ayudo a las empresas a protegerse de los
criminales de fuera y de los torpes de dentro.

00:01:31.400 --> 00:01:34.140
¿Cómo lo ves eso? ¿De qué hay más?

00:01:35.580 --> 00:01:39.913
¿De qué hay más? Hay muchos más,
afortunadamente hay muchos más torpes dentro.

00:01:41.140 --> 00:01:48.000
Al final, digamos que los ciberdelincuentes
son bastante menos que los torpes, sobre

00:01:48.000 --> 00:01:49.840
todo por una razón muy sencilla.

00:01:50.420 --> 00:01:53.840
Todos en algún momento somos torpes.

00:01:54.260 --> 00:02:00.300
Todos en algún momento terminas llegando
al trabajo, me da igual con resaca, me da igual

00:02:00.300 --> 00:02:05.060
habiendo venido de llevarle
al peque al hospital.

00:02:05.060 --> 00:02:11.080
Puede ser un momento en el que estés
pensando en otras cosas entonces todos todos todos

00:02:11.080 --> 00:02:15.920
la vamos a liar en algún momento todos
somos torpes en algún momento y afortunadamente

00:02:15.920 --> 00:02:21.380
no todos somos ciber delincuentes en algún
momento oye una cosa como nos ves a los dbas

00:02:21.380 --> 00:02:26.120
en los desarrollos como es los a la gente
de base de datos cuando tú haces alguna alguna

00:02:26.160 --> 00:02:32.020
consultoría de ciberseguridad sobre todo
tocas startups y empresas digamos para construir

00:02:32.020 --> 00:02:35.853
toda la política de ciberseguridad
desde cero, toda la planificación.

00:02:35.900 --> 00:02:38.456
¿Cómo nos ves a los
técnicos de base de datos?

00:02:38.760 --> 00:02:41.120
¿Estamos educados? ¿Hay
que evangelizarlos mucho?

00:02:41.160 --> 00:02:47.320
¿Cómo nos ves? A ver, tampoco os puedo
poner a parir en este foro, estaría feo.

00:02:47.840 --> 00:02:54.780
No, Hablando en serio yo lo que me suelo
encontrar con la gente de base de datos

00:02:55.860 --> 00:02:58.471
para mí es muy parecida
a la gente de sistemas.

00:02:58.720 --> 00:03:05.180
La gente de base de datos y la gente de
sistemas temas, vienen de, en general, obviamente

00:03:05.180 --> 00:03:09.400
estoy generalizando, vienen de situaciones
en las que cada vez que hay un problema en

00:03:09.440 --> 00:03:14.120
producción sudan sangre. Cada vez que hay
un problema en producción es levantarse a la

00:03:14.160 --> 00:03:19.900
hora que sea, ir a resolver, no se está
dando un servicio, no está funcionando lo que

00:03:19.900 --> 00:03:21.080
debería estar funcionando.

00:03:21.120 --> 00:03:27.040
Son cuestiones en general muy graves y que
requieren una atención inmediata entonces

00:03:27.040 --> 00:03:34.160
eso hace que el cuidado con el que
tanto la gente de sistemas como la

00:03:34.160 --> 00:03:41.220
gente de bea el cuidado con el que tratan
la información sobre todo desde el punto

00:03:41.220 --> 00:03:47.810
de vista de la seguridad es francamente
bueno todo el mundo todo el mundo no siempre

00:03:47.810 --> 00:03:55.870
hay siempre hay digamos pero en mi
experiencia trabajar con gente de base

00:03:55.870 --> 00:04:03.110
de datos en general es francamente agradable
puede que haya que explicar ciertas

00:04:03.110 --> 00:04:09.550
cosas puede que haya que echar un cable en
algún tema pero todos los momentos en el momento

00:04:09.550 --> 00:04:15.570
en el que alguien de base de datos entiende
cuál es el riesgo está está encantado de

00:04:15.570 --> 00:04:17.910
hacer todo lo que sea
necesario para mitigarlo.

00:04:17.950 --> 00:04:20.950
Eso es maravilloso y
hasta aquí el podcast.

00:04:21.290 --> 00:04:23.290
No hace falta que Hablemos nada más.

00:04:25.350 --> 00:04:31.730
Genial muchas gracias pues, oye, fíjate
que yo, además, yo tenía muchas veces el complejo

00:04:31.730 --> 00:04:36.470
de que éramos un poco también los torpes,
porque fíjate que habíamos comentado muchas

00:04:36.470 --> 00:04:40.790
veces que la password de SIS, yo te había
dicho, la password de SIS de toda la vida siempre

00:04:40.830 --> 00:04:43.090
ha sido change on install, ¿no?

00:04:43.090 --> 00:04:44.590
Y la de System era Manager.

00:04:44.750 --> 00:04:52.050
Entonces, ¿no te puedes imaginar la de
sitios donde aquí los usuarios, la seguridad

00:04:52.050 --> 00:04:57.010
y no sé qué, y entrabas al servidor como
sys, password, change on install, y entrabas.

00:04:57.190 --> 00:05:01.079
Y entrabas y viste, es decir, toda
la política estaba en los usuarios,

00:05:01.850 --> 00:05:08.070
o cuando te autentica el sistema operativo
tú puedes conectarte con barra, barra a sysdba.

00:05:08.250 --> 00:05:11.470
O sea, no me autentico porque ya el
sistema operativo me deja entrar.

00:05:11.510 --> 00:05:18.530
Ni contraseña nada, para adelante entonces
tenía un poco la idea esa y esa es la

00:05:18.530 --> 00:05:23.270
forma de trabajar en muchísimas
empresas hasta que se empieza

00:05:24.910 --> 00:05:30.510
Hasta que empiezan los incidentes, vale, o
sea no hay, digamos, no hay empresa con mejor,

00:05:30.670 --> 00:05:34.790
no voy a decir mayor, pero desde luego no
hay empresa con mejor presupuesto de ciberseguridad

00:05:34.830 --> 00:05:41.230
que la empresa al día siguiente de haber
recibido un ciberataque, vale Es posible que

00:05:41.230 --> 00:05:45.810
cambie el responsable de seguridad, bien,
pero el responsable de seguridad que está al

00:05:45.850 --> 00:05:50.290
día siguiente normalmente suele tener
las cosas más o menos en condiciones.

00:05:50.530 --> 00:05:54.990
Y en el momento en el que tienes el primer
incidente porque alguien no cambió la contraseña

00:05:55.030 --> 00:06:01.950
por defecto de la base de datos, del
servicio de VPN o de cualquier otro elemento crítico,

00:06:02.790 --> 00:06:07.512
al día siguiente, bueno, pues lo normal
suele ser que haya visitas a recursos humanos

00:06:08.680 --> 00:06:14.730
Y que se empiecen a arreglar las cosas Sí,
además quiero decir, está cada vez no más

00:06:14.730 --> 00:06:18.250
de moda, pero está a la orden del día
noticias como lo que ha pasado en el Louvre, la

00:06:18.290 --> 00:06:24.350
filtración de datos de clientes que ha
tenido recientemente Endesa un montón de...

00:06:24.350 --> 00:06:28.630
Es decir, estamos a la orden del día
quizá la IA está ayudando también a los

00:06:29.870 --> 00:06:33.210
Cibercriminales A ver, la
IA ayuda a todo el mundo.

00:06:33.250 --> 00:06:34.861
Como tecnología es agnóstica.

00:06:35.190 --> 00:06:39.230
Entonces, va a echar una mano
tanto a ataque como a defensa.

00:06:40.930 --> 00:06:45.890
Lo que pasa es que las condiciones del
ataque son muy distintas a las condiciones de

00:06:45.890 --> 00:06:50.840
la defensa, me explico. Tú en ataque
solamente necesitas encontrar una puerta, o sea,

00:06:50.860 --> 00:06:57.400
necesitas encontrar un agujero Tú en
defensa tienes que tapar todos los agujeros Tú en

00:06:57.400 --> 00:07:03.880
ataque puedes atacar un millón de veces
que solamente necesitas que una funcione Tú en

00:07:03.880 --> 00:07:10.640
defensa tienes que asegurarte de que
ninguna de ese millón un ataques tenga éxito Con

00:07:10.640 --> 00:07:18.360
lo cual, mi sensación es que vamos a
estar en desventaja, en defensa durante

00:07:18.360 --> 00:07:25.640
bastante tiempo hasta que entendamos
todos cómo utilizar la inteligencia

00:07:25.640 --> 00:07:30.940
artificial. Hasta entonces vamos a seguir
probando, por decirlo de alguna manera, y haciendo

00:07:30.940 --> 00:07:32.773
cosas más o menos experimentales.

00:07:33.680 --> 00:07:40.780
Y en ese contexto, mi sensación es que
los atacantes tienen ventaja, porque

00:07:40.780 --> 00:07:48.220
ellos pueden probar mil cosas y con que
funcione una, pues eso, les toca la lotería.

00:07:48.440 --> 00:07:52.740
En defensa tiene que funcionar, entre
comillas, tiene que funcionar cada cosa.

00:07:52.780 --> 00:07:56.740
A mí, de esto que hablabas de la IA, me
gustaba mucho una cosa que contaste hace poco

00:07:56.780 --> 00:08:00.020
en tu newsletter, que decías
que la IA es un amplificador.

00:08:00.720 --> 00:08:03.940
Luego, como el dinero el
dinero es un amplificador.

00:08:04.720 --> 00:08:09.240
Si eres buena persona, pues serás mucho
más buena persona si tienes dinero.

00:08:09.340 --> 00:08:12.280
Si eres un gilipollas, serás
mucho más gilipollas con dinero.

00:08:12.320 --> 00:08:16.160
La IA, digamos, es un amplificador
también de lo que eres.

00:08:16.740 --> 00:08:25.950
A muchos niveles. Más allá del
uso que hago de la IA en la parte

00:08:25.950 --> 00:08:30.090
de ciberseguridad, también soy profesor en
un máster de inteligencia artificial no -code

00:08:30.130 --> 00:08:37.630
y parte de lo que suelo comentar es
que la IA nos va a obligar a saber

00:08:37.630 --> 00:08:44.690
mucho más de los temas y a conocernos
mucho mejor a nosotros, porque si no, no va a funcionar

00:08:44.690 --> 00:08:49.970
bien. Quiero decir, este fin de semana he
estado utilizando la inteligencia artificial

00:08:49.970 --> 00:08:52.359
para crear un programa
de edición de vídeo.

00:08:52.810 --> 00:08:58.820
Yo necesito tener muy claro qué es lo que
yo sé de edición de vídeo, qué es lo que yo

00:08:58.820 --> 00:09:05.940
sé de programación para poder guiar,
corregir y digamos pulir lo que me dé

00:09:05.940 --> 00:09:06.720
la inteligencia artificial.

00:09:06.760 --> 00:09:13.340
Si yo no sé nada de edición y yo no sé
nada de programación las probabilidades que tengo

00:09:13.340 --> 00:09:20.760
de que eso llegue a donde yo quiero son
mucho menores es lo que está que vete a echar

00:09:20.760 --> 00:09:27.900
gpt ayúdame a fortalecer la seguridad
de mis sistemas pero eso es lo mismo

00:09:27.900 --> 00:09:34.980
que nos hubiera pasado con el
preguntárselo a google y que te devuelva me da igual las

00:09:34.980 --> 00:09:42.600
10 mejores medidas de seguridad que
tiene que tomar tu empresa y cesc las

00:09:43.430 --> 00:09:50.550
probabilidades que tienes de acertar son
bajas que bueno que bueno oye pues vamos

00:09:50.550 --> 00:09:57.170
a meternos en materia técnica dura vale a
ver a ver a ver qué tal yo tengo contar una

00:09:57.170 --> 00:10:02.910
Esto que decías de empresas, yo soy de una
empresa, no voy A decir cuál, un portal web

00:10:02.910 --> 00:10:09.450
muy famoso. Un día llegó la Guardia Civil
con un CD -ROM, se habían llevado la base de

00:10:09.450 --> 00:10:13.490
datos y se la habían llevado
del servidor de backup.

00:10:13.490 --> 00:10:21.410
Es decir, parece muchas veces que ponemos
una puerta, digamos, una fortaleza inexpugnable,

00:10:21.410 --> 00:10:26.210
digamos, en la base de datos para que los
usuarios de una contraseña vayan cambiando,

00:10:26.250 --> 00:10:30.250
el servidor principal está en clúster,
cifrado, encriptado, todo esto.

00:10:30.250 --> 00:10:36.510
Y luego los backups se están llevando a un
NAS, a un file system compartido, es decir,

00:10:36.570 --> 00:10:39.790
se habían llevado la base de datos de ahí,
se había llevado limpio el export -import,

00:10:39.830 --> 00:10:44.550
el feature de export se habían
llevado limpio para hacer un import.

00:10:44.850 --> 00:10:51.310
Te quería preguntar, ¿cómo es de homogénea
o cómo te encuentras de homogénea o sigue

00:10:51.310 --> 00:10:57.210
aplicando esto de estoy poniendo muchísima
fortaleza en un sitio y estoy descuidando

00:10:57.210 --> 00:11:01.930
lo más tonto? Te has encontrado con cosas
así o relativas en base a datos también es

00:11:01.930 --> 00:11:08.710
muy habitual un poco por lo que comentaba
antes de que cuando estás defendiendo tienes

00:11:08.710 --> 00:11:16.050
que tapar todos los agujeros es normal
que se queden algunos agujeros sin

00:11:16.050 --> 00:11:21.670
tapar el problema es cuando los agujeros
que se quedan sin tapar están en, vamos a decir,

00:11:21.770 --> 00:11:27.930
están en un ángulo muerto, no eres
consciente de que tengas que cubrir eso Eso.

00:11:28.430 --> 00:11:35.970
Yo normalmente trabajo sobre todo Con
startups entonces, en algunos casos, la

00:11:35.970 --> 00:11:41.010
gran revelación para esa empresa es
descubrir que debería de hacer backups.

00:11:41.270 --> 00:11:43.230
Y dices, ostras, es verdad,
debería de hacer backups.

00:11:43.270 --> 00:11:49.310
¿Vale? Digamos que hay niveles de
madurez para todos los gustos y sabores.

00:11:50.650 --> 00:11:57.810
Pero las empresas que se ponen a
hacer cosas de ciberseguridad, lo

00:11:57.810 --> 00:12:00.470
que les suele pasar es que las
hacen de manera desordenada.

00:12:00.510 --> 00:12:04.390
Quiere decir, todo el mundo sabe que hay
que poner un antivirus, todo el mundo sabe que

00:12:04.430 --> 00:12:07.530
hay que poner un segundo factor de
autenticación, todo el mundo sabe que hay que hacer

00:12:07.570 --> 00:12:15.190
backups. Entonces, si no
planteas, digamos, la estrategia

00:12:15.190 --> 00:12:19.410
a nivel de ciberseguridad, vas
a tomar acciones muy puntuales.

00:12:19.410 --> 00:12:24.290
Una de las acciones puntuales hacer
backups, entonces tenía en la lista hacer backups,

00:12:24.550 --> 00:12:29.010
entonces copio todos los ficheros o copio
todo el contenido de la base de datos a este

00:12:29.050 --> 00:12:34.790
servidor y marco un check en lo de hacer
backups entonces los backups ya están hechos

00:12:35.740 --> 00:12:38.280
es que luego hay que hacer
la prueba de restore ¿eh?

00:12:38.320 --> 00:12:41.042
Luego hay que hacer la
prueba de restore es decir

00:12:41.940 --> 00:12:47.060
dudo mucho bueno, dudo
mucho lo más habitual

00:12:48.000 --> 00:12:52.800
a ver A ver, es habitual que las
empresas no tengan ningún tipo de backup.

00:12:53.080 --> 00:12:57.240
No voy a decir que la mayor parte de las
empresas, no es cierto, pero hay muchas empresas

00:12:57.280 --> 00:13:04.380
que no tienen backup. De las que tienen
backup, muchas no tienen un backup o no tienen

00:13:04.380 --> 00:13:07.820
backups de manera sistemática.

00:13:07.950 --> 00:13:10.250
No digo ya automatizada, sistemática.

00:13:10.370 --> 00:13:15.430
Todos los viernes, todos los martes,
una vez al mes, no hay algo sistemático.

00:13:16.130 --> 00:13:23.130
Incluso habiendo algo sistemático,
la seguridad Del backup suele ser

00:13:23.130 --> 00:13:27.830
bastante deficiente. Y ahora entro
en la parte de cifrados y tal.

00:13:28.710 --> 00:13:36.000
Y de aquellos que tienen backup, empresas
que hagan una recuperación del backup una

00:13:36.000 --> 00:13:41.030
vez, te voy a decir, al
año, son una minoría.

00:13:41.090 --> 00:13:45.190
Son una minoría y esta me la
contó mi hermano, me gusta mucho.

00:13:46.230 --> 00:13:51.380
No eres digno del título
hasta que no lo defiendes.

00:13:52.020 --> 00:13:57.240
Entonces, lo de hacer backup está muy bien,
pero en realidad tú no tienes ese backup

00:13:57.240 --> 00:14:02.360
hasta que no defiendes el título y no
verificas que ese backup realmente sirve para algo.

00:14:03.080 --> 00:14:05.524
Y para eso necesitas
hacer una recuperación.

00:14:06.770 --> 00:14:13.010
Que bueno, mira dime, dime, perdona bueno,
te iba a ir al hilo de eso bueno, sí que te

00:14:13.010 --> 00:14:17.910
digo yo, al hilo de esto también para un
poco trasladarlo al siguiente tema, habíamos

00:14:17.910 --> 00:14:21.910
estado hablando de DBSAT, una de las
primeros warnings que te salta en DBSAT cuando tú

00:14:21.950 --> 00:14:26.730
miras una base de datos y le lanzas el
DBSAT y dices, oye, en esta base de datos ¿qué

00:14:26.730 --> 00:14:28.230
problemas de seguridad hay?

00:14:28.350 --> 00:14:33.010
Hay dos que son muy grandes, uno si está
en el último parche y dos, si hay backups físicos,

00:14:33.050 --> 00:14:35.470
o sea, se habla mucho de backups o de...

00:14:35.470 --> 00:14:38.692
Dice, no, no, si yo ya me llevo
un snapshot de la máquina.

00:14:38.770 --> 00:14:41.750
Y luego dices, oye, que esto a lo mejor
lo intentas recuperar y no funciona, ¿no?

00:14:41.790 --> 00:14:45.310
He visto casos que dicen, no, hemos
recuperado un snapshot de la máquina y luego Oracle

00:14:45.350 --> 00:14:48.517
no arrancaba, ¿no? El tema de
backups consistentes y tal.

00:14:49.210 --> 00:14:53.050
Ahí falta mucho yo te digo, mi experiencia
va a ser, entonces, que falta bastante.

00:14:53.090 --> 00:14:56.690
Fíjate en el DBSAT, es de las primeras
cosas que te avisa, te dice, si no tienes un backup

00:14:56.730 --> 00:15:01.830
físico consistente, digamos, en caliente,
cuidado, porque es como si no tuvieras nada.

00:15:02.850 --> 00:15:06.870
Y por lo que tú has visto, por lo que tú
Tú conoces de Debesat y todo esto, y te dejo

00:15:06.910 --> 00:15:08.890
que termines lo que decías de backup.

00:15:08.930 --> 00:15:10.450
¿Cómo has visto la herramienta?

00:15:10.490 --> 00:15:15.470
¿Cómo ves el tema? ¿O cómo ves la
explicación Que da cuando dice, oye, no tienes suficiente

00:15:15.510 --> 00:15:20.230
backup, estas son las buenas prácticas,
estas son las recomendaciones de seguridad?

00:15:20.350 --> 00:15:21.850
¿Cómo has visto la herramienta?

00:15:21.890 --> 00:15:27.210
A ver, para mí la herramienta es
francamente muy buena por dos razones.

00:15:27.210 --> 00:15:31.543
Primero, porque las cosas, digamos, más
flagrantes te las pones sobre la mesa.

00:15:32.150 --> 00:15:34.317
Oye, que es que esto está sin parchear.

00:15:34.370 --> 00:15:36.926
Cachondo, esto está sin
parchear, no me jodas.

00:15:37.030 --> 00:15:42.250
No tiene sentido desde un punto de vista
de ciberseguridad saber que hay vulnerabilidades

00:15:42.250 --> 00:15:45.870
de seguridad en algunos casos graves
y no haber aplicado los parches.

00:15:45.910 --> 00:15:52.250
Lo que dices de los backups, señores,
tener una base de datos en la que se supone que

00:15:52.250 --> 00:15:57.110
tienes información importante y no tener
unos backups, obviamente es una cagada.

00:15:57.650 --> 00:16:04.980
Pero me gusta también mucho porque presenta
muchísima información diciendo, oye,

00:16:04.980 --> 00:16:07.140
chico, esto échale un ojo.

00:16:07.660 --> 00:16:13.400
Tienes no sé cuántos usuarios de este
tipo, tienes esto configurado de esta manera, que

00:16:13.400 --> 00:16:17.100
a lo mejor es lo que a ti te gusta y a lo
mejor es la forma de funcionar en tu empresa,

00:16:17.140 --> 00:16:23.910
pero no huele bien. Entonces, no es una
cuestión de tienes una gran cagada, como el tema

00:16:23.910 --> 00:16:31.090
de los parches, pero sí que te ayuda mucho
a guiar a tu cliente a, oye, he visto

00:16:31.090 --> 00:16:37.500
esto, tú estás seguro de que se necesitan
tantos usuarios para esto, tú estás seguro

00:16:37.500 --> 00:16:43.360
de que Esto tiene sentido o es que simplemente
ha habido un crecimiento orgánico, un

00:16:43.360 --> 00:16:48.240
crecimiento de estos descontrolados, se le
empezó a dar a la gente permisos y se le empezó

00:16:48.280 --> 00:16:55.280
a permitir a todo el mundo hacer
mil cosas, y esto ha terminado en

00:16:55.280 --> 00:16:59.820
el caos. En eso te quería

00:17:01.000 --> 00:17:06.900
preguntar, ¿cuánto ves que va a seguir
siendo necesario la parte humana para interpretar

00:17:06.900 --> 00:17:12.420
cuando de verdad un usuario está crecido
en privilegios o cuando un sistema está como

00:17:12.420 --> 00:17:17.480
muy regalado de que se ha dado el DBA a
todo el mundo, porque claro te dice, oye yo veo

00:17:17.480 --> 00:17:23.780
aquí estos tres usuarios que tienen el rol
DBA pero yo no sé si está bien no sé si corresponde

00:17:23.780 --> 00:17:30.600
es decir, ¿hasta qué punto crees que vamos
a seguir siendo más importantes los humanos

00:17:30.600 --> 00:17:34.920
en toda la parte esa, ¿no?

00:17:35.800 --> 00:17:40.740
Sentido humano para mí, la toma de
decisiones durante mucho tiempo va a seguir siendo

00:17:40.740 --> 00:17:46.600
humana. Pero tiene que ser un humano
que sepa de lo que está hablando.

00:17:46.820 --> 00:17:49.700
Y eso cada vez es más complicado.

00:17:50.520 --> 00:17:53.620
Respecto al tema concreto
que dices de los permisos.

00:17:53.700 --> 00:17:58.720
Y luego quiero comentar una cosa sobre sobre
el tema de las versiones de passwords y

00:17:58.720 --> 00:18:07.140
tal. Sobre el tema de los permisos,
mi sensación es que, ¿cómo

00:18:07.140 --> 00:18:08.600
se llama? ¿El Privilege Capture?

00:18:08.640 --> 00:18:11.960
¿Puede ser? Sí, sí, es
una herramienta para...

00:18:11.960 --> 00:18:18.600
La herramienta esta lo que te va a decir
es qué privilegios que están dados, ¿vale?

00:18:19.060 --> 00:18:20.700
Realmente se están utilizando.

00:18:20.740 --> 00:18:27.960
Y eso, mi sensación es que va a tener
dos grandes beneficios uno es dentro

00:18:27.960 --> 00:18:33.180
de la seguridad de las bases de datos va a
ser fabuloso porque no nos engañemos si hay

00:18:33.180 --> 00:18:38.700
un usuario que no ha utilizado no sé qué
permiso en los últimos cinco años vamos a suponer

00:18:38.700 --> 00:18:44.220
que no lo necesita y digo cinco años pueden
ser cinco años cinco minutos cinco meses

00:18:44.220 --> 00:18:51.560
el tiempo digamos que lo podemos lo
podemos discutir pero va a ser para

00:18:51.560 --> 00:18:57.320
mí un factor actor clave a la hora de
reducir los permisos de los usuarios, que es un

00:18:57.320 --> 00:19:02.840
proceso que es dolorosísimo en ciberseguridad,
porque no nos engañemos no hay ningún

00:19:02.840 --> 00:19:07.260
usuario que nunca se haya quejado por tener
permisos de más como muchos se quejan de

00:19:07.300 --> 00:19:12.920
tener permisos de menos, necesito hacer no
sé qué y no puedo pero el decir tengo permisos

00:19:12.920 --> 00:19:16.500
de más y creo que no los necesito,
nunca nadie se quejó por eso

00:19:19.340 --> 00:19:25.660
Volviendo a lo que decía de las password
version Otro tema que me ha parecido súper curioso

00:19:25.660 --> 00:19:32.940
de base de datos, perdón, del DBSAT,
es que te hace un informe de qué

00:19:32.940 --> 00:19:39.220
usuarios tienen todavía las contraseñas
con versiones de passwords antiguas y vulnerables.

00:19:41.460 --> 00:19:48.650
Eso me parece genial desde el punto de
vista de vamos de los usuarios de base de

00:19:48.650 --> 00:19:55.970
datos pero hay un trabajo que hacer tremendo
a la hora de proteger las contraseñas

00:19:55.970 --> 00:20:02.070
de los usuarios de las aplicaciones ahí yo
me encontrado bueno desde poner las contraseñas

00:20:02.070 --> 00:20:09.170
en plano vale en texto claro Claro, un
clásico donde los haya, a no saber hacer una

00:20:09.170 --> 00:20:12.590
criptografía mínimamente decente
para proteger esas contraseñas.

00:20:12.630 --> 00:20:14.074
Y eso me parece muy grave.

00:20:14.370 --> 00:20:19.870
Y ese es uno de los casos que te comentaba
al principio, en el momento en el que hablas

00:20:19.870 --> 00:20:25.810
con un DBA y le explicas, oye, pues los
hashes funcionan así, el motivo por el que tienes

00:20:25.810 --> 00:20:30.630
que tener un hash con un salt es este, el
motivo por el que tienes que almacenarlo de

00:20:30.630 --> 00:20:35.530
esta manera es este, El motivo por el que
necesitas hacerlo de este otro modo es para

00:20:35.530 --> 00:20:36.890
protegerte de este ataque.

00:20:36.930 --> 00:20:43.230
En el momento en que a un DBA le explicas
esas cosas, se ponen manos a la obra, implementan

00:20:43.230 --> 00:20:47.970
un PL o hablan con el desarrollador o hacen
lo que sea necesario para garantizar que

00:20:47.970 --> 00:20:52.310
esas contraseñas estén hechas en
condiciones, escritas en condiciones.

00:20:53.610 --> 00:20:59.210
Te diré que estamos muy acostumbrados a
estar en la parte de que cada vez que implementamos

00:20:59.210 --> 00:21:05.290
algo, algo se rompe, alguien se queja, que
habéis tocado, que de pronto ahora ya no funciona

00:21:05.290 --> 00:21:10.750
esto. Pues mira, hemos puesto lo que sea,
hemos actualizado las versiones de las contraseñas,

00:21:10.850 --> 00:21:12.450
hemos actualizado esta paquetería.

00:21:12.490 --> 00:21:18.030
Pues a mí me iba, oye, esta paquetería es
del año de la polca, por favor, ya no tienes

00:21:18.030 --> 00:21:21.370
que utilizar este paquete, lo
hemos retirado por seguridad.

00:21:21.370 --> 00:21:27.290
No, no, pues es que ciertos procesos
financieros necesitan esta paquetería, déjanoslo.

00:21:27.590 --> 00:21:34.150
Entonces, estamos en esa primera línea de
fuego muchas veces de tener la mala fama, ¿no?

00:21:34.210 --> 00:21:40.390
De ser los que rompemos las cosas
en pro un poco de la seguridad, ¿no?

00:21:40.810 --> 00:21:45.270
Pero, bueno, es que me
suenan mucho cosas que…

00:21:45.270 --> 00:21:47.770
Nos pasa mucho en ciberseguridad.

00:21:48.210 --> 00:21:53.543
Hay un dicho que es la culpa es del
cortafuegos, sobre todo cuando trabajas con desarrolladores.

00:21:54.390 --> 00:21:58.810
Esto en mi máquina funciona, suele
derivar a la culpa es del cortafuegos.

00:21:58.810 --> 00:22:05.890
Y la forma en la que yo siempre he
instruido a mis equipos que trabajen

00:22:05.890 --> 00:22:12.910
con las quejas de el cortafuegos no funciona
y no nos está cortando el no sé qué.

00:22:13.670 --> 00:22:20.980
Necesitas tener un procedimiento
súper ágil para verificar

00:22:20.980 --> 00:22:24.080
si el problema es del cortafuegos o no.

00:22:24.800 --> 00:22:30.820
Vale cada vez que hacíamos modificaciones
cada vez que hacíamos cambios aunque no estuvieran

00:22:30.820 --> 00:22:35.760
relacionados con nada de las quejas de los
usuarios nosotros siempre teníamos un procedimiento

00:22:35.800 --> 00:22:41.660
de oye exactamente en el caso de cortafuegos
cuál es la máquina de origen cuál es la

00:22:41.660 --> 00:22:46.640
máquina de destino vamos a hacer un ping
si el ping funciona vamos a hacer un telnet

00:22:46.640 --> 00:22:51.160
si el telnet funciona vamos a hacer un tal
y si eso funciona vamos a hacer sí y teníamos

00:22:51.200 --> 00:22:56.780
un procedimiento súper claro súper a mano
de tal manera que cuando alguien se quejaba

00:22:56.780 --> 00:23:05.920
sabíamos perdón sabíamos que no habíamos
sido nosotros en el 90 % de los casos pero

00:23:05.920 --> 00:23:12.040
independientemente de que fuéramos
nosotros o no necesitábamos tener un procedimiento

00:23:12.040 --> 00:23:19.460
para demostrar demostrarnos si habíamos
sido nosotros otros a veces pasaba claro o demostrar

00:23:19.460 --> 00:23:27.740
a la otra parte esto no es nuestro vete a
quejarte a otra parte y qué bueno el procedimiento

00:23:27.740 --> 00:23:34.300
de verdad recomendadísimo cada vez que se
haga una actualización O lo que sea buscar

00:23:34.300 --> 00:23:42.640
la forma de cuando alguien se queje como
puedo mostrar que no he sido yo librarme

00:23:42.640 --> 00:23:48.360
de librar los ojos de mí te iba a decir
esto de firewall y tal oye que le has echado

00:23:48.360 --> 00:23:54.580
un ojo al sql firewall de oracle para la
nueva versión 26 y como que te ha parecido a

00:23:54.580 --> 00:23:59.340
ver me parece genial sobre todo desde el
punto de vista del rendimiento que se puede

00:23:59.340 --> 00:24:05.400
conseguir yo he trabajado con firewalls de
base de datos externos tipo por ejemplo interna

00:24:05.430 --> 00:24:12.510
entonces él Tienes una pieza
dentro de la infraestructura de red

00:24:12.510 --> 00:24:19.330
que te hace ese trabajo
de firewall de SQL.

00:24:20.440 --> 00:24:27.510
Básicamente, aprende cuáles son las SQL
que se ejecutan y todo aquello que no se corresponda

00:24:27.510 --> 00:24:33.190
con las SQL que ha aprendido, pues dice
esto no es mío, esto no hay que ejecutarlo, esto

00:24:33.190 --> 00:24:39.630
está mal. En contexto de sesión, si todo
el mundo entra por aplicación y de pronto entra

00:24:39.630 --> 00:24:45.870
un SQL Developer, por ejemplo, una
aplicación SQL Developer .exe, dice, esta aplicación

00:24:45.870 --> 00:24:50.090
no está dentro de mi contexto de entorno.

00:24:50.090 --> 00:24:57.230
A mí me parece súper interesante el
perfilado por usuario, porque obviamente

00:24:57.230 --> 00:25:03.750
las operaciones que va a realizar un DBA
van a ser muchísimo más variopintas que las

00:25:03.750 --> 00:25:05.450
operaciones que tiene
que hacer una aplicación.

00:25:05.490 --> 00:25:11.930
Ahí, ese es un caso claro del
procedimiento del que te hablaba yo.

00:25:12.270 --> 00:25:20.130
En algún momento el firewall De
SQL se pondrá a aprender durante

00:25:20.130 --> 00:25:24.410
X tiempo y habrá un momento
en el que se ponga a bloquear.

00:25:24.410 --> 00:25:29.950
En el momento en el que se ponga a
bloquear, lo más probable es que no tengáis ningún

00:25:29.950 --> 00:25:33.950
problema. ¿Por qué? Porque has estado
aprendiendo hasta hace 15 minutos.

00:25:34.010 --> 00:25:39.350
Muy raro será que la aplicación haya puesto
una SQL nueva en los últimos 15 minutos,

00:25:39.610 --> 00:25:47.690
pero un mes después, una semana después
o un año después, un desarrollador creará

00:25:47.690 --> 00:25:52.730
una SQL distinta, una SQL nueva
para una nueva funcionalidad.

00:25:52.730 --> 00:25:58.730
Y es como debe ser, no estoy diciendo que
eso sea pecado te voy a decir lo bueno, es

00:25:58.730 --> 00:26:04.210
que el error que va a dar es SQL no
permitida por contexto por el SQL Firewall

00:26:05.450 --> 00:26:12.490
Ahí sí que nos van a venir con esa etiqueta
que dice, oye el Firewall de SQL se

00:26:12.490 --> 00:26:14.823
está quejando el Firewall no me deja pasar

00:26:15.550 --> 00:26:19.490
que es una de las cosas que cuando no puedes
entrar a través de un Firewall no sabes

00:26:19.530 --> 00:26:21.250
qué pasa y dices, oye, ¿y el Firewall qué?

00:26:21.290 --> 00:26:26.070
Espera, a ver no es como un error
silencioso o es un bloqueo no te quedas ahí esperando

00:26:26.110 --> 00:26:30.590
es quien no me está dejando entrar aquí de
pronto se devuelve un error y dice oye este

00:26:30.630 --> 00:26:36.180
sql no está dentro de mi perfil como le
puedes decir oye habéis habéis metido una nueva

00:26:36.180 --> 00:26:41.800
sql porque habéis metido una sql nueva sin
decirnos nada no habíamos quedado en que tal

00:26:41.800 --> 00:26:47.040
tal tal sí y a mí me parece
que ese se va a ser un

00:26:48.000 --> 00:26:53.080
Desde un punto de vista de mejora de la
seguridad, creo que va a mejorar mucho la seguridad.

00:26:53.120 --> 00:27:01.040
Ahora te hago un par de referencias al
hospital, pero desde el punto de vista de, vamos

00:27:01.040 --> 00:27:07.700
a decir, de relaciones internas entre
equipos, creo que puede ser bastante claro.

00:27:07.820 --> 00:27:13.100
Como dices tú, si el error es
suficientemente claro, la discusión debería de ser suficientemente

00:27:13.140 --> 00:27:20.920
corta. El problema es

00:27:20.920 --> 00:27:26.700
lo que has dicho tú sobre sobre los
firewalls normalmente cuando bloqueas con un firewall

00:27:26.700 --> 00:27:33.760
lo que haces es ignorar una petición que
no te interesa vale entonces pues hay

00:27:33.760 --> 00:27:38.160
un time out y dices no sé si el time out
es porque está mal la red no sé si es por no

00:27:38.200 --> 00:27:42.100
sé qué no sé si es por no sé cuánto, no
tienes un error claro si tienes un error claro

00:27:42.140 --> 00:27:48.400
de estás meando fuera de tiesto con esta
sentencia SQL la discusión debería de ser muy

00:27:48.400 --> 00:27:55.430
corta Totalmente eso va a ser una opción
de pago el SQL Firewall va a estar dentro del

00:27:55.430 --> 00:28:02.430
Advanced Security y es una es un
componente carete en Oracle y me

00:28:02.430 --> 00:28:08.050
parece súper a ver, me parece razonable
que sea caro la protección que te da es muy alta

00:28:08.050 --> 00:28:15.890
lo que iba a decir de de Wasp
Top 10 el Wasp Top 10 son las 10

00:28:15.890 --> 00:28:20.310
vulnerabilidades más
comunes en aplicaciones web

00:28:21.790 --> 00:28:28.150
Así como hace yo creo que era, ojo, me
fallarán los años, pero la versión de 2017 si

00:28:28.150 --> 00:28:30.890
mal no recuerdo tenía como principal

00:28:32.430 --> 00:28:39.520
Principal problema inyecciones inyecciones
de código, especialmente inyecciones SQL hace

00:28:39.520 --> 00:28:46.820
Hace cosa de unos tres
años, una cosa así, pasó

00:28:46.820 --> 00:28:52.700
de, no sé si era la primera posición, no
sé si pasó a la quinta o a la tercera, y ahora

00:28:52.700 --> 00:28:57.940
está en la quinta. O sea, cada vez hay
menos inyecciones, cada vez es un tema menos...

00:28:57.940 --> 00:29:02.640
O sea, ha dejado de ser, digamos, el top
uno ha dejado de ser la máxima prioridad, pero

00:29:02.680 --> 00:29:04.500
sigue siendo un problema gravísimo.

00:29:04.540 --> 00:29:09.300
Te lo iba a preguntar, de eso te quería
preguntar yo, sobre el SQL Injection.

00:29:10.720 --> 00:29:13.980
¿Es tan fiero el lobo como lo pintan?

00:29:14.040 --> 00:29:18.140
¿Es tan real? ¿Es tan fácil
que nos hagan SQL Injection?

00:29:18.140 --> 00:29:25.220
A ver, es fácil. Se tienen que dar muchas

00:29:25.220 --> 00:29:27.040
cosas para que haya un SQL injection.

00:29:27.080 --> 00:29:33.660
Digamos que tienes que tener un número
razonablemente elevado de fallos.

00:29:34.260 --> 00:29:40.080
No has hecho una buena validación de la
entrada, no estás utilizando unas sentencias

00:29:40.080 --> 00:29:46.220
SQL específicas, No tienes un firewall de
base de datos, ni en la red, ni en la base

00:29:46.220 --> 00:29:52.940
de datos. Posiblemente no haces una buena
gestión de los errores, porque parte de lo

00:29:52.940 --> 00:29:58.800
que se necesita es que cuando hay un error,
al usuario le dices, ha habido un error.

00:29:58.800 --> 00:30:05.120
El desarrollador quiere saber exactamente
cuál es el error que ha habido claro pero al

00:30:05.120 --> 00:30:10.200
usuario deberías de darle tan poca
información como sea posible entonces hay una serie

00:30:10.200 --> 00:30:14.480
de cosas que se tienen que dar para que
haya una secuela inyección aún y todo se dan

00:30:14.520 --> 00:30:19.720
se siguen dando y se dan
demasiadas se dan demasiadas y

00:30:20.800 --> 00:30:26.380
bueno y parte de los problemas muchas veces
es un mal perfilado del el usuario de la

00:30:26.380 --> 00:30:33.420
aplicación la idea de que uno de
los típicos sql inyección de los

00:30:33.420 --> 00:30:40.960
viejos tiempos era hacer un drop table
dices ostras porque la aplicación puede

00:30:40.960 --> 00:30:48.000
hacer un drop table de la tabla de
usuarios o de no sé qué bueno pues porque

00:30:48.000 --> 00:30:50.900
tiene un permiso que
posiblemente no debería de tener.

00:30:50.940 --> 00:30:53.100
Entonces, ¿sigue sucediendo?

00:30:53.240 --> 00:30:56.018
Sí, sigue sucediendo y
sigue sucediendo demasiado.

00:30:56.790 --> 00:31:00.290
Madre mía, madre mía bueno,
tenemos que prepararnos un poquito.

00:31:00.590 --> 00:31:07.870
Desde la teoría, en principio si
utilizamos paquetes PSQL, utilizamos

00:31:07.870 --> 00:31:14.170
bind variables, deberíamos estar bastante
cubiertos, bastante cubiertos a que digamos,

00:31:14.390 --> 00:31:21.990
en una variable no puede ser
comilla y usuario like cualquiera

00:31:21.990 --> 00:31:27.430
uno igual a uno es decir, eso no puede ser
un valor de una variable y cuando se interpreta

00:31:27.430 --> 00:31:32.950
como una variable como hay varias
sustituciones es fuera, digamos, del contexto de compilación

00:31:32.950 --> 00:31:38.350
del código con lo cual podemos estar
tranquilos, pero no sé, pero siempre puede haber

00:31:38.350 --> 00:31:45.550
algún error con lo cual se nos cuele
ahí un un java con literales no sé A

00:31:45.550 --> 00:31:53.400
ver, la cuestión es dónde, desde el punto
de vista de gestión de la empresa, se

00:31:53.430 --> 00:31:58.070
focaliza el desarrollo y la
implementación de la lógica.

00:31:59.680 --> 00:32:06.280
La mayor parte de los DBAs con los que yo
he hablado están indignadísimos con muchas

00:32:06.280 --> 00:32:07.520
decisiones de muchas empresas.

00:32:07.560 --> 00:32:13.840
Y esas empresas lo que hacen es poner
prácticamente el 100%, no te voy a decir el 100%,

00:32:13.840 --> 00:32:19.480
pero me da igual, el 95 % de la carga del
desarrollo y de la seguridad en el desarrollo

00:32:19.480 --> 00:32:26.300
en el equipo de desarrollo que desarrolla
en lenguajes de programación, digamos, de alto

00:32:26.300 --> 00:32:28.580
nivel, totalmente desligados
de la base de datos.

00:32:28.620 --> 00:32:33.960
Un equipo de desarrollo con su
Javascript, con su Python, etc.

00:32:35.130 --> 00:32:42.470
Y estos equipos normalmente no tienen en
la cabeza un, mira, en lugar de lanzar una sentencia

00:32:42.470 --> 00:32:50.810
SQL, lo que voy a hacer es programarme un
PL dentro de la base de datos que encapsule

00:32:50.810 --> 00:32:54.254
la lógica de negocio que yo
necesito para hacer tal actividad.

00:32:55.170 --> 00:32:59.750
Normalmente como era eso del martillo de
maslow cuando lo único que tienes es un martillo

00:32:59.790 --> 00:33:04.890
todo te parece un clavo entonces si tú
tienes un equipo de desarrolladores que saben

00:33:04.890 --> 00:33:12.040
de python y algo de sql van a plantear todo
toda la solución de todos los problemas

00:33:12.040 --> 00:33:19.400
en python con lo cual vas a perder
una enorme cantidad de capacidad de

00:33:19.400 --> 00:33:26.710
securizar tu sistema que tiene la
base de datos bueno sí que bueno un

00:33:26.710 --> 00:33:34.530
ejemplo en el road level road level
security la capacidad de decidir

00:33:34.530 --> 00:33:42.190
a nivel de línea de tupla de base de datos
quien tiene acceso y quien no un cliente

00:33:42.190 --> 00:33:49.010
mío estaba encantadísimo y y estaba
Ufano diciendo, mi aplicación es segura.

00:33:49.070 --> 00:33:54.510
¿Por qué es segura? Porque yo tengo Row
Level Security, porque yo tengo definido a nivel

00:33:54.510 --> 00:33:59.770
de la propia base de datos, cuáles
son las líneas, y me parece fabuloso.

00:33:59.990 --> 00:34:03.770
Y le dije, tienes dos cosas
importantes a tener en cuenta.

00:34:03.930 --> 00:34:11.140
Primera, la autenticación de usuarios que
tienes no es buena, porque tenía ciertos problemas.

00:34:12.020 --> 00:34:16.260
Con lo cual, si la autenticación de usuario
que tienes no es buena toda la seguridad

00:34:16.300 --> 00:34:21.960
que puedas meter a nivel de base de datos
es irrelevante por decirlo de algún modo porque

00:34:21.960 --> 00:34:29.270
estás impersonando un usuario que
tiene permisos y segunda piensa muy

00:34:29.270 --> 00:34:37.010
mucho si cuando metas nuevos
desarrolladores al equipo de desarrollo van a entender La

00:34:38.130 --> 00:34:44.880
seguridad a nivel de base de datos porque
no vas a poder contratar a un tío que sepa

00:34:44.880 --> 00:34:49.940
de python vas a tener que contratar un tío
que sepa de python y se lleve muy bien con

00:34:49.940 --> 00:34:57.090
la base de datos entonces ese tipo de
cuestiones son más administrativas y son más

00:34:57.090 --> 00:35:04.180
de gestión que digamos puramente
tecnológicas en empresas En empresas grandes yo creo

00:35:04.180 --> 00:35:12.420
que se suelen hacer las cosas algo mejor
en el sentido de aplicar las bondades

00:35:12.420 --> 00:35:17.440
de ciberseguridad que te ofrece una base
de datos en condiciones tipo Oracle, pero en

00:35:17.440 --> 00:35:20.280
empresas más pequeñas hay

00:35:21.660 --> 00:35:28.750
Más equipos verdes yo sigo viendo empresas
muy grandes, con equipos de desarrollo muy

00:35:28.750 --> 00:35:33.230
grandes, que al final implementan todo el
tema de acceso desde tablas, tabla usuario,

00:35:33.270 --> 00:35:38.530
tabla contraseñas, tabla permisos, hechas
por ellos en su propio repositorio de la aplicación,

00:35:38.550 --> 00:35:42.070
programados por ellos. Entonces lo que te
encuentras es que el usuario, imagínate, la

00:35:42.110 --> 00:35:47.290
aplicación es de contabilidad, usuario,
propietario, contabilidad, contraseña, contabilidad.

00:35:47.770 --> 00:35:53.310
Todas las políticas de password están en
la lógica de la aplicación, pero luego alguien

00:35:53.310 --> 00:35:56.870
que entra a la base de datos y
hace un export dice, ¿qué usuario?

00:35:56.910 --> 00:36:02.630
Contabilidad, export full, me lo llevo
todo y decir, ostras, pues has puesto una barrera

00:36:02.630 --> 00:36:08.890
tremenda y justo detrás
has abierto la autopista.

00:36:09.370 --> 00:36:11.970
Por donde pasan sin
ningún tipo de peaje, ¿no?

00:36:12.550 --> 00:36:19.730
Y sobre el tema este que comentas, justo
de las contraseñas, Oracle en su momento

00:36:19.730 --> 00:36:25.570
tenía el cifrado de, o sea, sí, tenía el
cifrado de las contraseñas de usuarios de base

00:36:25.570 --> 00:36:30.930
de datos con algoritmo DES, que se
considera no seguro, con lo cual está feo utilizar,

00:36:31.210 --> 00:36:33.950
no sé si era 10G o no
sé cuál era la versión.

00:36:33.950 --> 00:36:36.690
Pero hay versiones antiguas
que no se deben de utilizar.

00:36:36.730 --> 00:36:44.570
Estupendo pasamos a versiones más nuevas
que utilizan SHA -1 y SHA -512, que son algoritmos

00:36:44.570 --> 00:36:51.910
de hashing mucho más robustos y a
día de Hoy se consideran seguros.

00:36:53.060 --> 00:37:00.410
Pero la cuestión es, si no los utilizas
de manera adecuada, vas a hacer un pan con

00:37:00.410 --> 00:37:07.450
unas hostias. Si tú tienes la contraseña
de la aplicación o la contraseña

00:37:07.450 --> 00:37:13.070
de un usuario de la aplicación cifrado con
un algoritmo de estos y no tienes ningún elemento

00:37:13.070 --> 00:37:20.370
adicional, ahí, perdón, dame un
segundo, ¿sabemos lo que es un algoritmo

00:37:20.370 --> 00:37:26.630
hash? Sí, sí, sí, aquí más o menos,
aquí estamos puestos en estas cosas, sí.

00:37:26.630 --> 00:37:31.530
Perfecto, perfecto cuando tú haces un hash,
esa es una operación de un solo sentido.

00:37:31.590 --> 00:37:37.310
En principio, no puedes deshacer un hash,
no puedes a partir del hash saber que la contraseña

00:37:37.310 --> 00:37:45.450
es Pepito Pérez. Pero, si tú
utilizas un algoritmo estándar,

00:37:45.450 --> 00:37:52.820
tipo SHA1, digamos con una configuración
por defecto, tú puedes ponerte

00:37:52.820 --> 00:38:01.070
a hacer los hashes de Pepito
Pérez, password 123, 123456,

00:38:01.270 --> 00:38:02.830
digamos contraseñas habituales.

00:38:02.870 --> 00:38:09.550
Entonces, creas una tabla de hashes y luego
cuando recibes una base de datos con los

00:38:09.550 --> 00:38:14.030
hashes de las contraseñas, puedes
hacer una búsqueda inversa.

00:38:14.510 --> 00:38:17.910
Es lo que se llaman las rainbow
tables, las tablas arcoiris.

00:38:17.910 --> 00:38:25.510
Entonces, hay ciertos ataques que si no
tienes cuidado a la hora de cifrar las contraseñas,

00:38:25.590 --> 00:38:30.570
las puedes liar. ¿Más formas
de liarla con contraseñas?

00:38:31.570 --> 00:38:38.840
La contraseña es robusta, está bien
almacenada, pero está en el código fuente

00:38:38.840 --> 00:38:44.240
de la aplicación. Ni te
imaginas lo habitual que es.

00:38:44.240 --> 00:38:51.310
Sí, Y hardcodeada o está en

00:38:51.310 --> 00:38:59.210
la aplicación o está en un repositorio
público o hay una piquí perdida

00:38:59.210 --> 00:39:06.410
de la mano de Dios que termina en GitHub
y hubo gran regocijo, como decían en la

00:39:06.410 --> 00:39:13.800
de Monty Python gran parte
del problema dime, dime De

00:39:13.800 --> 00:39:17.240
esto de las pasos quería decir otra cosa,
de las pasos para que nadie se asuste con versión

00:39:17.280 --> 00:39:24.860
10 y algo así, es que eso es cuando
tú migras un entorno de 8, 9, 10,

00:39:24.980 --> 00:39:30.660
se ha migrado esa base de datos, se ha
hecho un grade de la base de datos, te sigue conservando

00:39:30.660 --> 00:39:32.560
las pasos, no te las modifica.

00:39:32.920 --> 00:39:37.060
Entonces, si puedes tener un sistema a lo
mejor que ha evolucionado de una versión 9

00:39:37.100 --> 00:39:41.760
a una versión 10 y te dice, estos usuarios
se crearon en versión 10, si la contraseña

00:39:41.800 --> 00:39:45.680
no ha cambiado, sigue estando en versión
10, es decir tú no tienes forma, lo digo para

00:39:45.720 --> 00:39:49.820
los demás, es decir, no tenemos un problema
nosotros ahora de que alguien nos vaya a

00:39:49.860 --> 00:39:53.000
crear una password en versión 10, no

00:39:54.480 --> 00:39:58.400
Debería estar permitido, las passwords
nuevas que se crean son siempre en la versión

00:39:58.440 --> 00:40:01.900
nueva, pero ese sería
por dar la pista, ¿vale?

00:40:02.300 --> 00:40:06.840
Si nos encontramos una salida así en DBSAT
o algo así, hay que ver esos usuarios que

00:40:06.880 --> 00:40:12.840
vienen a lo mejor digamos de épocas anteriores
en las que la base de datos estaba en

00:40:12.840 --> 00:40:19.240
versiones anteriores. Si una aplicación ha
ido evolucionando de 9, 10, 11, es muy probable

00:40:19.240 --> 00:40:23.180
que a lo mejor la contraseña, si no se ha
actualizado, esté aún en el formato con la

00:40:23.220 --> 00:40:26.140
codificación DES, en el formato antiguo.

00:40:26.260 --> 00:40:30.440
Eso sería un pequeño disclaimer,
no decir que nadie se asuste.

00:40:30.620 --> 00:40:33.080
Vais a buscar ahí, alguien
me puede cambiar eso.

00:40:33.120 --> 00:40:38.920
Ahora no, si las cambian no van a poder
ponerse la versión antigua, pero sí sería investigar

00:40:38.920 --> 00:40:44.180
aquellos restos de usuarios que nos hace
muchísimo tiempo, que puedan tener la contraseña

00:40:46.020 --> 00:40:51.760
Paleolítica, digamos.
Pues, oye, muy interesante.

00:40:52.000 --> 00:40:55.240
Hoy te voy a decir que, mira, en Oracle,
no sé si sabes, en Oracle, por ejemplo, el tema

00:40:55.280 --> 00:41:01.100
de las contraseñas, de las passwords,
hay un PL que es el que es para cada...

00:41:01.100 --> 00:41:03.433
Tú puedes definir para perfiles de usuario

00:41:04.400 --> 00:41:06.980
Qué función de verificación
de passwords tiene.

00:41:07.020 --> 00:41:09.353
Hay una que es la por defecto, que te deja

00:41:10.100 --> 00:41:12.080
modificarla, pero tú puedes
crearte la tuya propia.

00:41:12.120 --> 00:41:17.060
Si tú puedes crear un PL y decir, oye, yo
quiero implementar mis propias reglas, no quiero

00:41:17.100 --> 00:41:21.620
que se utilicen ciertas palabras de
diccionario que aquí son comunes, no queremos que

00:41:21.660 --> 00:41:25.240
se utilicen fórmulas o lo que sea.

00:41:25.320 --> 00:41:30.340
Es decir, tú puedes implementarte eso muy
a mano, aunque Oracle te dice que sepas que

00:41:30.340 --> 00:41:36.900
la propia política estándar de
verificación de passwords de la que La que te viene ya

00:41:36.900 --> 00:41:39.120
por el fabricante es bastante fuerte.

00:41:39.640 --> 00:41:44.880
¿Tú conoces otras aplicaciones, otros
entornos donde el nivel de seguridad sea así?

00:41:44.920 --> 00:41:51.840
Es decir, defínete tu propia política de
verificación de passwords, como lo tiene, digamos,

00:41:51.900 --> 00:41:56.060
Oracle. ¿Es algo común o
estamos exagerando aquí un poco?

00:41:57.140 --> 00:42:03.080
A nivel de empresa tiene que haber una
política de contraseña si se toma la ciberseguridad

00:42:03.080 --> 00:42:08.380
mínimamente en serio. Pero
es a nivel de compañía.

00:42:10.790 --> 00:42:15.490
Cuestiones típicas de la política de
contraseña, si ahora me lo llevo a la base de datos.

00:42:15.530 --> 00:42:17.390
Longitud mínima de la contraseña.

00:42:17.450 --> 00:42:20.839
En algunos casos longitud máxima
también tiene mucho sentido.

00:42:22.340 --> 00:42:29.460
Número de mayúsculas, minúsculas,
símbolos de puntuación, emojis, kanjis,

00:42:29.700 --> 00:42:33.300
sangre de unicornio,
todo ese tipo de cosas.

00:42:33.300 --> 00:42:39.120
Importantísimo, sí las contraseñas
se hacen más seguras por longitud.

00:42:39.560 --> 00:42:47.160
El aumento de seguridad por longitud de
la contraseña es muchísimo más razonable

00:42:47.160 --> 00:42:53.580
y además mucho más fácil de recordar que
el aumento de complejidad por distintos tipos

00:42:53.580 --> 00:43:00.840
de caracteres, que es algo
que mucha gente se pasa

00:43:00.840 --> 00:43:05.500
por alto. Entonces decía, política
de tamaño de contraseña, etc.

00:43:05.680 --> 00:43:07.291
Si hace falta cambiarla o no.

00:43:07.440 --> 00:43:12.380
Las últimas recomendaciones de NIS, las
últimas recomendaciones, vamos a decir, de los

00:43:12.380 --> 00:43:18.000
que saben de seguridad, son a menos que
tengas la sensación de que la contraseña ha sido

00:43:18.000 --> 00:43:21.660
comprometida, no hace falta que
la cambies de manera periódica.

00:43:21.660 --> 00:43:27.240
Sobre todo porque descubrieron que los
usuarios al final ponían la misma contraseña pero

00:43:27.240 --> 00:43:32.280
ponían el número del mes al final y cuando
no le dejaban eso lo ponían al principio y

00:43:32.280 --> 00:43:37.940
cuando no le dejaban eso hacían mil
triquiñuelas hasta que al final se salían con la

00:43:37.940 --> 00:43:44.600
suya y seguían teniendo con perdón una
contraseña de mierda entonces la política de contraseñas

00:43:44.600 --> 00:43:51.440
tiene que estar definida a nivel de a
nivel de empresa la política de cifrado preferiblemente

00:43:51.440 --> 00:43:57.520
también y cuando te llevas eso a base de
datos termina siendo algo así como las contraseñas

00:43:57.520 --> 00:44:04.720
Se cifran así se utiliza un algoritmo
de hash algoritmos permitidos sh1 sh a

00:44:04.720 --> 00:44:11.780
512 si una lista de algoritmos permitidos
las contraseñas no se almacenan tal

00:44:11.780 --> 00:44:18.200
cual se les pone un salt vale el salt digamos
por simplificarlo es, si la contraseña

00:44:18.200 --> 00:44:25.840
es password123, le pones al principio
mi contraseña bonita password123.

00:44:26.450 --> 00:44:32.540
De esa manera, cuando pones ese mi
contraseña bonita, es muy poco probable que alguien

00:44:32.540 --> 00:44:40.060
se haya dedicado a hacer hashes de
contraseñas que tengan al principio el string mi contraseña

00:44:40.060 --> 00:44:47.470
bonita. Preferiblemente, además de
añadir la contraseña y esa salt, está

00:44:47.470 --> 00:44:49.830
muy bien añadir el usuario ¿Por qué?

00:44:50.170 --> 00:44:57.250
Porque de esa manera, dos usuarios
distintos que tengan la misma contraseña van

00:44:57.250 --> 00:45:00.750
a tener el hash de la contraseña distinto

00:45:01.770 --> 00:45:06.610
Pues fíjate, aquí te voy a decir una cosa,
en la política de verificación de contraseñas

00:45:06.650 --> 00:45:10.230
la contraseña no puede contener
el nombre de usuario en ella

00:45:11.840 --> 00:45:16.480
No, no, no la contraseña no va a
contener el nombre del usuario.

00:45:16.620 --> 00:45:21.860
O sea, si mi usuario es Javier, la contraseña
no puede ser mi contraseña bonita hash

00:45:21.860 --> 00:45:29.280
$ $37 Javier 2037. Sí, pero no puede

00:45:29.280 --> 00:45:31.880
figurar la cadena Javier
dentro de la contraseña.

00:45:31.920 --> 00:45:33.740
Sí, pero yo no estoy hablando de...

00:45:33.780 --> 00:45:36.920
O sea, la contraseña será
algo que tenga sentido.

00:45:37.780 --> 00:45:40.660
Voy a decir password 123, que
es una muy mala contraseña.

00:45:40.700 --> 00:45:47.260
Es la contraseña lo que me refiero con mi
contraseña bonita password123 es el string

00:45:47.260 --> 00:45:48.880
que nosotros vamos a jasear.

00:45:49.040 --> 00:45:52.740
Ah, vale, vale, claro en
aplicación estamos hablando.

00:45:53.820 --> 00:46:00.260
En lugar de jasear password123, vamos a
jasear Javier, mi contraseña bonita password123.

00:46:01.400 --> 00:46:04.780
¿Vale? Vale, vale, vale
¿Cuáles son las contraseñas?

00:46:04.880 --> 00:46:10.860
Dime, dime no, que quiero decir, esto es
cuando estamos delegando la seguridad En aplicación,

00:46:10.880 --> 00:46:17.100
porque en Oracle no tienes forma de
alterar esa, distorsionar, digamos, la password para

00:46:17.100 --> 00:46:19.260
que se almacene con más texto.

00:46:20.360 --> 00:46:26.600
Para los usuarios de base de datos no,
pero tiene mucho sentido tener PLs cuando se establece

00:46:26.600 --> 00:46:28.933
la contraseña de un usuario de aplicación.

00:46:29.450 --> 00:46:32.490
Sí, exacto ahí sí, es lo que te decía.

00:46:32.490 --> 00:46:36.210
Y ahí es el punto donde todo
esto puede tener sentido.

00:46:36.490 --> 00:46:43.250
Y añadir cosas como lo mismo que dices que
hace Oracle, no puede tener más de no sé cuántos

00:46:43.250 --> 00:46:50.130
caracteres seguidos del identificador de
Usuario no puede tener más de no sé cuántos

00:46:50.130 --> 00:46:54.630
caracteres seguidos de el
nombre de la persona, ¿vale?

00:46:54.790 --> 00:47:02.190
Imagínate, yo me llamo Borja Rooks, el
identificador de usuario es B .Rooks, la

00:47:02.190 --> 00:47:07.560
contraseña no puede tener
en ningún caso ORJA, ¿vale?

00:47:07.560 --> 00:47:14.830
Y si le quieres dar una vuelta más, en
lugar de almacenar el hash, puedes almacenar

00:47:14.830 --> 00:47:19.420
el hash del hash del hash, para ponerlo
incluso un poquito más complicado.

00:47:20.500 --> 00:47:22.111
Muy buena esa, muy buena esa.

00:47:22.440 --> 00:47:29.240
Voy a hacer una cosa borja, por los que no
lo conozcan, tiene una newsletter buenísima.

00:47:29.380 --> 00:47:34.440
Todos los días manda un consejo de
ciberseguridad muy útil, muy cachondo.

00:47:34.440 --> 00:47:41.500
A veces cuando lo lees se te clava una
espinita porque dices, ay, que yo esto

00:47:41.500 --> 00:47:49.320
lo he vivido. Y si os queréis dar de alta
en su newsletter, borjaroaks .com, y ahí

00:47:49.320 --> 00:47:56.560
vais a recibir unos tips de ciberseguridad
y podéis contactar con él porque ya veis

00:47:56.560 --> 00:48:03.600
que no solo es lo que sabe, sino que cómodo
y que fácil es comentar contigo todos

00:48:03.600 --> 00:48:07.360
estos temas. Eres el
auditor amable bueno, o no.

00:48:09.680 --> 00:48:14.680
Eres el auditor amable
con gente que lo intenta.

00:48:16.680 --> 00:48:23.780
Sí, sí, sí a ver, reconozco que este es un
sesgo, no te voy a decir que sea maravilloso,

00:48:23.820 --> 00:48:25.100
pero es algo que a mí me pasa mucho.

00:48:25.140 --> 00:48:34.300
Cuando yo trabajo con una empresa
que intenta hacer las cosas bien, soy

00:48:34.300 --> 00:48:40.800
mucho más amable. Habrá muchas cosas que
haya que modificar, pero desde un tono mucho

00:48:40.800 --> 00:48:44.580
más, vamos a decir, agradable conciliador.

00:48:44.580 --> 00:48:50.720
En el momento en el que detectó que una
empresa no está buscando la seguridad sino el

00:48:50.720 --> 00:48:58.020
cumplimiento normativo bueno pues
juego al juego del cumplimiento

00:48:58.020 --> 00:49:05.140
normativo y claro de esto estoy
una un tip que dijiste en una en

00:49:05.140 --> 00:49:11.080
un mail que me gustó mucho que era en la
mínima que veas que que algo no está acorde

00:49:11.080 --> 00:49:18.220
con tu concepto seguro, no te sientes
seguro, redacta una carta y di, a partir

00:49:18.220 --> 00:49:25.440
de ahora, si no se implementa esta política,
yo me eximo de total responsabilidad

00:49:25.440 --> 00:49:32.560
de cualquier cosa. Es decir, y decirle
a la persona, mírame a los ojitos y

00:49:32.560 --> 00:49:37.420
fírmame esto. Mírame a los ojos y fírmame
que si no vamos a poner este nivel de seguridad

00:49:37.460 --> 00:49:40.640
o esto y tal. El responsable
no voy a ser yo, vas a ser tú.

00:49:40.680 --> 00:49:42.680
No, mírame a los ojillos y dime qué.

00:49:43.660 --> 00:49:49.800
Eso yo lo he visto también a nivel de base
de datos, por ejemplo, en cuestiones de parches.

00:49:51.820 --> 00:49:55.800
El administrador de base de datos es
consciente de que la versión de base de datos que

00:49:55.840 --> 00:50:03.010
tienen tiene una serie de agujeros
de seguridad importantes y no tiene

00:50:03.010 --> 00:50:07.510
permiso para hacer las migraciones, o no
tiene permiso para hacer los mantenimientos,

00:50:07.550 --> 00:50:12.970
porque el negocio ha decidido que no se
pueden hacer intervenciones o por la razón que

00:50:12.970 --> 00:50:18.510
sea. Coge el administrador de base de
datos, que es el equivalente a lo que hago yo con

00:50:18.510 --> 00:50:20.899
mis clientes como
responsable de seguridad.

00:50:21.410 --> 00:50:24.810
Coge el administrador de base de datos y
dice, mira, es muy sencillo, yo te estoy diciendo

00:50:24.850 --> 00:50:29.750
que hay que hacer esto. Si tú me dices que
no, me miras a los ojos, me dices que no,

00:50:29.750 --> 00:50:31.870
lo ponemos por escrito y ya está.

00:50:31.950 --> 00:50:38.950
No me enfado no voy a
discutir una decisión de

00:50:38.950 --> 00:50:46.030
negocio porque creo que si queremos que la
ciberseguridad se tome en serio, se tiene

00:50:46.030 --> 00:50:47.490
que tomar como decisión de negocio.

00:50:47.530 --> 00:50:52.430
Si queremos que se tome como decisión de
negocio, negocio decide qué riesgos tomar y

00:50:52.430 --> 00:50:58.770
qué riesgos evitar. Y si decide tomar el
riesgo de esta base de datos lleva sin actualizarse

00:50:58.770 --> 00:51:01.850
desde que Franco era corneta, así es.

00:51:01.850 --> 00:51:09.070
O sea, si entiende cuáles son los riesgos,
mi punto de vista como profesional

00:51:09.070 --> 00:51:14.070
de ciberseguridad es, si entiendes cuáles
son los riesgos, no me parece mal realizar

00:51:14.070 --> 00:51:19.440
este tipo de acciones, este tipo de,
vamos a decir, falta de acciones.

00:51:20.380 --> 00:51:24.920
Lo que dices de mirarnos a los ojitos es,
hablas con alguien que realmente pueda tomar

00:51:24.960 --> 00:51:28.960
la decisión y te aseguras de que esa
decisión es una decisión explícita.

00:51:30.310 --> 00:51:37.550
Sí, sí, sí pues oye, tu newsletter,
lo vuelvo a decir, borjaroaks .com y

00:51:37.550 --> 00:51:43.590
que se apunten a ese. Lo que me suele
decir mucha gente de la newsletter es que, sobre

00:51:43.590 --> 00:51:45.701
todo, me leen porque se lo pasan bien.

00:51:45.940 --> 00:51:49.920
O sea, en algún caso he estado tentado de
decir, oye, pero no lo lees porque aprendes

00:51:49.960 --> 00:51:52.940
mucho de ciberseguridad y
dice, bueno, eso también.

00:52:00.520 --> 00:52:07.700
Oye, tengo más cosas que preguntarte
Mira Oracle ha sacado para la versión 26,

00:52:08.080 --> 00:52:13.700
23 pero ahora han renombrado 26 por un
tema de rebranding y tal ha sacado un rol developer

00:52:13.700 --> 00:52:21.180
por el tema de que en desarrollo, en
Oracle supongo que te habrás encontrado,

00:52:21.280 --> 00:52:28.820
como se Se utiliza la regla del
mínimo privilegio, es decir, creas

00:52:28.820 --> 00:52:34.220
un usuario y el usuario se no puede ni
hacer, créate sesión, todo lo tienes que dar de

00:52:34.220 --> 00:52:39.360
forma explícita. Pues en todos los
desarrollos se suele regalar mucho el DBA.

00:52:39.580 --> 00:52:45.980
Pues oye, mira, los usuarios en desarrollo
son DBAs y muchas veces estas cosas terminan

00:52:45.980 --> 00:52:50.380
acabando en producción. No ahora que se ha
sacado el rol de velo pero que en principio

00:52:50.420 --> 00:52:54.540
es cuando a los desarrolladores puedes dar
el rol de velo pero y pueden hacer todo lo

00:52:54.580 --> 00:52:58.080
que puedo hacer un de velo pero no te quiero
preguntar un par de cosas vamos a decir

00:52:58.120 --> 00:53:04.960
tú tú cómo crees que va a acabar eso
cuando se pase en producción cuando se produce van

00:53:04.960 --> 00:53:09.780
a colarse roles de velo pero en producción
también y yo te pregunta cómo ves el tema

00:53:09.780 --> 00:53:15.020
de estandarizar de que el fabricante
estandarice roles en plan decir vamos a crear un

00:53:15.020 --> 00:53:21.480
rol application y en producción se dará en
vez del rol de velo pero se dará el rol application

00:53:21.480 --> 00:53:26.680
así como hay un rol de vea evidentemente
que puedes hacerlo todo como ves está estandarizado

00:53:26.680 --> 00:53:32.900
Y es posible o al final siempre hay que
hilar fino y ver qué se está dando y que no y

00:53:32.900 --> 00:53:38.900
hay que personalizar lo conoces a ver voy
voy por partes primero lo que dice es de que

00:53:38.900 --> 00:53:45.760
se cuelen permisos de desarrollo en
producción eso va a suceder eso va a suceder mientras

00:53:45.760 --> 00:53:54.680
no nos lo tomemos en serio vale porque
normal lo habito lo más habitual es que pensemos

00:53:54.900 --> 00:54:02.260
en producción como lo que tenemos en
desarrollo termina en producción bueno o no habrá

00:54:02.260 --> 00:54:05.460
que ver ver cómo evoluciona.

00:54:05.580 --> 00:54:11.320
Pero si no hay cuidado, sí, cualquier
mierda que hayamos hecho en desarrollo terminará

00:54:11.320 --> 00:54:17.260
en producción, incluyendo cualquier
aberración en desarrollo o cualquier aberración en

00:54:17.260 --> 00:54:19.280
base de datos o en donde sea.

00:54:20.380 --> 00:54:27.500
Sobre si Oracle es capaz de definir
un perfil para un desarrollador

00:54:27.500 --> 00:54:34.260
con mucho cariño y mucho respeto si yo no
sé que necesitan mis desarrolladores que puñetas

00:54:34.260 --> 00:54:41.280
lo vas a ver oracle vale que oracle
me ofrezca de manera out of the

00:54:41.280 --> 00:54:48.840
box muy sencillita un perfil que
es más que nada y menos que admin

00:54:48.840 --> 00:54:55.890
oye bienvenido sea eso será
suficiente seguramente será suficiente

00:54:55.890 --> 00:55:02.900
pero seguramente no será necesario vale
seguramente mi sensación es que se va

00:55:02.900 --> 00:55:08.000
a pasar de permisos no se va a pasar tanto
como un como un administrador de base de datos

00:55:08.000 --> 00:55:14.140
pero sí que se va a pasar de los permisos
que necesite el desarrollador De turno oracle

00:55:14.140 --> 00:55:20.720
va a ser capaz de definir perfiles para
aplicaciones etcétera pues te respondo lo mismo

00:55:20.720 --> 00:55:26.040
si yo no sé qué permisos va a necesitar mi
aplicación que puñetas lo vas a ver oracle

00:55:27.680 --> 00:55:30.140
Que partiendo de lo que oracle me de como

00:55:31.760 --> 00:55:38.120
Aplicación típica yo puedo pasar a mi
aplicación tuneando a partir de ahí y añadiendo

00:55:38.120 --> 00:55:43.980
cuatro cosas y quitando cuatro cosas
seguro que es una muy buena ayuda pero igual que

00:55:43.980 --> 00:55:49.160
lo que decimos es una forma de empezar un
poquito es una forma de decir mira tienes ahí

00:55:49.160 --> 00:55:56.060
un he puesto ahí en el chat digamos que es
lo que que incluye el rol de developer, tiene

00:55:56.060 --> 00:56:02.460
crear vistas analíticas, crear attribute
dimensions, cubos, dimensiones, jerarquías,

00:56:02.520 --> 00:56:06.700
jobs, vistas materializadas,
procedimientos, secuencias, sesiones, sinónimos, tablas,

00:56:06.740 --> 00:56:12.040
triggers, tips. Es decir, sobre todo son
cosas de create, más que nada, de poder crear

00:56:12.040 --> 00:56:19.190
triggers y tablas y seguimientos
y temas de data warehouse y

00:56:19.190 --> 00:56:23.590
tal. Y force transaction y
on commit refresh, cosas así.

00:56:23.890 --> 00:56:26.350
Es una forma, digamos, de decir...

00:56:26.350 --> 00:56:31.690
Me parece una aproximación muy adecuada,
pero acuérdate del desarrollador del que te

00:56:31.690 --> 00:56:38.830
hablaba antes que se ponía a hacer
modificaciones en la seguridad a nivel de tupla.

00:56:40.660 --> 00:56:45.140
Pues muy probablemente Oracle no cuenta
con que un desarrollador se va a poner a hacer

00:56:45.180 --> 00:56:50.040
eso. Entonces, ¿será un
buen punto de partida?

00:56:50.080 --> 00:56:54.920
Seguro que sí pero si no se le dedica
cariño, no va a ser suficiente.

00:56:56.860 --> 00:57:01.760
Será mejor que todos los desarrolladores
tengan permisos de administración en producción.

00:57:01.800 --> 00:57:04.420
¿Vale? Sí o sea, mejor que eso va a ser.

00:57:04.780 --> 00:57:07.480
Seguro más que nada
porque no puede ser mucho.

00:57:08.640 --> 00:57:14.100
Sí, por lo menos lo que veo es
que no tiene el select any, ¿no?

00:57:14.300 --> 00:57:18.260
Los privilegios de any, muchos
de ellos son los peligrosos, ¿no?

00:57:18.280 --> 00:57:25.400
De select any table, create any table,
alter any table, que son los que dices, no, puede

00:57:25.400 --> 00:57:29.780
también de su usuario y de otros, de
otros puede ser incluso de sys, ¿no?

00:57:30.020 --> 00:57:34.060
Esos son los peligrosos quizá
es un rol contenidito, ¿no?

00:57:34.120 --> 00:57:36.780
Es a lo mejor muy peligroso, pero bueno.

00:57:36.780 --> 00:57:43.820
Y creo que es bueno, creo que es muy bueno
que haya un punto de partida que no sea

00:57:43.820 --> 00:57:48.860
ni todo ni nada. Pero
hay que darle cariño.

00:57:49.280 --> 00:57:52.640
Hacer estas cosas sin darle cariño
creo que puede ser un problema.

00:57:52.680 --> 00:57:59.940
Y en general el perfil de desarrollador
que termine en producción no lo

00:57:59.940 --> 00:58:05.680
veo como algo razonable al menos no
en la mayor parte de los casos porque

00:58:08.120 --> 00:58:12.820
El desarrollador debería de poder hacer lo
que quiera que pueda hacer en desarrollo no

00:58:12.860 --> 00:58:20.070
en producción claro que es donde
las cosas se se rompen, ahí

00:58:20.070 --> 00:58:22.550
hay impacto en dinero, ¿no?

00:58:22.690 --> 00:58:29.780
Sí. Pues, oye, no sé si se te ha hecho
corto o se te ha hecho largo, pero casi nos hemos

00:58:29.780 --> 00:58:31.280
estampado una hora ya, ¿eh?

00:58:32.120 --> 00:58:39.250
Cortito, ¿verdad? Pues, Si quieres
añadir algo más, algo que dices,

00:58:39.310 --> 00:58:42.421
oye, venga, ahora que tengo
gente aquí de base de datos,

00:58:43.760 --> 00:58:46.340
Consejito, una cosa que os
quiero decir, o un algo.

00:58:46.380 --> 00:58:53.380
Un consejo para La gente de base de datos
Sobre todo los que más se preocupan por

00:58:53.380 --> 00:58:57.320
la ciberseguridad, que en mi
experiencia tienden a sufrir bastante.

00:58:59.740 --> 00:59:07.260
Buscad el punto en el que las recomendaciones
que hacéis sean entendidas, que cuando

00:59:07.260 --> 00:59:12.500
vosotros digáis, oye, deberíamos de hacer
esto, entiendan por qué lo estáis diciendo,

00:59:12.500 --> 00:59:19.500
Pero no os llevéis a nivel
personal el que alguien tome la

00:59:19.500 --> 00:59:26.460
decisión, preferiblemente por escrito,
tome la decisión de no seguir vuestra recomendación.

00:59:26.910 --> 00:59:34.670
Porque conozco mucha gente que se ha
quemado, yo entre ellos, porque mis recomendaciones

00:59:34.670 --> 00:59:37.010
de ciberseguridad eran desoídas.

00:59:41.270 --> 00:59:45.570
Que te juegas el tipo es
decir yo a veces si he dicho

00:59:46.810 --> 00:59:50.490
Si no implementamos una política de
backup, yo no sigo jugando aquí, yo no quiero pasar

00:59:50.530 --> 00:59:56.510
a la historia como el de vea al que se le
quedó la base de datos en las manos y no pudo

00:59:56.510 --> 01:00:02.410
recuperar porque no tuvo backup si, si,
si, a ver, yo he ido de sitios o sea, yo he dejado

01:00:02.410 --> 01:00:06.670
de trabajar con clientes por cuestiones de
ese tipo o sea, hay un punto en el que dices

01:00:06.710 --> 01:00:12.450
el negocio quiere admitir estos riesgos
estupendo yo no quiero trabajar en una empresa

01:00:12.450 --> 01:00:17.410
que admite estos riesgos pero son para mí
son dos cuestiones distintas o sea obviamente

01:00:17.410 --> 01:00:23.470
una empresa que no quiere hacer backups
estupendo me parece genial yo no quiero trabajar

01:00:23.470 --> 01:00:32.050
con una empresa así Totalmente entendible

01:00:32.590 --> 01:00:37.050
cuando el tipo es que mira yo digo muchas
veces es que pasa que a nosotros en base de

01:00:37.090 --> 01:00:43.650
datos nos Nos viene un director de negocio
y nos dice, yo asumo la responsabilidad de

01:00:43.650 --> 01:00:45.150
que tú ahora pares la base de datos.

01:00:45.190 --> 01:00:49.470
Y eso qué significa, que si paro la base
de datos y no arranca, que voy a estar aquí

01:00:49.510 --> 01:00:53.121
hasta que arranque. Pues vaya
forma de asumir la responsabilidad.

01:00:53.750 --> 01:00:59.470
Al final, quizá a lo mejor somos un poco
vehementes, lo que acabas de decir y me identifico,

01:00:59.490 --> 01:01:03.090
somos muy vehementes en
decir, es mi base de datos.

01:01:04.570 --> 01:01:10.480
Por favor, debes poder cuidar la
seguridad, porque mi honra está en juego.

01:01:11.060 --> 01:01:17.380
Pero sí es cierto, a veces nos jugamos el
careto, nos ponemos de skin in the game.

01:01:18.840 --> 01:01:24.820
Y cuando viene un director y dice yo asumo
la responsabilidad se le responde con un en

01:01:24.820 --> 01:01:31.980
la línea de puntos Firmas en la línea
de puntos Y tanto, y tanto Pues oye,

01:01:32.000 --> 01:01:35.611
es que en la línea de puntos no
está asumiendo la responsabilidad

01:01:36.440 --> 01:01:41.380
Totalmente Totalmente, totalmente Pues
oye Borja, nos hemos tampado la hora

01:01:42.500 --> 01:01:45.940
y ha sido un placer, a mí también se me
ha hecho cortísimo ¿Qué tal has estado?

01:01:45.980 --> 01:01:50.280
¿Has estado cómodo? Me ha pasado
estupendamente me lo he pasado muy bien yo estoy hablando

01:01:50.320 --> 01:01:57.100
de estas cosas más que encantado que bien,
pues nada, si te parece dejamos el podcast

01:01:57.100 --> 01:02:02.240
aquí, nos despedimos de la gente por no
esternos un poquito de la hora, muchas gracias

01:02:02.240 --> 01:02:09.920
a todos y cuando quieras hacemos otra
segunda ronda seguro que sí, seguro que sí cuídate

01:02:09.920 --> 01:02:13.020
mucho, un abrazo vale,
muchas gracias, chao