Informazioni sull'applicazione

I componenti script in questa pagina sono utilizzati solo per scopi di navigazione e non alterano in alcun modo il contenuto.

L'applicazione dispone delle convenzioni di scopo, struttura e denominazione riportate di seguito.

Scopo dell'applicazione

L'applicazione è destinata a due tipi di utenti in un'azienda.

• Utenti tipici (responsabili dei dipendenti)

• Amministratori dell'applicazione

In genere, gli utenti possono eseguire i task riportati di seguito.

• Recupera i dipendenti in un determinato reparto

• Recupera la cronologia della mansione per un determinato dipendente

• Mostra informazioni generali per un dipendente specifico (nome, reparto, mansione, manager, stipendio e così via)

• Modificare lo stipendio di un dipendente specificato

• Modificare la mansione di un determinato dipendente

Gli amministratori dell'applicazione possono eseguire i task riportati di seguito.

• Modificare l'ID, il titolo o l'intervallo di stipendio di una mansione esistente

• Aggiungi un nuovo job

• Modificare l'ID, il nome o il manager di un reparto esistente

• Aggiungi un nuovo reparto

Struttura dell'applicazione

L'applicazione utilizza gli oggetti e gli schemi schema riportati di seguito.

Oggetti schema dell'applicazione

L'applicazione è composta dai seguenti oggetti schema:

• Quattro tabelle, che memorizzano i dati relativi agli elementi riportati di seguito.

  • Job

  • Departments;

  • Dipendenti

  • Cronologia del lavoro dei dipendenti

• Quattro viste di edizione, che coprono le tabelle, che consentono di utilizzare la ridefinizione basata su edizioni (EBR) per aggiornare l'applicazione finita quando è in uso

• Due trigger che applicano le regole aziendali

• Due sequenze che generano chiavi primarie univoche per nuovi reparti e nuovi dipendenti

• Due pacchetti.

  • employee_pkg, l'interfaccia API (Application Program Interface) per gli utenti standard

  • admin_pkg, l'API per gli amministratori dell'applicazione

  Gli utenti standard e gli amministratori delle applicazioni accedono all'applicazione solo tramite le relative API. Pertanto, possono modificare i dati solo richiamando i sottoprogrammi del pacchetto.

Vedere anche:

• "Informazioni su Oracle AI Database" per informazioni sugli oggetti dello schema

• Oracle AI Database Development Guide per informazioni su EBR

Schemi dell'applicazione

Per motivi di sicurezza, l'applicazione utilizza i cinque schemi (o utenti) elencati di seguito, ciascuno dei quali dispone solo dei privilegi necessari.

• Lo schema app_data, che possiede tutti gli oggetti dello schema tranne i package e carica le tabelle con i dati delle tabelle nello schema di esempio hr.

  Gli sviluppatori che creano i package non funzionano mai in questo schema. Pertanto, non possono modificare o eliminare accidentalmente gli oggetti dello schema dell'applicazione.

• Lo schema app_code, che possiede solo il pacchetto employees_pkg.

  Gli sviluppatori del package employees_pkg operano in questo schema.

• Lo schema app_admin, che possiede solo il pacchetto admin_pkg.

  Gli sviluppatori del package admin_pkg operano in questo schema.

• L'utente app_user, l'utente tipico dell'applicazione, che non possiede alcun proprietario e può eseguire solo il pacchetto employees_pkg.

  L'Application Server di livello intermedio si connette al database nel connection pool come utente app_user. Se questo schema è compromesso, ad esempio da un bug di SQL injection, l'attaccante può vedere e modificare solo ciò che i sottoprogrammi del pacchetto employees_pkg gli consentono di vedere e modificare. L'attaccante non può eliminare le tabelle, escalare i privilegi, creare o modificare oggetti dello schema o qualsiasi altra cosa.

• L'utente app_admin_user, amministratore dell'applicazione, che non possiede alcun proprietario e può eseguire solo i pacchetti admin_pkg e employees_pkg.

  Il connection pool per questo schema è molto piccolo e solo gli utenti con privilegi possono accedervi. Se questo schema è compromesso, l'attaccante può vedere e modificare solo ciò che i sottoprogrammi del pacchetto admin_pkg e employees_pkg gli consentono di vedere e modificare.

Si supponga che, al posto degli utenti app_user e app_admin_user, l'applicazione disponga di un solo schema che non possedeva nulla e che potesse eseguire entrambi i pacchetti employees_pkg e admin_pkg. Il connection pool per questo schema dovrebbe essere abbastanza grande sia per gli utenti standard che per gli amministratori dell'applicazione. Se c'era un bug di SQL injection nel pacchetto employees_pkg, un utente tipico che ha sfruttato quel bug potrebbe accedere al pacchetto admin_pkg.

Si supponga che, invece degli schemi app_data, app_code e app_admin, l'applicazione disponga di un solo schema proprietario di tutti gli oggetti dello schema, inclusi i package. I pacchetti avrebbero quindi tutti i privilegi sulle tabelle, che sarebbero sia inutili che indesiderabili.

Ad esempio, si supponga di disporre di una tabella di audit trail, AUDIT_TRAIL. Si desidera che gli sviluppatori del pacchetto employees_pkg siano in grado di scrivere nella tabella AUDIT_TRAIL, ma non di leggerlo o modificarlo. Si desidera che gli sviluppatori del pacchetto admin_pkg siano in grado di leggere la tabella AUDIT_TRAIL e scriverci, ma non di modificarla. Se la tabella AUDIT_TRAIL e i pacchetti employees_pkg e admin_pkg appartengono allo stesso schema, gli sviluppatori dei due pacchetti dispongono di tutti i privilegi sulla tabella AUDIT_TRAIL. Tuttavia, se la tabella AUDIT_TRAIL appartiene allo schema app_data, il pacchetto employees_pkg appartiene allo schema app_code e il pacchetto admin_pkg appartiene allo schema app_admin, è possibile connettersi al database come schema app_data ed eseguire i comandi seguenti:

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

Vedere anche:

• Informazioni su Oracle AI Database per informazioni sugli schemi
• Informazioni sullo schema di esempio HR per informazioni sullo schema di esempio HR
• Procedure di sicurezza consigliate

Convenzioni di denominazione nell'applicazione

L'applicazione utilizza queste convenzioni di denominazione.

Elemento	Nome
Tabella	n. tabella
Vista edizione per tabella n.	tabella
Attiva nella tabella della vista di edizione	tabella_{a|b}evento[_fer] dove: a identifica un trigger AFTER. b identifica un trigger PRIMA. fer identifica un trigger FOR EACH ROW. L'evento identifica l'evento che attiva il trigger. Ad esempio: i per INSERT, iu per INSERT o UPDATE, d per DELETE.
Vincolo PRIMARY KEY nella tabella n.	tabella_pk
Vincolo NOT NULL su n. tabella.colonna	table_column_not_null1
Vincolo UNIQUE sul n. tabella.colonna	table_column_unique1
Vincolo CHECK sul n. tabella.colonna	table_column_check1
Vincolo REF su n. tabella1.colonna a n. tabella2.colonna	tabella1_to_tabella2_fk1
Vincolo REF su n. tabella1.colonna1 a n. tabella2.colonna2	table1_col1atable2_col2_fk12
Sequenza per n. tabella	sequenza_tabella
Il nome del parametro	p_nome
Nome della variabile locale	l_nome

1. table, table1 e table2 sono abbreviati in emp per i dipendenti, dept per i reparti e job_hist per job_history. ↩ ↩² ↩³ ↩⁴ ↩⁵

2. col1 e col2 sono abbreviazioni dei nomi di colonna colonna1 e colonna2. Il nome di un vincolo non può contenere più di 30 caratteri. ↩