Mostrando entradas con la etiqueta Seguridad. Mostrar todas las entradas
Mostrando entradas con la etiqueta Seguridad. Mostrar todas las entradas

06 febrero 2019

Oracle 12C: Dos características interesantes en cuanto a seguridad

Hay muchas características nuevas en la base de datos de 12c que me gustan y que he discutido y hablado sobre ellas con varios colegas. Dos simples adiciones a la base de datos 12c hacen mi vida mucho más fácil en lo relativo a la seguridad de las bases de datos. El requisito era bloquear las cuentas de usuario que no hayan iniciado sesión en la base de datos durante 60 días consecutivos.

Last Login Time 

En las versiones anteriores a Oracle Database 12c (12.1) para averiguar cuándo un usuario inició sesión por última vez con éxito en la base de datos, debemos habilitar la auditoria de sesión, lo que conlleva cierta sobrecarga y el DBA debe configurar rutinas para limpiar la tabla de auditoria, etc. En 11g En la base de datos, tuve que habilitar la auditoría de sesión (mantener los registros de auditoria de la sesión durante al menos 61 días) y escribir un SQL que consultara a DBA_USERS y DBA_AUDIT_SESSION para enumerar a todos los usuarios activos que no usaron la base de datos durante 60 días.

En 12.1, Oracle registra automáticamente el tiempo de inicio de sesión exitoso en la tabla SYS.USER $ y está visible en DBA_USERS. La columna LAST_LOGIN de DBA_USERS muestra la última hora de inicio de sesión del usuario en la base de datos. En la base de datos 12.1, mi requisito se cumple al escribir un SQL simple contra DBA_USERS utilizando la columna LAST_LOGIN. No se requiere auditoria. El resultado se utiliza para crear SQL dinámico para bloquear cada cuenta mediante la instrucción ALTER USER ACCOUNT LOCK (similar a 11g).
Por cierto, notó que cuando inicie sesión en la base de datos utilizando SQL * Plus, también verá el último tiempo de inicio de sesión.

Bloqueo de cuenta inactiva

Mi requerimiento se automatizó completamente en la base de datos 12.2. Oracle introdujo el parámetro INACTIVE_ACCOUNT_TIME para los perfiles de usuario. El parámetro del perfil INACTIVE_ACCOUNT_TIME bloquea una cuenta de usuario que no ha iniciado sesión en la instancia de la base de datos en un número específico de días. El valor predeterminado para INACTIVE_ACCOUNT_TIME es 35. La configuración mínima es 15 y la máxima es 24855.

12 octubre 2018

Auditoría unificada en Oracle Database 12c


Una de las principales funciones de un DBA es implementar seguridad en la base de datos. Aunque si bien hay muchos aspectos relacionados a la aplicación de la misma, no siempre todos son utilizados en todos las empresas. Pero a pesar de esto, puede que un DBA no tenga que llegar a implementar una solución de autenticación basada en Kerberos pero siempre va a tener la responsabilidad de saber que está pasando en su base de datos. Es decir, quien se está conectado, que sentencias se están ejecutando, etc,.... La auditoria ha sido desde hace años la manera de satisfacer esta necesidad. No solamente es fácil de implementar y administrar, sino que además cubre todos los aspectos necesarios que un DBA tiene que cuidar cuando se trata de proteger su base de datos.

La política de auditoria unificada es como un grupo de opciones de auditoria con diferentes condiciones. Para habilitar la auditoria, primero debe crear una política con diferentes opciones de auditoria y luego debe habilitar o deshabilitar para todos o pocos usuarios, según los requisitos que tengamos. Todos los registros de auditoria se almacenarán en la tabla UNIFIED_AUDIT_TRAIL

Por defecto, hay 7 políticas de auditoria que estarán presentes en una base de datos Oracle 12c.

En versiones anteriores a 12c, el DBA tiene a su disposición 5 tipos diferentes de  auditoria. Estas son:

Auditoria obligatoria: Este tipo de auditoria está siempre habilitada y monitoriza las operaciones que involucren el inicio o apagado de la base de datos. Además de estas acciones, en cualquier momento que alguien utilice los roles predefinidos del sistema SYSDBA, SYSASM o SYSOPER esa acción será auditada.

Auditoria estándar: Este tipo de auditoria se habilita con el comando de AUDIT cuando es necesario auditar sentencias SQL, privilegios, objetos de esquema, y actividades de red o multicapa. Este tipo de auditoria se define y controla completamente a nivel de base de datos.



Auditoria basada en valores: La auditoria basada en valores fue introducida para poder capturar los valores reales que se cambian cada vez que algún tipo de sentencia DML es ejecutada en todas o determinadas filas de una tabla. Este tipo de auditoria aprovecha la funcionalidad de los triggers de base de datos (construcciones PL/SQL que responden a eventos) para lograr este objetivo.



Auditoria de grano fino: La auditoria de grano fino se centra en una auditoria de nivel  mas granular y las acciones auditadas se capturan basándose en el contenido accedido o modificado. Se puede simplemente crear políticas para disparar eventos de auditoria cuando alguien trata de realizar acciones que responden a las condiciones especificadas en la definición de la política.



Auditoria SYS: Este tipo de auditoria en realidad permite monitorizar las actividades de un administrador del sistema. Los usuarios que se conecten como SYS serán auditados y los registros de sus acciones serán escritos en un archivo de sistema operativo para evitar que sean borrados de la tabla AUD$ dentro de la base de datos. El parámetro de inicialización AUDIT_SYS_OPERATIONS se utiliza para activar y desactivar la auditoria de SYS.

Auditoria mixta: por defecto está habilitada en 12c. Permite utilizar tanto la auditoria tradicional como los métodos de auditoria unificada. Es decir. Además de la auditoria tradicional, podemos usar todas las características de la auditoria unificada. Una vez que nos sentimos cómodos con el concepto unificado, podemos migrar la configuración de auditoria existente a una política unificada, podemos habilitar la auditoria pura.
Esto sirve como un buen mediador para un cambio fácil y sin problemas a la auditoria Unificada preferida.

Auditoria pura: una vez que se habilita la auditoria pura. No podemos utilizar los métodos de auditoria tradicionales.


  • Valor: FALSE  -> AUDITORIA MIXTA
  • Valor: TRUE   -> AUDITORIA PURA


¿Qué modo de auditoria unificado está habilitado para mi base de datos?


¿Cómo cambiar de una auditoria mixta a pura?



Políticas por defecto en la base de datos Oracle 12c:



Pero no todos están habilitados. Consulta AUDIT_UNIFIED_ENABLED_POLICIES para buscar, qué políticas están habilitadas.



Consulta para comprobar las opciones de auditoria incluidas en una política:



Incluso si no se crea una nueva política en la base de datos, la acción de auditoria de las opciones de auditoria anteriores se registrará en UNIFIED_AUDIT_TRAIL.

Eliminamos la política de auditoria:



Purgamos la pista de auditoria:



21 febrero 2018

Oracle E-Business Suite: Consejos sobre seguridad cuando actualizas la base de datos

Al actualizar la base de datos de Oracle E-Business Suite a Oracle Database 12c (12.1), hay una serie de consideraciones y pasos de seguridad que deberían incluirse en el procedimiento de actualización:
  • Nota de soporte de Oracle ID 1524398.1 : Notas de interoperabilidad: Oracle E-Business Suite versión 12.0 o 12.1 con Oracle Database 12c versión 1 (12.1.0)


Aquí, documentaremos los pasos que se deben incluir o modificar para mejorar la seguridad de la base de datos. 

Consejo 1:

"Si bien no es obligatorio para la interoperabilidad de Oracle E-Business Suite con Oracle Database, los clientes pueden optar por aplicar Actualizaciones de conjunto de parches de base de datos (PSU) en su Oracle E-Business Suite Database ...".

Después de cualquier actualización de la base de datos, siempre se debe aplicar el último parche de CPU (ya sea PSU o SPU). La actualización de la base de datos solo tiene el último parche de CPU disponible en el momento del lanzamiento del parche de actualización de la base de datos. En el caso de 12.1.0.1, la actualización de la base de datos estará vigente a partir de julio de 2013 y faltarán los últimos cinco parches de CPU. Los parches de actualización de la base de datos restablecen el nivel de la CPU, por lo tanto, incluso si hubiera aplicado el parche de la CPU más reciente antes de la actualización, la actualización revertirá el nivel del parche de la CPU a julio de 2013.

Desde una perspectiva de seguridad, el último parche (PSU) debe considerarse obligatorio.

Consejo 2:

Es importante observar desde una perspectiva de seguridad que Database Vault, si está instalado, debe desactivarse durante el proceso de actualización. Todas las protecciones habilitadas en Database Vault destinadas a DBA se desactivarán durante la actualización.

Consejo 3:

El esquema DMSYS ya no se usa con Oracle E-Business Suite y se puede eliminar de forma segura. Recomendamos que elimine el esquema como parte de este paso para reducir la superficie de ataque de la base de datos y eliminar los componentes no utilizados. Use el siguiente SQL para eliminar el usuario DMSYS :

DROP USER DMSYS CASCADE;

Consejo 4:

Como parte de la actualización, es un buen momento para revisar que los parámetros de inicialización relacionados con la seguridad estén configurados correctamente. Verifique que los siguientes parámetros estén establecidos:

o7_dictionary_accessibility = FALSE
audit_trail = <set to a value other than none>
sec_case_sensitive_logon = TRUE (patch 12964564 may have to be applied)

Consejo 5:

Para Oracle E-Business Suite 12.1, sqlnet_ifile.ora debe contener el siguiente parámetro para que se corresponda con el parámetro de inicialización sec_case_sensitive_login = true -

SQLNET.ALLOWED_LOGON_VERSION_SERVER = 10

12 diciembre 2017

¿Hay vida más allá de Oracle? Open banking y PSD2

La Directiva de Servicios de Pago (PSD) adoptada en 2007 tenía por objeto crear un mercado único de pagos en la Unión Europea. Sin embargo, las limitaciones, como que cada país tenga diferentes regulaciones sobre el acceso de terceros a cuentas de clientes, llevaron a que los servicios se localizaran por país. Además, los bancos no estaban obligados a otorgar a proveedores externos acceso a las cuentas de sus clientes

A la luz de estas limitaciones, la Comisión revisó la Directiva revisada de servicios de pago (PSD2 - Directiva UE 2015/2366) en 2013. El objetivo de PSD2 es crear una mayor comodidad y elección para los clientes de la Unión Europea, integrar y mejorar el proceso de pago, crear igualdad de condiciones para los proveedores de servicios de pago, fomentar la innovación y la competencia.

 ¿Qué propone PSD2?

  • Derecho incondicional de devolución para los adeudos domiciliados en el marco del SEPA CORE.
  • Sistema de autenticación de clientes mucho más fuerte.
  • Prohibición de recargos por pagos con tarjeta.
  • Protección mejorada del cliente para pagos realizados fuera de la UE o en monedas no pertenecientes a la UE.
  • Introducción de proveedores de servicios de pago de terceros (TPP) al panorama financiero de la UE:
    • Proveedores de servicios de iniciación de pagos: (PISP) con acceso a la información de la cuenta del cliente del banco.
    • Proveedores de servicios de información de cuenta: (AISP) que puede iniciar un pago en nombre del cliente.
  • También habrá proveedores de servicios de pago de servicios a la cuenta: ASPSP que no son más que bancos que deben proporcionar acceso a la información del cliente a los TPP que utilizan APIs.

 

 ¿Cómo cambia el PSD2 el panorama financiero de la Unión Europea?


 Según una estrategia y estudio de PwC sobre PSD2 en 2016, el 88% de los consumidores utilizan proveedores externos para pagos en línea, lo que indica una gran base de clientes listos para otros servicios de banca digital como pagos, planificación financiera, etc. 2018 es cuando el PSD2 se supone que se pondrá en marcha y, según los expertos de la industria, terminará el monopolio de los bancos sobre la información de sus clientes. Bajo PSD2 los bancos estarán obligados a compartir su información de clientes con terceros a través de API abiertas. Estos terceros proveedores pueden construir sus servicios utilizando los datos del banco. Los bancos también tendrán que soportar mayores costos de proporcionar la infraestructura de seguridad alrededor de las API que expondrán. 

Esto dará como resultado un aumento dramático en la competencia en el sector financiero con los bancos que ya no compiten con otros bancos, sino también con entidades no bancarias o Fintechs que tendrán un acceso más fácil al mercado. De acuerdo con algunas proyecciones, se prevé que hasta el 9% de los ingresos de pagos minoristas se perderán para los servicios de PISP en 2020, justo dos años después de la puesta en marcha del PSD2.

¿Cómo pueden responder los bancos?

El sector bancario es uno de los mayores consumidores de tecnología. Sin embargo, la mayor parte de este gasto se realiza en actividades de mantenimiento (Transición Cobol --> Java de los noventa, Banca por internet en el inicio de siglo). Lo que ha impedido que los bancos tradicionales sean innovadores no es el costo de adquirir nueva tecnología, sino la indecisión de ceder el control y la inercia de la organización. Este puede ser un enfoque muy arriesgado a la luz de la presión del regulador para nivelar el campo de juego al permitir que nuevos jugadores ingresen al sector bancario y cambien las expectativas de los clientes. 

Los bancos pueden usar el PSD2 como otro requisito de cumplimiento (como PCI DSS o GDPR) o convertirlo en una oportunidad para desarrollar nuevos modelos de negocios al tiempo que brindan servicios que los clientes de la nueva era desean.

El Banco es la plataforma

Los bancos pueden abrir sus API que pueden ser utilizadas por desarrolladores externos para extender la funcionalidad de la plataforma a un nivel tecnológico, mientras que los proveedores externos pueden usar la plataforma para crear valor para los consumidores a nivel comercial. Los bancos actuales deberían liderar la industrialización de sus API y construir sus propios ecosistemas digitales y / o ser parte de un ecosistema externo. Este enfoque ayudará a los bancos a ser más ágiles y crear nuevas oportunidades en la creación y distribución de productos al tiempo que se abren nuevas fuentes de ingresos.
Hay dos enfoques para adoptar esta estrategia:
  • Crear una plataforma de banca digital basada en aplicaciones de aplicaciones de terceros, como:
      • Cuentas corrientes. 
      • Tarjetas de crédito / débito.
      • Préstamos personales instantáneos. 
    • El banco construirá un mercado de aplicaciones como una plataforma de comercio electrónico donde los demás jugadores;  Tanto FinTechs como otros bancos más pequeños pueden listar sus productos o servicios financieros. 
    • Los consumidores luego usarán el mercado bancario para consumir productos y servicios como lo hacen, por ejemplo, desde un Amazon
    • Los ingresos de un banco digital de este tipo no serán los honorarios que pagan los consumidores finales, sino los proveedores de aplicaciones que enumeran sus aplicaciones en la plataforma
    • Los bancos también pueden ampliar sus servicios al habilitar algunos de estos módulos de terceros para sus propias ofertas básicas y encontrar nuevas oportunidades de venta cruzada.
  • En segundo lugar, pueden formar parte de un mercado API de terceros como Open Bank Project (OBP) con sede en Berlín, donde tienen acceso a la comunidad de desarrolladores que pueden crear rápidamente nuevos productos y servicios para ellos. Estos mercados API de terceros también ofrecen aplicaciones etiquetadas en blanco y bancos de pruebas para bancos y otros proveedores de terceros para desarrollar soluciones que ofrezcan una mejor experiencia a sus clientes. Esto reducirá el costo y el tiempo de desarrollo para los bancos, ya que no tienen que invertir en la creación de productos y API desde cero, sino que usarán los servicios de los desarrolladores cuando sea necesario.

Ofrecer servicios PISP: los bancos pueden usar este enfoque para distribuir sus ofertas de banca transaccional y ofrecer soluciones de pago P2P basadas en API de bajo costo y mucho más rápidas. Un buen ejemplo son el banco danés Saxo Bank, o Capital One un banco con sede en el Reino Unido, que ahora permite a los afiliados beneficiarse a través de sus API, en España tenemos un ejemplo que conozco más BBVA:

El banco español BBVA es uno de los primeros en dar el salto al Open Bank. Viendo las API como fundamentales para su futuro, BBVA ha creado una Mercado API para desarrolladores externos.


Monetice los datos y las perspectivas de los clientes: los bancos tradicionalmente han recopilado y agregado información de los clientes que es tremendamente valiosa para los nuevos participantes. Los bancos pueden usar análisis avanzados para obtener información de datos transaccionales que ayudarán a los nuevos participantes a orientar mejor a sus clientes. Al utilizar API abiertas, los bancos pueden trabajar como proveedores de estos datos enriquecidos para terceros y así crear nuevas oportunidades de ingresos.

Los bancos también pueden actuar como proveedores de servicios de información de cuentas para sus clientes. Los nuevos participantes de AIS que pretenden proporcionar servicios similares estarían restringidos por la cantidad de clientes que se suscriban a sus servicios, mientras que los bancos ya tienen una gran base de datos de clientes existentes que ofrece una tremenda ventaja como primer usuario.

Pasos a tener en cuenta

Adopta un enfoque de diseño basado en el dominio.

El enfoque para identificar y empaquetar las API debe ser impulsado por el dominio. Para los bancos, esto significa volver al tablero de diseño y analizar todos los procesos comerciales relevantes. Este enfoque requiere que los bancos consideren los procesos desde la perspectiva del cliente (un esfuerzo a tener en cuenta) y los racionalicen para las experiencias digitales. También 
asegura una acumulación progresiva de un repositorio API sin perder 
vista de los controladores clave del programa.

Desde el punto de vista operativo, un enfoque de diseño impulsado por el dominio implica examinar cada uno de los procesos de negocios, internos y externos, y dividirlos en "bloques de LEGO" más pequeños de forma iterativa. Este enfoque es radicalmente diferente de un enfoque de abajo hacia arriba (Top-Down), que analiza las capacidades del panorama actual de la aplicación, lo que resulta en la limitación de las posibilidades de sostener futuras innovaciones.

El enfoque de diseño impulsado por el dominio se ha utilizado en el mundo del desarrollo de software desde hace tiempo y se puede aplicar a otras APIs .

Suscribirse a las API.

Construir cada API única no solo es innecesario sino también tiende a afectar el ritmo y la economía del propio programa. Al fin y al cabo, nadie construye APIs sociales, nos suscribimos a ellas a través de Facebook, Google o Twitter. Hay muchos repositorios de APIs, disponibles hoy para la suscripción desde FinTechs (BBVA España PayStats o BBVA España Payments) a empresas tecnológicas que se centran en cada dominio del negocio. El hecho de que estas organizaciones se enfocan en un solo problema comercial o dominio y muy a menudo trae experiencia global, ayuda a incorporar prácticas recomendadas a nivel mundial en un programa API.

Suscribiéndose a una APIs (y si es necesario ampliarlas, que es muy fácil) ayuda a acelerar no solo el programa API per se, sino también indirectamente empuja a las otras iniciativas de digitalización que están vinculadas.

Un banco puede pensar: "Vale, tenemos un gran producto, pero no podemos desarrollar todas sus vertientes. ¿Qué mejor que aliarse con quien está especializado en dar ese tipo de servicios, para ofrecer el mejor servicio posible a nuestros clientes?

Impulsar el negocio y supervisar la gestión.

Para que un programa API sea exitoso, necesita el compromiso y la cooperación de las partes interesadas comerciales relevantes. Las iniciativas API más exitosas cuentan con el apoyo del propio CEO, por complicada que sea este apoyo.

A largo plazo, la adopción de un enfoque táctico de las API, con el único propósito de ejecutar aceleradores y programas de incubación, puede no producir el mejor ROI.

Cualquier iniciativa API debe centrarse a largo plazo y basarse en modelos comerciales e ingresos innovadores. Esto debería contar con el respaldo adicional de un equipo de gobierno corporativo y un plan progresivo que se desglosa en objetivos a corto plazo.