คำแนะนำในการสร้างคีย์ลายเซ็นอิเล็กทรอนิกส์ คำแนะนำในการสร้างคีย์ลายเซ็นอิเล็กทรอนิกส์ การสร้างศูนย์รับรอง
วันนี้เราจะพูดถึง:
- สิ่งที่น่าสนใจเกี่ยวกับหัวข้อการเข้ารหัสและ ลายเซนต์อิเล็กทรอนิกส์วันนี้;
- ข้อบังคับปัจจุบันในหัวข้อนี้มีอะไรบ้าง
- ความสามารถในการเข้ารหัสใดบ้างที่นำมาใช้ในแพลตฟอร์ม 1C
- วิธีที่คุณสามารถขยายความสามารถเหล่านี้ด้วยส่วนประกอบภายนอก
- มาพูดถึงระบบย่อย "Electronic Signature" ใน BSP
- เกี่ยวกับการใช้บริการ "1C-EDO" และ "1C: DirectBank" การพัฒนาที่ฉันดูแล
- เราจะพูดถึงปัญหาของการพัฒนาโซลูชันของเราเองสำหรับการทำงานกับการเข้ารหัสบนแพลตฟอร์ม 1C: Enterprise
- ลองพิจารณาปัญหาทั่วไปที่เกิดขึ้นในการใช้งาน EDM ในองค์กร - ฉันจะบอกวิธีแก้ไขให้คุณ
ฉันต้องการดึงความสนใจของคุณไปที่คำศัพท์สองคำที่จะใช้ในชั้นเรียนปริญญาโท
- อย่างแรกคือ EDO การจัดการเอกสารอิเล็กทรอนิกส์... โดยเราหมายถึงทั้งโฟลว์เอกสารอิเล็กทรอนิกส์ภายในองค์กร และภายนอกกับคู่สัญญาบุคคลที่สาม
- ตัวย่อที่สองคือ EP.บนอินเทอร์เน็ตมีการถอดเสียง: "รัฐบาลอิเล็กทรอนิกส์" และ "ไดรฟ์ไฟฟ้า" เราจะมีมัน ลายเซนต์อิเล็กทรอนิกส์.
เหตุใดประเด็นของการเข้ารหัสและลายเซ็นอิเล็กทรอนิกส์จึงมีความเกี่ยวข้องในขณะนี้
- สำหรับองค์กรยุคใหม่ ความรวดเร็วของกระบวนการทางธุรกิจเป็นหนึ่งในข้อได้เปรียบในการแข่งขัน... ด้วยการใช้การจัดการเอกสารอิเล็กทรอนิกส์ เวลาที่ใช้ในสถิติจะลดลง 75%
- เมื่อเปลี่ยนไปใช้โฟลว์เอกสารอิเล็กทรอนิกส์ ประหยัดทรัพยากรของคุณเอง(กระดาษ, ตลับหมึกพิมพ์, พื้นที่จัดเก็บเอกสาร, เวลาพนักงานในการจัดเวิร์กโฟลว์กระดาษ) ทั้งหมดนี้ช่วยบริษัทได้มาก
- ปัจจุบันเกือบทุกธุรกิจใช้ช่องทางการธนาคารทางไกลและ ความปลอดภัยของการชำระเงินทางไกลในขณะนี้มีความเกี่ยวข้องมาก
- ขณะนี้ผู้เสียภาษีรายใหญ่ทั้งหมดรวมอยู่ในเอกสารสัญญาแล้วว่าหากคุณต้องการทำงานกับพวกเขาให้แลกเปลี่ยนเอกสารใน ในรูปแบบอิเล็กทรอนิกส์. ทุกอย่างไปที่อีเมล- ใบแจ้งหนี้อิเล็กทรอนิกส์ คำสั่งซื้อทางอิเล็กทรอนิกส์ ฯลฯ หากคุณต้องการเข้าร่วมการประมูล - คุณต้องมีลายเซ็นอิเล็กทรอนิกส์
- ทั้งหมดนี้ค่อยๆ กลายเป็นก้อนใหญ่แต่ถึงกระนั้น ประชากรของเราก็ยังไม่ได้รับข้อมูลเพียงพอ นี่เป็นการละเลยอย่างร้ายแรง ดังนั้นจุดประสงค์ของการทบทวนนี้คือเพื่อให้หลักสูตรแก่คุณที่จะช่วยคุณสำรวจปัญหาเหล่านี้และค้นหาว่าควรศึกษาอะไรและควรศึกษาที่ใด
กรอบการกำกับดูแล แนวปฏิบัติในการสมัคร
เราจะพิจารณาแนวคิดอะไร?
เอกสารอิเล็กทรอนิกส์
เอกสารอิเล็กทรอนิกส์คือข้อมูลที่ส่งทางอิเล็กทรอนิกส์:
- คุณได้ถ่ายภาพรถของคุณ - รูปภาพนี้เป็นเอกสารอิเล็กทรอนิกส์
- ส่งใบสมัครให้เจ้านายทางอีเมล - นี่เป็นเอกสารอิเล็กทรอนิกส์ด้วย
เอกสารใดๆ สามารถแปลเป็น "ดิจิทัล" ได้ แต่เอกสารอิเล็กทรอนิกส์บางฉบับไม่สามารถรับรู้ได้โดยปราศจากการแทรกแซงของมนุษย์
เครื่องจักรมีแนวโน้มมากขึ้น เอกสารจำนวนมากสามารถแบ่งออกเป็น เอกสารอิเล็กทรอนิกส์ที่เป็นทางการและไม่เป็นทางการ.
- โดยเอกสารที่ไม่เป็นทางการ เราหมายถึงคนดูรูปถ่ายและเห็นว่าจำนวนรถเป็นเช่นนั้นและเป็นเช่นนั้น
- และสำหรับพิธีการ เอกสารอิเล็กทรอนิกส์โดยปกติ แบบแผนจะได้รับการพัฒนาขึ้นโดยมีการระบุองค์ประกอบของเขตข้อมูล ข้อจำกัด บังคับหรือเป็นทางเลือก ฯลฯ เอกสารที่เป็นทางการดังกล่าวสามารถรับรู้ได้โดยอัตโนมัติ
โอกาสสำหรับเอกสารอิเล็กทรอนิกส์ที่เป็นทางการหน่วยงานต่างๆ ค่อยๆ เปลี่ยนไปใช้รางใหม่ หลายคนออกกฎระเบียบของตนเองโดยอธิบายรูปแบบที่สามารถแลกเปลี่ยนข้อมูลได้
- ตัวอย่างเช่น คณะอนุญาโตตุลาการยอมรับเฉพาะเอกสารในรูปแบบ PDF
- และต้องส่งใบแจ้งหนี้อิเล็กทรอนิกส์ไปที่ รูปแบบ XMLและมีกรอบการกำกับดูแลเฉพาะที่อธิบายฟิลด์ที่จำเป็น ผู้เสียภาษีที่ต้องการแลกเปลี่ยนใบแจ้งหนี้ทางอิเล็กทรอนิกส์ต้องปฏิบัติตามข้อกำหนดเหล่านี้อย่างเคร่งครัด
ก่อนหน้านี้มีปัญหาที่ Federal Tax Service จำเป็นต้องเปลี่ยนไปใช้เอกสารอิเล็กทรอนิกส์รูปแบบใหม่ในลักษณะเดียวกับการรายงานทางอิเล็กทรอนิกส์รูปแบบใหม่ - ตั้งแต่วันที่ 1 มีนาคมจะมีรูปแบบใหม่แล้ว "อย่างน้อย หญ้าจะไม่เติบโต” ตอนนี้หลังจากสองสามปี พวกเขาเผยแพร่รูปแบบ รอ ข้อเสนอแนะแล้วเตือนให้เปลี่ยนผ่านปีนี้ไปอย่างราบรื่น ในขณะเดียวกันก็ยอมรับทั้งรูปแบบเก่าและใหม่ควบคู่กันไป สำนักงานสรรพากรต้องยอมรับเอกสารในรูปแบบใด ๆ เสมอเพราะเอกสารสามารถมีอายุห้าปีและยังต้องได้รับการยอมรับในรูปแบบอิเล็กทรอนิกส์
ลายเซนต์อิเล็กทรอนิกส์
กฎหมายหมายเลข 63-FZ แนะนำแนวคิดของลายเซ็นอิเล็กทรอนิกส์ ก่อนหน้านี้มีแนวคิดเรื่อง "electronic ลายเซ็นดิจิทัล"(EDS) ตอนนี้การใช้คำว่า" ลายเซ็นอิเล็กทรอนิกส์ "ถูกต้องมากขึ้น ตามกฎหมายนี้มี ลายเซ็นอิเล็กทรอนิกส์สามประเภท.
- ชนิดแรกคือ ลายเซ็นอิเล็กทรอนิกส์อย่างง่าย... ตัวอย่างเช่น เมื่อใช้ธนาคารบนมือถือ คุณจะได้รับ SMS พร้อมรหัสผ่านแบบใช้ครั้งเดียว และคุณทำการยืนยัน ซึ่งเป็นแอนะล็อกของลายเซ็นอิเล็กทรอนิกส์อย่างง่าย เฉพาะผู้เขียนเท่านั้นที่สามารถระบุได้ด้วยลายเซ็นดังกล่าว
- ประเภทที่สองและสามคือ ลายเซ็นอิเล็กทรอนิกส์ที่ปรับปรุงแล้ว... "ปรับปรุง" หมายความว่ากำลังใช้เครื่องมือเข้ารหัสลับบางประเภท ลายเซ็นที่ปรับปรุงแล้วแบ่งออกเป็น ไร้ฝีมือและชำนาญ.
ลายเซ็นอิเล็กทรอนิกส์ที่ผ่านการรับรองที่ปรับปรุงแล้วบางครั้งเรียกง่ายๆ ว่าลายเซ็นอิเล็กทรอนิกส์ที่ผ่านการรับรอง (QEP) นี่คือลายเซ็นอิเล็กทรอนิกส์ตามใบรับรองที่ออกโดยหน่วยงานออกใบรับรองที่ได้รับการรับรอง กระทรวงโทรคมนาคมและสื่อสารมวลชนเก็บรักษารายชื่อศูนย์รับรองที่ออกใบรับรองลายเซ็นอิเล็กทรอนิกส์
ใบรับรองลายเซ็นอิเล็กทรอนิกส์(อาจเรียกอีกอย่างว่าใบรับรองของคีย์การตรวจสอบลายเซ็นอิเล็กทรอนิกส์) - นี่คือ กระดาษหรือเอกสารอิเล็กทรอนิกส์ที่ระบุว่าใครเป็นเจ้าของลายเซ็นนี้โดยเฉพาะ
ลายเซ็นอิเล็กทรอนิกส์ที่ผ่านการรับรองใช้กันอย่างแพร่หลายมากที่สุด วัตถุประสงค์หลักคือเพื่อพิสูจน์การประพันธ์ รับประกันการไม่ปฏิเสธ และรับรองความถูกต้องของข้อมูลที่ลงนาม ซึ่งหมายความว่าหากคุณได้ลงนามในใบแจ้งหนี้อิเล็กทรอนิกส์ด้วยลายเซ็นอิเล็กทรอนิกส์ที่ผ่านการรับรองแล้ว:
- คุณไม่สามารถพูดได้ว่านี่ไม่ใช่ลายเซ็นของคุณ
- คุณไม่สามารถปฏิเสธได้ (ถอนตัว);
- คุณสามารถตรวจสอบว่ามีการเปลี่ยนแปลงในเอกสารนี้หรือไม่หลังจากที่คุณลงนามแล้ว
ถ้าเราพูดถึง การประยุกต์ใช้ลายเซ็นอิเล็กทรอนิกส์แล้วมันคุ้มค่าที่จะแบ่งเป็นท้องถิ่นและคลาวด์
- ลายเซ็นอิเล็กทรอนิกส์ในท้องถิ่น- สถานการณ์เมื่อคุณลงนามในเอกสารบางอย่างบนคอมพิวเตอร์ของคุณ ในกรณีนี้ จำเป็นต้องใช้เครื่องมือเข้ารหัสลับ การติดตั้งใบรับรองเป็นเรื่องยากมาก
- ลายเซ็นอิเล็กทรอนิกส์บนคลาวด์- สถานการณ์ที่คุณไว้วางใจการจัดเก็บคีย์ส่วนตัวให้กับผู้ถือบางรายใน "คลาวด์" และเพื่อที่จะลงนามในเอกสาร คุณต้องถ่ายทอดไปยังคลาวด์นี้ เป็นไปได้มากว่าคุณจะได้รับรหัสผ่านแบบใช้ครั้งเดียวในโทรศัพท์ของคุณซึ่งจะต้องได้รับการยืนยัน และหลังจากการยืนยัน ลายเซ็นอิเล็กทรอนิกส์จะถูกสร้างขึ้นบนเซิร์ฟเวอร์ใน "คลาวด์" และคุณจะได้รับเอกสารที่ลงนาม
FSB ได้ออกหนังสือชี้แจงโดยอธิบายว่า ลายเซ็นอิเล็กทรอนิกส์บนคลาวด์ไม่ผ่านการรับรอง... ดังนั้นหากกฎหมายระบุว่าต้องลงนามในเอกสารด้วยลายเซ็นอิเล็กทรอนิกส์ที่ผ่านการรับรอง และเอกสารของคุณมีการลงนามใน "คลาวด์" โปรดจำไว้ว่าอาจมีปัญหากับสิ่งนี้ - ต้องดำเนินการอย่างระมัดระวัง
คุณสามารถบอกอะไรได้อีกที่น่าสนใจเกี่ยวกับกฎหมายที่จะเกี่ยวข้องกับเรา
- ในปี 2559 ศูนย์รับรองแห่งเดียวของกระทรวงโทรคมนาคมและสื่อสารมวลชนแห่งสหพันธรัฐรัสเซียปรากฏตัวขึ้น ซึ่งช่วยให้สร้างห่วงโซ่ความไว้วางใจให้กับใบรับรองใด ๆ หัวหน้าศูนย์รับรองของกระทรวงโทรคมนาคมและสื่อสารมวลชนแห่งนี้ออกใบรับรองให้กับศูนย์รับรองที่ได้รับการรับรองและได้ออกใบรับรองให้กับทางกายภาพและ นิติบุคคล... ดังนั้น คุณสามารถสร้างห่วงโซ่แห่งความไว้วางใจสำหรับลายเซ็นอิเล็กทรอนิกส์ใดๆ ได้เสมอ สะดวกมากเพราะเคยเป็นเรื่องยากที่จะตรวจสอบในทางปฏิบัติว่าลายเซ็นจากหน่วยงานออกใบรับรองอื่นนั้นถูกต้อง
- ค่อนข้างใหม่ - เมื่อต้นปี 2560 กระทรวงโทรคมนาคมและสื่อสารมวลชนได้ริเริ่มกฎหมายเพื่อมอบลายเซ็นอิเล็กทรอนิกส์ที่มีคุณสมบัติเหมาะสมทั้งหมดแก่รัฐผูกขาด ในการนี้ ธนาคารกลางและกระทรวงการพัฒนาเศรษฐกิจและการค้าในเดือนกรกฎาคมได้ตอบกลับมาว่าไม่ควรทำสิ่งนี้ เพราะมันจะแย่งงานและทำลายสิ่งที่สะสมมาตลอดหลายปีที่ผ่านมา เป็นไปได้มากว่าความคิดริเริ่มทางกฎหมายนี้จะไม่ดำเนินต่อไป แต่มีแนวคิดดังกล่าว
คุณสมบัติของการใช้ EDF พร้อมลายเซ็นอิเล็กทรอนิกส์ในบริษัทต่างๆ
อะไรคือคุณสมบัติของการใช้การจัดการเอกสารอิเล็กทรอนิกส์ในบริษัท? โปรดทราบว่าเมื่อคุณเริ่มโครงการที่เกี่ยวข้องกับลายเซ็นอิเล็กทรอนิกส์และการเข้ารหัส บริการให้คำปรึกษามีความสำคัญมาก
ถ้า บริษัทเปิดตัวการจัดการเอกสารอิเล็กทรอนิกส์, แล้ว:
- งานแรกคือ ลงทะเบียนการใช้การจัดการเอกสารอิเล็กทรอนิกส์ใน นโยบายการบัญชี;
- ต้องการเพิ่มเติม ออกคำสั่งที่สถานประกอบการที่จะระบุว่าบุคคลใดสามารถลงนามในเอกสารได้
- หากคุณกำลังแลกเปลี่ยนกับคู่สัญญา คุณต้องมีข้อตกลงที่ระบุว่าคุณจะยกเลิกและแก้ไขเอกสารอย่างไร ตัวอย่างเช่น หากคุณไม่ชอบเอกสารที่เป็นกระดาษ คุณสามารถตกลงกับคู่สัญญาของคุณและฉีกมันทิ้ง แล้วทุกอย่างจะเรียบร้อย และในรูปแบบอิเล็กทรอนิกส์ ทุกอย่างค่อนข้างซับซ้อน เนื่องจากจำนวนสำเนาของเอกสารที่คุณสร้างและลงนามสามารถมีได้ไม่จำกัด และแม้ว่าคุณและคู่สัญญาของคุณตกลงที่จะยกเลิกเอกสารนี้ เอกสารที่เทียบเท่าทางอิเล็กทรอนิกส์นั้นไม่เพียงพอที่จะลบออกจากฐานข้อมูลของคุณ ในการแก้ไขเอกสารอิเล็กทรอนิกส์หรือปฏิเสธ คุณต้องสร้างเอกสารอิเล็กทรอนิกส์ใหม่โดยอิงจากเอกสารดังกล่าว และในเอกสารดังกล่าวจะระบุว่าธุรกรรมของคุณมีหน้าตาเป็นอย่างไร และหลังจากที่คุณลงนามในเอกสารอิเล็กทรอนิกส์ฉบับใหม่นี้จากทั้งสองฝ่ายแล้ว ข้อมูลเกี่ยวกับการทำธุรกรรมจะถูกบันทึกในรูปแบบที่คุณต้องการ
ทั้งหมดนี้ต้องมีการกำหนดและใช้งาน
ความพร้อมของกรอบการกำกับดูแล
ฉันจะซาบซึ้งในความพร้อมของกรอบการกำกับดูแลของเรา - มี "การสร้าง" แล้ว แต่ก็ยังต้องทำให้เสร็จ
- ตัวอย่างเช่น, ไม่มีความเข้าใจว่าเราจะตรวจสอบลายเซ็นอิเล็กทรอนิกส์ในเอกสารอิเล็กทรอนิกส์ได้อย่างไรในห้าปี... เนื่องจากใบรับรองมีอายุหนึ่งปี และเมื่อหมดอายุการใช้งาน ลายเซ็นจะไม่ถูกต้อง - ยังไม่ชัดเจนว่าจะตรวจสอบได้อย่างไร
- ยังไม่ชัดเจนว่า "วันที่ลงนาม" คืออะไรสำหรับเอกสารทางบัญชีบางฉบับ สิ่งสำคัญคือต้องทราบว่ามีการลงนามในเอกสาร ณ จุดใด ตอนนี้เมื่อลงนามในเอกสาร คุณสามารถ "โกง" - พวกเขาแปลวันที่ของคอมพิวเตอร์ เซ็นชื่อ และมันจะดูเหมือนกับว่าเอกสารถูกเซ็น "ย้อนหลัง" ดังนั้น เพื่อที่จะบอกได้อย่างชัดเจนว่ามีการเซ็นเอกสารแล้ว จะต้องมีตัวเลือกอย่างใดอย่างหนึ่ง:
- หรือควรมีศูนย์กระจายการประทับเวลาเพียงแห่งเดียว เพื่อว่าในขณะที่ลงนามในเอกสาร เราจะสมัครกับแผนกบริการของรัฐบาลกลางบางแห่ง ซึ่งจะให้เวลาสำหรับการลงนามแก่เรา
- หรือเมื่อคุณแลกเปลี่ยนใบแจ้งหนี้อิเล็กทรอนิกส์มีลิงค์ที่สาม - ผู้ดำเนินการจัดการเอกสารอิเล็กทรอนิกส์ เขาส่งเอกสารด้วยตนเองและไม่อนุญาตให้ "โกง" เพราะเขาสร้างใบเสร็จรับเงิน (การยืนยัน) ซึ่งกำหนดวันที่และเวลา
โดยทั่วไปมีที่ว่างให้เคลื่อนย้าย
กลไกการเข้ารหัสในแพลตฟอร์ม 1C: Enterprise 8
กลไกการเข้ารหัสในแพลตฟอร์มปรากฏขึ้นตั้งแต่เวอร์ชัน 8.2 ซึ่งเป็นกลไกที่ค่อนข้างใหม่ แพลตฟอร์มนี้ไม่มีอัลกอริทึมการเข้ารหัส แต่มีเฉพาะการเรียกและวัตถุที่สามารถใช้ในการเข้าถึงเครื่องมือเข้ารหัสลับที่อยู่ในคอมพิวเตอร์:
- สำหรับ Windows มันคืออินเทอร์เฟซ CryptoAPI
- ไม่มีอินเทอร์เฟซดังกล่าวสำหรับ Linux มีการเรียกโดยตรงไปยังโมดูลการเข้ารหัส
จากนี้ไปจะเห็นได้ชัดว่า การเข้ารหัสสามารถใช้ได้เฉพาะเมื่อมีการติดตั้งเครื่องมือเข้ารหัสบนคอมพิวเตอร์... และในทางกลับกัน แพลตฟอร์ม 1C: Enterprise ไม่จำเป็นต้องได้รับการรับรองในแง่ของการเข้ารหัส
การดำเนินการเข้ารหัสขั้นพื้นฐานในแพลตฟอร์ม 1C: Enterprise 8:
- คุณทราบดีว่าแพลตฟอร์มสามารถทำงานได้ในโหมดต่างๆ: หนา, บาง, เว็บไคลเอ็นต์, การเชื่อมต่อภายนอก และแอปบนอุปกรณ์เคลื่อนที่ ในโหมดเริ่มต้นทั้งหมดนี้ รองรับการเข้ารหัส- สำหรับแอปพลิเคชั่นมือถือรองรับกลไกการเข้ารหัสปรากฏขึ้นตั้งแต่เวอร์ชัน 8.3.10 ฉันขอแนะนำให้อ่าน Syntax Assistant และดูว่ามีวิธีใดบ้างในโหมดเริ่มต้น เนื่องจากมีข้อ จำกัด
- แพลตฟอร์มช่วยให้คุณทำงานกับใบรับรอง กุญแจสาธารณะ(X.509)ที่ติดตั้งบนคอมพิวเตอร์ เราไม่สามารถออกใบรับรองใหม่หรือขอให้ออกใบรับรองได้ เราทำงานกับสิ่งที่เรามีเท่านั้น - โดยใช้กลไกของแพลตฟอร์ม เราสามารถค้นหาใบรับรองบนคอมพิวเตอร์ อ่านคุณลักษณะของใบรับรอง อัปโหลดไปยังไฟล์และตรวจสอบว่าใบรับรองนั้นถูกต้องเพียงใด
- ในทางปฏิบัติฉันมักจะพบความเข้าใจผิดเกี่ยวกับ การเข้ารหัสและถอดรหัสทำงานอย่างไรในแพลตฟอร์ม... นี่เป็นสิ่งสำคัญอย่างยิ่งเมื่อคุณกำลังทำงานร่วมกับผู้รับเหมาภายนอกที่ไม่ได้ทำงานใน 1C เมื่อคุณเข้ารหัสเอกสาร คุณได้ส่งเอกสารไปยังอีกด้านหนึ่ง และที่นั่นพวกเขาพยายามถอดรหัสลับ ตัวอย่างเช่น คำถามมักเกิดขึ้นหากมีการระบุอัลกอริทึม GOST 28147-89 ใน 1C เมื่อตั้งค่าผู้ให้บริการเข้ารหัส ซึ่งมีความสมมาตร และเมื่อถอดรหัส จำเป็นต้องเข้าถึงคีย์ส่วนตัว ให้ฉันเตือนคุณว่าอัลกอริธึมการเข้ารหัสแบบสมมาตรบอกเป็นนัยว่าคุณใช้คีย์เดียวกันสำหรับการเข้ารหัสและถอดรหัส และการเข้ารหัสแบบอสมมาตรคือเมื่อข้อมูลถูกเข้ารหัสโดยใช้กุญแจสาธารณะ และอีกรหัสหนึ่งคือคีย์ส่วนตัว (ลับ) ที่ใช้ในการถอดรหัส ผู้รับเหมาถามว่า: "แต่คุณบอกว่าอัลกอริธึมการเข้ารหัสมีความสมมาตร เหตุใดจึงจำเป็นต้องใช้ส่วนส่วนตัวของคีย์เพื่อถอดรหัส" มาดูกันว่ากลไกการเข้ารหัสทำงานอย่างไรในแพลตฟอร์ม:
- คีย์ความยาวคงที่บางคีย์จะถูกสร้างขึ้นแบบสุ่ม โดยชุดข้อมูลจะถูกเข้ารหัสโดยใช้อัลกอริธึมสมมาตร
- กุญแจนั้นจะถูกเข้ารหัสแบบอสมมาตรโดยใช้กุญแจสาธารณะของใบรับรองผู้รับ
- การเข้ารหัสโดยใช้อัลกอริทึมแบบสมมาตรทำงานได้เร็วขึ้น - เราเข้ารหัสข้อมูลจำนวนมากด้วยมัน จากนั้นเราเข้ารหัสคีย์ขนาดเล็กที่มีความยาวคงที่อย่างรวดเร็วโดยใช้อัลกอริทึมแบบอสมมาตร
- ข้อมูลที่เข้ารหัส รายการใบรับรองผู้รับ และคีย์ที่เข้ารหัสนั้นถูกรวมไว้ในแพ็กเก็ตข้อมูลเดียวตามข้อกำหนด PKCS # 7
- แพ็กเก็ตนี้ถูกส่งไปยังฝั่งผู้รับ
- และการถอดรหัสทำงานในลำดับที่กลับกัน
- การลงนามและการตรวจสอบลายเซ็นอิเล็กทรอนิกส์... เมื่อเซ็นชื่อโดยใช้แพลตฟอร์ม จะมีการเข้าถึงส่วนส่วนตัวของคีย์ และตรวจสอบความสมบูรณ์ (ความถูกต้องทางคณิตศาสตร์) ของลายเซ็นที่สร้างขึ้นในแพลตฟอร์ม จากมุมมองของความสำคัญทางกฎหมายนี้ไม่เพียงพอ หากคุณต้องการตรวจสอบลายเซ็นอิเล็กทรอนิกส์ภายใต้เอกสาร คุณต้องตรวจสอบ:
- ความถูกต้องของใบรับรอง
- ความถูกต้องทางคณิตศาสตร์ของข้อมูลที่คุณส่ง
นี่คือสิ่งที่ทำในกลไก BSP - เราจะพูดถึงในภายหลัง แพลตฟอร์มไม่ทำเช่นนี้
การเชื่อมต่อ TLS ที่ปลอดภัยสำหรับการจัดระเบียบช่องทางการสื่อสารที่เข้ารหัสรองรับ TLS สองเวอร์ชัน - 1.0 / 1.2 เวอร์ชัน TLS ถูกกำหนดโดยต้นทางที่คุณสร้างการเชื่อมต่อ - หากต้นทางใช้โปรโตคอล 1.2 แพลตฟอร์มจะเพิ่มการเชื่อมต่อที่เข้ารหัสเป็น 1.2 ด้วย หากใช้ BSP เมื่อเข้าถึงทรัพยากรที่มีที่อยู่เป็น "https" การเข้ารหัสจะเปิดขึ้นโดยอัตโนมัติ หากที่อยู่มี "http" แสดงว่าการรับส่งข้อมูลจะไม่ถูกเข้ารหัส สิ่งที่น่าสนใจอีกอย่างที่ฉันสามารถพูดได้ก็คือก่อนที่การเชื่อมต่อที่เข้ารหัสจะถูกสร้างขึ้นบนอัลกอริธึม RSA เท่านั้น และตอนนี้บนอัลกอริทึม GOST ด้วยเช่นกัน เบราว์เซอร์ยังไม่รองรับอัลกอริทึม GOST แต่แพลตฟอร์มรู้วิธีอยู่แล้ว แต่ไม่ใช่ทุกอย่างจะดีนัก
ฉันได้กล่าวไปแล้วว่าแพลตฟอร์มสามารถทำงานได้เฉพาะกับเครื่องมือเข้ารหัสลับที่ติดตั้งบนคอมพิวเตอร์เท่านั้น ดังนั้นจึงมีข้อจำกัด - หากคุณต้องการใช้การเข้ารหัส คุณต้องมีเครื่องมือเข้ารหัสบางอย่าง โดยที่ ไม่สามารถใช้เครื่องมือเข้ารหัสในโหมดพกพาได้ ต้องติดตั้งบน OS... ดูเหมือนว่าพวกเขาจะติดโทเค็นด้วยเครื่องมือเข้ารหัสลับในคอมพิวเตอร์ แพลตฟอร์มทำงานกับมัน - สิ่งนี้จะไม่ทำงาน
ลายเซ็นอิเล็กทรอนิกส์สร้างขึ้นในรูปแบบ PKCS # 7 เท่านั้น(แยกไฟล์ภายนอก) แพลตฟอร์มไม่ทราบเป็นอย่างอื่น
สำนักงานบางแห่งต้องการรูปแบบลายเซ็น XMLDSig- ในเวอร์ชันที่เรียบง่าย สถานการณ์เมื่ออยู่ในไฟล์ XML คุณสามารถใช้แท็กชุดหนึ่ง เซ็นชื่อ และใส่ลายเซ็นในแท็กถัดไป เพื่อให้มีหลายลายเซ็นในเอกสารเดียว แพลตฟอร์มไม่ทราบว่าต้องทำอย่างไร
ฉันจะชี้ให้เห็นว่า เป็นการยากที่จะวินิจฉัยปัญหาที่เกิดขึ้นใหม่โดยใช้แพลตฟอร์มตัวอย่างเช่น มีเครื่องมือเข้ารหัสบนคอมพิวเตอร์ มีใบรับรอง บางแห่งมีคีย์ส่วนตัว และหากแพลตฟอร์มเริ่มเรียกสิ่งนี้ทั้งหมด และในบางจุดมีบางอย่างที่ไม่พอดี ข้อผิดพลาดก็จะเกิดขึ้น - ว่าเกิดความล้มเหลวและการดำเนินการไม่ได้เกิดขึ้น เกิดอะไรขึ้นที่นั่น ปัญหาอยู่ที่ไหน ไม่ชัดเจน ดังนั้นจึงมีพื้นที่ให้เคลื่อนไหวในทิศทางนี้สำหรับทั้งแพลตฟอร์มและกองทุนคริปโต
การเข้ารหัสในส่วนประกอบภายนอก
หากต้องการลบข้อจำกัดของแพลตฟอร์ม คุณสามารถลองสร้างส่วนประกอบภายนอกได้
- เพื่อจุดประสงค์นี้ 1C มีทั้งหมด วิธีการก็มีอยู่ในดิสก์ ITSที่ https://its.1c.ru/db/metod8dev#content:3221:hdoc ตัวอย่างที่แนบมาคุณสามารถใช้
- เมื่อพัฒนาส่วนประกอบภายนอก คุณ คุณจะต้องสร้างแอสเซมบลีสำหรับระบบปฏิบัติการทั้งหมดที่ไคลเอ็นต์ของคุณกำลังทำงานอยู่เป็นการดีถ้าคุณรู้ล่วงหน้าว่าคุณมีไคลเอ็นต์ 100 ราย และทุกเครื่องมี Windows แบบ 32 บิต หากไม่เป็นเช่นนั้น คุณต้องสร้าง:
- สำหรับลินุกซ์;
- สำหรับ Windows (32 บิตและ 64 บิต);
- หากลูกค้าของคุณทำงานผ่านเบราว์เซอร์ คุณต้องสร้างส่วนขยายสำหรับแต่ละเบราว์เซอร์แยกกัน
- อาจยิ่งแย่ลงระหว่างการทำงาน คุณทำงานกับส่วนประกอบภายนอกเช่นเดียวกับวัตถุที่มีคุณสมบัติเฉพาะคุณเท่านั้นที่รู้ หากในระหว่างการใช้งานคุณทำผิดพลาดที่ใดที่หนึ่ง รหัสโปรแกรมสำหรับการโต้ตอบกับวัตถุนี้จะไม่สามารถทำงานได้
- มีปัญหาอีกประการหนึ่งคือ ไม่ชัดเจนว่าคุณจะส่งส่วนประกอบภายนอกนี้ให้กับลูกค้าอย่างไร... ลูกค้ามีแพลตฟอร์มอยู่แล้ว ทุกอย่างชัดเจนด้วยเครื่องมือเข้ารหัสลับ และตอนนี้คุณได้เขียนส่วนประกอบภายนอกที่เชื่อมต่อเครื่องมือเข้ารหัสลับและแพลตฟอร์มแล้ว แต่องค์ประกอบภายนอกนี้อยู่ที่ไหน การส่งมอบให้กับลูกค้านั้นไม่ชัดเจน
- คุณควร บำรุงรักษาและปรับปรุงรหัสโปรแกรม... หากคุณใช้ส่วนประกอบภายนอกในโซลูชันทั่วไป ทั้งหมดนี้จะต้องนำมาพิจารณาเมื่อทำการอัปเดต แล้วถ้าปล่อย รุ่นใหม่แพลตฟอร์ม คุณต้องทดสอบใหม่ทุกอย่าง
- มี ตัวอย่างสำเร็จรูปส่วนประกอบภายนอก ตัวอย่างที่โดดเด่นที่สุดในการปฏิบัติงานของฉันคือส่วนประกอบภายนอกสำหรับ Sberbank แม่นยำยิ่งขึ้น Sberbank กำลังเปิดตัวส่วนประกอบภายนอกสำหรับบริการ 1C: DirectBank ส่วนประกอบภายนอกนี้ใช้รูปแบบลายเซ็นอิเล็กทรอนิกส์ของตัวเองและการสร้างการเชื่อมต่อที่เข้ารหัส
ระบบย่อย BSP "ลายเซ็นอิเล็กทรอนิกส์"
ตอนนี้เกี่ยวกับความง่ายในการทำงาน
"1C: Library of Standard Subsystems" (BSP) เป็นการกำหนดค่ามาตรฐานสำเร็จรูปจาก 1C ซึ่งเป็นชุดของระบบย่อยการทำงานที่เป็นสากล ซึ่งหนึ่งในนั้นเรียกว่า "Electronic Signature"
ฉันต้องการดึงความสนใจของคุณทันทีว่า BSP นั้นอยู่ในระดับหนึ่งที่แยกได้จากแพลตฟอร์ม ซึ่งมีซอฟต์แวร์และส่วนต่อประสานกับผู้ใช้ ระบบย่อย "ลายเซ็นอิเล็กทรอนิกส์" ใช้ซอฟต์แวร์และอินเทอร์เฟซผู้ใช้สำหรับการทำงานกับวิธีการเข้ารหัส (การเข้ารหัส ลายเซ็นอิเล็กทรอนิกส์)
เมื่อพิจารณาถึงระบบย่อย "ลายเซ็นอิเล็กทรอนิกส์" สิ่งสำคัญคือต้องเข้าใจว่าประกอบด้วยอะไร:
- ฟังก์ชันพื้นฐานซึ่งนำสิ่งที่ไม่ควรแตะต้องหากคุณต้องการให้ทุกอย่างทำงาน
- และมีส่วนกำหนดใหม่สำหรับนักพัฒนาเช่นเรา ซึ่งคุณสามารถเพิ่มบางสิ่งบางอย่างเพื่อทำให้บางสิ่งบางอย่างทำงานแตกต่างออกไป หากมีบางอย่างขาดหายไป เราขอแนะนำให้คุณเขียนถึงผู้ที่พัฒนา BSP เพื่อให้พวกเขารวมความเป็นไปได้ของการกำหนดนิยามใหม่ไว้ในฟังก์ชันพื้นฐาน จากนั้นคุณสามารถทำสิ่งที่คุณต้องการในส่วนที่กำหนดใหม่ได้
จำนวนอ็อบเจ็กต์ในระบบย่อยไม่มากนัก มีเพียงสองไดเร็กทอรี:
- "โปรแกรมสำหรับลายเซ็นอิเล็กทรอนิกส์และการเข้ารหัส";
- "ใบรับรองลายเซ็นอิเล็กทรอนิกส์และคีย์การเข้ารหัส"
แต่จำนวนบรรทัดของรหัสในโมดูลทั่วไปนั้นใหญ่มาก - 11.5 พันบรรทัดของรหัส และการทำงานกับระบบย่อยเองก็ไม่ง่ายนัก
จะฝังระบบย่อย "Electronic Signature" ได้อย่างไร?
สมมติว่าคุณมีการกำหนดค่าบางอย่าง คุณตัดสินใจว่าคุณต้องสร้างระบบย่อยนี้:
- ก่อนอื่นคุณต้องอ่านเกี่ยวกับระบบ ITS ว่าระบบย่อยถูกฝังอย่างไร
- จากนั้น - อ่านคำแนะนำสำหรับระบบย่อย (บทที่ "การตั้งค่าและการใช้ระบบย่อยเมื่อพัฒนาการกำหนดค่า" ส่วนย่อย "ลายเซ็นอิเล็กทรอนิกส์") - มีการเขียนขั้นตอนการปฏิบัติงาน
- อย่าลืมทำความคุ้นเคยกับตัวอย่างการเรียกไปยังระบบย่อย "ลายเซ็นอิเล็กทรอนิกส์" ในฐานสาธิต BSP
- และในตอนท้าย หลังจากที่ระบบย่อยถูกสร้างขึ้น คุณต้องทำการตรวจสอบ:
- มีการตรวจสอบแพลตฟอร์มแบบขยายเมื่อคุณฝังอ็อบเจ็กต์
- และยังมีการประมวลผลแยกต่างหากใน ITS "การตรวจสอบการฝังระบบย่อย BSP" - ด้วยความช่วยเหลือนี้ คุณสามารถตรวจสอบว่าคุณสร้างมันขึ้นมาได้อย่างไร
และถ้าคุณมีการกำหนดค่าตั้งแต่เริ่มต้น ให้ใช้ระบบย่อยและเขียนตามพื้นฐาน - คุณจะอัปเดตตัวเอง
ฉันจะทดสอบลายเซ็นอิเล็กทรอนิกส์ได้อย่างไร
- สำหรับการทดสอบคุณสามารถ ใช้ใบรับรองที่ลงนามเอง- เพื่อเผยแพร่ในสิ่งอำนวยความสะดวกของ Microsoft crypto ซึ่งมีอยู่ใน Windows
- หรือคุณสามารถ ใช้เครื่องมือป้องกันข้อมูลการเข้ารหัสลับภายนอก... ด้วยความช่วยเหลือของ "CryptoPro" คุณสามารถ:
- ดาวน์โหลดรุ่นทดลองจากเว็บไซต์ของคุณ
- สั่งซื้อใบรับรองการทดสอบของคุณผ่านศูนย์รับรองการทดสอบ
- ติดตั้งใบรับรองหลักของผู้ออกใบรับรองการทดสอบ
- ดาวน์โหลดและติดตั้งรายการเพิกถอนใบรับรอง (CRL) จาก CA นี้
ดังนั้น "จากความสะดวกสบายของโซฟาของคุณ" คุณจะได้รับสภาพแวดล้อมการทดสอบสำหรับการทำงานกับใบรับรองและการเข้ารหัส นี้สามารถใช้ได้
หน้าที่หลักของระบบย่อย "ลายเซ็นอิเล็กทรอนิกส์" จากBSP
นี่คือตัวอย่างฐานสาธิต BSP มีสองตัวเลือกการทำงานในส่วน "การดูแลระบบ": "การเข้ารหัส" และ "ลายเซ็นอิเล็กทรอนิกส์" หากคุณเปิดใช้งานไว้ คุณสามารถไปที่การตั้งค่าได้
การตั้งค่ามีสองไดเร็กทอรี: "Programs" และ "Certificates" ใน "โปรแกรม" ระบบจะตรวจพบโปรแกรมที่ติดตั้งและแสดงทันทีว่าทุกอย่างดีหรือทุกอย่างไม่ดี หากคุณใช้เครื่องมือเข้ารหัสลับเฉพาะบางอย่างที่ไม่ได้อยู่ใน BSP คุณสามารถคลิกปุ่ม "เพิ่ม" และระบุพารามิเตอร์สำหรับการเข้าถึงที่นั่น
หากคุณทำงานผ่านเว็บไคลเอ็นต์ ระบบย่อย BSP จะแจ้งให้คุณติดตั้งส่วนขยายสำหรับการทำงานกับไฟล์และส่วนขยายสำหรับการทำงานกับการเข้ารหัสก่อน สะดวกมากเพราะคุณไม่จำเป็นต้องกำหนดค่าเอง - ระบบจะค้นหาส่วนขยายและเสนอให้ติดตั้ง
คุณสามารถเพิ่มใบรับรองได้สองวิธี
- ตัวเลือกแรกคือ "จากสิ่งที่ติดตั้งบนคอมพิวเตอร์" ในกรณีนี้ กล่องโต้ตอบจะเปิดขึ้นโดยที่เราระบุว่าเราจะใช้ใบรับรองนี้อย่างไร
- และตัวเลือกที่สอง - คุณสามารถสั่งซื้อใบรับรองที่ผ่านการรับรองใหม่ได้ โปรดทราบว่าตัวแพลตฟอร์มเองไม่อนุญาตให้ออกใบรับรอง แต่ BSP ทำได้ BSP ได้รวมเข้ากับศูนย์รับรอง 1C ซึ่งออกใบรับรองลายเซ็นอิเล็กทรอนิกส์ที่ผ่านการรับรอง คุณสามารถผ่านวิซาร์ดการตั้งค่าได้:
- ระบบจะแจ้งให้คุณทราบว่าต้องกรอกและพิมพ์เอกสารใดบ้างเพื่อออกใบรับรอง
- คุณจะต้องทำข้อตกลงกับพันธมิตรที่จะสามารถดำเนินการระบุตัวตนและโอนเอกสารไปยัง 1C;
- หลังจากที่ 1C ได้รับเอกสารแล้ว จะออกใบรับรอง
- ระบบจะค้นหาและติดตั้งลงในคอมพิวเตอร์ของคุณ
ดังนั้นผู้ใช้โดยไม่ต้องออกจากโปรแกรมจะได้รับใบรับรองลายเซ็นอิเล็กทรอนิกส์ที่ผ่านการรับรอง
จากนั้นเวทย์มนตร์ก็เกิดขึ้น - การตรวจสอบใบรับรองโดยการวินิจฉัยความถูกต้องของการตั้งค่ากล่องโต้ตอบนี้ช่วยให้คุณตรวจสอบความถูกต้องของการกำหนดค่าการเข้ารหัสบนคอมพิวเตอร์ - ระบบจะพยายามลงนามด้วยใบรับรอง ตรวจสอบ เข้ารหัส ถอดรหัส นอกจากนี้ยังสามารถแทรกการวินิจฉัยเพิ่มเติมได้ที่นี่
หากคุณหรือลูกค้าของคุณมีปัญหาใดๆ ให้เรียกใช้ "การวินิจฉัย" แล้วทุกอย่างจะชัดเจน หากมีปัญหาดังในตัวอย่างบนสไลด์ คุณสามารถคลิกที่ไอคอนข้อผิดพลาด มันจะแสดงให้คุณเห็น เหตุผลที่เป็นไปได้และจะพยายามแนะนำสิ่งที่ต้องแก้ไข
วิธีการโทรสำหรับการเซ็นชื่อและการเข้ารหัส / ถอดรหัสสามารถเห็นได้ในตัวอย่างของไดเรกทอรี "ไฟล์" ในฐานข้อมูลสาธิต BSP หรือใน "1C: การจัดการการค้า", "1C: ERP" - มีระบบย่อยเดียวกัน
บริการ "1C-EDO" และ "1C: ธนาคารโดยตรง"
การเข้ารหัสใช้ในบริการอย่างไร? บริการแรก 1C-EDO เป็นบริการที่ออกแบบมาสำหรับการแลกเปลี่ยนเอกสารอิเล็กทรอนิกส์ที่สำคัญทางกฎหมายผ่านผู้ให้บริการ 1C ที่เป็นมิตร
- ฟังก์ชันไคลเอ็นต์ได้รับการพัฒนาใน "ไลบรารีเอกสารอิเล็กทรอนิกส์"
- เมื่อคุณพยายามเชื่อมต่อกับเซิร์ฟเวอร์ การเชื่อมต่อ SSL ที่เข้ารหัส (ผ่าน HTTPS) จะเกิดขึ้นโดยใช้อัลกอริทึม RSA
- ใช้การรับรองความถูกต้องด้วยการเข้ารหัส เนื่องจากเซิร์ฟเวอร์ไม่รู้อะไรเกี่ยวกับเราเลย โทเค็นที่เข้ารหัสจึงส่งถึงคุณ และหากคุณเป็นบุคคลที่ "ถูกต้อง" คุณจะถอดรหัสโทเค็นนี้โดยใช้คีย์ส่วนตัวแล้วใช้เพื่อแลกเปลี่ยนข้อมูล
- สามารถดูเอกสารอิเล็กทรอนิกส์ ลงนาม ตรวจสอบ บรรจุลงในแพ็กเก็ตข้อมูล และส่งได้
- การยืนยันและโดยทั่วไปการเข้ารหัสทั้งหมดทำงานผ่าน BSP การตรวจสอบลายเซ็นอิเล็กทรอนิกส์ดำเนินการในสองขั้นตอน:
- ขั้นแรกให้ตรวจสอบความถูกต้องของใบรับรอง: ระยะเวลาที่มีผลบังคับใช้, สายแห่งความไว้วางใจ, คุณลักษณะ;
- หากทุกอย่างเรียบร้อยดีกับใบรับรอง การคำนวณแฮชทางคณิตศาสตร์ก็จะดำเนินการ หากทุกอย่างลงตัวกับคณิตศาสตร์ ลายเซ็นจะถือว่าถูกต้องและแนบมากับเอกสาร
- นอกจากนี้ ด้วยความช่วยเหลือของ BSP การวินิจฉัยเพิ่มเติมของการตั้งค่า EDM ได้ถูกนำมาใช้ - มีการระบุว่าเซิร์ฟเวอร์พร้อมใช้งาน และทุกอย่างเป็นไปตามลำดับของผู้เข้าร่วมในโฟลว์เอกสารอิเล็กทรอนิกส์ - เขามีแผนภาษีที่ใช้งานอยู่ ฯลฯ
บริการที่สองคือ 1C: DirectBank จุดประสงค์คือเพื่อแลกเปลี่ยนเอกสารอิเล็กทรอนิกส์กับธนาคารโดยตรง โดยไม่ผ่านโปรแกรมลูกค้า-ธนาคาร
- บริการนี้มีให้ใน "Library of Electronic Documents" ด้วย
- เทคโนโลยีแบบเปิด DirectBank อธิบายไว้ใน GitHub
- จากใหม่ - ช่องทางการสื่อสารที่เข้ารหัสพร้อมบริการสามารถยกระดับบนอัลกอริทึม GOST
- การตั้งค่าการแลกเปลี่ยนทำได้ดังนี้: 1C ร้องขอไปยังธนาคารเพื่อรับการตั้งค่าสำหรับลูกค้าเฉพาะ หากจำเป็น ร่วมกับการตั้งค่า ธนาคารจะส่งส่วนประกอบภายนอก ซึ่งใช้สำหรับการแลกเปลี่ยนเพิ่มเติม (ตามที่ Sberbank ดำเนินการ)
- การให้สิทธิ์ทำได้โดยโทเค็นที่เข้ารหัสหรือทาง SMS (ผ่านรหัสผ่านแบบใช้ครั้งเดียว)
- การลงนามและการตรวจสอบลายเซ็นอิเล็กทรอนิกส์ทำงานผ่าน BSP หรือผ่านส่วนประกอบภายนอก (ขึ้นอยู่กับวิธีที่ธนาคารดำเนินการเอง)
- และการวินิจฉัยก็น่าสนใจยิ่งขึ้นที่นี่ ผ่านการแลกเปลี่ยนเอกสารอิเล็กทรอนิกส์ประเภทพิเศษอย่างเต็มรูปแบบ - "คำขอโพรบ"
- ระบบ 1C ได้รับอนุญาตในระบบของธนาคารและส่งเอกสารอิเล็กทรอนิกส์พร้อมลายเซ็น
- ธนาคารตรวจสอบลายเซ็นอิเล็กทรอนิกส์ของลูกค้า สร้างการแจ้งเตือนว่าทุกอย่างเรียบร้อยดี และลงนามในหนังสือแจ้งด้วยลายเซ็น
- การแจ้งเตือนมาถึงที่ 1C ตรวจสอบว่าลายเซ็นของธนาคารถูกต้องแล้วบอกว่าทุกอย่างเป็นไปตามลำดับ
นี่เป็นวงจรขนาดเล็ก - ทำให้ชัดเจนว่าการแลกเปลี่ยนของคุณได้รับการกำหนดค่าอย่างถูกต้องกับธนาคารอย่างไร
โซลูชันของตัวเองด้วยการเข้ารหัสบนแพลตฟอร์ม 1C
จะพัฒนาโซลูชันการเข้ารหัสของคุณเองได้อย่างไร?
คุณสามารถสร้างการกำหนดค่าตั้งแต่เริ่มต้นโดยเปิด Syntax Assistant และใช้ความสามารถของแพลตฟอร์มสำหรับการดำเนินการเข้ารหัส แต่ฉันอยากจะแนะนำให้ใช้ BSP - มีการเขียนไว้มากมายแล้ว ในกรณีนี้ คุณต้องเขียนโค้ดไม่เกิน 11,000 บรรทัด แต่ให้น้อยกว่านั้น แต่โค้ดห้าพันบรรทัดแน่ๆ
ฉันได้บอกวิธีการทดสอบให้คุณแล้ว คุณสามารถรับใบรับรองการทดสอบและทดลองใช้งานได้
หากคุณได้พัฒนาการกำหนดค่าตั้งแต่เริ่มต้น คุณจะรักษาไว้เอง และหากคุณใช้ BSP ในระหว่างการพัฒนา และเปิดตัวคุณลักษณะใหม่บางอย่าง คุณสามารถอัปเดตระบบย่อย BSP และลองใช้คุณลักษณะนี้ ความยากลำบากจะเกิดขึ้นในทุกกรณีเพราะไม่มี "กระสุนเงิน" ที่นี่ ฉันจะเข้าใกล้การประเมินว่ามันคุ้มค่าหรือไม่ที่จะประดิษฐ์บางสิ่งขึ้นอยู่กับปัญหาที่คุณต้องการแก้ไข เมื่อพิจารณาถึงงานเฉพาะ คุณได้เลือกแล้ว: โซลูชันของคุณเองหรือโซลูชันมาตรฐานตาม BSP
ตัวอย่างของโซลูชันของเราเองคือการพัฒนาพันธมิตรด้านอุตสาหกรรมไอที พวกเขาพัฒนาโมดูลขนาดเล็กสำหรับการจัดการเอกสารอิเล็กทรอนิกส์ภายในโดยอิงจาก 1C: UPP บนพื้นฐานของแบบฟอร์มที่พิมพ์ออกมาจะมีการสร้างเอกสารอิเล็กทรอนิกส์ซึ่งเชื่อมโยงกับเอกสารของฐานข้อมูลและเป็นไปได้ที่จะลงนามด้วยลายเซ็นอิเล็กทรอนิกส์ โฟลว์เอกสารอย่างง่ายภายในบริษัท แต่คุณยังต้องติดตาม
ความยากลำบากในการใช้การเข้ารหัสและลายเซ็นดิจิทัลในองค์กร
สิ่งที่เป็น ปัญหาหลัก?
- หากคุณต้องการติดตั้งบนคอมพิวเตอร์เครื่องเดียว การเข้ารหัสลับสองวิธี ความขัดแย้งจะเกิดขึ้น... ตัวอย่างเช่น หากการรายงานของคุณทำงานผ่าน VipNet และการจัดการเอกสารอิเล็กทรอนิกส์กับคู่สัญญาผ่าน CryptoPro จะแก้ปัญหานี้อย่างไร?
ตัวเลือกแรกคือแจกจ่ายสินทรัพย์ crypto เหล่านี้ไปยังคอมพิวเตอร์เครื่องอื่น
หากไม่สามารถทำได้ สำหรับบริการใดบริการหนึ่ง คุณต้องออกใบรับรองในอุปกรณ์เข้ารหัสอื่น ๆ - เมื่อคุณสั่งซื้อใบรับรองจากศูนย์รับรอง คุณสามารถระบุได้ว่าจะใช้สิ่งอำนวยความสะดวก crypto ใด
- บางครั้งที่ลูกค้า การเข้ารหัสไม่ทำงานในเบราว์เซอร์ IE- จำเป็นต้องติดตั้งส่วนขยาย แต่ไม่ได้ติดตั้ง คำแนะนำซ้ำซาก - เรียกใช้เบราว์เซอร์ในฐานะผู้ดูแลระบบ... การดำเนินการนี้จะติดตั้งส่วนขยายและปัญหาจะได้รับการแก้ไข
- โปรแกรม 1C ไม่เห็นโทเค็น JaCard เสมอไป... ฉันไม่รู้ว่าปัญหาคืออะไร ไม่ว่าจะเป็น JaCard หรือแพลตฟอร์ม คุณติดตั้งเครื่องมือเข้ารหัสลับใหม่ - ใช้งานได้ระยะหนึ่ง และหลังจากรีบูตระบบ เครื่องมือจะบินอีกครั้ง ด้วยเหตุผลบางประการ 1C และ JaCard ไม่ค่อยเป็นมิตร
- มีปัญหาอื่น - เมื่อตรวจสอบใบรับรอง แพลตฟอร์มจะพยายามตรวจสอบว่าใบรับรองนี้เชื่อถือได้เพียงใด และบางครั้งก็ล้มเหลว ทำไมสิ่งนี้ถึงเกิดขึ้น? มีรายการเพิกถอนที่มีใบรับรองที่ไม่ถูกต้อง ตัวอย่างเช่น เมื่อพนักงานลาออกจากบริษัท จะต้องแจ้งศูนย์รับรองว่าพนักงานลาออกและใบรับรองของเขาใช้ไม่ได้ หลังจากนั้นหน่วยงานออกใบรับรองจะออกรายการตรวจสอบซึ่งรวมถึงใบรับรองนี้หลังจากนั้นจะถือว่าไม่ถูกต้อง ในบางครั้ง ด้วยเหตุผลบางประการ จึงไม่สามารถตรวจสอบใบรับรองในรายการที่ถูกเพิกถอนได้ อะไรคือปัญหา? รายการบทวิจารณ์เหล่านี้ไม่มีส่วนเกี่ยวข้องกับ 1C แต่จะได้รับการอัปเดตโดยอัตโนมัติโดยเครื่องมือเข้ารหัสลับเอง ในการดำเนินการนี้ ต้องกำหนดค่าแชนเนลที่เสถียรด้วยผู้ออกใบรับรอง หากรายการรีวิวไม่ได้รับการอัปเดตโดยอัตโนมัติ แสดงว่าบริการไม่ได้รับการกำหนดค่าอย่างเหมาะสมในหน่วยงานออกใบรับรอง หรือไม่มีอยู่เลย เปลี่ยนผู้ออกใบรับรองและปัญหาจะหายไป
- เมื่อมีใบรับรองจำนวนมาก (เช่น มากกว่า 30 ใบ) ปัญหาก็เริ่มขึ้น สมมติว่าคุณย้ายธุรกิจของคุณไปยังระบบรางอิเล็กทรอนิกส์ และเมื่อถึงวันทำงาน ปรากฏว่าลายเซ็นไม่ถูกต้องเนื่องจากใบรับรองหมดอายุ การออกใบรับรองต้องใช้เวลา ธุรกิจก็ "ติดใจ" คุณเช่นกัน สำหรับกรณีดังกล่าว คุณต้องใช้ซอฟต์แวร์พิเศษเพื่อรักษารายการใบรับรอง... มีโปรแกรมที่ให้คุณควบคุมได้ วงจรชีวิตใบรับรองและเมื่อหมดอายุจะส่งการแจ้งเตือนไปยังผู้ดูแลระบบ นี่เป็นตัวเลือกเล็กน้อย แต่ช่วยให้คุณสามารถสั่งซื้อใบรับรองได้ไม่มากก็น้อย
- การแลกเปลี่ยนข้อมูลจาก 1C เกิดขึ้นจากเซิร์ฟเวอร์ ดังนั้น:
- เปิดพอร์ตบน 1C: เซิร์ฟเวอร์องค์กร;
- สิทธิ บัญชีผู้ใช้เซิร์ฟเวอร์ต้องเป็น "การเชื่อมต่ออินเทอร์เน็ต";
- หากคุณมีคลัสเตอร์ของเซิร์ฟเวอร์ หมายความว่าเซิร์ฟเวอร์ 1C ทั้งหมดที่รวมอยู่ในคลัสเตอร์ต้องมีพอร์ตที่เปิดอยู่
- หากไม่มีความไว้วางใจในทรัพยากรภายนอก มีบทความแยกต่างหากเกี่ยวกับ "การวินิจฉัยปัญหา" ของ ITS โหนดระยะไกลไม่ผ่านการทดสอบ ""
- กฎความปลอดภัยขั้นพื้นฐาน:
- เราไม่เก็บรหัสผ่านไว้บนสติกเกอร์
- หลังเลิกงานเราจะนำโทเค็นออกจากรถยนต์
- เราอัปเดตโปรแกรมป้องกันไวรัสเป็นประจำ
มิฉะนั้น จะกลายเป็นว่าคุณได้จัดหาวิธีการเข้ารหัสลับที่ผ่านการรับรอง คีย์ และมีไวรัสอยู่รอบๆ ที่สามารถใช้ประโยชน์จากสิ่งนี้ได้ ดังนั้นป้องกันปริมณฑล
ที่มาของข้อมูล
คำถาม
ฉันขอแนะนำให้ใช้ศูนย์รับรองที่คุณจะทำงานในอนาคตในแง่ของการแลกเปลี่ยนเอกสารอิเล็กทรอนิกส์ ตัวอย่างเช่น มี Taxcom ผู้ดำเนินการจัดการเอกสารอิเล็กทรอนิกส์ เขามีศูนย์รับรอง หากคุณเริ่มการจัดการเอกสารอิเล็กทรอนิกส์ผ่าน Taxcom การสมัครขอใบรับรองนั้นสมเหตุสมผล
คุณบอกว่า FSB ให้ความกระจ่างบางอย่างเกี่ยวกับใบรับรองระบบคลาวด์ ว่าถ้าใบรับรองไม่ได้เก็บไว้ในเครื่อง แต่ในระบบคลาวด์ ก็ถือว่าเสริมความแข็งแกร่งไม่ได้ ในกรณีของการแลกเปลี่ยนมาตรฐานของใบแจ้งหนี้และ FRTT เราสามารถใช้ใบรับรองระบบคลาวด์หรือจำเป็นต้องมีการเสริมความแข็งแกร่งหรือไม่?
กฎหมายระบุว่าในการแลกเปลี่ยนใบแจ้งหนี้ จำเป็นต้องมีลายเซ็นอิเล็กทรอนิกส์ที่ผ่านการรับรอง ดังนั้น "คลาวด์" จะไม่ทำงานที่นี่ แต่สำหรับเอกสารอิเล็กทรอนิกส์ประเภทอื่น - ได้โปรด
พูดโดยคร่าว ๆ สำหรับ EDF มาตรฐานใด ๆ ที่เราใช้ใน 1C เราจำเป็นต้องมีใบรับรองที่ปรับปรุงแล้วหรือไม่
ไม่ ไม่ใช่สำหรับทุกคน กฎหมายระบุไว้เกี่ยวกับใบแจ้งหนี้อิเล็กทรอนิกส์เท่านั้น พวกเขาจะต้องลงนามด้วยลายเซ็นอิเล็กทรอนิกส์ที่ผ่านการรับรอง ไม่มีการเขียนเกี่ยวกับเอกสารที่เหลือ ซึ่งหมายความว่าสำหรับใบแจ้งหนี้ สำหรับคำสั่งซื้อ คุณสามารถใช้ลายเซ็นอิเล็กทรอนิกส์ที่ไม่ผ่านการรับรองที่เข้มงวดยิ่งขึ้นได้ รวมถึงในระบบคลาวด์
และไม่มีอะไรเกี่ยวกับ FRT? อันที่จริงแล้ว FRT ตอนนี้เหมือนกับใบแจ้งหนี้
มีคำจำกัดความที่คลุมเครืออยู่ที่นั่น - ใบแจ้งหนี้ที่มีตัวบ่งชี้เพิ่มเติม แต่ไม่เหมือนกับ UPD ดังนั้น ฉันคิดว่า UPD จัดอยู่ในหมวดหมู่ของลายเซ็นอิเล็กทรอนิกส์ที่ไม่เหมาะสม
และตัวดำเนินการทำหน้าที่อะไรในห่วงโซ่ทั้งหมดนี้ - 1C-EDO หรือ Taxcom? โดยปกติแล้ว เราจะส่งเอกสารไปยังหน่วยงานของรัฐและแลกเปลี่ยนใบแจ้งหนี้ผ่านผู้ให้บริการ และในการแลกเปลี่ยนเอกสารอื่นๆ กับคู่สัญญา เหตุใดเราจึงต้องมีผู้ดำเนินการ
ผู้ประกอบการในตลาดก็ทำงานมาหลายวันเช่นกัน ใบแจ้งหนี้ผ่านพ้นไป พวกเขาพูดอย่างนั้น - คุณส่งใบแจ้งหนี้หนึ่งใบและเอกสารอีกสองฉบับนั้นฟรี คุณจะยังคงแลกเปลี่ยนใบแจ้งหนี้ผ่านพวกเขา ดังนั้นจึงง่ายต่อการส่งเอกสารผ่านพวกเขาเช่นกัน อีกอย่างคือ ถ้าคุณใช้ระบบที่เรียบง่ายและไม่มีใบแจ้งหนี้ คุณสามารถขอให้ผู้ให้บริการค้นหาแผนภาษีที่ไม่แพงสำหรับคุณ ดังนั้นใน "Library of Electronic Documents" เดียวกันจึงสามารถแลกเปลี่ยนเอกสารด้วยลายเซ็นอิเล็กทรอนิกส์ทางอีเมลผ่าน FTP เป็นต้น แต่เมื่อคุณมีผู้รับเหมา 100 ราย จะเป็นการยากที่จะจัดช่องทางการสื่อสารของคุณเองสำหรับผู้รับเหมาแต่ละรายในแง่ของการสนับสนุน
และถ้าเราต้องการทดสอบใบรับรองที่ลงนามเอง เราสามารถทดสอบการแลกเปลี่ยนโดยใช้ใบรับรองที่ลงนามเองได้หรือไม่
ไม่ผ่านโอเปอเรเตอร์ - ไม่ หากคุณต้องการทดสอบจริงๆ เขียนถึง 1C ว่าคุณต้องการเชื่อมต่อกับบริการ EDF เพื่อทดสอบ
พวกเขาบอกว่าเราไม่ใช่ผู้ออกใบรับรอง
เขียนถึงฉันฉันจะช่วย
และถ้าเราแลกเปลี่ยนกันโดยไม่มีโอเปอเรเตอร์ EDM พวกเขาก็นำเอกสารอิเล็กทรอนิกส์ที่มีลายเซ็นมาให้ฉัน และฉันต้องการอัปโหลดไปที่ 1C เพื่อเก็บไว้ที่นั่น BSP มีเงินเพียงพอที่จะตรวจสอบว่านี่คือ CEP และมีรายละเอียดที่ถูกต้องหรือไม่ เพื่อให้ทั้งหมดนี้อยู่ในโหมดอัตโนมัติโดยไม่มีหน้าต่างโมดอล ฯลฯ
ฉันไม่เคยเห็นกรณีดังกล่าวในการปฏิบัติของฉัน แต่ใน BSP คุณสามารถดาวน์โหลดไฟล์และตรวจสอบลายเซ็นอิเล็กทรอนิกส์ได้อย่างแน่นอน เป็นไปได้มากว่าคุณจะต้องวาดต้นแบบบางอย่างสำหรับสถานการณ์นี้: ตรวจสอบโฟลเดอร์ นำเอกสาร ใช้ลายเซ็น ตรวจสอบทั้งหมด วางไว้ในที่ที่คุณต้องการและบอกว่าทุกอย่างเรียบร้อย สำหรับการซิงโครไนซ์การโทรทั้งหมดนี้มีการใช้งานใน BSP ทุกอย่างในเบราว์เซอร์ทำงานในโหมดอะซิงโครนัส
และถ้าคุณทำงานใน 1C บนเทอร์มินัล? เป็นไปได้ไหมที่จะติดตั้ง CryptoPro และฟอร์เวิร์ดคีย์ในเทอร์มินัล? คุณสมบัติ มีปัญหาอย่างไร? ดังนั้น หากเรามีนิติบุคคลมากกว่า 20 แห่ง และสำหรับแต่ละนิติบุคคลมีกุญแจสองดอก ความแตกต่างของสิทธิในกุญแจเหล่านี้จะดำเนินไปอย่างไร? ที่ระดับ 1C หรืออะไร?
ใน BSP เอง เมื่อคุณโหลดส่วนที่เปิดอยู่ของคีย์ เป็นไปได้ที่จะระบุให้ผู้ใช้คนใดสามารถใช้งานได้ ที่นั่น คุณสามารถเข้าสู่ระบบด้วยชื่อของคุณ เพื่อดูเฉพาะใบรับรองของคุณ แต่ในขณะเดียวกัน พวกมันทั้งหมดก็จะอยู่ในคอมพิวเตอร์ด้วย ดังนั้น คุณเองเข้าใจดีว่าไม่จำเป็นต้องติดตั้งส่วนส่วนตัวในรีจิสทรีอย่างแน่นอน เนื่องจากส่วนส่วนตัวของคีย์สามารถถ่ายโอนจากเครื่องหนึ่งไปยังอีกเครื่องหนึ่งได้อย่างง่ายดาย ใช้โทเค็นดีกว่า เป็นไปได้ที่จะส่งต่อโทเค็นด้วย ส่วนปิดคีย์ไปยังเซิร์ฟเวอร์เทอร์มินัล พวกที่สร้างกุญแจเองช่วยตั้งค่าเพื่อให้คีย์นี้มองเห็นได้ในเทอร์มินัล ลองใช้ ทดลอง ค้นหาคีย์อื่นๆ ค้นหาคนที่จะช่วยคุณตั้งค่า แต่ที่นี่คุณต้องเข้าใจว่าอุโมงค์ข้อมูลนี้จากเซิร์ฟเวอร์เทอร์มินัลไปยังคีย์ของคุณไม่ปลอดภัย คุณสร้างเอกสารอิเล็กทรอนิกส์บนเซิร์ฟเวอร์เทอร์มินัลแล้วพูดว่า - เซ็นชื่อ อะไรจะเกิดขึ้น? ข้อมูลจะถูกส่งผ่านช่องสัญญาณที่ไม่มีการป้องกันก่อนไปยังคอมพิวเตอร์ในพื้นที่ที่ติดตั้งคีย์ จากนั้นสร้างลายเซ็นอิเล็กทรอนิกส์ จากนั้นข้อมูลจะถูกโอนกลับไปยังเซิร์ฟเวอร์เทอร์มินัล แต่ช่องนี้ไม่ปลอดภัย สามารถป้องกันได้โดยการติดตั้งเฉพาะ ซอฟต์แวร์ซึ่งทำให้ช่องสัญญาณระหว่างเซิร์ฟเวอร์เทอร์มินัลและเครื่องในเครื่องมีความปลอดภัย หากคุณต้องการทำงานอย่างปลอดภัย คุณต้องใส่โทเค็น ส่งต่อไปยังเทอร์มินัลและติดตั้งซอฟต์แวร์สำหรับเข้ารหัสช่องทางระหว่างเซิร์ฟเวอร์เทอร์มินัลและเครื่องไคลเอนต์
บอกฉันว่ามีความแตกต่างในความเร็วระหว่างการลงนามในใบแจ้งหนี้อิเล็กทรอนิกส์และสัญญาสแกน 100 หน้า (โดยที่กราฟิกล้วนๆ)
ยิ่งเอกสารมีขนาดใหญ่เท่าใด การเซ็นชื่อก็จะยิ่งช้าลง เนื่องจากมีการเข้ารหัสแบบอะซิงโครนัส - แฮชจะคำนวณโดยใช้อัลกอริทึมแบบอะซิงโครนัส แต่จากมุมมองว่าคุณกำลังลงนามในใบแจ้งหนี้อิเล็กทรอนิกส์ในหลายบรรทัดหรือไฟล์ 10MB คุณจะไม่สังเกตเห็นความแตกต่างทางสายตา ประกาศเฉพาะเล่ม 1,000-3,000 เอกสารเท่านั้น
เกี่ยวกับการโรมมิ่ง 1C-EDO Taxcom มีการโรมมิ่งระหว่างผู้ให้บริการ 1C-EDO มีประสิทธิภาพแค่ไหน? คุณมีประสบการณ์ดังกล่าวหรือไม่? เนื่องจากผู้รับเหมาทุกรายใช้โอเปอเรเตอร์ต่างกันและยากมากที่จะเลือกโอเปอเรเตอร์ที่มีความครอบคลุมสูงสุด คุณจะแนะนำใคร
หากคุณเลือกระหว่าง 1C-EDO กับรุ่นอื่นๆ แน่นอนว่า 1C-EDO แต่ 1C-EDO มีปัญหากับการโรมมิ่ง - ไม่รองรับผู้ให้บริการหลายราย มีทรัพยากรแยกต่างหากสำหรับ 1C-EDO มีรายการโอเปอเรเตอร์ที่รองรับ ฉันคิดว่าควรเติมใหม่เมื่อเวลาผ่านไป
จะเก็บเอกสารที่ลงนามไว้ที่ไหน? ในบริษัทหรือในคลาวด์? เป็นไปได้ไหมที่จะรับรองความถูกต้องของเอกสารที่จัดเก็บไว้ในคลาวด์?
ที่ที่เราจัดเก็บเอกสารที่ลงนามแล้ว (ในคลาวด์หรือไม่) ไม่สำคัญ ในทางคณิตศาสตร์ แฮชได้รับการคำนวณแล้ว และเนื้อหาของเอกสารไม่สามารถแทนที่ได้โดยไม่มีการติดตาม จากนั้นคุณสามารถโอนอย่างน้อย 10 ครั้งที่ไหนสักแห่ง ลายเซ็นสามารถตรวจสอบได้เสมอทางคณิตศาสตร์อย่างหมดจด หากบริการคลาวด์สะดวก โปรดเก็บไว้ในนั้น น่าสนใจกว่านี้
ผู้ประกอบการให้บริการดังกล่าวหรือไม่?
หากคุณทำสัญญาแยกต่างหากกับเขาเพื่อจัดเก็บข้อมูลสำรอง พวกเขาจะทำเพื่อเงินแยกต่างหาก
พวกเขาไม่เก็บเอกสารที่ลงนามไว้หรือ
พวกเขาถูกเก็บไว้ทางกายภาพ แต่กฎหมายไม่ได้กำหนดให้ต้องจัดเก็บ พวกเขาจะต้องเก็บใบเสร็จเท่านั้น หากหน่วยงานด้านภาษีมาหาพวกเขาและถามว่าเอกสารดังกล่าวผ่านหรือไม่พวกเขาจะแสดงใช่นี่คือใบเสร็จรับเงินดู - ลายเซ็นเป็นเช่นนั้น และสิ่งที่อยู่ในเอกสารนี้ไม่ใช่คำถามสำหรับพวกเขาอีกต่อไป
และสำหรับ SCP ผู้ปฏิบัติงานไม่ได้จัดเตรียมการประมวลผลสำหรับ EDF เลยใช่หรือไม่
ฉันไม่สามารถพูดเกี่ยวกับโอเปอเรเตอร์ได้ มีหลายตัว และแต่ละตัวก็มีพัฒนาการของตัวเอง แต่ UPP เองก็มีโฟลว์เอกสารอิเล็กทรอนิกส์
****************
บทความนี้เขียนขึ้นจากผลการอ่านในการประชุม INFOSTART EVENT 2017 COMMUNITY สามารถอ่านบทความเพิ่มเติมได้
ในปี 2020 เราขอเชิญทุกคนเข้าร่วมมีตติ้งระดับภูมิภาค 7 ครั้ง รวมถึงงานครบรอบ INFOSTART EVENT 2020 ในมอสโก
ลายเซ็นอิเล็กทรอนิกส์ (ต่อไปนี้ - ES) ตามกฎหมายของรัฐบาลกลาง สหพันธรัฐรัสเซียหมายเลข 63-ФЗลงวันที่ 25 มีนาคม 2554 "ในลายเซ็นอิเล็กทรอนิกส์" หมายถึงข้อมูลในรูปแบบอิเล็กทรอนิกส์ซึ่งแนบมากับข้อมูลอื่น ๆ ในรูปแบบอิเล็กทรอนิกส์ (ข้อมูลที่ลงนาม) หรือเกี่ยวข้องกับข้อมูลดังกล่าวและใช้เพื่อระบุ ผู้ลงนามในข้อมูล ... พระราชบัญญัติกฎเกณฑ์ที่ระบุแทนที่กฎหมายของรัฐบาลกลางของสหพันธรัฐรัสเซียฉบับที่ 1-FZ เมื่อวันที่ 10 มกราคม 2545 "ในลายเซ็นดิจิทัลอิเล็กทรอนิกส์" ซึ่งสูญเสียอำนาจทางกฎหมายไปเมื่อวันที่ 1 กรกฎาคม 2013
กฎหมายของวันที่ 25 มีนาคม 2011 แบ่งลายเซ็นอิเล็กทรอนิกส์ออกเป็นสองประเภท: แบบธรรมดาและแบบปรับปรุง หลังสามารถมีคุณสมบัติหรือไม่ชำนาญ หาก ES ธรรมดายืนยันว่ามีการส่งข้อความอิเล็กทรอนิกส์ที่กำหนดโดยบุคคลใดบุคคลหนึ่ง ES ที่ไม่ผ่านการรับรองที่เสริมความแข็งแกร่งจะไม่เพียงแต่ระบุผู้ส่งได้อย่างชัดเจนเท่านั้น แต่ยังยืนยันว่าไม่มีใครเปลี่ยนแปลงข้อความดังกล่าวตั้งแต่ลงนามในเอกสาร ในอนาคตเราจะพูดถึงการเสริม ES ที่ไม่มีเงื่อนไข ข้อความที่มีลายเซ็นอิเล็กทรอนิกส์ที่ไม่เหมาะสมสามารถถือได้ว่าเป็นเอกสารกระดาษที่ลงนามด้วยมือของตนเอง หากคู่สัญญาได้ตกลงล่วงหน้าในเรื่องนี้ รวมทั้งในกรณีที่กฎหมายกำหนดไว้เป็นพิเศษ
ในอีกด้านหนึ่ง ES ใช้เพื่อยืนยันการประพันธ์เอกสาร - นี่คือความหมายสำหรับผู้ส่งเอกสาร ในทางกลับกัน ลายเซ็นอิเล็กทรอนิกส์ หากได้รับการยอมรับว่าถูกต้องตามกฎหมาย จะช่วยให้แน่ใจว่าผู้เขียนจะไม่ปฏิเสธเอกสารที่ลงนาม ซึ่งเป็นสิ่งสำคัญสำหรับผู้รับเอกสาร ในกรณีที่มีสถานการณ์ที่ขัดแย้งกัน การวิเคราะห์ความขัดแย้งสามารถทำได้เสมอ ซึ่งจะกำหนดผู้เขียนเอกสารที่ลงนามอย่างไม่น่าสงสัยและทำให้เขาต้องรับผิดชอบในเอกสารที่ลงนาม
การวิเคราะห์ข้อขัดแย้งที่เกี่ยวข้องกับลายเซ็นอิเล็กทรอนิกส์
ปัญหาหลักในการวิเคราะห์ความขัดแย้งในสถานการณ์กีฬาตามเอกสารที่ลงนามโดยลายเซ็นอิเล็กทรอนิกส์คือการพิสูจน์ข้อเท็จจริงที่ว่า "ข้อมูลในรูปแบบอิเล็กทรอนิกส์ซึ่งแนบกับข้อมูลอื่น ๆ ในรูปแบบอิเล็กทรอนิกส์ (ข้อมูลที่ลงนาม)" มีความสำคัญทางกฎหมาย ลายเซ็นอิเล็กทรอนิกส์ของบุคคลใดบุคคลหนึ่งภายใต้เอกสารเฉพาะ
การใช้วิธีการเข้ารหัสช่วยให้เราสามารถแก้ปัญหานี้ได้ หากบุคคลได้รับคีย์อิเล็กทรอนิกส์ที่ไม่ซ้ำใคร จากนั้นจึงทำการแปลงแบบพิเศษโดยใช้คีย์อิเล็กทรอนิกส์นี้และเอกสารอิเล็กทรอนิกส์ ผลลัพธ์ของการเปลี่ยนแปลงเหล่านี้ (และนี่คือลายเซ็นอิเล็กทรอนิกส์) จะไม่ซ้ำกันสำหรับคู่นี้ (เอกสารคีย์) ดังนั้นงานในขั้นตอนแรกในการวิเคราะห์ข้อขัดแย้ง - เพื่อเปิดเผยว่าลายเซ็นที่กำหนดถูกสร้างขึ้นโดยใช้คีย์อิเล็กทรอนิกส์ที่กำหนดหรือไม่ - ได้รับการแก้ไขโดยวิธีการเข้ารหัส
ขั้นตอนที่สองในการวิเคราะห์ความขัดแย้งคือการพิสูจน์ว่ากุญแจอิเล็กทรอนิกส์นี้เป็นทรัพย์สินของบุคคลใดบุคคลหนึ่ง หลักฐานนี้ให้ความหมายทางกฎหมายกับ ES เพื่อแก้ปัญหาขององค์กรนี้ - การบัญชีสำหรับคีย์ที่ออก - ใช้ PKI (Public Key Infrastructure)
ให้คุณค่าทางกฎหมายแก่ ES โดยใช้ PKI
กฎหมาย "ในลายเซ็นอิเล็กทรอนิกส์" แยกความแตกต่างระหว่างคีย์ ES และคีย์การตรวจสอบ ES คีย์ลายเซ็นอิเล็กทรอนิกส์คือลำดับอักขระที่ไม่ซ้ำกันซึ่งใช้สร้างลายเซ็นอิเล็กทรอนิกส์คีย์การตรวจสอบลายเซ็นอิเล็กทรอนิกส์คือลำดับอักขระที่ไม่ซ้ำกันซึ่งเชื่อมโยงกับคีย์ลายเซ็นอิเล็กทรอนิกส์โดยเฉพาะและได้รับการออกแบบมาเพื่อตรวจสอบความถูกต้องของลายเซ็นอิเล็กทรอนิกส์ คีย์ ES ได้มาจากคีย์ ES แต่การดำเนินการย้อนกลับเป็นไปไม่ได้ ดังนั้นจึงมีการติดต่อกันแบบหนึ่งต่อหนึ่งระหว่างคีย์ ES และคีย์การตรวจสอบ ES ลูกค้าต้องสร้างคีย์ ES เองและเก็บเป็นความลับ เป็นคีย์นี้ที่ใช้ในการลงนามในเอกสารด้วยลายเซ็นอิเล็กทรอนิกส์ คีย์การตรวจสอบ ES ใช้เพื่อยืนยัน ES และแจกจ่ายให้กับทุกคนที่ต้องการตรวจสอบลายเซ็น
องค์ประกอบหลักของ PKI คือผู้ออกใบรับรอง ศูนย์การรับรองจะเก็บรักษาบันทึกการติดต่อระหว่างกุญแจกับบุคคลที่เป็นเจ้าของกุญแจเหล่านี้ ในการลงทะเบียนคีย์ ลูกค้าจะนำส่วนสาธารณะของคีย์พร้อมกับข้อมูลประจำตัวของเขาไปที่ CA และรับใบรับรองความสอดคล้องเพื่อยืนยันความเป็นเจ้าของคีย์นี้โดยเฉพาะ ใบรับรองความสอดคล้องประกอบด้วยคีย์การตรวจสอบ ES และข้อมูลการระบุตัวตนของลูกค้า และลงนามโดย ES ของผู้ออกใบรับรอง ดังนั้น CA รับรองว่าลูกค้าได้รับการตรวจสอบแล้วและเป็นผู้ที่อ้างว่าเป็นใคร เมื่อได้รับใบรับรอง ในทางกลับกัน ลูกค้าจะลงนามในเอกสารพิเศษเกี่ยวกับความถูกต้องของใบรับรองที่ออกให้พร้อมลายเซ็นด้วยมือของเขา เอกสารเหล่านี้เป็นลิงค์หลักระหว่างบุคคลเฉพาะกับ "ชุดสัญลักษณ์อิเล็กทรอนิกส์" ซึ่งเป็นลายเซ็นอิเล็กทรอนิกส์ของเขา
ดังนั้น ใบรับรองของผู้ลงนามจึงเพียงพอที่จะตรวจสอบลายเซ็นและระบุตัวผู้ลงนามได้ กล่าวคือ ผู้ลงนามลงนามในเอกสารด้วยรหัส ES ของตน จากนั้นจึงส่งเอกสารที่ลงนามนี้และใบรับรองที่มีคีย์การตรวจสอบ ES ให้กับผู้รับ ดังนั้น ผู้รับจะสามารถตรวจสอบได้ว่าลายเซ็นนั้นสร้างด้วยรหัส ES ของผู้ลงนามจริง ๆ และจะได้รับข้อมูลระบุตัวตนของผู้ลงนามจากใบรับรอง ลูกค้าต้องปกป้องคีย์ ES ของเขาจากการประนีประนอม เพื่อจุดประสงค์นี้ที่การจัดเก็บคีย์ฮาร์ดแวร์ต่างๆจะถูกสร้างขึ้นด้วย ระดับสูงการป้องกัน ตัวอย่างเช่น อุปกรณ์ ruToken USB
มาตรฐานรัสเซีย EP
มาตรฐาน EDS เป็นแบบสองชั้น ในระดับแรก ลายเซ็นอิเล็กทรอนิกส์ตั้งอยู่โดยตรงจากเอกสาร ระดับที่สองประกอบด้วย ES และเอกสารทั้งหมดที่จำเป็นในการให้ความสำคัญทางกฎหมายกับ ES: ใบรับรองของผู้ลงนามหรือสายใบรับรอง เวลาในการสร้างลายเซ็น ฯลฯ
มาตรฐานรัสเซียสำหรับรหัสอิเล็กทรอนิกส์ระดับแรกคือ GOST 34-10.2012 มาตรฐานรัสเซียสำหรับ ES ระดับที่สองคือ PKCS # 7 พร้อมความสามารถในการเพิ่มการประทับเวลา TSA
ขอบเขตการใช้งาน EP
- ธนาคารทางอินเทอร์เน็ต
- ตลาดอิเล็กทรอนิกส์
- ระบบการจัดการเอกสารองค์กร
- อีเมล
- การส่งรายงานไปยังบริการของรัฐบาลกลางต่างๆ
- ลิขสิทธิ์
เว็บไซต์ที่มีลายเซ็นอิเล็กทรอนิกส์
การกำหนดปัญหา
สมมติว่าองค์กรของคุณตัดสินใจเปลี่ยนไปใช้ระบบจัดการเอกสารอิเล็กทรอนิกส์บนเว็บ ในเวลาเดียวกัน สถานที่หลักที่จำเป็นต้องมี ES คือ:
- ไฟล์ ES ของรูปแบบที่กำหนดเองเมื่อผู้ใช้อัพโหลดไปยังเว็บไซต์ผ่านแบบฟอร์มอินพุต
- ES ของข้อมูลข้อความที่ผู้ใช้ป้อนลงในแบบฟอร์มป้อนข้อมูลบนเว็บไซต์
- ลายเซ็นอิเล็กทรอนิกส์ของเอกสารที่โพสต์บนเว็บไซต์โดยผู้ใช้หลายคน
- การป้องกันการเข้ารหัสของการส่งข้อมูลระหว่างสถานที่ทำงานของผู้ใช้กับเว็บไซต์
- การตรวจสอบผู้ใช้ด้วยใบรับรองดิจิทัลเพื่อเข้าถึง .ของเขา พื้นที่ส่วนบุคคล
- การป้องกันการเข้ารหัสของข้อมูลที่จัดเก็บไว้ในเซิร์ฟเวอร์
รูปแบบการแก้ปัญหา
การสร้างศูนย์รับรอง
เลือกเซิร์ฟเวอร์ที่จะปรับใช้ผู้ออกใบรับรอง คุณสามารถเลือกใช้บริการประทับเวลาและการตรวจสอบสถานะใบรับรองออนไลน์ได้ เพื่อประหยัดเงิน CA และบริการที่ระบุสามารถใช้เซิร์ฟเวอร์เดียวได้ ซึ่งต้องพร้อมใช้งานออนไลน์ เราจะหารือถึงความเป็นไปได้ของบริการเหล่านี้ด้านล่าง
ติดตั้งผลิตภัณฑ์ MagPro CryptoPacket บนเซิร์ฟเวอร์
สร้างคีย์ CA และแอปพลิเคชันสำหรับใบรับรองรูทของ CA โดยใช้ยูทิลิตี้ mkkey จาก MagPro CryptoPacket คีย์สามารถสร้างได้ในอุปกรณ์ที่ปลอดภัย เช่น บน ruToken หลังจากสร้างคีย์ CA แล้ว จะต้องรักษาความปลอดภัยด้วยวิธีการขององค์กร ที่สุด ตัวเลือกที่ปลอดภัยจัดเก็บคีย์บนอุปกรณ์ ruToken และเชื่อมต่อกับเซิร์ฟเวอร์เมื่อออกใบรับรองเท่านั้น ใบรับรอง CA เป็นไฟล์ ไฟล์นี้จะถูกออกให้ไคลเอ็นต์ทั้งหมดของ CA ในเวลาต่อมาเมื่อพวกเขาได้รับใบรับรอง
สร้างใบรับรองรูท CA โดยใช้ยูทิลิตี้ openssl จาก MagPro CryptoPacket
สร้างโครงสร้างไดเร็กทอรีในระบบไฟล์ซึ่งใบรับรองผู้ใช้ที่ออก ใบรับรองเซิร์ฟเวอร์ที่ออก และแอปพลิเคชันใบรับรองจะถูกจัดเก็บในรูปแบบของไฟล์ วิธีการขององค์กร (เช่นการใช้ ACL) ควรให้สิทธิ์ที่ถูกต้องสำหรับไดเรกทอรีเหล่านี้ ใบรับรองจะออกเป็นไฟล์ PEM โปรดทราบว่าวิธีที่ดีที่สุดคือเก็บชื่อไฟล์ใบรับรองให้ชัดเจนเพื่อให้ค้นหาใบรับรองได้ง่ายขึ้นในภายหลัง
สร้างรหัสใบรับรอง PKCS # 10 และการลงทะเบียน
ในการขอรับใบรับรองโดยผู้ใช้ CA คุณสามารถใช้สองแผนงาน: ส่วนกลางและระยะไกล ด้วยโครงร่างแบบรวมศูนย์ ผู้ใช้มาที่ CA และเขาจะได้รับไฟล์ที่มีคีย์และใบรับรอง จากนั้นเขาก็เพิ่มไฟล์นี้ลงในแฟลชไดรฟ์ USB รูปแบบนี้เรียบง่ายและสะดวกสบาย แต่ไม่ปลอดภัย เนื่องจากช่วยให้พนักงาน CA สามารถค้นหารหัสผู้ใช้ได้ แต่ในบางกรณีการใช้โครงการนี้ก็สมเหตุสมผล
มีการแจกจ่ายโครงร่างที่ปลอดภัยที่สุดสำหรับการรับใบรับรอง ผู้ใช้สร้างคีย์ สร้างคำขอใบรับรอง PKCS # 10 ซึ่งมีคีย์การตรวจสอบ ES และข้อมูลการระบุตัวตน ผู้ใช้ลงนามในแอปพลิเคชันนี้ด้วยคีย์ ES และนำไปที่ CA CA จะตรวจสอบลายเซ็นบนแอปพลิเคชัน ตรวจสอบข้อมูลประจำตัวของผู้ใช้ เช่น ข้อมูลหนังสือเดินทาง และออกใบรับรอง จากนั้นใบรับรองจะถูกพิมพ์ออกมาและผู้ใช้ลงนามในเอกสารด้วยตนเองเพื่อยืนยันการปฏิบัติตามใบรับรองที่ออกให้
เป็นส่วนหนึ่งของการแก้ปัญหาภายใต้การสนทนา คีย์จะถูกสร้างขึ้นและคำสั่งจะถูกสร้างขึ้นโดยใช้โปรแกรมพิเศษจาก MagPro CryptoPacket โปรแกรมนี้รวมอยู่ในชุดปรับแต่ง CryptoTunnel
โปรแกรมนี้มีระบบการกำหนดค่าที่ยืดหยุ่น ซึ่งคุณสามารถสร้างคำสั่งซื้อได้อย่างสมบูรณ์ ประเภทต่างๆใบรับรอง ขยายชุดมาตรฐานของข้อมูลระบุตัวตน เพิ่มบทบาทและสิทธิ์ผู้ใช้ในใบรับรอง เช่น แยกความแตกต่างในการเข้าถึงทรัพยากรบนเว็บ เพิ่มคุณสมบัติต่าง ๆ ให้กับแอปพลิเคชัน
หลังจากสร้างคีย์แล้ว ผู้ใช้ต้องแน่ใจว่าได้จัดเก็บคีย์ไว้อย่างปลอดภัย
ประเภทของใบรับรองลายเซ็นอิเล็กทรอนิกส์บนเว็บไซต์
พอร์ทัลของเราจะใช้ใบรับรองหลายประเภท:
ใบรับรองรูท CA
ใบรับรองนี้ใช้เพื่อตรวจสอบใบรับรองอื่น ๆ ทั้งหมดสำหรับสมาชิกของเว็บพอร์ทัล
ใบรับรองการตรวจสอบสิทธิ์เซิร์ฟเวอร์ TLS
ใบรับรองนี้ใช้เพื่อยืนยันเซิร์ฟเวอร์โดยไคลเอนต์เมื่อสร้างการเชื่อมต่อ TLS ที่ปลอดภัยเมื่อโอนเอกสารที่ลงนามไปยังเว็บไซต์
ใบรับรองการตรวจสอบสิทธิ์ไคลเอ็นต์ TLS
ใบรับรองนี้ใช้เพื่อยืนยันไคลเอนต์โดยเซิร์ฟเวอร์และเพื่อให้ไคลเอนต์เข้าถึงบัญชีส่วนตัวของเขาเมื่อสร้างการเชื่อมต่อ TLS ที่ปลอดภัยเมื่อโอนเอกสารที่ลงนามไปยังเว็บไซต์
ใบรับรอง ES ของลูกค้า
ลูกค้าเพิ่มใบรับรองนี้ในลายเซ็นอิเล็กทรอนิกส์ ดังนั้นฝ่ายตรวจสอบจึงสามารถตรวจสอบลายเซ็นและระบุผู้ลงนามได้
ใบรับรองการลงนามเซิร์ฟเวอร์ OCSP
ด้วยใบรับรองนี้ เซิร์ฟเวอร์ OCSP จะเพิ่มการตอบกลับที่ลงนามเพื่อยืนยัน
ใบรับรองการลงนามเซิร์ฟเวอร์ TSA
ด้วยวิธีนี้ เซิร์ฟเวอร์ TSA จะเพิ่มใบรับรองในการตอบกลับที่ลงนามเพื่อยืนยันและให้ความสำคัญทางกฎหมาย
ใบรับรองทุกประเภทเหล่านี้สามารถสร้างได้โดยใช้ยูทิลิตี้จาก MagPro CryptoPacket และ CA ตาม MagPro CryptoPacket
การรับใบรับรองที่CA
เมื่อได้รับใบสมัครจากผู้ใช้ ผู้ดูแลระบบ CA จะสร้างสำเนาสำรองของแอปพลิเคชันของเขา จากนั้นจะตรวจสอบแอปพลิเคชัน และใช้ยูทิลิตี openssl สร้างใบรับรองผู้ใช้ ลงนามในคีย์ CA และทำการสำรองข้อมูลด้วย นอกจากนี้ เพื่อให้มั่นใจถึงความสำคัญทางกฎหมาย ผู้ดูแลระบบจะพิมพ์ข้อมูลจากใบรับรอง (ข้อมูลนี้ได้รับโดยใช้ยูทิลิตี้ openssl.exe) และรับลายเซ็นผู้ใช้ด้วยตนเองภายใต้งานพิมพ์นี้ จากนั้นจะออกใบรับรองให้กับผู้ใช้ในไฟล์
ดังนั้น ในขณะนี้ เราสามารถปรับใช้ CA และเรียนรู้วิธีสร้างคีย์ผู้ใช้ ยอมรับแอปพลิเคชันสำหรับใบรับรองจากพวกเขา และออกใบรับรองเมื่อได้รับแอปพลิเคชัน ผู้ใช้ยืนยันการรับและการปฏิบัติตามใบรับรองด้วยลายเซ็นด้วยตนเอง ดังนั้นจึงสามารถโต้แย้งได้ว่าเราได้ปรับใช้ PKI ซึ่งรับรองความสำคัญทางกฎหมายของลายเซ็นอิเล็กทรอนิกส์ของผู้ใช้
งานต่อไปคือการใช้ PKI ที่ปรับใช้ในการแก้ปัญหาที่ใช้ - จัดการการถ่ายโอนเอกสารอิเล็กทรอนิกส์ที่ลงนามอย่างปลอดภัยโดยใช้เบราว์เซอร์ไปยังเว็บไซต์และรับสำหรับการประมวลผลบนเว็บไซต์
การตรวจสอบลายเซ็นอิเล็กทรอนิกส์และโมดูลการจัดเก็บ (เซิร์ฟเวอร์)
โดยทั่วไป เว็บไซต์จะถูกปรับใช้บนเว็บเซิร์ฟเวอร์บางประเภท (Apache, IIS, nginx เป็นต้น) ไซต์นี้มีบัญชีส่วนตัวสำหรับผู้ใช้แต่ละรายที่ลงทะเบียนบนเว็บไซต์ ในการเข้าถึงบัญชีส่วนตัว ผู้ใช้ต้องผ่านขั้นตอนการตรวจสอบสิทธิ์ โดยทั่วไป การรับรองความถูกต้องประกอบด้วยการเข้าสู่ระบบและรหัสผ่านที่ตกลงกันไว้ระหว่างการลงทะเบียนผู้ใช้
นอกจากนี้ แบบฟอร์มป้อนข้อมูลทางเว็บยังใช้เพื่ออัปโหลดเอกสารอิเล็กทรอนิกส์ไปยังเซิร์ฟเวอร์
เพื่อ "ผูก" การตรวจสอบลายเซ็นอิเล็กทรอนิกส์ของเอกสารที่อัปโหลดไปยังไซต์ไปยังระบบนี้ เพื่อให้แน่ใจว่ามีการป้องกันการเชื่อมต่อระหว่างเบราว์เซอร์ของผู้ใช้และไซต์ ตลอดจนรับรองความถูกต้องของการเข้ารหัสที่เข้มงวดของผู้ใช้สำหรับการเข้าถึง สำหรับบัญชีส่วนตัว ควรติดตั้งผลิตภัณฑ์ MagPro CryptoServer บนเซิร์ฟเวอร์
โซลูชันทางสถาปัตยกรรมจะมีลักษณะดังนี้:
CryptoServer ได้รับการติดตั้งไว้ด้านหน้าเว็บเซิร์ฟเวอร์ที่มีการป้องกัน ในกรณีนี้ เว็บเซิร์ฟเวอร์ได้รับการกำหนดค่าในลักษณะที่ยอมรับการเชื่อมต่อขาเข้าจาก CryptoServer เท่านั้น (ดูคำแนะนำในการตั้งค่า) CryptoServer ยอมรับการเชื่อมต่อ HTTS ขาเข้า ถอดรหัสและส่งต่อไปยังเว็บเซิร์ฟเวอร์ นอกจากนี้ CryptoServer ยังเพิ่มส่วนหัว X509-Cert ให้กับคำขอ HTTP ซึ่งจะส่งใบรับรองดิจิทัลของไคลเอ็นต์ที่ผ่านขั้นตอนการตรวจสอบสิทธิ์แล้ว จากนั้นใบรับรองนี้จะใช้เพื่อเข้าถึงลูกค้าไปยังบัญชีส่วนตัวของเขา ในการตรวจสอบลายเซ็นอิเล็กทรอนิกส์ภายใต้เอกสารที่ส่ง CryptoServer มียูทิลิตี้ openssl ซึ่งช่วยให้คุณตรวจสอบลายเซ็นประเภทต่างๆ รับใบรับรองผู้ลงนามหรือใบรับรองห่วงโซ่จากซอง PKCS # 7 เป็นต้น ในการตรวจสอบลายเซ็นอิเล็กทรอนิกส์ หน้าเว็บสำหรับรับเอกสารต้องเรียกยูทิลิตี้นี้
โมดูลการสร้างลายเซ็นอิเล็กทรอนิกส์ (ไคลเอนต์)
งานหลักของผู้ใช้เมื่อเข้าถึงเว็บไซต์คือการอัปโหลดเอกสารอิเล็กทรอนิกส์และข้อมูลข้อความไปยังเว็บไซต์ ตลอดจนดาวน์โหลดเอกสารอิเล็กทรอนิกส์จากเว็บไซต์ เพื่อรักษาความปลอดภัยการเชื่อมต่อเว็บไปยังไซต์โดยใช้โปรโตคอล SSL / TLS และสำหรับการลงนามออนไลน์ของข้อมูลที่ส่งไปยังไซต์ ควรใช้ CryptoTunnel ที่เวิร์กสเตชันของไคลเอ็นต์
ข้อได้เปรียบหลักของ CryptoTunnel:
- ให้การป้องกันการเชื่อมต่อเว็บระหว่างเบราว์เซอร์และเว็บไซต์โดยใช้โปรโตคอล SSL / TLS พร้อมรองรับอัลกอริทึมการเข้ารหัสลับของรัสเซีย
- อนุญาตให้คุณตรวจสอบผู้ใช้โดยใช้ใบรับรองดิจิทัลเพื่อเข้าถึงบัญชีส่วนตัวของผู้ใช้
- อนุญาตให้คุณลงนามในเอกสารออนไลน์เมื่ออัปโหลดไปยังไซต์โดยไม่ต้องใช้ CSP และ Active X
- รองรับตัวตรวจสอบสถานะใบรับรองออนไลน์ (OCSP)
- รองรับการรับประทับเวลาที่เชื่อถือได้ภายใต้ลายเซ็นดิจิทัล (TimeStamp)
- รองรับโทเค็น USB และสมาร์ทการ์ดต่างๆ สำหรับการจัดเก็บคีย์
- ไม่ต้องการการติดตั้งในตำแหน่งที่กำหนดเอง แจกจ่ายโดยการคัดลอก
- สามารถเก็บไว้ในแฟลชไดรฟ์ปกติและเรียกใช้ได้
- ไม่ต้องการสิทธิ์ผู้ดูแลระบบในการทำงาน
- รองรับการทำงานกับเว็บเบราว์เซอร์ใด ๆ (Internet Explorer, Mozilla FireFox, Google Chrome, Opera, Safari Apple เป็นต้น)
- ไม่มี "ผูกพัน" กับคอมพิวเตอร์หนึ่งเครื่อง - ผู้ใช้สามารถใช้ชุดเดียวสำหรับใช้ในสำนักงานและที่บ้าน - ประหยัดเงิน
- มีส่วนต่อประสานผู้ใช้ที่เรียบง่ายและตรงไปตรงมาซึ่งไม่จำเป็นต้องมีการฝึกอบรมผู้ใช้
- ช่วยให้คุณลดต้นทุนการสนับสนุนทางเทคนิคสำหรับผู้ใช้
- สามารถทำงานบนระบบปฏิบัติการได้หลากหลาย (โซลูชั่นข้ามแพลตฟอร์ม)
นี่คือการดำเนินการทั้งหมดที่ต้องทำเพื่อให้ CryptoTunnel เริ่มลงนามข้อมูลและไฟล์ที่ส่งผ่านแบบฟอร์มบนเว็บ ไม่จำเป็นต้องเขียนสคริปต์เพิ่มเติม เรียกใช้ Active X ฯลฯ
การจัดระเบียบลายเซ็นอิเล็กทรอนิกส์หลายรายการ
จำเป็นต้องมี ES หลายฉบับหากเอกสารต้องลงนามโดยบุคคลหลายคน ในกรณีนี้ เอกสารมักจะถูกโพสต์บนไซต์ในลักษณะที่มีให้เฉพาะผู้ใช้ที่ต้องการลายเซ็นอิเล็กทรอนิกส์เท่านั้น การแบ่งปันการเข้าถึงนี้รับรองได้โดยการตรวจสอบสิทธิ์ผู้ใช้ด้วยใบรับรองดิจิทัล
เมื่อใช้ CryptoTunnel ผู้ใช้ไม่จำเป็นต้องดาวน์โหลดเอกสาร จากนั้นลงชื่อและอัปโหลดเอกสารไปยังเซิร์ฟเวอร์อีกครั้ง - CryptoTunnel จะดำเนินการทั้งหมดเหล่านี้โดยอัตโนมัติเมื่อคลิกที่ปุ่มบนหน้าเว็บ
บริการ OCSP
มักเกิดขึ้นที่ CA เพิกถอนใบรับรองของผู้ใช้ (เช่น หากคีย์ของผู้ใช้ถูกขโมยโดยผู้บุกรุก) ในเวลาเดียวกัน ผู้ใช้รายอื่นควรได้รับแจ้งเกี่ยวกับการเพิกถอนใบรับรองนี้ เพื่อที่พวกเขาจะได้หยุดเชื่อถือ มีหลายวิธีในการแจ้งให้ผู้ใช้ทราบถึงรีวิว
ที่สุด ด้วยวิธีง่ายๆคือการแจกแจงรายการเพิกถอน (CRLs) นั่นคือ CA จะสร้างและอัปเดตไฟล์พิเศษเป็นระยะที่ผู้ใช้ดาวน์โหลดเป็นระยะด้วย
อีกวิธีหนึ่งคือการใช้บริการตรวจสอบสถานะใบรับรองออนไลน์ บริการ OCSP ในการตรวจสอบสถานะของใบรับรองใด ๆ CryptoTunnel และ CryptoServer จะสร้างคำขอ OCSP โดยอัตโนมัติ ส่งคำขอนี้ไปยังบริการผ่านเครือข่าย บริการตรวจสอบใบรับรอง ลงนามผลการตรวจสอบของ ES และส่งคืนการตอบกลับไปยังไคลเอนต์ ลูกค้าดูคำตอบ ตรวจสอบลายเซ็นด้านล่างและตัดสินใจว่าจะเชื่อถือหรือไม่ ใบรับรองนี้หรือไม่.
สามารถสร้างบริการ OCSP ได้โดยใช้ยูทิลิตี้ openssl จาก MagPro CryptoPacket โปรดทราบว่าทางเลือกระหว่าง CRL และ OCSP นั้นขึ้นอยู่กับดุลยพินิจของผู้สร้างไซต์เสมอ CRL ถูกกว่าเล็กน้อย OCSP ปลอดภัยกว่าเล็กน้อย
ควรทิ้งว่า CryptoTunnel และ CryptoServer รองรับทั้ง OCSP และ CRL
บริการประทับเวลา TSA
วัตถุประสงค์หลักของบริการประทับเวลาคือเพื่อยืนยันข้อเท็จจริงว่าเอกสารได้รับการลงนามด้วยลายเซ็นอิเล็กทรอนิกส์ไม่ช้ากว่าเวลาที่ระบุในการประทับเวลา
ในการสร้างการประทับเวลา CryptoTunnel จะสร้างคำขอ TSA ซึ่งจะแนบแฮชจากลายเซ็นดิจิทัล ส่งคำขอนี้ไปยังบริการ TSA บริการ TSA จะเพิ่มเวลาปัจจุบันให้กับแฮชนี้และลงนามในผลลัพธ์ด้วย ES ดังนั้น การประทับเวลาที่เชื่อถือได้จึงถูกสร้างขึ้น
ในการสร้างบริการออนไลน์ของการประทับเวลาที่เชื่อถือได้ คุณควรใช้ผลิตภัณฑ์ MagPro TSA ในกรณีนี้ URL ของบริการประทับเวลาจะถูกระบุโดยหน้าเว็บที่มีแบบฟอร์มลายเซ็นเว็บ
ส่วนของไคลเอ็นต์ TSA ถูกสร้างไว้ใน CryptoTunnel เมื่อได้รับการประทับเวลาบนลายเซ็นอิเล็กทรอนิกส์แล้ว การดำเนินการทั้งหมดจะดำเนินการโดยอัตโนมัติ โดยไม่เกี่ยวข้องกับผู้ใช้
อนุญาโตตุลาการ
ผู้ตัดสินเป็นโปรแกรมพิเศษที่ใช้ในการวิเคราะห์ข้อขัดแย้งด้วยลายเซ็นอิเล็กทรอนิกส์
ผู้ตัดสินอนุญาตให้คุณเห็นภาพตัวตนของใบรับรองที่อยู่ในลายเซ็น PKCS # 7 เห็นภาพห่วงโซ่ของความไว้วางใจและเวลาของการสร้างลายเซ็นอิเล็กทรอนิกส์ (TimeStamp) ในการแยกแยะความขัดแย้ง อนุญาโตตุลาการจะตรวจสอบลายเซ็นภายใต้เอกสารที่ระบุและค้นหาว่าเจ้าของใบรับรองเป็นผู้จัดทำหรือไม่
ควรสังเกตว่าสำหรับความเป็นไปได้ในการแก้ไขข้อขัดแย้ง เอกสารและลายเซ็นจะต้องเก็บไว้ในที่เก็บถาวรอิเล็กทรอนิกส์เป็นเวลานาน
การปกป้องข้อมูลส่วนบุคคลบนเว็บไซต์
ข้อมูลที่แลกเปลี่ยนระหว่างเบราว์เซอร์ของลูกค้าและไซต์อาจมีข้อมูลส่วนบุคคลและข้อมูลที่เป็นความลับ หากผู้ใช้เว็บไซต์ทุกคนสนใจที่จะปกป้องข้อมูลที่เป็นความลับ การปกป้องข้อมูลส่วนบุคคลนั้นเป็นข้อกำหนดของกฎหมายของรัฐบาลกลาง 152-FZ "เกี่ยวกับข้อมูลส่วนบุคคล"
เมื่อใช้ไซต์ ข้อมูลมีความเสี่ยงเมื่อมีการส่งผ่านอินเทอร์เน็ตและเมื่อถูกจัดเก็บบนเซิร์ฟเวอร์ของไซต์
การป้องกันการถ่ายโอนระหว่างไคลเอนต์และเซิร์ฟเวอร์
อินเทอร์เน็ตเป็นช่องทางการสื่อสารที่ไม่ปลอดภัย ภัยคุกคามหลักเมื่อส่งข้อมูลทางอินเทอร์เน็ตคือการโจมตี "คนตรงกลาง" นั่นคือผู้โจมตีเชื่อมต่อกับเส้นแบ่งระหว่างไคลเอนต์และเซิร์ฟเวอร์และแทนที่ข้อมูลที่ส่ง วิธีเดียวที่จะปกป้องข้อมูลบนอินเทอร์เน็ตคือการเข้ารหัสข้อมูลนั้น เนื่องจากการเข้ารหัสเป็นวิธีการเข้ารหัสในการปกป้องข้อมูล จึงเป็นไปตามข้อกำหนดของ FSB สำหรับวิธีการป้องกันข้อมูลด้วยการเข้ารหัส - การมีใบรับรอง FSB
SSL / TLS ใช้เพื่อรักษาความปลอดภัยในการสื่อสารระหว่างเบราว์เซอร์ของผู้ใช้กับเว็บไซต์ (การเชื่อมต่อเว็บ) CryptoTunnel ให้การปกป้องข้อมูลสำหรับโปรโตคอลนี้ซึ่งเป็นไปตามข้อกำหนดของ FSB อย่างสมบูรณ์ ดังนั้น "CryptoTunnel" จึงเป็นโซลูชันที่ผ่านการรับรองซึ่งตรงตามข้อกำหนดสำหรับวิธีการทางเทคนิคในการปกป้องข้อมูลส่วนบุคคลอย่างเต็มที่
การป้องกันการจัดเก็บ
เมื่อจัดเก็บข้อมูลในไฟล์เก็บถาวรทางอิเล็กทรอนิกส์ของไซต์ ข้อมูลเหล่านี้จะต้องจัดเก็บในรูปแบบที่เข้ารหัส การสร้างที่เก็บถาวรอิเล็กทรอนิกส์ที่ปลอดภัยเป็นหัวข้อสำหรับบทความแยกต่างหาก
แนวคิดพื้นฐาน
KSKPEP
– ใบรับรองที่ผ่านการรับรองของคีย์การตรวจสอบลายเซ็นอิเล็กทรอนิกส์
CEP- ลายเซ็นอิเล็กทรอนิกส์ที่ผ่านการรับรอง
ผู้ให้บริการ Crypto – หมายถึงการป้องกันการเข้ารหัสข้อมูลโปรแกรมที่มีส่วนปิดของลายเซ็นอิเล็กทรอนิกส์ถูกสร้างขึ้นและช่วยให้คุณสามารถทำงานกับลายเซ็นอิเล็กทรอนิกส์ ช่องทำเครื่องหมายนี้ถูกตั้งค่าโดยอัตโนมัติ
ส่งออกคีย์ – ความสามารถในการคัดลอกลายเซ็นอิเล็กทรอนิกส์ไปยังสื่ออื่น หากไม่มีเครื่องหมายถูก จะไม่สามารถคัดลอกลายเซ็นอิเล็กทรอนิกส์ได้
งานสี- ปุ่มเมาส์ซ้าย
PKM- ปุ่มเมาส์ขวา
ซีอาร์เอ็ม-ตัวแทน- แอปพลิเคชันที่พัฒนาโดยผู้เชี่ยวชาญของ CA เพื่อลดความซับซ้อนของขั้นตอนในการสร้างคู่คีย์ การสร้างคำขอ และการเขียนใบรับรอง
หลังจากเยี่ยมชมศูนย์รับรองและทำตามขั้นตอนการยืนยันตัวตนไปยังศูนย์ที่คุณระบุไว้ในใบสมัคร อีเมล, CA ได้ส่งจดหมายที่มีลิงค์เพื่อสร้าง หากคุณไม่ได้รับจดหมาย โปรดติดต่อผู้จัดการของคุณหรือฝ่ายสนับสนุนด้านเทคนิคของ TC โดยใช้หมายเลขติดต่อจากคู่มือนี้
เปิดลิงก์เพื่อสร้างจากอีเมลในหนึ่งในเบราว์เซอร์ที่แนะนำ:Google Chrome, Mozilla Firefox, Yandex Browser... หากคุณอยู่ในเบราว์เซอร์ใดเบราว์เซอร์หนึ่งข้างต้นแล้ว ให้คลิกที่ลิงก์ งานสีหรือ PKM> "เปิดลิงก์ในแท็บใหม่" หน้าการสร้าง (รูปที่ 1) จะเปิดขึ้นในหน้าต่างใหม่
เมื่อคุณเปิดลิงก์ คำเตือนเริ่มต้นจะปรากฏขึ้น ตรวจสอบว่าคุณใช้สื่อบันทึกข้อมูลเพื่อจัดเก็บ CEP . หรือไม่จาการ์ต้า LT ... เรียนรู้เพิ่มเติมเกี่ยวกับสื่อในด้านล่าง. หากคุณกำลังใช้สื่ออื่น ให้คลิกปุ่ม ปิด I.
รูปที่ 1 - หน้าการสร้าง
คลิ๊กลิงค์"ดาวน์โหลดใบสมัคร" เพื่อเริ่มดาวน์โหลด หากไม่มีอะไรเกิดขึ้นหลังจากคลิก ให้คลิกที่ลิงก์ PKM > "เปิดลิงก์ในแท็บใหม่"... หลังจากดาวน์โหลดแอปพลิเคชันแล้ว ให้เริ่มการติดตั้ง
ขอแนะนำให้ปิดการใช้งานซอฟต์แวร์ป้องกันไวรัสก่อนดาวน์โหลดโปรแกรม !
ระหว่างขั้นตอนการติดตั้ง « crm - ตัวแทน » ข้อความขอการเข้าถึงจะปรากฏขึ้น (รูปที่ 2)
รูปที่ 2 - คำขอเข้าถึง
คลิกที่ปุ่ม "ใช่".
หลังจากติดตั้งแอปพลิเคชันเสร็จแล้ว ให้กลับไปที่หน้าพร้อมกับรุ่น ข้อความเกี่ยวกับ "การให้สิทธิ์การเข้าถึง" จะปรากฏขึ้น (รูปที่ 3)
รูปที่ 3 - การเข้าถึงที่เก็บใบรับรอง
คลิกที่ "ดำเนินการ"และในหน้าต่างที่ปรากฏขึ้น "ให้สิทธิ์การเข้าถึง"(รูปที่ 4).
รูปที่ 4 - การเข้าถึงที่เก็บใบรับรอง2
หากปุ่มไม่ปรากฏขึ้น "ดำเนินการ"
หากหลังจากติดตั้งแอพพลิเคชั่น « crm - ตัวแทน » , ลิงค์ดาวน์โหลดแอปพลิเคชั่นไม่หาย สาเหตุอาจเป็นเพราะระบบรักษาความปลอดภัยของคุณบล็อกการเชื่อมต่อ
เพื่อขจัดสถานการณ์ คุณต้อง:
ปิดใช้งานโปรแกรมป้องกันไวรัสที่ติดตั้งบนคอมพิวเตอร์ของคุณ
เปิดแท็บใหม่ในเบราว์เซอร์
ป้อนที่อยู่โดยไม่ต้องเว้นวรรคในแถบที่อยู่ของเบราว์เซอร์ - 127.0.0.1:90 - และไป (กดเข้า บนแป้นพิมพ์);
เมื่อข้อความเบราว์เซอร์ปรากฏขึ้น "การเชื่อมต่อของคุณไม่ปลอดภัย"เพิ่มหน้าไปยังข้อยกเว้นของเบราว์เซอร์ ตัวอย่างเช่น,โครเมียม: "เพิ่มเติม" - "ไปที่ไซต์ต่อไป"... สำหรับเบราว์เซอร์อื่นๆ ให้ใช้คำแนะนำสำหรับนักพัฒนาที่เหมาะสม
หลังจากข้อความแสดงข้อผิดพลาดปรากฏขึ้น ให้กลับไปที่หน้าการสร้างและทำซ้ำ จุดที่ 2ของคู่มือนี้
หากคุณไม่มีผู้ให้บริการเข้ารหัสที่ติดตั้งไว้ล่วงหน้า หลังจากขั้นตอนการอนุญาต ลิงก์สำหรับดาวน์โหลด CryptoPRO จะปรากฏขึ้น (รูปที่ 5)
มันเป็นสิ่งสำคัญ: แอปพลิเคชัน « crm - ตัวแทน » ตรวจพบผู้ให้บริการเข้ารหัสใด ๆ บนคอมพิวเตอร์และหากคุณติดตั้งตัวอื่น CryptoPRO CSP โปรแกรม (เช่นVipNET CSP ) ติดต่อผู้เชี่ยวชาญ การสนับสนุนทางเทคนิคคสช.เพื่อขอคำปรึกษา
คลิ๊กลิงค์ "CryptoPRO 4.0"ในหน้าการสร้างหรือลิงก์ที่คล้ายกันด้านล่างเพื่อดาวน์โหลดไฟล์การติดตั้ง CryptoPRO ลงในคอมพิวเตอร์ของคุณ
CryptoPro CSP 4.0 - เวอร์ชันสำหรับ OS Win 7/8/10
หลังจากดาวน์โหลดเสร็จ ให้เปิดzip- เก็บถาวรโดยใช้โปรแกรมเก็บถาวรที่เหมาะสม (เช่นชนะ - RAR ). ข้างในจะมีไฟล์การติดตั้ง CryptoPRO เอง เรียกใช้และติดตั้งด้วยพารามิเตอร์เริ่มต้น ในระหว่างกระบวนการติดตั้ง หน้าต่างต่อไปนี้อาจปรากฏขึ้น:
รูปที่ 5 - การติดตั้ง CryptoPRO
ข้ามหน้าต่างโดยคลิก "ไกลออกไป"... การติดตั้ง CryptoPRO เสร็จสมบูรณ์
การติดตั้งไดรเวอร์สำหรับโทเค็น
ลายเซ็นสามารถเก็บไว้ในรีจิสทรีของคอมพิวเตอร์ในแฟลชไดรฟ์ธรรมดาและพิเศษยูเอสบี-โทเค็น รายการโทเค็น รหัสพิน และลิงก์ไปยังซอฟต์แวร์แสดงอยู่ในตารางด้านล่าง (ตารางที่ 1)
ตารางที่ 1 - ไดรเวอร์สำหรับสื่อที่ปลอดภัย
|
ประเภทสื่อ USB |
รูปร่างแท่ง USB |
ลิงค์ดาวน์โหลดไดรเวอร์ |
เข็มหมุด |
|
ruToken |
 |
