Đây có phải là một cách tiếp cận được đề xuất / hợp lệ cho các quyền của máy chủ tệp không?


10

Máy chủ tệp là một thực tế của CNTT và tôi tò mò liệu có bất kỳ thực tiễn nào được chấp nhận chung không (tôi ngại sử dụng từ "tốt nhất" ở đây) cho cách bạn tạo nhóm và áp dụng quyền để quản lý quyền truy cập của khách hàng vào thư mục dùng chung một máy chủ tập tin.

Ở công việc hiện tại, cuối cùng tôi đã thừa hưởng khá nhiều cách khác nhau để thực hiện việc này, từ hàng chục nhóm trên ACL đến việc đưa người dùng cá nhân trực tiếp vào hệ thống tệp. Nhiệm vụ của tôi là dọn dẹp mớ hỗn độn và đưa ra một số cách tiếp cận tiêu chuẩn này trong toàn công ty (môi trường rộng lớn, nhân sự 150k, máy tính khách 90 nghìn, máy chủ tệp 100).

Từ hiểu biết của tôi về vấn đề này, có vẻ như bạn ở mức tối thiểu cần một nhóm cho mỗi cấp truy cập được yêu cầu cho mỗi tài nguyên được bảo mật. Mô hình này dường như mang lại sự linh hoạt nhất ở chỗ bạn không cần phải chạm lại các quyền của hệ thống tập tin trừ khi bạn cần hỗ trợ một cấp truy cập khác. Nhược điểm là bạn sẽ tạo nhiều nhóm hơn là sử dụng lại cùng một nhóm trên nhiều tài nguyên được chia sẻ.

Đây là một ví dụ cho thấy những gì tôi muốn nói:

Có một chia sẻ gọi là "Kết quả kiểm tra" trên một máy chủ tệp có tên FILE01 và bạn có những người cần truy cập chỉ đọc, truy cập đọc và ghi toàn quyền. 1 tài nguyên được bảo mật * 3 cấp truy cập = 3 nhóm bảo mật. Trong môi trường AD của chúng tôi, chúng tôi tạo các nhóm này dưới dạng các nhóm phổ quát để chúng tôi có thể dễ dàng thêm người dùng / nhóm từ bất kỳ miền nào trong rừng. Vì mỗi nhóm chỉ liên quan đến một thư mục dùng chung và cấp truy cập, nên tên nhóm kết hợp các phần dữ liệu "chính" đó và do đó, các quyền là:

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

Thông thường, chúng tôi cũng sẽ bao gồm tài khoản HỆ THỐNG tích hợp và Quản trị viên tích hợp với quyền truy cập Kiểm soát hoàn toàn. Mọi thay đổi đối với những người thực sự có quyền truy cập vào chia sẻ này giờ đây có thể được xử lý bằng cách sử dụng tư cách thành viên nhóm thay vì phải chạm vào ACL (bằng cách thêm các nhóm "Vai trò" đại diện cho các vai trò kinh doanh cụ thể như Người quản lý, Kỹ thuật viên, Nhà phân tích QA, v.v. người dùng để truy cập một lần).

Hai câu hỏi:

1) Đây thực sự là một cách tiếp cận được đề xuất hoặc hợp lệ để xử lý các quyền hoặc tôi đang thiếu một số giải pháp đơn giản, thanh lịch hơn? Tôi đặc biệt quan tâm đến bất kỳ giải pháp nào sử dụng tính kế thừa nhưng vẫn giữ được tính linh hoạt khi không phải thực hiện lại ACL phần lớn các hệ thống tệp khi mọi thứ thay đổi.

2) Bạn xử lý các quyền của máy chủ tệp và cấu trúc nhóm trong môi trường của bạn như thế nào? Điểm thưởng cho những người cũng đang làm việc trong môi trường lớn.


Câu hỏi rất thú vị. +1 cho mô tả hay. Rất đáng đọc.
John aka hot2use

Câu trả lời:


5

Cách tiếp cận của tôi là không sử dụng quyền cấp tệp / thư mục cấp; sử dụng quyền cấp độ chia sẻ tệp và đặt toàn bộ ổ dữ liệu của hệ thống tệp máy chủ thành Mọi người kiểm soát hoàn toàn (trở thành moot).

Trong nhiều năm (10+), tôi đã thấy rằng các quyền NTFS phức tạp hơn và dẫn đến nhiều lỗi hơn. Nếu các quyền được đặt sai hoặc thừa kế bị hỏng, bạn sẽ lộ dữ liệu và rất khó để tìm và xem nó. Thêm vào đó, bạn gặp phải vấn đề di chuyển / sao chép ... người dùng di chuyển tệp cũng di chuyển ACL của tệp, trong khi sao chép thừa hưởng ACL đích.

Sử dụng các nhóm đọc / ghi của bạn giống nhau, nhưng trên toàn bộ chia sẻ tệp bằng Comp Mgmt MMC. Đừng làm đầy đủ ... người dùng sẽ tự bắn mình với kiến ​​thức một phần / ý định tốt nhất.


Tôi cũng sử dụng phương pháp này và tôi nghĩ rằng nó hoạt động tốt cho các doanh nghiệp vừa và nhỏ, nơi các yêu cầu truy cập không chi tiết.
Kevin Kuphal

+1 Đây là một cách tiếp cận mới lạ và thú vị. Nếu tôi hiểu bạn một cách chính xác, bạn sẽ đặt ACL trên chia sẻ thay vì trên NTFS và chỉ tạo mọi "tài nguyên" chia sẻ của riêng mình. Nó sẽ giải quyết vấn đề di chuyển / sao chép cũng như thay đổi quyền nhanh chóng và không gây đau đớn vì bạn sẽ không phải chạm vào tất cả các tệp / thư mục nếu bạn cần thay đổi. Kết hợp với một số sử dụng DFS sáng tạo cho các tài nguyên lồng nhau, phương pháp này có một số lợi thế rõ ràng.
David Archer

7

Cách tiếp cận đó không tệ. Như một quy tắc không bao giờ sử dụng người dùng cá nhân để thêm quyền - sử dụng một nhóm. Tuy nhiên, các nhóm có thể được sử dụng trên các tài nguyên. Ví dụ: HR có thể có quyền truy cập RW vào các tệp trong khi QUẢN LÝ có thể có R. Bạn cũng có thể thiết lập Bảng liệt kê truy cập. Hãy xem webcast sau:

TechNet Webcast: Dòng quản trị Windows Server 2003 (Phần 4 của 12): Quản lý nhóm (Cấp 200)

Truy cập dựa trên liệt kê có thể làm cho cuộc sống dễ dàng hơn nhìn thấy:

Bảng liệt kê truy cập

ABE có thể giúp giảm số lượng cổ phần khác nhau mà bạn phải quản lý.


Jim, "cái bẫy" chính mà tôi quan tâm là bằng cách sử dụng lại cùng một nhóm trên nhiều tài nguyên, không có cách nào để trả lời "Nhóm X có quyền truy cập vào tài nguyên nào?" mà không kiểm tra mọi tài nguyên trong môi trường (xin lỗi nếu tôi hơi trừu tượng ở đây). Ngoài ra, cuối cùng bạn cũng cần phải ACL lại hệ thống tệp nếu một nhóm khác cũng cần quyền truy cập vào các tệp.
David Archer

@David, thực ra điều đó không hoàn toàn đúng: vì bạn đang đặt tên cho các nhóm tài nguyên với tên mô tả, bạn có thể đi đến các nhóm vai trò (nói Người quản lý) và kiểm tra xem nhóm nào thuộc về (nói FileServer01_HR_RO và FileServer01_Mgmt_RW). Tất nhiên, mô hình này đòi hỏi phải nghiêm ngặt với cả việc đặt tên và tuân theo tiêu chuẩn thành viên nhóm. Nhưng không nghiêm ngặt trong điều này hoặc bất kỳ mô hình nào khác sẽ kết thúc trong một mớ hỗn độn.
curropar

@curropar: Đã 7 năm nhưng tôi / nghĩ / điều tôi đang nói là nếu bạn thực sự đặt các nhóm Vai trò trực tiếp trên ACL tài nguyên thì nó sẽ có vấn đề. Chúng tôi thực sự đã kết thúc việc không sử dụng các nhóm vai trò nào trong dự án mà tôi đang thực hiện đã đặt ra câu hỏi ban đầu vì tất cả đều tự động. Người dùng sẽ yêu cầu quyền truy cập trực tiếp vào các nhóm tài nguyên bằng biểu mẫu web trực tuyến và chủ sở hữu tài nguyên (người kinh doanh) chịu trách nhiệm phê duyệt / từ chối các yêu cầu đó.
David Archer

Điều đó có ý nghĩa; và ngay cả khi nó 7 tuổi, tôi đã tìm kiếm các mô hình cho máy chủ tệp của mình và bài đăng này đã được tìm kiếm trên Google, vì vậy tôi đã nhận xét cho khách truy cập trong tương lai, chỉ trong trường hợp;)
curropar

1
@curropar Hình như tôi chưa bao giờ trả lời các câu hỏi từ nhiều năm trước. Theo như kiểm toán, bạn phải kiểm toán mọi nguồn lực vì cách khác không phải là kiểm toán hợp lệ.
Jim B

2

Cách tiếp cận của bạn về cơ bản là cách tôi sẽ tiếp cận nó.
Những điều duy nhất tôi sẽ thêm là:

1) Tôi sẽ thêm vào sơ đồ "vai trò" của bạn bằng cách đánh giá những gì họ cần trên các máy chủ không chỉ trên một máy chủ mà bạn có thể sẽ chạy ra ngoài các điều này, nhưng lý thuyết của tôi với những người đó là khi bạn chạy vào chúng, tạo một nhóm khác. theo kinh nghiệm của tôi, nơi có một ngoại lệ có rất nhiều.

2) Tôi chắc chắn sẽ đánh giá lại nhu cầu của các nhóm Universal cho mọi thứ khi bạn thực hiện sao chép với họ khi các thành viên và nhóm trong nhóm Universal được sao chép vào các máy chủ Danh mục Toàn cầu trong khi với nhóm Local Local và Global thì chỉ có nhóm nhân rộng đến các máy chủ cửa hàng toàn cầu. Vì vậy, nếu bạn thực hiện một thay đổi trong một nhóm phổ quát, nó sẽ khởi động một bản sao, trong khi với toàn cầu và tên miền cục bộ thì không.


Đồng ý với # 1. Phần vai trò của hệ thống là tùy chọn mặc dù nhưng làm cho việc quản lý dễ dàng hơn. Trên các nhóm Universal, tôi có một số lo ngại về lưu lượng truy cập sao chép nhưng do các thành viên nhóm của chúng tôi thay đổi khá chậm (có thể 1000 nhóm được sửa đổi một ngày?), Nó vẫn chưa trở thành vấn đề. Domain Local trông giống như nó sẽ hoạt động vì chúng có thể chứa người dùng cho bất kỳ tên miền nào trong rừng.
David Archer

Chỉ để theo dõi điều này: Chúng tôi đã kết thúc việc chuyển đổi các nhóm sang Domain Local và hoạt động tốt trong khoảng 6 tháng. THÌ khi chúng tôi có yêu cầu thiết lập môi trường khắc phục thảm họa và có các máy chủ tệp từ một tên miền được thiết lập làm bản sao cho máy chủ tệp từ một tên miền khác, cuối cùng chúng tôi phải chuyển đổi lại thành các nhóm Universal vì nếu không, các máy chủ DR không thể ' t diễn giải các quyền đó (vì các máy chủ DR không cùng tên miền với các máy chủ tệp nguồn và các nhóm cục bộ miền).
David Archer

1

Phương pháp sử dụng nhóm tài nguyên của bạn cho từng cấp truy cập là chính xác. Điều duy nhất tôi sẽ xem xét là sử dụng Domain Local Groups cho tài nguyên. Bạn không nhất thiết phải sử dụng Nhóm chung nếu bạn đang tạo các nhóm tài nguyên dành riêng cho máy chủ.

Nhược điểm của việc sử dụng Miền cục bộ cho các tài nguyên là bạn kết thúc với tổng số nhóm nhiều hơn. Ưu điểm là bạn ít gặp vấn đề với việc nhân rộng, như Zypher lưu ý.


Không chắc chắn tôi hiểu các nhóm Miền cục bộ yêu cầu nhiều nhóm hơn so với các nhóm phổ quát vì tôi vẫn sẽ cần 1 cho mỗi tài nguyên được bảo mật cho mỗi cấp truy cập. Tôi đồng ý với việc không thực hiện các bản sao để nhân rộng vì vậy tôi có thể xem xét việc thay đổi những thứ đó vào một thời điểm nào đó trong tương lai (nên là một thao tác khá đơn giản).
David Archer

1

Cách tiếp cận đề xuất có vẻ khá vững chắc. Một điều cần chú ý là cách ban đầu bạn thiết lập chia sẻ tệp. Thực hành được đề xuất là có một chia sẻ cấp cao nhất, chứa các thư mục con mà sau đó bạn gán quyền cho nhóm. Sau đó, NTFS có thể bỏ qua "Thư mục truy cập / tệp thực thi" trên thư mục cấp cao nhất và cấp quyền truy cập cho thư mục con.

Cấu trúc sau đó sẽ trông giống như \ servername \ sharename \ group-thư mục, với các quyền chia sẻ chỉ cần được đặt trên thư mục "sharename" và các quyền NTFS thực tế được đặt trên thư mục "thư mục nhóm".

Máy chủ tệp của bạn cũng sẽ có thể hoạt động tốt hơn với loại thiết lập này.

Nói chung, những việc khác tôi sẽ làm là có một quy ước đặt tên cho các nhóm sao cho tên nhóm giống với tên thư mục nhóm (với FC / RW / RO được nối thêm nếu muốn) và dán UNC vào thư mục vào mô tả nhóm (để tập lệnh đăng nhập của bạn có thể đọc lại và thiết lập ánh xạ ổ đĩa theo cách đó và cũng để bạn có thể dễ dàng xem các thư mục được chia sẻ áp dụng cho nhóm nào).


Phải, chúng tôi đưa UNC vào phần mô tả vì giới hạn độ dài tên nhóm AD. Trong môi trường sản xuất của tôi, tên nhóm phản ánh đường dẫn UNC đầy đủ đến thư mục có dấu gạch chéo ngược được chuyển thành dấu gạch ngang. Nếu tên quá lớn không phù hợp, chúng tôi sẽ kết thúc (trước hậu tố -RW hoặc -RO) và đặt số tăng 3 chữ số bắt đầu từ 001. Không phải là cách tiếp cận đơn giản nhất nhưng cũng đủ dễ dàng để truy vấn AD.
David Archer

1

Cách thực hành tiêu chuẩn mà tôi đã sử dụng cho máy chủ tệp Windows kể từ Windows 2000 (được trình bày trong sê-ri Máy chủ Windows của Mark Minasi, vì vậy hãy tìm thêm thông tin) là sử dụng các nhóm cục bộ của chính máy chủ tệp để lồng.

Ví dụ: hãy xem xét một máy chủ tệp có tên KERMIT trong một tên miền MUPPETS.

Nói rằng KERMIT có một vài chia sẻ tệp:

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

Tạo các nhóm cục bộ để KERMIT để truy cập và cấp cho họ quyền trên hệ thống tệp chính xác như bạn đã chỉ định (tức là một nhóm cho mỗi cấp truy cập trên mỗi chia sẻ)

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

Vì đây là các nhóm cục bộ, bạn có thể đặt bất kỳ nhóm nào hoặc người dùng nào bạn muốn vào chúng - các nhóm cục bộ miền, nhóm toàn cầu, nhóm phổ quát, tài khoản người dùng từ bất kỳ tên miền nào trong khu rừng của bạn. Quản lý quyền hiện là cục bộ đối với các nhóm của máy chủ tệp chứ không phải hệ thống tệp hoặc AD.

Điều này không thêm một lớp bổ sung vào quản lý nhóm của bạn, nhưng nó có lợi ích là cho phép (nói) quản trị viên trang cục bộ quản lý các máy chủ tệp của riêng họ mà không cần bất kỳ thứ gì ngoài quyền của Quản trị viên đối với máy chủ tệp đó. Nếu bạn có một loại cấu trúc văn phòng chi nhánh được liên kết, trong đó mỗi loại văn phòng làm việc riêng với máy chủ của mình, đây có thể là một lợi ích thực sự. Bạn có thể không muốn phải trao quyền quản trị viên AD cho vài chục quản trị viên trang địa phương.

Nó cũng giữ cho AD của bạn không bị lộn xộn với rất nhiều nhóm (một nhóm trên mỗi cấp truy cập trên mỗi cổ phần có thể tăng lên rất nhanh) và giảm thiểu sao chép nhóm giữa các GC. Nó cho phép bạn dự trữ các nhóm AD của mình cho các vai trò thay vì quyền.

Nếu môi trường của bạn được chuẩn hóa nghiêm ngặt và tất cả các máy chủ tệp giống hệt nhau và được sao chép, thì đây rõ ràng là một lớp nữa của các nhóm bạn không cần. Ngoài ra, nếu bạn biết bạn cần một nhóm AD cụ thể để có cùng quyền đối với một chia sẻ tồn tại trên mỗi máy chủ tệp duy nhất, bạn sẽ cần một số tự động hóa để duy trì điều đó.

Tóm lại, các máy chủ tệp của bạn càng khác nhau, các nhóm máy cục bộ sử dụng càng có ý nghĩa. Chúng càng giống nhau, bạn càng muốn sử dụng hệ thống bạn hiện đang sử dụng.


0

Tôi đang xem xét một quá trình di chuyển từ NetWare sang Windows Server 2008 vì vậy điều này đã xuất hiện trong tâm trí tôi gần đây. Server 2008 (và ở một mức độ nào đó Server 2003R2) có một số tính năng rất hay giúp thực sự dễ dàng chuyển đổi này. Server 2008 đi kèm với liệt kê truy cập dựa trên hộp. Đây là một tính năng rất hay cho phép người dùng chỉ nhìn thấy các thư mục mà họ có quyền. Nếu bạn có một chia sẻ như ...

\ người dùng-nhà-srv \ homes \

Nếu không có ABE, người dùng cuối sẽ thấy hàng chục / hàng trăm / nghìn thư mục. Với ABE, người dùng cuối sẽ chỉ nhìn thấy một. Điều tương tự cũng đúng với cổ phiếu được chia sẻ. Với ABE, bạn có thể có một khối lượng lớn duy nhất cho tất cả các thư mục bộ phận của mình nếu bạn muốn và không spam người dùng của bạn với các thư mục mà họ không thể truy cập. Mặc dù không phải là vấn đề ACL, nhưng nó có liên quan phần nào nên tôi đưa nó lên.

Một điều nữa mà Server 2008 dường như làm tốt hơn các phiên bản trước đó là kế thừa ACL. Nó dường như nhanh hơn trong việc truyền xuống lá thay đổi ACL ở ngọn cây lớn.

Do di sản Netware của chúng tôi, chúng tôi có một số lượng lớn các nhóm được đặt tên dựa trên những người trong đó, với một số ít được đặt tên cho những gì họ cung cấp quyền truy cập. Đối với các thư mục có quyền truy cập trung tâm, chúng tôi cũng sử dụng danh pháp "RO" "Đầy đủ".

Chúng tôi có một khối lượng "chia sẻ" nguyên khối (vẫn trên NetWare, nhưng chúng tôi dự định sẽ có khối lượng nguyên khối khi chúng tôi chuyển sang Windows), đó là khối lượng được chia sẻ duy nhất cho tất cả 4.400 công nhân và có hơn 3,5 triệu tệp trên đó. Các thư mục cấp cao nhất là tất cả các tên bộ phận và mỗi bộ phận quy định những gì diễn ra bên trong chúng. Có một vài trường hợp ngoại lệ cho các phòng ban thực sự lớn, những phòng ban có thư mục cấp 2 với ACL.

Ở công việc cuối cùng của chúng tôi, chúng tôi thậm chí có thể thiết lập quyền để nhân viên nhân sự xin việc sẽ không thể xem dữ liệu ứng dụng của họ trên máy chủ của họ. Phải mất một số bộ lọc quyền thừa kế để thực hiện, tương tự như thẻ "kế thừa khối" trên Windows. Phần khó khăn ở đó là ghi lại tất cả, nhưng nó đã hoạt động .


Tôi đã sử dụng ABE trước đây trong lần đính hôn trước nhưng khiếu nại chính là việc che giấu sự tồn tại của tài nguyên (thư mục) khỏi người dùng không thể truy cập được, khiến họ khó thực sự yêu cầu quyền truy cập nếu đó là thứ họ muốn có một nhu cầu chính đáng để có được vào. Trong môi trường hiện tại của tôi, chúng tôi có các máy chủ NAS dựa trên Linux này vì vậy ABE không phải là một tùy chọn ở đây.
David Archer

0

Một tình huống tốt nhất là mỗi người dùng được thêm vào một nhóm bảo mật cho vai trò công việc của người dùng. Vai trò sau đó được ủy quyền truy cập khi cần thiết.

Tương tự, một thư mục dùng chung phải được cấp quyền truy cập bằng cách sử dụng các nhóm bảo mật "tài nguyên", như ví dụ "FILE01-Test results-RW" của bạn. Điều này sẽ chứa các vai trò công việc, vai trò bộ phận hoặc các nhóm áp dụng khác.

Ưu điểm của thiết kế này là bạn ủy quyền truy cập trên cơ sở từng nhóm (nhóm, bộ phận, v.v.) và không truy cập một lần có thể khó theo dõi. Khi người dùng chuyển sang bộ phận khác, bạn cần dọn sạch tất cả các quyền truy cập cũ.

Nhược điểm là các nhóm có thể bị lạm dụng. Tạo sự khác biệt rõ ràng về việc các nhóm được sử dụng để làm gì, để các nhóm tài nguyên được gán cho một chia sẻ không được sử dụng lại như thể chúng là các nhóm bộ phận, tạo ra một mớ hỗn độn truy cập.


Đồng ý về kịch bản trường hợp tốt nhất sẽ có đủ kiến ​​thức và sự gắn kết với doanh nghiệp để có thể vạch ra vai trò công việc cho từng "loại" người dùng nhưng trong môi trường của tôi (công ty toàn cầu, 150k + người dùng) thì điều đó không thực tế mong đợi những người kinh doanh dành thời gian cần thiết để vạch ra điều đó. Về cơ bản, chúng tôi đã đi theo con đường khác chỉ với truy cập một lần nhưng chúng tôi đã tự động hóa toàn bộ quy trình để nó không phải là gánh nặng cho CNTT.
David Archer

Đối với các động thái và "dọn dẹp" quyền truy cập cũ, một lần nữa, chúng tôi đã tự động hóa quy trình và trách nhiệm thuộc về chủ sở hữu tài nguyên để định kỳ xem xét và yêu cầu xóa quyền truy cập đối với những người không còn quyền truy cập. "Di chuyển" trong môi trường của chúng tôi thường không liên quan đến việc xóa quyền truy cập vào tài nguyên vì ai tốt hơn chủ sở hữu tài nguyên để biết liệu người này có còn cần quyền truy cập hay không ở vị trí mới của họ?
David Archer

Cố gắng vạch ra 150k người dùng và vai trò của họ là một dấu hiệu cho thấy công ty đã không thực hiện nghiên cứu của họ trước khi phát triển đến quy mô đó. Rõ ràng, dễ dàng hơn nhiều để có khuôn khổ trước khi tăng trưởng mở rộng.
spoulson
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.