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?


29

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.

Où avez-vous vu qu'Oracle dépréciait l'authentification externe?
Justin Cave

1
@Justin Cave Je mettrai à jour la question avec ces informations.
Leigh Riffel

2
Merci pour la mise à jour. Pour plus de clarté, cependant, Oracle ne déprécie pas l'authentification externe, il déconseille l' authentification externe distante qui est généralement beaucoup moins sécurisée (comme Gaius le décrit ci-dessous)
Justin Cave

Réponses:


16

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.


2
C'est encore pire que ça. Voir «Pourquoi les comptes OPS $ constituent-ils un risque pour la sécurité dans un environnement client / serveur?» (ils blâment les fenêtres, mais vous avez raison, c'est n'importe quoi sur le réseau)
Joe

3
Comment le serveur sur un domaine Windows prend-il en compte cela? Par exemple, l'attaquant devrait-il joindre son ordinateur au domaine afin d'avoir un compte qui inclut le domaine, ou l'attaquant pourrait-il simuler la présence du domaine sans avoir à rejoindre son ordinateur?
Leigh Riffel

Je suppose que cela a été écrit à l'origine à une époque où tous les serveurs étaient Unix et tous les bureaux étaient Windows
Gaius

3
@Leigh - Vous pouvez rendre l'authentification à distance du système d'exploitation plus sécurisée avec les clients Windows en définissant OS_AUTHENT_PREFIX pour être un domaine Windows approuvé. Cela nécessite que le client distant se trouve (ou semble être) sur ce domaine approuvé. Cela soulève considérablement la barre sur un "branchement d'ordinateur" insignifiant dans un port de rechange, ajoutez un utilisateur local, et vous êtes en "attaque", mais c'est toujours assez battable.
Justin Cave

1
comparer et contraster avec s'il faisait une authentification AD / Kerberos réelle, et prendre un ticket de l'utilisateur et le vérifier avec le KDC, ce qui, je suppose, est ce que fait SqlServer lorsqu'il est configuré pour utiliser l'authentification Windows?
araqnid

8

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.


Je vois, donc pour simplifier à l'excès - deux exigences de nom d'utilisateur / mot de passe sont plus sécurisées qu'une -. Vos points semblent raisonnables.
Leigh Riffel

Il s'agit d'une réponse subtilement incorrecte - le problème n'est pas l'authentification externe mais l' authentification externe à distance . J'expliquerai ci-dessous.
Gaius

@Gaius L'authentification externe du système d'exploitation ne serait-elle pas extrêmement limitée presque au point d'être sans valeur si elle n'était pas distante? Voulez-vous dire qu'Oracle ne déprécie pas l'authentification à l'aide du système d'exploitation, mais désapprouve uniquement l'authentification du système d'exploitation à partir d'un ordinateur distant?
Leigh Riffel

@Leigh - Le cas d'utilisation principal pour l'authentification du système d'exploitation des comptes locaux est pour les tâches de type DBA où vous avez un tas de scripts shell en cours d'exécution sur le serveur de base de données qui doivent accéder à des comptes très puissants sur le serveur de base de données. L'authentification du système d'exploitation vous permet d'éviter d'avoir des mots de passe de niveau DBA non chiffrés dans ces scripts shell.
Justin Cave

@Justin batch jobs en général, implémentés en tant que scripts shell ou autre, dans des crons individuels
Gaius

4

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.


L'authentification LDAP peut ouvrir une autre boîte de vers ... Je vais publier une réponse plus longue.
Joe

+1 Merci d'avoir signalé Enterprise User Security. Nous avons déjà envisagé la sécurité avancée et cela la rend d'autant plus attrayante.
Leigh Riffel

4

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.


2
Je ne suis pas sûr de suivre le raisonnement ici. Si Oracle est authentifié par rapport à LDAP, vous devez interrompre LDAP pour obtenir le mot de passe - il n'y aurait pas de copie locale du hachage de mot de passe à force brute comme il le serait pour un utilisateur Oracle ordinaire. Si vous craignez que les attaquants ne battent votre authentification LDAP, vous avez probablement des problèmes plus importants que la façon dont vous authentifiez les utilisateurs Oracle. Et il est assez facile de configurer Oracle pour verrouiller les comptes après un certain nombre de tentatives infructueuses, restreindre les adresses IP autorisées, etc. En grande partie, c'est le comportement par défaut dans 11g.
Justin Cave

@Justin: ce n'est qu'un problème si vous le liez donc les informations d'identification pour la connexion au système d'exploitation sont les mêmes que les informations d'identification pour la connexion à la base de données (ou serveur Web, etc.). Et il semble que Oracle se soit amélioré sur l'authentification que lors de ma dernière utilisation, mais la plupart des autres bases de données ne l'ont pas été. (et Apache non plus, donc les utilisateurs des serveurs MacOS X devraient échanger mod_auth_appleet mod_auth_digest_applepour les versions par défaut, bien que je n'ai pas testé si le problème persiste en 10.6)
Joe
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.