YT YouTube2Text

YouTube2Text → Transcripts → Que tu App Funcione NO Significa que Sea Segura (Apps con IA + Supabase)

Que tu App Funcione NO Significa que Sea Segura (Apps con IA + Supabase) — Transcript

by VademecumIA · 2,574 words · 406 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00Hoy en la era de los agentes de la
0:02inteligencia artificial, cualquiera hace
0:04una aplicación. Sí, cualquiera hace una
0:06aplicación, la sube a una web, trabaja
0:09con su pabase. El tema es la seguridad.
0:13Ese es el tema, porque sí, cualquiera
0:16puede hacer una aplicación, pero lo que
0:19tenemos que también saber hacer es que
0:21esa aplicación sea segura. En este video
0:24vamos a hablar de la seguridad en
0:26nuestras aplicaciones, porque cuando ya
0:29nuestra aplicación está en producción,
0:30es decir, estamos recibiendo mensajes de
0:33clientes, datos de clientes, correos de
0:35clientes, número de teléfono de
0:37clientes, de personas reales, datos
0:40reales de personas reales, necesitamos
0:43garantizar la seguridad de esos datos.
0:45Esto no es menor. Hay una normativa de
0:48que los datos se deben garantizar y que
0:50la responsabilidad de garantizar esos
0:52datos es del dueño de la aplicación.
0:54Entonces, esto es un punto no menor.
0:57Cuando creamos una aplicación, tenemos
0:59que garantizar que esa aplicación sea
1:01segura. Ahora, ¿cómo garantizamos?
1:04No hay una aplicación cero riesgo, eso
1:07no existe, pero sí podemos minimizar los
1:10riesgos de ataque, sí podemos tratar de
1:14cerrar todas las ventanas y de poner
1:16candado a todas las puertas que se
1:18pueden abrir, no significa que alguien
1:20no lo pueda romper a ese candado, pero
1:22por lo menos nosotros garantizamos en
1:24poner los candados a todas las ventanas
1:27y por otro lado hacer backup de nuestra
1:29información, ¿sí? poder tener una un
1:33backup de todos los datos que nosotros
1:34vamos cargando. Y yo entiendo que vos me
1:37digas, Lore, yo no sé nada de
1:39ciberseguridad, yo no sé nada de
1:41programación. Primero te invito a que
1:43mires el video, que entiendas los puntos
1:45claves que necesitas para poder hacer tu
1:48aplicación segura y luego yo te voy a
1:51dejar el prometo para que vos puedas
1:54utilizar ese prom y pedirle a la
1:56inteligencia artificial que te haga
1:57todas las pruebas necesarias a tu
1:59aplicación que te la construyo. Además,
2:02te voy a dejar una skill para que
2:05también puedas activar esa skill en
2:07Cloud Code, en CHGPT, en la inteligencia
2:10artificial que trabajes. Te voy a dejar
2:11esa skill para que la llames a esa skill
2:14y le digas que someta tu aplicación a
2:17las pruebas necesarias para que sea una
2:19aplicación segura. Vamos al video.
2:22Entonces, en el video primero entendemos
2:23de qué se trata e todo esto, de la
2:26seguridad de tu aplicación y luego te
2:28doy las herramientas necesarias para que
2:30vos puedas realmente tener una
2:32aplicación segura. Primero tenemos que
2:34definir qué es lo que vamos a proteger,
2:38que ver se los tenemos que proteger. Por
2:40ejemplo, tenemos que proteger
2:42documentos, tenemos que proteger los
2:44datos, los chat de las conversaciones,
2:46tenemos que proteger las claves, las
2:49credenciales, los clientes. Entonces,
2:52hay acá un punto que es fundamental.
2:54Primero, si no es necesario, no se
2:58recolecta. Esa es la primer ley. Si yo
3:00no necesito DNI o no necesito datos
3:04sensibles de los clientes, no lo
3:06recolectamos. Primer punto. Entonces, lo
3:09que tengo que definir en un primer paso
3:12es mi aplicación. ¿Qué va a tener? Va a
3:14tener estos datos sensibles. Para cada
3:17dato tenemos que responder la siguiente
3:19pregunta. ¿Qué información guardamos?
3:22¿Para qué necesitamos esa información?
3:24¿Quién puede ver esa información? ¿Qué
3:26daño podría ocurrir si se filtra?
3:29Entonces, la regla más sencilla que
3:31tenemos en este caso es guardar
3:33solamente lo necesario, pedirle al
3:35cliente solamente lo necesario. Si la
3:38aplicación puede funcionar sin sin un
3:41quid, sí lo pedimos. Sí, eso porque el
3:44DNI es uno de los datos más sensibles.
3:46Entonces, cuanto menos datos sensibles
3:48nosotros pedimos de nuestro cliente,
3:50menor va a ser el riesgo. En el caso de
3:53pedirlo, bueno, definirlo primero para
3:56qué necesitamos. Y acá nosotros es
3:58fundamental que podamos tener dentro de
4:01nuestra aplicación las políticas de
4:03privacidad y las condiciones de
4:05servicio. Entonces, cuando nosotros
4:07creamos una aplicación, tenemos que
4:09definir cuáles son las políticas de
4:11privacidad y cuáles son las condiciones
4:13de servicio que nosotros vamos a tener
4:15dentro de nuestra aplicación. Y el
4:17cliente cuando ingresa debe aceptar esas
4:21políticas de privacidad y esas
4:22condiciones de servicio. El segundo
4:25punto que tenemos que tener también
4:28nosotros claro es esta estas diferencias
4:33entre lo que es autentificación y
4:36autorización. ¿Cuál es la diferencia?
4:38Porque entre los dos conceptos e suelen
4:41confundirse, pero realmente cumplen
4:43funciones diferentes. Si la
4:46autentificación puede responder eh quién
4:49es la persona. Cuando el usuario inicia
4:51sesión con un correo, con una
4:52contraseña, a través de de un enlace que
4:56nosotros le mandamos, la aplicación está
4:58verificando su identidad. La
5:00autorización responde a otra cosa,
5:03responde a qué es lo que esa persona
5:05puede hacer dentro de nuestra
5:07aplicación. Por ejemplo, puede tener el
5:10rol administrativo, puede tener un rol
5:13de comprador, un rol de vendedor, un rol
5:15de cliente. Entonces, acá yo tengo que
5:18diferenciar entre la autentificación y
5:22la autorización que nosotros le damos a
5:24esa persona dentro de nuestra
5:27aplicación. Supa base puede ayudarnos
5:30con la autentificación, pero para
5:33proteger la información de la base de
5:35datos necesitamos reglas, ¿sí?, de
5:39autorización. Entonces, esas reglas de
5:41autorización eh son fundamentales que
5:44cuando nosotros creamos nuestra
5:46aplicación podamos entender acá. Acá lo
5:50primero que tenemos, porque esto es un
5:51hueco que generalmente suele fallar si
5:55cuando creamos una aplicación. ¿Y qué
5:57qué es lo que suele pasar? Por ejemplo,
5:59el rol del cobrador puede ver lo que
6:02hace el rol del vendedor. Quedan
6:04ventanas abiertas y que cualquier
6:07persona puede entrar y ver lo que pasa
6:09en otro rol que no tiene permitido.
6:12Entonces, acá no solamente el detalle
6:15está en que tengamos roles definidos,
6:19sino que cada rolar
6:22al otro. ¿Sí? Entonces, no solamente es
6:25que la persona que yo le estoy asignando
6:27un rol pueda entrar y ver sus cosas,
6:30sino que también tenga prohibido ver
6:33otros datos. Entonces, ahí es donde
6:36generalmente la mayoría de las
6:37aplicaciones hechas con inteligencia
6:39artificial fallan y queda una ventana y
6:42un hueco muy importante en el cual no
6:45cerramos la seguridad de los roles.
6:48Entonces, primero dentro de su pace
6:51tenemos que tener activado, ¿sí?, el
6:53RLS, que ahora vamos a ver. Tenemos que
6:56definir las filas, qué filas puede leer,
6:59qué filas puede crear, qué filas pueda
7:01modificar, qué filas pueda eliminar.
7:03Esto es fundamental, que cada tabla en
7:07su pace tenga sí eh designado el RLS
7:13para que nadie que no tenga permiso
7:15pueda entrar a la base de datos y pueda
7:18modificar esas datas. Entonces, acá
7:20tenemos dos cuestiones muy importantes
7:23que tenemos que entender. Por un lado,
7:24la autentificación, que es los datos que
7:27la persona tiene que poner para poder
7:29ingresar a la aplicación y por otro
7:31lado, el rol que tiene dentro de nuestra
7:33aplicación. Y ese rol también tiene que
7:36tener ciertas prohibiciones, por
7:38ejemplo, que no pueda entrar en el rol
7:40de administrador o en el rol de
7:43cobrador o en el rol de contable. ¿Sí?
7:46Entonces, tenemos autorización, tenemos
7:49autentificación. Otro punto clave muy
7:52importante dentro de nuestras
7:54aplicaciones son las credenciales, ¿sí?
7:58las claves y las credenciales. Este
8:01punto es fundamental porque acá nosotros
8:03lo que tenemos que garantizar es que
8:06ninguna clave y que ninguna credencial
8:09esté público, que es decir que cualquier
8:12persona puede verlo. Tienen que estar
8:15alojadas dentro de un servidor seguro.
8:20Esto es clave, es fundamental y esto es
8:22también un error que suele suceder
8:25cuando la inteligencia artificial nos
8:27crea las aplicaciones. Entonces, ningún
8:29dato, ninguna credencial, nada debe
8:32estar como público. Y acá hay un detalle
8:34muy importante también. Cuando nosotros
8:37creamos una aplicación, nunca, pero
8:40nunca, nunca nosotros debemos poner
8:43APIs, credenciales, inicio de sesión,
8:45datos de usuario, contraseñas dentro del
8:48chat. Eso no lo tenemos que hacer.
8:50Nosotros trabajamos a través de datos
8:54externos donde nosotros cargamos las
8:56credenciales, las API, todo lo demás,
8:58pero no se lo ponemos en el chat. Esto
9:00es fundamental. El chat nunca tiene que
9:02traer la información de credenciales, de
9:05API y de datos. Entonces, nosotros ahí
9:07también estamos garantizando la
9:09seguridad de nuestras API, de nuestro
9:11usuario, de nuestra contraseña, ¿sí?
9:13para que esto no quede expuesto en un
9:15chat con la inteligencia artificial,
9:17sobre todo si nosotros estamos
9:19trabajando con modelos gratuitos.
9:21Entonces, las claves y credenciales
9:23nunca deben estar puestas de público.
9:27Sí, por ejemplo, una API de Open
9:30Chemini, Open Router, servicios de
9:32correo y otras plataformas nunca deben
9:34quedar público, siempre deben estar
9:37protegidas. Entonces la public de
9:40suabase sí está pensada para utilizarse
9:44en una aplicación pública. Puede
9:46aparecer en el navegador, pero su acceso
9:49debe ser limitado a través de el RLS
9:53para permisos mínimos. Las claves y las
9:57var las claves y los secretos deben
10:00guardarse dentro de las variables del
10:03entorno.
10:05Entonces, las variables las cargamos a
10:07través de variables del entorno. En
10:09Netlifly tenemos esa posibilidad de
10:11cargar todas las APIs y credenciales a
10:13través de las variables del entorno.
10:14Bien, no estás entendiendo esto porque
10:17Lore, yo no soy programadora, yo no
10:19entiendo lo que me estás hablando. Bien,
10:21¿qué es lo que vamos a hacer? Yo lo que
10:22quiero que a vos te quede claro es estos
10:25puntos que tenemos que tener, que
10:27estuvimos viendo hasta ahora, ¿sí? que
10:30vos puedas entender los puntos a tener
10:33en cuenta. Entonces, hasta ahora lo que
10:35nosotros vimos son los datos que debemos
10:38proteger, lo que vimos es la diferencia
10:41entre autentificación y autorización y
10:43que todas las claves y las credenciales
10:46se cargan a través de variables del
10:48entorno. Eso es lo que vos tenés que
10:50definir como tu estructura de seguridad.
10:52¿Para qué? Para crear un prom, para
10:54darle los datos, que es lo que nosotros
10:56ahora vamos a hacer. Pero yo quiero que
10:57vos entiendas, ¿sí? antes de darle un
10:59prom o antes de crear una skill para que
11:02proteja o para que realice la protección
11:04a tu aplicación, es que vos puedas
11:06entender qué es lo que tenemos que
11:08proteger. Entonces, si nosotros
11:10entendemos a nuestra API, la entendemos
11:13como que tenemos, ¿sí?, los usuarios de
11:15entrada. Tenemos el código de la
11:17aplicación, el HTML, que la inteligencia
11:19artificial me realiza, el Frontier, ese
11:22Frontier tiene que estar limpio, ese
11:24código HTML tiene que estar limpio. A su
11:27vez entendemos que dentro de una
11:29aplicación tenemos diferentes APIs o
11:32diferentes llaves de accesos y
11:33credenciales y que trabajamos también
11:36con Supase donde se van a alojar los
11:39datos que vamos a cargar dentro de
11:41nuestra aplicación. Sí, tenemos que
11:42entender que todo este conjunto es un
11:45conjunto que hay que proteger, la
11:48seguridad del fronter y de las APIs. Eh,
11:51esto es lo que nosotros tenemos que eh
11:54poder proteger. Cuando nosotros
11:56iniciamos sesión en una cuenta, tenemos
11:59el inicio sesión, es decir, el login y
12:02eso necesitamos tener un doble factor,
12:05un segundo factor. Es decir, si yo tengo
12:08un inicio de sesión como admin, lo ideal
12:11sería que podamos tener un segundo
12:13factor en el admin, un segundo factor en
12:15el inicio de la base de datos, un
12:17segundo factor en el inicio del hosting.
12:20Eso es fundamental. ¿Para qué? para que
12:23me avisen mi teléfono si alguien está
12:24entrando dentro de admin, si alguien
12:26está entrando a mi base de datos, los
12:29permisos dentro de los roles también, si
12:32es un rol importante dentro de la
12:33aplicación también que pueda tener el
12:36segundo factor. Otra cosa es que cuando
12:39salgamos de la aplicación se cierre
12:41inmediatamente el inicio de sesión, que
12:43no quede abierto. Eso también es un
12:46punto importante. Entonces, cuando
12:48creamos una aplicación y al salir de esa
12:50aplicación que inmediatamente si me pida
12:53revocar el acceso. Son puntos para tener
12:56en cuenta, sobre todo en la cuenta de
12:58los administradores. La cuenta de los
13:00administradores donde está cargada toda
13:02la información de la app, que tengamos
13:04en cuenta tener el segundo factor, los
13:06roles con permisos mínimos y que cuando
13:09se salga de la aplicación se cierre la
13:11sesión. El punto seis sí es la cadena
13:15que nosotros tenemos que dar. Entonces,
13:17tenemos que crear el código, si tenemos
13:19que ver la versión, tenemos que hacer un
13:22escaneo de vulnerabilidades,
13:25tenemos que escanear todas las posibles
13:28ventanas y fallas que pueda tener
13:30nuestra aplicación. Tenemos que hacer
13:33pruebas y este entorno tiene que ser
13:35pruebas por separado y tenemos que tener
13:37si un artefacto verificado. Eso es
13:40fundamental. Entonces, menos paquete,
13:43menos superficie de ataque. El séptimo
13:45punto de configuración es el hosting.
13:48¿Sí? Entonces, nosotros tenemos que ver
13:50dentro de nuestro hosting también todas
13:53las pruebas de seguridad, porque si
13:54nosotros tenemos usuarios reales,
13:56estamos trabajando dentro de producción
13:58con usuarios reales, debemos hacer la
14:00validación ya una vez que está subido al
14:03hosting. Y el último punto de seguridad
14:05es el backup. Toda aplicación tiene que
14:08tener un backup. Sí, nosotros tenemos
14:11que poderar sí, la base de datos en el
14:14caso que nosotros tengamos nuestra base
14:16de datos en supa base y supa base un
14:19ataque, no voy a poder restaurar con
14:20eso. Entonces, lo ideal es tener una
14:24base de datos alojada, por ejemplo, en
14:27un alojamiento interno como hiph hop,
14:30donde se pueda subir, sí, los datos en
14:33esa base de datos y eh nosotros podamos
14:36hacer una copia de seguridad diaria,
14:39porque si solo estoy trabajando en forma
14:40de producción todos los días, necesito
14:42hacer una copia de seguridad diaria y
14:44que se aloje, ¿sí?, en una cuenta de
14:47Hitop para eh poder subir toda la base
14:50de datos y tener ahí una copia de
14:52seguridad antes que suceda algo, antes
14:54que tengamos algún problema, bueno,
14:56podemos tener sí una restauración de
14:58nuestra base de datos.
15:02Para terminar, tenemos que entender,
15:05recordar que la seguridad no es una
15:07tarea que se realiza una sola vez antes
15:11de publicar. Cada función nueva, cada
15:14tabla nueva que nosotros le agregamos,
15:16cada modificación que hacemos a nuestra
15:18aplicación, tenemos que volver a
15:21revisar. Antes de publicar debemos
15:24comprobar el RLS este activo, que un
15:28usuario no pueda consultar datos de otro
15:31usuario ajeno, e que las claves secretas
15:34estén protegidas, que las entradas se
15:36validen, que el servidor e no tenga este
15:40no tenga las claves expuestas, sí, que
15:43las cuentas administrativas utilicen el
15:46MFA, es decir, el doble factor. También
15:50debemos revisar las dependencias,
15:52separar los ambientes, activar los log,
15:56las alertas y probar siempre probar las
16:00copias de seguridad que se estén
16:02descargando correctamente. una
16:05aplicación segura no es eh simplemente
16:09ocultar la base de datos, ¿sí? es que
16:13podamos identificar correctamente a cada
16:16persona que ingresa, limitar los
16:19permisos, guardar solo la información
16:21necesaria, detectar comportamientos
16:24extraños si la seguridad no se le agrega
16:27al final, sino que la seguridad se
16:29diseña desde el principio. Para hacer
16:32todo esto, te voy a dejar dos opciones.
16:34Te voy a dejar un prom para que vos
16:35puedas con ese promes
16:38necesarias a tu inteligencia artificial
16:40con lo que hagas, con Open Code, con
16:42Cloud Code, con CHGT, que puedas pegarle
16:44el prom y someter tu aplicación a
16:46pruebas. Y también te voy a dejar una
16:48skill que es la skill de seguridad para
16:52que la llames en el momento necesario.
16:54Te voy a dejar las dos cosas para que
16:56realmente puedas hacer todas las pruebas
16:59de seguridad dentro de tu aplicación. Y
17:01si este video te sirvió, por favor,
17:03déjanos un like y suscribite a este
17:05canal.

About this transcript

This page contains the full transcript of Que tu App Funcione NO Significa que Sea Segura (Apps con IA + Supabase) by VademecumIA, generated from the public captions YouTube serves with the video. The transcript has 2,574 words across 406 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to choose a caption track available on the video.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, caption language selection, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.