Sécurité pour les développeurs d'applications effectuant des travaux PL / SQL dans Oracle


13

Comment gérez-vous le manque de privilèges au niveau du schéma dans Oracle? L'architecture de sécurité d'Oracle fonctionne bien pour les applications qui n'ont besoin que de privilèges de niveau objet et elle fonctionne bien pour les administrateurs de base de données qui nécessitent peu de restrictions. Cependant, il semble y avoir un gros trou béant dans l'architecture pour les programmeurs qui font du développement avec une application frontale et PL / SQL dans plusieurs schémas. Voici quelques-unes de mes options avec leurs inconvénients:

  1. Faites en sorte que chaque programmeur fasse le développement dans son propre schéma. Le DBA accordera des privilèges de niveau objet aux programmeurs qui en ont besoin. Tout développement de package doit être effectué par un DBA. L'inconvénient majeur est que les programmeurs utiliseront la base de données comme un ensemble de bits au détriment des performances de la base de données. Je veux que les programmeurs se développent dans la base de données, mais cette méthode la découragerait grandement.

  2. Donnez à chaque programmeur le nom d'utilisateur / mot de passe pour la douzaine de schémas dans lesquels ils doivent effectuer le développement. Accordez à ces schémas d'application l'autorisation de créer des procédures, des tables, etc. Certains des inconvénients de cette approche sont que les programmeurs doivent maintenir plusieurs connexions et sont rarement connecté comme eux-mêmes. Le développement de schémas croisés est également difficile.

  3. Accordez aux programmeurs des privilèges d'authentification proxy sur chaque schéma pour lequel ils doivent effectuer le développement. Cela les maintient connectés comme eux-mêmes sans avoir à leur accorder des privilèges autres que le privilège proxy. Les inconvénients incluent que les programmeurs doivent maintenir des connexions distinctes pour chaque schéma pour lequel ils procurent des proxy, le développement de schémas croisés est plus lourd car les connexions doivent être constamment modifiées et les packages utilisant des liens de base de données publics avec une authentification passée ne se compileront pas dans les connexions proxy.

  4. Donnez à chaque programmeur des privilèges DBA. - L'inconvénient ici est la sécurité. Aucun programmeur de schéma ne peut être tenu à l'écart d'un schéma et tout programmeur peut emprunter l'identité d'un autre programmeur (DBA).

Il semble qu'il y ait une option manquante pour accorder à chaque programmeur SELECT / INSERT / CREATE / etc. privilèges sur le schéma dans lequel ils doivent effectuer le développement. Ils se connectent comme eux-mêmes pour effectuer leur travail à l'aide d'une seule connexion. Les nouveaux objets du schéma auxquels ils ont accès sont immédiatement disponibles.

Suis-je en train de manquer quelque chose? Comment gérez-vous les programmeurs d'applications qui font du développement PL / SQL?


3
+1 grande question - ceci, associé au manque de contrôle de source intégré, est un problème majeur avec Oracle dans un environnement multi-développeur.
ScottCher

Réponses:


11

À l'époque où je travaillais dans une boutique Oracle, nous avions un serveur de développement (développement) spécifique, qui avait des restrictions de sécurité différentes de celles du serveur de production (production). Les développeurs pouvaient faire tout ce dont ils avaient besoin, puis nous remettions les scripts nécessaires au DBA pour les appliquer au serveur de production.

Dans le cas de nos systèmes critiques (SCT Banner, pour le suivi des classes et des étudiants, et Oracle Financials), il y avait également des serveurs «test» et «seed». Le test visait les tests d'acceptation des utilisateurs avant que les éléments migrent de dev vers prod; 'seed' était une installation standard du logiciel, donc si nous découvrions un bogue, nous pourrions vérifier s'il s'agissait de quelque chose que nous avions introduit ou provenait du logiciel SCT ou d'Oracle.


+1 Avec notre base de données à usage général, les développeurs travaillent sur des projets très divers, donc le principe du moindre privilège ne leur donnerait pas un accès complet, même au serveur de développement. ( en.wikipedia.org/wiki/Principle_of_least_privilege )
Leigh Riffel

@Leigh - J'aurais probablement dû clarifier ... le serveur de développement est tombé sous ce que vous aviez comme n ° 1 pour la plupart, pas n ° 4
Joe

1
Je me souviens avoir cloné des bases de données DEV depuis Production, puis des subventions compliquées pour permettre aux développeurs de travailler sans restrictions. Au final, il a été plus facile de donner à chaque développeur sa propre base de données et accès DBA. Serait ensuite alimenter les modifications dans Dev via un cycle de version. Devrait être plus facile maintenant avec la virtualisation.
Sumnibot

@Sumnibot - Plus facile d'installer une base de données de maintenance, de sauvegarde, etc. pour chaque développeur que de leur accorder des autorisations!?! En plus du temps nécessaire à la mise à jour de chacun d'eux, il semblerait que les coûts de licence seraient considérables ou ne leur avez-vous pas donné la version entreprise?
Leigh Riffel

1
Ne contient pas de réponse concrète pour moi.
Michael-O

3

Utilisez des rôles pour associer des collections d'objets, puis accordez l'accès aux rôles

L' instruction GRANT permet au DBA de:

Privilèges d'objet pour un objet particulier pour les utilisateurs, les rôles et PUBLIC. Le tableau 18-2 répertorie les privilèges d'objet et les opérations qu'ils autorisent.

Comme les privilèges d'objet peuvent être accordés à un rôle, il est relativement facile d'accorder à un rôle l'accès à toutes les tables d'un schéma:

sql> spool privs.sql
sql> sélectionnez 'grant select on scott.' || table_name || ' à role_select; ' de dba_tables où owner = 'SCOTT';
sql> @ privs.sql
sql> accorder role_select à john, sam, peter;

Ceci, combiné avec celui GRANT CREATE TABLEémis par l'utilisateur de schéma approprié au rôle, signifie que les développeurs peuvent sélectionner et créer des tables. Ce n'est pas parfait car une table créée nécessite que le script soit à nouveau exécuté, mais WITH GRANT OPTIONsuggère que chaque développeur peut ensuite accorder l'accès à la table qu'il a créée au rôle approprié.

Cela suggère que vous pouvez créer des déclencheurs de niveau DDL qui peuvent exécuter le processus d'octroi approprié, bien que des quantités importantes de tests soient évidemment nécessaires, il devrait être possible de faire en sorte que l'instruction create table accorde automatiquement les autorisations appropriées aux rôles appropriés.

Éditer --

Selon GRANT , le CREATE TABLEprivilège:

Créez une table dans le schéma du bénéficiaire.

Ainsi, en leur donnant la création de table, la modification de table, etc. à partir du bon utilisateur, ils devraient pouvoir accéder au schéma de cet utilisateur comme s'ils étaient l'utilisateur approprié.


J'ai vu la méthodologie à laquelle vous faites référence tentée sans grand succès; cependant, je crois que vous avez raison de dire que cela pourrait être fait avec des tests approfondis. Le problème est que cela permet uniquement aux développeurs de sélectionner l'accès aux tables. L'octroi de la création de table directement ou via un rôle ne leur donne que des privilèges de création de table sur leur propre schéma. Ils ne peuvent toujours pas créer des tables, des procédures, des packages, des déclencheurs ou tout autre objet dans n'importe quel schéma, sauf le leur, ou est-ce votre point de vue qu'ils ne devraient créer des objets dans leur propre schéma même lors du développement?
Leigh Riffel

@Leigh Mis à jour avec des détails.
Brian Ballsun-Stanton

Ce n'est tout simplement pas ainsi que fonctionne Oracle. Essayez ceci: créez l'utilisateur u1 identifié par "ThisIsMy1Password"; créer l'utilisateur u2 identifié par "ThisIsMy1Password"; accorder dba à u1; accorder se connecter à u2; connect u1 / "ThisIsMy1Password" @db; accorder la table de création à u2; connect u2 / "ThisIsMy1Password" @db; créer la table u1.t1 (c1 varchar2 (10)); La dernière étape échoue avec des privilèges insuffisants.
Leigh Riffel
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.