RMAN-01009: syntax error: found "integer": expecting one of: "double-quoted-string, identifier, single-quoted-string, "

RMAN es para mi una de las herramientas preferidadas, sin embargo, cuando de intentar parsear un error de ejecución en un script se trata, es realmente todo un arte, saber lo que pasa.

Uno se pregunta, porque lo hicieron tan complicado.? 

 Podría ser más simple.

Hagan cuenta del siguiente script:

# Respaldo de nivel 1 Incremental Acumulativo con Utilitario RMAN
# Contiene los bloques que han cambiado desde el mas reciente respaldo de nivel 0 incremental
        sql 'alter system archive log current';
        sql "alter session set nls_date_format=''dd.mm.yyyy hh24:mi:ss''";
        RUN
        {
        configure controlfile autobackup on;
        set command id to '100011_BKAcum_Inc_level_0';
        ALLOCATE CHANNEL c1 DEVICE TYPE disk;
        ALLOCATE CHANNEL c2 DEVICE TYPE disk;
        ALLOCATE CHANNEL c3 DEVICE TYPE disk;
        ALLOCATE CHANNEL c4 DEVICE TYPE disk;
        backup incremental level 0 cumulative database tag='LEVEL NIVEL 0 100011' format '/DR_BCKS/rman/10.0.0.11/backup_rman/RMAN_100011_ACUM_LEVEL0_%d_%T_%s_%p';
        sql 'alter system archive log current';
        backup tag 100011_ARC format '/DR_BCKS/rman/10.0.0.11/backup_rman/RMAN_100011_ARCH_%d_%T_%s_%p' archivelog all;
        backup tag 100011_CTRL current controlfile format '/DR_BCKS/rman/10.0.0.11/backup_rman/CNTRLFILE_100011_%d_%T_%s_%p_CTL';
        release channel c4;
        release channel c3;
        release channel c2;
        release channel c1;
        }
exit;

Posiblemente si lo revisan de pies a cabeza, a simple vista no encontraran nada malo.

Pero a la hora de ejecutarse, genera este error.

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00558: error encountered while parsing input commands
RMAN-01009: syntax error: found "integer": expecting one of: "double-quoted-string, identifier, single-quoted-string, "
RMAN-01007: at line 7 column 12 file: standard input

Ahora, estoy buscando donde tengo un "entero" y que espera una "doble comilla".

Bastante confuso en verdad el mensaje de error.

Pues es el tema te puede llevar varias minutos buscándolo y es muy posible que no lo encuentres.

En realidad lo que sucede es que en la línea del tag para el backup de los archivelogs y el controlfile, hemos iniciado el nombre del TAG con un número.

        backup tag 100011_ARC format '/DR_BCKS/rman/10.0.0.11/backup_rman/RMAN_100011_ARCH_%d_%T_%s_%p' archivelog all;
        backup tag 100011_CTRL current controlfile format '/DR_BCKS/rman/10.0.0.11/backup_rman/CNTRLFILE_100011_%d_%T_%s_%p_CTL';

Eso es lo que provoca el error. El nombre del TAG no puede iniciar con un número, tiene que ser con una letra.

# Respaldo de nivel 1 Incremental Acumulativo con Utilitario RMAN
# Contiene los bloques que han cambiado desde el mas reciente respaldo de nivel 0 incremental
        sql 'alter system archive log current';
        sql "alter session set nls_date_format=''dd.mm.yyyy hh24:mi:ss''";
        RUN
        {
        configure controlfile autobackup on;
        set command id to '100011_BKAcum_Inc_level_0';
        ALLOCATE CHANNEL c1 DEVICE TYPE disk;
        ALLOCATE CHANNEL c2 DEVICE TYPE disk;
        ALLOCATE CHANNEL c3 DEVICE TYPE disk;
        ALLOCATE CHANNEL c4 DEVICE TYPE disk;
        backup incremental level 0 cumulative database tag='LEVEL NIVEL 0 100011' format '/DR_BCKS/rman/10.0.0.11/backup_rman/RMAN_100011_ACUM_LEVEL0_%d_%T_%s_%p';
        sql 'alter system archive log current';
        backup tag BK100011_ARC format '/DR_BCKS/rman/10.0.0.11/backup_rman/RMAN_100011_ARCH_%d_%T_%s_%p' archivelog all;
        backup tag BK100011_CTRL current controlfile format '/DR_BCKS/rman/10.0.0.11/backup_rman/CNTRLFILE_100011_%d_%T_%s_%p_CTL';
        release channel c4;
        release channel c3;
        release channel c2;
        release channel c1;
        }
exit;

Cambiamos el nombre del TAG para que inicie con letras y volvemos a correr el script y VOILA.

[oracle@migra-db scripts]$ rman target / < backup_rman_level0.rman

Recovery Manager: Release 19.0.0.0.0 - Production on Wed Oct 5 10:41:35 2022
Version 19.6.0.0.0

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

connected to target database: ORCL (DBID=40859130)

RMAN> 2> 3>
using target database control file instead of recovery catalog
sql statement: alter system archive log current

RMAN>
sql statement: alter session set nls_date_format=''dd.mm.yyyy hh24:mi:ss''

RMAN> 2> 3> 4> 5> 6> 7> 8> 9> 10> 11> 12> 13> 14> 15> 16> 17>
old RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
new RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
new RMAN configuration parameters are successfully stored

executing command: SET COMMAND ID

allocated channel: c1
channel c1: SID=1221 device type=DISK

allocated channel: c2
channel c2: SID=40 device type=DISK

allocated channel: c3
channel c3: SID=1193 device type=DISK

allocated channel: c4
channel c4: SID=1211 device type=DISK

Starting backup at 05-OCT-22
channel c1: starting incremental level 0 datafile backup set
channel c1: specifying datafile(s) in backup set
input datafile file number=00013 name=+DATA/ORCL_IAD2H4/BA8A363B8C1C7E0DE0530204000BA38F/DATAFILE/fcubsgold.280.1064825319
channel c1: starting piece 1 at 05-OCT-22
channel c2: starting incremental level 0 datafile backup set
channel c2: specifying datafile(s) in backup set
input datafile file number=00015 name=+DATA/ORCL_IAD2H4/BA8A363B8C1C7E0DE0530204000BA38F/DATAFILE/undotbs1.279.1065732281
channel c2: starting piece 1 at 05-OCT-22
channel c3: starting incremental level 0 datafile backup set
channel c3: specifying datafile(s) in backup set
input datafile file number=00010 name=+DATA/ORCL_IAD2H4/BA8A363B8C1C7E0DE0530204000BA38F/DATAFILE/undotbs1.272.1063639379
channel c3: starting piece 1 at 05-OCT-22
channel c4: starting incremental level 0 datafile backup set
channel c4: specifying datafile(s) in backup set
input datafile file number=00017 name=+DATA/ORCL_IAD2H4/BA8A363B8C1C7E0DE0530204000BA38F/DATAFILE/fcubsgld.287.1065733587
channel c4: starting piece 1 at 05-OCT-22
channel c4: finished piece 1 at 05-OCT-22
piece handle=/DR_BCKS/rman/10.0.0.11/backup_rman/RMAN_100011_ACUM_LEVEL0_ORCL_20221005_71055_1 tag=LEVEL NIVEL 0 100011 comment=NONE
channel c4: backup set complete, elapsed time: 00:04:45
channel c4: starting incremental level 0 datafile backup set
channel c4: specifying datafile(s) in backup set
input datafile file number=00008 name=+DATA/ORCL_IAD2H4/BA8A363B8C1C7E0DE0530204000BA38F/DATAFILE/system.276.1063639361
channel c4: starting piece 1 at 05-OCT-22
channel c3: finished piece 1 at 05-OCT-22
piece handle=/DR_BCKS/rman/10.0.0.11/backup_rman/RMAN_100011_ACUM_LEVEL0_ORCL_20221005_71054_1 tag=LEVEL NIVEL 0 100011 comment=NONE
channel c3: backup set complete, elapsed time: 00:07:50
channel c3: starting incremental level 0 datafile backup set
channel c3: specifying datafile(s) in backup set
input datafile file number=00034 name=+DATA/ORCL_IAD2H4/BA8A363B8C1C7E0DE0530204000BA38F/DATAFILE/fcubsuat_00.dbf
channel c3: starting piece 1 at 05-OCT-22
channel c4: finished piece 1 at 05-OCT-22
piece handle=/DR_BCKS/rman/10.0.0.11/backup_rman/RMAN_100011_ACUM_LEVEL0_ORCL_20221005_71056_1 tag=LEVEL NIVEL 0 100011 comment=NONE
channel c4: backup set complete, elapsed time: 00:03:31
channel c4: starting incremental level 0 datafile backup set
channel c4: specifying datafile(s) in backup set
input datafile file number=00012 name=+DATA/ORCL_IAD2H4/BA8A363B8C1C7E0DE0530204000BA38F/DATAFILE/users.275.1063639345
input datafile file number=00023 name=+DATA/ORCL_IAD2H4/BA8A363B8C1C7E0DE0530204000BA38F/DATAFILE/obdx_ias_opss.283.1069033695
input datafile file number=00030 name=+DATA/ORCL_IAD2H4/BA8A363B8C1C7E0DE0530204000BA38F/DATAFILE/obdx_iau.295.1069034919
input datafile file number=00031 name=+DATA/ORCL_IAD2H4/BA8A363B8C1C7E0DE0530204000BA38F/DATAFILE/obdx_stb.297.1069034919
input datafile file number=00032 name=+DATA/ORCL_IAD2H4/BA8A363B8C1C7E0DE0530204000BA38F/DATAFILE/obdx_wls.294.1069034921
channel c4: starting piece 1 at 05-OCT-22
channel c3: finished piece 1 at 05-OCT-22
piece handle=/DR_BCKS/rman/10.0.0.11/backup_rman/RMAN_100011_ACUM_LEVEL0_ORCL_20221005_71057_1 tag=LEVEL NIVEL 0 100011 comment=NONE
channel c3: backup set complete, elapsed time: 00:00:40
channel c3: starting incremental level 0 datafile backup set
channel c3: specifying datafile(s) in backup set
input datafile file number=00037 name=/u01/app/oracle/product/19.0.0.0/dbhome_1/dbs/tbsIntegracionDataTestParam.dbf
input datafile file number=00009 name=+DATA/ORCL_IAD2H4/BA8A363B8C1C7E0DE0530204000BA38F/DATAFILE/sysaux.271.1063639371
input datafile file number=00014 name=+DATA/ORCL_IAD2H4/BA8A363B8C1C7E0DE0530204000BA38F/DATAFILE/fcubsmig.284.1064825423
input datafile file number=00020 name=+DATA/ORCL_IAD2H4/BA8A363B8C1C7E0DE0530204000BA38F/DATAFILE/tbs_obdx_mig_ehms.dbf
input datafile file number=00021 name=+DATA/ORCL_IAD2H4/BA8A363B8C1C7E0DE0530204000BA38F/DATAFILE/obdx_mig.dbf
channel c3: starting piece 1 at 05-OCT-22
channel c1: finished piece 1 at 05-OCT-22
piece handle=/DR_BCKS/rman/10.0.0.11/backup_rman/RMAN_100011_ACUM_LEVEL0_ORCL_20221005_71052_1 tag=LEVEL NIVEL 0 100011 comment=NONE
channel c1: backup set complete, elapsed time: 00:08:36
channel c1: starting incremental level 0 datafile backup set
channel c1: specifying datafile(s) in backup set
input datafile file number=00022 name=+DATA/ORCL_IAD2H4/BA8A363B8C1C7E0DE0530204000BA38F/DATAFILE/obdx_audit_mig.dbf
input datafile file number=00033 name=+DATA/ORCL_IAD2H4/BA8A363B8C1C7E0DE0530204000BA38F/DATAFILE/tbs_obdx_sit_ehms.dbf
input datafile file number=00035 name=+DATA/ORCL_IAD2H4/BA8A363B8C1C7E0DE0530204000BA38F/DATAFILE/tbs_data_etl.289.1108569251
input datafile file number=00036 name=+DATA/ORCL_IAD2H4/BA8A363B8C1C7E0DE0530204000BA38F/DATAFILE/fcubsgold.300.1113398881
channel c1: starting piece 1 at 05-OCT-22
channel c1: finished piece 1 at 05-OCT-22
piece handle=/DR_BCKS/rman/10.0.0.11/backup_rman/RMAN_100011_ACUM_LEVEL0_ORCL_20221005_71060_1 tag=LEVEL NIVEL 0 100011 comment=NONE
channel c1: backup set complete, elapsed time: 00:00:25
channel c1: starting incremental level 0 datafile backup set
channel c1: specifying datafile(s) in backup set
input datafile file number=00003 name=+DATA/ORCL_IAD2H4/DATAFILE/sysaux.262.1063638273
channel c1: starting piece 1 at 05-OCT-22
channel c2: finished piece 1 at 05-OCT-22
piece handle=/DR_BCKS/rman/10.0.0.11/backup_rman/RMAN_100011_ACUM_LEVEL0_ORCL_20221005_71053_1 tag=LEVEL NIVEL 0 100011 comment=NONE
channel c2: backup set complete, elapsed time: 00:09:02
channel c2: starting incremental level 0 datafile backup set
channel c2: specifying datafile(s) in backup set
input datafile file number=00001 name=+DATA/ORCL_IAD2H4/DATAFILE/system.261.1063638237
input datafile file number=00004 name=+DATA/ORCL_IAD2H4/DATAFILE/undotbs1.263.1063638289
channel c2: starting piece 1 at 05-OCT-22
channel c2: finished piece 1 at 05-OCT-22
piece handle=/DR_BCKS/rman/10.0.0.11/backup_rman/RMAN_100011_ACUM_LEVEL0_ORCL_20221005_71062_1 tag=LEVEL NIVEL 0 100011 comment=NONE
channel c2: backup set complete, elapsed time: 00:00:25
channel c2: starting incremental level 0 datafile backup set
channel c2: specifying datafile(s) in backup set
input datafile file number=00016 name=+DATA/ORCL_IAD2H4/DATAFILE/undotbs1.286.1065732343
input datafile file number=00011 name=+DATA/ORCL_IAD2H4/DATAFILE/users.274.1063639345
channel c2: starting piece 1 at 05-OCT-22
channel c2: finished piece 1 at 05-OCT-22
piece handle=/DR_BCKS/rman/10.0.0.11/backup_rman/RMAN_100011_ACUM_LEVEL0_ORCL_20221005_71063_1 tag=LEVEL NIVEL 0 100011 comment=NONE
channel c2: backup set complete, elapsed time: 00:00:03
channel c2: starting incremental level 0 datafile backup set
channel c2: specifying datafile(s) in backup set
input datafile file number=00006 name=+DATA/ORCL_IAD2H4/9BB009ACC6A03ABEE053B407F40A09A3/DATAFILE/sysaux.266.1063638403
channel c2: starting piece 1 at 05-OCT-22
channel c4: finished piece 1 at 05-OCT-22
piece handle=/DR_BCKS/rman/10.0.0.11/backup_rman/RMAN_100011_ACUM_LEVEL0_ORCL_20221005_71058_1 tag=LEVEL NIVEL 0 100011 comment=NONE
channel c4: backup set complete, elapsed time: 00:01:16
channel c4: starting incremental level 0 datafile backup set
channel c4: specifying datafile(s) in backup set
input datafile file number=00005 name=+DATA/ORCL_IAD2H4/9BB009ACC6A03ABEE053B407F40A09A3/DATAFILE/system.265.1063638403
channel c4: starting piece 1 at 05-OCT-22
channel c1: finished piece 1 at 05-OCT-22
piece handle=/DR_BCKS/rman/10.0.0.11/backup_rman/RMAN_100011_ACUM_LEVEL0_ORCL_20221005_71061_1 tag=LEVEL NIVEL 0 100011 comment=NONE
channel c1: backup set complete, elapsed time: 00:00:46
channel c1: starting incremental level 0 datafile backup set
channel c1: specifying datafile(s) in backup set
input datafile file number=00007 name=+DATA/ORCL_IAD2H4/9BB009ACC6A03ABEE053B407F40A09A3/DATAFILE/undotbs1.267.1063638403
channel c1: starting piece 1 at 05-OCT-22
channel c2: finished piece 1 at 05-OCT-22
piece handle=/DR_BCKS/rman/10.0.0.11/backup_rman/RMAN_100011_ACUM_LEVEL0_ORCL_20221005_71064_1 tag=LEVEL NIVEL 0 100011 comment=NONE
channel c2: backup set complete, elapsed time: 00:00:15
channel c3: finished piece 1 at 05-OCT-22
piece handle=/DR_BCKS/rman/10.0.0.11/backup_rman/RMAN_100011_ACUM_LEVEL0_ORCL_20221005_71059_1 tag=LEVEL NIVEL 0 100011 comment=NONE
channel c3: backup set complete, elapsed time: 00:01:15
channel c4: finished piece 1 at 05-OCT-22
piece handle=/DR_BCKS/rman/10.0.0.11/backup_rman/RMAN_100011_ACUM_LEVEL0_ORCL_20221005_71065_1 tag=LEVEL NIVEL 0 100011 comment=NONE
channel c4: backup set complete, elapsed time: 00:00:15
channel c1: finished piece 1 at 05-OCT-22
piece handle=/DR_BCKS/rman/10.0.0.11/backup_rman/RMAN_100011_ACUM_LEVEL0_ORCL_20221005_71066_1 tag=LEVEL NIVEL 0 100011 comment=NONE
channel c1: backup set complete, elapsed time: 00:00:03
Finished backup at 05-OCT-22

Starting Control File and SPFILE Autobackup at 05-OCT-22
piece handle=+RECO/ORCL_IAD2H4/AUTOBACKUP/2022_10_05/s_1117277504.359.1117277505 comment=NONE
Finished Control File and SPFILE Autobackup at 05-OCT-22

sql statement: alter system archive log current

Starting backup at 05-OCT-22
current log archived
channel c1: starting archived log backup set
channel c1: specifying archived log(s) in backup set
input archived log thread=1 sequence=16005 RECID=16005 STAMP=1116738170
...
input archived log thread=1 sequence=16004 RECID=16004 STAMP=1116734552
channel c4: starting piece 1 at 05-OCT-22
channel c1: finished piece 1 at 05-OCT-22
piece handle=/DR_BCKS/rman/10.0.0.11/backup_rman/RMAN_100011_ARCH_ORCL_20221005_71068_1 tag=BK100011_ARC comment=NONE
channel c1: backup set complete, elapsed time: 00:24:42
channel c1: starting archived log backup set
channel c1: specifying archived log(s) in backup set
input archived log thread=1 sequence=16059 RECID=16059 STAMP=1116939258
...
input archived log thread=1 sequence=16112 RECID=16112 STAMP=1117047755
channel c1: starting piece 1 at 05-OCT-22
channel c2: finished piece 1 at 05-OCT-22
piece handle=/DR_BCKS/rman/10.0.0.11/backup_rman/RMAN_100011_ARCH_ORCL_20221005_71069_1 tag=BK100011_ARC comment=NONE
channel c2: backup set complete, elapsed time: 00:24:43
channel c2: starting archived log backup set
channel c2: specifying archived log(s) in backup set
input archived log thread=1 sequence=16168 RECID=16168 STAMP=1117166572
input archived log thread=1 sequence=16169 RECID=16169 STAMP=1117170179
...
input archived log thread=1 sequence=16230 RECID=16230 STAMP=1117277513
input archived log thread=1 sequence=16231 RECID=16231 STAMP=1117277513
channel c2: starting piece 1 at 05-OCT-22
channel c3: finished piece 1 at 05-OCT-22
piece handle=/DR_BCKS/rman/10.0.0.11/backup_rman/RMAN_100011_ARCH_ORCL_20221005_71070_1 tag=BK100011_ARC comment=NONE
channel c3: backup set complete, elapsed time: 00:24:43
channel c4: finished piece 1 at 05-OCT-22
piece handle=/DR_BCKS/rman/10.0.0.11/backup_rman/RMAN_100011_ARCH_ORCL_20221005_71071_1 tag=BK100011_ARC comment=NONE
channel c4: backup set complete, elapsed time: 00:24:42

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”. ”

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.

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

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)

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.