Restriktioner för åtkomst till data i roller 1s. Åtkomsträttigheter till SCP. RLS. Allmän information och inställningar. Begränsa åtkomsten på rekordnivå

Alla användarrättighetsinställningar som vi kommer att göra inom ramen för denna artikel finns i avsnitt 1C 8.3 "Administration" - "Användar- och rättighetersinställningar". Denna algoritm är liknande i de flesta konfigurationer på hanterade formulär. 1C Accounting-programmet kommer att användas som exempel, men att sätta upp rättigheter i andra program (1C UT 11, 1C ZUP 3, 1C ERP) görs på exakt samma sätt.

Låt oss gå till avsnittet "Användare" i inställningsfönstret. Här ser vi två hyperlänkar: "Användare" och "Inloggningsinställningar". Den första av dem låter dig gå direkt till listan över användare av denna infobas. Innan du skapar en ny användare, överväg de möjliga inloggningsinställningarna (hyperlänk till höger).

I det här inställningsformuläret kan du ställa in lösenordets komplexitet (minst 7 tecken, obligatoriskt innehåll av olika typer av tecken, etc.). Här kan du också ange lösenordets längd, dess giltighetstid och förbud mot åtkomst till programmet för användare som inte har haft aktivitet under en viss tid.

Nu kan du gå direkt till att lägga till en ny användare i 1C. Du kan göra detta genom att klicka på knappen "Skapa", som visas i bilden nedan.

Först och främst anger vi det fullständiga namnet - "Antonov Dmitry Petrovich", och väljer en person från motsvarande katalog. Här kan du även ange på vilken avdelning vår medarbetare arbetar.

Inloggningsnamnet "AntonovDP" ersattes automatiskt som en förkortning för det fullständiga namnet "Antonov Dmitry Petrovich". Ställ in ett lösenord och autentisering för 1C Enterprise. Här kan du också ange om denna användare får ändra lösenordet på egen hand.

Anta att vi vill att Dmitry Petrovich Antonov ska vara tillgänglig i urvalslistan när vi startar denna infobas. För att göra detta måste du ställa in flaggan på objektet "Visa i urvalslistan". Som ett resultat kommer auktoriseringsfönstret vid start av programmet att se ut som det som visas i figuren nedan.

Låt oss vara uppmärksamma på en annan viktig inställning i användarguidekortet - "Logga in på programmet är tillåtet." Om fördröjningen inte är inställd kommer användaren helt enkelt inte att kunna gå in i denna infobas.

Åtkomsträttigheter

Efter att ha fyllt i alla uppgifter på användarkortet - Antonov Dmitry Petrovich, kommer vi att skriva ner dem och fortsätta med att ställa in åtkomsträttigheter, som visas i bilden nedan.

Innan oss öppnade en lista över tidigare inmatade programåtkomstprofiler. Markera rutorna som krävs.

Få åtkomst till gruppprofiler

Åtkomstgruppsprofiler kan konfigureras från huvudformuläret för att ställa in användare och rättigheter. Gå till avsnittet "Åtkomstgrupper" och klicka på hyperlänken "Åtkomstgruppsprofiler".

Låt oss skapa en ny grupp från det öppnade listformuläret. I tabellsektionen på fliken "Tillåtna åtgärder (roller)" är det nödvändigt att markera rutorna för de roller som kommer att påverka åtkomsträttigheterna för användare som ingår i gruppen vi skapar. Alla dessa roller skapas och konfigureras i konfiguratorn. De kan inte ändras eller skapas från användarläge. Du kan bara välja från en befintlig lista.

RLS: Record Level Access Restriction

Ger dig möjlighet att mer flexibelt konfigurera åtkomst till programdata i vissa avsnitt. För att aktivera det, ställ in flaggan på objektet med samma namn i formuläret för användar- och rättigheterinställningar.

Observera att aktivering av denna inställning kan påverka systemets prestanda negativt. Poängen är att RLS-mekanismen ändrar alla förfrågningar beroende på de uppsatta begränsningarna.

Låt oss gå till "Testgrupp"-åtkomstgruppsprofilen som vi skapade tidigare. Bilden nedan visar att efter att ha aktiverat åtkomstbegränsningen på postnivå, dök ytterligare en flik "Åtkomstbegränsningar" upp.

Låt oss anta att vi vill att användarna som testgruppen är tilldelad ska ha tillgång till data för alla organisationer i denna infobas, förutom de som anges i profilen.

I den övre tabelldelen ställer du in åtkomstbegränsningen efter organisation. I den nedre delen kommer vi att förtydliga att åtkomst inte kommer att ges till data (dokument, kataloger, etc.) för Roga LLC-organisationen.

Ofta finns det ett behov av att delvis begränsa åtkomsten till data. Till exempel när en användare behöver se dokument endast för sin organisation. I sådana fall använder 1C en mekanism för åtkomstbegränsning på rekordnivå (den så kallade RLS - Record Level Securiy).

Anta till exempel att vi står inför följande uppgift. Företaget upprätthåller flera företagsredovisningar och varje motpart och databasanvändare tillhör en specifik organisation. Det är nödvändigt att ge åtkomst till katalogen "Contractors" på ett sådant sätt att varje användare endast kan se, redigera och lägga till motparter till sin organisation.

För att lösa problemet kommer vi att använda plattformen "1C:Enterprise 8.2". Låt oss skapa en ny konfiguration i vars egenskaper alternativet "Managed application" kommer att väljas som huvudstartläge.

Därefter kommer vi att skapa katalogen "Organisationer" och ytterligare två kataloger - "Entreprenörer" och "Användare" med attributet "Organisation". Förutom kataloger behöver vi två sessionsparametrar - "Organisation" och "Användare" (av lämplig typ). Värdena för dessa parametrar ställs in i början av en konfigurationssession och lagras tills den slutar. Det är värdena för dessa parametrar som vi kommer att använda när vi lägger till villkor för åtkomstbegränsning på rekordnivå.

Sessionsparametrar ställs in i en speciell modul - "Sessionsmodul"

I denna modul beskriver vi den fördefinierade proceduren "SetSessionParameters" där vi kallar funktionen för den förberedda allmänna modulen "FullPermissions". Detta är nödvändigt på grund av särdragen i databasoperationen i det hanterade applikationsläget, när en del av programkoden endast kan köras på serversidan (jag kommer inte att uppehålla mig vid att förklara dessa principer i den här artikeln).

Kod 1C v 8.x Procedurinställning av sessionsparametrar (obligatoriska parametrar)
FullPermissions.SetSessionParameters();
Slutprocedur

I egenskaperna för "FullPermissions"-modulen, markera rutorna "Server", "Serveranrop" och "Privileged" (det senare betyder att procedurerna och funktionerna för denna modul kommer att exekveras utan åtkomstkontroll). Texten i modulen kommer att se ut så här:

Kod 1C v 8.x Funktion DetermineCurrentUser()
CurrentUser = Directories.Users.FindByName(UserName(), True);
Returnera CurrentUser;
EndFunctions

Procedur SetSessionParameters() Export
CurrentUser = Bestäm CurrentUser();
CurrentOrganization = Directories.Organizations.EmptyReference();
Om ValueFilled(CurrentUser) Då
CurrentOrganization = CurrentUser.Organization;
EndIf;
SessionParameters.User = CurrentUser;
SessionParameters.Organization = CurrentOrganization;
Slutprocedur

FunctionSessionParameterSet(ParameterName) Export
Return ValueFilled(SessionParameters[ParameterName]);
EndFunctions

Funktion RoleAvailableToUser(RoleName) Export
Return RoleAvailable(RoleName);
EndFunctions

I den hanterade applikationsmodulen kommer vi att kontrollera om det finns en konfigurationsanvändare i katalogen "Användare" (för enkelhetens skull söker vi efter den med namn) och stänger av systemet om det inte hittas. Detta är nödvändigt för att säkerställa att sessionsparametrarna är ifyllda.

Kod 1C v 8.x Driftsprocedur före systemet (fel)
// alla utom administratören kommer att kontrolleras för närvaro i katalogen "Användare".
Om inte FullPermissions.RoleAvailableToUser("FullPermissions") då
Om INTE FullPermissions.SessionParameterSet("Användare") Då
Warning("Användare """ + Användarnamn() + """ hittades inte i katalogen!");
Avslag = sant;
Lämna tillbaka;
EndIf;
EndIf;
Slutprocedur

Nu kan vi gå direkt till beskrivningen av åtkomstbegränsningar. För att göra detta, skapa rollen "Användare" och gå till fliken "Begränsningsmallar", där vi lägger till en ny mall "AccountsReadingChange" med följande malltext: WHERE Organisation = Organisation #Parameter(1)

Begränsningsmalltext är en förlängning av frågespråket. Till skillnad från en vanlig begäran måste begränsningstexten nödvändigtvis innehålla "WHERE"-satsen. Som värdena för frågeparametrarna (i vårt fall är det "&Organisation"), används värdena för sessionsparametrarna med samma namn. En konstruktion av formen #Parameter(1) innebär att systemet kommer att ersätta den text som skickas som den första parametern på den plats där mallen används på denna plats. Med hjälp av den givna mallen kommer varje post i tabellen att kontrolleras (i vårt fall kommer det att vara "Contractors"-uppslagningen). För poster vars "Organisation"-attributvärde matchar det som anges i motsvarande sessionsparameter, kommer villkoret som beskrivs i mallen att vara uppfyllt. Således kommer dessa poster att vara tillgängliga för läsning, redigering eller tillägg (beroende på vilken av dessa rättigheter mallen gäller). Jag kommer att demonstrera ovanstående med vårt exempel.

Låt oss gå till fliken "Rättigheter" i rollen "Användare" och öppna listan med rättigheter i katalogen "Konton". Vi kommer att använda begränsningsmallen "AccountsReadChange" för behörigheterna "Läs", "Ändra" och "Lägg till".

För "Läs"-rätten kommer vi att använda en mall med parametern "OR ThisGroup". Samtidigt kommer användare av denna roll att tillåtas att läsa inte bara elementen i katalogen "Konton" i deras organisation, utan också alla grupper i denna katalog.

#AccountsReadingChange("ELLER denna grupp")

Eftersom när man lägger till nya element i katalogen utför systemet en implicit läsning av fördefinierade attribut (detta är nödvändigt, till exempel för numrering), är det nödvändigt att säkerställa obehindrad läsning av dessa fält. För att göra detta, lägg till ytterligare en rad med en tom begränsningstext i tabellen för dataåtkomstbegränsning och lista de fält som denna regel gäller - Länk, Dataversion, Förälder, Kod.

Därmed är uppgiften att begränsa åtkomsten på rekordnivå löst. Användare med befintliga begränsningar har endast åtkomst till att visa och redigera data för sin organisation.

1C:Enterprise 8-plattformen har en inbyggd mekanism för att begränsa åtkomst till data på rekordnivå. Du kan läsa allmän information om det här. Kort sagt, RLS tillåter dig att begränsa åtkomsten till data enligt vissa villkor på fältvärden. Du kan till exempel begränsa användarnas åtkomst till dokument beroende på värdet på attributet "Organisation". Vissa användare kommer att arbeta med dokument för "Management Company"-organisationen, och resten med "Dairy Plant"-organisationen. Som ett exempel.

Förberedelse

Exemplet är implementerat i demonstrationskonfigurationen av SCP 1.3. Låt oss skapa en "Storekeeper"-användare och lägga till "Storekeeper"-rollen med samma namn till den.

Låt oss nu gå direkt vidare till att ställa in åtkomsträttigheter på rekordnivå. Låt oss byta till gränssnittet "Användaradministration". I huvudmenyn väljer du "Åtkomst på postnivå -> Alternativ". Här markerar vi rutan "Begränsa åtkomsten på postnivå efter typer av objekt", och i listan över objekt väljer vi "Organisationer".

Därför har vi möjliggjort användningen av RLS. Nu måste du ställa in den.

Åtkomstkontroll på rekordnivå konfigureras inte separat för varje användar- eller behörighetsprofil. RLS är konfigurerat för användargrupper. Låt oss lägga till en ny användargrupp, låt oss kalla den "Storekeepers"

Gruppens sammansättning till höger i formuläret visar en lista över användare som tillhör denna grupp. Låt oss lägga till användaren vi skapade tidigare. Till vänster finns en tabell med åtkomstbegränsningar. I RLS-inställningen har vi valt att åtkomsten endast ska begränsas av organisationer, så vi ser bara en typ av åtkomstobjekt. Klicka på knappen "Åtkomstinställningar". Behandlingen för att ställa in behörigheter för den aktuella gruppen öppnas.

I listan över åtkomstobjekt för gruppen, lägg till organisationen "PPE "Entrepreneur"". Vi lämnar typen av arv av rättigheter oförändrad. Rätten till åtkomstobjektet kommer att ställas in på att läsa och skriva. Klicka på "OK", inställningarna är klara. Vi har precis satt upp RLS på organisationsnivå.

Vad användaren ser

Kör programmet under den tidigare skapade användaren och öppna katalogen "Organisationer". Så här kommer listan att se ut för vår användare och för en användare med fullständiga rättigheter:

Som vi kan se ser lagerhållaren endast en organisation som vi har öppnat läsbehörighet för. Detsamma gäller handlingar, som mottagningar av varor och tjänster.

Således kommer användaren inte bara att inte se organisationer, till vilka åtkomst inte är inställd för honom, men kommer inte heller att kunna läsa / skriva dokument och andra objekt i infobasen, för vilka rättigheterna i rollen på attributet "Organisation " är inställda.

Vi har övervägt det enklaste exemplet på att ställa in RLS. I nästa artikel kommer vi att prata om implementeringen av RLS-mekanismen i "Manufacturing Enterprise Management" version 1.3-konfigurationen.

1C har ett inbyggt åtkomsträttssystem (det här systemet kallas 1C-roller). Detta system är statiskt - eftersom administratören har ställt in rättigheterna till 1C, så var det.

Dessutom finns det ett dynamiskt system med åtkomsträttigheter (kallat - RLS 1C). I den beräknas 1C-rättigheter dynamiskt vid tidpunkten för användarens arbete baserat på de angivna parametrarna.

En av de vanligaste säkerhetsinställningarna i olika program är en uppsättning läs-/skrivbehörigheter för användargrupper och sedan - inkludering eller uteslutning av en användare från grupper. Till exempel används ett liknande system i Windows AD (Active Directory).

Ett sådant säkerhetssystem i 1C kallas Roll 1C. Roller 1C finns i konfigurationen i grenen Allmänt / Roller. 1C-roller fungerar som grupper för vilka 1C-rättigheter tilldelas. Därefter inkluderas eller exkluderas användaren från denna grupp.

Genom att dubbelklicka på namnet på 1C-rollen öppnar du rättighetsredigeraren för 1C-rollen. Till vänster finns en lista över 1C-objekt. Välj någon och alternativ för åtkomsträttigheter kommer att visas till höger (minst: läs, lägg till, ändra, radera).

För den översta grenen (namnet på den aktuella konfigurationen) ställs 1C-administratörsrättigheter och åtkomst till att starta olika alternativ in.

Alla 1C-rättigheter är uppdelade i två grupper - "enkel" höger och samma rätt med tillägg av "interaktiv". Vad betyder det?

När en användare öppnar ett formulär (till exempel bearbetning) och trycker på en knapp på det, utför programmet på det inbyggda 1C-språket vissa åtgärder, till exempel att ta bort dokument. För tillåtelse av dessa åtgärder (utförs programmatiskt) - "helt enkelt" är rättigheterna för 1C ansvariga.

När en användare öppnar en journal och börjar göra något från tangentbordet på egen hand (till exempel skriva in nya dokument), är dessa "interaktiva" 1C-rättigheter.

En användare kan ha flera tillgängliga roller, i vilket fall behörigheterna läggs ihop.

Avsnittet om möjligheterna att sätta åtkomsträttigheter med hjälp av roller är ett 1C-objekt. Det vill säga, du kan antingen aktivera åtkomst till katalogen eller inaktivera den. Går inte att slå på ett dugg.

För detta finns en utökning av 1C rollsystemet som kallas 1C RLS. Detta är ett dynamiskt system med åtkomsträttigheter som tillåter dig att delvis begränsa åtkomsten. Användaren ser till exempel bara dokument för ett visst lager och organisation och ser inte resten.

Försiktigt! När du använder det förvirrande RLS 1C-schemat kan olika användare ha frågor när de försöker verifiera samma rapport som genereras från olika användare.

Du tar en viss katalog (t.ex. organisationer) och en viss rättighet (t.ex. läsning). Du tillåter läsning för 1C-rollen. I panelen Dataåtkomstbegränsning ställer du in frågetexten, som returnerar TRUE eller FALSE beroende på inställningarna. Inställningarna lagras vanligtvis i informationsregistret (till exempel konAccounting UserAccessRightsSettingsUsers).

Denna begäran exekveras dynamiskt (när man försöker implementera läsning), för varje katalogpost. Således, för de poster för vilka säkerhetsfrågan returnerade TRUE, kommer användaren att se den, men resten inte.
1C-rättigheter som är föremål för RLS 1C-begränsningar är markerade i grått.

Kopiering av samma RLS 1C-inställningar görs med hjälp av mallar. Du gör en mall, namnger den (till exempel) MyTemplate, anger en säkerhetsförfrågan i den. Därefter, i inställningarna för 1C-åtkomsträttigheter, ange mallens namn så här: "#MyTemplate".

När en användare arbetar i 1C Enterprise-läge, när RLS 1C körs, kan han få ett felmeddelande "Otillräckliga rättigheter" (till exempel för att läsa Xxx-katalogen).

Detta innebär att RLS 1C blockerade läsningen av flera poster.

För att förhindra att ett sådant meddelande visas är det nödvändigt att använda ordet TILLÅT () i texten i begäran på det inbyggda 1C-språket.

Till exempel:

1C-programmet har ett inbyggt system med åtkomsträttigheter, som finns i Konfiguratorn - Allmänt - Roller.

Vad kännetecknar detta system och vad är dess huvudsakliga syfte? Den låter dig beskriva uppsättningar av rättigheter som motsvarar användarnas positioner eller deras aktiviteter. Detta system med åtkomsträttigheter är statiskt till sin natur, vilket innebär att det är det, eftersom administratören ställt in åtkomsträttigheterna till 1C. Förutom den statiska finns det ett andra system med åtkomsträttigheter - dynamiskt (RLS). I detta system beräknas åtkomsträttigheterna på ett dynamiskt sätt, beroende på de givna parametrarna, under arbetets gång.

Roller i 1C

De vanligaste säkerhetsinställningarna i olika program är den så kallade uppsättningen av läs-/skrivbehörigheter för olika användargrupper och i framtiden: inkludering eller uteslutning av en specifik användare från grupper. Ett sådant system används till exempel i operativsystemet Windows AD (Active Directory). Säkerhetssystemet som används i 1C-programvara kallas roller. Vad det är? Roller i 1C är ett objekt som finns i konfigurationen i grenen: Allmänt - Roller. Dessa 1C-roller är grupper för vilka rättigheter tilldelas. I framtiden kan varje användare inkluderas och exkluderas från denna grupp.

Genom att dubbelklicka på rollens namn öppnar du rättighetsredigeraren för rollen. Till vänster finns en lista med objekt, markera något av dem och till höger ser du alternativ för möjliga åtkomsträttigheter:

— läsning: hämta poster eller deras partiella fragment från en databastabell;
- lägga till: nya register samtidigt som befintliga bevaras;
— ändra: göra ändringar i befintliga register;
- radering: vissa poster, resten oförändrade.

Observera att alla åtkomsträttigheter kan delas in i två huvudgrupper - detta är en "enkel" rättighet och en sådan rättighet med tillägg av den "interaktiva" egenskapen. Vad menas här? Och saken är följande.

I fallet när användaren öppnar någon form, till exempel bearbetning, och samtidigt klickar på den med musen, börjar programmet på det inbyggda 1C-språket att utföra specifika åtgärder, till exempel att ta bort dokument. För tillåtelse av sådana åtgärder som utförs av programmet, är rättigheterna för 1C ansvariga respektive "helt enkelt".

I händelse av att användaren öppnar journalen och börjar skriva in något på egen hand från tangentbordet (nya dokument, till exempel), är "interaktiva" 1C-rättigheter ansvariga för att tillåta sådana åtgärder. Varje användare kan ha flera roller tillgängliga samtidigt, sedan läggs behörigheten till.

RLS i 1C

Du kan aktivera åtkomst till katalogen (eller dokumentet) eller inaktivera den. Du kan inte bara slå på den lite. För detta ändamål finns en viss utvidgning av 1C-rollsystemet, som kallas RLS. Detta är ett dynamiskt åtkomsträttssystem som introducerar partiella åtkomstbegränsningar. Till exempel blir bara dokument från en viss organisation och lager tillgängliga för användarens uppmärksamhet, han ser inte resten.

Man bör komma ihåg att RLS-systemet måste tillämpas mycket noggrant, eftersom det är ganska svårt att förstå dess intrikata system, och olika användare kan ha frågor när de till exempel jämför samma rapport, som genereras från olika användare. Låt oss överväga ett sådant exempel. Du väljer en specifik katalog (till exempel organisationer) och en specifik rättighet (till exempel läsning), det vill säga du tillåter läsning för 1C-rollen. Samtidigt ställer du in förfrågningstexten i fjärrpanelen för dataåtkomstbegränsningar, enligt vilken False eller True ställs in, beroende på inställningarna. Vanligtvis lagras inställningar i ett speciellt informationsregister.

Denna fråga kommer att köras dynamiskt (när ett försök görs att organisera läsning), för alla katalogposter. Det fungerar så här: de poster som säkerhetsbegäran har tilldelats - Visserligen kommer användaren att se, men andra inte. 1C-rättigheter med fastställda begränsningar är markerade i grått.

Operationen att kopiera identiska RLS-inställningar utförs med hjälp av mallar. Till att börja med skapar du en mall som döper den till, till exempel MyTemplate, där du speglar säkerhetsförfrågan. Ange sedan namnet på denna mall i inställningarna för åtkomsträttigheter på det här sättet: "#MyMall".

När en användare arbetar i 1C Enterprise-läge, vid anslutning till RLS, kan ett felmeddelande visas som: "Otillräckliga rättigheter" (för att till exempel läsa XXX-katalogen). Detta indikerar att RLS-systemet har blockerat läsningen av vissa poster. För att förhindra att det här meddelandet visas igen måste du ange ordet TILLÅT i förfrågningstexten.

https://zabor-vam.ru/product/metallicheskie/zabory-iz-profnastila/