Database Security
Database Security
ในทุกวันนี้ถ้าหากมีการพูดถึงเรื่อง IT Security ขึ้นมาแล้ว เชื่อว่าทุกคนมักจะนึกถึงเรื่องของ Firewall หรือ ไม่ Anti-Virus ซะเป็นส่วนใหญ่ โดยที่มักจะหลงลืม ไปว่ายังมี Security ในส่วนของ Database อยู่อีกด้วย
ลองพิสูจน์ได้โดยให้ลองนึกชื่อของ Product Vendor ที่ขายสินค้าทางด้าน IT Security ขึ้นมา โดยมากแล้วชื่ออื่นที่จะผุดขึ้นมากก็มักจะเป็นลักษณะประเภท Firewall หรือ Anti-Virus กันแทบจะทั้งนั้น โดยที่แทบจะไม่มีประเภท Database Security ขึ้นมาเลย
ทั้งๆ ที่เป้าหมายสุดท้ายส่วนใหญ่ของการบุกรุกก็มักจะเป็นตัว Database นั่นเอง ไม่ว่ารูปแบบของการบุกรุกจะเป็นการขโมยข้อมูล เช่น หมายเลขบัตรเครดิต ข้อมูลทางด้านการเงิน ไปจนถึง ทรัพย์สินทางปัญญาและอื่นๆ
บางครั้งที่ไม่ได้เป็นการเข้ามาขโมยข้อมูล แต่ก็จะเป็นการเข้ามาแก้ไขข้อมูลเลย ซึ่งโดยมากก็มักจะเป็นข้อมูลทางด้านการเงินหรือทรัพย์สินที่มีมูลค่าที่อยู่ในรูปแบบของ Digital ต่างๆ เช่น บัตรเติมเงิน, Debit Card
ลองมาคิดดูเล่นๆ กันว่าถ้าหากองค์กรของเราตกอยู่ในสถานการณ์ดังต่อไปนี้ แล้วระบบ IT Security ของเรามีกลไกครบถ้วนมากพอที่จะรับมือกับสิ่งที่เกิดขึ้นนี้ได้อย่างมีประสิทธิภาพเพียงพอหรือไม่
- ถ้าหาก ผู้บุกรุกสามารถผ่านด่านของ Network Security เข้ามาได้ ทำให้สามารถเข้าถึง Database ได้โดยตรง โดยที่ Database เองไม่ได้มีกลไกต่างหากในการป้องกันตัวเองเลย
- ถ้าหาก ผู้บุกรุกอยู่ในฐานะที่จะเข้ามา Access Network ภายในขององค์กรได้ในระดับเดียวกับที่พนักงานใช้อยู่ เช่น เป็นพนักงานของ Vendor, Outsource, Partner หรือแม้กระทั่งตัวพนักงานเอง ทำผู้บุกรุกสามารถทะลุเข้าไปถึงตัว Database ได้โดยอาศัยสิทธิจากหน้าที่งานที่ทำอยู่ โดยไม่ต้องใช้เทคนิคหรือความสามารถพิเศษใดๆ เลย
- ถ้าหาก Database Admins (DBAs) ซึ่งมีสิทธิที่จะทำ อะไรก็ได้ทุกอย่างในระบบ Database แล้วถ้าหาก DBA นี้เกิดทำ Password รั่วไหลไปสู่บุคคลอื่นไม่ว่าจะโดยเจตนาหรือไม่เจตนา หรือแม้กระทั่งตัว DBA เกิดทุจริตซะเอง
- ถ้าหาก ข้อมูล Database ซึ่งมักจะมีการทำ Backup เก็บลง Tape ไว้ เกิดถูกขโมยแล้วนำไป Restore ข้อมูลออกมาก็จะเท่ากับว่าผู้บุกรุกได้ข้อมูลไปทั้งหมดโดยไม่ต้องผ่านด่านของ IT Security ใดๆ เลย
- ถ้าหาก ระบบ Database ที่มักจะมีระบบ DR คู่ขนานไปด้วยซึ่งระบบ DR นี้ ในบางครั้งจะมีระดับของการป้องกันการบุกรุกที่ต่ำกว่าระบบ Production ดังนั้นผู้ที่จะบุกรุกเข้าไปที่ระบบ DR แทนที่จะไปที่ระบบ Production
- ถ้าหาก งาน Develop/Test Application ที่มีการเรียกใช้ข้อมูลส่วนที่เป็น Sensitive Information ซึ่งไม่ต้องการให้ Developer/Tester มองเห็นข้อมูลนี้ แต่ถ้าไม่ให้ข้อมูลไปก็จะไม่สามารถ Develop/Test Application ได้ลุล่วงตามที่ต้องการ
- ถ้าหาก Application บางตัวจำเป็นต้องเข้าถึงข้อมูลบางอย่างที่ไม่ได้ต้องการให้เห็น เช่น ระบบพิมพ์ใบเรียกเก็บเงินบัตรเครดิต ที่ต้องการให้ Application เห็นหมายเลขบัตรเครดิตเพียงแค่บางส่วน เช่น 1234-xxxx-xxxx-xx56 แต่ในขณะเดียวกันก็ต้องการให้ Application ตัวอื่นยังคงสามารถเข้าถึงหมายเลขบัตรเครดิตนี้ได้แบบครบถ้วน
จะเห็นได้ว่าข้อมูลทุกอย่างขององค์กรซึ่งนั่นก็จะรวมถึงข้อมูลสำคัญประเภทที่ว่าสามารถทำ ให้องค์กรสั่นคลอนได้ถ้าหากเกิดปัญหาขึ้นกับข้อมูลเหล่านี้ไม่ว่าจะเป็น ข้อมูลหาย ถูกแก้ไข ถูกขโมย ซึ่งผลเสียก็จะมีทั้งที่เป็นทางตรงที่คิดเป็นมูลค่าได้แล้วยังมีที่เป็นผลเสียแบบประเมินค่าไม่ได้
ซึ่งก็คือชื่อเสียงขององค์กร ที่อาจจะเป็นเรื่องใหญ่กว่าความเสียหายทางตัวเงินด้วยซ้ำ โดยเฉพาะอย่างยิ่งสำหรับองค์กรที่มีธุรกิจที่ต้องขายความน่าเชื่อถือ เช่น ธนาคาร ประกัน โรงพยาบาลหรือหน่วยงานราชการบางประเภท ซึ่งปัญหาทั้งหมดนี้สามารถที่จะเกิดขึ้นได้จากการกระทำของบุคคลเพียงบุคคลเดียว ไม่ว่าจะเป็นการกระทำที่ตั้งใจหรือไม่ตั้งใจ
จากสถานการณ์ที่ยกมาทั้งหมดนี้ หากพบว่าองค์กรของเรายังไม่มีเครื่องมือหรือวิธีการที่จะจัดการสถานการณ์เหล่านี้ได้อย่างเหมาะสม ในส่วนของ Oracle จะมี Solutions ที่จะช่วยเหลือได้
โดย Oracle Database Security Solution นี้จะช่วยในการป้องกันระบบ Database โดยแบ่งออกตามลักษณะการทำงานเป็นกลุ่มต่างๆ ได้ดังต่อไปนี้
Protecting Against Database Bypass
เป้าหมายการทำงานของ Solutions ในกลุ่มนี้คือเพื่อป้องกันการเข้าถึง Sensitive Information ที่มาในรูปแบบการ Access ไปที่ File ตรงๆ โดยไม่ผ่านระบบ Database เช่น ตามภาพด้านล่างจะแสดงให้เห็นวิธีการดึงข้อมูลหมายเลขบัตรเครดิตออกมาโดยใช้คำสั่งของ OS เพียงคำสั่งเดียวเท่านั้น
ซึ่งแน่นอนว่าไม่ต้องผ่านด่านระบบป้องกันต่างๆ ของ Database เลย (ขออนุญาตไม่แสดงตัวอย่างคำสั่งนะครับ เนื่องจากกลัวว่าจะกลายเป็นการชี้ช่องไป)
รวมไปถึงการป้องกันไม่ให้มีการนำ Backup Tape ไปทำการ Restore ข้อมูลและเข้าถึงข้อมูลต่างๆ ได้
โดยความสามารถนี้ของ Oracle จะมีชื่อว่า Transparent Data Encryption (TDE) ซึ่งจะมีหลักการคือจะทำการ Encrypt Database โดยสามารถทำได้ทั้งในระดับของ Columns และทั้ง Application Tablespaces โดยที่ในส่วนของ Application นั้นจะไม่ต้องมีการเปลี่ยนแปลงอะไรเลย
Protecting Against Application Bypass
เป้าหมายการทำงานของ Solutions ในกลุ่มนี้คือเพื่อป้องกันการเข้าถึง Sensitive Information ที่เข้ามาโดยไม่ผ่าน Applicationที่มีสิทธิในการเข้าถึงอย่างถูกต้อง เช่น DBA ที่สามารถเข้าถึงข้อมูลโดยตรงได้ทุกอย่าง
ซึ่งนี่ก็จะเป็นความเสี่ยงขององค์กรที่เอา Sensitive Information รวมไปถึงความมั่นคงปลอดภัยของธุรกิจมาขึ้นอยู่กับ DBA เพียงคนเดียว
โดย Oracle จะมี Solutions ที่ทำงานป้องกันในลักษณะนี้อยู่คือ Oracle Database Vault มีหลักการการทำงานคือแบ่งสิทธิการทำงานต่างๆ จากกันรวมถึงออกจาก DBA ด้วยเช่นกัน ซึ่งจะมีผลทำให้ DBA จะมีหน้าที่ในการดูแล Database Engine เท่านั้น
โดยที่ไม่สามารถเข้าถึงข้อมูลโดยตรงได้อีก โดยในส่วนของข้อมูลก็จะมีการแบ่งสิทธิให้กับ User ต่างๆ ตามหน้าที่รับผิดชอบและตาม Application เท่านั้น รวมไปถึงยังสามารถตั้งเงื่อนไขเพิ่มเติมสำหรับการเข้าถึงข้อมูลได้อีกด้วย เช่น ช่วงเวลาที่สามารถเข้าไปใช้ข้อมูลได้
Oracle Database Firewall มีหลักการการทำงานคล้ายกับ Network Firewall แต่จะต่างกันตรงที่ Network Firewall จะป้องกันระบบโดยวิเคราะห์จาก IP, Service Port
แต่ Database Firewall จะวิเคราะห์จาก SQL Transaction โดยจะคอยตรวจจับและป้องกันไม่ให้ Unauthorized Database Activities ตามที่ได้กำหนดไว้ใน Policy เข้ามาถึงระบบ Database ได้ ซึ่งรวมไปถึงสามารถป้องกันการโจมตีในลักษณะของ SQL Injection ได้ด้วยเช่นกัน
Protecting Against Sensitive Data Exposure
เป้าหมายการทำงานของ Solutions ในกลุ่มนี้คือเพื่อปกปิดข้อมูลบางส่วนหรือทั้งหมด ไม่ให้ผู้ใช้งานหรือ Application ได้เห็นข้อมูลที่แท้จริง แต่โครงสร้างรูปแบบของข้อมูลจะยังคงเดิมและสามารถนำไปใช้กับงานบางอย่างได้
โดย Oracle จะมี Solutions ที่ทำงานในลักษณะนี้อยู่คือ Oracle Data Masking มีลักษณะการทำงานคือทำให้ข้อมูลใน Database มีค่าเปลี่ยนแปลงไปโดยที่ยังคงมีโครงสร้างเหมือนเดิม เช่น เปลี่ยนชื่อ เปลี่ยนหมายเลขบัตรเครดิต เป็นชื่อ/หมายเลขอื่นๆ ที่ไม่ใช่ค่าจริงแต่โครงสร้างยังถูกต้องมากพอที่จะใช้ในการทดสอบหรือพัฒนาระบบงานได้โดยที่เราสามารถกำหนดวิธีการที่จะเปลี่ยนแปลงข้อมูลเหล่านี้ได้ด้วย
ซึ่งจะส่งผลให้ Application Development/Test ยังคงเดินหน้าได้ต่อไปโดยที่ไม่มีปัญหาเรื่อง Sensitive Information รั่วไหลออกไป ไม่ว่า Developer/Tester นั้นจะเป็นคนภายในหรือภายนอกองค์กร
จากที่ได้กล่าวมาทั้งหมด เชื่อว่าจะเป็นข้อมูลเพิ่มเติมสำหรับองค์กรต่างๆ เพื่อใช้พิจารณาถึงความจำเป็นสำหรับการที่จะเพิ่ม Security ให้กับระบบ Database ขององค์กร
โดยเฉพาะอย่างยิ่งในส่วนของ Database ที่เก็บ Sensitive Information ต่างๆ ไม่ว่าจะเป็น ข้อมูลหมายเลขบตั รเครดิตลกู ค้า ข้อมูลของเงินเดือนพนักงาน ข้อมูลหมายเลขที่มีลักษณะเป็น Digital Money เช่น บัตรเติมเงินต่างๆ ข้อมูลทางการเงินขององค์กร และอื่นๆ เพื่อให้การดำเนินงานขององค์กรเป็นไปอย่างราบรื่น ปลอดภัยและน่าเชื่อถือ
