การรักษาความปลอดภัยข้อมูลที่สำคัญจากนักพัฒนา

ฉันมีแอพพลิเคชั่นระดับองค์กรที่ใช้ทั้งMySQLและMongoDB datastores ทีมพัฒนาของฉันทุกคนสามารถเข้าใช้งานSSHได้เพื่อดำเนินการรีลีสแอปพลิเคชันการบำรุงรักษา ฯลฯ

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

สำหรับฉันนี่ดูเหมือนจะเป็นไปไม่ได้เพราะหากแอปพลิเคชันมีการเข้าถึงฐานข้อมูลนักพัฒนาที่มีสิทธิ์เข้าถึงเครื่องและแหล่งที่มาของแอปพลิเคชันจะสามารถเข้าถึงข้อมูลได้เสมอ

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

คุณได้ตั้งค่าสถานะความปลอดภัยซึ่งเป็นขั้นตอนแรกที่ดี ตอนนี้เป็นขั้นต่ำที่คุณต้องกำหนด: -

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

จนกว่าคุณจะรู้รายละเอียดทั้งหมดคุณจริงๆไม่มีอะไรจะทำงานกับ ข้อมูลดังกล่าวจะกำหนดว่าการบรรเทาภัยคุกคามใด ๆ ที่คุณสามารถทำได้ (และไม่สามารถทำได้) และทำไม

อาจเป็นไปได้ว่าสิ่งที่ดีที่สุดที่ต้องทำคือยอมรับว่าคุณไม่มีประสบการณ์ที่จำเป็นและจะเป็นการดีที่สุดที่จะนำคนใหม่มารับประสบการณ์นั้น ฉันมักจะได้ยินคำตอบว่าไม่มีงบประมาณ - หากเป็นเรื่องสำคัญจริง ๆ ก็จะพบงบประมาณ

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

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

(โปรดทราบว่ารูปแบบธุรกิจดังกล่าวดูเหมือนว่าจะไม่สามารถแก้ปัญหาทางการเมืองได้ธุรกิจต่างๆถูกบังคับให้ทำงานโดยบริการรักษาความปลอดภัยเพื่อพยายามทำสิ่งนี้อย่างแน่นอนฉันเข้าใจว่าการให้ความเป็นส่วนตัวรับประกันนั้นมีมูลค่าทางธุรกิจ มูลค่าทางธุรกิจมากกว่าเป้าหมายพื้นฐานของการอยู่ในธุรกิจ)

คุณพูดถูก นักพัฒนาบางคนจะต้องเข้าถึงข้อมูลสดเสมอหากเพียงเพื่อวินิจฉัยปัญหาการผลิต สิ่งที่ดีที่สุดที่คุณสามารถทำได้คือจำกัดความเสียหายที่อาจเกิดขึ้นโดยการลดจำนวนคนที่เกี่ยวข้อง

With great power comes great ... opportunity to really, *really* foul things up. 

นักพัฒนาหลายคนไม่ต้องการความรับผิดชอบนั้นและคนอื่น ๆ แต่จะไม่ "พร้อม" ที่จะถือมันและไม่ควรมี

คำถาม: ทำไมคุณพัฒนาทีมงานที่มีประสิทธิภาพสดรุ่น ?
ฉันขอแนะนำให้คุณต้องมี "การจัดการทีม" ที่วางจำหน่าย (แม้ว่าจะเป็นเพียงส่วนหนึ่งของทีมของคุณรวมถึงการเป็นตัวแทนธุรกิจเพื่อทำการตัดสินใจในวันใดวันหนึ่งเช่น "Go / No-Go")? สิ่งนี้จะลบ "ความต้องการ" ส่วนใหญ่สำหรับนักพัฒนาในการแตะสิ่งใด ๆ แบบสด

คุณมีข้อตกลงการไม่เปิดเผย / การรักษาความลับระหว่างนักพัฒนาและ บริษัท หรือไม่? เป็นงานหนัก แต่อาจมีบุญบ้าง

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

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

กฎความปลอดภัย # 1: หากใครบางคนมีการเข้าถึงข้อมูลพวกเขาสามารถเข้าถึงข้อมูลนั้นได้

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

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

หลังจากนั้นผู้พัฒนาสามารถสร้างการควบคุมการเข้าถึงที่ยืดหยุ่นมากขึ้นบนชั้นแกนหลัก รหัสนี้ยังต้องเป็น V & Vd แต่มันไม่เข้มงวดนักเพราะคุณสามารถพึ่งพาชั้นแกนกลางเพื่อปกปิดสิ่งจำเป็น

รูปแบบขยายออกไปด้านนอก

ส่วนที่ยากคือศิลปะในการออกแบบระบบเหล่านี้คือวิธีการสร้างแต่ละชั้นเพื่อให้นักพัฒนาสามารถพัฒนาและตรวจแก้จุดบกพร่องในขณะที่ยังคงให้ความปลอดภัยที่คุณคาดหวังกับ บริษัท ของคุณ โดยเฉพาะอย่างยิ่งคุณจะต้องยอมรับว่าการดีบั๊กต้องการสิทธิพิเศษมากกว่าที่คุณคิดและการล็อคลงจะส่งผลให้นักพัฒนาบางคนโกรธมาก

ในฐานะที่เป็นโซลูชันด้านข้างให้พิจารณาจัดทำฐานข้อมูล "ปลอดภัย" สำหรับการทดสอบที่ผู้พัฒนาสามารถดึงกลไกความปลอดภัยทั้งหมดและทำการดีบักอย่างจริงจัง

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

ตั้งค่าการปรับใช้สองแอปพลิเคชันซึ่งใช้การปรับใช้ฐานข้อมูลแยกต่างหาก หนึ่งคือการปรับใช้การผลิตและหนึ่งคือการใช้งานการทดสอบ

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

ใน บริษัท การเงินสองแห่งผู้พัฒนาไม่สามารถเข้าถึงเครื่องจักรผลิตได้ คำขอทั้งหมดเพื่อแก้ไขเครื่องจักรที่ใช้ในการผลิตจะต้องผ่านกระบวนการอนุมัติด้วยสคริปต์และได้รับการอนุมัติจากผู้จัดการ ทีม dev-ops เสร็จสิ้นการปรับใช้จริง ฉันถือว่าทีมนี้เป็นพนักงานเท่านั้นและผ่านการตรวจสอบประวัติ พวกเขายังไม่มีความรู้ด้านการพัฒนาดังนั้นอาจไม่สามารถสอดแนมหากพวกเขาต้องการ นอกจากนี้คุณจะเข้ารหัสรายการฐานข้อมูลทั้งหมดโดยใช้รหัสลับที่เก็บไว้ในตัวแปรสภาพแวดล้อม แม้ว่าฐานข้อมูลรั่วไหลออกสู่สาธารณะไม่มีใครสามารถอ่านได้ รหัสนี้สามารถป้องกันด้วยรหัสผ่านเพิ่มเติม (PBKDF) ดังนั้นผู้บริหารเท่านั้นจึงสามารถปลดล็อคได้ ระบบของคุณอาจต้องใช้รหัสผ่านผู้บริหารเมื่อบู๊ตเครื่อง (หรือมีแนวโน้มมากกว่าที่จะมอบหมายให้ dev-ops หรือผู้จัดการ dev-ops) โดยพื้นฐานแล้วกลยุทธ์คือการกระจายความรู้ดังนั้นมวลที่สำคัญของความรู้ที่ต้องการไม่มีอยู่ในบุคคลเดียวและมีการตรวจสอบและถ่วงดุล นี่คือวิธีที่ Coca-Cola ปกป้องสูตร จริงๆแล้วคำตอบบางคำเหล่านี้เป็นตำรวจ

MongoDB มีการควบคุมความปลอดภัยที่ จำกัด และขึ้นอยู่กับสภาพแวดล้อมที่ปลอดภัย การเชื่อมโยงกับ ip และพอร์ตเฉพาะ (และ ssl ตั้งแต่ 2.2) และการตรวจสอบความถูกต้องแบบหยาบนั่นคือสิ่งที่มันเสนอ MYSQL เพิ่ม GRANT o ON db.t TO ... ข้อมูลที่เหลือไม่ได้เข้ารหัสและ ssl จะไม่ถูกใช้โดยค่าเริ่มต้น สร้างรั้ว การเข้าถึงไฟล์บันทึกที่เกี่ยวข้องกับแอปพลิเคชันแบบอ่านอย่างเดียวควรเพียงพอที่จะทำการดีบัก ทำให้วงจรชีวิตของแอปพลิเคชันเป็นแบบอัตโนมัติ

Ansible ช่วยให้เราทำการดำเนินงานมาตรฐานโดยอัตโนมัติ (ปรับใช้อัปเกรดกู้คืน) ผ่านสภาพแวดล้อมแบบ tennant จำนวนมากในขณะที่ใช้ห้องเข้ารหัสที่แตกต่างกันเพื่อจัดเก็บตัวแปรสภาพแวดล้อมที่มีความละเอียดอ่อนเช่นโฮสต์พอร์ตและข้อมูลรับรอง หากแต่ละ vault สามารถถอดรหัสได้ด้วยบทบาทที่แตกต่างกันและบนโฮสต์ bastion เท่านั้นสำหรับการดำเนินการที่บันทึกไว้จากนั้นการตรวจสอบจะให้ความปลอดภัยที่ยอมรับได้ หากคุณให้ SSH จากนั้นโปรดใช้ selinux เพื่อหลีกเลี่ยงการดัดแปลงที่สำคัญใช้ bastion host ที่มีการพิสูจน์ตัวตน ldap / kerberos สำหรับการดูแลระบบและใช้ sudo อย่างชาญฉลาด