บัญชีทดสอบของ Microsoft ที่ถูกแฮ็กมีสิทธิ์ผู้ดูแลระบบ

 (arstechnica.com)
1 คะแนน โดย GN⁺ 2024-01-29 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เหตุการณ์เจาะระบบ Microsoft ร้ายแรงกว่าการยึดบัญชีธรรมดา เพราะ บัญชีทดสอบเก่าที่ไม่มี MFA นำไปสู่การเข้าถึงอีเมลของผู้บริหารระดับสูง รวมถึงทีมความปลอดภัยและกฎหมาย
  • กลุ่มที่เชื่อมโยงกับรัฐรัสเซีย Midnight Blizzard ใช้ประโยชน์จากข้อมูลรับรองที่อ่อนแอด้วยวิธี password spraying เพื่อเข้าสู่ระบบ “legacy non-production test tenant account”
  • ผู้โจมตีใช้ สิทธิ์ของแอป OAuth จากเทนเนนต์ทดสอบที่ถูกเจาะ เพื่อให้ได้บทบาท full_access_as_app บน Office 365 Exchange Online
  • เนื่องจากการมอบสิทธิ์ full_access_as_app ต้องใช้ สิทธิ์ผู้ดูแลระบบ จึงมีเสียงวิจารณ์ว่านี่เป็นการตั้งค่าผิดพลาดที่ทำให้บัญชีทดสอบมีสิทธิ์มากเกินไปในสภาพแวดล้อมโปรดักชัน
  • บัญชีทดสอบที่ขัดกับหลักสิทธิ์น้อยที่สุด และการทำ password spraying ผ่านพร็อกซีที่อยู่อาศัย ทำให้การตรวจจับที่อาศัยตัวบ่งชี้การเจาะระบบแบบเดิมทำได้ยาก

จากบัญชีทดสอบสู่การเข้าถึงอีเมล

  • แฮ็กเกอร์ที่ได้รับการสนับสนุนจากรัฐรัสเซียใช้ password spraying เพื่ออาศัยข้อมูลรับรองที่อ่อนแอเข้าสู่ระบบ “legacy non-production test tenant account”
  • บัญชีทดสอบดังกล่าวไม่ได้รับการป้องกันด้วย การยืนยันตัวตนหลายปัจจัย
  • จากนั้นจึงได้สิทธิ์ที่ทำให้เข้าถึงบัญชีอีเมลของผู้บริหารระดับสูงของ Microsoft รวมถึงพนักงานในทีมความปลอดภัยและกฎหมาย
  • กลุ่มผู้โจมตี Midnight Blizzard ใช้ประโยชน์จากโปรโตคอลการยืนยันตัวตน OAuth เพื่อคงการเข้าถึงบัญชีอีเมลที่มีสิทธิ์อย่างต่อเนื่อง
    • สร้าง แอปอันตราย ในเทนเนนต์ทดสอบที่ถูกเจาะ
    • มอบสิทธิ์ให้แอปสามารถเข้าถึงทุกที่อยู่อีเมลในบริการอีเมล Microsoft Office 365
    • ใช้แอปพลิเคชัน OAuth สำหรับทดสอบเดิมเพื่อมอบบทบาท full_access_as_app บน Office 365 Exchange Online

บัญชีทดสอบแบบ legacy ที่มีสิทธิ์ผู้ดูแลระบบ

  • อัปเดตของ Microsoft ระบุว่า “legacy test OAuth application” มี elevated access อยู่ใน Microsoft corporate environment
  • Kevin Beaumont ระบุว่า หากต้องการมอบบทบาท full_access_as_app ให้แอป OAuth บัญชีนั้นต้องมี สิทธิ์ผู้ดูแลระบบ
  • Beaumont ประเมินว่าการตั้งค่านี้เป็น “ความผิดพลาดด้านการตั้งค่าครั้งใหญ่พอสมควรในโปรดักชัน”
  • มีเสียงวิจารณ์ว่าแทบจินตนาการไม่ออกว่าจะมีเหตุผลอันสมควรใดในการมอบและคงไว้ซึ่งสิทธิ์กว้างขนาดนี้ให้กับบัญชีทดสอบแบบ legacy
  • Microsoft ปฏิเสธที่จะอธิบายว่าทำไมบัญชีทดสอบนี้จึงถูกตั้งค่าเช่นนั้นตั้งแต่แรก และเหตุใดจึงยังคงอยู่เช่นเดิมแม้จะกลายเป็นสถานะแบบ legacy แล้ว

การตั้งค่าที่ขัดกับหลักสิทธิ์น้อยที่สุด

  • การตั้งค่านี้ขัดกับ หลักสิทธิ์น้อยที่สุด ที่กำหนดให้บัญชีควรมีเพียงสิทธิ์ขั้นต่ำที่จำเป็นต่อการทำงาน
  • ประเด็นสำคัญคือยากจะเข้าใจว่าทำไมบัญชีทดสอบแบบ legacy จึงต้องมีสิทธิ์ผู้ดูแลระบบ
  • Beaumont เปรียบเทียบสถานการณ์นี้เหมือนนำผู้ใช้ Domain Admin ของระบบโปรดักชันไปไว้ในโดเมนทดสอบที่ไม่มีระบบความปลอดภัย, MFA, ไฟร์วอลล์ หรือการมอนิเตอร์
    • ผู้ใช้ Domain Admin มีสิทธิ์ผู้ดูแลเต็มรูปแบบต่ออุปกรณ์ที่เชื่อมต่อกับเครือข่าย รวมถึงโดเมนคอนโทรลเลอร์และ Active Directory
    • นี่คือบัญชีที่ทรงอำนาจที่สุดในเครือข่าย จึงควรถูกแยกออก และไม่ควรถูกนำไปรวมในระบบโปรดักชันบ่อยนัก
    • หากปล่อยบัญชีประเภทนี้ไว้โดยไม่มีรหัสผ่านที่แข็งแกร่งและมาตรการความปลอดภัยมาตรฐาน ความเสียหายจะรุนแรงมาก

การเจาะระบบองค์กรอื่นและ password spraying ที่แนบเนียน

  • Microsoft ตรวจพบว่า Midnight Blizzard ได้เจาะองค์กรอื่นเพิ่มเติมด้วย และได้แจ้งเตือนองค์กรที่ได้รับผลกระทบ
  • Hewlett-Packard Enterprises ก็เปิดเผยว่าเครือข่ายของบริษัทถูกแฮ็กโดย Midnight Blizzard เช่นกัน
    • การเจาะระบบดังกล่าวเกิดขึ้นในเดือนพฤษภาคม
    • กว่าจะตรวจพบและสกัดกั้นได้ก็ในเดือนธันวาคม
  • การทำ password spraying ที่ใช้เข้าถึงบัญชีทดสอบนั้นดำเนินการกับบัญชีจำนวนจำกัด และพยายามต่อบัญชีเพียงไม่กี่ครั้ง
  • ผู้โจมตีใช้ โครงสร้างพื้นฐานพร็อกซีที่อยู่อาศัยแบบกระจายตัว เพื่อทำให้กิจกรรมอันตรายสังเกตได้ยากขึ้น
    • เข้าถึงจากที่อยู่ IP ที่มีชื่อเสียงดี
    • ใช้ที่อยู่ IP ที่อยู่ในภูมิภาคที่คาดหมาย
    • ทำให้ดูปะปนเหมือนทราฟฟิกของผู้ใช้จริง

ข้อจำกัดของการตรวจจับด้วยตัวบ่งชี้การเจาะระบบแบบเดิม

  • วิธีการใช้พร็อกซีที่อยู่อาศัยไม่ใช่เทคนิคใหม่ และเคยถูกใช้ใน การโจมตีห่วงโซ่อุปทาน SolarWinds เมื่อปี 2020
  • การโจมตี SolarWinds ก็ถูกเชื่อมโยงว่าเป็นฝีมือของ Midnight Blizzard เช่นกัน
  • พร็อกซีที่อยู่อาศัยจะส่งทราฟฟิกผ่าน IP ของผู้ใช้จริงจำนวนมาก ทำให้การตรวจจับแบบดั้งเดิมที่อาศัย ตัวบ่งชี้การเจาะระบบ ทำได้ยากในทางปฏิบัติ
  • Midnight Blizzard คือกลุ่มที่รัฐบาลสหรัฐฯ และสหราชอาณาจักรระบุว่าปฏิบัติการให้กับหน่วยข่าวกรองต่างประเทศของรัสเซีย SVR
  • ชื่ออื่นที่ใช้ติดตามกลุ่มเดียวกันนี้ ได้แก่ APT29, the Dukes, Cloaked Ursa, UNC2452 และ Dark Halo

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

1 ความคิดเห็น

 
GN⁺ 2024-01-29
ความคิดเห็นจาก Hacker News

  • นึกถึง การแฮ็ก Roblox เก่า ๆ ที่เคยได้ยินมาก่อน มีไซต์สเตจจิงที่ไม่ใช่ระบบโปรดักชันซึ่งผู้ใช้สมัครได้ และมีแบนเนอร์ติดไว้ว่า “สิ่งที่อยู่ที่นี่ไม่ถาวร”
    มีการเพิ่มบัญชีผู้ดูแลระบบใหม่ในสภาพแวดล้อมโปรดักชัน แล้วมีใครบางคนไปสมัครบนไซต์สเตจจิงด้วยชื่อผู้ใช้เดียวกัน จากนั้นใช้คุกกี้และโทเค็นนั้นยึดบัญชีโปรดักชันและเจาะเว็บไซต์ได้
    ถ้าสร้างโทเค็นเข้ารหัสโดยอิงชื่อผู้ใช้หรือ ID ผู้ใช้ แต่ไม่ได้ใช้ค่าลับคนละชุดสำหรับโปรดักชัน/สเตจจิง หรือไซต์สเตจจิงสื่อสารกับบริการภายนอกแล้วไปปนกับการให้สิทธิ์ของโปรดักชัน ปัญหาแบบนี้ก็คงไม่ใช่เรื่องหายากนัก

    • ก่อนหน้านี้เคยทำ API สำหรับการจัดส่ง สำหรับอีคอมเมิร์ซ ซึ่งเชื่อมกับที่อย่าง DHL ลืมสลับไปใช้เซิร์ฟเวอร์โปรดักชันอยู่หลายเดือน เลยส่งของด้วยฉลากที่ออกจาก API ทดสอบ แต่ของก็ถูกส่งไปถึงและไม่มีการเรียกเก็บเงิน
      พอรู้ตัวก็รีบแจ้งความจริงทันที
    • เพราะแบบนี้ในโทเค็นจึงมี ฟิลด์กลุ่มเป้าหมาย อยู่

  • ในบริษัทขนาดใหญ่ ขอบเขตระหว่างพัฒนา/โปรดักชัน มีรูรั่วมากกว่าที่ผู้คนอยากคิดกันมาก
    ลองนึกถึงวันทำงานทั่วไป: ล็อกอินเข้า PC เช็กอีเมล แล้วใช้ข้อมูลรับรองชุดเดียวกันล็อกอินเข้า Azure portal สุดท้ายทั้งหมดก็ผูกอยู่กับเทแนนต์เดียวกัน และบัญชีก็เชื่อมกับ GitHub รวมถึงบัญชีคลาวด์ด้วย
    Groups และ Teams ถูกสร้างกระจัดกระจายไปทั่ว สิ่งที่เกิดขึ้นเพื่อใช้ Teams หรือ OneDrive พร้อมสิทธิ์น่าสงสัยบางอย่าง ก็ยังคงอยู่ในไดเรกทอรีของบริษัทโดยแทบแยกไม่ออกจากกลุ่มความปลอดภัย
    บางครั้งมีอีเมลอัตโนมัติมาถามว่า “ยังต้องใช้สิ่งนี้อยู่ไหม” แต่ข้อความก็ไม่ชัดเจน และในบริษัทใหญ่มาก ๆ ก็แทบไม่มีคนให้ถาม เฮลป์เดสก์กว่าจะตอบก็อีกสองวัน และจะไปถาม John Savill ทาง Twitter ก็ไม่ได้ สุดท้ายก็เลยกดรับรองแล้วผ่านไป
    ท้ายที่สุด ผืนผ้าขององค์กรก็เริ่มฉีกขาด และผู้โจมตีโชคดีเข้ามาตรงจุดอ่อน แล้ว เคลื่อนที่ในแนวขวาง ภายในเทแนนต์เพื่อหยิบสิ่งที่ต้องการไป
    อย่างที่ CISO ผู้ชาญฉลาดเคยพูดไว้ แฮ็กเกอร์ไม่ได้บุกรุกเข้ามา แต่ล็อกอินเข้ามา

    • สมมติฐานที่ว่า “ทั่วไป” ในที่นี้ค่อนข้างห้าวดี น่าสนใจ
      แน่นอนว่าเป็นแนวที่ทุกคนใช้ Microsoft cloud, Skype, Twitter, OneDrive อะไรพวกนั้น และยังโยนชื่อคนบางคนเข้ามาให้ดูสมจริงด้วย

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

    • เรื่องนี้มีแนวโน้มสูงว่าไม่ใช่ปัญหาทางเทคนิค แนวปฏิบัติที่ดีและกลไกป้องกันทางเทคนิคน่าจะมีอยู่สัก 20 อย่าง แต่การ์ดเรลพวกนั้นจะมีความหมายก็ต่อเมื่อองค์กร ผู้นำ และระบบราชการภายในใส่ใจเท่านั้น
      ตลอดหลายปีที่ผ่านมา เคยถูกขอหลายครั้งให้เพิกเฉยนโยบาย ขั้นตอน กฎระเบียบ และกฎหมายทั้งหมด แล้วมอบ สิทธิ์ซูเปอร์แอดมิน/root ให้ VIP ที่ไม่จำเป็นต้องมีสิทธิ์แบบนั้นเลย
      ทุกวันนี้ยิ่งแย่ลง เพราะงานทุกอย่างกลายเป็นเหมือนการควบตำแหน่งข้ามสาย พาร์ตไทม์ บทบาทคู่ บทบาทสามชั้น
      เคยเห็นระบบควบคุมการเข้าถึงตามบทบาทที่มีจำนวนบทบาทมากกว่าจำนวนสิทธิ์จริงที่ให้ได้ด้วยซ้ำ แบบนั้นเป้าหมายของ RBAC ก็พังตัวเองไปแล้ว การให้สิทธิ์เป็นรายสิทธิ์เร็วกว่าเสียอีก แต่ทำแบบนั้นไม่ได้เพราะรายงานจะไม่แสดงบทบาท
      เรื่องแบบนี้ไม่ได้มาจากฝ่ายเทคนิค แต่มาจาก ภาวะผู้นำที่แย่
      ก่อนหน้านี้เคยออกแบบส่วนขยายเพื่อบรรเทาปัญหานี้ในระบบสิทธิ์ RBAC ของ ERP ภายในบริษัท โดยเพิ่มประเภทที่เรียกว่า “ข้อยกเว้นสิทธิ์” ให้คนที่ต้องใช้สิทธิ์นอกบทบาทได้รับมอบหมายด้วยวิธีนั้น เพื่อให้สร้างรายงานรายชื่อคนที่ทำงานนอกบทบาทหน้าที่ของตนได้
      สุดท้ายก็แค่เพิ่มแฟล็กหนึ่งตัวให้สิทธิ์ แต่มันใช้งานได้ดี HR ตรวจสอบข้อยกเว้นสิทธิ์ทุกไตรมาสเพื่อพิจารณาถอดออก และผู้มีอำนาจที่รู้จริงก็สามารถควบคุมได้ แทนที่เฮลป์เดสก์พาร์ตไทม์จะลองผิดลองถูกจนปล่อยสิทธิ์มั่วไปหมด
    • สงสัยว่าจะทำให้การตั้งค่าพลาดเป็นเรื่อง เป็นไปไม่ได้ ได้อย่างไร

  • ตลกดีที่มี ใบรับรองด้านความปลอดภัย หรู ๆ เต็มไปหมดซึ่งอ้างว่าปกป้ององค์กรและอุตสาหกรรมด้วยความเสี่ยงที่วัดเชิงปริมาณได้ แต่แนวปฏิบัติที่ดีอย่างมีเหตุผลและรอบคอบในหนังสือราคา 36 ดอลลาร์บน Amazon กลับถูกเมินสนิท
    ความปลอดภัยดูเหมือนแคมเปญติดริบบิ้นอะไรสักอย่าง

    • ความปลอดภัยคือ กระบวนการ ไม่ใช่ผลิตภัณฑ์
      คนที่ขายความปลอดภัยเหมือนเป็นผลิตภัณฑ์คือกำลังหลอกลวง
    • ต่อให้ฉันมีใบรับรองด้านความปลอดภัย พนักงานอีก 1,000 คนอาจไม่มี
      พนักงานทั่วไปแทบไม่สนใจเรื่องความปลอดภัยเลย แค่ทำงานของตัวเอง
      มีเซิร์ฟเวอร์ แอปพลิเคชัน และการตั้งค่ามากเกินไป จนพนักงานที่ตระหนักเรื่องความปลอดภัยอย่างเดียวไม่พอที่จะตรวจสอบทั้งหมด
      ถ้าจ้องดูนานพอ บริษัทไหน ๆ สักวันก็จะมีสิ่งที่ไม่ควรเปิดถูกเปิดอยู่ งานของกลุ่มแฮ็กเกอร์ก็คือการคอยหาช่องโหว่อย่างต่อเนื่อง
      บริษัทต้องสร้างเซิร์ฟเวอร์ใหม่และการตั้งค่าใหม่ระหว่างดำเนินงานอยู่เรื่อย ๆ ดังนั้นนี่ไม่ใช่ปัญหาที่ตั้งค่าครั้งเดียวแล้วจบ
    • อยากรู้ว่าเป็นหนังสือเล่มไหน

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

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

  • ส่วนที่บทความนี้ขาดไปคือ ถ้าบัญชีที่ไม่ใช่บัญชีใช้งานจริงมีสิทธิ์ผู้ดูแลโดเมนใช้งานจริง ผู้เขียนนิยามคำว่า “ใช้งานจริง” อย่างไร

    • ผมมองว่านี่แหละคือประเด็นหลัก บทความและข้อความที่อ้างถึงเรียกสิ่งนี้ว่า “ความผิดพลาด” แต่ในองค์กรขนาดใหญ่และซับซ้อนอย่าง Microsoft ผมมองว่าการกำหนดสิทธิ์ผิดพลาดเป็นเรื่องที่หลีกเลี่ยงได้ยาก
      ดังนั้นการไปโฟกัสมุมว่า “ในบริษัทที่มีพนักงาน 220,000 คน มีใครสักคนพลาดในช่วงเวลาใดเวลาหนึ่ง” จึงไม่ค่อยมีประโยชน์
      แต่ในบริษัทส่วนใหญ่ มักมีเส้นแบ่งที่แข็งแรงและหนาระหว่างระบบใช้งานจริงกับระบบทดสอบ การให้สิทธิ์เข้าถึงระบบใช้งานจริงแก่บัญชีทดสอบควรแทบเป็นไปไม่ได้เลย ดังนั้นจุดโฟกัสของการสอบสวนควรเป็นว่าเรื่องแบบนั้นเกิดขึ้นได้อย่างไร

  • เคยเห็นกรณีที่หนักกว่านี้ด้วย ผมเคยทำงานที่สำนักงานกฎหมายแห่งหนึ่ง ซึ่งให้สิทธิ์ผู้ดูแลระบบเหนือทุกอย่างแก่ผู้บริหารและพาร์ตเนอร์
    หลังรีเซ็ตรหัสผ่าน รหัสผ่านเริ่มต้นคือ “passme” เพราะรหัสผ่านเดิมยาวเกินไปจนจำยาก เขาควรต้องเปลี่ยนรหัสผ่านหลังล็อกอินเข้าเซิร์ฟเวอร์
    แฮ็กเกอร์ยึดบัญชีของพวกเขาไปได้หลายบัญชี แล้วเข้าไปยุ่งกับนั่นนี่และขโมยข้อมูล บัญชีทดสอบบางบัญชีก็มีสิทธิ์ผู้ดูแลระบบด้วย
    ดีแล้วที่ผมไม่ได้ทำงานที่นั่นอีก ผมเป็นโปรแกรมเมอร์นักวิเคราะห์ และมีสิทธิ์ผู้ดูแลบนพีซีของตัวเองเท่านั้นเพื่อให้ Visual BASIC 6.0 ทำงานได้

  • แพตเทิร์นแบบนี้ในระบบนิเวศของ Microsoft โดยรวมแล้วใกล้เคียงกับกฎมากกว่าจะเป็นข้อยกเว้น แต่การที่ Microsoft เองทำแบบนี้ถือว่าน่าอายเป็นพิเศษ
    ทีมความปลอดภัยของ Microsoft ทุ่มเทไม่น้อยกับเครื่องมือและเอกสารแนวปฏิบัติที่ดีเพื่อป้องกันเหตุการณ์ใหญ่แบบนี้

    • อยากรู้ว่าบัญชีทดสอบบัญชีแรกถูกยึดไปได้อย่างไร อาจไม่มีการยืนยันตัวตนหลายปัจจัย และหลังจากทำ password spraying ผ่าน OAuth ROPC flow แล้วจึงเคลื่อนย้ายในแนวขวางก็เป็นได้
      M365 บังคับใช้การยืนยันตัวตนหลายปัจจัยได้ค่อนข้างแย่ เป็นโครงสร้างที่ต้องจ่ายเงิน
    • เรื่องแบบนี้เกิดขึ้นทุกที่ วิธีทดสอบของคนจำนวนมากที่ผมเคยร่วมงานด้วยแทบจะเป็นการให้สิทธิ์สูงสุดเสมอ ไม่รู้สิ มันให้ความรู้สึกเหมือนการดีบักแบบยิงกระจาย
      ปัญหาที่ใหญ่กว่าคือผู้คนลืม สร้างบัญชีทดสอบที่มีสิทธิ์ผู้ดูแลไว้ห้าบัญชี แล้วมันจะไม่โผล่มาจนกว่าจะมีใครสักคนทำ audit สิทธิ์ผู้ใช้ทั้งบริษัท

  • บริษัทที่ผมเคยทำงานมาก่อนใส่รหัสผ่านทั้งหมดของเซิร์ฟเวอร์และฐานข้อมูลใช้งานจริงไว้ในไฟล์ข้อความใน code repository เพราะหัวหน้าสถาปนิกไม่อยากจำรหัสผ่าน
    พอผมบอก CTO ว่านั่นโง่แค่ไหน ก็ได้คำตอบว่า “เราเชื่อใจพนักงานของเรา” และ “เราผ่านการตรวจสอบความปลอดภัยแล้ว”
    จนถึงตอนนี้ยังรู้สึกเจ็บจากการเอามือตบหน้าตัวเองอยู่เลย

    • ผมก็เกลียดรหัสผ่านฐานข้อมูลเหมือนกัน มันถูกแคร็กเร็วเกินไป
      มันเป็นแค่สิ่งน่ารำคาญ ไม่ใช่ฟีเจอร์ด้านความปลอดภัย ผมไม่ใช้รหัสผ่านอย่าง “c00lz500” แต่ใช้แบบสตริงว่างไปเลย
      แล้วใช้ไฟร์วอลล์และเครือข่ายภายในแทน