مواد پر جائیں

سیکیورٹی

مہمان نوازی جیسی سیکیورٹی۔

شناخت فراہم کنندہ اتنا ہی اچھا ہوتا ہے جتنی مضبوط اس کے ٹیننٹس کے درمیان دیواریں ہوں اور جتنی احتیاط وہ سیکرٹس کے ساتھ برتے۔ Usher Identity کیسے بنا ہے، یہ یہاں ہے۔ ہم بتاتے ہیں کہ سافٹ ویئر کیا کرتا ہے؛ ہم کسی سرٹیفیکیشن کا دعویٰ نہیں کرتے۔

ساخت

الگ ڈومینز، الگ نیٹ ورکس۔

Usher Identity کے اپنے صفحات اور ہر گاہک کا جاری کنندہ مختلف قابلِ رجسٹریشن ڈومینز پر ہوتے ہیں۔ ڈیٹا بیسز ایسے نیٹ ورک پر ہیں جو انٹرنیٹ تک نہیں پہنچ سکتا، اور باہر جانے کا واحد راستہ ایک پراکسی ہے جو جانچتی ہے کہ وہ کہاں جا رہی ہے۔

  • Caddy ہر ہوسٹ کے لیے TLS سنبھالتا ہے اور وہ ہیڈرز ہٹا دیتا ہے جو صرف Usher Identity کی اپنی سروسز سیٹ کر سکتی ہیں۔
  • آتھ ٹیئر ہر انوائرنمنٹ کی طرف سے جواب دیتا ہے، ہوسٹ کے ذریعے ان میں فرق کر کے؛ ایک ہوسٹ کے لیے کیش کی گئی کوئی چیز کسی دوسرے کو نہیں دی جاتی۔
  • ہر سروس Valkey سے اپنے الگ صارف کے طور پر بات کرتی ہے، صرف اپنی کلیدوں تک محدود۔ کوئی ڈیفالٹ صارف نہیں۔
  • ٹوکن اور کوڈ والی اسٹیٹمنٹس کبھی ان کی قدروں سمیت ڈیٹا بیس لاگ میں نہیں لکھی جاتیں۔

انٹرنیٹ

لوگ، آپ کی ایپس، آپ کے سرورز

ایج

Caddy: TLS، HSTS، اندرونی ہیڈرز ہٹاتا ہے

usheridentity.com

سائٹ اور Console

usheridentity.com, console.usheridentity.com

API

api.usheridentity.com

*.usherid.com

آتھ ٹیئر

ہر انوائرنمنٹ کا جاری کنندہ اور لابی

ڈیٹا نیٹ ورک · باہر کا کوئی راستہ نہیں

Postgres

ہر انوائرنمنٹ کے لیے ایک اسکیما

Valkey

ہر سروس صرف اپنی کلیدوں تک محدود

باہر جانے کا واحد راستہ

ایگریس پراکسی

گاہک کے دیے ہوئے ہر URL کے لیے

ڈسکوری، JWKS، لاگ آؤٹ

صرف عوامی پتے

Usher Identity کی پرتیں۔ ٹیننٹ ڈومین پلیٹ فارم کے ڈومین سے مختلف ایک قابلِ رجسٹریشن ڈومین ہے، اس لیے کسی ٹیننٹ کے صفحات کبھی Console کے ساتھ same-site نہیں ہوتے۔

علیحدگی

کوئی اہم چیز مشترک نہیں۔

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

usheridentity.com

سائٹ، Usher Identity Console، Usher Identity اکاؤنٹس

*.usherid.com

ہر انوائرنمنٹ کے لیے ایک جاری کنندہ، الگ ڈومین پر

انوائرنمنٹ

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

Acme پروڈکشن کا مہربند Google کلائنٹ سیکرٹ Northwind پروڈکشن میں کاپی کریں۔

محفوظ شدہ ڈیٹا کی انکرپشن

انویلپ انکرپشن، اپنی جگہ سے بندھی ہوئی۔

جو سیکرٹس آپ Usher Identity کو دیتے ہیں وہ ایک انوائرنمنٹ کی اپنی ڈیٹا کلید کے تحت AES-256-GCM سے مہربند کیے جاتے ہیں۔ ڈیٹا کلیدیں خود ڈیٹا بیس سے باہر رکھی گئی، ورژن والی ماسٹر کلید میں لپٹی ہوتی ہیں۔

ہر انوائرنمنٹ کی اپنی ڈیٹا کلید
ایک انوائرنمنٹ کی ڈیٹا کلید افشا ہونے سے دوسرے کے بارے میں کچھ ظاہر نہیں ہوتا۔
AAD بندش
انوائرنمنٹ اور مقصد ہر سائفر ٹیکسٹ میں بندھے ہوتے ہیں، اس لیے کوئی قدر ایک قطار یا ٹیننٹ سے دوسرے میں منتقل نہیں کی جا سکتی۔
ورژن والی کلیدیں
ہر مہربند قدر اس کلید کا ورژن درج رکھتی ہے جس سے وہ بنی، اس لیے کلیدیں روٹیٹ کی جا سکتی ہیں اور پرانی قدریں دوبارہ لپیٹی جا سکتی ہیں۔
تصدیق شدہ
GCM کے ٹیگ کا مطلب ہے کہ چھیڑ چھاڑ کی گئی قدر کھلتی ہی نہیں، بجائے اس کے کہ کسی اور چیز میں ڈی کرپٹ ہو جائے۔
  1. ماسٹر کلید

    ڈیٹا بیس سے باہر رکھی گئی، ورژن کے ساتھ

  2. ڈیٹا کلید، ہر انوائرنمنٹ کے لیے ایک

    ماسٹر کلید میں لپٹی ہوئی

  3. سیکرٹ

    ڈیٹا کلید کے تحت AES-256-GCM سے مہربند

u1.<key version>.<iv>.<ciphertext + tag>

aad = u1 | version | environment | purpose

مہربند قدر اپنے تصدیق شدہ ڈیٹا میں اپنے انوائرنمنٹ اور مقصد کا نام رکھتی ہے۔ کہیں اور کاپی کی جائے تو کھلتی نہیں۔

طریقۂ کار

تفصیلات، احتیاط سے۔

  • پاس ورڈز، اگر آپ انہیں استعمال کریں

    OWASP کی تجویز کردہ لاگت (19 MiB، دو پاس) پر Argon2id سے ہیش کیے جاتے ہیں، اس حد کے ساتھ کہ ایک وقت میں کتنے چل سکتے ہیں، تاکہ سائن ان کی بھرمار سروس کو بند نہ کر سکے۔ نئے پاس ورڈز Have I Been Pwned کی range API کے ذریعے معلوم لیکس سے ملا کر جانچے جاتے ہیں، جو پاس ورڈ کے ہیش کا صرف ایک چھوٹا سا ابتدائی حصہ دیکھتی ہے۔ کم از کم لمبائی ڈیفالٹ طور پر 12 ہے۔

  • دوبارہ چلائی جا سکنے والی کوئی چیز محفوظ نہیں

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

  • ہر دروازے پر ریٹ لمٹس

    سائن ان، سائن اپ، ای میل سے بھیجے گئے کوڈ، میجک لنکس، پاس ورڈ ری سیٹ اور دوسرے فیکٹر کی جانچ، ہر ایک کی اپنی حد ہے: مثلاً ایک منٹ میں دس پاس ورڈ سائن ان، اور ہر دس منٹ میں پانچ ای میل کوڈ۔

  • ایک سخت Content-Security-Policy

    لابی کے ہر صفحے کو ایک نیا nonce اور اس کے گرد بنی پالیسی ملتی ہے: صرف اسی اوریجن کی وہ اسکرپٹس چلتی ہیں جن میں nonce ہو، فارمز صرف اسی اوریجن پر پوسٹ ہوتے ہیں، اور دوسری سائٹس صفحے کو فریم نہیں کر سکتیں۔

  • ایسا آڈٹ لاگ جس پر بھروسا کیا جا سکے

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

  • گاہکوں کے URLs کے لیے ایگریس پراکسی

    Usher Identity کسی گاہک کے دیے ہوئے پتے پر جو بھی درخواست بھیجتا ہے (OIDC ڈسکوری، JWKS، بیک چینل لاگ آؤٹ)، وہ ایک ہی پراکسی سے باہر جاتی ہے۔ یہ نام کو ایک بار ریزالو کرتی ہے، نجی، لوپ بیک، لنک لوکل اور کلاؤڈ میٹا ڈیٹا پتوں کو مسترد کرتی ہے، اور اسی پتے سے جڑتی ہے جسے اس نے جانچا، اس لیے DNS ری بائنڈنگ گاہک کے URL کو اندرونی URL میں نہیں بدل سکتی۔

  • ہینڈلز جو کبھی دو بار نہیں دیے جاتے

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

  • سیشن جو آپ کے کہنے پر ختم ہوں

    Usher Identity کیش کی گئی نقل پر بھروسا کرنے کے بجائے ہر درخواست پر اپنے سیشنز جانچتا ہے، اس لیے جو سیشن آپ ختم کریں وہ فوراً ختم ہو جاتا ہے۔ ایکسیس ٹوکنز کی مدت مختصر ہوتی ہے (ڈیفالٹ طور پر دس منٹ)، اور آپ کی API ان کا انٹروسپیکشن کر سکتی ہے۔

ذمہ دارانہ انکشاف

کچھ ملا؟ پہلے ہمیں بتائیں۔

اگر آپ کو لگتا ہے کہ آپ کو Usher Identity میں کوئی سیکیورٹی مسئلہ ملا ہے، تو ہم اس کے بارے میں سننا چاہیں گے، اور اسے ٹھیک کرنے کے لیے آپ کے ساتھ مل کر کام کریں گے۔

security@usheridentity.com
  • آپ کو کیا ملا، کہاں، اور اسے دوبارہ کیسے پیدا کیا جائے۔
  • آپ کی سمجھ کے مطابق، کوئی اس سے کیا کر سکتا ہے۔
  • ہم آپ سے کیسے رابطہ کر سکتے ہیں، اور کیا آپ اپنا نام بطور دریافت کنندہ چاہتے ہیں۔

براہ کرم صرف اپنے انوائرنمنٹس پر جانچ کریں، دوسروں کے ڈیٹا تک رسائی نہ کریں، اور مسئلہ کسی اور کو بتانے سے پہلے ہمیں اسے ٹھیک کرنے کے لیے مناسب وقت دیں۔ Usher Identity کا سائن ان ہونے کا دعویٰ کرنے والے صفحے کی اطلاع دینے کے لیے، غلط استعمال کی اطلاع دیں دیکھیں۔