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 completare 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 delle applicazioni possono completare 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 da questi oggetti schema:

• Quattro tabelle, che memorizzano i dati seguenti:

  • 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 Database" per informazioni sugli oggetti dello schema

• Oracle 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.

• app_data 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.

• app_code possiede solo il pacchetto employee_pkg

  Gli sviluppatori di employee_pkg lavorano in questo schema.

• app_admin è proprietario solo del pacchetto admin_pkg

  Gli sviluppatori di admin_pkg lavorano in questo schema.

• app_user, tipico utente dell'applicazione, non possiede nulla e può eseguire solo employee_pkg

  Il server applicazioni di livello intermedio si connette al database nel connection pool come 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 employee_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.

• app_admin_user, un amministratore dell'applicazione, non possiede nulla e può eseguire solo admin_pkg e impiegati_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 admin_pkg e employee_pkg subprogrammi consentono di vedere e modificare.

Si supponga che invece di app_user e app_admin_user, l'applicazione avesse un solo schema che non possedeva nulla e che potesse eseguire sia employee_pkg che 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 SQL injection in impiegati_pkg, un utente tipico che ha sfruttato quel bug potrebbe accedere a admin_pkg.

Si supponga che invece di 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 di impiegati_pkg siano in grado di scrivere in AUDIT_TRAIL, ma non di leggerlo o modificarlo. Si desidera che gli sviluppatori di admin_pkg siano in grado di leggere AUDIT_TRAIL e scrivere su di esso, ma non modificarlo. Se AUDIT_TRAIL, impiegati_pkg e admin_pkg appartengono allo stesso schema, gli sviluppatori dei due pacchetti hanno tutti i privilegi su AUDIT_TRAIL. Tuttavia, se AUDIT_TRAIL appartiene a app_data, employee_pkg appartiene a app_code e admin_pkg appartiene a app_admin, è possibile connettersi al database come app_data ed eseguire le operazioni riportate di seguito.

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

Vedere anche:

• "Informazioni su Oracle 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_null (nota 1)
Vincolo UNIQUE sul n. tabella.colonna	table_column_unique (nota 1)
Vincolo CHECK sul n. tabella.colonna	table_column_check (nota a piè di pagina 1)
Vincolo REF su n. tabella1.colonna a n. tabella2.colonna	table1_to_table2_fk (nota a piè di pagina 1)
Vincolo REF su n. tabella1.colonna1 a n. tabella2.colonna2	table1_col1totable2_col2_fk (nota a piè pagina 1) (nota a piè pagina 2)
Sequenza per n. tabella	sequenza_tabella
Il nome del parametro	p_nome
Nome della variabile locale	l_nome

Footnote 1: table, table1 e table2 sono abbreviati in emp per i dipendenti, reparto per i reparti e job_hist per job_history.

Nota a piè di pagina 2: col1 e col2 sono abbreviazioni dei nomi di colonna colonna1 e colonna2. Il nome di un vincolo non può superare i 30 caratteri.