นี่เป็นวิธีที่แนะนำ / ถูกต้องสำหรับการอนุญาตเซิร์ฟเวอร์ไฟล์หรือไม่

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

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

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

นี่คือตัวอย่างที่แสดงสิ่งที่ฉันหมายถึง:

มีการแชร์ที่เรียกว่า "ผลการทดสอบ" บนเซิร์ฟเวอร์ไฟล์ชื่อ FILE01 และคุณมีผู้ที่ต้องการการเข้าถึงแบบอ่านอย่างเดียวการเข้าถึงเพื่ออ่าน - เขียนและการควบคุมอย่างสมบูรณ์ 1 ทรัพยากรที่ปลอดภัย * 3 ระดับการเข้าถึง = 3 กลุ่มความปลอดภัย ในสภาพแวดล้อมโฆษณาของเราเราสร้างกลุ่มเหล่านี้เป็นกลุ่มสากลเพื่อให้เราสามารถเพิ่มผู้ใช้ / กลุ่มจากโดเมนใด ๆ ในฟอเรสต์ได้อย่างง่ายดาย เนื่องจากแต่ละกลุ่มอ้างอิงถึงโฟลเดอร์ที่ใช้ร่วมกันและระดับการเข้าถึงที่ไม่ซ้ำกันชื่อกลุ่มจึงรวมส่วนข้อมูล "คีย์" เหล่านั้นไว้และการอนุญาตจึงเป็นดังนี้:

"FILE01-Test Results-FC"  --  Full Control
"FILE01-Test Results-RW"  --  Read & Write
"FILE01-Test Results-RO"  --  Read Only

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

สองคำถาม:

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

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

แนวทางของฉันคือไม่ใช้การอนุญาตระดับไฟล์ / ไดเรกทอรี ใช้สิทธิ์ในการแชร์ไฟล์และตั้งค่าไดรฟ์ระบบไฟล์ของเซิร์ฟเวอร์ทั้งหมดให้เป็นแบบเต็มทุกคน (ซึ่งกลายเป็นที่สงสัย)

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

ใช้กลุ่มการอ่าน / เขียนของคุณเหมือนกัน แต่ในการแชร์ไฟล์ทั้งหมดโดยใช้ Comp Mgmt MMC อย่าทำเต็มที่ ... ผู้ใช้จะยิงตัวเองด้วยความรู้บางส่วน / เจตนาดีที่สุด

วิธีการนั้นไม่เลว ตามกฎแล้วอย่าใช้ผู้ใช้แต่ละคนเพื่อเพิ่มการอนุญาต - ใช้กลุ่ม อย่างไรก็ตามกลุ่มสามารถใช้ข้ามทรัพยากรได้ เช่น HR อาจมีการเข้าถึงไฟล์ RW ในขณะที่ MANAGERS อาจมี R คุณยังสามารถตั้งค่า Access Based Enumeration ดูเว็บคาสต์ต่อไปนี้:

TechNet Webcast: ชุดการดูแลระบบ Windows Server 2003 (ตอนที่ 4 จาก 12): การจัดการกลุ่ม (ระดับ 200)

การเข้าถึงตามการแจงนับสามารถทำให้ชีวิตง่ายขึ้นเช่นกันดู:

การแจงนับตามการเข้าถึง

ABE สามารถช่วยลดจำนวนหุ้นที่แตกต่างกันที่คุณต้องจัดการ

วิธีการของคุณนั้นเป็นวิธีที่ฉันจะเข้าใกล้
สิ่งเดียวที่ฉันจะเพิ่มคือ:

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

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

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

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

วิธีการที่เสนอดูเหมือนจะค่อนข้างแข็งแกร่ง สิ่งหนึ่งที่ต้องระวังคือวิธีที่คุณตั้งค่าการแชร์ไฟล์ แนวทางปฏิบัติที่แนะนำคือการมีส่วนแบ่งระดับบนสุดเดียวประกอบด้วยโฟลเดอร์ย่อยที่คุณกำหนดสิทธิ์กลุ่มให้ NTFS สามารถเลี่ยงผ่าน "Traverse Folder / Execute File" ในโฟลเดอร์ระดับบนสุดและให้สิทธิ์การเข้าถึงโฟลเดอร์ย่อย

โครงสร้างจะมีลักษณะเหมือน \ servername \ sharename \ group-folder โดยมีการอนุญาตให้ใช้งานร่วมกันซึ่งจำเป็นต้องมีการตั้งค่าในโฟลเดอร์ "sharename" และสิทธิ์ NTFS จริงที่ตั้งค่าในโฟลเดอร์ "group-folder"

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

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

วิธีปฏิบัติมาตรฐานที่ฉันใช้สำหรับไฟล์เซิร์ฟเวอร์ Windows ตั้งแต่ Windows 2000 (วางในชุด Mastering Windows Server ของ Mark Minasi ดังนั้นดูที่นี่สำหรับข้อมูลเพิ่มเติม) คือการใช้กลุ่มที่อยู่ในเครื่องของไฟล์เซิร์ฟเวอร์เพื่อทำรัง

ตัวอย่างเช่นพิจารณาไฟล์เซิร์ฟเวอร์ชื่อ KERMIT ในโดเมนชื่อ MUPPETS

สมมติว่า KERMIT มีการแชร์ไฟล์บางส่วน:

\\KERMIT\Applications
\\KERMIT\Finance
\\KERMIT\Sales
\\KERMIT\Manufacturing

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

KERMIT\Applications-RO
KERMIT\Applications-RW
KERMIT\Applications-FC
KERMIT\Finance-RO
[...]

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

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

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

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

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

ฉันกำลังดูการย้ายข้อมูลจาก NetWare ไปเป็น Windows Server 2008 ดังนั้นเมื่อเร็ว ๆ นี้ฉันก็นึกถึงเรื่องนี้มาก Server 2008 (และในระดับหนึ่ง Server 2003R2) มีคุณสมบัติที่ดีมากที่ทำให้การเปลี่ยนแปลงนี้ง่ายขึ้น Server 2008 มาพร้อมกับ Access Based Enumeration นี่เป็นคุณสมบัติที่ดีมากที่ช่วยให้ผู้ใช้เห็นเฉพาะไดเรกทอรีที่พวกเขามีสิทธิ์ หากคุณมีส่วนแบ่งเช่น ...

\\ ใช้บ้าน srv \ บ้าน \

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

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

เนื่องจาก Netware ดั้งเดิมของเราเรามีกลุ่มจำนวนมากที่ตั้งชื่อตามผู้ที่อยู่ในพวกเขาโดยมีกลุ่มที่ได้รับการตั้งชื่อตามสิ่งที่พวกเขาให้การเข้าถึง สำหรับไดเรกทอรีที่มีการเข้าถึงอย่างเข้มงวดเรายังใช้ระบบตั้งชื่อ "RO" "Full"

เรามีปริมาณ "แชร์" เสาหิน (ยังคงอยู่ใน NetWare แต่เราวางแผนที่จะให้เสาหินเมื่อเราย้ายไปที่ Windows) ซึ่งเป็นไดรฟ์ข้อมูลที่ใช้ร่วมกันเดียวสำหรับพนักงาน 4,400 คนและมีไฟล์มากกว่า 3.5 ล้านไฟล์ ไดเรกทอรีระดับบนสุดคือชื่อแผนกทั้งหมดและแต่ละแผนกควบคุมสิ่งที่เกิดขึ้นภายใน มีข้อยกเว้นบางประการสำหรับแผนกที่มีขนาดใหญ่จริงๆซึ่งมีไดเรกทอรีระดับที่สองที่มี ACL

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

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

โฟลเดอร์ที่ใช้ร่วมกันควรได้รับอนุญาตให้เข้าถึงโดยใช้กลุ่มความปลอดภัย "ทรัพยากร" เช่นตัวอย่าง "FILE01-Test Results-RW" ของคุณ สิ่งนี้จะมีบทบาทงานบทบาทแผนกหรือกลุ่มที่เกี่ยวข้องอื่น ๆ

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

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