Sécurité de base d'Oracle Database

La sécurité est la principale préoccupation partout si vous êtes sur le Cloud ou sur la base de données Prim. Les fournisseurs de cloud fournissent de nombreuses fonctionnalités de sécurité au niveau de l'infrastructure et certains ont également la sécurité en tant que service.

Notre objectif principal dans cet article est de maintenir la sécurité de vos bases de données on-prim.

1. Nous devons verrouiller et expirer les utilisateurs SYS et SYSTEM pour toutes les bases de données.

Vous n’avez pas besoin d’utilisateurs SYS et SYSTEM au quotidien. Alors pourquoi les garder ouverts. Si vous avez vraiment besoin d'un compte sysdba, créez-en un. Vous pouvez essayer un utilisateur qui peut faire des choses comme déverrouiller des sessions, attribuer le privilège dba_ *, etc.

           

Remarque: - Vous devez verrouiller et expirer chaque utilisateur de la base de données qui n'est pas en cours d'utilisation.

2. Assurez-vous que le paramètre SQL92_SECURITY est défini sur true

      Assurez-vous que le paramètre SQL92_SECURITY est défini sur true, ce qui est déjà recommandé par oracle. Il était par défaut FALSE dans 10g et à cause de cela la plupart du temps reporté à 11g ou 12c. Oracle a changé ce paramètre en TRUE par défaut dans 12.2 selon mon étude.

       qu'est-ce que SQL92_SECURITY?

      Les normes SQL92 spécifient que les administrateurs de sécurité doivent être en mesure d'exiger que les utilisateurs disposent du privilège SELECT sur une table lors de l'exécution d'une instruction UPDATE ou DELETE qui référence les valeurs de colonne de table dans une clause WHERE ou SET. SQL92_SECURITY spécifie si les utilisateurs doivent avoir reçu le privilège d'objet SELECT pour exécuter de telles instructions UPDATE ou DELETE.Source (docs.oracle.com)

     

       Pour changer: - modifier l'ensemble du système sql92_security = TRUE scope = spfile;

3. Remplacez audit_sys_operations par true

      Remplacez audit_sys_operations par true, qui par défaut vaut FALSE jusqu'à 11g. En 12c, c'est TRUE par défaut. La modification de ce paramètre nécessite le rebond de la base de données, alors planifiez en conséquence si vous souhaitez modifier.

       

       qu'est-ce que audit_sys_operations?

      AUDIT_SYS_OPERATIONS active ou désactive l'audit des opérations émises par l'utilisateur SYS et les utilisateurs se connectant avec les privilèges SYSDBA ou SYSOPER. Les enregistrements d'audit sont écrits dans la piste d'audit du système d'exploitation. Les enregistrements d'audit seront écrits au format XML si le paramètre d'initialisation AUDIT_TRAIL est défini sur XML.Source (docs.oracle.com)

      

         Pour changer: - modifier l'ensemble du système audit_sys_operations = true scope = spfile;

4. Réglez certains paramètres sur FALSE ou NONE

      Assurez-vous que "DBA_USERS.PASSWORD" n'est pas défini sur "EXTERNAL" pour aucun utilisateur

Assurez-vous que «REMOTE_OS_ROLES» est défini sur «FALSE».

Assurez-vous que "REMOTE_OS_AUTHENT" est défini sur "FALSE".

Assurez-vous que «REMOTE_LOGIN_PASSWORDFILE» est défini sur «NONE».

Assurez-vous que «REMOTE_LISTENER» est vide.

Assurez-vous que "GLOBAL_NAMES" est défini sur "TRUE".

Les connexions privilégiées à distance à la base de données doivent être restreintes, ce qui signifie que l'utilisateur expérimenté (par exemple, sys) ne peut pas se connecter à la base de données à distance, au lieu de le faire uniquement sur le serveur de base de données. Je crois que le réglage REMOTE_LOGIN_PASSWORDFILE = NONE est suffisant. Donnez votre avis.

Pour changer: - modifier l'ensemble du système remote_login_passwordfile = none scope = spfile;

5. Modifier les mauvaises tentatives de mot de passe

      Modifiez la valeur de votre profil pour les tentatives de mot de passe erronées à 3minimum, qui est FAILED_LOGIN_ATTEMPTS par défaut, c'est 10. Si quelqu'un ne connaît pas le mot de passe après trois tentatives, il est fort probable qu'il ne le sache pas vraiment. Si quelqu'un essaie de casser le mot de passe, cela peut verrouiller l'utilisateur.

      Pour modifier: - modifier la super limite de profil failed_login_attempts 3;

6. Remplacez sec_case_sensitive_logon par true

     Jusqu'à 11g sec_case_sensitive_logon a été défini sur FALSE et ce paramètre est obsolète dans 12c. Assurez-vous donc que vous utilisez aussi VRAI dans les bases de données 11g ou 10g. Vous devrez peut-être travailler avec l'équipe d'application à ce sujet.

      qu'est-ce que sec_case_sensitive_logon?

      SEC_CASE_SENSITIVE_LOGON active ou désactive le respect de la casse des mots de passe dans la base de données. Source (docs.oracle.com)

        Pour changer: - modifier le jeu système sec_case_sensitive_logon = false;

Voici quelques éléments de sécurité de base que vous pouvez implémenter dans la base de données ON-PRIM. Nous mettrons également à jour pour la sécurité du cloud.

N'hésitez pas à ajouter plus de points dans les commentaires. Nous publierons sur notre blog avec votre adresse Gmail. Continuez à partager :)

Oracle Mean company, not database :)

Standard Edition High Availability in 19c for SE2

 In the last few years, we saw many changes done by oracle and it feels like Oracle just wants you to move on cloud or Enterprise edition. We love the SE version because it was serving us well and was not very expensive(almost one-third cost). So now Oracle decided to get it off and introduces SE2. In Oracle 19c  there is no RAC for SE2 but there is one feature called SEHA(standard edition high availability). So let's dig into it. 

What SEHA(Standard Edition High Availability) in 19c SE2?

Starting with 19c (19.7), you can use  Oracle SE2 DB in HA mode.SEHA gives you a cluster-based failover solution for a single instance using Oracle Clusterware. Oracle SEHA gives you cluster capabilities with storage solutions that are already part of Oracle Grid Infrastructure. That means you can have Oracle Clusterware, Oracle ASM, and Oracle ACFS.

Oracle ASM and Oracle ACFS enable Oracle Grid Infrastructure to restart another instance on failover node much faster. Oracle SE2 HA is a Cluster-based active/passive Oracle Database failover solution and only designed to serve a single node only. But you need to study more about the "oracle 10 days rule" to implement SEHA.

Operating system supported for SEHA:- 

• Linux x86-64 
• Oracle Solaris on SPARC (64-bit)
• Microsoft Windows

Oracle 19c SEHA workflow:- 

• Your instance got crashed
• The grid will identify the crash
• The grid will mount the database to another node 
• The grid will start the instance on another node
• The grid will trigger a recovery
• Your instance will be available

Thanks for reading. 

Oracle Mean company, not database :)

How many sessions can oracle database handle?

Sessions can 10g/11g/12c database handle

You can control sessions by your database's SESSIONS initialization parameter from the parameter file. But you also need to take care of the PROCESSES initialization parameter as sessions are proc *1.1+5. it's impossible to exceed this number of sessions unless you raise the parameter value.

SELECT name, value FROM v$parameter WHERE name = 'sessions';

This will show you the total number of sessions:-

SELECT COUNT(*) FROM v$session;


So answer to the question is Oracle can handle thousands of connections, but you need to take care of database resources.


Always use the below formula to set sessions and parameter:-

processes=x
sessions=x*1.1+5
transactions=sessions*1.1

Below SQL helps to check current utilization and max utilization. 

select resource_name, current_utilization, max_utilization, limit_value  from v$resource_limit
    where resource_name in ('sessions', 'processes');

As you see highlighted, We have changed the number of sessions according to our need. 

Oracle Mean company, not database :)