Inside SharePointSharePoint 보안 계정

Pav Cherny

목차

응용 프로그램 풀과 보안 계정
SharePoint 서버에서 사용자 지정 코드 실행
지킬 박사와 하이드 씨에 대해
보안 계정과 프로세스 격리
구성 데이터베이스의 보안 계정
보안 계정과 자격 증명 키
법칙을 지킬 것

SharePoint 보안 계정을 사용할 때는 전체 SharePoint 환경을 노출할 수 있는 취약한 시스템 구성을 만들게 될 위험이 높습니다. SharePoint 서버 팜을 올바르게 배포하고 보호하는 데 도움을 주기 위해 Microsoft는 지금까지 광범위한 정보와 세부적인 지침을 제공했습니다. 예를 들어 Office SharePoint Server 보안 가이드는 300페이지가 넘는 분량으로 사이트 계획 및 구현, 콘텐츠 계층, 인증 방법, 보안 역할, 관리자 및 서비스 계정을 비롯한 기타 다양한 보안 문제에 대해 설명합니다. Windows SharePoint Services 보안 계정 요구 사항 워크시트도 보안 계정 구성에 대한 필수 정보를 제공합니다. 보안을 중요하게 생각한다면 이 워크시트의 내용을 절대적으로 따라야 합니다.

이렇게 광범위한 설명서를 참고하더라도 보안 계정을 구성하기는 여전히 어려울 수 있습니다. 사실 단일 서버 설치의 기본 설정은 워크시트의 권장 사항에서 벗어나며, WSS(Windows SharePoint Services) 3.0에 포함된 전자 메일 통합 웹 서비스와 같은 특정 구성 요소에는 서버에 대해 상승된 권한이 필요한데, 이는 Microsoft 보안 권장 사항에 어긋날 뿐만 아니라 보안을 위한 최선의 방법 및 일반적인 상식과도 정면으로 배치됩니다. SharePoint 3.0 중앙 관리 도구는 아무런 경고 없이 위험한 보안 계정 구성을 적용하고 MBSA(Microsoft Baseline Security Analyzer)는 이로 인해 발생하는 취약점을 탐지하지 못하므로 SharePoint 서버 팜을 안전하게 보호하고 유지하기는 여전히 어려운 일입니다.

이 칼럼에서는 SharePoint 보안 계정을 자세히 관찰하면서 취약한 구성으로 인해 모든 사이트 모음 및 사이트에 대한 완전한 제어 권한이 공격자에게 넘어가는 과정을 살펴보겠습니다. 이는 다소 민감한 주제입니다. 한편으로는 여러분이 SharePoint 서버 구성을 둘러싼 보안 문제를 인식하도록 돕고자 하는 마음이 있습니다. 결국 SharePoint 환경을 효과적으로 보호하기 위해서는 이 환경의 강점과 약점을 모두 알아야 하기 때문입니다.

반면 필자는 악의를 가진 사람들을 돕고 싶은 생각은 없습니다. 이러한 이유로, 필자는 이 칼럼에서 워크시트나 사용자 지정 도구는 제공하지 않으며, 소스 코드에 대한 설명도 모든 전문 ASP.NET 개발자에게 익숙한 기본적인 주제로 한정할 것입니다. 이 칼럼에서 다루는 소스 코드 조각들은 취약점을 탐지하는 데는 도움이 되지만 이를 악용하려는 경우에는 도움이 되지 않습니다. 프로그래밍 기술이 풍부하지 않더라도 Microsoft Office SharePoint Designer 2007이 있다면 이러한 코드 조각들을 사용하여 사용자 지정 ASP.NET 페이지를 만들 수 있을 것입니다.

Microsoft Office SharePoint Designer 2007 평가판은 온라인으로 받을 수 있습니다. 각자의 기호에 따라 테스트 환경을 구성하고, 할 수 있는 최대한으로 이 환경을 보호한 다음, 확인을 위해 코드 조각들을 실행해 보십시오. 여러분의 SharePoint 사이트가 얼마나 안전한지 한번 살펴보겠습니다.

응용 프로그램 풀과 보안 계정

보안 계정은 SharePoint 요청-처리 모델의 중심에 위치합니다. 이 계정은 SharePoint 웹 응용 프로그램을 실행하는 IIS 작업자 프로세스의 보안 컨텍스트를 정의합니다. SharePoint 웹 응용 프로그램을 만들 때는 응용 프로그램 풀 및 이와 연결된 보안 계정 자격 증명, 그리고 SharePoint 데이터베이스 및 이와 연결된 인증 방법을 지정해야 합니다. Windows 인증을 사용하면(권장) SharePoint는 지정된 보안 계정에 콘텐츠 데이터베이스에 대한 dbOwner 권한을 자동으로 부여하여 SharePoint 웹 응용 프로그램을 실행하는 IIS 작업자 프로세스가 이 데이터베이스에서 호스팅되는 사이트 모음 및 사이트에 액세스할 수 있도록 합니다. 그 외의 다른 인증을 사용하는 경우 명시적인 SQL Server 자격 증명을 제공해야 합니다.

어떤 경우든 SharePoint 사이트 모음 및 사이트는 가상의 구조물로, 실제로는 데이터베이스 레코드에 해당합니다. 콘텐츠 데이터베이스에 직접 SQL Server를 연결하기 위한 계정 이름과 암호를 안다면 SharePoint 수준에서 정의된 사용 권한 및 액세스 제어에 관계없이 해당 데이터베이스의 모든 사이트 모음 및 사이트 데이터에 대한 모든 액세스 권한을 얻을 수 있습니다. 그림 1에 나와 있듯이, 데이터베이스 서버에 대해 직접 연결을 설정하므로 SharePoint에서는 이를 막을 수 없습니다. 따라서 보안 계정은 공격의 주요 표적이 됩니다.

fig01.gif

그림 1 SharePoint 사이트 모음 및 사이트를 우회하여 데이터에 액세스

보안 위험을 완화하기 위해 Microsoft는 인증된 콘텐츠를 갖는 사이트 모음과 익명 콘텐츠를 갖는 사이트 모음에 대해 각각 별도의 응용 프로그램 풀(보안 계정도 함께)을 구성하고, 암호를 저장하는 응용 프로그램, 또는 사용자가 자유롭게 사이트를 만들고 관리하고 콘텐츠에 대한 공동 작업을 수행하는 응용 프로그램은 격리할 것을 권장합니다. 이 구성 조언의 기본적인 개념은 공격자가 하나의 응용 프로그램 풀에 대한 제어 권한을 획득하더라도 이로 인해 SharePoint 팜에 호스팅되는 모든 데이터에 대한 전체 액세스 권한까지 암시적으로 갖게 되지는 않는다는 것입니다. 다른 데이터베이스에 있는 SharePoint 사이트 모음 및 사이트는 여전히 이 공격자로부터 안전합니다. 이와 연결된 웹 응용 프로그램에 대해 별도의 보안 계정을 사용한다는 가정하에 말이지요.

Microsoft는 IIS 6.0에서 응용 프로그램 풀을 기반으로 하는 작업자 프로세스 격리 개념을 처음 도입했는데, 이후로는 IIS에 심각한 보안 취약점이 단 한 개도 발생하지 않았다고 주장합니다. 무척 고무적인 일입니다. 그러니까 SharePoint 팜에서도 응용 프로그램 풀을 활용하도록 하십시오. 단, IIS 웹 사이트와 SharePoint 웹 응용 프로그램은 동의어가 아님을 유념하시기 바랍니다. IIS 웹 사이트는 격리할 수 있지만 SharePoint 웹 응용 프로그램은 서로 격리할 수 없습니다.

진정한 격리란 웹 사이트가 리소스를 공유하지 않을 경우에만 존재합니다. 그러나 SharePoint 웹 응용 프로그램은 항상 공통 리소스(예: 팜의 구성 데이터베이스)를 사용합니다. 그림 2에 나와 있듯이 SharePoint 보안 계정에 대한 제어 권한을 얻는다는 것은 SharePoint 구성 데이터베이스에 액세스할 수 있음을 의미합니다. 보안 계정 보호에 대해 고려하지 않고 SharePoint 팜을 배포했다면, 특히 다양한 내부 또는 외부 고객의 사이트 모음 및 사이트를 공유 환경에서 호스팅하는 중이라면 이러한 액세스 기능에 대해 상당한 불안감을 느낄 것입니다.

그림 2 SharePoint 웹 응용 프로그램, 구성 데이터베이스 및 콘텐츠 데이터베이스 간의 관계

SharePoint 서버에서 사용자 지정 코드 실행

SharePoint는 기본적으로 보안 계정 정보를 노출하지 않습니다. 따라서 세부 정보를 검색하기 위해서는 악성 코드가 필요합니다. 주지하다시피 보안 취약점은 공격자가 악성 코드를 업로드할 수 있도록 하지만 이보다 더 쉽게 침입이 이루어지는 경우도 있습니다.

가장 간단한 경우로, 공격자는 로컬로 또는 터미널 서버를 통해 SharePoint 서버에 로그온하여 %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\TEMPLATE\Layouts 폴더에 악성 코드를 복사할 수 있습니다. SharePoint는 모든 SharePoint 사이트에서 이 폴더를 가상화된 하위 폴더로 포함합니다.

다른 시나리오로는 SharePoint 관리자가 의심스러운 출처에서 가져온 사용자 지정 SharePoint 솔루션을 적절한 테스트 및 코드 확인 없이 배포하여 본인도 모르게 악성 코드를 유입시키는 경우가 있습니다. 마스터 및 콘텐츠 페이지에 포함된 인라인 ASP.NET 코드 역시 요주의 대상입니다. 기본적으로 SharePoint는 서버 측 스크립트를 처리하지 않지만 SharePoint 웹 응용 프로그램의 web.config 파일에 대한 쓰기 액세스 권한이 있는 사람은 누구나 서버 측 스크립트 처리에 대한 규칙을 변경할 수 있습니다. web.config 파일의 <PageParserPaths> 섹션에 PageParserPath 항목을 추가하기만 하면 됩니다. PageParserPath는 정확히 어떻게 동작할까요?

SharePoint를 사용하는 개발자가 여러분에게 전화를 걸어 사용자 지정 ASP.NET 페이지 개발 중에 발생하는 "이 파일에는 코드 블록을 사용할 수 없습니다."라는 오류 메시지에 대해 불평한다고 가정해 봅시다. 여러분은 인터넷을 검색하여 뉴스그룹이나 블로그 사이트에서 다음과 같은 해결책을 발견합니다.

<PageParserPath VirtualPath="/*" CompilationMode="Always" AllowServerSideScript="true" IncludeSubFolders="true" />

여러분이 이 해결책의 보안 경고를 무시할 수도 있고, 보안에 미치는 영향이 해결책에 아예 언급되어 있지 않을 수도 있습니다. 어쨌든 여러분은 web.config 파일에 이 줄을 추가하고, 결과적으로 문제가 해결되었기 때문에 모든 사람이 만족합니다.

그러나 여러분은 의식하지 못하는 사이에 ASP.NET 페이지에서 완전 신뢰 상태로 모든 사용자 지정 코드를 실행하는 길을 열어 준 것이기도 합니다. 이제 공격자가 악성 ASP.NET 페이지를 업로드하면 SharePoint 환경이 위험에 처하게 됩니다. 그림 3에 나와 있듯이 사이트 모음 계층 내에서 공격자가 페이지를 업로드할 권한이 있는 위치가 어디인지는 관계가 없습니다. 결백해 보이는 소규모 팀 사이트가 될 수도 있습니다. 공격은 항상 웹 응용 프로그램에 영향을 미치지만 콘텐츠 데이터베이스와 구성 데이터베이스에 모두 액세스가 가능하므로 전체 서버 팜에 영향을 미칠 수도 있습니다.

Figure 3

그림 3 인라인 ASP.NET 코드를 활성화로 인한 SharePoint 웹 응용 프로그램 손상

지킬 박사와 하이드 씨에 대해

그렇다면 공격자는 보안 계정 자격 증명을 명시적으로 알지 못하고도 콘텐츠 및 구성 데이터베이스에 대한 액세스 권한을 어떻게 얻을까요? 사실 단순합니다. SharePoint 웹 응용 프로그램을 실행하는 IIS 작업자 프로세스는 SharePoint 사용자를 가장하고, 이를 통해 얻는 스레드 토큰을 액세스 확인에 사용합니다. 예를 들어 지킬 박사는 자신의 보안 토큰에 액세스가 허용된 모든 SharePoint 리소스에 액세스할 수 있습니다. 그러나 SharePoint 웹 응용 프로그램에는 IIS 작업자 프로세스의 프로세스 토큰도 있습니다. 이는 SharePoint 보안 계정의 보안 토큰입니다.

그림 44a에 나와 있듯이 정적 WindowsIdentity.Impersonate 메서드를 호출하고 제로 포인터를 전달하여 가장을 원래 모습으로 되돌리면 바로 하이드 씨가 나타납니다. 지킬 박사에게는 데이터베이스에 대한 직접 액세스 권한이 없지만 하이드 씨에게는 있습니다. SQL Server 연결과 T-SQL 쿼리를 막을 것은 아무것도 없습니다.

fig4a_screen.gif

그림 4 SharePoint 웹 응용 프로그램에는 두 개의 보안 컨텍스트가 있음 (더 크게 보려면 이미지를 클릭하십시오.)

그림 4a 두 개의 SharePoint 웹 응용 프로그램 보안 컨텍스트를 검색하기 위한 코드

private string GetMrHyde()
{
    string retVal = string.Empty;
    retVal = "Dr Jekyll is: " + WindowsIdentity.GetCurrent().Name + "<br>";

    WindowsImpersonationContext impCtx = WindowsIdentity.Impersonate(IntPtr.Zero);

    retVal += "Mr Hyde is: " + WindowsIdentity.GetCurrent().Name + "<br>";

    impCtx.Undo();
    return retVal;
}

보안 계정과 프로세스 격리

응용 프로그램 풀과 보안 계정은 확인되지 않은 코드를 실행하도록 구성된 웹 응용 프로그램에 있는 사이트 모음과 사이트를 보호하는 데는 도움이 되지 않습니다. 이 둘의 목적은 프로세스 격리를 통해 한 사이트(공격자가 다른 사이트를 공격하기 위해 서버로 코드를 주입하도록 허용하는 사이트)에서 공격의 영향을 완화하는 것입니다. 프로세스 격리를 사용하면 이러한 목적을 달성할 수 있지만 이를 위해서는 응용 프로그램 풀에서 다른 보안 계정으로 실행되는 별도의 웹 응용 프로그램에 다른 사이트를 배치해야 합니다.

계정 자격 증명을 충분히 보호하지 않으면 구성 작업은 헛된 노력에 불과합니다. 이렇게 민감한 보안 자격 증명을 악당의 손에 바로 넘겨주는 손쉬운 방법은 응용 프로그램 풀 계정에 IIS 메타베이스(전자 메일 통합 웹 서비스의 일부인 디렉터리 관리 서비스를 실행하는 데 필요함)에 대한 액세스 권한을 부여하는 것입니다. 응용 프로그램 풀 계정에 메타베이스 액세스 권한이 있는 경우 공격자는 그림 55a에 나와 있듯이 가장을 되돌린 후 모든 게정과 암호를 일반 텍스트로 검색할 수 있습니다. 이제 공격자는 이러한 보안 계정 중 하나로 악성 코드를 실행하고 모든 콘텐츠 데이터베이스에 대한 SQL Server 연결을 설정하여 프로세스 격리를 우회할 수 있으므로 전체 서버 팜이 손실됩니다.

fig5a_screen.gif

그림 5 IIS 메타베이스에서 보안 계정 정보 검색

그림 5a IIS 메타베이스에서 보안 계정 정보를 검색하기 위한 코드

private string GetMetabaseAppPoolIDs()
{
        WindowsImpersonationContext impCtx = WindowsIdentity.Impersonate(IntPtr.Zero);
        string retVal = string.Empty;
        try
        {
            string metabasePath = "IIS://localhost/w3svc/AppPools";
            DirectoryEntry appPools = new DirectoryEntry(metabasePath);
            foreach (DirectoryEntry appPool in appPools.Children)
            {
            switch (int.Parse(appPool.Properties["AppPoolIdentityType"].Value.ToString()))
            {
                case 0: // Local System
                    retVal += "<br>" + appPool.Name
                        + " (Local System)";
                    break;
                case 1: // Local Service
                    retVal += "<br>" + appPool.Name
                        + " (Local Service)";
                    break;
                case 2: // Network Service
                     retVal += "<br>" + appPool.Name
                        + " (Network Service)";
                     break;
                case 3: // Custom 
                    retVal += "<br>" + appPool.Name
                        + " (" + appPool.Properties["WAMUserName"].Value
                        + " [Pwd: " + appPool.Properties["WAMUserPass"].Value
                        + "])";
                    break;
               }
            }
         }
        catch (Exception ee)
         {
        retVal = "Metabase " + ee.Message;
         }

        impCtx.Undo();
}

메타베이스 액세스가 필요 없는 디렉터리 관리 서비스 솔루션에 관심이 있다면 필자의 2008년 9월 칼럼 "SharePoint 디렉터리 통합"을 참조하십시오.

구성 데이터베이스의 보안 계정

응용 프로그램 풀 계정에 관리 권한을 부여하지 않고, SharePoint 서버의 IIS 메타베이스에 대한 읽기 액세스 권한조차 부여하지 않는다는 규칙을 따른다면 그림 5의 코드를 실행해도 액세스 거부 메시지만 나타나게 됩니다. 그러나 보안 계정 정보는 구성 데이터베이스에서도 사용할 수 있고, 하이드 씨는 앞서 설명한 바와 같이 이 데이터베이스에 액세스할 수 있습니다.

여러분은 SharePoint 보안 계정의 구성 데이터베이스에 대한 액세스도, 해당 SQL Server 연결 문자열이 저장된 레지스트리에 대한 액세스도 거부할 수 없습니다. SQL Server 2005 Express를 사용하는 경우에는 연결 문자열이 바로 동작하지 않을 수 있지만 현재 SharePoint 사이트 모음(SPContext.Current.Site.ContentDatabase.DatabaseConnectionString)과 로컬 팜의 이름에 해당하는 구성 데이터베이스의 이름(SPFarm.Local.Name)에서 정확한 데이터 원본 정보를 유추할 수 있습니다.

불행히도 이렇게 작은 장애물로는 공격을 막지 못합니다. SQL Server를 사용하든 SQL Server Express를 사용하든 관계없이 하이드 씨는 그림 66a에 표시되는 정보를 검색할 수 있습니다. 그래도 암호는 암호화되어 있으므로 공격이 아직 완전히 성공한 것은 아닙니다.

fig6a_screen.gif

그림 6 구성 메타베이스에서 보안 계정 정보 가져오기

그림 6a 구성 메타베이스에서 보안 계정 정보를 검색하기 위한 코드

private string EnumAppPoolAccounts()
{
    string retVal = string.Empty;
    try
    {
       WindowsImpersonationContext impCtx = WindowsIdentity.Impersonate(IntPtr.Zero);

       string regConfigDB = @"SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\Secure\ConfigDB";
       RegistryKey keyConfigDB = Registry.LocalMachine.OpenSubKey(regConfigDB);

       string ConfigDB = (string)keyConfigDB.GetValue("dsn");

       SqlConnection sqlConn = new SqlConnection(ConfigDB);
       sqlConn.Open();

       SqlCommand sqlCmd = new SqlCommand("SELECT Name, Properties FROM Objects"
          + " WHERE ClassId = 'B8369089-08AD-4978-B1CB-C597B5E90F64'", sqlConn);
       sqlCmd.CommandType = System.Data.CommandType.Text;
       SqlDataReader sqlReader = sqlCmd.ExecuteReader();

          while (sqlReader.Read())
          {
             retVal += "<br>" + sqlReader.GetString(0);
             string appPoolXML = sqlReader.GetString(1);
             if (!string.IsNullOrEmpty(appPoolXML))
             {

                 XmlDocument xmlDoc = new XmlDocument();
                 xmlDoc.LoadXml(appPoolXML);

                 XmlElement root = xmlDoc.DocumentElement;
                 XmlNode ndType = root.SelectSingleNode("/object/fld[@name=                   'm_IdentityType']");
                 if (ndType != null && ndType.InnerText.ToLower() != "specificuser")
                 {
                     retVal += " (" + ndType.InnerText + ")";
                 }
                 else
                 {
                     retVal += " (" 
                         + root.SelectSingleNode("/object/sFld[@name='m_Username']").InnerText
                         + " [Pwd: " 
                         + root.SelectSingleNode("/object/fld[@name='m_Password']").InnerText
                         + "])";
                 }
             }
          }
          sqlReader.Close();
          sqlConn.Close();
          impCtx.Undo();
    }
    catch (Exception ee)
    {
          retVal = ee.Message;
    }
    return retVal;
}

그러나 암호를 해독하지 않더라도 동일한 보안 계정을 사용하는 응용 프로그램 풀은 이미 인식할 수 있습니다. 예를 들어 그림 6에서 SharePoint Central Administration v3과 SharePoint—80 응용 프로그램 풀은 네트워크 서비스 계정을 사용하는데, 만일 SharePoint—80이 손상된 웹 응용 프로그램이라면 SharePoint Central Administration v3도 손상됩니다. 이에 해당하는 보안 계정은 중앙 관리 계정이며, 이 계정은 SharePoint 서버에 대한 상승된 권한을 가집니다.

이러한 구성은 표준 웹 응용 프로그램 풀에 사용하면 안 되지만 SharePoint 제품 및 기술 구성 마법사는 단일 서버 설치에서 기본적으로 이 구성을 적용합니다. 따라서 SharePoint 환경에서 보안 계정 구성을 검토하고 필요한 경우 변경하는 것이 매우 중요합니다. 이 주제에 대한 자세한 내용은 Microsoft 기술 자료 문서 "SharePoint Server 2007과 SharePoint Services 3.0에서 서비스 계정 및 서비스 계정 암호를 변경하는 방법"에서 볼 수 있습니다.

보안 계정과 자격 증명 키

그렇다면 중앙 관리 계정에서 중요한 점은 무엇일까요? 가장 중요한 것은 표준 응용 프로그램 풀 계정과 달리 중앙 관리 계정은 보안 계정 암호를 암호화하기 위한 자격 증명 키가 저장된 레지스트리 위치에 액세스할 수 있다는 점입니다.

그림 7은 이 매개 변수와 기본 보안 설정을 보여 줍니다. 여기에서 볼 수 있듯이 로컬 관리자인 WSS_RESTRICTED_WPG 그룹(중앙 관리 계정이 포함됨)과 SYSTEM 계정은 이 키에 액세스할 수 있습니다. 이는 SharePoint 웹 응용 프로그램은 로컬 관리자 권한이 있는 계정, 중앙 관리 계정, 또는 SYSTEM 계정을 사용하면 안 된다는 것을 시사합니다. SharePoint 웹 응용 프로그램은 자격 증명 키에 액세스할 수 없어야 합니다.

fig07a.gif

그림 7 FarmAdmin 레지스트리 키 액세스를 위한 권한 할당

그러나 이렇게 한다고 해도 숙련된 공격자라면 SYSTEM 토큰 하이재킹, 암호 크래킹을 통해, 또는 마스터 페이지나 콘텐츠 페이지에 악성 코드를 배치하여 보호되지 않는 위치로 자격 증명을 내보낸 다음 로컬 관리자 권한을 가진 사용자가 이 사이트에 액세스하기를 기다리는 방법으로 CredentialKey 또는 보안 계정 암호를 알아낼 수 있습니다. 즉, 확인되지 않은 코드는 서버에 위치하지 못하도록 하는 것이 중요합니다.

SharePoint 리소스

bluebullet.gif SharePoint 제품 및 기술 웹 사이트

bluebullet.gif Windows SharePoint Services TechCenter

bluebullet.gif Windows SharePoint Services 개발자 센터

bluebullet.gif Microsoft SharePoint 제품 및 기술 팀 블로그

SYSTEM 토큰 하이재킹에 대해서는 조금 더 세부적인 설명이 필요합니다. 네트워크 서비스와 같은 기본 제공 시스템 계정을 SharePoint 웹 응용 프로그램에 사용하지 않으면 이러한 형식의 공격을 방지할 수 있기 때문입니다. 사실 Argeniss의 설립자이자 CEO인 Cesar Cerrudo는 이 취약점을 발견하고 아랍에미리트 두바이에서 열린 HITBSecConf2008 Deep Knowledge Security Conference에서 이 취약점의 악용을 시연했습니다. Cesar는 네트워크 서비스 계정으로 실행되는 ASP.NET 웹 응용 프로그램이 RPC(원격 프로시저 호출) 서비스로 DLL을 주입한 후, SYSTEM 권한 수준으로 실행되는 RPC 서비스에서 스레드의 보안 토큰을 하이재킹하는 방법을 보여 주었습니다.

그런 다음 공격자는 하이재킹된 SYSTEM 보안 토큰을 WindowsIdentity.Impersonate 메서드로 전달하기만 하면 CredentialKey 레지스트리 매개 변수 및 기타 보호되는 리소스에 대한 액세스 권한을 얻을 수 있습니다. Microsoft에서도 이 취약점을 확인했으므로 SharePoint 웹 응용 프로그램에 네트워크 서비스 계정을 사용하지 말아야 합니다.

법칙을 지킬 것

10가지 불변의 보안 법칙은 Microsoft 보안 대응 센터가 오래 전에 게시한 문서이지만 그 내용은 지금도 여전히 유효합니다. Jesper M. Johansson은 최근 3부로 구성된 "10가지 불변의 보안 법칙 돌아보기"를 작성했습니다. SharePoint 서버 팜을 설계할 때는 이러한 법칙을 유념해야 하며, 안정적인 보안 계정 구성을 적용하기 위한 SharePoint 보안 지침 및 워크시트의 내용도 따라야 합니다.

요약하자면 강력한 암호를 사용하고, 보안 계정에 SharePoint에 대한 상승된 권한을 부여하지 말고, 암호를 자주 변경하고(팜 자격 증명 포함), 절대적 컴퓨터 보안이 없는 것과 마찬가지로 공통 리소스를 사용하는 SharePoint 웹 응용 프로그램 간에 절대적 격리는 없다는 사실을 유념해야 합니다. 이와 더불어 서버 코드 처리 규칙을 변경하지 말고, 확인되지 않은 어셈블리는 서버에 접근하지 못하도록 하고, 보안 계정 구성에서 Windows SharePoint Services 보안 계정 요구 사항 워크시트의 내용을 따른다면 여러분의 SharePoint 환경은 꽤 안전하다고 생각할 수 있을 것입니다.

한편 여러분의 조직에서 사이트 콘텐츠의 엄격한 분리를 요구한다면 해당되는 사이트 모음을 별도의 서버 팜, 가능하다면 별도의 Active Directory 포리스트와 SQL Server 환경에 호스팅하는 것이 좋습니다.

Pav Cherny는 공동 작업 및 통합 커뮤니케이션을 위한 Microsoft 기술을 전문으로 하는 IT 전문가이자 저술가입니다. IT 운영과 시스템 관리를 주로 다루는 백서, 제품 설명서 및 서적 등을 출간한 Pav는 문서 관리 및 지역화 서비스를 전문으로 하는 Biblioso Corporation의 사장입니다.