Security

พนักงานของคุณมี 24 รหัสผ่าน ธุรกิจของคุณมี 24 ช่องโหว่

  • June 11, 2026

บริษัทส่วนใหญ่ไม่รู้ว่าตัวเองมีปัญหาด้านการจัดการตัวตนดิจิทัล — จนกว่าจะเกิดเหตุ

บัญชีพนักงานที่ลาออกยังค้างอยู่ในสามระบบ เพราะไม่มีใครอัปเดต Checklist การปิดบัญชี ผู้รับเหมาได้สิทธิ์เข้าถึง Portal ฝ่ายการเงิน เพราะต้องการสิทธิ์ "ชั่วคราว" เมื่อหกเดือนก่อนและไม่มีใครปิดใบงาน การโจมตี Phishing สำเร็จ — ไม่ใช่เพราะระบบรักษาความปลอดภัยบกพร่อง แต่เพราะทีมไอทีต้องดูแลระบบล็อกอิน 24 ระบบแยกกัน และไม่มีใครสังเกตว่าระบบหนึ่งไม่มี MFA

นี่คือความเป็นจริงของธุรกิจขนาดกลางที่มีระบบภายในระหว่าง 15 ถึง 30 ระบบ ไม่ใช่ความประมาท แต่เป็นความซับซ้อนที่โตเร็วกว่าโครงสร้างพื้นฐานในการจัดการ

บริการที่เกี่ยวข้อง

ปัญหาไม่ได้อยู่ที่คนของคุณ

เมื่อพนักงานใช้รหัสผ่านซ้ำข้ามระบบ นั่นไม่ใช่ปัญหาวินัย — แต่เป็นปัญหาการออกแบบระบบ เมื่อฝ่ายไอทีใช้เวลาสามวันในการปิดสิทธิ์พนักงานที่ลาออก นั่นไม่ใช่ปัญหากระบวนการ — แต่เป็นปัญหาสถาปัตยกรรม

ทุกระบบที่จัดการล็อกอินของตัวเองคือเกาะหนึ่ง แต่ละเกาะมีรหัสผ่านของตัวเอง กฎ Session ของตัวเอง รายชื่อสิทธิ์เข้าถึงของตัวเอง และแต่ละเกาะมองไม่เห็นกัน

ความเสี่ยงด้านความปลอดภัยสะสมอย่างเงียบ ๆ:

  • หัวหน้าคลังสินค้าลาออก HR ปิดบัญชี Microsoft 365 แต่ล็อกอิน ERP, Portal รายงาน, ระบบจัดการคลังสินค้า — ยังใช้ Credential แยกต่างหากที่ไม่มีใครนึกถึงการเพิกถอน
  • แล็ปท็อปผู้จัดการฝ่ายการเงินถูกขโมย ไอทีรีเซ็ตรหัสผ่านอีเมลทันที แต่ Portal ลูกหนี้การค้าใช้รหัสผ่านอีกชุดที่เขียนไว้บนกระดาษโน้ตที่โต๊ะ
  • การตรวจสอบบัญชีต้องการ Log การเข้าถึงว่าใครดูข้อมูลการเงินในไตรมาส 3 แต่ละระบบมี Log ของตัวเอง บางระบบไม่มี Log เลย

สิ่งเหล่านี้ไม่ใช่สมมติฐาน แต่เป็นรูปแบบความล้มเหลวมาตรฐานของโครงสร้างพื้นฐานตัวตนที่กระจัดกระจาย

SSO แก้ปัญหาอะไรได้จริง

Single Sign-On (SSO) ไม่ใช่ฟีเจอร์ความสะดวกในการล็อกอิน แต่เป็นชั้นควบคุมตัวตน — การตัดสินใจเชิงสถาปัตยกรรมที่ทำให้ระบบเดียวรับผิดชอบในการตอบคำถามว่า: บุคคลนี้คือใคร และมีสิทธิ์ทำอะไรได้บ้าง?

เมื่อทุกแอปพลิเคชันมอบคำถามนั้นให้กับ Identity Provider เดียว สิ่งเหล่านี้จะเป็นไปไม่ได้ในเชิงโครงสร้าง:

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

Audit Trail เป็นระเบียบ ทุกล็อกอิน ทุก Session ทุกความพยายามเข้าถึงไหลผ่านระบบเดียว Log เดียว Query เดียว ภาพที่ครบถ้วน

MFA เป็นสากล แทนที่จะหวังว่าแต่ละแอปจะตั้งค่า MFA ถูกต้อง คุณบังคับใช้ครั้งเดียวที่ชั้นตัวตน ทุกแอปได้รับสืบทอดโดยอัตโนมัติ

การขโมย Credential ส่งผลกระทบน้อยลง รหัสผ่านที่ถูก Phish อันตรายเมื่อมันปลดล็อกหลายระบบ ด้วย SSO พนักงานของคุณไม่มีรหัสผ่านหลายชุดให้ขโมย — และจุดยืนยันตัวตนเดียวสามารถบังคับการยืนยันเพิ่มเติมสำหรับระบบที่ละเอียดอ่อน

การทำงานในทางปฏิบัติ

สถาปัตยกรรมนั้นเข้าใจง่าย Identity Provider — ในที่นี้คือ Authentik ที่เชื่อมต่อกับ Microsoft 365 — วางตัวอยู่หน้าระบบภายในทั้งหมด ทุกแอปพลิเคชันชี้ไปที่มันสำหรับการล็อกอิน Authentik ชี้ไปที่ Azure AD เพื่อยืนยันตัวตนผู้ใช้

flowchart TD
    subgraph STAFF["👤 พนักงาน"]
        B[...]
    end

    subgraph PORTAL["🌐 App Portal"]
        AP[...]
    end

    subgraph AUTHENTIK["🔐 Authentik — Identity Provider"]
        AK["ประตูล็อกอินเดียว\nสำหรับทุกระบบ"]
    end

    subgraph AZURE["☁️ Microsoft 365 / Azure AD"]
        AAD["แหล่งข้อมูลตัวตน\nที่เชื่อถือได้"]
    end

    subgraph APPS["24 ระบบของคุณ"]
        direction LR
        T1["🖥️ ERP · การเงิน · คลังสินค้า\nควบคุมเอกสาร · HR Portal"]
        T2["📱 อีเมล · โทรศัพท์ · ข้อความ"]
        T3["🖨️ เครื่องพิมพ์ · Hardware"]
    end

    B -->|"ล็อกอินครั้งเดียว"| AP
    AP -->|"ผู้ใช้นี้คือใคร?"| AUTHENTIK
    AUTHENTIK -->|"ยืนยันตัวตน"| AZURE
    AZURE -->|"ยืนยันแล้ว"| AUTHENTIK
    AUTHENTIK -->|"อนุญาต + Role"| APPS

    style AUTHENTIK fill:#EBF3FB,stroke:#2E75B6,stroke-width:2px
    style AZURE fill:#E8F4E8,stroke:#375623,stroke-width:2px
    style STAFF fill:#FFF9E6,stroke:#7F6000,stroke-width:2px
    style PORTAL fill:#FFF9E6,stroke:#7F6000,stroke-width:1px
    style APPS fill:#F5F5F5,stroke:#999999,stroke-width:1px

พนักงานไม่เห็นสิ่งเหล่านี้เลย พวกเขาเปิด Portal คลิกแอปที่ต้องการ แล้วเข้าใช้งานได้ทันที ถ้าพวกเขาล็อกอินบัญชี Microsoft ไปแล้วตั้งแต่เช้า พวกเขาจะไม่เห็นหน้าจอล็อกอินเลย

สิ่งที่เกิดขึ้นในการล็อกอินครั้งแรก:

sequenceDiagram
    actor Staff as พนักงาน
    participant Portal as App Portal
    participant Authentik as Authentik
    participant Azure as Azure AD
    participant App as ระบบใดก็ได้จาก 24 ระบบ

    Staff->>Portal: เปิดเบราว์เซอร์
    Portal->>Authentik: ไม่พบ Session
    Authentik->>Azure: Redirect ไปหน้าล็อกอิน MS365
    Azure-->>Staff: กรอก Email + รหัสผ่าน
    Staff->>Azure: ยืนยันตัวตน (+ MFA)
    Azure-->>Authentik: ยืนยันตัวตนแล้ว
    Note over Authentik: ตรวจสอบกลุ่ม, กำหนด Role,<br/>บังคับใช้ MFA Policy
    Authentik-->>Staff: สร้าง Session แล้ว ✓
    Portal-->>Staff: แสดง Tile แอปส่วนตัว

    Staff->>App: คลิก Tile ใดก็ได้
    Note over Authentik: มี Session อยู่แล้ว — ข้ามการล็อกอิน
    Authentik->>App: ออก Access Token พร้อม Role
    App-->>Staff: อนุญาตการเข้าถึง ✓

ทุกการล็อกอินหลังจากนั้น:

sequenceDiagram
    actor Staff as พนักงาน
    participant App as ระบบใดก็ได้จาก 24 ระบบ
    participant Authentik as Authentik

    Staff->>App: เปิดแอปโดยตรง
    App->>Authentik: ตรวจสอบ Session
    Note over Authentik: Session ยังใช้งานได้ — ไม่ต้องล็อกอินใหม่
    Authentik->>App: ออก Access Token
    App-->>Staff: อนุญาตการเข้าถึง ✓ — ไม่มีการถามรหัสผ่าน

เบื้องหลัง Identity Provider ทำงานหนักในทุกคำขอ: ตรวจสอบ Session, ตรวจสอบสมาชิกกลุ่ม, บังคับใช้ MFA Policy, ฉีด Claims ตาม Role เข้า Access Token และบันทึกลง Audit Log รวมศูนย์

สำหรับแอปพลิเคชันของคุณ การรวมระบบนั้นเบาสบาย แต่ละระบบได้รับ Client ID และ Client Secret มันค้นหา Endpoint การยืนยันตัวตนทั้งหมดอัตโนมัติจาก URL การกำหนดค่าเดียว เมื่อผู้ใช้มาถึง แอปถาม Identity Provider ว่าช่วยรับรองได้ไหม Identity Provider ตอบกลับด้วย Token ที่มีลายเซ็นซึ่งบรรจุทุกสิ่งที่แอปต้องการ — ตัวตน, กลุ่ม, Role, ระดับสิทธิ์เข้าถึง แอปอนุญาตการเข้าถึงและดำเนินการต่อ

งานปรับแต่งมีน้อย: แมป Azure AD Group ที่มีอยู่กับ Role เฉพาะแอป, กำหนดค่า Step-Up MFA สำหรับระบบที่ละเอียดอ่อน, และสร้าง Portal Tile Launcher ที่แสดงเฉพาะแอปที่ผู้ใช้แต่ละคนได้รับอนุญาตให้เข้าถึง

ปัญหาการปิดบัญชี — แก้ไขแล้ว

ประโยชน์ที่ถูกประเมินต่ำที่สุดของ SSO คือสิ่งที่เกิดขึ้นเมื่อมีคนลาออก

ในระบบที่กระจัดกระจาย การปิดบัญชีคือ Checklist ใครบางคน — ปกติคือไอที บางครั้งคือ HR บางครั้งไม่มีใคร — ทำงานผ่านรายการระบบและเพิกถอนสิทธิ์ด้วยตนเอง ระบบถูกข้ามไป Checklist ไม่ได้อัปเดตเมื่อเพิ่มแอปใหม่ คนที่ดูแล Checklist ลาออกไปเมื่อหกเดือนก่อน

ด้วย SSO และ SCIM Provisioning การปิดบัญชีคือเหตุการณ์ ไม่ใช่กระบวนการ ในทันทีที่บัญชีถูกปิดใช้งานใน Azure AD SCIM Push จะส่งการเปลี่ยนแปลงนั้นไปยัง Identity Provider Session ที่ใช้งานอยู่ถูกยกเลิก ทุกแอปที่เชื่อมต่อหยุดรับตัวตนนั้น ทุก 24 ระบบ พร้อมกัน โดยไม่ต้องมี Checklist

sequenceDiagram
    participant HR as HR / ผู้จัดการ
    participant Azure as Azure AD
    participant Authentik as Authentik
    participant Apps as ทุก 24 ระบบ

    HR->>Azure: ปิดใช้งานบัญชีพนักงาน
    Azure->>Authentik: SCIM Push — ปิดบัญชีแล้ว
    Note over Authentik: ยกเลิก Session ที่ใช้งานอยู่ทั้งหมด
    Authentik-->>Apps: เพิกถอนสิทธิ์ใน 24 ระบบ
    Note over Apps: พร้อมกัน ไม่มี Checklist<br/>ไม่มีช่องว่าง ไม่มีระบบที่ลืม
    HR-->>HR: เสร็จสิ้น ✓

เทียบกับทางเลือก: Checklist ที่ต้องทำทีละระบบ โดยคนที่อาจไม่รู้ว่าพนักงานคนนั้นเข้าถึงระบบใดบ้าง บน Checklist ที่ไม่ได้อัปเดตตั้งแต่การส่งมอบงานไอทีครั้งล่าสุด

สำหรับบริษัทที่มีการเปลี่ยนแปลงพนักงานสูง — ซึ่งเป็นเรื่องปกติในอุตสาหกรรมอาหารและการจัดจำหน่าย — นี่ไม่ใช่เรื่องเล็กน้อย ทุกวันที่บัญชีที่ปิดแล้วยังเข้าถึงระบบ Production ได้คือความรับผิดชอบที่แขวนอยู่

สิ่งที่ควรคาดหวังจากการติดตั้ง

การติดตั้ง SSO ที่กำหนดขอบเขตดีสำหรับ 24 ระบบใช้เวลาประมาณ 10 สัปดาห์ตั้งแต่ต้นจนจบ ขั้นตอนนั้นคาดเดาได้:

สองสัปดาห์แรกสร้างรากฐาน: ติดตั้ง Identity Provider, เชื่อมต่อกับ Microsoft 365 Tenant และตรวจสอบว่า Federation ทำงานถูกต้อง ยังไม่มีการย้ายแอปใด ๆ — ขั้นตอนนี้เป็นโครงสร้างพื้นฐานล้วน ๆ

สัปดาห์ที่สามและสี่เชื่อมต่อทุก 24 แอป แต่ละแอปได้รับการลงทะเบียนด้วย Client ID, Redirect URI และ Access Policy กำหนดค่าการอนุญาตตามกลุ่ม การกำหนดค่าถูก Export เป็น Blueprint YAML ที่ Version-Controlled — สามารถสร้างซ้ำได้และตรวจสอบได้

สัปดาห์ที่ห้าจัดการงานปรับแต่ง: การแมป ERP Role สำหรับระบบอย่าง Infor M3 ที่ต้องการ Attribute เฉพาะแอปใน Access Token และ Step-Up MFA Policy สำหรับระบบที่ละเอียดอ่อน

สัปดาห์ที่หกส่งมอบชั้นที่ผู้ใช้เห็น: App Portal, การ Localize ภาษาไทย, การ Branding บริษัทบนหน้าจอยืนยันตัวตนทั้งหมด

สัปดาห์ที่เจ็ดและแปดเชื่อมต่อเครื่องมือสื่อสาร — ระบบโทรศัพท์, แพลตฟอร์มข้อความ — ผ่าน Account Linking Stage ที่เชื่อมบัญชีแอปของพนักงานแต่ละคนกับ Azure AD Identity

สองสัปดาห์สุดท้ายคือการทดสอบ การตรวจรับ และการส่งมอบ: แผนทดสอบครบถ้วนต่อแอป, เซสชัน UAT กับทีมไอทีของคุณ และชุดเอกสารครบถ้วนครอบคลุมสถาปัตยกรรม, ขั้นตอนการดูแลระบบ และโปรโตคอลการเข้าถึงฉุกเฉิน

คำถามที่ควรถาม

คำถามไม่ใช่ว่าองค์กรของคุณต้องการการจัดการตัวตนแบบรวมศูนย์หรือไม่ ถ้าคุณมีระบบภายในมากกว่าสิบระบบ คุณต้องการมันแล้ว

คำถามคือคุณจะค้นพบความต้องการนั้นก่อนหรือหลังที่บางอย่างพังทลาย

ERP รุ่นเก่าที่ไม่มี MFA, Credential ของพนักงานที่ลาออกไปแล้วยังใช้งานได้ในระบบคลังสินค้า, คำขอตรวจสอบที่คุณตอบไม่ได้เพราะ Log กระจายอยู่ใน 12 แอป — สิ่งเหล่านี้ไม่ใช่กรณีพิเศษ แต่เป็นผลลัพธ์ที่คาดเดาได้ของโครงสร้างพื้นฐานตัวตนที่ขยายตัวโดยไม่มีสถาปัตยกรรม

SSO ไม่ได้กำจัดความเสี่ยงด้านความปลอดภัยทั้งหมด แต่กำจัดประเภทความเสี่ยงเฉพาะที่มาจากการกระจัดกระจาย: บัญชีผี, การนำ Credential มาใช้ซ้ำอย่างเงียบ ๆ, ช่องว่างในการปิดบัญชี, พื้นที่มืดใน Audit

บทความที่เกี่ยวข้อง

อ่านบทความทั้งหมด →

สำหรับองค์กรที่ใช้ Microsoft 365 รากฐานมีอยู่แล้ว Azure AD คือ Identity Authority ที่คุณจ่ายเงินไปแล้ว งานที่เหลือคือการเชื่อมต่ออีก 23 ระบบเข้ากับมัน — และตรวจสอบให้แน่ใจว่าการเชื่อมต่อนั้นแข็งแกร่ง ตรวจสอบได้ และควบคุมจากศูนย์กลาง

สนใจเชื่อมต่อระบบที่มีอยู่กับ SSO Layer แบบรวมศูนย์? เราทำงานกับองค์กรที่ใช้ Microsoft 365 เพื่อติดตั้งโครงสร้างพื้นฐานตัวตนบน Authentik — ครอบคลุม OIDC, SAML2, LDAP และการรวมระบบแบบกำหนดเองสำหรับ ERP และเครื่องมือสื่อสาร ติดต่อเราเพื่อพูดคุยเกี่ยวกับสภาพแวดล้อมของคุณ

บทความล่าสุด