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

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

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

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

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

การป้องกันการเชื่อมต่อ

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

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

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

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

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

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

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

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

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

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

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

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

ภาคผนวกรายงานในวิดีโอ:

การบันทึกคำสั่งพื้นฐานสามารถทำได้โดยใช้ฟังก์ชันการบันทึกมาตรฐานด้วย log_statement = all

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

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

นอกจากนี้ ควรสามารถระบุข้อความยืนยันที่เจาะจงซึ่งจะเป็นประโยชน์ต่อผู้ตรวจสอบได้

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

ตัวอย่างเช่น ผู้ตรวจสอบอาจต้องการตรวจสอบว่ามีการสร้างตารางเฉพาะภายในหน้าต่างการบำรุงรักษาที่มีการบันทึกไว้หรือไม่

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

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

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

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

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

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

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

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

การตรวจสอบ: เซสชัน, 33, 1, ฟังก์ชัน, ทำ,, "ทำ $$
เริ่ม
ดำเนินการ 'สร้างตารางนำเข้า' || 'ant_table(id int)';
จบ $$;"
การตรวจสอบ: เซสชัน, 33, 2, DDL, สร้างตาราง, ตาราง, ตารางสาธารณะ, สร้างตาราง important_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_rewritten = เปิด
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 เราจะทำการทดสอบโหลด 3 ครั้งโดยใช้คำสั่ง:

$ 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

ขนาดของบันทึก DB
0 MB
4587 MB

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

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

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

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

ในองค์กร การตรวจสอบบัญชีมีความซับซ้อนมากยิ่งขึ้น:

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

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

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

สิ่งที่สามารถนำมาใช้โดยทั่วไป:

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

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

  id | ข้อความ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

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

  id | ถอดรหัส | ถอดรหัส
-
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%

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

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

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

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

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

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

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

เอ็มเอสคิวแอล
เชิงพาณิชย์
+
+
+
+
+

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

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

มอนโกดีบี
ฟรี
-
+
-
-
มีเฉพาะใน 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