ניהול הרשאות וגישה מאובטחת

הושלם

הרשאות ברמת האובייקט שולטות באילו פעולות המשתמשים יכולים לבצע על אובייקטים במסד הנתונים כמו טבלאות, תצוגות, פרוצדורות מאוחסנות ופונקציות. בעוד שאבטחת Row-Level מסננת נתונים בתוך אובייקטים, הרשאות ברמת האובייקט קובעות האם המשתמש יכול לגשת לאובייקט בכלל ואילו פעולות הוא יכול לבצע.

מודל הרשאות מתוכנן היטב הולך יד ביד עם אימות מאובטח. היחידה הזו כוללת את שניהם: כיצד להעניק את ההרשאות הנכונות וכיצד להבטיח שהמשתמשים מאמתים בצורה מאובטחת, רצוי ללא סיסמאות.

הבן את היררכיית ההרשאות

SQL Server משתמש במודל הרשאות היררכי שבו הרשאות שניתנו ברמות גבוהות יותר זורמות לרמות נמוכות יותר. תחשוב על זה כמפל: שרת → מסד נתונים → סכמת → אובייקטים בודדים.

ברמת השרת, הרשאות שולטות בניהול ההתחברות ובהגדרת השרת. הרשאות ברמת מסד הנתונים שולטות בפעולות בתוך מסד נתונים מסוים. הרשאות ברמת הסכימה חלות על כל האובייקטים בתוך הסכימה, בעוד שהרשאות ברמת האובייקט מכוונות לטבלאות, תצוגות או פרוצדורות ספציפיות.

הנה דפוס חזק: כשאתה מעניק SELECT הרשאה לסכימה, המשתמשים יכולים לבחור מכל הטבלאות והתצוגות באותה סכמה—כולל אובייקטים שנוצרו בעתיד:

-- 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 Database, 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 ו-Data Masked דינמי להגנה מקיפה.