ระวังการแอบอ้างเป็นผู้ใช้ในแอป Low-Code/No-Code

เมื่อเดือนที่แล้วฉันเขียน บทความ เกี่ยวกับวิธีการที่แพลตฟอร์ม low-code/no-code เสนอการแบ่งปันข้อมูลรับรองเป็นบริการ เหตุใดพวกเขาจึงทำเช่นนี้ และลักษณะนี้เป็นอย่างไร มุมมองของผู้โจมตี. ในบทความนี้ ผมจะเน้นที่ความหมายของการประนีประนอมและผลกระทบที่มีต่อองค์กรในปัจจุบัน

เหตุใดการแบ่งปันข้อมูลประจำตัวขององค์กรกับบุคคลอื่นจึงเป็นแนวปฏิบัติที่ไม่ดี สมมติว่าฉันต้องการส่งข้อมูลประจำตัวของฉันไปยังเพื่อนร่วมงานเพื่อสอบถามบันทึกการใช้งานจริงสำหรับการวิเคราะห์พฤติกรรมผู้ใช้แบบครั้งเดียว ในองค์กรทั่วไป การให้สิทธิ์ผู้อื่นในการค้นหาแหล่งข้อมูลใหม่อาจหมายถึงกระบวนการตรวจสอบการเข้าถึงที่ยาวนาน โดยเฉพาะอย่างยิ่งเมื่อพูดถึงการผลิตหรือข้อมูลที่ละเอียดอ่อน เพื่อนร่วมงานของฉันอาจหงุดหงิดง่าย “ทั้งหมดที่ฉันต้องการคือทำแบบสอบถามแบบใช้ครั้งเดียวนี้ และฉันรอมาหนึ่งเดือนแล้ว!” พวกเขาสามารถพูดได้ ฉันสามารถเรียกใช้แบบสอบถามสำหรับพวกเขาได้ แต่ฉันล้นมือกับงานประจำวันของฉันเอง และการสืบค้นครั้งเดียวมักจะซับซ้อน

ฉันมีวิธีแก้ปัญหาอย่างรวดเร็วเพียงวิธีเดียว: ฉันสามารถแบ่งปันชื่อผู้ใช้/รหัสผ่านกับเพื่อนร่วมงานของฉันได้ หากพวกเขาได้รับการท้าทาย MFA ฉันยินดีที่จะอนุมัติ ฉันไม่ต้องเสียเวลาดำเนินการค้นหา และเพื่อนร่วมงานของฉันจะถูกปลดบล็อก ชนะทุกคน! ใช่ไหม

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

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

ตัวอย่างในโลกแห่งความเป็นจริง

มาดูโลกของ low-code/no-code และตรวจสอบสถานการณ์ในโลกแห่งความเป็นจริงกัน ในองค์กรขนาดใหญ่ Jane ซึ่งเป็นพนักงานที่ได้รับแรงบันดาลใจจากทีมดูแลลูกค้าได้ตระหนักว่าเมื่อพนักงานทั่วทั้งองค์กรมีส่วนร่วมในกรณีศึกษาของลูกค้า พวกเขามักจะขาดข้อมูลสำคัญเกี่ยวกับลูกค้า เช่น ประวัติกรณีการสนับสนุนและการซื้อครั้งล่าสุด สิ่งนี้ทำให้ประสบการณ์ของลูกค้าแย่ลง เนื่องจากพวกเขาต้องอธิบายปัญหาครั้งแล้วครั้งเล่าในขณะที่เคสถูกส่งไปยังพนักงานที่เหมาะสมที่สามารถแก้ไขปัญหาได้

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

ขณะสร้างแอปพลิเคชัน Jane ต้องแก้ไขปัญหาต่างๆ มากมาย ปัญหาที่ใหญ่ที่สุดคือการอนุญาต พนักงานทั่วทั้งองค์กรไม่มีสิทธิ์เข้าถึงโดยตรงเพื่อสอบถามฐานข้อมูลลูกค้าเพื่อรับข้อมูลที่ต้องการ ถ้าเป็นเช่นนั้น Jane ก็ไม่ต้องสร้างแอปพลิเคชันนี้ เพื่อแก้ไขปัญหานี้ Jane ได้ลงชื่อเข้าใช้ฐานข้อมูลและฝังเซสชันที่ตรวจสอบสิทธิ์ของเธอในแอปพลิเคชันโดยตรง เมื่อแอปพลิเคชันได้รับคำขอจากผู้ใช้รายหนึ่ง แอปพลิเคชันจะใช้ข้อมูลประจำตัวของ Jane เพื่อดำเนินการค้นหานั้นแล้วส่งคืนผลลัพธ์ไปยังผู้ใช้ คุณลักษณะการฝังข้อมูลรับรองนี้ ตามที่เราสำรวจเมื่อเดือนที่แล้วเป็นคุณสมบัติหลักของแพลตฟอร์มแบบ low-code/no-code เจนทำให้แน่ใจว่าได้ตั้งค่าการควบคุมการเข้าถึงตามบทบาท (RBAC) ในแอปพลิเคชันเพื่อให้ผู้ใช้ทุกคนสามารถเข้าถึงกรณีของลูกค้าที่ได้รับมอบหมายเท่านั้น

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

ในขณะเดียวกันที่ SOC การแจ้งเตือนที่มีความรุนแรงสูงซึ่งแสดงกิจกรรมที่ผิดปกติรอบฐานข้อมูลลูกค้าที่ใช้งานจริงถูกกระตุ้นและมอบหมายให้ Amy นักวิเคราะห์ความปลอดภัยที่มีประสบการณ์ การตรวจสอบเบื้องต้นของ Amy แสดงให้เห็นว่าผู้ใช้ภายในพยายามขูดฐานข้อมูลทั้งหมด โดยค้นหาข้อมูลเกี่ยวกับลูกค้าหลายรายจากที่อยู่ IP หลายแห่งทั่วทั้งองค์กร รูปแบบการสืบค้นมีความซับซ้อนมาก แทนที่จะเป็นรูปแบบการแจงนับง่ายๆ ที่คุณคาดหวังว่าจะได้เห็นเมื่อมีการคัดลอกฐานข้อมูล มีการสอบถามข้อมูลของลูกค้ารายเดียวกันหลายครั้ง บางครั้งผ่านที่อยู่ IP ที่แตกต่างกันและในวันที่ต่างกัน นี่อาจเป็นผู้โจมตีที่พยายามสร้างความสับสนให้กับระบบตรวจสอบความปลอดภัยหรือไม่

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

เอมี่เอื้อมมือไปหาเจนเพื่อถามเธอว่าเกิดอะไรขึ้น ตอนแรกเจนไม่รู้ ข้อมูลประจำตัวของเธอถูกขโมยหรือไม่? เธอคลิกลิงก์ผิดหรือเชื่อถืออีเมลที่ส่งเข้ามาผิดหรือเปล่า แต่เมื่อเจนบอกเอมี่เกี่ยวกับแอปพลิเคชันที่เธอเพิ่งสร้างขึ้น ทั้งคู่ก็รู้ว่าอาจมีการเชื่อมต่อ Amy นักวิเคราะห์ SOC ไม่คุ้นเคยกับ low-code/no-code ดังนั้นพวกเขาจึงติดต่อทีม AppSec ด้วยความช่วยเหลือของเจน ทีมงานพบว่าแอปพลิเคชันของเจนมีข้อมูลประจำตัวของเจนฝังอยู่ภายใน จากมุมมองของฐานข้อมูล ไม่มีแอปพลิเคชันใดๆ มีเพียง Jane ที่ดำเนินการค้นหาจำนวนมาก

Jane, Amy และทีม AppSec ตัดสินใจปิดแอปพลิเคชันจนกว่าจะพบวิธีแก้ปัญหา ผู้ใช้แอปพลิเคชันทั่วทั้งองค์กรรู้สึกผิดหวังเพราะพวกเขาต้องพึ่งพามัน และลูกค้าก็รู้สึกเช่นกัน

ขณะที่เอมี่ปิดประเด็นและบันทึกสิ่งที่ค้นพบ รองประธานฝ่ายดูแลลูกค้าไม่พอใจที่เห็นอัตราความพึงพอใจของลูกค้าลดลง ดังนั้นพวกเขาจึงขอให้เจนมองหาวิธีแก้ปัญหาแบบถาวร ด้วยความช่วยเหลือจากเอกสารของแพลตฟอร์มและทีม Center of Excellence ขององค์กร Jane ได้ลบข้อมูลประจำตัวที่ฝังไว้ออกจากแอปพลิเคชัน เปลี่ยนแอปเพื่อใช้ข้อมูลประจำตัวของผู้ใช้แต่ละรายในการสืบค้นฐานข้อมูล และทำให้แน่ใจว่าผู้ใช้จะได้รับสิทธิ์เฉพาะกรณีที่เกี่ยวข้องกับลูกค้าเท่านั้น . ในเวอร์ชันใหม่และที่ได้รับการปรับปรุง แอปพลิเคชันใช้ข้อมูลประจำตัวของผู้ใช้แต่ละคนในการค้นหาฐานข้อมูลลูกค้า Jane และผู้ใช้แอปพลิเคชันต่างดีใจที่แอปพลิเคชันกลับมาออนไลน์อีกครั้ง Amy และทีม AppSec ต่างยินดีที่ระบบจะไม่เปิดเผยตัวตนของ Jane อีกต่อไป และองค์กรเห็นว่าอัตราความพึงพอใจของลูกค้าเริ่มเพิ่มขึ้นอีกครั้ง ทุกอย่างเป็นไปด้วยดี

สองสัปดาห์ต่อมา SOC ได้รับการแจ้งเตือนอีกครั้งเกี่ยวกับการเข้าถึงฐานข้อมูลลูกค้าที่ใช้งานจริงอย่างผิดปกติ มันดูน่าสงสัยคล้ายกับการแจ้งเตือนก่อนหน้าในฐานข้อมูลเดียวกันนั้น อีกครั้ง ที่อยู่ IP จากทั่วทั้งองค์กรใช้ข้อมูลประจำตัวของผู้ใช้คนเดียวในการสืบค้นฐานข้อมูล อีกครั้ง ผู้ใช้คนนั้นคือเจน แต่คราวนี้ ทีมรักษาความปลอดภัยและเจนรู้ว่าแอปนี้ใช้ข้อมูลประจำตัวของผู้ใช้ เกิดอะไรขึ้น?

จากการสอบสวนพบว่าแอปเดิมมี แบ่งปันโดยปริยาย เซสชันฐานข้อมูลตรวจสอบสิทธิ์ของ Jane กับผู้ใช้แอป การแชร์แอปกับผู้ใช้ ทำให้ผู้ใช้รายนั้นเข้าถึง . ได้โดยตรง การเชื่อมต่อเป็น wrapper รอบๆ เซสชันฐานข้อมูลที่ตรวจสอบสิทธิ์โดยแพลตฟอร์มของ low-code/no-code เมื่อใช้การเชื่อมต่อดังกล่าว ผู้ใช้สามารถใช้ประโยชน์จากเซสชันที่ได้รับการตรวจสอบสิทธิ์ได้โดยตรง โดยที่พวกเขาไม่ต้องผ่านแอปอีกต่อไป ปรากฎว่าผู้ใช้หลายคนค้นพบสิ่งนี้ และคิดว่านี่เป็นพฤติกรรมที่ตั้งใจไว้ กำลังใช้เซสชันฐานข้อมูลที่ตรวจสอบสิทธิ์ของ Jane เพื่อเรียกใช้การสืบค้น พวกเขาชอบโซลูชันนี้ เนื่องจากการใช้การเชื่อมต่อโดยตรงทำให้พวกเขาสามารถเข้าถึงฐานข้อมูลได้อย่างเต็มที่ ไม่ใช่แค่กรณีของลูกค้าที่ได้รับมอบหมายเท่านั้น

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

จัดการกับความท้าทายด้านความปลอดภัยแบบ Low-Code/No-Code

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

As low-code/no-code ยังคงเบ่งบานในองค์กรไม่ว่าจะรู้ตัวหรือไม่เป็นสิ่งสำคัญสำหรับทีมรักษาความปลอดภัยและไอทีในการเข้าร่วมการสนทนาการพัฒนาธุรกิจ แอพที่มีโค้ดน้อย/ไม่มีโค้ดมาพร้อมกับ a ความท้าทายด้านความปลอดภัยที่ไม่เหมือนใครและธรรมชาติที่อุดมสมบูรณ์ทำให้ความท้าทายเหล่านั้นรุนแรงขึ้นอย่างรวดเร็วกว่าที่เคยเป็นมา