Partilhar via

SharePoint 2013의 새로운 앱 모델에 필요한 인프라 계획

  • Artigo

최초 문서 게시일: 2012년 9월 4일 화요일

SharePoint 2013에서는 새로운 응용 프로그램 모델(여기서는 완곡하게 "앱 모델" 또는 "클라우드 앱 모델"로 지칭함)이 제공됩니다. 이 모델은 개발 측면에서 완전히 새로운 기회를 제공함과 동시에, 이러한 기회를 지원하기 위해 계획 및 구축해야 하는 인프라 요구 사항도 함께 제시합니다. 개인적으로 생각하는 실제 앱 모델의 세 가지 주요 요소는 다음과 같습니다.

  1. 개발 모델 - 응용 프로그램을 개발하는 방법, 활용할 새로운 기능 등입니다. 기본적으로 개발자가 수행하는 작업입니다.
  2. 보안 모델 - 새롭게 제공되는 이러한 응용 프로그램의 보안 모델에는 다양한 "항목"이 흥미로운 방식으로 조합되어 있습니다. 우선, 응용 프로그램에 대한 권한을 정의하는 방식인 앱 계정이라는 새로운 개념이 도입되었습니다. 또한 사용자에 대해 설명하는 토큰(응용 프로그램의 클레임과 비슷함)을 SharePoint에 제공하는 메커니즘과, 사용 가능한 콘텐츠를 정의하는 OAuth 모델이 있습니다. 보안 모델 및 이러한 토큰을 만들어 제공하는 방법은 응용 프로그램이 SharePoint에서 호스팅되는지 아니면 다른 위치에서 호스팅되는지, 그리고 신뢰 브로커로 ACS(액세스 제어 서비스)를 사용하는지에 따라 크게 달라집니다. 그 외에도 다양한 요소가 있으며 이 블로그 게시물에서 다루지 못하는 내용도 있습니다. 보안 영역에서는 개발자와 IT 전문가가 모두 작업을 수행한다는 점을 마지막으로 언급하고 넘어가겠습니다.
  3. 인프라 - 인프라란 조직 내에서 응용 프로그램이 작동하도록 만드는 토대라 할 수 있으며 서비스 응용 프로그램, 응용 프로그램 도메인, 접두사, DNS, SSL, 웹 응용 프로그램 구성 등을 포함합니다. 인프라와 관련해서는 주로 IT 전문가가 작업을 수행합니다. 이 블로그 게시물에서도 이러한 작업에 대해 중점적으로 설명합니다. 또한 이 게시물에서는 SharePoint 자체에서 호스팅되는 응용 프로그램을 Windows Azure 등의 클라우드나 다른 사이트에서 외부 호스팅되는 응용 프로그램과 비교하여 살펴봅니다. SharePoint에서 호스팅되는 응용 프로그램을 설치하면 해당 응용 프로그램에 대해 새 SPWeb이 만들어집니다. 이러한 방식으로 각 응용 프로그램은 자체 데이터 집합을 가져오며 다른 응용 프로그램의 데이터를 덮어쓸 수 없습니다. 또한 이러한 방식에 맞는 보안 계층이 제공되기 때문에 특정 응용 프로그램에 대한 권한을 소유한 사용자가 현재 사용자의 권한을 사용하는 악성 코드를 통해 팜의 다른 사이트에 있는 데이터에 액세스할 수 없습니다. 이 점은 새로운 앱 모델을 기반으로 하는 응용 프로그램과 관련하여 반드시 기억해야 하는 중요한 기본 원칙입니다. 즉, SharePoint에서 호스팅되는 각 앱에는 SPWeb이 하나씩 포함됩니다.

다음으로 각각의 인프라 구성 요소에 대해 살펴보겠습니다. 먼저 팜에서 앱 관리 및 가입 설정 서비스 응용 프로그램 인스턴스가 만들어져 실행되고 있는지 확인해야 합니다. 앱 관리 서비스는 응용 프로그램, 배포, 라이선스 등을 추적하는 작업에 사용됩니다. 가입 설정 서비스는 다중 테넌트 배포에 사용되는 것과 같은 서비스 응용 프로그램으로, 앱 모델에서 응용 프로그램에 사용되는 고유 URL을 만드는 용도로도 사용됩니다.

그러면 이러한 URL이 작성되는 방법을 살펴볼까요? URL을 만들려면 먼저 중앙 관리에서 앱 구성을 수행합니다. 중앙 관리로 이동하면 앱이라는 새로운 섹션이 있습니다. 앱을 클릭하면 앱 URL 구성 옵션이 표시됩니다. 여기에는 응용 프로그램 URL을 만드는 데 사용되는 두 개의 값, 즉 앱 도메인과 앱 접두사가 있습니다. 앱 도메인은 팜의 모든 응용 프로그램에 사용할 호스트 이름과 같습니다. 이 이름을 계획할 때는 아래의 세 가지 사항을 고려해야 합니다.

  1. 앱 도메인은 팜 전체에서 사용되므로 다른 웹 응용 프로그램의 경우와 동일한 수준으로 계획 및 고려해야 합니다. 
  2. 앱 도메인은 정규화된 도메인 이름이어야 합니다. 이 이름에 대해 NetBIOS 스타일 이름을 사용하는 경우 이름이 확인되지 않습니다. 
  3. 마지막으로, 이 도메인은 웹 응용 프로그램의 하위 도메인이어서는 안 됩니다.

그러면 구체적인 예를 살펴보겠습니다. team.contoso.com, my contoso.com, portal.contoso.com과 같은 웹 응용 프로그램이 있다고 가정하겠습니다. 위의 고려 사항을 적용하자면 앱 도메인에는 "contoso.com"을 사용해서는 안 됩니다. 해당 도메인을 사용하는 경우 앱 끝점을 가리키는 모든 contoso.com에 대해 와일드카드 DNS 항목을 만들어야 하기 때문입니다(여기에 대해서는 뒷부분에서 자세히 설명함). 또한 "apps.contoso.com" 같은 이름도 웹 응용 프로그램(모두 루트가 "contoso.com"임)에 사용하는 도메인의 하위 도메인이므로 사용할 수 없습니다. 그러므로 위의 규칙을 기준으로 하면 "contosoapps.com"과 같은 이름을 선택하는 것이 적절합니다.

앱 접두사 값은 원하는 대로 지정할 수 있습니다. 해당 접두사는 응용 프로그램 URL의 첫부분에 추가됩니다. 여기에 대해서도 뒷부분에서 자세히 설명합니다.

위에서 와일드카드 DNS 항목에 대해 잠시 언급했는데요, 이제 해당 항목에 대해 자세히 설명하겠습니다. 응용 프로그램이 설치되어 SharePoint에서 호스팅되면 https://apps-87e90ada14c175.contosoapps.com/myapp/pages/default.aspx와 같은 URL이 지정됩니다. 이 URL의 요소는 다음과 같이 구분됩니다.

  • "apps" - 위에서 설명했듯이 중앙 관리에서 입력하는 앱 접두사 값입니다.
  • "87e90ada14c175" - 응용 프로그램이 설치된 웹 및 사이트 모음을 기준으로 하는 고유한 값입니다.
  • "contosoapps.com" - 중앙 관리에서 입력하는 앱 도메인입니다.
  • "myapp" - 설치된 응용 프로그램의 이름입니다. URL의 나머지 부분인 pages/default.aspx는 응용 프로그램이 설치된 SPWeb에 포함된 부분입니다.

위의 URL 및 해당 형식을 보면 와일드카드 DNS 항목을 사용해야 하는 이유를 이해하실 수 있을 것입니다. URL의 첫 부분은 설치되는 모든 응용 프로그램 인스턴스마다 다르므로(여러 사이트 모음에 같은 응용 프로그램을 설치하는 경우에도 마찬가지임), 모든 인스턴스마다 DNS를 계속 업데이트해야 한다면 번거로울 것입니다. 따라서 여기서 설명하는 시나리오에 사용되는 DNS의 경우 *.contosoapps.com과 같은 와일드카드 DNS 항목을 사용할 수 있습니다. 다음으로는 해당 URL이 가리키는 IP 주소에 대해 잠시 살펴보겠습니다.

와일드카드 DNS 항목과 관련하여 함께 살펴보아야 하는 요소가 와일드카드 SSL 항목입니다. 한 마디로 요약하자면, 앱을 사용하는 경우 SSL을 사용해야 합니다. 앱 모델에서는 현재 사용자와 응용 프로그램을 설명하는 OAuth 액세스 토큰을 전달합니다. SSL을 사용하는 것은 사용자에 대한 SAML 토큰을 전달할 때 토큰이 이동하는 채널을 암호화함으로써 네트워크 트래픽을 스니핑하려는 사용자에 의한 콘텐츠 액세스 권한을 부여하는 재생 스타일 공격을 방지하는 것과 마찬가지입니다. SSL을 사용하는 경우 이러한 시나리오의 발생을 방지할 수 있으며, 이러한 응용 프로그램의 URL은 설치된 인스턴스마다 다르기 때문에 URL을 쉽게 관리하려면 와일드카드 SSL 인증서도 필요합니다. 이 게시물에서 설명하는 시나리오에서는 *.contosoapps.com용 와일드카드 SSL 인증서를 가져옵니다.

지금까지 필요한 서비스 응용 프로그램, 앱 도메인 및 접두사에 필요한 구성, URL을 만드는 방법, 그리고 필요한 DNS 및 SSL 항목에 대해 설명했습니다. 다음으로는 응용 프로그램 요청의 경로를 지정하는 방법을 설명하겠습니다. 일반적으로는 응용 프로그램 요청 라우팅 전용으로 별도의 SharePoint 웹 응용 프로그램이 필요합니다. 아래에서 그 이유에 대해 살펴보겠습니다. 다음과 같이 정의되는 세 개의 웹 응용 프로그램이 있다고 가정하겠습니다. 이러한 웹 응용 프로그램은 모두 SSL을 사용하므로 각 응용 프로그램에 대해 다음과 같은 고유한 IP 주소를 사용합니다.

  • team.contoso.com – 192.168.1.10
  • my.contoso.com – 192.168.1.11
  • portal.contoso.com – 192.168.1.12

위에서 설명한 것처럼 앱 도메인은 팜에 하나만 있을 수 있으며 하위 도메인이어서는 안 됩니다. 이로 인해 위의 응용 프로그램과 관련하여 두 가지 문제가 발생합니다.

  • 이러한 각 웹 응용 프로그램에서 응용 프로그램을 설치할 때 적절한 응용 프로그램 요청을 올바른 웹 응용 프로그램으로 라우팅할 방법을 지정해야 합니다. 이 예제의 경우 웹 응용 프로그램은 세 개인데 앱 도메인은 하나뿐이기 때문입니다.
  • 기존 웹 응용 프로그램 중 하나로 응용 프로그램 요청을 라우팅하려고 하면 SSL이 손상됩니다. 위에서 설명했듯이 앱 섹션에서 모든 웹 응용 프로그램에 대해 SSL을 사용하므로, 모든 웹 응용 프로그램이 *.contoso.com과 같은 SSL 인증서를 포함하게 됩니다. 따라서 *.contoso.com과 *.contosoapps.com(앱이 사용할 URL) 둘 다에서 작동하는 SSL 와일드카드는 없기 때문에 응용 프로그램 요청을 웹 응용 프로그램으로 라우팅할 수 없습니다.

이러한 문제를 해결하려면 네 번째 웹 응용 프로그램을 만들면 됩니다. 이 응용 프로그램은 호스트 헤더 이름 없이 만든 다음 공유 IP인 192.168.1.13을 할당합니다. 그러면 DNS에서 *.contosoapps.com의 와일드카드 항목은 192.168.1.13을 가리키게 됩니다. 이에 따라 앱 웹 응용 프로그램은 해당 IP 주소에서 "수신 대기"하며, 라우팅을 수행하는 SharePoint http 모듈이 응용 프로그램에 대한 요청을 선택합니다. 이 모듈은 앱 관리 서비스 응용 프로그램을 사용하여 실제로 해당 응용 프로그램을 호스팅하는 웹 응용 프로그램을 확인한 다음 요청을 해당 웹 응용 프로그램으로 다시 라우팅합니다. 그러면 요청이 해당 웹 응용 프로그램, 사이트 모음 및 앱 자체가 실재하는 SPWeb에서 처리되므로 이들 항목에 대한 모든 보안 및 인증 설정이 올바르게 적용됩니다.

이 경우의 팜 구성은 다음과 같습니다.

  •  앱 구성
    • 앱 도메인 - contosoapps.com
    • 앱 접두사 - apps
  • 웹 응용 프로그램

    • team.contoso.com

      • IP 주소: 192.168.1.10
      • SSL 인증서: *.contoso.com

    • my.contoso.com

      • IP 주소: 192.168.1.11
      • SSL 인증서: *.contoso.com

    • portal.contoso.com

      • IP 주소: 192.168.1.12
      • SSL 인증서: *.contoso.com

    • 호스트 헤더는 사용하지 않을 수도 있고 contosoapps 등의 헤더를 사용할 수도 있습니다. 여기서는 호스트 헤더를 기반으로 라우팅하는 것이 아니라 IP 주소를 기반으로 라우팅하기 때문에 호스트 헤더는 관계가 없습니다. 그러나 호스트 헤더를 사용하는 경우 모든 웹 응용 프로그램이 같은 IP 주소를 사용한다면 이 수신기 웹 응용 프로그램에는 호스트 헤더 값을 포함해서는 안 됩니다. 호스트 헤더 값을 포함하는 경우에는 IIS에서 모든 웹 응용 프로그램에 대해 앱 요청을 선택하지 않습니다.

      • IP 주소: 192.168.1.13
      • SSL 인증서: *.contosoapps.com
  • DNS
    • team.contoso.com – 192.168.1.10
    • my.contoso.com – 192.168.1.11
    • portal.contoso.com – 192.168.1.12
    • *.contosoapps.com – 192.168.1.13

지금까지 앱의 모든 인프라 구성 측면에 대해 설명했습니다. 끝으로 SharePoint 2013용 새 앱 제공을 계획할 때 기억해야 할 몇 가지 고려 사항을 언급하고 게시물을 마무리하겠습니다.

  • SAML을 사용하는 웹 응용 프로그램에서는 SharePoint 앱이 작동하지 않습니다. 따라서 SAML 인증을 사용하는 경우에는 해당 웹 응용 프로그램에서 SharePoint 앱을 사용할 수 없습니다. 이 문제는 이후 서비스 팩이나 기타 유형의 패치에서 해결될 수도 있지만, SharePoint 2013 RTM에서는 해당 제한이 적용됩니다.
  • SharePoint 앱은 여러 영역(AAM)을 지원하지 않으며 모든 요청이 기본 영역에서 처리됩니다. AAM을 사용하여 여러 영역을 지원하는 경우에는 SharePoint 앱을 사용할 수 없습니다. 모든 앱은 기본 영역에서 처리되므로 이론적으로는 모든 사용자가 연결할 수 있도록 기본 영역을 표시했으며 모든 영역에서 정확히 동일한 인증 메커니즘을 사용하는 경우(몇 가지 제한이 적용될 수도 있지만 너무 세부적인 내용이라 여기서는 다루지 않음) 앱 사용이 가능할 수도 있습니다. 그러나 일반적으로는 모든 끝점을 모든 사용자에게 표시하지 않으려는 경우 또는 다른 인증 방법을 사용하려는 경우에 영역을 사용하므로 이 방식은 현실적으로 적용하기 어렵습니다. 이 문제 역시 이후에 변경될 수도 있지만 현재 SharePoint 2013 RTM에서는 제한으로 적용됩니다.

 

아, 마지막으로 한 가지 더 짚고 넘어갈 중요한 사항이 있네요. 위에서 길게 설명을 해서 구성을 많이 수행해야 하는 것처럼 보이고, 실제로도 여러 항목을 구성해야 하기는 하지만 Office 365를 사용하는 경우에는 모든 구성 작업이 자동으로 수행됩니다. 따라서 번거로운 작업을 수행할 필요가 없으며 응용 프로그램을 설치하여 사용하면 됩니다. 사용 가능한 옵션을 평가할 때 이 점도 고려하시기 바랍니다.

지금까지 살펴본 것처럼 SharePoint 앱은 SharePoint 2013의 중요한 요소이지만, 앱을 사용하기 전에 먼저 몇 가지 계획과 디자인 작업을 수행하여 앱 지원을 위한 인프라를 구축해야 합니다.

 

이 문서는 번역된 블로그 게시물입니다. 원본 문서는 Planning the Infrastructure Required for the new App Model in SharePoint 2013을 참조하십시오.