Aggiornamento
In un primo momento ho utilizzato la macro sc_change_connection il presupposto organizzativo era avere tutte le connessioni definite a livello di ambiente (_lib) e non di uso, questo per un idea di maggiore sicurezza (crittazione credenziali)
Ma ho notato che l uso della sc_change è complicato , mi domando a cosa possa servire .
Quindi ho optato per la riscrittura della connessione in tempo di esecuzione utilizzando i parametri depositati su una tabella . (esite un esempio banale nei corsi) .
Le cosa pare funzionino bisogna però avere delle accortezze in fase di sviluppo e successive manutenzioni.
In pratica tutte le app che gestiscono la sicurezza dovrebbero avere una loro connessione intoccabile, il resot del porgetto uun ,altra che poi viene modificata in fase di identificaizone dell'utente.
Agendo in questo modo è possibile utilizzare più connessioni per esempio sulle select dei form dove si può forzare la connessione dando il valore interessato, ovviamente se il contenuto della connessioenm viene modificato prima dle lancio del app il puntamento avverrà verso il nuovo db.
Bello ma non privo di rischio perdita orizzonte -- dove sono adesso?? ( a me capita spesso di perdermi nei dati
)
Seprarare la sicurezza dai dati è allineato alle direttive NIS2 cosi come separare i dati dalle app . vero che una connessione in più aumenta il rischio di intercettazione ma è anchevero che specializzandola il rischio si può azzerare.
Intema di sicurezza rimango a mio avviso aperte alcune lacune . La prima rigurardal intercettazione dele tabele contenenti le credenziali, anche se il ivello non è altor suggerisco di usare la macro di crittaizone di sc , questa permette di codificare e decodificare il valore delle PWD e altro . in questo modo un evntuale accesso non controllato alla tabella credenziali potrebbre essere accettabile non potendo decodificare (solo questione di tempo) i dati .
Ho molte perplessità sui client . mi pare che i parametri siano conservati nei "meandri" dei browser, questo non è buono e se cosi fosse allora esisterebbe un reale rischio di sicurezza . Accedere ai dati dei browser è facile ,a volte troppo facile e ci si può arrivare anche via messaggi email , quindi ..... terrore .
Chissà chi ha approfondito la questione. La faccenda non è da sottovalutare , SC viene utulizzato principalmente in ambito gestionale , ambito dove i dati hanno molta importanza e grandi tutele legali , ambito dove gli attacchi sono costanti , anche quelli "interni" ( dipendenti infedeli) .
La gestione sepraata degi utenti al sistema favorisce un migliore controllo di ciò che avviene , unico log , unico punto per conoscere sessioni attive ecc. ) se la nuova versioen 9.11 porta la gestioen messaggi allora la potenza della unica connessione di sicurezza potrebbe essere ottima , ala fine si emula un ambiete operativo di livello . chissà se hanno dato un occhiata alle connessioni per i messaggi ?
Io ragiono a livello mainframe ovvvero centro dati dove da ununico punto gestisco tutto ciò che avviene e con la frusta in mano attendo l utente distratto
La gestione separata permette anche di reaizzare sistemi dove alcuni dati sono comuni , ad esempio certe trascodifiche o addiittura pieni dei conti ecc.
Lo so mi spingo avanti pensando chissà cosa per poi scoprire l'acqua calda e vedere che è tutto nella norma , il problema del lavorare da casa .
Comunque prima p poi capirò l uso della change_connection .
I log . questi sono veramente ostici . anche loro operano con la connessione ,ma qualcosa non mi torna . vedremo .
Buona gornata a tutti e sopratutto : divertitevi , in fondo facciamo il lavoro più bello del mondo
