بکافی سیکیورٹی اور پرائیویسی

سیکیورٹی کے اکثر پوچھے گئے سوالات 

کیا پچھلے 5 سالوں میں کوئی اہم سیکورٹی خلاف ورزیاں یا واقعات ہوئے ہیں؟

نہیں.

مراعات یافتہ اور عام اکاؤنٹ تک رسائی کو سختی سے کنٹرول کیا جاتا ہے اور وقتا فوقتا جائزہ لیا جاتا ہے، کم از کم

سالانہ؟

جی ہاں.

صارف کے بارے میں کون سا ڈیٹا اکٹھا کیا جا رہا ہے؟ 

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

اکاؤنٹ کا مالک بکنگ کے وقت مختلف ڈیٹا پوائنٹس کو اکٹھا کرنے کے لیے ٹیکسٹ فیلڈز بنا سکتا ہے، لیکن صارف کو مکمل طور پر معلوم ہے کہ ڈیٹا اکٹھا کیا جا رہا ہے کیونکہ آخری صارف ڈیٹا کو فیلڈز میں ٹائپ کر رہا ہے۔ آخری صارف یا اکاؤنٹ کا مالک data@bookafy.com پر ای میل کر کے کسی بھی وقت ڈیٹا ڈیلیٹ کرنے کی درخواست کر سکتا ہے۔ 

ایپ کن مقاصد کے لیے ڈیٹا استعمال کر رہی ہے؟

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

ڈیٹا ڈیلیٹ کرنے کے لیے صارفین کے کیا حقوق ہیں اور صارف ڈیٹا کو ڈیلیٹ کرنے کی درخواست کیسے کرسکتا ہے؟ 

ہم اکاؤنٹ کے مالک (ہمارے گاہک) سے جمع کردہ ڈیٹا کو اکاؤنٹ کے مالک کو بہتر تجربہ فراہم کرنے کے لیے استعمال کرتے ہیں۔ اس میں ایسی کوئی بھی جگہ شامل ہے جہاں AO پھنس گیا ہو، کئی بار ملاحظہ کیا گیا ہو، اس پر سوالات یا بگ ہو سکتے ہیں۔ ہم اس ڈیٹا کو اپنے صارفین (اکاؤنٹ کے مالک) کے ساتھ صحیح وقت پر صحیح پیغام کے ساتھ بات چیت کرنے کے لیے استعمال کرتے ہیں۔ 

آخری صارف کے لیے، ہمارے صارف کے گاہک… ہم اس ڈیٹا کو صرف اکاؤنٹ کے مالک کے ساتھ لین دین (بکنگ) کے لیے استعمال کرتے ہیں۔ ہم ان صارفین کو مارکیٹ نہیں کرتے، یا ان کے ڈیٹا کو کسی اور طریقے سے استعمال نہیں کرتے۔ ان کا ڈیٹا بیچا یا ادھار نہیں لیا جاتا… یہ ہمارے سسٹم میں رہتا ہے۔ 

AO اور آخری صارف دونوں صورتوں میں، ان کا ڈیٹا کسی بھی وقت حذف کیا جا سکتا ہے۔ AO data@bookafy.com پر ای میل کر سکتا ہے اور اپنے اکاؤنٹ اور ڈیٹا کو ہٹانے کی درخواست کر سکتا ہے۔ آخری صارف اپنے ڈیٹا کو AO کے ذریعے ہٹانے کی درخواست کر سکتا ہے۔ 

کیا ملازمین کے لیے مشترکہ صارف اکاؤنٹس ممنوع ہیں؟ کلائنٹس کے بارے میں کیا خیال ہے؟

ملازمین کے اپنے مخصوص اکاؤنٹس ہوتے ہیں۔ کلائنٹس کے پاس اپنے مخصوص اکاؤنٹس بھی ہوتے ہیں، صرف ان کے ڈیٹا تک رسائی کے ساتھ۔

کیا آپ کے پاس ورڈ کی تعمیر کے لیے متعدد طاقت کے تقاضوں کی ضرورت ہوتی ہے، یعنی مضبوط پاس ورڈز اور الفا، عددی اور خصوصی حروف کی بے ترتیب ترتیب کو استعمال کرتے ہیں؟

ہمیں پاس ورڈ مینجمنٹ کی بنیادی سطح پر پاس ورڈز میں کم از کم 6 حروف درکار ہیں۔ OWASP اور NIST SP 800-63-3 پاس ورڈ پالیسی کے اختیارات آنے والے سال میں دستیاب ہو سکتے ہیں۔

کیا نیٹ ورک کی باؤنڈری انگریس اور ایگریس فلٹرنگ کے ساتھ فائر وال سے محفوظ ہے؟

جی ہاں. تمام فائر والز اور لوڈ بیلنسنگ کی سہولیات Azure اور Amazon AWS کے ذریعے فراہم کی جاتی ہیں۔

کیا عوام کو ایک اچھی طرح سے طے شدہ ڈی ملٹریائزڈ زون (DMZ) میں سرور کا سامنا ہے؟

ہاں، یہ Azure کے ڈیفالٹ انفراسٹرکچر زوننگ سے وراثت میں ملا ہے اور Bookafy کے علاقائی سرورز پوری دنیا میں پھیلے ہوئے ہیں۔ 

کیا اندرونی نیٹ ورک کی تقسیم کا استعمال حساس پیداواری وسائل جیسے PCI ڈیٹا کو مزید الگ کرنے کے لیے کیا جاتا ہے؟

PCI ڈیٹا محفوظ نہیں کیا جاتا ہے کیونکہ یہ صرف Bookafy کے ذریعے 3rd پارٹی فراہم کنندگان جیسے Stripe اور Authorize.net سے تیار کیا جاتا ہے۔ Bookafy ڈیٹا اکٹھا نہیں کرتا اور ڈیٹا اسٹور نہیں کرتا۔ 

کیا نیٹ ورک کی مداخلت کا پتہ لگانا یا روک تھام لاگو اور نگرانی کی جاتی ہے؟

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

کیا تمام ڈیسک ٹاپس باقاعدگی سے اپ ڈیٹ ہونے والے وائرس، ورم، اسپائی ویئر اور نقصان دہ کوڈ سافٹ ویئر کا استعمال کرتے ہوئے محفوظ ہیں؟

جی ہاں.

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

سسٹم سیکیورٹی آڈٹ فراہم کرنے کے لیے سیکیورٹی سروسز کا باقاعدگی سے استعمال کیا جاتا ہے۔ 

کیا تمام آپریٹنگ سسٹمز، نیٹ ورک ڈیوائسز اور ایپلیکیشنز کے لیے فعال وینڈر پیچ مینجمنٹ موجود ہے؟

جی ہاں. یہ Azure خود بخود ان کی سروس کے ذریعے فراہم کرتا ہے۔

کیا پیداواری نظام کی تمام خرابیاں اور حفاظتی واقعات ریکارڈ اور محفوظ ہیں؟

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

کیا سیکیورٹی ایونٹس اور لاگ ڈیٹا کا باقاعدگی سے جائزہ لیا جاتا ہے؟

جی ہاں. لاگز کا روزانہ، ہفتہ وار اور ماہانہ جائزہ لیا جاتا ہے – لاگ ایونٹس کی نوعیت پر منحصر ہے۔

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

جی ہاں.

اگر کوئی رازداری کی خلاف ورزی ہوتی ہے تو کیا کلائنٹس کو مطلع کرنے کا کوئی عمل موجود ہے؟

جی ہاں.

کیا آپ ذاتی طور پر قابل شناخت معلومات (PII) کو اسٹور، پروسیس، ٹرانسمٹ (یعنی "ہینڈل”) کرتے ہیں؟

جی ہاں.

PII کس ملک یا ممالک میں محفوظ ہے؟

ہمارا زیادہ تر PII ڈیٹا امریکہ میں محفوظ ہے۔ تاہم، ہم ایک مخصوص علاقائی مرکز میں اپنے انٹرپرائز صارفین کے اکاؤنٹ کا ڈیٹا ذخیرہ کرنے کے قابل ہیں۔ مثال. آسٹریلوی تنظیم اپنے ڈیٹا کو ہمارے Canberra Azure مقام میں محفوظ کرنے کا انتخاب کر سکتی ہے۔ یا یورپی ممالک یورپی ڈیٹا سینٹر میں محفوظ کر سکتے ہیں۔ 

کیا سسٹم لاگز تبدیلی اور تباہی سے محفوظ ہیں؟

یہ Azure کی طرف سے فراہم کیا جاتا ہے اور Dropbox Cloud Storage پر بیک اپ لیا جاتا ہے۔

کیا داخلے کے باؤنڈری اور VLAN پوائنٹس انٹریوژن پروٹیکشن اور ڈیٹیکشن ڈیوائسز کے ذریعے محفوظ ہیں جو حملے کے وقت الرٹ فراہم کرتے ہیں؟

جی ہاں. یہ خدمات ہمارے Azure فائر وال میں شامل ہیں جو دخل اندازی سے تحفظ فراہم کرتی ہیں اور ہماری ترقیاتی ٹیم کو خودکار الرٹس بھیجتی ہیں۔ 

کیا نوشتہ جات اور واقعات کسی ایسے ٹول سے منسلک ہیں جو کسی حملے کی پیشرفت کی وارننگ فراہم کرتے ہیں؟

جی ہاں، ہماری سیکیورٹی سروس میں لاگنگ اور حملوں کے انتباہات شامل ہیں۔ 

حل کے اندر دوسرے کلائنٹس سے ڈیٹا کو کیسے الگ کیا جاتا ہے، بشمول نیٹ ورکنگ، فرنٹ اینڈ، بیک اینڈ اسٹوریج اور بیک اپ؟

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

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

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

کیا آپ کے پاس واقعہ کے جواب کا منصوبہ ہے؟

ہاں، ایک "زندہ دستاویز” کو برقرار رکھا جاتا ہے جو تباہی اور واقعے کے ردعمل کا خاکہ پیش کرتا ہے۔

چیک لسٹ، رابطے کی تفصیلات اور واقعات کو سمجھنے اور جواب دینے کے لیے سسٹم کی اہم سہولیات۔

نیٹ ورک کے تحفظ کی کس سطح کو لاگو کیا جاتا ہے؟

ہم Azure Cloud پر چلنے والی ورچوئل مشینوں کے اپنے نیٹ ورک کی حفاظت کے لیے Azures Web Application gateway (load balancer) اور Next Generation Firewall کا استعمال کرتے ہیں۔ 

کیا پلیٹ فارم سروس کے معیار (QOS) کی کارکردگی کی پیمائش (وسائل کا استعمال، تھرو پٹ، دستیابی وغیرہ) کے لیے رپورٹس فراہم کرتا ہے؟

Status.pingdom.com پر ہمارے اسٹیٹس پیج کے مطابق دستیابی اور رسپانس کے اوقات کو چھوڑ کر اس طرح کے میٹرکس کلائنٹس کو فراہم نہیں کیے جاتے ہیں۔

کیا ڈیزاسٹر ریکوری پروگرام کا کم از کم سالانہ تجربہ کیا جاتا ہے؟

جی ہاں، وصولی کی جانچ پڑتال اور کارکردگی کا مظاہرہ اور سالانہ ٹیسٹ کیا جاتا ہے.

سسٹم کا ریکوری ٹائم مقصد (RTO) اور ریکوری پوائنٹ مقصد (RPO) کیا ہے؟

RTO 4 گھنٹے کا ہوتا ہے، RPO 1 گھنٹہ ہوتا ہے۔

کیا آپ انفرادی کلائنٹس کے لیے بیک اپ اور بحالی کے منصوبے فراہم کرتے ہیں؟

تمام پہلو کثیر کرایہ دار ہیں، لہذا بیک اپ پورے کلائنٹ بیس میں لیے جاتے ہیں۔ مکمل فائل بیک اپ ہر 24 گھنٹے بعد چلائے جاتے ہیں اور ہر 5 منٹ میں لیے جانے والے ٹائم بیک اپ میں Azure ڈیٹا بیس پوائنٹ سے فائدہ اٹھاتے ہیں۔ بیک اپس کو ڈراپ باکس کلاؤڈ کے ساتھ ساتھ فالتو Azure ورچوئل مشینوں پر محفوظ کیا جاتا ہے۔ 

بیک اپ کو برقرار رکھنے کا زیادہ سے زیادہ وقت کیا ہے؟

ڈیٹا بیس پوائنٹ ان ٹائم بیک اپ 30 دنوں کے لیے برقرار رکھا جاتا ہے، عام فائل بیک اپ کے ساتھ کم از کم 90 دن۔

ڈیٹا کی بحالی کے لیے متوقع تبدیلی کا وقت کیا ہے؟

کسی بھی غیر آفت کے منظر نامے میں کسی بھی کلائنٹ کی بحالی کی درخواست اور ہمارے ساتھ شیڈول ہونا ضروری ہے۔ ٹرن اراؤنڈ 1 اور 2 کاروباری دنوں کے درمیان ہے۔ 

کیا پورے پلیٹ فارم کو متاثر کیے بغیر ایک ہی ہستی کے اکاؤنٹ کو بحال کیا جا سکتا ہے؟

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

کیا اعلیٰ دستیابی فراہم کی گئی ہے – i۔ e جہاں ایک سرور مثال دستیاب نہیں ہو جاتا ہے کیا دوسرا دستیاب ہو جاتا ہے؟

ویب ایپلیکیشن گیٹ وے ہینڈلنگ لوڈ بیلنسنگ کے ساتھ، Azure کی ورچوئل مشین کے ذریعے تمام سسٹم ٹائر پر متعدد سرور مثالیں چل رہی ہیں۔ ڈیٹا سینٹر کے اندر سرور کی مثال کی ناکامی کو Azure WAG کے ذریعے ہینڈل کیا جاتا ہے، اس مسئلے کی مثال کو ری سائیکل کیا جاتا ہے اور/یا ہٹا دیا جاتا ہے اور اس کی جگہ ایک نئی مثال کے ساتھ تبدیل کیا جاتا ہے۔

کیا ڈیزاسٹر ریکوری کی ضروریات کو پورا کرنے کے لیے ڈیٹا کو کسی دوسرے مقام (ڈیٹا سینٹر) میں محفوظ اور دستیاب ہے؟

جی ہاں. تمام ڈیٹا کو دوسرے ڈیٹا سینٹر میں نقل کیا جاتا ہے جو جغرافیائی محل وقوع کے ساتھ ساتھ Dropbox Cloud Storage پر محفوظ کردہ بیک اپ ڈیٹا کے لحاظ سے مختلف ہوتا ہے۔ .

کیا فیل اوور کا عمل ایک فعال/فعال، خودکار سوئچ اوور عمل ہے؟

پرائمری ڈیٹا سینٹر کے اندر سرور کی مثال کی ناکامی کو Azure WAG لوڈ بیلنسرز کے ذریعے ہینڈل کیا جاتا ہے، اس مسئلے کے مثال کے طور پر ری سائیکل اور/یا ہٹا کر ایک نئی مثال کے ساتھ تبدیل کیا جاتا ہے۔

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