TechKendt indhold
Problemtip
og tricks til problemtips til sikkerhed.
Konfiguration
af løsningssikkerhed i financials oghjul er ofte et område af forvirring. Desuden skal sikkerheden i dens standardstatus fra demonstrationsdatabasen på cd'en analyseres og diskuteres for at forberede implementering af sikkerhed fuldt ud på et firmawebsted. Dette dokument er beregnet til at dække nogle grundlæggende oplysninger om sikkerhed og give yderligere oplysninger om nogle af de almindelige problemer, der er blevet rapporteret.
Grundlæggende om ikke-sikrede eller ikke-sikrede finansielle
elementer 1. Sikkerheden består af to primære granules: "Bruger-id'er og adgangskoder" og "Tilladelser". Dette dokument fokuserer primært på granulet Tilladelser. Hvis du vil have en detaljeret beskrivelse af granulet Bruger-id og Adgangskode, især når det relaterer til version 2.60B og nyere Windows problemer med godkendelse og databasegodkendelse, skal du se Yderligere ressourcer, der er knyttet til denne Knowledge Base-artikel.
2. Tilladelses granulet består af Roller (version 2.60 og nyere) eller Grupper (før version 2.60) i demonstrationsdatabasen. (Fremover vil ordetRoles blive brugt synonymt med Roller eller Grupper).
Rollerne består af en foruddefineret liste over objekttyper, tal og adgangsniveau (Læs, Indsæt, Rediger, Slet, Udfør). Hvert Adgangsniveau kan indstilles til "Ja", "Indirekte" eller "Nej". Hvis 'Ja' er valgt, har brugeren direkte adgangsniveauet til dette niveau. Hvis f.eks. 'Ja' er angivet i feltet Læs for objektet, kan du altid få direkte adgang til og Læse oplysningerne direkte. Hvis 'Indirekte' er markeret, er tilladelsen kun gyldig, når den bruges med et andet objekt, du har tilladelse til. Du kan f.eks. ikke oprette G/L-poster direkte, men kun "indirekte" ved hjælp af opslagsfunktionen. Hvis feltet er tomt, har du ikke denne tilladelse.
3. BasePermission-roller er baseret på tilladelser på objektniveau. Der findes syv objekttyper, der udgørPermissionerne: Tabeller, Formularer, Rapporter, Dataporte, Kodeenheder, System og Tabeldata. De første fem – Tabeller, Formularer, Rapporter, Dataporte og Codeunits – er de grundlæggende objekter, der udgør en database af en database af denne grund. Medtagelsen af disse objekttyper i tilladelser er ret indlysende. Men de to andre sikkerhedsobjekttyper er mindre indlysende og gennemgås mere detaljeret i de næste to afsnit.
4. Systemobjekttypen omfatter adgang til menuindstillingen i databasen, der er tilbage, eller økonomiske oplysninger, f.eks. adgang til | Databaseindstillinger og rulleindstillingerne Værktøjer. Systemtilladelser styrer adgangen til udviklingsområder under Værktøjer, hvor det antages, at kundelicensen giver adgang til udviklingsområdet.
Bemærk! Hvis kunden ikke har en licens til en granule, vil de ikke have adgang til dette område af systemet. Licensen bliver det højeste niveau af kontrol med adgang til bestemte områder af opsnive eller finansielle midler.
Desuden kontrolleres adgangen til Security security via systemtilladelserne. Rullemenuen Rediger, som omfatter adgang til filtrering og dataindtastning, styres også via systemtilladelser.
5. Tabeldataobjekttypen styrer adgangen til de oplysninger og data, der er angivet af brugerne. Tabelobjektet er strukturen til lagring af data. Tabeldataene er de faktiske oplysninger, der er placeret i dette lagringsområde. For at kunne se dataene skal brugeren have adgang til tabellen og tabeldataene.
Sammen med tabel- og tabeldataene skal en bruger også have adgang til enten en formular eller en rapport for at kunne se dataene. Med kontrol overadgang til data har du også kontrol over, hvilke firmaer der kan tilgås. Dette styres under Tilladelser for bruger-id'et under Roller.
6. Før du går for langt ind i Tilladelser, skal en grundlæggende forudsætning forstås. For at en bruger kan få vist oplysninger, skal brugeren enten have en formular eller rapport for at få vist oplysninger. Formularer er skærmbilleder og menuer til visning af oplysninger online (f.eks. et kundekort eller en konfigurationsmenu), mens rapporter udskrives dokumenter. Ud over de faktiskeObjects, der bruges til at vise data (dvs. enten formularen eller rapporten), skal en bruger også have adgang til at udføre objektet Tabel og et vist niveau af læseadgang til Tabeldata. Hvis en af disse objekttypekombinationer mangler (dvs. enten Formular/Tabel/Tabeldata eller Rapport/Tabel/Tabel/Tabeldata), vil en bruger ikke have adgang til de ønskede oplysninger.
7. I hver af versionerne af Tilbage eller Finansiel er den første rolle, der skal oprettes, "SUPER". Der skal være tildelt mindst ét bruger-IDmust denne rolle, og den første bruger konfigureret skal tildeles SUPER. Når du gennemgår tilladelserne for SUPER-rolle, kan du se, at alle syv objekttyper, der er angivet ovenfor, tildeles. Hver objekttype får et objekt-id '0', og Adgangsniveau er indstillet til Ja for alle objekttyperne. '0' i feltet Objekt-id angiver, at alle objekter inden for den pågældende objekttype tildeles. 'Ja' i adgangsniveauet betyder, at SUPERUSER kan læse, indsætte, redigere, slette og udføre på alle objekter. Så længe objektet er inkluderet i licensen, vil brugeren derfor kunne få fuld adgang til dette område.
Ud over mindst én SUPER-bruger på klientwebstedet kan det være hensigtsmæssigt, at NSC har konfigureret sit firma som superbruger. Dette sikre, at NSC kan få adgang til alt i databasen, hvis superbrugeren på kundewebstedet forlader webstedet og ikke informerer andre om disse oplysninger. Ellers skal du overskrive procedurer for at få adgang til databasen. TheNavision Break inAuthorizationform er inkluderet i alle vores manualereller dumay kontakte Kundesupport for formularen. Du skal selvfølgelig sørge for at diskutere konfiguration af løsningscenter-id og adgangskode med kunden for at sikre, at kunden giver godkendelse til dette.
8. For alle brugere, der ikke er tildelt SUPER-rollen, bør rollen ALL være tildelt. ALLRole har grundlæggende objektadgang, som hver enkelt bruger skal have. Der kræves en vis grad af læseadgang til konfigurationstabeller og tabeldata og andre systemområder for hver bruger af allRole, så ALLRole er beregnet til at give denne grundlæggende adgang. Der vil dog være nogle ændringer, der skal foretages i ALLRole, før denne rolle anvendes fuldt ud på alle. Især har ALLRole en linje, der er fastlagt til "Formular 0", med Execute-rettigheder angivet til Ja.
Problemet er, at der i kombination med de andre roller, der giver rettigheder til POST-transaktioner, f.eks. "R-Q/O/I/C, POST" og "P-Q/O/I/C, POST", findes en vigtig del af sikkerheden for nogle Kunder. Især ud af boksen kræver disse "POST"-roller en linje for TableData-objekt-id 17, som er G/L-posttabellen, og Læseadgang indstillet til 'JA'. Denne adgangstilladelse giver, i kombination med linjen ALLE roller i formular 0 og tabel 0, denne bruger fuld adgang til at gennemgå tabellen G/L Entry og se General Ledger-transaktioner på skærmen, især detaljerede indtægts- og udgiftstransaktioner. Dette kan være i uønsket form for nogle kunder og skal behandles via nogle løsninger, der er angivet nedenfor.
For at løse problemet med adgang til en G/L-post kan du gøre en af to ting. Først skal du muligvis oprette en ny "ALLE"-rolle kaldet "ALL-NOFORMS". Du skal derefter bruge funktionen Windows kopiér og kopiere linjerne Tilladelser fra "ALLE"-rollen og indsætte dem i rollen "ALL-NOFORMS". Du kan derefter slette linjen for Formular 0 – Udfør 'Ja' fra ALL-NOFORMS. Derefter skal du oprette nye Roller for hvert funktionelle område, der giver de nødvendige tilladelser til de enkelte formularer, der kræves til det pågældende funktionsområde.
Den anden ændring, som brugeren kan overveje, er at ændre Codeunit 12-tilladelser, der er relateret til at læse posttabellen G/L. For at gøre dette skal du:
A.Access-værktøjer | Objektdesigner.
B.Select Codeunit 12.
C. Vælg knappen Design.
D. Vælg ikonet Egenskaber.
E. Klik i feltet Værdi på linjen Tilladelser.
F. Vælg ellipseknappen (...).
G. Markér feltet "Læsetilladelse" på linjen for Objekt-id 17.
Når dette er fuldført, kan en bruger vælge en af de "POST"-roller, der er angivet ovenfor, og ændre indstillingen "Ja" i Læsetilladelse til tabel 17 – G/L Indtastning af tabeldata – til "indirekte". Ved at fuldføre denne ændring har en bruger tilladelse til at sende en faktura og få opslagsprocessen til at oprette den nye post i tabellen Hovedbog. Men ved at ændre Læsetilladelse til Indirekte vil brugeren ikke have adgang til tabellen Generelt hovedbog fra en analyse ned i Diagrammet over konti Net Change-feltet. Bemærk, at den anden ændring kun virker på indstillingen Oprindelig og ikke på SQL Server Indstillinger.
Yderligere ressourcer
1. Se Supplerende oplysninger om Hjælp-#12462 - security Tips og tricks. Hvis du vil hente dette dokument, skal du besøge følgende Microsoft-websted:
https://mbs.microsoft.com/downloads/customer/tk28331.doc 2. Se Knowledge Base-artikel 858242– NF 2.60, og Windows på SQL Server-indstillingen.
3. Se Knowledge Base-artikel 874362 – Sådan konfigurerer du lønsikkerhed
4. Se videnbaseartikel
858244– forskellen mellem granulet Bruger-id og Adgangskoder og granulet Brugertilladelser i Microsoft Dynamics NAV
5. Se Knowledge Base-artikel 858921– Windows logon med Financials 2,60.
Denne artikel var TechKendt dokument-id:28331
