แนวทางปฏิบัติที่ดีที่สุดสำหรับการจัดการคีย์ SSH ในทีมคืออะไร

ฉันทำงานกับทีมขนาดเล็ก (<10) ของนักพัฒนาซอฟต์แวร์และผู้ดูแลระบบที่มีคุณสมบัติดังต่อไปนี้:

• สมาชิกส่วนใหญ่ของทีมมีคอมพิวเตอร์ส่วนบุคคลมากกว่า 1 เครื่องส่วนใหญ่เป็นแบบพกพา
• สมาชิกในทีมสามารถเข้าถึงเซิร์ฟเวอร์ได้ 10-50 เซิร์ฟเวอร์โดยปกติจะใช้ sudo

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

อะไรคือแนวทางปฏิบัติที่ดีที่สุดสำหรับการจัดการคีย์ SSH ในทีมเช่นนี้

คุณควรแบ่งปันคีย์เดียวสำหรับทั้งทีมหรือไม่

แต่ละคนควรมีรหัสของตนเองในบัญชีที่ใช้ร่วมกัน ("อูบุนตู" ในทุก ๆ เซิร์ฟเวอร์) หรือไม่

แยกบัญชีกันไหม

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

ที่ บริษัท ของฉันเราใช้ LDAP เพื่อมีชุดบัญชีที่สอดคล้องกันในทุกเครื่องแล้วใช้เครื่องมือจัดการการกำหนดค่า (ในกรณีของเราในปัจจุบัน cfengine) เพื่อแจกจ่ายauthorized_keysไฟล์สำหรับผู้ใช้แต่ละคนในเซิร์ฟเวอร์ทั้งหมด ไฟล์คีย์ตัวเองจะถูกเก็บไว้ (พร้อมกับข้อมูลการกำหนดค่าระบบอื่น ๆ ) ในที่เก็บ git เพื่อให้เราสามารถเห็นเมื่อคีย์มาและไป cfengine ยังกระจายsudoersไฟล์ที่ควบคุมผู้ที่สามารถเข้าถึงสิ่งที่รูทในแต่ละโฮสต์โดยใช้ผู้ใช้และกลุ่มจากไดเรกทอรี LDAP

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

นอกจากนี้เรายังมีโฮสต์ป้อมปราการที่ใช้ในการเข้าถึงโฮสต์บนเครือข่ายการผลิตทำให้เรามีกฎไฟร์วอลล์ที่เข้มงวดมากรอบเครือข่ายนั้น วิศวกรส่วนใหญ่มีการกำหนดค่า SSH พิเศษเพื่อทำให้เกิดความโปร่งใส:

Host prod-*.example.com
     User jsmith
     ForwardAgent yes
     ProxyCommand ssh -q bastion.example.com "nc %h %p"

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

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

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

โดยส่วนตัวแล้วฉันชอบความคิดของพนักงานแต่ละคนที่มีกุญแจหนึ่งปุ่มบนเครื่องป้อมปราการ SSH โดยเฉพาะซึ่งพวกเขามีบัญชีผู้ใช้พื้นฐาน บัญชีผู้ใช้นั้นมีรหัส 1 ssh ซึ่งให้สิทธิ์การเข้าถึงเซิร์ฟเวอร์ทั้งหมดที่พวกเขาต้องการใช้ (เซิร์ฟเวอร์อื่น ๆ เหล่านี้ควรปิดไฟร์วอลล์ด้วยดังนั้นจึงเปิดใช้งานการเข้าถึง ssh จากเครื่องป้อมปราการเท่านั้น)

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

ในฐานะที่เป็นผู้ดูแลระบบบนเครือข่ายนั้นคุณมีจำนวนขั้นต่ำที่จะต้องดูแล (หนึ่งต่อ dev) สามารถตรวจสอบการเข้าถึง ssh ผ่านเครือข่ายได้อย่างง่ายดาย (เนื่องจากเส้นทางทั้งหมดผ่านเครื่องป้อมปราการ) และหาก dev ต้องการหลาย ๆ ปุ่มหรือเพียงแค่ สิ่งหนึ่งที่พวกเขาแบ่งปันในเครื่องของพวกเขานั้นไม่ใช่เรื่องจริงเนื่องจากคุณมีเพียงหนึ่งเครื่องที่จะอัปเดต (ยกเว้นว่าปุ่ม ssh ของ bastions ถูกทำลายให้ลองใช้ tbh ที่ไม่น่าจะเป็นไปได้มากกว่าหนึ่งในกุญแจของผู้ใช้)

ฉันมีสถานการณ์ที่ฉันต้องการให้การเข้าถึงคีย์ SSH สำหรับทีมนักพัฒนา 40 คนให้กับเซิร์ฟเวอร์ลูกค้าระยะไกล ~ 120

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

โดยส่วนตัวแล้วฉันจะไปกับผู้ใช้แต่ละคนจากนั้นคุณมีความรับผิดชอบทันทีและตั้งข้อ จำกัด ได้ง่ายขึ้น - ฉันไม่รู้ว่าคนอื่นคิดอย่างไร

วิธีการหนึ่งที่ฉันเคยได้ยิน แต่ไม่ได้ใช้ตัวเองคือให้ผู้ใช้แต่ละคนมีแพ็กเกจ (เช่น. deb, .rpm) ซึ่งมีการกำหนดค่าพับลิกคีย์ของ ssh รวมถึง dotfiles ที่พวกเขาต้องการปรับแต่ง (.bashrc , .profile, .vimrc ฯลฯ ) นี่คือการเซ็นชื่อและเก็บไว้ในที่เก็บของ บริษัท แพคเกจนี้อาจรับผิดชอบในการสร้างบัญชีผู้ใช้หรืออาจเสริมสิ่งอื่นในการสร้างบัญชี (cfengine / puppet ฯลฯ ) หรือระบบรับรองความถูกต้องส่วนกลางเช่น LDAP

แพคเกจเหล่านี้จะถูกติดตั้งบนโฮสต์ผ่านกลไกที่คุณต้องการ (cfengine / puppet ฯลฯ , งาน cron) วิธีหนึ่งคือการมี metapackage ซึ่งมีการพึ่งพาแพ็คเกจต่อผู้ใช้

หากคุณต้องการลบกุญแจสาธารณะ แต่ไม่ใช่ผู้ใช้ดังนั้นแพ็คเกจสำหรับผู้ใช้จะได้รับการอัพเดต หากคุณต้องการลบผู้ใช้คุณจะลบแพ็คเกจออก

หากคุณมีระบบที่แตกต่างกันและต้องบำรุงรักษาทั้งไฟล์. rpm และ. deb, ฉันสามารถเห็นสิ่งนี้น่ารำคาญเล็กน้อยแม้ว่าเครื่องมืออย่างเอเลี่ยนอาจจะทำให้มันง่ายขึ้นบ้าง

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

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

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

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

ไม่กี่ปีที่ผ่านมา Envy Labs เขียนเครื่องมือที่ชื่อว่า Keymaster (ร่วมมือกับลูกค้า Gatekeeper) เพื่อจัดการเรื่องนี้กับทีมพัฒนา

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

repo มีอยู่ใน github: https://github.com/envylabs/keymaster

aproach สามารถตั้งค่าเซิร์ฟเวอร์ NIS ด้วย / แชร์ที่บ้านผ่าน NFS ที่รวมกับ sudo ในเซิร์ฟเวอร์และอนุญาตเฉพาะผู้ใช้ที่คุณต้องการแต่ละเซิร์ฟเวอร์ผ่านการกำหนดค่า ssh

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

ความนับถือ,

ราฟาเอล