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 :)