Mon DBA Oracle a-t-il besoin d'un accès root?

Mon collègue Oracle DBA demande un accès root sur nos serveurs de production .
Il fait valoir qu'il en a besoin pour effectuer certaines opérations comme le redémarrage du serveur et d'autres tâches.

Je ne suis pas d'accord avec lui car je lui ai défini un utilisateur / groupe Oracle et un groupe dba auquel appartient l'utilisateur Oracle. Tout se passe bien et sans que le DBA ait un accès root actuellement.
Je pense également que toutes les tâches administratives telles que le redémarrage planifié du serveur doivent être effectuées par le bon administrateur (l'administrateur système dans notre cas) pour éviter tout type de problème lié à une mauvaise compréhension des interactions de l'infrastructure.

Je souhaiterais obtenir des commentaires des administrateurs système et des administrateurs de base de données Oracle. Existe-t-il une bonne raison pour qu'un administrateur de base de données Oracle ait un accès root dans un environnement de production ?

Si mon collègue a vraiment besoin de ce niveau d'accès, je le fournirai, mais j'en ai bien peur en raison de problèmes de sécurité et d'intégrité du système.

Je ne cherche pas des avantages / inconvénients, mais plutôt des conseils sur la façon dont je dois prendre pour faire face à cette situation.

• 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 donner un accès root au DBA.

Gardez à l'esprit que si votre DBA a déjà un accès shell en tant qu'utilisateur normal (avec ou sans certaines commandes, il peut s'exécuter via sudo; avec ou sans être chrooté), cela suffit à jouer avec le serveur (un méchant volant son compte peut fourrer une bombe , dépasser ulimit l'envoi de spam, supprimer 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.

En général - et non spécifique aux administrateurs de base de données - toute personne qui demande l' rootaccès sans donner de raison valable est soit:

1. Quelqu'un qui ne sait pas ce qu'il fait.
2. Arrogant et peu coopératif.
3. Les deux ci-dessus.

Maintenant, il pourrait y avoir de vraies raisons pour lesquelles ils ont besoin d'un rootaccè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 les traiterais pas. Les professionnels qui traitent avec des serveurs comprennent et respectent les limites. Des coups de feu 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 le temps soit planifié à l'avance afin que je puisse être sur le serveur avec eux pour gérer les problèmes à mesure qu'ils surviennent. Et cela a bien fonctionné.

Une autre alternative - qui pourrait ne pas être pratique - est de créer un clone exact du serveur en question et de leur donner rootaccès à cela. Assurez-vous de changer le mot de passe en quelque chose de spécifique à eux bien sûr. Laissez-les 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 le droit de refuser une demande d' rootaccès générale.

Théoriquement, les DBA peuvent fonctionner sans privilèges root, mais il s'agit de PITA pour les deux côtés. Il est pratiquement impossible de définir la liste des commandes accessibles via sudo.

Donnez des privilèges root aux administrateurs de base de données si:

• vous ne voulez pas être réveillé au milieu de la nuit, juste pour redémarrer le serveur
• vous souhaitez une gestion rapide et fluide des incidents
• si votre serveur est dédié au serveur DB uniquement

Les administrateurs de base de données ont généralement besoin de privilèges root pour: les ajustements des paramètres du noyau (sysctl), la manipulation du stockage, la recherche des 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 œuvre l'audit, vous pouvez toujours demander pourquoi ils ont fait / changé quelque chose. Si vous n'avez pas d'audit, vous n'avez de toute façon pas de sécurité.

ÉDITÉ

Voici une liste des exigences Oracle courantes sur les unités autonomes (installations non en cluster)

• Paramètres du noyau

  • Concernant la mémoire (configuration de pages volumineuses / volumineuses, RAM partagée (ipcs), RAM non échangeable (verrouillée))
  • liés aux réseaux (taille de la fenêtre d'envoi / réception, TCP keepalive)
  • liés au stockage (nombre de fichiers ouverts, async IO)

  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 les noms de périphériques persistants au démarrage. Par conséquent, Oracle a fourni le pilote du noyau et les outils (AsmLib). Cela vous permet de "marquer" les partitions physiques en tant que root et vous pouvez ensuite voir ces étiquettes lors de l'administration du stockage de base de données
• Enquête sur le problème:
  • Lorsque la base de données se bloque parce qu'elle ne peut pas ouvrir plus de descripteurs de fichiers, la seule solution consiste à augmenter la limite du noyau, à exécuter 'sysctl -p' puis à démarrer la base de données.
  • De plus, lorsque vous trouvez 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. Le seul moyen de coupler une connexion TCP avec PID est le débogueur de noyau.
  • glance (quelque chose comme top sur HP-UX) nécessite des privilèges root
  • diverses enquêtes au 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 séparation forte 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" toute la session ssh, ce qui garantit une indéniabilité. Cela peut servir mieux que sudo.

Je suis un DBA Oracle et ma réponse est, normalement DBA n'a pas besoin d'un accès root. Mais un RAC DBA? il a certainement besoin de l'accès root pour gérer CRS, le ménage et tout.

Cette question remonte à une époque où les systèmes étaient beaucoup plus simples et les processus OS par rapport à la base de données étaient définis et identifiables séparément. Les tâches et responsabilités de l'administration système et de l'administration de la base de données étaient très distinctes. Avec les environnements informatiques d'aujourd'hui et en particulier avec les serveurs de bases de données d'aujourd'hui, ces tâches et responsabilités, le plus souvent, ont tendance à se chevaucher. L'administrateur système fait preuve de diligence raisonnable pour restreindre l'accès «racine» à la «gestion des risques».

Avec les exigences actuelles de «haute disponibilité» et de «résolution immédiate» des problèmes rencontrés avec nos systèmes de base de données RAC, les administrateurs système et les administrateurs de base de données servent leurs communautés fonctionnelles, travaillant ensemble en équipe. La «confiance» ne devrait pas poser de problème, car les deux parties ont tout intérêt à maintenir les serveurs de base de données RAC en ligne près de 100% du temps. Gardez à l'esprit que le DBA dispose déjà d'un accès shell en tant qu'administrateur de base de données (avec ou sans certaines commandes qu'il peut exécuter via sudo; avec ou sans être chrooté), il est donc évident que le DBA est un agent «de confiance». Donc, en réalité, la question devrait être: "Pourquoi le DBA Oracle n'a-t-il pas besoin d'accéder?"

Le DBA d'aujourd'hui a assumé des responsabilités supplémentaires pour le serveur de base de données, où un serveur de base de données est membre d'un Oracle Real Application Cluster (RAC) et utilise Oracle Automatic Storage Management (ASMLIB) pour présenter le stockage partagé sur la ou les bases de données RAC. La gestion du RAC et de l'ASM par le DBA soulage l'administrateur système déjà surchargé, ce qui devrait être une contribution bienvenue au groupe / à l'équipe STS.

Et, comme le dit ibre5043, "... une séparation des rôles forte peut être très coûteuse dans certains cas. Donc, au lieu d'augmenter la" sécurité ", concentrez-vous sur la réduction des risques et des dangers. Ce qui n'est pas le même. Des outils comme ttysnoop ou shell spy vous permettent "enregistrer" toute la session ssh, ce qui leur confère une indéniblité. Cela peut mieux servir que sudo. " Vous devez également demander qui surveille les SSA.

Si les serveurs utilisent le logiciel Oracle Grid Infrastructure tel que CRS, RAC ou Oracle Restart, la plupart des services de base de données critiques s'exécutent en tant que root et de nombreux fichiers de configuration de base de données critiques appartiennent à root. Il s'agit d'une caractéristique de conception inhérente au logiciel. S'il s'agit d'une violation de vos politiques, les politiques doivent être révisées.

Le DBA aura besoin d'un accès root pour administrer ces fonctionnalités. Théoriquement, vous pouvez lui demander une liste des commandes qu'il s'attend à exécuter pour être entrées dans Sudo, mais la réponse sera une très longue liste. Jetez un œil dans $ GRID_HOME / bin pour une liste de tous les binaires que le DBA peut utiliser régulièrement. S'ils effectuent des activités de correction (ce qu'ils devraient être), la liste pourrait s'allonger encore plus.

Je viens de soumettre une question similaire. En fait, la raison pour laquelle un administrateur système ne veut pas accorder le privilège root est celle de la responsabilité et de la reddition de comptes, je pense.

Mais si c'est la cause, le DBA devrait également être le seul et unique administrateur système. Et la raison est simple. S'il y a un besoin de séparation de la responsabilité et de la responsabilité, l'administrateur système peut TOUJOURS être le DBA aussi. Il peut emprunter l'identité du compte Oracle, il peut entrer dans la base de données en tant que SYSDBA et faire n'importe quoi, sans avoir besoin du mot de passe SYS ou SYSTEM.

Donc, à mon avis, s'il y a un besoin de séparation des administrateurs système et des administrateurs de base de données, en raison de la responsabilisation et de la responsabilité, la seule raison logique est que le serveur doit également être géré par l'administrateur de base de données et non par l'administrateur système. Le serveur et la base de données devraient être dans leur ensemble la responsabilité du DBA, qui devrait également avoir des connaissances en administration système.

Si le serveur est utilisé pour plus que l'hébergement de la base de données, et qu'il existe un besoin de responsabilité et de responsabilisation distinctes, cela signifie des problèmes. Mais si le serveur est utilisé uniquement pour héberger la base de données, je ne vois aucune raison pour laquelle le DBA ne devrait pas avoir le privilège root, compte tenu de la myriade de cas dont il aurait également besoin.

Personnellement, je poserais la question dans l'autre sens. Pourquoi l'administrateur système a-t-il le privilège root sur un serveur de base de données dédié? En fait, sa spécialité serait requise dans beaucoup moins de cas que celle du DBA (avec le privilège root).

Un accès root est requis pour l'installation et l'application de correctifs à la grille Oracle. Il n'y a pas moyen de contourner cela. S'il y avait un moyen d'accorder un accès root temporaire à un DBA pour de tels besoins, ce serait l'idéal.