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

บทความนี้จัดทำขึ้นจากสุนทรพจน์ที่ @ฐานข้อมูลมีตอัพ, เป็นระเบียบ Mail.ru โซลูชั่นคลาวด์. ไม่อยากอ่านก็รับชมได้:

บทความนี้จะมีสามส่วน:

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

องค์ประกอบสามประการของการรักษาความปลอดภัย DBMS: การป้องกันการเชื่อมต่อ การตรวจสอบกิจกรรม และการปกป้องข้อมูล

การรักษาความปลอดภัยการเชื่อมต่อของคุณ

คุณสามารถเชื่อมต่อกับฐานข้อมูลทั้งทางตรงและทางอ้อมผ่านเว็บแอปพลิเคชัน ตามกฎแล้ว ผู้ใช้ทางธุรกิจซึ่งก็คือบุคคลที่ทำงานกับ DBMS จะโต้ตอบกับมันทางอ้อม

ก่อนที่จะพูดถึงการปกป้องการเชื่อมต่อ คุณต้องตอบคำถามสำคัญที่กำหนดว่ามาตรการรักษาความปลอดภัยจะมีโครงสร้างอย่างไร:

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

ตอนนี้เรามาดูกันว่าเครื่องมือใดบ้างที่สามารถใช้สำหรับการเชื่อมต่อที่ปลอดภัย:

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

   คุณสามารถอ่านเพิ่มเติมเกี่ยวกับฟังก์ชันการให้คะแนนผู้ใช้ได้ ที่นี่คุณยังสามารถค้นหาข้อมูลเกี่ยวกับ MS SQL Vulnerability Assessmen ได้ ที่นี่. 

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

สิ่งนี้จะส่งผลต่อประสิทธิภาพของ DBMS อย่างไร?

เรามาดูตัวอย่างของ PostgreSQL เพื่อดูว่า SSL ส่งผลต่อโหลด CPU อย่างไร เพิ่มการกำหนดเวลาและลด TPS และจะใช้ทรัพยากรมากเกินไปหรือไม่หากคุณเปิดใช้งาน

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

ทดสอบ 1 โดยไม่มี SSL และใช้ SSL — การเชื่อมต่อถูกสร้างขึ้นสำหรับแต่ละธุรกรรม:

pgbench.exe --connect -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres sslmode=require 
sslrootcert=rootCA.crt sslcert=client.crt sslkey=client.key"

vs

pgbench.exe --connect -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres"

ทดสอบ 2 โดยไม่มี SSL และใช้ SSL — ธุรกรรมทั้งหมดดำเนินการในการเชื่อมต่อเดียว:

pgbench.exe -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres sslmode=require
sslrootcert=rootCA.crt sslcert=client.crt sslkey=client.key"

vs

pgbench.exe -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres"

การตั้งค่าอื่นๆ:

scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
number of transactions per client: 5000
number of transactions actually processed: 50000/50000

ผลการทดสอบ:

 
ไม่มี SSL
SSL

มีการสร้างการเชื่อมต่อสำหรับทุกธุรกรรม

ค่าเฉลี่ยเวลาแฝง
ms 171.915
ms 187.695

tps รวมถึงการสร้างการเชื่อมต่อ
58.168112
53.278062

tps ไม่รวมการสร้างการเชื่อมต่อ
64.084546
58.725846

ซีพียู
ลด 24%
ลด 28%

ธุรกรรมทั้งหมดดำเนินการในการเชื่อมต่อเดียว

ค่าเฉลี่ยเวลาแฝง
ms 6.722
ms 6.342

tps รวมถึงการสร้างการเชื่อมต่อ
1587.657278
1576.792883

tps ไม่รวมการสร้างการเชื่อมต่อ
1588.380574
1577.694766

ซีพียู
ลด 17%
ลด 21%

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

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

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

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

การตรวจสอบการดำเนินการ

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

ใน DBMS ระดับองค์กรเชิงพาณิชย์ ทุกอย่างใช้ได้ดีกับการตรวจสอบ แต่ในโอเพ่นซอร์ส - ไม่เสมอไป นี่คือสิ่งที่ PostgreSQL มี:

• บันทึกเริ่มต้น - การบันทึกในตัว
• ส่วนขยาย: pgaudit - หากการบันทึกเริ่มต้นไม่เพียงพอสำหรับคุณ คุณสามารถใช้การตั้งค่าแยกต่างหากเพื่อแก้ไขปัญหาบางอย่างได้

นอกเหนือจากรายงานในวิดีโอ:

"การบันทึกคำสั่งพื้นฐานสามารถจัดเตรียมได้โดยเครื่องมืออำนวยความสะดวกการบันทึกมาตรฐานที่มี log_statement = all

ซึ่งเป็นที่ยอมรับสำหรับการตรวจสอบและการใช้งานอื่นๆ แต่ไม่ได้ให้ระดับรายละเอียดที่จำเป็นสำหรับการตรวจสอบโดยทั่วไป

การมีรายการการดำเนินการทั้งหมดที่ดำเนินการบนฐานข้อมูลนั้นไม่เพียงพอ

นอกจากนี้ยังควรสามารถค้นหาข้อความเฉพาะที่เป็นที่สนใจของผู้สอบบัญชีได้

การบันทึกมาตรฐานจะแสดงสิ่งที่ผู้ใช้ร้องขอ ในขณะที่ pgAudit มุ่งเน้นไปที่รายละเอียดของสิ่งที่เกิดขึ้นเมื่อฐานข้อมูลดำเนินการค้นหา

ตัวอย่างเช่น ผู้ตรวจสอบบัญชีอาจต้องการตรวจสอบว่าตารางใดถูกสร้างขึ้นภายในหน้าต่างการบำรุงรักษาที่มีการจัดทำเอกสารไว้

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

ทำ$$
เริ่ม
ดำเนินการ 'สร้างการนำเข้าตาราง' || 'ant_table(id int)';
สิ้นสุด$$;

การบันทึกแบบมาตรฐานจะให้สิ่งนี้แก่คุณ:

บันทึก: คำสั่ง: DO $$
เริ่ม
ดำเนินการ 'สร้างการนำเข้าตาราง' || 'ant_table(id int)';
สิ้นสุด$$;

ดูเหมือนว่าการค้นหาตารางที่สนใจอาจต้องใช้ความรู้ด้านโค้ดในกรณีที่ตารางถูกสร้างขึ้นแบบไดนามิก

สิ่งนี้ไม่เหมาะ เนื่องจากควรค้นหาโดยใช้ชื่อตารางเพียงอย่างเดียว

นี่คือจุดที่ pgAudit มีประโยชน์

สำหรับอินพุตเดียวกัน ระบบจะสร้างเอาต์พุตนี้ในบันทึก:

ตรวจสอบ: เซสชั่น, 33,1, ฟังก์ชั่น, ทำ ,,, "ทำ $$
เริ่ม
ดำเนินการ 'สร้างการนำเข้าตาราง' || 'ant_table(id int)';
จบ$$;"
ตรวจสอบ: เซสชัน, 33,2, DDL, สร้างตาราง, ตาราง, public.important_table, สร้างตาราง vital_table (id INT)

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

เมื่อบันทึกคำสั่ง SELECT และ DML คุณสามารถกำหนดค่า pgAudit เพื่อบันทึกรายการแยกต่างหากสำหรับแต่ละความสัมพันธ์ที่อ้างอิงในคำสั่ง

ไม่จำเป็นต้องแยกวิเคราะห์เพื่อค้นหาข้อความทั้งหมดที่แตะตารางใดตารางหนึ่ง (*) ».

สิ่งนี้จะส่งผลต่อประสิทธิภาพของ DBMS อย่างไร?

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

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

postgresql.conf

log_destination = 'stderr'
logging_collector = เปิด
log_truncate_on_rotation = เปิด
log_rotation_age = 1 วัน
log_rotation_size = 10MB
log_min_messages= ดีบัก 5
log_min_error_statement = ดีบัก 5
log_min_duration_statement = 0
debug_print_parse = เปิด
debug_print_rewrite = เปิด
debug_print_plan = เปิด
debug_pretty_print = เปิด
log_checkpoints = เปิด
log_connections = เปิด
log_disconnections = เปิด
log_duration = เปิด
log_hostname = เปิด
log_lock_waits = เปิด
log_replication_commands = เปิด
log_temp_files = 0
log_timezone = 'ยุโรป/มอสโก'

บน PostgreSQL DBMS ที่มีพารามิเตอร์ 1 CPU, 2,8 GHz, RAM 2 GB, HDD 40 GB เราทำการทดสอบโหลดสามครั้งโดยใช้คำสั่ง:

$ pgbench -p 3389 -U postgres -i -s 150 benchmark
$ pgbench -p 3389 -U postgres -c 50 -j 2 -P 60 -T 600 benchmark
$ pgbench -p 3389 -U postgres -c 150 -j 2 -P 60 -T 600 benchmark

ผลการทดสอบ:

ไม่มีการบันทึก
ด้วยการเข้าสู่ระบบ

ระยะเวลาในการกรอกฐานข้อมูลทั้งหมด
43,74 วินาที
53,23 วินาที

แรม
ลด 24%
ลด 40%

ซีพียู
ลด 72%
ลด 91%

ทดสอบ 1 (การเชื่อมต่อ 50 ครั้ง)

จำนวนธุรกรรมใน 10 นาที
74169
32445

ธุรกรรม/วินาที
123
54

เวลาแฝงเฉลี่ย
405 ms
925 ms

ทดสอบ 2 (การเชื่อมต่อ 150 รายการและเป็นไปได้ 100 รายการ)

จำนวนธุรกรรมใน 10 นาที
81727
31429

ธุรกรรม/วินาที
136
52

เวลาแฝงเฉลี่ย
550 ms
1432 ms

เกี่ยวกับขนาด

ขนาดฐานข้อมูล
2251 MB
2262 MB

ขนาดบันทึกฐานข้อมูล
0 MB
4587 MB

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

ลองดูพารามิเตอร์อื่น ๆ :

• ความเร็วไม่เปลี่ยนแปลงมากนัก: หากไม่มีการบันทึก - 43,74 วินาทีโดยมีการบันทึก - 53,23 วินาที
• ประสิทธิภาพของ RAM และ CPU จะลดลง เนื่องจากคุณจำเป็นต้องสร้างไฟล์ตรวจสอบ สิ่งนี้สามารถสังเกตได้ชัดเจนในด้านประสิทธิภาพการทำงาน

เมื่อจำนวนการเชื่อมต่อเพิ่มขึ้น ประสิทธิภาพจะลดลงเล็กน้อยตามธรรมชาติ

ในองค์กรที่มีการตรวจสอบจะยิ่งยากยิ่งขึ้น:

• มีข้อมูลมากมาย
• จำเป็นต้องมีการตรวจสอบไม่เพียง แต่ผ่าน syslog ใน SIEM เท่านั้น แต่ยังรวมถึงในไฟล์ด้วย: หากเกิดอะไรขึ้นกับ syslog จะต้องมีไฟล์ใกล้กับฐานข้อมูลที่บันทึกข้อมูล
• จำเป็นต้องมีชั้นวางแยกต่างหากสำหรับการตรวจสอบเพื่อไม่ให้ดิสก์ I/O เสียเปล่า เนื่องจากใช้พื้นที่มาก
• มันเกิดขึ้นที่พนักงานรักษาความปลอดภัยข้อมูลต้องการมาตรฐาน GOST ทุกที่และต้องมีการระบุตัวตนของรัฐ

การจำกัดการเข้าถึงข้อมูล

มาดูเทคโนโลยีที่ใช้เพื่อปกป้องข้อมูลและเข้าถึงข้อมูลใน DBMS เชิงพาณิชย์และโอเพ่นซอร์สกัน

โดยทั่วไปคุณสามารถใช้อะไรได้บ้าง:

1. การเข้ารหัสและทำให้สับสนของขั้นตอนและฟังก์ชัน (Wrapping) - นั่นคือแยกเครื่องมือและยูทิลิตี้ที่ทำให้โค้ดที่อ่านไม่สามารถอ่านได้ จริงอยู่ที่ว่าไม่สามารถเปลี่ยนแปลงหรือปรับโครงสร้างกลับได้ บางครั้งจำเป็นต้องใช้วิธีนี้อย่างน้อยก็ในด้าน DBMS - ตรรกะของข้อจำกัดสิทธิ์การใช้งานหรือตรรกะการอนุญาตได้รับการเข้ารหัสอย่างแม่นยำที่ขั้นตอนและระดับฟังก์ชัน
2. การจำกัดการมองเห็นข้อมูลตามแถว (RLS) เกิดขึ้นเมื่อผู้ใช้ที่แตกต่างกันเห็นตารางเดียว แต่มีองค์ประกอบของแถวที่แตกต่างกันในนั้น กล่าวคือ บางอย่างไม่สามารถแสดงให้ใครก็ตามในระดับแถวเห็นได้
3. การแก้ไขข้อมูลที่แสดง (มาสก์) คือเมื่อผู้ใช้ในคอลัมน์หนึ่งของตารางเห็นข้อมูลหรือเครื่องหมายดอกจันเท่านั้น นั่นคือ ข้อมูลจะถูกปิดสำหรับผู้ใช้บางราย เทคโนโลยีจะกำหนดว่าผู้ใช้รายใดจะถูกแสดงสิ่งใดตามระดับการเข้าถึงของพวกเขา
4. ความปลอดภัย การควบคุมการเข้าถึง DBA/Application DBA/DBA เป็นการจำกัดการเข้าถึง DBMS เอง กล่าวคือ พนักงานรักษาความปลอดภัยข้อมูลสามารถแยกออกจากผู้ดูแลระบบฐานข้อมูลและผู้ดูแลระบบแอปพลิเคชันได้ มีเทคโนโลยีดังกล่าวไม่กี่อย่างในโอเพ่นซอร์ส แต่มีมากมายใน DBMS เชิงพาณิชย์ จำเป็นเมื่อมีผู้ใช้จำนวนมากที่สามารถเข้าถึงเซิร์ฟเวอร์ได้
5. การจำกัดการเข้าถึงไฟล์ในระดับระบบไฟล์ คุณสามารถให้สิทธิ์และสิทธิพิเศษในการเข้าถึงไดเร็กทอรีเพื่อให้ผู้ดูแลระบบแต่ละคนสามารถเข้าถึงข้อมูลที่จำเป็นเท่านั้น
6. การเข้าถึงที่จำเป็นและการล้างหน่วยความจำ - เทคโนโลยีเหล่านี้ไม่ค่อยได้ใช้
7. การเข้ารหัสจากต้นทางถึงปลายทางโดยตรงจาก DBMS คือการเข้ารหัสฝั่งไคลเอ็นต์พร้อมการจัดการคีย์บนฝั่งเซิร์ฟเวอร์
8. การเข้ารหัสข้อมูล ตัวอย่างเช่น การเข้ารหัสแบบเรียงเป็นแนวคือเมื่อคุณใช้กลไกที่เข้ารหัสคอลัมน์เดียวของฐานข้อมูล

สิ่งนี้ส่งผลต่อประสิทธิภาพของ DBMS อย่างไร

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

มาทดสอบกับ pgcrypto กัน. มาสร้างตารางที่มีข้อมูลที่เข้ารหัสและข้อมูลปกติกันดีกว่า ด้านล่างนี้เป็นคำสั่งสำหรับการสร้างตารางในบรรทัดแรกมีคำสั่งที่มีประโยชน์ - การสร้างส่วนขยายด้วยการลงทะเบียน DBMS:

CREATE EXTENSION pgcrypto;
CREATE TABLE t1 (id integer, text1 text, text2 text);
CREATE TABLE t2 (id integer, text1 bytea, text2 bytea);
INSERT INTO t1 (id, text1, text2)
VALUES (generate_series(1,10000000), generate_series(1,10000000)::text, generate_series(1,10000000)::text);
INSERT INTO t2 (id, text1, text2) VALUES (
generate_series(1,10000000),
encrypt(cast(generate_series(1,10000000) AS text)::bytea, 'key'::bytea, 'bf'),
encrypt(cast(generate_series(1,10000000) AS text)::bytea, 'key'::bytea, 'bf'));

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

การเลือกจากตารางที่ไม่มีฟังก์ชันการเข้ารหัส:

psql -c "timing" -c "select * from t1 limit 1000;" "host=192.168.220.129 dbname=taskdb
user=postgres sslmode=disable" > 1.txt

นาฬิกาจับเวลาเปิดอยู่

  รหัส | ข้อความ1 | ข้อความ2
——+——-+——-
1 | 1 | 1
2 | 2 | 2
3 | 3 | 3
...
997 | 997 | 997
998 | 998 | 998
999 | 999 | 999
1000 | 1000 | 1000
(1000 เส้น)

เวลา: 1,386 มิลลิวินาที

การเลือกจากตารางที่มีฟังก์ชันการเข้ารหัส:

psql -c "timing" -c "select id, decrypt(text1, 'key'::bytea, 'bf'),
decrypt(text2, 'key'::bytea, 'bf') from t2 limit 1000;"
"host=192.168.220.129 dbname=taskdb user=postgres sslmode=disable" > 2.txt

นาฬิกาจับเวลาเปิดอยู่

  รหัส | ถอดรหัส | ถอดรหัส
——+—————+————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
...
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000 เส้น)

เวลา: 50,203 มิลลิวินาที

ผลการทดสอบ:

 
โดยไม่ต้องเข้ารหัส
Pgcrypto (ถอดรหัส)

ตัวอย่าง 1000 แถว
1,386 ms
50,203 ms

ซีพียู
ลด 15%
ลด 35%

แรม
 
+ 5%

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

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

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

ตัวอย่างการเข้ารหัสดังกล่าวใน MongoDB

คุณลักษณะด้านความปลอดภัยใน DBMS เชิงพาณิชย์และโอเพ่นซอร์ส

ฟังก์ชั่น
ชนิด
นโยบายรหัสผ่าน
กรรมการตรวจสอบ
การปกป้องซอร์สโค้ดของขั้นตอนและฟังก์ชัน
RLS
การเข้ารหัสลับ

คำพยากรณ์
เชิงพาณิชย์
+
+
+
+
+

MsSql
เชิงพาณิชย์
+
+
+
+
+

ชาโตบา
เชิงพาณิชย์
+
+
+
+
ส่วนขยาย

PostgreSQL
ฟรี
ส่วนขยาย
ส่วนขยาย
-
+
ส่วนขยาย

MongoDb
ฟรี
-
+
-
-
มีเฉพาะใน MongoDB Enterprise เท่านั้น

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

จะทำอย่างไรถ้าคุณไม่มีสิ่งที่ต้องการทุกที่? ตัวอย่างเช่น คุณต้องการใช้ DBMS เฉพาะที่ไม่มีฟังก์ชันที่ลูกค้าต้องการ

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

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

รายงานนี้ถูกนำเสนอครั้งแรกที่ @การพบปะฐานข้อมูล โดย Mail.ru Cloud Solutions ดู วีดีโอ การแสดงอื่น ๆ และสมัครรับประกาศกิจกรรมบน Telegram เกี่ยวกับ Kubernetes ที่ Mail.ru Group.

มีอะไรอีกให้อ่านในหัวข้อ:

1. มากกว่า Ceph: พื้นที่เก็บข้อมูลบล็อกคลาวด์ MCS.
2. วิธีเลือกฐานข้อมูลสำหรับโครงการเพื่อให้คุณไม่ต้องเลือกอีก.

ที่มา: will.com