1c bruker ib tilsvarer mer enn ett element. IB ledelse

Informasjonssikkerhet, i likhet med informasjonsbeskyttelse, er en kompleks oppgave rettet mot å sikre sikkerhet, implementert ved implementering av et sikkerhetssystem. Problemet med informasjonssikkerhet er mangefasettert og komplekst og dekker en rekke viktige oppgaver.

Informasjonssikkerhetsproblemer forverres stadig av inntrengningen av tekniske midler for databehandling og overføring til alle samfunnssfærer. Dette problemet er spesielt akutt innen finansielle regnskapssystemer. Det mest populære regnskaps-, salgs- og CRM-prosesssystemet i Russland er 1C Enterprise-systemet.

La oss vurdere potensielle sikkerhetstrusler når du bruker 1C-programmet.

	Bruker 1C med databaser i filformat. 1C-fildatabaser er de mest sårbare for fysisk påvirkning. Dette skyldes de arkitektoniske egenskapene til denne typen database - behovet for å holde alle konfigurasjonsfiler og selve fildatabasene åpne (med full tilgang) for alle brukere av operativsystemet. Som et resultat kan enhver bruker som har rett til å arbeide i en 1C-fildatabase teoretisk kopiere eller til og med slette en 1C-informasjonsdatabase med to museklikk.
	Bruker 1C med databaser i DBMS-format. Denne typen problemer oppstår hvis en DBMS (PosgreSQL, MS SQL) brukes som lagring for 1C-databaser, og en enterprise 1C-server brukes som en mellomliggende kommunikasjonstjeneste mellom 1C og DBMS. Dette er et eksempel - mange selskaper øver på å modifisere 1C-konfigurasjoner for å passe deres behov. I prosessen med foredling, under betingelsene for prosjekt "oppstyr", konstant testing av ny, forbedret funksjonalitet, forsømmer ansvarlige spesialister ofte reglene for nettverkssikkerhet. Som et resultat kan enkelte personer som har direkte tilgang til DBMS-databasen eller har administratorrettigheter på 1C Enterprise-serveren, selv for en midlertidig testperiode, enten lage en sikkerhetskopi til eksterne ressurser eller fullstendig slette databasen i DBMS.
	Åpenhet og tilgjengelighet av serverutstyr. Dersom det er uautorisert tilgang til serverutstyr, kan selskapets ansatte eller tredjeparter bruke denne tilgangen til å stjele eller skade informasjon. Enkelt sagt, hvis en angriper får direkte tilgang til kroppen og konsollen til en 1c-server, utvides rekkevidden av hans evner tidoblet.
	Risiko for tyveri og lekkasje av personopplysninger. Her forstås aktuelle trusler mot sikkerheten til personopplysninger som et sett av forhold og faktorer som skaper den aktuelle faren for uautorisert, inkludert utilsiktet, tilgang til personopplysninger under deres behandling i et informasjonssystem, for eksempel av ansvarlige ansatte, PC operatører, regnskapsavdelinger, etc. Dette kan resultere i ødeleggelse, modifikasjon, blokkering, kopiering, levering, distribusjon av personopplysninger, samt andre ulovlige handlinger fra ansvarlige personer.
	Nettverksikkerhet. Et bedriftsinformasjonssystem bygget i strid med GOST, sikkerhetskrav, anbefalinger eller mangelfull IT-støtte er fylt med hull, virus og spionprogrammer, og mange bakdører (uautorisert tilgang til det interne nettverket), som direkte påvirker sikkerheten til bedriftsdata i 1C. Dette fører til enkel tilgang for en angriper til kommersielt sensitiv informasjon. For eksempel kan en angriper bruke gratis tilgang til sikkerhetskopier og fravær av passord for arkiver med sikkerhetskopier for personlig vinning. For ikke å nevne den elementære skaden på 1C-databasen ved viral aktivitet.
	Forholdet mellom 1C og eksterne objekter. En annen potensiell trussel er behovet (og noen ganger en spesiell markedsføringsfunksjon) til 1C-regnskapsdatabasen for å kommunisere med "verden utenfor." Opp-/nedlastinger av kundebanker, informasjonsutveksling med filialer, regelmessig synkronisering med bedriftens nettsider, portaler, andre rapporteringsprogrammer, kunde- og salgsstyring og mye mer. Siden det i dette området av 1C ikke oppmuntres til overholdelse av sikkerhetsstandarder og ensartet utveksling av nettverksinformasjon, er en lekkasje ganske reell når som helst langs ruten. Som et resultat av behovet for ikke-standard forbedringer av prosessautomatisering eller budsjettkutt for nødvendige tiltak for å beskytte trafikk, øker antallet sårbarheter, hull, usikre tilkoblinger, åpne porter, lett tilgjengelige utvekslingsfiler i ukryptert form, etc. øyeblikkelig. i regnskapssystemet. Du kan trygt forestille deg hva dette kan føre til - fra elementær deaktivering av 1C-databasen i en viss tid, til forfalskning av en betalingsordre på flere millioner.

Hva kan foreslås for å løse slike problemer?

1. Når du arbeider med 1C-fildatabaser Det er viktig å implementere en rekke tiltak for å sikre sikkerheten til basene:

Ved å bruke NTFS-tilgangsbegrensninger, gi de nødvendige rettighetene bare til de brukerne som jobber med denne databasen, og beskytter dermed databasen mot tyveri eller skade fra skruppelløse ansatte eller en angriper;
Bruk alltid Windows-autorisasjon for å logge på brukerarbeidsstasjoner og få tilgang til nettverksressurser;
Bruk krypterte disker eller krypterte mapper som lar deg lagre konfidensiell informasjon selv om du fjerner 1C-databasen;
Etablere en policy for automatisk skjermlåsing, samt gi brukeropplæring for å forklare behovet for profillåsing;
Differensiering av tilgangsrettigheter på 1C-nivå vil tillate brukere å bare få tilgang til informasjonen de har de nødvendige rettighetene til;
Det er nødvendig å tillate lansering av 1C-konfiguratoren bare for de ansatte som trenger det.

2. Når du arbeider med DBMS 1C-databaser Vær oppmerksom på følgende anbefalinger:

Legitimasjon for å koble til DBMS skal ikke ha administrative rettigheter;
Det er nødvendig å differensiere tilgangsrettigheter til DBMS-databaser, for eksempel opprette din egen konto for hver informasjonsbase, noe som vil minimere tap av data hvis en av kontoene blir hacket;
Det anbefales å begrense fysisk og ekstern tilgang til bedriftsdatabase og 1C-servere;
Det anbefales å bruke kryptering for databaser dette vil lagre konfidensielle data selv om en angriper får fysisk tilgang til DBMS-filene;
En av de viktige avgjørelsene er også å kryptere eller angi et passord for sikkerhetskopiering av data;
Det er obligatorisk å opprette administratorer for 1C-klyngen, så vel som 1C-serveren, siden som standard, hvis ingen brukere opprettes, har absolutt alle brukere av systemet full tilgang til informasjonsbasene.

3. Krav for å sikre den fysiske sikkerheten til serverutstyr:
(ifølge GOST R ISO/IEC TO – 13335)

Tilgang til områder hvor sensitiv informasjon behandles eller lagres må kontrolleres og begrenses til kun autoriserte personer;
Autentiseringskontroller, for eksempel et adgangskontrollkort pluss et personlig identifikasjonsnummer , må brukes til å autorisere og bekrefte all tilgang;
Et revisjonsspor for all tilgang må oppbevares på et sikkert sted;
Tredjeparts støttepersonell bør kun gis begrenset tilgang til sikkerhetsområder eller sensitiv innår det er nødvendig;
denne tilgangen må være autorisert og overvåket til enhver tid;
Adgangsrettigheter til sikkerhetsområder bør jevnlig gjennomgås og oppdateres, og oppheves om nødvendig;
Relevante sikkerhets- og helseforskrifter og standarder må tas i betraktning;
Nøkkelanlegg bør plasseres slik at det hindres tilgang til dem for allmennheten;
Hvor det er aktuelt, bør bygninger og rom være upretensiøse og gi minimal indikasjon på formålet, uten fremtredende skilting, utenfor eller inne i bygningen, som indikerer tilstedeværelsen aver;
Skilt og interne telefonbøker som angir plasseringen av sensitiv informasjonsbehandlingsanlegg skal ikke være lett tilgjengelig for allmennheten.

4. Konfidensialitet av personopplysninger. Hovedmålet med å organisere beskyttelsen av personopplysninger er å nøytralisere aktuelle trusler i informasjonssystemet, definert Føderal lov av 27. juli 2006 nr. 152-FZ "Om personopplysninger" , en liste over statlige standarder og krav til internasjonale IT-sikkerhetssertifiseringer (GOST R ISO/IEC 13335 2-5, ISO 27001) . Dette oppnås ved å begrense tilgangen til informasjon etter dens typer, avgrense tilgangen til informasjon etter brukerroller, strukturere prosessen med å behandle og lagre informasjon.
Her er noen hovedpunkter:

Behandlingen av personopplysninger må begrenses til å oppnå spesifikke, forhåndsdefinerte og legitime formål;
Samtykke til behandling av personopplysninger må være spesifikt, informert og bevisst;
Behandling av personopplysninger som er uforenlig med formålet med å samle inn personopplysninger er ikke tillatt;
Bare personopplysninger som oppfyller formålene med behandlingen deres er gjenstand for behandling;
Operatører og andre personer som har tilgang til personopplysninger er forpliktet til ikke å avsløre til tredjeparter eller distribuere personopplysninger uten samtykke fra emnet for personopplysninger, med mindre annet er gitt av føderal lov;
Fotografisk, video, lyd eller annet opptaksutstyr som kameraer på mobile enheter bør ikke tillates med mindre det er autorisert;
Stasjoner med flyttbare medier bør bare tillates hvis det er et forretningsbehov for det;
For å sikre at konfidensiell informasjon ikke tukles med, må papir og elektroniske medier oppbevares i hensiktsmessig låste skap og/eller andre sikre møbler når de ikke er i bruk, spesielt i ikke-arbeidstid;
Medier som inneholder viktig eller sensitiv proprietær informasjon bør legges bort og låses når det ikke er nødvendig (for eksempel i en brannsikker safe eller skap), spesielt når området er ubebodd.

5. Nettverksikkerhet- dette er et sett med krav til infrastrukturen til en bedrifts datanettverk og retningslinjene for å jobbe i det, hvis implementering sikrer beskyttelse av nettverksressurser mot uautorisert tilgang. Som en del av de anbefalte handlingene for å organisere og sikre nettverkssikkerhet, i tillegg til de grunnleggende, kan du vurdere følgende funksjoner:

Først av alt må selskapet implementere en enhetlig informasjonssikkerhetsforskrift med passende instruksjoner;
Brukere bør nektes tilgang til uønskede nettsteder, inkludert filvertstjenester, så mye som mulig;
Bare de portene som er nødvendige for riktig drift av brukere skal være åpne fra det eksterne nettverket;
Det må være et system for omfattende overvåking av brukerhandlinger og umiddelbar varsling om brudd på normaltilstanden til alle offentlig tilgjengelige ressurser, hvis drift er viktig for selskapet;
Tilgjengelighet av et sentralisert antivirussystem og retningslinjer for rengjøring og fjerning av skadelig programvare;
Tilgjengelighet av et sentralisert system for administrasjon og oppdatering av antivirusprogramvare, samt retningslinjer for vanlige OS-oppdateringer;
Muligheten til å kjøre flyttbare flash-medier bør begrenses så mye som mulig;
Passordet må være minst 8 tegn langt, inneholde tall og store og små bokstaver;
Det må være beskyttelse og kryptering av nøkkelinformasjonsutvekslingsmapper, spesielt 1c-utvekslingsfiler og klient-banksystemet;
Kraft- og inkludert i informasjonsbehandlingsanlegg bør være under jorden der det er mulig eller være underlagt tilstrekkelig alternativ beskyttelse;
Nettverkskabler skal beskyttes mot uautorisert avskjæring eller skade, for eksempel ved å bruke en kanal eller unngå ruter gjennom offentlig tilgjengelige områder.

Oppsummerer alt det ovennevnte, vil jeg merke at hovedreglene for å beskytte informasjon er å begrense rettighetene og mulighetene til brukere, samt kontroll over dem ved bruk av informasjonssystemer. Jo færre rettigheter en bruker har når han arbeider med et informasjonssystem, jo mindre sjanse er det for informasjonslekkasje eller skade på grunn av ondsinnet hensikt eller uaktsomhet.

En omfattende løsning for å beskytte bedriftsdata, inkludert 1C-databaser, er "Server in Israel"-løsningen, som inneholder oppdaterte verktøy for å sikre et høyt nivå av informasjonskonfidensialitet.

System integrasjon. Rådgivning

INFORMASJONSBASISLEDELSE (IS)

Jeg ble tvunget til å skrive denne artikkelen av 3 omstendigheter: kommunikasjon med kjente regnskapsførere, en artikkel av regnskapssjefen, en samling anekdoter.

En venn av meg jobber som regnskapssjef og snakker flytende 1C. Men nylig flyttet hun til en ny organisasjon der det ikke er noen spesialist innen informasjonsteknologi (IT) og begynte å stille meg spørsmål som "Jeg vil jobbe i programmet hjemme, hvordan kan jeg overføre det til hjemmedatamaskinen?"

Når jeg kommuniserte med profesjonelle regnskapsførere, innså jeg at de ikke har noen spørsmål faglig. Spørsmål oppstår innen informasjonsbasestyring.

For det andre husker jeg den nylig publiserte artikkelen "Hvorfor trenger en regnskapsfører Infostart?" . Forfatter Alla (bux 2).

Den tredje omstendigheten er en samling av langt fra nye vitser "Instruksjoner for regnskapsførere om å kommunisere med en 1C-programmerer". Faktisk kan disse historiene kalles anekdoter med en stor strekk, dette er virkelige historier om hver IT-spesialist knyttet til regnskap.

Hvis du nøye analyserer disse anekdotene, kommer du ufrivillig til den konklusjon at konflikten oppstår i grenseområdet for ansvar, som ikke er tildelt verken applikasjonsbrukeren eller IT-spesialisten.

For tiden er mer enn 80 000 brukere registrert på Infostart-nettstedet. Det er usannsynlig at disse alle er 1C-programmerere, mest sannsynlig er disse "avanserte" brukere som har hatt problemer med å betjene 1C-systemer.

Det ser ut til at alle nettstedbrukere kan deles inn i tre hovedkategorier:

1C-programmerere som er narsissistisk involvert i rangeringskonkurranser
"Avanserte" brukere som leter etter mer avanserte verktøy for å jobbe med 1C
Nybegynnere som har støtt på problemer med å bruke 1C og leter etter svar på spørsmålet "Hva skal jeg gjøre?"

Denne artikkelen er ment for de to siste brukerkategoriene. Her vil jeg gjerne diskutere forvaltningen av 1C informasjonsbaser. Diskusjonen er kontroversiell og basert utelukkende på personlig erfaring.

Hvis vi analyserer de mest "vurderte" artiklene, kan vi se at ganske enkle artikler om generelle spørsmål om informasjonssikkerhetsstyring er vellykkede. Disse spørsmålene er forståelige for IT-spesialister, men for 1C-applikasjonsbrukere er de nesten en åpenbaring.

Dette gjelder spesielt for små selskaper som ikke har råd til å ansette en 1C-programmerer eller bare en IT-spesialist. I dette tilfellet faller alle problemer på brukerne.

Oftest bruker en slik bedrift konfigurasjonene "regnskap" og "lønn". Dette skyldes det faktum at 1C raskt gjenspeiler endringer i lovgivningen i sine konfigurasjoner. For virksomheter er dette viktig fra et skattemessig rapporteringssynspunkt.

Typisk liten bedrift. 1C-brukere: direktør; regnskapsfører, også sjefen; sekretær, som også er leder for OK; flere ledere (av en eller annen grunn er dette hva salgsspesialister kalles).

Hver bruker «administrerer» sin egen del av informasjonssikkerheten, men ingen er ansvarlig for hele databasen som helhet. Og når det oppstår problemer, er det ingen å spørre. Som Raikin, "Jeg sydde personlig på knappene. Har du spørsmål om knapper? Nei, de er sydd i hjel, du kan ikke rive dem av!» Men generelt er det ingen som er ansvarlige for drakten.

For normal drift av systemet må noen ta på seg funksjonene som generell informasjonssikkerhetskontroll. Slike funksjoner inkluderer for eksempel fjerning av duplikater fra kataloger. På den ene siden er dette et applikasjonsområde, på den andre siden må dette gjøres av en IT-spesialist. Disse funksjonene ligger i "borderline"-området, både IT-spesialister (hvis noen) og 1C-brukere nekter å utføre dem.

Dette problemet er relevant ikke bare for små bedrifter. Nylig holdt jeg på å oppdatere stillingsbeskrivelser og kunne fordele lignende funksjoner blant ansatte med store vanskeligheter. Og nå er tilnærmingen til stillingsbeskrivelser veldig seriøs, fordi... de er grunnlaget for ulike administrative sanksjoner, inkludert oppsigelse.

Systemadministratoren avviste tilbudet sint, 1C-programmereren erklærte stolt at han "koder" og ikke ryddet bort brukernes søppel. Kort sagt, i en vanlig virksomhet er det ingen spesialist som er ansvarlig for integriteten til informasjon innen informasjonssikkerhet. Denne stillingen er vanskelig å definere betinget, den kan kalles noe som "Informasjonssikkerhetssjef."

Disse funksjonene er forskjellige fra administratorens. 1C Company gir følgende definisjon av administrasjonsoppgaver:

Systeminstallasjon og oppdatering
Opprettholde en liste over brukere
Konfigurere tilgangsrettigheter basert på rollemekanismen
Overvåking av brukerhandlinger og systemhendelser
Sikkerhetskopiering
Testing og retting av informasjonsgrunnlaget
Angi regionale innstillinger
Oppdaterer konfigurasjoner
Laste og losse en informasjonsdatabase til en fil
Vedlikeholde og sette opp loggbok

Faktisk er kapittelet "Administrasjon" i 1C-dokumentasjonen "Konfigurasjon og administrasjon" viet til dette.

I virkeligheten er disse administrasjonsoppgavene ikke nok til å holde databasen jevn. Bredere og mer varierte handlinger kreves for "riktig" funksjon av databasen. "Databasestyring" er mye bredere enn begrepet "administrasjon".

I store virksomheter bør disse informasjonssikktildeles en heltidsspesialist. I små foretak vil disse funksjonene mest sannsynlig falle på regnskapssjefen, fordi han har mer fullstendig kontroll over informasjonen, han må kontrollere inndata og rekkefølge av dokumenter, laste opp og laste ned data osv.

Generelt kommer funksjonene til informasjonssikkerhetsstyring ned til å sikre at informasjonssikkerheten er "riktig" Problemer med "riktigheten" til databasen har alltid eksistert.

Etter min forståelse må den "riktige" 1C-informasjonsdatabasen i enhver konfigurasjon tilfredsstille minst følgende prinsipper:

Den skal ikke inneholde objekter merket for sletting. Alle merkede objekter skal slettes
Det skal ikke være upostede dokumenter i databasen
Ved re-postering av dokumenter for en periode, bør ikke resultatene endres

Databasehåndtering bør føre til disse resultatene. For uavbrutt arbeid med databasen, er det nødvendig å utføre følgende handlinger i standard 1C-konfigurasjoner (ved å bruke eksemplet med ZUP):

1. Sikkerhetskopiering
  - Kopier av alle databaser skal lages daglig på slutten av hver dag. I dette tilfellet kan du "overskrive" kopier av dagen før;
  - Det kreves kopier av databasen før oppdatering. Det anbefales å lagre disse kopiene under unike navn.
  - Det er obligatorisk å lagre kopier av databasen etter slutten av måneden, også under unike navn.

Nettstedet har mange artikler og behandlinger dedikert til sikkerhetskopiering.

1. Sjekk oppslagsverk ukentlig for duplikater. Hvis det oppstår duplikater, slett dem. Hvordan fjerne duplikater
2. Slett elementer merket for sletting på ukentlig basis. Hvis objekter ikke slettes, betyr det at det er referanser til disse objektene. Det er nødvendig å finne ut hvem som har merket dem for sletting og hvorfor. Om nødvendig må disse gjenstandene gjenopprettes. Fjerning kan gjøres ved hjelp av universelle behandlinger//site/blogs/1313/ Før forskriftsrapportering - Teknologisk kontroll
3. Express database analyse//site/public/21332/
4. Ved slutten av måneden etter at måneden er stengt, nekt tilgang til data

Kanskje du kan anbefale noe fra din erfaring?

For virksomheter, institusjoner og organisasjoner, uavhengig av eierform, er nøkkelspørsmålet å sikre beskyttelse av informasjonsressurser, inkludert regnskapsinformasjon og rapportering. Programmet "1C: Public Institution Accounting 8" utgave 2 oppfyller moderne krav til informasjonssikkerhet. 1C-eksperter snakker om mulighetene til ini artikkelen.

Relevansen av å sikre beskyttelse av informasjonsressurser

For å sikre informasjonssikkerheten til en organisasjon, institusjon, virksomhet, må det skapes betingelser for bruk, tap eller forvrengning av informasjon om organisasjonens tilstand, inkludert regnskaps- og finansiell informasjon, av ansatte i organisasjonen eller eksterne personer ( brukere) med høy grad av sannsynlighet vil ikke i overskuelig fremtid føre til fremveksten av trusler om å avbryte organisasjonens aktiviteter.

Relevansen av informasjonssikkerhetsproblemer på statlig nivå bekreftes av vedtakelsen av informasjonssikkerhetsdoktrinen i den russiske føderasjonen (godkjent av presidenten for den russiske føderasjonen 9. september 2000 nr. Pr-1895). En av komponentene i den russiske føderasjonens nasjonale interesser i informasjonssfæren er beskyttelsen av informasjonsressurser mot uautorisert tilgang, og sikrer sikkerheten til informasjons- og telekommunikasjonssystemer, både allerede utplassert og de som opprettes i Russland.

Å sikre den russiske føderasjonens informasjonssikkerhet i den økonomiske sfæren spiller en nøkkelrolle i å sikre den russiske føderasjonens nasjonale sikkerhet. Følgende er mest utsatt for virkningen av trusler mot informasjonssikkerheten til Den russiske føderasjonen i den økonomiske sfæren:

statlig statistikk system;
kreditt- og finanssystem;
informasjons- og regnskapsautomatiserte systemer for divisjoner av føderale utøvende myndigheter som sikrer samfunnets og statens aktiviteter i den økonomiske sfæren;
regnskapssystemer for virksomheter, institusjoner og organisasjoner, uavhengig av eierform;
systemer for innsamling, behandling, lagring og overføring av finansiell, børs-, skatte-, tollinformasjon og informasjon om utenlandsk økonomisk aktivitet til staten, samt foretak, institusjoner og organisasjoner, uavhengig av deres form for eierskap.

Trusler mot informasjonssikkerheten til en virksomhet, institusjon, organisasjon knyttet til regnskap og rapportering er truslene:

integriteten til regnskapsinformasjon og rapportering;
brudd på konfidensialitet av regnskapsinformasjon og rapportering;
brudd på tilgjengelighet (blokkering) av regnskapsinformasjon og rapportering;
påliteligheten av regnskapsinformasjon og rapportering;
innholdet i regnskapsinformasjon og rapportering forårsaket av handlingene til personell og andre personer;
forårsaket av bruk av dårlig kvalitet på regnskapsinformasjon og rapportering.

Informasjonssikkerhet i "1C: Public Institution Accounting 8"

Programmet «1C: Public Institution Accounting 8» utgave 2 (heretter referert til som programmet) oppfyller moderne krav til informasjonssikkerhet. For å øke beskyttelsesnivået mot uautorisert tilgang til informasjon som er lagret i programmet, tilbys følgende funksjoner:

autentisering;

La oss se nærmere på disse funksjonene i programmet.

Autentisering

Autentiseringsmekanismen er et av administrasjonsverktøyene. Den lar deg bestemme hvilke av brukerne som er oppført i listen over systembrukere som for øyeblikket kobler til programmet og forhindre uautorisert tilgang til programmet.

I "1C: Public Institution Accounting 8" utgave 2 støttes tre typer autentisering, som kan brukes avhengig av de spesifikke oppgavene informasjonsbaseadministratoren står overfor:

autentisering 1C:Enterprise- autentisering ved hjelp av brukeren og passordet som er opprettet i programmet;
operativsystemautentisering- i programmet er en av operativsystembrukerne valgt for brukeren. Programmet analyserer på vegne av hvilken operativsystembruker tilkoblingen til Programmet gjøres, og bestemmer på bakgrunn av dette den aktuelle brukeren av Programmet;
OpenID-autentisering- brukerautentisering utføres av en ekstern OpenID-leverandør som lagrer en liste over brukere.

Hvis ingen type autentisering er spesifisert for en bruker, nektes denne brukerens tilgang til programmet.

Hvis det er nødvendig for brukeren å gå inn i programmet med et passord som vil bli sjekket, bør flagget være aktivert Autentisering 1C:Enterprise(se fig. 1). Den er aktivert som standard sammen med flagget Innlogging til programmet er tillatt.

1C:Enterprise-autentiseringsstatusen vises under flagget.

Ris. 1

Når en ny bruker er opprettet, tildeler programmet ham automatisk et tomt passord. For å endre det, bruk kommandoen Lag et passord i brukerkortet (se fig. 1).

I formen av Sette et passord må legges inn Nytt passord for å gå inn i programmet, skriv det på nytt i feltet Bekreftelse.

Et godt passord bør være minst åtte tegn langt, inneholde store og små latinske bokstaver, tall, symboler (understreking, parentes osv.), og være vag. Det er uønsket at passordet sammenfaller med brukernavnet, består utelukkende av tall, inneholder forståelige ord eller vekslende grupper av tegn. Eksempler på gode passord: "nj7(jhjibq*Gfhjkm, F5"njnGhkmNj;t(HI. Eksempler på dårlige passord: Ivanov, qwerty, 12345678, 123123123. For flere detaljer, se dokumentasjonen "1C:Enterprise Administrator's Guide."

Programmet gir muligheten automatisk kontroll av passordkompleksitet.

Som standard, av sikkerhetsgrunner, vises ikke passordet når det skrives inn. For å se hvilke tegn som legges inn, bør du aktivere flagget Vis nytt passord.

For å generere et passord automatisk, kan du bruke knappen Lag et passord. Passordet vil bli generert av programmet.

For å lagre passordet ditt, klikk på knappen Lag et passord.

Etter dette endres 1C:Enterprise-autentiseringstilstanden til Passord satt. I brukerkortet endrer knappen verdi til Bytt passord.

For enkel administrasjon og sikkerhet har alle brukere et flagg , som er nødvendig for at brukeren skal endre passordet satt av administratoren til sitt eget. Når dette flagget er aktivert, vil brukeren bli bedt om å skrive inn sitt eget passord, som ingen andre vil vite.

Hvis flagget Krev endring av passord ved pålogging ikke er aktivert, og det tidligere innstilte passordet ikke passer deg av en eller annen grunn, kan du endre det når som helst i brukerkortet.

Aktivert flagg Brukeren har forbud mot å endre passordet forbyr en bruker som ikke har fulle rettigheter fra selvstendig å angi og endre et passord.

Forutsetninger Krev endring av passord ved pålogging Og Gyldighet kan sees i brukerkortet og i rapporten brukerinformasjon (Informasjon om eksterne brukere).

Program påloggingsinnstillinger

I formen av Innstillinger for pålogging(kapittel Administrasjon, kommandoen på navigasjonslinjen Bruker- og rettighetsinnstillinger) separat for interne og eksterne brukere av programmet kan du konfigurere følgende parametere:

innstilling og kontroll av passordkompleksitet;
krav om å endre passordet på en tidsplan eller manuelt. Endring av passord - med jevne mellomrom eller på forespørsel;
sette opp og kontrollere gjentakelse av passord;
begrense gyldighetsperioden for kontoer.

Figur 2 viser oppsettet for interne brukere.

Ris. 2

En lignende innstilling er gitt for eksterne brukere.

Kontroll av passordkompleksitet

Når flagget er satt Passordet må oppfylle kravene til kompleksitet programmet sjekker at det nye passordet:

hadde minst 7 tegn,
inneholdt 3 av 4 typer tegn: store bokstaver, små bokstaver, tall, spesialtegn,
samsvarte ikke med navnet (for pålogging).

Minste passordlengde kan endres ved å merke av i boksen ved siden av feltet med samme navn og angi ønsket passordlengde (fig. 3).

Ris. 3

Bytt passord

Det er to innstillinger for å endre passordet: periodisk eller på forespørsel fra administrator.

For å endre passordet med jevne mellomrom, må du begrense passordets utløpsdato ved hjelp av innstillingene Minimum passordgyldighet Og Maksimal passordgyldighet. Etter at den angitte perioden er utløpt, vil programmet be brukeren om å endre passordet.

Maksimal gyldighetsperiode for passord er perioden etter første pålogging med nytt passord, hvoretter brukeren må endre passordet, som standard 30 dager.

Minste gyldighetsperiode for passord er perioden etter første pålogging med nytt passord der brukeren ikke kan endre passordet, som standard 1 dag.

For å endre passordet på forespørsel, må administratoren sette flagget Krev passord ved innlogging i brukerkortet. Når du først går inn i programmet, vil det kreve at du endrer passordet angitt av administratoren til ditt eget.

Repeterbarhetskontroll

For å forhindre at brukere oppretter dupliserte passord, må du aktivere innstillingen Forhindre gjentakelse av passord blant de siste og angi antall nylige passord som det nye passordet skal sammenlignes med.

Begrensninger for brukerpålogging

For å beskytte mot uautorisert tilgang til programmet, kan du sette en begrensning for brukere som ikke jobber i programmet i en viss tidsperiode, for eksempel 45 dager.

Etter at den angitte perioden er utløpt, vil ikke programmet tillate brukeren å gå inn i programmet. Åpne brukerøkter vil automatisk avsluttes ikke mer enn 25 minutter etter at pålogging til programmet har blitt nektet.

I brukerkortet, som er tilgjengelig i de personlige innstillingene til programmet, via hyperlenken Sett restriksjoner Du kan angi ytterligere begrensninger for å gå inn i programmet (fig. 4).

Ris. 4

Ved å bruke bryteren kan du angi en begrensning for å gå inn i programmet:

I henhold til generelle påloggingsinnstillinger- installert som standard;
Ingen tidsbegrensning;
Inngang tillatt frem til(du må sette en frist - skriv inn datoen manuelt eller velg fra kalenderen ved hjelp av knappen). For å beskytte mot uautorisert tilgang til programmet, har alle brukere en gyldighetsperiode som gjør at brukeren automatisk kan kobles fra når en spesifisert dato er nådd;
Nekt adgang hvis det ikke fungerer lenger(antall dager må spesifiseres) - hvis brukeren ikke går inn i programmet på mer enn det angitte antall dager, vil det være umulig å gå inn i programmet. I dette tilfellet må brukeren kontakte administratoren for å gjenoppta arbeidet i programmet.

Rapport om brukerdetaljer

Rapportere brukerinformasjon(Fig. 5) er ment for å vise informasjon om Programbrukere, inkludert påloggingsinnstillinger (infobase brukeregenskaper). Behovet for en rapport oppstår dersom du ønsker å utføre en gruppeanalyse av påloggingsinnstillinger (påloggingsnavn, autentiseringstyper osv.).

Rapporten åpnes fra listen Brukere (Eksterne brukere) på kommando Alle handlinger - Brukerinformasjon (Alle handlinger-Om eksterne brukere). Avhengig av type liste, velger programmet automatisk ønsket rapportalternativ.

Informasjon om interne og eksterne brukere i én rapport kan åpnes gjennom seksjonens handlingspanel Administrasjon på kommando brukerinformasjon.

Behovet for en rapport oppstår dersom du ønsker å utføre en gruppeanalyse av påloggingsinnstillinger (påloggingsnavn, autentiseringstyper osv.).

Ris. 5

Ved hjelp av en knapp Innstillinger... Du kan åpne listen over felt og om nødvendig legge til de obligatoriske feltene i rapporten. Du kan for eksempel legge til felt i rapporten Krev endring av passord ved pålogging Og Gyldighet.

Sikre beskyttelse av personopplysninger

Avslutningsvis bør det bemerkes at tilgangskontroll til programmet bare er ett av databeskyttelseselementene som tilbys av programmet.

Dekret fra regjeringen i den russiske føderasjonen datert 1. november 2012 nr. 1119 godkjente kravene for beskyttelse av personopplysninger under behandlingen av personopplysninger i informasjonssystemer for personopplysninger, som definerer sikkerhetsnivåene for personopplysninger under behandlingen av personopplysninger. systemer avhengig av truslene mot sikkerheten til disse dataene. I samsvar med disse kravene, etter ordre fra FSTEC i Russland datert 18. februar 2013. nr. 21 detaljerer sammensetningen og innholdet av organisatoriske og tekniske tiltak for å ivareta sikkerheten til personopplysninger under behandlingen av dem i personopplysningssystemer.

Normene i gjeldende personopplysningslovgivning stiller tilleggskrav til programvareprodukter, spesielt til programvare som er et middel til å beskytte informasjon.

For å sikre beskyttelse av personopplysninger er den beskyttede programvarepakken (ZPK) "1C:Enterprise, versjon 8.3z" designet, som er en generell programvare sertifisert av FSTEC i Russland med innebygde midler for å beskytte informasjon mot uautoriserte tilgang (NSD) til informasjon som ikke inneholder opplysninger som utgjør statshemmeligheter.

ZPK "1C:Enterprise 8.3z" lar deg blokkere:

lansering av COM-objekter, ekstern behandling og rapporter, applikasjoner installert på 1C:Enterprise-serveren;
bruk av eksterne 1C:Enterprise-komponenter;
tilgang til Internett-ressurser.

Den kombinerte bruken av standard "1C: Public Institution Accounting" utgave 2 og ZPK "1C: Enterprise 8.3z" lar deg lage et informasjonssystem med personlige data på alle sikkerhetsnivåer, og ytterligere sertifisering av denne applikasjonsløsningen er ikke nødvendig.

Bruken av ZPK "1C:Enterprise 8.3z" sammen med FSTEC-sertifiserte operativsystemer, DBMS og andre sertifiserte verktøy lar deg fullt ut overholde kravene i de ovennevnte forskriftsdokumentene.

Siden "1C: Public Institution Accounting" sikrer datautveksling med de føderale finansmyndighetene, skattemyndighetene, informasjonssystemer om statlige og kommunale betalinger (GIS GMP), regnskap for føderal eiendom (ASUFI), registrering og periodisering av betalinger (IS RNIP), etc. via internett, for å oppfylle sikkerhetskrav må anlegget utstyres med sertifiserte brannmurverktøy.

Selvfølgelig er det nødvendig å sjekke datamaskinene som programmet er installert på daglig for tilstedeværelsen av ondsinnede dataprogrammer som bruker antivirusbeskyttelsesverktøy sertifisert i FSTEC-sertifiseringssystemet i Russland.

2009

Seksjon "Modernisering av ledelsesmessige, finansielle og økonomiske mekanismer på forskjellige nivåer i utdanningssystemet ved bruk av 1C-teknologier"

"25. Metoder og midler for å sikre informasjonssikkerhet i 1C:Enterprise 8.1-systemet" (P.B. Khorev, Russian State Social University (RGSU), Moskva)

Presentasjon

Den konstante utviklingen av informasjonsteknologier og -systemer fører dessverre til forverring av gamle problemer og fremveksten av nye. Et av disse problemene er problemet med informasjonsbeskyttelse - pålitelig levering av sikkerheten og etablert bruksstatus. Derfor er sikring av informasjon og informasjonsprosesser en obligatorisk funksjon i moderne informasjonssystemer.

De viktigste metodene for beskyttelse mot uautorisert tilgang til informasjonssystemobjekter er

identifikasjon og autentisering av brukere av informasjonssystemer og prosesser aktivert av dem;
autorisasjon av subjekter (bestemme subjektets tilgangsrettigheter til et objekt med konfidensiell informasjon);
revisjon av hendelser knyttet til sikkerheten til informasjonssystemet.

Denne rapporten vil diskutere metodene og midlene for å sikre informasjonssikkerhet tilgjengelig i 1C:Enterprise 8.1-systemet.

Databaseadministratoren i 1C:Enterprise 8.1-systemet kan opprette og deretter redigere en liste over brukere som har lov til å jobbe med systemet. Når du legger til en ny bruker (til å begynne med er listen over brukere tom), spesifiseres følgende egenskaper for kontoen som opprettes (på «Grunnleggende»-fanen):

navnet som brukeren vil bli registrert under i systemet;
fullt navn (det anbefales å bruke denne egenskapen til å spesifisere etternavn, fornavn og patronym, stilling og navn på avdelingen til en ansatt i organisasjonen der systemet brukes);
"1C:Enterprise" autentiseringsflagg (når denne "avmerkingsboksen" er merket, når en bruker prøver å logge på "1C:Enterprise" systemet, vil hans identifikasjon og autentisering bli utført ved hjelp av selve systemet);
brukerpassord, hvis oppføring vil være nødvendig for å identifisere ham ved å bruke 1C:Enterprise-systemet:
bekreftelse av brukerpassordet (kreves for å eliminere muligheten for feil ved inntasting av passordet, siden passordsymbolene erstattes av *-symboler når de skrives inn);
et tegn på at brukeren er forbudt å endre passordet sitt når det er autentisert med 1C:Enterprise;
et tegn på visning av brukernavnet i listen når du prøver å logge på og autentisere med 1C:Enterprise;
Windows-autentiseringsflagg (når dette "Flagget" er aktivert, når en bruker prøver å logge på 1C:Enterprise-systemet, vil navnet som økten kjører under med Microsoft Windows-operativsystemet bli bestemt, og navnet som navnet på samsvarer vil bli søkt i listen over brukere av 1C:Enterprise-systemet "nåværende" Windows-bruker);
brukernavnet til Windows-operativsystemet som denne brukeren av 1C:Enterprise-systemet er knyttet til ved bruk av autentisering ved bruk av Windows-operativsystemet (navnet kan angis i formatet \\domenenavn\brukerkontonavn eller velges med den tilsvarende knappen fra listen over lokale og globale kontoer kjent på denne datamaskinen).

Databaseadministratoren kan, ved å bruke infobase-parameterinnstillingene, angi minimumslengden på systembrukerpassord (hvis avmerkingsboksen "Sjekker kompleksiteten til brukerpassord" er valgt, kan minimumslengden på passord ikke være mindre enn 7 tegn) og kreve at brukerpassord oppfyller kompleksitetsbetingelsene, oppfyller kravene til kompleksiteten til Windows-brukerpassord (i tillegg må passordet ikke være en sekvens av tegn).

Den sikreste måten å autentisere brukere på når de logger på 1C:Enterprise-systemet er å kombinere autentisering ved hjelp av 1C:Enterprise- og Windows-verktøy. I dette tilfellet anbefales det å fjerne merket for "Vis i utvalgslisten" i "1C:Enterprise"-godkjenningsegenskapsgruppen, og i Windows-sikkerhetsinnstillingene aktivere kravene til minimumslengden og kompleksiteten til passord, og begrense deres maksimal gyldighetsperiode, ikke-repetisjon av passord og deres minste gyldighetsperiode, og innstilling av en terskelverdi for Windows-påloggingsfeilteller.

For å tvinge brukerautentiseringsdialogen til å vises med 1C:Enterprise (hvis Windows-autentiseringsboksen er aktivert), må du bruke /WA+ kommandolinjeparameteren når du starter 1C:Enterprise.

Det må tas i betraktning at listen over brukere av 1C:Enterprise-systemet ikke er en del av konfigurasjonen, men opprettes separat for hver organisasjon der dette systemet er installert.

En rolle i 1C:Enterprise-systemet er et sett med tilgangsrettigheter til ulike databaseobjekter. Vanligvis opprettes roller for individuelle jobbansvar, og hver bruker av systemet kan tildeles en eller flere roller. Hvis en bruker er tildelt flere roller, vil det å gi ham tilgang til et databaseobjekt gjøres som følger:

Hvis minst én av rollene som er tildelt brukeren tillater den forespurte tilgangen, blir den gitt til brukeren.
Hvis alle rollene som er tildelt en bruker ikke tillater passende tilgang, gis ikke den forespurte tilgangen.

For å opprette og redigere roller, bruk 1C:Enterprise-systemkonfiguratoren. Under koopprettes et sett med standardroller, som deretter kan redigeres.

Når du oppretter eller redigerer en rolle, brukes et vindu med to faner - "Rettigheter" og "Begrensningsmaler". "Rettigheter"-fanen inneholder en hierarkisk struktur av konfigurasjonsobjekter for alle undersystemer og en liste over tilgangsrettigheter som gjelder for det valgte objektet (for å aktivere en rettighet, må du velge den tilsvarende "avmerkingsboksen").

I 1C:Enterprise-systemet er det to typer rettigheter – grunnleggende og interaktive. Grunnleggende rettigheter kontrolleres hver gang man får tilgang til informasjonssystemobjekter. Interaktive rettigheter kontrolleres når du utfører interaktive operasjoner (for eksempel visning og redigering av data i et skjema).

1C:Enterprise-systemet lar tilgangsrettigheter kontrolleres ved hjelp av et innebygd språk. For eksempel, når du legger til nye kommandoer i et skjema, må utvikleren i tillegg kontrollere at brukeren har de riktige interaktive rettighetene.

Når du redigerer en rolle, er det nødvendig å ta hensyn til arven (hierarkiet) av rettigheter: når du kansellerer en "foreldre" ("senior") rettighet, kanselleres også dens "barn" ("junior") rettigheter, og når du installerer en "barn"-rettighet, dens "foreldre"-rett er også etablert. For eksempel, når du avbryter Vis-rettigheten, kanselleres også redigeringsretten til det tilsvarende objektet.

Ved å bruke avmerkingsboksen "Angi rettigheter for nye objekter" kan du sikre at den redigerte rollen automatisk setter tilgangsrettigheter til nye (senere lagt til) konfigurasjonsobjekter.

Følgende tilgangsrettigheter kan angis for rotkonfigurasjonsobjektet:

administrative funksjoner (inkluderer å åpne konfigurasjonen, åpne listen over brukere, sette opp loggen, oppdatere konfigurasjonen og andre administrative handlinger);
oppdatering av databasekonfigurasjonen;
monopol modus;
aktive brukere (åpner listen deres);
log (åpner denne loggen);
ekstern tilkobling (arbeid med systemet via et COM-grensesnitt);
automatisering (arbeide med systemet som en automatiseringsserver);
interaktiv åpning av ekstern behandling;
interaktiv åpning av eksterne rapporter;
utskrift, lagring, bruk av utklippstavlen når du arbeider med systemet).

For enkel administrasjon gir 1C:Enterprise-systemet et vindu for visning og redigering av alle roller som er opprettet i denne konfigurasjonen. Hvis du for en bestemt rolle må tilbakekalle eller angi alle tilgangsrettigheter til det valgte objektet, kan du bruke avmerkingsboksen i "Alle rettigheter"-raden for kolonnen med navnet på rollen som redigeres. Hvis en viss tilgangsrettighet må tilbakekalles eller angis i alle roller, kan du bruke avmerkingsboksen i raden med navnet på den tilsvarende rettigheten for kolonnen Alle roller.

For å begrense tilgangen til databaseobjekter på nivå med individuelle felt og poster, gir 1C:Enterprise-systemet en mekanisme for å begrense tilgang til data (ved å bruke rettigheter til å lese, legge til, endre og slette disse objektene). For leseretten er det mulig å sette flere tilgangsbegrensninger, og for de resterende spesifiserte rettighetene - kun én begrensning.

For hver datatilgangsbegrensning ved å leserett, kan du velge et felt med verdien som tilgangsbegrensningsbetingelsen skal kontrolleres for, eller spesifisere "Andre felt", som vil sikre at betingelsen for hvert felt blir sjekket.

Betingelsen for å begrense tilgang til data kan defineres ved hjelp av designeren eller manuelt ved å opprette og redigere navngitte tilgangsbegrensningsmaler på fanen "Restriction Templates" i rolleredigeringsvinduet.

For å lette brukerens arbeid og ytterligere begrense hans rettigheter, gir 1C:Enterprise-systemet en grensesnittmekanisme. Ved å bruke disse objektene lages sett med hovedmenykommandoer og verktøylinjeelementer som brukeren kan jobbe med. Ved å bruke hovedgrensesnittets menydesigner oppretter administratoren en liste over undermenyer og en liste over kommandoer for hver undermeny.

Etter å ha definert strukturen til hovedmenyen, kan en eller flere verktøylinjer legges til det opprettede grensesnittet. Disse panelene kan plasseres øverst, nederst, til venstre og til høyre i 1C:Enterprise-programvinduet.

Merk at etter å ha opprettet roller og grensesnitt, er det nødvendig å oppdatere databasekonfigurasjonen slik at nye brukere av informasjonssystemet kan tildeles de opprettede rollene og grensesnittene.

Hendelser som skal registreres i 1C:Enterprise-systemloggen kan spesifiseres av administratoren ved hjelp av konfigurasjonsfunksjonen. Her kan du også velge etter hvilket tidsrom loggen skal lagres i en ny fil, samt forkorte loggoppføringene før utløpet av den angitte perioden ved å slette dem og eventuelt lagre dem i en fil.

Litteratur

Radtsjenko M.G. "1C:Enterprise 8.1. Praktisk veiledning for utviklere. Eksempler og typiske teknikker. M.: 1C-Publishing LLC, St. Petersburg: Peter, 2007.
1C:Enterprise 8.1. Konfigurasjon og administrasjon. M.: Firmaet "1C", 2007.

Denne artikkelen viser nok en gang at ethvert sett med sikkerhetstiltak må dekke alle stadier av implementeringen: utvikling, distribusjon, systemadministrasjon og selvfølgelig organisatoriske tiltak. I informasjonssystemer er det den «menneskelige faktoren» (inkludert brukere) som er den viktigste sikkerhetstrusselen. Dette settet med tiltak må være rimelige og balanserte: det gir ikke mening, og det er usannsynlig at tilstrekkelige midler vil bli bevilget til å organisere beskyttelse som overstiger kostnadene for selve dataene.

Introduksjon

1C:Enterprise er det vanligste regnskapssystemet i Russland, men til tross for dette, frem til versjon 8.0 tok utviklerne svært lite oppmerksomhet til sikkerhetsproblemer. I bunn og grunn ble dette selvfølgelig diktert av prisnisjen til produktet og fokuset på små bedrifter der det ikke er kvalifiserte IT-spesialister, og de mulige kostnadene ved å distribuere og vedlikeholde et sikkert system ville være uoverkommelig dyrt for bedriften. Med utgivelsen av versjon 8.0 måtte vektleggingen endres: kostnadene for løsninger økte betydelig, systemet ble mye mer skalerbart og fleksibelt – kravene endret seg betydelig. Hvorvidt systemet er blitt tilstrekkelig pålitelig og sikkert er et veldig individuelt spørsmål. Hovedinformasjonssystemet til en moderne bedrift må oppfylle minst følgende sikkerhetskrav:

Ganske lav sannsynlighet for systemfeil på grunn av interne årsaker.
Pålitelig brukerautorisasjon og databeskyttelse mot feil handlinger.
Et effektivt system for å tildele brukerrettigheter.
Online sikkerhetskopiering og gjenopprettingssystem i tilfelle feil.

Oppfyller løsninger basert på 1C:Enterprise 8.0 disse kravene? Det finnes ikke noe klart svar. Til tross for betydelige endringer i tilgangskontrollsystemet, gjenstår mange uløste problemer. Avhengig av hvordan systemet er designet og konfigurert, kan det hende at alle disse kravene ikke oppfylles eller oppfylles i tilstrekkelig grad for en gitt implementering, men det er verdt å være oppmerksom (og dette er en betydelig konsekvens av plattformens "ungdom" ) at for å oppfylle de oppførte betingelsene fullt ut, er det nødvendig å bruke virkelig Herculean-innsats.

Denne artikkelen er ment for utviklere og implementere av løsninger på 1C:Enterprise-plattformen, samt systemadministratorer for organisasjoner der 1C:Enterprise brukes, og beskriver noen aspekter ved utvikling og konfigurering av en klient-serverversjon av systemet fra det punktet. med tanke på organisering av informasjonssikkerhet. Denne artikkelen kan ikke brukes som erstatning for dokumentasjon, men peker kun på noen punkter som ennå ikke er reflektert i den. Og selvfølgelig vil verken denne artikkelen eller all dokumentasjon kunne gjenspeile kompleksiteten i problemet med å bygge et sikkert informasjonssystem, som samtidig må tilfredsstille de motstridende kravene til sikkerhet, ytelse, bekvemmelighet og funksjonalitet.

Klassifikasjon og terminologi

Det sentrale temaet for vurdering i artikkelen er informasjonstrusler.

Informasjonstrussel– muligheten for en situasjon der data vil bli lest, kopiert, endret eller blokkert uten autorisasjon.

Og basert på denne definisjonen klassifiserer artikkelen informasjonstrusler som følger:

Uautorisert ødeleggelse av data
Uautorisert endring av data
Uautorisert kopiering av data
Uautorisert lesing av data
Data utilgjengelighet

Alle trusler er delt inn i tilsiktet og utilsiktet. Vi vil kalle en realisert informasjonstrussel hendelse. Funksjonene til systemet er:

Sårbarheter– funksjoner som fører til hendelser Beskyttelsestiltak– funksjoner som blokkerer muligheten for en hendelse

I utgangspunktet vurderes bare de tilfellene, sannsynligheten for at det skyldes bruken av den teknologiske plattformen 1C: Enterprise 8.0 i klient-serverversjonen (ytterligere, i tilfeller der dette ikke motsier betydningen av bare 1C eller 1C 8.0) . La oss definere følgende hovedroller i forhold til bruken av systemet:

Operatører– brukere som har rettigheter til å se og endre data begrenset av en applikasjonsrolle, men som ikke har administrative funksjoner
Systemadministratorer– brukere som har administrative rettigheter i systemet, inkludert administrative rettigheter i operativsystemene til applikasjonsserveren og MS SQL-serveren, administrative rettigheter i MS SQL, etc.
Informasjonssikkerhetsadministratorer– brukere som visse administrative funksjoner i 1C-informasjonsbasen er delegert til (som å legge til brukere, teste og fikse, sikkerhetskopiere, sette opp en applikasjonsløsning, etc.)
Systemutviklere– brukere som utvikler en applikasjonsløsning. Generelt kan det hende at de ikke har tilgang til det fungerende systemet.
Personer som ikke har direkte tilgang til systemet– brukere som ikke er delegert tilgangsrettigheter til 1C, men som i en eller annen grad kan påvirke driften av systemet (vanligvis er dette alle brukere av samme Active Directory-domene som systemet er installert i). Denne kategorien anses først og fremst for å identifisere potensielt farlige emner i systemet.
Automatiserte administrative skript– programmer som visse funksjoner er delegert til, designet for automatisk å utføre bestemte handlinger (for eksempel import-eksport av data)

To punkter bør bemerkes her: For det første er denne klassifiseringen veldig grov og tar ikke hensyn til divisjonene innen hver gruppe - en slik divisjon vil bli opprettet for noen spesifikke tilfeller, og for det andre antas det at andre personer ikke kan påvirke operasjonen av systemet, som må leveres med midler utenfor 1C.

Ethvert sikkerhetssystem må utformes med tanke på gjennomførbarhet og eierkostnader. Generelt, når du utvikler og implementerer et informasjonssystem, er det nødvendig at prisen for å beskytte systemet tilsvarer:

verdien av den beskyttede informasjonen;
kostnader ved å skape en hendelse (i tilfelle en bevisst trussel);
økonomisk risiko i tilfelle en hendelse

Det er meningsløst og skadelig å organisere et forsvar som er mye dyrere enn å vurdere dets økonomiske effektivitet. Det finnes flere metoder for å vurdere risikoen for tap av informasjon, men de er ikke omtalt innenfor rammen av denne artikkelen. Et annet viktig aspekt er å opprettholde en balanse mellom ofte motstridende krav til informasjonssikkerhet, systemytelse, bekvemmelighet og enkelt arbeid med systemet, hastighet på utvikling og implementering, og andre krav til bedriftsinformasjonssystemer.

Hovedtrekkene i systemets informasjonssikkerhetsmekanisme

1C:Enterprise 8.0 kommer i to versjoner: fil og klient-server. Filversjonen kan ikke anses å sikre informasjonssikkerheten til systemet av følgende grunner:

Data og konfigurasjon lagres i en fil som er lesbar og skrivbar for alle brukere av systemet.
Som det vil bli vist nedenfor, omgås systemautorisasjon veldig enkelt.
Integriteten til systemet sikres kun av kjernen til klientdelen.

I klient-serverversjonen brukes MS SQL Server til å lagre informasjon, som gir:

Mer pålitelig datalagring.
Isolering av filer fra direkte tilgang.
Mer avanserte transaksjons- og låsemekanismer.

Til tross for de betydelige forskjellene mellom fil- og klient-serverversjonene av systemet, har de et enhetlig tilgangskontrollskjema på applikasjonsløsningsnivå, som gir følgende funksjoner:

Brukerautorisasjon ved hjelp av passordet spesifisert i 1C.
Brukerautorisasjon basert på gjeldende Windows-bruker.
Tildele roller til systembrukere.
Begrense administrative funksjoner etter rolle.
Tildeling av tilgjengelige grensesnitt etter roller.
Begrensning av tilgang til metadataobjekter etter rolle.
Begrensning av tilgang til objektdetaljer etter rolle.
Begrensning av tilgang til dataobjekter etter roller og øktparametere.
Begrenser interaktiv tilgang til data og kjørbare moduler.
Noen begrensninger for kjøring av kode.

Generelt er datatilgangsordningen som brukes ganske typisk for informasjonssystemer på dette nivået. Men i forhold til denne implementeringen av en trelags klient-server-arkitektur, er det flere grunnleggende aspekter som fører til et relativt stort antall sårbarheter:

Et stort antall databehandlingstrinn, og på hvert trinn kan ulike regler for tilgang til objekter gjelde.

Et noe forenklet diagram over databehandlingstrinn som er viktige fra et sikkerhetssynspunkt er vist i fig. 1. Den generelle regelen for 1C er å redusere restriksjoner etter hvert som du beveger deg nedover denne ordningen, derfor kan bruk av en sårbarhet på et av de øvre nivåene forstyrre driften av systemet på alle nivåer.
Utilstrekkelig etablerte prosedyrer for overvåking av overførte data ved overgang fra nivå til nivå.

Dessverre er ikke alle interne mekanismer i systemet perfekt feilsøkt, spesielt for ikke-interaktive mekanismer, hvis feilsøking alltid er mer arbeidskrevende på den ene siden, men mer ansvarlig på den andre. Denne "sykdommen" er ikke et problem utelukkende med 1C, den finnes i mange serverprodukter fra de fleste leverandører. Først de siste årene har oppmerksomheten rundt disse problemene økt betydelig.
Utilstrekkelig høye gjennomsnittlige kvalifikasjoner for utviklere og systemadministratorer, arvet fra forrige versjon.

Produktene fra 1C:Enterprise-linjen var opprinnelig fokusert på enkel utvikling og støtte og på å jobbe i små organisasjoner, så det er ikke overraskende at det historisk sett har utviklet seg at en betydelig del av "utviklerne" av applikasjonsløsninger og "administratorer" av systemer har ikke tilstrekkelig kunnskap og ferdigheter til å jobbe med et mye mer komplekst produkt, som er versjon 8.0. Problemet forverres av praksisen som franchisetakerselskaper har brukt for å undervise "i kamp" på bekostning av klienter, uten å systematisk nærme seg dette problemet. Det er nødvendig å hylle 1C-selskapet som i løpet av de siste årene har denne situasjonen gradvis blitt korrigert: seriøse franchisetakerbedrifter har begynt å ta en mer ansvarlig tilnærming til problemet med personellvalg og opplæring, nivået på informasjonsteknologistøtte fra 1C-selskapet har økt betydelig, sertifiseringsprogrammer har dukket opp rettet mot høyt servicenivå; men situasjonen kan ikke korrigeres umiddelbart, så denne faktoren bør tas i betraktning når du analyserer sikkerheten til systemet.
Plattformen er relativt ung.

Blant produkter med lignende fokus og bruksformål er dette en av de yngste løsningene. Funksjonaliteten til plattformen ble mer eller mindre etablert for mindre enn ett år siden. Samtidig ble hver utgivelse av plattformen, fra og med 8.0.10 (det var i denne utgivelsen at nesten alle de nåværende funksjonene til systemet ble implementert) betydelig mer stabile enn de forrige. Funksjonaliteten til standard applikasjonsløsninger vokser fortsatt med stormskritt, selv om bare halvparten av plattformens muligheter brukes. Selvfølgelig kan vi under slike forhold snakke om stabilitet ganske betinget, men generelt må det erkjennes at løsninger på 1C 8.0-plattformen i mange henseender er betydelig foran i funksjonalitet og ytelse (og ofte i stabilitet) til lignende løsninger på 1C 7.7 plattform.

Så systemet (og muligens en standard applikasjonsløsning) distribueres i bedriften og installeres på datamaskiner. Først av alt er det nødvendig å lage et miljø der det er fornuftig å sette opp 1C-sikkerhet, og for dette må det konfigureres på en slik måte at antakelsen om at systemsikkerheten er betydelig påvirket av systeminnstillingene oppfylles.

Følg de generelle reglene for å sette opp sikkerhet.

Det kan ikke være snakk om noen informasjonssikkerhet ved et system dersom de grunnleggende prinsippene for å lage sikre systemer ikke følges. Sørg for at minst følgende betingelser er oppfylt:

Tilgang til servere er fysisk begrenset og deres uavbrutt drift er sikret:
- serverutstyret oppfyller krav til pålitelighet, utskifting av defekt serverutstyr er justert, for spesielt kritiske områder brukes ordninger med duplisering av maskinvare (RAID, strøm fra flere kilder, flere kommunikasjonskanaler, etc.);
- serverne er plassert i et låst rom, og dette rommet er kun åpnet for varigheten av arbeidet som ikke kan utføres eksternt;
- Kun én eller to personer har rett til å åpne serverrommet i nødstilfeller, det er utviklet et varslingssystem for ansvarlige personer;
- uavbrutt strømforsyning til servere er sikret
- normale klimatiske forhold for utstyrsdrift er sikret;
- det er brannalarm i serverrommet, det er ingen fare for flom (spesielt for første og siste etasje);
Innstillingene for nettverket og informasjonsinfrastrukturen til bedriften er riktig fullført:
- Brannmurer er installert og konfigurert på alle servere;
- alle brukere og datamaskiner er autorisert på nettverket, passord er komplekse nok til at de ikke kan gjettes;
- systemoperatører har nok rettigheter til å jobbe normalt med det, men har ikke rettigheter til administrative handlinger;
- antivirusverktøy er installert og aktivert på alle datamaskiner på nettverket;
- Det er ønskelig at brukere (unntatt nettverksadministratorer) ikke har administrative rettigheter på klientarbeidsstasjoner;
- tilgang til Internett og flyttbare lagringsmedier bør reguleres og begrenses;
- systemrevisjon av sikkerhetshendelser må konfigureres;
De viktigste organisatoriske problemene er løst:
- brukere har tilstrekkelige kvalifikasjoner til å jobbe med 1C og maskinvare;
- brukere blir varslet om ansvar for brudd på driftsreglene;
- det er utnevnt økonomisk ansvarlige personer for hvert vesentlig element i informasjonssystemet;
- alle systemenheter er forseglet og lukket;
- Vær spesielt oppmerksom på å instruere og føre tilsyn med renholdere, bygningsarbeidere og elektrikere. Disse personene kan ved uaktsomhet forårsake skade som ikke er sammenlignbar med den forsettlige skaden forårsaket av en useriøs bruker av systemet.

Merk følgende! Denne listen er ikke uttømmende, men beskriver bare hva som ofte går glipp av når du bruker et ganske komplekst og kostbart informasjonssystem!

MS SQL Server, applikasjonsserver og klientdel kjøres på forskjellige datamaskiner, serverapplikasjoner kjøres under rettighetene til spesielt opprettede Windows-brukere;
For MS SQL Server
- blandet autorisasjonsmodus er satt
- MS SQL-brukere inkludert i serveradmin-rollen deltar ikke i 1C-arbeid,
- for hver IB 1C er det opprettet en separat MS SQL-bruker som ikke har privilegert tilgang til serveren,
- MS SQL-bruker av en IS har ikke tilgang til andre IS;
Brukere har ikke direkte tilgang til applikasjonsserver- og MS SQL-serverfiler
Operatørarbeidsstasjoner er utstyrt med Windows 2000/XP (ikke Windows 95/98/Me)

Ikke overse anbefalingene fra systemutviklerne og les dokumentasjonen. Viktig materiale om oppsett av systemet er publisert på ITS-disker i delen "Metodeanbefalinger". Vær spesielt oppmerksom på følgende artikler:

Funksjoner til applikasjoner som jobber med 1C:Enterprise-serveren
Dataplassering 1C:Enterprise 8.0
Oppdatering 1C:Enterprise 8.0 av Microsoft Windows-brukere uten administratorrettigheter
Redigering av brukerlisten på vegne av en bruker som ikke har administrative rettigheter
Konfigurere Windows XP SP2 brannmurinnstillinger for å kjøre SQL Server 2000 og SQL Server Desktop Engine (MSDE)
Konfigurere COM+ Windows XP SP2-parametere for å kjøre 1C:Enterprise 8.0-serveren
Konfigurere Windows XP SP2-brannmurinnstillinger for 1C:Enterprise 8.0-serveren
Konfigurere Windows XP SP2 brannmurinnstillinger for HASP License Manager
Opprette en sikkerhetskopi av en infobase ved hjelp av SQL Server 2000
Installasjons- og konfigurasjonsproblemer 1C:Enterprise 8.0 i "klient-server"-versjonen(en av de viktigste artiklene)
Funksjoner for å sette opp Windows Server 2003 ved installasjon av 1C:Enterprise 8.0-server
Regulering av brukertilgang til informasjonsbasen i klient-serverversjonen(en av de viktigste artiklene)
Server 1C: Enterprise og SQL server
Detaljert installasjonsprosedyre for 1C:Enterprise 8.0 i "klient-server"-versjonen(en av de viktigste artiklene)
Bruker det innebygde språket på 1C:Enterprise-serveren

Men når du leser dokumentasjonen, vær kritisk til informasjonen som mottas, for eksempel, artikkelen "Problemer med å installere og konfigurere 1C: Enterprise 8.0 i klient-serverversjonen" beskriver ikke nøyaktig rettighetene som kreves for brukeren USER1CV8SERVER. Det vil være lenker til listen nedenfor, for eksempel betyr [ITS1] artikkelen "Funksjoner av applikasjoner som arbeider med 1C:Enterprise-serveren". Alle lenker til artikler er gitt til siste utgave av ITS i skrivende stund (januar 2006)

Bruk autorisasjonsfunksjoner kombinert med Windows-autorisasjon for brukere

Av de to mulige brukerautorisasjonsmodusene: innebygd 1C og kombinert med Windows OS-autorisasjon, hvis mulig, bør du velge kombinert autorisasjon. Dette vil tillate brukere å ikke forveksles med flere passord når de jobber, men vil ikke redusere nivået av systemsikkerhet. Men selv for brukere som bare bruker Windows-autorisasjon, er det sterkt tilrådelig å angi et passord når du oppretter det, og først etter det deaktivere 1C-autorisasjon for denne brukeren. For å sikre systemgjenoppretting i tilfelle ødeleggelse av Active Directory-strukturen, er det nødvendig å forlate minst én bruker som kan logge på systemet ved hjelp av 1C-autorisasjon.

Når du oppretter applikasjonsløsningsroller, ikke legg til rettigheter "i reserve"

Hver applikasjonsløsningsrolle må gjenspeile det minste nødvendige settet med rettigheter for å utføre handlingene definert av denne rollen. Noen roller kan imidlertid ikke brukes uavhengig. For å for eksempel kjøre eksterne prosessorer interaktivt, kan du opprette en egen rolle og legge den til alle brukere som trenger å bruke eksterne prosessorer.

Gjennomgå regelmessig logger og systemdriftsprotokoller

Hvis mulig, reguler og automatiser visningen av logger og systemdriftsprotokoller. Med riktig konfigurasjon og regelmessig gjennomgang av logger (filtrering kun etter viktige hendelser), kan uautoriserte handlinger oppdages tidlig eller til og med forhindres i forberedelsesfasen.

Noen funksjoner i klient-serverversjonen

Denne delen beskriver noen av driftsfunksjonene til klient-server-alternativet og deres innvirkning på sikkerheten. For å gjøre det enklere å lese, brukes følgende notasjoner:

Merk følgende! sårbarhetsbeskrivelse

Lagre informasjon som styrer tilgangen til systemet

Lagre en liste over brukere av informasjonssikkerhet

All informasjon om listen over brukere av denne informasjonssikkerheten og rollene som er tilgjengelige for dem i den, lagres i Params-tabellen i MS SQL-databasen (se [ITS2]). Når man ser på strukturen og innholdet i denne tabellen, blir det åpenbart at all brukerinformasjon er lagret i en post med filnavn-feltverdien "users.usr".

Siden vi antar at brukere ikke har tilgang til MS SQL-databasen, kan dette faktum i seg selv ikke brukes av en angriper, men hvis det er mulig å kjøre kode i MS SQL, "åpner dette døren" for å få noen(! ) tilgang fra 1C. Den samme mekanismen (med mindre endringer) kan også brukes i filversjonen av systemet, som, tatt i betraktning funksjonene til filversjonen, fullstendig utelukker dens anvendelighet i å bygge sikre systemer.

Anbefaling: For øyeblikket er det ingen måte å fullstendig beskytte applikasjonen mot slike endringer, bortsett fra bruk av triggere på MS SQL Server-nivå, som derimot kan forårsake problemer ved oppdatering av plattformversjonen eller endring av listen over brukere. For å spore slike endringer kan du bruke 1C-loggen (ta hensyn til "mistenkelige" pålogginger i konfiguratormodus uten å spesifisere brukeren) eller holde SQL Profiler konstant i gang (som vil ha en ekstremt negativ innvirkning på systemytelsen) eller konfigurere varslene mekanisme (mest sannsynlig sammen ved hjelp av triggere)

Lagre informasjon om IS-listen på serveren

For hver 1C-applikasjonsserver lagres informasjon om listen over MS SQL-databaser som er koblet til den. Hver infobase bruker sin egen tilkoblingsstreng fra applikasjonsserveren og MS SQL-serveren for å operere. Informasjon om infobaser registrert på applikasjonsserveren, sammen med tilkoblingsstrenger, lagres i filen srvrib.lst, som ligger på serveren i katalogen<Общие данные приложений>/1C/1Cv8 (for eksempel C:/Dokumenter og innstillinger/Alle brukere/Applikasjonsdata/1C/1Cv8/srvrib.lst). For hvert informasjonssikkerhetssystem lagres en komplett tilkoblingsstreng, inkludert MS SQL-brukerpassordet ved bruk av en blandet MS SQL-autorisasjonsmodell. Det er tilstedeværelsen av denne filen som gjør det mulig å frykte uautorisert tilgang til MS SQL-databasen, og hvis, i motsetning til anbefalinger, en privilegert bruker (for eksempel "sa") brukes til å få tilgang til minst én database, så i i tillegg til trusselen mot én informasjonssikkerhet, er det en trussel mot hele systemet som bruker MS SQL.

Det er interessant å merke seg at bruk av blandet autorisasjon og Windows-autorisasjon på en MS SQL-server fører til ulike typer problemer når man får tilgang til en gitt fil. Så de viktigste negative egenskapene til Windows-autorisasjon vil være:

Drift av all informasjonssikkerhet på applikasjonsserveren og på MS SQL-serveren under ett sett med rettigheter (mest sannsynlig redundant)
Fra 1C-applikasjonsserverprosessen (eller generelt fra brukeren USER1CV8SERVER eller tilsvarende) uten å spesifisere et passord, kan du enkelt koble til enhver informasjonssikkerhet uten å spesifisere et passord

På den annen side kan det være vanskeligere for en angriper å kjøre vilkårlig kode fra konteksten til brukeren USER1CV8SERVER enn å få tak i den angitte filen. Forresten, tilstedeværelsen av en slik fil er et annet argument for å distribuere serverfunksjoner på forskjellige datamaskiner.

Anbefaling: Filen srvrib.lst skal bare være tilgjengelig av serverprosessen. Sørg for å konfigurere revisjon for å endre denne filen.

Dessverre er denne filen som standard nesten ikke beskyttet mot lesing, noe som må tas i betraktning når du distribuerer systemet. Det ideelle alternativet ville være at applikasjonsserveren forhindrer lesing og skriving av denne filen mens den kjører (inkludert lesing og skriving av brukerforbindelser som kjører på denne serveren).

Manglende autorisasjon ved opprettelse av informasjonssikkerhet på serveren

Merk følgende! Mangelen på autorisasjonsfeil ble rettet i versjon 8.0.14 av 1C:Enterprise-plattformen. I denne utgivelsen dukket konseptet "1C:Enterprise Server Administrator" opp, men så lenge listen over administratorer er spesifisert på serveren, fungerer systemet som beskrevet nedenfor, så ikke glem denne mulige funksjonen.

Sannsynligvis den største sårbarheten fra denne delen er muligheten til nesten ubegrenset å legge til informasjonssikkerhet til applikasjonsserveren, som et resultat av at enhver bruker som får tilgang til en tilkobling til applikasjonsserveren automatisk får muligheten til å kjøre vilkårlig kode på applikasjonsserveren . La oss se på dette med et eksempel.

Systemet må installeres som følger

MS SQL Server 2000 (for eksempel nettverksnavn SRV1)
Server 1C:Enterprise 8.0 (nettverksnavn SRV2)
Klientdel 1C:Enterprise 8.0 (nettverksnavn WS)

Det forutsettes at brukeren (heretter kalt BRUKER) som arbeider på WS har minst minimal tilgang til ett av informasjonssikkerhetssystemene som er registrert på SRV2, men ikke har privilegert tilgang til SRV1 og SRV2. Generelt sett påvirker ikke kombinasjonen av funksjonene til de listede datamaskinene situasjonen. Systemet ble konfigurert under hensyntagen til anbefalingene i dokumentasjonen og på ITS-diskene. Situasjonen er vist i fig. 2.

konfigurere COM+-sikkerhet på applikasjonsserveren slik at bare 1C-brukere har rett til å koble til applikasjonsserverprosessen (mer detaljer [ITS12]);

filen srvrib.lst må være skrivebeskyttet for brukeren USER1CV8SERVER (for å legge til en ny informasjonssikkerhet til serveren, tillate midlertidig skriving);

For å koble til MS SQL, bruk kun TCP/IP-protokollen, i dette tilfellet kan du:
begrense tilkoblinger ved hjelp av en brannmur;

konfigurere bruken av en ikke-standard TCP-port, noe som vil komplisere tilkoblingen til "utenforstående" IB 1C;

bruke kryptering av overførte data mellom applikasjonsserveren og SQL-serveren;

konfigurere serverbrannmuren slik at bruk av tredjeparts MS SQL-servere er umulig;

bruke intranettsikkerhetsverktøy for å utelukke muligheten for at en uautorisert datamaskin dukker opp på det lokale nettverket (IPSec, gruppesikkerhetspolicyer, brannmurer osv.);

Ikke under noen omstendigheter gi brukeren USER1CV8SERVER administrative rettigheter på applikasjonsserveren.

Bruker kode som kjører på serveren

Når du bruker klient-serverversjonen av 1C, kan utvikleren distribuere kodekjøring mellom klienten og applikasjonsserveren. For at koden (prosedyren eller funksjonen) bare skal kjøres på serveren, er det nødvendig å plassere den i en generell modul som "Server"-egenskapen er satt for, og i tilfelle modulkjøring ikke bare er tillatt på serveren, plasser koden i den begrensede delen "#If Server ":

#Hvis server da
Funksjon OnServer(Param1, Param2 = 0) Eksport // Denne funksjonen, til tross for sin enkelhet, utføres på serveren
Param1 = Param1 + 12;
Returner Param1;
EndFunction
#TheEndIf

Når du bruker kode som kjører på serveren, må du ta hensyn til at:

koden kjører med USER1CV8SERVER-rettigheter på applikasjonsserveren (COM-objekter og serverfiler er tilgjengelige);
alle brukersesjoner utføres av én forekomst av tjenesten, så for eksempel vil en stackoverflyt på serveren føre til at alle aktive brukere kobler fra;
feilsøking av servermoduler er vanskelig (for eksempel kan du ikke sette et bruddpunkt i feilsøkeren), men må gjøres;
overføring av kontroll fra klienten til applikasjonsserveren og tilbake kan kreve betydelige ressurser med store mengder overførte parametere;
bruk av interaktive verktøy (skjemaer, regnearkdokumenter, dialogbokser), eksterne rapporter og prosessering i kode på applikasjonsserveren er umulig;
bruk av globale variabler (applikasjonsmodulvariabler deklarert med indikasjonen "Eksporter") er ikke tillatt;

For flere detaljer, se [ITS15] og andre ITS-artikler.

Applikasjonsserveren må ha spesielle krav til pålitelighet. I et riktig bygget klient-serversystem må følgende betingelser være oppfylt:

ingen handlinger fra klientapplikasjonen skal avbryte driften av serveren (bortsett fra administrative tilfeller);
serveren kan ikke kjøre programkode mottatt fra klienten;
ressurser må være "rettferdig" fordelt på tvers av klientforbindelser, og sikre servertilgjengelighet uavhengig av gjeldende belastning;
i fravær av datablokkering bør ikke klientforbindelser påvirke hverandres arbeid;
serveren har ikke et brukergrensesnitt, men overvåkings- og loggingsverktøy må utvikles;

Generelt er 1C-systemet bygget på en slik måte at det kommer nærmere disse kravene (det er for eksempel umulig å tvinge ekstern behandling til å utføres på serveren), men flere ubehagelige funksjoner eksisterer fortsatt, derfor:

Anbefaling: Når du utvikler en kjøretidsserver, anbefales det å følge prinsippet om minimalt grensesnitt. De. antall oppføringer i servermoduler fra klientapplikasjonen bør være svært begrenset, og parametrene bør være strengt regulert. Anbefaling: Når du mottar parametere for prosedyrer og funksjoner på serveren, er det nødvendig å validere parameterne (sjekk at parameterne samsvarer med forventet type og verdiområde). Dette gjøres ikke i standardløsninger, men det er svært ønskelig å innføre obligatorisk validering i egen utvikling. Anbefaling: Når du genererer forespørselstekst (og spesielt Kjør-kommandoparameteren) på serversiden, ikke bruk strenger mottatt fra klientapplikasjonen.

En generell anbefaling vil være å gjøre deg kjent med prinsippene for å bygge sikkert web-databaseapplikasjoner og arbeid etter lignende prinsipper. Likhetene er faktisk betydelige: For det første, som en webapplikasjon, er applikasjonsserveren et mellomlag mellom databasen og brukergrensesnittet (hovedforskjellen er at webserveren danner brukergrensesnittet); for det andre, fra et sikkerhetssynspunkt, kan du ikke stole på dataene som mottas fra klienten, fordi det er mulig å lansere eksterne rapporter og behandling.

Passerer parametere

Å sende parametere til en funksjon (prosedyre) utført på serveren er et ganske delikat problem. Dette skyldes først og fremst behovet for å overføre dem mellom applikasjonsserveren og klientprosessene. Når kontrollen går fra klientsiden til serversiden, blir alle overførte parametere serialisert, overført til serveren, hvor de "pakkes ut" og brukes. Når du flytter fra serversiden til klientsiden, blir prosessen reversert. Det skal bemerkes her at denne ordningen håndterer overføringsparametere korrekt ved referanse og etter verdi. Når du sender parametere, gjelder følgende begrensninger:

Bare ikke-foranderlige verdier (dvs. hvis verdier ikke kan endres) kan overføres mellom klienten og serveren (i begge retninger): primitive typer, referanser, universelle samlinger, systemoppregningsverdier, verdilagring. Hvis du prøver å sende noe annet, krasjer klientapplikasjonen (selv om serveren prøver å sende en feil parameter).
Det anbefales ikke å overføre store mengder data når parametere sendes (for eksempel strenger på mer enn 1 million tegn), dette kan påvirke serverytelsen negativt.
Du kan ikke sende parametere som inneholder en syklisk referanse, både fra serveren til klienten og tilbake. Hvis du prøver å sende en slik parameter, krasjer klientapplikasjonen (selv om serveren prøver å sende feil parameter).
Det anbefales ikke å overføre svært komplekse datainnsamlinger. Når du prøver å sende en parameter med et veldig stort nestenivå, krasjer serveren (! ).

Merk følgende! Det mest irriterende for øyeblikket er sannsynligvis feilen ved å sende komplekse verdisamlinger. Så, for eksempel, koden: Nesting Level = 1250;
M = New Array;
PassedParameter = M;
For konto = 1 etter nivå av hekkesyklus
MVInt = New Array;
M.Add(MVInt);
M = MVint;
EndCycle;
ServerFunction(PassedParameter);

Fører til en nødstopp av serveren med utkobling av alle brukere, og dette skjer før kontrollen overføres til koden i det innebygde språket.

Bruker usikre funksjoner på serversiden.

Ikke alle innebygde språkverktøy kan brukes i kode som kjøres på applikasjonsserveren, men selv blant de tilgjengelige verktøyene er det mange "problematiske" konstruksjoner som grovt sett kan klassifiseres som følger:

i stand til å gi muligheten til å kjøre kode som ikke finnes i konfigurasjonen ("Code Execution"-gruppen)
i stand til å gi klientapplikasjonen informasjon om brukerens fil og operativsystem eller utføre handlinger som ikke er relatert til arbeid med data («Rettighetsbrudd»)
i stand til å forårsake serverkrasj eller bruke svært store ressurser ("serverkrasj"-gruppe)
i stand til å forårsake klientfeil (klientfeilgruppe) – denne typen vurderes ikke. Eksempel: overføre en mutbar verdi til serveren.
feil i programmeringsalgoritmer (endeløse looper, ubegrenset rekursjon osv.) ("Programmeringsfeil")

De viktigste problematiske designene jeg kjenner (med eksempler) er listet opp nedenfor:

Prosedyre Utfør(<Строка>)

Utfører kode. Lar deg kjøre et stykke kode som sendes til det som en strengverdi. Når den brukes på serveren, må du sørge for at data mottatt fra klienten ikke brukes som parameter. Følgende bruk er for eksempel ikke tillatt:
#Hvis server da
ProcedureOnServer(Param1) Eksport
Utfør(Param1);
Slutt på prosedyre
#TheEndIf

Skriv "COMObject" (konstruktør Ny COMObject(<Имя>, <Имя сервера>))

Oppretter et eksternt applikasjons-COM-objekt med USER1CV8SERVER-rettigheter på applikasjonsserveren (eller annen spesifisert datamaskin). Når det brukes på en server, sørg for at parametere ikke sendes fra klientapplikasjonen. På serversiden er det imidlertid effektivt å bruke denne funksjonen ved import/eksport, sending av data over Internett, implementering av ikke-standardiserte funksjoner, etc.

Funksjonen GetCOMObject(<Имя файла>, <Имя класса COM>)

Rettighetsbrudd og utførelse av kode. I likhet med den forrige, får du bare COM-objektet som tilsvarer filen.

Prosedyrer og funksjoner ComputerName(), TemporaryFileDirectory(), ProgramDirectory(), WindowsUsers()

Rettighetsbrudd. Ved å utføre dem på serveren, lar de deg finne ut detaljene om organisasjonen av serverundersystemet. Når den brukes på en server, sørg for at dataene enten ikke overføres til klienten eller ikke er tilgjengelige for operatører uten passende tillatelse. Vær spesielt oppmerksom på at data kan sendes tilbake i en parameter sendt ved referanse.

Prosedyrer og funksjoner for arbeid med filer (CopyFile, FindFiles, MergeFiles og mange andre), samt filtyper.

Rettighetsbrudd. De tillater, ved å kjøre dem på serveren, å få delt tilgang til lokale (og plassert på nettverket) filer tilgjengelig under brukerrettighetene USER1CV8SERVER. Hvis det brukes bevisst, er det mulig å effektivt implementere oppgaver som å importere/eksportere data på serveren.

Sørg for å sjekke 1C-brukerrettighetene dine før du bruker disse funksjonene. For å sjekke brukerrettigheter kan du bruke følgende konstruksjon i servermodulen:
#Hvis server da
Prosedyre PerformWorkWithFile() Export
RoleAdministrator = Metadata.Roles.Administrator;
User = SessionParameters.CurrentUser;
Hvis User.Roles.Contains(RoleAdministrator) Da
//Koden for arbeid med filer kjøres her
slutt om;
#TheEndIf
Sørg for å sjekke parametrene hvis du bruker disse prosedyrene og funksjonene, ellers er det en risiko for ved et uhell eller bevisst å forårsake uopprettelig skade på 1C-applikasjonsserveren, for eksempel når du utfører følgende kode på serveren:
Path = "C:\Dokumenter og innstillinger\Alle brukere\Programdata\1C\1Cv8\";
MoveFile(Path + "srvrib.lst", Path + "Here'sWhereTheFileGoes");
Etter å ha utført en slik kode på serveren, hvis brukeren USER1CV8SERVER har rettighetene til å endre den, som beskrevet ovenfor, og etter å ha startet serverprosessen på nytt (som standard, 3 minutter etter at alle brukere går ut), vil det oppstå et STORT spørsmål om oppstart av serveren . Men det er også mulig å slette filer helt...

Typer "XBase", "BinaryData", "XML Reader", "XML Writer", "XSL Transformation", "ZipFile Writer", "ZipFile Reader", "Text Reader", "Text Writer"

Rettighetsbrudd. De tillater, ved å kjøre dem på serveren, tilgang til lokale (og plassert på nettverket) filer av visse typer og lese/skrive dem under brukerrettighetene USER1CV8SERVER. Hvis det brukes bevisst, er det mulig å effektivt implementere slike oppgaver som å importere/eksportere data på serveren, logge driften av visse funksjoner og løse administrative oppgaver. Generelt faller anbefalingene sammen med forrige avsnitt, men du bør vurdere muligheten for å overføre data fra disse filene (men ikke objekter av alle disse typene) mellom klient- og serverdelen.

Skriv "SystemInformation"

Rettighetsbrudd. Lar deg innhente data om applikasjonsserveren ved feil bruk og overføring av data til klientdelen av applikasjonen. Det er lurt å begrense bruksretten ved bruk.

Typer "InternetConnection", "InternetMail", "InternetProxy", "HTTPConnection", "FTPConnection"

Rettighetsbrudd. Når den brukes på en server, kobles den til en ekstern PC fra en applikasjonsserver under rettighetene USER1CV8SERVER. Anbefalinger:

Kontroll av parametere ved oppkalling av metoder.

Kontroll av 1C brukerrettigheter.

Sterke begrensninger på rettighetene til brukeren USER1CV8SERVER til å få tilgang til nettverket.

Riktig oppsett av brannmuren på 1C-applikasjonsserveren.

Når det brukes riktig, er det praktisk å organisere for eksempel å sende e-post fra en applikasjonsserver.

Typer "InformationBaseUserManager", "InformationBaseUser"

Rettighetsbrudd. Ved feil bruk (i en privilegert modul), er det mulig å legge til brukere eller endre autorisasjonsparametrene til eksisterende brukere.

Funksjonsformat

Serverkrasj. Ja! Denne tilsynelatende harmløse funksjonen, hvis parameterne ikke kontrolleres og kjøres på serveren, kan føre til at serverapplikasjonen krasjer. Feilen oppstår ved formatering av tall og bruk av modusen for å vise innledende nuller og et stort antall tegn, for eksempel
Format(1, "CHZ=999; CHVN=");
Jeg håper denne feilen vil bli rettet i de neste plattformutgivelsene, men i mellomtiden, i alle kall til denne funksjonen som kan utføres på serveren, sjekk anropsparametrene.

Prosedyrer og funksjoner for å lagre verdier (ValueInRowInt, ValueInFile)

Serverkrasj. Disse funksjonene håndterer ikke sirkulære referanser i samlinger eller veldig dype hekking, så de kan krasje i noen helt spesielle tilfeller.

Feil i grenseverdier og spesielle parameterverdier i funksjoner. Utførelseskontroll.

Et av problemene du kan støte på når du bruker en server er det høye "ansvaret" for serverfunksjoner (muligheten for at hele serverapplikasjonen krasjer på grunn av en feil i en tilkobling og bruk av ett "ressursrom" for alle tilkoblinger) . Derfor behovet for å kontrollere de viktigste kjøretidsparametrene:

For innebygde språkfunksjoner, sjekk startparametrene deres (et godt eksempel er "Format"-funksjonen)
Når du bruker løkker, sørg for at sløyfeutgangsbetingelsen er oppfylt. Hvis løkken er potensielt uendelig, begrenser du kunstig antall iterasjoner: MaximumIterationCounterValue = 1000000;
Iterasjonsteller = 1;
Ha det
FunctionWhichMayNotReturnFalseValue()
OG (Iterasjonsantall<МаксимальноеЗначениеСчетчикаИтераций) Цикл
//.... Hoveddelen av løkken
Iterasjonsteller = Iterasjonsteller + 1;
EndCycle;
If Iteration Counter>Maksimalverdi av Iteration Counter Da
//.... håndtere hendelsen med en for lang løkkekjøring
slutt om;
Når du bruker rekursjon, begrenser det maksimale hekkenivået.
Når du oppretter og utfører spørringer, prøv å forhindre svært lange valg og valg av store mengder informasjon (ikke bruk en tom verdi for eksempel når du bruker "IN HIERARCHY"-betingelsen)
Når du designer en informasjonsbase, gi en tilstrekkelig stor reserve av bitdybde for tall (ellers blir addisjon og multiplikasjon ikke-kommutativ og ikke-assosiativ, noe som gjør feilsøking vanskelig)
I kjørbare spørringer, sjekk operasjonslogikken for tilstedeværelsen av NULL-verdier og korrekt drift av spørringsbetingelser og uttrykk ved å bruke NULL.
Når du bruker samlinger, kontroller muligheten til å overføre dem mellom applikasjonsserveren og klientsiden.

Bruke terminaltilgang til klientsiden for å begrense tilgangen

Du kan ofte finne anbefalinger for å bruke terminaltilgang for å begrense tilgangen til data og forbedre ytelsen ved å kjøre klientsidekode på terminalserveren. Ja, hvis den er konfigurert riktig, kan bruken av terminaltilgang faktisk øke det generelle nivået av systemsikkerhet, men dessverre kan du ofte støte på det faktum at med praktisk bruk, reduseres sikkerheten til systemet bare. La oss prøve å finne ut hva dette henger sammen med. Nå er det to vanlige måter å organisere terminaltilgang på, disse er Microsoft Terminal Services (RDP-protokoll) og Citrix Metaframe Server (ICA-protokoll). Generelt gir Citrix-verktøy mye mer fleksiblever, men prisen på disse løsningene er mye høyere. Vi vil kun vurdere de grunnleggende funksjonene som er felles for begge protokollene som kan redusere det generelle sikkerhetsnivået. Det er bare tre hovedfarer ved bruk av terminaltilgang:

Evne til å blokkere arbeidet til andre brukere ved å beslaglegge for store mengder ressurser
Tilgang til andre brukeres data.
Uautorisert kopiering av data fra terminalserveren til brukerens datamaskin

I alle fall lar Terminal Services deg:

Øk påliteligheten til arbeidet (hvis det er en feil på terminaldatamaskinen, kan brukeren fortsette å jobbe fra samme sted)
Begrens tilgangen til klientapplikasjonen og filene den lagrer.
Overfør databelastningen fra brukerens arbeidsstasjon til terminaltilgangsserveren
Administrer systeminnstillinger mer sentralt. For brukere vil de lagrede innstillingene være gyldige uavhengig av hvilken datamaskin de logget på systemet fra.
I noen tilfeller kan du bruke en terminalløsning for ekstern tilgang til systemet.

Det er nødvendig å begrense antall mulige tilkoblinger til terminalserveren for én bruker

På grunn av "frasseri" til 1C-klientapplikasjonen med hensyn til ressurser, er det viktig å begrense det maksimale antallet samtidige tilkoblinger for én bruker (operatør) til terminalserveren. En aktivt brukt tilkobling kan bruke opptil 300 MB minne med bare én forekomst av applikasjonen. I tillegg til minne, brukes CPU-tid aktivt, noe som heller ikke bidrar til stabiliteten til brukerne av denne serveren. Samtidig som man forhindrer overdreven bruk av serverressurser, kan en slik begrensning hindre andres konto i å bli brukt. Implementert av standard terminalserverinnstillinger.

Du bør ikke tillate mer enn én eller to 1C-klientapplikasjoner å kjøre samtidig i én tilkobling

Diktert av samme grunner som i forrige avsnitt, men teknisk vanskeligere å implementere. Problemet er at det er nesten umulig å forhindre at 1C startes på nytt ved hjelp av terminalserververktøy (hvorfor vil bli forklart nedenfor), så du må implementere denne funksjonen på nivå med applikasjonsløsningen (som heller ikke er en god løsning, siden økter kan forbli «hengende» en stund. Hvis applikasjonen avsluttes feil, er det behov for å avgrense applikasjonsløsningen i applikasjonsmodulen og noen oppslagsverk, noe som vil komplisere bruken av oppdateringer fra 1C). Det er svært ønskelig å la brukeren kunne kjøre 2 applikasjoner for å kunne kjøre noen handlinger (for eksempel generere rapporter) i bakgrunnen - klientapplikasjonen er dessverre en-trådet.

Det anbefales ikke å gi tilgangsrettigheter til terminalserveren til brukere som har rett til å kjøre ressurskrevende dataoppgaver i 1C eller for å forhindre slik lansering mens andre brukere jobber aktivt.

Selvfølgelig er det bedre å overlate tilgang til terminalserveren kun til brukere som ikke bruker oppgaver som datautvinning, geografiske diagrammer, import/eksport og andre oppgaver som seriøst belaster klientdelen av applikasjonen. Hvis det fortsatt er behov for å løse slike oppgaver, er det nødvendig å: varsle brukeren om at disse oppgavene kan påvirke ytelsen til andre brukere, registrere starten og slutten av en slik prosess i loggen, kun tillate utførelse ved en regulert tid osv.

Det er nødvendig å sørge for at hver bruker kun har skriverettigheter til strengt definerte kataloger på terminalserveren og at andre brukere ikke har tilgang til dem.

For det første, hvis du ikke begrenser muligheten til å skrive til delte kataloger (for eksempel katalogen der 1C er installert), er det fortsatt mulig for en angriper å endre oppførselen til programmet for alle brukere. For det andre skal dataene til én bruker (midlertidige filer, filer for lagring av rapportinnstillinger osv.) under ingen omstendigheter være tilgjengelig for en annen bruker av terminalserveren - generelt, under normal konfigurasjon, følges denne regelen. For det tredje har angriperen fortsatt muligheten til å "kaste" partisjonen slik at det ikke er plass igjen på harddisken. Jeg vet at de vil protestere mot meg at Windows-operativsystemet, som starter med Windows 2000, har en kvotemekanisme, men dette er en ganske dyr mekanisme, og jeg har praktisk talt aldri sett noen reell bruk av den.

Hvis de tidligere problemene med å sette opp tilgang generelt sett var ganske enkle å implementere, er en så (tilsynelatende) enkel oppgave som å regulere brukertilgang til filer ikke trivielt implementert. For det første, hvis kvotemekanismen ikke brukes, kan store filer lagres. For det andre er systemet bygget på en slik måte at det nesten alltid vil være mulig å lagre filen slik at den er tilgjengelig for en annen bruker.

Med tanke på at oppgaven er vanskelig å løse fullstendig, anbefales det å revidere de fleste filhendelser

Det er nødvendig å forby tilkobling (tilordning) av diskenheter, skrivere og utklippstavlen til klientarbeidsstasjonen.

I RDP og ICA er det mulig å organisere automatisk tilkobling av disker, skrivere, utklippstavle com-porter på terminaldatamaskinen til serveren. Hvis denne muligheten eksisterer, er det nesten umulig å forhindre lansering av utenlandsk kode på terminalserveren og lagring av data fra 1C på terminaltilgangsklienten. Tillat disse funksjonene kun for de med administrative rettigheter.

Nettverksfiltilgang fra terminalserveren bør begrenses.

Hvis dette ikke gjøres, vil brukeren igjen kunne kjøre uønsket kode eller lagre data. Siden den vanlige loggen ikke sporer filhendelser (forresten, en god idé for implementering av plattformutviklere), og det er nesten umulig å sette opp en systemrevisjon gjennom hele nettverket (det er ikke nok ressurser til å vedlikeholde det), det er bedre at brukeren kan sende data enten til utskrift eller via e-post. Vær spesielt oppmerksom på å sikre at terminalserveren ikke fungerer direkte med brukernes flyttbare medier.

Under ingen omstendigheter bør du la applikasjonsserveren være på terminalserveren når du oppretter et sikkert system.

Hvis applikasjonsserveren kjører på samme datamaskin som klientapplikasjoner, er det mange muligheter for å forstyrre dens normale drift. Hvis det av en eller annen grunn er umulig å skille funksjonene til terminalserveren og applikasjonsserveren, vær spesielt oppmerksom på brukertilgang til filer som brukes av applikasjonsserveren.

Det er nødvendig å utelukke muligheten for å kjøre alle applikasjoner unntatt 1C:Enterprise på terminalserveren.

Dette er et av de vanskeligste ønskene å gjennomføre. La oss starte med det faktum at du må konfigurere gruppesikkerhetspolicyen på riktig måte i domenet. Alle administrative maler og retningslinjer for programvarerestriksjoner må konfigureres riktig. For å teste deg selv, sørg for at minst følgende funksjoner er blokkert:

Kompleksiteten ved å implementere dette kravet fører ofte til muligheten for å starte en "ekstra" 1C-sesjon på terminalserveren (selv om andre applikasjoner er begrenset, er det fundamentalt umulig å forby lansering av 1C ved bruk av Windows).

Vurder begrensningene til den vanlige loggen (alle brukere bruker programmet fra én datamaskin)

Siden brukere åpner 1C i terminalmodus, vil åpenbart terminalserveren bli registrert i loggen. Loggen angir ikke hvilken datamaskin brukeren koblet fra.

Terminal Server – Beskyttelse eller sårbarhet?

Så, etter å ha vurdert hovedtrekkene til terminalen nord, kan vi si at terminalen nord potensielt kan hjelpe med automatisering for å distribuere databelastningen, men å bygge et sikkert system er ganske vanskelig. Et av tilfellene når bruk av en terminalserver er mest effektivt er når du kjører 1C uten Windows Utforsker i fullskjermmodus for brukere med begrenset funksjonalitet og et spesialisert grensesnitt.

Arbeid av klientdelen

Bruke Internet Explorer (IE)

En av betingelsene for normal drift av 1C-klientdelen er bruken av Internet Explorer-komponenter. Du må være veldig forsiktig med disse komponentene.

Merk følgende! For det første, hvis en spyware- eller adware-modul er "koblet" til IE, vil den lastes selv om du viser HTML-filer i 1C. Så langt har jeg ikke sett noen bevisst bruk av denne funksjonen, men jeg har sett i en av organisasjonene en lastet "spion"-modul fra et av de pornografiske nettverkene med 1C kjørende (antivirusprogrammet ble ikke oppdatert, symptomer som ble oppdaget : når du satte opp brannmuren, var det tydelig at 1C prøvde på port 80 koble til et pornonettsted). Egentlig er dette enda et argument for at vernet bør være omfattende

Merk følgende! For det andre tillater 1C-systemet bruk av Flash-filmer, ActiveX-objekter, VBScript i viste HTML-dokumenter, sending av data til Internett, til og med åpning av PDF-filer (!), selv om det i sistnevnte tilfelle spør "åpne eller lagre"... Generelt, hva hjertet ditt begjærer. Et eksempel på en ikke helt rimelig bruk av de innebygde HTML-visnings- og redigeringsmulighetene:

Opprett et nytt HTML-dokument (Fil -> Nytt -> HTML-dokument).
Gå til "Tekst"-fanen i et tomt dokument.
Fjern teksten (helt).
Gå til "Vis"-fanen i dette dokumentet
Bruk dra-n-slipp, flytt en fil med en SWF-utvidelse (dette er Flash-filmfiler) fra en åpen Utforsker til et dokumentvindu, for eksempel fra nettleserbufferen, selv om du også kan bruke et FLASH-leketøy for moro skyld.
Så flott! Du kan kjøre et leketøy på 1C!

Fra et systemsikkerhetssynspunkt er dette helt feil. Så langt har jeg ikke sett noen spesielle angrep på 1C gjennom denne sårbarheten, men mest sannsynlig vil det være et spørsmål om tid og verdien av informasjonen din.

Det er noen andre mindre problemer som oppstår når du arbeider med et HTML-dokumentfelt, men de viktigste er de to som er oppført. Selv om du nærmer deg disse funksjonene kreativt, kan du organisere virkelig fantastiske grensesnittfunksjoner for å jobbe med 1C.

Bruk av eksterne rapporter og behandling.

Merk følgende! Eksterne rapporter og behandling - på den ene siden er de en praktisk måte å implementere ytterligere trykte skjemaer, forskriftsrapportering og spesialiserte rapporter på, på den andre siden er de en potensiell måte å omgå mange systemsikkerhetsbegrensninger og forstyrre applikasjonens drift server (for et eksempel, se ovenfor i "Passerende parametere"). I 1C-systemet er det en spesiell parameter i settet med rettigheter for rollen "Interaktiv åpning av ekstern behandling", men dette løser ikke helt problemet - for en fullstendig løsning er det nødvendig å begrense brukerkretsen som kan administrere eksterne trykte skjemaer, regulatoriske rapporter og andre standardmuligheter for standardløsninger implementert ved bruk av eksterne behandlinger. For eksempel, som standard i UPP, har alle hovedbrukerroller muligheten til å jobbe med en katalog med ekstra trykte skjemaer, og dette er faktisk muligheten til å bruke hvilken som helst ekstern behandling.

Bruke standardmekanismer for standardløsninger og plattformer (datautveksling)

Noen av standardmekanismene er potensielt farlige, og på uventede måter.

Utskrift av lister

Enhver liste (for eksempel en katalog eller informasjonsregister) i systemet kan skrives ut eller lagres i en fil. For å gjøre dette, bruk bare standardfunksjonen som er tilgjengelig fra kontekstmenyen og "Handlinger"-menyen:

Husk at praktisk talt alt som brukeren ser i listene kan sendes ut til eksterne filer. Det eneste vi kan gi råd er å føre en logg over dokumentutskrift på utskriftsservere. For spesielt kritiske former er det nødvendig å konfigurere handlingspanelet knyttet til det beskyttede tabellfeltet slik at muligheten til å vise en liste ikke er tilgjengelig fra dette panelet, og deaktivere kontekstmenyen (se figur 6).

Datautveksling i en distribuert database

Datautvekslingsformatet er ganske enkelt og er beskrevet i dokumentasjonen. Hvis brukeren har muligheten til å erstatte flere filer, kan han gjøre uautoriserte endringer i systemet (selv om dette er en ganske arbeidskrevende oppgave). Muligheten til å lage en perifer database ved bruk av distribuerte databaseutvekslingsplaner bør ikke være tilgjengelig for vanlige operatører.

Standard XML-datautveksling

I standard datautveksling, som brukes til utveksling mellom standardkonfigurasjoner (for eksempel "Trade Management" og "Enterprise Accounting"), er det mulig å spesifisere hendelsesbehandlere for lasting og lossing av objekter i utvekslingsreglene. Dette implementeres ved å hente en behandler fra filen og "Run()"-prosedyren for standardbehandling av fillasting og -lossing ("Run()"-prosedyren startes på klientsiden). Det er åpenbart ikke vanskelig å lage en slik falsk utvekslingsfil som vil utføre ondsinnede handlinger. For de fleste brukerrollene til standardløsninger er deling tillatt som standard.

Anbefaling: begrense tilgangen til XML-utveksling for de fleste brukere (overlater det kun tiltorer). Hold logger over lanseringene av denne behandlingen, lagre utvekslingsfilen, for eksempel, send den på e-post til inforfør nedlasting.

Bruke generiske rapporter, spesielt Reports Console

Et annet problem er standard brukertilgang til generiske rapporter, spesielt Rapportkonsoll-rapporten. Denne rapporten er preget av det faktum at den lar deg utføre nesten alle forespørsler til informasjonssikkerhet, og selv om 1C-rettighetssystemet (inkludert RLS) er konfigurert ganske strengt, lar det brukeren få mye "ekstra" informasjon og tvinge serveren til å utføre en forespørsel som vil forbruke alle ressurssystemer.

Bruke fullskjermmodus (skrivebordsmodus)

En av de effektive måtene å organisere spesialiserte grensesnitt med begrenset tilgang til programfunksjonaliteten er fullskjermmodusen til hovedformen (og muligens eneste) grensesnittet som brukes. I dette tilfellet er det ingen tilgjengelighetsproblemer, for eksempel "Fil"-menyen og alle brukerhandlinger er begrenset av egenskapene til skjemaet som brukes. For flere detaljer, se "Funksjoner ved implementering av skrivebordsmodus" på ITS-disken.

Sikkerhetskopiering

Sikkerhetskopiering for klient-serverversjonen av 1C kan utføres på to måter: laste opp data til en fil med dt-utvidelsen og lage sikkerhetskopier ved hjelp av SQL. Den første metoden har mange ulemper: eksklusiv tilgang er nødvendig, å lage en kopi i seg selv tar mye lengre tid, i noen tilfeller (hvis brytes) er det umulig å opprette et arkiv, men det er en fordel - minimumsstørrelsen på arkivet. For SQL-sikkerhetskopiering er det motsatte: Opprettelsen av en kopi skjer i bakgrunnen ved hjelp av SQL-serveren, på grunn av den enkle strukturen og mangelen på komprimering - dette er en veldig rask prosess, og så lenge den fysiske integriteten til SQL-en databasen er ikke ødelagt, sikkerhetskopieringen utføres, men størrelsen på kopien faller sammen med den sanne størrelsen på informasjonssikkerheten i utvidet tilstand (komprimering utføres ikke). På grunn av de ekstra fordelene med MS SQL backup-systemet, er det mer tilrådelig å bruke det (3 typer sikkerhetskopier er tillatt: full, differensiell, transaksjonsloggkopi; det er mulig å lage regelmessig utførte jobber; en sikkerhetskopi og en sikkerhetskopi systemet blir raskt distribuert; det er mulig å forutsi størrelsen på nødvendig diskplass, etc.). Hovedpunktene for å organisere en sikkerhetskopi fra et systemsikkerhetssynspunkt er:

Behovet for å velge et lagringssted for sikkerhetskopier slik at de ikke er tilgjengelige for brukere.
Behovet for å lagre sikkerhetskopier i fysisk avstand fra MS SQL-serveren (i tilfelle naturkatastrofer, branner, angrep osv.)
Muligheten til å gi rettigheter til å starte en sikkerhetskopi til en bruker som ikke har tilgang til sikkerhetskopier.

For mer informasjon, se MS SQL-dokumentasjonen.

Datakryptering

For å beskytte data mot uautorisert tilgang, brukes ofte ulike kryptografiske verktøy (både programvare og maskinvare), men deres gjennomførbarhet avhenger i stor grad av riktig applikasjon og den generelle sikkerheten til systemet. Vi vil se på datakryptering på ulike stadier av dataoverføring og lagring ved bruk av de vanligste midlene og hovedfeilene i systemdesign ved bruk av kryptografiske verktøy.

Det er flere hovedstadier av informasjonsbehandling som kan beskyttes:

Dataoverføring mellom klientdelen av systemet og applikasjonsserveren
Overføre data mellom applikasjonsserveren og MS SQL Server
Data lagret på MS SQL Server (datafiler på fysisk disk)
Kryptering av data lagret i informasjonssikkerhet
Eksterne data (i forhold til informasjonssikkerhet)

For data som er lagret på klientsiden og på applikasjonsserveren (lagrede brukerinnstillinger, liste over informasjonssikkerhet osv.), er kryptering kun berettiget i svært sjeldne tilfeller og vurderes derfor ikke her. Når du bruker kryptografiske verktøy, må vi ikke glemme at bruken av dem kan redusere ytelsen til systemet som helhet betydelig.

Generell informasjon om kryptografisk beskyttelse av nettverkstilkoblinger ved bruk av TCP/IP-protokollen.

Uten sikkerhet er alle nettverksforbindelser sårbare for uautorisert overvåking og tilgang. For å beskytte dem kan du bruke datakryptering på nettverksprotokollnivå. For å kryptere data som overføres på et lokalt nettverk, brukes oftest IPSec-verktøy levert av operativsystemet.

IPSec-verktøy gir kryptering av overførte data ved hjelp av DES- og 3DES-algoritmer, samt integritetsverifisering ved hjelp av MD5- eller SHA1-hash-funksjoner. IPSec kan operere i to moduser: transportmodus og tunnelmodus. Transportmodus er bedre egnet for å sikre tilkoblinger på et lokalt nettverk. Tunnelmodus kan brukes til å organisere VPN-tilkoblinger mellom separate nettverkssegmenter eller beskytte en ekstern tilkobling til et lokalt nettverk over åpne datakanaler.

De viktigste fordelene med denne tilnærmingen er:

Mulighet for sentralisert sikkerhetsstyring ved hjelp av Active Directory-verktøy.
Muligheten til å utelukke uautoriserte tilkoblinger til applikasjonsserveren og MS SQL-serveren (det er for eksempel mulig å beskytte mot uautorisert tillegg av informasjonssikkerhet på applikasjonsserveren).
Eliminering av "lytting" av nettverkstrafikk.
Det er ikke nødvendig å endre oppførselen til applikasjonsprogrammer (i dette tilfellet 1C).
Standardkarakteren til en slik løsning.

Denne tilnærmingen har imidlertid begrensninger og ulemper:

IPSec beskytter ikke data mot forstyrrelser og avlytting direkte på kilde- og måldatamaskiner.
Mengden data som overføres over nettverket er litt større enn uten bruk av IPSec.
Ved bruk av IPSec er belastningen på sentralprosessoren litt høyere.

En detaljert beskrivelse av implementeringen av IPSec-verktøy er utenfor rammen av denne artikkelen og krever en forståelse av de grunnleggende prinsippene for funksjonen til IP-protokollen. Les den relevante dokumentasjonen for å konfigurere tilkoblingssikkerheten.

Separat er det nødvendig å nevne flere aspekter av lisensavtalen med 1C når du organiserer VPN-tilkoblinger. Faktum er at, til tross for fravær av tekniske begrensninger, når du kobler flere segmenter av et lokalt nettverk eller ekstern tilgang til en individuell datamaskin til et lokalt nettverk, er det vanligvis nødvendig med flere grunnleggende forsyninger.

Kryptering av data ved overføring mellom klientdelen av systemet og applikasjonsserveren.

I tillegg til kryptering på nettverksprotokollnivå, er det mulig å kryptere data på COM+-protokollnivå, som er nevnt i artikkelen «Regulering av brukertilgang til informasjonsbasen i klient-serverversjonen» av ITS. For å implementere det, må du sette autentiseringsnivået for samtaler til "Packet Privacy" for 1CV8-applikasjonen i "Component Services". Når den er satt til denne modusen, blir pakken autentisert og kryptert, inkludert dataene og identiteten og signaturen til avsenderen.

Kryptering av data ved overføring mellom applikasjonsserveren og MS SQL Server

MS SQL Server tilbyr følgende verktøy for datakryptering:

Det er mulig å bruke Secure Sockets Layer (SSL) ved overføring av data mellom applikasjonsserveren og MS SQL Server.
Når du brukeret, brukes datakryptering på RPC-nivå. Dette er potensielt svakere kryptering enn å bruke SSL.
Hvis utvekslingsprotokollen for delt minne brukes (dette skjer hvis applikasjonsserveren og MS SQL Server er plassert på samme datamaskin), så brukes ikke kryptering i alle fall.

For å fastslå behovet for å kryptere alle overførte data for en spesifikk MS SQL-server, må du bruke verktøyet "Server Network Utility". Kjør den og på "Generelt"-fanen, merk av for "Force protocol encryption" avmerkingsboksen. Krypteringsmetoden velges avhengig av den som brukes av klientapplikasjonen (dvs. 1C-applikasjonsserveren). For å bruke SSL må du konfigurere sertifikattjenesten riktig på nettverket ditt.

For å angi behovet for å kryptere alle overførte data for en spesifikk applikasjonsserver, må du bruke verktøyet "Client Network Utility" (vanligvis plassert i "C:\WINNT\system32\cliconfg.exe"). Som i det forrige tilfellet, på "Generelt"-fanen, merk av for "Tving protokollkryptering".

Det er verdt å tenke på at bruk av kryptering i dette tilfellet kan ha en betydelig innvirkning på systemytelsen, spesielt ved bruk av spørringer som returnerer store mengder informasjon.

For å bedre beskytte forbindelsen mellom applikasjonsserveren og MS SQL Server ved bruk av TCP/IP-protokollen, kan vi anbefale flere endringer i standardinnstillingene.

For det første kan du angi en annen port enn standarden (port 1433 brukes som standard). Hvis du bestemmer deg for å bruke en ikke-standard TCP-port for datautveksling, vær oppmerksom på at:

MS SQL-serveren og applikasjonsserveren må bruke samme port.
Ved bruk av brannmurer må denne porten tillates.
Du kan ikke angi en port som kan brukes av andre applikasjoner på MS SQL-serveren. Som referanse kan du bruke http://www.ise.edu/in-notes/iana/assignments/port-numbers (adresse hentet fra SQL Server Books Online).
Når du bruker flere forekomster av MS SQL Server-tjenesten, sørg for å lese MS SQL-dokumentasjonen for konfigurasjon (avsnittet "Konfigurere nettverkstilkoblinger").

For det andre, i TCP/IP-protokollinnstillingene på MS SQL-serveren, kan du angi "Skjul server"-flagget, som forbyr svar på kringkastingsforespørsler for denne forekomsten av MS SQL Server-tjenesten.

Kryptering av MS SQL-data lagret på disk

Det er et ganske stort utvalg av programvare og maskinvare for kryptering av data som ligger på en lokal disk (dette inkluderer standard Windows-evne til å bruke EFS, bruk av eToken-nøkler og tredjepartsprogrammer som Jetico Bestcrypt eller PGPDisk). En av hovedoppgavene som utføres av disse verktøyene er å beskytte data ved tap av media (for eksempel når en server blir stjålet). Det er spesielt verdt å merke seg at Microsoft ikke anbefaler å lagre MS SQL-databaser på krypterte medier, og dette er ganske berettiget. Hovedproblemet med dette er et betydelig fall i ytelse og mulige pålitelighetsproblemer på grunn av feil. Den andre faktoren som kompliserer levetiden til systemadministratoren er behovet for å sikre tilgjengeligheten av alle databasefiler på det tidspunktet MS SQL-tjenesten først får tilgang til dem (dvs. det er ønskelig at interaktive handlinger ekskluderes når du kobler til et kryptert medium).

For å unngå et merkbart fall i systemytelsen, kan du bruke muligheten til MS SQL til å lage databaser i flere filer. Selvfølgelig, i dette tilfellet skal MS SQL-databasen ikke opprettes av 1C-serveren når du oppretter infobasen, men skal opprettes separat. Et eksempel på et TSQL-skript med kommentarer er gitt nedenfor:

BRUK master
GÅ
-- Lag en database SomeData,
LAG DATABASE SomeData
-- hvis data er helt plassert i filgruppen PRIMÆR.
PÅ PRIMÆR
-- Hoveddatafilen er plassert på krypterte medier (logisk stasjon E:)
-- og har en startstørrelse på 100 MB, kan automatisk økes til 200 MB med
-- 20 MB trinn
(NAME = SomeData1,
FILENAME = "E:\SomeData1.mdf",
STØRRELSE = 100 MB,
MAKSSTØRRELSE = 200,
FILEGROWTH = 2),
-- Den andre datafilen er plassert på ukrypterte medier (logisk stasjon C:)
-- og har en startstørrelse på 100 MB, kan automatisk økes til grensen
-- diskplass i trinn på 5 % av gjeldende filstørrelse (avrundet opp til 64 KB)
(NAME = SomeData2,
FILENAME = "c:\programfiler\microsoft sql-server\mssql\data\SomeData2.ndf",
STØRRELSE = 100 MB,
MAXSIZE = UBEGRENSET,
FILVEKST = 5 %)
LOGG PÅ
-- Selv om transaksjonsloggen også kan deles inn i deler, bør dette ikke gjøres,
-- fordi denne filen endres mye oftere og slettes regelmessig (for eksempel når
-- lage en databasesikkerhetskopi).
(NAME = SomeDatalog,
FILENAME = "c:\programfiler\microsoft sql-server\mssql\data\SomeData.ldf",
STØRRELSE = 10 MB,
MAXSIZE = UBEGRENSET,
FILVEKST = 10)
GÅ
-- Det er bedre å umiddelbart gi eierskap til databasen til brukeren på hvis vegne
-- 1C vil koble til. For å gjøre dette, må vi erklære den nåværende basen
- nettopp opprettet,
BRUK SomeData
GÅ
-- og utfør sp_changedbowner
EXEC sp_changedbowner @loginame = "SomeData_dbowner"

En kort digresjon om den automatiske veksten av datafilstørrelsen. Som standard økes filstørrelser for nye databaser i trinn på 10 % av gjeldende filstørrelse. Dette er en helt akseptabel løsning for små databaser, men ikke særlig god for store: Med en databasestørrelse på for eksempel 20 GB bør filen umiddelbart øke med 2 GB. Selv om denne hendelsen vil forekomme ganske sjelden, kan den vare i flere titalls sekunder (alle andre transaksjoner er faktisk inaktive i løpet av denne tiden), som, hvis den oppstår under aktivt arbeid med databasen, kan forårsake noen feil. Den andre negative konsekvensen av proporsjonal økning, som oppstår når diskplassen er nesten helt full, er sannsynligheten for for tidlig feil på grunn av utilstrekkelig ledig plass. For eksempel, hvis en diskpartisjon med en kapasitet på 40 GB er fullstendig dedikert til en database (mer presist, til en fil i denne databasen), er den kritiske størrelsen på databasefilen som det er nødvendig å raskt (svært presserende, til det punktet å avbryte det normale arbeidet til brukere) for å omorganisere lagringen av informasjon er datafilstørrelse 35 GB. Med inkrementstørrelsen satt til 10-20 MB, kan du fortsette å jobbe til du når 39 GB.

Selv om listen ovenfor spesifiserer en økning i størrelsen på en av databasefilene i trinn på 5 %, er det derfor bedre å sette en fast økning på 10-20 MB for store databasestørrelser. Når du angir økningsverdiene for vekst av databasefilstørrelse, er det nødvendig å ta hensyn til at inntil en av filene i en filgruppe når sin maksimale størrelse, gjelder regelen: filer i en filgruppe økes samtidig tid, når de alle er helt fylte. Så i eksemplet ovenfor, når SomeData1.mdf-filen når sin maksimale størrelse på 200 MB, vil SomeData2.ndf-filen være omtrent 1,1 GB stor.

Etter å ha opprettet en slik database, selv om dens ubeskyttede filer SomeData2.ndf og SomeData.ldf blir tilgjengelige for en angriper, vil det være ekstremt vanskelig å gjenopprette den sanne tilstanden til databasen - dataene (inkludert informasjon om den logiske strukturen til databasen ) vil være spredt over flere filer, og nøkkelinformasjon (om for eksempel hvilke filer som utgjør denne databasen) vil være i den krypterte filen.

Selvfølgelig, hvis lagring av databasefiler ved hjelp av kryptografiske midler brukes, bør sikkerhetskopiering (minst av disse filene) ikke utføres på ukrypterte medier. For å sikkerhetskopiere individuelle databasefiler, bruk riktig BACKUP DATABASE-kommandosyntaks. Vær oppmerksom på at selv om det er mulig å beskytte en databasesikkerhetskopi med et passord (alternativene "PASSWORD = " og "MEDIAPASSWORD = " for kommandoen "BACKUP DATABASE"), blir ikke en slik sikkerhetskopi kryptert!

Kryptering av applikasjonsserver og klientdata lagret på disker

I de fleste tilfeller kan det ikke anses forsvarlig å lagre filer brukt av 1C:Enterprise (klientdel og applikasjonsserver) på krypterte medier på grunn av urimelig høye kostnader, men hvis et slikt behov eksisterer, vær oppmerksom på at applikasjonsserveren og klientdelen av applikasjonen oppretter veldig ofte midlertidige filer. Ofte kan disse filene forbli etter at programmet er ferdig kjørt, og det er nesten umulig å garantere at de blir fjernet ved hjelp av 1C-verktøy. Dermed blir det nødvendig å kryptere katalogen som brukes for midlertidige filer i 1C eller ikke lagre den på disk ved hjelp av en RAM-stasjon (det siste alternativet er ikke alltid mulig på grunn av størrelsen på de genererte filene og RAM-kravene til 1C:Enterprise selve applikasjonen).

Datakryptering ved hjelp av innebygde 1C-verktøy.

Standardfunksjoner for bruk av kryptering i 1C kommer ned til å bruke objekter for å jobbe med Zip-filer med krypteringsparametere. Følgende krypteringsmoduser er tilgjengelige: AES-algoritme med en nøkkel på 128, 192 eller 256 biter og en foreldet algoritme som opprinnelig ble brukt i Zip-arkivet. Zip-filer kryptert med AES er ikke lesbare av mange arkivere (WinRAR, 7zip). For å generere en fil som inneholder krypterte data, må du spesifisere et passord og en krypteringsalgoritme. Det enkleste eksemplet på krypterings-dekrypteringsfunksjoner basert på denne funksjonen er gitt nedenfor:

Funksjon EncryptData(Data, Passord, Krypteringsmetode = Udefinert) Eksporter

// Skriv dataene til en midlertidig fil. Faktisk kan ikke alle data lagres på denne måten.
ValueInFile(TemporaryFileName, Data);

// Skriv midlertidige data til arkivet
Zip = New ZipFileRecord(Temporary ArchiveFileName, Password, EncryptionMethod);
Zip.Add(TemporaryFileName);
Zip.Skriv();

// Les data fra det mottatte arkivet inn i RAM
EncryptedData = NewValueStorage(NewBinaryData(ArchiveTemporaryFileName));

// Midlertidige filer - slett

EndFunctions Funksjon DecryptData(EncryptedData, Password) Export

// Merk følgende! Riktigheten til de beståtte parameterne overvåkes ikke

// Skriv den beståtte verdien til en fil
ArchiveTemporaryFileName = GetTemporaryFileName("zip");
BinaryArchiveData = EncryptedData.Get();
BinaryArchiveData.Write(ArchiveTemporaryFileName);

// Pakk ut den første filen i det nettopp skrevne arkivet
TemporaryFileName = GetTemporaryFileName();
Zip = New ReadZipFile(TemporaryArchiveFileName, Password);
Zip.Extract(Zip.Items, TemporaryFileName, ZIPFilePathRecoveryMode.Do NotRecover);

// Les den skrevne filen
Data = ValueFromFile(TemporaryFileName + "\" + Zip.Items.Name);

//Slett midlertidige filer
DeleteFiles(TemporaryFileName);
DeleteFiles(ArchiveTemporaryFileName);

Returner data;

EndFunction

Selvfølgelig kan denne metoden ikke kalles ideell - dataene skrives til en midlertidig mappe i klartekst, ytelsen til metoden, ærlig talt, er dårligere enn noen gang, lagring i databasen krever ekstremt mye plass, men dette er den eneste metoden som kun er basert på plattformens innebygde mekanismer. I tillegg har den en fordel fremfor mange andre metoder - denne metoden pakker samtidig data sammen med kryptering. Hvis du ønsker å implementere kryptering uten de ulempene som denne metoden har, må du enten implementere dem i en ekstern komponent, eller vende deg til eksisterende biblioteker ved å lage COM-objekter, for eksempel ved hjelp av Microsoft CryptoAPI. Som et eksempel vil vi gi funksjonene til å kryptere/dekryptere en streng basert på det mottatte passordet.

Funksjon EncryptStringDES(UncryptedString, Password)

CAPICOM_ENCRYPTION_ALGORITHM_DES = 2; // Denne konstanten er fra CryptoAPI

EncryptionMechanism.Content = UnencryptedString;
Encryption Engine.Algorithm.Name = CAPICOM_ENCRYPTION_ALGORITHM_DES;
EncryptedString = EncryptionMechanism.Encrypt();

Returner EncryptedString;

EndFunction // EncryptStringDES()

Funksjon DecryptStringDES(EncryptedString, Password)

//Merk følgende! Parametre er ikke kontrollert!

Encryption Engine = New COMObject("CAPICOM.EncryptedData");
EncryptionMechanism.SetSecret(Passord);
Forsøk
EncryptionMechanism.Decrypt(EncryptedString);
Unntak
// Feil passord!;
Returner Udefinert;
Sluttforsøk;

ReturnEncryptionMechanism.Content;

EndFunction // DecryptStringDES()

Vær oppmerksom på at å sende en tom verdi som en streng eller passord til disse funksjonene vil generere en feilmelding. Strengen oppnådd ved hjelp av denne krypteringsprosedyren er litt lengre enn originalen. Spesifisiteten til denne krypteringen er at hvis du krypterer en streng to ganger, vil de resulterende strengene IKKE være identiske.

Grunnleggende feil ved bruk av kryptografiske verktøy.

Når du bruker kryptografiske verktøy, blir de samme feilene ofte gjort:

Undervurderer ytelsesstraffen ved bruk av kryptografi.

Kryptografi er en oppgave som krever et ganske stort antall beregninger (spesielt for algoritmer som DES, 3DES, GOST, PGP). Og selv når du bruker høyytelses og optimaliserte algoritmer (RC5, RC6, AES), er det ingen unnslippe fra unødvendig dataoverføring i minnet og databehandling. Og dette opphever nesten mulighetene til mange serverkomponenter (RAID-matriser, nettverkskort). Når du bruker maskinvarekryptering eller maskinvareavledning av krypteringsnøkkelen, er det en ytterligere mulig flaskehals for ytelsen: hastigheten på dataoverføring mellom tilleggsenheten og minnet (der ytelsen til en slik enhet kanskje ikke er kritisk). Når du bruker kryptering av små mengder data (for eksempel en e-postmelding), er økningen i databelastningen på systemet ikke så merkbar, men i tilfelle total kryptering av alt, kan dette i stor grad påvirke ytelsen til systemet som helhet.

Undervurdering av moderne muligheter for valg av passord og nøkler.

For øyeblikket er teknologiens evner slik at en nøkkel med en lengde på 40-48 biter kan velges av en liten organisasjon, og en nøkkel med en lengde på 56-64 biter av en stor organisasjon. De. Algoritmer som bruker en nøkkel på minst 96 eller 128 biter må brukes. Men de fleste nøkler genereres ved hjelp av hash-algoritmer (SHA-1, etc.) basert på passord som er lagt inn av brukeren. I dette tilfellet kan det hende at en nøkkel med en lengde på 1024 biter ikke hjelper. For det første brukes ofte et passord som er lett å gjette. Faktorer som letter utvelgelsen er: bruk av kun én stor bokstav; bruk av ord, navn og uttrykk i passord; bruk av kjente datoer, bursdager osv.; bruke "mønstre" når du genererer passord (for eksempel 3 bokstaver, deretter 2 tall, deretter 3 bokstaver i hele organisasjonen). Et godt passord bør være en ganske tilfeldig sekvens av både store bokstaver, tall og skilletegn. Passord som legges inn fra tastaturet på opptil 7-8 tegn, selv om disse reglene følges, kan gjettes i rimelig tid, så det er bedre at passordet er på minst 11-13 tegn. Den ideelle løsningen er å unngå å generere en nøkkel ved å bruke et passord, for eksempel for å bruke ulike smartkort osv., men i dette tilfellet er det nødvendig å sørge for muligheten for å beskytte mot tap av krypteringsnøkkelmediet.

Usikker lagring av nøkler og passord.

Vanlige eksempler på denne feilen er:

lange og komplekse passord skrevet på klistrelapper limt på brukerens skjerm.
lagre alle passord i en fil som ikke er beskyttet (eller er beskyttet mye svakere enn selve systemet)
lagring av elektroniske nøkler i det offentlige.
hyppig overføring av elektroniske nøkler mellom brukere.

Hvorfor lage en pansret dør hvis nøkkelen til den er under dørmatten?

Overføring av opprinnelig kryptert data til et usikkert miljø.

Når du setter opp et sikkerhetssystem, sørg for at det gjør jobben sin. For eksempel kom jeg over en situasjon (ikke relatert til 1C) da en opprinnelig kryptert fil, når programmet kjørte i klar form, ble plassert i en midlertidig mappe, hvorfra den trygt kunne leses. Ofte er sikkerhetskopier av krypterte data i klar form plassert et sted "ikke langt" fra disse dataene.

Bruk av kryptografiske verktøy til andre formål

Ved å kryptere data under overføring kan du ikke forvente at dataene er utilgjengelige der de brukes. For eksempel hindrer IPSec-tjenester på ingen måte applikasjonsserveren i å "sniffe" nettverkstrafikk på applikasjonsnivå.

For å unngå feil når du implementerer kryptografiske systemer, bør du (i det minste) gjøre følgende før du distribuerer det.

Finne ut:
- Hva må beskyttes?
- Hvilken beskyttelsesmetode bør du bruke?
- Hvilke deler av systemet må sikres?
- Hvem skal kontrollere tilgangen?
- Vil kryptering fungere i alle de riktige områdene?
Bestem hvor informasjonen er lagret, hvordan den skal sendes over nettverket, og datamaskinene som informasjonen vil få tilgang til. Dette vil gi informasjon om nettverkshastighet, kapasitet og bruk før systemet implementeres, noe som er nyttig for å optimalisere ytelsen.
Vurder systemets sårbarhet for ulike typer angrep.
Utvikle og dokumentere en systemsikkerhetsplan.
Vurder den økonomiske effektiviteten (begrunnelsen) ved å bruke systemet.

Konklusjon

Selvfølgelig, i en rask gjennomgang er det umulig å indikere alle aspekter knyttet til sikkerhet i 1C, men la oss tillate oss å trekke noen foreløpige konklusjoner. Selvfølgelig kan denne plattformen ikke kalles ideell - den, som mange andre, har sine egne problemer med å organisere et sikkert system. Men dette betyr på ingen måte at disse problemene ikke kan omgås, tvert imot kan nesten alle mangler elimineres med riktig utvikling, implementering og bruk av systemet. De fleste problemer oppstår på grunn av utilstrekkelig utvikling av en spesifikk applikasjonsløsning og dens utførelsesmiljø. For eksempel innebærer standardløsninger uten vesentlige endringer rett og slett ikke opprettelsen av et tilstrekkelig sikkert system.

Selskap er en unik tjeneste for kjøpere, utviklere, forhandlere og tilknyttede partnere. I tillegg er dette en av de beste nettbaserte programvarebutikkene i Russland, Ukraina og Kasakhstan, som tilbyr kundene et bredt spekter av produkter, mange betalingsmetoder, rask (ofte øyeblikkelig) ordrebehandling og sporing av bestillingsprosessen i en personlig seksjon .