Google ha elaborado varios informes en los que se recoge información sobre diversos proyectos desarrollados internamente que contribuyen a adoptar mejores medidas de seguridad. BeyondProd se basa en los conceptos de BeyondCorp: si un modelo de seguridad perimetral deja de funcionar para los usuarios finales, también deja de ser válido para los microservicios. Por lo tanto, si adaptamos la cita del informe de BeyondCorp original, quedaría así: "Las suposiciones clave de ese modelo han dejado de tener vigencia: el perímetro ya no es solo la ubicación física de la empresa [del centro de datos], ni lo que se encuentra en el interior del perímetro es ya un lugar consagrado y seguro en el que alojar dispositivos de computación personales y aplicaciones empresariales [microservicios]".\nEn este informe, detallamos la forma en la que varias piezas de la infraestructura de Google colaboran para proteger las cargas de trabajo en una arquitectura que ahora se denomina "nativa de la nube". Para obtener información general sobre la seguridad de Google, consulta el informe Descripción general del diseño de seguridad de la infraestructura de Google.\nEl contenido incluido en este documento es correcto a fecha de diciembre del 2019 y representa la situación en el momento en que se redactó. Las políticas y sistemas de seguridad de Google Cloud podrían cambiar en el futuro, ya que mejoramos constantemente la protección que ofrecemos a nuestros usuarios.\nEn este documento se utilizan las definiciones expuestas a continuación:\nUn microservicio divide las tareas concretas que una aplicación debe realizar en distintos servicios. Cada uno de estos servicios puede desarrollarse y gestionarse de manera independiente, con su propia gestión de APIs, lanzamientos, escalados y cuotas. En una arquitectura más moderna, cualquier aplicación (por ejemplo, un sitio web) puede ejecutarse como una colección de microservicios en lugar de como un único servicio monolítico. Los microservicios son independientes, modulares, dinámicos y efímeros. Se pueden distribuir entre muchos hosts, clústeres o incluso nubes diferentes.\nUna carga de trabajo es una tarea única que completa cualquier aplicación. En una arquitectura de microservicios, una carga de trabajo podría ser uno o varios microservicios.\nUna tarea es una instancia de un microservicio que ejecuta alguna parte de una aplicación.\nTodo microservicio utiliza una identidad de servicio para autenticarse ante otros servicios que se ejecutan en la infraestructura.\nUna malla de servicios es una capa de la infraestructura destinada a las comunicaciones entre servicios. Sus funciones son controlar el tráfico, aplicar políticas y monitorizar de forma centralizada las llamadas de servicio. Cuando se usa una arquitectura de microservicios, se suprime la carga que soporta cada uno de los servicios a la hora de implementar estos controles. Asimismo, se consigue simplificar y centralizar la gestión entre numerosos microservicios.\nLa infraestructura de Google despliega cargas de trabajo en forma de microservicios en contenedores y las gestiona mediante Borg, nuestro sistema de orquestación de contenedores. Este sistema es la inspiración y el modelo en el que se sustenta lo que hoy se conoce como "arquitectura nativa de la nube".\nLa seguridad ha estado en el foco del diseño de la infraestructura de Google desde su concepción. Nuestra infraestructura no presupone la confianza entre sus servicios.\nGoogle brinda protección a sus microservicios por medio de una iniciativa denominada BeyondProd. Esta protección abarca la forma en la que el código se modifica y la manera de acceder a los datos de usuario de los microservicios. BeyondProd aplica conceptos como los siguientes: puntos de conexión de servicio autenticados mutuamente, seguridad de transporte, terminación perimetral con balanceo de carga global y protección frente a denegación de servicio, procedencia de código integral y zonas de pruebas de entornos de ejecución.\nAl pasar de un modelo de seguridad tradicional a uno nativo de la nube tuvimos que hacer cambios en dos áreas fundamentales: nuestra infraestructura y nuestro proceso de programación. La inclusión de componentes compartidos en un tejido común que envuelve y conecta a todos los microservicios (también conocida como "malla de servicios") facilitó el lanzamiento de cambios y la consecución de un grado de seguridad coherente entre servicios.\nGoogle empezó a usar un sistema de orquestación de contenedores para lograr un mayor aprovechamiento de los recursos, crear aplicaciones de alta disponibilidad y simplificar el trabajo de los programadores de Google. Al pasar a una infraestructura en contenedores también teníamos otra motivación: alinear nuestros controles de seguridad con nuestra arquitectura. Teníamos claro que un modelo de seguridad basado en perímetros no era lo suficientemente seguro. Si un atacante lograra traspasar el perímetro, podría moverse con total libertad dentro de la red. Aunque constatamos que necesitábamos controles de seguridad más robustos en toda nuestra infraestructura, también queríamos que nuestros programadores pudieran escribir y desplegar aplicaciones seguras fácilmente, sin tener que implementar funciones de seguridad por su cuenta.\nEl cambio de aplicaciones monolíticas a microservicios distribuidos y desplegados en contenedores por medio de un sistema de orquestación tuvo ventajas operativas evidentes, ya que conseguimos simplificar la gestión y la escalabilidad. Esta arquitectura nativa de la nube precisaba un modelo de seguridad diferente dotado con herramientas diferentes para proteger los despliegues y que estuviera alineado con las ventajas de gestión y escalabilidad de los microservicios.\nEn este documento, se describe cómo se implementa en Google la seguridad nativa de la nube, que aquí se denomina BeyondProd. Entre los temas que se incluyen, puedes encontrar información sobre cómo afecta a la seguridad el cambio a un modelo nativo de la nube, cuáles son los principios de seguridad relativos a la seguridad nativa de la nube, cuáles son los sistemas diseñados para abordar estos requisitos y algunos consejos sobre cómo abordar tú mismo cualquier cambio similar.\nSeguridad nativa de la nube en Google\nYa en sus inicios, Google tomó la decisión consciente de crear su capacidad de centros de datos a partir de servidores genéricos de bajo coste, en vez de invertir en hardware de alta disponibilidad más caro. La filosofía que rige nuestra fiabilidad era, y sigue siendo, la creencia de que todas las piezas de un sistema deberían poder fallar sin que la disponibilidad de los servicios que ven los usuarios se vea afectada. Conseguir este grado de disponibilidad exigió ejecutar instancias redundantes de servicios para que ningún fallo se tradujera en interrupciones. El producto de esta filosofía fue el desarrollo de contenedores, microservicios y orquestación de contenedores para gestionar de forma escalable el despliegue de estos sistemas altamente redundantes y distribuidos.\nUna infraestructura en contenedores implica que cada una de las cargas de trabajo se despliega con su propio conjunto de contenedores inmutables, móviles y programables. Para gestionar estos contenedores internamente, desarrollamos un sistema de orquestación de contenedores denominado Borg1, que aún utilizamos en la actualidad para desplegar varios miles de millones de contenedores a la semana.\nGracias a los contenedores, se simplificó la forma de empaquetar binarios y reprogramar cargas de trabajo entre máquinas. Gracias a los microservicios, se simplificaron los procesos de programación y depuración de las distintas secciones de las aplicaciones. La combinación de microservicios y contenedores permite dividir las cargas de trabajo en unidades más pequeñas y fáciles de gestionar con fines de mantenimiento y detección. El cambio a una infraestructura en contenedores con una arquitectura de microservicios se conoce como la "adopción de un modelo nativo de la nube". Los servicios se ejecutan dentro de contenedores que Borg se encarga de desplegar. Esta arquitectura escala las cargas de trabajo según sea necesario: si sube la demanda de una carga en concreto, podrá haber varias máquinas ejecutando copias del mismo servicio para gestionar el nivel de carga de trabajo que se precise.\nGoogle destaca porque ha tenido en cuenta la seguridad en todas las fases evolutivas de su arquitectura. El concepto más moderno de seguridad nativa de la nube se podría comparar con lo que Google ha utilizado durante mucho tiempo para mantener segura su infraestructura. Nuestro objetivo al crear esta arquitectura de microservicios y este proceso de desarrollo es abordar los problemas de seguridad en las fases tempranas del ciclo de desarrollo y despliegue (ya que estos son los momentos en los que la resolución de problemas es menos costosa) y, además, hacerlo de forma normalizada y uniforme. El resultado final es que los programadores dedican menos tiempo preocupándose por la seguridad y, a la vez, consiguen resultados más seguros.\nMigración a una arquitectura nativa de la nube\nLas arquitecturas de seguridad modernas han dejado atrás el tradicional modelo de seguridad basado en perímetros, en el que un cortafuegos protegía el perímetro y se daba plena confianza a los usuarios o los servicios que estuvieran dentro. BeyondCorp fue una de las respuestas al cambio en la forma de trabajar que ha experimentado el usuario corporativo de hoy en día. En la actualidad, los usuarios son móviles y tienden a operar fuera del perímetro de seguridad convencional de la organización; por ejemplo, desde una cafetería, un avión o cualquier otro lugar. Con BeyondCorp, prescindimos del concepto de una red corporativa con privilegios y accesos autorizados basada únicamente en credenciales y atributos de dispositivo y usuario, y en la que no importa la ubicación de red de los usuarios.\nEn la seguridad nativa de la red, los servicios se abordan con la misma inquietud que se plantea respecto de los usuarios: en un mundo nativo de la nube, la protección de la red de producción, así como de la red corporativa, no puede depender solo de un cortafuegos. Del mismo modo que no todos los usuarios utilizan la misma ubicación física o el mismo dispositivo, no todos los programadores despliegan código en el mismo entorno. BeyondProd permite que los microservicios, los cuales deben estar seguros en cualquier ubicación, se ejecuten en centros de datos provistos de cortafuegos, pero también en nubes públicas, en nubes privadas o en servicios alojados por terceros.\nDel mismo modo que los usuarios se desplazan, utilizan varios dispositivos y se conectan desde ubicaciones diferentes, los microservicios también se desplazan y se despliegan en entornos diferentes entre hosts heterogéneos. Mientras que en BeyondCorp se afirma que "la confianza del usuario debería depender de características tales como el estado contextual de los dispositivos y no de la capacidad de conectarse a la red corporativa", en BeyondProd se indica que "la confianza del servicio debería depender de características tales como la procedencia del código y la identidad del servicio, no de la ubicación dentro de la red de producción (por ejemplo, la identidad basada en la dirección IP o el nombre del host)".\nDesarrollo nativo de la nube y de aplicaciones\nUn modelo de seguridad más tradicional, que base su sistema de seguridad en perímetros, no tiene la capacidad necesaria para proteger una arquitectura nativa de la nube. Analiza este ejemplo: una aplicación monolítica que emplea arquitectura de tres niveles se despliega en un centro de datos corporativo privado cuya capacidad es suficiente para gestionar cargas máximas para eventos críticos. Las aplicaciones con requisitos específicos de hardware o redes se despliegan en máquinas concretas cuyas direcciones IP suelen ser fijas. Los lanzamientos se realizan con poca frecuencia, son voluminosos y es difícil coordinarlos, ya que los cambios resultantes afectan simultáneamente a muchas secciones de la aplicación. Esto se traduce en aplicaciones de muy largo recorrido que se actualizan con menos frecuencia y cuyos parches de seguridad se implementan con menos regularidad.\nSin embargo, en un modelo nativo de la nube, los contenedores desvinculan los binarios que tu aplicación necesita del sistema operativo del host subyacente y dotan a tus aplicaciones de mayor portabilidad. Los contenedores están diseñados para un uso inmutable, por lo que no cambian tras su despliegue, lo que explica que a menudo se vuelvan a crear y a desplegar. Las tareas se escalan para gestionar la carga, de tal forma que se despliegan tareas nuevas cuando la carga se incrementa y se eliminan las que ya existen cuando esta se reduce. Ya que los contenedores se reinician, se eliminan y se reprograman a menudo, el hardware y las redes también se reutilizan y se usan de forma compartida con más frecuencia. Gracias a un proceso normalizado y compartido de compilación y distribución, el proceso de programación gana en coherencia y uniformidad entre los equipos, aunque estos gestionen la programación de sus microservicios de manera independiente. Por lo tanto, los aspectos relativos a la seguridad (por ejemplo, las revisiones de seguridad, los análisis de código y la gestión de vulnerabilidades) se pueden desarrollar en las primeras fases del ciclo de programación.\nHemos analizado en detalle por qué el modelo de interiores no confiables con usuarios de BeyondCorp también es aplicable a los microservicios de BeyondProd, pero ¿cómo funciona este cambio realmente? En la tabla 1 se comparan algunos aspectos de la seguridad de las infraestructuras tradicionales y sus equivalentes en una arquitectura nativa de la nube. También se exponen los requisitos necesarios para migrar de un modelo a otro. En el resto de esta sección se ofrecen más detalles sobre cada fila de la tabla.\nSeguridad de una infraestructura tradicional\nRequisitos implícitos de la seguridad nativa de la nube\nSeguridad basada en perímetros (es decir, un cortafuegos); las comunicaciones internas se consideran de confianza. Seguridad basada en los principios de confianza cero con verificación de comunicaciones entre servicios y sin confianza implícita para los servicios del entorno. Protección de la red en el perímetro (sigue vigente) e inexistencia de confianza mutua inherente entre los servicios.\nDirecciones IP y hardware fijos para determinadas aplicaciones. Mayor grado de aprovechamiento, reutilización y uso compartido de recursos, incluidos IP y hardware. Ejecución de código de procedencia conocida por parte de máquinas de confianza.\nIdentidad basada en direcciones IP. Identidad basada en servicios.\nEjecución de servicios en una ubicación conocida y prevista. Los servicios se pueden ejecutar en cualquier ubicación del entorno, incluidos despliegues híbridos en la nube pública y centros de datos privados.\nIntegración de requisitos específicos de seguridad en todas las aplicaciones e implementación de estos por separado. Integración de requisitos de seguridad compartidos en pilas de servicios en cumplimiento de una política centralizada de implementaciones. Puntos críticos destinados a lograr una implementación coherente de políticas en los servicios.\nImposición de restricciones limitadas al modo de crear y revisar servicios. Implantación coherente de los requisitos de seguridad en todos los servicios.\nSupervisión limitada de los componentes de seguridad. Vista centralizada de las políticas de seguridad y de su cumplimiento.\nLanzamientos especializados y poco frecuentes. Proceso normalizado de compilación y lanzamiento y mayor frecuencia de cambios en microservicios concretos. Simplificación, automatización y normalización del lanzamiento de cambios.\nLas cargas de trabajo tienden a desplegarse en forma de máquinas virtuales o en hosts físicos y utilizan máquinas físicas o hipervisores para proporcionar aislamiento. Las cargas de trabajo con paquetes de binarios y los procesos de estas se ejecutan en un sistema operativo compartido, por lo que se precisa un mecanismo que las aísle. Aislamiento entre cargas de trabajo que compartan sistema operativo.\nTabla 1: Requisitos implícitos de seguridad para realizar una migración a una arquitectura nativa de la nube\nDe seguridad basada en perímetros a seguridad basada en los principios de confianza cero\nEn el modelo de seguridad tradicional, la protección de las aplicaciones de una organización frente al tráfico entrante posiblemente dependiera de un cortafuegos externo dispuesto en torno a su centro de datos privado. En un entorno nativo de la nube, aunque sigue siendo necesario proteger el perímetro de red (al igual que en el modelo de BeyondCorp), el modelo de seguridad basado en perímetros ya no es suficiente. Esto no plantea un nuevo problema de seguridad, sino que viene a destapar el hecho de que si un cortafuegos no es capaz de proteger totalmente la red corporativa, tampoco podrá hacerlo con la red de producción. El modelo de seguridad de confianza cero conlleva la pérdida de la confianza implícita en el tráfico interno: requiere otros controles de seguridad, tales como la autenticación y el encriptado. Paralelamente, el cambio hacia los microservicios brinda la oportunidad de reconsiderar la idoneidad del modelo de seguridad tradicional. A medida que te vayas independizando del perímetro de red (por ejemplo, un cortafuegos), podrás ir segmentando aún más la red por servicio. Para desarrollar esta idea, podrías implementar una segmentación a nivel de microservicio, procurando que no haya confianza inherente entre los servicios. Con los microservicios, el tráfico posiblemente experimente niveles variables de confianza según el control que manejes, pues ya no compararás únicamente el tráfico interno con el externo.\nDe IP y hardware fijos a un mayor uso compartido de recursos\nEn el modelo de seguridad tradicional, las aplicaciones de las organizaciones se desplegaban en máquinas concretas y sus direcciones IP rara vez cambiaban. Esto suponía que las herramientas de seguridad podían basarse en una asignación arquitectónica relativamente estática que vinculaba aplicaciones de un modo predecible: las políticas de seguridad de herramientas tales como los cortafuegos podían utilizar direcciones IP a modo de identificadores.\nSin embargo, en un mundo nativo de la nube, en el que se comparten hosts y las tareas cambian con frecuencia, el uso de un cortafuegos para controlar accesos entre microservicios deja de tener utilidad. Ya no se puede contar con que una dirección IP concreta vaya a estar asociada a un servicio determinado. Por lo tanto, en lugar de basar la identidad en una dirección IP o en el nombre de un host, esta se vincula a un servicio.\nDe implementaciones de seguridad específicas de aplicaciones a integración de requisitos de seguridad compartidos en pilas de servicios\nEn el modelo de seguridad tradicional, cada una de las aplicaciones se encargaba de cumplir sus propios requisitos de seguridad de manera independiente respecto de otros servicios. Entre esos requisitos se encontraban la gestión de identidades, la terminación SSL/TLS y la gestión del acceso a los datos. Esto se traducía a menudo en implementaciones incoherentes o problemas de seguridad pendientes de resolución debido a que debían rectificarse en demasiados lugares, lo que dificultaba la aplicación de correcciones.\nEn un mundo nativo de la nube, los diversos servicios reutilizan los componentes con mucha más frecuencia, y la existencia de puntos críticos permite la implementación sistemática de políticas entre los servicios. Es posible implementar políticas diferentes a través de servicios de seguridad diferentes. En lugar de exigir a cada una de las aplicaciones que implemente por separado servicios de seguridad críticos, puedes dividir las distintas políticas en microservicios independientes (por ejemplo, una política que garantice el acceso autorizado a datos de usuario y otra que garantice el uso de suites actualizadas de algoritmos de cifrado TLS).\nDe procesos de lanzamiento especializados y poco frecuentes a procesos normalizados con lanzamientos más frecuentes\nEn el modelo de seguridad tradicional, el número de servicios compartidos era limitado. La combinación de un código más distribuido y una programación local denotaban la dificultad de determinar las repercusiones de un cambio que afectaba a muchas secciones de una aplicación; por ello, los lanzamientos eran poco frecuentes y difíciles de coordinar. Para hacer cualquier cambio, es posible que los programadores tuvieran que actualizar cada componente directamente (por ejemplo, accediendo a una máquina virtual a través de SSH para actualizar un parámetro). En términos generales, esto dio lugar a aplicaciones de recorrido extremadamente largo. Desde el punto de vista de la seguridad, cuanto más distribuido estaba el código, más difícil era su revisión, y más complicado aún resultaba garantizar que la corrección de cualquier vulnerabilidad se aplicara en todos los sitios donde debía aplicarse. El cambio al modelo nativo de la nube, en el que los lanzamientos son frecuentes y están normalizados, permite a la seguridad realizar cambios en fases tempranas ("shift left"2) del ciclo de la programación de software. Se posibilita así una implementación más sencilla y coherente del mantenimiento de la seguridad, incluida la implantación regular de parches de seguridad.\nDe cargas de trabajo aisladas mediante máquinas físicas o hipervisores a cargas con paquetes de binarios que se ejecutan en la misma máquina, con la consiguiente necesidad de mayor aislamiento\nEn el modelo de seguridad tradicional, las cargas de trabajo se programaban en sus propias instancias y no había recursos compartidos. El contorno de la máquina y la red que alojaban la aplicación demarcaban el límite de esta, y la única forma de implementar el aislamiento de la carga de trabajo consistía en recurrir a la separación física de hosts, a hipervisores y a cortafuegos convencionales.\nEn un mundo nativo de la nube, las cargas de trabajo se crean en contenedores en hosts y recursos compartidos, donde también se sintetizan a modo de paquetes de binarios. Por lo tanto, tienes que contar con un mayor aislamiento entre las cargas de trabajo. Las cargas de trabajo se pueden separar en microservicios, que se aíslan entre sí en parte por medio de controles de red y tecnologías de zonas de pruebas.\nCon el desarrollo de una arquitectura nativa de la nube, pretendíamos reforzar de forma simultánea toda nuestra seguridad; así que desarrollamos y optimizamos los siguientes principios de seguridad:\nProtección de redes en el perímetro, de forma que las cargas de trabajo queden aisladas de los ataques a la red y del tráfico no autorizado procedente de Internet. El enfoque basado en cortafuegos, aunque no es un concepto novedoso para el modelo nativo de la nube, sigue formando parte de las prácticas recomendadas en materia de seguridad. En un mundo nativo de la nube, el enfoque perimetral sirve para proteger tantos componentes de la infraestructura como sea posible frente al tráfico no autorizado y posibles ataques procedentes de Internet (por ejemplo, ataques de denegación de servicio por volumen).\nInexistencia de confianza mutua inherente entre servicios, de tal forma que solo pueden hacer uso del servicio las llamadas conocidas, de confianza y portadoras de una autorización específica. Se impide así que los atacantes utilicen código no confiable para acceder a los servicios. Si un servicio sufre una vulneración, este principio evita que el atacante lleve a cabo acciones que le permitan ampliar su alcance. Esta desconfianza mutua contribuye a limitar el alcance de cualquier posible vulneración.\nEjecución por parte de máquinas de confianza de código cuya procedencia sea conocida, de forma que se obligue a las identidades de servicio a utilizar solo código y configuraciones autorizados, así como a ejecutarse solo en entornos autorizados y verificados.\nPuntos críticos destinados a lograr una implementación coherente de políticas en los servicios. Por ejemplo, un punto crítico que sirva para verificar solicitudes de acceso a datos de usuario, de tal forma que el acceso a cualquier servicio proceda de una solicitud validada proveniente de un usuario final que cuente con autorización y que el acceso de administrador requiera una justificación empresarial.\nSimplificación, automatización y normalización del lanzamiento de cambios, de tal forma que se pueda revisar con facilidad cómo los cambios en la infraestructura repercuten en la seguridad y para que se puedan lanzar los parches de seguridad ocasionando el mínimo impacto posible en la producción.\nAislamiento entre cargas de trabajo que compartan sistema operativo, de tal forma que sea imposible que la vulneración de cualquier servicio afecte a la seguridad de otra carga que se ejecute en el mismo host. Se limita así el alcance de cualquier posible vulneración.\nLa meta que perseguimos en toda nuestra infraestructura es contar con una seguridad automatizada que no dependa de personas. La seguridad debería escalarse en la misma medida que lo hagan los servicios. Los servicios deberían ser seguros de manera predeterminada e inseguros de manera excepcional: las acciones humanas deberían ser una excepción, no una rutina, además de auditables cada vez que ocurran. De ese modo, podremos autenticar un servicio en función del código y la configuración desplegados para el servicio, en lugar de las personas que lo desplegaron.\nLa implementación de estos principios de seguridad en su conjunto equivale a que los contenedores y los microservicios que se ejecutan en el interior de estos pueden desplegarse, comunicarse entre sí y ejecutarse en paralelo sin debilitar las propiedades de cualquier arquitectura nativa de la nube (es decir, la gestión sencilla de las cargas de trabajo, el escalado sin operaciones y el empaquetado de binarios eficaz). Todo esto se puede lograr sin que los detalles de seguridad e implementación de la infraestructura subyacente supongan una carga para los programadores de los microservicios.\nServicios de seguridad internos de Google\nPara proteger la infraestructura nativa de la nube de Google, hemos diseñado y desarrollado diferentes herramientas y servicios internos. Los servicios de seguridad que enumeramos a continuación funcionan de forma cooperativa para abordar las directrices definidas en la sección Principios de seguridad:\nGoogle Front End (GFE): se encarga de terminar las conexiones procedentes del usuario final y proporciona un punto centralizado para implementar las prácticas recomendadas en materia de TLS. A pesar de que hemos dejado de hacer hincapié en la seguridad basada en perímetros, GFE sigue siendo una parte importante de nuestra estrategia de protección de los servicios internos frente a los ataques de denegación de servicio. GFE es el primer punto de entrada a Google de cualquier conexión de usuario; una vez que este accede a nuestra infraestructura, GFE también se encarga del balanceo de carga y del redireccionamiento del tráfico entre regiones según sea necesario. En nuestra infraestructura, GFE es el proxy perimetral que enruta el tráfico al microservicio pertinente.\nSeguridad de transporte en la capa de la aplicación (ALTS): se emplea con fines de autenticación, integridad y encriptado de RPC. ALTS es un sistema de encriptado durante el transporte y autenticación mutua para los servicios de la infraestructura de Google. Las identidades están, por lo general, vinculadas a los servicios en lugar de a un nombre de servidor o host específicos. Se aporta así fluidez a la replicación de microservicios, al balanceo de carga y a la reprogramación entre hosts.\nLa autorización binaria para Borg y la integridad de hosts sirven para verificar la integridad de microservicios y máquinas, respectivamente:\nAutorización binaria para Borg (BAB): mecanismo de comprobación del cumplimiento en el momento del despliegue que se asegura de que el código cumpla los requisitos de seguridad internos antes de ser desplegado. BAB comprueba, por ejemplo, que un segundo ingeniero revisa los cambios, que el código se envía a nuestro repositorio de código fuente y que los binarios se compilan de forma verificable en infraestructuras dedicadas. En nuestra infraestructura, BAB restringe el despliegue de microservicios que no cuenten con autorización.\nIntegridad de hosts (HINT): verifica la integridad del software de sistemas de hosts a través de un proceso de arranque seguro y, cuando existe compatibilidad, tiene el respaldo de un hardware seguro de microcontrolador. HINT comprueba, por ejemplo, si se incluye la verificación de firmas digitales en el BIOS, el BMC, el bootloader y el kernel del sistema operativo.\nLa política de acceso a servicios y las incidencias contextuales de usuarios finales sirven para restringir el acceso a los datos:\nPolítica de acceso a servicios: limita la forma de acceder a datos entre los servicios. Cada vez que se envía una RPC de un servicio a otro, la política de acceso a servicios define las políticas de autenticación, autorización y auditoría que se necesitan para acceder a los datos del servicio receptor. De este modo, se restringe la forma de acceso a los datos, se concede el nivel mínimo de acceso necesario y se especifican las opciones de auditar ese acceso. En la infraestructura de Google, la política de acceso a servicios limita el acceso de un microservicio a los datos de otro y permite realizar análisis globales de controles de acceso.\nIncidencias contextuales de usuarios finales (EUC): un servicio de autenticación de usuarios finales emite estas incidencias, que prestan servicios con una identidad de usuario que es independiente de su identidad de servicio. Se trata de credenciales protegidas por integridad, emitidas de forma centralizada y susceptibles de reenvío que certifican la identidad del usuario final que haya solicitado el servicio. Se reduce así la necesidad de que haya confianza entre servicios, ya que la identidad de emparejamiento a través de ATLS no suele ser suficiente para conceder acceso y tales decisiones de autorización tienden a basarse también en la identidad del usuario final.\nHerramientas de Borg para despliegues azul-verde:3 este conjunto de herramientas se encarga de migrar cargas de trabajo en ejecución cuando se realizan tareas de mantenimiento. Se despliega una nueva tarea de Borg, además de la que ya existe, y un balanceador de carga va traspasando tráfico de una a otra. Se posibilita así la actualización de un microservicio sin que haya periodo inactivo alguno y sin que el usuario se dé cuenta. Estas herramientas sirven para aplicar mejoras a los servicios cada vez que les añadimos nuevas funciones, así como para aplicar actualizaciones de seguridad críticas sin que haya periodos inactivos (por ejemplo, para los errores heartbleed y las vulnerabilidades Spectre/Meltdown). En cuanto a los cambios que afectan a la infraestructura de Google Cloud, empleamos un proceso de migración activa para asegurarnos de que no afecten a las cargas de trabajo de las máquinas virtuales.\nLa herramienta que utilizamos para aislar cargas de trabajo es gVisor. Esta utiliza un kernel de espacio de usuario para interceptar y gestionar syscalls, con lo que se reducen la interacción con el host y la posible superficie de ataque. Este kernel proporciona la mayor parte de la funcionalidad que se necesita para ejecutar una aplicación y limita la superficie del kernel del host a la que puede acceder la aplicación. En la infraestructura de Google, gVisor figura entre las varias herramientas importantes que se utilizan para aislar entre sí las cargas de trabajo internas y las de clientes de Google Cloud que se ejecutan en el mismo host.\nEn la tabla 2, se asigna cada uno de los principios de seguridad descritos en la sección del mismo nombre a la herramienta correspondiente que utilizamos para implementarlo.\nPrincipio de seguridad Herramienta o servicio de seguridad internos de Google\nProtección de la red en el perímetro Google Front End (GFE), para gestionar la terminación de TLS y las políticas de tráfico entrante\nInexistencia de confianza mutua inherente entre los servicios Seguridad de transporte en la capa de la aplicación (ALTS), para las identidades de servicio y para la autenticación, la integridad y el encriptado de RPC\nEjecución de código de procedencia conocida por parte de máquinas de confianza Autorización binaria para Borg (BAB), para verificar la procedencia del código\nIntegridad de hosts (HINT), para verificar la integridad de las máquinas\nPuntos críticos destinados a lograr una implementación coherente de políticas en los servicios Política de acceso a servicios, para limitar la forma de acceder a datos entre los servicios\nIncidencias contextuales de usuarios finales (EUC), para certificar la identidad del solicitante original\nSimplificación, automatización y normalización de la implementación de cambios Herramienta de Borg, para realizar despliegues azul-verde\nAislamiento entre cargas de trabajo que compartan sistema operativo gVisor, para aislar cargas de trabajo\nTabla 2: Principios y herramientas de seguridad para implementar la seguridad nativa de la nube en Google\nEn esta sección, describimos cómo se acoplan los componentes analizados hasta ahora para entregar las solicitudes de usuario en un mundo nativo de la nube. Para ello utilizamos dos ejemplos: en el primero, rastreamos una solicitud de datos de usuario típica desde su creación hasta su entrega en destino y, en el segundo, rastreamos un cambio de código desde la programación hasta la producción. No todas las tecnologías mencionadas aquí se utilizan en todas las partes de la infraestructura de Google, sino que ello depende de los servicios y las cargas de trabajo.\nComo se muestra en la figura 1, cuando GFE recibe la solicitud de un usuario (paso 1), este servicio termina la conexión TLS y reenvía la solicitud al frontend del servicio correspondiente mediante ALTS4 (paso 2). El frontend de la aplicación autentica la solicitud del usuario mediante un servicio de autenticación de usuarios finales (EUA) centralizado y, si es correcta, recibe una incidencia contextual de usuarios finales (EUC) criptográfica de corta duración (paso 3).\nFigura 1: Controles de seguridad de la arquitectura nativa de la nube de Google: acceso a datos de usuario\nA continuación, el frontend de la aplicación hace una RPC a través de ALTS a un servicio de backend de almacenamiento y reenvía la incidencia EUC en la solicitud de backend (paso 4). El servicio de backend utiliza la política de acceso a servicios para asegurarse de que se cumpla lo siguiente:\nLa identidad ALTS del servicio de frontend tiene autorización para realizar solicitudes al servicio de backend y presentar una incidencia EUC.\nLa identidad del frontend está protegida por nuestra autorización binaria para Borg (BAB).\nLa incidencia EUC es válida.\nEl servicio de backend comprueba entonces que el usuario de la incidencia EUC tenga la autorización para acceder a los datos solicitados. Si alguna de estas comprobaciones fracasa, se rechaza la solicitud. En muchos casos, hay una cadena de llamadas de backend, cada uno de los servicios intermediarios somete a las RPC entrantes a una verificación de política de acceso a servicios y la incidencia EUC se reenvía con RPC salientes. Si estas comprobaciones prosperan, los datos se devuelven al frontend de la aplicación autorizada y se entregan al usuario autorizado.\nCada una de las máquinas cuenta con una credencial ALTS que se aprovisiona a través del sistema HINT, y que solo se puede desencriptar si HINT ha verificado que la máquina se inició correctamente. La mayoría de los servicios de Google se ejecutan en forma de microservicios sobre Borg, cada uno de los cuales tiene su propia identidad ALTS. El borgmaster5 otorga estas credenciales ALTS de microservicios a cargas de trabajo en función de la identidad del microservicio, como se describe en la figura 1. Las credenciales ALTS de nivel de máquina forman el canal seguro destinado a aprovisionar credenciales de microservicios, de modo que solo las máquinas que hayan superado el inicio verificado por HINT puedan alojar cargas de trabajo de microservicios.\nComo se muestra en la figura 2, cada vez que un Googler hace un cambio en un microservicio protegido por una BAB cuya solidez esté acreditada, el cambio debe enviarse a nuestro repositorio central de código, que aplica una revisión de código. Una vez aprobado, el cambio se envía al sistema de compilación central y confiable, que genera un paquete que incluye un certificado de archivo de manifiesto de compilación verificable y firmado (paso 1). En el momento del despliegue, BAB verifica que se haya seguido este proceso validando el certificado firmado procedente del flujo de procesamiento de compilación (paso 2).\nFigura 2: Controles de seguridad de la arquitectura nativa de la nube de Google: cambios en el código\nTodas las actualizaciones de las cargas de trabajo se gestionan a través de despliegues azul-verde, ya se trate de un lanzamiento rutinario o de un parche de seguridad urgente (paso 3). GFE balancea la carga del tráfico de modo que vaya dirigido al nuevo despliegue para garantizar la continuidad de las operaciones.\nTodas las cargas de trabajo precisan aislamiento. Si la carga de trabajo es menos confiable —porque, por ejemplo, la carga tenga varios propietarios o la procedencia del código fuente sea ajena a Google—, se puede desplegar en un entorno protegido por gVisor, o se pueden usar otras capas de aislamiento. Este aislamiento garantiza que, en caso de que una de las instancias de la aplicación sufra una vulneración, las demás instancias no se vean afectadas.\nImplementación de BeyondProd\nGracias a la conversión a una arquitectura nativa de la nube y a la creación de medidas de seguridad para dicha infraestructura, Google está en condiciones de ofrecer propiedades de seguridad muy sólidas para sus cargas de trabajo internas y externas (Google Cloud).\nLa creación de componentes compartidos permite minimizar la carga que soportan los programadores al tener que cumplir requisitos de seguridad comunes. En un escenario ideal, la funcionalidad de seguridad apenas debería exigir integración en cada aplicación y habría de proporcionarse como un tejido que envolviera y conectara todos los microservicios. Esta es una característica que conocemos como "malla de servicios". Esto significa, además, que la seguridad se puede gestionar e implementar por separado a partir de actividades rutinarias de programación y despliegue.\nCambio hacia el modelo nativo de la nube\nLa transición de Google hacia el modelo nativo de la nube requirió cambios en dos áreas principales: nuestra infraestructura y nuestro proceso de programación. Aunque los abordamos simultáneamente, estos cambios se podrían haber desvinculado y abordado de manera independiente.\nCambio de nuestra infraestructura\nComenzamos levantando una sólida base de identidad, autenticación y autorización de servicios. Los cimientos que construimos a modo de identidades de servicio confiables nos permitieron implementar funciones de seguridad de nivel superior que dependieran de la validación de estas identidades, como la política de acceso a servicios y las incidencias EUC. Con el objetivo de agilizar esta transición para los servicios nuevos y actuales, el sistema ALTS se proporcionó inicialmente como biblioteca con un único daemon auxiliar. Este daemon se ejecutaba en el host al que llamaban todos los servicios y con el tiempo evolucionó hasta convertirse en una biblioteca que utilizaba credenciales de servicios. La biblioteca de ALTS se integró a la perfección en la biblioteca principal de RPC, lo que facilitó su amplia adopción, y no impuso una carga significativa a equipos de programación concretos. El lanzamiento de ALTS era un requisito previo para lanzar los servicios de política de acceso a servicios y de incidencias EUC.\nCambio de nuestros procesos de programación\nPara Google fue crucial establecer un proceso sólido de compilación y revisión de código. Esto nos permitió garantizar la integridad de los servicios en ejecución y el sentido de las identidades utilizadas por ALTS. Establecimos un proceso de compilación centralizado que nos permitía comenzar a aplicar requisitos, como la revisión de código por dos personas y la realización automatizada de pruebas en las fases de compilación y despliegue. Consulta el informe Autorización binaria para Borg si quieres más información sobre el despliegue.\nTras levantar la estructura básica, comenzamos a abordar la necesidad de ejecutar código externo y no confiable en nuestros entornos. Para ello, comenzamos a trabajar creando zonas de pruebas: primero con ptrace; luego, con gVisor. Del mismo modo, los despliegues azul-verde aportaron una ventaja notable en términos de seguridad (por ejemplo, en la aplicación de parches) y fiabilidad.\nNo tardamos en darnos cuenta de que todo se simplificaba si los servicios se iniciaban registrando infracciones de políticas en lugar de bloqueándolas. La ventaja de este enfoque fue doble: en primer lugar, les brindaba a los propietarios de servicios la oportunidad de probar el cambio y medir el impacto (si lo hubiera) que tendría en su servicio la migración a un entorno nativo de la nube; en segundo lugar, nos permitió corregir errores, así como identificar cualquier funcionalidad complementaria que fuera necesario proporcionar a los equipos de servicio. Por ejemplo, cuando un servicio se incorpora a BAB, los propietarios de servicios habilitan el modo de solo auditoría. Esto les facilita la identificación de código o flujos de trabajo que no cumplan con sus requisitos. Una vez que abordan los problemas indicados por el modo de solo auditoría, los propietarios de servicios se pasan al modo de cumplimiento. En gVisor esto lo logramos, en primer lugar, demarcando zonas de pruebas y asignándoles cargas de trabajo, a pesar de que ello comportara carencias de compatibilidad; y, en segundo lugar, resolviendo estas carencias sistemáticamente para mejorar la zona de pruebas.\nDel mismo modo que BeyondCorp nos ayudó a evolucionar y superar un modelo de seguridad basado en perímetros, BeyondProd representa un salto similar en nuestro enfoque sobre la seguridad de la producción. El enfoque de BeyondProd describe una arquitectura de seguridad nativa de la nube que no presupone la confianza entre servicios, proporciona aislamiento entre las cargas de trabajo, verifica que solo se desplieguen aplicaciones compiladas de manera centralizada, automatiza la gestión de vulnerabilidades e implementa sólidos controles de acceso a datos críticos. La arquitectura de BeyondProd dio pie a que Google innovara creando varios sistemas para cumplir con estos requisitos.\nCon demasiada frecuencia, la seguridad se deja para el último momento, cuando ya se ha tomado la decisión de migrar a una nueva arquitectura. La implicación de tu equipo de seguridad en las fases iniciales de implantación de una arquitectura nativa de la nube y la priorización de las ventajas de este nuevo modelo de seguridad —por ejemplo, la simplificación de la gestión de parches y el endurecimiento de los controles de acceso— posiblemente aporten ventajas significativas a los equipos de seguridad y de desarrollo de aplicaciones. La aplicación de los principios de seguridad descritos en este documento a tu infraestructura nativa de la nube permite reforzar el despliegue de tus cargas de trabajo y las medidas de protección de las comunicaciones de dichas cargas, así como controlar las repercusiones de estas medidas en otras cargas.\n1 Borg es el sistema de gestión de clústeres de Google y está concebido para programar y ejecutar cargas de trabajo a gran escala. Borg fue el primer sistema de gestión de contenedores unificado de Google y sirvió de inspiración a los creadores de Kubernetes.\n2 La expresión en inglés "shifting left" (literalmente, "desplazarse a la izquierda") hace referencia a hacer cambios en las fases tempranas del ciclo de programación de software, entre los que se pueden incluir la codificación, la compilación, la realización de pruebas, la validación y el despliegue. Los diagramas de ciclo de vida se dibujan generalmente de izquierda a derecha, por lo que la izquierda se refiere a las fases que se hacen antes.\n3 Un despliegue azul-verde es una forma de lanzar un cambio en una carga de trabajo sin afectar al tráfico entrante, de modo que los usuarios finales no experimenten periodos de inactividad al acceder a la aplicación.\n4 Para comprender mejor cómo se enruta el tráfico dentro de la infraestructura de Google desde GFE hasta un servicio, consulta la sección ¿Cómo se enruta el tráfico? de nuestro informe "Encriptado en tránsito".\n5El borgmaster es el controlador centralizado perteneciente a Borg. Se encarga de gestionar la programación de tareas y de comunicarse con las que estén en ejecución acerca de su estado.


“Y sí… lo cotidiano y fantasía” – La Cola de Rata\nPresentación en el teatrino del Santiago Londoño del grupo brasilero “La compañía Tato Criaçao Cênica”, con la obra “Tropiezo”, en el marco del 5° red festival iberoamericano de teatro de muñecos Pereira.\nGrupo: Tato Criaçao Cenica\nConcepción y actuación: Dico Ferreira y Katiane Negrão\nColaboración dramatúrgica: Juliana Capilé\nDesde la onomatopeya se canta. Un muñeco prende la luz emanada por blancas velas. Un pequeño escenario se ilumina; tan pequeño como grande y bella la historia que a partir de él se narra. Una anciana ataviada con blanco velo teje, hasta cuando se le une su compañera, quien de verde viste.\nPequeños cofres acompañan a las dos ancianas, de grandes narices y largas lenguas. Sus ojos son tan pequeños como gigantes sus manos. Se comunican en un idioma extraño. Ellas lo crearon, ellas lo comparten.\nAunque esto parece ser lo único que ambas pretenden compartir. Son egoístas, pese a que tienen el deseo de reunirse en torno a un diminuto libro el cual sale desde uno de los tantos cofres que rodean a las protagonistas. Cofres llenos de sorpresa, cofres de un tesoro escondido, de una historia que trasciende y redefine a dos personas vestidas de negro que con sus manos dan vida a dos ancianas ataviadas de curiosos y bien hechos trajes.\nPorque acaso es esta la magia del teatro y en general, del arte de contar historias. Porque lo que se ve en el pequeño escenario lleno de cofres misteriosos además de mujeres mayores son parejas, son novios, son amigos y enemigos jurados a muerte. Son niños que buscan complicidad al momento de realizar cualquier pilatuna. Lo es todo.\nLa complicidad de compartir un cigarrillo mal fumado se convierte en el placer de consumirlo solo, mientras el acompañante busca la forma de superar su eventual desventaja, lo que crea situaciones cómicas, simpáticas, en sí mismas cándidas o inocentes. Hamlet vive desde el papel y la tinta. “Tropiezo”, el o la personaje principal de la historia, vive desde dos manos. Y desde “Tropiezo” viven los libros, toman vida los cofres, las velas, los cigarrillos, el mismo humo emanado desde estos. Las sorpresas. Una botella de licor cuyo consumo al final no compartido viene precedido desde el protocolo de la católica bendición.\nY lo más importante, “Tropiezo” vive desde su compañera o compañero; desde la anciana o niño que lo acompaña, de quien es perturbado y a quien perturba. A quien quiere darle un regalo de cumpleaños, con quien se funde en un apasionado beso. Quien complementa un concierto de onomatopeyas, una fotografía iluminada por velas, las cuales, paulatinamente al igual como se prendieron, de a poco se van apagando.\nSuena la música que dio inicio a la historia. “Tropiezo” de repente ya no tiene compañía. Su andar es pesado, triste, cuando antes corría, cantaba y levitaba. Junto a un cofre ve como la última luz, más tenuemente, se apaga. Y mientras el fuego vacila entre apagarse del todo y permanecer un segundo más prendido, se extingue…\n“Tropiezo” llora en silencio. “Tropiezo” dura siempre un segundo más.\nreseña teatroteatro de muñecosTeatro en Pereira\nArtículo AnteriorLos extremos se juntan: Intocable\nArtículo siguienteConsecuencias socio ambientales de la revolución agro-minera


La polémica obra de arte en homenaje a Montoneros que causó el enojo de todos - El Cronista\nLa polémica obra de arte en homenaje a Montoneros que causó el enojo de todos\nUna polémica obra de arte se exhibió en la Casa de la Independencia para "conmemorar" la ocupación de la misma por parte de un grupo de montoneros, generando repudio generalizado.\nActualizado el 09/09/2021 11:28\nUna polémica situación se vivió durante estos días en la provincia de Tucumán, luego de que se decidió exhibir una obra de arte en la Casa de la Independencia que conmemora la toma que la agrupación clandestina Montoneros realizó en el año 1971 sobre este sitio histórico.\nLa misma pertenece a una muestra más importante que busca contar la historia de la provincia mediante la utilización de Randa, una técnica de tejido tucumana ancestral la cual se centra en la creación de obras de arte mediante el uso de telares. En el caso de la polémica obra, la misma muestra una de las pintadas realizadas por un grupo de montoneros el 15 de febrero de 1971, cuando tomaron la casa.\nLa obra estuvo presente por varios días antes de ganar reconocimiento a nivel nacional, con los turistas compartiendo en redes el particular homenaje realizado por la artista Carlota Beltrame, con el diputado nacional por la provincia de Neuquén, Francisco Sánchez, siendo el primero en criticar su inclusión.\n"¿Qué carajos hace el nombre del grupo terrorista Montoneros contaminando la Casa Histórica de Tucumán?", aseguró el legislador mediante su cuenta de Twitter, mientras que agregó: "Hay que echar al responsable de esta blasfemia".\n— Francisco Sánchez %uD83C%uDDE6%uD83C%uDDF7 (@fsancheznqn) September 3, 2021\nClases y cuarentena: cuántos chicos no aprendieron a leer ni a escribir por la pandemia\nQUE MUESTRA EL TELAR\nEn el telar se puede observar una interpretación de las pintadas realizadas por la agrupación durante la toma de 1971, con las frases "Montoneros" y "Perón Vive" siendo las más llamativas. Además, lo acompaña un texto donde se lee una frase del sociólogo francés Michael Foucault explicando la razón para hacer la obra.\nEn la misma se lee: "Es preciso saber reconocer los sucesos de la historia, sus sacudidas, sus sorpresas, sus triunfos afortunados o sus derrotas mal digeridas pues también nos hablan de nuestros comienzos y de nuestras herencias. Percibir sus peripecias, sus desviaciones ínfimas y sus retornos complejos porque los errores, los fallos de apreciación, los malos cálculos y hasta lo que pudo ser y no ha tenido lugar también han producido aquello que hoy existe y que aún pesa sobre nosotros. Descubrir que en la raíz de lo que conocemos y de lo que somos no están en absoluto la Verdad ni el Ser, sino el accidente".\nLa polémica obra exhibida.\nJunto con este texto se agrega una descripción de lo sucedido en la Casa de la Independencia: "El 15 de febrero de 1971, la Casa Histórica fue tomada por un grupo reducido de militantes montoneros, quienes, en la Sala de la Jura, realizaron una acción temeraria con consignas ligadas al peronismo de izquierda".\nPor su parte, Beltrame justificó la inclusión explicando que "forma parte de la historia oculta de Tucumán". "Había resistencia a que se conozca, por ello me interesó rememorarlo porque pertenece a esa parte ‘opaca' de la historia de nuestra provincia", explicó en una entrevista para Télam.\n"Es la traducción de una fotografía documental, que registra una de las pintadas que hizo la organización Montoneros en 1971 cuando todavía se encontraba como presidente de facto Juan Carlos Onganía", agregó la artista al explicar cómo se realizó la obra, mientras que también aseguró que la misma fue confeccionada durante dos meses "con la ayuda de un subsidio del Estado".\nQUÉ SUCEDIÓ REALMENTE EN 1971\nSegún la mayoría de los registros históricos de aquella época, el 15 de febrero de 1971 se vivió un ataque por parte de un grupo de cinco montoneros a las 7 de la mañana. Los integrantes redujeron al guardia del lugar y ocuparon la Casa de Tucumán, realizando destrozos en el Salón de Jura (donde dejaron pintadas) y el Salón Belgrano.\nDiario relatando lo sucedido en 1971.\nA las pocas horas, la organización clandestina detalló lo sucedido mediante un comunicado: "En el día de la fecha a las 7:40 horas nuestra unidad básica de combate Evita procedió a ocupar la Casa Histórica. Para ellos fue necesario reducir al personal de guardia, recuperando para la lucha del pueblo un arma y uniforme. Se ha ocupado la casa de la Independencia como homenaje y recuerdo de la independencia económica que el general Perón declarara junto al pueblo en dicho lugar en 1947".


1.-¿Qué es la CONEAU y por qué es importante? La Comisión Nacional de Evaluación y Acreditación Universitaria es un organismo ...\nEncuesta Participativa - Tu participación es importante!!! La UNMDP diseñó una encuesta ...\nCharla sobre Periodismo Digital Inscripción: click aquí En el marco del ingreso a la nueva Tecnicatura Universitaria...\nConvocatoria de la Escuela de Gobierno y Administración Pública La Escuela de Gobierno y Administración nació en Julio de este año en la Facultad...\nFinalizó la primera capacitación de la Escuela de Gobierno y Administración Pública La Escuela de Gobierno y Administración Pública de nuestra facultad en conjunto...\nPrograma Nacional de Formación de Mandos Medios de la Administración Pública en Bahía Blanca La Escuela de Gobierno y Administración Pública de nuestra facultad en conjunto...\nLa Secretaría de Vinculación con el Medio invita a participar del curso que se llevará a cabo con el objetivo de brindar herramientas y conocimientos de finanzas a profesionales de carreras universitarias no vinculadas a temáticas económicas y financieras.\nEl mismo se realizará en tres encuentros, los días lunes 25 de junio, lunes 2 de julio y martes 10 de julio de 17 a 19:30 horas en esta unidad académica (Funes 3250)\nLa capacitación es arancelada y los interesados en participar deberán inscribirse AQUÍ\nEl curso está dirigido a profesionales cuyas carreras universitarias no estén vinculadas a temáticas económicas y financieras y que tengan interés en profundizar sobre la temática; a personas sin formación previa en la temática que manifiesten necesidades concretas de adquirir conocimiento aplicado en función de su desarrollo laboral o personal.\nLa modalidad será teórico - práctica y aula taller con apoyo audiovisual y actividades individuales y grupales. Se recomendarán sitios web y otras opciones digitales para fortalecer los conceptos y habilidades financieras adquiridas.\nReconocer y comprender el nuevo entorno económico y social en el que nos desenvolvemos y su impacto sobre nuestras finanzas domésticas.\nConocer las Nuevas Finanzas: desde la banca tradicional a las nuevas formas de vinculación “sin intermediarios”. De qué se trata la llamada Economía Colaborativa.\nElaborar un autodiagnóstico de su situación financiera personal.\nEvaluar las distintas posibilidades de endeudamiento en función de su costo, plazo, moneda, garantías, etc compatibles con sus ingresos y su patrimonio.\nDiseñar estrategias de inversión acordes a su perfil personal (implicará trabajar las variables claves para la selección/rechazo y jerarquización de las mismas)\nCurso Gestión sostenible para las organizaciones de la sociedad civil\nTaller Empretec Universidad Nacional de Mar del Plata\nCurso Gestión Sostenible para las Organizaciones de la Sociedad Civil: Buenas Prácticas


Pon Fe y Esperanza en tu Vida: LOS BUHOS NO SON LO QUE PARECEN... Iluminan tu casa por la noche, las lámparas Ti vedo, de Matteo Ugolini.\nLOS BUHOS NO SON LO QUE PARECEN... Iluminan tu casa por la noche, las lámparas Ti vedo, de Matteo Ugolini.\nTomo el título de la frase de Twin Peaks, en este caso nada tiene que ver con la serie, sino con estos buhos apliques para pared y de sobremesa, la idea sencilla... buhos, pero con unos ojos que te iluminan, son raros hay que reconocer, pero el diseño de Matteo Ugolini para la marca de iluninación italiana Karman cuanto menos no deja indiferente... ¿Qué os parece las lamparas Ti vedo (te veo)?\nPero antes y para acompañar os dejo el tema principal que el compositor de origen italiano, Angelo Badalamenti creó para Twin Peaks, hay piezas que son sublimes y esta lo es sin duda, este es el enlace... la música a veces dice tanto, que sobra toda añadidura.\nSegún el diseñador, estos buhos, son «La prima lampada che ribalta il normale gesto di guardare un oggetto luminoso ... ora é la luce che guarda te!»\n(La primera lámpara que invierte el acto normal de ver un objeto brillante ... ¡ahora es la luz la que te mira a tí!.)\nY aquí tenemos al artista con parte de sus obras.\nY con este comentario me despido hasta mañana... dejemos la la vida nos ilumine!


“Para mí el olfato canino es la octava maravilla” - Blog para Emprendedoras y emprendedores\npor Desarrollo Local | Nov 29, 2018 | Emprendedores de la sierra de Guadarrama, Mujeres emprendedoras | 0 Comentarios\nIsabel, traductora de profesión, es una apasionada del mundo canino y, más concretamente, de los perros de búsqueda y detección. Un día decidió compartir su pasión y crear un foro sobre perros de búsqueda que –quince años después- se ha convertido en una web de referencia sobre temas relacionados con perros que trabajan con el olfato.\n¿Cómo tuviste la idea de emprender?\nBásicamente emprendí porque hace más de veinte años empecé a trabajar como voluntaria en un grupo de rescate con perros y, buscando información, di con foros de Estados Unidos donde la gente compartía consultas, trabajos y experiencias. En español no había apenas información sobre los perros de rescate, así que decidí iniciar mi propio foro especializado. Al poco tiempo decidí abrir una página web dedicada a los perros que trabajan con su olfato. Perros de rescate, detección de drogas, explosivos, alerta médica, etc. Hoy es un referente en este campo y cuenta con grupos de debate especializados donde se reúnen profesionales y aficionados de cada disciplina de trabajo.\nCon el tiempo, y como siempre ando metida en temas de perros, me preocupó también que en España nos quejamos mucho de que no nos dejan acceder a muchos sitios con perro. Pero aún hay mucha gente que no tiene asumido que tenemos unos deberes que cumplir como propietarios. Y para tratar de buscar solución, se me ocurrió organizar en 2014 un Flashmob con perros, a través de un grupo en Facebook y bajo el lema: “Perros educados y controlados, ¡no molestamos!”. Un día determinado, a una hora determinada, se reunían grupos de propietarios con sus perros en algún punto concurrido de una ciudad y, con una música de fondo, realizaban una serie de ejercicios. Fue el primer flashmob con perros que se hizo en España y lo repetimos durante tres años.\nA partir de aquello surgió otra página sobre perros, para seguir concienciando a los dueños para que, si quieren tener mayor acceso a lugares públicos, tienen que cumplir con sus responsabilidades.\n¿Qué es lo que más te fascina del olfato canino?\nPara mí es la octava maravilla. Para que te hagas una idea, un perro entrenado te puede detectar una gota de gasolina rebajada al 10% en una nave totalmente quemada (perros de acelerantes del fuego). Detectan personas, drogas, explosivos, células cancerígenas, bajadas de azúcar,… Hay incluso perros para detectar chinches o moho. En Estados Unidos tienen muchos problemas con el moho en las construcciones de madera y por esto allí los utilizan. En realidad hay perros detectores de casi lo que queramos, la lista es cada vez más larga.\nY no es solo que tengan un sentido del olfato desarrollado, sino que además el perro es capaz de identificar un solo olor entre miles de olores. Por eso, hasta la fecha, el olfato canino es la mejor “herramienta” para buscar y detectar. Todavía no han conseguido inventar algo que lo supere, ni siquiera que lo iguale. Es una pasada.\n¿Ahora vives de estas páginas web sobre perros?\nNo, todavía no. Hago traducciones on-line, soy distribuidora de pienso para perros y estas páginas las estoy monetizando; están dando dinero, pero no para vivir.\n¿Qué nos recomiendas para monetizar una web?\nHay varias maneras. Google Adsense, lo descarto. Ganaba muy poco, me parecía un poco “timo” tener un espacio publicitario a disposición de otros anunciantes cuando da una miseria. YouTube tampoco me ha funcionado. Lo que sí me funciona son los programas de afiliación como el de Amazon. Puedo colocar anuncios de Amazon con banners o aconsejando productos. Por ejemplo, escribo un artículo sobre el problema de los perros de trabajo en verano y enlazo algunas palabas con productos de Amazon. Si alguien compra entrando desde mi blog, me llevo una pequeña comisión.\nLuego hay plataformas de afiliación que ponen en contacto a la empresa anunciante con el medio. Ellos lanzan ofertas, te avisan de campañas que puedes aceptar o no. La empresa anunciante elige en qué páginas se quiere promocionar y elige la forma: banner, publicación en Facebook, Twitter, Instagram o lo que hayas ofrecido. Puede ser un precio cerrado o un porcentaje por cada clic en redes sociales. Esta última fórmula nunca la acepto porque el producto que anuncian casi nunca tiene que ver con el tema canino y creo que se desvirtúa su sentido, su seriedad. Lo que más utilizo es la opción de enlaces patrocinados: anuncias un producto dentro de un texto con el link al anunciante. O el formato del artículo patrocinado, aunque para este último tengo que tener muy claro que es un buen producto porque lo estoy respaldando.\nAhora estoy en trámites con una gran empresa para encontrar la forma de ayudarnos mutuamente. Ellos necesitan leads, yo necesito monetización… solo hay que buscar conjugarlo. Esa será quizás la mejor fórmula futura de monetización de las páginas.\nSe te ve muy puesta en esto del marketing on line…\nMe cuesta vender, es más, no me gusta vender. Pero es un tema que tengo que solucionar y para ello busco formación, me apunto a todos los cursos que puedo. Tengo un buen producto, una buena página bien posicionada y que no tiene competencia. Es un referente en español en temas de perros de búsqueda y detectores. No solo en España, también en Hispanoamérica.\n¿Qué más ofreces?\nDoy formación sobre temas caninos. Imparto charlas y seminarios sobre temas relacionados con perros y sobre perros de rescate, que es mi especialidad, ya que fui guía canino durante más de veinte años.\nAdemás, realizo traducciones on-line con plataformas como Gengo. Te apuntas y allí te ofrecen trabajos a un precio determinado, tú los seleccionas o no. Tengo que reconocer que no está bien pagado y que hay una verdadera “guerra” para conseguir los trabajos.\nMonetizar más mi web. Afortunadamente tengo colaboraciones dentro de la página porque hay muchas-os apasionadas-os del mundo canino que quieren aportar su granito de arena. Tenemos colaboradores que nos ayudan a buscar información nueva, hay traductores, editor de vídeos, reporteros que realizan reportajes y entrevistas, hay un dibujante que nos ofrece sus creaciones para ilustrar los artículos, y desde hace muy poco tenemos la colaboración de una fotógrafa profesional. También tenemos articulistas que colaboran en la elaboración de artículos técnicos, que es uno de nuestros pilares.\nLas redes sociales son un mundo aparte… pero yo creo que necesarias para cualquier empresa. Eso sí, hay que darles mucha vida, hay que hacer varias publicaciones diarias… Para eso tenemos colaboradores que buscan y envían contenidos, aunque también, y cada vez más, son los propios grupos y unidades caninas los que nos envían contenidos y eso facilita mucho las cosas.\n¿Colaborar es la clave?\nSí. Suele ser colaboración altruista pero trato de corresponder ofreciendo algo que le interese al colaborador. Puede ser a través de publicidad o incluso una especie de “beca”: si hay un curso canino que le interesa al colaborador, le intento conseguir una plaza a cambio de publicidad del centro en mi página.\nOtro ejemplo es el trabajo de la fotógrafa, una colaboradora recién incorporada: ella acude a eventos patrocinados por la página o simplemente que nos han invitado. Saca fotos del evento que a ella le vienen bien, a mí me sirven para utilizarlas en la página y además, para hacer publicidad del evento –que a la vez es contenido para la página- y de forma indirecta o directa, hago publicidad del trabajo de la fotógrafa. Es una especie de simbiosis, se trata de que todos ganemos algo.\nHasta ahora salimos adelante así pero mi objetivo es que la parte comercial funcione bien para mejorar la página. De hecho, creo que hay muchas posibilidades para ambas páginas.\n¿En qué te puede ayudar el Ayuntamiento como emprendedora?\nSe pueden hacer muchas cosas. Aquí en Hoyo hicimos una feria de perros hace tres años para concienciar a la gente de cómo comportarse cuando se tienen perros. Porque seamos sinceros, muchos perros o mejor dicho, muchos dueños no están bien educados y eso se traduce en pises, cacas sin recoger, bolsas de basura rotas, perros sueltos/perdidos que pueden provocar un accidente de tráfico…\nEl Ayuntamiento podría plantearse campañas de concienciación: empezando por la elección del perro, algo a lo que no se suele dar importancia y que puede suponer un problemón que desemboque incluso en abandono. Qué raza elegir, adoptar o comprar, cachorro o adulto… Y todo lo que tenga que ver con la tenencia de un perro, desde que llega, deberes, leyes…\nY luego a nivel práctico, se pueden organizar talleres de educación canina básica en grupo, algo esencial para los propietarios inexpertos. Incluso con los más aplicados se podrían proponer actividades con los perros, grupos de trabajo para hacer detección de objetos, búsqueda de personas, obediencia avanzada… podría ser muy interesante y divertido.\n¿Qué perro recomiendas para un piso?\nPara tener un perro en un piso lo principal es que lo saques todo lo que necesite. Pero no cinco minutos. Hay que darles un buen paseo, dejarles explorar, olfatear, correr, jugar… Si cubrimos esa necesidad da igual que vivamos en un piso pequeño.\nLuego sí, es importante el tema de la raza. Pero más que para un piso, es según las necesidades o el tipo de vida que lleve el dueño. Un Border Collie de trabajo por ejemplo. Es muy bonito pero no es lo más recomendable para quien no vaya a realizar actividades con él porque son muy especiales. Y esto es extensible a muchas otras razas de perro. En realidad siempre recomendaría a cualquier futuro propietario de un perro que se informe muy bien antes de elegir un perro. Pequeños, grandes… cada raza tiene sus características y es fundamental conocerlas antes de tomar la decisión.\nMi consejo es acudir a una buena protectora que te asesore bien y te recomiende un perro adecuado a tu forma de vida.\n¿Nos recomiendas protectoras?\nPuedo recomendar con cariño Abrazo Animal, porque tengo un perro que vino de allí. O ANAA, donde me consta que son muy buenos profesionales. En una protectora seria, cuando vas a por el perro te hacen un cuestionario con el fin de evitar adopciones frustradas. Además, en ANAA, cuando los perros tienen problemas, las-os trabajadoras-es se los llevan a su casa para rehabilitarles. La protectora de Cuatro Vientos, en Madrid, está bien también. Al menos hace pocos años, ya que fui a adoptar a una perrita y me encantó el trato, las explicaciones, sus preguntas y además, realizaron después un seguimiento durante algún tiempo.\nTengo tres perros; siempre me han apasionado los perros, desde pequeña. Y tengo claro que no volveré a vivir sin perro.\n¿Qué recomendarías a la gente que tiene perro?\nAdemás de sacarle a dar un paseo, es muy recomendable hacer actividades con tu perro, jugar con él, “trabajar” con él. Hoy en día hay muchas disciplinas caninas que podemos practicar, a nivel deportivo y para todos los públicos: obediencia, detección de objetos, agility, mantrailing (búsqueda de personas por rastro), pastoreo… Yo tengo dos Border Collie y a veces les llevo a pastorear ovejas a un centro que tenemos aquí cerquita, en Guadarrama. Es importante conocer las necesidades del perro y realizar actividades con él. Aunque para ser sincera, lo de la detección de objetos o la detección deportiva, es quizás lo más cómodo, les viene bien a todos y es divertidísimo. A todos los perros les gusta… y todos tienen olfato.


Los beneficios de correr son muchos. ¡Descubrélos!\n12/01/2015 12/01/2015 Laura Serra Bienestar\nCorrer es un ejercicio muy beneficioso ya que nos permite aumentar la resistencia física, perder peso y tonificar algunos grupos musculares. También se ha demostrado que nos permite prevenir numerosas enfermedades y nos ayuda a mantener un estilo de vida más saludable. Sin embargo, lo que pocos saben es que empezar a correr también es beneficioso para el cerebro.\n1. Correr mantiene joven el cerebro\nCorrer estimula la neurogénesis, es decir, el crecimiento de nuevas células nerviosas. También potencia la angiogénesis, o sea, la regeneración de los vasos sanguíneos. Ambos procesos, la neurogénesis y la angiogénesis, aumentan el volumen de tejido cerebral, que de otro modo se habría reducido como resultado del envejecimiento.\nEn un estudio publicado en la revista PNAS se pudo apreciar que los adultos mayores que corrían con regularidad mostraban un aumento en el volumen de algunas regiones del cerebro, entre ellas el hipocampo, una estructura que está íntimamente vinculada con el aprendizaje y la memoria. Por tanto, los neurocientíficos no tienen dudas: correr hace que nuestro cerebro se mantenga más joven.\n2. Correr mejora el recuerdo\nCorrer no solo preserva nuestra capacidad mnémica sino que también mejora nuestra habilidad para acceder a los recuerdos. A estas conclusiones llegó un estudio publicado en la revista Brain Sciences en el cual se analizaron a personas que atravesaban por los primeros estadios del Alzheimer.\nLos investigadores pudieron apreciar que aquellos que corrían con regularidad y hacían ejercicios aeróbicos tenían más facilidad para acceder a sus recuerdos. Los escáneres cerebrales mostraron que la clave radica en el núcleo caudado, una estructura que se encuentra justo abajo del cuerpo calloso y que no solo está involucrada en las funciones motoras sino que también sirve como soporte a los circuitos de la memoria. De hecho, las personas que corrían con frecuencia mostraron una mejoría en la calidad de las señales que se transmitían a través de estos circuitos.\n3. Correr reequilibra la química cerebral\nNumerosos estudios han demostrado que cuando corremos se producen cambios en la química a nivel cerebral ya que se estimula la producción de algunos neurotransmisores. Por ejemplo, un estudio publicado en la British Journal of Sports Medicine encontró que correr tan solo media hora en un entorno natural provoca transformaciones en la actividad cerebral similares a los que se aprecian durante la meditación. Por tanto, correr es una actividad excelente para manejar la frustración y el estrés.\nOtro estudio, esta vez publicado en la Journal of Clinic Psychiatry, ha descubierto que correr estimula la producción de serotonina y norepinefrina, sustancias que estimulan las sinapsis y que mejoran nuestro estado de ánimo. Por consiguiente, ahora no solo sabemos que correr ayuda a prevenir la depresión sino que también es una herramienta muy eficaz para luchar contra este trastorno una vez que se ha instaurado, tanto como los antidepresivos, pero sin sus efectos adversos.\nCorrer es beneficioso pero…\nAunque correr es una actividad muy beneficiosa y no es necesario tener un gran conocimiento para ponerla en práctica, como sucede con deportes más complejos, es importante que tengas en cuenta algunos consejos. De hecho, recientemente salió a la luz un estudio en el cual se ponían de relieve los riesgos de correr maratones sin estar preparados: no solo pueden dañarse tus huesos y tendones sino también tu corazón. Por tanto, échale un vistazo a estos consejos para runners.\nbeneficios de correr consejos para correr salir a correr


Significado y definición de escifóforo, etimología de escifóforoescifóforo – Definiciona\nSignificado y definicion de escifóforo, etimologia deescifóforo\nSustantivo masculino. Este vocabulario es una expresión antiguo (en botánica) se refiere a un genero de liquen considerado como el grupo polifilético, es decir que no tiene definido su clasificación taxonómica, un tipo de organismo que se obtiene la simbiosis, se caracteriza por su tallo en forma de copa o embudo hacia la parte de encima.\nSustantivo femenino. Es una palabra se refiere (en medicina) como la acción y re...\nSustantivo femenino. Este termino en la actualidad se encuentra desusado se refi...\nSustantivo femenino. Este vocabualrio es de uso anticuado (en cirugía y biología...\nVerbo Pronominal. Este vocabulario hace referencia en obrar, hacer o actuar de [...\nEste vocablo etimológicamente esta compuesto del griego «σκυφος» (skyphos) vaso y «φορος» (phorós) que significa portador o el que porta.\nDefiniciona.com (7 mayo, 2016). Definición y etimología de escifóforo. Bogotá: E-Cultura Group. Recuperado de https://definiciona.com/escifoforo/\nDefinición y etimología de orellano Adjetivo. Este vocabulario en la actualidad se encuentra desusado, se refi...\nDefinición y etimología de ética (sustantivo) Sustantivo femenino. Este vocabulario se refiere a una agrupación, conjun...\nDefinición y etimología de eccrinológica Sustantivo femenino. Este vocablo es de uso anticuado (en medicina) se def...\nDefinición y etimología de electronegativo Adjetivo. Se dice de una (en física y química), sustancia, ion o radical...\nConcepto, definición corta y significado de escifóforo - Etimología y origen de la palabra escifóforo - Qué es escifóforo - RAE - Wikipedia.


LOS ANGELES EXISTEN Y ESTAN PARA AYUDARNOS: DESCUBRE A TUS ANGELES (fragmentos del libro)\nLos ángeles integran el llamado Grupo Solar (Ángeles y Arcángeles) y el grupo de los guías (los ángeles de la guarda). Son aquellos que nos observan, que nos aman y nos aportan una información maravillosa. Los ángeles están llenos de información práctica y amor para nosotros. Por ejemplo Solara y el Arcángel Miguel. Los guías o ángeles de la guarda, como los conocemos, nos fueron asignados a cada uno de nosotros al principio de nuestras vidas. Se encuentran cerca de nosotros y nos aman profundamente. Son aquellos a los que ocasionalmente percibimos, pero que siempre parecen estar fuera de nuestro alcance. (Los sueños constituyen a menudo el vehículo de comunicación con los guías). .\nAbigrael dice: Está en reorganización la relación de ciertos ángeles que trabajan con vuestro mundo. Esto se debe a cambios en vuestra conciencia colectiva que ahora nos permiten acercarnos más que nunca… Vais viviendo más en armonía con Todo Lo Que Es, aunque superficialmente no lo parezca. Por eso es que libros como Descubre a tus ángeles [y otros más] pueden surgir ahora a la existencia. Mientras que en el pasado habrían hecho falta veinte años de práctica par lograr la misma posibilidad de establecer la comunicación, hoy está al alcance de quien se interese en establecerla. Felicitaciones por vuestra evolución como especie sensible, aunque la evidencia aún no esté a la vista.”\nPrimera esfera:1. Serafines2. Querubines3. Tronos\nSegunda esfera:4. Dominios5. Virtudes6. Poderes\nSerafines: Estos seres celestiales, de quienes se dice que rodean en trono de Dios y manifiestan su gloria, cantan la música de las esferas y regulan el movimiento de los cielos según emana de Dios.Querubines: Son los custodios de la luz y de las estrellas. Aunque alejados de nuestro plano material, su luz toca nuestras vidas, la luz divina que ellos filtran desde el Cielo manifestando la sabiduría divina.Tronos: Son ángeles acompañantes de los planetas y manifiestan la unión con Dios. En este momento de nuestro desarrollo evolutivo es importante que cobremos conciencia de un trono en especial, el ángel de la Tierra que es el guardián de nuestro planeta.\nDominios: Son los seres que manifiestan la soberanía de Dios gobernando las actividades de todos los grupos angélicos inferiores e integrando el mundo espiritual con el mundo material. Aunque reciben órdenes de Dios y rara vez se ponen en contacto con los individuos, su trabajo está vinculado con nuestra realidad.Virtudes: Manifiestan la voluntad de Dios. Ahora son de especial importancia para nosotros porque pueden proyectar grandes niveles de energía divina. A medida que mayor número de humanos aprendamos a trabajar con las virtudes, habrá una mayor infusión de energía espiritual disponible para nuestro planeta.Poderes: Son los que manifiestan el poder de Dios. Son portadores de la conciencia de toda la humanidad, los que conservan nuestra historia colectiva. A esta categoría pertenecen los ángeles del nacimiento y de la muerte. Ellos pueden atraer y retener la energía del plan divino, tal como los árboles absorben la energía del sol. De este modo los poderes pueden enviarnos a todos la visión de una red espiritual mundial. Todos los centros espirituales del planeta son órganos diferentes del cuerpo espiritual emergente de nuestro planeta.\nPrincipados (ángeles integradores): Son los ángeles que manifiestan el dominio de Dios sobre la naturaleza. Son los devas o guardianes de todos los grandes grupos, desde ciudades y naciones hasta creaciones humanas recientes, como las corporaciones multinacionales. Ahora sería más adecuado llamarlos ángeles integradores. Hay muchos de estos seres dedicados a nuestro planeta.Arcángeles (ángeles superlumínicos): Manifiestan el liderazgo de Dios. Nos sugieren que los llamemos ángeles superlumínicos porque se ocupan de las zonas más amplias de la experiencia humana. Pertenecen a una familia diferente de los ángeles y hay muchos tipos distintos de ángeles superlumínicos en esta familia mayor. Algunos comandan a los espíritus planetarios, otros son responsables del reino animal y otros más cumplen tareas específicas en servicio de la humanidad.Ángeles (ángeles acompañantes): Son los más próximos a la humanidad, los que más se ocupan de los asuntos humanos manifestando la protección de Dios. Dentro de la categoría de ángeles hay muchos diferentes, los que más conocemos son los ángeles guardianes o ángeles acompañantes quienes se ocupan de nuestra evolución espiritual. Conforme entramos a una época de mayor luz y amor en el planeta, estos ángeles ya no necesitan ser nuestros guardianes, sino nuestros guías y compañeros entrañables hacia una conciencia cada vez mayor.\nDice Abigrael: “Existen cuatro ángeles superlumínicos mayores, que se ocupan de la vida humana sobre la Tierra. Cuando pensabais que la Tierra era el centro del Universo, esos cuatro parecían muy importantes en el Cielo. No lo son. Hay millones de arcángeles. Sin embargo, esos cuatro son muy importantes en la Tierra. Antes eran necesarios en mayor número para haceros llegar información, porque erais menos receptivos, pero como habéis evolucionado se necesitan menos arcángeles. En la actualidad para la Tierra, son importantes los arcángeles Gabriel, Miguel, Rafael y Uriel.” La terminación “EL” los identifica como mensajeros y enviados de Dios.\nNo hay una manera correcta de percibir a los ángeles. Se manifiestan de mil modos diferentes a diferentes personas, con apariencias que son sumamente personales según cada individuo. Normalmente se comunican con nosotros en nuestros sueños, normalmente los vemos como figuras sabias o protectoras que nos prestan consejo o ayuda o simplemente nos hacen felices con su sola presencia; pero a veces los vemos como ángeles en la imagen de seres perfectos, espléndidos y de una belleza absolutamente pura. Durante las horas de vigilia también podemos percibirlos bajo determinadas circunstancias. Algunas personas sienten su presencia físicamente, como un escalofrío o un cosquilleo en la nuca, como “piel de gallina” en los brazos o como una sensación de calor más o menos intensa; algunos pueden ver fugazmente alguna luz, una figura alada, o simplemente algún desconocido que les resulta extrañamente familiar, otros pueden escuchar sonidos sutiles como campanitas o percibir un perfume o aroma agradable sin ningún motivo aparente. Las apariciones inesperadas de ciertos animales o las sincronicidadesque nos llevan a leer mensajes que forman parte de otros contextos como anuncios o titulares de periódicos, son también subterfugios que utilizan nuestros ángeles para entrar en contacto con nosotros.\nAdemás de brindarnos su amor, su inspiración, su apoyo y su agradable compañía, los ángeles nos pueden guiar mediante sincronicidades, o sea, el encadenamiento “casual” de hechos significativos que vienen en nuestra ayuda para que podamos lograr nuestros más elevados propósitos. Los ángeles también nos dan señales, pistas e incluso consejo directo a través de canalizaciones o telepatía para conducirnos hacia lo que es mejor para nosotros en las distintas encrucijadas vitales, allanando así nuestro camino de regreso a la divinidad. Entablar contacto con ellos es un preciado regalo y un potente catalizador en nuestro proceso evolutivo. Son los mejores psicólogos, pues nos ayudan a descubrir nuestras respectivas trabas y bloqueos; los mejores médicos porque nos develan el verdadero origen de nuestras enfermedades y los mejores asesores, pues nos ayudan a modificar nuestro presente para elegir los más luminosos futuros.\nPublicado por Estelar en 17:40\nhola soy fatima lucero tengo9 años y quisiera visualizar a mis angeles por fabor escribanme a esta pagina fatilucero2007@hotmail.com.gasias escribanme poronto\n10 noviembre, 2008 10:24\nezta muy bonito tu pagina d los angeles\n03 mayo, 2009 15:11\nque linda es esta página.\n17 enero, 2012 10:52\nalberto da. dijo...\ngracias es muy bonito que la gente publique esto para el vrecimiento del ser. Att: alberto david 12 años jeje grax\n02 junio, 2012 09:15


Objetivo China: Honda venderá sus híbridos allí y compartirá tecnología con fabricantes locales Compartir\nCompartir Objetivo China: Honda venderá sus híbridos allí y compartirá tecnología con fabricantes locales Facebook\nEn Honda el futuro parece que pasa por China, y debido a ello se han propuesto un plan para renovar los modelos actuales a la vez que se introducen más modelos híbridos en el mercado. Durante este año se procederá a la implantación de los Insight, CR-Z y Fit (Jazz) híbrido. Así mismo, todos los modelos Honda incluirán una revisión de motores bajo el paraguas tecnológico de las Earth Dreams Technology, nombre bajo el cual Honda aglutina sus nuevas innovaciones en tecnologías de propulsión; intentando colocarse como líderes de bajas emisiones en China.\nHonda se está preparando también para comenzar la fabricación de los híbridos en China, utilizando proveedores locales para reducir los precios y, de esa manera, popularizar los híbridos en China. Otra de las novedades de Honda exclusivas para China será el lanzamiento de un sistema híbrido más apropiado para vehículos medios y grandes así como una nueva plataforma híbrida enchufable.\nEn el campo de los eléctricos puros, Honda comenzó un programa de demostración el año pasado en la ciudad de Guangzhou. Basándose en los resultados de esos tests, Honda se prepara para producir modelos eléctricos en China a finales de este año en la planta que la compañía nipona dispone en Guanzhou junto con el fabricante local Guangqi.\nPara Acura, la marca premium de Honda, el futuro en China para por lanzar el nuevo NSX con el sistema híbrido Sport Hybrid SH-AWD(R) (Super Handling All Wheel Drive o tracción integral de super manejo), así como una linea de vehículos con motores de tamaño más reducido junto a nuevas plataformas por venir.\nEstos planes de expansión en China se llevarán a cabo mediante las joint ventures que Honda tiene en China con Dongfeng y Guangqi, compartiendo los secretos de la tecnología IMA con sus socios chinos.\nEn Motorpasión Futuro | Una reflexion sobre el sistema híbrido de Honda, Honda confirma la producción del EV-STER, Honda Jazz EV 2013 se dará a conocer en el Salón de Los Ángeles


Cerrajeros Aravaca se compone de profesionales cerrajeros los cuales están totalmente capacitados para llevar a cabo todos los servicios de cerrajería que necesite.\nGracias a nuestra amplia experiencia y a los años, somos los cerrajeros Aravaca baratos rápidos más solicitados por nuestros clientes, ya que ofrecemos una excelente calidad-precio así como la atención que necesite.\nNinguna otra empresa de cerrajería de Aravaca cuenta con profesionales como los que cerrajeros Aravaca tiene en su equipo.\nQué hacemos en Cerrajeros Aravaca.\nCerrajeros Aravaca 24 horas urgentes realiza la apertura de puertas atascas de garaje, ventanas, puertas de vehículos, cajas fuertes, candados de moto o puertas de portales.\nNuestro profesional cerrajeros Aravaca realiza con total maestría el duplicado y amaestramiento de todo tipo de llaves, ya sean sencillas o forjadas, así como la copia de mandos de garaje o reparación de las mismas.\nTan solo deberá de ponerse en contacto con nosotros, donde le tomaremos nota y enviaremos de inmediato a uno de nuestros cerrajeros Aravaca baratos las 24 horas donde nos indique con la mayor rapidez posible.