ความปลอดภัยหุ่นกระบอกและทอพอโลยีเครือข่าย

พื้นหลัง:

ในที่สุดฉันก็สละเวลาเพื่อเข้าร่วมศตวรรษที่ 21 และดูหุ่นกระบอก

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

ดังนั้นฉันหวังว่า Puppet จะเป็นส่วนเสริมที่เรียบง่าย แต่น่าทึ่งสำหรับสิ่งที่เรามีอยู่แล้ว

ตอนนี้ฉันพิจารณากระบวนการที่เราต้องมีความปลอดภัยอย่างสมเหตุสมผล บนสมมติฐานที่ว่าเครือข่ายภายในของเราจะมีความปลอดภัยมากกว่าเครือข่ายสาธารณะในศูนย์ข้อมูลของเรา

• กระบวนการนี้เป็นวิธีหนึ่งเสมอ เปลี่ยนการเคลื่อนที่จากสภาพแวดล้อมที่ปลอดภัยไปเป็นที่ไม่ปลอดภัยและจะไม่มีทางกลับกัน

• ร้านค้าหลักอยู่ในสถานที่ที่ปลอดภัยที่สุด ความเสี่ยงของการประนีประนอมไม่ว่าจะโดยการขโมยการกำหนดค่าหรือการส่งการดัดแปลงที่เป็นอันตรายจะลดลงอย่างมาก

คำถาม:

จากสิ่งที่ฉันเข้าใจเกี่ยวกับ Puppet server / client model คือการสำรวจความคิดเห็นของลูกค้าและดึงการอัพเดทโดยตรงจากเซิร์ฟเวอร์ การรับส่งข้อมูลถูกห่อด้วย SSL ดังนั้นจึงไม่สามารถดักจับหรือปลอมแปลงได้ แต่มันแตกต่างจากสิ่งที่เราทำอยู่ในขณะนี้เพราะเซิร์ฟเวอร์ Puppet [s] จะต้องถูกโฮสต์ในที่สาธารณะ ไม่ว่าจะเป็นศูนย์กลางหรือหนึ่งแห่งสำหรับแต่ละศูนย์ข้อมูลที่เราดูแล

ดังนั้นฉันสงสัย:

• ฉันถูกหวาดระแวงโดยไม่จำเป็นเกี่ยวกับการเปลี่ยนแปลงจากการผลักไปสู่การดึง?

• ฉันถูกหวาดระแวงโดยไม่จำเป็นเกี่ยวกับการจัดเก็บข้อมูลทั้งหมดจากส่วนกลางบนเครือข่ายสาธารณะหรือไม่?

• คนอื่น ๆ ดูแลเครือข่ายหลายแห่งอย่างไร - แยกเซิร์ฟเวอร์สำหรับแต่ละไซต์

อัปเดต 30/07/09:

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

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

• สมมติฐานนั้นถูกต้องหรือไม่

• มีวิธีใดบ้างที่สามารถบรรเทาได้

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

ดังนั้น puppetmaster ของฉันจึงอยู่ในเครือข่ายส่วนตัวในสำนักงานของเราและฉันไม่ได้เรียกใช้ puppetd daemon บนเซิร์ฟเวอร์ เมื่อฉันต้องการปรับใช้ฉันใช้ ssh จาก private net ไปยังเซิร์ฟเวอร์สร้าง tunnel และเรียก puppetd จากระยะไกล
เคล็ดลับไม่ได้เป็นการตั้งค่าอุโมงค์ระยะไกลและไคลเอ็นต์หุ่นเชิดเพื่อเชื่อมต่อกับ puppetmaster แต่เป็นพร็อกซีที่ยอมรับการเชื่อมต่อ httpและสามารถเข้าถึงเซิร์ฟเวอร์ puppetmaster บนเครือข่ายส่วนตัว มิฉะนั้นหุ่นจะปฏิเสธที่จะดึงเนื่องจากชื่อโฮสต์ขัดแย้งกับใบรับรอง

# From a machine inside privatenet.net :
ssh -R 3128:httpconnectproxy.privatenet.net:3128 \
    -t remoteclient.publicnetwork.net \
    sudo /usr/sbin/puppetd --server puppetmaster.privatenet.net \
    --http_proxy_host localhost --http_proxy_port 3128 \
    --waitforcert 60 --test –-verbose

มันใช้งานได้สำหรับฉันหวังว่ามันจะช่วยคุณ

เรามีสองไซต์สำนักงานและโคโลของเรา แต่ละไซต์มี puppetmaster ของตัวเอง เราตั้งค่าพื้นที่เก็บข้อมูล svn ด้วยโครงสร้างต่อไปนี้:

root/office
root/office/manifests/site.pp
root/office/modules
root/colo
root/colo/manifests/site.pp
root/colo/modules
root/modules

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

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

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

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

สำหรับเครือข่ายที่หลากหลาย - เราจัดการกับหุ่นกระบอกต้นแบบ "ต้นแบบ" กลางที่มีหุ่นเชิด sattelite ในแต่ละสถานที่ซึ่งทำหน้าที่เป็นลูกค้าของเจ้านายหลัก

แนวทางการออกแบบอย่างหนึ่งคือการมี puppetmaster ในแต่ละสถานที่ของระบบและใช้เครื่องมือการปรับใช้เพื่อผลักดันการเปลี่ยนแปลงไปยัง puppetmasters (การใช้ git กับ git hooks ก็สามารถใช้ได้เช่นกัน)

สิ่งนี้จะรักษาความกังวลของคุณเกี่ยวกับบริการฟังบนเครือข่ายสาธารณะเนื่องจากปริมาณเครือข่ายหุ่นกระบอกจะเป็นภายในเท่านั้น

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

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

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

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

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

อ่านเพิ่มเติมได้ที่http://current.workingdirectory.net/posts/2011/puppet-without-masters/