A propos de l'application

Le contenu du script de cette page a pour seul objectif la navigation et n'altère en rien le contenu.

L'application possède les conventions de finalité, de structure et de dénomination suivantes.

Rôle de l'application

L'application est destinée à deux types d'utilisateurs dans une entreprise.

• Utilisateurs standard (responsables des employés)

• Administrateurs d'application

Les utilisateurs standard peuvent effectuer les tâches suivantes :

• Obtenir les employés d'un service donné

• Obtenir l'historique de l'emploi pour un employé donné

• Afficher les informations générales d'un employé donné (nom, service, fonction, responsable, salaire, etc.)

• Modifier le salaire d'un employé donné

• Modifier le poste d'un employé donné

Les administrateurs d'application peuvent effectuer les tâches suivantes :

• Modifier le code, l'intitulé ou la fourchette de salaires d'un emploi existant

• Ajouter un nouveau travail

• Modifier l'ID, le nom ou le responsable d'un service existant

• Ajouter un nouveau service

Structure de l'application

L'application utilise les schémas et objets de schéma suivants.

Objets de schéma de l'application

L'application est composée des objets de schéma suivants :

• Quatre tables qui stockent les données suivantes :

  • jobs

  • Departments

  • Employés

  • Historique des emplois des employés

• Quatre vues d'édition, qui couvrent les tables, vous permettant d'utiliser la redéfinition basée sur l'édition (EBR) pour mettre à niveau l'application terminée lorsqu'elle est utilisée

• Deux déclencheurs qui appliquent des règles métier

• Deux séquences qui génèrent des clés primaires uniques pour les nouveaux services et les nouveaux employés

• Deux packages :

  • employees_pkg, l'interface de programme d'application (API) pour les utilisateurs standard

  • admin_pkg, l'API pour les administrateurs d'application

  Les utilisateurs standard et les administrateurs d'application accèdent à l'application uniquement via ses API. Par conséquent, ils ne peuvent modifier les données qu'en appelant des sous-programmes de package.

Voir aussi :

• "A propos d'Oracle Database" pour plus d'informations sur les objets de schéma

• Guide de développement Oracle Database pour plus d'informations sur EBR

Schémas de l'application

Pour des raisons de sécurité, l'application utilise les cinq schémas (ou utilisateurs) suivants, dont chacun dispose uniquement des privilèges dont il a besoin.

• app_data possède tous les objets de schéma à l'exception des packages et charge ses tables avec les données des tables de l'exemple de schéma HR

  Les développeurs qui créent les packages ne fonctionnent jamais dans ce schéma. Par conséquent, ils ne peuvent pas modifier ou supprimer accidentellement des objets de schéma d'application.

• app_code possède uniquement le package employees_pkg

  Les développeurs de employees_pkg travaillent dans ce schéma.

• app_admin possède uniquement le package admin_pkg

  Les développeurs de admin_pkg travaillent dans ce schéma.

• app_user, l'utilisateur d'application standard, ne possède rien et peut uniquement exécuter employees_pkg

  Le serveur d'applications de niveau intermédiaire se connecte à la base de données du pool de connexions en tant qu'app_user. Si ce schéma est compromis (par un bug d'injection SQL, par exemple), l'attaquant ne peut voir et modifier que les sous-programmes employees_pkg qui le permettent. L'attaquant ne peut pas supprimer des tables, escalader des privilèges, créer ou modifier des objets de schéma, ou autre chose.

• app_admin_user, un administrateur d'application, ne possède rien et peut uniquement exécuter admin_pkg et employees_pkg

  Le pool de connexions de ce schéma est très petit et seuls les utilisateurs privilégiés peuvent y accéder. Si ce schéma est compromis, l'attaquant ne peut voir et modifier que ce que les sous-programmes admin_pkg et employees_pkg permettent de voir et de changer.

Supposons qu'au lieu d'app_user et d'app_admin_user, l'application n'avait qu'un seul schéma qui ne possédait rien et pouvait exécuter à la fois employees_pkg et admin_pkg. Le pool de connexions pour ce schéma doit être suffisamment volumineux pour les utilisateurs standard et les administrateurs d'application. S'il y avait un bug d'injection SQL dans employees_pkg, un utilisateur standard qui a exploité ce bug pouvait accéder à admin_pkg.

Supposons qu'au lieu de app_data, app_code et app_admin, l'application n'avait qu'un seul schéma qui possédait tous les objets de schéma, y compris les packages. Les packages auraient alors tous les privilèges sur les tables, ce qui serait à la fois inutile et indésirable.

Par exemple, supposons que vous disposiez d'une table de trace d'audit, AUDIT_TRAIL. Vous voulez que les développeurs de employees_pkg puissent écrire dans AUDIT_TRAIL, mais pas le lire ni le modifier. Vous voulez que les développeurs de admin_pkg puissent lire AUDIT_TRAIL et y écrire, mais pas le modifier. Si AUDIT_TRAIL, employees_pkg et admin_pkg appartiennent au même schéma, les développeurs des deux packages disposent de tous les privilèges sur AUDIT_TRAIL. Toutefois, si AUDIT_TRAIL appartient à app_data, employees_pkg appartient à app_code et admin_pkg appartient à app_admin, vous pouvez vous connecter à la base de données en tant qu'app_data et effectuer les opérations suivantes :

GRANT INSERT ON AUDIT_TRAIL TO app_code;
GRANT INSERT, SELECT ON AUDIT_TRAIL TO app_admin;

Voir aussi :

• "A propos d'Oracle Database" pour plus d'informations sur les schémas

• "A propos du schéma échantillon HR" pour plus d'informations sur le schéma échantillon HR

• "Pratiques de Sécurité Recommandées"

Conventions de dénomination dans l'application

L'application utilise ces conventions de dénomination.

Elément	Nom
Table	table#
Vue Editioning pour la table#	tableau
Déclencheur sur la table de la vue de modification	table_{a|b}event[_fer] où : a identifie un déclencheur AFTER. b identifie un déclencheur AVANT. fer identifie un déclencheur FOR EACH ROW. event identifie l'événement qui déclenche le déclencheur. Par exemple : i pour INSERT, iu pour INSERT ou UPDATE, d pour DELETE.
Contrainte de clé primaire dans la table#	table_pk
Contrainte NOT NULL sur la table#.column	table_column_not_null (note de bas de page 1)
Contrainte UNIQUE sur table#.column	table_column_unique (note de bas de page 1)
Contrainte CHECK sur la table#.column	table_column_check (note de bas de page 1)
Contrainte REF sur la table1#.column à table2#.column	table1_to_table2_fk (note de bas de page 1)
Contrainte REF sur table1#.column1 à table2#.column2	table1_col1verstable2_col2_fk (note de bas de page 1) (note de bas de page 2)
Séquence pour le numéro de table	séquence_table
Nom de paramètre	p_nom
Nom de la variable locale	l_nom

Note de bas de page 1 : table, table1 et table2 sont abrégés en emp pour les employés, dept pour les services et job_hist pour job_history.

Note de bas de page 2 : col1 et col2 sont des abréviations des noms de colonne column1 et column2. Un nom de contrainte ne peut pas comporter plus de 30 caractères.