이것이 파일 서버 권한에 권장되는 / 올바른 접근입니까?

파일 서버는 IT 분야의 사실이며 그룹을 만들고 공유 폴더에 대한 클라이언트 액세스를 관리하기위한 권한을 적용하는 방법에 대해 일반적으로 인정되는 관행 (여기서는 "최고"라는 단어를 사용하는 것이 주저함)이 있는지 궁금합니다. 파일 서버.

현재 직장에서 ACL의 수십 그룹에서 개별 사용자를 파일 시스템에 직접 배치하는 것에 이르기까지 다양한 방법으로 많은 혼란을 겪었습니다. 내 임무는 엉망을 정리하고 회사 전체 (대규모 환경, 150k 직원, 90k 클라이언트 컴퓨터, 100 대 파일 서버)에 접근하는 표준화 된 방법을 고안하는 것이 었습니다.

이 문제에 대한 나의 이해에서 최소한 보안 리소스 당 필요한 액세스 수준 당 하나의 그룹이 필요합니다. 이 모델은 다른 액세스 수준을 지원할 필요가 없으면 파일 시스템 권한을 다시 만질 필요가 없다는 점에서 가장 융통성이있는 것 같습니다. 단점은 여러 공유 리소스에서 동일한 그룹을 재사용하는 것보다 더 많은 그룹을 생성한다는 것입니다.

다음은 내가 무슨 뜻인지 보여주는 예입니다.

FILE01이라는 파일 서버에 "Test Results"라는 공유가 있으며 읽기 전용 액세스, 읽기 / 쓰기 액세스 및 모든 권한이 필요한 사용자가 있습니다. 1 개의 보안 리소스 * 3 개의 액세스 수준 = 3 개의 보안 그룹. AD 환경에서는 이러한 그룹을 유니버설 그룹으로 만들어 포리스트의 모든 도메인에서 사용자 / 그룹을 쉽게 추가 할 수 있습니다. 각 그룹은 공유 폴더 및 액세스 수준을 고유하게 참조하기 때문에 그룹 이름에는 이러한 "핵심"데이터 조각이 포함되므로 권한은 다음과 같습니다.

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

일반적으로 내장 시스템 계정과 모든 권한을 가진 내장 관리자도 포함합니다. 실제로이 공유에 대한 액세스 권한을 얻는 사람에 대한 변경 사항은 이제 ACL, 관리자, 기술자, QA 분석가 등과 같은 특정 비즈니스 역할을 나타내는 "역할"그룹을 추가하거나 그룹 구성원을 사용하여 그룹 구성원을 사용하여 처리 할 수 ​​있습니다. 일회성 액세스 사용자).

두 가지 질문 :

1) 이것은 실제로 권한을 처리하기 위해 권장되거나 유효한 접근법입니까, 더 간단하고 우아한 솔루션이 누락 되었습니까? 상속을 사용하지만 상황이 바뀌면 파일 시스템의 많은 부분을 다시 ACL하지 않아도되는 유연성을 유지하는 솔루션에 특히 관심이 있습니다.

2) 환경에서 파일 서버 권한 및 그룹 구조를 어떻게 처리합니까? 큰 환경에서 일하는 사람들을위한 보너스 포인트.

내 접근 방식은 파일 / 디렉토리 레벨 파일 권한을 사용하지 않는 것입니다. 파일 공유 레벨 권한을 사용하고 전체 서버 파일 시스템 데이터 드라이브를 Everyone Full Control (무엇이 될지)로 설정하십시오.

몇 년 동안 (10+) NTFS NTFS 권한이 더 복잡하고 더 많은 오류가 발생한다는 것을 알았습니다. 권한이 잘못 설정되거나 상속이 중단되면 데이터를 찾아서 찾기가 어렵습니다. 또한 이동 / 복사 문제에 노출됩니다. 파일을 이동하는 사용자도 파일의 ACL을 이동하지만 copy는 대상 ACL을 상속합니다.

Comp Mgmt MMC를 사용하여 전체 파일 공유에서 읽기 / 쓰기 그룹을 동일하게 사용하십시오. 완전하지 마십시오 ... 사용자는 부분 지식 / 최선의 의도로 자신을 쏠 것입니다.

그 접근 방식은 나쁘지 않습니다. 일반적으로 개별 사용자를 사용하여 권한을 추가하지 마십시오. 그룹을 사용하십시오. 그러나 그룹은 여러 자원에서 사용될 수 있습니다. 예를 들어 HR에 파일에 대한 RW 액세스 권한이 있고 MANAGERS에 R이있을 수 있습니다. 액세스 기반 열거를 설정할 수도 있습니다. 다음 웹 캐스트를 살펴보십시오.

TechNet 웹 캐스트 : Windows Server 2003 관리 시리즈 (4/4 부) : 그룹 관리 (레벨 200)

액세스 기반 열거는 삶을 더 쉽게 만들 수 있습니다.

액세스 기반 열거

ABE는 관리해야하는 다른 공유 수를 줄이는 데 도움이 될 수 있습니다.

귀하의 접근 방식은 기본적으로 내가 접근하는 방식입니다.
내가 추가 할 유일한 것은 이것입니다 :

1) 나는 당신이 아마도 이것에 대한 이상치에 빠질 것 중 하나의 서버가 아닌 서버간에 필요한 것을 평가함으로써 당신의 "역할"체계에 추가하고 싶지만, 이것들에 대한 나의 이론은 당신이 그들에 부딪 치면 다른 그룹을 만드는 것입니다. 하나의 이상 치가있는 내 경험에는 많은 것이 있습니다.

2) 유니버설 그룹 내부의 구성원과 그룹이 글로벌 카탈로그 서버에 복제되는 동안 도메인 로컬 및 글로벌 만 사용하면 그룹에 대한 복제 적중시 모든 그룹에 대한 유니버설 그룹의 필요성을 강력하게 재평가합니다. 글로벌 카탈로그 서버에 복제되었습니다. 따라서 유니버설 그룹을 변경하면 글로벌 및 도메인 로컬에서는 복제를 시작하지만 복제는 시작되지 않습니다.

각 액세스 레벨마다 자원 그룹을 사용하는 방법이 정확합니다. 내가 고려해야 할 유일한 것은 리소스에 도메인 로컬 그룹을 사용하는 것입니다. 서버 별 리소스 그룹을 생성하는 경우 반드시 유니버설 그룹을 사용할 필요는 없습니다.

리소스에 도메인 로컬 그룹을 사용하는 단점은 더 많은 총 그룹을 갖게된다는 것입니다. Zypher가 지적했듯이 단점은 복제 문제가 적다는 것입니다.

제안 된 접근 방식은 상당히 견고합니다. 그러나 주목해야 할 것은 처음에 파일 공유를 설정하는 방법입니다. 권장되는 방법은 그룹 권한을 할당 할 하위 폴더가 포함 된 단일 최상위 공유를 갖는 것입니다. 그런 다음 NTFS는 최상위 폴더에서 "Traverse Folder / Execute File"을 무시하고 하위 폴더에 대한 액세스 권한을 부여 할 수 있습니다.

그런 다음 구조는 \ servername \ sharename \ group-folder와 같으며 공유 권한은 "sharename"폴더에만 설정하고 실제 NTFS 권한은 "group-folder"폴더에 설정하면됩니다.

이러한 종류의 설정으로 파일 서버의 성능을 향상시킬 수 있습니다.

내가 할 일반적인 다른 일은 그룹 이름이 그룹 폴더 이름과 같도록하고 (원하는 경우 FC / RW / RO가 추가 된) 그룹 이름 지정 규칙을 가지고 폴더에 UNC를 그룹 설명에 붙여 넣는 것입니다. 로그온 스크립트가이를 읽고 드라이브 매핑을 그런 식으로 설정하고 어떤 공유 폴더가 어떤 그룹에 적용되는지 더 쉽게 볼 수 있도록합니다.

Windows 2000 이후 Windows 파일 서버에 사용했던 표준 사례 (Mark Minasi의 Mastering Windows Server 시리즈에 배치되어 있으므로 자세한 내용을 참조하십시오)는 중첩을 위해 파일 서버 자체에 로컬 인 그룹을 사용하는 것입니다.

예를 들어, MUPPETS라는 도메인에 KERMIT라는 파일 서버를 고려하십시오.

KERMIT에 몇 개의 파일 공유가 있다고 가정하십시오.

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

액세스 할 그룹을 KERMIT에 로컬로 작성하고 지정한대로 파일 시스템에 대한 권한을 부여하십시오 (예 : 공유 당 액세스 레벨 당 하나의 그룹).

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

이들은 로컬 그룹이므로 도메인 로컬 그룹, 글로벌 그룹, 유니버설 그룹, 포리스트의 모든 도메인에있는 사용자 계정 등 원하는 다른 그룹이나 사용자를 포함 할 수 있습니다. 권한 관리는 이제 파일 시스템이나 AD가 아닌 파일 서버 그룹에 로컬입니다.

이렇게하면 그룹 관리에 추가 계층이 추가되지만 사이트 로컬 관리자가 해당 파일 서버에 대한 관리자 권한 외에 다른 파일 서버를 관리 할 수 ​​있다는 이점이 있습니다. 모든 종류의 사무실에서 자체 서버를 사용하는 페더레이션 종류의 지점 구조가있는 경우 이는 실질적인 이점이 될 수 있습니다. 수십 명의 로컬 사이트 관리자에게 AD 관리자 권한을 부여하지 않아도됩니다.

또한 많은 그룹 (서버 당 공유 수준 당 하나의 그룹이 매우 빠르게 추가 될 수 있음)으로 인해 AD가 복잡 해지는 것을 방지하고 GC 간의 그룹 복제를 최소화합니다. 권한 대신 역할을 위해 AD 그룹을 예약 할 수 있습니다.

환경이 엄격하게 표준화되어 있고 모든 파일 서버가 동일하고 복제 된 경우 이는 필요하지 않은 하나 이상의 그룹 계층입니다. 또한 모든 단일 파일 서버에 존재하는 공유에 대해 동일한 권한을 갖기 위해 특정 AD 그룹이 필요하다는 것을 알고 있다면이를 유지하기 위해 자동화가 필요합니다.

간단히 말해서, 파일 서버가 서로 다르면 시스템 로컬 그룹을 더 많이 사용하는 것이 합리적입니다. 유사할수록 현재 사용중인 시스템을 더 많이 사용하려고합니다.

NetWare에서 Windows Server 2008 로의 마이그레이션을보고 있으므로 최근에 많이 생각했습니다. Server 2008 (및 어느 정도 Server 2003R2)에는 이러한 전환을 용이하게하는 매우 유용한 기능이 있습니다. Server 2008은 기본적으로 액세스 기반 열거와 함께 제공됩니다. 이것은 사용자에게 권한이있는 디렉토리 만 볼 수있는 매우 유용한 기능입니다. 당신이 같은 공유를 가지고 있다면 ...

\\ user-home-srv \ homes \

ABE가 없으면 최종 사용자는 수십 / 수백 / 수천 개의 디렉토리를 볼 수 있습니다. ABE를 사용하면 최종 사용자는 하나만 볼 수 있습니다. 공유 공유도 마찬가지입니다. ABE를 사용하면 원하는 경우 모든 부서 디렉토리에 대해 하나의 거대한 볼륨을 가질 수 있으며 사용자가 액세스 할 수없는 디렉토리로 스팸 메일을 보내지 않아도됩니다. ACL 문제는 아니지만 다소 관련이 있으므로이를 제기합니다.

Server 2008이 이전 버전보다 더 나은 것으로 보이는 또 다른 것은 ACL 상속입니다. 큰 트리의 맨 위에서 ACL 변경 사항을 리프로 전파하는 것이 더 빠릅니다.

Netware의 레거시로 인해 우리는 누가 속한 사람을 기준으로 이름이 지정된 많은 그룹을 보유하고 있으며, 그 중 몇 개는 액세스 권한을 부여한 그룹을 가지고 있습니다. 액세스가 제한적인 디렉토리의 경우 "RO" "Full"명명법도 사용합니다.

우리는 4,400 명의 모든 작업자를위한 단일 공유 볼륨 인 단일 "공유"볼륨 (NetWare에서는 여전히 Windows로 이동할 때이를 단일체로 만들 계획)을 가지고 있으며 350 만 개 이상의 파일을 보유하고 있습니다. 최상위 디렉토리는 모든 부서 이름이며 각 부서는 그 내부에서 일어나는 일을 규제합니다. 실제로 큰 부서에는 ACL이있는 2 단계 디렉토리가있는 예외가 있습니다.

마지막 작업에서 우리는 권한을 설정하여 작업을 신청하는 HR 직원이 서버에서 자신의 응용 프로그램 데이터를 볼 수 없었습니다. 이를 위해서는 상속 권한 필터가 필요했으며 이는 Windows의 "블록 상속"태그와 유사합니다. 까다로운 부분은 모두 문서화하는 것이었지만 효과가 있었습니다.

가장 좋은 시나리오는 모든 사용자가 사용자의 역할에 대해 하나의 보안 그룹에만 추가하는 것입니다. 그런 다음 필요한 경우 역할이 액세스 권한을 위임받습니다.

마찬가지로, "FILE01-Test Results-RW"예제와 같이 "리소스"보안 그룹을 사용하여 공유 폴더에 액세스 권한을 부여해야합니다. 여기에는 직무 역할, 부서 역할 또는 기타 해당 그룹이 포함됩니다.

이 디자인의 장점은 그룹별로 (팀, 부서 등) 액세스 권한을 위임하며 추적하기 어려운 일회성 액세스 권한은 아니라는 것입니다. 사용자가 다른 부서로 이전 할 때는 이전 액세스를 모두 정리해야합니다.

단점은 그룹을 오용 할 수 있다는 것입니다. 공유에 할당 된 자원 그룹이 부서 그룹처럼 재사용되지 않아 액세스가 엉망이되도록 그룹이 무엇을 사용하는지 명확하게 구분하십시오.