ผู้ตรวจสอบความปลอดภัยสำหรับเซิร์ฟเวอร์ของเราได้เรียกร้องสิ่งต่อไปนี้ภายในสองสัปดาห์:
- รายการชื่อผู้ใช้ปัจจุบันและรหัสผ่านข้อความล้วนสำหรับบัญชีผู้ใช้ทั้งหมดบนเซิร์ฟเวอร์ทั้งหมด
- รายการการเปลี่ยนแปลงรหัสผ่านทั้งหมดสำหรับหกเดือนที่ผ่านมาอีกครั้งในข้อความธรรมดา
- รายการ "ทุกไฟล์ที่เพิ่มไปยังเซิร์ฟเวอร์จากอุปกรณ์ระยะไกล" ในช่วงหกเดือนที่ผ่านมา
- พับลิกและไพรเวตคีย์ของคีย์ SSH ใด ๆ
- อีเมลที่ส่งถึงเขาทุกครั้งที่ผู้ใช้เปลี่ยนรหัสผ่านประกอบด้วยรหัสผ่านข้อความล้วน
เราใช้กล่อง Red Hat Linux 5/6 และ CentOS 5 พร้อมการตรวจสอบสิทธิ์ LDAP
เท่าที่ฉันทราบทุกอย่างในรายการนั้นเป็นไปไม่ได้หรือยากที่จะได้รับอย่างเหลือเชื่อ แต่ถ้าฉันไม่ให้ข้อมูลนี้เราต้องเผชิญกับการสูญเสียการเข้าถึงแพลตฟอร์มการชำระเงินของเราและสูญเสียรายได้ในช่วงระยะเวลาการเปลี่ยนแปลง บริการใหม่ คำแนะนำใด ๆ สำหรับฉันจะแก้ไขหรือปลอมข้อมูลนี้ได้อย่างไร
วิธีเดียวที่ฉันคิดว่าจะได้รับรหัสผ่านแบบข้อความล้วนคือให้ทุกคนรีเซ็ตรหัสผ่านและจดบันทึกสิ่งที่พวกเขาตั้งไว้ ไม่ได้แก้ปัญหาการเปลี่ยนแปลงรหัสผ่านหกเดือนที่ผ่านมาเพราะฉันไม่สามารถบันทึกสิ่งต่าง ๆ ย้อนหลังแบบเดียวกันได้เช่นเดียวกันสำหรับการบันทึกไฟล์ระยะไกลทั้งหมด
การรับคีย์ SSH สาธารณะและส่วนตัวทั้งหมดเป็นไปได้ (แม้ว่าจะน่ารำคาญ) เนื่องจากเรามีผู้ใช้และคอมพิวเตอร์เพียงไม่กี่คน หากฉันไม่ได้ทำวิธีนี้ง่ายกว่านี้อีก
ฉันอธิบายให้เขาหลายครั้งว่าสิ่งที่เขาขอนั้นเป็นไปไม่ได้ เพื่อตอบข้อกังวลของฉันเขาตอบกลับด้วยอีเมลต่อไปนี้:
ฉันมีประสบการณ์มากกว่า 10 ปีในการตรวจสอบความปลอดภัยและเข้าใจวิธีการรักษาความปลอดภัย redhat ดังนั้นฉันขอแนะนำให้คุณตรวจสอบข้อเท็จจริงของคุณเกี่ยวกับสิ่งที่เป็นและเป็นไปไม่ได้ คุณบอกว่าไม่มี บริษัท ใดอาจมีข้อมูลนี้ แต่ฉันได้ทำการตรวจสอบหลายร้อยครั้งซึ่งข้อมูลนี้พร้อมใช้งานแล้ว ลูกค้า [ผู้ให้บริการประมวลผลบัตรเครดิตทั่วไป] ทั้งหมดจะต้องปฏิบัติตามนโยบายความปลอดภัยใหม่ของเราและการตรวจสอบนี้มีจุดประสงค์เพื่อให้แน่ใจว่านโยบายเหล่านั้นได้ดำเนินการอย่างถูกต้อง *
* "นโยบายความปลอดภัยใหม่" เปิดตัวสองสัปดาห์ก่อนการตรวจสอบของเราและไม่จำเป็นต้องมีการบันทึกประวัติหกเดือนก่อนการเปลี่ยนแปลงนโยบาย
ในระยะสั้นฉันต้องการ;
- วิธีเปลี่ยนรหัสผ่าน "ปลอม" หกเดือนที่คุ้มค่าและทำให้ถูกต้อง
- วิธีการ "ปลอม" การถ่ายโอนไฟล์ขาเข้าหกเดือน
- วิธีง่ายๆในการรวบรวมกุญแจสาธารณะและกุญแจส่วนตัวของ SSH ทั้งหมดที่ใช้งาน
หากเราล้มเหลวในการตรวจสอบความปลอดภัยเราจะสูญเสียการเข้าถึงแพลตฟอร์มการประมวลผลบัตรของเรา (เป็นส่วนสำคัญของระบบของเรา) และใช้เวลาสองสัปดาห์ในการย้ายที่อื่น ฉันเมาแค่ไหน?
อัปเดต 1 (วันเสาร์ที่ 23)
ขอบคุณสำหรับคำตอบทั้งหมดของคุณมันทำให้ฉันรู้สึกโล่งใจที่ได้รู้ว่านี่ไม่ใช่การปฏิบัติตามมาตรฐาน
ขณะนี้ฉันกำลังวางแผนการตอบกลับอีเมลของฉันเพื่ออธิบายสถานการณ์ ดังที่คุณหลายคนชี้ให้เห็นเราต้องปฏิบัติตาม PCI ซึ่งระบุไว้อย่างชัดเจนว่าเราไม่ควรมีวิธีการเข้าถึงรหัสผ่านแบบข้อความธรรมดา ฉันจะโพสต์อีเมลเมื่อฉันเขียนเสร็จแล้ว น่าเสียดายที่ฉันไม่คิดว่าเขาจะทดสอบเรา สิ่งเหล่านี้อยู่ในนโยบายความปลอดภัยอย่างเป็นทางการของ บริษัท ในขณะนี้ อย่างไรก็ตามฉันมีการตั้งค่าล้อในการเคลื่อนไหวเพื่อย้ายออกไปจากพวกเขาและบน PayPal ในขณะนี้
อัปเดต 2 (วันเสาร์ที่ 23)
นี่คืออีเมลที่ฉันได้ร่างไว้คำแนะนำสำหรับสิ่งที่จะเพิ่ม / ลบ / เปลี่ยน?
สวัสดี [ชื่อ]
น่าเสียดายที่เราไม่สามารถให้ข้อมูลบางอย่างที่คุณร้องขอได้โดยส่วนใหญ่เป็นรหัสผ่านข้อความธรรมดาประวัติรหัสผ่านคีย์ SSH และไฟล์บันทึกระยะไกล สิ่งเหล่านี้ไม่เพียงเป็นไปไม่ได้ทางเทคนิคเท่านั้น แต่ยังสามารถให้ข้อมูลนี้ได้ทั้งกับมาตรฐาน PCI และการฝ่าฝืนพระราชบัญญัติการปกป้องข้อมูล
เพื่ออ้างอิงข้อกำหนด PCI8.4 แสดงรหัสผ่านทั้งหมดที่อ่านไม่ได้ในระหว่างการส่งและจัดเก็บข้อมูลในส่วนประกอบของระบบทั้งหมดโดยใช้การเข้ารหัสที่รัดกุม
ฉันสามารถให้คุณมีรายชื่อผู้ใช้และรหัสผ่านที่แฮชที่ใช้ในระบบของเราสำเนาของกุญแจสาธารณะ SSH และไฟล์โฮสต์ที่ได้รับอนุญาต (ซึ่งจะให้ข้อมูลเพียงพอที่จะกำหนดจำนวนผู้ใช้ที่ไม่ซ้ำกันที่สามารถเชื่อมต่อกับเซิร์ฟเวอร์ของเราและการเข้ารหัส วิธีการที่ใช้) ข้อมูลเกี่ยวกับข้อกำหนดด้านความปลอดภัยของรหัสผ่านและเซิร์ฟเวอร์ LDAP ของเรา แต่ข้อมูลนี้อาจไม่ถูกนำออกจากไซต์ ฉันขอแนะนำให้คุณตรวจสอบข้อกำหนดการตรวจสอบของคุณเนื่องจากขณะนี้ยังไม่มีวิธีที่เราจะผ่านการตรวจสอบนี้ในขณะที่ยังคงเป็นไปตาม PCI และพระราชบัญญัติการปกป้องข้อมูล
ขอแสดงความนับถือ
[ฉัน]
ฉันจะเป็น CC'ing ใน CTO ของ บริษัท และผู้จัดการบัญชีของเราและฉันหวังว่า CTO จะสามารถยืนยันได้ว่าไม่มีข้อมูลนี้ ฉันจะติดต่อกับ PCI Security Standards Council เพื่ออธิบายสิ่งที่เขาต้องการจากเรา
อัปเดต 3 (26)
นี่คืออีเมลที่เราแลกเปลี่ยน
RE: อีเมลแรกของฉัน
ตามที่อธิบายไว้ข้อมูลนี้ควรมีอยู่ในระบบที่ได้รับการบำรุงรักษาอย่างดีให้กับผู้ดูแลระบบที่มีอำนาจ ความล้มเหลวของคุณในการให้ข้อมูลนี้ทำให้ฉันเชื่อว่าคุณตระหนักถึงข้อบกพร่องด้านความปลอดภัยในระบบของคุณและไม่ได้เตรียมที่จะเปิดเผยข้อมูลเหล่านั้น คำขอของเราสอดคล้องกับแนวทาง PCI และสามารถพบได้ทั้งคู่ การเข้ารหัสลับที่แข็งแกร่งหมายถึงรหัสผ่านจะต้องถูกเข้ารหัสในขณะที่ผู้ใช้กำลังป้อนรหัสผ่าน แต่จากนั้นพวกเขาควรจะย้ายไปอยู่ในรูปแบบที่กู้คืนได้เพื่อใช้ในภายหลัง
ฉันไม่เห็นปัญหาการป้องกันข้อมูลสำหรับคำขอเหล่านี้การป้องกันข้อมูลจะใช้กับผู้บริโภคที่ไม่ใช่ธุรกิจเท่านั้นดังนั้นจึงไม่ควรมีปัญหากับข้อมูลนี้
เพียงแค่สิ่งที่ฉันไม่สามารถแม้แต่ ...
"การเข้ารหัสที่รัดกุมเท่านั้นหมายถึงรหัสผ่านจะต้องถูกเข้ารหัสในขณะที่ผู้ใช้กำลังป้อนรหัสผ่าน แต่จากนั้นพวกเขาควรจะย้ายไปอยู่ในรูปแบบที่กู้คืนได้เพื่อใช้ในภายหลัง"
ฉันจะใส่กรอบลงไปที่ผนังของฉัน
ฉันเบื่อหน่ายกับการเจรจาต่อรองและชี้นำเขาไปยังหัวข้อนี้เพื่อแสดงคำตอบที่ฉันได้รับ:
การให้ข้อมูลนี้ขัดแย้งโดยตรงกับข้อกำหนดหลายประการของแนวทาง PCI ส่วนที่ฉันยกมาพูดว่า
storage
(ตรงกับที่เราเก็บข้อมูลบนดิสก์) ฉันเริ่มการสนทนาบน ServerFault.com (ชุมชนออนไลน์สำหรับผู้เชี่ยวชาญด้าน sys-admin) ซึ่งได้สร้างการตอบสนองอย่างมากทุกคนที่แนะนำว่าไม่สามารถให้ข้อมูลนี้ได้ รู้สึกอิสระที่จะอ่านผ่านตัวคุณเองhttps://serverfault.com/questions/293217/
เราได้ย้ายระบบของเราไปยังแพลตฟอร์มใหม่แล้วและจะยกเลิกบัญชีของเรากับคุณภายในวันถัดไปหรือมากกว่านั้น แต่ฉันต้องการให้คุณตระหนักว่าคำขอเหล่านี้ไร้สาระเป็นอย่างไรและไม่มี บริษัท ใดที่ปฏิบัติตามแนวทาง PCI อย่างถูกต้อง สามารถให้ข้อมูลนี้ได้ ฉันขอแนะนำให้คุณลองคิดทบทวนข้อกำหนดด้านความปลอดภัยของคุณเพราะไม่มีลูกค้าคนใดที่สามารถปฏิบัติตามข้อกำหนดนี้
(ฉันลืมไปแล้วจริง ๆ ฉันเรียกเขาว่าคนโง่ในชื่อ แต่ดังที่กล่าวไว้แล้วว่าเราได้ย้ายออกจากแพลตฟอร์มของพวกเขาแล้วดังนั้นจึงไม่มีการสูญเสียที่แท้จริง)
และในการตอบกลับของเขาเขาบอกว่าไม่มีใครรู้ว่าคุณกำลังพูดถึง:
ฉันอ่านรายละเอียดผ่านทางคำตอบเหล่านั้นและโพสต์ต้นฉบับของคุณผู้ตอบทุกคนต้องได้รับข้อเท็จจริง ฉันอยู่ในอุตสาหกรรมนี้นานกว่าทุกคนในไซต์นั้นการรับรายการรหัสผ่านของบัญชีผู้ใช้เป็นพื้นฐานอย่างไม่น่าเชื่อมันควรเป็นหนึ่งในสิ่งแรกที่คุณทำเมื่อเรียนรู้วิธีการรักษาความปลอดภัยระบบของคุณ เซิร์ฟเวอร์ หากคุณขาดทักษะในการทำสิ่งนี้อย่างแท้จริงฉันจะสมมติว่าคุณไม่ได้ติดตั้ง PCI บนเซิร์ฟเวอร์ของคุณเนื่องจากความสามารถในการกู้คืนข้อมูลนี้เป็นข้อกำหนดพื้นฐานของซอฟต์แวร์ เมื่อจัดการกับสิ่งต่าง ๆ เช่นการรักษาความปลอดภัยคุณไม่ควรถามคำถามเหล่านี้ในฟอรัมสาธารณะหากคุณไม่มีความรู้พื้นฐานเกี่ยวกับวิธีการทำงาน
ฉันอยากจะแนะนำว่าความพยายามใด ๆ ที่จะเปิดเผยฉันหรือ [ชื่อ บริษัท ] จะได้รับการพิจารณาว่าเป็นการหมิ่นประมาทและจะมีการดำเนินการทางกฎหมายที่เหมาะสม
ทำคะแนนงี่เง่าถ้าคุณทำพลาด:
- เขาเป็นผู้ตรวจสอบความปลอดภัยนานกว่าใครที่นี่ (เขาคาดเดาหรือสะกดรอยตามคุณ)
- ความสามารถในการรับรายการรหัสผ่านบนระบบ UNIX นั้นเป็น 'พื้นฐาน'
- PCI เป็นซอฟต์แวร์
- ผู้คนไม่ควรใช้ฟอรัมเมื่อพวกเขาไม่มั่นใจในความปลอดภัย
- การโพสต์ข้อมูลข้อเท็จจริง (ซึ่งฉันมีหลักฐานอีเมล) ทางออนไลน์คือการกลั่นแกล้ง
ยอดเยี่ยม
PCI SSC ได้ตอบกลับและกำลังตรวจสอบเขาและ บริษัท ซอฟต์แวร์ของเราย้ายไปยัง PayPal แล้วดังนั้นเราจึงรู้ว่าปลอดภัยแล้ว ฉันจะรอให้ PCI กลับมาหาฉันก่อน แต่ฉันเริ่มกังวลเล็กน้อยว่าพวกเขาอาจใช้วิธีปฏิบัติด้านความปลอดภัยเหล่านี้ภายใน ถ้าเป็นเช่นนั้นฉันคิดว่ามันเป็นความกังวลหลักสำหรับเราเนื่องจากการประมวลผลบัตรทั้งหมดของเราดำเนินการผ่านพวกเขา หากพวกเขาทำสิ่งนี้ภายในฉันคิดว่าสิ่งเดียวที่รับผิดชอบที่ต้องทำคือแจ้งลูกค้าของเรา
ฉันหวังว่าเมื่อ PCI รู้ว่ามันแย่แค่ไหนพวกเขาจะทำการตรวจสอบทั้ง บริษัท และระบบ แต่ฉันไม่แน่ใจ
ดังนั้นตอนนี้เราย้ายออกจากแพลตฟอร์มของพวกเขาและสมมติว่าอย่างน้อยสองสามวันก่อนที่ PCI จะกลับมาหาฉันคำแนะนำในการประดิษฐ์สำหรับวิธีการหมุนรอบเขาสักเล็กน้อย? =)
เมื่อฉันได้รับอนุญาตจากนักกฎหมายของฉัน (ฉันสงสัยอย่างมากเกี่ยวกับเรื่องนี้เป็นความจริง แต่ฉันต้องการตรวจสอบอีกครั้ง) ฉันจะเผยแพร่ชื่อ บริษัท ชื่อและอีเมลของเขาและหากคุณต้องการให้คุณสามารถติดต่อเขาและอธิบาย ทำไมคุณไม่เข้าใจพื้นฐานของการรักษาความปลอดภัย Linux เช่นวิธีรับรายการรหัสผ่านผู้ใช้ LDAP ทั้งหมด
อัพเดทเล็กน้อย:
"นักกฎหมาย" ของฉันแนะนำให้เปิดเผย บริษัท อาจจะทำให้เกิดปัญหามากกว่าที่จำเป็น ฉันสามารถพูดได้ว่านี่ไม่ใช่ผู้ให้บริการรายใหญ่ แต่มีลูกค้าน้อยกว่า 100 รายที่ใช้บริการนี้ ตอนแรกเราเริ่มใช้มันเมื่อไซต์เล็ก ๆ และทำงานบน VPS เล็กน้อยและเราไม่ต้องการผ่านความพยายามทั้งหมดในการรับ PCI (เราเคยเปลี่ยนเส้นทางไปยังส่วนหน้าของพวกเขาเช่น PayPal Standard) แต่เมื่อเราย้ายไปที่การประมวลผลการ์ดโดยตรง (รวมถึงการรับ PCI และสามัญสำนึก) devs ตัดสินใจที่จะใช้ บริษัท เดียวกันกับ API ที่แตกต่างกันต่อไป บริษัท ตั้งอยู่ในเขตเบอร์มิงแฮมสหราชอาณาจักรดังนั้นฉันจึงสงสัยอย่างมากว่าทุกคนที่นี่จะได้รับผลกระทบ