Sirvige läbi kõik kasutajad ib 1s 8. Kasutajate loendi seadistamine

30.10.2019

Infoturbe, samuti infokaitse - turvalisuse tagamisele suunatud kompleksne ülesanne, mida rakendatakse turvasüsteemi juurutamisega. Infoturbe probleem on mitmetahuline ja keeruline ning hõlmab mitmeid olulisi ülesandeid.

Infoturbe probleeme süvendavad pidevalt protsessid, mis puudutavad andmete töötlemise ja edastamise tehniliste vahendite tungimist kõigisse ühiskonna sfääridesse, see probleem on eriti terav finantsarvestussüsteemide valdkonnas. Venemaal on kõige populaarsem raamatupidamis-, müügi- ja CRM-i protsesside süsteem 1C Enterprise.

1C programmi kasutamisel arvestage võimalike turvaohtudega.

	1C kasutamine failivormingus andmebaasidega. 1C failibaasid on füüsilise mõju suhtes kõige haavatavamad. Selle põhjuseks on seda tüüpi andmebaaside arhitektuuri iseärasused - vajadus hoida avatud (täieliku juurdepääsuga) kõik konfiguratsioonifailid ja failibaasid ise kõigi operatsioonisüsteemi kasutajate jaoks. Selle tulemusena saab iga kasutaja, kellel on õigus töötada 1C failibaasis, teoreetiliselt kahe hiireklõpsuga 1C teabebaasi kopeerida või isegi kustutada.
	1C kasutamine DBMS-vormingus andmebaasidega. Seda tüüpi probleem ilmneb siis, kui DBMS-i (PosgreSQL, MS SQL) kasutatakse 1C andmebaasi salvestusruumina ja ettevõtte 1C serverit kasutatakse vahesideteenusena 1C ja DBMS-i jaoks. Selline näide - paljudes ettevõtetes harjutatakse 1C konfiguratsioonide viimistlemist vastavalt nende vajadustele. Lõpetamisprotsessis, projekti "sagina" tingimustes, uute täiustatud funktsionaalsuse pidev testimine - vastutavad spetsialistid eiravad sageli võrguturbe reegleid. Selle tulemusel saavad mõned isikud, kellel on otsene juurdepääs DBMS-i andmebaasile või kellel on 1C Enterprise serveri administraatoriõigused, isegi ajutiseks testiperioodiks, teha varukoopia välistesse ressurssidesse või andmebaasi DBMS-is täielikult kustutada.
	Serveri riistvara avatus ja kättesaadavus. Kui serveriseadmetele on volitamata juurdepääs, saavad ettevõtte töötajad või kolmandad osapooled seda juurdepääsu kasutada teabe varastamiseks või rikkumiseks. Lihtsamalt öeldes – kui ründaja pääseb juurde otse 1c serveri korpusele ja konsoolile – laieneb tema võimaluste ulatus kümneid kordi.
	Varguse ohud, isikuandmete lekkimine. Isikuandmete turvalisuse tegelike ohtude all mõistetakse siin tingimuste ja tegurite kogumit, mis loovad tegeliku ohu volitamata, sealhulgas juhuslikuks, juurdepääsuks isikuandmetele nende töötlemisel infosüsteemis, näiteks vastutavate töötajate, PC poolt. operaatorid, raamatupidamisosakonnad jne. Selle tagajärjeks võib olla isikuandmete hävitamine, muutmine, blokeerimine, kopeerimine, edastamine, levitamine, aga ka muu vastutavate isikute ebaseaduslik tegevus.
	Võrgu turvalisus. Ettevõtte infosüsteem, mis on ehitatud rikkudes GOST-i, turvanõudeid, soovitusi või ilma korraliku IT-toeta, on täis auke, viiruseid ja nuhkvara, palju tagauksi (volitamata juurdepääs sisevõrgule), mis mõjutab otseselt ettevõtte andmete turvalisust 1C-s. . Selle tulemuseks on ründajal lihtne juurdepääs tundlikule äriteabele. Näiteks tasuta juurdepääsu varukoopiatele, varukoopiatega arhiivide parooli puudumist saab ründaja kasutada isikliku kasu saamiseks. Rääkimata elementaarsest kahjust 1C andmebaasile viirustegevuse poolt.
	1C seos väliste objektidega. Teine potentsiaalne oht on 1C kontobaasi vajadus (ja mõnikord ka spetsiaalne turundusfunktsioon) suhelda "välismaailmaga". Kliendipankade üles-/allalaadimine, infovahetus filiaalidega, regulaarne sünkroonimine ettevõtete veebisaitidega, portaalidega, muude aruandlusprogrammidega, klientide ja müügi haldamine ja palju muud. Kuna see 1C piirkond ei tervita turvastandardite järgimist ja võrgu teabevahetuse ühtsust, on leke selle marsruudi mis tahes segmendis üsna reaalne. Seoses mittestandardsete protsesside automatiseerimise täiustuste või liikluse kaitseks vajalike meetmete eelarvekärbete vajadusega kasvab turvaaukude, aukude, ebaturvaliste ühenduste, avatud portide, kergesti ligipääsetavate krüpteerimata vahetusfailide jms arv kiiresti raamatupidamissüsteem. Võite julgelt ette kujutada, milleni see võib viia - alustades 1C baasi elementaarsest keelamisest teatud ajaks ja lõpetades mitme miljoni suuruse maksekorralduse võltsimisega.

Mida saab selliste probleemide lahendamiseks välja pakkuda?

1. Failide andmebaasidega töötamisel 1C rakendage kindlasti mitmeid meetmeid, et tagada baaside turvalisus:

NTFS-i juurdepääsukontrolli kasutades andke vajalikud õigused ainult neile kasutajatele, kes selle andmebaasiga töötavad, kaitstes sellega andmebaasi hoolimatute töötajate või sissetungijate poolt varguse või kahjustamise eest;
Kasutage kasutaja tööjaamadesse sisselogimiseks ja võrguressurssidele juurdepääsuks alati Windowsi autoriseerimist;
Kasutage krüptitud kettaid või krüptitud kaustu, mis võimaldavad teil säilitada konfidentsiaalset teavet isegi 1C aluse eemaldamisel;
Kehtestada automaatse ekraaniluku poliitika, samuti viia läbi kasutajakoolitusi profiililuku vajaduse selgitamiseks;
Juurdepääsuõiguste diferentseerimine 1C tasemel võimaldab kasutajatel pääseda juurde ainult sellele teabele, mille jaoks neil on vastavad õigused;
1C konfiguraatori käivitamine on vajalik ainult neile töötajatele, kes seda vajavad.

2. DBMS-i andmebaasidega töötamisel 1C tähelepanu tuleks pöörata järgmistele soovitustele:

DBMS-iga ühenduse loomise mandaatidel ei tohi olla administraatoriõigusi;
Vajalik on eristada juurdepääsuõigusi DBMS-i andmebaasidele, näiteks luua iga infobaasi jaoks eraldi konto, mis minimeerib andmete kadumise ühe konto häkkimisel;
Soovitatav on piirata füüsilist ja kaugjuurdepääsu andmebaasiserveritele ja 1C ettevõttele;
Andmebaaside jaoks on soovitatav kasutada krüptimist, kuna see hoiab konfidentsiaalseid andmeid isegi siis, kui ründaja saab füüsilise juurdepääsu DBMS-failidele;
Samuti on üheks oluliseks otsuseks andmete varukoopiate krüpteerimine või parooli määramine;
1C klastri administraatorite ja 1C serveri loomine on kohustuslik, kuna vaikimisi, kui kasutajaid ei looda, on absoluutselt kõigil süsteemi kasutajatel täielik juurdepääs teabebaasidele.

3. Nõuded serveri riistvara füüsilise turvalisuse tagamiseks:
(vastavalt GOST R ISO / IEC TO - 13335)

Juurdepääsu piirkondadele, kus töödeldakse või säilitatakse tundlikku teavet, tuleks kontrollida ja piirduda ainult selleks volitatud isikutega;
Autentimise juhtelemendid, nagu läbipääsukaart ja isikukood , tuleks kasutada mis tahes juurdepääsu lubamiseks ja kinnitamiseks;
Kogu juurdepääsu kontrolljälg tuleks hoida turvalises kohas;
Kolmandate isikute tugipersonalile tuleks anda piiratud juurdepääs turvaaladele või tundlikele teabetöötlusseadmetele ainult vajaduse korral;
see juurdepääs peab olema lubatud ja seda tuleb pidevalt jälgida;
Juurdepääsuõigused turvatsoonidele tuleks regulaarselt üle vaadata ja ajakohastada ning vajadusel tühistada;
Arvesse tuleb võtta asjakohaseid ohutuse ja töökaitse norme ja standardeid;
Peamised rajatised peaksid asuma nii, et avalikkus ei pääseks neile ligi;
Kui see on asjakohane, peaksid hooned ja ruumid olema tagasihoidlikud ja andma minimaalse ülevaate nende otstarbest, ilma et hoone välis- ega siseruumides ei oleks räigeid silte, mis viitaksid teabetöötlustoimingutele;
Tundliku teabe töötlemise rajatiste asukohtadele osutavad teeviitad ja sisemised telefoniraamatud ei tohiks olla üldsusele kergesti kättesaadavad.

4. Isikuandmete konfidentsiaalsus. Isikuandmete kaitse korraldamise põhieesmärk on neutraliseerida infosüsteemis kehtivad ohud 27. juuli 2006 föderaalseadus nr 152-FZ "Isikuandmete kohta" , riiklike standardite ja rahvusvaheliste IT-turbe sertifikaatide nõuete loetelu (GOST R ISO/IEC 13335 2-5, ISO 27001) . See saavutatakse teabele juurdepääsu piiramisega selle liikide kaupa, teabele juurdepääsu piiritlemisega kasutajarollide kaupa, teabe töötlemise ja säilitamise protsessi struktureerimisega.
Siin on mõned põhipunktid.

Isikuandmete töötlemine peaks piirduma konkreetsete, eelnevalt kindlaksmääratud ja legitiimsete eesmärkide saavutamisega;
Nõusolek isikuandmete töötlemiseks peab olema konkreetne, teadlik ja teadlik;
Ei ole lubatud töödelda isikuandmeid, mis ei sobi kokku isikuandmete kogumise eesmärkidega;
Töötlemisele kuuluvad ainult isikuandmed, mis vastavad nende töötlemise eesmärgile;
Isikuandmetele juurdepääsu saanud operaatorid ja muud isikud on kohustatud mitte avaldama kolmandatele isikutele ega levitama isikuandmeid ilma isikuandmete subjekti nõusolekuta, kui föderaalseaduses ei ole sätestatud teisiti;
Foto-, video-, heli- või muud salvestusseadmed, näiteks mobiilseadmete kaamerad, ei tohi olla lubatud, välja arvatud juhul, kui see on lubatud;
Irdkandjadraive tuleks lubada ainult siis, kui selleks on äriline vajadus;
Konfidentsiaalse teabega seotud pahatahtlike tegude vältimiseks on nõutav, et paberit ja elektroonilisi andmekandjaid hoitakse sobivates kappides ja/või muudes turvalistes mööbliesemetes, kui neid ei kasutata, eriti pärast tööaega;
Olulise või kriitilise teenindusteabega kandjad tuleks eemaldada ja lukustada (näiteks tulekindlasse seifi või kappi), kui seda pole vaja, eriti kui ruum on tühi.

5. Võrgu turvalisus- see on nõuete kogum ettevõtte arvutivõrgu infrastruktuurile ja selles töötamise poliitikatele, mille täitmine tagab võrguressursside kaitse volitamata juurdepääsu eest. Võrguturbe korraldamiseks ja tagamiseks soovitatud toimingute osana võib lisaks põhilistele kaaluda järgmisi funktsioone:

Esiteks peab ettevõte rakendama ühtset infoturbe regulatsiooni koos vastavate juhistega;
Kasutajatel tuleks võimaluse korral keelata juurdepääs soovimatutele saitidele, sealhulgas failimajutussaitidele;
Välisvõrgust tuleks avada ainult need pordid, mis on vajalikud kasutajate korrektseks tööks;
Peaks olema süsteem kasutajate tegevuste igakülgseks jälgimiseks ja kõigi avalike ressursside, mille töö on Ettevõtte jaoks oluline, tavaseisundi rikkumisest kiireks teavitamiseks;
Tsentraliseeritud viirusetõrjesüsteemi ja pahavara puhastamise ja eemaldamise reeglite olemasolu;
Viirusetõrjetarkvara haldamiseks ja värskendamiseks mõeldud tsentraliseeritud süsteemi, samuti OS-i regulaarsete värskenduste poliitikate olemasolu;
Võimalus kasutada irdvälkmälu peaks olema võimalikult piiratud;
Parool peab olema vähemalt 8 tähemärgi pikkune, sisaldama numbreid, samuti suur- ja väiketähti;
Peaks olema kaitstud ja krüpteeritud võtmeteabe vahetamise kaustad, eelkõige 1c vahetusfailid ja kliendi-panga süsteem;
Teabetöötlusseadmetega seotud elektriliinid ja kaugliinid peaksid võimaluse korral olema maa all või neile tuleks kohaldada piisavat alternatiivset kaitset;
Võrgukaableid tuleb kaitsta volitamata pealtkuulamise või kahjustamise eest, kasutades näiteks kanalit või vältides avalikke alasid läbivaid marsruute.

Kõike eelnevat kokku võttes märgin, et teabe kaitsmise peamiseks reegliks on kasutajate õiguste ja võimaluste ning nende üle kontrolli piiramine infosüsteemide kasutamisel. Mida vähem on kasutajal infosüsteemiga töötamisel õigusi, seda väiksem on kuritahtliku kavatsuse või hooletuse tõttu teabe lekkimise või kahjustumise tõenäosus.

Terviklik lahendus ettevõtte andmete, sealhulgas 1C andmebaaside kaitsmiseks on lahendus Server in Israel, mis sisaldab ajakohaseid tööriistu teabe kõrge konfidentsiaalsuse tagamiseks.

Süsteemi integreerimine. Konsulteerimine

See artikkel näitab veel kord, et mis tahes turvameetmete kogum peaks hõlmama kõiki rakendamisetappe: arendust, juurutamist, süsteemi administreerimist ja loomulikult korralduslikke meetmeid. Infosüsteemides on just "inimfaktor" (ka kasutajad) peamine turvaoht. See meetmete kogum peaks olema mõistlik ja tasakaalustatud: see ei ole mõttekas ja on ebatõenäoline, et kaitse korraldamiseks eraldatakse piisavalt raha, mis ületab andmete enda maksumuse.

Sissejuhatus

1C:Enterprise on Venemaal kõige levinum raamatupidamissüsteem, kuid vaatamata sellele pöörasid selle arendajad enne versiooni 8.0 turvaprobleemidele väga vähe tähelepanu. Põhimõtteliselt tingis selle muidugi toote hinnanišš ja keskendumine väikeettevõtetele, kus puuduvad kvalifitseeritud IT-spetsialistid ning võimalik kulu turvalise süsteemi juurutamiseks ja ülalpidamiseks läheks ettevõttele üle jõu käivaks. Versiooni 8.0 ilmumisega pidid rõhuasetused muutuma: lahenduste maksumus on oluliselt kasvanud, süsteem on muutunud palju skaleeritavamaks ja paindlikumaks – nõuded on oluliselt muutunud. Kas süsteem on muutunud piisavalt töökindlaks ja turvaliseks, on väga individuaalne küsimus. Kaasaegse ettevõtte põhiinfosüsteem peab vastama vähemalt järgmistele turvanõuetele:

Piisavalt väike tõenäosus, et süsteemis sisemistel põhjustel tekib rike.
Usaldusväärne kasutaja autoriseerimine ja andmekaitse ebaõigete toimingute eest.
Tõhus süsteem kasutajaõiguste määramiseks.
Veebipõhine varundus- ja taastesüsteem rikke korral.

Kas 1C:Enterprise 8.0-l põhinevad lahendused vastavad neile nõuetele? Ühest vastust pole. Vaatamata olulistele muudatustele läbipääsusüsteemis on veel palju lahendamata probleeme. Olenevalt süsteemi disainist ja konfigureerimisest ei pruugi kõik need nõuded selle teostuse jaoks olla täidetud või piisaval määral täidetud, kuid tähelepanu tasub pöörata (ja see on platvormi "nooruse" oluline tagajärg ), et loetletud tingimuste täielikuks täitmiseks peate tegema tõeliselt titaanlikke pingutusi.

See artikkel on mõeldud 1C:Enterprise platvormil põhinevate lahenduste arendajatele ja juurutajatele, aga ka 1C:Enterprise'i kasutavate organisatsioonide süsteemiadministraatoritele ning kirjeldab mõningaid aspekte süsteemi klient-server versiooni arendamise ja konfigureerimisel. infoturbe korraldamise seisukohast. Seda artiklit ei saa kasutada dokumentatsiooni asendajana, vaid see osutab ainult mõnele punktile, mida selles veel ei kajastatud. Ja loomulikult ei suuda ei käesolev artikkel ega kogu dokumentatsioon kajastada probleemi keerukust turvalise infosüsteemi ehitamisel, mis peab üheaegselt vastama vastuolulistele turvalisuse, jõudluse, mugavuse ja funktsionaalsuse nõuetele.

Klassifikatsioon ja terminoloogia

Teabeohud on artikli põhiteema.

Infooht– olukorra võimalus, kus andmeid loetakse, kopeeritakse, muudetakse või blokeeritakse volitamata.

Ja selle määratluse põhjal liigitatakse artiklis teabeohud järgmiselt:

Andmete volitamata hävitamine
Volitamata andmete muutmine
Andmete volitamata kopeerimine
Andmete volitamata lugemine
Andmetele ligipääsmatus

Kõik ohud jagunevad tahtlikeks ja tahtmatuteks. Realiseeritud infooht kutsutakse intsident. Süsteemi omadused on järgmised:

Haavatavused– vahejuhtumiteni viivad omadused Kaitsemeetmed– funktsioonid, mis blokeerivad intsidendi võimaluse

Põhimõtteliselt võetakse arvesse ainult neid juhtumeid, mille tõenäosus on tingitud 1C:Enterprise 8.0 tehnoloogilise platvormi kasutamisest klient-server versioonis (edaspidi juhtudel, kui see ei ole vastuolus lihtsalt 1C või 1C 8.0 tähendusega) . Seoses süsteemi kasutamisega määratleme järgmised peamised rollid:

Operaatorid– kasutajad, kellel on piiratud rakenduserolli õigused andmete vaatamiseks ja muutmiseks, kuid kellel ei ole haldusfunktsioone
Süsteemiadministraatorid– kasutajad, kellel on süsteemis administraatoriõigused, sh rakendusserveri ja MS SQL serveri operatsioonisüsteemides administraatoriõigused, MS SQLi administraatoriõigused jne.
Infoturbe administraatorid- kasutajad, kellele on 1C teabebaasis delegeeritud teatud haldusfunktsioonid (nt kasutajate lisamine, testimine ja parandamine, varundamine, rakenduslahenduse seadistamine jne)
Süsteemi arendajad- kasutajad, kes arendavad rakenduslahendust. Üldiselt ei pruugi neil töötavale süsteemile ligi pääseda.
Isikud, kellel puudub otsene juurdepääs süsteemile- kasutajad, kellele ei ole 1C-le juurdepääsuõigusi delegeeritud, kuid kes võivad ühel või teisel määral süsteemi tööd mõjutada (tavaliselt on need kõik sama Active Directory domeeni kasutajad, kuhu süsteem on installitud). Seda kategooriat peetakse peamiselt potentsiaalselt ohtlike üksuste tuvastamiseks süsteemis.
Automatiseeritud haldusskriptid– programmid, millele on delegeeritud teatud funktsioonid ja mis on loodud teatud toimingute automaatseks sooritamiseks (näiteks andmete import-eksport)

Siinkohal tuleb ära märkida kaks punkti: esiteks on see klassifikatsioon väga konarlik ega võta arvesse iga grupi siseseid jaotusi – selline jaotus luuakse teatud konkreetsete juhtumite jaoks ning teiseks eeldatakse, et teised isikud ei saa grupi toimimist mõjutada. süsteem, mis peaks olema tagatud 1C-väliste vahenditega.

Iga turvasüsteem peab olema kavandatud teostatavust ja omamiskulusid silmas pidades. Üldjuhul on infosüsteemi arendamisel ja juurutamisel vajalik, et süsteemikaitse hind vastaks:

kaitstud teabe väärtus;
intsidendi tekitamise maksumus (sihiliku ähvarduse korral);
finantsriskid intsidendi korral

Mõttetu ja kahjulik on korraldada kaitset, mis on palju kallim kui selle rahalise efektiivsuse hindamine. Infokao riskide hindamiseks on mitu meetodit, kuid käesolevas artiklis neid ei käsitleta. Teine oluline aspekt on säilitada tasakaal sageli vastandlike nõuete vahel infoturbe, süsteemi jõudluse, süsteemi kasutusmugavuse ja lihtsuse, arenduse ja juurutamise kiiruse ning muude ettevõtete infosüsteemidele esitatavate nõuete vahel.

Süsteemi infoturbemehhanismi põhijooned

1C:Enterprise 8.0 on saadaval kahes versioonis: fail ja klient-server. Faili versiooni ei saa pidada süsteemi infoturvet tagavaks järgmistel põhjustel:

Andmed ja konfiguratsioon salvestatakse faili, mis on lugemiseks ja kirjutamiseks kättesaadav kõigile süsteemi kasutajatele.
Nagu allpool näidatud, on süsteemi autoriseerimisest väga lihtne mööda minna.
Süsteemi terviklikkuse tagab ainult kliendiosa tuum.

Klient-serveri versioonis kasutatakse teabe salvestamiseks MS SQL Serverit, mis pakub:

Turvalisem andmesalvestus.
Eraldage failid otsesest juurdepääsust.
Täiustatud tehingu- ja lukustusmehhanismid.

Vaatamata olulistele erinevustele süsteemi faili- ja klient-serveri versioonide vahel, on neil rakenduslahenduse tasemel ühtne juurdepääsukontrolliskeem, mis pakub järgmisi funktsioone:

Kasutaja autoriseerimine punktis 1C määratud parooliga.
Kasutaja autoriseerimine praeguse Windowsi kasutaja poolt.
Süsteemi kasutajatele rollide määramine.
Haldusfunktsioonide täitmise piiramine rollide kaupa.
Saadaolevate liideste määramine rollide kaupa.
Metaandmeobjektidele juurdepääsu piiramine rollide kaupa.
Juurdepääsu piiramine objektide detailidele rollide kaupa.
Andmeobjektidele juurdepääsu piiramine rollide ja seansi parameetrite järgi.
Andmetele ja käivitatavatele moodulitele interaktiivse juurdepääsu piiramine.
Mõned koodi täitmise piirangud.

Üldiselt on kasutatav andmetele juurdepääsu skeem selle taseme infosüsteemidele üsna tüüpiline. Seoses kolmetasandilise klient-server arhitektuuri rakendamisega on aga mitmeid põhiaspekte, mis toovad kaasa suhteliselt suure hulga haavatavusi:

Andmetöötluse suur hulk etappe ja igas etapis võivad objektidele juurdepääsuks kehtida erinevad reeglid.

Mõnevõrra lihtsustatud diagramm turvalisuse seisukohalt olulistest andmetöötlusetappidest on näidatud joonisel 1. Üldreegel 1C puhul on piirangute vähendamine, kui liigute selle skeemi allapoole, seega võib haavatavuse ärakasutamine ühel ülemistest tasemetest häirida süsteemi kõigil tasanditel.
Ebapiisavalt silutud protseduurid edastatavate andmete juhtimiseks üleminekul tasemelt tasemele.

Kahjuks pole kaugeltki kõik süsteemi sisemised mehhanismid täiuslikult silutud, eriti mitteinteraktiivsete mehhanismide puhul, mille silumine on ühest küljest alati aeganõudvam, kuid teisalt vastutustundlikum. See "haigus" ei ole ainult 1C probleem, seda leidub enamiku tarnijate paljudes serveritoodetes. Alles viimastel aastatel on tähelepanu nendele probleemidele märkimisväärselt suurenenud.
Eelmisest versioonist päritud arendajate ja süsteemiadministraatorite ebapiisavalt kõrge keskmine kvalifikatsioon.

Sarja 1C:Enterprise tooted olid algselt keskendunud arendamise ja toe lihtsusele ning tööle väikestes organisatsioonides, mistõttu pole üllatav, et ajalooliselt on märkimisväärne osa rakenduslahenduste "arendajaid" ja süsteemide "administraatoreid". ei oma piisavalt teadmisi ja oskusi, et töötada palju keerulisema tootega, milleks on versioon 8.0. Probleemi süvendab frantsiisivõtjate ettevõtetes omaks võetud tava treenida "võitluses" klientide kulul, ilma et sellele probleemile süstemaatiliselt lähenetaks. 1C-le tuleb au anda selle eest, et viimastel aastatel on olukord järk-järgult paranenud: tõsised frantsiisivõtjad on hakanud vastutustundlikumalt suhtuma personali värbamise ja koolitamise probleemi, infotehnoloogia toe tase alates aastast. 1C on märkimisväärselt suurenenud, sertifitseerimisprogrammid on keskendunud kõrgele teenindustasemele; kuid olukorda ei saa kohe parandada, seega tuleks seda tegurit süsteemi turvalisuse analüüsimisel arvesse võtta.
Platvormi suhteliselt väike vanus.

Sarnase orientatsiooni ja kasutusotstarbega toodete seas on see üks nooremaid lahendusi. Platvormi funktsionaalsus lahenes enam-vähem vähem kui aasta tagasi. Samal ajal muutus iga platvormi väljalase, alates versioonist 8.0.10 (just selles väljaandes rakendati peaaegu kõik süsteemi praegused funktsioonid), palju stabiilsem kui eelmised. Standardsete rakenduslahenduste funktsionaalsus kasvab endiselt hüppeliselt, kuigi kasutusel on vaid pool platvormi võimalustest. Muidugi võib sellistes tingimustes stabiilsusest rääkimine olla üsna meelevaldne, kuid üldiselt tuleb tõdeda, et 1C 8.0 platvormil põhinevad lahendused on nii funktsionaalsuse kui ka jõudluse (sageli ka stabiilsuse) poolest oluliselt ees. ) sarnaseid lahendusi platvormil 1C 7.7.

Seega juurutatakse süsteem (ja võib-olla ka tüüpiline rakenduslahendus) ettevõttes ja installitakse arvutitesse. Kõigepealt on vaja luua keskkond, milles 1C turvasättel on mõtet, ja selleks tuleb see konfigureerida nii, et oleks täidetud eeldus, et süsteemi sätted mõjutavad oluliselt süsteemi turvalisust.

Järgige turvalisuse seadistamise üldreegleid.

Süsteemi infoturbest ei saa juttugi olla, kui ei järgita turvaliste süsteemide loomise põhiprintsiipe. Veenduge, et täidetud on vähemalt järgmised tingimused:

Juurdepääs serveritele on füüsiliselt piiratud ja nende katkematu töö tagatud:
- serveri riistvara vastab töökindlusnõuetele, vigase serveri riistvara asendamine on silutud, eriti kriitilistes valdkondades kasutatakse riistvara dubleerimisega skeeme (RAID, toide mitmest allikast, mitmed sidekanalid jne);
- serverid asuvad lukustatud ruumis ja see ruum on avatud ainult töö ajaks, mida ei ole võimalik kaugjuhtimisega teha;
- serveriruumi avamise õigus on vaid ühel või kahel inimesel, hädaolukorras on välja töötatud vastutavate isikute hoiatamise süsteem;
- tagas serverite katkematu toite
- tagatakse seadmete normaalne klimaatiline töörežiim;
- serveriruumis on tulekahjusignalisatsioon, üleujutuse võimalus puudub (eriti esimesel ja viimasel korrusel);
Ettevõtte võrgu- ja infoinfrastruktuuri sätted on õiged:
- tulemüürid on installitud ja konfigureeritud kõikidesse serveritesse;
- kõik kasutajad ja arvutid on võrgus volitatud, paroolid on piisavalt keerulised, et neid pole võimalik ära arvata;
- süsteemihalduritel on piisavalt õigusi sellega normaalseks töötamiseks, kuid neil ei ole õigusi haldustoiminguteks;
- kõikidesse võrgu arvutitesse on installitud ja lubatud viirusetõrjevahendid;
- on soovitav, et kasutajatel (v.a võrguadministraatorid) ei oleks kliendi tööjaamades administraatoriõigusi;
- juurdepääs Internetile ja teisaldatavatele andmekandjatele tuleks reguleerida ja piirata;
- turvasündmuste süsteemiaudit peab olema konfigureeritud;
Peamised korralduslikud probleemid on lahendatud:
- kasutajad on kvalifitseeritud töötama 1C ja riistvaraga;
- kasutajaid teavitatakse vastutusest tööreeglite rikkumise eest;
- vastutab rahaliselt iga infosüsteemi olulise elemendi eest;
- kõik süsteemiplokid on pitseeritud ja suletud;
- pöörama erilist tähelepanu ruumide koristajate, ehitajate ja elektrikute juhendamisele ja järelevalvele. Need isikud võivad tahtmatult tekitada kahju, mis ei ole võrreldav süsteemi hoolimatute kasutajate poolt tekitatud tahtliku kahjuga.

Tähelepanu! See loetelu ei ole ammendav, vaid kirjeldab ainult seda, mis mis tahes üsna keeruka ja kuluka infosüsteemi juurutamisel sageli tähelepanuta jääb!

MS SQL Server, rakendusserver ja kliendiosa töötavad erinevates arvutites, serverirakendused töötavad spetsiaalselt loodud Windowsi kasutajate õiguste all;
MS SQL Serveri jaoks
- segatud autoriseerimisrežiim on seatud
- Serveradmini rollis olevad MS SQL-i kasutajad ei osale 1C-s,
- iga IB 1C jaoks on loodud eraldi MS SQL-i kasutaja, kellel pole privilegeeritud juurdepääsu serverile,
- Ühe IB MS SQL kasutajal puudub juurdepääs teistele IB-dele;
Kasutajatel pole otsest juurdepääsu rakendusserveri ja MS SQL serveri failidele
Operaatori tööjaamad on varustatud operatsioonisüsteemiga Windows 2000/XP (mitte Windows 95/98/Me)

Ärge jätke tähelepanuta süsteemiarendajate soovitusi ja dokumentatsiooni lugemist. Olulised materjalid süsteemi seadistamise kohta on avaldatud ITS-ketastel jaotises "Juhised". Pöörake erilist tähelepanu järgmistele artiklitele:

Rakenduste töö omadused serveriga 1C: Enterprise
Andmete paigutus 1C: Enterprise 8.0
Värskendus 1C: Enterprise 8.0 administraatoriõigusteta Microsoft Windowsi kasutajatelt
Kasutajate loendi muutmine administraatoriõigusteta kasutaja nimel
Windows XP hoolduspaketi SP2 tulemüüri sätete konfigureerimine SQL Server 2000 ja SQL Serveri töölauamootori (MSDE) jaoks
COM+ Windows XP SP2 parameetrite konfigureerimine 1C:Enterprise 8.0 serveri tööks
Windows XP hoolduspaketi SP2 tulemüüri sätete konfigureerimine 1C:Enterprise 8.0 serveri tööks
Windows XP hoolduspaketi SP2 tulemüüri sätete konfigureerimine HASP litsentsihalduri jaoks
Teabebaasi varukoopia loomine SQL Server 2000 abil
1C installimise ja konfigureerimise probleemid: Enterprise 8.0 "kliendi-serveri" versioonis(üks tähtsamaid artikleid)
Windows Server 2003 konfigureerimise funktsioonid serveri 1C:Enterprise 8.0 installimisel
Kasutajate juurdepääsu reguleerimine infobaasile klient-serveri versioonis(üks tähtsamaid artikleid)
Server 1C: Enterprise ja SQL Server
Üksikasjalik protseduur 1C:Enterprise 8.0 installimiseks "kliendi-serveri" versioonis(üks tähtsamaid artikleid)
1C:Enterprise serveri sisseehitatud keele kasutamine

Kuid dokumentatsiooni lugedes olge kriitiline näiteks artiklis "1C: Enterprise 8.0 installimise ja konfigureerimise probleemid klient-serveri versioonis" saadud teabe suhtes, kasutaja USER1CV8SERVER jaoks vajalikud õigused ei ole päris täpsed. kirjeldatud. Allolevasse loendisse on lingid, näiteks [ITS1] tähendab artiklit "Rakenduste 1C:Enterprise serveriga töötamise iseärasused". Kõik viited artiklitele viitavad ITS-i viimasele numbrile nende kirjutamise ajal (jaanuar 2006)

Kasutage kasutajate autoriseerimisvõimalusi koos Windowsi autoriseerimisega

Kahest võimalikust kasutaja autoriseerimisrežiimist: sisseehitatud 1C ja kombineerituna Windows OS-i autoriseerimisega, peaksite võimalusel valima kombineeritud autoriseerimise. See võimaldab kasutajatel mitte segadusse ajada mitme parooliga tööl, kuid samal ajal ei vähenda see süsteemi turvalisuse taset. Kuid isegi ainult Windowsi autoriseerimist kasutavate kasutajate jaoks on väga soovitav seadistada loomisel parool ja alles pärast seda keelata selle kasutaja 1C autoriseerimine. Süsteemi taastamise tagamiseks Active Directory struktuuri hävimise korral on vaja jätta vähemalt üks kasutaja, kes saab 1C autoriseerimist kasutades sisse logida.

Rakenduslahenduse rollide loomisel ärge lisage "varukoopia" õigusi

Iga rakenduslahenduse roll peaks kajastama minimaalset nõutavat õiguste kogumit selle rolliga määratletud toimingute tegemiseks. Mõnda rolli ei pruugita siiski iseseisvalt kasutada. Näiteks välise töötlemise interaktiivseks käitamiseks saate luua eraldi rolli ja lisada selle kõigile kasutajatele, kes peaksid kasutama välist töötlemist.

Vaadake regulaarselt üle süsteemi logid ja logid

Võimalusel reguleerige ja automatiseerige süsteemi toimimise logide ja protokollide ülevaatust. Korrektse konfigureerimise ja logide regulaarse ülevaatamise abil (filtreeritud ainult oluliste sündmuste järgi) saate volitamata toimingud õigeaegselt tuvastada või neid ettevalmistusfaasis isegi ära hoida.

Mõned klient-serveri versiooni funktsioonid

Selles jaotises kirjeldatakse mõningaid klient-serveri versiooni funktsioone ja nende mõju turvalisusele. Lugemise hõlbustamiseks on kasutusele võetud järgmine märge:

Tähelepanu! haavatavuse kirjeldus

Teabe salvestamine, mis kontrollib juurdepääsu süsteemile

IB kasutajate loendi salvestamine

Kogu teave selle IS-i kasutajate loendi ja neile selles saadaolevate rollide kohta salvestatakse MS SQL andmebaasi tabelisse Params (vt [ITS2]). Selle tabeli struktuuri ja sisu vaadates on ilmne, et kogu teave kasutajate kohta on salvestatud kirjesse, mille väärtus on välja FileName - "users.usr".

Kuna eeldame, et kasutajatel puudub juurdepääs MS SQL andmebaasile, siis seda asjaolu iseenesest ei saa ründaja kasutada, kuid kui MS SQL-is on võimalik koodi käivitada, siis see "avab ukse" mis tahes (! ) juurdepääs 1C-st. Sama mehhanismi (väiksemate muudatustega) saab kasutada ka süsteemi failiversiooni puhul, mis failiversiooni iseärasusi arvestades välistab täielikult selle rakendatavuse turvaliste süsteemide ehitamisel.

Soovitus: Hetkel ei ole võimalik rakendust sellise muudatuse eest täielikult kaitsta, välja arvatud MS SQL Serveri tasemel trigerite kasutamine, mis seevastu võib tekitada probleeme platvormi versiooni uuendamisel või kasutajate nimekirja muutmisel. Selliste muudatuste jälgimiseks võite kasutada 1C logi (pöörates tähelepanu "kahtlastele" sisselogimistele konfiguraatori režiimis ilma kasutajat määramata) või hoida SQL Profilerit pidevalt töös (mis avaldab süsteemi jõudlusele äärmiselt negatiivset mõju) või konfigureerida hoiatusi. mehhanism (tõenäoliselt koos päästikute abil)

IB loendi teabe salvestamine serverisse

Iga 1C rakendusserveri kohta salvestatakse teave sellega ühendatud MS SQL-i andmebaaside loendisse. Iga teabebaas kasutab rakendusserveri ja MS SQL serveri vahel oma ühendusstringi. Teave rakendusserveris registreeritud teabebaaside kohta koos ühenduse stringidega salvestatakse faili srvrib.lst, mis asub serveris kataloogis<Общие данные приложений>/1C/1Cv8 (näiteks C:/Dokumendid ja sätted/Kõik kasutajad/Rakenduse andmed/1C/1Cv8/srvrib.lst). Iga IB jaoks salvestatakse täielik ühendusstring, sealhulgas MS SQL-i kasutaja parool, kui kasutatakse segatud MS SQL-i autoriseerimismudelit. Just selle faili olemasolu võimaldab karta volitamata juurdepääsu MS SQL andmebaasile ja kui vastupidiselt soovitustele kasutatakse vähemalt ühele andmebaasile juurdepääsuks privilegeeritud kasutajat (näiteks "sa"), siis lisaks ühe IS-i ohule on oht kogu MS SQL-i kasutavale süsteemile.

Huvitav on märkida, et kombineeritud autoriseerimise ja Windowsi autoriseerimise kasutamine MS SQL-serveris põhjustab failile juurdepääsul erinevat tüüpi probleeme. Seega on Windowsi autoriseerimise peamised negatiivsed omadused:

Kogu teabeturbe töö rakendusserveris ja MS SQL serveris ühe õiguste kogumi alusel (tõenäoliselt üleliigne)
1C rakendusserveri protsessist (või üldiselt kasutajalt USER1CV8SERVER või selle samaväärselt) ilma parooli määramata saate hõlpsalt ühenduse luua mis tahes teabeturbega ilma parooli määramata

Teisest küljest võib kasutaja kontekstist USER1CV8SERVER suvalise koodi käivitamise võimaluse saamine olla ründaja jaoks keerulisem kui määratud faili hankimine. Muide, sellise faili olemasolu on veel üks argument serveri funktsioonide levitamiseks erinevates arvutites.

Soovitus: Fail srvrib.lst peaks olema juurdepääsetav ainult serveriprotsessile. Selle faili muutmiseks seadistage kindlasti auditeerimine.

Kahjuks pole see fail vaikimisi peaaegu lugemiskaitsega, millega tuleb süsteemi juurutamisel arvestada. Ideaalis takistaks rakendusserver selle faili lugemist ja kirjutamist (sealhulgas selles serveris käivitatavate kasutajaühenduste lugemist ja kirjutamist) töötamise ajal.

Volituse puudumine serveris IB loomisel

Tähelepanu! Volituse puudumise viga parandati platvormi 1C:Enterprise versioonis 8.0.14. Selles versioonis ilmus mõiste "1C: Enterprise Server Administrator", kuid seni, kuni administraatorite loend on serveris määratud, toimib süsteem allpool kirjeldatud viisil, seega ärge unustage seda võimalikku funktsiooni.

Tõenäoliselt on selle jaotise suurim haavatavus võimalus lisada rakendusserverisse peaaegu piiramatult infoturvet, mille tulemusena saab iga kasutaja, kes on saanud ligipääsu rakenduseserveriga ühendusele, automaatselt võimaluse käivitada rakenduses suvaline kood. server. Vaatame seda näitega.

Süsteem tuleks installida järgmises versioonis

MS SQL Server 2000 (näiteks võrgu nimi SRV1)
Server 1C: Enterprise 8.0 (võrgu nimi SRV2)
Kliendipool 1C: Enterprise 8.0 (võrgu nimi WS)

Eeldatakse, et WS-is töötaval kasutajal (edaspidi KASUTAJA) on vähemalt minimaalne juurdepääs ühele SRV2-s registreeritud IB-le, kuid tal puudub privilegeeritud juurdepääs SRV1-le ja SRV2-le. Üldiselt ei mõjuta loetletud arvutite funktsioonide kombinatsioon olukorda. Süsteemi konfigureerimisel võeti arvesse dokumentatsioonis ja ITS-ketastel olevaid soovitusi. Olukord on näidatud joonisel fig. 2.

konfigureerige rakendusserveris COM+ turvalisus nii, et ainult 1C kasutajatel oleks õigus ühenduda rakendusserveri protsessiga (täpsemalt [ITS12]);

fail srvrib.lst peab olema kirjutuskaitstud kasutajale USER1CV8SERVER (uue IB lisamiseks serverisse lubage ajutiselt kirjutamine);

MS SQL-iga ühenduse loomiseks kasutage ainult TCP / IP-protokolli, sel juhul saate:
piirata ühendusi tulemüüriga;

konfigureerige mittestandardse TCP-pordi kasutamine, mis raskendab "võõra" IB 1C ühendamist;

kasutada rakendusserveri ja SQL-serveri vahel edastatavate andmete krüptimist;

konfigureerige serveri tulemüür nii, et kolmandate osapoolte MS SQL-serverite kasutamine oleks võimatu;

kasutada sisevõrgu turvatööriistu, et välistada võimalus, et kohtvõrku ilmub volitamata arvuti (IPSec, grupi turvapoliitikad, tulemüürid jne);

mitte mingil juhul ei anna kasutajale USER1CV8SERVER rakendusserveris administraatoriõigusi.

Kasutades serveris töötavat koodi

1C klient-serveri versiooni kasutamisel saab arendaja jaotada koodi täitmist kliendi ja rakendusserveri vahel. Selleks, et kood (protseduur või funktsioon) saaks käivituda ainult serveris, on vaja see paigutada ühisesse moodulisse, mille jaoks on määratud atribuut "Server" ja juhul kui mooduli täitmine on lubatud mitte ainult sisestage kood serveris piiratud jaotisesse "#If Server":

#Kui server Siis
Funktsioon OnServer(Param1, Param2 = 0) Eksport // Seda funktsiooni käivitatakse hoolimata selle lihtsusest serveris
Param1 = Param1 + 12;
Tagasi Param1;
Lõppfunktsioonid
#EndIf

Kui kasutate serveris töötavat koodi, pidage meeles järgmist.

kood käivitatakse USER1CV8SERVER õigustega rakendusserveris (saadaval on COM-objektid ja serverifailid);
kõiki kasutajaseansse juhib teenuse üks eksemplar, nii et näiteks virna ületäitumine serveris põhjustab kõigi aktiivsete kasutajate ühenduse katkestamise;
serverimoodulite silumine on keeruline (näiteks ei saa siluris katkestuspunkti määrata), kuid seda tuleks teha;
juhtimise ülekandmine kliendilt rakendusserverisse ja vastupidi võib nõuda märkimisväärseid ressursse suure hulga edastatavate parameetritega;
interaktiivsete tööriistade (vormid, tabelidokumendid, dialoogiboksid), väliste aruannete kasutamine ja koodis töötlemine rakendusserveris ei ole võimalik;
globaalsete muutujate (rakendusmooduli muutujad, mis on deklareeritud käsuga "Eksport") kasutamine ei ole lubatud;

Vaadake üksikasju [ITS15] ja teistest ITS-i artiklitest.

Rakendusserver peab vastama töökindluse erinõuetele. Õigesti ehitatud klient-server süsteemis peavad olema täidetud järgmised tingimused:

ükski klientrakenduse tegevus ei tohiks serveri tööd katkestada (välja arvatud haldusjuhtumid);
server ei saa kliendilt saadud programmikoodi täita;
ressursid peaksid olema "õiglaselt" jaotatud kliendiühenduste vahel, tagades serveri kättesaadavuse sõltumata praegusest koormusest;
andmelukkude puudumisel ei tohiks kliendiühendused üksteise tööd mõjutada;
serveril puudub kasutajaliides, kuid tuleks välja töötada seire- ja logimisvahendid;

Üldiselt on 1C-süsteem üles ehitatud nii, et see vastaks nendele nõuetele (näiteks on võimatu sundida serveris välist töötlemist läbi viima), kuid siiski on mitmeid ebameeldivaid funktsioone, seetõttu:

Soovitus: Taustakäituse kujundamisel on soovitatav järgida minimaalse liidese põhimõtet. Need. kliendirakendusest serverimoodulite sisendite arv peaks olema väga piiratud ja parameetrid peaksid olema rangelt reguleeritud. Soovitus: Protseduuride ja funktsioonide parameetrite vastuvõtmisel serveris on vaja läbi viia parameetrite valideerimine (kontrollida, et parameetrid vastaksid eeldatavale tüübile ja väärtusvahemikule). Standardlahendustes seda ei tehta, kuid meie enda arendustes on väga soovitav sisse viia kohustuslik valideerimine. Soovitus: Päringute teksti (ja veelgi enam käsu Run parameetri) genereerimisel serveri poolel ära kasuta klientrakendusest saadud stringe.

Üldine soovitus oleks tutvuda turvalise ehitamise põhimõtetega võrk-andmebaaside rakendused ja töö sarnastel põhimõtetel. Sarnasus on tõesti märkimisväärne: esiteks, nagu veebirakendus, on ka rakendusserver vahekiht andmebaasi ja kasutajaliidese vahel (peamine erinevus seisneb selles, et veebiserver moodustab kasutajaliidese); teiseks, turvalisuse seisukohalt ei saa kliendilt saadud andmeid usaldada, sest on võimalik käivitada välised aruanded ja töötlemine.

Parameetrite edastamine

Parameetrite edastamine serveris töötavale funktsioonile (protseduurile) on üsna delikaatne probleem. See on peamiselt tingitud vajadusest neid rakendusserveri protsessi ja kliendi vahel üle kanda. Juhtimise ülekandmisel kliendi poolelt serveri poolele serialiseeritakse kõik edastatavad parameetrid, kantakse üle serverisse, kus need "lahti pakitakse" ja kasutatakse. Serveri poolelt kliendi poolele liikudes on protsess vastupidine. Siinkohal tuleb märkida, et see skeem käsitleb õigesti parameetrite edastamist viite ja väärtuse järgi. Parameetrite edastamisel kehtivad järgmised piirangud:

Kliendi ja serveri vahel saab edastada ainult mittemuutuvaid väärtusi (st mille väärtusi ei saa muuta) (mõlemas suunas): primitiivsed tüübid, viited, üldised kogud, süsteemi loendusväärtused, väärtuste salvestus. Kui proovite saata midagi muud, jookseb klientrakendus kokku (isegi kui server proovib saata vale parameetri).
Parameetrite edastamisel ei ole soovitatav edastada suuri andmemahtusid (näiteks üle 1 miljoni tähemärgi pikkused stringid), see võib serveri jõudlust negatiivselt mõjutada.
Ringviidet sisaldavaid parameetreid ei saa edastada nii serverist kliendile kui ka vastupidi. Kui proovite sellist parameetrit edastada, jookseb klientrakendus kokku (isegi kui server proovib saata vale parameetri).
Väga keerulisi andmekogusid ei soovita edastada. Kui proovite edastada väga suure pesastustasemega parameetrit, jookseb server kokku (! ).

Tähelepanu! Kõige tüütum omadus hetkel on ilmselt viga keeruliste väärtuskogumite edastamisel. Nii näiteks kood: NestingLevel = 1250;
M = uus massiiv;
Läbitud parameeter = M;
N = 1 pesastustaseme silmuse järgi
MVInt = uus massiiv;
M.Add(MVInt);
M = MVin;
EndCycle;
ServerFunction (PassedParameter);

Põhjustab serveri krahhi, katkestades kõigi kasutajate ühenduse, ja see juhtub enne, kui juhtimine läheb üle 1C-koodile.

Ebaturvaliste funktsioonide kasutamine serveri poolel.

Rakendusserveris töötavas koodis ei saa kasutada kõiki sisseehitatud keele funktsioone, kuid isegi saadaolevate tööriistade hulgas on palju "probleemseid" konstruktsioone, mida saab tinglikult liigitada järgmiselt:

on võimeline pakkuma võimalust käivitada koodi, mida konfiguratsioon ei sisalda (rühm "Koodi täitmine")
suudab anda kliendirakendusele teavet kasutaja faili ja operatsioonisüsteemi kohta või teha toiminguid, mis ei ole seotud andmetega töötamisega ("õiguste rikkumine")
võib põhjustada serveri krahhi või kasutada väga suuri ressursse (serveritõrgete rühm)
võib põhjustada kliendi tõrke (rühm "Kliendi rike") – seda tüüpi ei arvestata. Näide: muutuva väärtuse edastamine serverile.
vead programmeerimisalgoritmides (lõpmatud tsüklid, piiramatu rekursioon jne) ("Programmeerimisvead")

Peamised mulle teadaolevad probleemsed konstruktsioonid (koos näidetega) on loetletud allpool:

Protseduur Käivita (<Строка>)

Koodi täitmine. Võimaldab käivitada koodi, mis edastatakse sellele stringiväärtusena. Serveris kasutamisel tuleb jälgida, et parameetrina ei kasutataks kliendilt saadud andmeid. Näiteks ei ole lubatud kasutada järgmist:
#Kui server Siis
Protseduur OnServer(Param1) Eksport
Käivita(Param1);
Lõppprotseduur
#EndIf

Tippige "COMObject" (konstruktor New COMObject(<Имя>, <Имя сервера>))

Loob rakendusserveris (või muus määratud arvutis) välise rakenduse COM-objekti nimega USER1CV8SERVER. Kui kasutate serveris, veenduge, et parameetreid ei edastataks klientrakendusest. Kuid serveri poolel on seda funktsiooni tõhus kasutada importimisel/eksportimisel, andmete üle Interneti saatmisel, mittestandardsete funktsioonide rakendamisel jne.

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

Õiguste rikkumine ja koodi täitmine. Sarnaselt eelmisele, hankides ainult failile vastava COM-objekti.

Protseduurid ja funktsioonidArvutinimi(), TempFileDirectory(), ProgramDirectory(), WindowsUsers()

Õiguste rikkumine. Võimaldab neid serveris käivitades välja selgitada serveri alamsüsteemi korralduse üksikasjad. Kui kasutate serveris, veenduge, et andmeid ei edastataks kliendile või et need pole ilma nõuetekohase volituseta operaatoritele kättesaadavad. Pöörake erilist tähelepanu asjaolule, et andmeid saab viitena edastatud parameetris tagasi anda.

Failidega töötamise protseduurid ja funktsioonid (CopyFile, FindFiles, MergeFiles ja paljud teised), samuti "Faili" tüübid.

Õiguste rikkumine. Need võimaldavad neid serveris käivitades saada jagatud juurdepääsu kohalikele (ja võrgus asuvatele) failidele, mis on saadaval kasutaja USER1CV8SERVER õiguste all. Teadlikul kasutamisel on võimalik efektiivselt realiseerida selliseid ülesandeid nagu andmete import/eksport serverisse.

Enne nende funktsioonide kasutamist kontrollige kindlasti 1C kasutajaõigusi. Kasutajaõiguste kontrollimiseks saate serverimoodulis kasutada järgmist konstruktsiooni:
#Kui server Siis
Protseduur DoWorkOnFile() Eksport
RoleAdministrator = Metadata.Roles.Administrator;
Kasutaja = SessionParameters.CurrentUser;
Kui User.Roles.Contains(RoleAdministrator) Siis
//Siin käivitatakse failidega töötamise kood
EndIf;
#EndIf
Kontrollige kindlasti parameetreid, kui kasutate neid protseduure ja funktsioone, vastasel juhul on oht kogemata või teadlikult tekitada 1C rakendusserverile korvamatut kahju, näiteks serveris koodi käivitamisel:
Path = "C:\Dokumendid ja sätted\Kõik kasutajad\Rakendusandmed\1C\1Cv8\";
MoveFile(Path + "srvrib.lst", Path + "HereWhereFileGone");
Pärast sellise koodi käivitamist serveris, kui kasutajal USER1CV8SERVER on õigus seda muuta, nagu ülal kirjeldatud, ja pärast serveri protsessi taaskäivitamist (vaikimisi 3 minutit pärast kõigi kasutajate väljalogimist), tekib käivitamise kohta SUUR küsimus. server. Kuid faile on võimalik täielikult kustutada ...

Tüübid "XBase", "BinaryData", "XMLReader", "XMLWriter", "XSLTransformer", "ZipFileWrite", "ZipFileReader", "TextReader", "TextWriter"

Õiguste rikkumine. Need võimaldavad serveris käivitades juurdepääsu teatud tüüpi kohalikele (ja võrgus asuvatele) failidele ning neid lugeda/kirjutada kasutaja USER1CV8SERVER õiguste all. Teadlikul kasutamisel on võimalik efektiivselt realiseerida selliseid ülesandeid nagu andmete import/eksport serveris, mõne funktsiooni toimimise logimine, haldusülesannete lahendamine. Üldiselt on soovitused samad, mis eelmises lõigus, kuid peaksite kaaluma võimalust edastada nende failide (kuid mitte kõiki seda tüüpi objekte) andmeid kliendi ja serveri osade vahel.

Tippige "Süsteemi teave"

Õiguste rikkumine. Võimaldab vale kasutamise ja andmete edastamise korral rakenduse kliendiosale saada andmeid rakendusserveri kohta. Kasutamisel on soovitav piirata kasutusõigust.

Tüübid "InternetConnection", "InternetMail", "InternetProxy", "HTTPConnection", "FTPConnection"

Õiguste rikkumine. Kui seda kasutatakse serveris, ühendub see rakendusserverist kaugarvutiga USER1CV8SERVER õiguste all. Soovitused:

Parameetrite juhtimine meetodite kutsumisel.

Kasutajaõiguste kontroll 1C.

Ranged piirangud kasutaja USER1CV8SERVER võrgule juurdepääsuõigustele.

Õige tulemüüri konfiguratsioon 1C rakendusserveris.

Õige kasutamise korral on mugav korraldada näiteks e-kirjade levitamist rakendusserverist.

Tüübid "InfobaseUsersManager", "InfobaseUser"

Õiguste rikkumine. Ebaõigel kasutamisel (privilegeeritud moodulis) on võimalik kasutajaid lisada või olemasolevate kasutajate autoriseerimisparameetreid muuta.

Funktsiooni vorming

Serveri rike. Jah! See näiliselt kahjutu funktsioon, kui selle parameetreid ei kontrollita ja serveris ei käivitata, võib serverirakenduse krahhi põhjustada. Viga ilmneb näiteks numbrite vormindamisel ja eesolevate nullide ja suure hulga märkide väljundrežiimi kasutamisel
Formaat(1, "HTS=999; FHN=");
Loodan, et see viga parandatakse platvormi järgmistes väljaannetes, kuid praegu kontrollige kõigi selle funktsiooni väljakutsete puhul, mida serveris saab käivitada, kõne parameetreid.

Väärtuste salvestamise protseduurid ja funktsioonid (ValueToStringInt, ValueToFile)

Serveri rike. Need funktsioonid ei käsitle kogude ringikujulisi viiteid ega väga sügavat pesastust, mistõttu võivad need mõnel väga erilisel juhul kokku kukkuda.

Vead funktsioonide piirides ja eriparameetrite väärtustes. Täitmise kontroll.

Üheks probleemiks, millega serveri kasutamisel kokku puutuda võib, on serveri funktsioonide suur "vastutus" (ühe ühenduse vea tõttu kogu serverirakenduse kokkujooksmise võimalus ja kõigi ühenduste jaoks ühe "ressursiruumi" kasutamine) . Seetõttu on vaja juhtida peamisi käitusaja parameetreid:

Sisseehitatud keelefunktsioonide puhul kontrollige nende käivitusparameetreid (eesmärk on funktsioon "Format")
Silmuste kasutamisel veenduge, et tsükli väljumise tingimus on käivitatud. Kui tsükkel on potentsiaalselt lõpmatu, piirake iteratsioonide arvu kunstlikult: IterationCountMaxValue = 1000000;
Iteratsiooniarv = 1;
Hüvasti
Funktsioon, mis ei pruugi tagastada vale()
JA (Loendurid<МаксимальноеЗначениеСчетчикаИтераций) Цикл
//.... Loop body
IterationCount = IterationCount + 1;
EndCycle;
Kui IterationCount>IterationCountMaxValue Siis
//.... tegelema liiga pika tsükli täitmisega
EndIf;
Piirake rekursiooni kasutamisel maksimaalset pesastustaset.
Päringute moodustamisel ja täitmisel püüdke vältida väga pikki ja suure hulga teabe toomisi (näiteks tingimuse "HIERARHIAS" kasutamisel ärge kasutage tühja väärtust)
Infobaasi kujundamisel jätke arvudele piisavalt suur varu (vastasel juhul muutuvad liitmine ja korrutamine mittekommutatiivseks ja mitteassotsiatiivseks, mis muudab silumise keeruliseks)
Käivitatavates päringutes kontrollige toimingute loogikast NULL-väärtuste olemasolu ning päringutingimuste ja avaldiste õiget toimimist, kasutades NULL-i.
Kogude kasutamisel kontrollige, kas neid saab edastada rakendusserveri ja kliendi poole vahel.

Terminali juurdepääsu kasutamine kliendi poolele juurdepääsu piiramiseks

Harvad on soovitused kasutada terminali juurdepääsu andmetele juurdepääsu piiramiseks ja jõudluse parandamiseks, käivitades terminaliserveris kliendipoolset koodi. Jah, õige seadistamise korral võib terminali juurdepääsu kasutamine tõepoolest tõsta üldist süsteemi turvalisuse taset, kuid kahjuks võib sageli kohata tõsiasja, et praktilisel kasutamisel süsteemi turvalisus ainult väheneb. Proovime välja mõelda, millega see seotud on. Nüüd on terminali juurdepääsu korraldamiseks kaks levinumat viisi, need on Microsoft Terminal Services (RDP-protokoll) ja Citrix Metaframe Server (ICA-protokoll). Üldiselt pakuvad Citrixi tööriistad palju paindlikumaid juurdepääsu haldusvõimalusi, kuid nende lahenduste maksumus on palju suurem. Vaatleme ainult mõlema protokolli ühiseid põhifunktsioone, mis võivad üldist turbetaset alandada. Terminali juurdepääsu kasutamisel on ainult kolm peamist ohtu:

Võimalus blokeerida teiste kasutajate tööd liigse hulga ressursside hõivamisega
Juurdepääs teiste kasutajate andmetele.
Andmete volitamata kopeerimine terminaliserverist kasutaja arvutisse

Igal juhul võimaldab terminaliteenused teil:

Suurendada töökindlust (terminalarvuti rikke korral saab kasutaja hiljem samast kohast tööd jätkata)
Piirake juurdepääsu kliendirakendusele ja selle salvestatavatele failidele.
Viige arvutuskoormus kasutaja töökohast üle terminali juurdepääsuserverisse
Hallake süsteemiseadeid kesksemalt. Kasutajate jaoks kehtivad salvestatud sätted sõltumata sellest, millisest arvutist nad süsteemi sisse logisid.
Mõnel juhul saate süsteemile kaugjuurdepääsuks kasutada terminalilahendust.

Vajalik on piirata võimalike ühenduste arvu ühe kasutaja terminaliserveriga

1C-kliendirakenduse ressursside ahvatlemise tõttu on hädavajalik piirata ühe kasutaja (operaatori) üheaegsete ühenduste maksimaalset arvu terminaliserveriga. Aktiivne ühendus võib kasutada kuni 300 MB mälu ainult ühe rakenduse eksemplariga. Lisaks mälule kasutatakse aktiivselt protsessori aega, mis samuti ei aita kaasa selle serveri kasutajate töö stabiilsusele. Samaaegselt serveriressursside liigse kasutamise vältimisega võib selline piirang takistada kellegi teise konto kasutamist. Rakendatud standardsete terminaliserveri sätetega.

Ühes ühenduses ei tohi korraga töötada rohkem kui üks või kaks 1C-klientrakendust

Seda tingivad samad põhjused nagu eelmises lõigus, kuid seda on tehniliselt keerulisem rakendada. Probleem on selles, et 1C-l on peaaegu võimatu takistada terminaliserverit kasutades taaskäivitamist (allpool selgitatakse, miks), seega peate selle funktsiooni juurutama rakenduse lahenduse tasemel (mis pole samuti hea lahendus, kuna Kui rakendus on mõnda aega "riputatud", on vaja rakendusmoodulis ja mõnes kataloogis rakenduse lahendust täpsustada, mis raskendab 1C värskenduste kasutamist). Äärmiselt soovitav on jätta kasutajale võimalus käivitada 2 rakendust, et saaks mõnda tegevust taustal käivitada (näiteks aruannete genereerimine) - klientrakendus on kahjuks tegelikult ühe lõimega.

Ei ole soovitatav anda terminaliserverile juurdepääsuõigusi kasutajatele, kellel on õigus 1C-s ressursimahukaid arvutusülesandeid käivitada, või takistada sellist käivitamist teiste kasutajate aktiivse töö ajal.

Loomulikult on parem jätta juurdepääs terminaliserverile ainult kasutajatele, kes ei kasuta selliseid ülesandeid nagu andmete analüüs (andmekaevandamine), geograafilised skeemid, import / eksport ja muud rakenduse kliendipoolset külge tõsiselt koormavad toimingud. Kui sellegipoolest on vaja selliseid ülesandeid lahendada, siis on vaja: teavitada kasutajat, et need ülesanded võivad mõjutada teiste kasutajate jõudlust, salvestada logisse sellise toimingu alguse ja lõpu sündmus. protsessi, et lubada täitmist ainult ettenähtud aegadel jne.

Peate veenduma, et igal kasutajal on kirjutamisõigus ainult rangelt määratletud terminaliserveri kataloogidele ja et teistel kasutajatel pole neile juurdepääsu.

Esiteks, kui te ei piira võimalust kirjutada jagatud kataloogidesse (näiteks kataloogi, kuhu 1C on installitud), on ründajal siiski võimalus muuta programmi käitumist kõigi kasutajate jaoks. Teiseks ei tohiks ühe kasutaja andmed (ajutised failid, aruannete seadistuste salvestamise failid jne) kunagi teisele terminaliserveri kasutajale kättesaadavad olla – üldjuhul järgitakse seda reeglit tavakonfigureerimisel. Kolmandaks on ründajal siiski võimalus partitsiooni "risustada", et kõvakettale ruumi ei jääks. Ma tean, et vastu vaieldakse, et alates Windows 2000-st on Windowsis kvoodimehhanism, kuid see on üsna kallis mehhanism ja ma pole praktiliselt kunagi näinud selle tegelikku kasutamist.

Kui varasemad juurdepääsusätete küsimused olid üldiselt üsna lihtsalt teostatavad, siis selline (näiliselt) lihtne ülesanne nagu kasutajate juurdepääsu reguleerimine failidele pole triviaalne. Esiteks, kui kvoodimehhanismi ei kasutata, saab suuri faile salvestada. Teiseks on süsteem üles ehitatud nii, et peaaegu alati on võimalik faili salvestada nii, et see oleks teisele kasutajale kättesaadav.

Arvestades, et ülesannet on raske täielikult lahendada, on soovitatav enamikku failisündmusi auditeerida

Vajalik on keelata kettaseadmete, printerite ja klienditööjaama lõikepuhvri ühendamine (kaardistamine).

RDP ja ICA puhul on võimalik korraldada terminali arvuti ketaste, printerite, lõikepuhvri com-portide automaatne ühendamine serveriga. Kui see võimalus on olemas, siis on praktiliselt võimatu keelata kõrvalise koodi käivitamist terminaliserveris ja andmete salvestamist 1C-st terminali juurdepääsukliendis. Luba need funktsioonid ainult administraatoriõigustega inimestele.

Juurdepääs võrgufailidele terminaliserverist peab olema piiratud.

Kui seda ei tehta, saab kasutaja taas käitada soovimatut koodi või salvestada andmeid. Kuna tavalogi failisündmusi ei jälgi (muide, see on platvormi arendajatele hea idee juurutamiseks) ja kogu võrgus süsteemiauditit on peaaegu võimatu seadistada (selle hooldamiseks pole piisavalt ressursse), on parem, kui kasutaja saab andmeid saata või printida või meili teel. Pöörake erilist tähelepanu asjaolule, et terminaliserver ei tööta otse kasutaja irdkandjaga.

Mitte mingil juhul ei tohiks turvalise süsteemi loomisel jätta rakendusserverit terminaliserverisse.

Kui rakendusserver töötab klientrakendustega samas arvutis, siis on selle normaalse töö häirimiseks üsna palju võimalusi. Kui terminaliserveri ja rakendusserveri funktsioone ei ole mingil põhjusel võimalik eraldada, siis pöörake erilist tähelepanu kasutaja juurdepääsule rakendusserveri poolt kasutatavatele failidele.

On vaja välistada võimalus käivitada terminaliserveris kõik rakendused, välja arvatud 1C: Enterprise.

See on üks raskemini täidetavaid soove. Alustame sellest, et domeenis on vaja õigesti konfigureerida rühma turvapoliitika. Kõik "Haldusmallid" ja "Tarkvarapiirangute eeskirjad" peavad olema õigesti konfigureeritud. Enda testimiseks veenduge, et vähemalt järgmised valikud on keelatud.

Selle nõude rakendamise keerukus toob sageli kaasa võimaluse käivitada terminaliserveris "lisa" 1C seanss (isegi kui muud rakendused on piiratud, on Windowsi abil 1C käivitamist põhimõtteliselt võimatu keelata).

Võtke arvesse tavapärase registreerimislogi piiranguid (kõik kasutajad kasutavad programmi ühest arvutist)

Ilmselgelt, kuna kasutajad avavad 1C terminalirežiimis, salvestatakse registreerimislogi terminaliserver. Millise arvutiga kasutaja ühendas, logi ei teata.

Terminaliserver – kaitse või haavatavus?

Seega, pärast terminalide põhjaosa põhijooni kaaludes, võib öelda, et potentsiaalselt võib terminalide põhjaosa aidata automatiseerida arvutuskoormuse jaotust, kuid turvalise süsteemi ülesehitamine on üsna keeruline. Üks juhtumeid, mil terminaliserveri kasutamine on kõige tõhusam, on 1C käivitamine ilma Windows Explorerita täisekraanirežiimis piiratud funktsionaalsuse ja spetsiaalse liidesega kasutajatele.

Kliendipoolne töö

Internet Exploreri (IE) kasutamine

1C kliendiosa normaalse töö üheks tingimuseks on Internet Exploreri komponentide kasutamine. Nende komponentidega peate olema väga ettevaatlik.

Tähelepanu! Esiteks, kui IE-le on "kinnitatud" nuhkvara või reklaamvara moodul, siis see laaditakse isegi siis, kui 1C-s vaadatakse mõnda HTML-faili. Seni pole ma selle funktsiooni teadlikku kasutamist näinud, kuid olen näinud ühes organisatsioonis ühe pornograafilise võrgu "nuhkvara" moodulit, kui 1C töötab (viirusetõrjeprogrammi ei värskendatud, sümptomid millest leiti: tulemüüri seadistamisel oli selge, et 1C proovis pordil 80 ühendust porno saidiga). Tegelikult on see veel üks argument selle kasuks, et kaitse peaks olema kõikehõlmav.

Tähelepanu! Teiseks võimaldab 1C-süsteem kuvatavates HTML-dokumentides kasutada flash-filme, ActiveX-objekte, VBScripti, saata andmeid Internetti, isegi avada PDF-faile (!), Tõsi, viimasel juhul küsib see "ava või salvesta" .. Üldiselt, mida iganes su süda ihkab. Näide sisseehitatud HTML-i vaatamis- ja redigeerimisvõimaluse mitte täiesti mõistlikust kasutamisest:

Looge uus HTML-dokument (Fail -> Uus -> HTML-dokument).
Minge tühja dokumendi vahekaardile "Tekst".
Kustuta tekst (täielikult).
Minge selle dokumendi vahekaardile "Vaade".
Drag-n-drop abil liiguta SWF-laiendiga fail (need on flash-filmifailid) avatud explorerist dokumendiaknasse, näiteks brauseri vahemälust, kuigi naljalt on see võimalik ka FLASH-mänguasjaga.
Kui armas! 1C-l saate mänguasja joosta!

Süsteemi turvalisuse seisukohast on see täiesti vale. Seni pole ma selle haavatavuse kaudu 1C-le spetsiaalseid rünnakuid näinud, kuid suure tõenäosusega osutub see aja ja teie teabe väärtuse küsimuseks.

HTML-dokumendis väljaga töötades ilmnevad veel mõned väiksemad punktid, kuid need kaks on peamised. Kuigi kui lähenete nendele funktsioonidele loovalt, saate 1C-ga töötamiseks korraldada tõeliselt hämmastavaid liidesevõimalusi.

Väliste aruannete kasutamine ja töötlemine.

Tähelepanu! Välised aruanded ja töötlemine – ühelt poolt on mugav viis täiendavate prinditavate vormide, regulatiivsete aruandluse, eriaruannete juurutamiseks, teisest küljest potentsiaalne viis paljudest süsteemi turvapiirangutest mööda hiilimiseks ja rakendusserveri häirimiseks (näiteks vt ülalpool jaotist "Parameetrite läbimine"). 1C süsteemil on rolli "Välise töötlemise interaktiivne avamine" õiguste komplektis spetsiaalne parameeter, kuid see ei kõrvalda probleemi täielikult - täieliku lahenduse saamiseks on vaja kitsendada kasutajate ringi, kes saavad hallata. välised printimisvormid, rutiinsed aruanded ja muud välistöötluse abil rakendatud standardlahenduste regulaarsed funktsioonid. Näiteks on SCP-s vaikimisi kõigil peamistel kasutajarollidel võimalus töötada täiendavate printimisvormide kataloogiga ja see on tegelikult võimalus kasutada mis tahes välist töötlemist.

Standardlahenduste ja platvormi standardmehhanismide kasutamine (andmevahetus)

Mõned standardmehhanismid on potentsiaalselt ohtlikud ja üsna ootamatul viisil.

Nimekirjade trükkimine

Iga süsteemi loendit (näiteks kataloogi või teaberegistrit) saab printida või faili salvestada. Selleks piisab, kui kasutada kontekstimenüüst ja menüüst "Toimingud" saadaolevat standardfunktsiooni:

Pidage meeles, et peaaegu kõike, mida kasutaja loendites näeb, saab väljastada välistesse failidesse. Ainus, mida saab soovitada, on dokumentide printimise protokolli hoidmine prindiserverites. Eriti kriitiliste vormide puhul on vaja konfigureerida kaitstud tabeliväljaga seotud tegevuspaneel nii, et sellelt paneelilt loendi kuvamise võimalus puudub, ning keelata kontekstimenüü (vt joonis 6).

Andmevahetus hajutatud andmebaasis

Andmevahetuse formaat on üsna lihtne ja seda on kirjeldatud dokumentatsioonis. Kui kasutajal on võimalus mitu faili asendada, saab ta süsteemis volitamata muudatusi teha (kuigi see ülesanne on üsna töömahukas). Võimalus luua servandmebaasi hajutatud andmebaasivahetusplaanide kasutamisel ei peaks olema tavaoperaatoritele kättesaadav.

Standardne XML andmevahetus

Tavalises andmevahetuses, mida kasutatakse tüüpiliste konfiguratsioonide vaheliseks vahetuseks (näiteks "Kaubanduse juhtimine" ja "Ettevõtte raamatupidamine"), on võimalik vahetusreeglites määrata objekti laadimise ja mahalaadimise sündmuste töötlejad. Seda rakendatakse failist töötleja hankimise ja faili laadimise ja mahalaadimise standardtöötluse "Execute()" protseduuriga (kliendi poolel käivitatakse protseduur "Execute()"). Ilmselgelt pole keeruline luua sellist võltsitud vahetusfaili, mis sooritaks pahatahtlikke toiminguid. Enamiku üldiste lahenduste kasutajarollide puhul on jagamine vaikimisi lubatud.

Soovitus: piirata enamiku kasutajate juurdepääsu XML-vahetusele (jäta ainult infoturbe administraatoritele). Pidage arvestust selle töötlemise käivitamiste kohta, salvestades vahetusfaili, näiteks saates selle enne allalaadimist e-postiga infoturbe administraatorile.

Üldiste aruannete, eriti aruandluskonsooli kasutamine

Teine probleem on kasutaja vaikejuurdepääs üldistele aruannetele, eriti aruannete konsooli aruandele. Seda aruannet iseloomustab asjaolu, et see võimaldab teil täita peaaegu kõiki teabeturbe taotlusi ja isegi kui 1C õiguste süsteem (sh RLS) on üsna jäigalt seadistatud, võimaldab see kasutajal saada palju "tarbetut" teavet ja sundida serverit sellist päringut täitma, mis võtab kõik ressursisüsteemid.

Täisekraani režiimi kasutamine (töölauarežiim)

Üks tõhusaid viise spetsiaalsete liideste korraldamiseks, millel on piiratud juurdepääs programmi funktsionaalsusele, on kasutatava liidese peamise (ja võib-olla ka ainsa) vormi täisekraanirežiim. Samas puuduvad ligipääsetavusprobleemid, näiteks menüü "Fail" ning kõik kasutaja tegevused on piiratud kasutatava vormi võimalustega. Üksikasju vaadake ITS-i kettal jaotisest "Töölauarežiimi rakendamise funktsioonid".

Varundamine

1C klient-serveri versiooni varukoopiaid saab teha kahel viisil: andmete üleslaadimine dt-laiendiga faili ja varukoopiate loomine SQL-i abil. Esimesel meetodil on palju puudusi: vaja on eksklusiivset juurdepääsu, koopia loomine võtab palju kauem aega, mõnel juhul (kui IS-i struktuuri rikutakse) on arhiivi loomine võimatu, kuid sellel on üks eelis - minimaalne suurus. arhiivist. SQL-i varukoopia puhul on vastupidi: koopia luuakse taustal SQL-serveri abil, lihtsa ülesehituse ja tihendamise puudumise tõttu on see väga kiire protsess ning seni, kuni SQL-i andmebaasi füüsiline terviklikkus on säilinud. ei rikuta, tehakse varukoopia, kuid koopia suurus on sama, mis IB tegelik suurus laiendatud olekus (tihendamist ei tehta). MS SQL varundussüsteemi lisaeelistest tulenevalt on seda otstarbekam kasutada (lubatud on 3 tüüpi varukoopiaid: täis-, diferentsiaal-, tehingulogi koopia; võimalik luua regulaarselt täidetavaid ülesandeid; varukoopia ja varusüsteem võetakse kiiresti kasutusele; võime ennustada vajaliku kettaruumi suurust jne). Varundamise korraldamise põhipunktid süsteemi turvalisuse seisukohast on järgmised:

Vajadus valida varukoopiate salvestamise koht selliselt, et need poleks kasutajatele kättesaadavad.
Vajadus hoida varukoopiaid MS SQL serverist füüsilisel kaugusel (loodusõnnetuste, tulekahjude, rünnakute jms korral)
Võimalus anda varundamise alustamise õigusi kasutajale, kellel puudub juurdepääs varukoopiatele.

Lisateabe saamiseks vaadake MS SQL-i dokumentatsiooni.

Andmete krüpteerimine

Andmete kaitsmiseks volitamata juurdepääsu eest kasutatakse sageli erinevaid krüptograafilisi tööriistu (nii tarkvara kui riistvara), kuid nende otstarbekus sõltub suuresti õigest rakendusest ja süsteemi üldisest turvalisusest. Arvestame andmete krüptimist andmeedastuse ja -salvestuse erinevates etappides kõige levinumate vahenditega ning peamisi süsteemi projekteerimise vigu krüptograafiliste tööriistade abil.

Teabe töötlemisel on mitu põhietappi, mida saab kaitsta:

Andmeedastus süsteemi kliendiosa ja rakendusserveri vahel
Andmeedastus rakendusserveri ja MS SQL Serveri vahel
MS SQL Serveris salvestatud andmed (andmefailid füüsilisel kettal)
IB-s salvestatud andmete krüpteerimine
Välised andmed (seoses infoturbega)

Kliendi poolel ja rakendusserveris salvestatud andmete puhul (salvestatud kasutaja seaded, IB loend jne) on krüpteerimine õigustatud ainult väga harvadel juhtudel ja seetõttu seda siin ei käsitleta. Krüptotööriistade kasutamisel ei tohiks unustada, et nende kasutamine võib oluliselt vähendada süsteemi kui terviku jõudlust.

Üldteave võrguühenduste krüptograafilise kaitse kohta TCP / IP-protokolli kasutamisel.

Ilma kaitseta on kõik võrguühendused volitamata järelevalve ja juurdepääsu suhtes haavatavad. Nende kaitsmiseks võite kasutada andmete krüptimist võrguprotokolli tasemel. Kohalikus võrgus edastatavate andmete krüptimiseks kasutatakse kõige sagedamini operatsioonisüsteemi pakutavaid IPSec-tööriistu.

IPSec-tööriistad pakuvad edastatud andmete krüptimist DES- ja 3DES-algoritmide abil ning terviklikkuse kontrollimist MD5 või SHA1 räsifunktsioonide abil. IPSec saab töötada kahes režiimis: transpordirežiim ja tunnelirežiim. Transpordirežiim on parem kohtvõrgu ühenduste tagamiseks. Tunnelirežiimi saab kasutada VPN-ühenduste korraldamiseks eraldi võrgusegmentide vahel või kaugühenduse kaitsmiseks kohaliku võrguga avatud andmekanalite kaudu.

Selle lähenemisviisi peamised eelised on järgmised:

Võimalus turvalisust tsentraalselt hallata Active Directory tööriistade abil.
Võimalus välistada volitamata ühendused rakendusserveri ja MS SQL serveriga (näiteks on võimalik kaitsta rakendusserveris infoturbe volitamata lisamise eest).
Erandiks võrguliikluse "kuulamine".
Rakendusprogrammide (antud juhul 1C) käitumist pole vaja muuta.
Sellise lahenduse standard.

Sellel meetodil on aga piirangud ja puudused:

IPSec ei kaitse andmeid otse lähte- ja sihtarvutites võltsimise ja pealtkuulamise eest.
Võrgu kaudu edastatavate andmete hulk on mõnevõrra suurem kui ilma IPSec-i kasutamata.
IPSeci kasutamisel on keskprotsessori koormus mõnevõrra suurem.

IPSec-i juurutamise üksikasjalik kirjeldus ei kuulu selle artikli ulatusse ja nõuab IP-protokolli põhiprintsiipide mõistmist. Ühenduse turvalisuse õigesti konfigureerimiseks lugege vastavat dokumentatsiooni.

Eraldi on VPN-ühenduste korraldamisel vaja mainida mitmeid 1C-ga sõlmitud litsentsilepingu aspekte. Fakt on see, et vaatamata tehniliste piirangute puudumisele on kohaliku võrgu mitme segmendi ühendamisel või ühe arvuti kaugjuurdepääsul kohtvõrku tavaliselt vaja mitut põhitarvikut.

Andmete krüpteerimine süsteemi kliendiosa ja rakendusserveri vahelise edastamise ajal.

Lisaks võrguprotokolli tasemel krüpteerimisele on võimalik krüpteerida andmeid ka COM+ protokolli tasemel, millest on juttu ITS-i artiklis "Kasutajate juurdepääsu reguleerimine infobaasile klient-server versioonis". Selle rakendamiseks peate määrama 1CV8 rakenduse jaoks "Komponentiteenused", et seada kõnede autentimistasemeks "Pakettide privaatsus". Kui see režiim on määratud, autenditakse ja krüpteeritakse pakett, sealhulgas andmed ning saatja identiteet ja allkiri.

Andmete krüpteerimine rakendusserveri ja MS SQL Serveri vahelise edastuse ajal

MS SQL Server pakub andmete krüptimiseks järgmisi tööriistu:

Andmete edastamisel rakendusserveri ja MS SQL Serveri vahel on võimalik kasutada SSL-i (Secure Sockets Layer).
Võrguteegi Multiprotocol kasutamisel kasutatakse andmete krüptimist RPC tasemel. See on potentsiaalselt nõrgem krüptimine kui SSL-i puhul.
Kui kasutatakse Shared Memory vahetusprotokolli (see juhtub siis, kui rakendusserver ja MS SQL Server asuvad samas arvutis), siis krüptimist mingil juhul ei kasutata.

Konkreetse MS SQL-serveri jaoks kõigi edastatavate andmete krüptimise vajaduse seadistamiseks kasutage utiliiti "Server Network Utility". Käivitage see ja vahekaardil "Üldine" märkige ruut "Force Protocol encryption". Krüpteerimismeetod valitakse sõltuvalt sellest, mida klientrakendus (st 1C rakendusserver) kasutab. SSL-i kasutamiseks peate oma võrgus sertifikaadi väljastamise teenuse õigesti konfigureerima.

Et määrata, kas kõik edastatavad andmed peavad olema konkreetse rakendusserveri jaoks krüptitud, kasutage "Client Network Utility" (tavaliselt asub "C:\WINNT\system32\cliconfg.exe"). Nagu eelmisel juhul, märkige vahekaardil "Üldine" ruut "Sundi protokolli krüpteerimine".

Tuleb meeles pidada, et krüptimise kasutamine võib sel juhul oluliselt mõjutada süsteemi jõudlust, eriti kui kasutatakse päringuid, mis tagastavad suurel hulgal teavet.

Rakendusserveri ja MS SQL Serveri vahelise ühenduse täielikumaks kindlustamiseks TCP/IP-protokolli kasutamisel saame soovitada mõningaid muudatusi vaikeseadetes.

Esiteks saate määrata standardsest erineva pordi (vaikimisi kasutatakse porti 1433). Kui otsustate andmevahetuseks kasutada mittestandardset TCP-porti, pange tähele, et:

MS SQL Server ja Application Server peavad kasutama sama porti.
Tulemüüride kasutamisel peab see port olema lubatud.
Te ei saa määrata porti, mida saavad kasutada MS SQL serveri teised rakendused. Lisateavet leiate aadressilt http://www.ise.edu/in-notes/iana/assignments/port-numbers (aadress on võetud veebisaidilt SQL Server Books Online).
Kui kasutate MS SQL Serveri teenuse mitut eksemplari, lugege konfigureerimiseks kindlasti MS SQL-i dokumentatsiooni (jaotis "Võrguühenduste konfigureerimine").

Teiseks saate MS SQL serveri TCP/IP-protokolli sätetes määrata märkeruudu "Peida server", mis keelab vastused MS SQL Serveri teenuse sellele eksemplarile edastatavatele päringutele.

Kettale salvestatud MS SQL-i andmete krüpteerimine

Kohalikul kettal asuvate andmete krüptimiseks on üsna suur valik tarkvara ja riistvara (see on Windowsi tavapärane võimalus kasutada EFS-i ja eToken võtmeid ning kolmandate osapoolte programme nagu Jetico Bestcrypt või PGPDisk). Üks peamisi ülesandeid, mida need tööriistad täidavad, on andmete kaitsmine andmekandja kadumise korral (näiteks kui server varastatakse). Eraldi tuleb märkida, et Microsoft ei soovita MS SQL-i andmebaase krüpteeritud andmekandjatele salvestada ja see on igati õigustatud. Peamine probleem on sel juhul jõudluse märkimisväärne langus ja võimalikud riketest tulenevad töökindlusprobleemid. Teine tegur, mis muudab süsteemiadministraatori elu keerulisemaks, on vajadus tagada, et kõik andmebaasifailid oleksid MS SQL-teenuse esmakordsel juurdepääsul neile kättesaadavad (st krüpteeritud faili ühendamisel on soovitav interaktiivsed toimingud välistada meedia).

Süsteemi jõudluse märgatava languse vältimiseks võite kasutada MS SQL-i võimalust luua andmebaase mitmes failis. Loomulikult ei tohiks sel juhul MS SQL andmebaasi infobaasi loomisel luua 1C server, vaid see tuleks luua eraldi. Allpool on toodud TSQL-i skripti näide koos kommentaaridega:

USEmaster
MINNA
-- Loo andmebaas SomeData,
LOO ANDMEBAAS SomeData
-- mille kogu andmed asuvad PEAMISES failirühmas.
ESMASEL
-- Põhiandmefail asub krüptitud andmekandjal (loogiline draiv E:)
-- ja selle esialgne suurus on 100 MB, mida saab automaatselt suurendada 200 MB-ni
-- samm 20 Mb
(NAME = SomeData1,
FILENAME = "E:\SomeData1.mdf",
SUURUS = 100 MB,
MAXSIZE = 200
FILEGROWTH=2),
-- Teine andmefail asub krüptimata andmekandjal (loogiline draiv C:)
-- ja selle esialgne suurus on 100 MB, seda saab automaatselt suurendada limiidini
-- kettaruumi 5% sammuga praegusest failisuurusest (ümardatuna kuni 64 KB)
(NAME = SomeData2,
FILENAME = "c:\program files\microsoft sql server\mssql\data\SomeData2.ndf",
SUURUS = 100 MB,
MAXSIZE=PIIRAMATU,
FAILIKAV = 5%)
SISSE LOGIMA
-- Kuigi tehingute logi võiks ka osadeks jagada, ei tohiks seda teha,
-- sest seda faili muudetakse palju sagedamini ja seda puhastatakse regulaarselt (näiteks kui
-- andmebaasist varukoopia loomine).
(NAME = SomeDatalog,
FILENAME = "c:\program files\microsoft sql server\mssql\data\SomeData.ldf",
SUURUS = 10 MB,
MAXSIZE=PIIRAMATU,
FILEGROWTH=10)
MINNA
-- Parem on anda andmebaasi omandiõigus kohe kasutajale, kelle nimel
-- 1C ühendatakse. Selleks peame deklareerima praeguse baasi
- just loodud
KASUTAGE SomeData
MINNA
-- ja käivitage sp_changedboowner
EXEC sp_changedbowner @loginame = "Mõned andmed_dbowner"

Väike kõrvalepõige andmefaili suuruse automaatse kasvu kohta. Vaikimisi suurenevad loodud andmebaaside failimahud 10% sammuga praegusest failisuurusest. See on väikeste andmebaaside jaoks täiesti vastuvõetav lahendus, kuid mitte eriti hea suurte andmebaaside jaoks: näiteks 20 GB suuruse andmebaasi korral peaks fail suurenema korraga 2 GB võrra. Kuigi seda sündmust tuleb ette harva, võib see kesta mitukümmend sekundit (kõik muud tehingud on sel ajal tegelikult jõude), mis kui see toimub andmebaasiga aktiivse töö ajal, võib see põhjustada mõningaid tõrkeid. Teine proportsionaalse juurdekasvu negatiivne mõju, mis ilmneb siis, kui kettaruum on peaaegu täielikult täidetud, on enneaegse rikke võimalus vaba ruumi puudumise tõttu. Näiteks kui 40 GB suurune ketta partitsioon on täielikult eraldatud ühe andmebaasi jaoks (täpsemalt selle andmebaasi ühe faili jaoks), siis on andmebaasifaili kriitiline suurus, mille juures on vaja kiiresti (väga kiiresti, kuni katkestuseni) tavalisest kasutajatööst) korraldada ümber teabe salvestamine on andmefaili suurus 35 GB. Kui juurdekasvu suuruseks on määratud 10–20 MB, saate tööd jätkata, kuni jõuate 39 GB-ni.

Seega, kuigi ülaltoodud loend määrab ühe andmebaasifaili suuruse suurendamise 5% sammuga, on suurte andmebaaside jaoks parem määrata fikseeritud juurdekasv 10–20 MB. Andmebaasifailide suuruse kasvusammu väärtuste määramisel tuleb arvestada, et enne kui üks failigrupi failidest saavutab maksimaalse suuruse, kehtib reegel: ühe failirühma failid kasvavad kõik samal ajal, kui need kõik on täielikult täidetud. Nii et ülaltoodud näites, kui fail SomeData1.mdf saavutab oma maksimaalse suuruse 200 MB, on faili SomeData2.ndf suurus umbes 1,1 GB.

Pärast sellise andmebaasi loomist, isegi kui selle kaitsmata failid SomeData2.ndf ja SomeData.ldf muutuvad ründajale kättesaadavaks, on andmebaasi tegeliku oleku – andmete (sealhulgas teabe andmebaasi loogilise struktuuri kohta) taastamine äärmiselt keeruline. ) on hajutatud mitme faili vahel, pealegi on põhiteave (näiteks selle kohta, millised failid selle andmebaasi moodustavad) krüptitud failis.

Muidugi, kui andmebaasifaile hoitakse krüptograafiliste vahenditega, siis ei tohiks (vähemalt nendest failidest) varukoopiaid teha krüpteerimata andmekandjale. Tagamaks, et üksikud andmebaasifailid oleksid varundatud, kasutage käsku BACKUP DATABASE sobivat süntaksit. Pange tähele, et hoolimata võimalusest kaitsta andmebaasi varukoopiat parooliga (käsu "BACKUP DATABASE" valikud "PASSWORD = " ja "MEDIAPASSWORD = "), ei ole selline varukoopia krüptitud!

Kettale salvestatud rakendusserveri ja kliendi andmete krüpteerimine

Enamasti ei saa 1C:Enterprise'i poolt kasutatavate failide (kliendiosa ja rakendusserver) krüptitud meediumil hoidmist pidada põhjendatuks ebamõistlikult suurte kulude tõttu, kuid sellise vajaduse olemasolul tuleb arvestada, et rakendusserver ja kliendiosa rakendus loob väga sageli ajutisi faile. Sageli võivad need failid pärast rakenduse lõppu alles jääda ja nende eemaldamist 1C tööriistade abil on peaaegu võimatu tagada. Seega tekib 1C-s ajutiste failide jaoks kasutatav kataloog krüptimine või RAM-draivi abil kettale salvestamata jätmine (viimane võimalus pole genereeritud failide suuruse ja RAM-i mahu nõuete tõttu alati võimalik rakendusest 1C:Enterprise).

Andmete krüpteerimine sisseehitatud 1C tööriistadega.

Regulaarsed võimalused krüptimise kasutamiseks 1C-s taanduvad objektide kasutamisele krüpteerimisparameetritega Zip-failidega töötamiseks. Saadaval on järgmised krüpteerimisrežiimid: AES-algoritm võtmega 128-, 192- või 256-bitine ja vananenud algoritm, mida algselt kasutati Zip-arhiivis. AES-iga krüptitud ZIP-failid ei ole paljudele arhiivijatele loetavad (WinRAR, 7zip). Krüpteeritud andmeid sisaldava faili genereerimiseks peate määrama parooli ja krüpteerimisalgoritmi. Sellel funktsioonil põhinevate krüpteerimis-dekrüpteerimise funktsioonide lihtsaim näide on toodud allpool:

Funktsioon EncryptData (andmed, parool, krüpteerimismeetod = määramata) Eksport

// Kirjutage andmed ajutisse faili. Tegelikult ei saa kõiki andmeid sel viisil salvestada.
ValueToFile(TempFileName, Data);

// Ajutiste andmete kirjutamine arhiivi
Zip = uus ZipFileEntry(TempArhiivi failinimi, parool, krüpteerimismeetod);
Zip.Add(TemporaryFileName);
Zip.Write();

// Vastuvõetud arhiivi andmete lugemine RAM-i
Krüpteeritud andmed = NewValueStorage(New BinaryData(TempArchiveFileName));

// Ajutised failid – kustuta

EndFunction Function DecryptData (krüptitud andmed, parool) eksport

// Tähelepanu! Läbitud parameetrite õigsust ei jälgita

// Kirjutage edastatud väärtus faili
TempArchiveFileName = GetTemporalFileName("zip");
BinaryArchiveData = EncryptedData.Get();
BinaryArchiveData.Write(TempArchiveFileName);

// Ekstrakti äsja kirjutatud arhiivi esimene fail
TempFileName = GetTempFileName();
Zip = NewReadZipFile(TempArchiveFileName, parool);
Zip.Extract(Zip.Items, TemporaryFileName, FilePath Recovery ModeZIP.Don'tRecover);

// Loe kirjutatud faili
Andmed = ValueFromFile(TempFileName + "\" + Zip.Elements.Name);

// Kustutage ajutised failid
Kustuta failid(TempFileName);
Kustuta failid(TempArchiveFileName);

Andmete tagastamine;

Lõppfunktsioonid

Muidugi ei saa seda meetodit ideaalseks nimetada - andmed kirjutatakse ajutisse kausta selge tekstina, meetodi jõudlus pole ausalt öeldes kusagil halvem, andmebaasis salvestamine nõuab äärmiselt palju ruumi, kuid see on ainus meetod, mis põhineb ainult platvormi sisseehitatud mehhanismidel. Lisaks on sellel eelis paljude teiste meetodite ees – see meetod teostab andmete pakendamist samaaegselt krüpteerimisega. Kui soovite krüptimist rakendada ilma selle meetodi puudusteta, peate need kas rakendama välises komponendis või viitama olemasolevatele teekidele COM-objektide loomise kaudu, näiteks Microsoft CryptoAPI abil. Toome näitena stringi krüpteerimise / dekrüpteerimise funktsioonid saadud parooli alusel.

Funktsioon EncryptStringDES (krüptimata string, parool)

CAPICOM_ENCRYPTION_ALGORITHM_DES = 2; // See konstant pärineb CryptoAPI-st

EncryptionMechanism.Content = tavaline string;
EncryptionMechanism.Algorithm.Name = CAPICOM_ENCRYPTION_ALGORITHM_DES;
EncryptedString = EncryptionMechanism.Encrypt();

Tagasta EncryptedString;

EndFunction // EncryptStringDES()

Funktsioon DecryptStringDES (krüpteeritud string, parool)

//Tähelepanu! Parameetreid ei kontrollita!

EncryptionMechanism = Uus COMObject("CAPICOM.EncryptedData");
Krüpteerimismehhanism.SetSecret(Password);
Katse
EncryptionMechanism.Decrypt(EncryptedString);
Erand
// Vale parool!;
Tagasta määramata;
Katse lõpp;

Tagasta krüpteerimismehhanism.Sisu;

EndFunction // DecodeStringDES()

Pidage meeles, et tühja väärtuse stringina või paroolina nendele funktsioonidele edastamine genereerib veateate. Selle krüpteerimisprotseduuri abil saadud string on mõnevõrra pikem kui originaal. Selle krüptimise eripära on selline, et kui krüpteerite stringi kaks korda, EI OLE saadud stringid identsed.

Peamised vead krüptotööriistade kasutamisel.

Krüptograafiliste tööriistade kasutamisel tehakse sageli samu vigu:

Toimivuse halvenemise alahindamine krüptograafia kasutamisel.

Krüptograafia on ülesanne, mis nõuab üsna palju arvutusi (eriti selliste algoritmide puhul nagu DES, 3DES, GOST, PGP). Ja isegi suure jõudlusega ja optimeeritud algoritmide (RC5, RC6, AES) kasutamise korral pole pääsu tarbetust andmeedastusest mälus ja arvutuslikus töötlemises. Ja see muudab peaaegu olematuks paljude serverikomponentide (RAID-massiivid, võrguadapterid) võimalused. Kui kasutada krüpteerimiseks riistvaralist krüptimist või riistvaravõtme tuletamist, tekib täiendav võimalik jõudluse kitsaskoht: andmeedastuskiirus sekundaarse seadme ja mälu vahel (ja sellise seadme jõudlus ei pruugi mängida määravat rolli). Väikeste andmemahtude (näiteks meilisõnumi) krüptimise kasutamisel ei ole süsteemi arvutuskoormuse suurenemine nii märgatav, kuid kõige ja kõige täieliku krüptimise korral võib see oluliselt mõjutada süsteemi jõudlust. süsteem tervikuna.

Paroolide ja võtmete valiku kaasaegsete võimaluste alahindamine.

Hetkel on tehnika võimalused sellised, et väike organisatsioon saab valida 40-48 bitise võtme, suur organisatsioon aga 56-64 bitise võtme. Need. Kasutada tuleb algoritme, mis kasutavad vähemalt 96- või 128-bitist võtit. Kuid enamik võtmeid genereeritakse kasutaja sisestatud paroolide põhjal räsialgoritmide (SHA-1 jne) abil. Sel juhul ei pruugi ka 1024-bitine võti salvestada. Esiteks kasutatakse sageli kergesti äraarvatatavat parooli. Valikut hõlbustavad tegurid on: ainult ühe tähtede kasutamine; sõnade, nimede ja väljendite kasutamine paroolides; teadaolevate kuupäevade, sünnipäevade jms kasutamine; "mustrite" kasutamine paroolide genereerimisel (näiteks 3 tähte, siis 2 numbrit, siis 3 tähte kogu organisatsiooni ulatuses). Hea parool peaks olema üsna juhuslik jada nii suurtähtedest, numbritest kui ka kirjavahemärkidest. Klaviatuurilt sisestatud kuni 7-8 tähemärgi pikkused paroolid, isegi kui neid reegleid järgitakse, on mõistliku aja jooksul ära arvatavad, seega on parem, kui parool on vähemalt 11-13 tähemärgi pikkune. Ideaalne lahendus on keelduda võtme genereerimisest parooliga, näiteks kasutades erinevaid kiipkaarte vms, kuid sel juhul tuleb ette näha võimalus kaitsta end krüpteerimisvõtme kandja kaotsimineku eest.

Võtmete ja paroolide ebaturvaline salvestus.

Selle vea tüüpilised näited on:

pikad ja keerulised paroolid, mis on kirjutatud kasutaja monitorile kleebitud kleebistele.
kõigi paroolide salvestamine faili, mis pole kaitstud (või kaitstud palju nõrgemini kui süsteem ise)
elektrooniliste võtmete üldkasutatav säilitamine.
sagedane elektrooniliste võtmete ülekandmine kasutajate vahel.

Milleks teha soomusust, kui selle võti lebab ukse juures vaiba all?

Algselt krüptitud andmete edastamine ebaturvalisse keskkonda.

Turvasüsteemi korraldades veenduge, et see täidaks oma eesmärki. Näiteks puutusin kokku olukorraga (pole 1C-ga seotud), kui algselt krüpteeritud fail, kui programm töötas avatud kujul, pandi ajutisse kausta, kust seda sai turvaliselt lugeda. Üsna sageli asuvad krüpteeritud andmete varukoopiad selgetekstis kusagil nende andmete "lähedal".

Krüptograafiliste tööriistade kuritarvitamine

Kui edastatavad andmed on krüpteeritud, ei saa eeldada, et andmed pole nende kasutuskohtades kättesaadavad. Näiteks ei takista IPSec-teenused kuidagi võimalust võrguliiklust "kuulata" rakendusserveri poolel olevas rakenduskihis.

Seega, et vältida vigu krüptosüsteemide juurutamisel, tuleks enne selle juurutamist (vähemalt) teha järgmist.

Uurige:
- Mida on vaja kaitsta?
- Millist kaitsemeetodit tuleks kasutada?
- Millised süsteemi osad vajavad turvalisust?
- Kes haldab juurdepääsu?
- Kas krüptimine töötab kõigis õigetes piirkondades?
Otsustage, kus teavet salvestatakse, kuidas seda võrgu kaudu saadetakse ja millistest arvutitest teabele juurde pääseb. See annab enne süsteemi juurutamist teavet kiiruse, võimsuse ja võrgukasutuse kohta, mis on kasulik jõudluse optimeerimiseks.
Hinnake süsteemi haavatavust erinevat tüüpi rünnakute suhtes.
Töötada välja ja dokumenteerida süsteemi turvaplaan.
Hinda süsteemi kasutamise majanduslikku efektiivsust (põhjendust).

Järeldus

Loomulikult on pealiskaudsel ülevaatel võimatu näidata kõiki 1C turvalisusega seotud aspekte, kuid tehkem mõned esialgsed järeldused. Loomulikult ei saa seda platvormi nimetada ideaalseks - sellel, nagu paljudel teistelgi, on turvalise süsteemi korraldamisel omad probleemid. Kuid see ei tähenda mingil juhul, et nendest probleemidest ei saaks mööda minna, vaid vastupidi, süsteemi õige arendamise, rakendamise ja kasutamisega saab peaaegu kõik puudused kõrvaldada. Enamik probleeme tekib konkreetse rakenduslahenduse ja selle täitmiskeskkonna ebapiisava arendamise tõttu. Näiteks tüüpilised lahendused ilma olulisi muudatusi tegemata ei tähenda lihtsalt piisavalt turvalise süsteemi loomist.

Ettevõte on ainulaadne teenus ostjatele, arendajatele, edasimüüjatele ja siduspartneritele. Lisaks on see üks parimaid veebipõhiseid tarkvarapoode Venemaal, Ukrainas, Kasahstanis, mis pakub klientidele laia valikut tooteid, palju makseviise, kiiret (sageli kohest) tellimuste töötlemist, tellimuse täitmise protsessi jälgimist isiklikus osas.

Kataloog "Kasutajad" on loodud kasutajate loendi salvestamiseks. Põhimõtteliselt on need kasutajad, kes töötavad konfiguratsiooniga (IB kasutajad).

IS-i kasutaja tuvastamine kataloogi kasutajaga toimub IS-i kasutajanime ja kataloogi kasutajanime sobitamise teel.

Lisainfot redigeeritakse alammenüü „Lisainfo“ kaudu.

Lisateavet leiate ainult tavalisest rakendusest.

Kasutaja seaded – võimaldab muuta kasutaja seadeid

Kontaktteave - võimaldab muuta kontaktteavet, mida kasutatakse, kui kasutaja töötab klientidega ja töötab sisseehitatud e-postiga

Kasutajagrupid – võimaldab muuta gruppe, kuhu kasutaja kuulub

Lisaõigused – võimaldab muuta täiendavaid kasutajaõigusi

Ainult kasutaja administraator saab kasutajaid luua, muuta ja kustutada.

IB kasutajate loomine

Saate luua IB kasutajaid konfiguraatori režiimis või ettevõtte režiimis.

IS-i kasutaja atribuutide haldamine ettevõtte režiimis on eelistatavam kui otsene kasutajahaldus konfiguraatori kaudu.

Kasutajate volitused määratakse nende rollide ja lisaõigustega.

Lubasid saab määrata profiilide abil.

Kirjetaseme juurdepääsuõigused määravad kasutajarühmad, kuhu kasutaja kuulub.

2009

Jaotis "Haridussüsteemi erinevatel tasanditel juhtimis- ja finants- ja majandusmehhanismide kaasajastamine "1C" tehnoloogiate abil"

"25. Infoturbe tagamise meetodid ja vahendid süsteemis 1C:Enterprise 8.1" (Khorev P.B., Venemaa Riiklik Sotsiaalülikool (RGSU), Moskva)

Esitlus

Infotehnoloogiate ja -süsteemide pidev areng toob kahjuks kaasa vana süvenemise ja uute probleemide esilekerkimise. Üks neist probleemidest on teabe kaitse probleem - selle ohutuse ja väljakujunenud kasutusseisundi usaldusväärne säilitamine. Seetõttu on info ja infoprotsesside turvalisuse tagamine tänapäevaste infosüsteemide kohustuslik funktsioon.

Peamised kaitsemeetodid infosüsteemi objektidele volitamata juurdepääsu eest on

infosüsteemide ja nende poolt aktiveeritud protsesside kasutajate tuvastamine ja autentimine;
subjektide autoriseerimine (subjekti juurdepääsuõiguste määramine konfidentsiaalse teabega objektile);
infosüsteemi turvalisusega seotud sündmuste audit.

Selles aruandes käsitletakse 1C:Enterprise 8.1 süsteemis saadaolevaid teabeturbe tagamise meetodeid ja vahendeid.

1C:Enterprise 8.1 andmebaasiadministraator saab luua ja seejärel muuta nende kasutajate loendit, kellel on lubatud süsteemiga töötada. Uue kasutaja lisamisel (esialgu on kasutajate loend tühi) näidatakse loodud konto järgmisi atribuute (vahekaardil "Põhiline"):

nimi, mille all kasutaja süsteemi registreeritakse;
täisnimi (soovitav on kasutada seda atribuuti selle organisatsiooni töötaja perekonnanime, eesnime ja isanime, ametikoha ja osakonna nime määramiseks, kus süsteemi kasutatakse);
Autentimislipp "1C:Enterprise" (kui see "märkeruut" on valitud, siis kui kasutaja proovib süsteemi "1C:Enterprise" sisse logida, teostab tema tuvastamise ja autentimise süsteem ise);
kasutaja parool, mille sisestamist on vaja tema tuvastamiseks süsteemi 1C:Enterprise abil:
kasutaja parooli kinnitamine (vajalik, et välistada parooli sisestamisel tõrke võimalus, kuna parooli märgid asendatakse sisestamisel * tähemärkidega);
märk, et kasutajal on keelatud 1C:Enterprise tööriistade abil autentimise ajal parooli muuta;
lipp kasutajanime kuvamiseks loendis, kui proovite sisse logida ja autentida 1C:Enterprise tööriistade abil;
Windowsi autentimise lipp (kui see märkeruut on sisse lülitatud, määratakse kasutaja 1C:Enterprise'i sisselogimisel nimi, mille all Microsoft Windowsi operatsioonisüsteemiga seanss töötab, ja 1CEnterprise'i süsteemi kasutajate loendis , otsitakse nime, mis vastab nimele "praegune" Windowsi kasutaja);
Windowsi operatsioonisüsteemi kasutajanimi, millega see 1C:Enterprise kasutaja on seotud Windowsi operatsioonisüsteemiga autentimise kasutamisel (nime saab määrata vormingus \\domeeninimi\kasutajakonto nimi või valida vastava nupu abil selles arvutis teadaolevate kohalike ja globaalsete kontode loend).

Andmebaasi administraator saab infobaasi sätete abil määrata süsteemi kasutajate paroolide minimaalse pikkuse (kui ruut "Kontrolli kasutaja paroolide keerukust" on märgitud, siis ei tohi paroolide minimaalne pikkus olla alla 7 tähemärgi) ja nõuda, et kasutajate paroolid vastaksid keerukuse tingimused, mis vastavad Windowsi kasutajate paroolide keerukuse nõuetele (lisaks ei tohi parool olla märgijada).

Kõige turvalisem viis kasutajate autentimiseks rakendusse 1C:Enterprise sisse logides on ühendada autentimine 1C:Enterprise'i ja Windowsi tööriistade abil. Sel juhul on soovitatav autentimisatribuutide rühmas "1C:Enterprise" eemaldada märkeruut "Kuva valikuloendis" ning Windowsi turvaseadetes lubada paroolide minimaalse pikkuse ja keerukuse nõuded, nende piirangud. maksimaalne kehtivusaeg, paroolide mittekordavus ja nende minimaalne kehtivusaeg ning määrake Windowsile ebaõnnestunud sisselogimiskatsete loenduri läviväärtus.

Kasutaja autentimise dialoogi sundimiseks kuvamiseks 1C:Enterprise tööriistade abil (kui Windowsi autentimise märkeruut on lubatud), kasutage 1C:Enterprise'i käivitamisel käsurea parameetrit /WA+.

Pidage meeles, et 1C:Enterprise süsteemi kasutajate loend ei ole selle konfiguratsiooni osa, vaid see luuakse iga organisatsiooni jaoks, kuhu see süsteem on installitud, eraldi.

Roll 1C: Enterprise'is on juurdepääsuõiguste kogum erinevatele andmebaasiobjektidele. Tavaliselt luuakse rollid individuaalsete tööülesannete jaoks ja igale süsteemi kasutajale saab määrata ühe või mitu rolli. Kui kasutajale on määratud mitu rolli, siis andmebaasiobjektile juurdepääsu võimaldamine toimub järgmiselt:

Kui vähemalt ühes kasutajale määratud rollis on taotletud juurdepääs lubatud, antakse see kasutajale.
Kui kõik kasutajale määratud rollid ei võimalda vastavat juurdepääsu, siis taotletud juurdepääsu ei anta.

Rolle luuakse ja redigeeritakse 1C:Enterprise süsteemikonfiguraatori abil. Konfiguratsiooni loomise käigus luuakse tüüpiliste rollide komplekt, mida saab seejärel redigeerida.

Rolli loomisel või redigeerimisel kasutatakse kahe vahekaardiga akent - "Õigused" ja "Piiramise mallid". Vahekaart "Õigused" sisaldab kõigi alamsüsteemide konfiguratsiooniobjektide hierarhilist struktuuri ja valitud objektile kehtivate juurdepääsuõiguste loendit (õiguse lubamiseks peate määrama vastava "märkekasti").

Teenuses 1C:Enterprise on kahte tüüpi õigusi - põhi- ja interaktiivsed. Põhiõigusi kontrollitakse infosüsteemi objektidele juurdepääsuks. Interaktiivseid õigusi kontrollitakse interaktiivsete toimingute tegemisel (näiteks andmete vaatamine ja muutmine vormil).

Süsteem 1C:Enterprise võimaldab juurdepääsuõigusi kontrollida sisseehitatud keele abil. Näiteks vormile uute käskude lisamisel peab arendaja lisaks kontrollima, kas kasutajal on vastavad interaktiivsed õigused.

Rolli redigeerimisel tuleb arvestada õiguste pärandusega (hierarhiaga): kui tühistatakse "vanema" ("vanema" õigus), tühistatakse ka selle "lapse" ("alaealise") õigused ja millal seatakse “lapse” õigus, kehtestatakse ka tema “vanema” õigus. Näiteks kui tühistatakse „View“ õigus, siis tühistatakse ka vastava objekti „Muuda“ õigus.

Märkeruudu "Määra õigused uutele objektidele" abil saate tagada, et redigeeritud roll määrab automaatselt juurdepääsuõigused uutele (hiljem lisatud) konfiguratsiooniobjektidele.

Juurkonfiguratsiooniobjektile saab määrata järgmised juurdepääsuõigused:

haldusfunktsioonid (hõlmab konfiguratsiooni avamist, kasutajate loendi avamist, logi seadistamist, konfiguratsiooni värskendamist ja muid haldustoiminguid);
andmebaasi konfiguratsiooni värskendus;
monopolirežiim;
aktiivsed kasutajad (nende nimekirja avamine);
registreerimispäevik (selle logi avamine);
välisühendus (töö süsteemiga COM-liidese kaudu);
automatiseerimine (töötamine süsteemiga automatiseerimisserverina);
välise töötlemise interaktiivne avamine;
välisaruannete interaktiivne avamine;
väljundi printimine, salvestamine, lõikepuhvri kasutamine süsteemiga töötamisel).

Haldamise hõlbustamiseks pakub 1C:Enterprise akent kõigi selles konfiguratsioonis loodud rollide vaatamiseks ja redigeerimiseks. Kui mõne rolli puhul on vaja valitud objektile kõik juurdepääsuõigused tühistada või määrata, siis saab redigeeritava rolli nimega veeru juures kasutada märkeruutu "Kõik õigused" real. Kui kõigis rollides on vaja teatud juurdepääsuõigust määrata või tühistada, siis saab veeru Kõik rollid vastava õiguse nimetusega märkeruutu kasutada.

Andmebaasiobjektidele juurdepääsu piiramiseks üksikute väljade ja kirjete tasemel pakub 1C:Enterprise mehhanismi andmetele juurdepääsu piiramiseks (kasutades nende objektide lugemise, lisamise, muutmise ja kustutamise õigusi). Lugemisõigusele on võimalik seada mitu juurdepääsupiirangut ja teistele määratud õigustele ainult üks piirang.

Iga lugemisõigusega andmetele juurdepääsupiirangu jaoks on võimalik valida väli, mille väärtuse järgi juurdepääsupiirangu tingimust kontrollitakse, või märge “Muud väljad”, mis tagab tingimuse kontrollimise iga välja puhul.

Andmejuurdepääsupiirangu tingimuse saab määratleda konstruktori abil või käsitsi, luues ja redigeerides rollide redigeerimise akna vahekaardil Piirangumallid nimelisi juurdepääsupiirangu malle.

Kasutaja töö hõlbustamiseks ja nende õiguste edasiseks piiramiseks pakub 1C:Enterprise liidesemehhanismi. Nende objektide abil luuakse peamenüü ja tööriistariba elementide käskude komplektid, millega kasutaja saab töötada. Liidese põhimenüü koostajat kasutades loob administraator iga alammenüü jaoks alammenüüde loendi ja käskude loendi.

Pärast peamenüü struktuuri määratlemist saab loodud liidesele lisada ühe või mitu tööriistariba. Need paneelid võivad asuda programmi 1C: Enterprise akna ülaosas, all, vasakul ja paremal.

Arvesta, et peale rollide ja liideste loomist on vaja uuendada andmebaasi konfiguratsiooni, et uutele infosüsteemi kasutajatele saaks määrata loodud rollid ja liidesed.

Sündmused, mis tuleks 1C:Enterprise'i süsteemilogis registreerida, saab administraator määrata oma seadete funktsiooni abil. Siin saate valida ka ajaperioodi, mille möödudes logi uude faili salvestatakse, samuti vähendada logikirjeid enne määratud perioodi möödumist, kustutades need ja võimalusel salvestades faili.

Kirjandus

Radchenko M.G. "1C: Ettevõte 8.1. Praktiline arendaja juhend. Näited ja tüüpilised tehnikad. M.: 1C-Publishing LLC, Peterburi: Peter, 2007.
1C: Ettevõte 8.1. Seadistamine ja administreerimine. M.: Firma "1C", 2007.

TEABEBAASI (IB) HALDUS

Selle artikli sundis mind kirjutama 3 asjaolu: suhtlus tuttavate raamatupidajatega, pearaamatupidaja artikkel, naljakogumik.

Mu sõber töötab pearaamatupidajana ja valdab vabalt 1C. Kuid hiljuti kolis ta uude organisatsiooni, kus puudub infotehnoloogia (IT) spetsialist, ja hakkas mulle esitama selliseid küsimusi nagu "Ma tahan programmiga kodus töötada, kuidas saan selle oma koduarvutisse üle kanda?".

Kutseliste raamatupidajatega suheldes sain aru, et tööalaselt neil küsimusi ei ole. Küsimused tekivad infobaasi haldamise vallas.

Teiseks meenub hiljuti ilmunud artikkel “Milleks on raamatupidajal vaja Infostarti?” . Autor Alla (bux 2).

Kolmas asjaolu on kaugeltki uute naljade kogumik “Juhised raamatupidajatele 1s programmeerijaga suhtlemiseks”. Tegelikult ei saa neid lugusid naljaks nimetada, need on tõestisündinud lood igast raamatupidamisega seotud IT-spetsialistist.

Neid anekdoote hoolikalt analüüsides jõuate tahes-tahtmata järeldusele, et konflikt tekib vastutusala piirimail, mis pole määratud ei rakenduse kasutajale ega IT-spetsialistile.

Nüüd on Infostarti veebisaidil registreeritud üle 80 000 kasutaja. On ebatõenäoline, et need kõik on 1C programmeerijad, tõenäoliselt on tegemist edasijõudnud kasutajatega, kellel on probleeme 1C-süsteemidega.

Mulle tundub, et kõik saidi kasutajad võib jagada kolme põhikategooriasse:

1C programmeerijad, kes osalevad nartsissistlikult edetabelikonkurentsis
"Täpsemad" kasutajad, kes otsivad 1C-ga töötamiseks täpsemaid tööriistu
Algajad, kellel on 1C töös probleeme ja kes otsivad vastuseid küsimusele "Mida teha?"

See artikkel on mõeldud kahele viimasele kasutajakategooriale. Siinkohal tahaksin arutleda 1C teabebaaside haldamise üle. Arutelu on vastuoluline ja põhineb ainult minu enda kogemusel.

Kui analüüsida enim hinnatud artikleid, siis näeme, et üsna lihtsad artiklid infoturbehalduse üldistest küsimustest on edukad. Need küsimused on IT-spetsialistidele selged, kuid 1C rakenduste kasutajate jaoks on need peaaegu ilmutus.

See kehtib eriti väikeste ettevõtete kohta, kes ei saa endale lubada 1C programmeerijat või isegi lihtsalt IT-spetsialisti. Sel juhul langevad kõik probleemid kasutajatele.

Kõige sagedamini kasutab selline ettevõte konfiguratsioone "raamatupidamine" ja "palk". Selle põhjuseks on asjaolu, et 1C kajastab oma konfiguratsioonides viivitamatult muudatusi õigusaktides. Ettevõtete jaoks on see fiskaalaruandluse seisukohalt oluline.

Tüüpiline väikeettevõte. 1C kasutajad: direktor; raamatupidaja, ta on pealik; sekretär, ta on OK juht; mitu juhti (millegipärast nimetatakse nii müügispetsialiste).

Iga kasutaja "hoiab" oma osa infoturbest ja keegi ei vastuta kogu andmebaasi kui terviku eest. Ja kui probleemid tekivad, pole kelleltki küsida. Nagu Raikin “Õmblesin ise nööbid külge. Kas teil on nuppude kohta küsimusi? Ei, surnuks õmmeldud, te ei saa seda lahti rebida! Ja üldiselt ei vastuta ülikonna eest keegi.

Süsteemi normaalseks tööks peab keegi üle võtma üldise infoturbe kontrolli funktsioonid. Sellised funktsioonid hõlmavad näiteks duplikaatide eemaldamist kataloogidest. Ühest küljest on see rakendusvaldkond, teisalt peaks seda tegema IT-spetsialist. Need funktsioonid asuvad piirialal, nii IT-spetsialistid (kui neid on) kui ka 1C kasutajad keelduvad nende rakendamisest.

See küsimus ei puuduta ainult väikeettevõtteid. Hiljuti tegelesin ametijuhendite uuendamisega ja suutsin selliseid funktsioone väga vaevaliselt töötajate vahel ära jagada. Ja nüüd on lähenemine ametijuhenditele väga tõsine, sest. need on aluseks erinevatele halduskaristustele kuni vallandamiseni (kaasa arvatud).

Süsteemiadministraator lükkas ettepaneku vihaselt tagasi, 1C programmeerija teatas uhkelt, et ta "kodeerib" ja ei riisu kasutajate jaoks prügi kokku. Ühesõnaga, tüüpilises ettevõttes puudub spetsialist, kes vastutaks infoturbe info terviklikkuse eest. Seda positsiooni on raske määratleda, tinglikult võib seda nimetada "IB-juhiks".

Need funktsioonid erinevad administraatori funktsioonidest. Ettevõte 1C annab järgmise haldusülesannete määratluse:

Süsteemi installimine ja värskendamine
Kasutajate nimekirja pidamine
Juurdepääsuõiguste konfigureerimine rollimehhanismi alusel
Kasutajate tegevuste ja süsteemisündmuste jälgimine
Varundamine
Infobaasi testimine ja parandamine
Piirkondlike eelistuste määramine
Konfiguratsioonide värskendamine
Infoandmebaasi faili laadimine ja mahalaadimine
Logi hooldamine ja püstitamine

Tegelikult on sellele pühendatud peatükk "Haldus" dokumentatsioonis 1C "Konfigureerimine ja administreerimine".

Tegelikkuses ei piisa nendest haldusülesannetest andmebaasi tõrgeteta töötamiseks. Andmebaasi "õigeks" toimimiseks on vaja laiemaid ja mitmekülgsemaid tegevusi. "Andmebaasihaldus" on palju laiem kui "halduse" mõiste.

Suurtes ettevõtetes tuleks need infoturbe haldamise funktsioonid määrata täiskohaga spetsialistile. Väikeettevõtetes langevad need funktsioonid tõenäoliselt pearaamatupidajale, sest. talle kuulub rohkem infot, ta peab kontrollima dokumentide sisestamist ja järjestust, andmeid üles ja alla laadida jne.

Üldjuhul taandatakse IS-i haldusfunktsioonid selle tagamisele, et IS on “korrektne”. Andmebaasi “õigsuse” probleemid on alati olemas olnud.

Minu arvates peab "õige" 1C teabeandmebaas mis tahes konfiguratsioonis vastama vähemalt järgmistele põhimõtetele:

See ei tohiks sisaldada kustutamiseks märgitud objekte. Kõik märgitud objektid tuleb kustutada
Andmebaasis ei tohiks olla postitamata dokumente
Mis tahes perioodi dokumentide uuesti postitamisel ei tohiks tulemused muutuda

Andmebaasi haldamine ja peaks nende tulemusteni viima. Andmebaasiga katkematuks tööks on standardsetes 1C konfiguratsioonides (näiteks ZUP) vaja teha järgmised toimingud:

1. Varundamine
  - Kõigist andmebaasidest tuleb koopiad teha iga päev, iga päeva lõpus. Sel juhul saate eelmise päeva koopiad "üle kirjutada";
  - Enne täiendamist on vaja andmebaasi koopiat. Soovitatav on need koopiad salvestada kordumatute nimede all.
  - Andmebaasi koopiad on kohustuslik salvestada peale kuu lõppu, ka unikaalsete nimede all.

Saidil on palju varundamisele pühendatud artikleid ja käsitlusi.

1. Kontrollige kord nädalas teatmeteostest duplikaate. Kui on duplikaate, kustutage need. Kuidas duplikaate eemaldada
2. Kustutage iganädalaselt kustutamiseks märgitud üksused. Kui objekte ei kustutata, on nendele objektidele viited. Tuleb välja selgitada, kes ja miks need kustutamiseks märkis. Vajadusel tuleb need objektid taastada. Eemaldamist saab teha universaalsete ravimeetodite abil//site/blogs/1313/ Enne regulatiivset aruandlust – Tehnoloogiline kontroll
3. Ekspressandmebaasi analüüs//site/public/21332/
4. Kuu lõpus pärast kuu lõppu keelake juurdepääs andmetele

Kas oskate midagi oma kogemusest soovitada?