ความปลอดภัย
ความปลอดภัยที่ให้ความรู้สึกเหมือนการต้อนรับ
ผู้ให้บริการข้อมูลประจำตัวจะดีได้ก็ต่อเมื่อกำแพงระหว่างผู้เช่าแข็งแรง และดูแลข้อมูลลับอย่างใส่ใจ นี่คือวิธีที่ Usher Identity ถูกสร้างขึ้น เราอธิบายสิ่งที่ซอฟต์แวร์ทำ โดยไม่ได้อ้างว่าได้รับการรับรองใดๆ
สถาปัตยกรรม
โดเมนแยกกัน เครือข่ายแยกกัน
หน้าเว็บของ Usher Identity เองและ Issuer ของลูกค้าทุกรายอยู่บนโดเมนที่จดทะเบียนต่างกัน ฐานข้อมูลอยู่บนเครือข่ายที่เข้าถึงอินเทอร์เน็ตไม่ได้ และทางออกเดียวคือพร็อกซีที่ตรวจสอบปลายทางทุกครั้ง
- Caddy จัดการ TLS ให้ทุกโฮสต์ และตัดเฮดเดอร์ที่มีเพียงบริการของ Usher Identity เองเท่านั้นที่ตั้งได้ออก
- ชั้นการยืนยันตัวตนตอบคำขอให้ทุกสภาพแวดล้อม โดยแยกแยะจากโฮสต์ ไม่มีสิ่งใดที่แคชไว้สำหรับโฮสต์หนึ่งแล้วถูกส่งให้อีกโฮสต์หนึ่ง
- แต่ละบริการเชื่อมต่อ Valkey ในฐานะผู้ใช้ของตัวเอง และเข้าถึงได้เฉพาะคีย์ของตัวเอง ไม่มีผู้ใช้เริ่มต้น
- คำสั่งที่มีโทเค็นและรหัสจะไม่ถูกเขียนลงในล็อกของฐานข้อมูลพร้อมกับค่าของมัน
อินเทอร์เน็ต
ผู้คน แอปของคุณ เซิร์ฟเวอร์ของคุณ
Edge
Caddy: TLS, HSTS, ตัดเฮดเดอร์ภายในออก
usheridentity.com
เว็บไซต์และ Console
usheridentity.com, console.usheridentity.com
API
api.usheridentity.com
*.usherid.com
ชั้นการยืนยันตัวตน
Issuer และ Lobby ของทุกสภาพแวดล้อม
เครือข่ายข้อมูล · ไม่มีเส้นทางออก
Postgres
หนึ่งสคีมาต่อหนึ่งสภาพแวดล้อม
Valkey
แต่ละบริการเข้าถึงได้เฉพาะคีย์ของตัวเอง
ทางออกเดียว
พร็อกซีขาออก
สำหรับทุก URL ที่ลูกค้าระบุ
Discovery, JWKS, การลงชื่อออก
เฉพาะที่อยู่สาธารณะ
การแยกส่วน
ไม่มีสิ่งสำคัญใดที่ใช้ร่วมกัน
แต่ละสภาพแวดล้อมของโปรเจกต์มีสคีมา Postgres คีย์ลงนาม และข้อมูลลับที่ปิดผนึกด้วยคีย์ข้อมูลเป็นของตัวเอง Issuer ของสภาพแวดล้อมคือโฮสต์บนโดเมนผู้เช่า และคุกกี้เป็นแบบ host-only เบราว์เซอร์จึงไม่มีทางส่งคุกกี้ของสภาพแวดล้อมหนึ่งไปให้อีกสภาพแวดล้อมหนึ่ง
usheridentity.com
เว็บไซต์ Usher Identity Console และบัญชี Usher Identity
*.usherid.com
หนึ่ง Issuer ต่อหนึ่งสภาพแวดล้อม บนโดเมนที่แยกต่างหาก
ผู้ใช้ เซสชัน และโทเค็นอยู่ในสคีมาที่สร้างขึ้นสำหรับสภาพแวดล้อมนี้ คิวรีทำงานกับสคีมานั้น ไม่เคยทำงานกับตารางที่ใช้ร่วมกันซึ่งมีคอลัมน์ tenant
คัดลอก Client secret ของ Google ที่ปิดผนึกไว้ของ Acme (ใช้งานจริง) ไปยัง Northwind (ใช้งานจริง)
การเข้ารหัสข้อมูลที่จัดเก็บ
การเข้ารหัสแบบ envelope ที่ผูกไว้กับที่ของมัน
ข้อมูลลับที่คุณให้ Usher Identity จะถูกปิดผนึกด้วย AES-256-GCM ภายใต้คีย์ข้อมูลที่เป็นของสภาพแวดล้อมเดียว คีย์ข้อมูลเหล่านี้ถูกห่อหุ้มอีกชั้นด้วยคีย์หลักที่มีการกำหนดเวอร์ชันและเก็บไว้นอกฐานข้อมูล
- คีย์ข้อมูลแยกตามสภาพแวดล้อม
- หากคีย์ข้อมูลของสภาพแวดล้อมหนึ่งรั่วไหล ก็ไม่เปิดเผยสิ่งใดเกี่ยวกับคีย์ของสภาพแวดล้อมอื่น
- การผูก AAD
- สภาพแวดล้อมและวัตถุประสงค์ถูกผูกไว้ในข้อความที่เข้ารหัสทุกชิ้น ค่าจึงย้ายข้ามแถวหรือข้ามผู้เช่าไม่ได้
- คีย์ที่มีเวอร์ชัน
- ค่าที่ปิดผนึกแต่ละค่าบันทึกเวอร์ชันของคีย์ที่ใช้สร้างไว้ จึงหมุนเวียนคีย์และห่อหุ้มค่าเก่าใหม่ได้
- ยืนยันความถูกต้องได้
- แท็กของ GCM ทำให้ค่าที่ถูกดัดแปลงเปิดไม่ได้ แทนที่จะถอดรหัสออกมาเป็นอย่างอื่น
คีย์หลัก
เก็บไว้นอกฐานข้อมูล มีการกำหนดเวอร์ชัน
คีย์ข้อมูล หนึ่งคีย์ต่อหนึ่งสภาพแวดล้อม
ห่อหุ้มด้วยคีย์หลัก
ข้อมูลลับ
ปิดผนึกด้วย AES-256-GCM ภายใต้คีย์ข้อมูล
u1.<key version>.<iv>.<ciphertext + tag>
aad = u1 | version | environment | purpose
แนวปฏิบัติ
รายละเอียดที่ทำอย่างพิถีพิถัน
รหัสผ่าน หากคุณใช้
แฮชด้วย Argon2id ตามค่าที่ OWASP แนะนำ (19 MiB สองรอบ) และจำกัดจำนวนที่ทำงานพร้อมกัน เพื่อไม่ให้การลงชื่อเข้าจำนวนมหาศาลทำให้บริการล่ม รหัสผ่านใหม่จะถูกตรวจสอบกับข้อมูลที่รั่วไหลที่ทราบกันผ่าน Range API ของ Have I Been Pwned ซึ่งเห็นเพียงส่วนต้นสั้นๆ ของแฮชรหัสผ่าน ความยาวขั้นต่ำเริ่มต้นคือ 12 ตัวอักษร
ไม่เก็บสิ่งใดที่นำไปใช้ซ้ำได้
Client secret โทเค็น โทเค็นของลิงก์ลงชื่อเข้า และรหัสทางอีเมล ถูกจัดเก็บในรูปแฮช รหัสสำรองถูกเข้ารหัส รหัสการอนุญาตมีอายุห้านาที และรหัสทางอีเมลลองได้สามครั้ง
จำกัดอัตราที่ทุกประตู
การลงชื่อเข้า การสมัคร รหัสทางอีเมล ลิงก์ลงชื่อเข้า การรีเซ็ตรหัสผ่าน และการตรวจสอบปัจจัยที่สอง ต่างก็มีขีดจำกัดของตัวเอง เช่น ลงชื่อเข้าด้วยรหัสผ่านได้สิบครั้งต่อนาที และส่งรหัสทางอีเมลได้ห้าครั้งต่อสิบนาที
Content-Security-Policy ที่เข้มงวด
ทุกหน้าของ Lobby ได้รับ nonce ใหม่และนโยบายที่สร้างขึ้นรอบ nonce นั้น: มีเพียงสคริปต์จาก origin นี้ที่มี nonce เท่านั้นที่ทำงาน แบบฟอร์มส่งข้อมูลไปยัง origin เดียวกันเท่านั้น และเว็บไซต์อื่นใส่หน้านี้ไว้ในเฟรมไม่ได้
บันทึกการตรวจสอบที่ไว้ใจได้
การเปลี่ยนแปลงเวิร์กสเปซ โปรเจกต์ และสภาพแวดล้อมจะถูกเขียนลงในล็อกที่เพิ่มได้อย่างเดียว แต่ละรายการเชื่อมโยงด้วยแฮชกับรายการก่อนหน้า รายการที่ถูกแก้ไขหรือหายไปจึงปรากฏให้เห็น
พร็อกซีขาออกสำหรับ URL ของลูกค้า
ทุกคำขอที่ Usher Identity ส่งไปยังที่อยู่ที่ลูกค้าให้ไว้ (OIDC discovery, JWKS, การลงชื่อออกผ่าน Back-channel) จะออกผ่านพร็อกซีเดียว พร็อกซีจะแปลงชื่อเป็นที่อยู่เพียงครั้งเดียว ปฏิเสธที่อยู่ส่วนตัว loopback, link-local และที่อยู่ข้อมูลเมตาของคลาวด์ แล้วเชื่อมต่อไปยังที่อยู่ที่ตรวจสอบแล้ว DNS rebinding จึงเปลี่ยน URL ของลูกค้าให้กลายเป็น URL ภายในไม่ได้
แฮนเดิลที่ไม่มีวันมอบให้ซ้ำ
แฮนเดิลของสภาพแวดล้อมใช้งานจริงคือส่วนแรกของ Issuer Console เปิดให้ใช้เฉพาะผู้ที่ได้รับคำเชิญ Lobby ที่ถูกรายงานว่าใช้ฟิชชิงจะถูกระงับ และแฮนเดิลที่เคยใช้แล้วจะไม่ถูกมอบให้ใครอีก เพราะแอปเก่าอาจยังเชื่อถือโทเค็นของแฮนเดิลนั้นอยู่
เซสชันที่สิ้นสุดเมื่อคุณสั่ง
Usher Identity ตรวจสอบเซสชันของตัวเองในทุกคำขอ แทนที่จะเชื่อสำเนาที่แคชไว้ เซสชันที่คุณยุติจึงสิ้นสุดทันที โทเค็นการเข้าถึงมีอายุสั้น (ค่าเริ่มต้นสิบนาที) และ API ของคุณทำ introspection โทเค็นเหล่านี้ได้
การเปิดเผยช่องโหว่อย่างรับผิดชอบ
พบอะไรบางอย่างใช่ไหม บอกเราก่อน
หากคุณคิดว่าพบปัญหาด้านความปลอดภัยใน Usher Identity เรายินดีรับฟัง และจะทำงานร่วมกับคุณเพื่อแก้ไข
- สิ่งที่คุณพบ พบที่ไหน และวิธีทำให้เกิดขึ้นซ้ำ
- สิ่งที่ผู้อื่นอาจทำได้ด้วยปัญหานี้ ตามที่คุณเข้าใจ
- ช่องทางที่เราติดต่อคุณได้ และคุณต้องการให้เราระบุชื่อเป็นเครดิตหรือไม่
โปรดทดสอบเฉพาะกับสภาพแวดล้อมที่คุณเป็นเจ้าของ อย่าเข้าถึงข้อมูลของผู้อื่น และให้เวลาเราแก้ไขปัญหาตามสมควรก่อนที่คุณจะเปิดเผย หากต้องการรายงานหน้าที่แอบอ้างเป็นหน้าลงชื่อเข้าของ Usher Identity โปรดดู รายงานการละเมิด