SQL Server 2016 เข้ารหัสเสมอ: ใช้งานง่าย ทนทานต่อการถอดรหัส

เผยแพร่แล้ว: 2022-03-11

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

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

ภาพหน้าปกการเข้ารหัส SQL Server

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

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

แนวคิดเบื้องหลังการเข้ารหัสเสมอ

Always Encrypted เป็นเทคโนโลยีการเข้ารหัสฝั่งไคลเอ็นต์ที่ Microsoft นำมาใช้กับ SQL Server 2016 Always Encrypted ช่วยให้ข้อมูลมีการเข้ารหัสโดยอัตโนมัติ ไม่เพียงแต่เมื่อเขียนเท่านั้น แต่ยังอ่านเมื่อแอปพลิเคชันที่ได้รับอนุมัติอ่านอีกด้วย ต่างจาก Transparent Data Encryption ซึ่งเข้ารหัสข้อมูลและล็อกไฟล์บนดิสก์ตามเวลาจริง แต่อนุญาตให้อ่านข้อมูลโดยแอพพลิเคชั่นใดๆ ที่สืบค้นข้อมูล Always Encrypted กำหนดให้แอปพลิเคชันไคลเอนต์ของคุณใช้ไดรเวอร์ที่เปิดใช้งาน Always Encrypted เพื่อสื่อสารกับ ฐานข้อมูล เมื่อใช้ไดรเวอร์นี้ แอปพลิเคชันจะถ่ายโอนข้อมูลที่เข้ารหัสอย่างปลอดภัยไปยังฐานข้อมูล ซึ่งสามารถถอดรหัสได้ในภายหลังโดยแอปพลิเคชันที่มีสิทธิ์เข้าถึงคีย์การเข้ารหัสเท่านั้น แอปพลิเคชันอื่นๆ ที่สอบถามข้อมูลสามารถดึงค่าที่เข้ารหัสไว้ได้ แต่แอปพลิเคชันนั้นไม่สามารถใช้ข้อมูลได้หากไม่มีคีย์เข้ารหัส ซึ่งจะทำให้ข้อมูลไม่มีประโยชน์ เนื่องจากสถาปัตยกรรมการเข้ารหัสนี้ อินสแตนซ์ของ SQL Server จะไม่เห็นข้อมูลเวอร์ชันที่ไม่ได้เข้ารหัส

ในขณะนี้ โปรแกรมควบคุมที่เปิดใช้งานการเข้ารหัสเสมอเท่านั้นคือ .NET Framework Data Provider สำหรับ SQL Server ซึ่งต้องมีการติดตั้ง .NET Framework เวอร์ชัน 4.6 บนคอมพิวเตอร์ไคลเอนต์และไดรเวอร์ JDBC 6.0 ซึ่งอาจเปลี่ยนแปลงได้ทันเวลา แต่นี่เป็นข้อกำหนดอย่างเป็นทางการของ Always Encrypted ในเดือนเมษายน 2017

แต่ทำไมเราถึงต้องการเทคโนโลยีนี้? มีเหตุผลที่ดีสองสามประการว่าทำไมควรใช้ Always Encrypted:

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

วิธีใช้การเข้ารหัสเสมอ

การใช้ Always Encrypted ต้องมีการเตรียมการเพียงเล็กน้อยภายในเซิร์ฟเวอร์ฐานข้อมูลที่จัดเก็บตารางที่เข้ารหัสไว้ การเตรียมการเป็นกระบวนการสองขั้นตอน:

  • สร้างคำนิยามคีย์หลักของคอลัมน์
  • สร้างคีย์การเข้ารหัสคอลัมน์

คีย์หลักคอลัมน์

แล้วคีย์หลักของคอลัมน์คืออะไร?

คีย์หลักของคอลัมน์ใน SQL Server 2016

คีย์หลักของคอลัมน์คือใบรับรองที่จัดเก็บไว้ในที่เก็บใบรับรองของ Windows (ซึ่งใช้การสาธิตเป็นตัวเลือกการจัดเก็บใบรับรอง) โมดูลความปลอดภัยของฮาร์ดแวร์ของบริษัทอื่น (ชื่อทั่วไปสำหรับโซลูชันของบริษัทอื่นสำหรับการติดตั้ง การจัดการ และการใช้งาน ใบรับรอง ) หรือ Azure Key Vault (โซลูชันระบบคลาวด์ของ Microsoft สำหรับการจัดการใบรับรอง)

แอปพลิเคชันที่เข้ารหัสข้อมูลใช้คีย์หลักของคอลัมน์เพื่อป้องกันคีย์การเข้ารหัสคอลัมน์ต่างๆ ที่จัดการการเข้ารหัสข้อมูลภายในคอลัมน์ของตารางฐานข้อมูล การใช้ที่เก็บใบรับรองจาก SQL Server ซึ่งบางครั้งเรียกว่า Enterprise Key Manager จำเป็นต้องใช้ SQL Server Enterprise Edition

ในบทความนี้ เราจะอธิบายการใช้ใบรับรองแบบลงนามเองที่คุณจัดเก็บไว้ใน Microsoft Certificate Store ของระบบปฏิบัติการ Windows แม้ว่าวิธีนี้จะไม่ใช่การกำหนดค่าที่เหมาะสมที่สุด แต่ก็แสดงให้เห็นถึงแนวคิดของ Always Encrypted—แต่ยังต้องระบุด้วยว่าวิธีการนี้ ไม่เป็นที่ยอมรับสำหรับสภาพแวดล้อมการใช้ งานจริง โดยที่การจัดการใบรับรองต้องทำด้วยบัญชีผู้ใช้ที่ปลอดภัยแยกต่างหาก และโดยเฉพาะอย่างยิ่ง , บนเซิร์ฟเวอร์แยกต่างหาก

คุณสามารถสร้างคำนิยามคีย์หลักของคอลัมน์ได้โดยใช้อินเทอร์เฟซแบบกราฟิกภายใน SQL Server Management Studio (SSMS) หรือโดยใช้ T-SQL ใน SSMS ให้เชื่อมต่อกับอินสแตนซ์ฐานข้อมูล SQL Server 2016 ที่คุณต้องการใช้ Always Encrypted เพื่อปกป้องตารางฐานข้อมูล

การสร้างและการใช้คีย์หลักของคอลัมน์

ใน Object Explorer ให้ไปที่ฐานข้อมูลก่อน จากนั้นไปที่ Security จากนั้นขยายโฟลเดอร์ Always Encrypted Keys เพื่อแสดงโฟลเดอร์ย่อยสองโฟลเดอร์ดังที่แสดงในรูปต่อไปนี้:

สร้างคีย์ใน SSMS

สร้างคีย์ใน SSMS

เปิดกล่องโต้ตอบคีย์หลักของคอลัมน์ใหม่

เปิดกล่องโต้ตอบคีย์หลักของคอลัมน์ใหม่

ตรวจสอบการมีอยู่ของคีย์ใน Windows Certificate Store

ตรวจสอบการมีอยู่ของคีย์ใน Windows Certificate Store

ในการสร้างคีย์หลักของคอลัมน์ ให้คลิกขวาที่โฟลเดอร์ Column Master Keys และเลือก New Column Master Key ในกล่องโต้ตอบ New Column Master Key ให้พิมพ์ชื่อสำหรับคีย์หลักของคอลัมน์ ระบุว่าจะเก็บคีย์ไว้ในที่เก็บใบรับรองของผู้ใช้ปัจจุบันหรือเครื่องภายในเครื่อง หรือ Azure Key Vault จากนั้นเลือกใบรับรองในรายการ หากไม่มีใบรับรอง หรือถ้าคุณต้องการใช้ใบรับรองที่ลงนามเองใหม่ ให้คลิกปุ่ม Generate Certificate จากนั้นคลิก OK ขั้นตอนนี้จะสร้างใบรับรองที่ลงนามเองและโหลดลงในที่เก็บใบรับรองของบัญชีผู้ใช้ปัจจุบันที่เรียกใช้ SSMS

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

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

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

  • การส่งออกใบรับรอง
    • Windows 7 และ Windows Server 2008 R2
    • Windows 8 และ Windows Server 2012
    • Windows 8.1 และ Windows Server 2012 R2
    • Windows 10 และ Windows Server 2016
  • ใบรับรองการนำเข้า
    • Windows 7 และ Windows Server 2008 R2
    • Windows 8 และ Windows Server 2012
    • Windows 8.1 และ Windows Server 2012 R2
    • Windows 10 และ Windows Server 2016

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

คีย์การเข้ารหัสคอลัมน์

หลังจากสร้างคีย์หลักของคอลัมน์ คุณก็พร้อมที่จะสร้างคีย์เข้ารหัสสำหรับคอลัมน์เฉพาะแล้ว โปรแกรมควบคุม ADO.NET ของ SQL Server 2016 ใช้คีย์การเข้ารหัสคอลัมน์เพื่อเข้ารหัสข้อมูลก่อนที่จะส่งไปยัง SQL Server และเพื่อถอดรหัสข้อมูลหลังจากดึงข้อมูลจากอินสแตนซ์ของ SQL Server 2016 เช่นเดียวกับคีย์หลักคอลัมน์ คุณสามารถสร้างคีย์การเข้ารหัสคอลัมน์โดยใช้ T-SQL หรือ SSMS แม้ว่าคีย์หลักคอลัมน์จะสร้างได้ง่ายกว่าโดยใช้ T-SQL แต่คีย์การเข้ารหัสคอลัมน์ก็สร้างได้ง่ายกว่าโดยใช้ SSMS

ในการสร้างคีย์การเข้ารหัสคอลัมน์ ให้ใช้ Object Explorer เพื่อเชื่อมต่อกับอินสแตนซ์ฐานข้อมูล นำทางไปยังฐานข้อมูล จากนั้นไปที่ Security และขยายโฟลเดอร์ Always Encrypted Keys คลิกขวาที่ Column Encryption Keys จากนั้นเลือก New Column Encryption Key ในไดอะล็อกบ็อกซ์ New Column Encryption Key ให้พิมพ์ชื่อสำหรับคีย์เข้ารหัสใหม่ เลือก Column Master Key Definition ในรายการดรอปดาวน์ จากนั้นคลิก OK ตอนนี้คุณสามารถใช้คีย์การเข้ารหัสคอลัมน์ในคำจำกัดความของตารางใหม่ได้แล้ว

การสร้างคีย์การเข้ารหัสคอลัมน์

การเข้ารหัส SQL: การสร้างคีย์การเข้ารหัสคอลัมน์, ภาพที่1

การเข้ารหัส SQL: การสร้างคีย์การเข้ารหัสคอลัมน์, รูปภาพ2

การสร้างตารางที่มีค่าเข้ารหัส

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

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

ประเภทการเข้ารหัสของ SQL Server 2016

ก่อนสร้างตารางเพื่อให้มีค่าที่เข้ารหัส คุณต้องตัดสินใจว่าควรเข้ารหัสแต่ละคอลัมน์หรือไม่

อันดับแรก คอลัมน์นี้จะใช้เพื่อค้นหาค่าหรือเพียงแค่คืนค่าเหล่านั้น

หากคอลัมน์จะใช้สำหรับการค้นหา คอลัมน์นั้นจะต้องใช้ ประเภทการเข้ารหัสที่กำหนด ขึ้นได้ ซึ่งช่วยให้ดำเนินการได้อย่างเท่าเทียมกัน อย่างไรก็ตาม มีข้อจำกัดในการค้นหาข้อมูลที่ได้รับการเข้ารหัสโดยใช้คุณลักษณะ Always Encrypted SQL Server 2016 รองรับเฉพาะการดำเนินการที่เท่าเทียมกัน ซึ่งรวมถึง equal to not equal to joins (ซึ่งใช้ความเท่าเทียมกัน) และการใช้ค่าในส่วนคำสั่ง GROUP BY ไม่รองรับการค้นหาใด ๆ โดยใช้ LIKE นอกจากนี้ การเรียงลำดับข้อมูลที่เข้ารหัสโดยใช้ Always Encrypted จะต้องดำเนินการในระดับแอปพลิเคชัน เนื่องจาก SQL Server จะเรียงลำดับตามค่าที่เข้ารหัสมากกว่าค่าที่ถอดรหัส

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

การสร้างตารางด้วยคอลัมน์ที่เข้ารหัส

เมื่อสร้างตาราง คุณใช้ไวยากรณ์ CREATE TABLE ปกติพร้อมพารามิเตอร์เพิ่มเติมบางส่วนภายในคำจำกัดความของคอลัมน์ มีการใช้พารามิเตอร์สามตัวภายในไวยากรณ์ ENCRYPTED WITH สำหรับคำ CREATE TABLE

อันดับแรกคือพารามิเตอร์ ENCRYPTION_TYPE ซึ่งยอมรับค่า RANDOMIZED หรือ DETERMINISTIC ตัวที่สองคือพารามิเตอร์ ALGORITHM ซึ่งยอมรับเฉพาะค่า RAEAD_AES_256_CBC_HMAC_SHA_256 พารามิเตอร์ที่สามคือ COLUMN_ENCRYPTION_KEY ซึ่งเป็นคีย์การเข้ารหัสที่คุณใช้เพื่อเข้ารหัสค่า

 CREATE TABLE [dbo].[Customers] ( [CustomerId] [int] IDENTITY(1,1), [TaxId] [varchar](11) COLLATE Latin1_General_BIN2 ENCRYPTED WITH (ENCRYPTION_TYPE = DETERMINISTIC, ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256', COLUMN_ENCRYPTION_KEY = YOUR_COLUMN_ENCRYPTION_KEY) NOT NULL, [FirstName] [nvarchar](50) NULL, [LastName] [nvarchar](50) NULL, [MiddleName] [nvarchar](50) NULL, [Address1] [nvarchar](50) NULL, [Address2] [nvarchar](50) NULL, [Address3] [nvarchar](50) NULL, [City] [nvarchar](50) NULL, [PostalCode] [nvarchar](10) NULL, [State] [char](2) NULL, [BirthDate] [date] ENCRYPTED WITH (ENCRYPTION_TYPE = RANDOMIZED, ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256', COLUMN_ENCRYPTION_KEY = YOUR_COLUMN_ENCRYPTION_KEY) NOT NULL PRIMARY KEY CLUSTERED ([CustomerId] ASC) ON [PRIMARY] ); GO

การสร้างดัชนีด้วยการเข้ารหัสเสมอ

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

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

ประสิทธิภาพที่เข้ารหัสเสมอ

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

การทดสอบผลลัพธ์ประสิทธิภาพการทำงานที่เข้ารหัสเสมอของเซิร์ฟเวอร์ SQL

การทดสอบผลลัพธ์ประสิทธิภาพการทำงานที่เข้ารหัสเสมอของเซิร์ฟเวอร์ SQL ภาพที่1

การทดสอบผลลัพธ์ประสิทธิภาพการทำงานที่เข้ารหัสเสมอของเซิร์ฟเวอร์ SQL รูปภาพ2

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

หมายเหตุ: ในกรณีที่คุณต้องการเรียนรู้เพิ่มเติมเกี่ยวกับการเพิ่มประสิทธิภาพการทำงานของ Microsoft SQL Sever โปรดดูบทความก่อนหน้าของเรา วิธีปรับแต่ง Microsoft SQL Server สำหรับประสิทธิภาพ

การเปลี่ยนแปลงการสมัคร

คุณต้องทำอะไรเพื่อใช้ Always Encrypted ในรหัสดั้งเดิมอย่างถูกต้อง

ข้อดีอย่างหนึ่งของฟีเจอร์ Always Encrypted ของ SQL Server 2016 ก็คือ แอปพลิเคชันที่ใช้กระบวนงานที่เก็บไว้, ORM หรือคำสั่ง T-SQL ที่มีการกำหนดพารามิเตอร์อยู่แล้ว ไม่ควรต้องมี การเปลี่ยนแปลงแอปพลิเคชัน เพื่อใช้ Always Encrypted เว้นแต่จะมีการใช้การดำเนินการที่ไม่เท่าเทียมกันอยู่แล้ว แอปพลิเคชันที่สร้างคำสั่ง SQL เป็น SQL แบบไดนามิกภายในแอปพลิเคชันและดำเนินการคำสั่งเหล่านั้นกับฐานข้อมูลโดยตรง จำเป็นต้องแก้ไขเพื่อใช้การกำหนดพารามิเตอร์ของการสืบค้น ซึ่งเป็นแนวทางปฏิบัติด้านความปลอดภัยที่ดีที่สุดสำหรับแอปพลิเคชันทั้งหมด ก่อนจึงจะสามารถใช้ประโยชน์จากคุณลักษณะ Always Encrypted ได้

การเปลี่ยนแปลงอื่นที่จำเป็นเพื่อให้ Always Encrypted ทำงานได้คือการเพิ่มแอตทริบิวต์สตริงการเชื่อมต่อไปยังสตริงการเชื่อมต่อของแอปพลิเคชันที่เชื่อมต่อกับฐานข้อมูล: Column Encryption Setting=enabled

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

ดังนั้น .NET Framework จึงมีวิธีการใหม่บนวัตถุ SqlConnection ที่เรียกว่า SqlCommandColumnEncryptionSetting ซึ่งมีสามค่าที่เป็นไปได้:

  • Disabled ใช้งาน — ไม่มีคอลัมน์หรือพารามิเตอร์ที่เข้ารหัสเสมอที่จะใช้สำหรับแบบสอบถามที่ดำเนินการโดยใช้วัตถุการเชื่อมต่อนี้
  • Enabled — มีคอลัมน์และ/หรือพารามิเตอร์ที่เข้ารหัสเสมอสำหรับคิวรีที่ดำเนินการโดยใช้วัตถุการเชื่อมต่อนี้
  • ResultSet — ไม่มีพารามิเตอร์ที่เข้ารหัสเสมอ อย่างไรก็ตาม การดำเนินการสอบถามโดยใช้วัตถุการเชื่อมต่อนี้จะส่งคืนคอลัมน์ที่เข้ารหัสโดยใช้การเข้ารหัสเสมอ

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

เพื่อประสิทธิภาพที่ดีที่สุดของ SQL Server ขอแนะนำให้ขอเฉพาะข้อมูลเมตาเกี่ยวกับ Always Encrypted สำหรับการสืบค้นที่ใช้ Always Encrypted ซึ่งหมายความว่าในแอปพลิเคชันที่การสืบค้นจำนวนมากใช้ Always Encrypted ควรเปิดใช้งานสตริงการเชื่อมต่อและแบบสอบถามเฉพาะภายในแอปพลิเคชันควรระบุ SqlCommandColumnEncryptionSetting เป็น Disabled สำหรับแอปพลิเคชันที่การสืบค้นส่วนใหญ่ไม่ได้ใช้ค่า Always Encrypted ไม่ควรเปิดใช้งานสตริงการเชื่อมต่อ และควรตั้งค่า SqlCommandColumnEncryptionSetting สำหรับ Enabled หรือ ResultSet ตามความจำเป็นสำหรับคิวรีเหล่านั้นที่ใช้คอลัมน์ Always Encrypted ในกรณีส่วนใหญ่ แอปพลิเคชันสามารถเปิดใช้งานแอตทริบิวต์สตริงการเชื่อมต่อได้อย่างง่ายดาย และประสิทธิภาพของแอปพลิเคชันจะไม่เปลี่ยนแปลงในขณะที่ใช้ข้อมูลที่เข้ารหัส

การเข้ารหัสเสมอคุ้มค่ากับความพยายามหรือไม่?

ตอบสั้นๆ? ใช่อย่างแน่นอน!

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

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

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