ข้อดีของการใส่ค่าความลับของเว็บไซต์เป็นตัวแปรสภาพแวดล้อมคืออะไร

แนวทาง devops ที่https://12factor.net/configแนะนำให้ใส่ความลับของเว็บไซต์ (รหัสผ่านฐานข้อมูลคีย์ api และอื่น ๆ ) ลงในตัวแปรสภาพแวดล้อม ข้อดีอะไรที่แทนที่จะใช้ไฟล์ข้อความ (JSON, XML, YAML, INI หรือที่คล้ายกัน) ที่ถูกละเว้นจากการควบคุมเวอร์ชัน

ฉันพบว่าการคัดลอกไฟล์การกำหนดค่าด้วยความลับง่ายกว่าการจัดการกับตัวแปรสภาพแวดล้อมในการกำหนดค่า. bash_profile และเว็บเซิร์ฟเวอร์ ฉันพลาดอะไรไปหรือเปล่า?

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

ด้วยประสบการณ์ของฉันเองคุณมีสามตัวเลือกดังต่อไปนี้โดยมีข้อดีและข้อเสียที่เกี่ยวข้อง:

เก็บข้อมูลในไฟล์กำหนดค่า

เมื่อใช้วิธีการนี้คุณควรแยกพวกเขาออกจากพื้นที่เก็บข้อมูลและควรตรวจสอบให้แน่ใจว่าพวกเขาอยู่นอกพื้นที่ที่แอพจัดเก็บเนื้อหาของมัน

ข้อดี:

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

ข้อเสีย:

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

เก็บข้อมูลในตัวแปรสภาพแวดล้อม

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

ข้อดี:

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

ข้อเสีย

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

ใช้อาร์กิวเมนต์บรรทัดคำสั่งเพื่อส่งผ่านข้อมูล

อย่างจริงจังหลีกเลี่ยงสิ่งนี้ในทุกวิถีทางไม่ปลอดภัยและเจ็บปวดในการดูแลรักษา

ข้อดี:

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

ข้อเสีย:

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

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

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

แม้ว่าจะมีการปิดการแลกเปลี่ยนที่เกี่ยวข้องกับความปลอดภัยบางอย่างเมื่อมันมาถึงตัวแปรสภาพแวดล้อมหรือไฟล์ฉันไม่คิดว่าการรักษาความปลอดภัยเป็นแรงผลักดันหลักสำหรับคำแนะนำนี้ โปรดจำไว้ว่าผู้เขียน 12factor.net นั้นเป็นผู้พัฒนาของ Heroku PaaS การทำให้ทุกคนใช้ตัวแปรสภาพแวดล้อมอาจทำให้การพัฒนาง่ายขึ้นเล็กน้อย มีหลากหลายมากในรูปแบบไฟล์และตำแหน่งที่ตั้งที่แตกต่างกันและมันคงเป็นเรื่องยากสำหรับพวกเขาที่จะสนับสนุนพวกเขาทั้งหมด ตัวแปรสภาพแวดล้อมนั้นง่ายต่อการเปรียบเทียบ

ไม่ต้องใช้จินตนาการมากนักในการคาดเดาบทสนทนาบางส่วนที่มี

ผู้พัฒนา A: "อ่า UI ไฟล์ปรับแต่งความลับนี้รกเกินไปจริง ๆ เราจำเป็นต้องเลื่อนลงที่สลับไปมาระหว่าง json, xml และ csv หรือไม่"

นักพัฒนา B: "โอ้ชีวิตจะยิ่งใหญ่ถ้าทุกคนใช้ตัวแปรสภาพแวดล้อมสำหรับการตั้งค่าแอพ"

ผู้พัฒนา A: "จริงๆแล้วมีเหตุผลที่เกี่ยวข้องกับความปลอดภัยที่น่าเชื่อถือบางประการตัวแปรสภาพแวดล้อมอาจไม่ได้รับการตรวจสอบโดยไม่ได้ตั้งใจในการควบคุมแหล่งที่มา"

ผู้พัฒนา B: "คุณไม่ได้ตั้งค่าตัวแปรสภาพแวดล้อมด้วยสคริปต์ที่เรียกใช้ daemon หรือไฟล์ปรับแต่ง"

ผู้พัฒนา A: "ไม่ได้อยู่ใน Heroku! เราจะทำให้พวกมันพิมพ์ลงใน UI"

ผู้พัฒนา B: "อ๋อการแจ้งเตือนชื่อโดเมนของฉันกับ 12factor.net เพิ่งจะปิดตัวลง" ¹

¹ : แหล่งที่มา: สร้างขึ้น

TL; DR

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

การกำหนดค่านอกวง: การแยกความลับจากซอร์สโค้ด

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

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

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

เพิ่มประสิทธิภาพการแยก: เซิร์ฟเวอร์แอปพลิเคชันและบทบาท

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

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

พรากจากความคิดเกี่ยวกับความปลอดภัย

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

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

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

ส่วนตัวผมไม่แนะนำให้ตั้งค่าตัวแปรสภาพแวดล้อม.bashrcเพราะสิ่งเหล่านี้สามารถมองเห็นได้ในทุกกระบวนการที่เริ่มต้นโดยเชลล์ แต่เพื่อตั้งไว้ที่ระดับ daemon / supervisor (สคริปต์ init / rc, systemd config) เพื่อ จำกัด ขอบเขตของตำแหน่งที่ต้องการ .

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

สิ่งที่ต้องพิจารณาอีกประการหนึ่งคือ CI / CD pipelines เนื่องจากรหัสผ่านสภาวะแวดล้อมที่แตกต่างกัน(เช่น dev, test / qa, staging, production) รายการด้านสิ่งแวดล้อม (โซนการนำไปใช้งาน, รายการการเชื่อมต่อฐานข้อมูล, หนังสือรับรอง, ที่อยู่ IP, ชื่อโดเมน, ฯลฯ ) ถูกกำหนดโดยเครื่องมือ / กรอบการจัดการการกำหนดค่าเฉพาะที่ดีที่สุด กระบวนการจากสภาพแวดล้อม (ใน DRY เขียนหนึ่งครั้งเรียกใช้แฟชั่นทุกที่) ตามธรรมเนียมแล้วที่นักพัฒนามักจะจัดการกับข้อกังวลในการปฏิบัติงานพวกเขามักจะเช็คอินไฟล์หรือแม่แบบนอกเหนือจากรหัส - จากนั้นก็เพิ่มการแก้ไขปัญหาและความซับซ้อนอื่น ๆ เมื่อความต้องการในการปฏิบัติงานเปลี่ยนไป (เช่นสภาพแวดล้อมใหม่ ชั่งน้ำหนัก

• Env-vars ลดความซับซ้อนของการกำหนดค่า / ความซับซ้อนในระดับ
• Env-vars วางการกำหนดค่าการปฏิบัติงานให้ตรงกับทีมที่รับผิดชอบด้านที่ไม่เกี่ยวข้องกับรหัสของแอปพลิเคชันในลักษณะที่เป็นเครื่องแบบ (หากไม่ใช่มาตรฐาน) วิธีที่ไม่มีผลผูกพัน
• Env-vars รองรับการสับเปลี่ยนกระบวนการหลัก / หัวหน้างาน (เช่น god, monit, supervisord, sysvinit, systemd และอื่น ๆ ) ที่สนับสนุนแอปพลิเคชัน - และแน่นอนว่าแม้แต่ระบบการนำไปใช้งาน (OSes, ภาพคอนเทนเนอร์ ฯลฯ ) หรืออื่น ๆ วิวัฒนาการ / เปลี่ยน ในขณะที่กรอบการทำงานของภาษาทุกวันนี้มีการประมวลผลที่ผิดเพี้ยนไปบ้าง แต่สิ่งเหล่านี้มีแนวโน้มที่จะด้อยกว่าเหมาะสำหรับสภาพแวดล้อมการพัฒนาและ / หรือเพิ่มความซับซ้อนในสภาพแวดล้อมการผลิตหลายภาษา / หลายเฟรม

สำหรับการผลิตที่ผมโปรดปรานการตั้งค่าโปรแกรมประยุกต์ env-vars ในEnvironmentFileเช่น/etc/default/myapplication.confที่มีการใช้งานโดยจัดการการตั้งค่าและการตั้งค่าที่อ่านได้โดยเฉพาะrootเช่นนั้นsystemd(หรือสิ่งอื่นใดสำหรับเรื่องที่) สามารถวางไข่แอพลิเคชันภายใต้โดยเฉพาะผู้ใช้ระบบ Deprivilegedในภาคเอกชน กลุ่ม สำรองข้อมูลด้วยกลุ่มผู้ใช้เฉพาะสำหรับopsและsudo- ไฟล์เหล่านี้ไม่สามารถอ่านได้ในโลกโดยค่าเริ่มต้น สิ่งนี้เป็นไปตามมาตรฐาน 12factor ที่สนับสนุนความดีทั้งหมดของ Dev + Ops plus ซึ่งมีประโยชน์ด้านความปลอดภัยที่เหมาะสมในขณะที่ยังช่วยให้นักพัฒนา / ผู้ทดสอบสามารถวาง EnvironmentFiles ของตนเองในสภาพแวดล้อม dev / qa / test

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

แอปเว็บ Azure มีตัวเลือกให้ใช้รูปแบบนี้และใช้งานได้ดีมาก

นอกจากนั้นมันยังช่วยให้ข้อมูลที่มีความละเอียดอ่อนอาจไม่อยู่ในการควบคุมของแหล่งที่มา การเพิกเฉยไฟล์เหล่านั้นจากแหล่งควบคุมนั้นเป็นไปไม่ได้จริง ๆ (อย่างน้อยก็ใน. NET) เนื่องจากมีการกำหนดค่าสำเร็จรูปจำนวนมากที่จำเป็นในไฟล์เหล่านั้นด้วย