본문 바로가기

Golden City of El Dorado


기술 잡지

보안을 강화하는 SharePoint의 7가지 새로운 기능

Microsoft Office SharePoint Server(MOSS) 2007 환경에 효과적인 보안 기능을 구현하면 관리 부담을 현저하게 줄일 수 있을 뿐만 아니라

팀이 안전한 환경에서 공동 작업을 수행하고 비즈니스 데이터를 공유할 수 있습니다. MOSS 2007이 기본적으로 제공하는 혁신적인 인증 기능을 사용하면 사용자 지정 인증 공급자를 통한 웹 기반의 보안 표준, 인터넷 스타일의 폼 기반 인증 및 웹 SSO(Single Sign-On)를 구현할 수 있습니다. 더 나아가 MOSS는 2007 Microsoft® Office system 파일과 같은 비즈니스 자산에 대한 세부적인 권한 관리 및 네이티브 암호화 기능을 제공하고 클라이언트 인증 의무를 완화합니다.

다음은 신속하게 적용할 수 있는 MOSS 2007의 7가지 보안 기능입니다.

1. 플러그형 인증 공급자 인증 공급자는 사용자 자격 증명을 확인하는 데 사용할 수 있는 구성 요소입니다. 인터넷 스타일의 SharePoint® 인증을 설정하는 경우 MOSS 환경에 사용할 인증 공급자를 구성하는 작업은 보안상 매우 중요한 결정 사항입니다. MOSS는 실제 Windows ID로 사용자를 확인하는 통합 인증 및 기본 인증을 비롯하여 이전 버전의 SharePoint에서 사용할 수 있는 Windows® 기반 인증 방식을 계속해서 지원하며, 이번 버전에는 다이제스트 인증이 추가되었습니다. 그러나 이제는 Windows ID 확인 외에 선택의 폭이 넓어졌습니다. 또한 필요한 경우 인증 공급자를 여러 개 적용하여 내부 사용자는 Windows 인증을 사용하여 로그인하고 외부 사용자는 별도의 플러그형 공급자를 사용하여 로그인하도록 구성할 수도 있습니다.

MOSS는 ASP.NET 2.0을 기반으로 구축되어 플러그형 인증 공급자도 지원하기 때문에 구성원 데이터 저장소에 해당하는 ASP.NET 2.0 그룹 등록 공급자와 역할 공급자(선택 사항)가 있으면 구성 가능한 디렉터리에 사용자 정보를 저장할 수 있습니다. machine.config 파일에서 그룹 등록 공급자에 해당하는 노드 값에 따라 플러그형 공급자 자격 증명을 해시 또는 암호화하거나 일반 텍스트 형식으로 저장할 수 있습니다. MOSS에서는 LDAP V3 그룹 등록 공급자(기본 제공), SQL Server™ 그룹 등록 공급자, ASP.NET 2.0과 함께 사용할 수 있는 Active Directory® 그룹 등록 공급자 등을 포함하여 다양한 그룹 등록 공급자를 사용할 수 있습니다.

기본 제공되는 그룹 등록 공급자와 역할 공급자 외에 다른 공급자를 구현할 수도 있습니다. 예를 들어 ASP.NET 2.0 그룹 등록 아키텍처를 사용하면 Microsoft Access™ 또는 Oracle 데이터베이스, XML 파일, 기본 텍스트 파일 등의 그룹 등록 저장소를 사용하는 사용자 지정 공급자를 만들 수 있습니다. 사용자 지정 인증 공급자는 ProviderBase 클래스에서 상속되는 ASP.NET MembershipProvider 인터페이스에서 상속됩니다(그림 1 참조).


그림 1 .NET 그룹 등록 클래스 계층 구조

MOSS에서 ASP.NET 2.0 인증을 사용할 경우에는 Windows 인증과 비교하여 몇 가지 차이점을 고려해야 합니다. 대부분의 사용자가 느끼는 가장 큰 차이점은 Microsoft Office 클라이언트 상호 운용이 감소한다는 점인데 이는 MOSS와 Office 클라이언트 간의 웹 서비스 통신이 원래 Windows ID에 사용하도록 만들어졌기 때문입니다.

또한 콘텐츠 크롤링 및 인덱싱 관련 서비스를 비롯한 일부 MOSS 서비스는 플러그형 공급자를 사용하는 경우에도 Windows 계정을 사용해야 합니다. Windows ID를 확인하지 않는 인증 형식을 사용하여 이와 같이 하려면 Windows 인증을 사용하는 별도의 MOSS 영역을 만들어야 합니다. 영역에 대해서는 이 문서의 뒷부분에서 설명하겠습니다.

스마트 카드처럼 공개 키나 인증서가 클라이언트에 저장되는 보안 메커니즘을 기반으로 하는 PKI 인프라를 사용할 경우 구현 방식에 따라서는 Windows ID를 확인해야만 제대로 클라이언트 인증서를 허용하고 권한을 부여할 수 있습니다. 이 경우 MOSS 영역을 추가로 만들거나 다른 인증 구성을 사용해야 할 수 있습니다.

2. 폼 기반 인증 및 웹 SSO(Single Sign-On)  MOSS 2007에서 사용할 수 있는 또 다른 인증 메커니즘으로는 ASP.NET 2.0을 기반으로 하는 폼 기반 인증이 있습니다. 이전 버전의 SharePoint에서는 사용자 지정 ISAPI(인터넷 서버 응용 프로그래밍 인터페이스) 확장을 사용하거나 IIS 6.0 도구 키트의 CustomAuth ISAPI 확장을 적용하는 방법으로만 이 인증 메커니즘을 구현할 수 있었습니다. 그러나 이러한 방법으로 구현하더라도 SharePoint에서는 Windows 사용자 ID를 통해 계정을 다시 확인해야 하기 때문에 경계 네트워크에 배포하는 데 제약이 있습니다.

폼 기반 MOSS 인증에서는 플러그형 인증 및 역할 공급자를 사용하여 기존의 NT 로그인 프롬프트 방식에서 벗어나 인터넷 스타일의 보안 메커니즘을 구현할 수 있습니다. 폼 기반 인증을 사용하면 사용자의 필요에 맞게 사용자 지정된 로그인 프로세스를 만들 수 있습니다. 이때 인증 프로세스를 보호하기 위해 암호화되고 변조가 불가능한 폼 인증 쿠키와 인증 티켓이 사용됩니다.

폼 ID 공급자는 로컬 위치에 있을 필요 없이 외부 ID 관리 시스템에 플러그 인할 수 있고, 이 경우 해당 외부 ID 관리 시스템에서 사용자 자격 증명을 확인합니다. 웹 Single Sign-On이라고 하는 이 기능은 HTTP 모듈을 사용하여 외부 인증을 수행합니다. 이러한 시나리오에서는 사용자의 조직과 비즈니스 파트너 간에 ID를 연결하여 해당 사용자가 자신이 속한 조직의 로그인 정보를 통해 MOSS에 로그인할 수 있습니다.

3. MOSS 응용 프로그램 연결 문자열 암호화 중요한 연결 문자열 정보를 web.config 파일에 일반 텍스트로 저장하는 것은 보안상 매우 위험합니다. 이렇게 정보를 노출하면 다른 사용자가 SQL 데이터베이스 서버에 대한 개체 인스턴스를 만들어 중요한 데이터를 조작할 수 있습니다. 그러나 기본 ASP.NET 2.0 기능을 사용하면 두 가지 기술, 즉 Windows DPAPI(데이터 보호 API) 또는 RSA 암호화 중 하나를 사용하여 데이터를 암호화할 수 있습니다. DPAPI는 Windows에 기본 제공되는 암호화 기능을 활용하여 MOSS 서버 시스템 키로 암호화/암호 해독을 실행합니다. RSA 암호화를 사용하면 공개 키 알고리즘을 사용할 수 있지만 암호화 키를 저장할 컨테이너가 필요하므로 추가적인 오버헤드가 발생합니다.

MOSS 2007, 구체적으로 말하자면 플러그형 ASP.NET 2.0 SQL Server 인증 공급자의 경우 가장 심각한 보안 위반이 발생할 가능성이 있는 <connectionStrings> 노드를 암호 텍스트로 암호화하는 것이 좋습니다.

<connectionStrings>
<add name="MembershipConnectionString" 
     connectionString="connectionString"/>
</connectionStrings>

DPAPI 암호화는 사용 방법이 비교적 간단하며 가상 디렉터리나 실제 디렉터리 모두에 대해 네이티브 시스템 키 암호화를 사용하기 때문에 구현하기 가장 쉽습니다. 다른 방법을 사용하여 이 암호화를 프로그래밍 방식으로 구현할 수도 있지만 명령 프롬프트에서 다음 명령을 사용하는 방법이 가장 쉽고 간단합니다.

aspnet_regiis.exe -pe section -app MOSS_virtual_directory -prov provider
 
aspnet_regiis.exe -pef section MOSS_physical_directory -prov provider

이 경우에는 연결 문자열 노드를 암호화해야 하므로 다음과 같이 섹션 매개 변수를 지정하여 특정 섹션을 암호화할 수 있습니다.

aspnet_regiis.exe -pef "connectionStrings" "C:\Inetpub\wwwroot\WssVirtual " -prov "Provider"
 
aspnet_regiis.exe -pe "connectionStrings" -app "/MOSSAppinstance" -prov "Provider"

암호화를 구현하면 다음과 같이 중요한 정보가 포함된 노드가 올바른 형식의 XML 암호 값으로 바뀝니다.

<connectionStrings confiProtectionProvider=
"EncryptionProvider">
<EncryptedData>
<CipherData>
<CipherValue>XXXXXXXXXXXXXXXXXXXXXXXXXXXXX
</CipherValue>
<CipherData>
</EncryptedData>
</connectionStrings>
 

이 모델은 고유한 암호화 공급자를 만들어 적절한 MOSS 구성 파일(web.config 또는 machine.config)의 암호화 텍스트를 관리할 수 있고, RSA나 DPAPI 암호화 외에도 다양한 암호화 방식을 사용할 수 있다는 점에서 전반적인 MOSS 아키텍처와 마찬가지로 플러그형입니다.

그러나 암호화를 사용하는 데는 단점도 있습니다. 로컬 시스템 키를 사용하여 암호화하기 때문에 이 구성 노드를 만든 MOSS 서버에서만 해당 구성 노드를 사용할 수 있고, 그렇지 않으면 암호화 프로세스가 실패합니다. 침입자가 서버에 대한 액세스 권한을 획득한 경우 시스템 키를 찾아 연결 문자열의 암호를 해독할 수 있습니다. 또한 이와 같은 암호 해독 프로세스로 인해 응용 프로그램 성능이 약간 저하될 수 있습니다.

4. 대체 액세스 매핑 및 영역   AAM(대체 액세스 매핑)은 SharePoint 환경에 진입점을 둘 이상 설정하는 경우에 특히 중요합니다. AAM을 사용하면 하나의 실제 사이트에 액세스하는 데 사용되는 다양한 URL을 지정할 수 있습니다(그림 2 참조). AAM은 서로 다른 인증 공급자와 웹 응용 프로그램 보안 정책을 통해 사용자를 MOSS 사이트의 동일한 실제 경로에 연결할 수 있습니다. AAM은 서로 다른 도메인, 역방향 프록시 및 기타 URL 리디렉션 메커니즘 사용을 보완합니다. MOSS에서 사용하는 URL은 기본적으로 자동 매핑되지만, 다른 진입 방식을 처리하기 위해 SharePoint 설계자가 명시적으로 만든 추가 URL을 사용하도록 이 기본 URL을 확장할 수 있습니다. AAM은 올바른 내부 URL 및 공용 URL 매핑이 제대로 작동하도록 하는 데 필요합니다.


그림 2 URL 매핑 및 영역 (Click the image for a smaller view)


그림 2 URL 매핑 및 영역 (Click the image for a larger view)

영역은 MOSS에 추가된 새로운 기능으로, AAM에서 제공하는 사이트 매핑을 보다 강력하게 제어할 수 있도록 도와줍니다. 영역을 사용하면 사용자가 콘텐츠에 연결하는 데 사용하는 AAM URL 매핑에 따라 서로 다른 인증 공급자를 동일한 실제 경로와 MOSS 콘텐츠에 매핑할 수 있습니다. AAM URL 매핑을 지정할 때는 가급적 영역을 인증 메커니즘에 바인딩하는 것이 좋습니다. 인증 공급자 페이지에 정의되어 있지 않은 영역에 AAM URL을 매핑하면 기본 영역의 보안 설정이 사용됩니다.

영역은 여러 URL 진입점의 포털에서 사용자가 인증되고 라우팅되는 방법에 상당한 영향을 주기 때문에 미리 계획하는 것이 좋습니다. 새 웹 응용 프로그램을 확장하는 경우 이 설정의 "부하 분산 URL" 구역 아래에서 사용할 영역을 지정할 수 있습니다(그림 3 참조). 기본 영역에서 지정하는 URL은 현재 영역을 제대로 확인할 수 없는 경우에 사용되므로 여기에는 가장 쉽게 액세스할 수 있는 URL(예를 들어 인터넷에 공개할 URL)을 입력하는 것이 좋습니다.


그림 3 MOSS 영역 구성 (Click the image for a smaller view)


그림 3 MOSS 영역 구성 (Click the image for a larger view)

각 영역에서는 해당 영역의 사용자에 대한 권한 설정을 정의하는 글로벌 웹 응용 프로그램 보안 정책을 바인딩할 수 있습니다. 이렇게 하면 대규모의 사용 권한 수정 작업을 한 곳에서 관리할 수 있습니다. 일반적으로 웹 응용 프로그램은 다양한 사이트 모음에 여러 개의 사이트를 포함하는데 응용 프로그램의 규모가 커지고 복잡하게 될수록 이러한 사이트의 사용 권한을 관리하는 것이 어려워질 수 있습니다. MOSS 2007에서는 모든 권한, 모든 읽기 권한, 쓰기 권한 거부 또는 모든 권한 거부와 같은 정책 설정을 응용 프로그램 내의 특정 사용자나 그룹에 바인딩하는 글로벌 보안 정책을 사용할 수 있습니다. 이러한 정책은 MOSS에서 제공하고 SharePoint 중앙 관리 인터페이스에서 관리하는 세부적인 권한 설정보다 우선 적용되므로 구성을 신중하게 계획해야 합니다.

종합적으로 볼 때 외부와 접한 사이트의 AAM 설정에는 회사 사용자가 액세스하는 데 사용하는 URL 하나와 외부 사용자가 액세스하는 데 사용하는 URL 하나씩 총 두 개의 URL을 정의할 수 있습니다. 각 URL에는 contoso.com(내부 사용자용) 및 extranet.contoso.com(신뢰할 수 있는 외부 파트너용)과 같이 고유한 URL을 사용할 수 있습니다. 이 두 URL은 동일한 콘텐츠에 매핑되지만, 각 URL은 고유한 인증 공급자와 응용 프로그램 보안 정책이 있는 개별 영역을 통해 사이트에 액세스할 수 있습니다. 내부 URL의 인트라넷 영역을 구성하면 내부 사용자가 자신의 도메인 인증된 Windows ID를 사용하여 로그인할 수 있고, 외부 파트너는 엑스트라넷 영역을 통해 웹 Single Sign-On 인증을 사용함으로써 자신이 속한 조직의 사용자 자격 증명으로 로그인할 수 있습니다. 웹 응용 프로그램 보안 정책을 영역에 바인딩하는 기능을 잘 활용하면 개체별로 액세스 권한을 직접 설정하지 않고도 신뢰할 수 있는 모든 외부 사용자에게 모든 읽기 액세스 권한을 부여할 수 있습니다.

5. 안전한 공동 작업을 위한 대상 콘텐츠  SharePoint 사이트 모음을 잠그면 사용자는 자신에게 액세스 권한이 부여된 정보만 처리할 수 있습니다. 유연하게 활용할 수 있는 새로운 권한 메커니즘을 사용하면 MOO 환경에 저장된 다양한 유형의 비즈니스 정보를 더욱 강력하게 제어할 수 있습니다.

MOSS 2007에서는 사이트 모음, 개별 사이트, 문서 라이브러리, 하위 폴더, 목록 또는 개별 문서나 목록 항목과 같은 특정 개체에 ID를 바인딩할 수 있습니다. 이렇게 하면 항목에 대해 세부적인 액세스 권한과 명시적인 그룹 등록이 적용되어 해당 항목에 대한 액세스를 거부하고 사용자에게 액세스 권한이 부여되지 않은 항목은 표시되지 않도록 사용자 인터페이스를 조정할 수 있습니다. MOSS에서는 이 기능을 ILS(항목 수준 보안) 또는 SO(보안 개체)라고 합니다. MOSS 개체 사용 권한은 기본적으로 계층적 구조이기 때문에 목록 항목과 같은 개별 개체에서 목록 또는 문서 라이브러리 등 규모가 더 큰 항목에 이르기까지 권한을 확장할 수 있습니다. 또한 권한 상속을 구현하여 하위 수준에 있는 자식 개체에 상위 수준에 있는 부모 개체의 권한을 선택적으로 상속할 수 있습니다. 33개의 고유한 기본 사용 권한 중에서 선택하여 사용자 또는 SharePoint 그룹에 지정할 수 있으며 각 권한은 개체에 바인딩될 수 있습니다. 필요한 경우에는 새 권한 수준을 만들 수도 있습니다.

예를 들어 프로젝트 관리 사이트에서 중요한 개발 자료(예: Microsoft Word 문서로 작성하여 문서 라이브러리에 저장한 디자인 사양 및 코딩 기술)에는 개발자와 프로젝트 관리자만 액세스할 수 있도록 설정할 수 있습니다. 라이브러리에 대한 권한은 기본적으로 사이트 권한에서 상속되지만 개발자와 프로젝트 관리자에게만 액세스 권한을 부여하거나 각 Word 문서를 특정 프로젝트 관리자와 개발 팀에서만 보고 액세스할 수 있도록 권한을 수정할 수 있습니다. 이와는 반대로 중요하지 않은 자료는 항목, 폴더 또는 문서 라이브러리 수준에서 모두 공개할 수 있습니다.

이벤트 항목(예: 이벤트 목록의 프로젝트 기한)에 대해 사용 권한을 지정하여 특정 구성원만 특정 이벤트를 볼 수 있도록 구성할 수도 있습니다. 또한 ILS 기능을 반환되는 검색 결과에도 적용할 수 있으므로 검색을 실행한 사용자의 보안 컨텍스트에 맞는 개체만 반환되도록 할 수 있습니다. 결과적으로 이러한 모든 제어 기능은 개별 사용자 컨텍스트에 맞게 사용자 인터페이스를 조절합니다.

MOSS 2007에서는 사용 권한 관리 아키텍처가 대폭 향상되어 SharePoint 그룹과 도메인 그룹뿐만 아니라 개별 사용자 수준에서 사용 권한을 설정할 수 있습니다. 소유자(모든 권한), 방문자(참가자 권한), 구성원(읽기 권한) 등을 비롯한 몇몇 그룹은 기본적으로 롤아웃됩니다. 개별 사용자나 도메인 그룹을 이러한 기본 그룹에 할당하거나 사이트 모음 수준에서 만들고 관리하면서 다양한 고유 권한 수준을 지정할 수 있는 사용자 지정 그룹에 할당할 수도 있습니다.

역할을 기반으로 그룹을 만들 경우에는 "개발자" 및 "프로젝트 관리자" 그룹을 만든 후 세부적인 사용 권한을 할당할 수 있습니다. 예를 들어 개발자에게는 관련 코딩 문서를 업로드할 수 있는 권한을 부여하고, 프로젝트 관리자에게는 이러한 문서를 평가하고 승인할 수 있도록 읽기 및 승인 권한을 부여할 수 있습니다. 그룹 등록은 사이트 모음 전체에서 일관되게 유지되므로 기존에 만든 그룹을 여러 프로젝트 사이트에 다시 사용할 수 있습니다.

6. 플러그형 Single Sign-On 통합 일반적인 컴퓨팅 환경에서 사용자는 각기 고유한 인증 기준을 사용하는 다양한 타사 응용 프로그램에 액세스할 수 있는데, 이 경우 여러 가지 보안 문제가 발생할 수 있을 뿐만 아니라 관리해야 하는 암호가 너무 많아질 수 있습니다. MOSS SSO 서비스는 연결된 업무용 시스템에 매핑하는 데 필요한 사용자 자격 증명의 암호화된 백 엔드 캐시를 제공함으로써 이와 같은 문제를 줄이는 데 도움을 줍니다. 이 서비스를 사용하면 업무상 중요한 정보를 검색하여 BDC(비즈니스 데이터 카탈로그) 또는 SharePoint DVWP(DataView 웹 파트)와 같은 MOSS 메커니즘을 통해 표시할 수 있습니다.

MOSS SSO 공급자는 앞에서 설명한 다른 응용 프로그램 아키텍처 기능과 마찬가지로 플러그형이므로 MOSS에 기본 제공되는 SSO 공급자(SpsSsoProvider) 이외에 다른 고유한 SSO 공급자를 지정할 수 있습니다. 그러나 MOSS 환경에서는 업무용 시스템별로 SSO 공급자를 한 번에 하나만 등록할 수 있습니다.

7. IRM(정보 권한 관리)  California Senate Bill No. 1386, SOX(Sarbanes-Oxley) Compliance 및 HIPAA(Health Insurance Portability and Accountability Act)와 같은 법규의 제약을 받는 중요한 데이터를 주로 다루는 회사에서는 비즈니스 정보를 오프라인 상태에서 사용할 경우에도 클라이언트 수준에서 정보를 보호하는 것이 매우 중요합니다. 서버 쪽 IRM(정보 권한 관리)은 MOSS 리포지토리에 통합되어 Windows Rights Management(WRM) 프레임워크를 기반으로 하는 공통의 솔루션을 제공합니다. IRM을 사용하면 문서가 저장된 위치나 문서를 열려는 사용자에 관계없이 문서 수준에서 액세스 제한을 적용하여 비즈니스 데이터를 보다 세밀하게 제어할 수 있습니다. 일반적인 IRM 구현 시나리오에서는 적절한 사용 권한이 있는 경우에만 보기 및 인쇄를 허용하는 정도로 데이터 액세스를 제어할 수 있지만 일정한 시간이 경과한 후 사용자 자격 증명 확인을 요구하거나, IRM을 사용하지 않는 자산은 업로드할 수 없도록 제한하거나, 제한 정책을 삭제하는 예약된 만료 태그를 사용하거나, 조직의 글로벌 IRM 사용 권한 정책에 바인딩하는 것처럼 기본적인 IRM 시나리오를 확장하여 더욱 복잡한 시나리오를 구현할 수 있습니다.

IRM 기능은 보호 기능을 통해 제공되는데 MOSS 2007에는 몇 가지 보호 기능이 기본적으로 설치됩니다. 보호 기능은 특정 파일 형식에 대한 암호화 프로세스를 관리하는 응용 프로그램으로, 일반적으로 MOSS 내에서 저장하는 모든 파일에 대해서는 지정된 기본 보호 기능이 있습니다. 예를 들어 Microsoft Office system 파일 및 OpenXML 파일 형식은 기본적으로 지원됩니다. 그러나 보호 기능의 응용 프로그램 아키텍처는 MOSS에서 제공하는 다른 공급자와 마찬가지로 플러그형으로 설계되었기 때문에 다른 파일 형식에 대해 사용자 지정 보호 기능을 구현할 수 있습니다.

IRM을 구현하려면 MOSS 환경의 모든 요구 사항을 충족하는지 여부를 가장 먼저 확인해야 합니다. 즉, 모든 MOSS 프런트 엔드 웹 서버에 WRM Services Client가 설치되어 있어야 하고 MOSS 프런트 엔드 웹 서버에 Microsoft Rights Management Services(RMS)가 연결되어 있어야 합니다. 그런 다음 MOSS에서 SharePoint 중앙 관리를 통해 사용할 수 있도록 RMS 서버를 지정해야 합니다. 이때 Active Direcotry의 기본값을 사용하거나 위치를 직접 지정할 수 있습니다.

IRM은 문서 라이브러리와 같은 SharePoint 데이터 저장소 구조를 직접 사용하여 사용 권한을 관리합니다. 사용자가 IRM이 설정된 문서 라이브러리로 이동하여 문서 다운로드를 시도하면 MOSS는 문서 라이브러리에 대해 구성된 사용 권한을 문서에 바인딩합니다(그림 4 참조). 이렇게 하면 MOSS와 문서 사용 권한이 일대일로 매핑되어 문서와 관련된 SharePoint 역할이 문서 자체의 IRM 사용 권한 수준으로 변환됩니다.


그림 4 문서 라이브러리의 IRM 사용 권한 전환 (Click the image for a smaller view)


그림 4 문서 라이브러리의 IRM 사용 권한 전환 (Click the image for a larger view)

오프라인 상태에서 문서를 보호하기 위해 로컬 위치에서 문서가 암호화되고, 해당 문서를 문서 라이브러리에 다시 업로드할 때까지 이 상태가 유지됩니다. 문서를 업로드하면 전체 텍스트 검색을 위해 SharePoint Gatherer가 해당 문서의 콘텐츠를 인덱싱할 수 있도록 문서가 암호화되지 않은 형태로 유지됩니다. 그러나 암호화되지 않은 형태에서는 어떤 사용자 계정도 문서 콘텐츠에 액세스할 수 없습니다.

MOSS 2007은 추가적인 관리 부담 없이 조직의 보안을 효과적으로 구현하는 데 도움을 주는 다양한 기능을 제공합니다. 뿐만 아니라 이러한 기능은 사용자가 필요한 정보에만 액세스할 수 있도록 세부적으로 사용자 지정할 수 있으므로 매우 다양하게 활용할 수 있습니다. 간단한 예제를 보려면 "SQL Server 인증 공급자" 추가 기사를 참조하십시오.