Pourquoi l'authentification du système d'exploitation est-elle considérée comme une sécurité médiocre pour les bases de données Oracle?

Oracle déconseille l'authentification du système d'exploitation selon le manuel Oracle Database Security Guide , qui dit

N'oubliez pas que le paramètre REMOTE_OS_AUTHENT a été déconseillé dans Oracle Database 11g version 1 (11.1) et n'est conservé que pour des raisons de compatibilité descendante.

De plus, la plupart des informations et des outils de sécurité considèrent l' authentification du système d'exploitation (externe) comme un problème de sécurité. J'essaie de comprendre pourquoi c'est le cas. Voici quelques avantages que je vois de l'authentification du système d'exploitation:

1. Sans authentification du système d'exploitation, les applications doivent stocker les mots de passe dans diverses applications, chacune avec son propre modèle de sécurité et ses propres vulnérabilités.
2. L'authentification de domaine doit déjà être sécurisée car si ce n'est pas le cas, la sécurité de la base de données ralentit simplement l'accès à la base de données, mais ne peut pas l'empêcher.
3. Les utilisateurs qui ne doivent se souvenir que d'un seul mot de passe de domaine peuvent être amenés à créer des mots de passe de domaine plus sécurisés plus facilement qu'ils ne peuvent l'être pour créer des mots de passe de base de données encore moins sécurisés, car le nombre de bases de données auxquelles ils doivent se connecter augmente.

Considérez le scénario suivant:

1. Il y a un utilisateur Unix nommé gaiussur le serveur Oracle avec une authentification externe, donc dans Oracle il y a un utilisateur correspondant appelé ops$gaius. Lorsque je suis connecté à un shell, je peux également me connecter directement à mon schéma Oracle et mes tâches cron n'ont pas non plus besoin d'un mot de passe intégré dans le script.
2. L'authentification du système d'exploitation à distance est autorisée, en supposant que le réseau local est 100% sécurisé et que les clients peuvent être approuvés (identiques rlogin/ rshnormalement autorisés)
3. Un attaquant obtient son ordinateur portable sur le LAN par quelque moyen que ce soit, sait que j'y travaille et crée un utilisateur local sur son ordinateur portable appelé gaiuset exécute SQL * Plus en tant qu'utilisateur
4. Oracle voit (c'est- OSUSERà- dire dans V$SESSION) est gaiuset enregistre cet utilisateur distant commeops$gaius

C'est non seulement ridiculement facile à usurper, mais en mettant mon chapeau de cynique, Oracle ne peut pas gagner plus d'argent en vous vendant leur produit de connexion unique sophistiqué ... Ce qui, en passant, répond à tous les points que vous soulevez en tant qu'avantages du système d'exploitation -auth niveau. Deux mots de passe meilleurs qu'un sont totalement faux; la plupart des gens les définiront de la même façon (il n'y a pas de mécanisme dans Oracle pour empêcher cela).

Le principe général est qu'il est extrêmement difficile de se défendre dans un logiciel lorsqu'un attaquant a un accès physique. Et ne faites jamais confiance au client.

Il augmente les points de défaillance uniques et agrandit la surface de risque de vos données.

Un attaquant qui accède au système aura, avec l'authentification OS, accès à la base de données. En exigeant un accès plus sécurisé à la base de données, l'attaquant potentiel doit augmenter ses privilèges sur le système compromis pour obtenir un accès root ou oracle, plutôt que n'importe quel utilisateur.

Ce problème est fonction de l'accès externe à la base de données. S'il n'y a pas d'accès externe et que la machine est entièrement sécurisée, la question des autorisations est sans objet. Cependant, si les développeurs y ont accès, les autorisations utilisateur au niveau du système d'exploitation augmentent la portée des catastrophes de sécurité potentielles.

Envisagez d'utiliser un accès à plusieurs niveaux pour limiter l'étendue des failles de sécurité et donner à tout utilisateur, application ou client l'accès dont ils ont besoin sans avoir à créer de comptes au niveau du système d'exploitation pour chaque instance.

Gaius a déjà souligné pourquoi l' authentification du système d'exploitation à distance (par opposition à l'authentification du système d'exploitation vanilla où vous autorisez les utilisateurs de machines locales à accéder à la base de données sans spécifier un mot de passe séparé) est relativement peu sécurisée.

Je m'attends à ce qu'Oracle évolue dans cette direction car il souhaite encourager les utilisateurs à utiliser les utilisateurs d' entreprise (ou la suite de gestion des identités à part entière) plutôt que les utilisateurs authentifiés par le système d'exploitation distant. Les utilisateurs d'entreprise ont les mêmes avantages que les utilisateurs authentifiés du système d'exploitation distant, mais Oracle sort en fait et frappe votre serveur Active Directory pour authentifier l'utilisateur. Vous bénéficiez des mêmes avantages d'authentification unique sans laisser le contrôle de sécurité à la machine cliente.

Vous pointez spécifiquement vers l'authentification de style ident, mais je voudrais également souligner que d'autres méthodes de liaison de la base de données ou de toute autre connexion aux connexions du système d'exploitation sont tout aussi mauvaises. (que ce soit des fichiers de mots de passe locaux, LDAP ou autre pour le stockage réel des informations d'identification)

Si vous autorisez les connexions à distance à la base de données (ou au serveur Web ou à tout ce qui fait l'authentification), certains systèmes d'exploitation ignoreront les règles qui pourraient être définies pour rendre difficile la force brute des comptes (par exemple, bloquer les adresses IP d'où proviennent les tentatives infructueuses; verrouillage utilisateurs pendant une période après un nombre défini de défaillances, etc.). Normalement, ces règles sont liées sshdet non le système d'authentification dans son ensemble.

Donc, si quelqu'un peut se connecter à distance à la base de données / au serveur Web / quoi que ce soit, il peut forcer le mot de passe, car les bases de données n'ont pas tendance à avoir les mêmes mécanismes pour ralentir les tentatives, puis ssh une fois qu'il a trouvé les informations d'identification nécessaires.