วิธีการจัดการสิทธิ์การเข้าถึงอัตโนมัติภายใน AWS S3 Buckets

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

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

ตัวอย่างทั่วไปเพิ่มเติมอาจรวมถึง:

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

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

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

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

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

วิธีการด้วยตนเองที่เรียบง่าย แต่มากมาย

วิธีหนึ่งที่จะแก้ไขปัญหานี้โดยไม่ใช้การทำงานอัตโนมัตินั้นค่อนข้างตรงไปตรงมาและเรียบง่าย:

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

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

ตามค่าเริ่มต้น สามารถสร้างบัคเก็ต S3 ได้สูงสุด 100 บัคเก็ตภายใต้บัญชี AWS เดียว ขีดจำกัดนี้สามารถขยายได้ถึง 1,000 โดยส่งการเพิ่มขีดจำกัดบริการไปยังตั๋ว AWS หากข้อจำกัดเหล่านั้นไม่ใช่สิ่งที่กรณีการใช้งานเฉพาะของคุณกังวล คุณสามารถปล่อยให้ผู้ใช้โดเมนที่แตกต่างกันแต่ละคนดำเนินการบนบัคเก็ต S3 แยกต่างหากและเรียกมันว่าวัน

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

• นักวิเคราะห์ข้อมูลประเมินเนื้อหาข้อมูลสำหรับหลายพื้นที่ ภูมิภาค ฯลฯ
• ทีมทดสอบแบ่งปันบริการที่ให้บริการแก่ทีมพัฒนาที่แตกต่างกัน
• การรายงานผู้ใช้ที่ต้องการสร้างการวิเคราะห์แดชบอร์ดในประเทศต่างๆ ในภูมิภาคเดียวกัน

อย่างที่คุณอาจจินตนาการไว้ รายการนี้สามารถขยายได้อีกมากที่สุดเท่าที่คุณจะจินตนาการได้ และความต้องการขององค์กรสามารถสร้างกรณีการใช้งานได้ทุกประเภท

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

แล้วจะบรรลุสิ่งเดียวกันด้วยวิธีที่เป็นระเบียบและเป็นอัตโนมัติได้อย่างไร

แนะนำแท็กสำหรับถัง

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

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

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

แท็กประเภทใดที่จะใช้ในการทำงานนี้

ขึ้นอยู่กับกรณีการใช้งานที่เป็นรูปธรรมของคุณ ตัวอย่างเช่น:

• อาจจำเป็นต้องแยกบัคเก็ตตามประเภทสภาพแวดล้อม ดังนั้น ในกรณีนั้น หนึ่งในชื่อแท็กควรเป็น "ENV" และมีค่าที่เป็นไปได้คือ "DEV", "TEST", "PROD" เป็นต้น
• บางทีคุณอาจต้องการแยกทีมตามประเทศ ในกรณีนั้น แท็กอื่นจะเป็น "COUNTRY" และให้คุณค่ากับชื่อประเทศ
• หรือคุณอาจต้องการแยกผู้ใช้ตามแผนกการทำงานที่พวกเขาสังกัดอยู่ เช่น นักวิเคราะห์ธุรกิจ ผู้ใช้คลังข้อมูล นักวิทยาศาสตร์ข้อมูล เป็นต้น คุณจึงสร้างแท็กด้วยชื่อ “USER_TYPE” และค่าที่เกี่ยวข้อง
• อีกทางเลือกหนึ่งคือคุณต้องการกำหนดโครงสร้างโฟลเดอร์คงที่อย่างชัดเจนสำหรับกลุ่มผู้ใช้เฉพาะที่พวกเขาจำเป็นต้องใช้ (เพื่อไม่ให้สร้างโฟลเดอร์ที่รกรุงรังและหลงทางเมื่อเวลาผ่านไป) คุณสามารถทำได้อีกครั้งด้วยแท็ก ซึ่งคุณสามารถระบุไดเร็กทอรีการทำงานต่างๆ เช่น: “data/import”, “data/processed”, “data/error” เป็นต้น

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

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

• /<ENV>/<USER_TYPE>/<COUNTRY>/<อัปโหลด>

เพียงแค่เปลี่ยนค่า <ENV> คุณก็สามารถกำหนดวัตถุประสงค์ของแท็กใหม่ได้ (ไม่ว่าจะถูกกำหนดให้ทดสอบระบบนิเวศของสภาพแวดล้อม, dev, prod ฯลฯ)

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

สร้างนโยบายไดนามิกและแมปแท็กบัคเก็ตภายใน

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

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

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

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

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

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

ทำให้การเริ่มต้นใช้งานเอนทิตีใหม่เป็นแบบอัตโนมัติ

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

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

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

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

• create_new_bucket(<ENV>,<ENV_VALUE>,<COUNTRY>,<COUNTRY_VALUE>, ..)
• create_new_tag(<bucket_id>,<tag_name>,<tag_value>)
• update_existing_tag(<bucket_id>,<tag_name>,<tag_value>)
• create_user_group(<user_type>,<country>,<env>)
• เป็นต้น

คุณได้รับประเด็น

เคล็ดลับมือโปร

มีเคล็ดลับสำหรับมือโปรหนึ่งข้อหากคุณต้องการ ซึ่งสามารถนำไปใช้กับคำแนะนำด้านบนได้อย่างง่ายดาย

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

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

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

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

คุณอาจดูที่คำสั่ง AWS S3 เหล่านี้เพื่อจัดการบัคเก็ตและข้อมูล