תקן שגיאת הצפנה של SQL Server - פתרון בלחיצה אחת

קרא את השגיאה - זוהי בעיית אמון, לא בעיית רשת

הרשת שלך בסדר והשרת פועל. החיבור הגיע ל-SQL Server, השרת הציע ערוץ מוצפן לכניסה, והמחשב שלך סירב לכך כי האישור המוכיח את זהות השרת חתום על ידי אף אחד שהמחשב שלך סומך עליו. השגיאה המלאה ש-SSMS מציג היא:

כברירת מחדל, SQL Server מגן על ההתחברות באמצעות אישור בחתימה עצמית שהוא יוצר בעצמו. אישור בחתימה עצמית אמנם מצפין את התעבורה, אבל הוא לא יכול להוכיח שהשרת הוא באמת השרת שלך, ולכן לקוחות שדורשים הצפנה מאומתת דוחים אותו. כל תיקון כנה הוא אחד משני דברים: לגרום ללקוח לקבל את השרת המסוים הזה ביודעין (שלבים 2 ו-3), או לתת לשרת אישור שלקוחות סומכים עליו בעצמם (שלב 4).

תיקון הלקוח המהיר ב-SSMS - תעודת שרת אמון

זהו המסלול המהיר המוצג בסרטון. זה לא משנה דבר בשרת; הוא אומר לחיבור האחד הזה לקבל את האישור של השרת מבלי לבדוק מי חתם עליו. בחלון SSMS התחבר לשרת, לחץ על אפשרויות כדי לפתוח את הכרטיסיות הנוספות, עבור אל הכרטיסייה מאפייני חיבור, הגדר את ההצפנה ל-חובה (או השאר אותה כמוצעת), סמן את אישור שרת אמון ולחץ על התחבר. ההתחברות עוברת מיד.

אותו תיקון בתוך מחרוזת חיבור לאפליקציה

אם יישום נכשל במקום SSMS, אותו מתג חי במחרוזת החיבור שלו. הוסף את שתי ההגדרות במפורש - Encrypt=True מפעיל את הערוץ המוגן, וTrustServerCertificate=True הוא האיות של מחרוזת החיבור של תיבת הסימון SSMS:

Server=SQL01;Database=AppDB;User Id=appuser;Password=YourPassword;Encrypt=True;TrustServerCertificate=True;

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

התיקון הנכון - תן לשרת אישור אמיתי

התיקון הקבוע מתרחש פעם אחת, בשרת, ולאחר מכן כל לקוח מתחבר בקפדנות ללא תיבת סימון וללא אזהרה. תחילה קבל אישור עבור שם ה-DNS המלא של השרת (לדוגמה sql01.company.local) מרשות האישורים הפנימית שלך או רשות אישורים ציבורית, עם שימוש באימות שרת. ייבא אותו, עם המפתח הפרטי שלו, למאגר האישורים של מחשב מקומי במחשב SQL Server. לאחר מכן לחץ באמצעות לחצן העכבר הימני על האישור, בחר כל המשימות ← ניהול מפתחות פרטיים, והענק לחשבון שירות SQL Server הרשאת קריאה על המפתח הפרטי. פתח את מנהל תצורת שרת SQL, הרחב את תצורת רשת שרת SQL, לחץ באמצעות לחצן העכבר הימני על פרוטוקולים עבור MSSQLSERVER, בחר מאפיינים ובחר את האישור בכרטיסייה אישור. בכרטיסייה דגלים תוכל גם להגדיר את ForceEncryption ל-כן כך שכל לקוח נדרש להצפין. הפעל מחדש את שירות SQL Server - השינוי לא עושה כלום עד שאתה עושה זאת.

אמת את ה-Fix the Strict Way

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

SELECT session_id, encrypt_option, auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SPID;

encrypt_option המציג את TRUE הוא ציון העובר. FALSE עם כניסה עובדת פירושו שהחיבור הצליח על ידי ביטול ההגנה, והעבודה לא בוצעה. מבחן המעבר הזה הוא קו הסיום האמיתי: כל לקוח מוגדר כהלכה, כולל גרסאות SSMS עתידיות, מתחבר כעת עם אימות מלא וללא הגדרות מיוחדות.