sábado, 24 de septiembre de 2022

El CEO de Google, Sundar Pichai, les dice a los empleados que no ‘identifiquen la diversión con el dinero’ en una acalorada reunión con todo el personal.


Fuente: https://www.cnbc.com/


Pichai, dedicó gran parte de la reunión de esta semana a abordar las preocupaciones de los empleados sobre las medidas de reducción de costos de la empresa.

Pichai, quien expresó cierta molestia durante la reunión, dijo: “Recuerdo cuando Google era pequeño y rudimentario”, y agregó que “no siempre debemos equiparar la diversión con el dinero”.

El jefe de finanzas de Google les dijo a los empleados que moderaran sus expectativas para las fiestas navideñas.

Mientras Google intenta navegar en un entorno desconocido de desaceleración del crecimiento, reducción de costos y disidencia de los empleados sobre los cambios culturales, el director ejecutivo Sundar Pichai se encuentra a la defensiva.

En una reunión de toda la empresa esta semana, Pichai se enfrentó a preguntas difíciles de los empleados relacionadas con los recortes en los presupuestos de viajes y entretenimiento, la gestión de la productividad y los posibles despidos, según el audio obtenido por CNBC.

Se le preguntó a Pichai, en una pregunta que fue altamente calificada por los empleados en el sistema interno de Dory de Google, por qué la compañía está “recortando y reduciendo los empleados” al recortar los presupuestos de viajes y botín en un momento en que “Google tiene ganancias récord y enormes reservas de efectivo”. ”, como lo hizo saliendo de la pandemia de Covid .

″¿Cómo lo digo?” Pichai comenzó su respuesta mesurada. “Miren, espero que todos ustedes estén leyendo las noticias, externamente. El hecho de que sepamos que estamos siendo un poco más responsables a través de una de las condiciones macroeconómicas más difíciles de la última década, creo que es importante que, como empresa, nos unamos para superar momentos como este”.

La reunión más reciente se produce cuando la matriz de Google, Alphabet, Meta y otras empresas tecnológicas se enfrentan a una serie de desafíos económicos, incluida una posible recesión, una inflación vertiginosa, tasas de interés en aumento y un gasto publicitario moderado. Las empresas que, durante más de la última década, han sido conocidas por su alto crecimiento y una gran cantidad de ventajas divertidas, están viendo cómo es en el otro lado.

En julio, Alphabet informó su segundo trimestre consecutivo de ganancias e ingresos más débiles de lo esperado, y se espera que el crecimiento de las ventas del tercer trimestre caiga a un solo dígito, por debajo del 40% del año anterior. Pichai admitió que no es solo la economía lo que ha causado desafíos en Google, sino también una burocracia en expansión en Google.


Aún así, a veces parecía molesto en la reunión y recordó a los empleados que “no siempre podemos elegir las condiciones macroeconómicas”.


Después de que el número de empleados de la compañía se disparara durante la pandemia, la directora financiera Ruth Porat dijo a principios de este año que espera que algunos problemas económicos persistan en el corto plazo. Google canceló la próxima generación de su computadora portátil Pixelbook y recortó los fondos para su incubadora interna del Área 120.

Google lanzó un esfuerzo en julio llamado “Simplicity Sprint”, cuyo objetivo era solicitar ideas de sus más de 174,000 empleados sobre cómo “obtener mejores resultados más rápido” y “eliminar el desperdicio”. A principios de este mes, Pichai dijo que esperaba que la empresa fuera un 20 % más productiva al tiempo que ralentizaba las contrataciones y las inversiones.

Cómo ser más productivo

Una de las preguntas mejor calificadas planteadas por los empleados en la reunión de esta semana le pidió a Pichai que elaborara su comentario sobre la mejora de la productividad y la meta del 20%.


“Creo que podría ser un equipo de 20 personas o un equipo de 100 personas, vamos a estar limitados en nuestro crecimiento de cara al futuro”, dijo Pichai. “Tal vez estabas planeando contratar a seis personas más, pero tal vez tendrás que conformarte con cuatro y ¿cómo vas a hacer que eso suceda? Las respuestas van a ser diferentes con diferentes equipos”.


Pichai dijo que el liderazgo está revisando más de 7,000 respuestas que recibió de los empleados con respecto a las sugerencias del esfuerzo Simplicity Sprint.

“A veces tenemos un proceso de lanzamiento de productos, que probablemente, durante muchos años, se ha vuelto más complicado de lo que debería ser”, dijo Pichai. “¿Podemos mirar ese proceso y tal vez eliminar dos pasos y ese será un ejemplo de cómo hacer que algo sea un 20% más eficiente? Creo que todos nosotros aportando y haciendo eso en todos los niveles, creo que podemos ayudar a la empresa. A nuestra escala, no hay forma de que podamos resolver eso a menos que las unidades de equipos de todos los tamaños lo hagan mejor”.

Pichai también reconoció brevemente la reciente encuesta de empleados , en la que los empleados criticaron la creciente burocracia de la empresa.

Otra pregunta de los empleados se refería a cómo la compañía compartirá sus planes para posibles recortes de empleos, luego de que se filtraran noticias sobre el retiro de Pixelbook y los recortes en el Área 120, que afectaron la “capacidad de concentrarse en el trabajo” de los trabajadores.

Pichai respondió diciendo que informar a toda la fuerza laboral de los recortes “no es una forma escalable de hacerlo”, pero dijo que “intentará y notificará a la compañía sobre las actualizaciones más importantes”.

El all-hands, conocido como TGIF (Thank God It’s Friday) fue en Nueva York, donde Pichai respondió preguntas frente a una audiencia en vivo de empleados.

“Es una opción interesante para Sundar estar en Nueva York para TGIF la semana después de que los viajes de los empleados se reduzcan a los más críticos para el negocio”, escribió un empleado en Dory. “Estoy seguro de que Sundar tiene reuniones críticas para el negocio en Nueva York”.

Pichai respondió: “Creo que sí. Creo que calificó”. Algunos en la audiencia estallaron en carcajadas.

Pichai esquivó las preguntas de los empleados sobre la reducción de costos en la compensación ejecutiva. Pichai obtuvo una paga total el año pasado de $6.3 millones, mientras que otros altos ejecutivos ganaron más de $28 millones.

“No siempre debemos equiparar la diversión con el dinero”

Abordó el tema más amplio de los recortes de costos e indicó que la cultura de Google aún puede ser agradable, incluso si se quitan algunas cosas, como ciertos artículos promocionales.

“Recuerdo cuando Google era pequeño y rudimentario”, dijo. “La diversión no siempre, no siempre debemos equiparar la diversión con el dinero. Creo que puedes entrar en una startup trabajadora y la gente puede divertirse y no siempre debería equivaler a dinero”.

Los empleados querían saber por qué la gerencia les pide a los empleados que se adhieran a la política de regreso a la oficina “al mismo tiempo que dicen que no es necesario viajar/conectarse en persona”.

“Entiendo algunas de las restricciones de viaje en un momento como este y RTO y las personas que quieren verse, definitivamente no es lo ideal”, respondió Pichai. “Si no ha visto a su equipo por un tiempo y le ayudará en su trabajo reunirse en persona, creo que puede hacerlo. Creo que es por eso que no estamos diciendo que no a viajar, estamos dando discreción a los equipos”.

Kristin Reinke, directora de finanzas de Google, dijo en la reunión que los equipos de ventas tendrán más libertad de acción para viajar, ya que sus trabajos requieren reunirse con los clientes.

“Sabemos que es muy valioso estar al lado de su equipo, pero simplemente le pedimos que sea considerado y limite sus viajes y gastos donde pueda”, dijo Reinke. Por ejemplo, pidió que los empleados moderaran sus expectativas para las fiestas navideñas.

“Donde tenga cumbres y grandes reuniones, intente hacerlo en la oficina”, dijo. “Definitivamente queremos que la gente siga divirtiéndose. Sabemos que se acercan fiestas navideñas, celebraciones de fin de año, todavía queremos que la gente haga eso. Pero solo les estamos pidiendo que los mantengan pequeños, que los mantengan informales, que traten de no exagerar”.

Hacia el final de la reunión, Pichai respondió una pregunta sobre por qué la empresa ha pasado de “contratar y gastar rápidamente a ahorrar costos de manera igualmente agresiva”.

Pichai no estuvo de acuerdo con la caracterización.

“Me preocupa un poco que piense que lo que hemos hecho es lo que usted definiría como un ahorro de costos agresivo”, dijo. “Creo que es importante que no nos desconectemos. Debe tener una visión a largo plazo en condiciones como esta”.

Agregó que la compañía “todavía está invirtiendo en proyectos a largo plazo como la computación cuántica”, y dijo que en tiempos de incertidumbre, es importante “ser inteligente, ser frugal, ser rudimentario, ser más eficiente”.

Bret Hill, vicepresidente de “recompensas totales” de Google, respondió una pregunta sobre aumentos, equidad y bonificaciones y cómo se verán afectados por los cambios. Dijo que la compañía no planea desviarse de pagar a los trabajadores “en el extremo superior del mercado para que podamos ser competitivos”.

Pichai reiteró ese sentimiento.

“Estamos comprometidos a cuidar a nuestros empleados”, dijo. “Creo que estamos atravesando un momento difícil desde el punto de vista macroeconómico y creo que es importante que, como empresa, nos alineemos y trabajemos juntos”.

Un portavoz de Google dijo: “Sundar ha estado hablando constantemente con la compañía durante los últimos meses sobre las formas en que podemos estar más enfocados”. El vocero agregó que Pichai reforzó que los “líderes de la compañía están trabajando para ser responsables y eficientes en todo lo que hacen sus equipos” en un momento de incertidumbre, y que están “asegurándose de que nuestra gente esté trabajando en el trabajo de mayor impacto/mayor prioridad”. ”

viernes, 23 de septiembre de 2022

Charlas del LAOUC Community Tour 2022- Disponibles en el canal de Youtube.

 




No tuviste el tiempo necesario para disfrutar de todas las sesiones del LAOUC Community Tour 2022.?

No te preocupes, la mayor parte de ellas están ya disponibles en el canal de Youtube de Latinoamerican Oracle User Community shorturl.at/djlst 

Este fin de semana, habrá nuevos estrenos.

Nota: Algunas de las charlas no están disponibles, debido a que los expositores solicitaron no grabarlas.







martes, 20 de septiembre de 2022

AttachMe: la vulnerabilidad crítica de OCI que permitió el acceso no autorizado a los volúmenes de almacenamiento de la nube de clientes

Apache: ¿Qué es Log4Shell? ¿Por qué es la peor vulnerabilidad informática  de la década? | Tecnología | EL PAÍS
Fuente: https://www.wiz.io/blog/attachme-oracle-cloud-vulnerability-allows-unauthorized-cross-tenant-volume-access

Antes de que se parcheara, #AttachMe podría haber permitido a los atacantes acceder y modificar los volúmenes de almacenamiento OCI de otros usuarios sin autorización, violando así el aislamiento de la nube. Tras la divulgación, Oracle solucionó la vulnerabilidad en cuestión de horas. No se requirió ninguna acción del cliente.

En junio, los ingenieros de Wiz descubrieron e informaron #AttachMe, una importante vulnerabilidad de aislamiento de la nube en Oracle Cloud Infrastructure (OCI), lo que llevó a Oracle a corregir la vulnerabilidad en cuestión de horas y sin necesidad de que el cliente hiciera nada.

Impacto potencial: antes de que se parcheara, todos los clientes de OCI podrían haber sido atacados por un atacante con conocimiento de #AttachMe. Cualquier volumen de almacenamiento no conectado, o volúmenes de almacenamiento adjuntos que permitan la conexión múltiple, podrían haber sido leídos o escritos siempre que un atacante tuviera su Oracle Cloud Identifier (OCID), lo que permitía filtrar datos confidenciales o iniciar ataques más destructivos. manipulación de archivos ejecutables.

Remediación: dentro de las 24 horas posteriores a la notificación de Wiz, Oracle parcheó #AttachMe para todos los clientes de OCI. No se requirió ninguna acción del cliente.

Conclusiones clave: el aislamiento de inquilinos en la nube es un elemento clave en la nube. Los clientes esperan que otros clientes no puedan acceder a sus datos. Sin embargo, las vulnerabilidades de aislamiento de la nube rompen las barreras entre los inquilinos. Esto destaca la importancia crucial de la
investigación proactiva de vulnerabilidades de la nube, la divulgación responsable y el seguimiento público de las vulnerabilidades de la nube para la seguridad de la nube.

¿Qué es Adjuntarme?

#AttachMe es una de las vulnerabilidades en la nube más graves reportadas, ya que podría haber afectado a todos los clientes de OCI. Las vulnerabilidades de aislamiento de la nube generalmente afectan un servicio de nube específico. Sin embargo, en este caso, el impacto está relacionado con un servicio central en la nube.

Los ingenieros de Wiz descubrieron que adjuntar un disco a una máquina virtual en otra cuenta no requería ningún permiso. Esto significa que un atacante potencial podría haber accedido y modificado datos de cualquier cliente de OCI y, en algunos casos, incluso apoderarse del entorno.

El flujo de ataque potencial era simple:

Descubra un ID (OCID) del volumen de una víctima de destino buscando en la web o utilizando un permiso de usuario con pocos privilegios para leer el volumen OCID del entorno de la víctima.

Inicie una instancia informática en un arrendatario controlado por un atacante ubicado en el mismo dominio de disponibilidad (AD) que el volumen de destino.

Adjunte el volumen de la víctima a la instancia informática del atacante, obteniendo así privilegios de lectura/escritura sobre el volumen.

A partir de ahí, un atacante potencial podría haber realizado numerosas acciones graves:

Extraiga los datos confidenciales almacenados en el volumen.

Busque en el volumen secretos de texto claro para moverse lateralmente a través del entorno de la víctima y/o aumentar los privilegios. ype paravirtualizado -- instance-id <instancia_ocid> --volume-id <volumen_ocid>

Según la referencia de la política, los permisos necesarios para AttachVolume son:

  • VOLUME_WRITE, 
  • VOLUME_ATTACHMENT_CREATE e 
  • INSTANCE_ATTACH_VOLUME. 
No es necesario que la instancia y el volumen estén en el mismo compartimento.

La conexión de volumen es un recurso de OCI que reside en el compartimento de la instancia informática y describe una conexión de un volumen a una instancia informática. Los permisos se aplican a un compartimento (y su árbol de compartimentos). 

Por lo tanto, se requieren VOLUME_ATTACHMENT_CREATE e INSTANCE_ATTACH_VOLUME en el ámbito del compartimento de la instancia (en este caso, el compartimento del atacante) y VOLUME_WRITE en el ámbito del compartimento del volumen (el compartimento de la víctima).

Sin embargo, como descubrimos, había una brecha en la validación del permiso VOLUME_WRITE al adjuntar un volumen, lo que hizo posible adjuntar cualquier volumen sin autorización. Además, la conexión fue posible en diferentes arrendamientos: logramos adjuntar un volumen de un arrendamiento a una instancia informática en otro arrendamiento. Manifestación

Cuando un usuario no autorizado intenta realizar cualquier operación en un volumen, el servicio (correctamente) devuelve un error que indica que el usuario carece de los permisos necesarios:

elad_gabay@cloudshell:~ (us-ashburn-1)$ oci bv volumen get --volume-id ocid1.bootvolume.oc1.iad.abuwcljrybvvdsn******************* *********************** Error
de servicio: { "client_version": "Oracle-PythonSDK/2.69.0, Oracle-PythonCLI/3.10.0", "código": "No autorizado o no encontrado", "logging_tips": "Ejecute el comando OCI CLI usando el indicador --debug para encontrar más información de depuración"., "message": "Autorización fallida o recurso solicitado no encontrado.", "opc-request-id": "DFB9SCC25*****", "nombre_operación": "obtener_volumen", "request_endpoint": "OBTENGA https://iaas.us-ashburn-oraclecloud.com/20160918/volumes/ocid1.bootvolume.oc1.iad.abuwcljrybvvdsn***************** ***************************", "estado": 404, "target_service": "almacenamiento en bloque", "marca de tiempo": "2022-06-07114:12:21.408280", "troubleshooting_tips": "Consulte
https://docs.oracle.com/iaas/Content/API/References/apierrors.htm#apierrors_404_404_notauthorizedornotfound para obtener más información sobre cómo resolver este error. Si no puede resolver este problema, ejecute este comando CLI con la opción --debug, comuníquese con el soporte de Oracle y proporcióneles el mensaje de
error completo". }

Sin embargo, antes de que se remediara #AttachMe, intentar adjuntar un volumen a una instancia de cómputo tuvo éxito, ya sea que el usuario tuviera suficientes permisos o no:

elad_gabay@cloudshell:~(us-ashburn-1)$ oci computar volumen-archivo adjunto adjuntar --instance-id ocid1.instance.oc1.iad.anuwcljrixjtluica*****************
************************** --volume-id ocid1.bootvolume.oc1.iad.abuwcljrybvvdsn3********** ******************************** --tipo paravirtualizado { "datos": {
"tipo-de-archivo adjunto": "paravirtualizado", "dominio-de-disponibilidad": "zSfH:US-ASHBURN-AD-1", "id-compartimento":
"ocid1.tenancy.oc1..aaaaaaaaaote2dzazv***********************", "dispositivo": "nulo", "nombre para mostrar": "archivo adjunto de volumen20220607141228", "id":
"ocid1.archivo adjunto de volumen.oc1.iad.anuwcljrixjtluic***********************", "id-de-instancia": "ocid1.instancia-
oc1.iad.anuwcljrixjtluica************************", "es-multipath": nulo, "es-pv-encryption-in-transit-enabled": falso, "es de solo lectura": falso, "es-
compartible": falso, "iscsi-login-state": nulo, "estado del ciclo de vida": "ADJUNTAR", "tiempo-creado": "2022-06-07T14:12:29.027000+00:00", "id-volumen":
"ocid1.bootvolume.oc1.iad.abuwcljrybvvdsn3***********************", }, "etag": "992e06ff86b86a5fe732308092a55***********************************" }

Una vez adjunto el volumen, pudimos visualizar y modificar su contenido.

Los requisitos detallados para explotar #AttachMe fueron:

El atacante debe conocer el OCID del volumen de destino. Si bien los OCID generalmente son privados, no se tratan como secretos, por lo que esto se logra fácilmente.

La instancia informática del atacante debe estar en el mismo dominio de disponibilidad (AD) que el volumen de destino. Esta condición se puede cumplir fácilmente ya que la cantidad de zonas de disponibilidad es relativamente pequeña (hasta tres en algunas regiones) y, por lo tanto, se puede enumerar.

El volumen de destino debe estar desconectado o adjunto como compartible: los volúmenes desconectados son relativamente comunes porque, de forma predeterminada, los volúmenes de arranque asociados con las instancias informáticas terminadas no se eliminan. Además, los volúmenes de datos de copia de seguridad a menudo no se adjuntan a una instancia informática en ejecución.

Análisis de riesgo

Cuando un atacante obtiene acceso de lectura a sus volúmenes, el principal riesgo es la violación de datos. Los volúmenes pueden contener información confidencial, como información de identificación personal (PII), secretos y más.

Otro riesgo es la manipulación de datos y intrusión en su red en la nube. Adjuntar un volumen proporciona acceso de escritura que podría usarse para manipular cualquier dato en el volumen, incluido el tiempo de ejecución del sistema operativo (por ejemplo, mediante la modificación de archivos binarios), obteniendo así la ejecución del código en la instancia informática remota y un punto de apoyo en el entorno de la nube de la víctima. una vez que el volumen se utiliza para iniciar
una máquina.

Las posibles rutas de ataque incluyen:

Aumento de privilegios dentro del compartimento o arrendamiento: si un atacante logró obtener acceso inicial al entorno OCI de una víctima, #AttachMe podría haber sido explotado para aumentar aún más los privilegios. Un atacante habría podido consultar todos los volúmenes disponibles en el compartimento para obtener sus OCID, montarlos y leer cualquier información confidencial almacenada en ellos. Acceso entre inquilinos: un escenario más impactante es si un atacante logra
obtener OCID de volúmenes en un inquilino remoto. #AttachMe podría haberse utilizado para obtener acceso inicial al entorno de la víctima mediante la lectura de información confidencial y secretos de larga duración que se almacenaron en los volúmenes de destino. Además, el atacante podría haber manipulado volúmenes de bloque y volúmenes de arranque existentes de una manera que proporcionaría la ejecución del código del atacante cuando los volúmenes estaban montados en
instancias informáticas.

Consideramos que ambas posibles rutas de ataque son bastante factibles dado que los OCID generalmente no se tratan como secretos. Se pueden encontrar numerosos OCID de volúmenes de bloque y volúmenes de arranque de varios entornos, incluidos los de las principales empresas, mediante una simple búsqueda en línea.

También es posible encontrar OCID de volúmenes que se publicaron en GitHub, lo que indica que los desarrolladores no tratan estos ID como secretos. Los usuarios con pocos privilegios y los proveedores externos con acceso de lectura al entorno podrían obtener OCID muy fácilmente. Cronología de descubrimiento y divulgación

Al descubrir #AttachMe, inmediatamente divulgamos nuestros hallazgos a Oracle, quien investigó y solucionó este problema en menos de 24 horas. Estamos felices de colaborar con un equipo tan profesional.

  • 6 de junio de 2022: Wiz descubre la vulnerabilidad 9 de junio de 2022: vulnerabilidad informada a Oracle 
  • 10 de junio de 2022: Oracle reconoce el informe 10 de junio de 2022: se corrige la vulnerabilidad

Lecciones para constructores y defensores de la nube

La validación insuficiente de los permisos de usuario es una clase de error común entre los proveedores de servicios en la nube. La mejor manera de identificar tales problemas es realizar revisiones de código rigurosas y pruebas exhaustivas para cada API sensible en la etapa de desarrollo. Oracle compartió con nosotros que utiliza tecnología de análisis de código estático para detectar tales problemas que ya están en desarrollo e investigar los problemas conocidos e informados para garantizar que el patrón problemático no se repita en otra parte de la base de código.

También recomendamos realizar pruebas de penetración específicas del servicio y participar en programas de recompensas por errores, ya que estos han demostrado ser efectivos con este tipo de problemas. Seguimiento de vulnerabilidades en la nube #AttachMe es la última de una larga lista de vulnerabilidades de aislamiento en la nube descubiertas por la comunidad de investigación: los ejemplos recientes incluyen "ExtraReplica", una vulnerabilidad de base de datos de inquilinos cruzados en Azure PostgreSQL también descubierta por la investigación de Wiz, y una vulnerabilidad de inquilinos cruzados en Azure Cloud Shell descubierto por Chen Cohen del equipo de pruebas de penetración de eBay.

Hoy en día, no existe un proceso claro en torno a las vulnerabilidades de la nube impuestas por la comunidad de seguridad. Las vulnerabilidades de la nube no se emiten CVE, por lo que son muy difíciles de rastrear para los clientes. Recientemente, los investigadores de Wiz junto con otros miembros de la comunidad de seguridad en la nube iniciaron la base de datos de problemas de seguridad y vulnerabilidades de la nube abierta para ayudar a los usuarios y defensores de la nube a
monitorear y rastrear las vulnerabilidades de la nube.

Si está interesado en contribuir, puede consultar OpenCVDB GitHub.

Asegure todo lo que crea y ejecuta en la nube


Oracle Database: Porqué algunas versiones de parches para base de datos tienen una númeración distinta?

El tema de los parches y su numeración, se ha convertido en una verdadera embolia cerebral.

Hay muchos conceptos que se incluyeron con la nueva política de parcheo instaurada años atrás con Oracle Database 12c.

Desde un "Database Release Update" que contiene mejoras y reparaciones a componentes de base de datos, hasta un "GI Release Update", que contiene mejoras y reparaciones a componentes para el software de Infraestructura Grid y Base de Datos conjuntamente.

En ocasiones encontramos el término "SINGLETON", "CPU", "PSU","RU", "RUR","BP", etc.

Aprovechando para aclarar, quizás los menos conocidos son "RU","RUR" y "BP":

  • Patch Set Updates (PSU)
  • Proactive Bundle Patches (BP)
  • Release Updates (RU)
  • Release Update Revisions (RUR).  

 Esta es una guía rápida de lo que significa cada tipo de parche, entre ellos "SINGLETON".

Pero también volviendo a la pregunta del título de post, que son los números que vienen adicionales al final del RU.?

En la referencia de la nota: Oracle Database 19c Proactive Patch Information (Doc ID 2521164.1), en My Oracle Support, nos facilita una liga al Document ID: 19202201.9, con fecha de liberación del 18 de enero del 2022. Así que 19.14.0.0 ( RU 14 para 19c ), 220118 ( fecha de liberación ).

En las revisiones 15 y 16, no se adjunta ya la fecha de liberación.

 

Puedes encontrar mayor información sobre esto en https://mikedietrichde.com/2017/10/24/differences-psu-bp-ru-rur/

Parche de paquete - Bundle Patch-

Un paquete de parches es una colección acumulativa de arreglos para un producto o componente específico. Se lanza un parche de este tipo según sea necesario según los requisitos del producto. También puede conocer un parche de paquete como: paquete de mantenimiento, paquete de servicio, MLR, parche acumulativo o versión de actualización.


Parche de diagnóstico -Diagnostic Patch-

Un parche de diagnóstico está diseñado para ayudar a diagnosticar o verificar una corrección o colección de correcciones de errores. También puede conocer un parche de diagnóstico como: parche de prueba, Fix Verification Binary (FVB) o e-fix.


Parche provisional -Interim Patch-

Un parche provisional proporciona una única corrección de errores, una colección de correcciones de errores o una corrección de seguridad específica del cliente. Por lo general, abordan errores específicos para un cliente en particular y, por lo general, no deben aplicarse a menos que Oracle Support lo indique. También puede conocer un parche provisional como: seguridad única, lanzamiento de excepción, x-fix, PSE, MLR o hotfix.


MLR

Solicitud de combinación de etiquetas. Un paquete de parches que corrigen varios errores.

Conjunto de parches -Patch Set-

La forma principal en que Oracle proporciona correcciones de errores entre versiones. Oracle agrupa una serie de correcciones, las prueba minuciosamente juntas y las empaqueta juntas para facilitar su descarga e instalación. Por lo general, no incluyen nuevas funcionalidades y no requieren una nueva certificación. Todas las correcciones en el conjunto de parches han sido probadas y están certificadas para funcionar entre sí.


Actualización del conjunto de parches -Patch Set Update-

Una colección de parches acumulativos proactivos y estabilizadores para una versión de producto en particular (versión base o conjunto de parches). Las PSU son acumulativas e incluyen todas las correcciones de seguridad de los parches de SPU (anteriormente conocidas como CPU), además de correcciones adicionales.


Actualización del parche de seguridad -Security Patch Update-

Una actualización de parche de seguridad es una colección acumulativa de correcciones de errores relacionados con la seguridad. En general, las actualizaciones de parches de seguridad se publican con regularidad. La actualización del parche de seguridad se conocía anteriormente como Actualización de parche crítico o CPU.

Único -Singleton-

Un parche con una corrección de errores.

Parche -Patch-

Un parche es un fragmento de código/software diseñado para solucionar problemas con el código/software existente. Esto incluye corregir vulnerabilidades de seguridad y otros errores, y mejorar la usabilidad o el rendimiento.

Conflicto de parches -Patch Conflict-

Si un parche realiza cambios diferentes en la misma sección de código que modifica otro OPatch, estos dos parches entran en conflicto y solo se puede instalar uno de ellos (a menos que haya disponible un parche de combinación o superposición).

Parche de actualizacion crítica  -Superset Patch-

Si un parche en particular que se va a aplicar contiene todas las correcciones incluidas en un parche ya instalado, además de correcciones adicionales, entonces el parche con más correcciones es un parche de superconjunto y no hay conflicto.

Conflicto de combinación -Combination Conflict -

Si un parche que se va a instalar entra en conflicto con más de un parche ya instalado, esto se considera un conflicto de combinación. En este caso, OPatch eliminará todos los parches en conflicto y luego aplicará solo el parche nuevo.


Actualización de parche crítico -Critical Patch Update-

Las actualizaciones de parches críticos (CPU) son el medio principal para publicar parches de seguridad para los productos de Oracle. Las CPU son acumulativas con respecto a las CPU anteriores y, en general, solo contienen correcciones de seguridad.


Combinar parche -Merge Patch-

Un parche combinado es aquel en el que varios parches en conflicto se combinan en un parche integrado.


Parche superpuesto -Overlay Patch-

Cuando un parche provisional entra en conflicto con una fuente de alimentación, la resolución del conflicto de parches se logra proporcionando un nuevo parche que coexiste con (y requiere) el parche de la fuente de alimentación. El nuevo parche se superpone a la PSU, y la PSU es un requisito previo para el parche superpuesto.

Inicio compartido/no compartido (GI o RAC) -Shared/Non-shared (GI or RAC) Home-

En un hogar GI/RAC compartido, todos los nodos del clúster utilizan la misma copia física del software. Esto simplifica la configuración y administración de muchas operaciones de base de datos porque hay una única ubicación de inicio en lugar de inicios separados en cada nodo. Cuando se comparte un GI Home o RAC Home, los nodos individuales dentro de los entornos GI o RAC comparten un solo sistema de archivos y utilizan un sistema de archivos de clúster como Oracle Cluster File System 2 (OCFS2), además de compartir el mismo Home. Aunque esta configuración es más eficiente en el uso del espacio en disco, el proceso de aplicación de parches se vuelve un poco más complicado ya que los diferentes nodos utilizan los mismos recursos/espacio en disco.

Uber: comunicado de actualizacióon sobre el incidente de seguridad de la semana pasada.

 19 de septiembre, 10:45 a. m. (hora del Pacífico)

844 Uber Logo Imágenes y Fotos - 123RF

Si bien nuestra investigación aún está en curso, brindamos una actualización de nuestra respuesta al incidente de seguridad de la semana pasada.

¿Qué sucedió?

Un atacante comprometió la cuenta de un contratista de Uber EXT. Es probable que el atacante haya comprado la contraseña corporativa de Uber del contratista en la web oscura, después de que el dispositivo personal del contratista se infectara con malware, exponiendo esas credenciales. Luego, el atacante intentó repetidamente iniciar sesión en la cuenta de Uber del contratista. Cada vez, el contratista recibió una solicitud de aprobación de inicio de sesión de dos factores, que inicialmente bloqueó el acceso. Eventualmente, sin embargo, el contratista aceptó uno y el atacante inició sesión con éxito.

A partir de ahí, el atacante accedió a varias otras cuentas de empleados que finalmente le dieron al atacante permisos elevados para una serie de herramientas, incluidas G-Suite y Slack. Luego, el atacante publicó un mensaje en un canal de Slack de toda la empresa, que muchos de ustedes vieron, y reconfiguró OpenDNS de Uber para mostrar una imagen gráfica a los empleados en algunos sitios internos.

¿Cómo respondimos?

Nuestros procesos de monitoreo de seguridad existentes permitieron a nuestros equipos identificar rápidamente el problema y actuar para responder. Nuestras principales prioridades eran asegurarnos de que el atacante ya no tuviera acceso a nuestros sistemas; para garantizar que los datos de los usuarios estén seguros y que los servicios de Uber no se vean afectados; y luego investigar el alcance y el impacto del incidente.

Estas son algunas de las acciones clave que tomamos y seguimos tomando:

Identificamos las cuentas de los empleados que se vieron comprometidas o potencialmente comprometidas y bloqueamos su acceso a los sistemas de Uber o requerimos un restablecimiento de contraseña.
Deshabilitamos muchas herramientas internas afectadas o potencialmente afectadas.
Rotamos las claves (restableciendo efectivamente el acceso) a muchos de nuestros servicios internos.
Bloqueamos nuestra base de código, evitando cualquier cambio de código nuevo.
Al restaurar el acceso a las herramientas internas, requerimos que los empleados se vuelvan a autenticar. También estamos reforzando aún más nuestras políticas de autenticación multifactor (MFA).
Agregamos monitoreo adicional de nuestro entorno interno para vigilar aún más de cerca cualquier actividad sospechosa adicional.

¿Cuál fue el impacto?

El atacante accedió a varios sistemas internos y nuestra investigación se ha centrado en determinar si hubo algún impacto material. Si bien la investigación aún está en curso, tenemos algunos detalles de nuestros hallazgos actuales que podemos compartir.

En primer lugar, no hemos visto que el atacante haya accedido a los sistemas de producción (es decir, de cara al público) que alimentan nuestras aplicaciones; cualquier cuenta de usuario; o las bases de datos que usamos para almacenar información confidencial del usuario, como números de tarjetas de crédito, información de la cuenta bancaria del usuario o historial de viajes. También encriptamos la información de la tarjeta de crédito y los datos personales de salud, lo que ofrece una capa adicional de protección.

Revisamos nuestra base de código y no encontramos que el atacante haya realizado ningún cambio. Tampoco hemos encontrado que el atacante haya accedido a ningún dato de cliente o usuario almacenado por nuestros proveedores de la nube (por ejemplo, AWS S3). Parece que el atacante descargó algunos mensajes internos de Slack, así como accedió o descargó información de una herramienta interna que nuestro equipo de finanzas usa para administrar algunas facturas. Actualmente estamos analizando esas descargas.

El atacante pudo acceder a nuestro tablero en HackerOne, donde los investigadores de seguridad informan errores y vulnerabilidades. Sin embargo, todos los informes de errores a los que el atacante pudo acceder se han corregido.

En todo momento, pudimos mantener todos nuestros servicios públicos de Uber, Uber Eats y Uber Freight operativos y funcionando sin problemas. Debido a que eliminamos algunas herramientas internas, las operaciones de atención al cliente se vieron mínimamente afectadas y ahora han vuelto a la normalidad.

¿Quién es responsable?

Creemos que este atacante (o atacantes) están afiliados a un grupo de piratería llamado Lapsus$, que ha estado cada vez más activo durante el último año más o menos. Este grupo generalmente usa técnicas similares para atacar a las empresas de tecnología, y solo en 2022 ha violado a Microsoft, Cisco, Samsung, Nvidia y Okta, entre otros. También hay informes durante el fin de semana de que este mismo actor violó al fabricante de videojuegos Rockstar Games. Estamos en estrecha coordinación con el FBI y el Departamento de Justicia de los EE. UU. en este asunto y continuaremos apoyando sus esfuerzos.

¿A dónde vamos desde aquí?

Estamos trabajando con varias firmas forenses digitales líderes como parte de la investigación. También aprovecharemos esta oportunidad para continuar fortaleciendo nuestras políticas, prácticas y tecnología para proteger aún más a Uber contra futuros ataques.

viernes, 9 de septiembre de 2022

Planned Maintenance to My Oracle Support Portal on Friday September 16, 2022




My Oracle Support Portal (MOS) will be undergoing maintenance from Friday Sep 16, 2022, 7:00 PM PDT to Saturday Sep 17, 2022, 7:30 AM PDT.

During the maintenance period you will not be able to create, view, or update SRs through our Customer Support portals. Oracle Support Services will continue to be available and can be reached via telephone for any critical issues that need immediate attention. In addition, access to Oracle Knowledge Base will be available from https://support-lite.oracle.com and you will be able to use MOS Communities at https://community.oracle.com

If you are using Oracle monitoring services like ASR and Platinum, these will continue to monitor your systems, however the creation of Service Requests will occur after the planned maintenance if required.

You can find the telephone numbers for your location at Oracle Support Center.

viernes, 2 de septiembre de 2022

OCI Login failed for user 'SERVERDB-01-DES\opc'. (Microsoft SQL Server, Error: 18456) in SSMS al logear por primera vez

 


OCI es una caja de sorpresas, de la cuál aprendemos todos los días.

Hoy me toco hacer un despliegue de un servicio del MarketPlace. Específicamente una Microsoft SQL Server Standard para un desarrollo de servicios de integración.

Este tipo de servicio tiene algunas limitaciones para su despliegue dependiendo de la región geográfica en donde te encuentres.

Necesitaba hacer un despliegue con SQL Server 2019, el cuál en EE no esta disponible para la mayor parte de Latinoamérica. En su versión SE si es posible, siempre y cuando no vaya acompañada de Windows Server.


Hasta este punto no hay nada realmente especial.

Cuando terminas de hacer el despliegue, la hacer login por primera vez con el usuario "OPC", que es la cuenta administradora a nivel de windows, se te pide cambiar la clave del usuario que te entrega de facto al terminar de desplegar el servicio.

Ingresas en el ambiente y todo bien, hasta que después de hacer mil y un malabares logras instalar un navegador decente para poder descargar la versión de SQL Server Management Studio (SSMS).

Una vez instalado el SSMS, normalmente lo que haríamos es ingresar en el para confirmar que nos podamos conectar a la instancia de base de datos SQL Server.

Hacemos login con el usuario "opc" validado por sistema operativo y sorpresa:

TITLE: Connect to Server

------------------------------
Cannot connect to SERVERDB-01-DES.
------------------------------
ADDITIONAL INFORMATION:

Login failed for user 'SERVERDB-01-DES\opc'. (Microsoft SQL Server, Error: 18456)

For help, click: https://docs.microsoft.com/sql/relational-databases/errors-events/mssqlserver-18456-database-engine-error
------------------------------
BUTTONS:
OK

No hemos descubierto nada nuevo. Recuerden que habíamos cambiado la clave del usuario "OPC" con el primer logeo. La clave no coincide, por tanto tenemos un problema de logeo.

Otra cosa obvia que no debes intentar, el usuario SA no tiene como clave SA, por tanto no te sirve de nada.

Ahora, pensaríamos: "hagamos sustitución de la clave del usuario opc con la clave original brindada con la instalación", suena sencillo, pero otra sorpresa, la clave no cumple con las políticas de manejo de claves, así que no la puedes resetear al valor original.


Hago copia de las imágenes por si desaparece o le pasa algo al sitio. - Respetando los derechos de autoría del sitio  hex64.net.

El primer paso es ir al SQL Server Configuration Manager

1.  Open the SQL Server Configuration manager.

Luego vamos a ir en SQL Server Services y vamos a detener el servicio SQL Server Instance.


Damos click derecho en la opción de SQL Server Instancia y seleccionamos propiedades.

Vamos directo a parámetros de inicio y agregamos el paramétro "-m" y le damos aplicar.


Cuando aparezca la ventana con el mensaje de "Warning" aceptamos aplicar los cambios a nivel de los parámetros de inicio.

Ahora reiniciamos el servicio.


Vamos a iniciar una ventana de comandos de windows en modo administrativo. Recuerden que "opc" es administrador del equipo.

Iniciamos la consola de comandos de SQLSERVER y vamos a digitar la siguiente sentencia cambiando los valores respectivos por los propios de su servicio y lo ejecutamos con el comando "GO"



Una vez ejecutada la sentencia, vamos a ir nuevamente a las propiedades del servicio de SQL Server y removemos el parámetro "-m" ingresado previamente y reiniciamos el servicio de base de datos.

Ahora ya puedes ir nuevamente al SSMS, seleccionar la opción de logeo con la cuenta de sistema operativo y todo solucionado.


Comunidad en español de técnicos en Oracle por Javier Morales- en Discord

Por: Facundo Ezequiel Grande
Lead Oracle Database Administrator - Especialista DBA Oracle en Red Link S.A.

Te cuento que Javier Morales está creando una comunidad en español de técnicos Oracle en Discord, para chatear, comentarnos dudas, conocernos, etc. ¿Te gustaría participar? Es gratis, y ya hemos empezado a hacer laboratorios de rendimiento SQL, podcast, cosas así... Te paso el enlace para que te sumes si quieres! Cuantos más seamos, mejor!

https://lnkd.in/dgAYyd7t


Mejora de 10x en ODI ETLs con un sencillo paso- Por Ariel Loría-Cloud Enginner en Oracle- Lectura recomendada



Cloud Engineer en Oracle

El tuning de ETLs en Oracle Data Integrator (y cualquier otra herramienta de integración de datos) puede ser un reto enorme. Siendo los ETLs unos tipos de procesos que suelen tomar mucho tiempo de nuestras noches y nuestras madrugadas, el tuning se convierte clave para soportar las cortas ventanas que tenemos para ejecutarlos.

Para hacer estas mejoras tenemos múltiples buenas prácticas que podemos considerar: hacer configuraciones de procesos batches, hacer la menor cantidad de transformaciones posibles, tener menos componentes en el flujo, ejecutar los procesos cuando la base de datos tiene menos carga, asegurarnos que el ancho de banda no tenga vecinos ruidosos, etc.

En mi experiencia buscando estos tiempos increíbles para ejecutar ETLs con millones de registros, encontré una recomendación de parte de Product Management en Oracle que cambió mi lista de buenas prácticas a la hora de crear ETLs en Oracle Data Integrator.

Los parámetros a cambiar en nuestras conexiones son los siguientes:
  • Batch Update Size
  • Array Fetch Size
Estos 2 parámetros controlan cuantas filas son pre-buscadas y colocadas en memorias para mejorar las siguientes ejecuciones y también ayudan con el mapeo de variables cuando se ejecutan DMLs con el fin de hacer una sola ejecución en lugar de ejecuciones separadas.

Mi experiencia de rendimiento cambiando estos parámetros son de 10x de mejora de performance en los ETLs, lo cual nos ha ayudado a posicionar ODI como un producto superior en performance con respecto a otras herramientas del mercado.

¿Cuánto deben subirse estos valores? La respuesta puede ser variable. Hay diferentes razones que nos pueden impactar positivamente si cambiamos este valor x5 o 10x. La recomendación más sencilla es hacer los cambios y ponerlo a prueba.

Al igual como me ayudó a mi, espero que este pequeño cambio les impacte sus ETLs de manera potencial.

TNS-00515: Connect failed because target host or object does not exist- desplegando 19c en OCI

 Con esto de que a la hora de hacer un despliegue en el OCI nos permite ponerle un nombre lo más representativo posible al ambiente al cuál pertenece el servicio, se nos va la mano con dicha descripción en ocasiones.

Posiblemente a la hora de hacer el despliegue no tengas inconvenientes que el nombre dado a la máquina, sea de más de 40 caracteres de largo.

Incluso a la hora de instalar el motor de base de datos y levantar el LISTENER, este no presente problema alguno.

Sin embargo, si haces una imágen del servicio desplegado y quieres crear otro ambiente dentro del mismo compartimiento o en otro, tomando como base esta imágen creada, vas a tener problemas a la hora de levantar el servicio LISTENER.

Todo esta ligado al nombre del servidor asignado, en base a la descripción que le dimos inicialmente.

Basta con utilizar el comando "hostnamectl" para cambiar el nombre del servidor, no sin antes, tomar en consideración lo dicho en el post https://oracledbacr.blogspot.com/2022/01/el-fantasma-de-la-opera-cambio-el.html sobre las consideraciones en OCI para mantener el cambio del hostname, una vez que este sea reiniciado.


[oracle@ambiente-de-produccion-base-de-datos-flexcube admin]$ lsnrctl

LSNRCTL for Linux: Version 19.0.0.0.0 - Production on 30-AUG-2022 15:44:01

Copyright (c) 1991, 2020, Oracle.  All rights reserved.

Welcome to LSNRCTL, type "help" for information.

LSNRCTL> start
Starting /opt/app/oracle/product/19c/bin/tnslsnr: please wait...

TNSLSNR for Linux: Version 19.0.0.0.0 - Production
System parameter file is /opt/app/oracle/product/19c/network/admin/listener.ora
Log messages written to /opt/app/oracle/diag/tnslsnr/ambiente-de-produccion-base-de-datos-flexcube/listener/alert/log.xml
Error listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=ambiente-produccion-base-de-datos-flexcube)(PORT=1521)))
TNS-12545: Connect failed because target host or object does not exist
 TNS-12560: TNS:protocol adapter error
  TNS-00515: Connect failed because target host or object does not exist
   Linux Error: 2: No such file or directory

Listener failed to start. See the error message(s) above...

LSNRCTL> exit
[oracle@ambiente-de-produccion-base-de-datos-flexcube admin]$ exit
logout
[opc@ambiente-de-produccion-base-de-datos-flexcube ~]$ sudo -s /bin/bash
[root@ambiente-de-produccion-base-de-datos-flexcube opc]# systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2022-08-30 11:39:41 CST; 4h 5min ago
     Docs: man:firewalld(1)
 Main PID: 1297 (firewalld)
   Memory: 28.3M
   CGroup: /system.slice/firewalld.service
           └─1297 /usr/bin/python2 -Es /usr/sbin/firewalld --nofork --nopid

Aug 30 11:39:41 ambiente-produccion-base-de-datos-flexcube systemd[1]: Starting firewalld - dynamic firewall daemon...
Aug 30 11:39:41 ambiente-produccion-base-de-datos-flexcube systemd[1]: Started firewalld - dynamic firewall daemon.
[root@ambiente-de-produccion-base-de-datos-flexcube opc]# firewall-cmd --permanent --zone=public --list-services
dhcpv6-client ssh
[root@ambiente-de-produccion-base-de-datos-flexcube opc]# firewall-cmd --permanent --zone=public --list-ports
22/tcp 1521/tcp 5500/tcp 5501/tcp
[root@ambiente-de-produccion-base-de-datos-flexcube opc]# adrci
bash: adrci: command not found
[root@ambiente-de-produccion-base-de-datos-flexcube opc]# exit
exit
[opc@ambiente-de-produccion-base-de-datos-flexcube ~]$ sudo su - oracle
Last login: Tue Aug 30 15:41:33 CST 2022 on pts/0
[oracle@ambiente-de-produccion-base-de-datos-flexcube ~]$ env|grep ORACLE
ORACLE_SID=cdb
ORACLE_BASE=/opt/app/oracle
ORACLE_HOME=/opt/app/oracle/product/19c
[oracle@ambiente-de-produccion-base-de-datos-flexcube ~]$ adrci

ADRCI: Release 19.0.0.0.0 - Production on Tue Aug 30 15:46:14 2022

Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.

ADR base = "/opt/app/oracle"
adrci> show laert
DIA-48415: Syntax error found in string [show laert] at column [10]

adrci> show homes
ADR Homes:
diag/rdbms/cdb/cdb
diag/clients/user_oracle/host_3013543445_110
diag/tnslsnr/ambiente-produccion-base-de-datos-flexcube/listener
diag/tnslsnr/ambiente-de-produccion-base-de-datos-flexcube/listener
adrci> set home diag/tnslsnr/ambiente-de-produccion-base-de-datos-flexcube/listener
adrci> show alert

ADR Home = /opt/app/oracle/diag/tnslsnr/ambiente-de-produccion-base-de-datos-flexcube/listener:
*************************************************************************
Output the results to file: /tmp/alert_2379_14052_listener_1.ado
  TNS-00515: Connect failed because target host or object does not exist
   Linux Error: 2: No such file or directory
2022-08-30 15:42:54.100000 -06:00

LISTENER for Linux: Version 19.0.0.0.0 - Production
Version 19.10.0.0.0

System parameter file is /opt/app/oracle/product/19c/network/admin/listener.ora
Log messages written to /opt/app/oracle/diag/tnslsnr/ambiente-de-produccion-base-de-datos-flexcube/listener/alert/log.xml
Trace information written to /opt/app/oracle/diag/tnslsnr/ambiente-de-produccion-base-de-datos-flexcube/listener/trace/ora_1354_139893665668288.trc
Trace level is currently 0

Started with pid=1354
Error listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=ambiente-produccion-base-de-datos-flexcube)(PORT=1521)))
TNS-12545: Connect failed because target host or object does not exist
 TNS-12560: TNS:protocol adapter error
  TNS-00515: Connect failed because target host or object does not exist
   Linux Error: 2: No such file or directory
2022-08-30 15:44:05.244000 -06:00

LISTENER for Linux: Version 19.0.0.0.0 - Production
Version 19.10.0.0.0

System parameter file is /opt/app/oracle/product/19c/network/admin/listener.ora
Log messages written to /opt/app/oracle/diag/tnslsnr/ambiente-de-produccion-base-de-datos-flexcube/listener/alert/log.xml
Trace information written to /opt/app/oracle/diag/tnslsnr/ambiente-de-produccion-base-de-datos-flexcube/listener/trace/ora_1739_140179646594240.trc
Trace level is currently 0

Started with pid=1739
Error listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=ambiente-produccion-base-de-datos-flexcube)(PORT=1521)))
TNS-12545: Connect failed because target host or object does not exist
 TNS-12560: TNS:protocol adapter error
  TNS-00515: Connect failed because target host or object does not exist
   Linux Error: 2: No such file or directory

Todos los Sábados a las 8:00PM

Optimismo para una vida Mejor

Optimismo para una vida Mejor
Noticias buenas que comentar