เจาะลึก simpliSSO: โครงการ SSO 12 โมดูลส่งมอบอะไรบ้างจริง ๆ ตั้งแต่เชื่อม Azure AD จนถึง ERP รุ่นเก่าระบบสุดท้าย

ที่ผ่านมาเราเขียนถึง เหตุผล ที่องค์กรซึ่งมีระบบภายในหลายสิบระบบต้องมีชั้นจัดการตัวตนกลางมาแล้วสองครั้ง ครั้งแรกคือเรื่อง ความเสี่ยงที่ซ่อนอยู่ในองค์กรวิศวกรรม ครั้งที่สองคือ พนักงานมี 24 รหัสผ่าน ธุรกิจก็มี 24 ช่องโหว่ และเมื่อเดือนสิงหาคม เราเพิ่มบทความที่สามว่าเมื่อองค์กรเริ่มใช้ Passkey จุดลงทะเบียนคือช่องโหว่ใหม่ และการแก้ไขเกือบทั้งหมดอยู่ที่ Identity Provider

บทความนี้พูดถึงตัวผลิตภัณฑ์ที่อยู่เบื้องหลังข้อโต้แย้งทั้งหมดนั้น simpliSSO คือ Identity Portal ที่ Simplico สร้างและส่งมอบให้ลูกค้า ประกอบด้วย Authentik ทำหน้าที่ Identity Provider เชื่อมต่อ (Federation) กับ Microsoft 365 / Azure AD ของบริษัท และวางตัวอยู่หน้าระบบภายในทุกระบบ ด้านล่างนี้คือสิ่งที่อยู่ในโครงการจริง ๆ โมดูลทั้ง 12 ทำงานร่วมกันอย่างไร โค้ดที่เขียนเพิ่มทำอะไร และที่สำคัญไม่แพ้กันคือ อะไรที่ต้องกำหนดขอบเขตแยกตามโครงการ และอะไรที่อยู่นอกขอบเขต

1. โจทย์ที่ simpliSSO ถูกออกแบบมารองรับ

ตัวอย่างการติดตั้งอ้างอิงบนหน้าผลิตภัณฑ์ไม่ใช่โจทย์ของเล่น แต่เป็นรูปแบบจริง: 24 ระบบ 3 โปรโตคอล 12 โมดูล ใช้งานจริงใน 10 สัปดาห์ และ 24 ระบบนั้นไม่ใช่เว็บแอปสมัยใหม่ทั้งหมด แต่เป็นส่วนผสมที่โรงงานและบริษัทจัดจำหน่ายขนาดกลางในไทยคุ้นเคยดี:

• เว็บแอปภายในรุ่นใหม่ (รายงานอายุลูกหนี้ รายงานคลังสินค้า ระบบควบคุมเอกสาร IT Service ระบบอนุมัติ รายงานโครงการ)
• ERP รุ่นเก่าอย่าง Infor M3 ที่รองรับ SAML2 แต่ใช้ชื่อ Attribute ไม่ตรงมาตรฐาน
• เครื่องมือสื่อสารอย่าง WhatsApp Business และตู้สาขา IP Phone 3CX ที่ไม่รู้จักคำว่า SSO เลย
• ฮาร์ดแวร์อย่างเครื่องพิมพ์ Kyocera เครื่องพิมพ์ฉลาก และระบบหุ่นยนต์ในคลังสินค้า ที่ยืนยันตัวตนได้แค่ผ่าน LDAP หรือทำไม่ได้เลย

ถ้าผลิตภัณฑ์รองรับได้แค่กลุ่มแรก ก็ครอบคลุมได้ราวครึ่งหนึ่งของระบบทั้งหมด และทิ้งครึ่งที่เสี่ยงที่สุดไว้ไม่ได้แตะ simpliSSO จึงถูกออกแบบให้รองรับส่วนผสมทั้งหมดนี้ตั้งแต่ต้น

2. สามโปรโตคอล สามระดับ หนึ่ง Identity Provider

สถาปัตยกรรมเป็นแบบศูนย์กลางเดียว Azure AD ยังเป็นแหล่งข้อมูลหลักว่าพนักงานแต่ละคนคือใคร Authentik เป็นจุดเดียวที่ตัดสินว่าแต่ละคนเข้าถึงอะไรได้และออก Token ให้ และทุกแอปเชื่อมต่อกับ Authentik ด้วยโปรโตคอลที่แอปนั้นรองรับได้จริง

flowchart TD
    STAFF["พนักงาน"] --> PORTAL["App Portal แสดง Tile แอป"]
    PORTAL --> AK["Authentik Identity Provider"]
    AK --> AAD["Microsoft 365 และ Azure AD"]
    AAD --> AK
    AK --> POL["Policy และ Step up MFA"]
    AK --> OIDC["OIDC Provider"]
    AK --> SAML["SAML2 Provider"]
    AK --> LDAP["LDAP Outpost"]
    OIDC --> MAP["Property Mapping เพิ่ม Role ของ ERP"]
    MAP --> T1["ระดับ 1 เว็บแอป"]
    SAML --> T1
    LDAP --> T3["ระดับ 3 เครื่องพิมพ์และฮาร์ดแวร์รุ่นเก่า"]
    PORTAL --> T2["ระดับ 2 WhatsApp และ 3CX ผ่านการผูกบัญชี"]

ระดับ 1 — เว็บแอปผ่าน OIDC และ SAML2 แอปสมัยใหม่ใช้ OpenID Connect และได้รับ JWT ที่มีลายเซ็น ส่วน ERP รุ่นเก่าใช้ SAML2 Authentik รัน Provider ทั้งสองแบบพร้อมกัน ระบบลูกหนี้ตัวใหม่และ ERP อายุสิบห้าปีจึงล็อกอินผ่านประตูเดียวกัน

ระดับ 2 — เครื่องมือสื่อสารผ่านการผูกบัญชี WhatsApp และ 3CX ใช้ OIDC Token ไม่ได้ จึงใช้ Stage แบบกำหนดเองที่ผูกเบอร์ WhatsApp และเบอร์ต่อ 3CX ของพนักงานแต่ละคนเข้ากับบัญชี Azure AD ตั้งแต่การล็อกอินครั้งแรก แล้ว Tile บน Portal จะพาไปยังแชตหรือหน้าโทรศัพท์ที่ยืนยันตัวตนไว้แล้ว

ระดับ 3 — ฮาร์ดแวร์ผ่าน LDAP เครื่องพิมพ์ เครื่องพิมพ์ฉลาก และอุปกรณ์ที่ไม่รองรับ OIDC หรือ SAML2 จะยืนยันตัวตนกับ LDAP Outpost ที่ Authentik ติดตั้งให้ ส่วนระบบหุ่นยนต์ที่ทำแม้แต่ LDAP ไม่ได้ จะเข้าถึงผ่านลิงก์จาก Portal เท่านั้น

Azure AD เป็นค่าเริ่มต้น แต่ไม่ใช่ข้อบังคับ Authentik เชื่อมต่อกับ Google Workspace, Okta, OIDC หรือ SAML2 ทั่วไปได้ และที่สำคัญสำหรับโรงงานที่ต้องแยกเครือข่ายหรือใช้งานแบบ On-premise ล้วน คือเชื่อมกับ Active Directory หรือ OpenLDAP ภายในองค์กรได้โดยตรงโดยไม่ต้องออกคลาวด์ และยังใช้หลายแหล่งพร้อมกันได้ เช่น Microsoft 365 สำหรับพนักงาน และ LDAP สำหรับผู้รับเหมา

3. โมดูลทั้ง 12

แต่ละโมดูลกำหนดขอบเขตและราคาแยกกัน สามโมดูลเป็นข้อบังคับ ที่เหลือแบ่งเฟสหรือตัดออกได้ก่อนเซ็นสัญญา โดยปรับราคาตามสัดส่วน

โมดูล	สิ่งที่ส่งมอบ	สถานะในโครงการมาตรฐาน
F-01 เชื่อม MS365 / Azure AD	ใช้ Azure เป็น IdP ต้นทาง ส่งต่อ MFA และ Conditional Access	บังคับ
F-02 ติดตั้งและเสริมความปลอดภัย Authentik	Docker Compose สำหรับ Production พร้อม PostgreSQL, Redis, Nginx TLS, Backup, Admin Portal และ Branding	บังคับ
F-03 ลงทะเบียนแอปทั้งหมด	ลงทะเบียนทุกระบบเป็นแอป OIDC หรือ SAML2 กำหนดสิทธิ์ตามกลุ่ม เก็บค่าเป็น Blueprint YAML	บังคับ
F-05 JWT Claims สำหรับ Role ของ ERP	ฝังรหัสบริษัท ฝ่าย และ Role ของ ERP ไว้ใน Token	แบ่งเฟสได้
F-06 Step-up MFA	บังคับยืนยัน MFA ซ้ำเมื่อเข้าระบบที่กำหนดว่าอ่อนไหว	แบ่งเฟสได้
F-07 App Portal	FastAPI แสดงเฉพาะแอปที่ผู้ใช้มีสิทธิ์ พร้อมชื่อภาษาไทย/อังกฤษ	แบ่งเฟสได้
F-08 ผูกบัญชี WhatsApp	ผูกเบอร์ WhatsApp ของพนักงานกับบัญชีในไดเรกทอรี	แบ่งเฟสได้
F-09 ผูกเบอร์ต่อ 3CX	ผูกเบอร์ต่อกับบัญชี Tile เปิดโทรศัพท์บนเว็บที่ล็อกอินไว้แล้ว	แบ่งเฟสได้
F-10 แก้ปัญหา SAML2 ของ Infor M3	แปลง SAML2 ของ Authentik ให้ตรงกับ Attribute และ NameID ที่ M3 ต้องการ	แบ่งเฟสได้
F-11 หน้าจอภาษาไทย	หน้าล็อกอิน MFA ข้อความแจ้งข้อผิดพลาด และรีเซ็ตรหัสผ่านเป็นภาษาไทย พร้อม Branding	แบ่งเฟสได้
F-12 ทดสอบและ UAT	ทดสอบทุกระบบแบบครบวงจร รวมกรณี Token หมดอายุ MFA ล้มเหลว และ SAML ไม่ตรงกัน	รวมอยู่แล้ว
F-13 เอกสารและการส่งมอบ	แผนภาพสถาปัตยกรรม คู่มือผู้ดูแล คู่มือรับเข้าและออกจากงาน ภาษาไทยและอังกฤษ พร้อมเซสชันส่งมอบ	รวมอยู่แล้ว

ตารางนี้มีสองประเด็นที่ควรสังเกต ประเด็นแรก ส่วนที่บังคับมีขนาดเล็กจริง ๆ คือการเชื่อม Azure AD การติดตั้งที่เสริมความปลอดภัยแล้ว และการลงทะเบียนแอป บริษัทที่ต้องการแค่ "ล็อกอินครั้งเดียวสำหรับเว็บแอป" หยุดแค่นั้นได้ ประเด็นที่สอง โมดูลที่แบ่งเฟสได้ส่วนใหญ่มีอยู่เพราะระบบจริงทุกที่มีระบบที่ "ไม่ยอมทำตามมาตรฐาน" อย่างน้อยหนึ่งตัว ทั้ง ERP ที่ Attribute แปลก ระบบโทรศัพท์ที่ไม่รู้จัก SSO และพนักงานหน้างานที่ต้องการหน้าล็อกอินภาษาไทย

4. ชั้น Python ที่เขียนเพิ่ม และเหตุผลที่มันเป็นของคุณ

ส่วนของ simpliSSO ที่ไม่ใช่ Authentik สำเร็จรูป คือชั้น Python บาง ๆ ที่รัน ภายใน Authentik ในรูปแบบ Expression Policy, Property Mapping และ Django Stage ไม่มีบริการภายนอกที่ต้องดูแลเพิ่ม และโค้ด Python ทั้งหมดจะเป็นทรัพย์สินทางปัญญาของลูกค้าเมื่อชำระเงินงวดสุดท้าย

การกำหนด Claim (F-05) Property Mapping ใส่ข้อมูลของ ERP เช่น บริษัท ฝ่าย และ Role ใน M3 รวมถึงระดับสิทธิ์ในระบบลูกหนี้ ไว้ใน Token โดยตรง แอปอ่าน Role จาก Token แทนการมีตารางสิทธิ์ของตัวเอง นี่คือความต่างระหว่าง "SSO เพื่อล็อกอิน" กับ "SSO เพื่อกำหนดสิทธิ์" เมื่อพนักงานย้ายฝ่ายใน Azure AD Role ใน ERP จะเปลี่ยนตามทุกที่ตั้งแต่การล็อกอินครั้งถัดไป ไม่ต้องรอให้ใครจำได้ว่าต้องไปแก้อีกระบบ

Step-up MFA (F-06) Expression Policy ราว 20 บรรทัด ตรวจว่าแอปปลายทางอยู่ในรายการระบบอ่อนไหวหรือไม่ และการยืนยัน MFA ครั้งล่าสุดเกิน 30 นาทีแล้วหรือยัง ถ้าใช่ทั้งสองข้อ Authentik จะขอยืนยันซ้ำก่อนออก Token ที่มีสิทธิ์สูงขึ้น การใช้งานประจำวันส่วนใหญ่จะไม่เจอขั้นตอนนี้ แต่ระบบการเงินและระบบผู้ดูแลไอทีจะเจอเสมอ

การแก้ปัญหา M3 (F-10) Infor M3 ต้องการชื่อ Attribute และรูปแบบ NameID ที่ไม่ตรงกับ SAML2 ตามมาตรฐาน แทนที่จะไปแก้ ERP เราแปลงค่าที่ฝั่ง Identity Provider แทน โมดูลแบบนี้มีอยู่ได้ก็เพราะเคยมีคนเสียเวลากับปัญหานี้ไปแล้วทั้งสัปดาห์

App Portal (F-07) FastAPI สร้างหน้า Portal ที่แสดงเฉพาะแอปที่ผู้ใช้มีสิทธิ์ พร้อมไอคอน ชื่อภาษาไทย/อังกฤษ และลิงก์ตรง หน้านี้เป็นหน้าแรกที่พนักงานเห็น และสร้างจาก Policy ชุดเดียวกับที่ใช้ควบคุมสิทธิ์ Portal จึงไม่มีทางแสดงแอปที่ Policy จะปฏิเสธ

5. เพิ่มแอปอีกหนึ่งระบบ ต้องทำอะไรบ้าง

สิ่งที่แอปใหม่ต้องมีคือตัวแปรสภาพแวดล้อมเพียงสี่ตัว:

OIDC_CLIENT_ID     = "your-app-client-id"
OIDC_CLIENT_SECRET = "your-app-client-secret"
SESSION_SECRET     = "random-256-bit-string"
OIDC_ISSUER_URL    = "https://sso.example.com/application/o/<app-slug>/"

OIDC Provider แต่ละตัวของ Authentik เผยแพร่เอกสาร Discovery ที่ .well-known/openid-configuration แอปจึงดึง Endpoint คีย์สำหรับตรวจลายเซ็น และ Scope ที่รองรับ (รวมถึง Claim ของ ERP) ได้จาก URL เดียว หน้าผลิตภัณฑ์มีตัวอย่างที่ใช้งานได้จริงสำหรับ FastAPI, Django, Express และ PHP ทุกกรณีแอปจะ Redirect ไปที่ Authentik รับ Callback แล้วอ่านกลุ่มและ Role จาก Token ไม่ต้องเขียนระบบยืนยันตัวตนเอง และไม่มีตารางรหัสผ่านรายแอปให้ลืมปิดตอนพนักงานลาออก

6. ส่งมอบใน 10 สัปดาห์ จ่ายเงินตามผลงานที่ใช้งานได้จริง

การติดตั้งแบ่งเฟสเพื่อพิสูจน์ว่ารากฐานใช้งานได้ก่อนเริ่มงานปรับแต่ง:

flowchart TD
    W1["สัปดาห์ 1 ถึง 2 โครงสร้างพื้นฐาน F01 F02"] --> W3["สัปดาห์ 3 ถึง 4 SSO หลัก F03"]
    W3 --> W5["สัปดาห์ 5 Claim ของ ERP Step up MFA และ M3"]
    W5 --> W6["สัปดาห์ 6 หน้าจอภาษาไทยและ Branding"]
    W6 --> W7["สัปดาห์ 7 ถึง 8 Portal WhatsApp และ 3CX"]
    W7 --> W9["สัปดาห์ 9 ถึง 10 ทดสอบ UAT และส่งมอบ"]

การชำระเงินผูกกับผลงานที่ตรวจรับแล้ว ไม่ใช่วันที่ในปฏิทิน: 30% เมื่อเซ็นสัญญา 40% เมื่อการเชื่อม Microsoft 365 ใช้งานได้และแอปห้าระบบแรกเชื่อมต่อแล้ว และ 30% สุดท้ายเมื่อทุกระบบใช้งานจริงและเซ็นรับ UAT หลังเปิดใช้งาน มีบริการดูแลรายเดือนแบบเลือกได้สามระดับ (ตอบกลับภายในวันทำการถัดไป ภายใน 4 ชั่วโมงทำการ หรือภายใน 2 ชั่วโมงทำการ) ยกเลิกได้โดยแจ้งล่วงหน้า 30 วันเป็นลายลักษณ์อักษร

7. มุมมองสำหรับองค์กรไทย: PDPA และหลักฐานการควบคุมการเข้าถึง

สำหรับองค์กรไทย ประเด็นที่ทำให้ SSO มีน้ำหนักมากกว่าความสะดวก คือ พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล มาตรา 37 กำหนดให้ผู้ควบคุมข้อมูลต้องจัดให้มีมาตรการรักษาความมั่นคงปลอดภัยที่เหมาะสม และประกาศคณะกรรมการคุ้มครองข้อมูลส่วนบุคคลเรื่องมาตรการรักษาความมั่นคงปลอดภัยได้ระบุรายละเอียดถึงการควบคุมการเข้าถึง การบริหารจัดการสิทธิ์ของผู้ใช้ และการจัดให้มีวิธีตรวจสอบย้อนหลังว่าใครเข้าถึงข้อมูลเมื่อใด

เมื่อระบบ 24 ระบบมีบัญชีและ Log แยกกัน การตอบคำถามเหล่านี้ต้องใช้เวลาหลายสัปดาห์ เมื่อทุกระบบผ่าน Authentik การให้สิทธิ์ตามกลุ่ม การเพิกถอนสิทธิ์ทันทีผ่าน SCIM เมื่อพนักงานลาออก และ Blueprint YAML ที่เก็บค่าตั้งเป็นเวอร์ชัน คือหลักฐานการควบคุมที่ตรวจสอบได้ สำหรับหน่วยงานที่เป็นโครงสร้างพื้นฐานสำคัญทางสารสนเทศตาม พ.ร.บ. การรักษาความมั่นคงปลอดภัยไซเบอร์ ชั้นจัดการตัวตนกลางยังช่วยให้ทำตามข้อกำหนดด้านการควบคุมการเข้าถึงได้ง่ายกว่าการไล่ตั้งค่าทีละระบบมาก

อีกประเด็นที่สำคัญในทางปฏิบัติ คือพนักงานหน้างานในโรงงานแถบ EEC จำนวนมากใช้งานภาษาไทยเป็นหลัก โมดูล F-11 ทำให้หน้าล็อกอิน คำขอ MFA และข้อความแจ้งข้อผิดพลาดเป็นภาษาไทย ซึ่งช่วยลดจำนวนเคสที่พนักงานโทรหาไอทีเพราะอ่านหน้าจอไม่เข้าใจได้จริง

8. อะไรส่งมอบแล้ว อะไรทำตามโครงการ และอะไรอยู่นอกขอบเขต

เรื่องตัวตนดิจิทัลเป็นเรื่องที่การกล่าวอ้างเกินจริงสร้างความเสียหายได้จริง เราจึงขอขีดเส้นให้ชัด

ส่งมอบเป็นโมดูลที่ระบุไว้: การเชื่อม Azure AD พร้อมส่งต่อ MFA, Authentik แบบติดตั้งเองที่เสริมความปลอดภัยแล้ว, การลงทะเบียนแอป OIDC และ SAML2, LDAP Outpost สำหรับฮาร์ดแวร์, SCIM สำหรับสร้างและปิดบัญชีจาก Azure AD พร้อมยกเลิก Session, การกำหนดสิทธิ์ตามกลุ่ม, Claim สำหรับ ERP, Step-up MFA, App Portal, การผูก WhatsApp และ 3CX, ตัวแปลง SAML2 สำหรับ M3, หน้าจอภาษาไทย, การทดสอบ และเอกสารสองภาษา

ตั้งค่าตามโครงการ ไม่ใช่โมดูลแยก: นโยบายการลงทะเบียน Passkey และ WebAuthn Authentik รองรับการสร้าง Flow สำหรับลงทะเบียนโดยเฉพาะที่มี Stage และ Policy ของตัวเอง และแนวทางเสริมความปลอดภัยจาก บทความเรื่องการลงทะเบียน Passkey เช่น การบังคับ Step-up ก่อนลงทะเบียน การจำกัดช่องทางกู้คืน และการแจ้งเตือนเมื่อมีการเปลี่ยน Credential ของบัญชีสิทธิ์สูง จะถูกตั้งค่าเป็นส่วนหนึ่งของงาน Policy สำหรับลูกค้าที่ต้องการ แต่ไม่ใช่ฟีเจอร์สำเร็จรูปที่มีรายการราคาแยก เช่นเดียวกับการเชื่อม Log ด้านตัวตนเข้า SIEM อย่าง simpliSOC Log มีอยู่แล้ว แต่การต่อเข้าระบบแจ้งเตือนเป็นงานที่กำหนดขอบเขตแยก ส่วนการผูกบัญชีกับ LINE ซึ่งองค์กรไทยใช้มากกว่า WhatsApp ก็ทำได้ในรูปแบบ Stage แบบกำหนดเองเช่นกัน แต่ไม่ได้อยู่ในรายการโมดูลมาตรฐาน และต้องประเมินเป็นรายโครงการ

นอกขอบเขต: ตัวฮาร์ดแวร์เอง เครื่องพิมพ์ ระบบฉลาก และหุ่นยนต์เป็นของลูกค้า simpliSSO มีลิงก์จาก Portal ไปยังอุปกรณ์เหล่านั้นเท่าที่ทำได้ทางเทคนิค แต่ไม่ได้เปลี่ยนหรือตั้งค่าเฟิร์มแวร์ของอุปกรณ์

9. เหมาะกับใคร

simpliSSO เหมาะกับองค์กรที่ใช้ Microsoft 365 อยู่แล้ว (หรือไดเรกทอรีอื่นที่รองรับมาตรฐาน) มีระบบภายในตั้งแต่สิบถึงหลายสิบระบบ และมีระบบรุ่นเก่าอย่างน้อยหนึ่งระบบที่บริการ SSO แบบ SaaS ล้วนจะทิ้งไว้ข้างหลัง และเหมาะเป็นพิเศษกับองค์กรที่ทีมไอทีต้องการดูแลระบบเองบนโครงสร้างพื้นฐานของตัวเองหลังส่งมอบ ใช้ Docker Compose บนเครื่อง 4 vCPU / 8 GB และเก็บค่าตั้งเป็น Blueprint YAML ที่มีเวอร์ชัน ไม่ใช่เก็บไว้ในความจำของใครคนหนึ่ง

แต่ถ้าคุณมีเครื่องมือ SaaS แค่ห้าตัวและไม่มีระบบ On-premise เลย บริการ Identity แบบโฮสต์จะง่ายกว่า

คำถามที่พบบ่อย

simpliSSO มาแทน Azure AD หรือไม่?

ไม่ Azure AD ยังเป็นไดเรกทอรีหลัก และยังดูแลรหัสผ่าน MFA และ Conditional Access ตามเดิม Authentik ไม่เก็บรหัสผ่านของพนักงาน แต่เชื่อมต่อขึ้นไปยัง Azure AD และออก Token ลงไปให้แต่ละแอป

ใช้งานโดยไม่มี Microsoft 365 ได้ไหม?

ได้ Authentik เชื่อมกับ Google Workspace, Okta, OIDC หรือ SAML2 ทั่วไป หรือเชื่อมกับ Active Directory / OpenLDAP ภายในองค์กรได้โดยตรง สำหรับโรงงานที่พึ่งไดเรกทอรีบนคลาวด์ไม่ได้

เมื่อพนักงานลาออก จะเกิดอะไรขึ้นกับสิทธิ์?

ฝ่ายไอทีปิดบัญชีครั้งเดียวใน Azure AD SCIM ส่งการเปลี่ยนแปลงไปที่ Authentik ยกเลิก Session ที่ใช้งานอยู่ และทุกแอปที่เชื่อมต่อหยุดรับตัวตนนั้น ถ้ามีการใช้ Passkey หรือ Authenticator อื่น ควรกำหนดใน Policy ให้ลบ Credential ที่ลงทะเบียนไว้ระหว่างการปิดบัญชีด้วย เพราะบัญชีที่ถูกปิดแต่ยังมี Authenticator ผูกอยู่คือความเสี่ยงที่จะถูกเปิดใช้งานกลับมา

รวม Passkey ไว้แล้วหรือยัง?

การเสริมความปลอดภัยการลงทะเบียน Passkey ตั้งค่าตามโครงการเป็นส่วนหนึ่งของงาน Policy ไม่ได้ส่งมอบเป็นโมดูลแยก ดูรายละเอียดในหัวข้อที่ 8

ใครเป็นเจ้าของโค้ดที่เขียนเพิ่ม?

โค้ด Python ทั้งหมด ทั้ง Policy, Mapping และ Stage เป็นทรัพย์สินทางปัญญาของลูกค้าเมื่อชำระเงินงวดสุดท้าย

คิดราคาอย่างไร?

คิดราคาต่อการติดตั้งหนึ่งครั้ง เสนอราคาแบบคงที่หลังพูดคุยกำหนดขอบเขต โมดูลบังคับคือ F-01, F-02 และ F-03 ที่เหลือเพิ่ม แบ่งเฟส หรือตัดออกได้ก่อนเซ็นสัญญา

---

ถ้านับจำนวนการล็อกอินในองค์กรของคุณแล้วรู้สึกไม่สบายใจ บอกเราว่ามีกี่ระบบ ใช้โปรโตคอลอะไร และใช้ไดเรกทอรีต้นทางตัวไหน เราจะกำหนดขอบเขตและเสนอราคาแบบคงที่ให้ภายในการคุยครั้งเดียว: hello@simplico.net โทร (+66) 97 496 6397 WhatsApp (+66) 83 001 0222 หรือ LINE iiitum1984 ดูสถาปัตยกรรมและตัวอย่างการเชื่อมต่อทั้งหมดได้ที่ หน้าผลิตภัณฑ์ simpliSSO

---

แหล่งที่มา:

• simpliSSO — Simplico
• การลงทะเบียน Passkey คือช่องโหว่ใหม่ขององค์กรคุณ — Simplico
• พนักงานของคุณมี 24 รหัสผ่าน ธุรกิจของคุณมี 24 ช่องโหว่ — Simplico
• ความเสี่ยงด้านความปลอดภัยที่ซ่อนอยู่ในองค์กรวิศวกรรมของคุณ — Simplico