SharePoint Server의 일반적인 세분화된 사용 권한 문제 해결
적용 대상:
2013 2016 2019 Subscription Edition 
SharePoint in Microsoft 365
세분화된 사용 권한을 구현한 후에 SharePoint 환경에서 보안 또는 성능 문제가 발생할 수 있습니다. 세분화된 사용 권한과 관련될 수 있는 문제를 해결하는 데 도움을 얻으려면 다음 정보를 검토합니다.
일반적인 세분화된 사용 권한 및 성능 문제에 대한 권장 이슈 및 해결 방법
다음 문제는 세분화된 권한의 광범위한 사용과 관련된 성능 문제의 영향을 줄이는 데 도움이 될 수 있습니다. 다음 각 문제는 세분화된 권한과 관련된 성능 문제에 기여하는 환경 보안, 개체 계층 또는 사용자 지정 코드의 변경 내용을 다룹니다. 각 문제는 단일 웹에 여러 문서 라이브러리가 포함된 다음 예제 환경에서 시작되며, 각각 고유하게 권한이 부여된 여러 자식 개체가 있습니다.
이슈 1: 세분화된 사용 권한을 제거하고 웹 수준에서만 보안 적용 사용
더 이상 세분화된 권한이 필요하지 않도록 환경을 다시 설계하기 위해 환경 정리 프로세스를 구현한 다음 범위가 지정된 항목 수를 조정하여 장기적으로 환경의 확장성을 개선할 수 있습니다. 다음 권장 사항은 이 솔루션을 달성하는 데 필요한 환경 정리 및 아키텍처 보안 변경에 대해 설명합니다.
환경 보안 정리
사용자가 웹 수준 범위에서 제거되면 내부 개체 모델은 웹 수준 아래의 모든 범위에서 사용자를 제거해야 합니다. 기존 권한을 정리하기 위해 개별 사용자를 제거하는 것은 시간이 많이 걸리는 프로세스입니다. 대신 먼저 각 고유한 항목 수준 범위를 제거하여 항목이 부모 개체의 사용 권한을 상속하도록 설정됩니다. 이 작업은 항목에 대한 단일 범위에서만 작동해야 하므로 사용자를 먼저 제거하는 것보다 시간이 적게 소요됩니다.
중요
현재 웹이 사이트 모음의 루트에 있지 않으며 웹이 부모 웹에서 권한을 상속하도록 설정된 경우 아래에 포함된 모든 고유 범위가 제거되며 모든 제한된 액세스 구성원 자격이 단일 SQL Server 왕복 작업만에 동시에 덮어쓰여집니다.
모든 항목 수준 범위가 제거된 후에도 액세스를 허용하도록 웹 수준 범위의 개별 범위 구성원 자격이 하나 이상의 그룹 구성원 자격으로 바뀔 수 있습니다.
환경 보안 아키텍처 재설계
기존 세분화된 권한 및 범위가 제거된 후 장기 아키텍처 계획은 웹 수준에서만 고유한 범위를 유지 관리해야 합니다. 다음 다이어그램에서는 웹 수준 범위만 유지되도록 구조화할 수 있는 방법을 보여줍니다. 뷰에서 항목을 처리하는 데 필요한 시간이 늘어나므로 아키텍처의 핵심 요구 사항은 문서 라이브러리에서 동일한 수준의 계층 구조에 너무 많은 항목을 포함하지 않는 것입니다.
해결 방법:
계층 구조의 모든 수준에서 항목 또는 폴더의 최대 수는 약 2,000개입니다.
아키텍처에 대한 추가 변경이 필요한 경우 문서 라이브러리를 다른 웹 또는 사이트 모음으로 이동하는 것이 좋습니다. 문서 라이브러리의 수는 저장된 콘텐츠의 분류 또는 대상 그룹을 기반으로 하는 비즈니스 요구 사항 및 크기 조정 권장 사항을 보다 긴밀하게 지원하도록 변경할 수도 있습니다.
이슈 2: 계층 구조를 변경하여 세분화된 사용 권한 사용
세분화된 사용 권한을 그대로 사용하지만 너무 많은 업데이트를 발생하거나 단일 웹 범위의 크기를 조정하지 않도록 환경을 재설계하려면 보안 지정 방식에 따라 문서 라이브러리를 각기 다른 웹으로 이동하는 것이 좋습니다.
환경 계층 구조 재디자인
다음 다이어그램에서는 각 문서 라이브러리가 고유하게 권한이 부여된 웹에 있도록 물리적 아키텍처가 변경되었습니다. 또한 항목 수준의 세분화된 권한을 유지해야 하는 경우 액세스 권한이 부여되는 누적 보안 주체 수는 고정된 제한은 아니지만 약 2,000개로 제한해야 합니다. 따라서 모든 제한된 액세스 멤버 사용자를 포함하는 각 웹의 유효 멤버 자격은 약 2,000명의 사용자여야 합니다. 이렇게 하면 각 웹 수준 범위가 너무 커지는 것을 방지합니다.
고유 범위의 자식 수는 중요한 문제가 아니며 많은 수로 확장할 수 있습니다. 그러나 범위 체인을 고유하게 권한이 부여된 첫 번째 웹에 대한 제한된 액세스 권한으로 추가되는 원칙의 수는 제한 요소입니다.
마지막으로, 구체적으로 세분화된 권한에 대한 문제는 아니지만 폴더 구조는 문서 라이브러리의 단일 계층적 수준이 약 2,000개 항목을 초과하지 않도록 보장해야 합니다. 이 제한은 사용자가 요청한 보기의 우수한 성능을 보장하는 데 도움이 될 수 있습니다.
이슈 3: 범위 구조를 변경하여 세분화된 사용 권한 사용
환경을 다시 설계하여 세분화된 권한을 계속 사용하지만 단일 웹 범위에 너무 많은 업데이트를 발생하거나 크기를 조정하지 않도록 하려면 다른 항목 보안 프로세스를 사용하는 것이 좋습니다. 이는 많은 수의 고유 범위의 원인이 동적으로 개체 권한을 변경한 이벤트 처리기 또는 워크플로와 같은 자동화된 프로세스인 경우 주로 적용됩니다. 이 경우 고유한 보안 범위를 만드는 프로세스에 관계없이 코드를 변경하는 것이 좋습니다.
동적 보안 변경 코드 재설계
다음 다이어그램에서는 범위 멤버 자격으로 인해 부모 문서 라이브러리 및 웹에서 ACL 다시 계산이 발생하지 않도록 범위 아키텍처가 변경되었습니다. 앞에서 설명한 것처럼 모든 제한된 액세스 멤버를 포함하는 웹의 유효 멤버 자격은 웹 수준 범위가 너무 커지지 않도록 하려면 약 2,000명 이상이어야 합니다. 이 경우 제한된 액세스 권한이 있어야 하는 모든 멤버를 보유하도록 새 SharePoint 그룹을 구현하면 범위가 너무 커지지 않습니다. SharePoint Server SPRoleAssignmentCollection.AddToCurrentScopeOnly 메서드를 사용하여 웹 수준에서 개별 범위에 사용자를 추가할 때 추가 코드를 통해 웹 및 문서 라이브러리 수준에서 제한된 액세스 권한이 있는 것으로 설정된 새 그룹에 추가할 수도 있습니다.
해결 방법:
항목 수준 세분화된 권한을 유지해야 하는 경우 고정된 제한은 아니지만 액세스 권한이 부여될 보안 주체의 누적 수는 약 2,000개로 제한되어야 합니다. 보안 주체 수가 증가하면 이진 ACL을 다시 계산하는 데 더 오래 걸립니다. 범위의 멤버 자격이 변경되면 이진 ACL을 다시 계산해야 합니다. 자식 항목 고유 범위에 사용자를 추가하면 부모 범위 멤버 자격이 변경되지 않더라도 부모 범위가 새 제한 액세스 멤버로 업데이트됩니다. 이 경우 부모 범위에 대한 이진 ACL도 다시 계산해야 합니다.
이전 솔루션에서와 같이 고유하게 범위가 지정된 자식의 수는 중요한 문제가 아니며 많은 수로 확장할 수 있습니다. 첫 번째 고유 권한 웹에 대한 범위 체인에 대한 제한된 액세스 권한으로 추가되는 원칙의 수는 제한 요인이 될 것입니다.