1C ha un sistema integrato di diritti di accesso (questo sistema è chiamato - ruoli 1C). Questo sistema è statico - poiché l'amministratore ha impostato i diritti 1C, così sia.
Inoltre, esiste un sistema dinamico di diritti di accesso (chiamato RLS 1C). In esso, i diritti 1C vengono calcolati dinamicamente al momento del lavoro dell'utente in base ai parametri specificati.
Una delle impostazioni di sicurezza più comuni in vari programmi è un insieme di autorizzazioni di lettura / scrittura per gruppi di utenti e quindi - inclusione o esclusione di un utente dai gruppi. Ad esempio, un sistema simile viene utilizzato in Windows AD (Active Directory).
Tale sistema di sicurezza in 1C è chiamato Ruoli 1C. I ruoli 1C si trovano nella configurazione nel ramo Generale / Ruoli. I ruoli 1C agiscono come gruppi per i quali sono assegnati i diritti 1C. Inoltre, l'utente è incluso o escluso da questo gruppo.
Facendo doppio clic sul nome del ruolo 1C, si aprirà l'editor dei diritti per il ruolo 1C. Sinistra: un elenco di oggetti 1C. Selezionare uno e le opzioni per i diritti di accesso verranno visualizzate sulla destra (almeno: leggi, aggiungi, modifica, elimina).
Per il ramo superiore (il nome della configurazione corrente), vengono impostati i diritti amministrativi 1C e l'accesso per avviare varie opzioni.
Tutti i diritti 1C sono divisi in due gruppi: il diritto "semplice" e lo stesso diritto con l'aggiunta di "interattivo". Cosa significa?
Quando un utente apre un modulo (ad esempio, l'elaborazione) e fa clic su un pulsante su di esso, il programma nella lingua 1C integrata esegue determinate azioni, ad esempio l'eliminazione di documenti. Per l'autorizzazione di queste azioni (eseguite a livello di programmazione) - i diritti 1C sono "semplicemente" responsabili.
Quando un utente apre una rivista e inizia a fare qualcosa dalla tastiera da solo (ad esempio, inserendo nuovi documenti), questi sono diritti 1C "interattivi".
Un utente può avere più ruoli disponibili, quindi vengono aggiunte le autorizzazioni.
Sezione delle possibilità di impostazione dei diritti di accesso tramite ruoli - oggetto 1C. Cioè, puoi abilitare l'accesso alla directory o disabilitarla. Non puoi accenderlo un po '.
Per questo, esiste un'estensione del sistema di ruolo 1C chiamato 1C RLS. È un sistema dinamico di diritti di accesso che consente di limitare l'accesso in parte. Ad esempio, un utente vede solo i documenti per un magazzino e un'organizzazione specifici e non vede il resto.
Accuratamente! Quando si utilizza lo schema RLS 1C confuso, diversi utenti possono avere domande quando provano a confrontare lo stesso report generato da utenti diversi.
Prendi una determinata directory (ad esempio le organizzazioni) e un certo diritto (ad esempio, leggi). Consenti la lettura per il ruolo 1C. Nel pannello Limitazione dell'accesso ai dati, si imposta il testo della query che restituisce VERO o FALSO a seconda delle impostazioni. Le impostazioni sono generalmente memorizzate in un registro delle informazioni (ad esempio, il registro delle informazioni di configurazione Accounting UserAccessPreferences).
Questa richiesta viene eseguita in modo dinamico (quando si tenta di implementare la lettura), per ogni record del dizionario. Pertanto, per quei record per i quali la query di sicurezza ha restituito VERO - l'utente vedrà e il resto no.
I diritti 1C per i quali sono impostate le restrizioni RLS 1C sono evidenziati in grigio.
La copia delle stesse impostazioni RLS 1C viene eseguita utilizzando i modelli. Fai un modello, chiamalo (ad esempio) MyPattern, specifica una richiesta di sicurezza in esso. Inoltre, nelle impostazioni dei diritti di accesso 1C, specificare il nome del modello in questo modo: "#MyTemplate".
Quando un utente lavora in modalità Enterprise 1C, quando RLS 1C è in esecuzione, potrebbe ricevere un messaggio di errore "Diritti insufficienti" (ad esempio, per leggere la directory Xxx).
Ciò significa che RLS 1C ha bloccato la lettura di più record.
Per evitare che appaia un messaggio del genere, è necessario utilizzare la parola ALLOWED () nel testo della richiesta nella lingua 1C incorporata.
Per esempio:
Problema classico: dare all'utente l'accesso a un oggetto, ma non per tutti gli elementi / documenti, ma solo per alcuni.
Ad esempio, in modo che il gestore veda i rapporti solo per i suoi clienti.
O potrebbe essere una limitazione "Tutti tranne pochi".
Oppure la restrizione non riguarda directory / documenti, ma sui dati di registro…
Ad esempio, in modo che gli utenti non possano estrarre dati sui pagamenti ai partner con alcun rapporto.
In realtà, questa è un'impostazione sottile e molto flessibile "cosa può essere visto da questo utente e cosa non ha bisogno di indovinare".
Perché RLS?
La maggior parte delle implementazioni richiede a diversi utenti di stabilire diversi livelli di accesso alle informazioni nel database.
Nelle configurazioni, gli oggetti speciali dei metadati - ruoli - sono responsabili di possibili diritti di accesso ai dati. A ciascun utente infobase sono assegnati uno o più ruoli. Determinano se le operazioni sono possibili con oggetti specifici di metadati (lettura, scrittura, condotta, ecc.).
Ma non è tutto.
È spesso necessario non solo apre / nega l'accesso a un oggetto specifico, ma limita l'accesso a parte dei dati in esso contenuti.
I ruoli da soli non possono risolvere questo problema. - per questo, viene implementato un meccanismo di restrizione dell'accesso a livello record (RLS).
I vincoli sono condizioni alle quali sarà consentita un'azione sui dati (lettura, scrittura, ecc.). - in questo modo è possibile limitare l'accesso non all'intero oggetto, ma solo a una parte dei suoi dati.
Informazioni su RLS - in modo più dettagliato: 8 video e PDF
Poiché questa è un'attività comune per la gestione di 1C, ti consigliamo di esaminare materiali più dettagliati:
Limitazione dell'accesso ai dati mediante i ruoli
Questo video spiega come limitare l'accesso ai dati usando i ruoli. Si specifica che i ruoli limitano l'accesso al tipo di oggetti infobase (una directory separata, ma non elementi specifici della directory).
Record Level Restriction (RLS)
Questo video illustra il meccanismo delle restrizioni di accesso a livello di record (RLS), quando è possibile configurare l'accesso non all'intera directory nel suo insieme, ma ai suoi singoli elementi, a seconda di quelli memorizzati nel database delle informazioni. Tali restrizioni sono scritte in ruoli.
Implementazione di restrizioni di accesso a livello di record per gli appaltatori di directory
Questo video descrive come configurare l'accesso dei gestori solo ai propri appaltatori assegnati loro nella configurazione demo dell'applicazione gestita.
Come funzionano le restrizioni di accesso a basso livello a livello record
Questo video mostra come la piattaforma trasforma le richieste inviate al server DBMS per l'esecuzione in presenza di restrizioni di accesso a livello record.
Applicare insieme più restrizioni di accesso a livello di record
A un utente infobase possono essere assegnati diversi ruoli. Allo stesso tempo, ogni ruolo può avere le proprie restrizioni di accesso a livello record. Questo video spiega come si comporta il sistema quando è vincolato.
Vincolo con il metodo ALL
Questo video descrive il primo modo per imporre restrizioni a livello di record: il metodo ALL. Allo stesso tempo, se la selezione include record a cui l'accesso è limitato, verrà visualizzato un messaggio di errore.
Imporre restrizioni usando il metodo AMMESSO
Questo video descrive il primo modo per applicare le restrizioni a livello di record: il metodo AMMESSO. In questo caso, solo i record a cui l'utente ha i diritti di accesso saranno inclusi nella selezione.
Ecco alcuni argomenti del corso:
- Installazione e aggiornamento della piattaforma 1C: Enterprise 8 - manuale e automatico, per Windows e Linux
- Avvio automatico per eseguire operazioni di routine
- Aggiornamento delle configurazioni dalla modalità utente
- Aggiornamento di configurazioni non standard. Come evitare problemi durante l'aggiornamento ha cambiato le configurazioni tipiche
- Crea il tuo file di consegna cfu
- Strumenti BSP: moduli esterni, elaborazione dei documenti di compilazione, ecc.
- utilizzando dBMS PostgreSQL gratuito
- Installazione e avvio cluster di server 1C: Enterprise 8
- Utilità di amministrazione per configurare il cluster e i server di produzione
- Personalizzazione RLS sull'esempio di SCP 1.3 e ERP 2
- Cosa fare, se i dati in IB sono danneggiati
- Personalizzazione scambio di dati tra le configurazioni
- Organizzazione sviluppo del gruppo
- Personalizzazione e utilizzo chiavi di protezione hardware
- Licenze software 1C: installazione e collegamento ad apparecchiature esterne
In ogni caso, un giorno dovrai distribuire 1C, configurare ridondanza, diritti di accesso, varie modalità di avvio, testare l'integrità dei database, garantire il funzionamento dei server, ecc.
Ed è meglio farlo subito.
In modo che più tardi ci fosse “...! Bene che ... Il tuo ...! " - e altre espressioni di rimpianto :)
Ogni dirigente concorderà incondizionatamente che ogni dipendente dell'impresa dovrebbe avere accesso solo alle informazioni che rientrano nelle sue competenze. Ad esempio, un negoziante in un magazzino non ha bisogno di esaminare quali operazioni vengono eseguite dal CFO o dal capo contabile. Tuttavia, spesso sorgono situazioni piuttosto sottili, ad esempio, quando il programma 1C: Enterprise 8 non viene utilizzato per una, ma per diverse aziende. Ognuno di loro ha i propri dipendenti che dovrebbero avere accesso solo alle informazioni autorizzate relative alla propria azienda.
In questo caso, l'assistente ideale per garantire i diritti di accesso necessari è la tecnologia Sicurezza a livello di record (RLS), che consente di fornire accesso alle informazioni a livello di record.
Consideriamo un esempio di una situazione specifica. La nostra azienda è composta da due organizzazioni. Il primo riguarda la vendita di software, il secondo - la formazione per lavorare con esso. Per tenere conto di entrambe le organizzazioni, utilizziamo il prodotto software 1C: Integrated Automation 8.
Il nostro compito è quello di differenziare i diritti di accesso alle informazioni dei dipendenti di due organizzazioni in modo che i dipendenti con gli stessi diritti possano vedere solo ciò che appartiene all'organizzazione in cui lavorano.
La prima cosa che viene in mente quando si imposta questa attività è l'impostazione delle selezioni per le organizzazioni. Tuttavia, questa soluzione presenta due svantaggi significativi:
- le selezioni dovranno essere configurate in tutte le forme del programma;
- per un utente più o meno intelligente, non è assolutamente difficile disabilitarli.
Il modo più sicuro è delimitare l'accesso degli utenti a livello di record. Come si può fare?
La prima cosa da fare è abilitare il programma a utilizzare questo metodo. Questo richiede:
Nel nostro caso, è necessario introdurre restrizioni di accesso per organizzazione, ma è chiaro che il programma offre opportunità molto più ampie. Ad esempio, per delimitare l'accesso tramite libri e documenti di riferimento.
Un meccanismo simile è implementato in altre soluzioni applicate 1C:
- (revisione 10.3)
- e 1C: Stipendio e gestione del personale 8 (versione 2.5).
In questi programmi, la differenziazione dei diritti di accesso viene effettuata utilizzando la directory "Gruppi utenti", che è disponibile dal menu "Servizio", sezione "Impostazioni accesso utente".
- Pertanto, in questi programmi, dobbiamo dividere tutti i nostri utenti che lavorano come parte dell'azienda in gruppi per organizzazione.
- Quindi premere il pulsante "Accedi alle impostazioni".
- Nella finestra che appare, fai clic sul pulsante "Aggiungi" e inserisci l'oggetto di accesso (nella nostra situazione, questa è un'organizzazione).
- Se dobbiamo consentire ai dipendenti dell'organizzazione di inserire i dati nel database delle informazioni, dobbiamo selezionare la casella nella colonna "Registra".
Questi passaggi devono essere completati per ciascuna organizzazione. Successivamente, dopo aver inserito il programma, ogni dipendente vedrà solo quei documenti che sono determinati dai suoi diritti di accesso per posizione e relativi alla sua organizzazione.
Il programma 1C ha un sistema integrato di diritti di accesso, che si trova nel Configuratore - Generale - Ruoli.
Cosa caratterizza questo sistema e qual è il suo scopo principale? Ti consente di descrivere gruppi di diritti che corrispondono alle posizioni degli utenti o ai tipi delle loro attività. Questo sistema di diritti di accesso è di natura statica, il che significa che l'amministratore ha impostato i diritti di accesso su 1C. Oltre a quello statico, esiste un secondo sistema di diritti di accesso - dinamico (RLS). In questo sistema, i diritti di accesso sono calcolati in modo dinamico, a seconda dei parametri specificati, durante il funzionamento.
Ruoli in 1C
Le impostazioni di sicurezza più comuni in diversi programmi sono il cosiddetto insieme di autorizzazioni di lettura / scrittura per vari gruppi di utenti e in futuro: inclusione o esclusione di un utente specifico dai gruppi. Tale sistema, ad esempio, viene utilizzato nel sistema operativo Windows AD (Active Directory). Il sistema di sicurezza utilizzato nel software 1C è chiamato ruoli. Cos'è? Ruoli in 1C è un oggetto situato nella configurazione nel ramo: Generale - Ruoli. Questi ruoli 1C sono gruppi per i quali sono assegnati diritti. In futuro, ogni utente può essere incluso ed escluso da questo gruppo.
Facendo doppio clic sul nome del ruolo, si aprirà l'editor dei diritti per il ruolo. Sulla sinistra c'è un elenco di oggetti, segnane uno qualsiasi e sulla destra vedrai le opzioni per i possibili diritti di accesso:
- lettura: ricezione dei record o dei loro frammenti parziali dalla tabella del database;
- aggiunta: nuovi record durante il salvataggio di quelli esistenti;
- modifica: modifica dei record esistenti;
- eliminazione: alcune voci, mantenendo invariato il resto.
Si noti che tutti i diritti di accesso possono essere divisi in due gruppi principali: questo è un diritto "semplice" e un tale diritto con l'aggiunta della caratteristica "interattiva". Cosa significa questo? E il punto è il seguente.
Nel caso in cui l'utente apra un modulo, ad esempio l'elaborazione, e allo stesso tempo fa clic su di esso con il mouse, il programma nella lingua 1C integrata inizia a eseguire azioni specifiche, eliminando documenti, ad esempio. Per l'autorizzazione di tali azioni eseguite dal programma, i corrispondenti diritti "semplici" 1C sono responsabili.
Nel caso in cui un utente apra una rivista e inizi a inserire qualcosa da solo dalla tastiera (nuovi documenti, ad esempio), i diritti "interattivi" 1C sono responsabili per consentire tali azioni. Ogni utente può avere più ruoli disponibili contemporaneamente, quindi viene aggiunta l'autorizzazione.
RLS in 1C
È possibile abilitare o disabilitare l'accesso al libro di riferimento (o al documento). Allo stesso tempo, non puoi "includere un po '". A tal fine, esiste una certa estensione del sistema di ruolo 1C, che si chiama RLS. È un sistema dinamico per i diritti di accesso, che introduce restrizioni parziali sull'accesso. Ad esempio, solo i documenti di una determinata organizzazione e magazzino diventano disponibili all'attenzione dell'utente, non vede il resto.
Va tenuto presente che il sistema RLS deve essere usato con molta attenzione, poiché il suo schema di confusione è piuttosto difficile da capire, diversi utenti potrebbero avere domande quando, ad esempio, controllano lo stesso report, che viene generato da under utenti diversi. Consideriamo un esempio. Si seleziona una directory specifica (organizzazioni, ad esempio) e un diritto specifico (leggi, ad esempio), ovvero si consente la lettura per il ruolo 1C. In questo caso, nel pannello Restrizioni di accesso ai dati remoti, si imposta il testo della richiesta, in base al quale è impostato Falso o Vero, a seconda delle impostazioni. Di solito le impostazioni vengono salvate in un apposito registro di informazioni.
Questa richiesta verrà eseguita in modo dinamico (quando si tenta di organizzare la lettura) per tutti i record del dizionario. Funziona così: quei record per i quali è stata assegnata la query di sicurezza - True, l'utente vedrà e altri - no. I diritti 1C con restrizioni stabilite sono evidenziati in grigio.
L'operazione di copia delle stesse impostazioni RLS viene eseguita utilizzando i modelli. Innanzitutto, si crea un modello, chiamandolo, ad esempio, MyTemplate, in cui si riflette la richiesta di sicurezza. Quindi, nelle impostazioni dei diritti di accesso, specificare il nome di questo modello in questo modo: "#MyTemplate".
Quando un utente lavora in modalità Enterprise 1C, durante la connessione a RLS, potrebbe apparire un messaggio di errore del modulo: "Diritti insufficienti" (per leggere la directory XXX, ad esempio). Ciò indica che il sistema RLS ha bloccato la lettura di alcuni record. Per evitare che questo messaggio appaia di nuovo, è necessario inserire la parola CONSENTITO nel testo della richiesta.
Il suggerimento fornisce istruzioni dettagliate per l'impostazione di Record Level Sceurity (RLS) in Axapt 3.0.
Dove è scritto nella documentazione
Versione russa: Guida per l'utente per l'amministratore (russo) _3.0.pdf (p. 126)
Versione inglese: Guida dell'utente per l'amministrazione (p. 40, 101)
introduzione
La limitazione dei diritti a livello di record (Sicurezza a livello di record - RLS) consente di limitare l'accesso ai record per diversi gruppi di utenti. Ad esempio, un gruppo di manager può vedere clienti russi, mentre un altro è straniero. Inoltre, i manager che lavorano con clienti russi non dovrebbero vedere clienti stranieri. Inoltre, i manager non dovrebbero nemmeno vederli.
RLS in Axapta funziona in combinazione con il sistema di impostazione dei diritti personalizzati. Ciò significa che, al fine di limitare l'accesso a un determinato campo di una tabella, è necessario impostare i diritti normali per queste tabelle. Il compito di RLS è filtrare i record inosservati dall'utente.
L'impostazione della restrizione dei diritti a livello di record si riduce alla definizione di filtri per determinate tabelle per diversi gruppi di utenti. Se l'utente appartiene a più gruppi, i filtri sono combinati dalla condizione OR.
L'arte di impostare le autorizzazioni è definire i filtri corretti sulle tabelle corrette. Inoltre, per farlo in modo ottimale, in modo da non ridurre le prestazioni del sistema.
Personalizzazione
Prima di eseguire la configurazione della limitazione dei diritti di accesso, è necessario adottare le misure preliminari:
I lavori preparatori sono stati completati. Attualmente l'utente Test non ha diritti. Puoi andare su Axapta sotto l'utente test e assicurarti che non possa nemmeno aprire il menu principale.
Puoi iniziare a configurare RLS:
- Configuriamo i diritti normali per il gruppo tstGroup1.
- Clicca sul pulsante Richiesta;
A rigor di termini, tutto! RLS è configurato. Ora l'utente Test ha il diritto di leggere i dati dal modulo Contabilità clienti e il diritto di creare ed eliminare gli ordini. Inoltre, viene applicato un filtro alla tabella dei clienti. D'ora in poi, gli utenti appartenenti al gruppo tstGroup1 saranno in grado di vedere solo altri client (client per cui è impostato l'altro gruppo).
Controlla l'impostazione
Accedi ad Axapta sotto l'utente Test. Aprire l'elenco dei clienti (menu principale \\ Contabilità \\ Clienti). Assicurarsi che l'elenco dei client visualizzi solo quei client per i quali è impostato il gruppo con il codice Prch.
Si noti che nel menu principale non è stata aperta solo la scheda Contabilità clienti. Sono state aperte anche le schede Contabilità generale, Contanti, CRM, Gestione inventario, Generale. Il fatto è che concedendo i diritti al modulo client, abbiamo influenzato molte tabelle di altri moduli. Sì, certo, i segnalibri non necessari sono quasi vuoti. Tuttavia, nella vita reale i diritti devono essere dati in modo molto più preciso.
Inoltre, nella vita reale, i segnalibri dei moduli non acquistati non vengono mai visualizzati. Ad esempio, prova a disabilitare il modulo CRM nell'impostazione delle chiavi di configurazione.
Prova ad applicare il filtro "*" al gruppo (Posiziona il mouse sulla colonna Gruppo client, fai clic con il pulsante destro del mouse, seleziona Trova ..., inserisci il filtro "*").
Prova anche ad applicare il filtro "! Prc". Prova ad aggiungere filtri ad altri campi. Assicurarsi che il filtro client funzioni effettivamente in tutti i casi.
Scopri come RLS funziona nei rapporti. Aprire il report con l'elenco dei client (menu principale \\ Contabilità \\ Rapporti \\ Dati di base \\ Cliente). Prova a creare lo stesso rapporto con i filtri. Assicurarsi che il filtro client funzioni correttamente anche nei report.
Si noti che il programmatore non ha bisogno di cambiare o ripetere nulla per far funzionare RLS nel suo report, se ha usato il kernel nei moduli o per creare report e non ha ignorato il meccanismo di recupero dei dati. Se il programmatore ha codificato manualmente le query, deve aggiungere una chiamata al metodo recordLevelSecurity (true) per quelle tabelle in cui è necessario abilitare la limitazione dell'accesso ai record. Per i dettagli, consultare la guida per sviluppatori per la parola chiave Security a livello di record.
Ordini aperti. Oops! E gli ordini sono mostrati per tutti i clienti. Perché? Perché gli ordini contengono codici cliente, non i clienti stessi. Prova ad andare alla tabella principale con i client: non sarai in grado di vedere i parametri dei client nascosti.
In generale, nella vita reale non è sufficiente configurare una singola tabella per impostare una limitazione dei privilegi. Di norma, i vincoli correlati devono essere imposti su diverse tabelle correlate.
I diritti di accesso a livello di record si applicano non solo ai moduli e ai report, ma anche agli elenchi a discesa. Apri l'ordine e fai clic sul pulsante dell'elenco a discesa per il client. Sì, tutto è corretto. L'utente Test vede solo altri client.
RLS per più gruppi
Ora esaminiamo una situazione in cui è necessario configurare più gruppi diversi con diritti diversi e con restrizioni sui diritti diversi.
Supponiamo che un gruppo di manager abbia accesso ad altri clienti (gruppo di clienti \u003d O&M) e un altro gruppo di manager abbia accesso a clienti normali (gruppo di clienti \u003d T&A). Abbiamo già configurato il primo gruppo. Resta da configurare il secondo gruppo.
Ripetere i passaggi 8-10. Basta impostare i diritti completi del gruppo tstGroup2 sul modulo Contabilità clienti e specificare "T&U" come criterio nell'impostazione RLS per il gruppo tstGroup2.
Per verificare, vai su Axapta sotto l'utente Test e assicurati che i moduli e i report funzionino correttamente, assicurati di aver ricevuto tutti i diritti sui client e di poter modificare i parametri del client.
Cosa succede se un cliente ha un cambio di gruppo? Nel modulo, il client sarà visibile fino a quando non lascia il modulo dello schermo. Non appena Axapta legge nuovamente i dati dal server, RLS funzionerà e il gestore non vedrà più il client "esterno".
Questo esempio mostra ancora una volta che i diritti devono essere configurati in modo complesso. In questa situazione, è possibile impedire ai gestori di modificare il campo Gruppo client o impostare una restrizione a livello di record (RLS) e nella tabella con i gruppi.
Per consentire ad alcuni utenti l'accesso all'intero elenco di client, è necessario assegnare i diritti del terzo gruppo alla tabella dei client, ma non configurare RLS. Axapta esamina i normali permessi. E, se è presente il diritto di accesso, controlla le impostazioni RLS. Se non ci sono impostazioni RLS per questo gruppo e questa tabella, Axapta mostra tutti i record della tabella.
Si noti che il gruppo tstGroup3 non ha influenzato il comportamento di RLS fino a quando non ha avuto diritti sulla tabella dei client. Non appena questo gruppo è diventato idoneo per i clienti, questo gruppo è stato immediatamente coinvolto in RLS. Per verificare questa tesi, rimuovere i diritti sul modulo Contabilità clienti nel gruppo tstGroup2 e verificare l'RLS per il client Test. Vedrai solo altri clienti.
