จัดการสิทธิ์และการเข้าถึงที่ปลอดภัย

เสร็จสมบูรณ์เมื่อ

สิทธิ์ระดับวัตถุจะควบคุมการกระทําที่ผู้ใช้สามารถทําได้กับวัตถุฐานข้อมูล เช่น ตาราง มุมมอง กระบวนงานที่เก็บไว้ และฟังก์ชัน ในขณะที่ Row-Level Security กรองข้อมูลภายในออบเจ็กต์ สิทธิ์ระดับออบเจ็กต์จะกําหนดว่าผู้ใช้สามารถเข้าถึงออบเจ็กต์ได้เลยหรือไม่ และการดําเนินการใดที่พวกเขาสามารถทําได้

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

ทําความเข้าใจลําดับชั้นของสิทธิ์

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

ในระดับเซิร์ฟเวอร์ สิทธิ์จะควบคุมการจัดการการลงชื่อเข้าใช้และการกําหนดค่าเซิร์ฟเวอร์ สิทธิ์ระดับฐานข้อมูลจะควบคุมการดําเนินการภายในฐานข้อมูลเฉพาะ สิทธิ์ระดับ Schema ใช้กับออบเจ็กต์ทั้งหมดภายใน Schema ในขณะที่สิทธิ์ระดับออบเจ็กต์กําหนดเป้าหมายตาราง มุมมอง หรือกระบวนงานที่เฉพาะเจาะจง

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

-- Grant SELECT on all objects in the Sales schema
GRANT SELECT ON SCHEMA::Sales TO SalesAnalyst;

-- Grant EXECUTE on all procedures in the Reports schema
GRANT EXECUTE ON SCHEMA::Reports TO ReportingUsers;

ให้และเพิกถอนสิทธิ์

คําสั่งสามคําสั่งควบคุมสิทธิ์: GRANT ให้สิทธิ์ REVOKE เฉพาะแก่ผู้ใช้ ลบสิทธิ์ที่ได้รับก่อนหน้านี้ และ DENY บล็อกสิทธิ์อย่างชัดเจน โดยแทนที่การให้สิทธิ์ใดๆ

-- Allow reading data
GRANT SELECT ON dbo.Customers TO CustomerServiceRole;

-- Allow data modifications
GRANT INSERT, UPDATE ON dbo.Orders TO OrderProcessingRole;

-- Explicitly deny access to sensitive data (overrides any grants)
DENY SELECT ON dbo.EmployeeSalaries TO HRAssistants;

-- Remove a permission without explicitly denying it
REVOKE INSERT ON dbo.Customers FROM CustomerServiceRole;

ความแตกต่างระหว่าง REVOKE และ DENYคืออะไร ? มันสําคัญเมื่อผู้ใช้มีแหล่งที่มาของสิทธิ์หลายแหล่ง การเพิกถอนจะนําการให้สิทธิ์หนึ่งรายการออก แต่จะไม่ป้องกันการเข้าถึงผ่านการให้สิทธิ์อื่นๆ การปฏิเสธการเข้าถึงจะบล็อกไม่ว่าจะมีเงินช่วยเหลืออื่นใดก็ตาม

ใช้การควบคุมการเข้าถึงตามบทบาท

แทนที่จะให้สิทธิ์โดยตรงแก่ผู้ใช้ ให้สร้าง บทบาทฐานข้อมูล ที่แสดงถึงฟังก์ชันงาน กําหนดสิทธิ์ให้กับบทบาท จากนั้นเพิ่มผู้ใช้ในบทบาทที่เหมาะสม:

-- Create roles for different job functions
CREATE ROLE DataReaders;
CREATE ROLE DataWriters;

-- Grant appropriate permissions to each role
GRANT SELECT ON SCHEMA::dbo TO DataReaders;
GRANT INSERT, UPDATE, DELETE ON SCHEMA::dbo TO DataWriters;

-- Add users to roles
ALTER ROLE DataReaders ADD MEMBER JohnSmith;
ALTER ROLE DataWriters ADD MEMBER JaneDoc;

คุณยังสามารถซ้อนบทบาทเพื่อสร้างโครงสร้างสิทธิ์ตามลําดับชั้น โดยการเพิ่มบุคคลในบทบาทระดับบนสุดจะให้สิทธิ์บทบาทรองทั้งหมดแก่พวกเขาโดยอัตโนมัติ

เคล็ดลับ

จัดทําเอกสารลําดับชั้นของบทบาทของคุณและใช้แบบแผนการตั้งชื่อที่ทําให้วัตถุประสงค์ของแต่ละบทบาทชัดเจน เช่น การนําหน้าแผนกหรือหน้าที่

ใช้การแยกสคีมาเพื่อความปลอดภัย

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

CREATE SCHEMA Sales AUTHORIZATION dbo;
CREATE SCHEMA HR AUTHORIZATION dbo;

-- Sales team can read and write sales data
GRANT SELECT, INSERT, UPDATE ON SCHEMA::Sales TO SalesTeam;

-- HR has full control of their schema
GRANT CONTROL ON SCHEMA::HR TO HRAdministrators;

กําหนดค่าการรับรองความถูกต้องของ Microsoft Entra

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

ฐานข้อมูล SQL รองรับวิธีการรับรองความถูกต้องหลายวิธี การรับรองความถูกต้อง SQL ใช้ชื่อผู้ใช้และรหัสผ่านที่เก็บไว้ในฐานข้อมูล ตรงไปตรงมา แต่มีความเสี่ยงหากข้อมูลประจําตัวถูกบุกรุก การรับรองความถูกต้องของ Microsoft Entra ขยายการรวมข้อมูลประจําตัวไปยังสถานการณ์ระบบคลาวด์ โดยทํางานร่วมกับฐานข้อมูล Azure SQL, Azure SQL Managed Instance, SQL Server 2022+ และฐานข้อมูล SQL ใน Microsoft Fabric

การสร้างผู้ใช้ฐานข้อมูลจากข้อมูลประจําตัวของ Microsoft Entra นั้นง่ายมาก:

-- Create users for Entra accounts, managed identities, or groups
CREATE USER [app-service-identity] FROM EXTERNAL PROVIDER;
CREATE USER [developer@contoso.com] FROM EXTERNAL PROVIDER;
CREATE USER [DataAnalystsGroup] FROM EXTERNAL PROVIDER;

-- Grant permissions just like SQL users
ALTER ROLE db_datareader ADD MEMBER [developer@contoso.com];
ALTER ROLE db_datawriter ADD MEMBER [app-service-identity];

ใช้การรับรองความถูกต้องของข้อมูลประจําตัวที่มีการจัดการ

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

สําหรับ Azure App Service ที่เชื่อมต่อกับฐานข้อมูล Azure SQL ให้เปิดใช้งานข้อมูลประจําตัวที่มีการจัดการที่ระบบกําหนด จากนั้นสร้างผู้ใช้ฐานข้อมูล:

CREATE USER [MyWebApp] FROM EXTERNAL PROVIDER;
ALTER ROLE db_datareader ADD MEMBER [MyWebApp];
ALTER ROLE db_datawriter ADD MEMBER [MyWebApp];

อัปเดตสตริงการเชื่อมต่อแอปพลิเคชันของคุณเพื่อใช้การรับรองความถูกต้องของข้อมูลประจําตัวที่มีการจัดการ:

Server=tcp:myserver.database.windows.net,1433;Database=mydb;Authentication=Active Directory Managed Identity;Encrypt=True;

เคล็ดลับ

ใช้ข้อมูลประจําตัวที่มีการจัดการที่ผู้ใช้กําหนดเมื่อหลายแอปพลิเคชันต้องการสิทธิ์ฐานข้อมูลเดียวกัน ซึ่งจะช่วยลดจํานวนผู้ใช้ฐานข้อมูลที่ต้องจัดการ

สตริงการเชื่อมต่อที่ปลอดภัย

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

• จัดเก็บไว้ใน Azure Key Vault หรือตัวแปรสภาพแวดล้อม ไม่ใช่ในโค้ด
• ใช้ข้อมูลประจําตัวที่มีการจัดการเพื่อกําจัดข้อมูลประจําตัวออกจากสตริงการเชื่อมต่อทั้งหมด
• เปิดใช้งานการเชื่อมต่อที่เข้ารหัสด้วย Encrypt=True;TrustServerCertificate=False
• จํากัดการเข้าถึงเครือข่ายโดยใช้กฎไฟร์วอลล์และปลายทางส่วนตัว

สำคัญ

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

ดูและตรวจสอบสิทธิ์

คุณสามารถสืบค้นมุมมองระบบเพื่อทําความเข้าใจการกําหนดสิทธิ์ปัจจุบัน:

-- View all permissions for a specific principal
SELECT 
    prin.name AS PrincipalName,
    perm.permission_name,
    perm.state_desc AS PermissionState,
    obj.name AS ObjectName
FROM sys.database_permissions perm
INNER JOIN sys.database_principals prin ON perm.grantee_principal_id = prin.principal_id
LEFT JOIN sys.objects obj ON perm.major_id = obj.object_id
WHERE prin.name = 'SalesAnalyst';

-- Check effective permissions for the current user
SELECT * FROM fn_my_permissions('Sales.Orders', 'OBJECT');

ทําให้เป็นนิสัยในการตรวจสอบการมอบหมายสิทธิ์อย่างสม่ําเสมอเพื่อให้แน่ใจว่ายังคงสอดคล้องกับหน้าที่งานปัจจุบัน และอย่าลืมว่าสิทธิ์ระดับอ็อบเจ็กต์จะทํางานได้ดีที่สุดเมื่อรวมกับฟีเจอร์ความปลอดภัยอื่นๆ เช่น Row-Level Security และ Dynamic Data Masking เพื่อการป้องกันที่ครอบคลุม