Local blog for Spanish speaking developers in LATAM
12 prácticas recomendadas para la administración de cuentas de usuario, autorizaciones y contraseñas
martes, 27 de febrero de 2018
Por
Ian Maddox
, arquitecto de GCP Solutions
La administración de cuentas, autorizaciones y contraseñas puede ser complicada. Para muchos programadores, la administración de cuentas es un punto ciego al que no se le presta suficiente atención. Para los gerentes de producto y los clientes, la experiencia resultante generalmente no cumple con las expectativas.
Por suerte,
Google Cloud Platform
(GCP) incluye varias herramientas que te ayudarán a tomar buenas decisiones respecto de la creación, administración segura y autenticación de cuentas de usuarios (en este contexto, cualquiera que se identifique con tu sistema,
clientes o usuarios internos). Si eres responsable de un sitio web alojado en
Google Kubernetes Engine
, una API en
Apigee
, una app que usa
Firebase
u otro servicio con usuarios autenticados, en esta entrada se abarcarán las prácticas recomendadas para garantizar que cuentes con un sistema de autenticación de cuentas seguro, escalable y utilizable.
1. Guarda las contraseñas
Mi regla más importante para la administración de cuentas es guardar de forma segura la información confidencial del usuario, incluidas sus contraseñas. Debes tratar esos datos como si fueran sagrados y manipularlos correctamente.
No guardes contraseñas en texto sin formato bajo ninguna circunstancia. Tu servicio debe, como alternativa, almacenar un hash criptográficamente seguro de la contraseña que no pueda revertirse
;
creado, por ejemplo, con PBKDF2, SHA3, Scrypt o Bcrypt. Se debe
aplicar sal
a ese hash con un valor exclusivo para esa credencial de acceso específica. No uses tecnologías de hashing obsoletas, como MD5, SHA1. Tampoco debes usar bajo ninguna circunstancia encriptación reversible ni
intentar revertir tu algoritmo de hashing
.
Debes diseñar tu sistema asumiendo que presentará fisuras en algún momento. Pregúntate esto: “si mi base de datos quedara expuesta hoy, ¿estaría en riesgo la seguridad de mis usuarios en mi servicio o en otros que utilizan? ¿Qué se puede hacer para reducir las probabilidades de daños en caso de una fuga?”
Otro punto: si pudieras producir una contraseña de usuario en texto sin formato en cualquier momento, salvo inmediatamente después de que ellos te la proporcionen, habrá un problema en tu implementación.
2. Si es posible, permite el uso de proveedores de identidad externos
Los proveedores de identidad externos te permiten consultar un servicio externo confiable para autenticar la identidad de un usuario. Google, Facebook y Twitter son proveedores que se utilizan con frecuencia.
Puedes implementar proveedores de identidad externos junto con tu sistema de autenticación interno actual usando una plataforma como
Firebase Auth
. Firebase Auth ofrece una serie de beneficios, en los que se incluyen una administración simplificada, una menor superficie de ataque y un SDK multiplataforma. Abordaremos más beneficios a lo largo de esta lista. Consulta nuestros
estudios de casos
sobre compañías que pudieron integrar Firebase Auth en un solo día.
3. Separa el concepto de identidad del usuario y cuenta del usuario
Tus usuarios no son una dirección de correo electrónico. No son un número de teléfono. No son un ID único proporcionado por una respuesta de OAUTH. Tus usuarios son la culminación de sus datos exclusivos y personalizados, y sus experiencias con tu servicio. Un sistema de administración de usuarios bien diseñado ofrece poca vinculación y gran cohesión entre las diferentes partes del perfil de un usuario.
Mantener separados los conceptos de cuenta de usuario y credenciales simplificará notablemente el proceso de implementación de proveedores de identidad externos, lo que permitirá a los usuarios cambiar sus nombres de usuario y vincular varias identidades a una sola cuenta de usuario. En términos prácticos, puede ser útil tener un identificador global interno para cada usuario y vincular su perfil y autenticación a través de ese ID en lugar de amontonarlos a todos en un solo registro.
4. Permite la vinculación de varias identidades con una sola cuenta de usuario
Un usuario que se autentica en tu servicio usando su
nombre de usuario y contraseña
durante una semana podría elegir
Google Sign-In
a la semana siguiente sin saber que esto podría crear una cuenta duplicada. De igual manera, un usuario podría tener una muy buena razón para vincular varias direcciones de correo electrónico a tu servicio. Si separaste correctamente la identidad y la autenticación del usuario, el proceso de
vincular varias identidades
con un solo usuario será más simple.
En tu back-end deberá contemplarse la posibilidad de que un usuario realice el proceso de acceso de forma parcial o total antes de darse cuenta de que usa una nueva identidad externa no vinculada a su cuenta en tu sistema. Esto se logra con mayor facilidad si se solicita al usuario proporcionar un detalle identificatorio común, como la dirección de correo electrónico, el teléfono o el nombre de usuario. Si los datos coinciden con un usuario existente de tu sistema, solicítale también autenticarse con un proveedor de identidad conocido y vincular el nuevo ID con su cuenta existente.
5. No bloquees contraseñas extensas o complejas
Recientemente, NIST ha actualizado las pautas sobre
complejidad y seguridad de las contraseñas
. Gracias a que usas (o usarás muy pronto) un hash criptográfico seguro para el almacenamiento de contraseñas, ya tienes muchos problemas resueltos. Los hash siempre producirán un código de extensión fija, independientemente de la extensión de la contraseña ingresada, de modo que tus usuarios podrán usar sus contraseñas durante el tiempo que quieran. Si necesitaras reducir la extensión de las contraseñas, solo hazlo teniendo en cuenta el tamaño de POST máximo permitido por tus servidores. Normalmente, es bastante superior a 1 MB. De verdad.
Tus contraseñas con hash constarán de una pequeña selección de caracteres ASCII conocidos. De lo contrario, puedes convertir fácilmente un hash binario a
Base64
. Considerando esto, deberías permitir que tus usuarios usen, literalmente, los caracteres que deseen en sus contraseñas. Si alguien desea que su contraseña contenga
Klingon
,
Emoji
y caracteres de control con espacios en blanco en ambos extremos, no deberías tener razones técnicas para impedirlo.
6. No impongas reglas disparatadas para los nombres de usuario
No es disparatado que un sitio o servicio solicite nombres de usuario de más de dos o tres caracteres, que bloquee los caracteres ocultos y que evite la presencia de espacios en blanco al comienzo y al final de un nombre de usuario. No obstante, algunos sitios se exceden con los requisitos, como una extensión mínima de ocho caracteres o el bloqueo de caracteres que no sean letras y números en ASCII de 7 bits.
Un sitio con restricciones rígidas para los nombres de usuario puede ofrecer algunas ventajas a los programadores, pero la carga recaerá sobre los usuarios. A su vez, en casos extremos, algunos usuarios se alejarán del sitio.
En algunos casos, la mejor estrategia es asignar los nombres de usuario. Si esto se aplica a tu servicio, asegúrate de que el nombre de usuario asignado sea simple para que el usuario pueda recordarlo y comunicarlo. Para los ID alfanuméricos deben evitarse símbolos visualmente ambiguos, como “Il1O0”. También se te recomienda buscar en el diccionario algunas cadenas generadas al azar para asegurarte de que no haya mensajes inadvertidos en el nombre de usuario. Estas mismas pautas se aplican para las contraseñas generadas automáticamente.
7. Permite que los usuarios cambien su nombre de usuario
Es muy común que en los sistemas heredados, o en algunas plataformas que proporcionan cuentas de correo electrónico, se prohíba a los usuarios cambiar su nombre de usuario. Existen
muy buenas razones
para no liberar automáticamente nombres de usuario con el propósito de que vuelvan a usarse, pero quienes emplean tu sistema hace mucho tendrán, con el tiempo, un buen motivo para usar un nombre de usuario diferente y probablemente no deseen crear una cuenta nueva.
Puedes cumplir el deseo de tus usuarios de cambiar sus nombres de usuario habilitando el uso de alias y permitiéndoles elegir el alias principal. Puedes aplicar las reglas empresariales que necesites sobre la base de esta funcionalidad. Algunas organizaciones solo permiten un cambio de nombre de usuario por año o exigen al usuario mostrar solo su nombre de usuario principal. Los proveedores de correo electrónico podrían garantizar que los usuarios reciban la información necesaria sobre los riesgos antes de desvincular un nombre de usuario en desuso de sus cuentas, o quizá prohibir por completo la desvinculación de nombres de usuario en desuso.
Escoge las reglas adecuadas para tu plataforma, pero asegúrate de permitir a tus usuarios desarrollarse y realizar cambios a medida que pase el tiempo.
8. Permite que tus usuarios borren sus cuentas
Un número sorprendente de servicios no tienen opciones de autoservicio para que un usuario borre su cuenta y los datos asociados. Existen varias buenas razones por las que un usuario puede cerrar una cuenta de forma permanente y borrar todos los datos personales. Esas inquietudes deben considerarse sin perder de vista tu seguridad y tus necesidades de cumplimiento, pero los entornos más reglamentados proporcionan pautas específicas sobre la retención de datos. Una solución común para evitar preocupaciones en relación con el cumplimiento y posibles intrusiones es permitir que los usuarios programen sus cuentas para la eliminación automática en el futuro.
En algunas circunstancias, es posible que
se te exija, por medios legales, acceder
a la solicitud de un usuario que desee borrar sus datos de forma oportuna. A su vez, tu exposición también aumentará notablemente si ocurre una filtración de datos en la que se revelen datos de cuentas “cerradas”.
9. Toma una decisión consciente con respecto a la duración de las sesiones
Un aspecto de seguridad y autenticación generalmente omitido es la
duración de las sesiones
. Google se esfuerza mucho por
garantizar que los usuarios sean quienes dicen ser
y lo corroborará en función de conductas o eventos determinados. Los usuarios pueden tomar medidas para
aumentar aún más su seguridad
.
Tu servicio puede tener un buen motivo para mantener una sesión abierta indefinidamente con fines de análisis no crítico, pero debe haber
umbrales
que deben superarse para que solicites la verificación de usuarios mediante de contraseña, segundo factor u otro elemento.
Piensa en cuánto tiempo un usuario debe estar inactivo antes de tener que volver a autenticarse. Si alguien restablece la contraseña, verifica la identidad del usuario en todas las sesiones activas. Solicita la autenticación o un segundo factor si un usuario cambia aspectos centrales de su perfil o cuando realice una acción confidencial. Evalúa si tiene sentido deshabilitar el acceso desde más de un dispositivo o lugar a la vez.
Cuando tu servicio finalice una sesión de usuario o solicite repetir la autenticación, informa al usuario en tiempo real o proporciona un mecanismo que preserve la actividad que no guardó desde su última autenticación. Resulta frustrante para un usuario llenar un formulario extenso, enviarlo un tiempo después y descubrir que todo lo que ingresó se perdió y debe acceder nuevamente.
10. Usa verificación en dos pasos
Piensa en el impacto que tiene, en términos prácticos, sobre un usuario el robo de su cuenta al elegir un método de
verificación en dos pasos
(también conocida como autorización de dos factores o simplemente 2FA).
NIST ha dejado de usar
la autorización 2FA por SMS debido a varios puntos débiles; no obstante, quizá sea la opción más segura que tus usuarios aceptarán para lo que consideren un servicio de poca importancia. Ofrece el método de autorización 2FA más seguro que puedas. Permitir el uso de proveedores de identidad externos y realizar “piggyback” en sus 2FA es un modo sencillo de aumentar tu seguridad sin grandes gastos ni esfuerzos.
11. Haz que no se distingan mayúsculas y minúsculas para los ID de usuario
A tus usuarios no les importa y quizá ni siquiera recuerden la forma exacta en la que escribieron su nombre de usuario. No deben distinguirse mayúsculas y minúsculas para los nombres de usuario. No es eficaz almacenar nombres de usuario y direcciones de correo electrónico en minúsculas y transformar las entradas en minúsculas antes de la comparación.
Los smartphones representan un porcentaje cada vez mayor de los dispositivos de usuarios. La mayoría ofrecen autocorrección y cambio automático a mayúsculas de campos con texto sin formato. Evitar esta conducta a nivel de la IU podría no ser lo mejor ni completamente eficaz, y tu servicio debe ser suficientemente sólido como para administrar una dirección de correo electrónico o un nombre de usuario que se haya ingresado en mayúsculas por error.
12. Crea un sistema de autenticación seguro
Si usas un servicio como Firebase Auth, muchas cuestiones de seguridad se abordan por ti automáticamente. Sin embargo, siempre deberás diseñar tu servicio correctamente para evitar abusos. Entre las consideraciones más importantes se incluyen la implementación de un
restablecimiento de contraseña
en lugar de la recuperación de esta, el registro detallado de la actividad de la cuenta, una cantidad límite de intentos de acceso, el bloqueo de cuentas después de demasiados intentos sin éxito y la solicitud de autenticación de 2 factores para cuentas o dispositivos desconocidos que hayan permanecido inactivos durante un tiempo prolongado. Hay muchos más aspectos importantes para un sistema de autenticación seguro, por lo que te recomiendo leer la siguiente sección, donde encontrarás vínculos a más información.
Consultas adicionales
Hay disponibles varios recursos excelentes que te guiarán en el proceso de desarrollo, actualización o migración de tu sistema de administración de cuentas y autenticación. Te recomiendo lo siguiente como punto de partida:
En
NIST 800-063B
se abarcan la administración de la autenticación y el ciclo de vida.
OWASP actualiza continuamente su
Hoja de referencia de almacenamiento de contraseñas.
OWASP proporciona información aún más detallada en la
Hoja de referencia de autenticación.
En el sitio de
Firebase Authentication
de Google se ofrece una amplia biblioteca de guías, material de referencia y ejemplos de código.
Mejoramiento de los modelos integrales para el reconocimiento de voz
viernes, 23 de febrero de 2018
Publicado por Tara N. Sainath, científica investigadora, equipo de voz, y Yonghui Wu, ingeniero de software, equipo de ideas de Google
Los sistemas de reconocimiento de voz automáticos (ASR) tradicionales, que se usan para diferentes aplicaciones de búsqueda por voz en Google, constan de un modelo acústico (AM), un modelo de pronunciación (PM) y un modelo de idioma (LM), que se preparan individualmente y, por lo general, se diseñan manualmente, en diferentes conjuntos de datos [1]. Los AM toman funciones acústicas y predicen un conjunto de unidades de subpalabras; normalmente, fonemas dependientes e independientes del contexto. Luego, un léxico diseñado manualmente (el PM) asigna una secuencia de
fonemas
, producida por el modelo acústico, a palabras. Por último, el LM asigna probabilidades a secuencias de palabras. La preparación de componentes independientes crea otras complejidades y no es óptimo cuando se compara con la preparación de todos los componentes de forma conjunta. Durante los últimos años, se ha vuelto cada vez más popular el desarrollo de sistemas integrales, cuyo propósito es aprender esos componentes independientes de forma conjunta como un solo sistema. Si bien esos modelos integrales han mostrado resultados prometedores en la literatura [2, 3], aún no está claro si esos enfoques pueden mejorar en los sistemas convencionales de vanguardia actuales.
Hoy compartimos con entusiasmo “
Reconocimiento de voz innovador con modelos secuenciales
[4]”, que describe un nuevo modelo integral que supera el rendimiento de un sistema de producción convencional [1]. Mostramos que nuestro sistema integral alcanza un
índice de error de palabras
(WER) del 5,6%, que corresponde a una mejora relativa del 16% en comparación con un sistema convencional sólido, que alcanza un WER del 6,7%. Además, el modelo integral usado para generar la hipótesis de palabras inicial, antes de realizar una nueva puntuación de cualquier hipótesis, es 18 veces más pequeño que el modelo convencional, ya que no contiene LM ni PM independientes.
Nuestro sistema se basa en la arquitectura integral escuchar-asistir-deletrear (LAS), que se presentó por primera vez en [2]. La arquitectura LAS consta de 3 componentes. El componente codificador de
escucha
, similar a un AM estándar, toma una representación de frecuencia de tiempo de la señal de voz de entrada,
x
, y usa un conjunto de capas de red neurales para asignar los datos de entrada a una representación de función de nivel superior,
h
enc
. Los datos de salida del codificador se pasan a un
mecanismo de atención
, que usa
h
enc
para determinar una alineación entre las funciones de entrada
x
y las unidades de subpalabra previstas {y
n
, … y
0
}, donde cada subpalabra generalmente es un
grafema
o una
parte de una palabra
. Por último, el resultado del módulo de atención se pasa al
deletreador
(es decir, el decodificador), similar a un LM, que produce una distribución de probabilidad entre un conjunto de palabras supuestas.
Componentes del modelo integral LAS.
Todos los componentes del modelo LAS se preparan de forma conjunta como una sola red neural integral, no como módulos independientes propios de los sistemas convencionales, lo cual hace mucho más simple el proceso.
Además, debido a que el modelo LAS es completamente neural, no se requieren componentes externos diseñados manualmente, como transductores de estado limitados, un léxico o módulos de normalización de texto. Por último, a diferencia de lo que sucede con los modelos convencionales, para la preparación de modelos integrales no se necesitan arranques desde árboles de decisión ni alineaciones de tiempo generadas por un sistema independiente; esta se puede lograr a partir de pares de transcripciones de texto y de la acústica correspondiente.
En [4], presentamos diferentes mejoras estructurales nuevas, que incluyen la optimización de los vectores de atención que se pasan al decodificador y la preparación con unidades de subpalabras más extensas (es decir, partes de palabras). A su vez, también presentamos varias mejoras de optimización para la preparación, entre las que se incluyen el uso de preparación con un índice de error de palabras mínimo [5]. Estas mejoras estructurales y de optimización son las que permiten alcanzar la mejora relativa del 16% en comparación con el modelo convencional.
Otro campo de aplicación potencial que genera entusiasmo para esta investigación es el de los sistemas multidialecto y multilingüe, en el cual la facilidad de optimización de una red neural individual hace que el modelo sea muy atractivo. Aquí, los datos para todos los dialectos e idiomas se pueden combinar para preparar una red sin la necesidad de un AM, PM y LM independientes para cada dialecto o idioma. Estos modelos funcionan bien en 7 dialectos del inglés [6] y 9 idiomas de la India [7], y su rendimiento supera al de un modelo preparado de forma independiente para cada idioma o dialecto por separado.
Si bien estamos entusiasmados con los resultados, nuestro trabajo no ha terminado. Actualmente, estos modelos no pueden procesar voz en tiempo real [8, 9 y 10], que es un requisito importante para las aplicaciones sensibles a la latencia, como la búsqueda por voz. Además, la comparación de estos modelos con la producción aún es negativa cuando se evalúan en los datos de producción en tiempo real. Además, nuestro modelo integral incorpora 22 millones de enunciados en pares de audio-texto en comparación con un sistema convencional, que generalmente se prepara con elementos mucho más extensos. A esto se suma que nuestro modelo propuesto no puede aprender a deletrear de forma correcta palabras de uso poco frecuente, como nombres propios, algo que generalmente se logra con un PM diseñado manualmente. Nuestros esfuerzos continuos se centran en la manera de abordar esos desafíos.
Agradecimientos
Este trabajo se realizó en un gran esfuerzo colaborativo entre los equipos de ideas y voz de Google. Entre los colaboradores se incluyen Tara Sainath, Rohit Prabhavalkar, Bo Li, Kanishka Rao, Shankar Kumar, Shubham Toshniwal, Michiel Bacchiani y Johan Schalkwyk, del equipo de voz, y Yonghui Wu, Patrick Nguyen, Zhifeng Chen, Chung-cheng Chiu, Anjuli Kannan, Ron Weiss, Navdeep Jaitly, William Chan, Yu Zhang y Jan Chorowski, del equipo de ideas de Google. El trabajo se describe de forma más detallada en los documentos [4-12].
Referencias
[1] G. Pundak and T. N. Sainath, “
Lower Frame Rate Neural Network Acoustic Models
," in Proc. Interspeech, 2016.
[2] W. Chan, N. Jaitly, Q. V. Le y O. Vinyals, “
Listen, attend and spell
”, CoRR, vol. abs/1508.01211, 2015
[3] R. Prabhavalkar, K. Rao, T. N. Sainath, B. Li, L. Johnson y N. Jaitly, “
A Comparison of Sequence-to-sequence Models for Speech Recognition
”, en Proc. Interspeech, 2017.
[4] C.C. Chiu, T.N. Sainath, Y. Wu, R. Prabhavalkar, P. Nguyen, Z. Chen, A. Kannan, R.J. Weiss, K. Rao, K. Gonina, N. Jaitly, B. Li, J. Chorowski y M. Bacchiani, “
State-of-the-art Speech Recognition With Sequence-to-Sequence Models
”, presentado en ICASSP 2018.
[5] R. Prabhavalkar, T.N. Sainath, Y. Wu, P. Nguyen, Z. Chen, C.C. Chiu y A. Kannan, “
Minimum Word Error Rate Training for Attention-based Sequence-to-Sequence Models
”, presentado en ICASSP 2018.
[6] B. Li, T.N. Sainath, K. Sim, M. Bacchiani, E. Weinstein, P. Nguyen, Z. Chen, Y. Wu y K. Rao, “
Multi-Dialect Speech Recognition With a Single Sequence-to-Sequence Model
”, presentado en ICASSP 2018.
[7] S. Toshniwal, T.N. Sainath, R.J. Weiss, B. Li, P. Moreno, E. Weinstein y K. Rao, “
End-to-End Multilingual Speech Recognition using Encoder-Decoder Models
”, presentado en ICASSP 2018.
[8] T.N. Sainath, C.C. Chiu, R. Prabhavalkar, A. Kannan, Y. Wu, P. Nguyen y Z. Chen, “
Improving the Performance of Online Neural Transducer Models
”, presentado en ICASSP 2018.
[9] C.C. Chiu* y C. Raffel*, “
Monotonic Chunkwise Attention
”, presentado en ICLR 2018.
[10] D. Lawson*, C.C. Chiu*, G. Tucker*, C. Raffel, K. Swersky, N. Jaitly. “
Learning Hard Alignments with Variational Inference
”, presentado en ICASSP 2018.
[11] T.N. Sainath, R. Prabhavalkar, S. Kumar, S. Lee, A. Kannan, D. Rybach, V. Schogol, P. Nguyen, B. Li, Y. Wu, Z. Chen y C.C. Chiu, “
No Need for a Lexicon? Evaluating the Value of the Pronunciation Lexica in End-to-End Models
”, presentado en ICASSP 2018.
[12] A. Kannan, Y. Wu, P. Nguyen, T.N. Sainath, Z. Chen y R. Prabhavalkar. “
An Analysis of Incorporating an External Language Model into a Sequence-to-Sequence Model
”, presentado en ICASSP 2018.
Usa Forseti para asegurarte de que tus clústeres de Google Kubernetes Engine se actualicen para “Meltdown” y “Spectre”
miércoles, 21 de febrero de 2018
Por
Andrew Hoying
, experto en Seguridad de
Google Cloud
.
El mes pasado, Project Zero divulgó detalles sobre las
vulnerabilidades de CPU
que se han denominado “Meltdown” y “Spectre”, y te informamos que Google Cloud se
actualizó para brindar protección
contra todas las vulnerabilidades conocidas.
Los clientes que poseen equipos virtuales (VM) en los servicios de Google Cloud deben continuar siguiendo las prácticas recomendadas de seguridad y aplicar periódicamente todas las actualizaciones de seguridad, tal como lo harían con cualquier otra vulnerabilidad del sistema operativo. Proporcionamos una
lista completa de medidas recomendada
s para que los clientes de GCP puedan protegerse contra estas vulnerabilidades.
Una medida recomendada es actualizar todos los clústeres de
Google Kubernetes Engine
para garantizar que se revise por completo la imagen del VM subyacente. Puedes hacerlo automáticamente habilitando la actualización automática en tus grupos de nodos de Kubernetes. ¿Quieres asegurarte de que todos tus clústeres tengan una versión revisada que contemple estas vulnerabilidades de CPU? El equipo de seguridad de Google Cloud desarrolló un escáner que puede resultar útil.
Este se encuentra en
Forseti Security
, un conjunto de herramientas de código abierto para GCP que te permite identificar rápidamente clústeres de Kubernetes Engine aún no revisados.
Si ya instalaste Forseti, debes
actualizarlo
a la versión 1.1.10 y
habilitar el escáner
. Si aún no lo has hecho,
instala Forseti Security
en un nuevo proyecto de tu organización en GCP. El escáner comprobará, una vez por hora, la versión de los grupos de nodos de todos los clústeres de Kubernetes Engine que se ejecuten en todos tus proyectos de GCP. Forseti registra las infracciones que detecta en su tabla de infracciones y, opcionalmente, envía un correo electrónico a tus administradores de GCP para ayudarte a identificar cualquier exposición persistente a Meltdown.
El conjunto de herramientas Forseti se puede usar de muchas formas diferentes para ayudarte a preservar la seguridad. Para obtener más información sobre la comunidad Forseti, lee esta
entrada del blog
. Si tienes preguntas sobre esta herramienta, envía un mensaje a
discuss@forsetisecurity.org
.
Labels
.app
.dev
.txt
#AMP
#CPU
#DeveloperStudentClubs
#DevFest
#DragonBall
#DSC
#Forsety
#ForsetySecurity
#freeandopen
#GCP
#Google
#GoogleCloud
#GoogleCloudPlatform
#GoogleLaunchpad
#iio2009
#Kubernetes
#MaterialDesign
#OneCommunity
#Security
#TensorFlow
#UPGlobal
#UpLatam
#WithGoogle
+page
10 YEARS
2013
2019
64 bits
A/B Testing
AA
Accelerator
Action on Goolge
actionbar
Actions
Actions Console
AdMob
Ads
adwords
adwords api
AI
AIY
ajax
alarmmanager
ALFA
almacenamiento
alojamiento de proyectos en google code
AMP
AMP Conf
AMP Project
amp-date-picker
amphtml
Analytics
Andorid
android
Android (operating System)
Android 3.1
android 3.3
android 4.2
android 9
Android 9 Pie
Android App Bundle
android design
Android Dev Summit
Android Developers
android Jetpack
Android P
Android SDK
Android Studio
Android Things
Android Wear
AndroidDevStory
androititlan
angelina jolie
Annotation
Announcements
anuncios
API
API Analytics YouTube
Apigee
APIs
Aplicaciones
aplicaciones chrome
app
app engine
App Indexing
app invites
App Server
applications
AppQuality
apps
Apps Script
AR
ARCore
arte
ATLAS
AWP
backend
Base64
batch
Bava
Betatesting
Better Ads Standars
bigdata
BigQuery
Biometrics
blink
bootcamp
BOT
BQ
Business
búsqueda ajax
by Google
byCases
byCommunity
byDevelopers
byGoogle
C++
CALENDAR
Cardboard
case
caso de éxito
Casos de éxito
casos destacados
CCOSS
Century Fox
chat
chrome
chrome web store
chromebook
chromecast
chromium
Cinéfilos
cloud
Cloud Anchors
CLOUD endpoints
Cloud Firestore
Cloud Functions
Cloud IoT Core
Cloud Next
Cloud Scheduler
Cloud services
cloud test lab
Cloud Text-to-Speech
Cloud Translation
CMD en vivo
coconut
code
code-in
code.org
CodeLabs
código
código abierto
Colab
colombia
Communities
Comunidades
concurso google
conference
contenedores
convocatoria
Coordinate
crashlytics
CRE
crear aplicaciones ajax
creatividad
Crowdsource
CSS
cws
daniela robles
dart
dart sdk
dartium
dartlang
Dataset
DCL
denis labelle
desarrolladores
Desarrolladores Google
desarrolladores LatAm
Desarrollar
Design
Design Sprint
Destacados
dev
Dev.f
DevArt
DevBus
DevBusLatAm
Developer Bus
Developer Summit
DeveloperConsole
developers
DevFest
devoxx
dialogflow
diseño UX
Distribuir
DNS
DOM
domain
DonkeyCar
doubleclick
Drive SDK
Drivers
ecommerce
ecosistema
elections
elizalde
Emoticons
emprendedores
empresas
engagement
english
Enhanced Campaigns
enterprise
eventos
Events
evolución de aplicaciones
Excel
ExpertosDicen
Faas
Family
FanBridge
FCM
FCP
Featured
fido
find people
Fintech
firebase
Firebase Cloud Messaging
firebase summit
flu trends
Flutter
Flutter 1.0
flutter 1.7
flutter developers
Flutter Live
FlutterLive
FoundersLab
Freebase
Fuction
Fuctions
Full-Stack
functional programming
G Suite Dev Show
G+
g+ goto gal
G+GotoGal
GAE
game
games
GCloud
gcm
GCP
GCS
GDA
GDE
GDG
GDH
GDL
GDLevent
GDS
Get Inspired
get.app
GitHub
GLP
gmail
golang
GOMO
Google
Google Accelerator
Google AdMob SDK
Google AdWords
Google Analytics
Google APIS
Google App Engine
Google Apps
Google Apps Script
Google Art Project
Google Assistant
google calendar
google cast
Google Charts
Google Chrome
Google Cloud
Google Cloud Console
Google Cloud Messaging
Google Cloud Next
Google Cloud Platform
Google Cloud Platform Newsletter
google cloud platforn
Google Cloud Storage
google code-in
Google Compute Engine
Google Dataset
Google Developer Groups
google developers
Google Developers Academy
google developers expert
Google Developers Hackademy
google dns
Google Drawings
Google Drive
Google Earth
Google for games
Google Forms
google geo
Google Home
google i/o
google i/o extended
google io
Google Keep
Google Kubernetes Engine
Google Launchapad
Google Launchpad
Google Maps
google maps coordinate
Google Maps Platform
Google Mexico
Google Nose
google now
Google Person Finder
google places api
Google Play
Google Play Books
Google Play Developer API
google play games
Google Play Movies
Google Play Protect
Google Play Services
Google Plus
Google Science Fair
google search
Google Sheets
google sign in
Google Top Geek
Google+
Google+ Communities
Google+ Hangouts
google+ sign-in
GoogleAPI
googlecloud storage
GoogleCloudPlatform
googledevs
GooglePlay
Googleplex
Goolge Lunchpad
GTG
Hackademy
hackers
Haiko
Haití
hangouts
Hangouts Remote Desktop
hardcode
Heello
honeycomb
HTML
HTML5
HTTPS
I/O
IA
IAM
IETF
IFAI
in app purchases
in-app
ingles
Ingress
instagram
integración de soluciones
interactive post
Interesante
International
International Women’s Day
IO
io15
io18
io19
iOS
IoT
istio
IU
IVR
J2EE
java
JavaScript
jelly bean
JS
JSON
Juegos
juegos html5
Kit ML
Knative
kotlin
kUBERNATES
Kubernetes
LATAM
latamRegionSur
Launchpad
Launchpad Studio
Lenovo Mirage Solo
lightbox
linux
lucero galindo
machine learning
Made with Code
Mapdata
Mapeo
maps
Maps Ad Unit
Maps API
Maps Engine
Market
Marketing
Marshmallow
MATERIAL DESIG
Material Design
mejores apps 2013
México
michelle marie
MIT
MIT Global Start-up Labs
MIT-AITI
ML
ML Kit
mobile
monetizar
mongoDB
MOOC
Motorola
Mountain View
móvil
MQTT
mr.white
mTLS
natalie villalobos
Navigation
NBA JAM
NES
Next Big Sound
Next Level
nfc
Niantic
Nik
NINTENDO
node.js
NoSQL
nube
OAuth2
Objective-C
OClock
open source
OPenApi
OS
OSS
Paas
PageSpeed
PagesSpeed
parallel18
patrones
patters
performance
permisos
Pipeline API
Pixability
pixel
Píxel
play
Play Console
Playtime
Podcast
pollito pio
Polymer
por lote
Posse
Prediction API
primer
Producto
programación
Propositos
Protocol Buffers
proyecto 20%
Push API
PYMES
python
Q
Q4
quickoffice
Rasberry Pi Zero WH
Raspberry Pi
Realtime
Reflectly
register
Release
Resources
robots.txt
Safe
SDK
Search
Security
seedbank
seguridad
SEO
servidores
Showyou
sign-in
SNES
SO
social media
Spain
SpLATAM
SQL
SQLite
Start
startup grind
Startup Launch
startup weekend
startup weekend for the planet
startupbus
startups
StayAtHome
story
Street View
subtitles
success
sw
SyScan
tablet
Tablet Optimization Tips
tabletas
takeaction
Tango
tendencias 2013
TensorFlow Developer Summit
testing
TextView
TF JAM
The Garage
The Venture City
tips G+
tips gmail
TLD
TLS
Top Experts
Top Geek
top level domain
TopExpert
topics
traducciones
Transparency Report
triggers
Tubular Labs
twilio
Tyka
TypeScript
UAC
udacity
ui
Umbrales
UNAM
unity
Unity3D
universal search
UX
Vector
VectorDrawable
video juegos
vidIQ
ViewPager
Visual Progress
Voicekit
VPC
VR
VSCode
web
Web hosting
Web móvil
WebAssembly
with google
Wizdeo
WizTracker
Women at Google
Women Techmakers
workmanager
WTM
XKCD
XML
Yifat Cohen
youtube
YouTube Analytics API
YouTube API
YouTube Data API
YouTube One Channel
YouTube Player API
Archive
2024
sept
2023
nov
oct
sept
ago
jun
may
abr
mar
ene
2022
dic
nov
oct
sept
ago
jul
jun
may
abr
mar
feb
ene
2021
dic
nov
oct
sept
ago
jul
jun
may
abr
mar
feb
2020
dic
nov
oct
sept
ago
jul
jun
may
abr
mar
feb
ene
2019
dic
nov
oct
sept
ago
jun
may
abr
mar
feb
ene
2018
dic
nov
oct
sept
ago
jul
jun
may
abr
mar
feb
2017
nov
sept
ago
jul
jun
may
abr
ene
2016
nov
oct
sept
ago
jul
jun
may
abr
mar
feb
ene
2015
dic
nov
oct
sept
ago
jul
jun
may
abr
mar
feb
ene
2014
dic
oct
sept
ago
jul
jun
may
abr
mar
feb
ene
2013
dic
nov
oct
ago
jul
jun
may
abr
mar
feb
ene
2012
dic
nov
oct
sept
ago
jul
2011
nov
oct
may
mar
2010
dic
nov
oct
sept
ago
jul
jun
may
abr
mar
feb
ene
2009
dic
nov
sept
ago
jul
jun
may
abr
mar
feb
ene
2008
oct
sept
ago
jul
jun
may
abr
mar
feb
ene
2007
dic
Feed
Desarrolladores
Eventos y Comunidad
Casos Destacados
Dicen los Expertos
Google Accelerator