T-SQL سه شنبه شماره 69: محدودیت های همیشه رمزگذاری شده

رویداد سه شنبه T-SQL این ماه توسط Ken Wilson (@_KenWilson) میزبانی می شود و موضوع رمزگذاری است. من کمی با SQL Server 2016 بازی کردم، بنابراین فکر کردم در مورد یک ویژگی جدید در آنجا صحبت کنم، Always Encrypted. مواد زیادی وجود دارد که در آن ستایش می کنند (و به حق). تصمیم گرفتم روی محدودیت ها تمرکز کنم، تا بتوانید درک کنید که در اجرای فعلی این ویژگی به چه چیزی ملزم هستید.

توجه داشته باشید که این مشاهدات بیشتر از تجربه ساخت CTP 2. 2 گرفته شده است و هر چیزی در اینجا ممکن است تغییر کند.

زمینه

به عنوان یک آغازگر، Always Encrypted از دو طریق عمده با رمزگذاری داده های شفاف (TDE) متفاوت است:

• شما به جای کل پایگاه داده، در سطح ستون رمزگذاری می کنید.
• داده ها هم در حالت استراحت و هم در حافظه رمزگذاری می شوند (رمزگشایی توسط درایور مشتری انجام می شود)، به این معنی که می توانید داده ها را هم در برابر مدیران مخرب و هم از حملات انسان در وسط محافظت کنید.(TDE فقط داده ها را در حالت استراحت رمزگذاری می کند.)

دو سبک رمزگذاری وجود دارد: قطعی و تصادفی. Deterministic هر بار همان مقدار رمزگذاری شده را به شما می دهد، در حالی که تصادفی سازی هر بار - حداقل از نظر تئوری - به یک مقدار متفاوت می رسد (هیچ تضمینی در مورد منحصربه فرد بودن جهانی یا چیزی شبیه به آن وجود ندارد). قطعی بهترین استفاده برای ستون هایی است که احتمالاً در آنها جستجو یا جستجوی نقطه انجام می دهید، مانند LastName شاید (شبه کد: WHERE LastName = ). تصادفی سازی امن تر است، اما باید فقط برای ستون هایی استفاده شود که فقط نمایش داده می شوند، مانند حقوق و دستمزد - من به دنبال همه افرادی که در جدول کارمندان هستند که دقیقاً 84500 دلار درآمد دارند (و اگر حقوق را رمزگذاری کنیم، نمی گردم). بدانید که ما نیز کوئری های محدوده را انجام نمی دهیم).

خوب، در حال حاضر با محدودیت ها.

الگوریتم های رمزگذاری

در حال حاضر فقط یک گزینه الگوریتم پشتیبانی می شود و مطمئناً یک گزینه است: AEAD_AES_256_CBC_HMAC_SHA_256. این چیزی نیست که من هرگز به خاطر بسپارم، و هنگام آزمایش این ویژگی، به سرعت به بالای لیست کلیپ بورد من رسید.

ستون ها / انواع داده ها

ستون های رشته ای که با رمزگذاری قطعی رمزگذاری شده اند، باید از یک ترکیب _BIN2 (مثلا Latin1_General_BIN2) استفاده کنند.

طبق اسناد، انواع داده های زیر به عنوان ستون های رمزگذاری شده *پشتیبانی نمی شوند:

• متن / متن / تصویر
• XML/hierarchyid/geography/geometry
• انواع مستعار / انواع داده های تعریف شده توسط کاربر
• SQL_VARIANT
• rowversion (مهر زمانی)

این موارد اضافی پشتیبانی نمی شوند، اما در اسناد فهرست نشده اند:

• مجموعه ستون های پراکنده (ستون های پراکنده مشکلی ندارند، تا زمانی که جدول شامل مجموعه ستونی نباشد)

  سایر محدودیت های مرتبط با ویژگی

  در حال حاضر، چندین ویژگی با Always Encrypted به خوبی اجرا نمی شوند. اینها مواردی هستند که من پیدا کردم، اما مطمئن نیستم که آیا این محدودیت ها به دلیل مراحل اولیه CTP ها، مرحله v1 ویژگی هستند یا اینکه محدودیت های دائمی خواهند بود.

  • جداول موقت - در حالی که می توانید ستون های زمانی را به یک جدول با ستون های رمزگذاری شده اضافه کنید، به محض اینکه سعی می کنید نسخه سازی سیستم را روشن کنید، یک پیام خطا دریافت می کنید:

    و اگر سعی کنید یک ستون رمزگذاری شده را به جدولی اضافه کنید که از قبل نسخه سیستم در آن وجود دارد:

    • جستجوی متن کامل پشتیبانی نمی شود. اگر بخواهید یک فهرست کامل متن ایجاد کنید، با خطایی مانند زیر مواجه خواهید شد:

      ستون 'col' نمی تواند برای جستجوی متن کامل استفاده شود زیرا یک ستون مبتنی بر کاراکتر، XML، تصویر یا varbinary (max) نیست یا رمزگذاری شده است.(Microsoft SQL Server، خطا: 7670)

      • (از طرف دیگر، Change Tracking با Always Encrypted به خوبی کار می کند. من معتقدم این به این دلیل است که فقط مقادیر کلیدی ثبت می شوند، بنابراین طبق تعریف تاریخچه هرگز نمی تواند شامل ستون های رمزگذاری شده باشد.)

      عملیات

      ستون هایی که از رمزگذاری قطعی استفاده می کنند، از مقایسه برابری WHERE و همچنین DISTINCT، JOIN و GROUP BY پشتیبانی می کنند. شما نمی توانید نابرابری، محدوده، یا پرس و جوهای LIKE یا هر عملیات دیگری را در برابر ستون های رمزگذاری شده (عملیات حسابی، تاریخ/زمان، و غیره) انجام دهید:

      شاخص ها / محدودیت ها

      شما نمی توانید یک فهرست یا محدودیت در ستونی ایجاد کنید که از رمزگذاری تصادفی استفاده می کند:

      و کلیدهای خارجی باید با انواع رمزگذاری مطابقت داشته باشند:

      کد مشتری

      کتابخانه های مشتری باید برای پشتیبانی از رمزگذاری و رمزگشایی ستون ها و پارامترها به روز شوند. همه درایورها از این عملکرد پشتیبانی نمی کنند و برخی ممکن است هرگز. در حال حاضر تنها فناوری که از این پشتیبانی می کند .net 4. 6 است. به روزرسانی های ODBC و JDBC باید به زودی ارائه شوند.

      رشته اتصال باید با ویژگی اضافی زیر به روز شود:

      خود استودیو مدیریت از هر مشتری می خواهد که یک کپی از کلید رمزگذاری ستون یا دسترسی مستقیم به آن داشته باشد. من در یک پست آینده به سناریوی مفصل تری خواهم پرداخت، اما در حال حاضر می توانید فرض کنید که باید به کاربران برنامه (از جمله SSMS) توانایی دیدن ابرداده کلید اصلی/ستونی را با کد زیر اعطا کنید:

      تا زمانی که تنظیمات رمزگذاری ستون به عنوان یک پارامتر اتصال اضافی اضافه شود ، کاربران SSMS قادر خواهند بود مقادیر رمزگشایی شده را در نتیجه یک پرس و جو مشاهده کنند. اما آنها نمی توانند پارامترهایی را به یک روش ذخیره شده منتقل کنند که مقادیر رمزگذاری شده را درج یا به روزرسانی می کند ، زیرا - بر خلاف یک برنامه ، که رمزگذاری را انجام می دهد - بین اعلام پارامترها و انتقال آنها به روش ذخیره شده ، هیچ سفر دور وجود ندارد. نتیجه:

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

      برای برنامه های مشتری در دستگاه های غیر از جایی که SQL Server 2016 نصب شده است ، آنها به یک نسخه به روز شده از .net Framework (در ویندوز 10 لازم نیست یا اگر Visual Studio 2015 لازم نیست) و گواهی نصب شده (همانطور که در اینجا شرح می دهم ، نیاز دارند.). اگر چارچوب به اندازه کافی مدرن نباشد ، تنظیم رشته اتصال به سادگی کار نمی کند (اگرچه من پیام خطای دقیق را تأیید نکرده ام زیرا تمام VM های من SQL Server 2016 Windows 10 هستند). اگر گواهی مورد استفاده برای کلیدها در آنجا نباشد ، بسته به نوع کلیدهایی که در سرور پایگاه داده ایجاد کرده اید ، برنامه با خطاهایی مانند این خراب می شود:

      (این می داند که کجا می توانید آن گواهی را در دستگاه محلی جستجو کنید زیرا این ابرداده را از SQL Server دریافت می کند. برای برخی از اطلاعات دیگر در مورد کلیدهای اصلی/ستون و به ویژه در مورد چرخش کلید ، به این پست وبلاگ امنیتی SQL Server مراجعه کنید.)

      پارامترهای رمزگذاری شده باید به عنوان پارامترهای تایپ شده به درستی منتقل شوند. این نوع ad hoc sql شکسته می شود ، حتی اگر از برنامه C# 4. 6 شما با تنظیم رمزگذاری ستون مناسب در رشته اتصال منتقل شود:

      برای انجام هر یک از عملیات پشتیبانی شده در برابر ستون های رمزگذاری شده ، باید از SQLCommand و SQLParameter استفاده کنید.

      سرانجام ، سربار اضافی لازم برای مذاکره در مورد دست های رمزگذاری وجود دارد ، بنابراین اگر برنامه شما واقعاً چرب است ، مطمئناً می خواهید عملکرد شبکه خود را پایه گذاری کنید و پس از رمزگذاری ستون های خود مقایسه کنید. همچنین این نکته وجود دارد که داده های رمزگذاری شده می توانند فضای بیشتری را نسبت به معادل رمزگذاری نشده خود ، چه از فشرده سازی استفاده کنید یا خیر ، به خود اختصاص دهند. من به عنوان یک همراه با این پست ، نگاهی به این دو تأثیر در یک پست جداگانه در SQLPerformance.com انداختم.

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

      با وجود همه نقض داده های این روزها ، من کاملاً خوشحالم که پیشرفت هایی در محافظت از داده ها وجود دارد. اما درک محدودیت ها قبل از پرش به آن می تواند یک تمرین یادگیری ارزشمند باشد. من تکرار می کنم ، زیرا به اندازه کافی نمی توان تأکید کرد ، که این محدودیت هایی است که من در ساخت های فعلی امروز مشاهده می کنم و وضعیت هر یک از این موضوعات می تواند در هر زمان تغییر کند. من همچنین اعتراف می کنم که این لزوماً از نظر ویژگی ها یک لیست جامع نیست. فقط آنهایی که فکر می کردم واضح ترین آنها را بررسی کنم.

      برای پست های بیشتر در مورد رمزگذاری و سرور SQL ، برچسب هش #TSQL2SDay و پست کن را دنبال کنید.

      

      هارون برتراند

      Aaron (Aaronbertrand) یک پلت فرم داده MVP با تجربه صنعت است که قدمت آن به ASP Classic و SQL Server 6. 5 باز می گردد. او سردبیر وبلاگ مربوط به عملکرد ، sqlperformance.com است. وبلاگ هارون بر روی عادات بد T-SQL و بهترین شیوه ها و همچنین پوشش به روزرسانی ها و ویژگی های جدید در Plan Explorer ، Sentryone و SQL Server تمرکز دارد.< Span> با تمام نقض داده های این روزها ، من کاملاً خوشحالم که پیشرفت هایی در محافظت از داده ها وجود دارد. اما درک محدودیت ها قبل از پرش به آن می تواند یک تمرین یادگیری ارزشمند باشد. من تکرار می کنم ، زیرا به اندازه کافی نمی توان تأکید کرد ، که این محدودیت هایی است که من در ساخت های فعلی امروز مشاهده می کنم و وضعیت هر یک از این موضوعات می تواند در هر زمان تغییر کند. من همچنین اعتراف می کنم که این لزوماً از نظر ویژگی ها یک لیست جامع نیست. فقط آنهایی که فکر می کردم واضح ترین آنها را بررسی کنم.