فصل ۴

بهبودهای امنیتی

دیدگاه عمومی دربارهٔ نسخهٔ قبلی Microsoft SQL Server این بود که حفاظت استثنایی از داده، کنترل دسترسی و انطباق را ارائه می‌کرد. SQL Server 2008 R2 قابلیت‌های متعددی در اختیار سازمان‌ها گذاشته بود؛ از جمله رمزگذاری شفاف داده (Transparent Data Encryption یا TDE) برای حفاظت از دادهٔ ساکن، Extensible Key Management یا EKM برای جداسازی داده و کلید، احراز هویت Kerberos برای قوی‌ترین سطح احراز هویت، و SQL Server Audit، Policy-Based Management و Change Data Capture برای رعایت الزامات انطباق. SQL Server 2008 R2 از منظر امنیت بسیار قوی و یکی از رهبران صنعت سکوی پایگاه‌داده بود؛ کمترین آسیب‌پذیری و کمترین تعداد وصلهٔ امنیتی برای نگه‌داری را داشت. SQL Server 2012 با ارائهٔ چندین بهبود امنیتی، محبوبیت SQL Server را افزایش می‌دهد و به سازمان‌ها کمک می‌کند کنترل دسترسی به داده را بهتر کنند، در حالی که بالاترین سطح حفاظت و انطباق حفظ می‌شود.

بهبودهای امنیتی SQL Server 2012

• بهبودهای مدیریت‌پذیری امنیت: شِمای پیش‌فرض گروه‌ها و نقش‌های سروری تعریف‌شده توسط کاربر.
• بهبودهای ممیزی: پشتیبانی در همهٔ SKUها، تاب‌آوری بهتر، رویداد ممیزی تعریف‌شده توسط کاربر، فیلتر رکورد و اطلاعات پشتهٔ T-SQL.
• بهبود احراز هویت پایگاه‌داده: احراز هویت پایگاه‌داده‌های محصور.

• تغییرات رمزنگاری: الگوریتم‌های Hash، طول کلید گواهی، و تغییر رمزگذاری Service Master Key و Database Master Key از 3DES به AES.
• بهبودهای متفرقه: یکپارچگی عمیق با SharePoint و Active Directory، بهبودهای Provisioning و مجوزهای جدید.

این فصل همهٔ این بهبودهای جدید را، با آغاز از مدیریت‌پذیری امنیت، شرح می‌دهد.

بهبودهای مدیریت‌پذیری امنیت

دو تغییر کوچک اما بسیار مهم معرفی شده است: شِمای پیش‌فرض برای گروه‌ها و نقش‌های سروری تعریف‌شده توسط کاربر.

شِمای پیش‌فرض برای گروه‌ها

در نسخه‌های پیشین می‌شد برای کاربران SQL Server شِمای پیش‌فرض تعریف کرد. این کار امنیت را بهتر و مدیریت را ساده می‌کرد. شِمای پیش‌فرض نخستین شِمایی بود که هنگام Resolve نام اشیای ارجاع‌شده جست‌وجو می‌شد. اگر حساب شِمای پیش‌فرض نداشت، SQL Server شِمای dbo را فرض می‌کرد. مشکل مهم این بود که برای گروه‌های Windows نمی‌شد شِمای پیش‌فرض تعریف کرد. اگر کاربر به‌عنوان عضو یک گروه Windows احراز هویت می‌شد، شِمای پیش‌فرضی نداشت. اگر شیئی مانند جدول می‌ساخت، شِمای جدیدی با نام همان کاربر ایجاد می‌شد. اگر ۵۰۰ کاربر عضو گروه هرکدام شیء ایجاد می‌کردند، مدیر باید ۵۰۰ شِما را مدیریت می‌کرد.

در SQL Server 2012 می‌توان برای گروه‌های Windows شِمای پیش‌فرض ساخت؛ بنابراین مدیریت شِما ساده می‌شود.

این قابلیت همچنین احتمال واگذاری شِما به کاربران نادرست هنگام تغییر عضویت گروه را کاهش می‌دهد، از خطاهای پرس‌وجو در صورت استفاده از شِمای اشتباه جلوگیری می‌کند و مانع ایجاد ضمنی و غیرضروری شِما می‌شود.

اگر کاربر عضو بیش از یک گروه Windows باشد و برای حساب کاربر شِمای پیش‌فرض تعریف نشده باشد، SQL Server جدول sys.principal را بررسی و گروه دارای کمترین Principal ID را به‌عنوان شِمای پیش‌فرض انتخاب می‌کند.

اسکریپت زیر یک گروه محلی Windows، عضویت نقش، شِمای پیش‌فرض و جدول را ایجاد می‌کند:

-- Create User based on Local Group [SQL01\CDBUsers]
    CREATE USER [SQL01\CDBUsers]
    GO
    --Allocate Database Role Membership
    ALTER ROLE DB_DATAREADER ADD MEMBER [SQL01\CDBUsers]
    ALTER ROLE DB_DATAWRITER ADD MEMBER [SQL01\CDBUsers];
    GO
    --Create Default Schema for Group
    CREATE SCHEMA Users AUTHORIZATION [SQL01\CDBUsers];
    GO
    -- Set the default schema for Group
    ALTER USER [SQL01\CDBUsers] WITH DEFAULT_SCHEMA = Users
    GO
    --Create Table with Group and Default Schema
    CREATE TABLE Users.t1(c1 int)
    GO
    --Insert Value
    INSERT INTO Users.t1 VALUES (1)

مثال گروه [SQL01\CDBUsers] را می‌سازد، عضویت نقش پایگاه‌داده را تخصیص می‌دهد، شِمای پیش‌فرض را ایجاد و به گروه اختصاص می‌دهد و در پایان جدول و یک رکورد می‌سازد.

نقش‌های سروری تعریف‌شده توسط کاربر

امنیت مبتنی بر نقش و جداسازی وظایف برای انطباق ضروری‌اند. هدف، محدودکردن دسترسی به کاربران مجاز برای کاهش تهدید، نقض امنیت و خطاهای عملیاتی، همراه با مدیریت بهتر کاربران و امتیازهای آن‌هاست.

این راهبرد معمولاً با ساخت نقش، اعمال مجوزها روی نقش و افزودن اعضا به نقش اجرا می‌شود، نه با دادن مجوز یکسان به هر کاربر یا مدیر.

در نسخه‌های پیشین، نقش تعریف‌شده توسط کاربر جداسازی وظایف را فقط در سطح پایگاه‌داده فراهم می‌کرد. در سطح سرور فقط نقش‌های ثابت موجود بودند و مدیر نمی‌توانست Securableها را با جزئیات سفارشی کند. در نتیجه گاهی نقش پرقدرتی مانند sysadmin داده می‌شد، چون نقش ثابت مناسبی وجود نداشت. SQL Server 2012 نقش‌های تعریف‌شده توسط کاربر را در سطح سرور معرفی می‌کند تا انعطاف، مدیریت‌پذیری و جداسازی وظایف بهتر شوند.

ایجاد و مدیریت نقش‌های سرور

در SSMS پوشهٔ Security را باز، روی Server Roles راست‌کلیک و New Server Role را انتخاب کنید. روش دیگر استفاده از CREATE SERVER ROLE، ALTER SERVER ROLE و DROP SERVER ROLE است.

ایجاد با SSMS

1. با Object Explorer به Database Engine متصل شوید.
2. نمونه و پوشهٔ Security را باز کنید.
3. روی Server Roles راست‌کلیک و New Server Role را انتخاب کنید.
4. در صفحهٔ General نام و مالک نقش را تعیین، Securableهای مناسب را انتخاب و برای هرکدام Grant، With Grant یا Deny را مشخص کنید.
5. در Members، Loginهای افراد یا گروه‌ها را اضافه کنید.

6. در Memberships، نقش‌های سروری دیگری را که نقش جدید عضو آن‌ها خواهد بود مشخص کنید.

ایجاد با Transact-SQL

اسکریپت زیر نقش DBAControlServer را می‌سازد، گروه Windows مربوط به Finance را عضو می‌کند و اجازهٔ ساخت پایگاه‌داده و گروه دسترس‌پذیری را می‌دهد، اما تغییر Loginها و Server Auditها را منع می‌کند.

USE [master]
    CREATE SERVER ROLE [DBAControlServer] AUTHORIZATION [sysadmin]
    ALTER SERVER ROLE [DBAControlServer] ADD
     MEMBER [PROTOTYPE\Finance]
    GRANT CONTROL SERVER TO [DBAControlServer]
    GO
    GRANT CREATE ANY DATABASE TO [DBAControlServer]
    GRANT CREATE AVAILABILITY GROUP TO [DBAControlServer]
    DENY ALTER ANY LOGIN TO [DBAControlServer]
    DENY ALTER ANY SERVER AUDIT TO [DBAControlServer]
    GO

بهبودهای ممیزی

با افزایش سازمان‌های مشمول مقررات، گروه امنیت SQL Server قابلیت‌های ممیزی سرور و پایگاه‌داده را در زمینه‌های زیر بهبود داد:

• پشتیبانی Audit در همهٔ SKUها.
• تاب‌آوری بهتر.
• رویداد Audit تعریف‌شده توسط کاربر.
• فیلتر رکورد.
• اطلاعات پشتهٔ T-SQL.

پشتیبانی در همهٔ SKUها

Server Audit Specification و Database Audit Specification در SQL Server 2008 و 2008 R2 برای انطباق محبوب بودند، اما فقط در SKUهای ممتاز در دسترس بودند. کاربران Standard مجبور بودند از SQL Trace استفاده کنند که قابلیت ممیزی محدودتر، احتمال اثر منفی بر کارایی و نبود راهکار یکپارچه برای گردآوری داده از Trace و Security Log را به همراه داشت. SQL Trace در نهایت بازنشسته خواهد شد و قابلیت پایهٔ Audit در همهٔ SKUهای SQL Server 2012 عرضه می‌شود.

تاب‌آوری بهتر

در نسخه‌های پیشین، خرابی مقصد Audit می‌توانست به ازدست‌رفتن داده منجر شود. اگر Log روی Network Share نوشته می‌شد و Share از دسترس خارج می‌شد، اطلاعات دیگر ثبت نمی‌شد. این کمبود در بررسی‌های Forensic مشکل ایجاد می‌کرد. اگر ON_FAILURE = SHUTDOWN بود، حتی امکان توقف سراسری SQL Server وجود داشت. SQL Server 2012 گزینه‌های جدیدی ارائه می‌دهد:

• On Audit Shut Down Server: در صورت ناتوانی نوشتن Log، SQL Server خاموش می‌شود؛ حساب صادرکنندهٔ Shutdown باید مجوز لازم را داشته باشد.

• On Audit Log Failure: Continue: عملیات SQL Server ادامه می‌یابد و سامانه تلاش برای نوشتن رویدادها را ادامه می‌دهد، اما رکوردهای زمان خرابی حفظ نمی‌شوند. فقط زمانی استفاده شود که ادامهٔ کار از ثبت کامل مهم‌تر و با سیاست سازمان سازگار است.
• On Audit Log Failure: Fail Operation: تراکنش‌های مشمول Audit در صورت ناتوانی نوشتن رویداد شکست می‌خورند، اما تراکنش‌های غیرمشمول ادامه می‌یابند. مثلاً اگر فقط جدول Customer ممیزی شود، خرابی Audit عملیات Customer را متوقف می‌کند ولی Sales ادامه می‌یابد.

بهبودهای دیگر:

• گزینهٔ MAX_FILES تعداد فایل‌های Audit را محدود می‌کند.
• اطلاعات اضافی Stack Frame در Log کمک می‌کند مشخص شود Query از Stored Procedure یا برنامه صادر شده است.
• رویهٔ sp_audit_write اجازه می‌دهد برنامه اطلاعات سفارشی مانند کاربر برنامه را در Log بنویسد.
• ستون‌های اضافی به sys.server_file_audits، sys.server_audits و sys.fn_get_audit_file افزوده شده و فیلتر رویدادهای ناخواسته با WHERE در CREATE/ALTER SERVER AUDIT ممکن است.
• کاربران پایگاه‌داده‌های محصور قابل ممیزی‌اند.

ایجاد Audit جدید با SSMS

1. با Object Explorer به Database Engine متصل شوید.
2. نمونه و Security را باز کنید.
3. روی Audits راست‌کلیک و New Audit را انتخاب کنید.
4. در General نام Audit، Queue Delay بر حسب میلی‌ثانیه، گزینهٔ Audit Log Failure و مقصد را مشخص کنید.
5. اگر File انتخاب شده، File Path، Audit File Maximum Limit، Maximum File Size و در صورت نیاز Enable Reserve Disk Space را تعیین کنید.
6. در Audit Properties Filter می‌توان Predicate یا WHERE افزود.
7. برای ساخت Audit روی OK کلیک کنید.

در شکل، Audit با گزینهٔ Fail Operations ساخته شده است؛ اگر SQL Server نتواند در Log بنویسد عملیات شکست می‌خورد. همچنین پس از رسیدن تعداد فایل‌ها به سقفی مانند ۱۰، هر عمل ایجادکنندهٔ رویداد Audit جدید با خطا شکست می‌خورد.

USE [master]
    GO
    CREATE SERVER AUDIT [Audit-SQL01]
    TO FILE
    (    FILEPATH = N'D:\Audits'
       ,MAXSIZE = 10 GB
       ,MAX_FILES = 100
       ,RESERVE_DISK_SPACE = OFF
    )
    WITH
    (    QUEUE_DELAY = 1000
       ,ON_FAILURE = FAIL_OPERATION
    )
    GO

رویداد Audit تعریف‌شده توسط کاربر

این ویژگی اجازه می‌دهد برنامه‌ها رویداد سفارشی را در Audit Log ثبت کنند. نمونهٔ زیر پایگاه‌داده، شِما، جدول حساب‌ها و Stored Procedure اعتبارسنجی رمز عبور را ایجاد می‌کند:

CREATE DATABASE app1
    GO
    USE app1
    GO
    CREATE SCHEMA app
    GO
    CREATE TABLE app.accounts
    (name nvarchar(128), passwordHash varbinary(128))
    INSERT INTO app.accounts (name, passwordHash) values (N'jackr', 0x1234)
    INSERT INTO app.accounts (name, passwordHash) values (N'rob', 0x12345)
    CREATE PROCEDURE app.sp_establishId
    (@name nvarchar(128),
    @passwordHash varbinary(128))
    AS
    BEGIN
        DECLARE @hashMatches bit
        DECLARE @hash varbinary(128)
        DECLARE @additionalInfo nvarchar(512)
        SELECT @hash = passwordHash FROM app.accounts WHERE name = @name;
        IF (@hash = @passwordHash)

    BEGIN
             SET @hashMatches = 1;
        END
        ELSE
        BEGIN
             SET @hashMatches = 0;
        END
        SELECT @additionalInfo = NTech webuser=' + @name;
        EXEC sys.sp_audit_write 1, @hashMatches, @additionalInfo
        RETURN @hashMatches
    END
    DECLARE @authOK bit
    EXEC @authOK = app.sp_establishId N'jackr', 0x1234
    SELECT @authOK
    DECLARE @authOK bit
    EXEC @authOK = app.sp_establishId N'rob', 0x1234
    SELECT @authOK
    SELECT * from sys.fn_get_audit_file('c:\auditlogs\*', NULL, NULL)
    // cleanup
    use master
    go
    drop database app1
    go

در این نمونه جدول حساب‌ها نام کاربران لایهٔ میانی و Hash رمز را نگه می‌دارد و sp_establishId رمز را اعتبارسنجی می‌کند. لایهٔ میانی نام و رمز را می‌گیرد، رمز را Hash می‌کند و Procedure را فراخوانی می‌کند. در پایان، رویداد Audit شامل نام کاربر و موفق یا ناموفق بودن تطابق ثبت می‌شود. ممیزان با بررسی این رویداد و رویدادهای بعدی همان Session می‌توانند بفهمند چه عملی از طرف کاربر لایهٔ میانی انجام شده، حتی اگر Web Server با Service Account به SQL Server متصل باشد. سپس اسکریپت حالت موفق و شکست را نمایش و رکوردهای فایل c:\auditlogs را برمی‌گرداند.

فیلتر رکورد

SQL Server Audit بر Extended Events ساخته شده است. این زیرساخت سامانه‌ای عمومی برای مدیریت رویداد است، هم‌بستگی داده از SQL Server و در شرایطی سیستم‌عامل و برنامه‌ها را پشتیبانی می‌کند و چارچوبی با کارایی و Throughput بالا فراهم می‌سازد. SQL Server 2012 از فیلتر Extended Events استفاده می‌کند تا رویدادهای ناخواسته پیش از نوشتن حذف شوند. مثلاً می‌توان دسترسی حساب برنامه به جدول را از Audit حذف کرد ولی دسترسی همان جدول از خارج برنامه را ثبت کرد.

نمونهٔ زیر پایگاه‌داده، شِما و دو جدول می‌سازد. SensitiveData محرمانه است و باید ممیزی شود؛ GeneralData محرمانه نیست. Database Audit Specification همهٔ اشیای DataSchema را پوشش می‌دهد ولی Server Audit با WHERE فقط SensitiveData را نگه می‌دارد. فرض می‌شود پوشهٔ C:\SQLAudit وجود دارد.

CREATE DATABASE TestDB;
    GO
    USE TestDB;
    GO
    CREATE SCHEMA DataSchema;
    GO
    CREATE TABLE DataSchema.GeneralData (ID int PRIMARY KEY, DataField varchar(50) NOT NULL);
    GO CREATE TABLE DataSchema.SensitiveData (ID int PRIMARY KEY, DataField varchar(50) NOT NULL);
    GO
    -- Create the server audit in the master database USE master;
    GO
    CREATE SERVER AUDIT AuditDataAccess TO FILE ( FILEPATH ='C:\SQLAudit\' ) WHERE object_name =
    'SensitiveData' ;
    GO
    ALTER SERVER AUDIT AuditDataAccess WITH (STATE = ON);
    GO
    -- Create the database audit specification in the TestDB database USE TestDB;
    GO
    CREATE DATABASE AUDIT SPECIFICATION [FilterForSensitiveData]
    FOR SERVER AUDIT [AuditDataAccess]
    ADD (SELECT ON SCHEMA::[DataSchema]
    BY [public]) WITH (STATE = ON);
    GO
    -- Trigger the audit event by selecting from tables
    SELECT ID, DataField FROM DataSchema.GeneralData;
    SELECT ID, DataField FROM DataSchema.SensitiveData;
    GO
    -- Check the audit for the filtered content
    SELECT * FROM fn_get_audit_file
    ('C:\SQLAudit\AuditDataAccess_*.sqlaudit',default,default);
    GO

بهبودهای احراز هویت پایگاه‌داده

در نسخه‌های پیشین، کاربر برای احراز هویت پایگاه‌داده به Login در Database Engine نیاز داشت؛ Login می‌توانست حساب کاربر یا گروه Windows یا حساب SQL Server باشد. این وابستگی، به‌ویژه در قابلیت انتقال پایگاه‌داده، مشکل ایجاد می‌کرد. هنگام مهاجرت یا Failover باید همهٔ Loginهای مبدأ در مقصد نیز وجود می‌داشتند؛ در غیر این صورت کاربر، گروه یا برنامه نمی‌توانست متصل شود و ممکن بود توقف سراسری رخ دهد.

SQL Server 2012 با Contained Database Authentication این چالش را حل و انطباق، مجوزدهی و قابلیت انتقال را بهتر می‌کند. کاربران مستقیماً در پایگاه‌دادهٔ کاربری و بدون Login در Database Engine احراز هویت می‌شوند؛ بنابراین پایگاه‌دادهٔ محصور وابستگی خارجی ندارد.

اطلاعاتی مانند نام و رمز کاربر مستقیماً در پایگاه‌دادهٔ کاربری، نه master، ذخیره می‌شود. کاربران احراز‌شده نمی‌توانند عملیات سطح نمونه انجام دهند و فقط عملیات DML در پایگاه‌دادهٔ کاربری دارند. این قابلیت همچنین Loginهای Orphan یا بلااستفاده را حذف می‌کند.

فعال‌کردن پایگاه‌داده‌های محصور

این ویژگی Property سراسری سرور است و از Advanced Server Properties در SSMS یا Transact-SQL فعال می‌شود.

با SSMS

1. در Object Explorer روی نمونه راست‌کلیک و Properties را انتخاب کنید.
2. Advanced را باز و در Containment، گزینهٔ Enable Contained Databases را True کنید و OK بزنید.

با Transact-SQL

sp_configure 'show advanced options' 1,
    GO
    sp_configure 'contained database authentication', 1;
    GO
    RECONFIGURE;
    GO

مقدار ۱ اجازهٔ ساخت یا Attach پایگاه‌دادهٔ محصور را می‌دهد و مقدار ۰ آن را غیرفعال می‌کند.

ایجاد کاربران

پایگاه‌دادهٔ محصور کاربر و پایگاه‌داده را از Database Engine جدا می‌کند و قابلیت انتقال میان نمونه‌ها را می‌دهد. هنگام اتصال، اگر کاربر Login در master نداشته باشد، رشتهٔ اتصال باید نام پایگاه‌دادهٔ محصور را به‌عنوان Initial Catalog داشته باشد. این پارامتر برای کاربر دارای رمز همیشه لازم است.

کاربر محصور دارای رمز

USE AdventureWorks2012;
    GO
    CREATE USER SherryS
    WITH PASSWORD='3e4w3cREs$mE_uk'
        , DEFAULT_LANGUAGE=[English]
        , DEFAULT_SCHEMA=[dbo]
    GO

کاربر محصور برای Login دامنه

USE AdventureWorks2012;
    GO
    CREATE USER [Prototype\Kyanna] ;
    GO

برای تبدیل کاربر موجود از Login احراز هویت SQL Server به کاربر محصور دارای رمز می‌توان از Procedure زیر استفاده کرد:

sp_migrate_user_to_contained
    @username = N'<User Name>',
    @rename = N'keep_name',
    @disablelogin = N'do_not_disable_login' ;
    Go

نگرانی‌های امنیتی

کاربری با مجوز ALTER ANY USER می‌تواند بدون اطلاع مدیر، کاربران محصور ایجاد و مجوزدهی کند. همچنین کاربر محصور ممکن است به پایگاه‌داده‌های دیگری که Guest در آن‌ها فعال است دسترسی یابد.

ساخت Loginهای تکراری می‌تواند حملهٔ Denial-of-service ایجاد کند. اگر کاربر محصور دارای رمز با همان نام SQL Server Login ساخته شود و Login اصلی با Initial Catalog همان پایگاه‌داده متصل شود، ممکن است نتواند اتصال برقرار کند. بهتر است تا حد امکان Windows Authentication استفاده شود، زیرا از Kerberos و سیاست‌های رمز قوی Windows بهره می‌برد.

سایر بهبودهای امنیتی

تغییرات رمزنگاری

• AES: استانداردی که جایگزین DES شده و برای حفاظت از Service Master Key و Database Master Key استفاده می‌شود.
• طول کلید گواهی: بیشینهٔ طول کلید خصوصی واردشده از منبع خارجی از ۳۴۵۶ به ۴۰۹۶ بیت افزایش یافته است.
• الگوریتم‌های Hash: تابع HASHBYTES اکنون SHA2_256 و SHA2_512 را پشتیبانی می‌کند؛ SHA-2 خانواده‌ای از توابع Hash رمزنگاری توسعه‌یافته توسط NSA است.
• پشتیبانی Binary: با گزینهٔ FROM BINARY در CREATE CERTIFICATE می‌توان گواهی را از توصیف Binary گواهی ASN ایجاد کرد.

یکپارچگی عمیق با SharePoint و Active Directory

SharePoint و SQL Server برای بهره‌وری کسب‌وکار، هوش تجاری و گزارش‌ها به‌طور عمیق یکپارچه‌اند. ماژول‌های امنیتی جدید SharePoint و Active Directory، گزارش‌های کاربر نهایی منتشرشده در SharePoint را بهتر محافظت می‌کنند.

مدل‌های امنیتی بهبودیافته کنترل در سطح ردیف و ستون را فراهم می‌کنند و به سازمان‌ها اجازه می‌دهند:

• سیاست رمز عبور را اعمال کنند.
• از نقش‌ها و Proxy Accountها استفاده کنند.
• دسترسی امن‌تر به Metadata فراهم کنند.
• ویژگی‌های امنیت را با Execution Context تقویت کنند.

بهبودهای Provisioning

• BUILTIN\administrators و Local System یا NT AUTHORITY\SYSTEM دیگر خودکار عضو نقش ثابت sysadmin نمی‌شوند؛ مدیر محلی در Single-user Mode همچنان دسترسی دارد.
• SQL Server هنگام نصب روی Windows 7 یا Windows Server 2008 R2 از Managed Service Account و Virtual Account پشتیبانی می‌کند.
• حفاظت سرویس‌های سیستم‌عامل با SID اختصاصی هر سرویس اکنون به همهٔ سیستم‌عامل‌ها گسترش یافته است.

مجوزهای جدید

• مجوزهای جدید GRANT، REVOKE و DENY برای SEARCH PROPERTY LIST.
• مجوزهای جدید برای CREATE SERVER ROLE و ALTER ANY SERVER ROLE.