14.04.2016 Տարբերակ 3.22 Ինտերֆեյսը փոխվել է, ռեգիստրների փոխանցման ժամանակ սխալները շտկվել են, կազմակերպության փոխանցման կարգը և հաշվապահական հաշվառման քաղաքականությունը փոխվել են: Հարթակ 8.3.7.2027 BP 3.0.43.174
17.03.2016 Տարբերակ 3.24 Նկատված սխալները ուղղվել են: Հարթակ 8.3.8.1747 BP 3.0.43.241
16.06.2016 Տարբերակ 3.26 Նկատված սխալները ուղղվել են: Հարթակ 8.3.8.2088 BP 3.0.44.123
16.10.2016 Տարբերակ 4.0.1.2 Արժեքի պահպանման ֆիքսված փոխանցում, թողարկումների հաշվապահական հաշվառման քաղաքականության փոփոխված փոխանցում 3.44.*: Հարթակ 8.3.9.1818 BP 3.0.44.164.
19.04.2017 Տարբերակ 4.0.2.7 Փոխվել է գրացուցակների հետ կապված ռեգիստրների փոխանցման ալգորիթմը, ուղղվել են նկատված սխալները, շտկվել է հղումների վերագրմամբ փոխանցումը։
29.05.2017 Տարբերակ 4.0.4.5 Փոխվել է շարժումների փոխանցումը, ավելացվել է փոխանցված փաստաթղթերի տեղաշարժերի դիտում, այլ բան...
05/30/2017 Տարբերակ 4.0.4.6 Ուղղվել է աղբյուրի առկա դիրեկտորիաների ցանկը լրացնելիս սխալ (շնորհակալություն շոյ)
17.06.2017 Տարբերակ 4.0.5.1 Շարժումների փոխանցման ալգորիթմը փոխվել է։
19.07.2017 Տարբերակ 4.0.5.4 CI-ի փոխանցումը BP 2.0-ից փոխվել է: Անսպասելիորեն, UT 10.3-ից փոխանցումը իրականացվել է Smilegm-ի կողմից, այս տարբերակում փոխանցումը մի փոքր շտկվել է այս իրավիճակի համար)))
08/10/2017 Տարբերակ 4.0.5.5 Ուղղված սխալներ BP 2.0-ից փոխանցելիս
19.09.2017 Տարբերակ 4.4.5.7 Ֆիքսված կապի ստուգում 3.0.52-ի համար*
11/28/2017 Տարբերակ 4.4.5.9 Ուղղվել է հաղորդված սխալները
12/06/2017 Տարբերակ 5.2.0.4 Հղումների որոնման ալգորիթմը վերանախագծվել է: Ավելացվել են BP 1.6-ից փոխանցման ընթացակարգերը, այլևս չկա խիստ կապ BP-ի հետ. դուք կարող եք հեշտությամբ օգտագործել այն «գրեթե» նույնական կոնֆիգուրացիաների տվյալները փոխանցելու համար: Ես կփորձեմ արագ ուղղել բոլոր մեկնաբանությունները:
12/08/2017 Տարբերակ 5.2.1.3 Ավելացվել է աշխատավարձի հաշվետվությունները BP.2.0-ից BP 3.0-ին փոխանցելու ալգորիթմ: Ներառված փոփոխություններ՝ նույնական կոնֆիգուրացիաների միջև համօգտագործման համար:
19.12.2017 Տարբերակ 5.2.2.2 Անկախ տեղեկատվական ռեգիստրների փոխանցումը դիրեկտորիաների համար, որոնք գտնվում են այս ռեգիստրների չափսերում:
12/06/2017 Նոր վերամշակման տարբերակ 5.2.0.4. Նշանակալից փոփոխությունների թվում է BP 1.6-ից BP 3.0 տեղափոխելու հնարավորությունը։ Հիմնական փոփոխությունը գրացուցակի հղումների որոնման կառավարումն է. նախորդ տարբերակներում որոնումը կատարվել է GUID-ի միջոցով, սակայն այս տարբերակում կարող եք միացնել «Ըստ մանրամասների» որոնումը.
17.01.2018 Տարբերակ 5.2.2.3 Ամրագրվել է - նկատվել են սխալներ ենթակա գրացուցակներում և պարբերական տեղեկատվական ռեգիստրներում:
19.07.2018 Տարբերակ 5.2.2.8 Նկատված սխալները ուղղվել են:
որտեղ դուք կարող եք սահմանել որոնման մանրամասներ ցանկացած գրացուցակի համար: Այս ռեժիմն ինքնին «առաջացել է» աշխատողների բազմաթիվ խնդրանքներով, այն դեպքերի համար, երբ անհրաժեշտ է փոխանակում արդեն գոյություն ունեցող տվյալների բազայի մեջ, որն արդեն ունի տվյալներ (օրինակ, երկու կազմակերպությունների հաշվապահական հաշվառումները միացնելու համար մեկ տվյալների բազայում):
12/21/2015 Պլատֆորմ 8.3.7.1805 և BP 3.0.43.29 թողարկվել են համապատասխանաբար նոր տարբերակմշակում 3.1:-) (նկարագրությունը ստորև): Նոր ֆունկցիոնալություն - BP-ի երկու տվյալների շտեմարանների միջև մնացորդները և շրջանառությունը համեմատելու հնարավորություն (բոլոր հաշիվների համար, եթե հաշիվների գծապատկերները համընկնում են, կամ անհատական համապատասխան հաշվապահական հաշիվների համար, վերլուծություններով կամ առանց):
01/03/2016 Տարբերակ 3.5 - աղբյուրի բազայի հետ միանալու մեխանիզմը փոխվել է - համապատասխանեցվել BSP 2.3.2.43-ին: Աննշան վրիպակներ ուղղվեցին: Հարթակ 8.3.7.1845, BP 3.0.43.50
02/16/2016 Տարբերակ 3.6 - Ավելացվել է «Սահմանել ձեռքով ուղղում» դրոշը շարժումներով փոխանցված փաստաթղթերի համար: Շարժումների ֆիքսված փոխանցում - ժամանակաշրջանի սկզբից փոքր ամսաթիվ ունեցող փաստաթղթերը փոխանցվում են առանց տեղաշարժերի: Հարթակ 8.3.7.1917, BP 3.0.43.116
03/22/2016 Տարբերակ 3.10 - Ավելացվեց «Միշտ վերագրիր հղումները» դրոշը հղումով օբյեկտների պարտադիր վերագրման համար (փոխանցման արագությունը զգալիորեն կրճատվում է, բայց երբեմն դա անհրաժեշտ է): Ավելացվել է «Պատրաստում» ներդիրը, որտեղ կարող եք կարգավորել հաշվային հաշվառման սկզբնաղբյուրի և նպատակակետի գծապատկերների համապատասխանությունը (հաշվի կոդերի նույն մակարդակի վրա) և հաստատունների փոխանցումը։ Հարթակ 8.3.7.1970, BP 3.0.43.148
04/03/2016 Տարբերակ 3.11 Աղբյուրում առկա փաստաթղթերի ցանկի լրացումը փոխվել է. այն լրացվել է ըստ հաշվային պլանի տեղաշարժերի, կատարվել է պարզապես ժամանակաշրջանի հղումներով, ինչպես // site/public/509628/
Մշակումը նախատեսված է ցանկացած ժամանակաշրջանի տվյալների փոխանցման համար, ինչպես «MXL վերբեռնումը» ITS-ով, միայն առանց XML, JSON և այլ միջանկյալ ֆայլերի օգտագործման՝ տվյալների բազայից տվյալների բազա COM-ի միջոցով փոխանակում: 3.10-ից ավելի հին տարբերակներում կապն օգտագործվում է BSP-ի ալգորիթմի միջոցով, որը նախատեսում է comcntr.dll-ի գրանցում (եթե ՕՀ-ն «թույլ է տալիս»), ինչպես նաև տարբեր հաղորդագրություններ, երբ անհնար է կապ հաստատել, օրինակ - «Տեղեկատվական բազան թարմացման փուլում է» և այլն: Ստացողը որպես IS աղբյուր ընտրելու համար ավելացվել է ստուգում. տրվում է նախազգուշացում:
Կարող է օգտագործվել՝
1. Կարգավորող տեղեկատու տեղեկատվության (RNI) փոխանցում IS աղբյուրից դեպի IS նպատակակետ (բոլոր տեղեկատու տեղեկատվության փոխանցումը կատարվում է օգտագործողի խնդրանքով, անհրաժեշտ տեղեկատու գրքերը և այլն փոխանցվում են հղումների միջոցով ցանկացած փոխանցման ժամանակ):
2. Փաստաթղթերի փոխանցում ցանկացած ընտրված ժամանակահատվածի համար:
3. Ամբողջ տեղեկատվության փոխանցումը «կոտրված» տեղեկատվական անվտանգության համակարգից, եթե այն գործարկվում է 1C:Enterprise ռեժիմով, և տվյալների վերբեռնումը կամ Կոնֆիգուրատորի գործարկումն անհնար է:
Մշակման առանձնահատկությունը - ստացողի և աղբյուրի տեղեկատվական անվտանգությունը կարող է տարբեր լինել, տեղափոխել 2.0-ից 3.0 - հրատարակությունները տարբեր են, բայց փոխանցումը գործում է!!! Անհամապատասխան մանրամասները անտեսվում են, կամ դրանց համար պետք է նշվեն փոխանցման ալգորիթմներ:
Մեկնաբանություն: Տվյալների փոխարկումը ՉԻ ՕԳՏԱԳՈՐԾՎՈՒՄ: Եվ մի հարցրեք, թե ինչու !!! Նրանց համար, ովքեր հատկապես բծախնդիր են - BP 3.0-ը փոխվում է գրեթե ամեն օր, այլևս ուժ չկա փոխանցման կանոնները թարմացնելու համար. այստեղ ամեն ինչ ավելի պարզ է :-):
Մշակման մեկ այլ առանձնահատկությունն այն է, որ այն գործարկվում է ստացողի տեղեկատվական անվտանգության մեջ (ֆունկցիոնալությամբ ամենամոտ անալոգները հակառակն են աշխատում՝ աղբյուրից մինչև ստացող):
Սկսում ենք - դուք պետք է նշեք մշակման ժամանակահատվածը, նշեք կազմակերպության աղբյուրը, այն կտեղափոխվի նպատակակետ:
Կազմակերպություն փոխանցելիս փոխանցվում են հաշվապահական հաշվառման քաղաքականությունը և «կապված» տեղեկատվական ռեգիստրները: Հետևաբար, երբ սկզբնաղբյուրում կազմակերպություն եք ընտրում, որոշ ժամանակ կանցնի, մինչև այն կհայտնվի ընդունիչում:
Աղբյուրի և նպատակակետի հաշվային գծապատկերները պետք է լինեն նույնը, 2.* տարբերակներում տարբեր հաշիվներ չեն փոխանցվում նպատակակետին, նախատեսվում է հետագայում հնարավորություն տալ համապատասխանող հաշիվների և վերլուծությունների ճշգրտումը: Հաշիվները փոխանցվում են ստացողի մեջ չգտնվող կոդերի միջոցով ՉԻ ՍՏԵՂԾՎԵԼ!!!
Մնացած օբյեկտները փոխանցվում են ներքին նույնացուցիչների (GUID) միջոցով, այնպես որ դուք պետք է ուշադրություն դարձնեք որոշ հիմնական դիրեկտորիաների վրա, օրինակ՝ արժույթների:
Եթե նախատեսում եք փոխանակում կատարել «մաքուր» տվյալների բազայի հետ, ապա ավելի լավ է ջնջել այն գրացուցակները, որոնք լրացված են եղել առաջին գործարկման ժամանակ՝ նախքան փոխանակումը: Ինչու կա վերամշակման էջ, որտեղ դուք կարող եք ստանալ այս գրացուցակի տարրերը և ջնջել դրանք: Առնվազն, դուք պետք է հեռացնեք «ռուբլի» արժույթը: - որովհետեւ Կրկնօրինակումը գրեթե անխուսափելի է (սկզբունքորեն, դա հեշտությամբ շտկվում է BP 3.0-ում ներկառուցված կրկնօրինակների որոնումը և փոխարինումը տարածելուց հետո):
Մշակումը նախատեսում է կանչել գրացուցակի ջնջման էջը, երբ նախնական լրացման ձևը բաց է.
Երբ բացում եք մշակումը, կցուցադրվի սկզբնական լրացման ժամանակ լրացված դիրեկտորիաները ջնջելու էջ.
3.22 տարբերակից ի վեր ինտերֆեյսը փոխվել է, այժմ բոլոր նախապատրաստական գործողությունները ներդիր են և միշտ հասանելի են
Կարևոր է ստուգել աղբյուրի և ստացողի հաշվային պլանի համապատասխանությունը և անպայման նշել հաշիվների համապատասխանությունը:
Կարիք չկա ջնջել նախապես սահմանված գրացուցակի տարրերը. դրանք փոխանցվում են կազմաձևման նույնացուցիչներով (ոչ GUID-ներով):
Դուք կարող եք ընտրել փոխանցման օբյեկտներ՝ օգտագործելով ընտրության ձևը գրացուցակներից և փաստաթղթերից (այս օբյեկտների հետ կապված տեղեկատվական ռեգիստրները կփոխանցվեն ավտոմատ կերպով, ուստի կարիք չկա դրանք առանձին ընտրել):Գրանցամատյանների փոխանցումը, կրճատումը ժամանակավորապես անջատված է - պետք է մշակեք փոխանցման գրանցամատյանների ցուցակը, ինչ-որ բան պետք է փոխանցվի, ինչ-որ բան չպետք է, այս փուլում բավական է այն, ինչ փոխանցվում է գրացուցակներում, փոխանցման գրանցամատյանների ցանկը կլինի: ապագա տարբերակների ձևանմուշում:
2.0-ի հետ փոխանակելիս որոշ մանրամասներ (օրինակ. Կոնտակտային տվյալներ) փոխանցվում է մշակման մեջ ներկառուցված ալգորիթմի համաձայն, քանի որ 2.0-ի և 3.0-ի համար դրանք պահվում են տարբեր կերպ: Իրավիճակը նման է մի շարք փաստաթղթերի (օրինակ՝ Պարտքի ճշգրտում):
Օբյեկտների տեսակների ցանկը կարող է լրացվել տարբեր կերպ 3.22 տարբերակում, այն տեղադրված է ենթամենյուում, փոփոխությունները նշված են նկարում.
Գոյություն ունի մշակման օգտագործման պարզեցում. դուք չեք կարող ընտրել դիրեկտորիաներ փոխանակման համար, այլ պարզապես լրացնել ստացողի տեսակների ցանկը միայն այն տեսակի դիրեկտորիաներով, որոնք աղբյուրում առնվազն մեկ մուտք ունեն:
Մշակումն ունի ներկառուցված դասավորություն, որը թվարկում է դիրեկտորիաները, որոնք կարիք չունեն փոխանցվելու աղբյուրից դեպի նպատակակետ («Բացառել փոխանցումից» դասավորությունը): Դուք կարող եք ավելացնել (հեռացնել) ցանկացած դիրեկտորիա այս դասավորության մեջ: Եթե ձեզ հարկավոր չէ փոխանցել բոլոր տեղեկատու տվյալները, բավական է փոխանցել փաստաթղթերը, որոնց ցանկը կարելի է ստանալ նաև առանց տեսակների ընտրության, պարզապես լրացրեք բոլոր սկզբնաղբյուր փաստաթղթերը, որոնց համար կան գործարքներ:
Շարժումներով փաստաթղթերի փոխանցումը նախատեսված է, 3.0-ից 3.0 փոխանակումների և հաշվային գծապատկերների համապատասխանության դեպքում այն աշխատում է մեկ առ մեկ, 2.0-ից 3.0-ին փոխանակելիս հնարավոր են սխալներ, ուստի խորհուրդ է տրվում փաստաթղթերը փոխանցել առանց տեղաշարժի, այնուհետև պարզապես դրանք փոխանցեք ընդունիչին: Շարժումներով փաստաթղթեր փոխանցելիս դրված է «Ձեռքով կարգավորում» դրոշը:
«Փակցված» հատկանիշը սահմանվում է ստացողի փաստաթղթերում այնպես, ինչպես սկզբնաղբյուրում, բայց շարժումները (եթե դրանք չեն փոխանցվել) կհայտնվեն միայն փաստաթղթերը մշակելուց հետո, օրինակ՝ օգտագործելով BP 3.0 Խմբի տեղադրման մեջ ներկառուցված մշակումը: փաստաթղթեր (առաջարկվող տարբերակ) կամ այս մշակումից (այստեղ կա «Փաստաթղթեր փակցնել» կոճակը):
Եթե մշակումը նախատեսվում է օգտագործել մշտական փոխանակման համար, այն կարող է գրանցվել ստացողի տեղեկատվական անվտանգության մեջ («Գրանցվել» կոճակը): «Մեկանգամյա» փոխանցումների համար կարող եք պարզապես օգտագործել այն File - Open-ի միջոցով:
12/21/2015 - Տարբերակ 3.1 պլատֆորմ 8.3.7.1805 և սնուցման միավոր 3.0.43.29 (2.15 տարբերակը 3.0.43.*-ի համար չի աշխատում. կոնֆիգուրացիան բավականին շատ է փոխվել):
Փոխվել է՝
Կապի տարբերակ ընտրելու համար երկխոսություն, Հաճախորդ-սերվերի դրոշը միշտ հասանելի է, կախված դրա կարգավորումից, կա՛մ ֆայլի տվյալների բազայի թղթապանակի ընտրությունը, կա՛մ սերվերի վրա գտնվող տվյալների բազայի անվանումը և հենց սերվերի անունը հասանելի է (երկխոսության 2.15 տարբերակի սխալը շտկվել է)
- ՆՈՐ ՖՈՒՆԿՑԻՈՆԱԼՈՒԹՅՈՒՆ. Աղբյուրի և ստացողի տվյալների շտեմարանների միջև մնացորդների և շրջանառության համաձայնեցման մեխանիզմ՝ մանրամասնության տարբեր աստիճաններով.
Կարծում եմ, որ ստուգման տարբերակների ընտրությունը պարզ է նկարից.
Օգտագործման տարբերություններ կան բարակ և հաստ հաճախորդների մեջ. հաստ հաճախորդում անմիջապես ցուցադրվում է ֆայլերի համեմատման պատուհան.
Thin client-ում ես չէի անհանգստանում կոճակների ծրագրային սեղմումից, առաջարկում եմ համեմատական պատուհանի ցուցադրման պարզ տարբերակ.
Համեմատությունը նիհար հաճախորդի՝ IMHO-ում ավելի հարմար է, քանի որ... ունի նավարկության կոճակներ տարբերությունների համար, որն ավելի հարմար է մեծ սեղանների համար, քան մկնիկով ոլորելը.
03/22/2016 Տարբերակ 3.10 - Ավելացվեց «Միշտ վերագրիր հղումները» դրոշը հղումով օբյեկտների պարտադիր վերագրման համար (փոխանցման արագությունը զգալիորեն կրճատվում է, բայց երբեմն դա անհրաժեշտ է): Ավելացվել է «Պատրաստում» ներդիրը, որտեղ կարող եք կարգավորել հաշվային հաշվառման սկզբնաղբյուրի և նպատակակետի գծապատկերների համապատասխանությունը (հաշվի կոդերի նույն մակարդակի վրա) և հաստատունների փոխանցումը։ Հարթակ 8.3.7.1970, BP 3.0.43.148
- ՆՈՐ ՖՈՒՆԿՑԻՈՆԱԼՈՒԹՅՈՒՆ.Նախքան փաստաթղթերը փոխանցելը, խորհուրդ է տրվում ստուգել հաշվային աղյուսակը աղբյուրի և նպատակակետի համապատասխանության, ինչպես նաև սահմանված հաստատունների հետ համապատասխանության համար:
Այդ նպատակով ավելացվել է «Պատրաստում» ներդիրը, որտեղ կարող եք սահմանել հետևյալ համապատասխանությունները.
Հաշվի համընկնման աղյուսակը լրացնելու ալգորիթմը պարզ է. աղբյուրում առկա շրջանառությունը վերլուծվում է, և այնտեղ հայտնաբերված յուրաքանչյուր հաշվի համար ստացողի մեջ համընկնում է կոդով, եթե համընկնում չի գտնվել, տող է հաշվի հետ: կոդը ցուցադրվում է աղյուսակում, որով պետք է ընտրել ստացողի հաշիվը, այն կօգտագործվի փոխանցման ժամանակ: Poke-ի համապատասխանությունը հաստատված է կոդի մակարդակով:
Սահմանված հաստատունների համապատասխանությունը ստուգելու և փոխանցելու համար օգտագործվում է համապատասխան աղյուսակը.
Լրացնում ենք, անհրաժեշտության դեպքում փոխանցում։ Փոխանցվում են միայն դրոշակով նշված հաստատունները...
Ծրագրի փաթեթը հատուկ հիշողության տարածք է, որը կազմակերպված է ըստ LIFO (Վերջին մուտք, առաջին դուրս) հերթի սկզբունքի: «Դեղ» անվանումը գալիս է դրա կառուցման սկզբունքի անալոգիայից ափսեների կույտով. դուք կարող եք ափսեներ դնել միմյանց վրա (դիզին ավելացնելու մեթոդը, «հրել», «հրել»), այնուհետև. տարեք դրանք՝ սկսած վերևից (կույտից արժեք ստանալու մեթոդ, «popping», «pop»): Ծրագրի կույտը կոչվում է նաև զանգերի կույտ, կատարման կույտ կամ մեքենայական կույտ (որպեսզի չշփոթենք այն «կույտի»՝ տվյալների վերացական կառուցվածքի հետ):
Ինչի՞ համար է ստեկը: Այն թույլ է տալիս հարմարավետ կերպով կազմակերպել ենթածրագրերի զանգը: Երբ կանչվում է, ֆունկցիան ստանում է որոշ արգումենտներ. այն նաև պետք է ինչ-որ տեղ պահի իր տեղական փոփոխականները: Բացի այդ, պետք է հաշվի առնել, որ մի ֆունկցիան կարող է կանչել մեկ այլ ֆունկցիա, որը նույնպես պետք է փոխանցի պարամետրերը և պահպանի իր փոփոխականները։ Օգտագործելով stack-ը, պարամետրեր փոխանցելիս պարզապես անհրաժեշտ է դրանք դնել stack-ի վրա, այնուհետև կանչված ֆունկցիան կարող է «թափել» դրանք այնտեղից և օգտագործել դրանք: Տեղական փոփոխականները նույնպես կարող են պահվել այնտեղ. իր կոդի սկզբում ֆունկցիան հատկացնում է stack հիշողության մի մասը, և երբ վերահսկողությունը վերադառնում է, այն մաքրում և ազատում է այն: Բարձր մակարդակի լեզուներով ծրագրավորողները սովորաբար չեն մտածում նման բաների մասին. կոմպիլյատորը ստեղծում է նրանց համար անհրաժեշտ բոլոր սովորական ծածկագիրը:
Սխալի հետևանքները
Հիմա մենք գրեթե մոտ ենք խնդրին։ Վերացական իմաստով, կույտը անսահման պահեստ է, որտեղ կարելի է անվերջ ավելացնել նոր տարրեր: Ցավոք, մեր աշխարհում ամեն ինչ վերջավոր է, և stack հիշողությունը բացառություն չէ: Ի՞նչ կլինի, եթե այն ավարտվի, երբ ֆունկցիայի արգումենտները դրվեն փաթեթի վրա: Թե՞ ֆունկցիան հիշողություն է հատկացնում իր փոփոխականներին:
Սխալ կառաջանա, որը կոչվում է կույտի արտահոսք: Քանի որ կույտը անհրաժեշտ է օգտատիրոջ կողմից սահմանված գործառույթների կանչը կազմակերպելու համար (և ժամանակակից լեզուներով գրեթե բոլոր ծրագրերը, ներառյալ օբյեկտ-կողմնորոշվածները, այս կամ այն կերպ կառուցված են գործառույթների հիման վրա), նրանք այլևս չեն կարողանա կոչվել. Հետևաբար, օպերացիոն համակարգը վերցնում է վերահսկողությունը, մաքրում է կույտը և դադարեցնում ծրագիրը: Այստեղ մենք կարող ենք ընդգծել stack overflow-ի և stack overflow-ի տարբերությունը. առաջին դեպքում սխալ հիշողության տարածք մուտք գործելիս տեղի է ունենում սխալ, և եթե այս փուլում պաշտպանություն չկա, այն չի դրսևորվում այդ պահին՝ հաջողությամբ։ հանգամանքների համակցությամբ, ծրագիրը կարող է նորմալ աշխատել: Եթե միայն մուտք գործվող հիշողությունը պաշտպանված լիներ, . Կույտի դեպքում ծրագիրը, անշուշտ, ավարտվում է:
Լիովին ճշգրիտ լինելու համար պետք է նշել, որ իրադարձությունների նման նկարագրությունը ճշմարիտ է միայն այն կոմպիլյատորների համար, որոնք կոմպիլյացիա են կատարում հայրենի կոդով։ Կառավարվող լեզուներում վիրտուալ մեքենան ունի կառավարվող ծրագրերի իր փաթեթը, որի վիճակը շատ ավելի հեշտ է վերահսկել, և դուք նույնիսկ կարող եք թույլ տալ բացառություն անել ծրագրից, երբ արտահոսք է տեղի ունենում: C և C++ լեզուներով նման «շքեղության» վրա հույս դնել չես կարող։
Սխալի պատճառները
Ի՞նչը կարող է հանգեցնել նման տհաճ իրավիճակի։ Ելնելով վերը նկարագրված մեխանիզմից, հավանականություններից մեկն այն է, որ կան չափազանց շատ ներդիր ֆունկցիայի կանչեր: Այս սցենարը հատկապես հավանական է, երբ օգտագործվում է ռեկուրսիա: Անսահման ռեկուրսիան (ծույլ գնահատման մեխանիզմի բացակայության դեպքում) ընդհատվում է այս կերպ՝ ի տարբերություն , որը երբեմն ունի օգտակար կիրառություններ։ Այնուամենայնիվ, փաթեթին հատկացված փոքր քանակությամբ հիշողության դեպքում (ինչը, օրինակ, բնորոշ է միկրոկառավարիչների համար), կարող է բավարար լինել զանգերի պարզ հաջորդականությունը:
Մեկ այլ տարբերակ են տեղական փոփոխականները, որոնք պահանջում են մեծ հիշողություն: Մի միլիոն տարրերից բաղկացած տեղական զանգված կամ միլիոն տեղական փոփոխականներ (դուք երբեք չգիտեք, թե ինչ է տեղի ունենում) լավագույն գաղափարը չէ: Նույնիսկ մեկ զանգը նման ագահ ֆունկցիային կարող է հեշտությամբ առաջացնել բուրգի արտահոսք: Մեծ քանակությամբ տվյալներ ստանալու համար ավելի լավ է օգտագործել հիշողության դինամիկ մեխանիզմներ, որոնք թույլ կտան հաղթահարել դրա բացակայության սխալը:
Այնուամենայնիվ, դինամիկ հիշողությունը բավականին դանդաղ է տեղաբաշխման և տեղաբաշխման առումով (քանի որ օպերացիոն համակարգը զբաղվում է դրանով), և ուղղակի մուտքի դեպքում դուք պետք է ձեռքով հատկացնեք և տեղաբաշխեք այն: Կույտի վրա հիշողությունը տեղաբաշխվում է շատ արագ (իրականում, դուք պարզապես պետք է փոխեք մեկ ռեգիստրի արժեքը), բացի այդ, կույտի վրա տեղաբաշխված օբյեկտները ավտոմատ կերպով կանչում են դեստրուկտորներ, երբ ֆունկցիայի կառավարումը վերադառնում է և կույտը մաքրվում է: Իհարկե, անմիջապես ցցից հիշողություն ստանալու ցանկություն է առաջանում։ Հետևաբար, հորդելու երրորդ ճանապարհը ծրագրավորողի կողմից հիշողության բաշխումն է փաթեթի վրա: C գրադարանը տրամադրում է alloca ֆունկցիան հատուկ այս նպատակով: Հետաքրքիր է նշել, որ եթե դինամիկ հիշողության malloc հատկացնելու գործառույթն ունի իր «երկվորյակը» այն ազատելու համար, անվճար, ապա alloca ֆունկցիան չունի այն. հիշողությունը ավտոմատ կերպով ազատվում է ֆունկցիայի կառավարումը վերադարձնելուց հետո: Թերևս դա միայն բարդացնում է իրավիճակը. ի վերջո, գործառույթից դուրս գալուց առաջ հնարավոր չի լինի ազատել հիշողությունը: Թեև, ըստ man page-ի, «alloca ֆունկցիան կախված է մեքենայից և կոմպիլյատորից, շատ համակարգերում դրա իրականացումը խնդրահարույց է և խելագարված, դրա օգտագործումը շատ անլուրջ է և չարամիտ», այն դեռ օգտագործվում է:
Օրինակներ
Որպես օրինակ, եկեք նայենք MSDN-ում տեղադրված ռեկուրսիվ ֆայլերի որոնման կոդը.
Void DirSearch(String* sDir) (փորձեք ( // Գտեք ենթաթղթապանակները փոխանցված թղթապանակում: String* d = Directory::GetDirectories(sDir); int numDirs = d->get_Length(); for (int i= 0; i< numDirs; i++) { // Find all the files in the subfolder. String* f = Directory::GetFiles(d[i],textBox1->Տեքստ); int numFiles = f->get_Length(); համար (int j=0; j< numFiles; j++) { listBox1->Items->Add(f[j]); ) DirSearch(d[i]); ) ) catch (System::Exception* e) ( MessageBox::Show(e->Message); ) )
Այս ֆունկցիան ստանում է նշված գրացուցակում գտնվող ֆայլերի ցանկը, այնուհետև իրեն կանչում է ցանկի այն տարրերը, որոնք պատահաբար դիրեկտորիաներ են: Համապատասխանաբար, բավական խորը ծառով ֆայլային համակարգ, ստանում ենք բնական արդյունք։
Երկրորդ մոտեցման օրինակ, որը վերցված է «Ինչու՞ է տեղի ունենում կույտերի արտահոսքը» հարցից: Stack Overflow կոչվող կայքից (կայքը ծրագրավորման ցանկացած թեմայի վերաբերյալ հարցերի և պատասխանների հավաքածու է, և ոչ միայն Stack Overflow, ինչպես կարող է թվալ).
#սահմանել W 1000 #սահմանել H 1000 #սահմանել MAX 100000 //... int main() ( int image; float dtr; initImg (image,dtr); return 0; )
Ինչպես տեսնում եք, հիմնական ֆունկցիան հիշողություն է հատկացնում stack-ի վրա int և float տիպերի զանգվածների համար, որոնցից յուրաքանչյուրը ունի միլիոն տարրեր, որոնք ընդհանուր առմամբ տալիս են 8 մեգաբայթից մի փոքր պակաս: Եթե հաշվի առնեք, որ լռելյայնորեն Visual C++-ը ստեկի համար պահում է ընդամենը 1 մեգաբայթ, ապա պատասխանն ակնհայտ է դառնում։
Եվ ահա մի օրինակ՝ վերցված Lightspark Flash նվագարկչի նախագծի GitHub պահոցից.
ՍահմանելSoundTag::DefineSoundTag(/* ... */) ( // ... unsigned int soundDataLength = h.getLength()-7; unsigned char *tmp = (unsigned char *)alloca(soundDataLength); // .. .)
Կարելի է հուսալ, որ h.getLength()-7-ը այնքան էլ մեծ թիվ չէ, որպեսզի հաջորդ տողում գերհոսք չլինի։ Բայց արդյո՞ք հիշողության բաշխման վրա խնայված ժամանակը արժե ծրագրի «պոտենցիալ» խափանումը:
Ներքեւի գիծ
Stack overflow-ը ճակատագրական սխալ է, որն առավել հաճախ ազդում է ռեկուրսիվ ֆունկցիաներ պարունակող ծրագրերի վրա: Այնուամենայնիվ, նույնիսկ եթե ծրագիրը չի պարունակում նման գործառույթներ, այնուամենայնիվ, հնարավոր է արտահոսք՝ կապված տեղական փոփոխականների մեծ չափի կամ կույտի վրա հիշողության ձեռքով տեղաբաշխման սխալի հետ: Բոլոր դասական կանոնները մնում են ուժի մեջ՝ եթե կա ընտրություն, ապա ավելի լավ է ռեկուրսի փոխարեն ընտրել կրկնություն, ինչպես նաև կոմպիլյատորի փոխարեն ձեռքով աշխատանք չանել։
Մատենագիտություն
- E. Tanenbaum. Համակարգչային ճարտարապետություն.
- Վիքիպեդիա. Դույների հորդացում:
- Stack Overflow. Stack overflow C++.
Ստեկը, այս համատեքստում, վերջինն է առաջին բուֆերում, որը դուք հատկացնում եք ձեր ծրագրի կատարման ընթացքում: «Վերջին, առաջինը» (LIFO) նշանակում է, որ վերջին բանը, որը դուք դնում եք, միշտ առաջին բանն է, որ ետ եք թողնում. եթե 2 տարր եք դուրս հանում կույտի վրա՝ «A» և ապա «B», ապա առաջին բանը, որ դուրս եք հանում կույտից: կլինի «B», իսկ հաջորդը կլինի «A»:
Երբ ձեր կոդի մեջ որևէ ֆունկցիա եք կանչում, գործառույթի կանչից հետո հաջորդ հրամանը պահվում է կույտում և ցանկացած հիշողության տարածքում, որը կարող է վերագրվել ֆունկցիայի կանչով: Ընտրված ֆունկցիան կարող է օգտագործել ավելի շատ ստեկ իր տեղական փոփոխականների համար: Երբ դա արվի, այն կազատի տեղական փոփոխական տարածքը, որն օգտագործում էր, այնուհետև կվերադառնա նախորդ գործառույթին:
Stack Overflow
Կույտի արտահոսքն այն է, երբ դուք ավելի շատ հիշողություն եք օգտագործել փաթեթում, քան ձեր ծրագիրը նախատեսված էր օգտագործել: Ներկառուցված համակարգերում դուք կարող եք ունենալ միայն 256 բայթ կույտի համար, և եթե յուրաքանչյուր ֆունկցիան վերցնում է 32 բայթ, ապա կարող եք ունենալ միայն 8 ֆունկցիայի կանչ 2 ֆունկցիայի համար խորը ֆունկցիա 1 ֆունկցիայով, որը կանչում է ֆունկցիա 3, որը կանչում է ֆունկցիա 4: .Ով կանչում է ֆունկցիա 8, որը կանչում է ֆունկցիա 9, բայց ֆունկցիան 9-ը վերագրում է հիշողությունը կույտից դուրս: Սա կարող է վերագրանցել հիշողությունը, կոդը և այլն:
Շատ ծրագրավորողներ այս սխալը թույլ են տալիս՝ զանգահարելով A ֆունկցիան, որն այնուհետև կանչում է ֆունկցիան B, որն այնուհետև կանչում է C ֆունկցիան, որն այնուհետև կանչում է ֆունկցիան A: Այն կարող է շատ ժամանակ աշխատել, բայց միայն մեկ սխալ մուտքագրումը կհանգեցնի այն ընդմիշտ շրջանագծին, մինչև համակարգիչը: ձախողվելը պարզում է, որ դարակը լիքն է:
Ռեկուրսիվ ֆունկցիաները նույնպես դրա պատճառն են, բայց եթե դուք գրում եք ռեկուրսիվ (այսինքն՝ ձեր գործառույթն իրեն կանչում է), ապա դուք պետք է իմանաք դրա մասին և օգտագործեք ստատիկ/գլոբալ փոփոխականներ՝ անվերջ ռեկուրսիայի կանխարգելման համար:
Սովորաբար, ՕՀ-ն և ծրագրավորման լեզուն, որը դուք օգտագործում եք, կառավարում է փաթեթը, և դա ձեր ձեռքից դուրս է: Դուք պետք է նայեք ձեր զանգի գրաֆիկին (ծառի կառուցվածքը, որը ցույց է տալիս ձեր հիմնական կետից, թե ինչ է կանչում յուրաքանչյուր ֆունկցիա), որպեսզի տեսնեք, թե որքան խորն են ձեր ֆունկցիայի կանչերը, և նույնականացնեք հանգույցներն ու ռեկուրսիան, որոնք նախատեսված չեն: Կանխամտածված օղակները և ռեկուրսիան պետք է արհեստականորեն ստուգվեն սխալներով, եթե դրանք շատ անգամ են զանգում միմյանց:
Բացի լավ ծրագրավորման փորձից, ստատիկ և դինամիկ փորձարկումներից, այս բարձր մակարդակի համակարգերում շատ բան չեք կարող անել:
Ներկառուցված համակարգեր
Ներկառուցված աշխարհում, հատկապես բարձր հավաստիության կոդում (ավտոմոբիլային, օդատիեզերական, օդատիեզերական), դուք կատարում եք լայնածավալ փորձարկումներ և կոդերի վերանայում, բայց նաև անում եք հետևյալը.
- Անջատել ռեկուրսիան և հանգույցները՝ քաղաքականության և փորձարկման համապատասխանությունը
- Պահեք կոդը և դրեք իրարից հեռու (կոդը ֆլեշում, դրեք RAM-ում և երբեք չեն համապատասխանի միմյանց)
- Տեղադրեք պահակաձողեր դարակի շուրջը. հիշողության դատարկ տարածք, որը դուք լրացնում եք կախարդական թվով (սովորաբար ընդհատման ռեժիմը, բայց այստեղ շատ տատանումներ կան) և հարյուրավոր կամ հազարավոր անգամներ վայրկյանում նայում եք պահակաձողերին, որպեսզի պատրաստեք: վստահ եմ, որ դրանք վերագրված չեն:
- Օգտագործեք հիշողության պաշտպանություն (այսինքն՝ մի՛ գործարկեք կույտի վրա, մի՛ կարդացեք կամ մի՛ գրեք անմիջապես կույտի հետևում)
- Ընդհատումները չեն կանչում երկրորդական գործառույթներ. դրանք սահմանում են դրոշներ, պատճենում են տվյալները և թույլ են տալիս հավելվածին հոգ տանել դրանց հետ (հակառակ դեպքում դուք կարող եք հայտնվել 8 խորությամբ ձեր ֆունկցիայի կանչի ծառի մեջ, ունենալ ընդհատում և հետո ունենալ ևս մի քանի գործառույթներ ներսում: ընդհատման ելքը՝ առաջացնելով նետում): Դուք ունեք բազմաթիվ զանգերի ծառեր՝ մեկը հիմնական գործընթացների համար և մեկը՝ յուրաքանչյուր ընդհատման համար: Եթե ձեր ընդհատումները կարող են ընդհատել միմյանց... դե, վիշապներ կան...
Բարձր մակարդակի լեզուներ և համակարգեր
Բայց օպերացիոն համակարգերով աշխատող բարձր մակարդակի լեզուներով.
- Նվազեցրեք տեղական փոփոխականների պահեստը (տեղական փոփոխականները պահվում են կույտի վրա), թեև կոմպիլյատորները բավականին խելացի են այս հարցում և երբեմն մեծ կտորներ են դնում կույտի վրա, եթե ձեր զանգի ծառը մակերեսային է)
- Խուսափեք կամ խստորեն սահմանափակեք կրկնությունը
- Մի ընդհատեք ձեր ծրագրերը ավելի ու ավելի փոքր գործառույթների մեջ. նույնիսկ առանց հաշվի առնելու տեղական փոփոխականները, յուրաքանչյուր ֆունկցիայի կանչը սպառում է մինչև 64 բայթ փաթեթի վրա (32-բիթանոց պրոցեսոր, պահպանում է պրոցեսորի ռեգիստրների կեսը, դրոշները և այլն):
- Պահպանեք զանգի ծառը մակերեսային (նման է վերևի նկարագրությանը)
Վեբ սերվերներ
Կախված է ձեր ունեցած ավազարկղից՝ կարո՞ղ եք կառավարել կամ նույնիսկ տեսնել բուրգը: Հավանական է, որ դուք կարող եք կառավարել վեբ սերվերները, ինչպես ցանկացած այլ բարձր մակարդակի լեզու և օպերացիոն համակարգ. դա հիմնականում ձեր ձեռքից դուրս է, բայց ստուգեք ձեր օգտագործած լեզուն և սերվերի փաթեթը: Օրինակ, դուք կարող եք բաժանել փաթեթը ձեր SQL սերվերի վրա:
Informix® DataBlade™ API ծրագրավորողի ուղեցույցը հասանելի է ներբեռնման համար: «Stack Space կառավարում» բաժինը նկարագրում է օգտագործողի կողմից սահմանված գործառույթների (UDR) ստեղծումը: Այս հոդվածը տրամադրում է լրացուցիչ տեղեկություններ և վրիպազերծման խորհուրդներ:
Հետևյալ տեղեկատվությունը կիրառվում է անկախ նրանից, թե UDR-ն աշխատում է օգտագործողի կողմից սահմանված վիրտուալ պրոցեսորի (VP) կամ VP պրոցեսորի վրա: Թելերի կույտը կարող է տեղափոխվել օգտվողի կողմից սահմանված վիրտուալ պրոցեսոր՝ UDR-ն իրականացնելուց անմիջապես առաջ:
Ինչ չափի կույտ է հատկացվել UDR-ի համար:
UDR-ին հասանելի կույտի չափը կախված է նրանից, թե ինչպես է ստեղծվել UDR-ը.
օգտագործելով STACK փոփոխիչը, որը թույլ է տալիս UDR-ին օգտագործել իր հատուկ հատկացված կույտը,
առանց STACK մոդիֆիկատորի, ինչը նշանակում է, որ UDR-ը սերվերի կողմից հատկացված ստեկը կհամօգտագործի հարցումը կատարող շարանի հետ: Կույտի չափն այս դեպքում որոշվելու է onconfig կազմաձևման ֆայլում STACKSIZE պարամետրի արժեքով:
STACK փոփոխիչ
CREATE PROCEDURE կամ CREATE FUNCTION հայտարարություններն ունեն կամընտիր STACK մոդիֆիկատոր, որը թույլ է տալիս Ձեզ նշել կույտի տարածության քանակը՝ բայթերով, որը պահանջվում է UDR-ն իրականացնելու համար:
Եթե UDR ստեղծելիս օգտագործում եք STACK մոդիֆիկատորը, ապա սերվերը կհատկացնի և կհատկացնի stack տարածքը ամեն անգամ, երբ UDR-ն գործարկվի: Փաստացի հասանելի չափը հավասար է STACK արժեքին բայթերով՝ հանած որոշ գերավճար՝ կախված ֆունկցիայի արգումենտների քանակից:
Եթե STACK-ի արժեքը onconfig ֆայլում STACKSIZE պարամետրից փոքր է (տես հաջորդ բաժինը), ապա UDR-ի համար հատկացված կույտի չափը ավտոմատ կերպով կկլորացվի մինչև STACKSIZE արժեքը:
STACKSIZE կազմաձևման պարամետր
Onconfig կազմաձևման ֆայլը ներառում է STACKSIZE պարամետր, որը սահմանում է օգտագործողի թելերի լռելյայն չափը:
Եթե UDR ստեղծելիս չեք նշում STACK, ապա սերվերը չի հատկացնում լրացուցիչ stack տարածք այդ UDR-ն գործարկելու համար: Փոխարենը, UDR-ն օգտագործում է կույտի տարածքը, որը հատկացված է հարցումը կատարելու համար: Հասանելի կույտի չափը կախված կլինի SQL մակարդակում գործառույթի կատարման ծախսերից:
Յուրաքանչյուր շղթայի կույտը հատկացվում է մեկ անգամ՝ հարցումը կատարող կոնկրետ շղթայի համար: Կատարումը ավելի լավ է, երբ UDR-ը կիսում է մեկ կույտ թելերի հետ, քանի որ սերվերը չի վատնում ռեսուրսները յուրաքանչյուր UDR զանգի համար լրացուցիչ ստեկ հատկացնելու վրա: Մյուս կողմից, եթե UDR-ի կողմից օգտագործվող կույտի չափը մոտենում է STACKSIZE արժեքին, դա կարող է առաջացնել կույտի արտահոսք՝ ֆունկցիան որպես բարդ հարցման մաս կանչելիս (այդ դեպքում ավելի քիչ կույտ տարածք հասանելի կլինի UDR-ի կատարման համար):
Խնդրում ենք նկատի ունենալ, որ չպետք է սահմանեք STACKSIZE արժեքը չափազանց բարձր, քանի որ դա կազդի բոլոր օգտվողների շղթաների վրա:
Ե՞րբ է անհրաժեշտ վերահսկել կույտի չափը:
YԴուք պետք է կառավարեք կույտերի տարածքը, եթե UDR-ն կատարում է ռեկուրսիվ զանգեր կամ եթե UDR-ն պահանջում է ավելի շատ դարսային տարածք, քան հասանելի է լռելյայնորեն հարցման շղթայի կույտում (STACKSIZE):
UDR-ի կատարման համար ստեկը մեծացնելու երկու եղանակ կա.
UDR ստեղծելիս նշեք STACK փոփոխիչը:
Օգտագործեք mi_call()՝ ռեկուրսիվ զանգեր կատարելու համար (տե՛ս Informix DataBlade API ծրագրավորողի ուղեցույցը որպես օրինակ):
Եթե դուք չափը չնշեք STACK-ի միջոցով, և եթե չօգտագործեք mi_call()՝ ընթացիկ ստեկը մեծացնելու համար, և եթե UDR-ն անում է մի բան, որը պահանջում է մեծ տարածություն, դա կհանգեցնի ցցերի արտահոսքի:
Նկատի ունեցեք, որ որոշ mi_* ֆունկցիաներ ավելացնում են նոր կույտ հատված՝ իրենց կատարման համար: Այս հատվածներն ազատվում են կանչող UDR ֆունկցիային վերադառնալիս:
Ի՞նչ անել, եթե ինչ-որ բան սխալ է:
Stack-ի օգտագործման մոնիտորինգ
Մոնիտորինգի նպատակն է բացահայտել հատուկ UDR-ն, որն առաջացնում է կույտի արտահոսք, որպեսզի կարողանաք փոխել STACK արժեքը հատուկ այդ UDR-ի համար:
Դիտել կույտի օգտագործումը «onstat -g sts» հրամանով
SQL հարցում կատարող նստաշրջանի մոնիտորինգ՝ օգտագործելով «onstat -g ses session_id»
SQL հարցումը նույնականացնելուց հետո, որն ավարտվում է stack overflow-ով, դուք պետք է որոշեք stack-ի օգտագործումը՝ առանձին-առանձին կատարելով UDR հարցումները, որոնք սկզբնական հարցման մաս են կազմում:
Դուք կարող եք դինամիկ կերպով սահմանել STACK արժեքը UDR-ի համար: Օրինակ:
փոխել MyFoo ֆունկցիան (lvarchar,lvarchar) հետ (add stack=131072);STACK արժեքը փոխելուց հետո դուք պետք է փորձարկեք սկզբնական հարցումը՝ համոզվելու համար, որ այն այժմ կայուն է:
Մեծացնել STACKSIZE-ը
Որպես այլընտրանք, փորձեք ավելացնել STACKSIZE արժեքը: Ստուգեք, արդյոք սա լուծում է խնդիրը: (Մի մոռացեք հետագայում վերադարձնել հին արժեքը):
Եթե STACKSIZE-ի ավելացումը չի օգնում, ապա խնդիրը ամենայն հավանականությամբ հիշողության խաթարումն է: Ահա մի քանի առաջարկներ.
Միացնել հիշողության խզբզումը և հիշողության լողավազանի ստուգումը: «Վրիպազերծման խնդիրներ» բաժինը UDR-ների համար հիշողության հատկացում հոդվածում բացատրում է, թե ինչպես դա անել:
Վերանայեք mi_lvarchar-ի օգտագործումը: Առանձնահատուկ ուշադրություն պետք է դարձնել այն վայրերին, որտեղ mi_lvarchar-ը փոխանցվում է մի ֆունկցիայի, որն ակնկալում է ստանալ զրոյական վերջացրած տող՝ որպես արգումենտ:
Կրճատեք պրոցեսորների (կամ օգտագործողի) VP-ների թիվը մինչև մեկ՝ խնդիրն ավելի արագ վերարտադրելու համար:
mi_print_stack() -- Solaris
Informix Dynamic Server-ը Solaris OS-ի համար ներառում է mi_print_stack() ֆունկցիա, որը կարելի է կանչել UDR-ում: Լռելյայնորեն, այս գործառույթը պահպանում է stack frame-ը հետևյալ ֆայլում.
/tmp/default.stack
Դուք չեք կարող փոխել ելքային ֆայլի անունը, բայց կարող եք փոխել դրա գտնվելու վայրը՝ փոխելով DBTEMP միջավայրի փոփոխականի արժեքը: Համոզվեք, որ $DBTEMP գրացուցակը գրելի է informix օգտագործողի կողմից: Mi_print_stack()-ի գործարկման ընթացքում հայտնաբերված ցանկացած սխալ հաղորդվում է $MSGPATH-ին:
Այս հատկությունը հասանելի է միայն OC Solaris-ի համար:
Բառարան
Այս հոդվածում օգտագործված տերմինները և հապավումները.
| UDR | Օգտագործողի կողմից սահմանված ռեժիմ |
|---|---|
| Վ.Պ. | Վիրտուալ պրոցեսոր |
Այս հոդվածը ևս մեկ անգամ ցույց է տալիս, որ անվտանգության միջոցների ցանկացած համալիր պետք է ներառի իրականացման բոլոր փուլերը՝ մշակում, տեղակայում, համակարգի կառավարում և, իհարկե, կազմակերպչական միջոցառումներ: Տեղեկատվական համակարգերում հենց «մարդկային գործոնն» է (ներառյալ օգտատերերը) անվտանգության գլխավոր սպառնալիքը։ Միջոցառումների այս փաթեթը պետք է լինի ողջամիտ և հավասարակշռված. իմաստ չունի և քիչ հավանական է, որ բավարար միջոցներ կհատկացվեն պաշտպանություն կազմակերպելու համար, որը գերազանցում է բուն տվյալների արժեքը:
Ներածություն
1C:Enterprise-ը Ռուսաստանում ամենատարածված հաշվապահական համակարգն է, բայց չնայած դրան, մինչև 8.0 տարբերակը նրա մշակողները շատ քիչ ուշադրություն էին դարձնում անվտանգության խնդիրներին: Հիմնականում, իհարկե, դա թելադրված էր արտադրանքի գնային նիշով և փոքր բիզնեսի վրա կենտրոնացվածությամբ, որտեղ չկան որակյալ ՏՏ մասնագետներ, և անվտանգ համակարգի տեղակայման և պահպանման հնարավոր ծախսերը չափազանց թանկ կլինեն ձեռնարկության համար: 8.0 տարբերակի թողարկմամբ շեշտը պետք է փոխվեր. լուծումների արժեքը զգալիորեն ավելացավ, համակարգը դարձավ շատ ավելի լայնածավալ և ճկուն. պահանջները զգալիորեն փոխվեցին: Արդյոք համակարգը դարձել է բավականաչափ հուսալի և անվտանգ, շատ անհատական հարց է: Ժամանակակից ձեռնարկության հիմնական տեղեկատվական համակարգը պետք է համապատասխանի առնվազն հետևյալ անվտանգության պահանջներին.
- Ներքին պատճառներով համակարգի խափանման բավականին ցածր հավանականություն:
- Օգտագործողի հուսալի թույլտվություն և տվյալների պաշտպանություն սխալ գործողություններից:
- Օգտագործողի իրավունքների հատկացման արդյունավետ համակարգ:
- Առցանց պահուստավորման և վերականգնման համակարգ՝ ձախողման դեպքում:
Արդյո՞ք 1C:Enterprise 8.0-ի վրա հիմնված լուծումները համապատասխանում են այս պահանջներին: Հստակ պատասխան չկա. Չնայած մուտքի վերահսկման համակարգում զգալի փոփոխություններին, դեռևս բազմաթիվ չլուծված խնդիրներ են մնում: Կախված նրանից, թե ինչպես է համակարգը նախագծված և կազմաձևված, այս բոլոր պահանջները կարող են բավարար չափով չբավարարվել կամ բավարարվել տվյալ ներդրման համար, այնուամենայնիվ, արժե ուշադրություն դարձնել (և սա հարթակի «երիտասարդության» էական հետևանք է. ) որ թվարկված պայմաններն ամբողջությամբ կատարելու համար անհրաժեշտ է իսկապես հերկուլեսյան ջանքեր գործադրել։
Այս հոդվածը նախատեսված է 1C:Enterprise հարթակում լուծումներ մշակողների և իրականացնողների, ինչպես նաև այն կազմակերպությունների համակարգային ադմինիստրատորների համար, որտեղ օգտագործվում է 1C:Enterprise, և նկարագրում է համակարգի հաճախորդ-սերվերի տարբերակի մշակման և կազմաձևման որոշ ասպեկտներ: կազմակերպության տեսակետից տեղեկատվական անվտանգություն. Այս հոդվածը չի կարող օգտագործվել որպես փաստաթղթերի փոխարինում, այլ միայն մատնանշում է որոշ կետեր, որոնք դեռ չեն արտացոլվել դրանում: Եվ, իհարկե, ոչ այս հոդվածը, ոչ ամբողջ փաստաթղթերը չեն կարողանա արտացոլել անվտանգ տեղեկատվական համակարգի կառուցման խնդրի բարդությունը, որը միևնույն ժամանակ պետք է բավարարի անվտանգության, կատարողականի, հարմարության և ֆունկցիոնալության հակասական պահանջները:
Դասակարգում և տերմինաբանություն
Հոդվածում քննարկվող հիմնական թեման տեղեկատվական սպառնալիքներն են։
Տեղեկատվական սպառնալիք– իրավիճակի հնարավորությունը, երբ տվյալները կկարդվեն, պատճենվեն, փոխվեն կամ արգելափակվեն առանց թույլտվության:
Եվ այս սահմանման հիման վրա հոդվածը տեղեկատվական սպառնալիքները դասակարգում է հետևյալ կերպ.
- Տվյալների չարտոնված ոչնչացում
- Տվյալների չարտոնված փոփոխություն
- Տվյալների չարտոնված պատճենում
- Տվյալների չարտոնված ընթերցում
- Տվյալների անհասանելիություն
Բոլոր սպառնալիքները բաժանվում են միտումնավոր և ոչ միտումնավոր: Իրականացված տեղեկատվական սպառնալիք կանվանենք միջադեպ. Համակարգի առանձնահատկություններն են.
Խոցելիություններ- միջադեպերի հանգեցնող հատկանիշներ Պաշտպանության միջոցառումներ– հատկանիշներ, որոնք արգելափակում են միջադեպի հնարավորությունըՀիմնականում դիտարկվում են միայն այն դեպքերը, որոնց հավանականությունը պայմանավորված է հաճախորդ-սերվեր տարբերակում 1C: Enterprise 8.0 տեխնոլոգիական պլատֆորմի օգտագործմամբ (հետագայում, այն դեպքերում, երբ դա չի հակասում պարզապես 1C կամ 1C 8.0 իմաստին) . Եկեք սահմանենք հետևյալ հիմնական դերերը համակարգի օգտագործման հետ կապված.
- Օպերատորներ– օգտատերեր, ովքեր իրավունք ունեն դիտելու և փոփոխելու տվյալները, որոնք սահմանափակված են հավելվածի դերով, բայց չունեն վարչական գործառույթներ
- Համակարգի ադմինիստրատորներ– օգտատերեր, ովքեր ունեն ադմինիստրատիվ իրավունքներ համակարգում, ներառյալ վարչական իրավունքներ հավելվածի սերվերի և MS SQL սերվերի օպերացիոն համակարգերում, MS SQL-ի վարչական իրավունքներ և այլն:
- Տեղեկատվական անվտանգության ադմինիստրատորներ– օգտատերեր, որոնց հանձնարարված են 1C տեղեկատվական բազայի որոշակի վարչական գործառույթներ (օրինակ՝ օգտվողների ավելացում, փորձարկում և ամրագրում, կրկնօրինակում, կիրառական լուծումների ստեղծում և այլն):
- Համակարգի մշակողները- կիրառական լուծում մշակող օգտվողներ: Ընդհանուր առմամբ, նրանք կարող են մուտք չունենալ աշխատանքային համակարգ։
- Անձինք, ովքեր չունեն ուղղակի մուտք դեպի համակարգ– օգտատերեր, որոնց 1C-ի մուտքի իրավունքը պատվիրակված չէ, բայց ովքեր կարող են այս կամ այն չափով ազդել համակարգի աշխատանքի վրա (սովորաբար սրանք բոլորը նույն Active Directory տիրույթի օգտվողներն են, որտեղ տեղադրված է համակարգը): Այս կատեգորիան հիմնականում համարվում է համակարգում պոտենցիալ վտանգավոր առարկաները բացահայտելու համար:
- Ավտոմատացված վարչական սկրիպտներ– ծրագրեր, որոնց պատվիրակված են որոշակի գործառույթներ, որոնք նախատեսված են որոշակի գործողություններ ավտոմատ կերպով կատարելու համար (օրինակ՝ տվյալների ներմուծում-արտահանում)
Այստեղ հարկ է նշել երկու կետ. նախ՝ այս դասակարգումը շատ կոպիտ է և հաշվի չի առնում բաժանումները յուրաքանչյուր խմբի մեջ. նման բաժանում կստեղծվի որոշ կոնկրետ դեպքերի համար, և երկրորդ՝ ենթադրվում է, որ այլ անձինք չեն կարող ազդել գործողության վրա։ համակարգի, որը պետք է տրամադրվի 1C-ին արտաքին միջոցներով:
Անվտանգության ցանկացած համակարգ պետք է նախագծված լինի՝ հաշվի առնելով իրագործելիությունը և սեփականության արժեքը: Ընդհանուր առմամբ տեղեկատվական համակարգ մշակելիս և ներդնելիս անհրաժեշտ է, որ համակարգի պաշտպանության գինը համապատասխանի.
- պաշտպանված տեղեկատվության արժեքը.
- միջադեպ ստեղծելու ծախսերը (կանխամտածված սպառնալիքի դեպքում);
- Միջադեպի դեպքում ֆինանսական ռիսկեր
Անիմաստ ու վնասակար է պաշտպանություն կազմակերպելը, որը շատ ավելի թանկ արժե, քան դրա ֆինանսական արդյունավետությունը գնահատելը։ Տեղեկատվության կորստի ռիսկերը գնահատելու մի քանի մեթոդներ կան, բայց դրանք չեն քննարկվում այս հոդվածի շրջանակներում: Մեկ այլ կարևոր ասպեկտ է հաճախակի հակասական պահանջների հավասարակշռության պահպանումը տեղեկատվական անվտանգության, համակարգի կատարողականի, համակարգի հետ աշխատանքի հարմարավետության և դյուրինության, զարգացման և ներդրման արագության և ձեռնարկությունների տեղեկատվական համակարգերի այլ պահանջների նկատմամբ:
Համակարգի տեղեկատվական անվտանգության մեխանիզմի հիմնական առանձնահատկությունները
1C:Enterprise 8.0-ը գալիս է երկու տարբերակով՝ ֆայլ և հաճախորդ-սերվեր: Ֆայլի տարբերակը չի կարող համարվել որպես համակարգի տեղեկատվական անվտանգությունն ապահովելու հետևյալ պատճառներով.
- Տվյալները և կոնֆիգուրացիան պահվում են ֆայլում, որը ընթեռնելի և գրավոր է համակարգի բոլոր օգտագործողների համար:
- Ինչպես ցույց կտա ստորև, համակարգի թույլտվությունը շատ հեշտությամբ շրջանցվում է:
- Համակարգի ամբողջականությունն ապահովվում է միայն հաճախորդի մասի միջուկով։
Հաճախորդ-սերվեր տարբերակում MS SQL Server-ը օգտագործվում է տեղեկատվության պահպանման համար, որն ապահովում է.
- Ավելի հուսալի տվյալների պահպանում:
- Ֆայլերի մեկուսացում ուղղակի մուտքից:
- Գործարքների և կողպման ավելի առաջադեմ մեխանիզմներ:
Չնայած համակարգի ֆայլի և հաճախորդ-սերվերի տարբերակների միջև զգալի տարբերություններին, նրանք ունեն կիրառական լուծումների մակարդակում մուտքի վերահսկման միասնական սխեմա, որն ապահովում է հետևյալ հնարավորությունները.
- Օգտագործողի թույլտվություն՝ օգտագործելով 1C-ում նշված գաղտնաբառը:
- Օգտատիրոջ թույլտվություն՝ հիմնված Windows-ի ընթացիկ օգտագործողի վրա:
- Համակարգի օգտագործողներին դերերի վերագրում:
- Վարչական գործառույթների սահմանափակումն ըստ դերի.
- Առկա ինտերֆեյսերի նշանակումը ըստ դերերի:
- Մետատվյալների օբյեկտների հասանելիության սահմանափակում ըստ դերի:
- Սահմանափակելով մուտքը օբյեկտի մանրամասներին ըստ դերի:
- Տվյալների օբյեկտների մուտքի սահմանափակում ըստ դերերի և նիստի պարամետրերի:
- Տվյալների և գործարկվող մոդուլների ինտերակտիվ հասանելիության սահմանափակում:
- Կոդի կատարման որոշ սահմանափակումներ:
Ընդհանուր առմամբ, օգտագործվող տվյալների հասանելիության սխեման բավականին բնորոշ է այս մակարդակի տեղեկատվական համակարգերի համար: Այնուամենայնիվ, եռաստիճան հաճախորդ-սերվեր ճարտարապետության այս իրականացման հետ կապված, կան մի քանի հիմնարար ասպեկտներ, որոնք հանգեցնում են համեմատաբար մեծ թվով խոցելիության.
Տվյալների մշակման մեծ թվով փուլեր, և յուրաքանչյուր փուլում կարող են կիրառվել օբյեկտներ մուտք գործելու տարբեր կանոններ:
Անվտանգության տեսանկյունից նշանակալի տվյալների մշակման փուլերի փոքր-ինչ պարզեցված դիագրամը ներկայացված է Նկար 1-ում: Ընդհանուր կանոն 1C-ի համար նշանակում է նվազեցնել սահմանափակումները, երբ դուք շարժվում եք այս սխեմայի ներքևում, հետևաբար, օգտագործելով խոցելիությունը որևէ մեկի վրա: վերին մակարդակներըկարող է խաթարել համակարգը բոլոր մակարդակներում:
Հաղորդված տվյալների մոնիտորինգի անբավարար սահմանված ընթացակարգեր մակարդակից մակարդակ տեղափոխելիս:
Ցավոք սրտի, համակարգի ոչ բոլոր ներքին մեխանիզմներն են կատարյալ կարգաբերված, հատկապես ոչ ինտերակտիվ մեխանիզմների դեպքում, որոնց վրիպազերծումը մի կողմից միշտ ավելի աշխատատար է, մյուս կողմից՝ ավելի պատասխանատու: Այս «հիվանդությունը» բացառապես 1C-ի հետ կապված խնդիր չէ, այն հայտնաբերվել է շատ վաճառողների սերվերային արտադրանքներում: Միայն վերջին տարիներին էապես ավելացել է ուշադրությունը այս խնդիրների նկատմամբ։
Նախորդ տարբերակից ժառանգված ծրագրավորողների և համակարգի ադմինիստրատորների ոչ բավարար բարձր միջին որակավորում:
1C:Enterprise գծի արտադրանքն ի սկզբանե կենտրոնացած էր զարգացման հեշտության և աջակցության և փոքր կազմակերպություններում աշխատելու վրա, ուստի զարմանալի չէ, որ պատմականորեն այն զարգացրել է, որ կիրառական լուծումների «մշակողների» և «ադմինիստրատորների» զգալի մասը. համակարգերը չունեն բավարար գիտելիքներ և հմտություններ շատ ավելի բարդ արտադրանքի հետ աշխատելու համար, որը 8.0 տարբերակն է: Խնդիրն ավելի է սրվում ֆրանչայզեր ընկերությունների կողմից հաճախորդների հաշվին «մարտական» դասավանդման պրակտիկայով, առանց այս հարցին համակարգված մոտենալու։ Պետք է հարգանքի տուրք մատուցել 1C ընկերությանը, որ վերջին մի քանի տարիների ընթացքում այս իրավիճակը աստիճանաբար շտկվել է. լուրջ ֆրանչայզեր ընկերությունները սկսել են ավելի պատասխանատու մոտեցում ցուցաբերել անձնակազմի ընտրության և վերապատրաստման խնդրին, տեղեկատվական տեխնոլոգիաների աջակցության մակարդակին: 1C ընկերությունը զգալիորեն աճել է, սերտիֆիկացման ծրագրեր են հայտնվել՝ ուղղված սպասարկման բարձր մակարդակին. բայց իրավիճակը հնարավոր չէ շտկել ակնթարթորեն, ուստի այս գործոնը պետք է հաշվի առնել համակարգի անվտանգությունը վերլուծելիս:
Հարթակը համեմատաբար երիտասարդ է։
Նմանատիպ ուշադրության և օգտագործման նպատակների ապրանքների շարքում սա ամենաերիտասարդ լուծումներից մեկն է: Պլատֆորմի ֆունկցիոնալությունը քիչ թե շատ հաստատվել է ավելի քիչ, քան մեկ տարի առաջ: Միևնույն ժամանակ, պլատֆորմի յուրաքանչյուր թողարկում՝ սկսած 8.0.10-ից (այս թողարկումում էր, որ ներդրվեցին համակարգի գրեթե բոլոր ներկայիս հնարավորությունները) զգալիորեն ավելի կայուն դարձավ, քան նախորդները։ Ստանդարտ կիրառական լուծումների ֆունկցիոնալությունը դեռևս աճում է թռիչքներով և սահմաններով, թեև օգտագործվում է հարթակի հնարավորությունների միայն կեսը: Իհարկե, նման պայմաններում կարելի է բավականին պայմանականորեն խոսել կայունության մասին, բայց ընդհանուր առմամբ պետք է ընդունել, որ 1C 8.0 հարթակի լուծումները շատ առումներով զգալիորեն առաջ են 1C-ի նմանատիպ լուծումների ֆունկցիոնալությամբ և կատարողականությամբ (և հաճախ կայունությամբ): 7.7 հարթակ.
Այսպիսով, համակարգը (և, հնարավոր է, ստանդարտ կիրառական լուծում) տեղակայվում է ձեռնարկությունում և տեղադրվում համակարգիչների վրա: Նախևառաջ անհրաժեշտ է ստեղծել այնպիսի միջավայր, որտեղ 1C անվտանգության կարգավորումը իմաստ ունի, և դրա համար այն պետք է կազմաձևվի այնպես, որ կատարվի այն ենթադրությունը, որ համակարգի անվտանգության վրա էականորեն ազդում են համակարգի կարգավորումները:
Հետևեք անվտանգության ստեղծման ընդհանուր կանոններին:
Համակարգի որևէ տեղեկատվական անվտանգության մասին խոսք լինել չի կարող, եթե ապահով համակարգեր ստեղծելու հիմնական սկզբունքները չեն պահպանվում։ Համոզվեք, որ համոզվեք, որ առնվազն հետևյալ պայմանները բավարարված են.
- Սերվերների մուտքը ֆիզիկապես սահմանափակ է, և դրանց անխափան աշխատանքը ապահովված է.
- սերվերի սարքավորումը համապատասխանում է հուսալիության պահանջներին, կարգավորվել է անսարք սերվերային սարքավորումների փոխարինումը, հատկապես կրիտիկական տարածքների համար օգտագործվում են սարքավորումների կրկնօրինակման սխեմաներ (RAID, բազմաթիվ աղբյուրներից էներգիա, բազմաթիվ կապի ուղիներ և այլն);
- սերվերները գտնվում են փակ սենյակում, և այս սենյակը բացվում է միայն աշխատանքի տևողության համար, որը հնարավոր չէ կատարել հեռակա կարգով.
- Սերվերի սենյակը բացելու իրավունք ունի միայն մեկ կամ երկու հոգի, արտակարգ իրավիճակների դեպքում մշակվել է պատասխանատու անձանց ծանուցման համակարգ;
- ապահովված է սերվերների անխափան սնուցումը
- ապահովված են սարքավորումների նորմալ կլիմայական աշխատանքային պայմանները.
- սերվերի սենյակում կա հրդեհային ազդանշան, ջրհեղեղի վտանգ չկա (հատկապես առաջին և վերջին հարկերում);
- Ձեռնարկության ցանցի և տեղեկատվական ենթակառուցվածքի կարգավորումները ճիշտ են լրացված.
- Firewall-ները տեղադրվում և կազմաձևվում են բոլոր սերվերների վրա;
- բոլոր օգտատերերը և համակարգիչները լիազորված են ցանցում, գաղտնաբառերը բավական բարդ են, որ դրանք հնարավոր չէ կռահել.
- համակարգի օպերատորները բավարար իրավունքներ ունեն դրա հետ նորմալ աշխատելու համար, բայց չունեն վարչական գործողությունների իրավունք.
- հակավիրուսային գործիքները տեղադրվում և միացված են ցանցի բոլոր համակարգիչների վրա.
- Ցանկալի է, որ օգտատերերը (բացառությամբ ցանցի ադմինիստրատորների) չունենան ադմինիստրատիվ իրավունքներ հաճախորդի աշխատանքային կայանների վրա.
- Ինտերնետի և շարժական կրիչների հասանելիությունը պետք է կարգավորվի և սահմանափակվի.
- Անվտանգության իրադարձությունների համակարգի աուդիտը պետք է կազմաձևվի.
- Լուծված են հիմնական կազմակերպչական խնդիրները.
- օգտվողները բավարար որակավորում ունեն 1C-ի և ապարատային սարքերի հետ աշխատելու համար.
- օգտվողները ծանուցվում են շահագործման կանոնները խախտելու պատասխանատվության մասին.
- տեղեկատվական համակարգի յուրաքանչյուր նյութական տարրի համար նշանակվել են ֆինանսապես պատասխանատու անձինք.
- բոլոր համակարգի միավորները կնքված և փակ են.
- Հատուկ ուշադրություն դարձրեք հավաքարարներին, շինարարական աշխատողներին և էլեկտրիկներին հրահանգելու և վերահսկելուն: Այս անձինք կարող են անզգուշությամբ պատճառել վնաս, որը համեմատելի չէ համակարգի անբարեխիղճ օգտագործողի կողմից դիտավորյալ վնասի հետ:
Ուշադրություն.Այս ցանկը սպառիչ չէ, այլ միայն նկարագրում է այն, ինչը հաճախ բաց է թողնվում ցանկացած բավականին բարդ և թանկ տեղեկատվական համակարգ տեղադրելիս:
- MS SQL Server-ը, հավելվածի սերվերը և հաճախորդի մասը աշխատում են տարբեր համակարգիչների վրա, սերվերային հավելվածները գործում են հատուկ ստեղծված Windows-ի օգտատերերի իրավունքների ներքո;
- MS SQL Server-ի համար
- սահմանվել է խառը թույլտվության ռեժիմ
- MS SQL օգտվողները, որոնք ներառված են սերվերադմինիստրատորի դերում, չեն մասնակցում 1C աշխատանքին,
- յուրաքանչյուր IB 1C-ի համար ստեղծվել է առանձին MS SQL օգտվող, որը չունի արտոնյալ մուտք դեպի սերվեր,
- Մեկ IS-ի MS SQL օգտվողը մուտք չունի մյուս IS-ին.
- Օգտագործողները ուղղակի մուտք չունեն հավելվածի սերվեր և MS SQL սերվերի ֆայլեր
- Օպերատորի աշխատատեղերը հագեցած են Windows 2000/XP-ով (ոչ Windows 95/98/Me)
Մի անտեսեք համակարգի մշակողների առաջարկությունները և փաստաթղթերի ընթերցումը: Համակարգի ստեղծման վերաբերյալ կարևոր նյութերը հրապարակվում են ITS սկավառակների վրա՝ «Մեթոդական առաջարկություններ» բաժնում: Հատուկ ուշադրություն դարձրեք հետևյալ հոդվածներին.
- 1C:Enterprise սերվերի հետ աշխատող հավելվածների առանձնահատկությունները
- Տվյալների տեղադրում 1C:Enterprise 8.0
- Թարմացնել 1C:Enterprise 8.0 օգտվողների կողմից Microsoft Windowsառանց ադմինիստրատորի իրավունքների
- Օգտատերերի ցուցակի խմբագրում այն օգտատիրոջ անունից, ով չունի վարչական իրավունքներ
- Windows XP SP2 Firewall-ի կարգավորումները SQL Server 2000 և SQL Server Desktop Engine (MSDE) գործարկելու համար
- COM+ Windows XP SP2 պարամետրերի կարգավորում 1C:Enterprise 8.0 սերվերի գործարկման համար
- Windows XP SP2 firewall-ի կարգավորումների կարգավորում 1C:Enterprise 8.0 սերվերի համար
- Windows XP SP2 firewall-ի կարգավորումների կարգավորում HASP License Manager-ի համար
- Կրկնօրինակի ստեղծում տեղեկատվական բազանօգտագործելով SQL Server 2000
- Տեղադրման և կազմաձևման խնդիրներ 1C:Enterprise 8.0 «հաճախորդ-սերվեր» տարբերակում(ամենակարևոր հոդվածներից մեկը)
- Առանձնահատկություններ Windows-ի կարգավորումներՍերվեր 2003 1C:Enterprise 8.0 սերվեր տեղադրելիս
- Հաճախորդ-սերվեր տարբերակում օգտագործողների մուտքը տեղեկատվական բազայի կարգավորում(ամենակարևոր հոդվածներից մեկը)
- Սերվեր 1C: Ձեռնարկություն և SQL սերվեր
- 1C:Enterprise 8.0-ի տեղադրման մանրամասն ընթացակարգը «հաճախորդ-սերվեր» տարբերակում(ամենակարևոր հոդվածներից մեկը)
- Օգտագործելով ներկառուցված լեզուն 1C:Enterprise սերվերի վրա
Բայց փաստաթղթերը կարդալիս քննադատաբար վերաբերվեք ստացված տեղեկատվությանը, օրինակ՝ «1C. Enterprise 8.0-ի տեղադրման և կազմաձևման խնդիրները հաճախորդ-սերվերի տարբերակում» հոդվածը ճշգրիտ չի նկարագրում USER1CV8SERVER օգտվողի համար պահանջվող իրավունքները: Ստորև բերված ցանկին հղումներ կլինեն, օրինակ [ITS1] նշանակում է «1C:Enterprise սերվերի հետ աշխատող հավելվածների առանձնահատկությունները» հոդվածը: Հոդվածների բոլոր հղումները տրված են ITS-ի վերջին թողարկմանը գրելու պահին (հունվար 2006)
Օգտատերերի համար օգտագործեք թույլտվության հնարավորությունները՝ համակցված Windows-ի թույլտվության հետ
Օգտագործողի թույլտվության երկու հնարավոր ռեժիմներից՝ ներկառուցված 1C և համակցված Windows OS-ի թույլտվության հետ, եթե հնարավոր է, դուք պետք է ընտրեք համակցված թույլտվություն: Սա թույլ կտա օգտատերերին չշփոթել բազմաթիվ գաղտնաբառերի հետ աշխատելիս, սակայն չի նվազեցնի համակարգի անվտանգության մակարդակը։ Այնուամենայնիվ, նույնիսկ այն օգտատերերի համար, ովքեր օգտագործում են միայն Windows-ի թույլտվությունը, խորհուրդ է տրվում ստեղծել գաղտնաբառ այն ստեղծելիս և միայն դրանից հետո անջատել 1C թույլտվությունը այս օգտվողի համար: Active Directory կառուցվածքի ոչնչացման դեպքում համակարգի վերականգնումն ապահովելու համար անհրաժեշտ է թողնել առնվազն մեկ օգտվող, ով կարող է մուտք գործել համակարգ՝ օգտագործելով 1C թույլտվությունը:
Հավելվածի լուծման դերեր ստեղծելիս մի ավելացրեք իրավունքները «պահեստում»
Ծրագրի լուծման յուրաքանչյուր դեր պետք է արտացոլի այս դերով սահմանված գործողությունները կատարելու համար պահանջվող իրավունքների նվազագույն փաթեթը: Այնուամենայնիվ, որոշ դերեր չեն կարող օգտագործվել ինքնուրույն: Օրինակ՝ ինտերակտիվ գործարկման համար արտաքին բուժումԴուք կարող եք ստեղծել առանձին դեր և ավելացնել այն բոլոր օգտվողներին, ովքեր պետք է օգտագործեն արտաքին մշակումը:
Պարբերաբար վերանայեք տեղեկամատյանները և համակարգի գործառնական արձանագրությունները
Հնարավորության դեպքում կարգավորեք և ավտոմատացրեք տեղեկամատյանների և համակարգի գործառնական արձանագրությունների դիտումը: Պատշաճ կազմաձևման և տեղեկամատյանների կանոնավոր վերանայման դեպքում (զտում միայն ըստ կարևոր իրադարձությունների), չարտոնված գործողությունները հնարավոր է վաղ հայտնաբերել կամ նույնիսկ կանխել նախապատրաստման փուլում:
Հաճախորդ-սերվեր տարբերակի որոշ առանձնահատկություններ
Այս բաժինը նկարագրում է հաճախորդ-սերվեր տարբերակի գործառնական որոշ առանձնահատկություններ և դրանց ազդեցությունը անվտանգության վրա: Ընթերցանության ավելի հեշտության համար օգտագործվում են հետևյալ նշումները.
Ուշադրություն. խոցելիության նկարագրությունը
Տեղեկատվության պահպանում, որը վերահսկում է մուտքը համակարգ
Տեղեկատվական անվտանգության օգտագործողների ցուցակի պահպանում
Այս տեղեկատվական անվտանգության օգտագործողների ցուցակի և դրանում նրանց հասանելի դերերի մասին ամբողջ տեղեկատվությունը պահվում է MS SQL տվյալների բազայի Params աղյուսակում (տես [ITS2]): Նայելով այս աղյուսակի կառուցվածքին և բովանդակությանը, ակնհայտ է դառնում, որ օգտվողի ամբողջ տեղեկատվությունը պահվում է «users.usr» դաշտի արժեքով «FileName» գրառման մեջ:
Քանի որ մենք ենթադրում ենք, որ օգտվողները մուտք չունեն MS SQL տվյալների բազա, այս փաստն ինքնին չի կարող օգտագործվել հարձակվողի կողմից, սակայն, եթե հնարավոր է կատարել կոդը MS SQL-ում, դա «դուռ է բացում» որևէ (! ) մուտք 1C-ից: Նույն մեխանիզմը (փոքր փոփոխություններով) կարող է կիրառվել նաև համակարգի ֆայլային տարբերակում, որը, հաշվի առնելով ֆայլային տարբերակի առանձնահատկությունները, լիովին բացառում է դրա կիրառելիությունը անվտանգ համակարգեր կառուցելիս։
Առաջարկություն:Այս պահին հավելվածը նման փոփոխություններից ամբողջությամբ պաշտպանելու միջոց չկա, բացառությամբ MS SQL Server-ի մակարդակում գործարկիչների օգտագործման, ինչը, մյուս կողմից, կարող է խնդիրներ առաջացնել հարթակի տարբերակը թարմացնելու կամ ցանկը փոխելու ժամանակ։ օգտվողներ. Նման փոփոխություններին հետևելու համար կարող եք օգտագործել 1C գրանցամատյանը (ուշադրություն դարձնելով կոնֆիգուրատորի ռեժիմում «կասկածելի» մուտքերին՝ առանց օգտագործողին նշելու) կամ անընդհատ աշխատեցնել SQL Profiler-ը (որը չափազանց բացասաբար կանդրադառնա համակարգի աշխատանքի վրա) կամ կարգավորել «Alerts»-ը։ մեխանիզմ (ամենայն հավանականությամբ միասին՝ օգտագործելով ձգաններ)Սերվերում IS ցուցակի մասին տեղեկատվության պահպանում
Յուրաքանչյուր 1C հավելվածի սերվերի համար տեղեկատվությունը պահվում է դրան միացված MS SQL տվյալների բազաների ցանկի մասին: Յուրաքանչյուր տեղեկատվական բազա օգտագործում է իր կապի տողը հավելվածի սերվերից և MS SQL սերվերից գործելու համար: Հավելվածի սերվերում գրանցված տեղեկատվական բազաների մասին տեղեկատվությունը միացման տողերի հետ միասին պահվում է srvrib.lst ֆայլում, որը գտնվում է գրացուցակի սերվերի վրա:<Общие данные приложений>/1C/1Cv8 (օրինակ՝ C:/Documents and Settings/All Users/Application Data/1C/1Cv8/srvrib.lst): Տեղեկատվական անվտանգության յուրաքանչյուր համակարգի համար պահվում է միացման ամբողջական տողը, ներառյալ MS SQL օգտվողի գաղտնաբառը, երբ օգտագործում եք խառը MS SQL թույլտվության մոդել: Այս ֆայլի առկայությունն է, որը հնարավորություն է տալիս վախենալ MS SQL տվյալների բազա չարտոնված մուտքից, և եթե, ի տարբերություն առաջարկությունների, արտոնյալ օգտվող (օրինակ, «sa») օգտագործվում է առնվազն մեկ տվյալների բազա մուտք գործելու համար, ապա Բացի մեկ տեղեկատվական անվտանգության սպառնալիքից, վտանգ կա MS SQL օգտագործող ամբողջ համակարգի համար:
Հետաքրքիր է նշել, որ MS SQL սերվերի վրա խառը թույլտվության և Windows-ի թույլտվության օգտագործումը հանգեցնում է տարբեր տեսակի խնդիրների՝ տվյալ ֆայլ մուտք գործելու ժամանակ: Այսպիսով, Windows-ի թույլտվության հիմնական բացասական հատկությունները կլինեն.
- Ամբողջ տեղեկատվական անվտանգության գործարկումը հավելվածի սերվերի և MS SQL սերվերի վրա մեկ իրավունքների փաթեթի ներքո (ամենայն հավանականությամբ ավելորդ)
- 1C հավելվածի սերվերի գործընթացից (կամ ընդհանրապես USER1CV8SERVER օգտվողից կամ դրա համարժեքից) առանց գաղտնաբառ նշելու, դուք կարող եք հեշտությամբ միանալ ցանկացած տեղեկատվական անվտանգության՝ առանց գաղտնաբառ նշելու:
Մյուս կողմից, հարձակվողի համար կարող է ավելի դժվար լինել USER1CV8SERVER օգտվողի կոնտեքստից կամայական կոդ գործարկելը, քան նշված ֆայլը ստանալը: Ի դեպ, նման ֆայլի առկայությունը ևս մեկ փաստարկ է տարբեր համակարգիչների վրա սերվերի գործառույթների բաշխման համար։
Առաջարկություն: Srvrib.lst ֆայլը պետք է հասանելի լինի միայն սերվերի գործընթացով: Համոզվեք, որ կարգավորեք աուդիտը այս ֆայլը փոխելու համար:Ցավոք, լռելյայն այս ֆայլըգրեթե պաշտպանված չէ կարդալուց, ինչը պետք է հաշվի առնել համակարգը տեղակայելիս: Իդեալական տարբերակն այն կլիներ, որ հավելվածի սերվերը թույլ չտա այս ֆայլի ընթերցումն ու գրելը գործարկման ընթացքում (ներառյալ այս սերվերի վրա աշխատող օգտվողի կապերի ընթերցումն ու գրելը):
Սերվերի վրա տեղեկատվական անվտանգություն ստեղծելիս թույլտվության բացակայություն
Ուշադրություն. Թույլտվության բացակայությունը շտկվել է 1C:Enterprise հարթակի 8.0.14 թողարկումում: Այս թողարկումում հայտնվեց «1C:Enterprise Server Administrator» հասկացությունը, բայց քանի դեռ սերվերում նշված է ադմինիստրատորների ցանկը, համակարգը գործում է այնպես, ինչպես նկարագրված է ստորև, այնպես որ մի մոռացեք այս հնարավոր գործառույթի մասին:
Հավանաբար այս բաժնի ամենամեծ խոցելիությունը հավելվածի սերվերին տեղեկատվական անվտանգությունը գրեթե անսահմանափակ ավելացնելու հնարավորությունն է, ինչի արդյունքում ցանկացած օգտվող, ով մուտք է ստանում հավելվածի սերվերի հետ կապ, ավտոմատ կերպով ստանում է կամայական կոդ գործարկելու հնարավորություն հավելվածի սերվերի վրա: . Սրան նայենք օրինակով։
Համակարգը պետք է տեղադրվի հետևյալ կերպ
- MS SQL Server 2000 (օրինակ, ցանցի անունը SRV1)
- Սերվեր 1C:Enterprise 8.0 (ցանցի անունը SRV2)
- Հաճախորդի մաս 1C:Enterprise 8.0 (ցանցի անունը WS)
Ենթադրվում է, որ WS-ում աշխատող օգտատերը (այսուհետ՝ USER) ունի առնվազն նվազագույն մուտք դեպի SRV2-ում գրանցված տեղեկատվական անվտանգության համակարգերից մեկը, բայց չունի արտոնյալ մուտք դեպի SRV1 և SRV2: Ընդհանուր առմամբ, թվարկված համակարգիչների գործառույթների համակցությունը չի ազդում իրավիճակի վրա։ Համակարգը կազմաձևվել է՝ հաշվի առնելով փաստաթղթերում և ITS սկավառակների վերաբերյալ առաջարկությունները: Իրավիճակը ցույց է տրված Նկ. 2.
- կարգավորել COM+ անվտանգությունը հավելվածի սերվերի վրա, որպեսզի միայն 1C օգտագործողները իրավունք ունենան միանալ հավելվածի սերվերի գործընթացին (ավելի մանրամասն [ITS12]);
- srvrib.lst ֆայլը պետք է լինի միայն կարդալու USER1CV8SERVER օգտվողի համար (սերվերին նոր տեղեկատվական անվտանգություն ավելացնելու համար ժամանակավորապես թույլատրեք գրել);
- MS SQL-ին միանալու համար օգտագործեք միայն TCP/IP արձանագրությունը, այս դեպքում կարող եք.
- սահմանափակել կապերը՝ օգտագործելով firewall;
- կարգավորել ոչ ստանդարտ TCP պորտի օգտագործումը, որը կբարդացնի «օտարների» IB 1C կապը.
- օգտագործել փոխանցված տվյալների կոդավորումը հավելվածի սերվերի և SQL սերվերի միջև.
- կարգավորել սերվերի firewall-ը այնպես, որ անհնար լինի երրորդ կողմի MS SQL սերվերների օգտագործումը.
- օգտագործել ներցանցային անվտանգության գործիքներ՝ բացառելու տեղական ցանցում չարտոնված համակարգչի հայտնվելու հնարավորությունը (IPSec, խմբի անվտանգության քաղաքականություն, firewalls և այլն);
- Ոչ մի դեպքում մի տրամադրեք օգտվողին USER1CV8SERVER վարչական իրավունքներ հավելվածի սերվերի վրա:
Սերվերի վրա աշխատող կոդ օգտագործելով
1C-ի հաճախորդ-սերվեր տարբերակն օգտագործելիս ծրագրավորողը կարող է բաշխել կոդերի կատարումը հաճախորդի և հավելվածի սերվերի միջև: Որպեսզի կոդը (ընթացակարգը կամ գործառույթը) կատարվի միայն սերվերի վրա, անհրաժեշտ է այն տեղադրել ընդհանուր մոդուլում, որի համար սահմանված է «Server» հատկությունը, և այն դեպքում, երբ մոդուլի կատարումը թույլատրվում է ոչ միայն. սերվերը, տեղադրեք կոդը «#If Server» սահմանափակ բաժնում.
#If Server then
Գործառույթ OnServer(Param1, Param2 = 0) Export // Այս ֆունկցիան, չնայած իր պարզությանը, իրականացվում է սերվերի վրա
Param1 = Param1 + 12;
Վերադարձի Param1;
EndFunction
#ՎերջԵթե
Սերվերի վրա աշխատող կոդ օգտագործելիս պետք է հաշվի առնել, որ.
- կոդը աշխատում է USER1CV8SERVER իրավունքներով հավելվածի սերվերի վրա (COM օբյեկտները և սերվերի ֆայլերը հասանելի են);
- օգտատերերի բոլոր նիստերն իրականացվում են ծառայության մեկ օրինակով, այնպես որ, օրինակ, սերվերի վրա կուտակիչի արտահոսքը կհանգեցնի բոլոր ակտիվ օգտվողների անջատմանը.
- Սերվերի մոդուլների վրիպազերծումը դժվար է (օրինակ, դուք չեք կարող վրիպազերծիչում բեկման կետ սահմանել), բայց պետք է արվի.
- Հաճախորդից հսկողությունը հավելվածի սերվեր և հետ փոխանցելը կարող է պահանջել զգալի ռեսուրսներ՝ փոխանցված պարամետրերի մեծ ծավալով.
- ինտերակտիվ գործիքների օգտագործում (ձևեր, աղյուսակային փաստաթղթեր, երկխոսության տուփեր), արտաքին հաշվետվությունները և կոդով մշակումը հավելվածի սերվերում անհնար է.
- գլոբալ փոփոխականների օգտագործումը (կիրառական մոդուլի փոփոխականներ, որոնք հայտարարված են «Արտահանում» նշումով) չի թույլատրվում.
Լրացուցիչ մանրամասների համար տե՛ս [ITS15] և այլ ITS հոդվածներ:
Հավելվածի սերվերը պետք է ունենա հատուկ հուսալիության պահանջներ: Պատշաճ կերպով կառուցված հաճախորդ-սերվեր համակարգում պետք է պահպանվեն հետևյալ պայմանները.
- Հաճախորդի հավելվածի ոչ մի գործողություն չպետք է ընդհատի սերվերի աշխատանքը (բացառությամբ վարչական դեպքերի).
- սերվերը չի կարող կատարել հաճախորդից ստացված ծրագրի կոդը.
- ռեսուրսները պետք է «արդարացիորեն» բաշխվեն հաճախորդների կապեր, ապահովելով սերվերի հասանելիությունը՝ անկախ ընթացիկ ծանրաբեռնվածությունից;
- տվյալների արգելափակման բացակայության դեպքում հաճախորդի կապերը չպետք է ազդեն միմյանց աշխատանքի վրա.
- ոչ սերվերի վրա օգտագործողի ինտերֆեյս, բայց պետք է մշակվեն մոնիտորինգի և անտառահատումների գործիքներ.
Ընդհանուր առմամբ, 1C համակարգը կառուցված է այնպես, որ մոտենա այս պահանջներին (օրինակ, անհնար է ստիպել արտաքին մշակումը կատարել սերվերի վրա), բայց մի քանի տհաճ առանձնահատկություններ դեռ կան, հետևաբար.
Առաջարկություն: Runtime սերվեր մշակելիս խորհուրդ է տրվում պահպանել նվազագույն ինտերֆեյսի սկզբունքը: Նրանք. Հաճախորդի հավելվածից սերվերի մոդուլների մուտքերի քանակը պետք է շատ սահմանափակ լինի, իսկ պարամետրերը պետք է խստորեն կարգավորվեն: Առաջարկություն:Սերվերի վրա պրոցեդուրաների և գործառույթների պարամետրեր ստանալիս անհրաժեշտ է վավերացնել պարամետրերը (ստուգեք, որ պարամետրերը համապատասխանում են սպասվող տեսակին և արժեքների միջակայքին): Սա չի արվում ստանդարտ լուծումներում, սակայն շատ ցանկալի է պարտադիր վավերացում մտցնել սեփական մշակումների մեջ: Առաջարկություն:Հարցման տեքստը (և հատկապես Run հրամանի պարամետրը) սերվերի կողմից ստեղծելիս մի օգտագործեք հաճախորդի հավելվածից ստացված տողերը:Ընդհանուր առաջարկություն կլինի ծանոթանալ անվտանգ կառուցելու սկզբունքներին վեբ-Տվյալների բազայի հավելվածներ և աշխատել նմանատիպ սկզբունքներով: Նմանություններն իսկապես զգալի են. նախ, ինչպես վեբ հավելվածը, հավելվածի սերվերը միջանկյալ շերտ է տվյալների բազայի և օգտատիրոջ միջերեսի միջև (հիմնական տարբերությունն այն է, որ վեբ սերվերը կազմում է օգտագործողի միջերեսը); երկրորդ, անվտանգության տեսանկյունից դուք չեք կարող վստահել հաճախորդից ստացված տվյալներին, քանի որ հնարավոր է գործարկել արտաքին հաշվետվություններ և մշակում։
Անցումային պարամետրեր
Պարամետրերի փոխանցումը սերվերում կատարված գործառույթին (ընթացակարգին) բավականին նուրբ խնդիր է։ Սա առաջին հերթին պայմանավորված է դրանք հավելվածի սերվերի և հաճախորդի գործընթացների միջև փոխանցելու անհրաժեշտությամբ: Երբ հսկողությունը հաճախորդի կողմից անցնում է սերվերի կողմ, փոխանցված բոլոր պարամետրերը սերիականացվում են, փոխանցվում սերվերին, որտեղ դրանք «բացվում» և օգտագործվում են: Սերվերի կողմից հաճախորդի կողմ տեղափոխելիս գործընթացը հակադարձվում է: Այստեղ պետք է նշել, որ այս սխեման ճիշտ է մշակում անցնող պարամետրերը ըստ հղումների և արժեքների: Պարամետրերը փոխանցելիս կիրառվում են հետևյալ սահմանափակումները.
- Հաճախորդի և սերվերի միջև (երկու ուղղություններով) կարող են փոխանցվել միայն անփոփոխ արժեքներ (այսինքն, որոնց արժեքները չեն կարող փոխվել)՝ պարզունակ տեսակներ, հղումներ, համընդհանուր հավաքածուներ, համակարգի թվարկման արժեքներ, արժեքների պահպանում: Եթե դուք փորձում եք փոխանցել այլ բան, հաճախորդի հավելվածը խափանում է (նույնիսկ եթե սերվերը փորձում է փոխանցել սխալ պարամետր):
- Պարամետրեր փոխանցելիս խորհուրդ չի տրվում փոխանցել մեծ քանակությամբ տվյալներ (օրինակ՝ ավելի քան 1 միլիոն նիշ ունեցող տողեր), դա կարող է բացասաբար ազդել սերվերի աշխատանքի վրա:
- Դուք չեք կարող փոխանցել ցիկլային հղում պարունակող պարամետրեր, ինչպես սերվերից, այնպես էլ հաճախորդին և հակառակը: Եթե դուք փորձում եք փոխանցել նման պարամետր, հաճախորդի հավելվածը խափանում է (նույնիսկ եթե սերվերը փորձում է փոխանցել սխալ պարամետրը):
- Խորհուրդ չի տրվում փոխանցել շատ բարդ տվյալների հավաքածուներ: Երբ փորձում եք փոխանցել մի պարամետր շատ մեծ բույնի մակարդակով, սերվերը խափանում է (! ):
Ուշադրություն. Այս պահին ամենաանհանգստացնող հատկանիշը հավանաբար արժեքների բարդ հավաքածուներ փոխանցելու սխալն է: Այսպիսով, օրինակ, կոդը՝ Nesting Level = 1250;
M = Նոր զանգված;
Անցած Պարամետր = M;
Հաշվի համար = 1 ըստ բնադրման ցիկլի մակարդակի
MVInt = Նոր զանգված;
M.Add (MVInt);
M = MVint;
End Cycle;
ServerFunction (PassedParameter);
Հանգեցնում է սերվերի վթարային կանգառին՝ բոլոր օգտատերերի անջատմամբ, և դա տեղի է ունենում նախքան կառավարումը ներկառուցված լեզվով կոդին փոխանցելը:
Օգտագործելով ոչ անվտանգ գործառույթներ սերվերի կողմից:
Ոչ բոլոր ներկառուցված լեզվական գործիքները կարող են օգտագործվել հավելվածի սերվերի վրա գործարկվող կոդում, բայց նույնիսկ առկա գործիքների թվում կան բազմաթիվ «խնդրահարույց» կառուցվածքներ, որոնք կարելի է մոտավորապես դասակարգել հետևյալ կերպ.
- ի վիճակի է ապահովել կոնֆիգուրացիայի մեջ չպարունակվող ծածկագիրը («Code Execution» խումբ)
- ի վիճակի է հաճախորդի հավելվածին տրամադրել տեղեկատվություն ֆայլի և օպերացիոն համակարգօգտվող կամ կատարել գործողություններ, որոնք կապված չեն տվյալների հետ աշխատելու հետ («Իրավունքների խախտում»)
- կարող է առաջացնել սերվերի խափանում կամ օգտագործել շատ մեծ ռեսուրսներ («Սերվերի խափանում» խումբ)
- կարող է առաջացնել հաճախորդի ձախողում (հաճախորդի ձախողման խումբ) – այս տեսակը հաշվի չի առնվում: Օրինակ՝ փոփոխվող արժեք փոխանցելը սերվերին:
- ծրագրավորման ալգորիթմների սխալներ (անվերջ օղակներ, անսահմանափակ ռեկուրսիա և այլն) («Ծրագրավորման սխալներ»)
Ինձ հայտնի հիմնական խնդրահարույց նախագծերը (օրինակներով) թվարկված են ստորև.
Ընթացակարգի կատարում (<Строка>)
Կոդը գործարկվում է:Թույլ է տալիս կատարել կոդի մի հատված, որը փոխանցվում է նրան որպես տողային արժեք: Երբ օգտագործվում է սերվերում, դուք պետք է համոզվեք, որ հաճախորդից ստացված տվյալները չեն օգտագործվում որպես պարամետր: Օրինակ, հետևյալ օգտագործումը չի թույլատրվում.
#If Server then
ProcedureOnServer (Param1) Արտահանում
Կատարել (Param1);
Ընթացակարգի ավարտը
#ՎերջԵթե
Մուտքագրեք «COMObject» (կոնստրուկտոր Նոր COMObject(<Имя>, <Имя сервера>))
Ստեղծում է արտաքին հավելվածի COM օբյեկտ՝ USER1CV8SERVER իրավունքներով հավելվածի սերվերի (կամ այլ նշված համակարգչի վրա): Երբ օգտագործվում է սերվերի վրա, համոզվեք, որ պարամետրերը չեն փոխանցվում հաճախորդի հավելվածից: Այնուամենայնիվ, սերվերի կողմից արդյունավետ է օգտագործել այս հնարավորությունը ներմուծման/արտահանման, ինտերնետով տվյալներ ուղարկելու, ոչ ստանդարտ գործառույթներ իրականացնելիս և այլն:
GetCOMObject ֆունկցիա (<Имя файла>, <Имя класса COM>)
Իրավունքների խախտում և կոդի կատարում։Նախորդին նման՝ ստանալով միայն ֆայլին համապատասխանող COM օբյեկտը։
Ընթացակարգեր և գործառույթներ ComputerName(), TemporaryFileDirectory(), ProgramDirectory(), WindowsUsers()
Իրավունքների խախտում.Դրանք կատարելով սերվերի վրա՝ թույլ են տալիս պարզել սերվերի ենթահամակարգի կազմակերպման մանրամասները։ Երբ օգտագործվում է սերվերի վրա, համոզվեք, որ տվյալները կամ չեն փոխանցվում հաճախորդին, կամ հասանելի չեն օպերատորներին առանց համապատասխան թույլտվության: Հատուկ ուշադրություն դարձրեք այն փաստին, որ տվյալները կարող են հետ փոխանցվել հղումով փոխանցված պարամետրով:
Ֆայլերի հետ աշխատելու ընթացակարգեր և գործառույթներ (CopyFile, FindFiles, MergeFiles և շատ ուրիշներ), ինչպես նաև Ֆայլերի տեսակները:
Իրավունքների խախտում.Դրանք թույլ են տալիս դրանք սերվերի վրա գործարկելով ընդհանուր հասանելիություն ստանալ տեղական (և ցանցում տեղակայված) ֆայլերին, որոնք հասանելի են USER1CV8SERVER օգտվողի իրավունքների ներքո: Եթե օգտագործվում է գիտակցաբար, ապա հնարավոր է արդյունավետ կերպով իրականացնել այնպիսի առաջադրանքներ, ինչպիսիք են սերվերի վրա տվյալների ներմուծումը/արտահանումը:
Նախքան այս գործառույթներն օգտագործելը, համոզվեք, որ ստուգեք ձեր 1C օգտատիրոջ իրավունքները: Օգտագործողի իրավունքները ստուգելու համար սերվերի մոդուլում կարող եք օգտագործել հետևյալ կառուցվածքը.
#If Server then
Ընթացակարգ PerformWorkWithFile() Export
RoleAdministrator = Metadata.Roles.Administrator;
User = SessionParameters.CurrentUser;
If User.Roles.Contains(RoleAdministrator) Ապա
//Այստեղ կատարվում է ֆայլերի հետ աշխատելու կոդը
վերջԵթե;
#ՎերջԵթեՀամոզվեք, որ ստուգեք պարամետրերը, եթե օգտագործում եք այս ընթացակարգերն ու գործառույթները, հակառակ դեպքում կա 1C հավելվածի սերվերին պատահաբար կամ գիտակցաբար անուղղելի վնաս պատճառելու վտանգ, օրինակ՝ սերվերում հետևյալ ծածկագիրը կատարելիս.
Ճանապարհ = "C:\Documents and Settings\All Users\Application Data\1C\1Cv8\";
MoveFile(Path + "srvrib.lst", Path + "Here'sWhereTheFileGoes");Սերվերում նման կոդը գործարկելուց հետո, եթե USER1CV8SERVER օգտվողը իրավունք ունի փոխելու այն, ինչպես նկարագրված է վերևում, և սերվերի գործընթացը վերագործարկելուց հետո (լռելյայն, բոլոր օգտվողների դուրս գալուց 3 րոպե հետո), ՄԵԾ հարց կառաջանա սերվերը գործարկելու վերաբերյալ: . Բայց հնարավոր է նաև ամբողջությամբ ջնջել ֆայլերը...
Տեսակները «XBase», «BinaryData», «XML Reader», «XML Writer», «XSL Transformation», «ZipFile Writer», «ZipFile Reader», «Text Reader», «Text Writer»
Իրավունքների խախտում.Դրանք թույլ են տալիս դրանք սերվերի վրա կատարելով մուտք գործել որոշակի տեսակի տեղական (և ցանցում տեղակայված) ֆայլեր և կարդալ/գրել դրանք USER1CV8SERVER օգտվողի իրավունքների ներքո: Գիտակցված օգտագործման դեպքում հնարավոր է արդյունավետորեն իրականացնել այնպիսի առաջադրանքներ, ինչպիսիք են սերվերի վրա տվյալների ներմուծումը/արտահանումը, որոշակի գործառույթների հաշվառումը և վարչական խնդիրների լուծումը: Ընդհանուր առմամբ, առաջարկությունները համընկնում են նախորդ պարբերության հետ, բայց դուք պետք է հաշվի առնեք այս ֆայլերից (բայց ոչ այս բոլոր տեսակների օբյեկտներից) տվյալների փոխանցման հնարավորությունը հաճախորդի և սերվերի մասերի միջև:
Մուտքագրեք «Համակարգային տեղեկատվություն»
Իրավունքների խախտում.Թույլ է տալիս ստանալ տվյալներ հավելվածի սերվերի մասին սխալ օգտագործման և տվյալների փոխանցման դեպքում հավելվածի հաճախորդի մաս: Օգտագործելիս նպատակահարմար է սահմանափակել օգտագործման իրավունքը։
Տեսակները «InternetConnection», «InternetMail», «InternetProxy», «HTTPConnection», «FTPConnection»
Իրավունքների խախտում.Երբ օգտագործվում է սերվերի վրա, այն միանում է հեռավոր համակարգչին կիրառական սերվերից՝ USER1CV8SERVER իրավունքների ներքո: Առաջարկություններ.
- Մեթոդներ կանչելիս պարամետրերի վերահսկում:
- 1C օգտագործողի իրավունքների վերահսկում:
- Խիստ սահմանափակումներ USER1CV8SERVER օգտվողի՝ ցանց մուտք գործելու իրավունքների նկատմամբ:
- 1C հավելվածի սերվերի վրա firewall-ի ճիշտ կարգավորում:
Երբ ճիշտ օգտագործվում է, հարմար է կազմակերպել, օրինակ, նամակներ ուղարկել հավելվածի սերվերից:
Տեսակները «InformationBaseUserManager», «InformationBaseUser»
Իրավունքների խախտում.Սխալ օգտագործման դեպքում (արտոնյալ մոդուլում), հնարավոր է ավելացնել օգտվողներ կամ փոխել առկա օգտագործողների թույլտվության պարամետրերը:
Ֆունկցիայի ձևաչափ
Սերվերի խափանում.Այո՛։ Այս անվնաս թվացող ֆունկցիան, եթե դրա պարամետրերը չեն վերահսկվում և չեն գործում սերվերում, կարող է առաջացնել սերվերի հավելվածի խափանում: Սխալը տեղի է ունենում թվերի ձևաչափման և հիմնական զրոների և մեծ թվով նիշերի ցուցադրման ռեժիմի օգտագործման ժամանակ, օրինակ.
Ձևաչափ (1, «CHZ=999; CHVN=»);
Հուսով եմ, որ այս սխալը կուղղվի հարթակի հաջորդ թողարկումներում, բայց միևնույն ժամանակ, այս ֆունկցիայի բոլոր զանգերում, որոնք կարող են իրականացվել սերվերի վրա, ստուգեք զանգի պարամետրերը:
Արժեքների պահպանման ընթացակարգեր և գործառույթներ (ValueInRowInt, ValueInFile)
Սերվերի խափանում.Այս գործառույթները չեն կարգավորում շրջանաձև հղումները հավաքածուներում կամ շատ խորը բույնում, ուստի դրանք կարող են խափանվել որոշ շատ հատուկ դեպքերում:
Ֆունկցիաներում սահմանային և հատուկ պարամետրերի արժեքների սխալներ: Կատարման հսկողություն.
Խնդիրներից մեկը, որը կարող եք հանդիպել սերվեր օգտագործելիս, սերվերի գործառույթների բարձր «պատասխանատվությունն» է (ամբողջ սերվերի հավելվածի խափանման հնարավորությունը մեկ կապի սխալի պատճառով և բոլոր կապերի համար մեկ «ռեսուրսային տարածքի» օգտագործումը): . Հետևաբար, գործարկման ժամանակի հիմնական պարամետրերը վերահսկելու անհրաժեշտություն կա.
- Ներկառուցված լեզվական գործառույթների համար ստուգեք դրանց գործարկման պարամետրերը (լավ օրինակ է «Format» գործառույթը)
- Օղակներ օգտագործելիս համոզվեք, որ օղակի ելքի պայմանը բավարարված է: Եթե օղակը պոտենցիալ անսահման է, արհեստականորեն սահմանափակեք կրկնությունների քանակը. MaximumIterationCounterValue = 1000000;
Կրկնման հաշվիչ = 1;
Ցտեսություն
FunctionWhichMayNotReturnFalseValue()
ԵՎ (Iteration Count<МаксимальноеЗначениеСчетчикаИтераций) Цикл//.... Օղակի մարմին
Iteration Counter = Iteration Counter + 1;
End Cycle;
If Iteration Counter>Maximum Value Of Iteration Counter then
//.... կարգավորել չափազանց երկար օղակի կատարման իրադարձությունը
վերջԵթե; - Ռեկուրսիա օգտագործելիս սահմանափակեք բնադրման առավելագույն մակարդակը:
- Հարցումներ ձևավորելիս և կատարելիս փորձեք կանխել մեծ քանակությամբ տեղեկատվության շատ երկար ընտրությունը և ընտրությունը (օրինակ, «ՀԻԵՐԱՐԽԻԱՅՈՒՄ» պայմանն օգտագործելիս մի օգտագործեք դատարկ արժեք)
- Տեղեկատվական բազա նախագծելիս տրամադրեք թվերի համար բիթային խորության բավական մեծ պաշար (հակառակ դեպքում գումարումը և բազմապատկումը դառնում են ոչ փոխադարձ և ոչ ասոցիատիվ, ինչը դժվարացնում է վրիպազերծումը)
- Գործարկվող հարցումներում ստուգեք գործողության տրամաբանությունը NULL արժեքների առկայության և հարցման պայմանների և արտահայտությունների ճիշտ աշխատանքի համար՝ օգտագործելով NULL:
- Հավաքածուներ օգտագործելիս վերահսկեք դրանք հավելվածի սերվերի և հաճախորդի կողմից փոխանցելու հնարավորությունը:
Օգտագործելով տերմինալային մուտք դեպի հաճախորդի կողմ՝ մուտքը սահմանափակելու համար
Դուք հաճախ կարող եք առաջարկություններ գտնել տերմինալի հասանելիությունն օգտագործելու համար՝ տվյալների հասանելիությունը սահմանափակելու և կատարողականությունը բարելավելու համար՝ տերմինալային սերվերում հաճախորդի կողմից կոդ գործարկելու միջոցով: Այո, եթե ճիշտ կազմաձևված է, տերմինալի մուտքի օգտագործումը իսկապես կարող է բարձրացնել համակարգի անվտանգության ընդհանուր մակարդակը, բայց, ցավոք, հաճախ կարող եք հանդիպել այն փաստի, որ գործնական օգտագործման դեպքում համակարգի անվտանգությունը միայն նվազում է: Փորձենք պարզել, թե ինչի հետ է սա կապված։ Այժմ տերմինալների հասանելիությունը կազմակերպելու երկու ընդհանուր միջոց կա, դրանք են՝ Microsoft Terminal Services (RDP արձանագրություն) և Citrix Metaframe Server (ICA արձանագրություն): Ընդհանուր առմամբ, Citrix գործիքներն ապահովում են մուտքի շատ ավելի ճկուն կառավարման տարբերակներ, սակայն այս լուծումների գինը շատ ավելի բարձր է: Մենք կքննարկենք միայն այն հիմնական հատկանիշները, որոնք ընդհանուր են երկու արձանագրությունների համար, որոնք կարող են նվազեցնել անվտանգության ընդհանուր մակարդակը: Տերմինալ մուտք գործելու ժամանակ կա միայն երեք հիմնական վտանգ.- Այլ օգտատերերի աշխատանքը արգելափակելու ունակություն՝ չափազանց մեծ քանակությամբ ռեսուրսներ գրավելով
- Մուտք դեպի այլ օգտվողների տվյալները:
- Տերմինալային սերվերից օգտվողի համակարգչին տվյալների չարտոնված պատճենում
Ամեն դեպքում, Terminal Services-ը թույլ է տալիս.
- Բարձրացնել աշխատանքի հուսալիությունը (եթե տերմինալային համակարգչի վրա խափանում կա, օգտագործողը կարող է հետագայում շարունակել աշխատել նույն վայրից)
- Սահմանափակել մուտքը դեպի հաճախորդի հավելված և այն պահվող ֆայլերը:
- Տեղափոխեք հաշվողական բեռը օգտագործողի աշխատակայանից դեպի տերմինալ մուտքի սերվեր
- Կառավարեք համակարգի կարգավորումները ավելի կենտրոնացված կերպով: Օգտատերերի համար պահպանված կարգավորումները վավեր կլինեն՝ անկախ նրանից, թե որ համակարգչից են նրանք մուտք գործել համակարգ:
- Որոշ դեպքերում դուք կարող եք օգտագործել տերմինալային լուծում՝ համակարգին հեռավոր մուտք գործելու համար:
Անհրաժեշտ է սահմանափակել տերմինալային սերվերին հնարավոր միացումների քանակը մեկ օգտագործողի համար
1C հաճախորդի հավելվածի ռեսուրսների վերաբերյալ «շատակերության» պատճառով հրամայական է սահմանափակել մեկ օգտագործողի (օպերատորի) միաժամանակյա միացումների առավելագույն քանակը տերմինալային սերվերին: Ակտիվորեն օգտագործվող կապը կարող է օգտագործել մինչև 300 ՄԲ հիշողություն հավելվածի միայն մեկ օրինակով: Բացի հիշողությունից, ակտիվորեն օգտագործվում է պրոցեսորի ժամանակը, ինչը նույնպես չի նպաստում այս սերվերի օգտագործողների կայունությանը։ Միևնույն ժամանակ, ինչպես կանխում է սերվերի ռեսուրսների ավելորդ օգտագործումը, նման սահմանափակումը կարող է կանխել ուրիշի օգտագործումը. հաշիվ. Իրականացվում է ստանդարտ տերմինալային սերվերի կարգավորումներով:
Դուք չպետք է թույլ տաք, որ մեկ կամ երկու 1C հաճախորդի հավելվածներ միաժամանակ աշխատեն մեկ կապով
Թելադրված է նույն պատճառներով, ինչ նախորդ պարբերությունում, բայց տեխնիկապես ավելի դժվար է իրականացնել: Խնդիրն այն է, որ գրեթե անհնար է կանխել 1C-ի վերագործարկումը՝ օգտագործելով տերմինալային սերվերի գործիքները (ինչու կբացատրվի ստորև), այնպես որ դուք պետք է կիրառեք այս հատկությունը հավելվածի լուծման մակարդակում (ինչը նույնպես լավ լուծում չէ, քանի որ. նիստերը կարող են որոշ ժամանակ մնալ «կախված» Եթե հավելվածը սխալ է դադարեցվել, անհրաժեշտություն է առաջանում կատարելագործել հավելվածի լուծումը հավելվածի մոդուլում և որոշ տեղեկատու գրքերում, ինչը կբարդացնի 1C-ից թարմացումների օգտագործումը): Ցանկալի է օգտատիրոջը թողնել 2 հավելված գործարկելու հնարավորությունը, որպեսզի կարողանանք կատարել որոշ գործողություններ (օրինակ՝ հաշվետվություններ ստեղծելը) հետին պլանում. հաճախորդի հավելվածը, ցավոք, իրականում մեկ թելային է:
Խորհուրդ չի տրվում տերմինալային սերվերի մուտքի իրավունքներ տալ այն օգտվողներին, ովքեր իրավունք ունեն կատարել ռեսուրսների ինտենսիվ հաշվողական առաջադրանքներ 1C-ում կամ կանխել այդպիսի գործարկումը, մինչ այլ օգտվողներ ակտիվորեն աշխատում են:
Իհարկե, ավելի լավ է տերմինալային սերվերի մուտքը թողնել միայն այն օգտվողներին, ովքեր չեն օգտագործում այնպիսի առաջադրանքներ, ինչպիսիք են տվյալների արդյունահանումը, աշխարհագրական դիագրամները, ներմուծումը/արտահանումը և այլ առաջադրանքներ, որոնք լրջորեն բեռնում են հավելվածի հաճախորդի մասը: Եթե դեռ անհրաժեշտություն կա թույլ տալ նման առաջադրանքները, ապա անհրաժեշտ է. տեղեկացնել օգտվողին, որ այդ առաջադրանքները կարող են ազդել այլ օգտվողների կատարողականի վրա, գրանցել նման գործընթացի սկիզբը և ավարտը գրանցամատյանում, թույլատրել կատարումը միայն կարգավորվող ռեժիմով: ժամանակ և այլն:
Պետք է համոզվել, որ յուրաքանչյուր օգտատեր գրելու իրավունք ունի միայն տերմինալային սերվերի վրա խստորեն սահմանված դիրեկտորիաների նկատմամբ, և որ մյուս օգտվողները մուտք չունենան դրանք:
Նախ, եթե դուք չեք սահմանափակում ընդհանուր դիրեկտորիաներում գրելու հնարավորությունը (օրինակ, գրացուցակը, որտեղ տեղադրված է 1C), ապա հարձակվողի համար հնարավոր կլինի փոխել ծրագրի վարքագիծը բոլոր օգտագործողների համար: Երկրորդ, մեկ օգտագործողի տվյալները (ժամանակավոր ֆայլեր, հաշվետվության կարգավորումները պահելու ֆայլեր և այլն) ոչ մի դեպքում չպետք է հասանելի լինեն տերմինալային սերվերի մեկ այլ օգտագործողի համար. ընդհանուր առմամբ, նորմալ կազմաձևման ժամանակ պահպանվում է այս կանոնը: Երրորդ, հարձակվողը դեռևս հնարավորություն ունի «աղբեցնել» միջնորմը, որպեսզի կոշտ սկավառակի վրա տեղ չմնա: Ես գիտեմ, որ նրանք կառարկեն ինձ, որ Windows օպերացիոն համակարգը, սկսած Windows 2000-ից, ունի քվոտայի մեխանիզմ, բայց սա բավականին թանկ մեխանիզմ է, և ես գործնականում երբեք չեմ տեսել դրա իրական օգտագործումը:
Եթե մուտքի ստեղծման նախորդ խնդիրները ընդհանուր առմամբ բավականին հեշտ էին իրականացնել, ապա այնպիսի (թվացյալ) պարզ խնդիր, ինչպիսին է օգտատերերի մուտքը ֆայլեր կարգավորելը, աննշանորեն չի իրականացվում: Նախ, եթե քվոտայի մեխանիզմը չի օգտագործվում, ապա մեծ ֆայլերը կարող են պահպանվել: Երկրորդ, համակարգը կառուցված է այնպես, որ գրեթե միշտ հնարավոր կլինի պահպանել ֆայլը, որպեսզի այն հասանելի լինի մեկ այլ օգտագործողի համար:
Հաշվի առնելով, որ առաջադրանքը դժվար է ամբողջությամբ լուծել, խորհուրդ է տրվում ստուգել ֆայլերի իրադարձությունների մեծ մասը
Անհրաժեշտ է արգելել սկավառակային սարքերի, տպիչների և հաճախորդի աշխատակայանի clipboard-ի միացումը (քարտեզագրումը):
RDP-ում և ICA-ում հնարավոր է կազմակերպել տերմինալային համակարգչի սկավառակների, տպիչների, clipboard com նավահանգիստների ավտոմատ միացումը սերվերին: Եթե այս հնարավորությունը կա, ապա գրեթե անհնար է կանխել տերմինալի սերվերի վրա օտարերկրյա կոդի գործարկումը և տերմինալ մուտքի հաճախորդի վրա 1C-ից տվյալների պահպանումը: Թույլատրել այս գործառույթները միայն նրանց համար, ովքեր վարչական իրավունքներ ունեն:
Տերմինալային սերվերից ցանցային ֆայլերի հասանելիությունը պետք է սահմանափակվի:
Եթե դա չկատարվի, օգտվողը կրկին կկարողանա գործարկել անցանկալի կոդը կամ պահպանել տվյալները: Քանի որ սովորական գրանցամատյանը չի հետևում ֆայլի իրադարձություններին (ի դեպ, լավ գաղափար է պլատֆորմի մշակողների կողմից իրականացման համար), և գրեթե անհնար է համակարգի աուդիտ ստեղծել ամբողջ ցանցում (այն պահպանելու համար բավարար ռեսուրսներ չկան), ավելի լավ է, որ օգտագործողը կարողանա տվյալներ ուղարկել կա՛մ տպելու, կա՛մ էլ. Հատուկ ուշադրություն դարձրեք ապահովելու համար, որ տերմինալային սերվերը ուղղակիորեն չի աշխատում օգտվողների շարժական կրիչների հետ:
Անվտանգ համակարգ ստեղծելիս ոչ մի դեպքում չպետք է թողնեք հավելվածի սերվերը տերմինալի սերվերի վրա:
Եթե հավելվածի սերվերը աշխատում է նույն համակարգչով, ինչ հաճախորդի հավելվածները, ապա դրա բնականոն աշխատանքը խաթարելու բազմաթիվ հնարավորություններ կան: Եթե ինչ-ինչ պատճառներով անհնար է առանձնացնել տերմինալային սերվերի և հավելվածի սերվերի գործառույթները, ապա հատուկ ուշադրություն դարձրեք կիրառական սերվերի կողմից օգտագործվող ֆայլերին օգտագործողի հասանելիությանը:
Անհրաժեշտ է բացառել բոլոր հավելվածների գործարկման հնարավորությունը, բացառությամբ 1C:Enterprise-ի տերմինալային սերվերի վրա:
Սա ամենադժվար իրականացնելու ցանկություններից մեկն է։ Սկսենք նրանից, որ դուք պետք է ճիշտ կարգավորեք Խմբի անվտանգության քաղաքականության քաղաքականությունը տիրույթում: Բոլոր վարչական ձևանմուշները և ծրագրային ապահովման սահմանափակման քաղաքականությունը պետք է ճիշտ կազմաձևվեն: Ինքներդ փորձարկելու համար համոզվեք, որ առնվազն հետևյալ գործառույթներն արգելափակված են.
Այս պահանջի իրականացման բարդությունը հաճախ հանգեցնում է տերմինալի սերվերի վրա «լրացուցիչ» 1C նստաշրջան գործարկելու հնարավորությանը (նույնիսկ եթե այլ հավելվածները սահմանափակ են, սկզբունքորեն անհնար է արգելել 1C-ի գործարկումը Windows-ի միջոցով):
Հաշվի առեք սովորական գրանցամատյանի սահմանափակումները (բոլոր օգտվողներն օգտագործում են ծրագիրը մեկ համակարգչից)
Ակնհայտ է, որ քանի որ օգտվողները բացում են 1C տերմինալային ռեժիմում, ապա տերմինալային սերվերը կգրանցվի մատյանում: Գրանցամատյանը չի նշում, թե որ համակարգչից է միացել օգտվողը:
Տերմինալային սերվեր – Պաշտպանությո՞ւն, թե՞ խոցելիություն:
Այսպիսով, հյուսիսային տերմինալի հիմնական առանձնահատկությունները դիտարկելուց հետո մենք կարող ենք ասել, որ հյուսիսային տերմինալը կարող է պոտենցիալ օգնել ավտոմատացման մեջ՝ բաշխելու հաշվողական բեռը, բայց անվտանգ համակարգ կառուցելը բավականին դժվար է: Տերմինալային սերվեր օգտագործելու դեպքերից մեկն ամենաարդյունավետն այն է, երբ 1C-ն առանց Windows Explorer-ի ամբողջ էկրանով աշխատում է սահմանափակ ֆունկցիոնալ և մասնագիտացված ինտերֆեյս ունեցող օգտվողների համար:
Հաճախորդի մասի աշխատանքը
Օգտագործելով Internet Explorer (IE)
1C հաճախորդի մասի նորմալ շահագործման պայմաններից մեկը բաղադրիչների օգտագործումն է Internet Explorer. Դուք պետք է շատ զգույշ լինեք այս բաղադրիչների հետ:
Ուշադրություն. Նախ, եթե լրտեսող ծրագրերի կամ գովազդային ծրագրերի մոդուլը «կցված է» IE-ին, ապա այն կբեռնվի, նույնիսկ եթե դիտեք որևէ HTML ֆայլ 1C-ում: Առայժմ ես չեմ տեսել այս հատկանիշի գիտակցված օգտագործումը, բայց կազմակերպություններից մեկում տեսել եմ պոռնոգրաֆիկ ցանցերից մեկից բեռնված «լրտես» մոդուլ, որն աշխատում է 1C (հակավիրուսային ծրագիրը չի թարմացվել, որի ախտանիշները հայտնաբերվել են : firewall-ը տեղադրելիս պարզ էր, որ 1C-ը փորձում է 80 նավահանգիստը միացնել պոռնոկայքին): Փաստորեն, սա ևս մեկ փաստարկ է այն բանի օգտին, որ պաշտպանությունը պետք է լինի համապարփակ
Ուշադրություն. Երկրորդ, 1C համակարգը թույլ է տալիս օգտագործել Flash ֆիլմեր, ActiveX օբյեկտներ, VBScript ցուցադրվող HTML փաստաթղթերում, տվյալներ ուղարկել ինտերնետ, նույնիսկ բացել PDF ֆայլեր (!), չնայած վերջին դեպքում խնդրում է «բացել կամ պահպանել»... Ընդհանրապես, այն ամենը, ինչ ցանկանում է ձեր սիրտը: Ներկառուցված HTML դիտման և խմբագրման հնարավորությունների ոչ ամբողջովին ողջամիտ օգտագործման օրինակ.
- Ստեղծեք նոր HTML փաստաթուղթ (Ֆայլ -> Նոր -> HTML փաստաթուղթ):
- Գնացեք դատարկ փաստաթղթի «Տեքստ» ներդիր:
- Հեռացրեք տեքստը (ամբողջությամբ):
- Գնացեք այս փաստաթղթի «Դիտել» ներդիր
- Օգտագործելով drag-n-drop, տեղափոխեք SWF ընդլայնումով ֆայլը (սրանք Flash ֆիլմերի ֆայլեր են) բաց Explorer-ից փաստաթղթի պատուհանից, օրինակ՝ դիտարկիչի քեշից, թեև կարող եք նաև զվարճանքի համար օգտագործել FLASH խաղալիքը:
- Ի՜նչ սիրուն է։ Դուք կարող եք խաղալիք գործարկել 1C-ով:
Համակարգի անվտանգության տեսանկյունից սա լիովին սխալ է: Մինչ այժմ ես չեմ տեսել որևէ հատուկ հարձակում 1C-ի վրա այս խոցելիության միջոցով, բայց, ամենայն հավանականությամբ, դա կլինի ժամանակի և ձեր տեղեկատվության արժեքի հարց:
Կան մի քանի այլ աննշան խնդիրներ, որոնք առաջանում են HTML փաստաթղթի դաշտի հետ աշխատելիս, բայց հիմնականները նշված երկուսն են: Թեև, եթե ստեղծագործորեն մոտենաք այս հնարավորություններին, կարող եք կազմակերպել իսկապես զարմանալի ինտերֆեյսի հնարավորություններ 1C-ի հետ աշխատելու համար:
Արտաքին հաշվետվությունների օգտագործում և մշակում:
Ուշադրություն. Արտաքին հաշվետվություններ և մշակում, մի կողմից, հարմար միջոցլրացուցիչ տպագիր ձևերի իրականացում, կարգավորող հաշվետվություններ, մասնագիտացված հաշվետվություններ, մյուս կողմից՝ համակարգի անվտանգության բազմաթիվ սահմանափակումները շրջանցելու և հավելվածի սերվերի աշխատանքը խաթարելու հնարավոր միջոց (օրինակ, տես վերևում «Անցման պարամետրեր» բաժնում): 1C համակարգում «Արտաքին մշակման ինտերակտիվ բացում» դերի իրավունքների փաթեթում կա հատուկ պարամետր, բայց դա ամբողջությամբ չի լուծում խնդիրը. ամբողջական լուծման համար անհրաժեշտ է նեղացնել օգտվողների շրջանակը, ովքեր կարող են կառավարել: արտաքին տպագիր ձևեր, կարգավորող հաշվետվություններ և ստանդարտ լուծումների այլ ստանդարտ հնարավորություններ, որոնք իրականացվում են արտաքին մշակումների միջոցով: Օրինակ, UPP-ում լռելյայնորեն բոլոր հիմնական օգտատերերի դերերը հնարավորություն ունեն աշխատելու լրացուցիչ տպագիր ձևերի գրացուցակի հետ, և դա, ըստ էության, ցանկացած արտաքին մշակում օգտագործելու հնարավորություն է:
Օգտագործելով ստանդարտ մեխանիզմներ ստանդարտ լուծումների և հարթակների համար (տվյալների փոխանակում)
Որոշ ստանդարտ մեխանիզմներ պոտենցիալ վտանգավոր են և անսպասելի ձևերով:
Ցուցակների տպագրություն
Համակարգի ցանկացած ցուցակ (օրինակ՝ գրացուցակ կամ տեղեկատվական ռեգիստր) կարող է տպվել կամ պահպանվել ֆայլում: Դա անելու համար պարզապես օգտագործեք համատեքստի ընտրացանկից և «Գործողություններ» ցանկից հասանելի ստանդարտ գործառույթը.
Հիշեք, որ գրեթե այն ամենը, ինչ օգտվողը տեսնում է ցուցակներում, կարող է արտածվել արտաքին ֆայլեր: Միակ բանը, որ մենք կարող ենք խորհուրդ տալ, տպագիր սերվերների վրա փաստաթղթերի տպագրության մատյան պահելն է: Հատկապես կարևոր ձևերի համար անհրաժեշտ է կարգավորել գործողությունների վահանակը, որը կապված է պաշտպանված աղյուսակի դաշտի հետ, որպեսզի ցուցակ ցուցադրելու հնարավորությունը հասանելի չլինի այս վահանակից և անջատել համատեքստի ընտրացանկը (տես Նկար 6):
Տվյալների փոխանակում բաշխված տվյալների բազայում
Տվյալների փոխանակման ձևաչափը բավականին պարզ է և նկարագրված է փաստաթղթերում: Եթե օգտատերն ունի մի քանի ֆայլ փոխարինելու հնարավորություն, նա կարող է չարտոնված փոփոխություններ կատարել համակարգում (չնայած սա բավականին աշխատատար խնդիր է): Բաշխված տվյալների բազայի փոխանակման պլաններն օգտագործելիս ծայրամասային տվյալների բազա ստեղծելու հնարավորությունը չպետք է հասանելի լինի սովորական օպերատորներին:
Ստանդարտ XML տվյալների փոխանակում
Ստանդարտ տվյալների փոխանակման մեջ, որն օգտագործվում է ստանդարտ կոնֆիգուրացիաների միջև փոխանակման համար (օրինակ՝ «Առևտրի կառավարում» և «Ձեռնարկությունների հաշվառում»), փոխանակման կանոններում հնարավոր է նշել իրադարձությունների մշակիչներ՝ օբյեկտների բեռնման և բեռնաթափման համար: Սա իրականացվում է ֆայլից կարգավորիչ ստանալու միջոցով և «Run()» ընթացակարգը ֆայլերի բեռնման և բեռնաթափման ստանդարտ մշակման համար («Run()» ընթացակարգը գործարկվում է հաճախորդի կողմից): Ակնհայտ է, որ դժվար չէ ստեղծել նման կեղծ փոխանակման ֆայլ, որը կկատարի վնասակար գործողություններ: Ստանդարտ լուծումների օգտատերերի դերերի մեծ մասի համար համօգտագործումը թույլատրվում է լռելյայն:
Առաջարկություն:սահմանափակել XML փոխանակման հասանելիությունը օգտվողների մեծ մասի համար (այն թողնելով միայն տեղեկատվական անվտանգության ադմինիստրատորներին): Պահպանեք այս մշակման գործառնությունների մատյանները՝ պահպանելով փոխանակման ֆայլը, օրինակ՝ ուղարկելով այն փոստովտեղեկատվական անվտանգության ադմինիստրատորը ներբեռնումից առաջ:
Օգտագործելով ընդհանուր հաշվետվություններ, հատկապես Reports Console-ը
Մեկ այլ խնդիր է օգտատերերի կանխադրված մուտքը ընդհանուր հաշվետվություններին, հատկապես Report Console զեկույցին: Այս զեկույցը բնութագրվում է նրանով, որ այն թույլ է տալիս կատարել տեղեկատվական անվտանգության գրեթե ցանկացած հարցում, և նույնիսկ եթե 1C իրավունքների համակարգը (ներառյալ RLS) կազմաձևված է բավականին խիստ, այն թույլ է տալիս օգտվողին ստանալ շատ «լրացուցիչ» տեղեկատվություն: և ստիպել սերվերին կատարել հարցում, որը կսպառի բոլոր ռեսուրսների համակարգերը:
Ամբողջ էկրանով ռեժիմի օգտագործումը (աշխատասեղանի ռեժիմ)
Ծրագրի ֆունկցիոնալության սահմանափակ հասանելիությամբ մասնագիտացված ինտերֆեյսներ կազմակերպելու արդյունավետ միջոցներից մեկը օգտագործվող ինտերֆեյսի հիմնական (և հնարավոր է միայն) ձևի լիաէկրան ռեժիմն է: Այս դեպքում մատչելիության հետ կապված խնդիրներ չկան, օրինակ՝ «Ֆայլ» ընտրացանկը և օգտվողի բոլոր գործողությունները սահմանափակվում են օգտագործված ձևի հնարավորություններով: Լրացուցիչ մանրամասների համար տե՛ս «Սեղանի ռեժիմի ներդրման առանձնահատկությունները» ITS սկավառակի վրա:
Կրկնօրինակում
1C-ի հաճախորդ-սերվերի տարբերակի կրկնօրինակումը կարող է իրականացվել երկու եղանակով՝ տվյալների վերբեռնում dt ընդլայնմամբ ֆայլի վրա և կրկնօրինակների ստեղծում՝ օգտագործելով SQL: Առաջին մեթոդն ունի բազմաթիվ թերություններ. բացառիկ մուտք է պահանջվում, պատճենի ստեղծումն ինքնին շատ ավելի երկար է տևում, որոշ դեպքերում (եթե տեղեկատվական անվտանգության կառուցվածքը խախտվում է) արխիվ ստեղծելն անհնար է, բայց կա մեկ առավելություն՝ նվազագույն չափը. արխիվը։ SQL կրկնօրինակման դեպքում ճիշտ հակառակն է. պատճենի ստեղծումը տեղի է ունենում ֆոնի վրա՝ օգտագործելով SQL սերվերը՝ պարզ կառուցվածքի և սեղմման բացակայության պատճառով. սա շատ արագ գործընթաց է, և քանի դեռ SQL-ի ֆիզիկական ամբողջականությունը տվյալների բազան կոտրված չէ, կրկնօրինակումը կատարվում է, բայց պատճենի չափը համընկնում է իրականի հետ՝ ընդլայնված վիճակում գտնվող տեղեկատվական անվտանգության չափը (սեղմումը չի կատարվում): MS SQL կրկնօրինակման համակարգի լրացուցիչ առավելությունների պատճառով ավելի նպատակահարմար է օգտագործել այն (թույլատրվում է կրկնօրինակման 3 տեսակ՝ ամբողջական, դիֆերենցիալ, գործարքների գրանցամատյանի պատճեն. հնարավոր է ստեղծել կանոնավոր կատարվող աշխատատեղեր, կրկնօրինակ և կրկնօրինակ: համակարգը արագորեն գործարկվում է, հնարավոր է կանխատեսել սկավառակի պահանջվող տարածքի չափը և այլն): Համակարգի անվտանգության տեսանկյունից կրկնօրինակում կազմակերպելու հիմնական կետերն են.
- Պահուստավորման համար պահեստային վայր ընտրելու անհրաժեշտությունը, որպեսզի դրանք հասանելի չլինեն օգտագործողների համար:
- Պահուստային պատճենները MS SQL սերվերից ֆիզիկական հեռավորության վրա պահելու անհրաժեշտությունը (բնական աղետների, հրդեհների, հարձակումների և այլնի դեպքում)
- Կրկնօրինակում ստեղծելու իրավունքներ տալու հնարավորություն այն օգտատիրոջը, ով մուտք չունի կրկնօրինակում:
Լրացուցիչ մանրամասների համար խնդրում ենք դիմել MS SQL փաստաթղթերին:
Տվյալների կոդավորումը
Տվյալները չարտոնված մուտքից պաշտպանելու համար հաճախ օգտագործվում են գաղտնագրման տարբեր գործիքներ (և՛ ծրագրային, և՛ ապարատային), սակայն դրանց իրագործելիությունը մեծապես կախված է համակարգի ճիշտ կիրառությունից և ընդհանուր անվտանգությունից: Մենք կդիտարկենք տվյալների գաղտնագրումը տվյալների փոխանցման և պահպանման տարբեր փուլերում՝ օգտագործելով ամենատարածված միջոցները և գաղտնագրման գործիքների օգտագործմամբ համակարգի նախագծման հիմնական սխալները:
Տեղեկատվության մշակման մի քանի հիմնական փուլեր կան, որոնք կարելի է պաշտպանել.
- Տվյալների փոխանցում համակարգի հաճախորդի մասի և հավելվածի սերվերի միջև
- Տվյալների փոխանցում հավելվածի սերվերի և MS SQL Server-ի միջև
- MS SQL Server-ում պահված տվյալներ (տվյալների ֆայլեր ֆիզիկական սկավառակի վրա)
- Տեղեկատվական անվտանգության մեջ պահվող տվյալների գաղտնագրում
- Արտաքին տվյալներ (տեղեկատվական անվտանգության հետ կապված)
Հաճախորդի կողմում և հավելվածի սերվերում պահվող տվյալների համար (օգտագործողի պահպանված կարգավորումներ, տեղեկատվական անվտանգության ցանկ և այլն), գաղտնագրումը արդարացված է միայն շատ հազվադեպ դեպքերում և, հետևաբար, այստեղ չի դիտարկվում: Կրիպտոգրաֆիկ գործիքներ օգտագործելիս չպետք է մոռանալ, որ դրանց օգտագործումը կարող է էապես նվազեցնել ընդհանուր համակարգի աշխատանքը:
Ընդհանուր տեղեկություններ ցանցային միացումների գաղտնագրային պաշտպանության մասին TCP/IP արձանագրությունն օգտագործելիս:
Առանց անվտանգության, բոլոր ցանցային կապերը խոցելի են չարտոնված հսկողության և մուտքի համար: Նրանց պաշտպանելու համար դուք կարող եք օգտագործել տվյալների կոդավորումը ցանցային արձանագրության մակարդակում: Տեղական ցանցում փոխանցված տվյալները գաղտնագրելու համար առավել հաճախ օգտագործվում են օպերացիոն համակարգի կողմից տրամադրված IPSec գործիքները:
IPSec գործիքներն ապահովում են փոխանցված տվյալների կոդավորումը՝ օգտագործելով DES և 3DES ալգորիթմները, ինչպես նաև ամբողջականության ստուգում՝ օգտագործելով MD5 կամ SHA1 հեշ ֆունկցիաները: IPSec-ը կարող է գործել երկու ռեժիմով՝ տրանսպորտի ռեժիմ և թունելային ռեժիմ: Տրանսպորտի ռեժիմն ավելի հարմար է տեղական ցանցում միացումներն ապահովելու համար: Թունելի ռեժիմը կարող է օգտագործվել ցանցի առանձին հատվածների միջև VPN կապեր կազմակերպելու կամ տվյալների բաց ալիքների միջոցով տեղական ցանցի հետ հեռավոր կապը պաշտպանելու համար:
Այս մոտեցման հիմնական առավելություններն են.
- Անվտանգության կենտրոնացված կառավարման հնարավորություն՝ օգտագործելով Active Directory գործիքները:
- Ծրագրի սերվերի և MS SQL սերվերի հետ չթույլատրված կապերը բացառելու ունակություն (օրինակ, հնարավոր է պաշտպանվել հավելվածի սերվերի վրա տեղեկատվական անվտանգության չարտոնված ավելացումից):
- Ցանցային տրաֆիկի «լսելու» վերացում.
- Կիրառական ծրագրերի (այս դեպքում 1C) վարքագիծը փոխելու կարիք չկա։
- Նման լուծման ստանդարտ բնույթը.
Այնուամենայնիվ, այս մոտեցումն ունի սահմանափակումներ և թերություններ.
- IPSec-ը չի պաշտպանում տվյալները միջամտությունից և գաղտնալսումից անմիջապես աղբյուրի և նպատակակետ համակարգիչների վրա:
- Ցանցով փոխանցված տվյալների քանակը մի փոքր ավելի մեծ է, քան առանց IPSec-ի օգտագործման:
- IPSec-ի օգտագործման ժամանակ կենտրոնական պրոցեսորի ծանրաբեռնվածությունը մի փոքր ավելի բարձր է:
IPSec գործիքների իրականացման մանրամասն նկարագրությունը դուրս է այս հոդվածի շրջանակներից և պահանջում է IP արձանագրության գործունեության հիմնական սկզբունքների ըմբռնում: Կապի անվտանգությունը ճիշտ կարգավորելու համար խնդրում ենք կարդալ համապատասխան փաստաթղթերը:
Առանձին-առանձին, VPN կապեր կազմակերպելիս անհրաժեշտ է նշել 1C-ի հետ լիցենզային պայմանագրի մի քանի ասպեկտներ: Փաստն այն է, որ, չնայած տեխնիկական սահմանափակումների բացակայությանը, տեղական ցանցի մի քանի հատվածներ կամ առանձին համակարգչի հեռավոր մուտք դեպի տեղական ցանց միացնելիս, սովորաբար պահանջվում են մի քանի հիմնական մատակարարումներ:
Տվյալների կոդավորումը, երբ փոխանցվում է համակարգի հաճախորդի մասի և հավելվածի սերվերի միջև:
Ցանցային արձանագրության մակարդակում գաղտնագրումից բացի, հնարավոր է գաղտնագրել տվյալները COM+ արձանագրության մակարդակով, որը նշված է ITS-ի «Օգտագործողի մուտքի տեղեկատվական բազայի կարգավորումը հաճախորդ-սերվեր տարբերակում» հոդվածում: Այն իրականացնելու համար դուք պետք է զանգերի համար նույնականացման մակարդակը սահմանեք «Փաթեթների գաղտնիություն» 1CV8 հավելվածի համար «Բաղադրիչների ծառայություններում»: Այս ռեժիմի վրա դնելու դեպքում փաթեթը վավերացվում և կոդավորված է, ներառյալ տվյալները, ուղարկողի ինքնությունն ու ստորագրությունը:
Տվյալների կոդավորումը, երբ փոխանցվում է հավելվածի սերվերի և MS SQL Server-ի միջև
MS SQL Server-ը տրամադրում է տվյալների կոդավորման հետևյալ գործիքները.
- Հնարավոր է օգտագործել Secure Sockets Layer (SSL) հավելվածի սերվերի և MS SQL Server-ի միջև տվյալները փոխանցելիս:
- Multiprotocol ցանցային գրադարանից օգտվելիս տվյալների կոդավորումն օգտագործվում է RPC մակարդակում: Սա պոտենցիալ ավելի թույլ կոդավորում է, քան SSL-ի օգտագործումը:
- Եթե օգտագործվում է Shared Memory փոխանակման արձանագրությունը (դա տեղի է ունենում, եթե հավելվածի սերվերը և MS SQL Server-ը գտնվում են նույն համակարգչում), ապա գաղտնագրումը ոչ մի դեպքում չի օգտագործվում:
Որոշակի MS SQL սերվերի համար փոխանցված բոլոր տվյալների գաղտնագրման անհրաժեշտությունը հաստատելու համար դուք պետք է օգտագործեք «Server Network Utility» ծրագիրը: Գործարկեք այն և «Ընդհանուր» ներդիրում ստուգեք «Հարկադիր արձանագրության կոդավորումը» վանդակը: Գաղտնագրման մեթոդը ընտրվում է կախված հաճախորդի հավելվածի կողմից օգտագործվողից (այսինքն՝ 1C հավելվածի սերվերը): SSL-ն օգտագործելու համար դուք պետք է ճիշտ կազմաձևեք վկայագրի ծառայությունը ձեր ցանցում:
Հատուկ հավելվածի սերվերի համար փոխանցված բոլոր տվյալների գաղտնագրման անհրաժեշտությունը սահմանելու համար դուք պետք է օգտագործեք «Client Network Utility» ծրագիրը (սովորաբար գտնվում է «C:\WINNT\system32\cliconfg.exe»): Ինչպես նախորդ դեպքում, «Ընդհանուր» ներդիրում ստուգեք «Հարկադիր արձանագրության կոդավորումը» վանդակը:
Արժե հաշվի առնել, որ գաղտնագրման օգտագործումն այս դեպքում կարող է զգալի ազդեցություն ունենալ համակարգի աշխատանքի վրա, հատկապես մեծ քանակությամբ տեղեկատվություն վերադարձնող հարցումներ օգտագործելիս:
TCP/IP արձանագրությունն օգտագործելիս հավելվածի սերվերի և MS SQL Server-ի միջև կապն ավելի լիարժեք պաշտպանելու համար մենք կարող ենք առաջարկել մի քանի փոփոխություններ լռելյայն կարգավորումներում:
Նախ, դուք կարող եք սահմանել այլ նավահանգիստ, քան ստանդարտը (1433 նավահանգիստը օգտագործվում է լռելյայն): Եթե դուք որոշում եք օգտագործել տվյալների փոխանակման համար ոչ ստանդարտ TCP պորտ, խնդրում ենք նկատի ունենալ, որ.
- MS SQL սերվերը և հավելվածի սերվերը պետք է օգտագործեն նույն պորտը:
- Firewall-ներ օգտագործելիս այս նավահանգիստը պետք է թույլատրվի:
- Դուք չեք կարող մի նավահանգիստ սահմանել, որը կարող է օգտագործվել այլ հավելվածների կողմից MS SQL սերվերի վրա: Հղման համար կարող եք օգտագործել http://www.ise.edu/in-notes/iana/assignments/port-numbers (հասցեն վերցված է SQL Server Books Online-ից):
- MS SQL Server ծառայության մի քանի օրինակներ օգտագործելիս համոզվեք, որ կարդացեք MS SQL փաստաթղթերը կազմաձևման համար (բաժին «Ցանցային կապերի կարգավորում»):
Երկրորդ, MS SQL սերվերի TCP/IP արձանագրության կարգավորումներում կարող եք սահմանել «Թաքցնել սերվերի» դրոշը, որն արգելում է MS SQL Server ծառայության այս օրինակի հեռարձակման հարցումների պատասխանները:
Սկավառակի վրա պահվող MS SQL տվյալների գաղտնագրում
Կա ծրագրային ապահովման և ապարատային բավականին մեծ ընտրություն տեղական սկավառակի վրա գտնվող տվյալների կոդավորման համար (սա ներառում է EFS-ի օգտագործման ստանդարտ Windows-ի հնարավորությունը, eToken ստեղների օգտագործումը և երրորդ կողմի ծրագրերը, ինչպիսիք են Jetico Bestcrypt կամ PGPDisk): Այս գործիքների կատարած հիմնական խնդիրներից մեկը տվյալների պաշտպանությունն է լրատվամիջոցների կորստի դեպքում (օրինակ, երբ սերվերը գողանում են): Հատկապես հարկ է նշել, որ Microsoft-ը խորհուրդ չի տալիս MS SQL տվյալների բազաները պահել կոդավորված լրատվամիջոցների վրա, և դա միանգամայն արդարացված է: Հիմնական խնդիրը այս դեպքում արտադրողականության զգալի անկումն է և հնարավոր խնդիրներհուսալիություն ձախողումներից. Համակարգի ադմինիստրատորի կյանքը բարդացնող երկրորդ գործոնը տվյալների բազայի բոլոր ֆայլերի հասանելիությունն ապահովելու անհրաժեշտությունն է այն պահին, երբ MS SQL ծառայությունն առաջին անգամ մուտք է գործում դրանց (այսինքն՝ ցանկալի է, որ գաղտնագրված միջավայրը միացնելիս ինտերակտիվ գործողությունները բացառվեն):
Համակարգի կատարողականի նկատելի անկումից խուսափելու համար կարող եք օգտագործել MS SQL-ի կարողությունը մի քանի ֆայլերում տվյալների բազաներ ստեղծելու համար: Իհարկե, այս դեպքում MS SQL տվյալների բազան չպետք է ստեղծվի 1C սերվերի կողմից ինֆոբազա ստեղծելիս, այլ պետք է ստեղծվի առանձին։ Մեկնաբանություններով TSQL սցենարի օրինակ տրված է ստորև.
ՕԳՏԱԳՈՐԾԵԼ վարպետ
ԳՆԱՑԵՔ
-- Ստեղծել տվյալների բազա SomeData,
Ստեղծել տվյալների բազա SomeData
-- որի տվյալները ամբողջությամբ գտնվում են PRIMARY ֆայլային խմբում:
ԻՐԱԿԱՆԱԿԱՆ ՄԱՍԻՆ
-- Հիմնական տվյալների ֆայլը գտնվում է կոդավորված կրիչի վրա (տրամաբանական սկավառակ E :)
-- և ունի 100 ՄԲ նախնական չափ, կարող է ավտոմատ կերպով ավելացվել մինչև 200 ՄԲ
-- 20 ՄԲ հավելումներով
(NAME = SomeData1,
FILENAME = «E:\SomeData1.mdf»,
ՉԱՓ = 100 ՄԲ,
MAXSIZE = 200,
ՖԻԼԵԱՃ = 2),
-- Երկրորդ տվյալների ֆայլը գտնվում է չգաղտնագրված կրիչի վրա (տրամաբանական սկավառակ C :)
-- և ունի 100 ՄԲ նախնական չափ, կարող է ավտոմատ կերպով ավելացվել մինչև սահմանը
- սկավառակի տարածությունը ընթացիկ ֆայլի չափի 5%-ի չափով (կլորացված մինչև 64 ԿԲ)
(NAME = SomeData2,
FILENAME = «c:\ծրագրի ֆայլեր\microsoft sql սերվեր\mssql\data\SomeData2.ndf»,
ՉԱՓ = 100 ՄԲ,
MAXSIZE = ԱՆՍԱՀՄԱՆԱՓԱԿ,
ՖԻԼԵԱՃ = 5%)
ՄՈՒՏՔ ԳՈՐԾԵԼ
-- Թեև գործարքների մատյանը կարող է նաև բաժանվել մասերի, դա չպետք է արվի,
-- որովհետեւ այս ֆայլը շատ ավելի հաճախ է փոխվում և պարբերաբար մաքրվում է (օրինակ՝ երբ
- տվյալների բազայի կրկնօրինակի ստեղծում):
(NAME = SomeDatalog,
FILENAME = «c:\ծրագրի ֆայլեր\microsoft sql սերվեր\mssql\data\SomeData.ldf»,
ՉԱՓ = 10 ՄԲ,
MAXSIZE = ԱՆՍԱՀՄԱՆԱՓԱԿ,
ՖԻԼԵԱՃ = 10)
ԳՆԱՑԵՔ
-- Ավելի լավ է տվյալների բազայի սեփականությունը անմիջապես տալ այն օգտվողին, ում անունից
-- 1C-ը կմիանա: Դա անելու համար մենք պետք է հայտարարենք ընթացիկ բազան
- հենց նոր ստեղծվեց,
ՕԳՏԱԳՈՐԾԵԼ Որոշ տվյալներ
ԳՆԱՑԵՔ
-- և գործարկեք sp_changedbowner
EXEC sp_changedbowner @loginame = «SomeData_dbowner»
Կարճ շեղում տվյալների ֆայլի չափի ավտոմատ աճի մասին: Լռելյայնորեն, նոր տվյալների բազաների ֆայլերի չափերն ավելանում են ընթացիկ ֆայլի չափի 10%-ով: Սա լիովին ընդունելի լուծում է փոքր տվյալների բազաների համար, բայց ոչ շատ լավը մեծերի համար. տվյալների բազայի չափով, օրինակ, 20 ԳԲ, ֆայլը պետք է անմիջապես ավելանա 2 ԳԲ-ով: Թեև այս իրադարձությունը տեղի կունենա բավականին հազվադեպ, այն կարող է տևել մի քանի տասնյակ վայրկյան (այս ընթացքում մնացած բոլոր գործարքները գործնականում անգործուն են), ինչը, եթե այն տեղի է ունենում տվյալների բազայի հետ ակտիվ աշխատանքի ընթացքում, կարող է որոշ ձախողումներ առաջացնել: Համամասնական աճի երկրորդ բացասական հետևանքը, որը տեղի է ունենում, երբ սկավառակի տարածքը գրեթե ամբողջությամբ լցված է, վաղաժամ ձախողման հավանականությունն է անբավարար ազատ տարածության պատճառով: Օրինակ, եթե 40 ԳԲ հզորությամբ սկավառակի բաժանումն ամբողջությամբ նվիրված է մեկ տվյալների բազայի (ավելի ճիշտ՝ այս տվյալների բազայի մեկ ֆայլին), ապա տվյալների բազայի ֆայլի կրիտիկական չափը, որում անհրաժեշտ է շտապ (շատ շտապ, մինչև օգտատերերի բնականոն աշխատանքը ընդհատելու աստիճան) տեղեկատվության պահպանումը վերակազմավորելու համար տվյալների ֆայլի չափը 35 ԳԲ է։ 10-20 ՄԲ չափի ավելացման դեպքում դուք կարող եք շարունակել աշխատել մինչև հասնեք 39 ԳԲ-ի:
Հետևաբար, չնայած վերը նշված ցուցակը նշում է տվյալների բազայի ֆայլերից մեկի չափի աճը 5%-ով, շտեմարանի մեծ չափերի համար ավելի լավ է սահմանել 10-20 ՄԲ ֆիքսված հավելում: Տվյալների բազայի ֆայլի չափի աճի համար հավելյալ արժեքները սահմանելիս անհրաժեշտ է հաշվի առնել, որ մինչև ֆայլերի խմբի ֆայլերից մեկը հասնի իր առավելագույն չափին, գործում է կանոնը. մեկ ֆայլի խմբի ֆայլերը միաժամանակ մեծանում են ժամանակ, երբ դրանք բոլորն ամբողջությամբ լցված են: Այսպիսով, վերը նշված օրինակում, երբ SomeData1.mdf ֆայլը հասնի իր առավելագույն չափը՝ 200 ՄԲ, SomeData2.ndf ֆայլը կունենա մոտ 1,1 ԳԲ չափ:
Նման տվյալների բազա ստեղծելուց հետո, նույնիսկ եթե դրա անպաշտպան SomeData2.ndf և SomeData.ldf ֆայլերը հասանելի դառնան հարձակվողի համար, չափազանց դժվար կլինի վերականգնել տվյալների բազայի իրական վիճակը՝ տվյալները (ներառյալ տվյալների բազայի տրամաբանական կառուցվածքի մասին տեղեկատվությունը: ) կցրվեն մի քանի ֆայլերի վրա, և հիմնական տեղեկությունները (օրինակ, թե որ ֆայլերն են կազմում այս տվյալների բազան) կլինեն գաղտնագրված ֆայլում:
Իհարկե, եթե օգտագործվում է գաղտնագրման միջոցների միջոցով տվյալների բազայի ֆայլերի պահպանումը, ապա կրկնօրինակում (առնվազն այդ ֆայլերից) չպետք է իրականացվի չգաղտնագրված կրիչների վրա: Տվյալների բազայի առանձին ֆայլերը պահուստավորելու համար օգտագործեք ՊԱՀԱՆԳՎԱԾ ՏԵՎՅԱԼՆԵՐԻ ԲԱԶԱ հրամանի համապատասխան շարահյուսությունը: Խնդրում ենք նկատի ունենալ, որ չնայած տվյալների բազայի կրկնօրինակը հնարավոր է պաշտպանել գաղտնաբառով («PASSWORD =» և «MEDIAPASSWORD =» «BACKUP DATABASE» հրամանի տարբերակները), նման կրկնօրինակը չի գաղտնագրվում:
Սկավառակներում պահվող հավելվածի սերվերի և հաճախորդի տվյալների գաղտնագրում
Շատ դեպքերում չի կարելի արդարացված համարել 1C:Enterprise-ի (հաճախորդի մաս և հավելվածի սերվեր) կողմից օգտագործվող ֆայլերի պահպանումը կոդավորված կրիչների վրա՝ անհիմն բարձր ծախսերի պատճառով, սակայն, եթե այդպիսի անհրաժեշտություն կա, խնդրում ենք նկատի ունենալ, որ հավելվածի սերվերը և հաճախորդի մասը հավելվածը շատ հաճախ ստեղծում է ժամանակավոր ֆայլեր: Հաճախ այդ ֆայլերը կարող են մնալ հավելվածի գործարկումից հետո, և գրեթե անհնար է երաշխավորել դրանց հեռացումը 1C գործիքների միջոցով: Այսպիսով, անհրաժեշտ է դառնում գաղտնագրել 1C-ում ժամանակավոր ֆայլերի համար օգտագործվող գրացուցակը կամ այն չպահել սկավառակի վրա՝ օգտագործելով RAM սկավառակ (վերջին տարբերակը միշտ չէ, որ հնարավոր է գեներացված ֆայլերի չափի և 1C:Enterprise-ի RAM-ի պահանջների պատճառով: դիմումը ինքնին):
Տվյալների գաղտնագրում ներկառուցված 1C գործիքների միջոցով:
1C-ում կոդավորումն օգտագործելու ստանդարտ հնարավորությունները հանգում են գաղտնագրման պարամետրերով Zip ֆայլերի հետ աշխատելու օբյեկտների օգտագործմանը: Հասանելի են գաղտնագրման հետևյալ ռեժիմները. AES ալգորիթմ՝ 128, 192 կամ 256 բիթանոց բանալիով և հնացած ալգորիթմով, որն ի սկզբանե օգտագործվում էր Zip արխիվայում: AES-ով կոդավորված Zip ֆայլերը ընթեռնելի չեն բազմաթիվ արխիվատորների կողմից (WinRAR, 7zip): Կոդավորված տվյալներ պարունակող ֆայլ ստեղծելու համար դուք պետք է նշեք գաղտնաբառ և գաղտնագրման ալգորիթմ: Այս հատկության վրա հիմնված գաղտնագրման-վերծանման գործառույթների ամենապարզ օրինակը տրված է ստորև.
Գործառույթ EncryptData (տվյալներ, գաղտնաբառ, գաղտնագրման մեթոդ = չսահմանված) Արտահանում
// Տվյալները գրեք ժամանակավոր ֆայլում: Փաստորեն, ոչ բոլոր տվյալները կարող են պահպանվել այս կերպ:
ValueInFile (TemporaryFileName, Data);
// Գրել ժամանակավոր տվյալներ արխիվում
Zip = Նոր ZipFileRecord (TemporaryArchiveFileName, Password, EncryptionMethod);
Zip.Add(TemporaryFileName);
Zip.Write();
// Կարդացեք ստացված արխիվից տվյալները RAM
EncryptedData = NewValueStorage (NewBinaryData (ArchiveTemporaryFileName));
// Ժամանակավոր ֆայլեր - ջնջել
EndFunctions ֆունկցիա DecryptData (Կոդավորված տվյալներ, գաղտնաբառ) Արտահանում
// Ուշադրություն. Անցած պարամետրերի ճշգրտությունը չի վերահսկվում
// Փոխանցված արժեքը գրեք ֆայլում
ArchiveTemporaryFileName = GetTemporaryFileName («zip»);
BinaryArchiveData = EncryptedData.Get();
BinaryArchiveData.Write(ArchiveTemporaryFileName);
// Քաղեք նոր գրված արխիվի առաջին ֆայլը
TemporaryFileName = GetTemporaryFileName();
Zip = Նոր ReadZipFile (TemporaryArchiveFileName, Password);
Zip.Extract(Zip.Items, TemporaryFileName, ZIPFilePathRecoveryMode.Do NotRecover);
// Կարդացեք գրված ֆայլը
Տվյալներ = ValueFromFile (TemporaryFileName + "\" + Zip.Items.Name);
//Ջնջել ժամանակավոր ֆայլերը
Ջնջել Ֆայլերը (Ժամանակավոր Ֆայլի անունը);
DeleteFiles (ArchiveTemporaryFileName);
Վերադարձի տվյալները;
EndFunction
Իհարկե, այս մեթոդը չի կարելի անվանել իդեալական. տվյալները գրվում են ժամանակավոր թղթապանակում հստակ տեքստով, մեթոդի կատարումը, անկեղծ ասած, ավելի վատ է, քան երբևէ, տվյալների բազայում պահպանումը պահանջում է չափազանց մեծ տարածք, բայց սա. միակ մեթոդն է, որը հիմնված է միայն հարթակի ներկառուցված մեխանիզմների վրա։ Բացի այդ, այն առավելություն ունի շատ այլ մեթոդների նկատմամբ՝ այս մեթոդը միաժամանակ փաթեթավորում է տվյալները՝ կոդավորման հետ մեկտեղ: Եթե ցանկանում եք գաղտնագրում իրականացնել առանց այս մեթոդի թերությունների, դուք կամ պետք է դրանք իրականացնեք արտաքին բաղադրիչում, կամ դիմեք առկա գրադարաններին՝ COM օբյեկտների ստեղծման միջոցով, օրինակ՝ օգտագործելով Microsoft CryptoAPI: Որպես օրինակ՝ կտանք ստացված գաղտնաբառի հիման վրա տողի կոդավորման/գաղտնազերծման գործառույթները։
EncryptStringDES ֆունկցիան (չկոդավորված տող, գաղտնաբառ)
CAPICOM_ENCRYPTION_ALGORITHM_DES = 2; // Այս հաստատունը CryptoAPI-ից է
EncryptionMechanism.Content = UnencryptedString;
Encryption Engine.Algorithm.Name = CAPICOM_ENCRYPTION_ALGORITHM_DES;
EncryptedString = EncryptionMechanism.Encrypt();
վերադարձնել EncryptedString;
EndFunction // EncryptStringDES()
Գործառույթ DecryptStringDES (գաղտնագրված տող, գաղտնաբառ)
//Ուշադրություն. Պարամետրերը չեն ստուգվում:
Գաղտնագրման շարժիչ = Նոր COMObject ("CAPICOM.EncryptedData");
EncryptionMechanism.SetSecret(Password);
Փորձ
EncryptionMechanism.Decrypt(EncryptedString);
Բացառություն
// Սխալ գաղտնաբառ!;
Վերադարձեք չսահմանված;
Վերջ փորձը;
ReturnEncryptionMechanism.Content;
EndFunction // DecryptStringDES()
Խնդրում ենք նկատի ունենալ, որ փոխանցելիս դատարկ արժեքԱյս գործառույթների մեջ տող կամ գաղտնաբառ մուտքագրելը սխալի հաղորդագրություն կառաջացնի: Այս գաղտնագրման ընթացակարգով ստացված տողը մի փոքր ավելի երկար է, քան բնօրինակը: Այս գաղտնագրման առանձնահատկությունն այն է, որ եթե դուք գաղտնագրեք տողը երկու անգամ, ապա ստացված տողերը նույնական չեն լինի:
Կրիպտոգրաֆիկ գործիքների օգտագործման հիմնական սխալները.
Կրիպտոգրաֆիկ գործիքներ օգտագործելիս հաճախ արվում են նույն սխալները.
Կրիպտոգրաֆիայի օգտագործման ժամանակ կատարման տույժի թերագնահատում:
Կրիպտոգրաֆիան առաջադրանք է, որը պահանջում է բավականին մեծ թվով հաշվարկներ (հատկապես այնպիսի ալգորիթմների համար, ինչպիսիք են DES, 3DES, GOST, PGP): Եվ նույնիսկ բարձր արդյունավետությամբ և օպտիմիզացված ալգորիթմներ օգտագործելիս (RC5, RC6, AES), հիշողության և հաշվողական մշակման մեջ տվյալների անհարկի փոխանցումից փրկություն չկա: Եվ սա գրեթե ժխտում է բազմաթիվ սերվերի բաղադրիչների (RAID զանգվածներ, ցանցային ադապտերների) հնարավորությունները: Սարքավորումների գաղտնագրում կամ գաղտնագրման բանալի ապարատային ածանցում օգտագործելիս հնարավոր է կատարողականի լրացուցիչ խոչընդոտ՝ լրացուցիչ սարքի և հիշողության միջև տվյալների փոխանցման արագությունը (որտեղ նման սարքի աշխատանքը կարող է կարևոր չլինել): Փոքր քանակությամբ տվյալների կոդավորումն օգտագործելիս (օրինակ՝ էլփոստի հաղորդագրություն), համակարգում հաշվողական բեռի ավելացումն այնքան էլ նկատելի չէ, բայց ամեն ինչի ամբողջական գաղտնագրման դեպքում դա կարող է մեծապես ազդել համակարգի աշխատանքի վրա։ որպես ամբողջություն։
Գաղտնաբառերի և ստեղների ընտրության ժամանակակից հնարավորությունների թերագնահատում.
Տեխնոլոգիայի հնարավորություններն այս պահին այնպիսին են, որ 40-48 բիթ երկարությամբ բանալին կարող է ընտրել փոքր կազմակերպությունը, իսկ 56-64 բիթ երկարությամբ բանալին՝ մեծ կազմակերպության կողմից։ Նրանք. Պետք է օգտագործվեն ալգորիթմներ, որոնք օգտագործում են առնվազն 96 կամ 128 բիթանոց բանալի: Բայց բանալիների մեծ մասը ստեղծվում է օգտագործելով հաշ ալգորիթմներ (SHA-1 և այլն), որոնք հիմնված են օգտագործողի մուտքագրած գաղտնաբառերի վրա: Այս դեպքում 1024 բիթ երկարությամբ բանալին չի կարող օգնել: Նախ, հաճախ օգտագործվում է հեշտ գուշակելի գաղտնաբառ: Ընտրությանը նպաստող գործոններն են՝ տառերի միայն մեկ դեպքի օգտագործումը. գաղտնաբառերում բառերի, անունների և արտահայտությունների օգտագործումը. հայտնի ամսաթվերի, ծննդյան օրերի և այլնի օգտագործում; գաղտնաբառեր ստեղծելիս օգտագործելով «նախշեր» (օրինակ՝ 3 տառ, ապա 2 թիվ, ապա 3 տառ ամբողջ կազմակերպությունում): Լավ գաղտնաբառը պետք է լինի երկու մեծատառերի, թվերի և կետադրական նշանների բավականին պատահական հաջորդականություն: Ստեղնաշարից մուտքագրված մինչև 7-8 նիշ պարունակող գաղտնաբառերը, նույնիսկ եթե պահպանվեն այս կանոնները, կարելի է գուշակել ողջամիտ ժամկետում, ուստի ավելի լավ է, որ գաղտնաբառը լինի առնվազն 11-13 նիշ: Իդեալական լուծումը գաղտնաբառի միջոցով բանալի չգեներացնելն է, օրինակ՝ տարբեր խելացի քարտերի օգտագործումը և այլն, սակայն այս դեպքում անհրաժեշտ է ապահովել գաղտնագրման բանալին կորցնելուց պաշտպանվելու հնարավորությունը:
Բանալիների և գաղտնաբառերի անապահով պահեստավորում:
Այս սխալի ընդհանուր օրինակներն են.
- երկար և բարդ գաղտնաբառեր, որոնք գրված են օգտագործողի մոնիտորի վրա կպչուն գրառումների վրա:
- բոլոր գաղտնաբառերը պահելով չպաշտպանված ֆայլում (կամ պաշտպանված է շատ ավելի թույլ, քան ինքնին համակարգը)
- էլեկտրոնային բանալիների պահպանում հանրային տիրույթում:
- օգտագործողների միջև էլեկտրոնային բանալիների հաճախակի փոխանցում:
Ինչու՞ պատրաստել զրահապատ դուռ, եթե դրա բանալին գտնվում է դռան գորգի տակ:
Սկզբնապես գաղտնագրված տվյալների փոխանցում անապահով միջավայր:
Անվտանգության համակարգ ստեղծելիս համոզվեք, որ այն կատարում է իր գործը: Օրինակ, ես հանդիպեցի մի իրավիճակի (կապված չէ 1C-ի հետ), երբ ի սկզբանե գաղտնագրված ֆայլը, երբ ծրագիրը աշխատում էր հստակ ձևով, տեղադրվում էր ժամանակավոր թղթապանակում, որտեղից այն կարելի էր ապահով կարդալ: Հաճախ կոդավորված տվյալների կրկնօրինակները հստակ ձևով գտնվում են այս տվյալներից «ոչ հեռու» ինչ-որ տեղ:
Կրիպտոգրաֆիկ գործիքների օգտագործումը այլ նպատակներով
Կոդավորելով տարանցիկ տվյալները, դուք չեք կարող ակնկալել, որ տվյալները անհասանելի կլինեն այնտեղ, որտեղ դրանք օգտագործվում են: Օրինակ, IPSec ծառայությունները ոչ մի կերպ չեն խանգարում հավելվածի սերվերին «sniffing» ցանցային երթեւեկությունը հավելվածի մակարդակով:
Այսպիսով, ծածկագրային համակարգերի ներդրման ժամանակ սխալներից խուսափելու համար դուք պետք է (առնվազն) կատարեք հետևյալը նախքան այն տեղադրելը.
- Պարզել:
- Ինչը պետք է պաշտպանվի:
- Պաշտպանության ո՞ր մեթոդը պետք է օգտագործեք:
- Համակարգի ո՞ր մասերը պետք է ապահովված լինեն:
- Ո՞վ է վերահսկելու մուտքը:
- Արդյո՞ք կոդավորումը կաշխատի բոլոր ճիշտ ոլորտներում:
- Որոշեք, թե որտեղ է պահվում տեղեկատվությունը, ինչպես է այն ուղարկվելու ցանցի միջոցով և այն համակարգիչները, որոնցից հասանելի կլինի տեղեկատվությունը: Սա տեղեկատվություն կտրամադրի ցանցի արագության, հզորության և օգտագործման մասին՝ նախքան համակարգը կիրառելը, որն օգտակար է արդյունավետությունը օպտիմալացնելու համար:
- Գնահատեք համակարգի խոցելիությունը տարբեր տեսակի հարձակումների նկատմամբ:
- Մշակել և փաստաթղթավորել համակարգի անվտանգության պլանը:
- Գնահատել համակարգի օգտագործման տնտեսական արդյունավետությունը (հիմնավորումը).
Եզրակացություն
Իհարկե, արագ վերանայման մեջ անհնար է նշել 1C-ում անվտանգության հետ կապված բոլոր ասպեկտները, բայց եկեք թույլ տանք ինքներս մեզ նախնական եզրակացություններ անել: Իհարկե, այս հարթակը չի կարելի անվանել իդեալական. այն, ինչպես շատ ուրիշներ, ունի իր խնդիրներն անվտանգ համակարգ կազմակերպելու հարցում։ Բայց դա ոչ մի կերպ չի նշանակում, որ այդ խնդիրները հնարավոր չէ շրջանցել, ընդհակառակը, գրեթե բոլոր թերությունները կարելի է վերացնել համակարգի պատշաճ մշակմամբ, ներդրմամբ և կիրառմամբ։ Խնդիրների մեծ մասն առաջանում է կոնկրետ կիրառական լուծման և դրա կատարման միջավայրի անբավարար մշակման պատճառով: Օրինակ, առանց էական փոփոխությունների ստանդարտ լուծումները պարզապես չեն ենթադրում բավականաչափ ապահով համակարգի ստեղծում։
Այս հոդվածը ևս մեկ անգամ ցույց է տալիս, որ անվտանգության միջոցների ցանկացած համալիր պետք է ներառի իրականացման բոլոր փուլերը՝ մշակում, տեղակայում, համակարգի կառավարում և, իհարկե, կազմակերպչական միջոցառումներ: Տեղեկատվական համակարգերում հենց «մարդկային գործոնն» է (ներառյալ օգտատերերը) անվտանգության գլխավոր սպառնալիքը։ Միջոցառումների այս փաթեթը պետք է լինի ողջամիտ և հավասարակշռված. իմաստ չունի և քիչ հավանական է, որ բավարար միջոցներ կհատկացվեն պաշտպանություն կազմակերպելու համար, որը գերազանցում է բուն տվյալների արժեքը:
Ընկերություն եզակի ծառայություն է գնորդների, մշակողների, դիլերների և փոխկապակցված գործընկերների համար: Բացի այդ, սա Ռուսաստանում, Ուկրաինայում և Ղազախստանում ծրագրային ապահովման լավագույն առցանց խանութներից մեկն է, որն առաջարկում է հաճախորդներին ապրանքների լայն տեսականի, վճարման բազմաթիվ եղանակներ, պատվերի արագ (հաճախ ակնթարթային) մշակում և պատվերի գործընթացին հետևում անձնական բաժնում։ .
Ինչ անել, եթե iPhone-ի տեսախցիկը ամպամած է
Ինքնուսուցման ձեռնարկ համակարգչով աշխատելու համար՝ արագ, հեշտ, արդյունավետ
Ինչպե՞ս ակտիվացնել ազգային ռոումինգը:
Ինչպե՞ս միացնել Wi-Fi-ը Acer նոութբուքում:
Աշխարհի ամենաարագ ինտերնետը, որքա՞ն է արագությունը: