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

Question

Oracle déconseille l'authentification du système d'exploitation selon le 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 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:

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.
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.
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.

Gaius · Accepted Answer

Considérez le scénario suivant:

Il y a un utilisateur Unix nommé gaius sur 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.
L'authentification du système d'exploitation à distance est autorisée, en supposant que le LAN est 100% sécurisé et que les clients peuvent être approuvés (comme rlogin/rsh étaient normalement autorisés)
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é gaius et exécute SQL * Plus en tant qu'utilisateur
Oracle voit (c'est-à-dire OSUSER dans V$SESSION) est gaius et enregistre cet utilisateur distant en tant que ops$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 signature unique ... Ce qui, soit dit en passant remplit tous les points que vous soulevez comme avantages de l'authentification au niveau du système d'exploitation. 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.

Brian Ballsun-Stanton · Answer

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.

Pensez à utiliser 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 des comptes de niveau OS pour chaque instance.

Justin Cave · Answer

Gaius a déjà expliqué 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 de mot de passe séparé) est relativement peu sûr.

Je m'attends à ce qu'Oracle évolue dans cette direction car il veut encourager les gens à utiliser tilisateurs d'entreprise (ou la suite de gestion des identités à part entière) plutôt que des 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.

Joe · Answer

Vous pointez spécifiquement vers l'authentification de style ident, mais je voudrais également souligner que les 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 à sshd et pas au 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.