คำขอ 1c ซับซ้อนเกินไป อาจเป็นกองล้น กองล้น การเข้ารหัสข้อมูลระหว่างการส่งระหว่างเซิร์ฟเวอร์แอปพลิเคชันและ MS SQL Server

บทความนี้แสดงให้เห็นอีกครั้งว่ามาตรการรักษาความปลอดภัยชุดใดชุดหนึ่งควรครอบคลุมทุกขั้นตอนของการใช้งาน: การพัฒนา การปรับใช้ การดูแลระบบ และแน่นอน มาตรการขององค์กร ในระบบข้อมูล มันคือ "ปัจจัยมนุษย์" (รวมถึงผู้ใช้) ที่เป็นภัยคุกคามความปลอดภัยหลัก ชุดของมาตรการนี้ต้องสมเหตุสมผลและสมดุล: ไม่สมเหตุสมผลและไม่น่าเป็นไปได้ที่เงินทุนที่เพียงพอจะถูกจัดสรรเพื่อจัดระเบียบการป้องกันซึ่งเกินต้นทุนของข้อมูลเอง

บทนำ

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 infobase (เช่น การเพิ่มผู้ใช้ การทดสอบและการแก้ไข สำรอง, การตั้งค่าโซลูชันที่ใช้ ฯลฯ)
• นักพัฒนาระบบ- ผู้ใช้พัฒนาโซลูชันที่ประยุกต์ใช้ โดยทั่วไปแล้วพวกเขาอาจไม่สามารถเข้าถึงระบบการทำงานได้
• บุคคลที่ไม่มีการเข้าถึงระบบโดยตรง- ผู้ใช้ที่ไม่ได้รับมอบหมายสิทธิ์ในการเข้าถึง 1C แต่ใครบ้างที่มีผลกระทบต่อการทำงานของระบบไม่ทางใดก็ทางหนึ่ง (โดยปกติคือผู้ใช้ทั้งหมดในโดเมน Active Directory เดียวกันที่ติดตั้งระบบ) หมวดหมู่นี้ถือเป็นหลักในการระบุตัวแบบที่อาจเป็นอันตรายในระบบ
• สคริปต์การดูแลระบบอัตโนมัติ- โปรแกรมที่มอบหมายฟังก์ชันบางอย่าง ออกแบบมาเพื่อดำเนินการบางอย่างโดยอัตโนมัติ (เช่น นำเข้า-ส่งออกข้อมูล)

ควรสังเกตสองประเด็นที่นี่: ประการแรก การจำแนกประเภทนี้มีความหยาบมากและไม่คำนึงถึงการแบ่งแยกภายในแต่ละกลุ่ม - การแบ่งดังกล่าวจะถูกสร้างขึ้นสำหรับกรณีเฉพาะบางกรณี และประการที่สอง สันนิษฐานว่าบุคคลอื่นไม่สามารถมีอิทธิพลต่อการดำเนินงานของ ระบบซึ่งต้องจัดให้มีวิธีการภายนอก 1C

ระบบรักษาความปลอดภัยใดๆ จะต้องได้รับการออกแบบโดยคำนึงถึงความเหมาะสมและต้นทุนในการเป็นเจ้าของ โดยทั่วไป เมื่อพัฒนาและนำระบบสารสนเทศไปใช้งาน จำเป็นต้องมีราคาของการปกป้องระบบที่สอดคล้องกับ:

• คุณค่าของข้อมูลที่ได้รับการคุ้มครอง
• ค่าใช้จ่ายในการสร้างเหตุการณ์ (ในกรณีของการคุกคามโดยเจตนา);
• ความเสี่ยงทางการเงินในกรณีที่เกิดเหตุ

การจัดระบบป้องกันที่มีราคาแพงกว่าการประเมินประสิทธิภาพทางการเงินนั้นไร้เหตุผลและเป็นอันตราย มีหลายวิธีในการประเมินความเสี่ยงของการสูญเสียข้อมูล แต่ไม่มีการพิจารณาในบทความนี้ สิ่งสำคัญอีกประการหนึ่งคือการรักษาสมดุลของข้อกำหนดที่มักขัดแย้งกันสำหรับการรักษาความปลอดภัยข้อมูล ประสิทธิภาพของระบบ ความสะดวกและความเรียบง่ายในการทำงานกับระบบ ความเร็วในการพัฒนาและการใช้งาน และข้อกำหนดอื่นๆ สำหรับระบบข้อมูลขององค์กร

คุณสมบัติหลักของกลไกการรักษาความปลอดภัยของข้อมูลของระบบ

1C: Enterprise 8.0 มาในสองเวอร์ชัน: ไฟล์และไคลเอนต์ - เซิร์ฟเวอร์ เวอร์ชันไฟล์ไม่ถือเป็นการรับรองความปลอดภัยของข้อมูลของระบบด้วยเหตุผลดังต่อไปนี้:

• ข้อมูลและการกำหนดค่าจะถูกเก็บไว้ในไฟล์ที่ผู้ใช้ทุกคนของระบบสามารถอ่านและเขียนได้
• ดังที่แสดงด้านล่าง การอนุญาตระบบนั้นง่ายมากที่จะเลี่ยงผ่าน
• ความสมบูรณ์ของระบบได้รับการประกันโดยแกนหลักของฝั่งไคลเอ็นต์เท่านั้น

ในเวอร์ชันไคลเอ็นต์-เซิร์ฟเวอร์ MS SQL Server ใช้เพื่อเก็บข้อมูล ซึ่งให้:

• การจัดเก็บข้อมูลที่เชื่อถือได้มากขึ้น
• การแยกไฟล์จากการเข้าถึงโดยตรง
• กลไกการทำธุรกรรมและการล็อคที่ดีขึ้น

แม้จะมีความแตกต่างที่สำคัญระหว่างระบบเวอร์ชันไฟล์และไคลเอ็นต์-เซิร์ฟเวอร์ แต่ก็มีรูปแบบการควบคุมการเข้าถึงเดียวที่ระดับโซลูชันแอปพลิเคชัน ซึ่งมีความสามารถดังต่อไปนี้:

• การอนุญาตผู้ใช้โดยใช้รหัสผ่านที่ระบุใน 1C
• การอนุญาตผู้ใช้โดยผู้ใช้ Windows ปัจจุบัน
• การกำหนดบทบาทให้กับผู้ใช้ระบบ
• การจำกัดการดำเนินการของฟังก์ชันการดูแลระบบตามบทบาท
• การกำหนดอินเทอร์เฟซที่พร้อมใช้งานตามบทบาท
• การจำกัดการเข้าถึงออบเจ็กต์ข้อมูลเมตาตามบทบาท
• การจำกัดการเข้าถึงแอตทริบิวต์ของวัตถุตามบทบาท
• การจำกัดการเข้าถึงออบเจ็กต์ข้อมูลตามบทบาทและพารามิเตอร์เซสชัน
• การจำกัดการเข้าถึงข้อมูลและโมดูลปฏิบัติการแบบโต้ตอบ
• ข้อจำกัดบางประการในการรันโค้ด

โดยทั่วไปแล้ว รูปแบบการเข้าถึงข้อมูลที่ใช้นั้นเป็นเรื่องปกติสำหรับระบบข้อมูลในระดับนี้ อย่างไรก็ตาม ในส่วนที่เกี่ยวกับการใช้งานสถาปัตยกรรมไคลเอนต์-เซิร์ฟเวอร์สามระดับนี้มีประเด็นพื้นฐานหลายประการที่นำไปสู่ช่องโหว่จำนวนมาก:

1. ขั้นตอนการประมวลผลข้อมูลจำนวนมาก และในแต่ละขั้นตอน อาจใช้กฎที่แตกต่างกันสำหรับการเข้าถึงออบเจ็กต์

   ไดอะแกรมที่ค่อนข้างง่ายของขั้นตอนการประมวลผลข้อมูลที่มีความสำคัญจากมุมมองด้านความปลอดภัยจะแสดงในรูปที่ 1 กฎทั่วไปสำหรับ 1C คือการลดข้อจำกัดเมื่อคุณเลื่อนลงตามแผนนี้ ดังนั้น การใช้ช่องโหว่บนหนึ่งใน ระดับบนสามารถขัดขวางการทำงานของระบบได้ทุกระดับ

2. ขั้นตอนการดีบั๊กไม่เพียงพอสำหรับการควบคุมข้อมูลที่ส่งเมื่อย้ายจากระดับหนึ่งไปอีกระดับ

   น่าเสียดายที่ไม่ใช่กลไกภายในทั้งหมดของระบบที่ได้รับการดีบักอย่างสมบูรณ์ โดยเฉพาะอย่างยิ่งสำหรับกลไกที่ไม่โต้ตอบ ซึ่งการดีบักนั้นใช้เวลานานกว่าเสมอ ในแง่หนึ่ง แต่อีกด้านหนึ่งมีความรับผิดชอบมากกว่า "โรค" นี้ไม่ได้เป็นปัญหาสำหรับ 1C โดยเฉพาะ แต่จะพบในผลิตภัณฑ์เซิร์ฟเวอร์จำนวนมากของผู้ขายส่วนใหญ่ เฉพาะในปีที่ผ่านมามีความสนใจในปัญหาเหล่านี้เพิ่มขึ้นอย่างมาก

3. คุณสมบัติเฉลี่ยสูงไม่เพียงพอของนักพัฒนาและผู้ดูแลระบบที่สืบทอดมาจากเวอร์ชันก่อนหน้า

   ผลิตภัณฑ์ของ 1C: กลุ่มผลิตภัณฑ์ในขั้นต้นมุ่งเน้นไปที่ความง่ายในการพัฒนาและการสนับสนุน และเพื่อทำงานในองค์กรขนาดเล็ก ดังนั้นจึงไม่น่าแปลกใจที่ในอดีต ส่วนสำคัญของ "นักพัฒนา" ของโซลูชันแอปพลิเคชันและ "ผู้ดูแลระบบ" ของระบบไม่ มีความรู้และทักษะเพียงพอที่จะทำงานกับผลิตภัณฑ์ที่ซับซ้อนมากขึ้น ซึ่งก็คือเวอร์ชัน 8.0 ปัญหารุนแรงขึ้นจากการปฏิบัติที่บริษัทแฟรนไชส์ซีนำมาใช้ในการฝึกอบรม "ในการต่อสู้" โดยเสียค่าใช้จ่ายของลูกค้า โดยไม่ต้องเข้าถึงปัญหานี้อย่างเป็นระบบ จำเป็นต้องส่งส่วย 1C ว่าในช่วงไม่กี่ปีที่ผ่านมาสถานการณ์นี้ค่อยๆดีขึ้น: บริษัท แฟรนไชส์ที่จริงจังได้เริ่มใช้แนวทางที่รับผิดชอบมากขึ้นในการแก้ไขปัญหาการสรรหาและฝึกอบรมบุคลากรระดับของการสนับสนุนเทคโนโลยีสารสนเทศจาก 1C เพิ่มขึ้น ที่สำคัญโปรแกรมการรับรองได้เน้นไปที่การบริการในระดับสูง แต่สถานการณ์ไม่สามารถแก้ไขได้ในทันที ดังนั้นควรคำนึงถึงปัจจัยนี้เมื่อวิเคราะห์ความปลอดภัยของระบบ

4. อายุค่อนข้างน้อยของแพลตฟอร์ม

   ในบรรดาผลิตภัณฑ์ที่มีจุดเน้นและวัตถุประสงค์ในการใช้งานที่คล้ายคลึงกัน นี่เป็นหนึ่งในโซลูชั่นที่อายุน้อยที่สุด ฟังก์ชันการทำงานของแพลตฟอร์มได้รับการตัดสินน้อยกว่าหนึ่งปีที่ผ่านมา ในเวลาเดียวกัน การเปิดตัวของแพลตฟอร์มแต่ละครั้งเริ่มใน 8.0.10 (ในรีลีสนี้ที่ความสามารถปัจจุบันเกือบทั้งหมดของระบบถูกนำไปใช้) มีความเสถียรมากกว่ารุ่นก่อนมาก ฟังก์ชันการทำงานของโซลูชันแอปพลิเคชันทั่วไปยังคงเติบโตอย่างก้าวกระโดด แม้ว่าความสามารถของแพลตฟอร์มครึ่งหนึ่งจะถูกใช้อย่างมากที่สุด แน่นอน ในสภาวะเช่นนี้ เราสามารถพูดคุยเกี่ยวกับความเสถียรได้ค่อนข้างไม่แน่นอน แต่โดยทั่วไปแล้ว ต้องยอมรับว่าในหลาย ๆ ด้าน โซลูชันบนแพลตฟอร์ม 1C 8.0 มีประสิทธิภาพเหนือกว่าโซลูชันที่คล้ายคลึงกันบนแพลตฟอร์ม 1C 7.7 อย่างมากในแง่ของการทำงานและประสิทธิภาพ (และ มักจะมีเสถียรภาพ)

ดังนั้นระบบ (และอาจเป็นโซลูชันแอปพลิเคชันทั่วไป) จึงถูกปรับใช้ที่องค์กรและติดตั้งบนคอมพิวเตอร์ ประการแรก จำเป็นต้องสร้างสภาพแวดล้อมที่เหมาะสมในการกำหนดค่าความปลอดภัย 1C และสำหรับสิ่งนี้ จะต้องกำหนดค่าในลักษณะที่ว่าการตั้งค่าระบบได้รับผลกระทบอย่างมากจากการตั้งค่าระบบ

ปฏิบัติตามกฎทั่วไปสำหรับการตั้งค่าความปลอดภัย

จะไม่มีคำถามเกี่ยวกับความปลอดภัยของข้อมูลใดๆ ของระบบ หากไม่ปฏิบัติตามหลักการพื้นฐานของการสร้างระบบความปลอดภัย ตรวจสอบให้แน่ใจว่าอย่างน้อยตรงตามเงื่อนไขต่อไปนี้:

• การเข้าถึงเซิร์ฟเวอร์ถูกจำกัดทางกายภาพและมั่นใจได้ว่าการทำงานจะไม่หยุดชะงัก:
  • อุปกรณ์เซิร์ฟเวอร์ตรงตามข้อกำหนดของความน่าเชื่อถือ การเปลี่ยนอุปกรณ์เซิร์ฟเวอร์ที่ผิดพลาดถูกดีบั๊ก สำหรับพื้นที่วิกฤตโดยเฉพาะ วงจรซ้ำซ้อนถูกนำมาใช้ ฮาร์ดแวร์(RAID, แหล่งจ่ายไฟจากหลายแหล่ง, หลายช่องทางการสื่อสาร ฯลฯ );
  • เซิร์ฟเวอร์ตั้งอยู่ในห้องที่ถูกล็อก และห้องนี้จะเปิดเฉพาะในช่วงเวลาของการทำงานที่ไม่สามารถดำเนินการจากระยะไกลได้
  • มีเพียงคนเดียวหรือสองคนเท่านั้นที่มีสิทธิ์เปิดห้องเซิร์ฟเวอร์ในกรณีฉุกเฉินได้มีการพัฒนาระบบแจ้งเตือนสำหรับผู้รับผิดชอบ
  • มีการจ่ายไฟให้กับเซิร์ฟเวอร์อย่างต่อเนื่อง
  • มั่นใจโหมดการทำงานของสภาพอากาศปกติของอุปกรณ์
  • มีสัญญาณเตือนไฟไหม้ในห้องเซิร์ฟเวอร์ ไม่มีโอกาสเกิดน้ำท่วม (โดยเฉพาะชั้นแรกและชั้นสุดท้าย)
• การตั้งค่าเครือข่ายและโครงสร้างพื้นฐานข้อมูลขององค์กรถูกต้อง:
  • เซิร์ฟเวอร์ทั้งหมดมีไฟร์วอลล์ติดตั้งและกำหนดค่า
  • ผู้ใช้และคอมพิวเตอร์ทั้งหมดได้รับอนุญาตบนเครือข่าย รหัสผ่านซับซ้อนพอที่จะคาดเดาไม่ได้
  • ตัวดำเนินการระบบมีสิทธิ์เพียงพอที่จะทำงานได้ตามปกติ แต่ไม่มีสิทธิ์ในการดำเนินการด้านการดูแลระบบ
  • มีการติดตั้งและเปิดใช้งานเครื่องมือป้องกันไวรัสในคอมพิวเตอร์ทุกเครื่องในเครือข่าย
  • เป็นที่พึงปรารถนาที่ผู้ใช้ (ยกเว้นผู้ดูแลระบบเครือข่าย) ไม่มีสิทธิ์ผู้ดูแลระบบบนไคลเอ็นต์เวิร์กสเตชัน
  • การเข้าถึงอินเทอร์เน็ตและสื่อที่ถอดออกได้ควรมีการควบคุมและจำกัด
  • ต้องกำหนดค่าการตรวจสอบระบบของเหตุการณ์ความปลอดภัย
• ปัญหาองค์กรหลักได้รับการแก้ไขแล้ว:
  • ผู้ใช้มีคุณสมบัติเพียงพอที่จะทำงานกับ 1C และฮาร์ดแวร์
  • ผู้ใช้จะได้รับแจ้งถึงความรับผิดชอบในการละเมิดกฎการปฏิบัติงาน
  • ได้แต่งตั้งผู้รับผิดชอบทางการเงินสำหรับองค์ประกอบที่เป็นสาระสำคัญของระบบสารสนเทศแต่ละส่วน
  • ทั้งหมด บล็อกระบบปิดผนึกและปิด;
  • ให้ความสนใจเป็นพิเศษกับการสอนและควบคุมงานทำความสะอาด ช่างก่อสร้าง และช่างไฟฟ้า บุคคลเหล่านี้สามารถทำให้เกิดความเสียหายที่ไม่สามารถเทียบได้กับความเสียหายโดยเจตนาที่เกิดจากผู้ใช้ระบบที่ไร้ยางอาย

ความสนใจ!รายการนี้ไม่ได้ครอบคลุมทั้งหมด แต่อธิบายเฉพาะสิ่งที่มักถูกมองข้ามเมื่อปรับใช้ระบบข้อมูลที่ค่อนข้างซับซ้อนและมีราคาแพง!

• MS SQL Server แอปพลิเคชันเซิร์ฟเวอร์และฝั่งไคลเอ็นต์ทำงานบนคอมพิวเตอร์หลายเครื่อง แอปพลิเคชันเซิร์ฟเวอร์ทำงานภายใต้สิทธิ์ที่สร้างขึ้นเป็นพิเศษ ผู้ใช้ Windows;
• สำหรับ MS SQL Server
  • ตั้งค่าโหมดการอนุญาตแบบผสม
  • ผู้ใช้ MS SQL ที่รวมอยู่ในบทบาทผู้ดูแลระบบเซิร์ฟเวอร์ไม่มีส่วนร่วมในการทำงานของ 1C
  • สำหรับแต่ละ IS 1C จะมีการสร้างผู้ใช้ MS SQL แยกต่างหากซึ่งไม่มีสิทธิ์เข้าถึงเซิร์ฟเวอร์
  • ผู้ใช้ MS SQL ของการรักษาความปลอดภัยข้อมูลหนึ่งไม่สามารถเข้าถึงการรักษาความปลอดภัยข้อมูลอื่น ๆ
• ผู้ใช้ไม่มีสิทธิ์เข้าถึงไฟล์ Application Server และ MS SQL Server โดยตรง
• สถานที่ทำงานของผู้ให้บริการติดตั้ง Windows 2000 / XP (ไม่ใช่ Windows 95/98 / Me)

อย่าละเลยคำแนะนำของผู้พัฒนาระบบและอ่านเอกสารประกอบ บนดิสก์ ITS ในส่วน "คำแนะนำเกี่ยวกับระเบียบวิธี" มีการเผยแพร่เอกสารสำคัญเกี่ยวกับการปรับแต่งระบบ ให้ความสนใจเป็นพิเศษกับบทความต่อไปนี้:

1. คุณสมบัติของแอปพลิเคชันที่ทำงานร่วมกับเซิร์ฟเวอร์ 1C: Enterprise
2. การจัดวางข้อมูล 1C: Enterprise 8.0
3. กำลังอัปเดต 1C: Enterprise 8.0 โดยผู้ใช้ Microsoft Windowsไม่มีสิทธิ์ของผู้ดูแลระบบ
4. การแก้ไขรายชื่อผู้ใช้ในนามของผู้ใช้ที่ไม่มีสิทธิ์ผู้ดูแลระบบ
5. การกำหนดค่าการตั้งค่าไฟร์วอลล์ Windows XP SP2 เพื่อเรียกใช้ SQL Server 2000 และ SQL Server Desktop Engine (MSDE)
6. การกำหนดค่าพารามิเตอร์ COM + Windows XP SP2 สำหรับ 1C: การทำงานของเซิร์ฟเวอร์ Enterprise 8.0
7. การกำหนดค่าพารามิเตอร์ไฟร์วอลล์ Windows XP SP2 สำหรับ 1C: การทำงานของเซิร์ฟเวอร์ Enterprise 8.0
8. การกำหนดค่าการตั้งค่าไฟร์วอลล์ Windows XP SP2 สำหรับ HASP License Manager
9. การสร้างสำเนาสำรองของฐานข้อมูลโดยใช้ SQL Server 2000
10. คำถามเกี่ยวกับการติดตั้งและการกำหนดค่า 1C: Enterprise 8.0 ในตัวเลือก "ไคลเอนต์ - เซิร์ฟเวอร์"(หนึ่งในบทความที่สำคัญที่สุด)
11. ลักษณะเฉพาะ การตั้งค่า Windows Server 2003 เมื่อติดตั้ง 1C: Enterprise 8.0 server
12. ระเบียบการเข้าถึงของผู้ใช้ในฐานข้อมูลในเวอร์ชันไคลเอนต์ - เซิร์ฟเวอร์(หนึ่งในบทความที่สำคัญที่สุด)
13. เซิร์ฟเวอร์ 1C: Enterprise และ SQL Server
14. ขั้นตอนโดยละเอียดสำหรับการติดตั้ง 1C: Enterprise 8.0 ในเวอร์ชัน "client-server"(หนึ่งในบทความที่สำคัญที่สุด)
15. การใช้ภาษาในตัวบน 1C: เซิร์ฟเวอร์องค์กร

แต่การอ่านเอกสารควรวิจารณ์ข้อมูลที่ได้รับเช่นในบทความ "คำถามในการติดตั้งและกำหนดค่า 1C: Enterprise 8.0 ในตัวเลือก" ไคลเอนต์ - เซิร์ฟเวอร์ "ตัวเลือก" สิทธิ์ที่จำเป็นสำหรับผู้ใช้ USER1CV8SERVER ไม่ใช่ อธิบายค่อนข้างแม่นยำ จะมีลิงก์ไปยังรายการด้านล่าง เช่น [ITS1] หมายถึงบทความ "ลักษณะเฉพาะของการทำงานกับเซิร์ฟเวอร์ 1C: Enterprise" ลิงก์ทั้งหมดไปยังบทความจะมอบให้กับฉบับล่าสุดของ ITS ณ เวลาที่เขียน (มกราคม 2549)

ใช้ความสามารถในการอนุญาตสำหรับผู้ใช้รวมกับการอนุญาตของ Windows

จากสองโหมดการให้สิทธิ์ผู้ใช้ที่เป็นไปได้: 1C ในตัวและรวมกับการอนุญาต Windows OS - ถ้าเป็นไปได้ คุณควรเลือกการอนุญาตแบบรวม สิ่งนี้จะช่วยให้ผู้ใช้ไม่ต้องสับสนกับรหัสผ่านหลายอันในขณะทำงาน แต่จะไม่ลดระดับความปลอดภัยของระบบ อย่างไรก็ตาม แม้กระทั่งสำหรับผู้ใช้ที่ใช้เฉพาะการอนุญาต Windows ขอแนะนำให้ตั้งรหัสผ่านเมื่อสร้าง และหลังจากนั้นก็ปิดการใช้งานการอนุญาต 1C สำหรับ ผู้ใช้ที่ได้รับ... เพื่อให้แน่ใจว่าการกู้คืนระบบในกรณีที่โครงสร้าง Active Directory ถูกทำลาย จำเป็นต้องปล่อยให้ผู้ใช้อย่างน้อยหนึ่งรายสามารถเข้าสู่ระบบโดยใช้การอนุญาต 1C

เมื่อสร้างบทบาทโซลูชันแอปพลิเคชันอย่าเพิ่มสิทธิ์ "สำรอง"

แต่ละบทบาทของโซลูชันแอปพลิเคชันต้องสะท้อนถึงชุดสิทธิ์ขั้นต่ำที่จำเป็นในการดำเนินการตามที่กำหนดโดยบทบาทนี้ อย่างไรก็ตาม บางบทบาทอาจใช้ไม่ได้ด้วยตัวเอง ตัวอย่างเช่น สำหรับการเปิดตัวแบบโต้ตอบ การรักษาภายนอกคุณสามารถสร้างบทบาทแยกต่างหากและเพิ่มให้กับผู้ใช้ทั้งหมดที่จำเป็นต้องใช้การประมวลผลภายนอก

ตรวจสอบบันทึกและบันทึกของระบบเป็นประจำ

ควบคุมและทำให้การตรวจสอบบันทึกและโปรโตคอลการทำงานของระบบเป็นไปโดยอัตโนมัติ ด้วยการกำหนดค่าที่เหมาะสมและการตรวจสอบบันทึกเป็นประจำ (กรองเฉพาะเหตุการณ์สำคัญเท่านั้น) การดำเนินการที่ไม่ได้รับอนุญาตสามารถตรวจพบได้ตั้งแต่เนิ่นๆ หรือแม้แต่ป้องกันในระหว่างขั้นตอนการเตรียมการ

คุณลักษณะบางอย่างของเวอร์ชันไคลเอนต์ - เซิร์ฟเวอร์

ส่วนนี้อธิบายคุณลักษณะบางอย่างของเวอร์ชันไคลเอ็นต์-เซิร์ฟเวอร์และผลกระทบต่อความปลอดภัย เพื่อให้อ่านง่ายขึ้น ยอมรับการกำหนดต่อไปนี้:

ความสนใจ! คำอธิบายช่องโหว่

การจัดเก็บข้อมูลที่ควบคุมการเข้าถึงระบบ

การจัดเก็บรายชื่อผู้ใช้การรักษาความปลอดภัยของข้อมูล

ข้อมูลทั้งหมดเกี่ยวกับรายชื่อผู้ใช้ของ IS นี้และบทบาทที่มีให้กับพวกเขาจะถูกเก็บไว้ในตาราง Params ในฐานข้อมูล MS SQL (ดู [ITS2]) เมื่อดูโครงสร้างและเนื้อหาของตารางนี้ จะเห็นได้ชัดว่าข้อมูลผู้ใช้ทั้งหมดถูกจัดเก็บไว้ในบันทึก โดยมีค่าฟิลด์ชื่อไฟล์ "users.usr"

เนื่องจากเราคิดว่าผู้ใช้ไม่มีสิทธิ์เข้าถึงฐานข้อมูล MS SQL ผู้โจมตีจึงไม่สามารถใช้ข้อเท็จจริงนี้ได้ แต่ถ้าเป็นไปได้ที่จะรันโค้ดใน MS SQL สิ่งนี้จะ "เปิดประตู" เพื่อรับ (! ) การเข้าถึงจาก 1C ... กลไกเดียวกัน (ที่มีการเปลี่ยนแปลงเล็กน้อย) สามารถใช้กับเวอร์ชันไฟล์ของระบบได้ ซึ่งเมื่อพิจารณาจากลักษณะเฉพาะของเวอร์ชันไฟล์แล้ว จะไม่รวมการบังคับใช้ในการสร้างระบบความปลอดภัยโดยสมบูรณ์

คำแนะนำ:ปัจจุบันยังไม่มีวิธีใดที่จะปกป้องแอปพลิเคชันจากการเปลี่ยนแปลงดังกล่าวได้อย่างสมบูรณ์ ยกเว้นการใช้ทริกเกอร์ที่ระดับ MS SQL Server ซึ่งในทางกลับกัน อาจทำให้เกิดปัญหาเมื่ออัปเดตเวอร์ชันแพลตฟอร์มหรือเปลี่ยนรายชื่อผู้ใช้ . ในการติดตามการเปลี่ยนแปลงดังกล่าว คุณสามารถใช้บันทึก 1C (ให้ความสนใจกับการเข้าสู่ระบบ "น่าสงสัย" ในโหมดตัวกำหนดค่าโดยไม่ต้องระบุผู้ใช้) หรือให้ SQL Profiler ทำงานอย่างต่อเนื่อง (ซึ่งจะส่งผลเสียอย่างมากต่อประสิทธิภาพของระบบ) หรือกำหนดค่าการแจ้งเตือน กลไก (น่าจะใช้ทริกเกอร์ร่วมกัน)

การจัดเก็บข้อมูลเกี่ยวกับรายการ IS บนเซิร์ฟเวอร์

สำหรับแอปพลิเคชันเซิร์ฟเวอร์ 1C แต่ละรายการ ข้อมูลเกี่ยวกับรายการฐานข้อมูล MS SQL ที่เชื่อมต่อจะถูกเก็บไว้ ฐานข้อมูลแต่ละอันใช้สตริงการเชื่อมต่อของตัวเองระหว่างเซิร์ฟเวอร์แอปพลิเคชันและเซิร์ฟเวอร์ MS SQL ข้อมูลเกี่ยวกับฐานข้อมูลที่ลงทะเบียนบนแอปพลิเคชันเซิร์ฟเวอร์พร้อมกับสตริงการเชื่อมต่อจะถูกเก็บไว้ในไฟล์ srvrib.lst ซึ่งอยู่บนเซิร์ฟเวอร์ในไดเรกทอรี<Общие данные приложений>/ 1C / 1Cv8 (เช่น C: / เอกสารและการตั้งค่า / ผู้ใช้ทั้งหมด / ข้อมูลแอปพลิเคชัน / 1C / 1Cv8 / srvrib.lst) สำหรับการรักษาความปลอดภัยข้อมูลแต่ละรายการ จะมีการจัดเก็บสตริงการเชื่อมต่อที่สมบูรณ์ รวมถึงรหัสผ่านผู้ใช้ MS SQL เมื่อใช้แบบจำลองการอนุญาต MS SQL แบบผสม การมีอยู่ของไฟล์นี้ทำให้กลัวการเข้าถึงฐานข้อมูล MS SQL โดยไม่ได้รับอนุญาต และหากผู้ใช้ที่มีสิทธิพิเศษถูกใช้เพื่อเข้าถึงฐานข้อมูลอย่างน้อยหนึ่งฐานข้อมูล (เช่น "sa") ตรงกันข้ามกับคำแนะนำ นอกจากการคุกคามของ IS หนึ่งระบบแล้ว ระบบทั้งหมดที่ใช้ MS SQL ยังถูกคุกคามอีกด้วย

เป็นที่น่าสนใจที่จะทราบว่าการใช้การอนุญาตแบบผสมและการอนุญาต Windows บนเซิร์ฟเวอร์ MS SQL ทำให้เกิดปัญหาประเภทต่างๆ เมื่อเข้าถึงไฟล์นี้ ดังนั้นคุณสมบัติเชิงลบที่สำคัญของการอนุญาต Windows จะเป็น:

• การทำงานของการรักษาความปลอดภัยของข้อมูลทั้งหมดบนเซิร์ฟเวอร์แอปพลิเคชันและบนเซิร์ฟเวอร์ MS SQL ภายใต้สิทธิ์ชุดเดียว (ส่วนใหญ่มักจะซ้ำซ้อน)
• จากกระบวนการเซิร์ฟเวอร์แอปพลิเคชัน 1C (หรือโดยทั่วไปจากผู้ใช้ USER1CV8SERVER หรืออนาล็อก) โดยไม่ต้องระบุรหัสผ่าน คุณสามารถเชื่อมต่อกับการรักษาความปลอดภัยข้อมูลใด ๆ ได้อย่างง่ายดายโดยไม่ต้องระบุรหัสผ่าน

ในทางกลับกัน ผู้โจมตีอาจเรียกใช้โค้ดโดยอำเภอใจจากบริบทของผู้ใช้ USER1CV8SERVER ได้ยากกว่าการดึงไฟล์ที่ระบุ อย่างไรก็ตาม การปรากฏตัวของไฟล์ดังกล่าวเป็นอีกอาร์กิวเมนต์สำหรับการแยกฟังก์ชันเซิร์ฟเวอร์บนคอมพิวเตอร์หลายเครื่อง

คำแนะนำ:ไฟล์ srvrib.lst ควรเข้าถึงได้เฉพาะกระบวนการของเซิร์ฟเวอร์เท่านั้น อย่าลืมตั้งค่าการตรวจสอบเพื่อเปลี่ยนแปลงไฟล์นี้

ขออภัย โดยค่าเริ่มต้น ไฟล์นี้แทบจะอ่านไม่ได้ทั้งหมด ซึ่งต้องนำมาพิจารณาเมื่อปรับใช้ระบบ ตัวเลือกที่เหมาะสมที่สุดคือถ้าเซิร์ฟเวอร์แอปพลิเคชันป้องกันการอ่านและเขียนไฟล์นี้ระหว่างการทำงาน (รวมถึงการอ่านและการเขียนโดยการเชื่อมต่อของผู้ใช้ที่ดำเนินการบนเซิร์ฟเวอร์นี้)

ขาดการอนุญาตเมื่อสร้างความปลอดภัยของข้อมูลบนเซิร์ฟเวอร์

ความสนใจ! ข้อผิดพลาดในการอนุญาตได้รับการแก้ไขในรุ่น 8.0.14 ของแพลตฟอร์ม 1C: Enterprise รุ่นนี้แนะนำแนวคิดของ "1C: Enterprise Server Administrator" แต่ในขณะที่มีการระบุรายชื่อผู้ดูแลระบบไว้บนเซิร์ฟเวอร์ ระบบจะทำงานตามที่อธิบายไว้ด้านล่าง ดังนั้นอย่าลืมเกี่ยวกับคุณลักษณะที่เป็นไปได้นี้

น่าจะเป็นช่องโหว่ที่ใหญ่ที่สุดจากส่วนนี้ คือ ความสามารถในการเพิ่มความปลอดภัยของข้อมูลเกือบไม่จำกัดให้กับเซิร์ฟเวอร์แอปพลิเคชัน ส่งผลให้ผู้ใช้ที่เข้าถึงการเชื่อมต่อกับแอปพลิเคชันเซิร์ฟเวอร์ได้รับโอกาสในการเรียกใช้รหัสตามอำเภอใจโดยอัตโนมัติบนแอปพลิเคชันเซิร์ฟเวอร์ . มาดูตัวอย่างกัน

ต้องติดตั้งระบบในตัวแปรต่อไปนี้

• MS SQL Server 2000 (เช่น ชื่อเครือข่าย SRV1)
• เซิร์ฟเวอร์ 1C: Enterprise 8.0 (ชื่อเครือข่าย SRV2)
• ส่วนไคลเอ็นต์ของ 1C: Enterprise 8.0 (ชื่อเครือข่าย WS)

สันนิษฐานว่าผู้ใช้ (ต่อไปนี้คือ USER) ที่ทำงานบน WS มีการเข้าถึงหนึ่งใน IB ที่ลงทะเบียนบน SRV2 น้อยที่สุด แต่ไม่มีสิทธิ์ในการเข้าถึง SRV1 และ SRV2 โดยทั่วไป การรวมกันของฟังก์ชันต่างๆ โดยคอมพิวเตอร์ที่อยู่ในรายการจะไม่ส่งผลต่อสถานการณ์ ระบบได้รับการกำหนดค่าโดยคำนึงถึงคำแนะนำในเอกสารประกอบและบนดิสก์ ITS สถานการณ์สะท้อนให้เห็นในรูปที่ 2.

• กำหนดค่าความปลอดภัย COM + บนเซิร์ฟเวอร์แอปพลิเคชันเพื่อให้ผู้ใช้ 1C เท่านั้นที่มีสิทธิ์เชื่อมต่อกับกระบวนการเซิร์ฟเวอร์แอปพลิเคชัน (สำหรับรายละเอียดเพิ่มเติม [ITS12]);
• ไฟล์ srvrib.lst จะต้องเป็นแบบอ่านอย่างเดียวสำหรับผู้ใช้ USER1CV8SERVER (เปิดใช้งานการเขียนชั่วคราวเพื่อเพิ่ม IB ใหม่ไปยังเซิร์ฟเวอร์)
• ในการเชื่อมต่อกับ MS SQL ให้ใช้เฉพาะโปรโตคอล TCP / IP ในกรณีนี้ คุณสามารถ:
  • จำกัดการเชื่อมต่อโดยใช้ไฟร์วอลล์
  • กำหนดค่าการใช้พอร์ต TCP ที่ไม่ได้มาตรฐานซึ่งจะทำให้การเชื่อมต่อของ "บุคคลภายนอก" IS 1C ซับซ้อนขึ้น
  • ใช้การเข้ารหัสข้อมูลที่ส่งระหว่างเซิร์ฟเวอร์แอปพลิเคชันและเซิร์ฟเวอร์ SQL
• กำหนดค่าไฟร์วอลล์ของเซิร์ฟเวอร์เพื่อไม่ให้ใช้เซิร์ฟเวอร์ MS SQL ของบุคคลที่สาม
• ใช้เครื่องมือรักษาความปลอดภัยอินทราเน็ตเพื่อแยกความเป็นไปได้ที่คอมพิวเตอร์ที่ไม่ได้รับอนุญาตจะปรากฏใน เครือข่ายท้องถิ่น(IPSec, นโยบายความปลอดภัยกลุ่ม, ไฟร์วอลล์, ฯลฯ );
• ไม่อนุญาตให้สิทธิ์ผู้ดูแลระบบ USER1CV8SERVER บนแอปพลิเคชันเซิร์ฟเวอร์ไม่ว่าในกรณีใด

การใช้โค้ดที่รันบนเซิร์ฟเวอร์

เมื่อใช้ 1C เวอร์ชันไคลเอ็นต์-เซิร์ฟเวอร์ นักพัฒนาสามารถแจกจ่ายการเรียกใช้โค้ดระหว่างไคลเอ็นต์และแอปพลิเคชันเซิร์ฟเวอร์ เพื่อให้โค้ด (ขั้นตอนหรือฟังก์ชัน) ทำงานบนเซิร์ฟเวอร์เท่านั้น จำเป็นต้องวางไว้ในโมดูลทั่วไปที่มีการตั้งค่าคุณสมบัติ "เซิร์ฟเวอร์" และในกรณีที่อนุญาตให้เรียกใช้โมดูล ไม่เพียงแต่บนเซิร์ฟเวอร์เท่านั้น ให้วางโค้ดในส่วนที่จำกัด "# If Server ":

# ถ้าเซิร์ฟเวอร์แล้ว
ฟังก์ชัน OnServer (Param1, Param2 = 0) ส่งออก // ฟังก์ชันนี้ทำงานบนเซิร์ฟเวอร์
พารามิเตอร์ 1 = พารามิเตอร์ 1 + 12;
การกลับมาของ Param1;
EndFunction
#EndIf

เมื่อใช้รหัสที่ทำงานบนเซิร์ฟเวอร์ โปรดทราบว่า:

• รหัสถูกเรียกใช้ด้วยสิทธิ์ USER1CV8SERVER บนแอปพลิเคชันเซิร์ฟเวอร์ (มีอ็อบเจ็กต์ COM และไฟล์เซิร์ฟเวอร์)
• เซสชันผู้ใช้ทั้งหมดดำเนินการโดยอินสแตนซ์เดียวของบริการ ตัวอย่างเช่น สแต็กโอเวอร์โฟลว์บนเซิร์ฟเวอร์จะทำให้ผู้ใช้ที่ใช้งานอยู่ทั้งหมดถูกตัดการเชื่อมต่อ
• การดีบักโมดูลเซิร์ฟเวอร์เป็นเรื่องยาก (เช่น คุณไม่สามารถตั้งค่าเบรกพอยต์ในดีบักเกอร์) แต่ต้องทำ
• การถ่ายโอนการควบคุมจากไคลเอนต์ไปยังเซิร์ฟเวอร์แอปพลิเคชันและในทางกลับกันอาจต้องใช้ทรัพยากรจำนวนมากพร้อมพารามิเตอร์ที่ส่งจำนวนมาก
• การใช้เครื่องมือโต้ตอบ (แบบฟอร์ม เอกสารสเปรดชีต, กล่องโต้ตอบ), รายงานภายนอก และการประมวลผลโค้ดบนแอปพลิเคชันเซิร์ฟเวอร์ไม่สามารถทำได้
• ไม่อนุญาตให้ใช้ตัวแปรส่วนกลาง (ตัวแปรโมดูลแอปพลิเคชันที่ประกาศด้วยตัวบ่งชี้ "ส่งออก")

สำหรับรายละเอียดเพิ่มเติม โปรดดูที่ [ITS15] และบทความอื่นๆ ของ ITS

แอปพลิเคชันเซิร์ฟเวอร์ต้องมีข้อกำหนดด้านความน่าเชื่อถือเป็นพิเศษ ในระบบไคลเอนต์-เซิร์ฟเวอร์ที่สร้างขึ้นอย่างถูกต้อง ต้องเป็นไปตามเงื่อนไขต่อไปนี้:

• แอปพลิเคชันไคลเอ็นต์ไม่ควรขัดจังหวะเซิร์ฟเวอร์ (ยกเว้นกรณีการดูแลระบบ)
• เซิฟเวอร์ไม่สามารถรันได้ รหัสโปรแกรมได้รับจากลูกค้า;
• ทรัพยากรควรกระจาย "อย่างยุติธรรม" ผ่านการเชื่อมต่อไคลเอ็นต์ เพื่อให้มั่นใจว่าเซิร์ฟเวอร์พร้อมใช้งานโดยไม่คำนึงถึงโหลดปัจจุบัน
• ในกรณีที่ไม่มีการล็อกข้อมูล การเชื่อมต่อไคลเอ็นต์จะไม่ส่งผลต่องานของกันและกัน
• ไม่มีส่วนต่อประสานกับผู้ใช้บนเซิร์ฟเวอร์ แต่ควรพัฒนาเครื่องมือตรวจสอบและบันทึก

โดยทั่วไป ระบบ 1C ถูกสร้างขึ้นในลักษณะที่สอดคล้องกับข้อกำหนดเหล่านี้ (เช่น เป็นไปไม่ได้ที่จะบังคับให้ดำเนินการประมวลผลภายนอกบนเซิร์ฟเวอร์) แต่ยังมีคุณสมบัติที่ไม่พึงประสงค์หลายประการ ดังนั้น:

คำแนะนำ:ในการพัฒนาฝั่งเซิร์ฟเวอร์ของการดำเนินการ ขอแนะนำให้ปฏิบัติตามหลักการของอินเทอร์เฟซขั้นต่ำ เหล่านั้น. จำนวนรายการไปยังโมดูลเซิร์ฟเวอร์จากแอปพลิเคชันไคลเอนต์ควร จำกัด มากและควรควบคุมพารามิเตอร์อย่างเคร่งครัด คำแนะนำ:เมื่อได้รับพารามิเตอร์ของโพรซีเดอร์และฟังก์ชันบนเซิร์ฟเวอร์ จำเป็นต้องตรวจสอบพารามิเตอร์ (ตรวจสอบว่าพารามิเตอร์สอดคล้องกับประเภทและช่วงของค่าที่คาดไว้หรือไม่) วิธีนี้ไม่ได้ทำในโซลูชันมาตรฐาน แต่ขอแนะนำให้ใช้การตรวจสอบความถูกต้องที่จำเป็นในการออกแบบของคุณเอง คำแนะนำ:เมื่อสร้างข้อความคำขอ (และยิ่งกว่านั้นคือพารามิเตอร์คำสั่ง Run) ทางฝั่งเซิร์ฟเวอร์ อย่าใช้สตริงที่ได้รับจากแอปพลิเคชันไคลเอ็นต์

คำแนะนำทั่วไปคือการทำความคุ้นเคยกับหลักการสร้างความปลอดภัย เว็บ- การใช้งานฐานข้อมูลและการทำงานบนหลักการที่คล้ายคลึงกัน ความคล้ายคลึงกันนั้นมีความสำคัญมาก อย่างแรก เช่นเดียวกับเว็บแอปพลิเคชัน แอปพลิเคชันเซิร์ฟเวอร์เป็นเลเยอร์กลางระหว่างฐานข้อมูลและอินเทอร์เฟซผู้ใช้ (ความแตกต่างหลักคือเว็บเซิร์ฟเวอร์สร้างอินเทอร์เฟซผู้ใช้) ประการที่สอง จากมุมมองของความปลอดภัย ข้อมูลที่ได้รับจากลูกค้าไม่สามารถเชื่อถือได้ เนื่องจาก เป็นไปได้ที่จะเปิดรายงานภายนอกและการประมวลผล

ผ่านพารามิเตอร์

การส่งพารามิเตอร์ไปยังฟังก์ชัน (ขั้นตอน) ที่ดำเนินการบนเซิร์ฟเวอร์เป็นปัญหาที่ค่อนข้างละเอียดอ่อน สาเหตุหลักมาจากความจำเป็นในการถ่ายโอนระหว่างกระบวนการเซิร์ฟเวอร์แอปพลิเคชันและไคลเอนต์ เมื่อการควบคุมถูกถ่ายโอนจากฝั่งไคลเอ็นต์ไปยังฝั่งเซิร์ฟเวอร์ พารามิเตอร์ที่ส่งทั้งหมดจะถูกจัดลำดับ ถ่ายโอนไปยังเซิร์ฟเวอร์ โดยจะ "แตกไฟล์" และใช้งาน เมื่อย้ายจากฝั่งเซิร์ฟเวอร์ไปยังฝั่งไคลเอ็นต์ กระบวนการจะย้อนกลับ ควรสังเกตว่ารูปแบบนี้จัดการพารามิเตอร์ที่ส่งผ่านอย่างถูกต้องโดยการอ้างอิงและตามค่า เมื่อถ่ายโอนพารามิเตอร์ จะใช้ข้อจำกัดต่อไปนี้:

• เฉพาะค่าที่ไม่สามารถเปลี่ยนแปลงได้ (นั่นคือค่าที่ไม่สามารถเปลี่ยนแปลงได้) ระหว่างไคลเอนต์และเซิร์ฟเวอร์ (ในทั้งสองทิศทาง): ประเภทดั้งเดิม, การอ้างอิง, คอลเล็กชั่นสากล, ค่าการแจงนับระบบ, การจัดเก็บค่า หากคุณพยายามส่งอย่างอื่น แอปพลิเคชันไคลเอนต์หยุดทำงาน (แม้ว่าเซิร์ฟเวอร์จะพยายามส่งพารามิเตอร์ที่ไม่ถูกต้อง)
• เมื่อส่งผ่านพารามิเตอร์ ไม่แนะนำให้ถ่ายโอนข้อมูลจำนวนมาก (เช่น สตริงที่มีอักขระมากกว่า 1 ล้านตัว) ซึ่งอาจส่งผลเสียต่อประสิทธิภาพของเซิร์ฟเวอร์
• คุณไม่สามารถส่งผ่านพารามิเตอร์ที่มีการอ้างอิงแบบวงกลม ทั้งจากเซิร์ฟเวอร์ไปยังไคลเอนต์ และในทางกลับกัน เมื่อมีการพยายามส่งผ่านพารามิเตอร์ดังกล่าว แอปพลิเคชันไคลเอนต์จะขัดข้อง (แม้ว่าเซิร์ฟเวอร์จะพยายามส่งพารามิเตอร์ที่ไม่ถูกต้อง)
• ไม่แนะนำให้ถ่ายโอนชุดข้อมูลที่ซับซ้อนมาก เมื่อพยายามส่งผ่านพารามิเตอร์ที่มีระดับการซ้อนที่ใหญ่มาก เซิร์ฟเวอร์จะขัดข้อง (!)

ความสนใจ! คุณลักษณะที่ไม่พึงประสงค์ที่สุดในขณะนี้อาจเป็นข้อผิดพลาดในการส่งผ่านค่าที่ซับซ้อน ตัวอย่างเช่น รหัส: Nesting Level = 1250;
ม = อาร์เรย์ใหม่;
ส่งพารามิเตอร์ = M;
สำหรับ MF = 1 โดยการทำรังระดับรอบ
MVint = อาร์เรย์ใหม่;
เอ็มเพิ่ม (MVintr);
M = MVintr;
สิ้นสุดรอบ;
ฟังก์ชันเซิร์ฟเวอร์ (PassedParameter);

ทำให้เซิร์ฟเวอร์หยุดทำงานโดยที่ผู้ใช้ทั้งหมดถูกตัดการเชื่อมต่อ และสิ่งนี้จะเกิดขึ้นก่อนการควบคุมจะถูกโอนไปยังรหัสภาษาที่ฝังไว้

การใช้ฟังก์ชันที่ไม่ปลอดภัยทางฝั่งเซิร์ฟเวอร์

ฟีเจอร์ภาษาที่ฝังอยู่บางรายการไม่สามารถใช้ในโค้ดที่ทำงานบนเซิร์ฟเวอร์แอปพลิเคชันได้ แต่แม้ในเครื่องมือที่มีอยู่ก็ยังมีโครงสร้าง "ปัญหา" จำนวนมากที่สามารถจำแนกคร่าวๆ ได้ดังนี้:

• สามารถให้ความสามารถในการรันโค้ดที่ไม่มีอยู่ในการกำหนดค่า (กลุ่ม "Code Execution")
• สามารถให้ข้อมูลเกี่ยวกับไฟล์และระบบปฏิบัติการของผู้ใช้แก่แอปพลิเคชันไคลเอนต์หรือดำเนินการที่ไม่เกี่ยวข้องกับการทำงานกับข้อมูล ("การละเมิดสิทธิ์")
• สามารถทำให้เซิร์ฟเวอร์หยุดฉุกเฉินหรือใช้ทรัพยากรที่มีขนาดใหญ่มาก (กลุ่ม "เซิร์ฟเวอร์ล้มเหลว")
• สามารถทำให้เกิดความล้มเหลวในการทำงานของลูกค้า (กลุ่ม "ไคลเอนต์ล้มเหลว") - ไม่พิจารณาประเภทนี้ ตัวอย่าง: การส่งค่าที่เปลี่ยนแปลงได้ไปยังเซิร์ฟเวอร์
• ข้อผิดพลาดของอัลกอริธึมการเขียนโปรแกรม (ลูปไม่สิ้นสุด การเรียกซ้ำไม่จำกัด ฯลฯ) ("ข้อผิดพลาดในการเขียนโปรแกรม")

โครงสร้างปัญหาหลักที่ฉันรู้จัก (พร้อมตัวอย่าง) มีการระบุไว้ด้านล่าง:

ขั้นตอนการดำเนินการ (<Строка>)

การรันโค้ดเรียกใช้งานโค้ดบางส่วนที่ส่งผ่านไปยังค่าสตริง เมื่อใช้งานบนเซิร์ฟเวอร์ คุณต้องแน่ใจว่าข้อมูลที่ได้รับจากไคลเอนต์จะไม่ถูกใช้เป็นพารามิเตอร์ ตัวอย่างเช่น การใช้งานต่อไปนี้ไม่ถูกต้อง:

# ถ้าเซิร์ฟเวอร์แล้ว
ขั้นตอนบนเซิร์ฟเวอร์ (Param1) ส่งออก
ดำเนินการ (Param1);
สิ้นสุดขั้นตอน
#EndIf

พิมพ์ "COMObject" (ตัวสร้างใหม่ COMObject (<Имя>, <Имя сервера>))

สร้างวัตถุ COM ของแอปพลิเคชันภายนอกที่มีสิทธิ์ USER1CV8SERVER บนแอปพลิเคชันเซิร์ฟเวอร์ (หรือคอมพิวเตอร์อื่นที่ระบุ) เมื่อใช้งานบนเซิร์ฟเวอร์ ตรวจสอบให้แน่ใจว่าไม่มีพารามิเตอร์ใดถูกส่งผ่านจากแอปพลิเคชันไคลเอนต์ อย่างไรก็ตาม ทางฝั่งเซิร์ฟเวอร์ การใช้คุณสมบัตินี้เมื่อนำเข้า / ส่งออก ส่งข้อมูลทางอินเทอร์เน็ต การใช้ฟังก์ชันที่ไม่ได้มาตรฐาน ฯลฯ จะมีประสิทธิภาพ

ฟังก์ชัน GetCOMObject (<Имя файла>, <Имя класса COM>)

การละเมิดสิทธิ์และการใช้รหัสคล้ายกับก่อนหน้านี้ รับเฉพาะวัตถุ COM ที่สอดคล้องกับไฟล์เท่านั้น

ขั้นตอนและฟังก์ชัน ComputerName (), TempFilesDirectory () , ProgramsDirectory (), ผู้ใช้ Windows ()

การละเมิดสิทธิอนุญาตให้ดำเนินการบนเซิร์ฟเวอร์เพื่อค้นหารายละเอียดขององค์กรของระบบย่อยเซิร์ฟเวอร์ เมื่อใช้งานบนเซิร์ฟเวอร์ ตรวจสอบให้แน่ใจว่าข้อมูลไม่ได้ถูกส่งไปยังไคลเอนต์ หรือไม่สามารถใช้ได้กับโอเปอเรเตอร์โดยไม่ได้รับอนุญาตอย่างเหมาะสม ให้ความสนใจเป็นพิเศษกับข้อเท็จจริงที่ว่าข้อมูลสามารถส่งกลับในพารามิเตอร์ที่ส่งผ่านโดยการอ้างอิงได้

ขั้นตอนและฟังก์ชันสำหรับการทำงานกับไฟล์ (CopyFile, FindFiles, CombineFiles และอื่นๆ อีกมากมาย) รวมถึงประเภท "ไฟล์"

การละเมิดสิทธิอนุญาตให้ดำเนินการบนเซิร์ฟเวอร์เพื่อเข้าถึงไฟล์ในเครื่อง (และอยู่ในเครือข่าย) ทั่วไปที่สามารถเข้าถึงได้ภายใต้สิทธิ์ผู้ใช้ USER1CV8SERVER หากใช้อย่างจงใจ ใช้งานอย่างมีประสิทธิภาพ เช่น นำเข้า / ส่งออกข้อมูลบนเซิร์ฟเวอร์ได้

อย่าลืมตรวจสอบสิทธิ์ผู้ใช้ 1C ก่อนใช้ฟังก์ชันเหล่านี้ ในการตรวจสอบสิทธิ์ของผู้ใช้ คุณสามารถใช้โครงสร้างต่อไปนี้ในโมดูลเซิร์ฟเวอร์:

# ถ้าเซิร์ฟเวอร์แล้ว
ขั้นตอน ExecuteWork พร้อมไฟล์ () ส่งออก
RoleAdministrator = Metadata.Role.Administrator;
ผู้ใช้ = SessionParameters.CurrentUser;
ถ้า User.Roles.Contains (RoleAdministrator) แล้ว
// รหัสสำหรับการทำงานกับไฟล์จะถูกดำเนินการที่นี่
สิ้นสุดถ้า;
#EndIf

อย่าลืมตรวจสอบพารามิเตอร์หากคุณใช้ขั้นตอนและฟังก์ชันเหล่านี้ มิฉะนั้น อาจมีความเสี่ยงที่จะก่อให้เกิดอันตรายต่อแอปพลิเคชันเซิร์ฟเวอร์ 1C โดยไม่ได้ตั้งใจหรือโดยเจตนา เช่น เมื่อเรียกใช้โค้ดบนเซิร์ฟเวอร์:

เส้นทาง = "C: \ Documents and Settings \ All Users \ Application Data \ 1C \ 1Cv8 \";
MoveFile (เส้นทาง + "srvrib.lst", เส้นทาง + "Here'sWhereFile");

หลังจากรันโค้ดดังกล่าวบนเซิร์ฟเวอร์แล้ว หากผู้ใช้ USER1CV8SERVER ได้รับอนุญาตให้เปลี่ยนตามที่อธิบายไว้ข้างต้น และหลังจากเริ่มกระบวนการเซิร์ฟเวอร์ใหม่ (โดยค่าเริ่มต้น 3 นาทีหลังจากที่ผู้ใช้ทั้งหมดออกจากระบบ) คำถามใหญ่จะเกิดขึ้นเกี่ยวกับการเริ่มเซิร์ฟเวอร์ . แต่มันเป็นไปได้และ การกำจัดอย่างสมบูรณ์ไฟล์ ...

ประเภท "XBase", "BinaryData", "Read XML", "Write XML", "Transform XSL", "Write ZipFile", "ReadZipFile", "ReadText", "WriteText"

การละเมิดสิทธิพวกเขาอนุญาตให้ดำเนินการบนเซิร์ฟเวอร์เพื่อเข้าถึงไฟล์บางประเภทในเครื่อง (และตั้งอยู่บนเครือข่าย) และอ่าน / เขียนภายใต้สิทธิ์ของผู้ใช้ USER1CV8SERVER หากใช้โดยเจตนา เป็นไปได้ที่จะใช้งานอย่างมีประสิทธิภาพ เช่น นำเข้า / ส่งออกข้อมูลบนเซิร์ฟเวอร์ การบันทึกฟังก์ชันบางอย่าง และการแก้ไขงานด้านการดูแลระบบ โดยทั่วไป คำแนะนำจะเหมือนกับย่อหน้าก่อนหน้า แต่คุณควรคำนึงถึงความเป็นไปได้ในการถ่ายโอนข้อมูลของไฟล์เหล่านี้ (แต่ไม่ใช่วัตถุทุกประเภทเหล่านี้) ระหว่างส่วนไคลเอ็นต์และเซิร์ฟเวอร์

ประเภทข้อมูลระบบ

การละเมิดสิทธิอนุญาต หากมีการใช้ข้อมูลอย่างไม่ถูกต้องและถ่ายโอนไปยังส่วนไคลเอนต์ของแอปพลิเคชัน คุณสามารถรับข้อมูลเกี่ยวกับแอปพลิเคชันเซิร์ฟเวอร์ ขอแนะนำให้จำกัดสิทธิ์ในการใช้งานเมื่อใช้งาน

ประเภท "InternetConnection", "InternetMail", "InternetProxy", "HTTPConnection", "FTPConnection"

การละเมิดสิทธิเมื่อใช้งานบนเซิร์ฟเวอร์ จะเชื่อมต่อกับพีซีระยะไกลจากเซิร์ฟเวอร์แอปพลิเคชันภายใต้สิทธิ์ USER1CV8SERVER คำแนะนำ:

• การควบคุมพารามิเตอร์เมื่อเรียกใช้เมธอด
• การควบคุมสิทธิ์ของผู้ใช้ 1C.
• ข้อ จำกัด ที่รุนแรงเกี่ยวกับสิทธิ์ของผู้ใช้ USER1CV8SERVER ในการเข้าถึงเครือข่าย
• การกำหนดค่าที่ถูกต้องของไฟร์วอลล์บนแอปพลิเคชันเซิร์ฟเวอร์ 1C

เมื่อใช้อย่างถูกต้อง จะสะดวกในการจัดระเบียบ เช่น การส่งอีเมลจากเซิร์ฟเวอร์แอปพลิเคชัน

พิมพ์ "InformationBaseUserManager", "InformationBaseUser"

การละเมิดสิทธิหากใช้อย่างไม่ถูกต้อง (ในโมดูลที่มีสิทธิพิเศษ) คุณสามารถเพิ่มผู้ใช้หรือเปลี่ยนพารามิเตอร์การอนุญาตของผู้ใช้ที่มีอยู่ได้

รูปแบบฟังก์ชัน

เซิร์ฟเวอร์ขัดข้องใช่! ฟังก์ชันที่ดูเหมือนไม่เป็นอันตรายนี้ หากคุณไม่ได้ควบคุมพารามิเตอร์และดำเนินการบนเซิร์ฟเวอร์ อาจทำให้แอปพลิเคชันเซิร์ฟเวอร์หยุดทำงานอย่างผิดปกติ ข้อผิดพลาดปรากฏขึ้นเมื่อจัดรูปแบบตัวเลขและใช้โหมดเอาต์พุตสำหรับเลขศูนย์นำหน้าและอักขระจำนวนมาก เช่น

รูปแบบ (1, "CHT = 999; CHVN =");

ฉันหวังว่าข้อผิดพลาดนี้จะได้รับการแก้ไขในแพลตฟอร์มรุ่นถัดไป แต่สำหรับตอนนี้ ในการเรียกใช้ฟังก์ชันนี้ทั้งหมดที่สามารถดำเนินการบนเซิร์ฟเวอร์ได้ ให้ตรวจสอบพารามิเตอร์การโทร

ขั้นตอนและฟังก์ชันสำหรับการจัดเก็บค่า (ValueInStringInternally, ValueInFile)

เซิร์ฟเวอร์ขัดข้องฟังก์ชันเหล่านี้ไม่ได้จัดการการอ้างอิงแบบวงกลมในคอลเล็กชันและการซ้อนที่ลึกมาก ดังนั้นจึงอาจขัดข้องในบางกรณีที่พิเศษมาก

ข้อผิดพลาดของขอบเขตและค่าพิเศษของพารามิเตอร์ในฟังก์ชัน การควบคุมการดำเนินการ

ปัญหาหนึ่งที่สามารถพบได้เมื่อใช้เซิร์ฟเวอร์คือ "ความรับผิดชอบ" ขนาดใหญ่ของฟังก์ชันเซิร์ฟเวอร์ (ความเป็นไปได้ของการยกเลิกแอปพลิเคชันเซิร์ฟเวอร์ทั้งหมดอย่างผิดปกติเนื่องจากข้อผิดพลาดในการเชื่อมต่อครั้งเดียวและการใช้ "พื้นที่ทรัพยากร" หนึ่งรายการ สำหรับการเชื่อมต่อทั้งหมด) ดังนั้น ความจำเป็นในการควบคุมพารามิเตอร์หลักของรันไทม์:

• สำหรับฟังก์ชันภาษาในตัว ให้ตรวจสอบพารามิเตอร์การเรียกใช้ (ตัวอย่างเฉพาะคือฟังก์ชัน "รูปแบบ")
• เมื่อใช้ลูป ตรวจสอบให้แน่ใจว่าเงื่อนไขการออกลูปถูกทริกเกอร์ หากการวนซ้ำอาจไม่มีที่สิ้นสุด ให้จำกัดจำนวนการวนซ้ำ: MaximumIterationCount = 1,000,000;
  นับซ้ำ = 1;
  ลาก่อน
  ฟังก์ชันที่ไม่สามารถคืนค่าที่เป็นเท็จ ()
  AND (ตัวนับการวนซ้ำ<МаксимальноеЗначениеСчетчикаИтераций) Цикл

  // .... เนื้อความของวง
  ตัวนับการวนซ้ำ = ตัวนับการวนซ้ำ + 1;
  สิ้นสุดรอบ;
  IfIterationCount> MaximumIterationCounterValue จากนั้น
  // .... จัดการเหตุการณ์ของการดำเนินการรอบที่ยาวเกินไป
  สิ้นสุดถ้า;

• เมื่อใช้การเรียกซ้ำ ให้จำกัดระดับการซ้อนสูงสุด
• เมื่อสร้างและดำเนินการค้นหา พยายามป้องกันไม่ให้มีการเลือกและการเลือกข้อมูลจำนวนมากเป็นเวลานาน (เช่น เมื่อใช้เงื่อนไข "IN HIERARCHY" อย่าใช้ค่าว่าง)
• เมื่อออกแบบอินโฟเบส ให้ระบุระยะขอบขนาดใหญ่เพียงพอของความจุหลักสำหรับตัวเลข (มิฉะนั้น การบวกและการคูณจะไม่เปลี่ยนและไม่สัมพันธ์กัน ซึ่งทำให้การดีบักทำได้ยาก)
• ในคำขอที่ดำเนินการได้ ให้ตรวจสอบตรรกะของงานสำหรับการมีอยู่ ค่า NULLและ งานที่ถูกต้องเงื่อนไขและนิพจน์แบบสอบถามโดยใช้ NULL
• เมื่อใช้คอลเล็กชัน ให้ควบคุมความสามารถในการถ่ายโอนระหว่างแอปพลิเคชันเซิร์ฟเวอร์และไคลเอ็นต์

การใช้เทอร์มินัลเข้าถึงฝั่งไคลเอ็นต์เพื่อจำกัดการเข้าถึง

ไม่ใช่เรื่องแปลกที่จะพบคำแนะนำในการใช้การเข้าถึงเทอร์มินัลเพื่อจำกัดการเข้าถึงข้อมูลและเพิ่มประสิทธิภาพโดยการรันโค้ดฝั่งไคลเอ็นต์บนเซิร์ฟเวอร์เทอร์มินัล ใช่ หากกำหนดค่าไว้อย่างเหมาะสม การใช้การเข้าถึงเทอร์มินัลสามารถเพิ่มระดับความปลอดภัยโดยรวมของระบบได้จริง แต่น่าเสียดายที่บ่อยครั้งจะพบกับความจริงที่ว่าในทางปฏิบัติ ความปลอดภัยของระบบจะลดลงเท่านั้น ลองหาว่าสิ่งนี้เกี่ยวข้องกับอะไร ขณะนี้มีสองวิธีทั่วไปในการจัดการเข้าถึงเทอร์มินัล ได้แก่ Microsoft Terminal Services (โปรโตคอล RDP) และ Citrix Metaframe Server (โปรโตคอล ICA) โดยทั่วไป เครื่องมือ Citrix มีตัวเลือกการจัดการการเข้าถึงที่ยืดหยุ่นกว่ามาก แต่ต้นทุนของโซลูชันเหล่านี้สูงขึ้นอย่างมาก เราจะพิจารณาเฉพาะคุณสมบัติพื้นฐานทั่วไปของโปรโตคอลทั้งสองที่สามารถลดระดับความปลอดภัยโดยรวมได้ มีเพียงสามอันตรายหลักเมื่อใช้การเข้าถึงเทอร์มินัล:

• ความสามารถในการบล็อกการทำงานของผู้ใช้รายอื่นโดยยึดทรัพยากรมากเกินไป
• การเข้าถึงข้อมูลของผู้ใช้รายอื่น
• การคัดลอกข้อมูลจากเซิร์ฟเวอร์เทอร์มินัลไปยังคอมพิวเตอร์ของผู้ใช้โดยไม่ได้รับอนุญาต

ไม่ว่าในกรณีใด บริการเทอร์มินัลจะช่วยให้คุณสามารถ:

• เพิ่มความน่าเชื่อถือของงาน (ในกรณีที่เครื่องปลายทางเกิดข้อผิดพลาด ผู้ใช้สามารถทำงานต่อจากที่เดิมได้ในภายหลัง)
• จำกัดการเข้าถึงแอปพลิเคชันไคลเอ็นต์และไฟล์ที่เก็บไว้
• โอนภาระการคำนวณจากที่ทำงานของผู้ใช้ไปยังเซิร์ฟเวอร์การเข้าถึงเทอร์มินัล
• จัดการการตั้งค่าระบบจากส่วนกลางมากขึ้น สำหรับผู้ใช้ การตั้งค่าที่บันทึกไว้จะถูกต้องโดยไม่คำนึงถึงคอมพิวเตอร์ที่พวกเขาเข้าสู่ระบบ
• ในบางกรณี คุณสามารถใช้โซลูชันเทอร์มินัลสำหรับการเข้าถึงระบบระยะไกลได้

จำเป็นต้องจำกัดจำนวนการเชื่อมต่อที่เป็นไปได้กับเซิร์ฟเวอร์เทอร์มินัลของผู้ใช้หนึ่งราย

เนื่องจาก "ตะกละ" ของแอปพลิเคชันไคลเอนต์ 1C เกี่ยวกับทรัพยากร จึงจำเป็นต้องจำกัดจำนวนสูงสุดของการเชื่อมต่อพร้อมกันของผู้ใช้หนึ่งราย (ผู้ดำเนินการ) ไปยังเซิร์ฟเวอร์เทอร์มินัล การเชื่อมต่อที่ใช้งานสามารถใช้หน่วยความจำได้ถึง 300 MB กับอินสแตนซ์เดียวเท่านั้น นอกจากหน่วยความจำแล้ว เวลาของโปรเซสเซอร์ยังถูกใช้อย่างแข็งขัน ซึ่งไม่ได้ส่งผลต่อความเสถียรของผู้ใช้เซิร์ฟเวอร์นี้ด้วย นอกเหนือจากการป้องกันการใช้ทรัพยากรเซิร์ฟเวอร์มากเกินไป ข้อจำกัดนี้สามารถป้องกันไม่ให้มีการใช้งานบัญชีของบุคคลอื่น ดำเนินการโดยการตั้งค่ามาตรฐานของเซิร์ฟเวอร์เทอร์มินัล

คุณต้องไม่อนุญาตให้แอปพลิเคชันไคลเอ็นต์ 1C มากกว่าหนึ่งหรือสองรายการทำงานพร้อมกันในการเชื่อมต่อเดียว

กำหนดโดยเหตุผลเดียวกับในย่อหน้าก่อน แต่ในทางเทคนิคยากกว่าที่จะนำไปใช้ ปัญหาคือแทบเป็นไปไม่ได้เลยที่จะป้องกันการรีสตาร์ท 1C โดยใช้เซิร์ฟเวอร์เทอร์มินัล (จะอธิบายไว้ด้านล่างว่าทำไม) ดังนั้นคุณต้องใช้คุณสมบัตินี้ในระดับของโซลูชันที่ใช้ (ซึ่งก็ไม่ดีเช่นกัน วิธีแก้ปัญหา เนื่องจากอาจมีช่วงที่ "หยุดทำงาน" ในกรณีที่การสิ้นสุดแอปพลิเคชันไม่ถูกต้อง จำเป็นต้องปรับแต่งโซลูชันที่นำไปใช้ในโมดูลแอปพลิเคชันและหนังสืออ้างอิงบางเล่ม ซึ่งจะทำให้การใช้การอัปเดตจาก 1C ซับซ้อนขึ้น) เป็นที่พึงปรารถนาอย่างยิ่งที่จะให้ผู้ใช้สามารถเรียกใช้ 2 แอปพลิเคชันเพื่อให้สามารถดำเนินการบางอย่างได้ (เช่น การสร้างรายงาน) ใน พื้นหลัง- น่าเสียดายที่แอปพลิเคชันไคลเอนต์เป็นแบบเธรดเดียว

ไม่แนะนำให้ให้สิทธิ์การเข้าถึงเซิร์ฟเวอร์เทอร์มินัลแก่ผู้ใช้ที่มีสิทธิ์เรียกใช้งานการคำนวณที่ใช้ทรัพยากรมากใน 1C หรือเพื่อป้องกันการเรียกใช้งานดังกล่าวระหว่างการใช้งานของผู้ใช้รายอื่น

แน่นอน เป็นการดีกว่าที่จะปล่อยให้การเข้าถึงเทอร์มินัลเซิร์ฟเวอร์เฉพาะกับผู้ใช้ที่ไม่ได้ใช้งาน เช่น การทำเหมืองข้อมูล แผนงานทางภูมิศาสตร์ การนำเข้า/ส่งออก และงานอื่นๆ ที่โหลดฝั่งไคลเอ็นต์ของแอปพลิเคชันอย่างจริงจัง หากยังคงมีความจำเป็นต้องแก้ไขงานดังกล่าวมีความจำเป็น: แจ้งให้ผู้ใช้ทราบว่างานเหล่านี้อาจส่งผลต่อประสิทธิภาพของผู้ใช้รายอื่นให้บันทึกเหตุการณ์การเริ่มต้นและสิ้นสุดของกระบวนการดังกล่าวลงในบันทึก อนุญาตให้ดำเนินการตามเวลาที่กำหนดเท่านั้น เป็นต้น

จำเป็นต้องตรวจสอบให้แน่ใจว่าผู้ใช้แต่ละคนสามารถเขียนเฉพาะไดเร็กทอรีที่กำหนดไว้อย่างเคร่งครัดของเซิร์ฟเวอร์เทอร์มินัลและผู้ใช้รายอื่นไม่สามารถเข้าถึงได้

อันดับแรก หากคุณไม่จำกัดความสามารถในการเขียนไปยังไดเร็กทอรีที่ใช้ร่วมกัน (เช่น ไดเร็กทอรีที่ติดตั้ง 1C) ผู้โจมตีสามารถเปลี่ยนพฤติกรรมของโปรแกรมสำหรับผู้ใช้ทั้งหมดได้ ประการที่สอง ข้อมูลของผู้ใช้รายหนึ่ง (ไฟล์ชั่วคราว ไฟล์สำหรับบันทึกการตั้งค่ารายงาน ฯลฯ) ไม่ควรมีให้ผู้ใช้อื่นของเซิร์ฟเวอร์เทอร์มินัลไม่ว่าในกรณีใด - โดยทั่วไปแล้ว กฎนี้จะสำเร็จในระหว่างการตั้งค่าปกติ ประการที่สาม ผู้โจมตียังคงมีโอกาสที่จะ "ทิ้งขยะ" พาร์ติชั่นเพื่อไม่ให้มีพื้นที่เหลือบนฮาร์ดดิสก์ ฉันรู้ว่าพวกเขาจะคัดค้านฉันว่าใน Windows ตั้งแต่ Windows 2000 มีกลไกโควต้า แต่นี่เป็นกลไกที่ค่อนข้างแพง และฉันแทบไม่เห็นการใช้งานจริงเลย

หากคำถามก่อนหน้านี้เกี่ยวกับการตั้งค่าการเข้าถึงโดยทั่วไปค่อนข้างง่ายต่อการนำไปใช้ งานง่าย (ดูเหมือน) เช่นการควบคุมการเข้าถึงไฟล์ของผู้ใช้จะถูกนำไปใช้อย่างไม่สำคัญ ขั้นแรก หากไม่ได้ใช้กลไกโควต้า ไฟล์ขนาดใหญ่ก็สามารถบันทึกได้ ประการที่สอง ระบบถูกสร้างขึ้นในลักษณะที่เกือบจะเป็นไปได้ที่จะบันทึกไฟล์เพื่อให้ผู้ใช้รายอื่นสามารถใช้งานได้

พิจารณาว่างานนั้นแก้ไขได้ยากอย่างยิ่ง ขอแนะนำให้ตรวจสอบเหตุการณ์ไฟล์ส่วนใหญ่

จำเป็นต้องปิดใช้งานการแมปของอุปกรณ์ดิสก์ เครื่องพิมพ์ และคลิปบอร์ดของไคลเอ็นต์เวิร์กสเตชัน

ใน RDP และ ICA เป็นไปได้ที่จะจัดระเบียบการเชื่อมต่ออัตโนมัติของดิสก์ เครื่องพิมพ์ พอร์ตคอมพอร์ตคลิปบอร์ดของเทอร์มินัลคอมพิวเตอร์ไปยังเซิร์ฟเวอร์ หากมีความเป็นไปได้นี้ แทบจะเป็นไปไม่ได้เลยที่จะห้ามไม่ให้เรียกใช้โค้ดภายนอกบนเซิร์ฟเวอร์เทอร์มินัลและบันทึกข้อมูลจาก 1C บนไคลเอ็นต์การเข้าถึงเทอร์มินัล อนุญาตคุณลักษณะเหล่านี้เฉพาะสำหรับบุคคลที่มีสิทธิ์ในการดูแลระบบเท่านั้น

การเข้าถึงไฟล์เครือข่ายจากเซิร์ฟเวอร์เทอร์มินัลต้องถูกจำกัด

หากยังไม่เสร็จสิ้น ผู้ใช้สามารถเรียกใช้โค้ดที่ไม่ต้องการหรือบันทึกข้อมูลได้อีกครั้ง เนื่องจากบันทึกปกติไม่ได้ติดตามเหตุการณ์ของไฟล์ (อย่างไรก็ตาม เป็นความคิดที่ดีสำหรับการใช้งานโดยนักพัฒนาแพลตฟอร์ม) และแทบจะเป็นไปไม่ได้เลยที่จะกำหนดค่าการตรวจสอบระบบทั่วทั้งเครือข่าย (จะมีทรัพยากรไม่เพียงพอสำหรับให้บริการ) จะดีกว่าที่ผู้ใช้สามารถส่งข้อมูลหรือพิมพ์หรือทางอีเมล ให้ความสนใจเป็นพิเศษว่าเซิร์ฟเวอร์เทอร์มินัลไม่ทำงานโดยตรงกับสื่อแบบถอดได้ของผู้ใช้

ไม่ควรทิ้งแอปพลิเคชันเซิร์ฟเวอร์ไว้บนเซิร์ฟเวอร์เทอร์มินัลเมื่อสร้างระบบที่ปลอดภัย

หากเปิดแอปพลิเคชันเซิร์ฟเวอร์บนคอมพิวเตอร์เครื่องเดียวกับแอปพลิเคชันไคลเอ็นต์ มีโอกาสมากมายที่จะขัดขวางการทำงานปกติ หากไม่สามารถแยกฟังก์ชันของเซิร์ฟเวอร์เทอร์มินัลและแอปพลิเคชันเซิร์ฟเวอร์ด้วยเหตุผลบางอย่าง ให้ใส่ใจเป็นพิเศษกับการเข้าถึงของผู้ใช้ในการเข้าถึงไฟล์ที่ใช้โดยแอปพลิเคชันเซิร์ฟเวอร์

จำเป็นต้องแยกความเป็นไปได้ของการเปิดตัวแอปพลิเคชันทั้งหมดยกเว้น 1C: Enterprise บนเซิร์ฟเวอร์เทอร์มินัล

นี่เป็นหนึ่งในความปรารถนาที่ยากที่สุดในการดำเนินการ ในการเริ่มต้น คุณต้องกำหนดค่า Group Security Policy สำหรับโดเมนอย่างเหมาะสม เทมเพลตการดูแลระบบและนโยบายการจำกัดซอฟต์แวร์ทั้งหมดต้องได้รับการกำหนดค่าอย่างถูกต้อง เพื่อทดสอบตัวเอง ตรวจสอบให้แน่ใจว่าอย่างน้อยคุณสมบัติต่อไปนี้ถูกบล็อก:

ความซับซ้อนของการดำเนินการตามข้อกำหนดนี้มักจะนำไปสู่ความเป็นไปได้ในการเปิดใช้เซสชัน 1C "พิเศษ" บนเซิร์ฟเวอร์เทอร์มินัล (แม้ว่าแอปพลิเคชันอื่นจะถูกจำกัด แต่หลักการก็เป็นไปไม่ได้ที่จะห้ามการเปิดตัว 1C โดยใช้ Windows)

พิจารณาข้อ จำกัด ของสมุดบันทึกปกติ (ผู้ใช้ทั้งหมดใช้โปรแกรมจากคอมพิวเตอร์เครื่องเดียว)

เห็นได้ชัดว่า เนื่องจากผู้ใช้เปิด 1C ในโหมดเทอร์มินัล จึงเป็นเซิร์ฟเวอร์เทอร์มินัลที่จะถูกบันทึกไว้ในบันทึกการลงทะเบียน จากคอมพิวเตอร์ที่ผู้ใช้เชื่อมต่อ บันทึกจะไม่รายงาน

Terminal Server - ความปลอดภัยหรือช่องโหว่?

ดังนั้น หลังจากพิจารณาคุณสมบัติหลักของเทอร์มินัล North แล้ว เราสามารถพูดได้ว่าเทอร์มินัล North อาจช่วยในระบบอัตโนมัติในการกระจายโหลดการคำนวณ แต่การสร้างระบบที่ปลอดภัยนั้นค่อนข้างยาก กรณีหนึ่งที่การใช้เทอร์มินัลเซิร์ฟเวอร์มีประสิทธิภาพมากที่สุดคือการเปิดใช้ 1C โดยไม่มี Windows Explorer ในโหมดเต็มหน้าจอสำหรับผู้ใช้ที่มีฟังก์ชันการทำงานที่จำกัดและอินเทอร์เฟซเฉพาะ

งานฝั่งลูกค้า

การใช้ Internet Explorer (IE)

เงื่อนไขประการหนึ่งสำหรับการทำงานปกติของส่วนไคลเอ็นต์ 1C คือการใช้ส่วนประกอบ Internet Explorer คุณต้องระวังให้มากกับส่วนประกอบเหล่านี้

ความสนใจ! ประการแรก หากโมดูลสปายแวร์หรือแอดแวร์แนบมากับ IE จะถูกโหลดแม้ว่าคุณจะดูไฟล์ HTML ใดๆ ใน 1C จนถึงตอนนี้ ฉันไม่เคยเห็นการใช้คุณลักษณะนี้อย่างมีสติ แต่ฉันได้พบโมดูล "สายลับ" ที่โหลดอยู่ในหนึ่งในองค์กรของหนึ่งในเครือข่ายลามกอนาจารเมื่อ 1C ทำงาน (โปรแกรมป้องกันไวรัสไม่ได้รับการอัพเดตอาการของ ซึ่งพบ: เมื่อตั้งค่าไฟร์วอลล์ เป็นที่ชัดเจนว่า 1C พยายามที่พอร์ต 80 เชื่อมต่อกับไซต์ลามก) อันที่จริง นี่เป็นอีกข้อโต้แย้งที่สนับสนุนความจริงที่ว่าการป้องกันควรครอบคลุม

ความสนใจ! ประการที่สอง ระบบ 1C อนุญาตให้ใช้ภาพยนตร์แฟลช, วัตถุ ActiveX, VBScript ในเอกสาร HTML ที่แสดง, ส่งข้อมูลไปยังอินเทอร์เน็ต, แม้แต่เปิดไฟล์ PDF (!), แม้ว่าในกรณีหลังจะขอให้ "เปิดหรือบันทึก" . ..โดยทั่วๆ ไป แล้วแต่ใจคุณปรารถนา ตัวอย่างการใช้ความสามารถในการดูและแก้ไข HTML ที่ไม่เหมาะสมทั้งหมด:

• สร้างเอกสาร HTML ใหม่ (ไฟล์ -> ใหม่ -> เอกสาร HTML)
• ไปที่แท็บ "ข้อความ" ของเอกสารเปล่า
• ลบข้อความ (ทั้งหมด)
• ไปที่แท็บ "มุมมอง" ของเอกสารนี้
• ใช้ drag-n-drop ย้ายไฟล์ที่มีนามสกุล SWF (เป็นไฟล์ภาพยนตร์แฟลช) จาก open explorer ไปยังหน้าต่างเอกสาร เช่น จากแคชของเบราว์เซอร์ แม้ว่าจะเป็นไปได้ด้วยของเล่น FLASH เพื่อความสนุกสนาน
• ช่างน่ารักอะไรเช่นนี้! คุณสามารถเรียกใช้ของเล่นใน 1C!

จากมุมมองด้านความปลอดภัยของระบบ ถือว่าผิดทั้งหมด จนถึงตอนนี้ ฉันไม่เคยเห็นการโจมตีพิเศษบน 1C ผ่านช่องโหว่นี้ แต่เป็นไปได้มากว่ามันจะกลายเป็นเรื่องของเวลาและคุณค่าของข้อมูลของคุณ

มีบางจุดเล็กน้อยที่ปรากฏขึ้นเมื่อทำงานกับฟิลด์เอกสาร HTML แต่มีการระบุไว้สองจุดหลัก แม้ว่าหากคุณใช้คุณลักษณะเหล่านี้อย่างสร้างสรรค์ คุณสามารถจัดระเบียบความสามารถอินเทอร์เฟซที่น่าตื่นตาตื่นใจอย่างแท้จริงในการทำงานร่วมกับ 1C ได้

การใช้รายงานภายนอกและการประมวลผล

ความสนใจ! รายงานภายนอกและการประมวลผล - ในอีกด้านหนึ่ง เป็นวิธีที่สะดวกในการใช้แบบฟอร์มเพิ่มเติมที่สามารถพิมพ์ได้ การรายงานตามกิจวัตร รายงานเฉพาะทาง ในทางกลับกัน เป็นวิธีที่มีศักยภาพในการหลีกเลี่ยงข้อจำกัดด้านความปลอดภัยของระบบจำนวนมากและขัดขวางการทำงานของเซิร์ฟเวอร์แอปพลิเคชัน (ตัวอย่างเช่น ดูด้านบนใน "การส่งพารามิเตอร์") ในระบบ 1C มีพารามิเตอร์พิเศษในชุดสิทธิ์สำหรับบทบาท "การเปิดการประมวลผลภายนอกแบบโต้ตอบ" แต่สิ่งนี้ไม่สามารถแก้ปัญหาได้อย่างสมบูรณ์ - สำหรับโซลูชันที่สมบูรณ์จำเป็นต้อง จำกัด วงผู้ใช้ให้แคบลงอย่างมาก ผู้ที่สามารถจัดการแบบฟอร์มการพิมพ์ภายนอก รายงานประจำ และคุณสมบัติมาตรฐานอื่นๆ ของโซลูชันมาตรฐานที่นำไปใช้โดยใช้การรักษาภายนอก ตัวอย่างเช่น ตามค่าเริ่มต้นใน SCP บทบาทผู้ใช้พื้นฐานทั้งหมดมีความสามารถในการทำงานกับหนังสืออ้างอิงของแบบฟอร์มเพิ่มเติมที่สามารถพิมพ์ได้ และที่จริงแล้ว นี่คือความสามารถในการใช้การประมวลผลภายนอกใดๆ

การใช้กลไกมาตรฐานของโซลูชันและแพลตฟอร์มทั่วไป (การแลกเปลี่ยนข้อมูล)

กลไกมาตรฐานบางอย่างอาจเป็นอันตรายได้ และในลักษณะที่คาดไม่ถึงเลยทีเดียว

รายการพิมพ์

รายการใดๆ (เช่น ไดเร็กทอรีหรือการลงทะเบียนข้อมูล) ในระบบสามารถพิมพ์หรือบันทึกลงในไฟล์ได้ เมื่อต้องการทำเช่นนี้ ก็เพียงพอแล้วที่จะใช้คุณลักษณะมาตรฐานจากเมนูบริบทและเมนู "การดำเนินการ":

โปรดทราบว่าแทบทุกอย่างที่ผู้ใช้เห็นในรายการสามารถส่งออกไปยังไฟล์ภายนอกได้ สิ่งเดียวที่สามารถแนะนำได้คือให้เก็บโปรโตคอลสำหรับการพิมพ์เอกสารบนเซิร์ฟเวอร์การพิมพ์ สำหรับรูปแบบที่สำคัญอย่างยิ่ง จำเป็นต้องกำหนดค่าแผงการดำเนินการที่เกี่ยวข้องกับฟิลด์ตารางที่ได้รับการป้องกัน เพื่อไม่ให้มีตัวเลือกในการแสดงรายการจากแผงนี้ และปิดใช้งานเมนูบริบท (ดูรูปที่ 6)

การแลกเปลี่ยนข้อมูลในฐานข้อมูลแบบกระจาย

รูปแบบการแลกเปลี่ยนข้อมูลค่อนข้างง่ายและอธิบายไว้ในเอกสารประกอบ หากผู้ใช้มีความสามารถในการแทนที่หลายไฟล์ เขาสามารถทำการเปลี่ยนแปลงระบบโดยไม่ได้รับอนุญาต (แม้ว่าจะใช้เวลานานมาก) ความสามารถในการสร้างฐานอุปกรณ์ต่อพ่วงเมื่อใช้แผนการแลกเปลี่ยนฐานข้อมูลแบบกระจายไม่ควรมีให้ผู้ปฏิบัติงานทั่วไป

การแลกเปลี่ยนข้อมูลมาตรฐาน XML

ในการแลกเปลี่ยนข้อมูลมาตรฐาน ซึ่งใช้สำหรับการแลกเปลี่ยนระหว่างการกำหนดค่าทั่วไป (เช่น "การจัดการการค้า" และ "การบัญชีองค์กร") เป็นไปได้ที่จะระบุตัวจัดการเหตุการณ์สำหรับการโหลดและยกเลิกการโหลดวัตถุในกฎการแลกเปลี่ยน สิ่งนี้ถูกนำไปใช้โดยรับตัวจัดการจากไฟล์และขั้นตอน "Execute ()" สำหรับการประมวลผลมาตรฐานของการโหลดและยกเลิกการโหลดไฟล์ (ขั้นตอน "Execute ()" จะเปิดขึ้นที่ฝั่งไคลเอ็นต์) เห็นได้ชัดว่าไม่ใช่เรื่องยากที่จะสร้างไฟล์แลกเปลี่ยนปลอมที่จะดำเนินการที่เป็นอันตราย สำหรับบทบาทผู้ใช้ส่วนใหญ่สำหรับโซลูชันทั่วไป การแลกเปลี่ยนถูกเปิดใช้งานโดยค่าเริ่มต้น

คำแนะนำ:จำกัดการเข้าถึงการแลกเปลี่ยน XML สำหรับผู้ใช้ส่วนใหญ่ (ปล่อยให้เป็นผู้ดูแลระบบ IS เท่านั้น) รักษาบันทึกการเริ่มต้นของการประมวลผลนี้ บันทึกไฟล์การแลกเปลี่ยน เช่น โดยการส่ง โดยอีเมลถึงผู้ดูแลระบบ IB ก่อนโหลด

การใช้รายงานทั่วไป โดยเฉพาะคอนโซลรายงาน

ปัญหาอีกประการหนึ่งคือผู้ใช้เข้าถึงรายงานทั่วไปโดยค่าเริ่มต้น โดยเฉพาะรายงานคอนโซลรายงาน รายงานนี้มีลักษณะเฉพาะว่าช่วยให้คุณสามารถปฏิบัติตามคำขอเกือบทั้งหมดของการรักษาความปลอดภัยข้อมูล และแม้ว่าระบบสิทธิ์ 1C (รวมถึง RLS) จะได้รับการกำหนดค่าค่อนข้างเข้มงวด แต่ก็ช่วยให้ผู้ใช้ได้รับข้อมูล "พิเศษ" จำนวนมาก และบังคับให้เซิร์ฟเวอร์ดำเนินการตามคำขอดังกล่าวซึ่งจะใช้ระบบทรัพยากรทั้งหมด

การใช้โหมดเต็มหน้าจอ (โหมดเดสก์ท็อป)

วิธีที่มีประสิทธิภาพที่สุดวิธีหนึ่งในการจัดระเบียบอินเทอร์เฟซเฉพาะที่มีการเข้าถึงฟังก์ชันการทำงานของโปรแกรมอย่างจำกัดคือโหมดเต็มหน้าจอของรูปแบบอินเทอร์เฟซหลัก (และอาจเป็นเพียงรูปแบบเดียว) ที่ใช้ ในกรณีนี้ ไม่มีคำถามเกี่ยวกับการช่วยสำหรับการเข้าถึง เช่น เมนู "ไฟล์" และการดำเนินการของผู้ใช้ทั้งหมดถูกจำกัดด้วยความสามารถของฟอร์มที่ใช้ สำหรับรายละเอียดเพิ่มเติม โปรดดู "คุณสมบัติของการใช้งานโหมดเดสก์ท็อป" บนดิสก์ ITS

สำรอง

การสำรองข้อมูลสำหรับเวอร์ชันไคลเอ็นต์-เซิร์ฟเวอร์ของ 1C สามารถทำได้สองวิธี: การอัปโหลดข้อมูลไปยังไฟล์ที่มีนามสกุล dt และสร้างการสำรองข้อมูลโดยใช้ SQL วิธีแรกมีข้อเสียค่อนข้างมาก: จำเป็นต้องมีการเข้าถึงแบบเอกสิทธิ์เฉพาะบุคคล การสร้างสำเนาเองใช้เวลานานกว่ามาก ในบางกรณี (หากโครงสร้างความปลอดภัยของข้อมูลถูกละเมิด) การสร้างที่เก็บถาวรเป็นไปไม่ได้ แต่มีข้อดีอย่างหนึ่งคือ ขนาดต่ำสุดของไฟล์เก็บถาวร สำหรับการสำรองข้อมูล SQL สิ่งที่ตรงกันข้ามคือความจริง: สำเนาถูกสร้างขึ้นในพื้นหลังโดยใช้เซิร์ฟเวอร์ SQL เนื่องจากโครงสร้างที่เรียบง่ายและขาดการบีบอัด - นี่เป็นกระบวนการที่รวดเร็วมากและตราบใดที่ความสมบูรณ์ทางกายภาพของ SQL ฐานข้อมูลไม่ถูกละเมิด กำลังสำรองข้อมูล แต่ขนาดของสำเนาจะตรงกับขนาดจริงของ IB ในสถานะขยาย (ไม่มีการบีบอัดข้อมูล) เนื่องจากข้อดีเพิ่มเติมของระบบสำรองข้อมูล MS SQL จึงเหมาะสมกว่าที่จะใช้ (อนุญาตให้สำรองข้อมูล 3 ประเภท: เต็ม ค่าส่วนต่าง สำเนาบันทึกธุรกรรม สามารถสร้างงานที่ดำเนินการเป็นประจำได้ ปรับใช้อย่างรวดเร็ว สำเนาสำรองและระบบสำรอง ใช้ความสามารถในการทำนายขนาดของพื้นที่ดิสก์ที่ต้องการ ฯลฯ ) ประเด็นหลักของการจัดระเบียบการสำรองข้อมูลจากมุมมองของความปลอดภัยของระบบคือ:

• จำเป็นต้องเลือกสถานที่จัดเก็บสำหรับการสำรองข้อมูลเพื่อไม่ให้ผู้ใช้ใช้งานได้
• ความจำเป็นในการจัดเก็บข้อมูลสำรองที่ระยะห่างทางกายภาพจากเซิร์ฟเวอร์ MS SQL (ในกรณีที่เกิดภัยธรรมชาติ ไฟไหม้ การโจมตี ฯลฯ)
• ความสามารถในการให้สิทธิ์ในการเริ่มการสำรองข้อมูลให้กับผู้ใช้ที่ไม่มีสิทธิ์เข้าถึงข้อมูลสำรอง

สำหรับข้อมูลโดยละเอียดเพิ่มเติม โปรดดูเอกสารประกอบ MS SQL

การเข้ารหัสข้อมูล

เพื่อป้องกันข้อมูลจากการเข้าถึงโดยไม่ได้รับอนุญาต มักใช้เครื่องมือเข้ารหัสต่างๆ (ทั้งซอฟต์แวร์และฮาร์ดแวร์) แต่ความเป็นไปได้ส่วนใหญ่ขึ้นอยู่กับความถูกต้องของการใช้งานและความปลอดภัยโดยรวมของระบบ เราจะพิจารณาการเข้ารหัสข้อมูลในขั้นตอนต่างๆ ของการถ่ายโอนและจัดเก็บข้อมูลโดยใช้วิธีการทั่วไปและข้อผิดพลาดในการออกแบบหลักของระบบโดยใช้วิธีการเข้ารหัส

การประมวลผลข้อมูลสามารถป้องกันได้หลายขั้นตอนหลัก:

• การถ่ายโอนข้อมูลระหว่างส่วนไคลเอนต์ของระบบและแอปพลิเคชันเซิร์ฟเวอร์
• การถ่ายโอนข้อมูลระหว่างเซิร์ฟเวอร์แอปพลิเคชันและ MS SQL Server
• ข้อมูลที่เก็บไว้ใน MS SQL Server (ไฟล์ข้อมูลบนฟิสิคัลดิสก์)
• การเข้ารหัสข้อมูลที่จัดเก็บในความปลอดภัยของข้อมูล
• ข้อมูลภายนอก (เกี่ยวกับความปลอดภัยของข้อมูล)

สำหรับข้อมูลที่จัดเก็บในฝั่งไคลเอ็นต์และบนเซิร์ฟเวอร์แอปพลิเคชัน (การตั้งค่าผู้ใช้ที่บันทึกไว้ รายการความปลอดภัยของข้อมูล ฯลฯ) การเข้ารหัสจะเหมาะสมในกรณีที่หายากมากเท่านั้น ดังนั้นจึงไม่นำมาพิจารณาในที่นี้ เมื่อใช้เครื่องมือเข้ารหัสลับ เราต้องไม่ลืมว่าการใช้งานของพวกเขาสามารถลดประสิทธิภาพของระบบโดยรวมได้อย่างมาก

ข้อมูลทั่วไปเกี่ยวกับการป้องกันการเข้ารหัสของการเชื่อมต่อเครือข่ายเมื่อใช้โปรโตคอล TCP / IP

ไม่มีการป้องกันทุกอย่าง เชื่อมต่อเครือข่ายเสี่ยงต่อการถูกสอดส่องและเข้าถึงโดยไม่ได้รับอนุญาต เพื่อป้องกัน คุณสามารถใช้การเข้ารหัสข้อมูลที่ระดับโปรโตคอลเครือข่าย ในการเข้ารหัสข้อมูลที่ส่งในเครือข่ายท้องถิ่น มักใช้เครื่องมือ IPSec ที่ระบบปฏิบัติการจัดให้

เครื่องมือ IPSec ให้การเข้ารหัสข้อมูลที่ส่งโดยใช้อัลกอริธึม DES และ 3DES ตลอดจนการตรวจสอบความสมบูรณ์โดยใช้ฟังก์ชันแฮช MD5 หรือ SHA1 IPSec สามารถทำงานได้ในสองโหมด: โหมดการขนส่งและโหมดทันเนล โหมดการขนส่งเหมาะกว่าสำหรับการรักษาความปลอดภัยการเชื่อมต่อ LAN โหมดทันเนลสามารถใช้เพื่อจัดระเบียบการเชื่อมต่อ VPN ระหว่างเซ็กเมนต์เครือข่ายแต่ละส่วน หรือเพื่อรักษาความปลอดภัยการเชื่อมต่อระยะไกลกับเครือข่ายท้องถิ่นผ่านช่องทางข้อมูลแบบเปิด

ข้อดีหลักของวิธีนี้คือ:

• ความสามารถในการจัดการความปลอดภัยจากส่วนกลางโดยใช้เครื่องมือ Active Directory
• ความสามารถในการแยกการเชื่อมต่อที่ไม่ได้รับอนุญาตไปยังเซิร์ฟเวอร์แอปพลิเคชันและเซิร์ฟเวอร์ MS SQL (เช่น เป็นไปได้ที่จะป้องกันการเพิ่มความปลอดภัยของข้อมูลบนแอปพลิเคชันเซิร์ฟเวอร์โดยไม่ได้รับอนุญาต)
• การกำจัด "การฟัง" ของการรับส่งข้อมูลเครือข่าย
• ไม่จำเป็นต้องเปลี่ยนพฤติกรรมของโปรแกรมประยุกต์ (ในกรณีนี้คือ 1C)
• มาตรฐานของการแก้ปัญหาดังกล่าว

อย่างไรก็ตาม วิธีการนี้มีข้อจำกัดและข้อเสีย:

• IPSec ไม่ได้ปกป้องข้อมูลจากการปลอมแปลงและดักฟังโดยตรงบนคอมพิวเตอร์ต้นทางและปลายทาง
• ปริมาณข้อมูลที่ส่งผ่านเครือข่ายนั้นมากกว่าโดยไม่ต้องใช้ IPSec เล็กน้อย
• เมื่อใช้ IPSec หลายตัว ภาระมากขึ้นไปยังโปรเซสเซอร์กลาง

คำอธิบายโดยละเอียดของการนำสิ่งอำนวยความสะดวกของ IPSec ไปใช้นั้นอยู่นอกเหนือขอบเขตของบทความนี้ และจำเป็นต้องมีความเข้าใจในหลักการพื้นฐานของโปรโตคอล IP ในการกำหนดค่าการป้องกันการเชื่อมต่ออย่างเหมาะสม โปรดอ่านเอกสารที่เกี่ยวข้อง

แยกจากกัน จำเป็นต้องพูดถึงแง่มุมต่างๆ ของข้อตกลงใบอนุญาตกับ 1C เมื่อจัดการการเชื่อมต่อ VPN ความจริงก็คือแม้ว่าจะไม่มีข้อ จำกัด ทางเทคนิคเมื่อเชื่อมต่อหลายส่วนของเครือข่ายท้องถิ่นหรือการเข้าถึงระยะไกลของคอมพิวเตอร์แยกต่างหากกับเครือข่ายท้องถิ่นมักจะต้องใช้อุปกรณ์พื้นฐานหลายอย่าง

การเข้ารหัสข้อมูลระหว่างการส่งระหว่างส่วนไคลเอนต์ของระบบและแอปพลิเคชันเซิร์ฟเวอร์

นอกเหนือจากการเข้ารหัสที่ โปรโตคอลเครือข่ายเป็นไปได้ที่จะเข้ารหัสข้อมูลที่ระดับของโปรโตคอล COM + ซึ่งกล่าวถึงในบทความ "ระเบียบการเข้าถึงของผู้ใช้ไปยังฐานข้อมูลในเวอร์ชันไคลเอนต์ - เซิร์ฟเวอร์" ของ ITS สำหรับการใช้งาน จำเป็นต้องตั้งค่าระดับการตรวจสอบสิทธิ์ "Packet Privacy" สำหรับการเรียกใช้แอปพลิเคชัน 1CV8 ใน Component Services เมื่อตั้งค่าเป็นโหมดนี้ แพ็กเกจจะได้รับการตรวจสอบสิทธิ์และเข้ารหัส รวมถึงข้อมูล ตลอดจนข้อมูลระบุตัวตนและลายเซ็นของผู้ส่ง

การเข้ารหัสข้อมูลระหว่างการส่งระหว่างเซิร์ฟเวอร์แอปพลิเคชันและ MS SQL Server

MS SQL Server มีเครื่องมือเข้ารหัสข้อมูลดังต่อไปนี้:

• สามารถใช้ Secure Sockets Layer (SSL) เมื่อถ่ายโอนข้อมูลระหว่างเซิร์ฟเวอร์แอปพลิเคชันและ MS SQL Server
• เมื่อใช้ไลบรารีเครือข่าย Multiprotocol การเข้ารหัสข้อมูลที่ระดับ RPC จะถูกใช้ นี่อาจเป็นการเข้ารหัสที่อ่อนแอกว่า SSL
• หากใช้โปรโตคอลหน่วยความจำที่ใช้ร่วมกัน (สิ่งนี้จะเกิดขึ้นหากแอปพลิเคชันเซิร์ฟเวอร์และ MS SQL Server อยู่ในคอมพิวเตอร์เครื่องเดียวกัน) การเข้ารหัสจะไม่ถูกใช้ในทุกกรณี

เพื่อกำหนดความจำเป็นในการเข้ารหัสข้อมูลที่ส่งทั้งหมดสำหรับเซิร์ฟเวอร์ MS SQL เฉพาะ ให้ใช้ยูทิลิตี้ "Server Network Utility" เรียกใช้และบนแท็บ "ทั่วไป" ให้ทำเครื่องหมายที่ช่อง "บังคับเข้ารหัสโปรโตคอล" วิธีการเข้ารหัสจะถูกเลือกขึ้นอยู่กับวิธีที่แอปพลิเคชันไคลเอนต์ใช้ (เช่น โดยแอปพลิเคชันเซิร์ฟเวอร์ 1C) ในการใช้ SSL คุณต้องกำหนดค่าผู้ออกใบรับรองบนเครือข่ายของคุณอย่างเหมาะสม

เพื่อกำหนดความจำเป็นในการเข้ารหัสข้อมูลที่ส่งทั้งหมดสำหรับเซิร์ฟเวอร์แอปพลิเคชันเฉพาะ คุณต้องใช้ยูทิลิตี้ "Client Network Utility" (ปกติจะอยู่ใน "C: \ WINNT \ system32 \ cliconfg.exe") เช่นเดียวกับในกรณีก่อนหน้านี้ บนแท็บ "ทั่วไป" ให้เลือกช่องทำเครื่องหมาย "บังคับเข้ารหัสโปรโตคอล"

โปรดทราบว่าการใช้การเข้ารหัสในกรณีนี้อาจส่งผลกระทบอย่างมากต่อประสิทธิภาพของระบบ โดยเฉพาะอย่างยิ่งเมื่อใช้การสืบค้นข้อมูลที่ส่งคืนข้อมูลจำนวนมาก

เพื่อป้องกันการเชื่อมต่อระหว่างเซิร์ฟเวอร์แอปพลิเคชันและ MS SQL Server อย่างเต็มที่ยิ่งขึ้นเมื่อใช้โปรโตคอล TCP / IP เราสามารถแนะนำการเปลี่ยนแปลงหลายอย่างในการตั้งค่าเริ่มต้น

ขั้นแรก คุณสามารถตั้งค่าพอร์ตอื่นที่ไม่ใช่พอร์ตมาตรฐาน (พอร์ต 1433 ถูกใช้โดยค่าเริ่มต้น) หากคุณตัดสินใจใช้พอร์ต TCP ที่ไม่ได้มาตรฐานสำหรับการสื่อสาร โปรดทราบว่า:

• MS SQL Server และ Application Server ต้องใช้พอร์ตเดียวกัน
• เมื่อใช้ไฟร์วอลล์ ต้องอนุญาตพอร์ตนี้
• คุณไม่สามารถตั้งค่าพอร์ตที่แอปพลิเคชันอื่นสามารถใช้บน MS SQL Server ได้ สำหรับการอ้างอิง โปรดดูที่ http://www.ise.edu/in-notes/iana/assignments/port-numbers (URL ที่นำมาจาก SQL Server Books Online)
• เมื่อใช้ MS SQL Server หลายอินสแตนซ์ โปรดอ่านเอกสารประกอบ MS SQL สำหรับการกำหนดค่า (ส่วน "การกำหนดค่าการเชื่อมต่อเครือข่าย")

ประการที่สอง ในการตั้งค่าโปรโตคอล TCP / IP บนเซิร์ฟเวอร์ MS SQL คุณสามารถเลือกช่องทำเครื่องหมาย "ซ่อนเซิร์ฟเวอร์" ซึ่งห้ามไม่ให้ตอบสนองต่อคำขอออกอากาศสำหรับอินสแตนซ์ของบริการ MS SQL Server นี้

การเข้ารหัสข้อมูล MS SQL ที่จัดเก็บไว้ในดิสก์

มีเครื่องมือซอฟต์แวร์และฮาร์ดแวร์ให้เลือกมากมายสำหรับการเข้ารหัสข้อมูลที่อยู่บนดิสก์ในเครื่อง (นี่คือความสามารถมาตรฐานของ Windows ในการใช้ EFS และการใช้คีย์ eToken และโปรแกรมของบริษัทอื่น เช่น Jetico Bestcrypt หรือ PGPDisk) งานหลักอย่างหนึ่งที่ดำเนินการโดยเครื่องมือเหล่านี้คือการปกป้องข้อมูลในกรณีที่สื่อสูญหาย (เช่น เมื่อเซิร์ฟเวอร์ถูกขโมย) ควรสังเกตเป็นพิเศษว่า Microsoft ไม่แนะนำให้จัดเก็บฐานข้อมูล MS SQL บนสื่อที่เข้ารหัส และนี่ค่อนข้างสมเหตุสมผล ปัญหาหลักในกรณีนี้คือผลผลิตที่ลดลงอย่างมากและ ปัญหาที่เป็นไปได้ความน่าเชื่อถือจากความล้มเหลว ปัจจัยที่สองที่ทำให้ชีวิตของผู้ดูแลระบบซับซ้อนคือต้องตรวจสอบให้แน่ใจว่าไฟล์ฐานข้อมูลทั้งหมดพร้อมใช้งาน ณ เวลาที่บริการ MS SQL เข้าถึงไฟล์เหล่านี้เป็นครั้งแรก (กล่าวคือ เป็นที่พึงปรารถนาที่จะไม่รวมการกระทำแบบโต้ตอบเมื่อเชื่อมต่อสื่อที่เข้ารหัส ).

เพื่อหลีกเลี่ยงไม่ให้ประสิทธิภาพของระบบลดลงอย่างเห็นได้ชัด คุณสามารถใช้ความสามารถของ MS SQL เพื่อสร้างฐานข้อมูลในไฟล์ต่างๆ แน่นอน ในกรณีนี้ เซิร์ฟเวอร์ 1C ไม่ควรสร้างฐานข้อมูล MS SQL เมื่อสร้างอินโฟเบส แต่ควรสร้างแยกต่างหาก ตัวอย่างสคริปต์ TSQL พร้อมความคิดเห็นแสดงอยู่ด้านล่าง:

ใช้มาสเตอร์
ไป
- สร้างฐานข้อมูล SomeData,
สร้างฐานข้อมูล SomeData
- ซึ่งมีข้อมูลอยู่ในกลุ่มไฟล์หลักทั้งหมด
ในระดับประถมศึกษา
- ไฟล์ข้อมูลหลักอยู่บนสื่อที่เข้ารหัส ( ไดรฟ์ตรรกะอี :)
- และมีขนาดเริ่มต้น 100 MB ขยายอัตโนมัติได้ถึง 200 MB ด้วย
- 20 Mb ขั้นตอน
(NAME = SomeData1,
FILENAME = "E: \ SomeData1.mdf",
ขนาด = 100MB,
สูงสุด = 200,
ไฟล์ = 2),
- ไฟล์ข้อมูลที่สองตั้งอยู่บนสื่อที่ไม่ได้เข้ารหัส (ไดรฟ์ลอจิคัล C :)
- และมีขนาดเริ่มต้น 100 MB สามารถเพิ่มได้ถึงขีดจำกัดโดยอัตโนมัติ
- พื้นที่ดิสก์ที่มีขั้นตอน 5% ของขนาดไฟล์ปัจจุบัน (ปัดเศษขึ้นเป็น 64 Kb)
(NAME = SomeData2,
FILENAME = "c: \ ไฟล์โปรแกรม \ microsoft sql server \ mssql \ data \ SomeData2.ndf",
ขนาด = 100MB,
MAXSIZE = ไม่จำกัด
ไฟล์ = 5%)
เข้าสู่ระบบ
- แม้ว่าบันทึกธุรกรรมสามารถแบ่งออกเป็นส่วน ๆ ได้ แต่สิ่งนี้ไม่ควรทำ
- ตั้งแต่ ไฟล์นี้เปลี่ยนแปลงบ่อยกว่ามากและล้างข้อมูลเป็นประจำ (เช่น เมื่อ
- การสร้างสำเนาสำรองของฐานข้อมูล)
(NAME = SomeDatalog,
FILENAME = "c: \ ไฟล์โปรแกรม \ microsoft sql server \ mssql \ data \ SomeData.ldf",
ขนาด = 10MB,
MAXSIZE = ไม่จำกัด
ไฟล์ = 10)
ไป
- เป็นการดีกว่าที่จะมอบความเป็นเจ้าของฐานข้อมูลให้กับผู้ใช้ในนามของทันที
- 1C จะเชื่อมต่อ ในการดำเนินการนี้ เราต้องประกาศฐานปัจจุบัน
- เพิ่งสร้าง
ใช้ SomeData
ไป
- และดำเนินการตามขั้นตอน sp_changedbowner
EXEC sp_changedbowner @loginame = "SomeData_dbowner"

การพูดนอกเรื่องเล็กน้อยเกี่ยวกับการเติบโตของขนาดไฟล์ข้อมูลโดยอัตโนมัติ โดยค่าเริ่มต้น สำหรับฐานข้อมูลที่สร้างขึ้นใหม่ ขนาดไฟล์จะเพิ่มขึ้นทีละ 10% ของขนาดไฟล์ปัจจุบัน นี่เป็นวิธีแก้ปัญหาที่ยอมรับได้อย่างสมบูรณ์สำหรับฐานข้อมูลขนาดเล็ก แต่ไม่ดีสำหรับฐานข้อมูลขนาดใหญ่: ด้วยขนาดฐานข้อมูลเช่น 20 GB ไฟล์ควรขยาย 2 GB พร้อมกัน แม้ว่าเหตุการณ์นี้จะเกิดขึ้นค่อนข้างน้อย แต่ก็สามารถเกิดขึ้นได้หลายสิบวินาที (ธุรกรรมอื่นๆ ทั้งหมดไม่ได้ใช้งานจริงในขณะนี้) ซึ่งหากเกิดขึ้นขณะทำงานกับฐานข้อมูล อาจทำให้เกิดความล้มเหลวได้ ผลเสียประการที่สองของการขยายตามสัดส่วน ซึ่งเกิดขึ้นเมื่อพื้นที่ดิสก์เกือบเต็มคือความน่าจะเป็นของความล้มเหลวก่อนเวลาอันควรเนื่องจากไม่เพียงพอ ที่ว่าง... ตัวอย่างเช่น หากพาร์ติชั่นดิสก์ขนาด 40 GB ถูกจัดสรรอย่างสมบูรณ์สำหรับหนึ่งฐานข้อมูล (ให้แม่นยำยิ่งขึ้นสำหรับหนึ่งไฟล์ของฐานข้อมูลนี้) ดังนั้นขนาดที่สำคัญของไฟล์ฐานข้อมูลซึ่งมีความจำเป็นเร่งด่วน (อย่างเร่งด่วนมาก จนถึงการขัดจังหวะ การใช้งานปกติของผู้ใช้) การจัดระบบจัดเก็บข้อมูลใหม่เป็นไฟล์ข้อมูลขนาด 35 GB ด้วยชุดการเพิ่มทีละ 10-20 MB คุณสามารถทำงานต่อได้จนถึง 39 GB

ดังนั้น แม้ว่ารายการที่ระบุจะระบุการเพิ่มขนาดของไฟล์ฐานข้อมูลหนึ่งไฟล์โดยเพิ่มขึ้นทีละ 5% สำหรับขนาดฐานข้อมูลขนาดใหญ่ จะเป็นการดีกว่าที่จะตั้งค่าการเพิ่มทีละ 10-20 MB เมื่อตั้งค่าการเพิ่มขึ้นสำหรับการเติบโตของขนาดของไฟล์ฐานข้อมูล จำเป็นต้องคำนึงว่าก่อนที่ไฟล์ใดไฟล์หนึ่งในกลุ่มไฟล์จะมีขนาดสูงสุด กฎจะใช้: ไฟล์ของกลุ่มไฟล์เดียว เติบโตพร้อมกันเมื่อเต็ม ดังนั้น ในตัวอย่างข้างต้น เมื่อไฟล์ SomeData1.mdf ถึงขนาดสูงสุด 200 MB ไฟล์ SomeData2.ndf จะมีขนาดประมาณ 1.1 GB

หลังจากสร้างฐานข้อมูลดังกล่าวแล้ว แม้ว่าไฟล์ที่ไม่มีการป้องกันของ SomeData2.ndf และ SomeData.ldf จะพร้อมใช้งานสำหรับผู้โจมตี จะเป็นการยากมากที่จะกู้คืนสถานะที่แท้จริงของฐานข้อมูล - ข้อมูล (รวมถึงข้อมูลเกี่ยวกับโครงสร้างตรรกะของฐานข้อมูล ) จะกระจายอยู่หลายไฟล์ นอกจากนี้ ข้อมูลสำคัญ (เช่น ไฟล์ที่ประกอบเป็นฐานข้อมูล) จะอยู่ในไฟล์ที่เข้ารหัส

แน่นอน หากใช้การจัดเก็บไฟล์ฐานข้อมูลโดยใช้วิธีการเข้ารหัส การสำรองข้อมูล (อย่างน้อยก็ไฟล์เหล่านี้) ไม่ควรดำเนินการบนสื่อที่ไม่ได้เข้ารหัส ใช้ไวยากรณ์คำสั่ง "BACKUP DATABASE" ที่เหมาะสมเพื่อสำรองไฟล์ฐานข้อมูลแต่ละไฟล์ โปรดทราบว่าแม้จะมีความเป็นไปได้ในการป้องกันการสำรองข้อมูลฐานข้อมูลด้วยรหัสผ่าน (ตัวเลือก "PASSWORD =" และ "MEDIAPASSWORD =" ของคำสั่ง "BACKUP DATABASE") การสำรองข้อมูลดังกล่าวจะไม่ถูกเข้ารหัส!

การเข้ารหัสข้อมูลเซิร์ฟเวอร์แอปพลิเคชันและไคลเอนต์ที่จัดเก็บไว้ในดิสก์

ในกรณีส่วนใหญ่ การจัดเก็บไฟล์ที่ใช้โดย 1C: Enterprise (ฝั่งไคลเอ็นต์และเซิร์ฟเวอร์แอปพลิเคชัน) บนสื่อที่เข้ารหัสนั้นไม่ถือว่าสมเหตุสมผล เนื่องจากมีค่าใช้จ่ายที่สูงเกินควร อย่างไรก็ตาม หากมีความจำเป็นดังกล่าว โปรดทราบว่าแอปพลิเคชันเซิร์ฟเวอร์และไคลเอ็นต์ ด้านข้างของแอปพลิเคชันมักสร้างไฟล์ชั่วคราว บ่อยครั้ง ไฟล์เหล่านี้สามารถยังคงอยู่หลังจากแอปพลิเคชันเสร็จสิ้น และแทบจะเป็นไปไม่ได้เลยที่จะรับประกันการลบออกโดยใช้ 1C ดังนั้นดูเหมือนว่าจะเข้ารหัสไดเร็กทอรีที่ใช้สำหรับไฟล์ชั่วคราวใน 1C หรือไม่ได้เก็บไว้ในดิสก์โดยใช้ RAM-drive (ตัวเลือกหลังไม่สามารถทำได้เสมอไปเนื่องจากขนาดของไฟล์ที่สร้างขึ้นและข้อกำหนดสำหรับจำนวน RAM ของ 1C: แอปพลิเคชันระดับองค์กรเอง)

การเข้ารหัสข้อมูลด้วยเครื่องมือ 1C ในตัว

ความเป็นไปได้มาตรฐานสำหรับการใช้การเข้ารหัสใน 1C จะลดลงเหลือการใช้อ็อบเจ็กต์สำหรับการทำงานกับไฟล์ Zip ที่มีพารามิเตอร์การเข้ารหัส มีโหมดการเข้ารหัสดังต่อไปนี้: อัลกอริธึม AES ที่มีคีย์ 128, 192 หรือ 256 บิต และอัลกอริธึมที่ล้าสมัยซึ่งเดิมใช้ใน Zip archiver ไฟล์ Zip ที่เข้ารหัสด้วย AES ไม่สามารถอ่านได้โดยผู้จัดเก็บหลายราย (WinRAR, 7zip) ในการสร้างไฟล์ที่มีข้อมูลที่เข้ารหัส คุณต้องระบุรหัสผ่านและอัลกอริธึมการเข้ารหัส ตัวอย่างที่ง่ายที่สุดฟังก์ชันการเข้ารหัส-ถอดรหัสตามความสามารถนี้แสดงไว้ด้านล่าง:

ฟังก์ชัน EncryptData (ข้อมูล รหัสผ่าน วิธีเข้ารหัส = ไม่ได้กำหนด) ส่งออก

// เขียนข้อมูลลงในไฟล์ชั่วคราว อันที่จริง ไม่สามารถบันทึกข้อมูลทั้งหมดด้วยวิธีนี้
ValueInFile (TempFileName, ข้อมูล);

// เขียนข้อมูลชั่วคราวไปยังไฟล์เก็บถาวร
Zip = ZipFileWrite ใหม่ (ชื่อชั่วคราว, รหัสผ่าน, วิธีการเข้ารหัส);
Zip.Add (ชื่อไฟล์ชั่วคราว);
Zip.เขียน ();

// อ่านข้อมูลจากไฟล์เก็บถาวรที่ได้รับลงใน แกะ
EncryptedData = NewValueStore (ใหม่ BinaryData (TemporaryArchiveFileName));

// ไฟล์ชั่วคราว - ลบ

ฟังก์ชัน EndFunction DecryptData (EncryptedData, รหัสผ่าน) ส่งออก

// ความสนใจ! ความถูกต้องของพารามิเตอร์ที่ส่งผ่านไม่ได้รับการตรวจสอบ

// เขียนค่าที่ส่งผ่านไปยังไฟล์
TempFileName = GetTempFileName ("zip");
BinaryArchiveData = EncryptedData.Get ();
BinaryArchiveData.Write (ชื่อไฟล์เก็บถาวรชั่วคราว);

// แตกไฟล์แรกของไฟล์เก็บถาวรที่เขียนใหม่
TempFileName = GetTempFileName ();
Zip = ไฟล์ ReadZipFile ใหม่ (ชื่อไฟล์ชั่วคราว, รหัสผ่าน);
Zip.Extract (Zip.Elements, TemporaryFileName, ZipFilePath RecoveryMode.NotRecover);

// อ่านไฟล์ที่เขียน
ข้อมูล = ValueFromFile (ชื่อไฟล์ชั่วคราว + "\" + Zip.Elements.Name);

// ลบไฟล์ชั่วคราว
DeleteFiles (ชื่อไฟล์ชั่วคราว);
ลบไฟล์ (TempArchiveFileName);

ส่งคืนข้อมูล;

EndFunction

แน่นอนว่าวิธีนี้ไม่สามารถเรียกว่าอุดมคติได้ - ข้อมูลถูกเขียนไปยังโฟลเดอร์ชั่วคราวในรูปแบบข้อความที่ชัดเจนประสิทธิภาพของวิธีการนั้นตรงไปตรงมาไม่มีที่แย่ไปกว่าการจัดเก็บในฐานข้อมูลต้องใช้พื้นที่จำนวนมาก แต่นี่เป็นเพียงเท่านั้น วิธีการที่อิงตามกลไกในตัวของแพลตฟอร์มเท่านั้น นอกจากนี้ยังมีข้อได้เปรียบเหนือวิธีการอื่นๆ อีกมาก - วิธีนี้ช่วยแพ็คข้อมูลด้วยการเข้ารหัสไปพร้อม ๆ กัน หากคุณต้องการใช้การเข้ารหัสโดยไม่มีข้อเสียที่วิธีนี้มี คุณต้องติดตั้งใช้งานในองค์ประกอบภายนอก หรืออ้างอิงไลบรารีที่มีอยู่ผ่านการสร้างวัตถุ COM เช่น การใช้ Microsoft CryptoAPI ตัวอย่างเช่น เราจะให้ฟังก์ชันสำหรับการเข้ารหัส / ถอดรหัสสตริงตามรหัสผ่านที่ได้รับ

ฟังก์ชัน EncryptStringDES (UnencryptedString, รหัสผ่าน)

CAPICOM_ENCRYPTION_ALGORITHM_DES = 2; // ค่าคงที่นี้มาจาก CryptoAPI

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

ส่งคืน EncryptedString;

EndFunction // EncryptStringDES ()

ฟังก์ชัน DecryptStringDES (EncryptedString, รหัสผ่าน)

//ความสนใจ! พารามิเตอร์จะไม่ถูกตรวจสอบ!

Encryption Engine = COMObject ใหม่ ("CAPICOM.EncryptedData");
กลไกการเข้ารหัส SetSecret (รหัสผ่าน);
พยายาม
Encryption Engine.Decrypt (EncryptedString);
ข้อยกเว้น
// รหัสผ่านผิด!;
การคืนเงินไม่ระบุ;
สิ้นสุดความพยายาม;

ส่งคืน Encryption Engine.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 ไม่ได้ป้องกันแอปพลิเคชันเซิร์ฟเวอร์จากการรับฟังการรับส่งข้อมูลเครือข่ายในระดับแอปพลิเคชันแต่อย่างใด

ดังนั้น เพื่อหลีกเลี่ยงข้อผิดพลาดในการใช้งานระบบเข้ารหัส ก่อนปรับใช้คุณควร (อย่างน้อย) ดำเนินการดังต่อไปนี้

• หา:
  • คุณต้องการปกป้องอะไร?
  • คุณควรใช้วิธีการป้องกันแบบใด?
  • คุณต้องการให้ระบบรักษาความปลอดภัยส่วนใดของระบบ
  • ใครจะเป็นผู้ควบคุมการเข้าถึง
  • การเข้ารหัสจะทำงานในทุกที่ที่ถูกต้องหรือไม่?
• กำหนดตำแหน่งที่ข้อมูลถูกจัดเก็บ วิธีส่งข้อมูลผ่านเครือข่าย และคอมพิวเตอร์ที่จะเข้าถึงข้อมูล ข้อมูลนี้จะให้ข้อมูลเกี่ยวกับความเร็ว ความจุ และการใช้งานเครือข่ายก่อนการปรับใช้ระบบ ซึ่งเป็นประโยชน์สำหรับการเพิ่มประสิทธิภาพการทำงาน
• ประเมินจุดอ่อนของระบบสำหรับ ประเภทต่างๆการโจมตี
• จัดทำและจัดทำเอกสารแผนการรักษาความปลอดภัยของระบบ
• ประเมินประสิทธิภาพทางเศรษฐกิจ (เหตุผล) ของการใช้ระบบ

บทสรุป

แน่นอน ในการตรวจสอบคร่าวๆ เป็นไปไม่ได้ที่จะระบุทุกแง่มุมที่เกี่ยวข้องกับความปลอดภัยใน 1C แต่ขอให้เราสรุปผลเบื้องต้นบางอย่าง แน่นอนว่าแพลตฟอร์มนี้ไม่สามารถเรียกได้ว่าเป็นอุดมคติ - มันเหมือนกับปัญหาอื่น ๆ ที่มีปัญหาในการจัดระบบความปลอดภัย แต่สิ่งนี้ไม่ได้หมายความว่าปัญหาเหล่านี้ไม่สามารถหลีกเลี่ยงได้ ในทางกลับกัน ข้อบกพร่องเกือบทั้งหมดสามารถขจัดได้ด้วยการพัฒนา การนำไปใช้ และการใช้ระบบที่ถูกต้อง ปัญหาส่วนใหญ่เกิดจากการอธิบายอย่างละเอียดไม่เพียงพอของโซลูชันแอปพลิเคชันเฉพาะและสภาพแวดล้อมในการดำเนินการ ตัวอย่างเช่น โซลูชันทั่วไปที่ไม่มีการเปลี่ยนแปลงที่สำคัญ ไม่ได้หมายความถึงการสร้างระบบที่มีความปลอดภัยเพียงพอ

บทความนี้แสดงให้เห็นอีกครั้งว่ามาตรการรักษาความปลอดภัยชุดใดชุดหนึ่งควรครอบคลุมทุกขั้นตอนของการใช้งาน: การพัฒนา การปรับใช้ การดูแลระบบ และแน่นอน มาตรการขององค์กร ในระบบข้อมูล มันคือ "ปัจจัยมนุษย์" (รวมถึงผู้ใช้) ที่เป็นภัยคุกคามความปลอดภัยหลัก ชุดของมาตรการนี้ต้องสมเหตุสมผลและสมดุล: ไม่สมเหตุสมผลและไม่น่าเป็นไปได้ที่เงินทุนที่เพียงพอจะถูกจัดสรรเพื่อจัดระเบียบการป้องกันซึ่งเกินต้นทุนของข้อมูลเอง

บริษัท เป็นบริการเฉพาะสำหรับผู้ซื้อ นักพัฒนา ตัวแทนจำหน่าย และพันธมิตรในเครือ นอกจากนี้ยังเป็นหนึ่งในร้านซอฟต์แวร์ออนไลน์ที่ดีที่สุดในรัสเซีย ยูเครน คาซัคสถาน ซึ่งนำเสนอผลิตภัณฑ์ที่หลากหลายแก่ลูกค้า วิธีการชำระเงินที่หลากหลาย ดำเนินการตามคำสั่งอย่างรวดเร็ว (มักจะทันที) ติดตามกระบวนการปฏิบัติตามคำสั่งซื้อในส่วนส่วนบุคคล

ดาวน์โหลด Informix® DataBlade ™ API Programmer's Guide ได้ที่ ส่วนการจัดการ Stack Space อธิบายวิธีสร้างฟังก์ชันแบบกำหนดเอง (UDR) บทความนี้ให้ข้อมูลเพิ่มเติมและเคล็ดลับการดีบัก

ข้อมูลด้านล่างนี้ใช้ได้ไม่ว่า UDR จะทำงานบนตัวประมวลผลเสมือนที่ผู้ใช้กำหนด (VP) หรือบน CPU VP กองเธรดสามารถย้ายไปยัง vCPU ที่ผู้ใช้กำหนดเองได้ก่อนดำเนินการ UDR

สแต็กขนาดใดที่จัดสรรสำหรับ UDR

ขนาดของสแต็กที่พร้อมใช้งานสำหรับ UDR ขึ้นอยู่กับวิธีสร้าง UDR:

ใช้ตัวแก้ไข STACK ซึ่งช่วยให้ UDR ใช้สแต็กเฉพาะของตัวเอง

โดยไม่มีตัวแก้ไข STACK ซึ่งหมายความว่า UDR จะแบ่งปันสแต็กที่เซิร์ฟเวอร์จัดสรรให้กับเธรดที่ส่งคำขอ ขนาดสแต็กในกรณีนี้จะถูกกำหนดโดยค่าของพารามิเตอร์ STACKSIZE ในไฟล์คอนฟิกูเรชัน onconfig

ตัวปรับแต่ง STACK

นิพจน์ CREATE PROCEDURE หรือ CREATE FUNCTION มีตัวแก้ไข STACK ทางเลือกที่ให้คุณระบุจำนวนพื้นที่สแต็กเป็นไบต์ที่ UDR จำเป็นต้องดำเนินการ

หากคุณใช้ตัวแก้ไข STACK เมื่อสร้าง UDR เซิร์ฟเวอร์จะจัดสรรและจัดสรรคืนพื้นที่สแต็กทุกครั้งที่ดำเนินการ UDR ขนาดที่มีอยู่จริงคือ STACK ในหน่วยไบต์ลบค่าโสหุ้ยบางส่วน ขึ้นอยู่กับจำนวนอาร์กิวเมนต์ของฟังก์ชัน

หากค่า STACK น้อยกว่าค่า STACKSIZE ในไฟล์ onconfig (ดูหัวข้อถัดไป) ขนาดของสแตกที่จัดสรรให้กับ UDR จะถูกปัดเศษเป็นค่า STACKSIZE โดยอัตโนมัติ

พารามิเตอร์การกำหนดค่า STACKSIZE

ไฟล์คอนฟิกูเรชัน onconfig มีพารามิเตอร์ STACKSIZE ที่กำหนดขนาดสแต็กเริ่มต้นสำหรับเธรดของผู้ใช้

ถ้าคุณไม่ระบุ STACK เมื่อสร้าง UDR เซิร์ฟเวอร์จะไม่จัดสรรพื้นที่สแต็กเพิ่มเติมเพื่อดำเนินการ UDR นั้น แต่ UDR จะใช้พื้นที่สแต็กที่จัดสรรเพื่อดำเนินการตามคำขอแทน ขนาดสแต็กที่ใช้ได้จะขึ้นอยู่กับโอเวอร์เฮดของการดำเนินการฟังก์ชันที่ระดับ SQL

สแต็กของเธรดได้รับการจัดสรรครั้งเดียวสำหรับเธรดที่ร้องขอ ประสิทธิภาพจะดีกว่าเมื่อ UDR แชร์หนึ่งเธรดกับหนึ่งสแต็ก เนื่องจากเซิร์ฟเวอร์ไม่เปลืองทรัพยากรในการจัดสรรสแต็กเพิ่มเติมสำหรับการเรียก UDR แต่ละครั้ง ในทางกลับกัน หากขนาดของสแต็ก UDR ที่ใช้เข้าใกล้ค่า STACKSIZE ก็อาจทำให้สแต็กโอเวอร์โฟลว์เมื่อเรียกใช้ฟังก์ชันเป็นส่วนหนึ่งของคำขอที่ซับซ้อน (ในกรณีนี้ พื้นที่สแต็กน้อยกว่าจะพร้อมใช้งานเพื่อดำเนินการ UDR)

อย่าลืมตั้งค่า STACKSIZE สูงเกินไป เนื่องจากจะส่งผลต่อเธรดของผู้ใช้ทั้งหมด

คุณต้องจัดการขนาดสแต็กเมื่อใด

คุณต้องจัดการพื้นที่สแต็กถ้า UDR ทำการเรียกซ้ำ หรือถ้า UDR ต้องการพื้นที่สแต็กมากกว่าที่พร้อมใช้งานตามค่าเริ่มต้นบนสแต็กเธรดที่ร้องขอ (STACKSIZE)

มีสองวิธีในการเพิ่มสแต็กเพื่อเรียกใช้ UDR:

ระบุตัวแก้ไข STACK เมื่อสร้าง UDR

ใช้ mi_call () เพื่อโทรซ้ำ (ดูตัวอย่างใน Informix DataBlade API Programmer's Guide)

หากคุณไม่ได้ระบุขนาดด้วย STACK และหากคุณไม่ได้ใช้ mi_call () เพื่อเพิ่มสแต็กปัจจุบัน และหาก UDR ทำสิ่งที่ต้องการพื้นที่สแต็กมาก จะทำให้สแต็กโอเวอร์โฟลว์

โปรดทราบว่าฟังก์ชันบางอย่างเช่น mi_ * เพิ่มกลุ่มสแต็กใหม่สำหรับการดำเนินการของตนเอง ส่วนเหล่านี้จะว่างเมื่อกลับไปยังผู้เรียก UDR

เกิดอะไรขึ้นถ้ามีอะไรผิดพลาด?

การตรวจสอบการใช้งานสแต็ค

วัตถุประสงค์ของการตรวจสอบคือเพื่อระบุ UDR เฉพาะที่ทำให้เกิดการล้นของสแต็ก เพื่อให้คุณสามารถเปลี่ยนค่า STACK สำหรับ UDR ที่เฉพาะเจาะจงได้

สังเกตการใช้สแต็กด้วย "onstat -g sts"

สังเกตเซสชันที่ดำเนินการแบบสอบถาม SQL ด้วย "onstat -g ses session_id"

หลังจากระบุตัวตน แบบสอบถาม SQLซึ่งส่งผลให้สแต็กล้น คุณควรกำหนดการใช้งานสแต็กโดยดำเนินการ UDR แยกต่างหากซึ่งเป็นส่วนหนึ่งของคำขอดั้งเดิม

คุณสามารถตั้งค่า STACK สำหรับ UDR แบบไดนามิกได้ ตัวอย่างเช่น:

แก้ไขฟังก์ชัน MyFoo (lvarchar, lvarchar) ด้วย (เพิ่ม stack = 131072);

หลังจากเปลี่ยนค่า STACK คุณควรทดสอบการสืบค้นข้อมูลเดิมเพื่อให้แน่ใจว่าขณะนี้ใช้งานได้อย่างเสถียร

เพิ่ม STACKSIZE

หรือลองเพิ่มค่า STACKSIZE ตรวจสอบว่าวิธีนี้แก้ปัญหาได้หรือไม่ (อย่าลืมคืนค่าเดิมในภายหลัง)

หากการเพิ่ม STACKSIZE ไม่ได้ผล ปัญหาน่าจะเกิดจากหน่วยความจำเสียหาย นี่คือคำแนะนำบางส่วน:

เปิดใช้งานการขีดเขียนหน่วยความจำและการตรวจสอบพูลหน่วยความจำ ส่วน "ปัญหาการดีบัก" ของบทความการจัดสรรหน่วยความจำสำหรับ UDR จะอธิบายวิธีการดำเนินการนี้

พิจารณาใหม่โดยใช้ mi_lvarchar ให้ความสนใจเป็นพิเศษกับตำแหน่งที่ส่งผ่าน mi_lvarchar ไปยังฟังก์ชันที่คาดว่าจะได้รับสตริงที่สิ้นสุดด้วยค่า null เป็นอาร์กิวเมนต์

ลดจำนวน VPs ของ CPU (หรือผู้ใช้) ให้เหลือ 1 ตัวเพื่อให้เกิดปัญหาเร็วขึ้น

mi_print_stack () - Solaris

Informix Dynamic Server สำหรับ Solaris OC มีฟังก์ชัน mi_print_stack () ที่สามารถเรียกใช้ใน UDR โดยค่าเริ่มต้น ฟังก์ชันนี้จะบันทึกเฟรมสแต็กลงในไฟล์ต่อไปนี้:

/tmp/default.stack

คุณไม่สามารถเปลี่ยนชื่อของไฟล์เอาต์พุต แต่คุณสามารถเปลี่ยนตำแหน่งได้โดยการเปลี่ยนค่าของตัวแปรสภาพแวดล้อม DBTEMP ตรวจสอบให้แน่ใจว่าผู้ใช้ informix สามารถเขียนไปยังไดเร็กทอรี $ DBTEMP ข้อผิดพลาดใดๆ ที่เกิดขึ้นขณะเรียกใช้งาน mi_print_stack () จะถูกพิมพ์ไปที่ $ MSGPATH

คุณลักษณะนี้มีให้สำหรับ Solaris OC เท่านั้น

อภิธานศัพท์

ข้อกำหนดและตัวย่อที่ใช้ในบทความนี้:

UDR	กิจวัตรที่ผู้ใช้กำหนด
VP	โปรเซสเซอร์เสมือน

04/14/2016 เวอร์ชัน 3.22 เปลี่ยนอินเทอร์เฟซ แก้ไขข้อผิดพลาดเมื่อโอนทะเบียน เปลี่ยนขั้นตอนการโอนองค์กรและนโยบายการบัญชี แพลตฟอร์ม 8.3.7.2027 BP 3.0.43.174
03/17/2016 เวอร์ชัน 3.24 แก้ไขข้อบกพร่อง แพลตฟอร์ม 8.3.8.1747 BP 3.0.43.241
06/16/2016 เวอร์ชัน 3.26 แก้ไขข้อบกพร่อง แพลตฟอร์ม 8.3.8.2088 BP 3.0.44.123
10/16/2016 เวอร์ชัน 4.0.1.2 แก้ไขการโอนที่เก็บมูลค่า การเปลี่ยนแปลงการโอนนโยบายการบัญชีสำหรับรุ่น 3.44 * แพลตฟอร์ม 8.3.9.1818 BP 3.0.44.164
04/19/2017 เวอร์ชัน 4.0.2.7 มีการเปลี่ยนแปลงอัลกอริธึมสำหรับการถ่ายโอนการลงทะเบียนที่เชื่อมโยงกับไดเร็กทอรี ข้อผิดพลาดที่สังเกตเห็นได้รับการแก้ไข การถ่ายโอนด้วยการเขียนลิงก์ใหม่ได้รับการแก้ไขแล้ว
05/29/2017 เวอร์ชัน 4.0.4.5 เปลี่ยนการถ่ายโอนการเคลื่อนไหวเพิ่มการดูการเคลื่อนไหวของเอกสารที่โอนอย่างอื่น ...
05/30/2017 เวอร์ชัน 4.0.4.6 แก้ไขข้อผิดพลาดเมื่อกรอกรายการไดเรกทอรีที่มีอยู่ในแหล่งที่มา (ขอบคุณ shoy)
06/17/2017 เวอร์ชัน 4.0.5.1 อัลกอริธึมสำหรับการถ่ายโอนการเคลื่อนไหวมีการเปลี่ยนแปลง
07/19/2017 เวอร์ชัน 4.0.5.4 การถ่ายโอน CI จาก BP 2.0 มีการเปลี่ยนแปลง โดยไม่คาดคิด Smilegm ถูกย้ายจาก UT 10.3 ในเวอร์ชันนี้ การถ่ายโอนได้รับการแก้ไขเล็กน้อยสำหรับสถานการณ์ดังกล่าว)))
08/10/2017 เวอร์ชัน 4.0.5.5 แก้ไขข้อผิดพลาดเมื่อถ่ายโอนจาก BP 2.0
09/19/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 การเปลี่ยนแปลงจะถูกรวมไว้สำหรับการแบ่งปันระหว่างการกำหนดค่าเดียวกัน
12/19/2017 เวอร์ชัน 5.2.2.2 แก้ไขการถ่ายโอนข้อมูลการลงทะเบียนอิสระสำหรับไดเร็กทอรีซึ่งอยู่ในมิติของการลงทะเบียนเหล่านี้

12/06/2017 เวอร์ชันการประมวลผลใหม่ 5.2.0.4 ท่ามกลางการเปลี่ยนแปลงที่สำคัญคือความสามารถในการถ่ายโอนจาก BP 1.6 เป็น BP 3.0 การเปลี่ยนแปลงหลักคือการจัดการการค้นหาลิงก์ที่อ้างอิง - ในเวอร์ชันก่อนหน้า การค้นหาทำได้โดย GUID และในเวอร์ชันนี้ คุณสามารถเปิดใช้งานการค้นหา "ตามข้อกำหนด":

01/17/2018 เวอร์ชัน 5.2.2.3 แก้ไขข้อผิดพลาดที่สังเกตเห็นของไดเร็กทอรีย่อยและการลงทะเบียนข้อมูลเป็นระยะ

07/19/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 - เพิ่มแฟล็ก "Always overwrite links" สำหรับการเขียนทับวัตถุที่อ้างอิง (ความเร็วในการถ่ายโอนลดลงอย่างมาก แต่บางครั้งก็จำเป็น) เพิ่มแท็บ "การเตรียมการ" ซึ่งคุณสามารถกำหนดค่าการติดต่อของแผนภูมิต้นทางและปลายทางของบัญชี (ในระดับที่มีรหัสบัญชี) และการโอนค่าคงที่ แพลตฟอร์ม 8.3.7.1970, BP 3.0.43.148

04/03/2016 เวอร์ชัน 3.11 การกรอกรายการเอกสารที่มีอยู่ในแหล่งที่มามีการเปลี่ยนแปลง: การกรอกเป็นไปตามการเคลื่อนไหวตามผังบัญชีทำได้โดยง่ายโดยลิงก์สำหรับช่วงเวลาเช่นเดียวกับใน ที่ // เว็บไซต์ / สาธารณะ / 509628 /

การประมวลผลมีไว้สำหรับการถ่ายโอนข้อมูลในช่วงเวลาใด ๆ ที่คล้ายกับ "การขนถ่ายและโหลด MXL" จาก ITS โดยไม่ต้องใช้ XML, JSON และไฟล์ระดับกลางอื่นๆ เท่านั้น - แลกเปลี่ยนจากฐานข้อมูลไปยังฐานข้อมูลผ่าน COM ในเวอร์ชันที่เก่ากว่า 3.10 จะใช้การเชื่อมต่อโดยใช้อัลกอริทึมจาก BSP ซึ่งมีการลงทะเบียน comcntr.dll (หากระบบปฏิบัติการ "อนุญาต") รวมถึงข้อความต่างๆ เมื่อไม่สามารถสร้างการเชื่อมต่อได้ , ตัวอย่างเช่น - " ฐานข้อมูลอยู่ในกระบวนการอัปเดต " ฯลฯ เพิ่มการตรวจสอบตัวเลือกผู้รับเป็นแหล่ง IS - มีการออกคำเตือน

สามารถใช้สำหรับ:

1. การถ่ายโอนข้อมูลเชิงบรรทัดฐานและข้อมูลอ้างอิง (NSI) จากแหล่ง IS ไปยังเครื่องรับ IS (การโอน NSI ทั้งหมดดำเนินการตามคำขอของผู้ใช้ หนังสืออ้างอิงที่จำเป็น ฯลฯ จะถูกโอนโดยลิงก์สำหรับการโอนใดๆ ).

2. การโอนเอกสารตามระยะเวลาที่เลือก

3. การถ่ายโอนข้อมูลทั้งหมดจาก IB ที่ "เสีย" หากเริ่มต้นใน 1C: โหมด Enterprise และการอัปโหลดข้อมูลหรือเปิดใช้ Configurator เป็นไปไม่ได้

คุณสมบัติการประมวลผล - ความปลอดภัยของข้อมูลของผู้รับและแหล่งที่มาสามารถถ่ายโอนข้อมูลที่แตกต่างกันจาก 2.0 เป็น 3.0 - รุ่นต่างกัน แต่การถ่ายโอนใช้งานได้ !!! แอตทริบิวต์ที่ไม่ตรงกันจะถูกละเว้น หรือต้องระบุอัลกอริธึมการถ่ายโอนสำหรับแอตทริบิวต์เหล่านั้น

ความคิดเห็น: การแปลงข้อมูลไม่ได้ใช้! แล้วอย่าถามว่าทำไม!!! สำหรับสิ่งที่กัดกร่อนมากที่สุด - BP 3.0 เปลี่ยนแปลงเกือบทุกวัน ไม่มีความแข็งแกร่งใดๆ ในการทำให้กฎการโอนเป็นปัจจุบันอีกต่อไป - ทุกอย่างง่ายขึ้นที่นี่ :-)

คุณสมบัติการประมวลผลอีกประการหนึ่งคือมันเปิดตัวใน IS ของตัวรับ (แอนะล็อกที่ใกล้เคียงที่สุดในแง่ของการทำงานทำงานในทางกลับกัน

เริ่มงาน - คุณต้องระบุระยะเวลาการประมวลผล ระบุองค์กรจากแหล่งที่มา จะถูกโอนไปยังผู้รับ

เมื่อองค์กรถูกโอนย้าย นโยบายการบัญชีและการลงทะเบียนข้อมูล "ที่เกี่ยวข้อง" จะถูกโอน ดังนั้น เมื่อคุณเลือกองค์กรในแหล่งที่มาครั้งแรก จะใช้เวลาสักครู่ก่อนที่จะปรากฏในผู้รับ

แผนภูมิต้นทางและปลายทางของบัญชีจะต้องเหมือนกัน ไม่มีบัญชีที่แตกต่างกันในเวอร์ชัน 2 * ถูกโอนไปยังผู้รับ การตั้งค่าความสอดคล้องของบัญชีและการวิเคราะห์มีการวางแผนที่จะรวมในอนาคต บัญชีโอนด้วยรหัสที่ไม่พบในเครื่องรับ อย่าสร้าง !!!

ออบเจ็กต์ที่เหลือจะถูกถ่ายโอนโดยตัวระบุภายใน (GUID) ดังนั้นคุณควรให้ความสนใจกับหนังสืออ้างอิงที่สำคัญบางเล่ม เช่น - สกุลเงิน

หากคุณวางแผนที่จะแลกเปลี่ยนกับฐานที่ "สะอาด" จะเป็นการดีกว่าที่จะลบหนังสืออ้างอิงที่กรอกในครั้งแรกก่อนการแลกเปลี่ยน สำหรับสิ่งนี้ หน้าจะถูกจัดเตรียมในการประมวลผล ซึ่งคุณสามารถรับองค์ประกอบเหล่านี้ของไดเร็กทอรีและลบออกได้ อย่างน้อยที่สุด คุณต้องลบสกุลเงิน "RUB" - ตั้งแต่ การทำซ้ำแทบจะหลีกเลี่ยงไม่ได้ (โดยหลักการแล้ว สิ่งนี้สามารถแก้ไขได้ง่ายหลังจากแลกเปลี่ยนการค้นหาและแทนที่รายการซ้ำที่สร้างใน 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 ( ตัวเลือกที่แนะนำ) หรือจากการประมวลผลนี้ (มีปุ่ม "โพสต์เอกสาร" ที่นี่)

หากการประมวลผลถูกวางแผนที่จะใช้สำหรับการแลกเปลี่ยนแบบถาวร ก็สามารถลงทะเบียนใน IS ของผู้รับได้ (ปุ่ม "ลงทะเบียน") สำหรับการถ่ายโอน "ครั้งเดียว" คุณสามารถใช้มันผ่านไฟล์ - เปิด

12/21/2015 - เวอร์ชัน 3.1 แพลตฟอร์ม 8.3.7.1805 และ BP 3.0.43.29 (เวอร์ชัน 2.15 สำหรับ 3.0.43. * ไม่ทำงาน - การกำหนดค่ามีการเปลี่ยนแปลงไปมาก)

เปลี่ยน:

กล่องโต้ตอบสำหรับการเลือกตัวเลือกการเชื่อมต่อ แฟล็กไคลเอ็นต์-เซิร์ฟเวอร์จะพร้อมใช้งานเสมอ ขึ้นอยู่กับการติดตั้ง ไม่ว่าจะเป็นตัวเลือกของโฟลเดอร์ฐานไฟล์หรือฟิลด์ที่มีชื่อฐานบนเซิร์ฟเวอร์และชื่อของเซิร์ฟเวอร์เอง (แก้ไขข้อผิดพลาดของกล่องโต้ตอบเวอร์ชัน 2.15)

- ฟังก์ชันใหม่: กลไกการกระทบยอดของสารตกค้างและการปฏิวัติระหว่างฐานของแหล่งกำเนิดและตัวรับในรายละเอียดที่แตกต่างกัน:

ฉันคิดว่าตัวเลือกการกระทบยอดนั้นชัดเจนจากรูป:

การใช้งานไคลเอ็นต์แบบบางและแบบหนามีความแตกต่างกัน - แบบหนา หน้าต่างเปรียบเทียบไฟล์จะแสดงขึ้นทันที:

ในธินไคลเอ็นต์ ฉันไม่ได้บิดเบือนด้วยการกดปุ่มโดยทางโปรแกรม ฉันเสนอตัวเลือกง่ายๆ สำหรับการแสดงหน้าต่างเปรียบเทียบ:

การเปรียบเทียบในไคลเอ็นต์แบบบาง IMHO สะดวกกว่า เนื่องจาก มีปุ่มนำทางสำหรับความแตกต่าง ซึ่งสะดวกกว่าสำหรับตารางปริมาณมาก มากกว่าการเลื่อนด้วยเมาส์:

03/22/2016 เวอร์ชัน 3.10 - เพิ่มแฟล็ก "Always overwrite links" สำหรับการเขียนทับวัตถุที่อ้างอิง (ความเร็วในการถ่ายโอนลดลงอย่างมาก แต่บางครั้งก็จำเป็น) เพิ่มแท็บ "การเตรียมการ" ซึ่งคุณสามารถกำหนดค่าการติดต่อของแผนภูมิต้นทางและปลายทางของบัญชี (ในระดับที่มีรหัสบัญชี) และการโอนค่าคงที่ แพลตฟอร์ม 8.3.7.1970, BP 3.0.43.148

- ฟังก์ชันใหม่:ก่อนโอนเอกสาร ขอแนะนำให้ตรวจสอบผังบัญชีเพื่อความสอดคล้องในแหล่งที่มาและปลายทาง รวมถึงความสอดคล้องของค่าคงที่ที่กำหนดไว้

ในการทำเช่นนี้ ให้เพิ่มแท็บ "การเตรียมการ" ซึ่งคุณสามารถตั้งค่าการโต้ตอบเหล่านี้ได้:

อัลกอริทึมสำหรับการกรอกตารางการติดต่อของบัญชีนั้นง่าย - วิเคราะห์มูลค่าการซื้อขายที่มีอยู่ในแหล่งที่มาและแต่ละบัญชีพบว่ามีการค้นหาการจับคู่ด้วยรหัสในผู้รับหากไม่พบการจับคู่บรรทัดที่มี รหัสบัญชีจะแสดงในตารางโดยที่คุณต้องเลือกบัญชีของผู้รับจะใช้เมื่อโอน ความสอดคล้องของวิทยาศาสตร์ได้รับการจัดตั้งขึ้นในระดับรหัส

ในการตรวจสอบและถ่ายโอนความสอดคล้องของค่าคงที่ชุดจะใช้ตารางที่เกี่ยวข้อง:

เรากรอกถ้าจำเป็น - เราโอน เฉพาะค่าคงที่ที่ทำเครื่องหมายด้วยธงเท่านั้นที่จะถูกยกไป ...

สแต็กโปรแกรมเป็นพื้นที่พิเศษของหน่วยความจำที่จัดเรียงตามคิว LIFO (เข้าก่อนออกก่อน - เข้าก่อนออกก่อน) ชื่อ "กอง" มาจากการเปรียบเทียบหลักการของการสร้างด้วยแผ่นกอง - คุณสามารถวางแผ่นทับกัน (วิธีการเพิ่มลงในกอง "ผลัก", "ผลัก") แล้ว หยิบขึ้นมาโดยเริ่มจากด้านบน (วิธีการรับค่าจากสแต็ก "ป๊อป", "ป๊อป") สแต็คของโปรแกรมเรียกอีกอย่างว่า call stack, Execute stack, machine stack (เพื่อไม่ให้สับสนกับ "stack" - โครงสร้างข้อมูลนามธรรม)

สแต็คมีไว้เพื่ออะไร? ช่วยให้คุณจัดระเบียบการโทรของรูทีนย่อยได้อย่างสะดวก เมื่อถูกเรียก ฟังก์ชันจะได้รับอาร์กิวเมนต์บางอย่าง นอกจากนี้ยังต้องเก็บตัวแปรท้องถิ่นไว้ที่ใดที่หนึ่ง นอกจากนี้ เราควรคำนึงว่าฟังก์ชันหนึ่งสามารถเรียกใช้ฟังก์ชันอื่นได้ ซึ่งต้องส่งผ่านพารามิเตอร์และเก็บตัวแปรด้วย เมื่อใช้สแต็ก เมื่อส่งพารามิเตอร์ คุณเพียงแค่ใส่พารามิเตอร์ลงในสแต็ก จากนั้นฟังก์ชันที่เรียกจะสามารถ "ดัน" พารามิเตอร์เหล่านั้นออกจากที่นั่นและใช้งานได้ ตัวแปรโลคัลยังสามารถเก็บไว้ในที่เดียวกันได้ - ที่จุดเริ่มต้นของโค้ด ฟังก์ชันจะจัดสรรส่วนหนึ่งของหน่วยความจำสแต็ก เมื่อตัวควบคุมกลับมา ฟังก์ชันจะล้างและทำให้ว่าง โปรแกรมเมอร์ในภาษาระดับสูงมักจะไม่คิดถึงเรื่องดังกล่าว - คอมไพเลอร์สร้างรหัสประจำที่จำเป็นทั้งหมดสำหรับพวกเขา

ผลของความผิดพลาด

ตอนนี้เราเข้าใกล้ปัญหามากแล้ว ในรูปแบบนามธรรม กองซ้อนเป็นที่เก็บข้อมูลที่ไม่มีที่สิ้นสุดซึ่งสามารถเพิ่มองค์ประกอบใหม่ได้ไม่จำกัด น่าเสียดาย ในโลกของเราทุกอย่างมีจำกัด และหน่วยความจำภายใต้สแต็กก็ไม่มีข้อยกเว้น จะเกิดอะไรขึ้นถ้ามันสิ้นสุดลงเมื่อมีการผลักอาร์กิวเมนต์ของฟังก์ชันไปยังสแต็ก หรือฟังก์ชั่นจัดสรรหน่วยความจำสำหรับตัวแปรหรือไม่?

ข้อผิดพลาดที่เรียกว่าสแต็กโอเวอร์โฟลว์จะเกิดขึ้น เนื่องจากสแต็กจำเป็นสำหรับการจัดการการเรียกใช้ฟังก์ชันที่ผู้ใช้กำหนดเอง (และโปรแกรมเกือบทั้งหมดบน ภาษาสมัยใหม่ซึ่งรวมถึงวัตถุเชิงวัตถุถูกสร้างขึ้นบนพื้นฐานของฟังก์ชั่น) พวกมันจะไม่สามารถถูกเรียกได้อีกต่อไป ดังนั้น ระบบปฏิบัติการจึงเข้าควบคุม ล้างสแตก และยุติโปรแกรม ที่นี่คุณสามารถเน้นความแตกต่างระหว่างและกองล้น - ในกรณีแรกเกิดข้อผิดพลาดเมื่อเข้าถึงพื้นที่หน่วยความจำที่ไม่ถูกต้องและหากไม่มีการป้องกันในขั้นตอนนี้จะไม่ปรากฏให้เห็นในขณะนั้น - ด้วยความบังเอิญที่ประสบความสำเร็จ โปรแกรมสามารถทำงานได้ตามปกติ หากมีการป้องกันเฉพาะหน่วยความจำที่เข้าถึงได้ ก็จะเกิดขึ้น ในกรณีของสแต็ก โปรแกรมจะยุติการทำงานโดยไม่ล้มเหลว

เพื่อความชัดเจน ควรสังเกตว่าคำอธิบายเหตุการณ์นี้เป็นจริงสำหรับคอมไพเลอร์ที่คอมไพล์เป็นโค้ดเนทีฟเท่านั้น ในภาษาที่มีการจัดการ เครื่องเสมือนมีสแต็กของตัวเองสำหรับโปรแกรมที่มีการจัดการ ซึ่งสถานะนั้นง่ายต่อการตรวจสอบ และคุณยังสามารถยกเว้นโปรแกรมได้เมื่อเกิดโอเวอร์โฟลว์ ในภาษา C และ C ++ ไม่สามารถนับ "ความหรูหรา" ดังกล่าวได้

สาเหตุของข้อผิดพลาด

อะไรจะนำไปสู่สถานการณ์ที่ไม่พึงประสงค์เช่นนี้ได้? ตามกลไกที่อธิบายไว้ข้างต้น ตัวเลือกหนึ่งคือการเรียกใช้ฟังก์ชันที่ซ้อนกันมากเกินไป สถานการณ์นี้เป็นไปได้อย่างยิ่งเมื่อใช้การเรียกซ้ำ การเรียกซ้ำที่ไม่สิ้นสุด (ในกรณีที่ไม่มีกลไกสำหรับการประเมิน "ขี้เกียจ") จะถูกขัดจังหวะในลักษณะนี้ ซึ่งแตกต่างจากที่บางครั้งมีแอปพลิเคชันที่มีประโยชน์ อย่างไรก็ตาม ด้วยหน่วยความจำจำนวนเล็กน้อยที่จัดสรรให้กับสแต็ก (ซึ่ง ตัวอย่างเช่น เป็นเรื่องปกติสำหรับไมโครคอนโทรลเลอร์) ลำดับการเรียกง่ายๆ อาจเพียงพอ

อีกทางเลือกหนึ่งคือตัวแปรท้องถิ่นที่ต้องการหน่วยความจำมาก ไม่ควรสร้างอาร์เรย์ภายในที่มีองค์ประกอบนับล้าน หรือตัวแปรท้องถิ่นนับล้านตัว (คุณไม่มีทางรู้ว่าจะเกิดอะไรขึ้น) แม้แต่การเรียกใช้ฟังก์ชันที่โลภเช่นนี้เพียงครั้งเดียวก็สามารถทำให้สแต็กโอเวอร์โฟลว์ได้อย่างง่ายดาย เพื่อให้ได้ข้อมูลจำนวนมาก ควรใช้กลไกของหน่วยความจำฮีป ซึ่งจะช่วยให้คุณจัดการกับข้อผิดพลาดของการขาดแคลนได้

อย่างไรก็ตาม หน่วยความจำฮีพค่อนข้างช้าในแง่ของการจัดสรรและการจัดสรรคืน (เนื่องจากระบบปฏิบัติการทำเช่นนี้) และเมื่อใด การเข้าถึงโดยตรงคุณต้องจัดสรรและปล่อยด้วยตนเอง หน่วยความจำบนสแต็กได้รับการจัดสรรอย่างรวดเร็ว (อันที่จริง คุณเพียงแค่ต้องเปลี่ยนค่าของการลงทะเบียนหนึ่งรายการ) นอกจากนี้ ตัวทำลายจะถูกเรียกโดยอัตโนมัติสำหรับออบเจ็กต์ที่จัดสรรบนสแต็กเมื่อฟังก์ชันส่งคืนและล้างสแต็ก แน่นอน ความปรารถนาจะเกิดขึ้นทันทีเพื่อรับความทรงจำจากกองซ้อน ดังนั้น วิธีที่สามในการโอเวอร์โฟลว์คือการจัดสรรหน่วยความจำในสแต็กด้วยตนเองโดยโปรแกรมเมอร์ ไลบรารี C มีฟังก์ชัน alloca สำหรับวัตถุประสงค์นี้โดยเฉพาะ เป็นที่น่าสนใจที่จะทราบว่าหากฟังก์ชันสำหรับการจัดสรรหน่วยความจำแบบไดนามิก malloc มี "แฝด" สำหรับการทำให้ว่าง ฟังก์ชัน alloca จะไม่มี - หน่วยความจำจะว่างโดยอัตโนมัติหลังจากการกลับมาของการควบคุมฟังก์ชัน บางทีนี่อาจทำให้สถานการณ์ซับซ้อนขึ้นเท่านั้น - คุณจะไม่สามารถเพิ่มหน่วยความจำก่อนออกจากฟังก์ชันได้ แม้ว่าตามหน้า man "alloca ขึ้นอยู่กับเครื่องและคอมไพเลอร์ การใช้งานในหลาย ๆ ระบบนั้นมีปัญหาและมีข้อบกพร่องมากมาย การใช้งานนั้นไม่สำคัญและท้อแท้" - ยังคงใช้อยู่

ตัวอย่างของ

ตัวอย่างเช่น ให้พิจารณาโค้ดสำหรับการค้นหาไฟล์แบบเรียกซ้ำซึ่งอยู่บน MSDN:

Void DirSearch (String * sDir) (ลอง (// ค้นหาโฟลเดอร์ย่อยในโฟลเดอร์ที่ส่งผ่านเข้ามา String * d = Directory :: GetDirectories (sDir); int numDirs = d-> get_Length (); for (int i = 0; ฉัน< 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->รายการ -> เพิ่ม (f [j]); ) DirSearch (d [i]); )) catch (ระบบ :: ข้อยกเว้น * e) (กล่องข้อความ :: แสดง (e-> ข้อความ);))

ฟังก์ชันนี้รับรายการไฟล์ในไดเร็กทอรีที่ระบุ จากนั้นเรียกตัวเองสำหรับรายการเหล่านั้นที่กลายเป็นไดเร็กทอรี ดังนั้น ด้วยแผนผังของระบบไฟล์ที่มีความลึกเพียงพอ เราจึงจะได้ผลลัพธ์ที่เป็นตรรกะ

ตัวอย่างของวิธีที่สอง นำมาจากคำถาม "ทำไมสแต็กโอเวอร์โฟลว์จึงเกิดขึ้น" จากไซต์ที่เรียกว่า Stack Overflow (ไซต์นี้เป็นชุดของคำถามและคำตอบในหัวข้อการเขียนโปรแกรมใดๆ ไม่ใช่แค่สแต็กโอเวอร์โฟลว์ อย่างที่เห็น):

#define W 1000 #define H 1000 #define MAX 100000 // ... int main () (ภาพ int; float dtr; initImg (image, dtr); return 0;)

อย่างที่คุณเห็น ในฟังก์ชันหลัก หน่วยความจำจะถูกจัดสรรบนสแต็กสำหรับอาร์เรย์ประเภท int และ float โดยแต่ละองค์ประกอบมีหนึ่งล้านองค์ประกอบ ซึ่งโดยรวมแล้วจะให้น้อยกว่า 8 เมกะไบต์เล็กน้อย เมื่อพิจารณาว่าโดยค่าเริ่มต้น Visual C ++ จะสงวนไว้เพียง 1 เมกะไบต์สำหรับสแต็ก คำตอบก็ชัดเจน

และนี่คือตัวอย่างที่นำมาจากที่เก็บ GitHub ของโปรเจ็กต์ Lightspark Flash player:

DefineSoundTag :: DefineSoundTag (/ * ... * /) (// ... unsigned int soundDataLength = h.getLength () - 7; unsigned char * tmp = (unsigned char *) alloca (soundDataLength); // .. .)

หวังว่า h.getLength () - 7 จะไม่ใหญ่เกินไปที่จะหลีกเลี่ยงการล้นในบรรทัดถัดไป แต่เวลาที่บันทึกไว้ในการจัดสรรหน่วยความจำคุ้มกับความผิดพลาดของโปรแกรม "ที่อาจเกิดขึ้น" หรือไม่?

ผล

Stack overflow เป็นข้อผิดพลาดร้ายแรงที่มักส่งผลกระทบต่อโปรแกรมที่มีฟังก์ชันแบบเรียกซ้ำ อย่างไรก็ตาม แม้ว่าโปรแกรมจะไม่มีฟังก์ชันดังกล่าว แต่โอเวอร์โฟลว์ก็ยังเป็นไปได้เนื่องจากมีตัวแปรในเครื่องจำนวนมากหรือเกิดข้อผิดพลาดในการจัดสรรหน่วยความจำบนสแต็กด้วยตนเอง กฎคลาสสิกทั้งหมดยังคงอยู่: หากมีตัวเลือก จะเป็นการดีกว่าที่จะชอบการวนซ้ำแทนการเรียกซ้ำ และไม่ควรทำงานด้วยตนเองแทนการคอมไพเลอร์

รายการบรรณานุกรม

• อี. ทาเนนบอม. สถาปัตยกรรมคอมพิวเตอร์
• วิกิพีเดีย. กองล้น
• กองล้น กองล้น C ++

สแต็กในบริบทนี้เป็นอันสุดท้ายในบัฟเฟอร์แรกที่คุณจัดสรรระหว่างการทำงานของโปรแกรมของคุณ สุดท้าย สิ่งแรก (LIFO) หมายความว่าสิ่งสุดท้ายที่คุณใส่จะเป็นสิ่งแรกที่คุณส่งคืนเสมอ - หากคุณกด 2 รายการบนสแต็ก "A" และ "B" สิ่งแรกที่คุณดึงออกจากสแต็กจะเป็น "B" และสิ่งต่อไปก็คือ "A"

เมื่อคุณเรียกใช้ฟังก์ชันในโค้ดของคุณ คำสั่งถัดไปหลังจากการเรียกใช้ฟังก์ชันจะถูกเก็บไว้ในสแต็กและพื้นที่หน่วยความจำใดๆ ที่สามารถเขียนทับได้โดยการเรียกใช้ฟังก์ชัน ฟังก์ชันที่เลือกสามารถใช้สแต็กมากขึ้นสำหรับตัวแปรในเครื่องของตัวเอง เมื่อเสร็จแล้ว จะเป็นการเพิ่มพื้นที่ว่างของตัวแปรในเครื่องที่ใช้และเปลี่ยนกลับเป็นฟังก์ชันก่อนหน้า

กองล้น

สแต็กโอเวอร์โฟลว์คือเมื่อคุณใช้หน่วยความจำสำหรับสแต็กมากกว่าที่โปรแกรมของคุณตั้งใจจะใช้ ในระบบฝังตัว คุณสามารถมีได้เพียง 256 ไบต์สำหรับสแต็ก และหากแต่ละฟังก์ชันมีขนาด 32 ไบต์ คุณจะมีฟังก์ชันเรียกฟังก์ชัน 2 ได้เพียง 8 ฟังก์ชันด้วยฟังก์ชันลึก 1 ซึ่งเรียกใช้ฟังก์ชัน 3 ซึ่งเรียกใช้ฟังก์ชัน 4 ... ที่เรียกใช้ฟังก์ชัน 8 ซึ่งเรียกใช้ฟังก์ชัน 9 แต่ฟังก์ชัน 9 จะเขียนทับหน่วยความจำภายนอกสแต็ก ซึ่งสามารถเขียนทับหน่วยความจำ รหัส ฯลฯ

โปรแกรมเมอร์หลายคนทำพลาดโดยเรียกใช้ฟังก์ชัน A ซึ่งจะเรียกใช้ฟังก์ชัน B จากนั้นเรียกใช้ฟังก์ชัน C แล้วจึงเรียกใช้ฟังก์ชัน A ซึ่งสามารถทำงานได้เกือบตลอดเวลา แต่อินพุตผิดเพียงรายการเดียวจะทำให้เป็นวงกลมตลอดไปจนกว่าคอมพิวเตอร์ เรียนรู้ว่าสแตกเต็ม

ฟังก์ชันแบบเรียกซ้ำทำให้เกิดสิ่งนี้เช่นกัน แต่ถ้าคุณกำลังเขียนแบบเรียกซ้ำ (เช่น ฟังก์ชันของคุณเรียกตัวเอง) คุณต้องตระหนักถึงสิ่งนี้และใช้ตัวแปรสแตติก / โกลบอลเพื่อป้องกันการเรียกซ้ำที่ไม่สิ้นสุด

โดยทั่วไปแล้ว OS และภาษาการเขียนโปรแกรมที่คุณใช้จัดการสแต็ค และนี่เป็นสิ่งที่อยู่ในมือคุณ คุณควรดูกราฟการโทรของคุณ (โครงสร้างแบบต้นไม้ที่แสดงจากจุดหลักของคุณว่าแต่ละฟังก์ชันเรียกใช้อะไร) เพื่อดูว่าการเรียกใช้ฟังก์ชันของคุณลึกเพียงใด และระบุการวนซ้ำและการเรียกซ้ำที่ไม่ได้เจตนา ต้องตรวจสอบการวนซ้ำและการเรียกซ้ำโดยเจตนาเพื่อหาข้อผิดพลาดหากพวกเขาโทรหากันหลายครั้งเกินไป

นอกจากแนวปฏิบัติในการเขียนโปรแกรมที่ดี การทดสอบแบบสแตติกและไดนามิกแล้ว คุณยังทำอะไรไม่ได้มากในระบบเหล่านี้ ระดับสูง.

ระบบสมองกลฝังตัว

ในโลกที่ฝังอยู่ โดยเฉพาะอย่างยิ่งรหัสที่มีความน่าเชื่อถือสูง (ยานยนต์ การบิน อวกาศ) คุณต้องตรวจสอบและยืนยันรหัสอย่างละเอียด แต่คุณยังทำสิ่งต่อไปนี้ด้วย:

• ไม่อนุญาตการเรียกซ้ำและการวนซ้ำ - การปฏิบัติตามนโยบายและการทดสอบ
• เก็บโค้ดและสแต็กให้ห่างกัน (โค้ดแบบแฟลช สแต็กใน RAM และจะไม่ตรงกัน)
• วางแถบป้องกันรอบ ๆ กอง - พื้นที่ว่างของหน่วยความจำที่คุณกรอกด้วยตัวเลขมหัศจรรย์ (โดยปกติคือโปรแกรมขัดจังหวะ แต่มีตัวเลือกมากมายที่นี่) และหลายร้อยหรือหลายพันครั้งต่อวินาทีที่คุณมองไปที่แถบป้องกัน ตรวจสอบให้แน่ใจว่าไม่ได้ถูกเขียนทับ
• ใช้การป้องกันหน่วยความจำ (เช่น ห้ามรันบนสแต็ก ห้ามอ่านหรือเขียนลงบนสแต็กโดยตรง)
• การขัดจังหวะไม่เรียกใช้ฟังก์ชันรอง - ตั้งค่าแฟล็ก คัดลอกข้อมูล และให้แอปพลิเคชันจัดการ (ไม่เช่นนั้น คุณอาจลึกถึง 8 ลึกในแผนผังการเรียกใช้ฟังก์ชันของคุณ มีการขัดจังหวะ จากนั้นมีฟังก์ชันเพิ่มเติมภายในการออกจากการขัดจังหวะ ทำให้เกิดการขว้างปา) คุณมีหลายโครงสร้างการโทร - หนึ่งรายการสำหรับกระบวนการหลักและอีกรายการสำหรับการขัดจังหวะแต่ละครั้ง หากการขัดจังหวะของคุณสามารถขัดจังหวะซึ่งกันและกันได้ ... ก็มีมังกร ...

ภาษาและระบบระดับสูง

แต่ในภาษาระดับสูงที่ทำงานบนระบบปฏิบัติการ:

• ลด ที่จัดเก็บในตัวเครื่องตัวแปร (ตัวแปรโลคัลถูกเก็บไว้ในสแต็ก) แม้ว่าคอมไพเลอร์จะค่อนข้างฉลาดเกี่ยวกับสิ่งนี้และบางครั้งจะใส่ชิ้นส่วนขนาดใหญ่บนฮีปหากแผนผังการโทรของคุณมีขนาดเล็ก)
• หลีกเลี่ยงหรือจำกัดการเรียกซ้ำอย่างรุนแรง
• อย่าขัดจังหวะโปรแกรมของคุณให้เป็นฟังก์ชันที่เล็กและเล็กเกินไป แม้จะไม่สนใจตัวแปรในเครื่อง การเรียกใช้ฟังก์ชันแต่ละครั้งก็กินเนื้อที่มากถึง 64 ไบต์บนสแต็ก (โปรเซสเซอร์ 32 บิต โดยเก็บรีจิสเตอร์ตัวประมวลผลไว้ครึ่งหนึ่ง แฟล็ก ฯลฯ)
• ให้ทรีโทรตื้น (คล้ายกับด้านบน)

เว็บเซิร์ฟเวอร์

ขึ้นอยู่กับแซนด์บ็อกซ์ที่คุณมี ไม่ว่าคุณจะสามารถควบคุมหรือดูสแต็กได้หรือไม่ โอกาสที่คุณจะจัดการกับเว็บเซิร์ฟเวอร์ได้เหมือนกับภาษาระดับสูงอื่นๆ และ ระบบปฏิบัติการค่อนข้างเกินมือคุณ แต่ตรวจสอบภาษาที่ใช้และเซิร์ฟเวอร์สแต็ก ตัวอย่างเช่น เป็นไปได้ที่จะแยกสแต็กบนเซิร์ฟเวอร์ SQL ของคุณ