논리 아키텍처 디자인 예제: 공동 작업 사이트

  • 아티클

업데이트 날짜: 2009년 4월

적용 대상: Office SharePoint Server 2007

 

마지막으로 수정된 항목: 2015-03-09

이 문서의 내용

  • 모델 정보

  • 전체 디자인 목표

  • 서버 팜

  • 사용자, 영역 및 인증

  • 관리 사이트

  • 응용 프로그램 풀

  • 웹 응용 프로그램

  • 사이트 모음

  • 콘텐츠 데이터베이스

  • 영역 및 URL

  • 영역 정책

  • 공동 작업 사이트 백업 및 복원

  • 외부 보안 공동 작업 디자인

이 문서에서는 논리 아키텍처 구성 요소를 실제로 구현하여 작업 가능한 디자인을 얻는 방법에 대해 설명합니다. 이 문서는 논리 아키텍처 예제 디자인: Windows SharePoint Services 공동 작업 (영문)(https://go.microsoft.com/fwlink/?linkid=124861&clcid=0x412) 모델과 함께 사용해야 합니다.

모델 정보

이 모델은 Fabrikam, Inc.라는 가상의 회사에 대한 배포를 보여 줍니다. 이 모델에 나와 있는 유형의 공동 작업 사이트가 하나 이상 포함된 솔루션을 계획하는 경우 이 모델을 기반으로 해서 자신만의 디자인을 만들 수 있습니다.

이 모델에서는 다음과 같이 서로 다른 세 가지 유형의 공동 작업 사이트가 포함된 Windows SharePoint Services 3.0의 일반 배포를 보여 줍니다.

  • 팀 사이트

  • 셀프 서비스 사이트

  • 파트너 공동 작업 사이트

이 모델은 거의 모든 논리 아키텍처 구성 요소에 적용되며 이러한 구성 요소를 전체 디자인에 통합하는 방법을 보여 줍니다. 이 문서에서는 모델의 디자인 목표를 설명하고 모델에 나와 있는 논리 아키텍처 구성 요소를 사용하여 이러한 목표를 달성하는 방법도 설명합니다.

서로 다른 유형이라도 각 공동 작업 사이트는 다음과 같은 특징을 갖습니다.

  • 데이터 특성이 서로 다른 데이터를 호스팅합니다.

  • 서로 다른 사용 프로필에 종속됩니다.

  • 서로 다른 사용 권한 관리 전략이 필요합니다.

따라서 이 모델에서는 각 응용 프로그램의 성능과 보안을 최적화는 디자인이 선택되었습니다.

팀 사이트

팀 사이트는 체계적이고 엄격히 관리되는 공동 작업 사이트이며 다음과 같은 특징을 갖습니다.

  • 최상위 사이트 모음 수가 적으며 이러한 사이트 모음의 용도는 셀프 서비스 사이트와 달리 많은 양의 데이터를 포함하기 위한 것입니다.

  • 최상위 URL이 각 팀과 관련된 의미를 지닙니다.

  • 사이트 계층 구조, 분류 및 사용자 지정에 대한 계획을 더욱 체계적으로 세웁니다.

  • 각 팀의 콘텐츠는 별도의 데이터베이스에 저장되므로 이를 개별적으로 관리할 수 있습니다.

다음 그림에서는 팀 사이트의 사이트 계층 구조를 보여 줍니다.

팀 사이트의 구성

셀프 서비스 사이트

셀프 서비스 사이트는 엄격히 관리되는 팀 사이트를 대신하여 사용할 수 있는 사이트입니다. 셀프 서비스 사이트 관리를 사용하여 각 사용자와 팀이 고유한 사이트 모음을 만들도록 할 수 있습니다. 이 경우 중앙 관리에서 셀프 서비스 사이트 관리를 사용하도록 설정하면 됩니다. 이 방법은 그룹이나 커뮤니티에서 사이트를 만들 수 있도록 허용하려는 경우에 가장 적합합니다. 또한 사이트를 호스팅하고 사용자가 세부 절차를 기다릴 필요 없이 사이트를 만들 수 있도록 하려는 경우에도 유용합니다.

일반적으로 셀프 서비스 사이트의 특징은 엄격히 관리되는 사이트와 다릅니다. 셀프 서비스 사이트의 주요 특징은 다음과 같습니다.

  • 최상위 사이트 모음 수가 많습니다.

  • 사이트 모음별로 포함되는 데이터의 양이 적습니다.

  • URL이 자동으로 생성되지만 일반적으로 의미를 갖지 않습니다.

다음 그림에서는 이 디자인 예제에 구현된 셀프 서비스 사이트를 보여 줍니다.

셀프 서비스 사이트를 만들 수 있는 사이트

셀프 서비스 사이트를 구현하려는 경우 유의해야 할 단점이 몇 가지 있습니다. 이러한 단점은 해당 유형의 사이트를 관리하는 방식에 다음과 같은 영향을 줍니다.

  • 자세한 분류를 구현하는 것이 아니라 사이트 간에 아무런 구성 원칙 없이 사용자가 필요할 때마다 사이트를 만듭니다. 새 사이트 각각이 사이트 모음이므로 셀프 서비스 사이트 간에 서식 파일과 탐색을 공유할 수 없습니다.

  • 각 사이트 모음에서 해당 사이트 모음의 콘텐츠에 대해서만 검색을 제공하므로 사이트 모음 간 검색 결과를 집계할 수 없습니다.

  • 사이트 모음의 크기와 용도가 저마다 크게 다를 수 있습니다.

  • 사이트 사용을 쉽게 중단할 수 있습니다.

셀프 서비스 사이트 관리에는 콘텐츠 데이터베이스의 대상 규모를 기준으로 콘텐츠 저장소를 관리하는 작업과 더 이상 사용되지 않는 사이트를 정기적으로 삭제하는 작업이 포함될 수 있습니다.

셀프 서비스 사이트 관리를 구현하는 방법에 대한 자세한 내용은 사이트 만들기 프로세스 계획(Windows SharePoint Services)을 참조하십시오.

파트너 공동 작업 사이트

파트너 웹 응용 프로그램은 파트너 회사의 직원과 안전하게 공동 작업할 수 있는 외부에서 사용 가능한 사이트를 호스팅합니다. 이 응용 프로그램을 사용하여 공동 작업에 안전한 사이트를 손쉽게 만들 수 있습니다. 이 응용 프로그램을 디자인할 때 고려할 주요 사항은 다음과 같습니다.

  • **콘텐츠 격리   **파트너는 서버 팜에 호스팅되는 다른 콘텐츠 형식에 액세스할 수 없습니다.

  • **파트너 계정을 별도로 인증   **파트너 계정은 폼 인증을 통해 관리되며 기업 디렉터리에 추가되지 않습니다.

  • **사용 권한 관리   **개별 사이트 소유자는 자신의 사이트에 대한 사용 권한을 관리하고 공동으로 작업할 참가자만 초대합니다.

다음 그림에서는 파트너 공동 작업 사이트를 보여 줍니다.

파트너 웹의 프로젝트 사이트 계층

전체 디자인 목표

이 모델에서는 팀 사이트, 셀프 서비스 사이트, 파트너 사이트 등의 몇 가지 서로 다른 유형의 공동 작업 응용 프로그램 내에서 Windows SharePoint Services 3.0 기능을 실제로 구현하는 방법을 보여 줍니다. 또한 이 문서에서는 개별 사이트 응용 프로그램의 디자인 구현에 대해 설명합니다. 모델에 대한 주요 디자인 목표는 다음과 같습니다.

  • 확장 가능한 환경을 디자인하는 프레임워크를 만듭니다. 개별 공동 작업 응용 프로그램을 디자인할 때 다른 응용 프로그램을 추가할 수 있도록 해야 합니다. 예를 들어 초기 배포에는 공동 작업 팀 사이트나 파트너만 포함될 수 있습니다. 비슷한 논리 아키텍처 디자인을 사용하면 초기 공동 작업 사이트의 디자인에 영향을 주지 않고도 솔루션에 다른 유형의 공동 작업 사이트를 추가할 수 있습니다. 즉, 환경을 사용하는 방법을 제한하는 요소는 디자인에 포함하지 말아야 합니다.

  • 서로 다른 공동 작업 응용 프로그램 내에서 콘텐츠의 보안을 약화시키지 않으면서 몇 가지 유형의 사용자에게 액세스를 제공합니다. 네트워크 영역(내부 및 외부)과 인증 공급자가 서로 다른 여러 사용자가 공동 작업에 참여할 수 있습니다. 또한 사용자는 액세스 권한이 부여된 콘텐츠에만 액세스할 수 있습니다. 비슷한 논리 아키텍처 디자인에 따라 여러 위치에 있으며 작업 목표가 서로 다른 여러 사용자에게 액세스 권한을 제공할 수 있습니다. 예를 들어 초기 디자인에서는 내부 직원에게만 액세스 권한을 부여한 후 나중에 비슷한 디자인을 사용하여 원격 위치에 있는 직원, 파트너 직원 또는 고객에게까지 액세스 권한을 부여할 수도 있습니다.

  • 익스트라넷 환경에서 해당 디자인을 사용할 수 있어야 합니다. 경계 네트워크 또는 익스트라넷 팜 토폴로지 디자인(Windows SharePoint Services)에서 설명하는 익스트라넷 토폴로지 내에 서버 팜을 안전하게 배포하기 위한 디자인 요소를 신중하게 선택할 수 있습니다.

이 문서의 나머지 부분에서는 모델에 나타나는 각 논리적 구성 요소를 위쪽부터 아래쪽으로 설명하고 모델에 적용되는 디자인 선택 사항에 대해 논의합니다. 이런 식으로 설명하는 목적은 응용 프로그램에 따라 논리 아키텍처 구성 요소를 구성할 수 있는 다양한 방법을 보여 주기 위한 것입니다.

서버 팜

이 모델에서는 서버 팜(서버 5대)을 보여 줍니다. 그러나 단일 서버를 비롯하여 규모에 상관없이 어떤 팜에서나 이 모델을 구현할 수 있습니다. 모델의 서버 팜은 다음과 같은 토폴로지를 사용한 서버 다섯 대로 구성되어 있습니다.

  • 프런트 엔드 웹 서버 두 대

  • 검색 서버로 사용할 응용 프로그램 서버 한 대

  • 클러스터링 또는 미러링된 데이터베이스 서버 두 대

이 모델에서는 다음과 같은 Windows SharePoint Services 3.0의 논리 아키텍처를 보여 줍니다.

  • 모든 사이트가 프런트 엔드 웹 서버 간에 미러링됩니다.

  • 사용자가 직접 액세스할 수 없도록 중앙 관리 사이트가 응용 프로그램 서버에 설치됩니다.

실제 환경에서 서버 컴퓨터의 수와 서버 팜의 토폴로지는 필요에 따라 용량과 성능을 높이려는 경우를 제외하고 논리 아키텍처에서 중요하지 않습니다. 논리 아키텍처는 서버 팜 토폴로지에 관계없이 디자인할 수 있습니다. 성능 및 용량 계획을 세우면 성능 및 용량 목표에 맞게 서버 팜의 규모를 결정할 수 있습니다. 자세한 내용은 성능 및 용량 계획(Windows SharePoint Services)을 참조하십시오.

사용자, 영역 및 인증

이 모델에서는 서로 다른 영역에 할당된 다섯 가지 사용자 유형을 보여 줍니다. 각 웹 응용 프로그램 내에서 사용 가능한 영역 이름(기본, 인트라넷, 인터넷, 사용자 지정 또는 익스트라넷) 중 하나를 사용하여 최대 다섯 개의 영역을 만들 수 있습니다. 둘 이상의 웹 응용 프로그램을 호스팅하는 팜에서는 여섯 가지 이상의 네트워크 영역(웹 응용 프로그램당 최대 다섯 가지 영역)에서 들어오는 사용자 요청을 지원할 수 있습니다. 그러나 이 모델에서는 다섯 가지 영역만 보여 줍니다.

사용자 및 인증

이 모델에서는 서로 다른 네트워크 영역에 속한 사용자 간에 인증이 적용되는 방식을 보여 줍니다. 다음 표에서는 각 유형의 사용자와 영역에 어떤 인증이 적용되는지도 보여 줍니다.

영역 사용자 인증

인트라넷

내부 직원

NTLM(Windows 통합)

기본

원격 직원

NTLM(Windows 통합) 또는 LDAP(Lightweight Directory Access Protocol)를 사용한 폼 인증

익스트라넷

파트너 직원

폼 인증

내부 직원

인트라넷 영역은 내부 직원 액세스용으로 사용됩니다. 이때 Windows 통합 인증이 사용됩니다.

원격 직원

기본 영역은 원격 직원 액세스용으로 사용됩니다. 기본 영역의 디자인 목표는 다음과 같습니다.

  • 내부 Active Directory 디렉터리 서비스 환경에 대해 인증합니다.

  • 내부 직원과 원격 직원 모두에 대해 Windows 인증을 사용하여 권한 관리를 간소화합니다. 이 목표가 중요한 이유는 사용자가 서로 다른 두 가지 인증 공급자를 통해 사이트에 연결할 경우 Windows SharePoint Services 3.0에서 각 사용자에 대해 서로 다른 두 계정을 만들며 두 계정에 모두 사용 권한이 있어야 하기 때문입니다.

이 모델에는 원격 직원을 인증하는 서로 다른 두 가지 옵션이 나와 있습니다. 첫 번째 옵션(NTLM을 사용한 Windows 통합 인증)을 사용하면 두 가지 디자인 목표가 모두 달성되며, 두 번째 옵션(LDAP를 사용한 폼 인증)을 사용하면 첫 번째 목표만 달성됩니다. 따라서 원격 직원에 대해서는 첫 번째 옵션을 사용하는 것이 좋습니다.

다음 표에는 두 가지 인증 옵션의 차이점이 설명되어 있습니다.

비교 유형 NTLM을 사용한 Windows 통합 인증 LDAP 공급자를 사용한 폼 인증

기능

이 방법에서는 ISA(Internet Security and Acceleration) Server 2006 또는 IAG(Intelligent Application Gateway) 2007을 사용하여 사용자를 인증한 다음 사용자 자격 증명을 Windows SharePoint Services 3.0으로 전송합니다. 이러한 서버에서는 폼 인증을 사용하여 Active Directory 환경에 대해 사용자를 인증합니다. 그런 다음 Windows 자격 증명을 Windows SharePoint Services 3.0으로 전송합니다. 자세한 내용은 다음 리소스를 참조하십시오.

영역이 기본 영역이므로 인덱스 구성 요소의 요구 사항을 충족하기 위해 NTLM 인증이 사용됩니다. 자세한 내용은 이 문서의 뒷부분에서 "기본 영역의 구성 요구 사항"을 참조하십시오.

Windows SharePoint Services 3.0에서는 LDAP 공급자를 사용한 폼 인증을 통해 내부 Active Directory 환경에 대해 원격 직원을 인증합니다.

장점

내부에서도 작업하고 원격으로도 작업하는 사용자에 대해 Windows SharePoint Services 3.0에서 서로 다른 두 계정을 만들지 않습니다. 따라서 사용 권한 관리가 크게 간소화됩니다.

프록시 서버에서 사용자를 인증하고 자격 증명을 전달할 필요가 없습니다.

단점

ISA Server 2006, IAG 2007 또는 기타 프록시 서버 제품에 맞게 조정하고 이러한 제품을 구성해야 합니다.

사용자가 내부 및 원격 위치에서 Windows SharePoint Services 3.0에 연결하는 경우 Windows SharePoint Services 3.0에서 서로 다른 두 사용자 계정이 만들어집니다. 따라서 사이트 및 문서에 대한 사용 권한이 두 계정 모두에 필요합니다. 이런 이유로 내부 네트워크와 원격 위치에서 모두 작업하려는 직원은 자신의 사이트 및 문서에 대한 사용 권한을 두 사용자 계정 모두에서 관리해야 합니다.

파트너 직원

파트너 직원은 익스트라넷 영역을 통해 네트워크에 액세스하며 폼 인증을 사용하여 인증됩니다. 따라서 익스트라넷에 파트너 계정을 저장할 Microsoft SQL Server 데이터베이스 및 공급자와 같은 별도의 디렉터리 및 공급자가 필요합니다. 이 방법의 장점은 파트너 계정을 별도로 관리할 수 있으며 내부 직원 디렉터리에 파트너 계정을 추가할 필요가 없다는 데 있습니다.

또는 웹 SSO(Single Sign-On)를 사용하여 파트너의 자체 디렉터리에 대해 인증할 수 있습니다. 그러나 이 방법을 사용하려면 각 파트너 디렉터리에 별도의 영역이 필요합니다.

이 모델에서는 Fabrikam이 같은 파트너 응용 프로그램 내에서 서로 다른 여러 회사와 파트너 관계로 작업한다고 가정하므로 폼 인증이 사용됩니다. 디렉터리 및 공급자는 지정되지 않습니다.

영역

영역을 디자인할 때는 성공적인 배포를 위해 몇 가지 주요 사항을 결정해야 합니다. 이러한 사항에는 다음 영역에 대한 디자인 및 구성 결정 사항이 포함됩니다.

  • 기본 영역

  • 외부 액세스용 영역

다음 섹션에서는 이 모델에 통합된 결정 사항에 대해 설명합니다.

기본 영역의 구성 요구 사항

가장 주의 깊게 고려해야 하는 영역은 기본 영역입니다. Windows SharePoint Services 3.0에서는 기본 영역을 구성하는 방법에 다음과 같은 요구 사항을 적용합니다.

  • 사용자 요청을 특정 영역에 연결할 수 없는 경우 기본 영역의 인증 및 정책이 사용됩니다. 따라서 기본 영역은 가장 보안이 강화된 영역이어야 합니다.

  • 인덱스 구성 요소는 하나 이상의 영역을 통해 콘텐츠에 액세스하여 콘텐츠를 크롤링할 수 있어야 합니다. 인덱스 구성 요소에는 NTLM 인증이 사용됩니다. 따라서 콘텐츠를 크롤링하려면 최소한 하나 이상의 영역에서 NTLM 인증을 사용하도록 구성해야 합니다. 또한 크롤러는 기본 영역, 인트라넷 영역, 인터넷 영역, 사용자 지정 영역, 익스트라넷 영역의 순서로 영역을 폴링하여 인증 가능한 영역을 찾습니다. 그러나 크롤러에서 처음 발견한 영역이 Kerberos, 기본 또는 다이제스트 인증을 사용하도록 구성되어 있으면 크롤러가 인증되지 않고 다음 영역에 대한 액세스가 시도되지 않습니다. 따라서 인덱스 구성 요소에서 콘텐츠를 크롤링하지 못하는 경우가 발생하지 않도록 영역을 구성해야 합니다. 콘텐츠 크롤링과 관련된 인증 요구 사항에 대한 자세한 내용은 인증 방법 계획(Windows SharePoint Services)을 참조하십시오.

  • 관리 전자 메일은 기본 영역의 링크와 함께 전송됩니다. 여기에는 할당량 제한에 도달한 사이트 소유자에게 보내는 전자 메일 메시지가 포함됩니다. 따라서 이러한 유형의 전자 메일을 받는 사용자는 기본 영역을 통해 링크에 액세스할 수 있어야 합니다. 이는 사이트 소유자에게 특히 중요합니다.

  • 호스트 이름이 지정된 사이트 모음은 기본 영역을 통해서만 사용할 수 있습니다. 호스트 이름이 지정된 사이트 모음에 액세스해야 하는 모든 사용자는 기본 영역을 통한 액세스 권한이 있어야 합니다.

이 모델에서는 다음과 같은 이유로 인해 기본 영역이 원격 직원 액세스용으로 사용됩니다.

  • 직원이 내부에서 사이트에 액세스하는지 원격으로 액세스하는지와 상관없이 관리 전자 메일의 링크에 액세스할 수 있습니다.

  • 사용자 요청에 연결된 영역을 확인할 수 없는 경우 내부 서버 이름과 URL이 노출되지 않습니다. 기본 영역이 이미 원격 직원용으로 구성되어 있으므로 이 영역이 적용될 때 URL에 중요한 데이터가 노출되지 않습니다.

익스트라넷 환경에 대한 영역 구성

익스트라넷 환경에서는 다음 두 가지 이유로 인해 영역 디자인이 중요합니다.

  • 서로 다른 여러 네트워크에서 사용자 요청이 시작될 수 있습니다. 이 모델에서는 사용자 요청이 내부 네트워크, 인터넷 및 파트너 회사에서 시작됩니다.

  • 사용자가 여러 웹 응용 프로그램 간의 공동 작업에 참여할 수 있습니다. 예를 들어 내부 직원과 원격 직원이 팀 사이트, 셀프 서비스 사이트, 파트너 웹 등의 모든 웹 응용 프로그램 간에 콘텐츠를 제공하고 이를 관리할 수 있습니다.

익스트라넷 환경에서는 다음과 같은 디자인 원칙을 따라야 합니다.

  • 여러 웹 응용 프로그램에서 영역을 서로 동일하게 구성합니다. 이때 인증 구성과 대상 사용자가 같아야 합니다. 그러나 영역에 연결된 정책은 웹 응용 프로그램에 따라 다를 수 있습니다. 예를 들어 모든 웹 응용 프로그램에서 인트라넷 영역은 동일한 직원을 위해 사용되어야 합니다. 즉, 인트라넷 영역을 특정 웹 응용 프로그램에서는 내부 직원용으로 구성하고 다른 웹 응용 프로그램에서는 외부 직원용으로 구성하지 않아야 합니다.

  • 각 영역과 각 리소스에 대해 대체 액세스 매핑을 적절하고 정확하게 구성합니다.

이 모델에서는 각 웹 응용 프로그램의 기본 영역이 원격 직원 액세스용으로 동일하게 구성되어 있습니다. 또한 모든 웹 응용 프로그램에서 인트라넷 영역이 내부 직원 액세스용으로 동일하게 구성되어 있습니다. 익스트라넷 영역은 단일 웹 응용 프로그램에 대해서만 구성되어 있습니다.

영역을 만들면 대체 액세스 매핑이 자동으로 만들어집니다. 그러나 프록시 서버 또는 게이트웨이 제품을 사용하여 인터넷에서 사이트를 사용할 수 있도록 하는 경우에는 각 영역에 대해 다른 대체 액세스 매핑 항목을 추가해야 합니다. 이렇게 하면 내부 네트워크에 속하지 않은 사용자에게 반환되는 URL을 사용자가 현재 속한 영역의 컨텍스트에 따라 사용할 수 있습니다. 자세한 내용은 대체 액세스 매핑 계획(Windows SharePoint Services)을 참조하십시오.

웹 응용 프로그램 간에 영역이 서로 다르고 외부 리소스에 대한 링크가 적절하지 않으면 다음과 같은 위험이 따를 수 있습니다.

  • 서버 이름, DNS(Domain Name System) 이름 및 IP 주소가 내부 네트워크의 외부로 노출될 수 있습니다.

  • 사용자가 웹 사이트 및 기타 리소스에 액세스하지 못할 수 있습니다.

관리 사이트

이 모델에서 중앙 관리 사이트는 검색 서버에 호스팅되므로 사용자가 사이트에 직접 액세스할 수 없습니다. 성능 병목 현상이 발생하거나 보안 문제로 인해 프런트 엔드 웹 서버를 사용할 수 없는 경우에도 중앙 관리 사이트를 계속 사용할 수 있습니다. 또한 중앙 관리 사이트는 전용 응용 프로그램 풀과 웹 응용 프로그램 내에서 호스팅됩니다.

관리 사이트에 대한 부하 분산 URL은 모델이나 이 문서에서 설명되어 있지 않으며 다음과 같은 지침을 따르는 것이 좋습니다.

  • 관리 URL에 포트 번호가 사용되는 경우 표준이 아닌 포트를 사용합니다. 포트 번호는 기본적으로 URL에 포함되어 있습니다. 고객 연결 URL에는 일반적으로 포트 번호가 사용되지 않지만 관리 사이트에 포트 번호를 사용하면 이러한 사이트에 대한 액세스가 표준이 아닌 포트로 제한되므로 보안이 강화될 수 있습니다.

  • 관리 사이트에 대한 별도의 DNS 항목을 만듭니다.

응용 프로그램 풀

일반적으로 서로 구분된 IIS(인터넷 정보 서비스) 응용 프로그램 풀을 구현하여 사이트 간에 프로세스를 격리합니다. 응용 프로그램 풀을 통해 같은 서버 컴퓨터에서 여러 사이트를 실행하면서 자체 작업자 프로세스와 ID를 유지할 수 있습니다. 이렇게 하면 공격자가 한 사이트에서 다른 사이트를 공격하는 코드를 서버에 삽입할 수 있는 보안 문제를 완화할 수 있습니다.

다음과 같은 시나리오에서는 전용 응용 프로그램 풀을 사용하는 것이 더 실용적입니다.

  • 인증된 콘텐츠와 익명 콘텐츠를 구분하려는 경우

  • 외부 파트너나 고객과 공동 작업하는 데 주로 사용되는 사이트를 격리하려는 경우. 이렇게 하면 한 응용 프로그램 풀 내에서 사이트에 대한 외부 계정을 격리할 수 있습니다.

  • 사용자가 좀 더 자유롭게 사이트를 만들고 관리하며 콘텐츠에 대해 공동으로 작업할 수 있는 사이트를 격리하려는 경우

이 모델에서는 응용 프로그램 풀을 다음과 같이 사용합니다.

  • 관리 사이트는 전용 응용 프로그램 풀에 호스팅됩니다. 이는 Windows SharePoint Services 3.0의 요구 사항입니다.

  • 내부 공동 작업 사이트(팀 사이트와 셀프 서비스 사이트)는 하나의 응용 프로그램 풀에 호스팅됩니다.

  • 파트너 웹 응용 프로그램은 전용 응용 프로그램 풀에 호스팅됩니다.

웹 응용 프로그램

웹 응용 프로그램은 SharePoint 제품 및 기술에서 만들고 사용하는 IIS 웹 사이트입니다. 각 웹 응용 프로그램은 IIS에서 서로 다른 웹 사이트로 나타납니다. 각 웹 응용 프로그램에는 고유 도메인 이름을 할당하며, 이 이름을 통해 사이트 간 스크립트 공격을 막을 수 있습니다.

일반적으로 전용 웹 응용 프로그램을 사용하여 다음을 수행할 수 있습니다.

  • 익명 콘텐츠와 인증된 콘텐츠 분리.

  • 사용자 격리 이 모델에서는 파트너 웹이 전용 웹 응용 프로그램 및 응용 프로그램 풀에 호스팅되므로 파트너가 내부 공동 작업 콘텐츠에 액세스할 수 없습니다.

  • 사용 권한 적용 전용 웹 응용 프로그램을 통해 중앙 관리의 웹 응용 프로그램 정책 페이지를 사용하여 사용 권한을 적용할 수 있습니다. 예를 들어 내부 공동 작업 사이트에서 파트너 계정에 대해 액세스 권한을 명시적으로 거부하는 정책을 만들 수 있습니다. 웹 응용 프로그램 정책은 웹 응용 프로그램 내에서 개별 사이트나 문서에 대해 구성된 사용 권한에 관계없이 적용됩니다.

  • 성능 최적화 웹 응용 프로그램에 데이터 특성이 비슷한 여러 응용 프로그램을 함께 배치하면 사이트 성능이 향상됩니다. 예를 들어 셀프 서비스 사이트의 데이터 특성에는 크기가 작은 수많은 사이트가 포함되는 반면 팀 사이트에는 일반적으로 적은 수의 대규모 사이트가 포함됩니다. 이렇게 서로 다른 두 가지 유형의 사이트를 별도의 웹 응용 프로그램에 배치하면 결과 데이터베이스가 특징이 서로 비슷한 데이터로 구성되므로 데이터베이스 성능이 향상됩니다. 이 모델에서는 팀 사이트와 셀프 서비스 사이트에 대해 특별히 데이터를 격리할 필요가 없으므로 같은 응용 프로그램 풀이 공유됩니다. 그러나 성능을 최적화하기 위해 팀 사이트와 셀프 서비스 사이트를 별도의 웹 응용 프로그램에 배치합니다.

  • 관리 효율성 최적화 별도의 웹 응용 프로그램을 만들면 별도의 사이트 및 데이터베이스가 만들어지므로 서로 다른 사이트 제한(휴지통, 만료 및 크기)을 구현하고 서비스 수준 계약을 서로 다르게 조정할 수 있습니다. 예를 들어 조직 내에서 셀프 서비스 사이트 콘텐츠가 크게 중요하지 않은 경우 해당 콘텐츠의 복원 시간을 더 길게 설정할 수 있습니다. 이렇게 하면 셀프 서비스 사이트 콘텐츠가 복원되기 전에 더 중요한 콘텐츠가 먼저 복원됩니다. 이 모델에서는 관리자가 다른 응용 프로그램보다 확장을 더욱 적극적으로 관리할 수 있도록 셀프 서비스 사이트를 별도의 웹 응용 프로그램에 배치합니다.

사이트 모음

사이트 모음은 논리 아키텍처와 정보 아키텍처를 서로 연결합니다. 모델에서 사이트 모음의 디자인 목표는 URL 디자인 요구 사항을 충족하고 콘텐츠를 논리적으로 분할하는 것입니다.

URL 디자인 요구 사항을 충족하기 위해 각 웹 응용 프로그램에 단일 루트 수준 사이트 모음이 포함되어 있습니다. 관리 경로는 최상위 사이트 모음의 두 번째 계층을 통합하는 데 사용됩니다. URL 요구 사항 및 관리 경로를 사용하는 방법에 대한 자세한 내용은 이 문서 뒷부분의 "영역 및 URL"을 참조하십시오. 사이트 모음의 두 번째 계층 이후에 있는 모든 사이트는 하위 사이트입니다.

다음 그림에서는 팀 사이트의 사이트 계층 구조를 보여 줍니다.

공동 작업 사이트용 논리적 아키텍처

루트 수준 사이트 모음에 대한 요구 사항이 결정되었으면 사이트 모음의 두 번째 계층을 중심으로 디자인을 결정해야 합니다. 이 모델에는 응용 프로그램의 특징에 따른 선택 내용이 적용되어 있습니다.

셀프 서비스 사이트

이 모델에서는 셀프 서비스 사이트에 URL이 http://sites인 최상위 사이트가 통합됩니다. 와일드카드 포함을 사용하여 관리 경로가 통합되므로 사용자가 만들 수 있는 사이트의 수에 제한이 없습니다. 관리 경로 아래 있는 모든 사이트는 최상위 사이트를 만드는 데 사용된 사이트 서식 파일을 상속하는 독립된 사이트 모음입니다. 다음 그림에서는 셀프 서비스 사이트를 보여 줍니다.

셀프 서비스 사이트에 대한 자세한 내용은 사이트 만들기 프로세스 계획(Windows SharePoint Services)을 참조하십시오.

팀 사이트

팀 사이트 응용 프로그램 내에서 사이트 모음을 디자인할 때는 조직의 운영 방식을 기준으로 조직에 필요한 사이트 모음을 정해진 수만큼만 만드는 것이 좋습니다. 이 방법을 사용할 때는 Windows SharePoint Services 3.0 관리자가 사이트 모음을 만듭니다. 사이트 모음을 만들고 나면 팀에서 필요에 따라 사이트 모음 내에 사이트를 만들 수 있습니다.

이 방법을 사용하면 팀 사이트의 관리 및 확장 방식을 체계화하는 정교한 사이트 구조를 구현할 수 있습니다. 또한 사이트 모음을 공유하는 프로젝트 및 팀 간에 서식 파일 및 탐색을 공유할 수 있습니다. 정보 설계자는 조직에 적합한 방식으로 사이트 모음의 두 번째 계층을 만들어야 합니다. 다음 표에서는 다양한 조직 유형에 대해 권장되는 구조를 보여 줍니다.

조직 유형 권장되는 사이트 모음 구조

제품 개발

  • 개발 중인 각 제품에 대한 사이트 모음을 만듭니다. 참여하는 각 팀에서 사이트 모음 내에 사이트를 만들 수 있도록 허용합니다.

  • 장기 개발 프로젝트의 경우 제품 개발에 참여하는 각 대규모 팀에 대해 사이트 모음을 만듭니다. 예를 들어 디자이너, 엔지니어 및 콘텐츠 개발자 팀에 대해 사이트 모음을 하나씩 만듭니다.

리서치

  • 각 장기 리서치 프로젝트에 대해 사이트 모음을 하나씩 만듭니다.

  • 리서치 프로젝트의 각 범주에 대해 사이트 모음을 하나씩 만듭니다.

고등 교육 기관

  • 학과별로 사이트 모음을 하나씩 만듭니다.

정부 기관

  • 정당별로 사이트 모음을 하나씩 만듭니다. 같은 정당에 속한 공무원들이 서식 파일 및 탐색을 공유할 수 있습니다.

  • 위원회별로 사이트 모음을 하나씩 만들거나 모든 위원회에 대한 단일 사이트 모음을 만듭니다.

기업 법률 사무소

  • 기업 고객별로 사이트 모음을 하나씩 만듭니다.

제조

  • 제품 라인별로 사이트 모음을 하나씩 만듭니다.

파트너 웹

파트너 웹은 범위나 기간이 한정되어 있는 프로젝트에 대해 외부 파트너와 공동으로 작업하는 데 사용됩니다. 파트너 웹 응용 프로그램 내의 각 사이트는 서로 관련되지 않도록 디자인되어 있습니다. 파트너 웹에 대한 요구 사항은 다음과 같습니다.

  • 프로젝트 소유자가 파트너 공동 작업용 사이트를 손쉽게 만들 수 있어야 합니다.

  • 파트너 및 다른 참가자가 자신이 작업하는 프로젝트에만 액세스할 수 있어야 합니다.

  • 사이트 소유자가 사용 권한을 관리해야 합니다.

  • 프로젝트 중 하나에서 검색한 결과에 다른 프로젝트의 내용이 노출되지 않아야 합니다.

  • 더 이상 사용되지 않는 사이트를 관리자가 손쉽게 식별하여 삭제할 수 있어야 합니다.

이러한 요구 사항을 충족하기 위해 이 모델에는 각 프로젝트에 대한 사이트 모음이 하나씩 포함되어 있습니다. 이렇게 하면 다음과 같은 장점이 있습니다.

  • 개별 사이트 모음에서 프로젝트 사이에 적절한 격리 수준을 제공합니다.

  • 셀프 서비스 사이트 만들기를 구현할 수 있습니다.

콘텐츠 데이터베이스

다음과 같은 두 가지 방법을 사용하여 콘텐츠 데이터베이스를 디자인에 통합할 수 있습니다. 이 모델에서는 두 가지 방법을 모두 사용합니다.

  • 적절한 크기 경고 임계값을 사용하여 콘텐츠 데이터베이스의 대상 크기를 설정합니다. 크기 경고 임계값에 도달하면 새 데이터베이스를 만듭니다. 이 방법을 사용하면 대상 크기만을 기준으로, 사용 가능한 하나 이상의 데이터베이스에 사이트 모음이 자동으로 추가됩니다.

  • 사이트 모음을 특정 콘텐츠 데이터베이스에 연결합니다. 이 방법을 사용하면 다른 데이터베이스와 독립적으로 관리할 수 있는 전용 데이터베이스에 하나 이상의 사이트 모음을 배치할 수 있습니다.

사이트 모음을 특정 콘텐츠 데이터베이스에 연결하려는 경우 다음과 같은 방법을 사용할 수 있습니다.

  • Stsadm 명령줄 도구를 사용하여 특정 데이터베이스에 사이트 모음을 만듭니다.

  • 다음과 같은 데이터베이스 용량 설정을 적용하여 데이터베이스를 단일 사이트 모음에만 할당합니다.

    • 경고 이벤트가 발생되기 전의 사이트 수 = 1

    • 이 데이터베이스에서 만들 수 있는 최대 사이트 개수 = 1

  • 다음 단계를 수행하여 전용 데이터베이스에 사이트 모음 그룹을 추가합니다.

    1. 웹 응용 프로그램 내에서 데이터베이스를 만들고 데이터베이스 상태를 준비로 설정합니다.

    2. 다른 모든 데이터베이스의 상태를 오프라인으로 설정합니다. 콘텐츠 데이터베이스가 오프라인 상태이면 새 사이트 모음을 만들 수 없지만, 오프라인 데이터베이스의 기존 사이트 모음에는 계속 액세스하여 읽기 및 쓰기 작업을 수행할 수 있습니다.

    3. 사이트 모음을 만듭니다. 사이트 모음이 데이터베이스에 자동으로 추가됩니다.

    4. 다른 모든 데이터베이스의 상태를 다시 준비로 설정합니다.

팀 사이트

이 모델에는 팀 사이트 모음마다 전용 데이터베이스가 하나씩 포함되어 있습니다. 이 방법을 사용하면 각 팀의 데이터베이스에 대한 백업, 복원 및 마이그레이션을 독립적으로 관리할 수 있습니다. 또한 프로젝트가 완료되면 해당 프로젝트와 연결된 데이터베이스를 쉽게 보관할 수 있습니다.

셀프 서비스 사이트

셀프 서비스 사이트의 경우 이 모델에서는 데이터베이스를 최대 대상 크기까지 관리하여 규모의 효율성을 달성합니다. 이 목표를 위해 설정을 다음과 같이 구성합니다.

  • 사이트 저장 제한 용량   이 설정은 중앙 관리의 할당량 지정 서식 파일 페이지에서 구성할 수 있으며 개인 사이트의 크기를 제한합니다.

  • 2단계 휴지통   이 설정은 웹 응용 프로그램 일반 설정 페이지에서 구성할 수 있으며 2단계 휴지통에 할당되는 추가 공간을 결정합니다.

  • 이 데이터베이스에서 만들 수 있는 최대 사이트 개수   이 설정은 데이터베이스를 만들 때 구성됩니다. 위에 있는 두 가지 값에 지정한 숫자를 사용하여 허용되는 총 사이트 크기를 계산합니다. 그런 다음 각 데이터베이스의 크기 목표에 따라 데이터베이스에 포함될 수 있는 사이트 수를 결정합니다.

이 모델에서는 대상 데이터베이스 크기를 100GB로, 내 사이트의 대상 크기를 500MB로 가정하고 다음과 같은 예제 크기 설정을 사용합니다.

  • 사이트당 크기 제한 = 500MB

  • 데이터베이스의 대상 크기 = 100GB

  • 최대 사이트 수 = 200

  • 경고 전 사이트 수 = 175

경고 전 사이트 수에 도달하면 새 데이터베이스를 만들어야 합니다. 새 데이터베이스를 만들면 데이터베이스 중 하나의 최대 사이트 수에 도달할 때까지 새로 만든 셀프 서비스 사이트가 새 데이터베이스와 기존 데이터베이스에 교대로 추가됩니다.

파트너 웹

셀프 서비스 사이트와 마찬가지로 파트너 웹에서는 데이터베이스를 최대 대상 크기까지 관리하여 규모의 효율성을 달성합니다.

파트너 웹은 전용 웹 응용 프로그램에 호스팅되므로 작성된 크기 유형에 보다 적합한 크기 제한을 만들 수 있습니다. 이 모델에서는 다음과 같은 예제 크기 설정을 사용합니다.

  • 데이터베이스의 대상 크기 = 100GB

  • 사이트당 저장소 할당량 = 5GB

  • 최대 사이트 수 = 20

영역 및 URL

이 모델에서는 기업 배포에서 여러 응용 프로그램 간에 URL을 조정하는 방법을 보여 줍니다.

디자인 목표

다음 목표는 URL의 디자인과 관련된 결정에 영향을 줍니다.

  • 콘텐츠에 액세스하는 데 사용할 수 있는 영역이 URL 규칙에 따라 제한되지 않습니다.

  • 모델의 모든 응용 프로그램 사이에서 표준 HTTP 및 HTTPS 포트(80 및 443)를 사용할 수 있습니다.

  • URL에 포트 번호가 포함되지 않습니다. 실제 프로덕션 환경에서는 일반적으로 포트 번호가 사용되지 않습니다.

디자인 원칙

이러한 디자인 목표를 달성하려면 다음과 같은 디자인 원칙을 적용합니다.

  • 호스트 이름이 지정된 사이트 모음을 사용하지 않습니다. 호스트 이름이 지정된 사이트 모음은 IIS 호스트 헤더와 다르며, 대체 액세스 매핑 기능과 호환되지 않습니다. 여러 도메인 URL을 통해 동일한 콘텐츠에 액세스하려면 대체 액세스 매핑 기능이 필요합니다. 따라서 호스트 이름이 지정된 사이트를 사용하면 기본 영역을 통해서만 이러한 사이트를 사용할 수 있습니다. 또한 대체 액세스 매핑 기능은 오프 박스 SSL(Secure Sockets Layer) 종료를 지원하며, 이를 통해 원격 직원 액세스 및 파트너 액세스 시나리오에서 SSL(https)을 사용할 수 있습니다. 호스트 이름이 지정된 사이트 모음을 사용하는 방법에 대한 자세한 내용은 백서: Windows SharePoint Services에서 공유 호스팅 솔루션 만들기를 참조하십시오.

  • 각 응용 프로그램에는 단일 루트 사이트 모음이 포함되며, 이렇게 해야 대체 액세스 매핑을 사용할 수 있습니다. 웹 응용 프로그램 내에 여러 루트 사이트 모음이 필요하며 사용자 액세스용으로 기본 영역만 사용하려는 경우에는 호스트 이름이 지정된 사이트 모음을 사용하는 것이 좋습니다.

  • 각 사이트 모음이 최상위 팀이나 프로젝트를 나타내는 팀 사이트 등 높은 수준의 여러 사이트 모음이 포함된 응용 프로그램의 경우 이 모델에는 관리 경로가 포함되어 있습니다. 관리 경로를 사용하면 다음과 같은 사이트 유형의 URL을 보다 세밀하게 제어할 수 있습니다.

디자인 장단점

디자인 목표를 충족하면 다음을 비롯한 몇 가지 장단점이 있습니다.

  • URL이 길어집니다.

  • 호스트 이름이 지정된 사이트 모음을 사용하지 않습니다.

부하 분산 URL 디자인

웹 응용 프로그램을 만들 때는 응용 프로그램에 할당할 부하 분산 URL을 선택해야 합니다. 또한 웹 응용 프로그램 내에 만드는 각 영역에 대한 부하 분산 URL을 만들어야 합니다. 부하 분산 URL에는 프로토콜, 구성표, 호스트 이름 및 포트(사용되는 경우)가 포함됩니다. 부하 분산 URL은 모든 웹 응용 프로그램 및 영역 사이에서 고유해야 합니다. 따라서 각 응용 프로그램 및 각 응용 프로그램 내의 각 영역에는 모델 전체에서 고유한 URL이 필요합니다.

내부 공동 작업 사이트

서로 다른 두 가지 유형의 내부 공동 작업 사이트에는 각각 고유한 URL이 필요합니다. 이 모델에서 이러한 사이트의 대상 그룹은 내부 직원 및 원격 직원입니다. 다음 표에서는 내부 직원과 원격 직원이 각 응용 프로그램에 액세스하는 데 사용하는 URL을 보여 줍니다.

응용 프로그램 내부 직원 URL 원격 직원 URL

팀 사이트

http://teams

https://teams.fabrikam.com

셀프 서비스 사이트

http://sites

https://sites.fabrikam.com

파트너 웹

이 모델에서는 내부 직원, 원격 직원 및 파트너 직원이 파트너 웹에 액세스합니다. 원격 직원과 파트너 직원이 모두 외부에서 SSL(HTTPS)을 사용하여 파트너 웹에 액세스하지만 별도의 영역을 사용할 때의 장점(서로 다른 인증 방법 및 영역 정책)을 적용하려면 서로 다른 URL이 필요합니다. 다음 표에서는 내부 직원, 원격 직원 및 파트너가 파트너 웹에 액세스하는 데 사용하는 URL을 보여 줍니다.

영역 URL

내부 직원 URL

http://partnerweb

원격 직원 URL

https://remotepartnerweb.fabrikam.com

파트너 URL

https://partnerweb.fabrikam.com

URL 경로에 명시적 포함 및 와일드카드 포함 사용

관리 경로를 정의하면 웹 응용 프로그램의 URL 네임스페이스에서 사이트 모음에 사용되는 경로를 지정할 수 있습니다. 루트 사이트 아래에 있는 별도의 경로에 하나 이상의 사이트 모음이 있도록 지정할 수 있습니다. 관리 경로를 사용하지 않는 경우 루트 사이트 모음 아래에 만드는 모든 사이트가 루트 사이트 모음의 일부가 됩니다.

다음과 같은 두 가지 유형의 관리 경로를 만들 수 있습니다.

  • 명시적 포함   명시적으로 할당된 URL이 적용된 사이트 모음입니다. 명시적 포함은 사이트 모음 하나에만 적용되며 루트 사이트 모음 아래에 명시적 포함을 여러 개 만들 수 있습니다. 이 방법으로 만든 사이트 모음 URL의 예는 http://team/Team1입니다.

  • 와일드카드 포함   URL에 추가되는 경로입니다. 이 경로는 경로 이름 바로 뒤에 지정된 모든 사이트가 고유 사이트 모음임을 나타냅니다. 이 방법은 일반적으로 셀프 사이트 만들기를 지원하는 응용 프로그램에 사용됩니다. 이 방법으로 만든 사이트 모음 URL의 예는 http://sites/site1입니다.

이 모델에서는 다음 섹션의 설명에 따라 두 가지 유형을 모두 사용합니다.

명시적 포함: 팀 사이트

이 모델의 경우 팀 사이트 응용 프로그램에서 모두 명시적 포함을 사용합니다.

팀 사이트

팀 사이트 응용 프로그램 내에서 각 팀 사이트 모음에 대해 명시적 포함이 사용됩니다. 명시적 포함으로 만든 사이트 모음의 규모 제한은 대략 사이트 100개입니다. 최상위 팀 사이트의 개수는 적절한 수준으로 유지하는 것이 좋습니다. 또한 비즈니스 운영 방식에 맞는 논리적인 구조를 팀 사이트에 적용해야 합니다. 대부분의 조직에서는 100개 이하의 사이트를 사용하는 것이 좋습니다. 조직에서 팀 사이트의 규모가 더 커야 하는 경우 와일드카드 포함을 대신 사용하십시오.

이 모델에서는 명시적 포함을 사용하여 다음 표와 같은 URL을 만듭니다.

내부 직원(인트라넷 영역) 원격 직원(기본 영역)

http://team/Team1

https://team.fabrikam.com/Team1

http://team/Team2

https://team.fabrikam.com/Team2

http://team/Team3

https://team.fabrikam.com/Team3

이 예제에서 루트 사이트 모음인 http://team에는 사용자용 콘텐츠가 호스팅되지 않을 수도 있습니다.

와일드카드 포함: 파트너 웹 및 셀프 서비스 사이트

파트너 웹 및 셀프 서비스 사이트에 모두 와일드카드 포함이 사용됩니다. 와일드카드 포함은 사용자가 사이트 모음을 직접 만들 수 있는 응용 프로그램에 적합합니다. 와일드카드 포함은 와일드카드 뒤에 나오는 다음 항목이 사이트 모음의 루트 사이트임을 나타냅니다.

셀프 서비스 사이트

이 모델에서는 셀프 서비스 사이트에 /sites(http://selfservice/sites)라는 와일드카드 포함이 들어 있습니다.

이를 통해 다음 표에 나열된 형식의 URL이 만들어집니다.

내부(인트라넷 영역) 원격 직원(기본 영역)

http://selfservice/sites/site1

https://selfservice.fabrikam.com/sites/site1

http://selfservices/sites/site2

https://selfservice.fabrikam.com/sites/site2

http://selfservice/sites/user3

https://selfservices.fabrikam.com/personal/user3

파트너 웹

파트너 웹은 직원이 외부 파트너와 공동으로 작업할 수 있는 안전한 사이트를 손쉽게 만들 수 있도록 디자인됩니다. 이 목표를 지원하기 위해 셀프 서비스 사이트 만들기가 허용됩니다.

이 모델에서는 파트너 웹에 /sites(http://partnerweb/sites)라는 와일드카드 포함이 들어 있습니다. 이를 통해 다음 표에 나열된 형식의 URL이 만들어집니다.

내부 직원(인트라넷 영역) 원격 직원(기본 영역)

http://partnerweb/sites/project1

https://remotepartnerweb.fabrikam.com/sites/project1

http://partnerweb/sites/project2

https://remotepartnerweb.fabrikam.com/sites/project2

http://partnerweb/sites/project3

https://remotepartnerweb.fabrikam.com/sites/project3

파트너 참가자는 다음 표에 나열된 URL을 사용하여 파트너 웹 사이트에 액세스할 수 있습니다.

파트너(익스트라넷 영역)

https://partnerweb.fabrikam.com/sites/project1

https://partnerweb.fabrikam.com/sites/project2

https://partnerweb/fabrikam.com/sites/project3

영역 정책

웹 응용 프로그램에 대한 정책을 만들어 웹 응용 프로그램 수준에서 사용 권한을 적용할 수 있습니다. 정책을 웹 응용 프로그램에 일반적으로 정의하거나 특정 영역에 대해서만 정의할 수 있습니다. 정책을 사용하면 웹 응용 프로그램이나 영역 내의 모든 콘텐츠에 사용 권한이 적용됩니다. 정책 사용 권한은 사이트 및 콘텐츠에 대해 구성된 다른 모든 보안 설정보다 우선합니다. 사용자 또는 사용자 그룹을 기준으로 정책을 구성할 수 있지만 SharePoint 그룹은 기준으로 사용할 수 없습니다.

이 모델에서는 내부 공동 작업 사이트에 대한 파트너 계정의 액세스를 거부하는 예제 하나를 제공합니다.

공동 작업 사이트 백업 및 복원

공동 작업 사이트에 적합한 콘텐츠 백업 및 복원 방법에는 여러 가지가 있습니다.

  • 기본 제공 백업 및 복구 도구 - 데이터베이스 크기가 100GB 미만이고 사용자 지정 항목이 많지 않거나 사용자 지정 항목을 솔루션으로 패키징한 경우에는 Windows SharePoint Services 3.0과 함께 제공되는 도구를 사용합니다.

  • Microsoft SQL Server 2005 백업 및 복구 도구 - SQL 데이터베이스 관리자가 있으면 이 도구를 사용합니다.

자세한 내용은 백업 및 복구 도구 선택(Windows SharePoint Services)을 참조하십시오.

외부 보안 공동 작업 디자인

디자인 예제 포스터에는 외부 보안 공동 작업을 위한 계획을 세우는 방법에 대한 개요가 포함되어 있습니다. 이 섹션에서는 각 항목에 대해 소개하고 TechNet 라이브러리의 관련 문서에 대한 링크를 제공합니다.

디자인 권장 사항 지침

익스트라넷 토폴로지 선택

경계면 방화벽을 사용하거나 서버 팜을 경계 네트워크에 배치하여 서버 팜을 보호합니다. 자세한 내용은 TechNet의 다음 문서를 참조하십시오.

클라이언트/서버 통신 보호

익스트라넷 환경에서 안전한 공동 작업을 수행하려면 클라이언트 컴퓨터와 서버 팜 환경 간의 통신을 보호해야 합니다. 해당하는 경우에는 SSL(Secure Sockets Layer)을 사용하여 클라이언트 컴퓨터와 서버 간 통신을 보호하십시오.

자세한 내용은 TechNet의 다음 문서를 참조하십시오.

백 엔드 서버 및 중앙 관리 사이트 보호

외부 보안 공동 작업을 수행하려면 인터넷 연결 서버가 필요합니다. 웹 서버와 기타 서버 사이에 방화벽을 배치하고 중앙 관리 사이트를 백 엔드 서버에 호스팅하여 인터넷 트래픽에 대한 노출을 제한할 수 있습니다.

자세한 내용은 TechNet의 다음 문서를 참조하십시오.

대체 액세스 매핑 구성

대체 액세스 매핑은 IIS(인터넷 정보 서비스)를 통해 받은 웹 요청의 URL이 최종 사용자가 입력한 URL과 다른 인터넷 배포 시나리오를 지원합니다. 역방향 프록시 게시 및 부하 분산이 포함된 배포 시나리오에서 이러한 경우가 많습니다. 예를 들어 역방향 프록시는 SSL(HTTPS)을 사용하여 인터넷을 통해 웹 요청을 수신한 다음 HTTP를 사용하여 서버에 요청을 전달하는 등의 고급 기능을 수행할 수 있습니다. 이를 "오프 박스 SSL 종료"라고 합니다.

자세한 내용은 대체 액세스 매핑 계획(Windows SharePoint Services)을 참조하십시오.

이 문서의 다운로드

이 항목은 다운로드 가능한 다음 문서에도 포함되어 있어 더 쉽게 읽고 인쇄할 수 있습니다.

사용 가능한 문서의 전체 목록은 다운로드 가능한 Windows SharePoint Services 관련 문서 (영문)를 참조하십시오.