ڈیزائن کے لحاظ سے محفوظ: کوڈ لکھنے سے پہلے اپنے فن تعمیر میں سیکیورٹی کو کیسے انجینئر کریں۔

زیادہ تر انجینئرنگ ٹیموں میں، بات چیت ہوتی ہے، لیکن اکثر بہت دیر ہو جاتی ہے۔

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

کمزوریاں حقیقی ہیں۔ اسے ٹھیک کرنا مہنگا ہے۔ اور گفتگو میں، کوئی کہتا ہے، "ہمیں اس میں سیکورٹی شامل کرنے کی ضرورت ہے۔”

یہی مسئلہ ہے۔ سیکیورٹی ایسی چیز نہیں ہے جسے آپ سافٹ ویئر میں شامل کرتے ہیں۔ یہ ایسی چیز ہے جسے آپ شروع سے اس میں بناتے ہیں۔ جس لمحے آپ پہلے سے موجود کسی چیز میں سیکیورٹی شامل کرنے کی بات کرتے ہیں، آپ پہلے سے ہی نقصان پر قابو پانے کے موڈ میں ہوتے ہیں۔

Secure by Design سوچ کا ایک بالکل مختلف طریقہ ہے جو تعمیراتی فیصلے کرنے سے پہلے حفاظتی تقاضوں کی وضاحت کرتا ہے۔ ایک کلاس لکھنے سے پہلے اپنے خطرے کے ماڈل کو سمجھیں۔ ڈومین پرت پر کاروباری قواعد کی شناخت اور ان کو نافذ کریں۔ یہ سب اس فعالیت کے ساتھ آتے ہیں جو انجینئرنگ کو پیش کرنا ہوتی ہے، بجائے اس کے کہ صرف ایک پرت جو پہلے سے بنی ہوئی چیزوں کی تکمیل کرتی ہو۔

CI/CD پائپ لائنیں اس چیز کو پکڑتی ہیں جو انسانی جائزے سے محروم رہتی ہیں۔ سسٹم کی ہر پرت کو حملہ آور کے نقطہ نظر کو ذہن میں رکھ کر ڈیزائن کیا گیا ہے، سوچنے کے بعد نہیں بلکہ ایک بنیادی ضرورت کے طور پر۔

یہ سیکورٹی ٹیم کی ذمہ داری نہیں ہے۔ یہ انجینئرنگ ٹیم کی ذمہ داری ہے۔ اور یہ پہلی پل کی درخواست سے پہلے شروع ہوتا ہے۔

یہ ہینڈ بک آپ کو ہر اس چیز کے بارے میں رہنمائی کرے گی جس کی آپ کو یہ سمجھنے کی ضرورت ہے کہ انجینئرنگ ٹیمیں ڈیزائن کرتے وقت کس طرح حفاظتی ذہن رکھنے والے اصولوں کو فروغ دے سکتی ہیں۔

انڈیکس

شرطیں

اس مضمون کو پڑھنے سے پہلے، آپ کو درج ذیل سے واقف ہونا چاہیے:

• کسی بھی زبان یا فریم ورک میں APIs اور بیک اینڈ سسٹم بنائیں

• عام سافٹ ویئر آرکیٹیکچر کے تصورات: پرتیں، خدمات، گیٹ ویز

• CI/CD پائپ لائن کیا ہے اور یہ اعلیٰ سطح پر کیسے کام کرتی ہے۔

• انکرپشن اور ہیشنگ کا کیا مطلب ہے اس کی بنیادی سمجھ

سیکیورٹی کے پس منظر کی ضرورت نہیں ہے۔ یہ مضمون انجینئرنگ اور فن تعمیر کے نقطہ نظر سے تمام تصورات تک پہنچتا ہے۔

Secure by Design کا اصل مطلب کیا ہے۔

ڈیزائن کے لحاظ سے محفوظ ایک چیک لسٹ نہیں ہے۔ یہ انسٹال کرنے کے لیے ٹولز کا سیٹ نہیں ہے۔ یہ سافٹ ویئر کے بارے میں سوچنے کا ایک طریقہ ہے جو سیکیورٹی کی ضروریات کو اسی طرح پورا کرتا ہے جس طرح یہ فنکشنل ضروریات کو پورا کرتا ہے۔ آپریشن کا یہ طریقہ حفاظتی تقاضوں کو آئٹمز کے طور پر مانتا ہے جو سسٹم کو مکمل تصور کیے جانے سے پہلے پورا کرنا ضروری ہے۔

زیادہ تر ٹیمیں سیکیورٹی کو غیر فعال طریقے سے سنبھالتی ہیں۔ کچھ ٹوٹ جاتا ہے، کچھ جھنڈا لگ جاتا ہے، کچھ پیوند لگ جاتا ہے۔ سائیکل دہرایا جاتا ہے۔ سسٹمز تکنیکی تحفظ کا قرض اسی طرح جمع کرتے ہیں جس طرح وہ دوسرے تکنیکی قرضوں کو جمع کرتے ہیں۔ تاہم، آپ اعلی داؤ استعمال کر سکتے ہیں.

Secure by Design ٹیم فعال طور پر سیکورٹی کو ایڈریس کرتی ہے۔ فیچر بنانے سے پہلے، انجینئرنگ ٹیمیں درج ذیل سوالات پوچھتی ہیں: اس فیچر کو کیا خطرات ہیں؟ آپ کا ڈیٹا کہاں حساس ہے؟ اگر کوئی حملہ آور اس ان پٹ کو کنٹرول کر لے تو کیا ہوتا ہے؟ اگر اس جزو کو نقصان پہنچے تو دھماکے کا رداس کیا ہے؟ جوابات فن تعمیر کو شکل دیتے ہیں، دوسری طرف نہیں۔

یہ ایک بنیادی طور پر مختلف نظام بناتا ہے۔ یہ اس لیے نہیں ہے کہ انفرادی اجزاء مختلف ہوتے ہیں، بلکہ اس لیے کہ ہر پرت پر ڈیزائن کے فیصلے اس بات کی سمجھ کی عکاسی کرتے ہیں کہ کیا غلط ہو سکتا ہے۔

یہاں ایک کامل مثال ہے:
API گیٹ وے غلط استعمال کے لیے اپنے ڈیزائن کی وجہ سے طے شدہ طور پر شرح کو محدود کرتا ہے۔
ڈومین پرت اس ڈیزائن میں شناخت کر کے کاروباری قواعد کو نافذ کرتی ہے جہاں وہ اصول ہیں۔
CI/CD پائپ لائنز آپ کے کوڈ میں راز کو پکڑتی ہیں کیونکہ ڈیزائن میں شروع سے ہی وہ دروازے شامل ہوتے ہیں۔ وغیرہ

ڈیزائن کے وقت پر سیکیورٹی حاصل کرنے کی لاگت اس میں ترمیم یا برقرار رکھنے کی لاگت کا صرف ایک حصہ ہے۔ اور اس کے انتظام کی لاگت کسی بڑے حادثے کی لاگت کا صرف ایک حصہ ہے۔ یہ صرف وقت کی بات ہے!

تھریٹ ماڈلنگ: تعیناتی سے پہلے حملے کی سطح کو سمجھیں۔

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

مقصد آسان ہے۔ یہ اس بات کو سمجھنے کے بارے میں ہے کہ کون سسٹم پر حملہ کر سکتا ہے، وہ کیا چاہتے ہیں، وہ اسے حاصل کرنے کے لیے کیسے کام کریں گے، اور اگر وہ کامیاب ہو جاتے ہیں تو اس کا کیا اثر پڑے گا۔ اس تفہیم کے ساتھ، آپ سوچ سمجھ کر ڈیزائن کے فیصلے کر سکتے ہیں جو اس طرح کے حملوں کے امکانات اور اثرات کو کم کرتے ہیں۔

تھریٹ ماڈلنگ میں چار سوالات

1. ہم کیا بنا رہے ہیں؟

استعمال کا یہ خاص معاملہ سسٹم میپنگ سے شروع ہوتا ہے۔ اجزاء کیا ہیں؟ وہ کیسے بات چیت کرتے ہیں؟ ڈیٹا کہاں بہہ جاتا ہے؟ اعتماد کی حدیں کہاں ہیں – وہ پوائنٹس جہاں ڈیٹا ایک اعتماد کے سیاق و سباق سے دوسرے میں جاتا ہے؟

API گیٹ وے اور انٹرنیٹ کے درمیان، سروس لیئر اور ڈیٹا بیس کے درمیان، اور سسٹم اور تھرڈ پارٹی انضمام کے درمیان اعتماد کی حدود موجود ہیں۔ ہر اعتماد کی حد ممکنہ حملے کی سطح ہے۔

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

2. کیا غلط ہو سکتا ہے؟

استعمال کا یہ کیس ہر ایک جز اور ہر ڈیٹا کے بہاؤ سے پوچھتا ہے کہ حملہ آور کیا کر سکتا ہے۔ یہاں یہ آتا ہے آگے بڑھنا یہ ان سوالات کے لیے شارٹ ہینڈ ہے جو استعمال کے اس مخصوص معاملے کو پورا کرنے میں آپ کی مدد کرے گا۔

• سپوفنگ: کیا حملہ آور کسی ایسے شخص کا دکھاوا کر سکتا ہے جو وہ نہیں ہے؟ کیا آپ ٹوکن بنا سکتے ہیں، کسی صارف کی نقالی کر سکتے ہیں، یا ایسی شناخت کا دعویٰ کر سکتے ہیں جس کے آپ مالک نہیں ہیں؟

• آپریشن: کیا حملہ آور ٹرانزٹ یا آرام کے وقت ڈیٹا میں ترمیم کر سکتا ہے؟ کیا میں لین دین کی رقم کو تبدیل کر سکتا ہوں، کال بیک پے لوڈ میں ترمیم کر سکتا ہوں، یا محفوظ کردہ ریکارڈ کو تبدیل کر سکتا ہوں؟

• ترک کرنا: کیا صارف کوئی عمل کرنے سے انکار کر سکتا ہے؟ کیا آپ کے پاس یہ ثابت کرنے کے لیے کافی آڈٹ لاگز ہیں کہ کیا ہوا، کب ہوا، اور کس کے ذریعے ہوا؟ کیا آپ یہ ثابت کر سکتے ہیں کہ صارف نے سسٹم پر کوئی کارروائی کی ہے؟

• معلومات کا انکشاف: کیا کوئی حملہ آور کچھ سیکھ سکتا ہے جسے اسے نہیں سیکھنا چاہیے؟ کیا آپ دوسرے صارفین کا ڈیٹا پڑھ سکتے ہیں، خرابی کے جوابات سے اندرونی نظام کی معلومات نکال سکتے ہیں، یا اسٹیک ٹریس سے اندرونی انفراسٹرکچر کی تفصیلات حاصل کر سکتے ہیں؟

• خدمت سے انکار: کیا حملہ آور جائز صارفین کو سسٹم تک رسائی سے روک سکتا ہے؟ کیا یہ آپ کے وسائل کو ختم کر سکتا ہے، مہنگے آپریشنز کا سبب بن سکتا ہے، یا آپ کے سسٹم کو ٹریفک سے مغلوب کر سکتا ہے؟

• مراعات میں اضافہ: کیا کوئی حملہ آور غیر مجاز اجازتیں حاصل کر سکتا ہے؟ کیا باقاعدہ صارفین انتظامی خصوصیات تک رسائی حاصل کر سکتے ہیں؟ یا کیا بیرونی کال کرنے والے اندرونی API تک رسائی حاصل کر سکتے ہیں؟

3. ہم اس کے بارے میں کیا کریں گے؟

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

فیصلے واضح اور دستاویزی ہیں۔ یہ مضمر یا فرض نہیں کیا گیا ہے اور اس کا دستاویزی ہونا ضروری ہے۔

4. کیا ہم نے کافی اچھا کام کیا ہے؟

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

کیا خطرہ ماڈلنگ پیدا کرتا ہے۔

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

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

ایک کاروباری اصول کے طور پر سیکورٹی

ڈومین سے چلنے والا ڈیزائن آپ کو سکھاتا ہے کہ کاروباری منطق آپ کی درخواست کو بناتا یا توڑتا ہے۔ ڈومین پرت وہ ہے جہاں وہ اصول رہتے ہیں جو نظام کی درستگی کی وضاحت کرتے ہیں۔ سیکیورٹی کے تقاضے کاروباری اصول ہیں اور ان کا تعلق دیگر تمام کاروباری اصولوں کے ساتھ ڈومین لیئر میں ہے۔

سیلز ایجنٹ تصدیق شدہ ضمانت کے بغیر فروخت نہیں کر سکتا۔ یہ ایک کاروباری اصول ہے۔ اس کا تعلق اس ڈومین ہستی یا ڈومین سروس سے ہے جو فروخت کو تخلیق کرتا ہے، تخلیق کے وقت نافذ کیا جاتا ہے، اور مندرجہ بالا میں سے کسی بھی تہہ کے ذریعے اس کو روکا نہیں جا سکتا۔

ادائیگیوں کو پروسیسنگ کی حیثیت سے گزرے بغیر زیر التواء سے مکمل نہیں ہونا چاہئے۔ یہ ایک کاروباری اصول ہے۔ یہ ادائیگی کرنے والے ادارے کی ریاستی مشین سے تعلق رکھتی ہے، اسے ہستی کی سطح پر نافذ کیا جاتا ہے، اور اسے API یا انفراسٹرکچر پرت کے ذریعے توڑا نہیں جا سکتا۔

اگر اصل اکاؤنٹ کو دھوکہ دہی کے جائزے کے لیے جھنڈا لگایا گیا ہے، تو آپ کو اکاؤنٹ کی منتقلی کے ساتھ آگے نہیں بڑھنا چاہیے۔ یہ ایک کاروباری اصول اور سیکورٹی کی ضرورت دونوں ہے۔ اس کا تعلق ایک ڈومین سروس سے ہے جو فنڈز منتقل ہونے سے پہلے ہونے والی منتقلی کو مربوط کرتی ہے۔

ایک بار جب حفاظتی تقاضے ڈومین کے کاروباری اصولوں میں انکوڈ ہو جاتے ہیں، تو وہ API کو براہ راست کال کرنے، کسی دوسرے کلائنٹ کا استعمال کرتے ہوئے، یا ORM کے ذریعے ڈیٹا بیس تک رسائی حاصل کرنے سے نہیں روکا جا سکتا۔ جب کوئی ڈومین آبجیکٹ بنتا ہے یا اس کی حالت بدل جاتی ہے تو قواعد لاگو ہوتے ہیں۔ سسٹم کے ذریعے ہر راستہ ڈومین پرت تک پہنچتا ہے۔ ڈومین پرت قوانین کو نافذ کرتی ہے۔

قیمتی اشیاء اس میں مزید اضافہ کرتی ہیں۔ کنفیگریشن کے وقت منی ویلیو آبجیکٹ کی توثیق کرنے کا مطلب ہے کہ ڈومین میں غلط رقم موجود نہیں ہو سکتی۔ اکاؤنٹ نمبر ویلیو آبجیکٹ جو فارمیٹ اور چیک ہندسوں کو چیک کرتا ہے اس کا مطلب ہے کہ غلط فارمیٹ شدہ اکاؤنٹ نمبر سسٹم میں داخل نہیں کیے جا سکتے۔ توثیق کوئی کنٹرولر چیک نہیں ہے جسے چھوڑا جا سکتا ہے۔ یہ خود قسم کی ایک موروثی خاصیت ہے۔

یہ ڈومین کی سطح پر ڈیزائن کے ذریعے محفوظ کرنے کا ایک انجینئرنگ طریقہ کار ہے۔ حفاظتی تقاضوں کو ڈومین کی قسموں اور ڈومین آپریشنز میں رکاوٹوں میں انکوڈ کریں اور ان کو روکنا ناممکن بنائیں۔

خفیہ کاری کے معیارات: تنظیمی فیصلے

زیادہ تر تنظیموں کے لیے، سب سے خطرناک حفاظتی فیصلوں میں سے ایک وہ ہے جو ابھی تک نہیں کیا گیا ہے۔ آپ کی تنظیم کون سے خفیہ کاری کے معیارات استعمال کرتی ہے؟

تنظیمی معیارات کے بغیر، تمام ڈویلپرز اپنے انتخاب خود کرتے ہیں۔ ایک ٹیم AES-128 استعمال کرتی ہے۔ دوسرا CBC موڈ میں AES-256 استعمال کرتا ہے۔ تیسرا GCM موڈ میں AES-256 استعمال کرتا ہے۔ چوتھا اب بھی کسی مقصد کے لیے MD5 استعمال کر رہا ہے۔

ایسا ہونے کا کسی کا ارادہ نہیں تھا۔ ایسا اس لیے ہوا کہ کوئی بھی تنظیمی سطح پر فیصلے نہیں کر رہا تھا اور انہیں نافذ نہیں کر رہا تھا۔

ایڈہاک انکرپشن کے انتخاب سے پیدا ہونے والی کمزوریاں سنگین ہیں اور اکثر ان کا پتہ لگانا مشکل ہوتا ہے۔ پیڈنگ اوریکل حملے خفیہ کاری کے طریقوں اور غلطی سے نمٹنے کے ایک مخصوص امتزاج کو استعمال کرتے ہیں۔ غلط IV جنریشن کے ساتھ CBC موڈ ان حملوں کا خطرہ ہے جو GCM موڈ نہیں ہے۔ کمزور کلیدی لمبائی بروٹ فورس حملوں کے لیے حساس ہو سکتی ہے۔ انکرپشن کی ناکامی کے دوران اسٹیک ٹریس کو ظاہر کرنے سے عمل درآمد کی اندرونی تفصیلات سامنے آتی ہیں جو حملہ آور کے لیے مددگار ثابت ہو سکتی ہیں۔

کوئی بھی تنظیم جو حساس ڈیٹا پر کارروائی کرتی ہے اسے واضح طور پر درج ذیل فیصلے کرنے چاہئیں اور انہیں انجینئرنگ کے معیارات کے طور پر نافذ کرنا ہوں گے۔

1. کون سے ہم آہنگ انکرپشن الگورتھم اور موڈز ہیں؟

Symmetric encryption ڈیٹا کو انکرپٹ اور ڈکرپٹ کرنے کے لیے ایک ہی کلید کا استعمال کرتا ہے۔ یہ تیز اور کارآمد ہے، یہ آرام کے وقت یا ٹرانزٹ میں بڑی مقدار میں ڈیٹا کو خفیہ کرنے کے لیے ایک اچھا انتخاب بناتا ہے۔

AES-256 GCM موڈ کے ساتھ یہ زیادہ تر ایپلی کیشنز کے لیے موجودہ معیار ہے۔ AES کا مطلب ہے ایڈوانسڈ انکرپشن سٹینڈرڈ۔ 256 بٹس میں کلیدی سائز کی نمائندگی کرتا ہے۔ عام طور پر، کلید جتنی لمبی ہوگی، اتنے ہی ممکنہ امتزاج ہوں گے اور بروٹ فورس حملہ اتنا ہی مشکل ہو جائے گا۔

Galois/counter Mode (GCM) تصدیق شدہ خفیہ کاری فراہم کرتا ہے۔ یعنی، یہ ڈیٹا کو انکرپٹ کرتا ہے اور ایک تصدیقی ٹیگ بناتا ہے جو یہ پتہ لگاتا ہے کہ آیا سائفر ٹیکسٹ کے ساتھ چھیڑ چھاڑ کی گئی ہے۔ ایک قدم میں رازداری اور سالمیت کو یقینی بنائیں۔

سائفر بلاک چیننگ (CBC) موڈ اب بھی استعمال کیا جاتا ہے، لیکن ابتدائی ویکٹر (IV) اور میسج توثیقی کوڈ (MAC) کو احتیاط سے سنبھالنے کی ضرورت ہے تاکہ وہی خصوصیات حاصل کی جا سکیں جو GCM مقامی طور پر فراہم کرتا ہے۔ اگر یہ غلط ہو جاتا ہے، تو یہ پیڈنگ اوریکل حملوں کا دروازہ کھولتا ہے، جہاں ایک حملہ آور ڈیٹا کو ڈکرپٹ کر سکتا ہے یا اس کا بغور مشاہدہ کر کے سائفر ٹیکسٹ کو جعلی بنا سکتا ہے۔

2. پاس ورڈز کے لیے ہیشنگ الگورتھم کیا ہے؟

ہیشنگ ایک طرفہ آپریشن ہے۔ ہیش کو اس کی اصل قیمت پر واپس نہیں کیا جا سکتا۔ یہی وجہ ہے کہ ہم پاس ورڈ ہیشز کو پاس ورڈ کے بجائے اسٹور کرتے ہیں۔ جب کوئی صارف لاگ ان ہوتا ہے تو ہم ان کے ان پٹ کو ہیش کرتے ہیں اور اس کا موازنہ ذخیرہ شدہ ہیش سے کرتے ہیں۔

bcrypt، scrypt، اور Argon2 پاس ورڈ ہیشنگ کے لیے موجودہ معیار۔ یہ الگورتھم جان بوجھ کر سست اور کمپیوٹیشنل طور پر مہنگے ہوتے ہیں، جس سے بروٹ فورس حملوں کو ناقابل عمل بنا دیا جاتا ہے یہاں تک کہ اگر کوئی حملہ آور ہیش کا ڈیٹا بیس حاصل کر لے۔

SHA-256 پاس ورڈ ہیشنگ الگورتھم نہیں ہے۔ یہ ایک عام مقصد کا کرپٹوگرافک ہیش فنکشن ہے جو ڈیزائن کے لحاظ سے تیز ہے۔ یہ بالکل وہی ہے جو آپ اپنے پاس ورڈ کے لیے نہیں چاہتے ہیں۔ ایک حملہ آور جدید ہارڈ ویئر پر فی سیکنڈ اربوں SHA-256 ہیشز کی کوشش کر سکتا ہے۔

MD5 حساس اشیاء کے لیے ہیشنگ الگورتھم نہیں ہے۔ چونکہ اسے برسوں پہلے توڑا گیا تھا، اس لیے اسے کبھی بھی سیکیورٹی کے لحاظ سے حساس حالات میں ظاہر نہیں ہونا چاہیے۔ یہ صرف میری رائے نہیں ہے۔ یہ کرپٹوگرافک تحقیق اور حقیقی دنیا کے حملوں کی پیداوار ہے۔

3. دستخط اور کلیدی تبادلے کے لیے غیر متناسب الگورتھم کیا ہیں؟

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

استعمال کریں کم از کم RSA-2048 غیر متناسب کارروائیوں کے لیے۔ استعمال کریں RS256 یا ES256 اعلی سیکورٹی کے تناظر میں JWTs پر دستخط کرنے کے لیے۔ RS256 دستخط کرنے کے لیے SHA-256 کے ساتھ RSA کا استعمال کرتا ہے۔ ES256 P-256 وکر کے ساتھ Elliptic Curve Digital Signature Algorithm (ECDSA) کا استعمال کرتا ہے۔ سیکیورٹی کی مساوی سطحوں کے لیے عام طور پر EC کیز کو RSA پر ترجیح دی جاتی ہے کیونکہ وہ ایک جیسی خفیہ طاقت فراہم کرتے ہوئے چھوٹی چابیاں اور دستخط تیار کرتی ہیں۔

4. ڈیولپرز کو خفیہ کاری کیسے ڈیلیور کی جاتی ہے۔

سب سے اہم فیصلہ یہ ہے کہ پراجیکٹ بہ پروجیکٹ کی بنیاد پر شروع سے خفیہ کاری کو لاگو نہ کیا جائے۔ اسٹاف انجینئرز انکرپشن یوٹیلیٹیز کو اندرونی پیکجز یا کلاؤڈ فنکشنز کے طور پر بناتے ہیں۔ اس کے بعد آپ اسے درآمد کر کے استعمال کر سکتے ہیں۔ آپ کو خود سے کرپٹوگرافک پرائمیٹو نہیں لکھنا چاہیے۔ یہ ماخذ پر عمل درآمد کی ناکامیوں کے پورے زمرے کو ختم کرتا ہے۔

جب خفیہ کاری کے نفاذ کو مرکزی بنایا جاتا ہے، کمزوریوں کو ٹھیک کرنے کا مطلب ہے کہ انہیں ایک جگہ پر ٹھیک کرنا ہے۔ کسی کمزوری کو ٹھیک کرنے کا مطلب ہے کہ جب یہ تمام پروجیکٹس میں پھیل جائے تو سب سے پہلے تمام نفاذ کو تلاش کرنا، جو اکثر ناممکن ہوتا ہے۔

ڈیٹا بیس سیکورٹی

ڈیٹا بیس وہ جگہ ہے جہاں زیادہ تر سسٹمز میں سب سے زیادہ حساس ڈیٹا رہتا ہے۔ یہ پورے اسٹیک میں اکثر غلط کنفیگر کیے جانے والے اجزاء میں سے ایک ہے۔

ایس کیو ایل انجیکشن

ایس کیو ایل انجیکشن لگ بھگ 25 سال سے ہے۔ یہ 1998 سے جاری ہے۔ چونکہ انجینئرنگ کے معیارات نافذ نہیں کیے گئے ہیں، وہ اب بھی پیداواری نظاموں میں ظاہر ہوتے ہیں۔

وجہ ہمیشہ ایک ہی ہوتی ہے: سٹرنگ کنکٹنیشن۔ ڈویلپرز صارف کا ان پٹ لیتے ہیں اور اسے براہ راست SQL سٹرنگز میں جوڑ دیتے ہیں۔ ڈیٹا بیس ڈویلپر کی طرف سے ارادہ کردہ سوالات اور حملہ آور کے ذریعے بنائے گئے سوالات کے درمیان فرق نہیں کر سکتا۔

-- developer intended this
SELECT * FROM users WHERE email="user@example.com"

-- attacker passes: anything@example.com' OR '1'='1
SELECT * FROM users WHERE email="anything@example.com" OR '1'='1'
-- returns every user in the table

حل ہمیشہ پیرامیٹرائزڈ استفسار یا ORM ہوتا ہے۔ استفسار کے ڈھانچے میں ترمیم کی گئی ہے۔ اقدار کو الگ سے منظور کیا جاتا ہے۔ ڈیٹا بیس اس کو ڈیٹا کے طور پر مانتا ہے جو استفسار کے ڈھانچے کا حصہ نہیں ہے۔

آپ کی CI/CD پائپ لائن کے جامد تجزیے کو خام SQL سٹرنگ کنکٹنیشن کو جھنڈا لگانا چاہیے۔ یہ زیرو ٹالرینس کی پالیسی ہے۔ خام SQL سٹرنگز کے ساتھ صارف کے ان پٹ کو مربوط کرنے کی اجازت نہیں ہے اور انہیں کبھی پروڈکشن تک نہیں پہنچنا چاہیے۔

ڈیٹا بیس تک رسائی کے لیے کم سے کم استحقاق کا اصول

ایپلیکیشن کے ڈیٹا بیس کے صارف کے پاس صرف ضروری اجازتیں ہونی چاہئیں اور مزید نہیں۔ صرف پڑھنے کے لیے رپورٹنگ اینڈ پوائنٹس کو صرف SELECT کی اجازت کے ساتھ صارف کے طور پر منسلک ہونا چاہیے۔ کوئی INSERT، UPDATE، یا DELETE نہیں ہونا چاہیے۔ صرف لکھنے والے APIs کو ڈراپ ٹیبل کی اجازت نہیں ہونی چاہیے۔

یہ ایک کامیاب SQL انجیکشن یا کریڈینشل لیک کے دھماکے کے رداس کو محدود کرتا ہے۔ اگر آپ کی ایپلیکیشن صرف مخصوص ٹیبلز پر SELECTs انجام دے سکتی ہے، تو سمجھوتہ شدہ ڈیٹا بیس کی اسناد کے ساتھ حملہ آور صرف ان ٹیبلز پر SELECT انجام دے سکتا ہے۔ آپ ڈیٹا بیس کو حذف نہیں کر سکتے، غلط ریکارڈ داخل نہیں کر سکتے، یا اکاؤنٹ بیلنس کو اپ ڈیٹ نہیں کر سکتے۔

یہ ڈیٹا بیس کی فراہمی کا فیصلہ ہے جو ہر درخواست کے جزو کے لیے واضح طور پر کیا جانا چاہیے اور بنیادی ڈھانچے کی سطح پر نافذ کیا جانا چاہیے۔

تمام ڈیٹا بیس کنکشنز کو انکرپٹ کیا جانا چاہیے۔

ڈیٹا بیس کنکشنز کو TLS کا استعمال کرنا چاہیے۔ ایک غیر خفیہ کردہ ڈیٹا بیس کنکشن سوال کے نتائج کو نیٹ ورک پر واضح متن میں منتقل کرتا ہے۔ ایپلیکیشن اور ڈیٹا بیس کے درمیان کوئی بھی جزو جو نیٹ ورک ٹریفک کا مشاہدہ کر سکتا ہے وہ تمام استفسار کے نتائج کو پڑھ سکتا ہے۔

کلاؤڈ ماحول میں، خدمات اکثر اندرونی نیٹ ورکس پر بات چیت کرتی ہیں جو محفوظ محسوس کرتے ہیں، لیکن نہیں ہیں۔ ڈیٹا بیس کنکشن کو خفیہ کرنا اختیاری نہیں ہے۔

اپنے ڈیٹا بیس کنکشن پر TLS کو اصل میں نافذ کرنے کا طریقہ یہاں ہے:

final connection = await Connection.open(
  Endpoint(
    host: 'your-db-host.example.com',
    port: 5432,
    database: 'your_database',
    username: dbUser,
    password: dbPassword,
  ),
  settings: ConnectionSettings(
    sslMode: SslMode.require,
  ),
);

var connectionString =
    "Host=your-db-host.example.com;" +
    "Port=5432;" +
    "Database=your_database;" +
    "Username=db_user;" +
    "Password=db_password;" +
    "SSL Mode=Require;" +
    "Trust Server Certificate=false;";

await using var dataSource = NpgsqlDataSource.Create(connectionString);

ماحول SSL Mode=Require اس کا مطلب ہے کہ اگر آپ کا ڈیٹا بیس سرور TLS کو سپورٹ نہیں کرتا ہے تو کنکشن مکمل طور پر ناکام ہو جائے گا۔ یہ صحیح کرنسی ہے۔ ایک ایسا کنکشن جو TLS دستیاب نہ ہونے پر خود بخود سادہ متن پر واپس آجاتا ہے وہ بالکل بھی تحفظ فراہم نہیں کرتا ہے۔

ڈیٹا بیس کی اسناد کا والٹ میں ہونا ضروری ہے۔

ڈیٹا بیس کی اسناد رن ٹائم کے وقت سیکرٹس مینیجر سے حاصل کی جانی چاہئیں۔ یہ کنفیگریشن فائل میں محفوظ نہیں ہے، ورژن کنٹرول کے لیے پابند ہے، یا کنکشن سٹرنگ میں ہارڈ کوڈ نہیں ہے۔

یہاں یہ ہے کہ رن ٹائم اسناد کی بازیافت دراصل کیسے کام کرتی ہے:

final dbHost = Platform.environment['DB_HOST']!;
final dbUser = Platform.environment['DB_USER']!;
final dbPassword = Platform.environment['DB_PASSWORD']!;

final connection = await Connection.open(
  Endpoint(
    host: dbHost,
    database: 'your_database',
    username: dbUser,
    password: dbPassword,
  ),
  settings: ConnectionSettings(sslMode: SslMode.require),
);

builder.Configuration.AddAzureKeyVault(
    new Uri("https://your-vault.vault.azure.net/"),
    new DefaultAzureCredential()
);

var connectionString = builder.Configuration["DatabaseConnectionString"];

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

var dataSourceBuilder = new NpgsqlDataSourceBuilder(connectionString);
dataSourceBuilder.ConnectionStringBuilder.MaxPoolSize = 20;
dataSourceBuilder.ConnectionStringBuilder.MinPoolSize = 5;
dataSourceBuilder.ConnectionStringBuilder.ConnectionIdleLifetime = 300;
await using var dataSource = dataSourceBuilder.Build();

پیرامیٹرائزیشن کی حکمت عملی کے طور پر ذخیرہ شدہ طریقہ کار

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

ذخیرہ شدہ طریقہ کار SQL انجیکشن کے خلاف مزاحم ہیں کیونکہ SQL ڈھانچہ ڈیٹا بیس کے اندر طے ہوتا ہے اور پیرامیٹرز کو ہمیشہ ڈیٹا کے طور پر سمجھا جاتا ہے (وہ استفسار کے سٹرنگ سے منسلک نہیں ہوتے ہیں)۔

CREATE OR REPLACE PROCEDURE get_user_by_email(p_email VARCHAR(255))
LANGUAGE plpgsql
AS $$
BEGIN
    SELECT id, first_name, last_name, email
    FROM users
    WHERE email = p_email;
END;
$$;

public async Task FindUserByEmail(string email)
{
    await using var command = dataSource.CreateCommand("get_user_by_email");
    command.CommandType = CommandType.StoredProcedure;
    command.Parameters.AddWithValue("p_email", email);

    await using var reader = await command.ExecuteReaderAsync();
    if (await reader.ReadAsync())
    {
        return new User
        {
            Id = reader.GetGuid(0),
            FirstName = reader.GetString(1),
            LastName = reader.GetString(2),
            Email = reader.GetString(3)
        };
    }
    return null;
}

حملہ آور گزر رہا ہے۔ ' OR '1'='1 ای میل کی قدر بالکل اسی سٹرنگ کو پیرامیٹر کے طور پر لیتی ہے۔ ڈیٹا بیس اس کی تشریح SQL نحو سے نہیں کرتا ہے۔ ایک طریقہ کار صرف تخلیق کے وقت طے شدہ سوالات کو انجام دیتا ہے۔ یہ ان وجوہات میں سے ایک ہے جس کی وجہ سے ذخیرہ شدہ طریقہ کار صرف کارکردگی کو بہتر بنانے کے بجائے ایک جائز حفاظتی ٹول بنتے ہیں۔

CORS: API کے ذریعے نافذ کردہ حدود

کراس اوریجن ریسورس شیئرنگ ایک براؤزر سیکیورٹی میکانزم ہے جو یہ کنٹرول کرتا ہے کہ ویب صفحہ کون سے ڈومینز API کو درخواستیں دے سکتا ہے۔

پیداوار میں سب سے عام CORS غلط کنفیگریشن بھی سب سے خطرناک وائلڈ کارڈ CORS ہے۔

Access-Control-Allow-Origin: *

یہ تمام براؤزرز کو بتاتا ہے کہ پورے انٹرنیٹ پر کوئی بھی ویب صفحہ API کو تصدیق شدہ درخواستیں کرنے کے لیے اس صارف کی اسناد کا استعمال کر سکتا ہے۔ جب کوئی حملہ آور ایک بدنیتی پر مبنی ویب صفحہ کی میزبانی کرتا ہے اور کوئی صارف اس ویب صفحہ کو وزٹ کرتا ہے، تو حملہ آور کا صفحہ اس صارف کے طور پر API سے درخواستیں کر سکتا ہے۔

وائلڈ کارڈ CORS ترقی کے دوران آسان ہے۔ پیداوار میں، یہ ایک کمزوری ہے.

تمام پروڈکشن APIs کو واضح طور پر اجازت شدہ اصلیت کے ساتھ CORS کو کنفیگر کرنا چاہیے۔ یہ وائلڈ کارڈ کا نمونہ نہیں ہے۔ نہیں *.yourapp.com. ایک واضح، شمار شدہ ڈومین جو کراس اوریجن درخواستوں کی اجازت دیتا ہے۔

Access-Control-Allow-Origin: https://app.yourproduct.com
Access-Control-Allow-Origin: https://admin.yourproduct.com

ڈومین کی مماثلت درست ہونی چاہیے۔ اگر اصل ہیڈر واضح طور پر اجازت دی گئی اصل میں سے کسی ایک سے مماثل نہیں ہے، تو براؤزر جواب کو شامل نہیں کرے گا۔

اجازت شدہ طریقے اور اجازت شدہ ہیڈرز بھی واضح ہونے چاہئیں۔ پہلے سے طے شدہ انکار کی حیثیت لاگو ہوتی ہے۔ اگر واضح طور پر اجازت نہ ہو تو اس کی اجازت نہیں ہے۔

یہ API گیٹ وے یا فریم ورک کی سطح پر کیا جانے والا کنفیگریشن فیصلہ ہے۔ یہ فی اینڈ پوائنٹ کے بجائے تمام API اینڈ پوائنٹس پر یکساں طور پر لاگو ہوتا ہے، جسے انفرادی ڈویلپرز غلط کنفیگر کر سکتے ہیں۔

سٹرکچرڈ لاگنگ اور فیلڈ لیول ماسکنگ

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

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

ایک بار پھر، یہ ایک مفروضہ نہیں ہے. یہ حقیقی پروڈکشن لاگنگ پلیٹ فارمز میں پایا جانے والا ایک حقیقی نمونہ ہے۔

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

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

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

عملی طور پر فیلڈ لیول ماسکنگ کیسی دکھتی ہے وہ یہ ہے:

class SecureLogger {
  final Logger _logger;

  static const _sensitiveKeys = {
    'password', 'authorization', 'token',
    'account_number', 'card_number', 'bvn', 'nin', 'secret', 'api_key',
  };

  SecureLogger(this._logger);

  void info(String message, {Map? data}) {
    _logger.info(message, _mask(data));
  }

  void error(String message, {Map? data, Object? error}) {
    _logger.error(message, _mask(data), error);
  }

  Map? _mask(Map? data) {
    if (data == null) return null;
    return data.map((key, value) {
      if (_sensitiveKeys.contains(key.toLowerCase())) {
        return MapEntry(key, '***MASKED***');
      }
      if (value is Map) return MapEntry(key, _mask(value));
      return MapEntry(key, value);
    });
  }
}

final logger = SecureLogger(Logger('PaymentService'));

logger.info('Processing payment', data: {
  'transaction_id': 'txn_001',
  'amount': 50000,
  'account_number': '0123456789',
  'authorization': 'Bearer eyJ...',
});

// output:
// Processing payment
// { transaction_id: txn_001, amount: 50000,
//   account_number: ***MASKED***, authorization: ***MASKED*** }

public class MaskSensitiveFieldsPolicy : IDestructuringPolicy
{
    private static readonly HashSet SensitiveFields =
        new(StringComparer.OrdinalIgnoreCase)
        {
            "password", "authorization", "token", "account_number",
            "card_number", "bvn", "nin", "secret", "api_key"
        };

    public bool TryDestructure(
        object value,
        ILogEventPropertyValueFactory factory,
        out LogEventPropertyValue result)
    {
        if (value is not IDictionary dict)
        {
            result = null!;
            return false;
        }

        var properties = dict.Select(kvp => new LogEventProperty(
            kvp.Key,
            SensitiveFields.Contains(kvp.Key)
                ? factory.CreatePropertyValue("***MASKED***")
                : factory.CreatePropertyValue(kvp.Value, true)));

        result = new StructureValue(properties);
        return true;
    }
}

Log.Logger = new LoggerConfiguration()
    .Destructure.With()
    .WriteTo.Console()
    .CreateLogger();

یہ تمام ماحول پر لاگو ہوتا ہے، بغیر کسی استثناء کے، نہ صرف پیداوار پر۔ ڈویلپمنٹ لاگز اکثر تھرڈ پارٹی لاگنگ پلیٹ فارم پر ایکسپورٹ کیے جاتے ہیں اور اکثر ٹیم کے متعدد ممبران تلاش کرتے ہیں۔ ڈویلپرز ڈویلپمنٹ اور لاگنگ ریکوسٹ باڈیز کے تحت اصلی اکاؤنٹس کے خلاف جانچ کر رہے تھے حقیقی صارف ڈیٹا کو لاگنگ پلیٹ فارم میں ڈال رہے تھے جہاں اس کا تعلق نہیں تھا۔

CI/CD سیکیورٹی گیٹ

آپ کے کوڈ پروڈکشن تک پہنچنے سے پہلے CI/CD پائپ لائن آخری خودکار گیٹ ہے۔ یہ زیادہ تر انجینئرنگ تنظیموں میں مستقل طور پر زیر استعمال سیکیورٹی کنٹرولز میں سے ایک ہے۔

زیادہ تر پائپ لائنز ٹیسٹ چلاتی ہیں اور فارمیٹس کی جانچ کرتی ہیں۔ سیکیورٹی گیٹ ایک اضافی چیک ہے جو سیکیورٹی سے متعلق مسائل کو بے نقاب کرتا ہے جو انسانوں کے کوڈ کا جائزہ لینے پر مستقل طور پر چھوٹ جاتے ہیں۔

خفیہ پتہ لگانا

جب بھی آپ ہر برانچ کو دھکیلتے ہیں تو آپ کو راز کو بازیافت کرنے کی ضرورت ہوتی ہے۔ API کلید، ڈیٹا بیس پاس ورڈ، نجی کلید، ایمبیڈڈ اسناد کے ساتھ کنکشن سٹرنگ، کنفیگریشن فائل میں JWT راز۔

گٹلیکس یہ ایک مفت اور اوپن سورس ٹول ہے جسے خاص طور پر اس مقصد کے لیے بنایا گیا ہے۔ اسے اپنی GitHub ایکشن پائپ لائن میں ضم کرنے کا طریقہ یہاں ہے:

# .github/workflows/security.yml
name: Security Gates

on:
  push:
    branches: ["*"]
  pull_request:
    branches: ["*"]

jobs:
  secret-detection:
    name: Scan for secrets
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 0

      - uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

اگر Gitleaks کو راز مل جاتا ہے، تو پائپ لائن ناکام ہو جاتی ہے، درست فائل اور لائن نمبر کو آؤٹ پٹ کرتی ہے، اور انضمام کو روک دیتی ہے۔ آپ کو رازوں کو ہٹانے، اسناد کو تبدیل کرنے کی ضرورت ہے (چونکہ وہ ورژن کنٹرول کو متاثر کرتے ہیں اور اسے سمجھوتہ کیا جانا چاہئے)، اور پائپ لائن گزرنے سے پہلے ایک صاف عہد کو آگے بڑھانا ہوگا۔

اسکین کو آپ کی پوری گٹ ہسٹری پر چلایا جانا چاہئے، نہ کہ صرف تازہ ترین کمٹ پر۔ راز جو تین کمٹ پہلے جوڑے گئے اور اگلی کمٹ میں ہٹائے گئے وہ اب بھی ریپوزٹری ہسٹری میں ہیں اور ان کو کرپٹ سمجھا جانا چاہیے۔

مزید برآں، آپ کی تنظیم کے پاس ایک متعین جوابی عمل ہونا چاہیے، بشمول رازوں کا پتہ چلنے پر کس کو مطلع کیا جائے گا، کون سے اسناد کو تبدیل کیا جائے گا، اور کتنی دیر تک۔ جواب کے بغیر پتہ لگانا سیکیورٹی کنٹرول نہیں ہے۔

سیکیورٹی کے لیے جامد تجزیہ

جامد تجزیہ کے ٹولز کوڈ پر عمل کیے بغیر کمزوری کے نمونوں کے لیے کوڈ کا تجزیہ کرتے ہیں۔ یہ خام ایس کیو ایل سٹرنگ کنکٹنیشن، غیر محفوظ ڈی سیریلائزیشن، ہارڈ کوڈ شدہ اسناد، فرسودہ کرپٹوگرافک فنکشنز، گمشدہ ان پٹ توثیق، اور خطرناک فنکشن کالز کو پکڑتا ہے۔

شیمگریب ایک مفت اور اوپن سورس جامد تجزیہ ٹول جس میں سیکورٹی کمیونٹی کے زیر انتظام سیکورٹی قوانین کی ایک بڑی لائبریری ہے۔ اسے اپنی پائپ لائن پر لاگو کرنے کا طریقہ یہاں ہے:

  static-analysis:
    name: Static analysis
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - uses: semgrep/semgrep-action@v1
        with:
          config: >-
            p/owasp-top-ten
            p/secrets
            p/sql-injection
        env:
          SEMGREP_APP_TOKEN: ${{ secrets.SEMGREP_APP_TOKEN }}

کہ p/owasp-top-ten قاعدہ سیٹ OWASP ٹاپ 10 کمزوریوں سے مطابقت رکھنے والے نمونوں کو حاصل کرتا ہے۔ کہ p/sql-injection قاعدہ سیٹ خاص طور پر ڈیٹا بیس کے سوالات میں سٹرنگ کنکٹنیشن کو جھنڈا دیتا ہے۔ جب سیمگریپ کو کوئی مماثلت ملتی ہے، تو پائپ لائن ناکام ہو جاتی ہے اور درست فائل، لائن اور اصول کی نشاندہی کرتی ہے جس نے اسے متحرک کیا۔ مسئلہ حل ہونے تک کوڈ کو ضم نہیں کیا جا سکتا۔

.NET پروجیکٹس کے لیے مائیکروسافٹ سیکیورٹی کوڈ تجزیہ اور روزلن تجزیہ کار یہ اسی طرح کی فعالیت فراہم کرتا ہے جو براہ راست تعمیراتی عمل میں ضم ہوتا ہے۔

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

انحصار کمزوری اسکین

آپ کے پروجیکٹ میں ہر انحصار ممکنہ حملے کی سطح ہے۔ OWASP انحصار چیک کریں۔ ایک مفت ٹول جو آپ کے پروجیکٹ کی نیشنل ویلنریبلٹی ڈیٹا بیس (NVD) پر انحصار کو چیک کرتا ہے اور معروف CVEs کو جھنڈا دیتا ہے۔

  dependency-scan:
    name: Dependency vulnerability scan
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - uses: dependency-check/Dependency-Check_Action@main
        with:
          project: "your-project-name"
          path: "."
          format: "HTML"
          args: >
            --failOnCVSS 7
            --enableRetired

      - uses: actions/upload-artifact@v3
        if: always()
        with:
          name: dependency-check-report
          path: reports/

کہ --failOnCVSS 7 جھنڈے کا مطلب ہے کہ پائپ لائن ناکام ہو جائے گی اگر کسی بھی انحصار کو 7 یا اس سے زیادہ کے CVSS سکور کے ساتھ کمزوریاں معلوم ہوں۔ کامن ولنریبلٹی اسکورنگ سسٹم (CVSS) کا اسکور 0 سے 10 تک ہوتا ہے۔ 7 یا اس سے زیادہ کے اسکور کو زیادہ شدت سمجھا جاتا ہے۔ آپ اپنی خطرے کی رواداری کی بنیاد پر اس حد کو ایڈجسٹ کر سکتے ہیں۔

Node.js پروجیکٹس کے لیے، npm audit یہ بنیادی طور پر اسی طرح کی فعالیت فراہم کرتا ہے۔ ڈارٹ پروجیکٹ کے لیے، dart pub deps کمزوری ڈیٹا بیس اسکیننگ کے ساتھ مل کر، یہ انحصار کی سطحوں کا احاطہ کرتا ہے۔

ماحول کی طرف سے ترتیب کی تصدیق

پروڈکشن میں تعینات کرنے سے پہلے، آپ کی پائپ لائن کو اس بات کی تصدیق کرنی چاہیے کہ پروڈکشن کنفیگریشن مطلوبہ حفاظتی معیارات پر پورا اترتی ہے۔ یہ صرف اس بات کی جانچ نہیں کرتا ہے کہ آیا کنفیگریشن فائل موجود ہے۔ ہم فعال طور پر بعض حفاظتی اہم ترتیبات کی درستگی پر زور دیتے ہیں۔

پائپ لائن کے مراحل میں توثیق درج ذیل ہے:

  config-validation:
    name: Validate production configuration
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v3

      - name: Validate security configuration
        run: |
          if grep -r "debugEndpoint\|swagger-ui\|/debug" src/ --include="*.dart" --include="*.cs"; then
            echo "ERROR: Debug endpoints found in production build"
            exit 1
          fi

          if grep -r "AllowAnyOrigin\|\*" config/ --include="*.yaml" --include="*.json"; then
            echo "ERROR: Wildcard CORS configuration detected"
            exit 1
          fi

          if grep -rE "(password|secret|key)\s*=\s*['\"][^$\{]" config/ --include="*.yaml" --include="*.json"; then
            echo "ERROR: Hardcoded credentials detected in configuration"
            exit 1
          fi

          if grep -r "showStackTrace.*true\|expose_errors.*true" config/ --include="*.yaml"; then
            echo "ERROR: Stack trace exposure enabled in production config"
            exit 1
          fi

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

مختلف ماحول کے لیے مختلف ورک فلو

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

پروڈکشن پائپ لائن میں سیکورٹی گیٹس کا مکمل سیٹ شامل ہے۔ ڈویلپر کی رفتار کو برقرار رکھنے کے لیے ڈویلپمنٹ پائپ لائن طویل عرصے سے چلنے والے کچھ گیٹس کو چھوڑ سکتی ہے۔ تاہم، ہم اسے پروڈکشن پائپ لائن میں کبھی نہیں چھوڑتے ہیں۔

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

مائیکرو سروس اور اندرونی سروس سیکیورٹی

مائیکرو سروسز کی تعمیر سیکورٹی کے خدشات کو متعارف کراتی ہے جو یک سنگی فن تعمیرات نہیں کرتے ہیں۔ کوئی بھی انٹر سروس مواصلات ممکنہ حملے کی سطح ہے۔

یک سنگی میں، اجزاء کے درمیان میتھڈ کالز میموری میں فنکشن کالز ہیں۔ ٹرانزٹ کے دوران اسے روکا، جعل سازی یا تبدیل نہیں کیا جا سکتا۔

مائیکرو سرویس فن تعمیر میں، ہر سروس کال ایک نیٹ ورک کی درخواست ہے۔ نیٹ ورک کی درخواستوں کو روکا جا سکتا ہے، جعلی اور تبدیل کیا جا سکتا ہے۔ وہ خدمات جو ایک دوسرے پر واضح طور پر اعتماد کرتی ہیں کیونکہ وہ "اندرونی” ہیں ایک خطرناک مفروضہ بنا رہی ہیں۔

تمام مائیکرو سروسز کو، بطور ڈیفالٹ، آنے والی درخواستوں کو، بشمول دیگر داخلی خدمات کی درخواستوں کو، ناقابل اعتماد سمجھنا چاہیے۔ تمام انٹر سروس مواصلات کے لیے تصدیق کی ضرورت ہوتی ہے۔ API گیٹ وے بیرونی تصدیق کو ہینڈل کرتا ہے۔ داخلی خدمات کے درمیان توثیق کو الگ سے ہینڈل کیا جانا چاہیے۔

اس میں دو نمونے شامل ہیں: ہم وقت ساز کالوں کے لیے mTLS اور غیر مطابقت پذیر کمیونیکیشن کے لیے تصدیق شدہ ایونٹ اسٹریمز۔

ہم وقت ساز سروس سے سروس کالز کے لیے mTLS (Mutual TLS) کا مطلب ہے کہ دونوں خدمات ایک دوسرے کو سرٹیفکیٹ فراہم کرتی ہیں۔ ایک ادائیگی کی خدمت جو اکاؤنٹ سروس کو کال کرتی ہے اسے ایک درست سرٹیفکیٹ پیش کرنا چاہیے جس پر اکاؤنٹ سروس بھروسہ کرتی ہے۔ اگر سرٹیفکیٹ غائب یا غلط ہے، تو کوئی بھی ایپلیکیشن کوڈ چلنے سے پہلے کنکشن کو مسترد کر دیا جائے گا۔ یہ شناخت کا ایک خفیہ کردہ ثبوت ہے۔ چوری کرنے کے لیے کوئی بیئرر ٹوکن نہیں ہیں اور نہ ہی گھمانے کے لیے API کیز ہیں۔

Payment Service                    Account Service
      |                                  |
      |-- presents its certificate ----> |
      |                                  |-- verifies certificate against trusted CA
      |                                  |-- rejects connection if invalid
      | <-- presents its certificate --- |
      |-- verifies certificate           |
      |                                  |
      |-- authorized request ----------> |
      |                                  |-- processes because identity is proven

غیر مطابقت پذیر مواصلت کے لیے تصدیق شدہ ایونٹ کا سلسلہ اس کا مطلب ہے کہ بروکر کو شائع ہونے والے ہر پیغام میں ایک دستخط ہوتا ہے جس کی استعمال کرنے والی سروس پروسیسنگ سے پہلے تصدیق کرتی ہے۔ سروس جاری PaymentCompleted واقعات آپ کی نجی کلید کے ساتھ دستخط کیے جاتے ہیں۔ استعمال کرنے والی سروس ایونٹ پر کارروائی کرنے سے پہلے دستخط کی تصدیق کرتی ہے۔ بغیر کسی درست دستخط کے جعلی واقعات کو مسترد کر دیا جاتا ہے۔

class PaymentEventPublisher {
  final KafkaProducer _producer;
  final EventSigner _signer;

  Future publishPaymentCompleted(Payment payment) async {
    final event = PaymentCompletedEvent(
      paymentId: payment.id,
      amount: payment.amount,
      timestamp: DateTime.now().toIso8601String(),
    );

    final signature = await _signer.sign(jsonEncode(event.toJson()));

    await _producer.send(
      topic: 'payment.completed',
      value: jsonEncode({
        'payload': event.toJson(),
        'signature': signature,
        'publisher': 'payment-service',
      }),
    );
  }
}

class AccountEventConsumer {
  final EventVerifier _verifier;
  final AccountService _accountService;

  Future onMessage(KafkaMessage message) async {
    final data = jsonDecode(message.value);
    final isValid = await _verifier.verify(
      jsonEncode(data['payload']),
      data['signature'] as String,
      data['publisher'] as String,
    );

    if (!isValid) {
      logger.warning('Invalid signature from ${data['publisher']} — discarding');
      return;
    }

    final event = PaymentCompletedEvent.fromJson(data['payload']);
    await _accountService.handlePaymentCompleted(event);
  }
}

آپ کو API گیٹ وے کے علاوہ انٹرنیٹ سے براہ راست سروس تک رسائی حاصل نہیں کرنی چاہیے۔ گیٹ وے داخلے کا ایک واحد نقطہ ہے۔ تمام بیرونی ٹریفک کے لیے شرح کو محدود کرنے، تصدیق کرنے اور روٹنگ کو ہینڈل کرتا ہے۔ گیٹ وے کے پیچھے خدمات اندرونی ہیں۔ اس کا مطلب ہے کہ وہ اب بھی ایک دوسرے پر بھروسہ نہیں کرتے ہیں، لیکن وہ بیرونی دنیا کے سامنے نہیں آتے ہیں۔

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

ایک فن تعمیر کا انتخاب کریں جس کی بنیاد پر آپ کی ٹیم درحقیقت محفوظ طریقے سے کام کر سکتی ہے، نہ کہ فیڈز پر۔

انجینئرنگ کی ضروریات کے طور پر ڈیٹا کی رازداری اور تعمیل

ڈیٹا کی رازداری کے تقاضے انجینئرنگ کے تقاضے ہیں۔ یہ کوئی قانونی تقاضا نہیں ہے کہ انجینئرنگ قبول کرے۔ یہ ایک انجینئرنگ کی ضرورت ہے جو انجینئرنگ کی ملکیت ہے۔

نائیجیریا کے NDPA 2023 کے تحت، ذاتی ڈیٹا پر صرف واضح، واضح اور قانونی مقاصد کے لیے کارروائی کی جانی چاہیے۔ BVN ڈیٹا میں مخصوص رہائش اور پروسیسنگ کی ضروریات ہیں جو CBN رہنما خطوط کے تحت نافذ ہیں۔ PCI-DSS میں کسی بھی ایسے ماحول کی تعمیل شامل ہے جو کارڈ ہولڈر کے ڈیٹا کو اسٹور، پروسیس، یا منتقل کرتا ہے۔

ان تقاضوں کے مخصوص انجینئرنگ مضمرات ہیں۔

1. ڈیٹا کو کم سے کم کریں۔

ہم صرف ذاتی معلومات اکٹھا اور ذخیرہ کر سکتے ہیں جو درحقیقت مخصوص مقاصد کے لیے ضروری ہے۔ APIs جو ضروری سے زیادہ ڈیٹا اکٹھا کرتے ہیں تعمیل کے خطرات لاحق ہوتے ہیں۔ ایک جواب جو کال کرنے والے کی ضرورت سے زیادہ ڈیٹا واپس کرتا ہے BOPLA کمزوری اور ڈیٹا کو کم سے کم کرنے کی خلاف ورزی ہے۔

2. مقصد کی حد

ایک مقصد کے لیے جمع کیے گئے ڈیٹا کو مناسب بنیادوں کے بغیر کسی دوسرے مقصد کے لیے استعمال نہیں کیا جانا چاہیے۔ انجینئرنگ کا مطلب ہے ڈیٹا کو دستاویز کرنا اور لاگو کرنا جو کسی سسٹم کے اندر بہتا ہے۔ ایک سروس کا ڈیٹا دوسری سروس میں نہیں جانا چاہیے جو اسے غیر مجاز مقاصد کے لیے استعمال کرتی ہو۔

3. ڈیٹا کی رہائش

ڈیٹا کی کچھ اقسام کو مخصوص جغرافیائی خطوں میں ذخیرہ کیا جانا چاہیے۔ یہ بنیادی ڈھانچے کی ضروریات ہیں جو تعیناتی کے بعد پیچ ​​نہیں کی جا سکتی ہیں اور سسٹم کے فن تعمیر میں شامل ہونا ضروری ہے۔

4. برقرار رکھنا اور حذف کرنا

ذاتی معلومات کو ایک بار حذف کر دینا چاہیے جس مقصد کے لیے اسے جمع کیا گیا تھا یا رازداری کی پالیسی میں بیان کردہ برقرار رکھنے کی مدت ختم ہو جائے۔ انجینئرنگ کا مطلب یہ ہے کہ ذاتی ڈیٹا کے تمام زمروں میں برقرار رکھنے کی پالیسیاں اور خودکار حذف کرنے کے طریقہ کار کی وضاحت ہونی چاہیے۔ دستی حذف کرنے کی پالیسیاں جو ڈیٹا کو حذف کرنا یاد رکھنے والے لوگوں پر انحصار کرتی ہیں ان پر عمل نہیں کیا جاتا ہے۔

5. آڈٹ لاگنگ

تعمیل کو ظاہر کرنے کے لیے ذاتی ڈیٹا تک تمام رسائی کو کافی تفصیل سے ریکارڈ کیا جانا چاہیے۔ کس نے کس ڈیٹا تک رسائی حاصل کی، کب، اور کس مقصد کے لیے۔ یہ آڈٹ لاگ چھیڑ چھاڑ سے واضح ہونا چاہیے اور جب تک ضروری ہو اسے برقرار رکھا جائے۔

یہاں یہ ہے کہ ان پانچوں پالیسیوں کو ایک ہی فنکشن میں ایک ساتھ لاگو کیا جاتا ہے: صارف پروفائل اختتامی نقطہ۔

class UserProfileService {
  final UserRepository _repository;
  final AuditLogger _auditLogger;
  final DataResidencyValidator _residencyValidator;

  UserProfileService(this._repository, this._auditLogger, this._residencyValidator);

  Future getProfile(
    String requestingUserId,
    String targetUserId,
    String purpose,
  ) async {
    if (!_isValidPurpose(purpose)) {
      throw UnauthorizedException('Invalid or undeclared access purpose');
    }

    final user = await _repository.findById(targetUserId);
    if (user == null) throw NotFoundException('User not found');

    _residencyValidator.assertCompliant(user.dataRegion, requestingUserId);

    await _auditLogger.log(AuditEntry(
      action: 'READ_USER_PROFILE',
      actorId: requestingUserId,
      resourceId: targetUserId,
      purpose: purpose,
      timestamp: DateTime.now(),
      dataFieldsAccessed: ['first_name', 'last_name', 'email'],
    ));

    return UserProfileResponse(
      id: user.id,
      firstName: user.firstName,
      lastName: user.lastName,
      email: user.email,
    );
  }

  bool _isValidPurpose(String purpose) {
    const validPurposes = {
      'user_self_view',
      'customer_support_verified',
      'compliance_audit',
    };
    return validPurposes.contains(purpose);
  }
}

class DataRetentionService {
  final UserRepository _repository;
  final AuditLogger _auditLogger;

  Future enforceRetentionPolicy() async {
    final cutoff = DateTime.now().subtract(const Duration(days: 2555));
    final expiredUsers = await _repository.findInactiveUsersBefore(cutoff);

    for (final user in expiredUsers) {
      await _auditLogger.log(AuditEntry(
        action: 'AUTOMATED_DATA_DELETION',
        resourceId: user.id,
        purpose: 'retention_policy_enforcement',
        timestamp: DateTime.now(),
      ));

      await _repository.anonymize(user.id);
    }
  }
}

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

یہ تقاضے ذاتی ڈیٹا پر کارروائی کرنے والے تمام افعال کے لیے تقاضوں کی وضاحتوں کا حصہ ہونا چاہیے۔ فیچر بننے کے بعد یہ حل نہیں ہوتا۔ ڈیزائن میں احاطہ کرتا ہے۔

نتیجہ

سیکیورٹی وہ خصوصیت نہیں ہے جسے آپ سافٹ ویئر میں شامل کرتے ہیں۔ یہ وہ خصوصیات ہیں جو شروع سے انجنیئر ہیں۔

آرکیٹیکچرل فیصلے کرنے سے پہلے تھریٹ ماڈلنگ کا مطلب یہ سمجھنا ہے کہ آپ کس چیز کی حفاظت کرتے ہیں اور کس چیز کے خلاف آپ یہ فیصلہ کرتے ہیں کہ اسے کیسے تعینات کیا جائے۔

کاروباری اصول کے طور پر سیکیورٹی کا مطلب یہ ہے کہ ڈومین کی پرت سیکیورٹی کی ضروریات کو اسی طرح نافذ کرتی ہے جس طرح یہ دوسرے کاروباری اصولوں کو نافذ کرتی ہے، اور یہ کہ ان سے احتراز یا فراموش نہیں کیا جاسکتا۔

کسی تنظیم کی طرف سے طے شدہ خفیہ کاری کے معیارات کا مطلب یہ ہے کہ ڈویلپرز ترجیح یا سہولت کی بنیاد پر خفیہ کاری کے پرائمیٹوز کا انتخاب نہیں کرتے ہیں۔

ڈیٹا بیس سیکیورٹی کا مطلب یہ ہے کہ آپ کی ایپلیکیشن صرف وہی کر سکتی ہے جو اسے کرنے کی ضرورت ہے، اور یہ کہ حملہ آور جو ایک جزو سے سمجھوتہ کرتا ہے ان سب سے سمجھوتہ نہیں کر سکتا۔

CORS کنفیگریشن کا مطلب یہ ہے کہ براؤزر سیکیورٹی میکانزم دراصل وائلڈ کارڈز کو نظرانداز کرنے کے بجائے حدود کو نافذ کر رہے ہیں۔

فیلڈ لیول ماسکنگ کے ساتھ سٹرکچرڈ لاگنگ کا مطلب یہ ہے کہ لاگ فائلوں میں کوئی بھی حساس ڈیٹا باقی نہیں رہتا، چاہے ڈویلپرز لاگ ان کریں۔

اور CI/CD سیکیورٹی گیٹس کا مطلب ہے کہ خودکار توثیق اس چیز کو پکڑتی ہے جو تعیناتی سے پہلے ہر دھکے پر انسانی جائزے سے چھوٹ جاتی ہے۔

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

سیکیورٹی کے خطرے کو دور کرنے کا سب سے مہنگا حصہ اس کے استحصال کے بعد ہے۔ دوسری سب سے مہنگی جگہ پیداوار میں جانے کے بعد ہے۔ کوڈ کی ایک لائن ہونے سے پہلے سب سے کم مہنگا حصہ ڈیزائن کا حصہ ہے۔

Secure by Design کا اصل مطلب یہی ہے۔ یہ مکمل طور پر محفوظ نہیں ہے یا اس سے کوئی خطرہ نہیں ہے۔ اس بارے میں سوچ سمجھ کر، دستاویزی، اور قابل نفاذ فیصلے کرنا کہ سسٹم بننے سے پہلے مخالف حالات کو کس طرح سنبھالے گا اس بات کو یقینی بناتا ہے کہ انجینئرنگ شروع سے ہی درست ہے۔

تکنیکی شائقین کے طور پر، ان چیزوں میں سے ایک جس کا آپ کو انتظار کرنا چاہیے وہ دن ہے جب ایپلیکیشنز کو سیکیورٹی کے ساتھ ترقیاتی عمل کے ایک لازمی حصے کے طور پر بنایا جاتا ہے۔ یہ ایسی چیز نہیں ہے جسے بعد میں سوچا جانا چاہئے یا تعیناتی کے لئے منظور کیا جانا چاہئے۔ یہی وجہ ہے کہ Secure by Design کو نہ صرف ایپلیکیشن سیکیورٹی کے شعبے میں بلکہ بنیادی سافٹ ویئر انجینئرنگ میں بھی ایک معیاری عمل کے طور پر سمجھنا، اپنانا، اور اپنایا جانا چاہیے۔

محفوظ کوڈنگ کا لطف اٹھائیں!