¿Se considera segura la separación de datos de diferentes aplicaciones a través de esquemas Oracle?

Es un concepto común crear específico Base de datos - Usuarios para cada aplicación . Estos usuarios deben tener los privilegios mínimos necesarios para hacer su trabajo.

Permite aplicar esto a tu ejemplo:

• ApplicationA utiliza DataBaseUserA , que tiene los privilegios de Leer / Insertar / Actualizar / Eliminar TablaA en SchemaA.
• ApplicationB usa DataBaseUserB que tiene los privilegios de leer TableB en SchemaB.
• Por supuesto, también tienes al menos una cuenta DBA.

Ahora considere que ApplicationB es vulnerable a la inyección de SQL:

• select * from SchemaA.TableA se inyecta y ejecuta con DataBaseUserB.
• La respuesta de la base de datos sería ORA-00942: la tabla o la vista no existen

En la mayoría de los casos de uso, consideraría que este comportamiento es lo suficientemente seguro. Por supuesto, una instancia de DataBase completamente diferente agregaría otra capa de seguridad en caso de algún problema crítico de seguridad desconocido en Oracle DB.

En el escenario que describiste, si el Esquema A se ve comprometido, salvo una vulnerabilidad desconocida con el propio Oracle , solo tendría acceso a los datos del Esquema B en la medida en que los privilegios de B había sido compartido con A.

En caso de que esto no esté claro, supongamos que tienes TABLE1 y TABLE2 en el Esquema B. Ahora asumamos que ejecutas el siguiente comando en el Esquema B:

GRANT SELECT, INSERT, UPDATE, DELETE ON SCHEMA_B.TABLE1 TO SCHEMA_A;

Luego, si el esquema A está comprometido, TABLE1 está en riesgo, pero TABLE2 debería estar seguro.

Y si en cambio ejecutas lo siguiente en el Esquema B:

GRANT SELECT ON SCHEMA_B.TABLE1 TO SCHEMA_A;

Luego, se reduce su riesgo (pero no se elimina): el malvado que penetró en el Esquema A podría ver los datos para TABLE1 (que aún podría ser muy malo, dependiendo de lo que haya) - pero no debería poder cambiar los datos .

Ahora volviendo al punto en el que escribí en cursiva: (" salvo alguna vulnerabilidad desconocida con el propio Oracle "): un lote de las vulnerabilidades que causaron un enorme dolor comenzó como Vulnerabilidades desconocidas con aplicaciones específicas. Si tiene el lujo de separar los servidores (teniendo en cuenta los gastos del servidor, el tiempo de mantenimiento y los gastos, las necesidades actuales y futuras para compartir datos directamente), entonces, cuanto más aislamiento pueda dar a sus datos, más seguro estará.