Conținut TechKnowledge
Sfaturi
și trucuri pentru securitatea Navision.
Configurarea
Securității rezoluție în Navision Financials și Attainis este, de obicei, un domeniu de confuzie. În plus, securitatea în starea sa implicită din baza de date Demonstrație de pe CD trebuie analizată și discutată pentru a vă pregăti complet pentru implementarea securității la un site de firmă. Acest document este menit să acopere unele informații de bază legate de securitate și să ofere informații suplimentare pentru unele dintre problemele comune care au fost raportate.
Noțiuni de bază despre Navision Obțineți sau Navision FinancialsSecurity
1. Securitatea constă din două principale: "ID-uri de utilizator și parole" și "Permisiuni". Acest document se va concentra în principal pe pagina Permisiuni. Pentru o discuție detaliată despre ID-ul de utilizator și Parolă, în special când se referă la versiunea 2.60B și la versiunile mai recente de Windows la autentificare și autentificarea bazei de date, consultați articolul Resurse suplimentare legate la acest articol din Baza de cunoștințe.
2. Permisiunile constau în Roluri (Versiunea 2.60 și versiuni mai recente) sau Grupuri (pre-versiunea 2.60) în baza de date Demonstrație. (În viitor, termenulRolii vor fi folosiți cu sinonime cu Roluri sau Grupuri).
Rolurile sunt constituite dintr-o listă predefinită de tipuri de obiecte, numere și nivel de acces (Citire, Inserare, Modificare, Ștergere, Executare). Fiecare Nivel de acces poate fi setat la "Da", "Indirect" sau "Nu". Dacă este selectat "Da", utilizatorul are direct acel nivel de acces. De exemplu, dacă se introduce "Da" în câmpul Citire pentru obiect, puteți accesa oricând direct și citi informațiile în mod direct. Dacă este selectată "Indirect", permisiunea este validă numai atunci când este utilizată cu un alt obiect pentru care aveți permisiunea. De exemplu, nu puteți crea intrări G/L direct, dar numai "indirect", utilizând funcția de postare. În cazul în care câmpul este necompletat, nu aveți această permisiune.
3. Rolurile De bază se bazează pe Permisiuni la nivel de obiect. Există șapte Tipuri de obiecte care constituie Remiterea: Tabele, Formulare, Rapoarte,Porturi de date, Codeunituri, Sistem și Tabledata. Primele cinci- Tabele, Formulare, Rapoarte, Dataporturi și Codeunituri - sunt Obiectele de bază care formează o bază de date Navision. Includerea acestor Tipuri de obiecte în Permisiuni este destul de evidentă. Însă celelalte două Tipuri de obiecte de securitate sunt mai puțin evidente și vor fi discutate mai detaliat în următoarele două secțiuni.
4. Tip obiect sistem include accesul opțiunii de meniu din Navision Obține sau Financiare, cum ar fi accesul la fișierul | Opțiuni pentru baza de date și opțiunile din lista verticală Instrumente. Permisiunile de sistem vor controla accesul la zonele Dezvoltare de sub Instrumente, presupunând că licența Client oferă acces la zona de dezvoltare.
Notă Dacă clientul nu are licență pentru io, nu va avea acces la acea zonă a sistemului. Licența devine cel mai înalt nivel de control al accesului la anumite zone de Obținere sau Financiare.
În plus, accesul la Navision Security este controlat prin permisiunile de sistem. Meniul vertical Editare, care include accesul la filtrare și la introducerea datelor, este, de asemenea, controlat prin Permisiuni de sistem.
5. Tabledata Object Typeis controlează accesul la informații și date care au fost introduse de utilizatori. Obiectul Tabel furnizează structura pentru stocarea datelor. Tabledata reprezintă informațiile reale plasate în această zonă de stocare. Pentru a vedea datele, utilizatorul trebuie să aibă acces la Tabel și la Tabledata.
Împreună cu Table and Tabledata, un utilizator trebuie, de asemenea, să aibă acces la un formular sau la un raport pentru a vizualiza datele. Cu controlul de supraaccess la date, aveți și control asupra firmelor care pot fi accesate. Acest lucru este controlat în Permisiunile ID-ului de utilizator de sub Roluri.
6. Înainte de a intra prea mult în Permisiuni, trebuie să înțelegeți un loc de bază. Pentru ca un Utilizator să vadă informațiile, Utilizatorul trebuie să aibă un Formular sau un Raport pentru a vizualiza informațiile. Formularele sunt ecranele și meniurile pentru a vizualiza informațiile on-line (cum ar fi o fișă de client sau un meniu de configurare), în timp ce rapoartele sunt imprimate documente. În plus față de obiectele reale utilizate pentru a vizualiza date(adică, formular sau raport), un Utilizator trebuie, de asemenea, să aibă acces la Obiectul Tabel și la un anumit nivel de acces Citire la Tabledata. Dacă lipsește una dintre aceste combinații de tip obiect (adică, Formular/Tabel/TableData sau Raport/Tabel/TableData), atunci un utilizator nu va avea acces la informațiile dorite.
7. În fiecare dintre versiunile de Obținere sau Financiare, primul rol care trebuie stabilit este "SUPER". Cel puțin un ID de utilizator trebuie să aibă acest rol, iar primul utilizator configurat va trebui să aibă atribuit SUPER. La revizuirea permisiunilor rolului SUPER, veți vedea că sunt atribuite toate cele șapte Tipuri de obiecte listate mai sus. Fiecărui tip de obiect i se dă un ID de obiect "0" și un Nivel de acces setate la Da pentru toate tipurile de obiecte. The '0' in the ObjectID fieldrepresents that all objects within that Object Type are assigned. "Da" din nivelul de acces înseamnă că SUPERUSER poate citi, insera, modifica, șterge și executa pe toate obiectele. Prin urmare, atât timp cât obiectul este inclus în licență, utilizatorul va putea accesa în întregime acea zonă.
Pe lângă numărul minim de SUPER Utilizator pe site-ul client, se poate de dorit ca NSC să-și fi configurat firma ca SUPER Utilizator. Acest lucru vă asigură că NSC poate accesa totul din baza de date, în cazul în care utilizatorul SUPER de la site-ul Client pleacă și nu reușește să informeze alte persoane în legătură cu aceste informații. Altfel, ar trebui urmate procedurile de înlocuire pentru a accesa baza de date. TheNavision Break inAuthorizationform is included in all of our manualsor youmay contact Navision Support for the form. Desigur, asigurați-vă că discutați despre configurarea ID și a parolei centrului de soluții de către client, pentru a vă asigura că acordă aprobare în acest sens.
8. Pentru orice utilizator care nu are rolul SUPER, trebuie atribuit rolul ALL. ALLRole are acces de bază la obiecte pe care fiecare utilizator trebuie să le aibă. Un anumit nivel de acces Citire la tabelele și datele de configurare și la alte zone de sistem sunt necesare pentru fiecare utilizator Navision, astfel că ALLRole este menit să furnizeze acest acces de bază. Cu toate acestea, vor exista unele modificări care pot trebui efectuate la ALLRole înainte de a aplica complet acel rol tuturor. Mai exact, ALLRole are o linie stabilită pentru "Form 0" cu drepturile Execute setate la Yes.
Problema este că, în combinație cu alte roluri care acordă drepturi tranzacțiilor POST, cum ar fi "R-Q/O/I/C, POST" și "P-Q/O/I/C, POST", va exista un semn semnificativ în securitate pentru unii Clienți. În special, aceste roluri "POST" necesită o linie pentru TableData Object ID 17, care este tabelul de intrare G/L și Acces de citire setate la "DA". Acest acces de permisiune, în combinație cu linia ALL Role din Formular 0 și Tabel 0, îi oferă acestui utilizator acces complet pentru a revizui tabelul de intrare G/L și a vedea tranzacțiile Registru general pe ecran, în special tranzacțiile detaliate de venituri și cheltuieli. Acest lucru poate fi nedorit pentru unii clienți și va trebui să fie rezolvat prin intermediul unor soluții furnizate mai jos.
Pentru a vă ocupa de problema accesului la intrarea G/L, puteți face unul dintre aceste două lucruri. Mai întâi, poate fi necesar să creați un nou rol "ALL" numit "ALL-NOFORMS". Apoi veți utiliza funcția Windows copiere și veți copia liniile Permisiuni din rolul "ALL"și le veți lipi în rolul "ALL-NOFORMS". Apoi veți șterge linia pentru Formularul 0 - Execută "Da" din ALL-NOFORMS. Apoi veți crea roluri noi pentru fiecare zonă funcțională care oferă permisiunile necesare pentru Formularele individuale necesare pentru acea Zonă funcțională.
A doua modificare pe care se poate să o ia în considerare utilizatorul este modificarea Permisiunilor Codeunit 12 legate de citirea tabelului de intrare G/L. Pentru a face acest lucru, veți face:
Instrumentele A.Access | Object Designer.
B.Selectați Codeunit 12.
C. Selectați butonul Proiectare.
D. Selectați pictograma Proprietăți.
E. Faceți clic în câmpul Valoare din linia Permisiuni.
F. Selectați butonul puncte de suspensie (...).
G. Pe linia pentru ID obiect 17, bifați caseta "Permisiune de citire".
După ce aceasta este finalizată, un utilizator poate să selecteze oricare dintre rolurile de "POST" listate mai sus și să modifice opțiunea "Da" din Permisiune de citire pentru datele din tabelul 17 - Intrare G/L - la "Indirect". Prin finalizarea acestei modificări, unui utilizator i se va permite să posteze o factură și să aibă procesul de postare să creeze noua intrare în tabelul de introducere a registrului general. Cu toate acestea, prin modificarea permisiunii de citire la Indirect, utilizatorul nu va avea acces la tabelul de intrare registru general dintr-o detaliare din câmpul Diagram of Accounts Net Change (Modificare netă a diagramei conturilor). Rețineți că a doua modificare va funcționa doar pentru opțiunea Nativă, nu și pentru SQL Server opțiune.
Resurse suplimentare
1. Consultați Informații suplimentare pentru Ajutor pentru documentele #12462 - Sfaturi și trucuri pentru securitatea Sfaturi navision. Pentru a descărca acest document, vizitați următorul site Web Microsoft:
https://mbs.microsoft.com/downloads/customer/tk28331.doc 2. Consultați articolul 858242- NF 2.60 și autentificarea Windows bază de cunoștințe pe SQL Server Bază de cunoștințe.
3. Consultați articolul 874362 din Baza de cunoștințe - Cum se setează securitatea pentru salarii
4. Consultați articolul
858244din Baza de cunoștințe - Diferența dintre ID-ul de utilizator și parole și Permisiunile de utilizator în Microsoft Dynamics NAV
5. Consultați articolul 858921din Baza de cunoștințe - Windows de conectare cu financiare 2.60.
Acest articol a fost TechKnowledge Document ID:28331
