ڈومین اعتماد کے بغیر Excel سے پارٹنر کے SQL Server تک

کسی دوسرے ادارے کے SQL Server پر جدول کھولنے والی Excel ورک بک کو تین چیزیں درکار ہوتی ہیں جنہیں عام طور پر ایک ہی سمجھا جاتا ہے: وہ شناخت جو سرور قبول کرے، وہ منتقلی جس کی تصدیق کلائنٹ کرے، اور وہ نیٹ ورک راستہ جس کی دونوں فریق اجازت دیں۔ ڈومین اعتماد پہلی چیز پوری کرنے کا ایک طریقہ ہے، اور سب سے وسیع۔ TLS دوسری کو پورا کرتا ہے اور پہلی کے بارے میں کچھ نہیں کہتا۔ راستہ تیسری کو پورا کرتا ہے اور بذات خود کچھ محفوظ نہیں کرتا۔

ان تینوں کو الگ کرنا اسپریڈشیٹ کو انتظامی تعلق کے بجائے ایک چھوٹی، قابل جائزہ درخواست بنا دیتا ہے۔

وہ تین فیصلے جو سوال چھپاتا ہے

شناخت وہ ہے جو ڈیٹا بیس سمجھتا ہے کہ آپ کون ہیں: قابل اعتماد ڈومین کا Windows اکاؤنٹ، اپنے پاس ورڈ والا SQL لاگ اِن، یا سرٹیفکیٹ پر مبنی شناخت۔ منتقلی یہ ہے کہ سیشن خفیہ کردہ ہے یا نہیں اور کلائنٹ سرور کی سرٹیفکیٹ زنجیر جانچتا ہے یا نہیں۔ راستہ یہ ہے کہ پیکٹ سننے والے تک کیسے پہنچتے ہیں؛ یہ VPN، نجی لنک یا فائر وال قواعد والا عوامی اختتامی نقطہ ہو سکتا ہے۔ ہر ایک الگ جگہ رہتا ہے اور ہر ایک خود سے ناکام ہو سکتا ہے۔

جنگل کا اعتماد پہلی چیز کا وسیع جواب دیتا ہے اور یہ ایک ورک بک کی ترتیب نہیں بلکہ اداروں کے درمیان تعلق ہے۔ یہ کچھ خفیہ بھی نہیں کرتا، جو ان لوگوں کو حیران کرتا ہے جنہوں نے سمجھا تھا کہ اعتماد ہی حفاظتی کنٹرول ہے۔

جنگل کے اعتماد کے بغیر شناخت

ہدف ماحول میں جان بوجھ کر تیار کیا گیا اکاؤنٹ کسی بھی اعتماد کے بغیر تنگ ضرورت پوری کر سکتا ہے، بشرطیکہ کلائنٹ کا ورک فلو اسے استعمال کر سکے۔ SQL توثیق دوسرا عام جواب ہے جب پالیسی اجازت دے: لاگ اِن اپنا الگ اسناد کا لائف سائیکل رکھتا ہے اور ڈومینز میں شامل نہیں ہوتا اور Windows یکجا توثیق پیدا نہیں کرتا۔ سرٹیفکیٹ یا ٹوکن پر مبنی شناخت نئے پلیٹ فارمز پر تیسرا آپشن ہے۔ آپ جو بھی منتخب کریں، صرف وہی ڈیٹا بیس اجازتیں دیں جن کی ورک بک کو واقعی ضرورت ہے۔

کسی کی ذاتی لاگ اِن کے بجائے مخصوص اکاؤنٹ کو ترجیح دیں۔ اسپریڈشیٹ میں مشترکہ اسناد ایک سپورٹ مسئلہ ہے جو ہونے کا انتظار کر رہا ہے، اور نام والا اکاؤنٹ منصوبہ ختم ہونے پر منسوخی کو ممکن بناتا ہے۔

خفیہ کاری ہاں، لیکن سرٹیفکیٹ پر اعتماد؟

ODBC Driver 18 کے ساتھ، Encrypt=Yes;TrustServerCertificate=No ایسا خفیہ کردہ سیشن مانگتا ہے جس کا سرٹیفکیٹ واقعی جانچا جاتا ہے۔ پھر کنکشن سٹرنگ کو وہ سرور بتانا ہوگا جسے سرٹیفکیٹ ڈھکتا ہے، اور کلائنٹ کو اس کی زنجیر پر اعتماد کرنا ہوگا۔ Driver 18 پچھلے ورژنز کے برعکس بطور ڈیفالٹ بھی خفیہ کاری کرتا ہے، اس لیے پرانی کنکشن سٹرنگ اب بتائے بغیر TLS پر بات چیت کر سکتی ہے۔ واضح ترتیبات مطلوبہ پالیسی کو تمام مشینوں پر نظر آنے والی بناتی ہیں، جو اس وقت اہم ہے جب کئی لوگ ایک ہی ورک بک کو برقرار رکھیں۔

TrustServerCertificate=Yes خفیہ کرتا ہے اور تصدیق چھوڑ دیتا ہے، جو نام کے عدم توازن یا غیر قابل اعتماد زنجیر کے لیے برابر کا ازالہ نہیں ہے۔ یہ وہ اشارہ ہٹا دیتا ہے جو آپ کو بتاتا کہ کلائنٹ غلط اختتامی نقطے پر پہنچا، اس لیے سرٹیفکیٹ یا نام درست کریں۔

سرور کی جانب نفاذ ایک الگ کنٹرول ہے۔ اگر خفیہ کاری ہر کلائنٹ پر لاگو ہونی چاہیے، تو سرور کی جبری خفیہ کاری کی ترتیب کو ترتیب دیں اور تصدیق کریں، کیونکہ ایک تعاون کرنے والی کنکشن سٹرنگ کچھ نافذ نہیں کرتی۔

نیٹ ورک راستہ ہی حفاظت نہیں

VPN کے ذریعے پہنچنے والا نجی سننے والا نمائش کم کرتا ہے، اور یہ کام کرنے کے لیے VPN کو درست منزل اور واپسی کے راستے لے جانے ہوں گے۔ کام کرنے والی سرنگ توثیق کی ضرورت یا سرٹیفکیٹ کی تصدیق کو ختم نہیں کرتی، اور TLS یہ محدود نہیں کرتا کہ کون سے دور دراز نظام کنکشن کی کوشش کر سکتے ہیں۔ یہ تین الگ مشاہدے ہیں: TLS مصافحہ، VPN لاگ اِن اور مجاز استفسار۔ صرف تیسرا ثابت کرتا ہے کہ ورک بک نے وہ ڈیٹا پڑھا جسے پڑھنے کی اجازت تھی۔

لہٰذا ڈیٹا بیس کو انٹرنیٹ پر بے نقاب کر کے اعتماد کے سوال کا جواب دینے کے شارٹ کٹ کی مزاحمت کریں۔ تنگ جواب عام طور پر مخصوص اکاؤنٹ، تصدیق شدہ خفیہ کاری اور ایک منظور شدہ راستہ ہوتا ہے، اسی ترتیب میں۔

عام Excel ورک فلو سے تصدیق کریں: قبول شدہ شناخت، مؤثر اجازتیں اور طے شدہ خفیہ کاری، ہر ایک سرور کے اپنے سیشن منظر کے ذریعے۔