Solution 1 :
-
Qui installe Oracle sur les serveurs ?
Si c'est le DBA, ils ont besoin d'un accès root. Si c'est sysadmin, le DBA ne le fait pas. -
Qui est appelé tard dans la nuit lorsque le serveur de base de données est en panne ?
Si vous ne pouvez pas vous assurer que les administrateurs système sont disponibles 24h/24 et 7j/7, vous pouvez accorder un accès root au DBA.
Gardez à l'esprit que si votre DBA a déjà un accès shell en tant qu'utilisateur régulier (avec ou sans certaines commandes qu'il peut exécuter via sudo ; avec ou sans chroot), cela suffit pour déranger le serveur (un méchant qui vole son compte peut fork bomb , dépassez ulimit en envoyant du spam, supprimez la base de données, ...).
Pour toutes ces raisons, je pense que dans un monde idéal, les DBA ne devraient pas avoir un accès root; mais dans le monde réel, ils devraient au moins toujours pouvoir l'obtenir en cas d'urgence.
Solution 2 :
En général, et non spécifique aux DBA, toute personne qui demande root l'accès sans donner de raison valable est soit :
- Quelqu'un qui ne sait pas ce qu'il fait.
- Arrogant et peu coopératif.
- Les deux ci-dessus.
Maintenant, il pourrait y avoir de vraies raisons pour lesquelles ils ont besoin de root accès pour gérer leur tâche, mais encore une fois s'ils ne peuvent pas expliquer pourquoi et le mettre par écrit, je ne traiterais pas avec eux. Les professionnels qui traitent avec les serveurs comprennent et respectent les limites. Les meilleurs joueurs qui en savent assez pour avoir des ennuis croient que les règles s'appliquent à tout le monde sauf à eux.
Dans les cas où j'ai dû me battre avec des gens comme celui-ci, j'ai insisté pour que l'heure soit programmée à l'avance afin que je puisse être sur le serveur avec eux pour gérer les problèmes au fur et à mesure qu'ils surviennent. Et cela a bien fonctionné.
Une autre alternative, qui pourrait ne pas être pratique, consiste à créer un clone exact du serveur en question et à leur donner root accès là-dessus. Assurez-vous de changer le mot de passe en quelque chose de spécifique pour eux bien sûr. Laissez-les faire exploser une boîte de développement isolée.
Mais en général, si vous êtes celui qui sera appelé tard dans la nuit pour nettoyer un gâchis que ce type pourrait créer, alors vous avez parfaitement le droit de dire non à une demande globale de root accès.
Solution 3 :
Théoriquement, les DBA peuvent fonctionner sans root privs, mais c'est PITA pour les deux côtés. Il est pratiquement impossible de définir une liste de commandes accessible via sudo .
Donnez les privilèges racine aux administrateurs de bases de données si :
- vous ne voulez pas être réveillé au milieu de la nuit, juste pour redémarrer le serveur
- vous voulez une gestion des incidents rapide et fluide
- si votre serveur est dédié uniquement au serveur DB
Les DBA ont généralement besoin de root privs pour :les ajustements des paramètres du noyau (sysctl), la manipulation du stockage, la recherche de problèmes.
Une audition appropriée garantit de meilleures conditions d'exécution que des règles de sécurité strictement définies. Si vous avez mis en place un audit, vous pouvez toujours demander pourquoi ils ont fait/modifié quelque chose. Si vous n'avez pas d'audit, vous n'avez pas de sécurité de toute façon.
EDITÉ
Voici une liste des exigences Oracle courantes sur les installations autonomes (installations non groupées)
-
Paramètres du noyau
- Lié à la mémoire (configuration de pages volumineuses/énormes, RAM partagée (ipcs), RAM non échangeable (verrouillée))
- liés aux réseaux (taille de la fenêtre d'envoi/de réception, TCP keepalive)
- lié au stockage (nombre de fichiers ouverts, E/S asynchrones)
Il peut y avoir environ 15 à 20 paramètres sysctl. Pour chacun d'eux, Oracle fournit une valeur recommandée ou une équation. Pour certains paramètres, l'équation recommandée peut changer au fil du temps (aync io) ou, dans certains cas, Oracle a fourni plusieurs équations pour le même paramètre.
- Stockage :les règles Linux udev ne garantissent pas le démarrage des noms de périphériques persistants. Par conséquent, Oracle a fourni le pilote et les outils du noyau (AsmLib). Cela vous permet de "nommer" les partitions physiques en tant que racine et vous pouvez ensuite voir ces étiquettes lors de l'administration du stockage de la base de données
- Enquête sur le problème :
- Lorsque la base de données plante parce qu'elle ne peut pas ouvrir plus de descripteurs de fichiers, la seule solution est d'augmenter la limite du noyau, d'exécuter 'sysctl -p' puis de démarrer la base de données.
- De plus, lorsque vous constatez que la RAM physique est trop fragmentée et que la base de données ne peut pas allouer de grandes pages, la seule option consiste à redémarrer le serveur.
- (DCD) - détection de connexion morte. Par exemple sur AIX netstat n'imprime pas le PID. La seule façon de coupler une connexion TCP avec PID est le débogueur du noyau.
- glance (quelque chose comme top sur HP-UX) nécessite des privilèges root
- diverses enquêtes de niveau Veritas
- et bien d'autres
C'est à vous de décider combien de temps vous "perdrez" jusqu'à ce que le problème soit résolu. Je voulais juste souligner que la forte séparation des rôles peut être très coûteuse dans certains cas. Ainsi, au lieu d'augmenter la "sécurité", concentrez-vous sur la réduction des risques et des dangers. Ce qui n'est pas pareil. Des outils comme ttysnoop ou shell spy vous permettent "d'enregistrer" l'intégralité de la session ssh, ils garantissent donc l'indéniabilité. Cela peut servir mieux que sudo.