Neutralidad en Seguridad, algo de lo que no hablamos mucho.

En mis charlas sobre "Ethical Hacking", me encanta hablar sobre “Neutralidad en Seguridad”. Me gusta ampliar el principio clásico de mínimo privilegio desde una perspectiva puramente técnica, hacia una dimensión de gobernanza, responsabilidad y protección del propio usuario.

El principio tradicional de mínimo privilegio (Principle of Least Privilege, PoLP) establece:

Una identidad (usuario, aplicación, proceso o servicio) debe recibir únicamente los privilegios estrictamente necesarios para ejecutar sus funciones autorizadas, durante el tiempo necesario y bajo las condiciones necesarias.

Sin embargo mi concepto agrega una capa adicional: un exceso de privilegios no solo incrementa el riesgo para la organización, sino que rompe la neutralidad del usuario frente a un incidente.

Para mi: Neutralidad en seguridad: es el principio mediante el cual los privilegios asignados a una identidad digital deben mantenerse alineados estrictamente con sus responsabilidades reales, evitando que permisos innecesarios conviertan a dicha identidad en un punto injustificado de exposición, sospecha o atribución dentro de un incidente de seguridad.

El punto central desde mi perspectiva, es que la neutralidad ocurre cuando, los Permisos concedidos = Responsabilidad funcional. Ni menos, ni más.

Desde el punto de vista de seguridad, un exceso de privilegios genera varios problemas:

1. Incrementa la superficie de ataque

Ejemplo en base de datos:

Un analista requiere: 

• SELECT sobre tablas de reportes, 
• pero recibe: SELECT ANY TABLE o peor aún "DBA".

El atacante hereda todo lo que la cuenta puede hacer, no solamente lo que el usuario normalmente hace.

2. Rompe la presunción operacional de inocencia.

Supongamos:

• Usuario A: necesita consultar clientes, tiene acceso solo lectura
• Usuario B: necesita consultar clientes, pero además tiene: borrar registros, exportar información, crear usuarios, modificar privilegios.

Si ocurre una fuga, desde un análisis forense el Usuario A: 

• ¿Tenía capacidad técnica? 
• Respuesta: NO, menor probabilidad como origen.

En el caso del Usuario B:

• ¿Tenía capacidad técnica? 
• Respuesta: SÍ, debe investigarse. Aunque Usuario B sea inocente, los privilegios excesivos lo colocaron dentro del perímetro de sospecha.

3. La asignación excesiva de permisos crea responsabilidad compartida

Una frase que resume bien el concepto:

"Todo privilegio innecesario es una responsabilidad innecesaria transferida al usuario."

Dar privilegios no es solamente dar capacidad, también es asignar: 

1. riesgo,
2. trazabilidad, 
3. obligación de custodia, 
4. exposición ante auditoría.

Ustedes que opinan.?

Oracle Enterprise Edition "** MISSING: 6604574/6604574" en nombre de objeto en estadísticas del AWR.

Tenemos un script para validar el crecimiento de objetos dentro de la base de datos en los últimos 6 días y cuando ejecutamos la consulta nos devuelve la siguiente salida.

OWNER                     SEGMENT_NAME                        SEGMENT_TYPE               GROWTH_MB------------------------- ----------------------------------- -------------------- ---------------
INTEGRACION               LOG                                 TABLE                       1,714.20
FCUBSLIVE                 GWTB_MSG_OUT_LOG                    TABLE                       1,258.01
INTEGRACION               SYS_LOB0000989853C00006$$           LOB                           832.05
FCUBSLIVE                 GWTB_MSG_IN_LOG                     TABLE                         750.85
INTEGRACION               TRACK_ENTRY_REQUEST_INTEGRACION_HIS TABLE                         733.66
                          TORY

** MISSING **             ** MISSING: 6604574/6604574         UNDEFINED                     684.62
** MISSING **             ** MISSING: 6618097/6618097         UNDEFINED                     684.56
** MISSING **             ** MISSING: 6611295/6611295         UNDEFINED                     681.16
** MISSING **             ** MISSING: 6624752/6624752         UNDEFINED                     615.75
** MISSING **             ** MISSING: 6631455/6631455         UNDEFINED                     613.48
** MISSING **             ** MISSING: 6597842/6597842         UNDEFINED                     612.60
FCUBSLIVE                 PK01_ICTB_DEPOSIT_EXECUTION_LO      INDEX                         355.53
** MISSING **             ** MISSING: 6591054/6591054         UNDEFINED                     342.05
FCUBSLIVE                 IDX_CLTP_AMT_DUE                    INDEX                         304.77
FCUBSLIVE                 PK_CLTP_ACCOUNT_COMP_CALC           INDEX                         286.41
FCUBSLIVE                 PK01_STTB_FIELD_LOG                 INDEX                         273.21
SYS                       I_SCHEDULER_JOB_RUN_DETAILS         INDEX                         261.97
** MISSING **             ** MISSING: 6576422/6576422         UNDEFINED                     256.87
** MISSING **             ** MISSING: 6584108/6584108         UNDEFINED                     243.75
SYS                       SCHEDULER$_INSTANCE_PK              INDEX                         234.50

20 rows selected.

El script en cuestión es el siguiente, asociado a una vista para poderlo ejecutar más fácil:

create view v_tablas_mas_crecimiento as
WITH snaps AS (
    SELECT
        MIN(snap_id) AS begin_snap,
        MAX(snap_id) AS end_snap
    FROM dba_hist_snapshot
    WHERE begin_interval_time >= SYSDATE - 6
),
seg_begin AS (
    SELECT
        obj.owner,
        obj.object_name AS segment_name,
        obj.object_type AS segment_type,
        ss.space_used_delta
    FROM dba_hist_seg_stat ss
    JOIN dba_hist_seg_stat_obj obj
      ON obj.dbid = ss.dbid
     AND obj.obj# = ss.obj#
     AND obj.dataobj# = ss.dataobj#
    JOIN snaps sn
      ON ss.snap_id = sn.begin_snap
),
seg_growth AS (
    SELECT
        obj.owner,
        obj.object_name AS segment_name,
        obj.object_type AS segment_type,
        SUM(ss.space_used_delta) AS growth_bytes
    FROM dba_hist_seg_stat ss
    JOIN dba_hist_seg_stat_obj obj
      ON obj.dbid = ss.dbid
     AND obj.obj# = ss.obj#
     AND obj.dataobj# = ss.dataobj#
    WHERE ss.snap_id BETWEEN (SELECT begin_snap FROM snaps)
                         AND (SELECT end_snap FROM snaps)
    GROUP BY obj.owner, obj.object_name, obj.object_type
)
SELECT *
FROM (
    SELECT
        owner,
        segment_name,
        segment_type,
        ROUND(growth_bytes/1024/1024,2) AS growth_mb
    FROM seg_growth
    WHERE growth_bytes > 0
    ORDER BY growth_bytes DESC
)
WHERE ROWNUM <= 20;

select * from  "V_TABLAS_MAS_CRECIMIENTO";

Qué son estos datos en el nombre del objeto  ** MISSING: 6591054/6591054 ?

Vamos a explicarlo.

En Oracle, cuando estás consultando crecimiento histórico (normalmente desde AWR usando DBA_HIST_SEG_STAT y DBA_HIST_SEG_STAT_OBJ) y en lugar del nombre del objeto aparece algo como:

** MISSING: 6624752/6624752

significa que AWR tiene estadísticas históricas de un segmento, pero ya no puede resolver el objeto asociado en el diccionario histórico de objetos.

El formato corresponde normalmente a:

** MISSING: <OBJ#>/<DATAOBJ#>

En tu caso:

** MISSING: 6624752/6624752
             |       |
             |       +-- DATA_OBJECT_ID
             |
             +---------- OBJECT_ID

¿Por qué ocurre?

Oracle guarda actividad de segmentos en:

DBA_HIST_SEG_STAT
        |
        | OBJ#
        | DATAOBJ#
        v
DBA_HIST_SEG_STAT_OBJ

Cuando intenta hacer el JOIN:

ss.obj# = obj.obj#
and ss.dataobj# = obj.dataobj#

y no encuentra la descripción histórica del objeto, muestra:

** MISSING

---

Causas más comunes

1. La tabla fue eliminada

Ejemplo:

CREATE TABLE TEMP_CARGA AS SELECT ...
DROP TABLE TEMP_CARGA PURGE;

El AWR todavía conserva:

• lecturas
• escrituras
• crecimiento
• bloques modificados

pero el objeto ya no existe.

---

2. TRUNCATE de la tabla

Muy frecuente.

Al hacer:

TRUNCATE TABLE FACTURAS;

Oracle cambia:

DATA_OBJECT_ID

Ejemplo:

Antes:

OBJECT_ID       6624752
DATA_OBJECT_ID  6624752

Después:

OBJECT_ID       6624752
DATA_OBJECT_ID  6639011

Para AWR parece otro segmento.

---

3. Operaciones MOVE / REBUILD

Ejemplos:

ALTER TABLE CLIENTES MOVE;

ALTER INDEX IDX_CLIENTES REBUILD;

Generan nuevo DATAOBJ#.

---

4. Objetos temporales creados por procesos

Muy común con:

• Data Pump
• Cargas masivas
• ETL
• cargas batch
• APEX
• reportes
• particiones temporales

---

Cómo intentar identificarlo

Primero buscar si todavía existe:

SELECT owner,
       object_name,
       object_type,
       object_id,
       data_object_id,
       created,
       last_ddl_time
FROM dba_objects
WHERE object_id = 6624752
   OR data_object_id = 6624752;

Si no devuelve nada, ya desapareció.

---

Buscarlo en recycle bin:

SELECT owner,
       original_name,
       object_name,
       type,
       droptime
FROM dba_recyclebin
WHERE base_object = 6624752;

---

También puedes revisar si AWR todavía tiene rastros:

SELECT *
FROM dba_hist_seg_stat_obj
WHERE obj# = 6624752
   OR dataobj# = 6624752;

No necesariamente significa corrupción ni problema de diccionario.

Webinar Compliance y confianza: convierta los reportes SOC en una ventaja competitiva

 

Hola gente comparto con ustedes esta información con la participación de uno de nuestros aliados en el #LAOUCTOUR 2026 Legadmi

📢 Webinar Exclusivo | Compliance y confianza: convierta los reportes SOC en una ventaja competitiva

¿Su empresa maneja información sensible o trabaja con proveedores que lo hacen?

Le invitamos a un webinar donde descubrirá cómo los reportes SOC 1 y SOC 2 pueden ayudarle a reducir riesgos, fortalecer la confianza de sus clientes y diferenciarse en el mercado.

📅 Fecha: 8 de julio 2026
⏰ Hora: 9:00 a.m. – 10:00 a.m.
💻 Modalidad: Zoom
Aprenda cómo:

✅ Evaluar y gestionar riesgos de proveedores críticos.
✅ Demostrar cumplimiento con estándares internacionales.
✅ Agilizar cierres

comerciales mediante mayor confianza y transparencia.
🎙️ Expositores:
* José Manuel Ascanio – Director, Legadmi
• Nelson Camargo – IT Risk Consultant Partner, Next Audit

👥 Dirigido a profesionales de Compliance, Auditoría, Riesgos, Seguridad de la Información, Compras, Finanzas, Tecnología y Operaciones.

🔗 Reserve su espacio hoy mismo aquí: https://lnkd.in/eSFvNF4E

Error creando índice tipo VECTOR en Oracle AI Database 26ai- ORA-51962: The vector memory area is out of space for the current container

Estas trabajando con campos tipo vector en Oracle AI Database 26ai y deseas crear un índice de tipo vectorial y recibes un ORA-51962. Qué debes hacer. ?

Primero que todo, un índice vectorial es una estructura de datos especializada que permite localizar rápidamente los vectores más similares a un vector de consulta dentro de un espacio multidimensional, evitando tener que comparar el vector buscado contra todos los vectores almacenados.

En Oracle AI Database 26ai, los índices vectoriales están diseñados para acelerar operaciones de Nearest Neighbor Search (NNS) utilizadas en sistemas de búsqueda semántica, RAG (Retrieval-Augmented Generation), recomendación de contenido, detección de similitud y aplicaciones de inteligencia artificial.

ORA-51962 significa que el Vector Pool del contenedor actual no tiene espacio libre suficiente o que el parámetro que controla esta estructura a nivel del SGA no ha sido configurado.

Oracle AI Database 26ai, no configura valores de facto para el parámetro VECTOR_MEMORY_SIZE. El valor de facto del parámetro es 0.

El error puede dar, ya sea porque el parámetro esta con valor 0 o bien, que el espacio en el "Pool", ha sido agotado.

Una consulta a la vista dinámica de la base de datos v$vector_index, te permite validar como se esta utilizando el espacio del VECTOR POOL.

Puedes también utilizar la siguiente consulta para obtener un mejor detalle de ocupación en MBytes.

SET LINESIZE 220

SET PAGESIZE 100

COLUMN owner              FORMAT A20

COLUMN index_name         FORMAT A35

COLUMN partition_name     FORMAT A25

COLUMN index_organization FORMAT A30

COLUMN distance_type      FORMAT A15

COLUMN allocated_mb       FORMAT 999,999,990.00

COLUMN used_mb            FORMAT 999,999,990.00

COLUMN pct_used           FORMAT 990.00

COLUMN pct_free           FORMAT 990.00

SELECT owner,

       index_name,

       index_organization,

       distance_type,

       index_dimensions,

       num_vectors,

       ROUND(allocated_bytes / 1024 / 1024, 2) AS allocated_mb,

       ROUND(used_bytes      / 1024 / 1024, 2) AS used_mb,

       ROUND((used_bytes / NULLIF(allocated_bytes, 0)) * 100, 2) AS pct_used,

       ROUND((1 - (used_bytes / NULLIF(allocated_bytes, 0))) * 100, 2) AS pct_free,

       index_used_count,

       con_id

FROM   v$vector_index

ORDER  BY pct_used DESC NULLS LAST;

Puedes obtener una versión más resumida de la ocupación de los índices con la siguiente consulta.

SELECT owner,

       index_name,

       SUM(num_vectors) AS total_vectors,

       ROUND(SUM(allocated_bytes) / 1024 / 1024, 2) AS allocated_mb,

       ROUND(SUM(used_bytes)      / 1024 / 1024, 2) AS used_mb,

       ROUND((SUM(used_bytes) / NULLIF(SUM(allocated_bytes), 0)) * 100, 2) AS pct_used

FROM   v$vector_index

GROUP  BY owner, index_name

ORDER  BY pct_used DESC;

Si la situación es que el parámetro no ha sido configurado, debes seguir los siguientes pasos.

Te mostraré como hacer la configuración del parámetro y como luego se puede crear el índice sin inconvenientes.

Detalle importante, el parámetro no es dinámico, por tanto, vas a necesitar reiniciar el contenedor de base de datos.

SQL*Plus: Release 23.26.1.0.0 - Production on Sat Jun 6 22:44:12 2026
Version 23.26.1.0.0

Copyright (c) 1982, 2025, Oracle.  All rights reserved.

Last Successful login time: Sat Jun 06 2026 21:41:10 +00:00

Connected to:
Oracle AI Database 26ai Enterprise Edition Release 23.26.1.0.0 - Production
Version 23.26.1.0.0

SQL> CREATE VECTOR INDEX IDX_CHUNKS_EMBEDDING_HNSW
ON documentos_pdf (EMBEDDING)
ORGANIZATION INMEMORY NEIGHBOR GRAPH
DISTANCE COSINE
WITH TARGET ACCURACY 95
PARAMETERS (
  TYPE HNSW,
  NEIGHBORS 32,
  EFCONSTRUCTION 500
);

ON documentos_pdf (EMBEDDING)
   *
ERROR at line 2:
ORA-51962: The vector memory area is out of space for the current container.
Help: https://docs.oracle.com/error-help/db/ora-51962/

SQL> connect / as sysdba
Connected.
SQL> show user
USER is "SYS"
SQL> SHOW PARAMETER vector_memory_size;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
vector_memory_size                   big integer 0

SQL> alter system set vector_memory_size=1g scope=both;
alter system set vector_memory_size=1g scope=both
*
ERROR at line 1:
ORA-02097: parameter cannot be modified because specified value is invalid
ORA-51950: The Oracle Database Vector Memory size cannot be increased.
Help: https://docs.oracle.com/error-help/db/ora-02097/


SQL> alter system set vector_memory_size=1g scope=spfile;

System altered.

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.

SQL> startup
ORACLE instance started.

Total System Global Area 1.5717E+10 bytes
Fixed Size                  5027392 bytes
Variable Size            1979711488 bytes
Database Buffers         1.2650E+10 bytes
Redo Buffers                8855552 bytes
Vector Memory Area       1073741824 bytes
Database mounted.
Database opened.

SQL> SHOW PARAMETER vector_memory_size;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
vector_memory_size                   big integer 1G
SQL> connect sh/sh@pdb1
Connected

SQL> CREATE VECTOR INDEX IDX_CHUNKS_EMBEDDING_HNSW
ON documentos_pdf (EMBEDDING)
ORGANIZATION INMEMORY NEIGHBOR GRAPH
DISTANCE COSINE
WITH TARGET ACCURACY 95
PARAMETERS (
  TYPE HNSW,
  NEIGHBORS 32,
  EFCONSTRUCTION 500
);

Index created.

Para que sirve este índice.?
índice vectorial HNSW sobre la columna EMBEDDING de la tabla DOCUMENTOS_PDF 
para acelerar búsquedas de similitud semántica en Oracle AI Database 26ai.
Veámosla línea por línea:
CREATE VECTOR INDEX IDX_CHUNKS_EMBEDDING_HNSW
ON documentos_pdf (EMBEDDING)
Crea un índice llamado IDX_CHUNKS_EMBEDDING_HNSW.

El índice se construye sobre la columna EMBEDDING.

Dicha columna contiene vectores generados por un modelo de embeddings 
(texto, imágenes, audio, etc.).

Ejemplo:
[0.125, -0.234, 0.567, ...]
Cada vector representa el significado semántico de un chunk de documento.
ORGANIZATION INMEMORY NEIGHBOR GRAPH
Indica que Oracle utilizará una estructura de datos optimizada para búsquedas 
ANN (Approximate Nearest Neighbor).
En lugar de comparar el vector de búsqueda contra todos los registros de la tabla:
Vector Consulta
      |
      v
Comparar contra 10 millones de vectores

Oracle construye un grafo donde cada vector conoce a sus vecinos más cercanos:
      A
    / | \
   B  C  D
   |\/ \|
   E----F
La búsqueda "navega" por el grafo hasta encontrar los vectores más similares.
Beneficio:
Mucho más rápido.

Menor uso de CPU.

Escalable a millones de embeddings.

DISTANCE COSINE
Define la métrica de similitud.
Oracle calculará: Cosine Similarity entre el vector buscado y los vectores almacenados.
Matemáticamente:
A · B
-------
|A||B|
Valores:
Resultado
Interpretación
1
Idénticos
0.9
Muy similares
0.5
Relación moderada
0
Sin relación
Para RAG y documentos generalmente es la opción más utilizada.
Ejemplo:
Consulta:"¿Qué es Oracle RAC?"
Aunque el documento diga:"Real Application Clusters permite..."
los embeddings tendrán direcciones parecidas y la distancia coseno será pequeña.
WITH TARGET ACCURACY 95
Oracle intentará devolver aproximadamente el 95% de los vecinos que encontraría 
una búsqueda exacta.
Existe un compromiso entre:
Exactitud
Velocidad
100%
Más lenta
95%
Muy rápida
90%
Más rápida
80%
Extremadamente rápida
En RAG normalmente:
90 - 95 %
es un excelente equilibrio.
PARAMETERS
TYPE HNSW
Utiliza el algoritmo:Hierarchical Navigable Small World
Actualmente es uno de los algoritmos ANN más utilizados en sistemas vectoriales modernos.
También es usado en motores como:
FAISS

Milvus

Qdrant

OpenSearch

NEIGHBORS 32
También conocido como parámetro M en HNSW.
Indica cuántas conexiones tendrá cada nodo del grafo.
Visualmente:
Vector A
   |
   +----32 vecinos
Mayor valor: NEIGHBORS 64
Más memoria.

Índice más grande.

Mejor calidad de búsqueda.

Menor valor:NEIGHBORS 16
Menor tamaño.

Menor precisión.

Valor 32 suele ser una configuración equilibrada.
EFCONSTRUCTION 500
EFCONSTRUCTION 500
Controla la calidad durante la construcción del índice.
Cuando Oracle inserta cada vector:
Nuevo Vector
      |
      v
Busca 500 candidatos
      |
      v
Escoge los mejores vecinos
Valores típicos:
Valor
Calidad
100
Básica
200
Buena
500
Muy buena
1000
Excelente
Con:EFCONSTRUCTION 500
Oracle dedica más trabajo al construir el índice para obtener mejores 
resultados posteriormente.
Impacto:
Creación más lenta.

Índice de mayor calidad.

Búsquedas más precisas.

OLLDA, Oracle Listener Log Discovery and Analyzer por José Valdézio, Oracle ACE Pro.

 

Hola gente

@Jvaldeziodba ha creado una gran herramienta para hacer análisis de los logs generados por el servicio LISTENER de la base de datos.

Cuando pensamos en temas de seguridad, monitoreo, reporteria, regulatorios, etc, siempre nos da un dolor de cabeza enorme, cuando nos piden brindar un informe sobre las conexiones efectuadas a la base de datos, las IP de origen, los programas utilizados, conexiones existosas y fallidas.

OLLDA viene a simplificar todo este análisis de una manera magistral.

He solicitado el visto bueno de su creador José Valdézio, Brasileño; quién es miembro del Programa Oracle ACE, para mostrarles como se configura e instala la herrramienta en un entorno In-House, sin exponer información fuera de organización y para no incumplir normas regulatorias. En esta presentación les voy a ayudar a como interpretar y navegar por las múltiples opciones que pone a disposición la herramienta.

A estar atentos al link de la sesión.

Pueden conocer más sobre este proyecto en: https://lnkd.in/eP4hTpcp o directamente en su blog: https://lnkd.in/eu98juMf

Perfil linkedin: https://lnkd.in/evsfsjGj