네이티브 XML 웹 서비스 사용을 위한 최선의 구현 방법
Microsoft SQL Server의 이후 버전에서는 이 기능이 제거됩니다. 새 개발 작업에서는 이 기능을 사용하지 않도록 하고, 현재 이 기능을 사용하는 응용 프로그램은 수정하십시오.
이 항목에서는 비즈니스 솔루션에 사용하기 위해 SQL Server에서 네이티브 XML 웹 서비스를 계획하고 평가할 때 고려할 수 있는 최선의 구현 방법에 대해 설명합니다. 이러한 권장 구성은 다음과 같은 점에서 사용자를 지원합니다.
네이티브 XML 웹 서비스를 사용할 때 SQL Server 설치에 대해 보안을 지원합니다.
사용 지침을 제공하여 SQL Server의 성능을 개선합니다. 이러한 지침을 통해 네이티브 XML 웹 서비스를 사용하여 사용자의 응용 프로그램을 효과적으로 지원하고 있는지 여부를 판단할 수 있습니다.
보안을 위한 최선의 구현 방법
네이티브 XML 웹 서비스를 배포할 때는 다음과 같은 최선의 보안 구현 방법을 고려해 보십시오.
Kerberos 인증 사용
특정 사용자나 그룹에 대한 끝점 연결 권한 제한
중요한 데이터를 교환할 때 SSL(Secure Socket Layer) 사용
방화벽 뒤에 SQL Server 사용
서버에서 Windows Guest 계정이 비활성화되어 있는지 확인
필요에 따라 끝점 상태 제어 및 업데이트
가능한 한 안전한 끝점 기본값 사용
Kerberos 인증 사용
CREATE ENDPOINT(Transact-SQL)를 사용하여 끝점을 만들 때 AUTHENTICATION = KERBEROS 또는 AUTHENTICATION = INTEGRATED를 선택하여 Kerberos 하에서 끝점에 사용되는 인증 유형으로 Windows 통합 보안을 설정할 수 있습니다. 첫 번째 옵션을 사용하면 끝점의 인증 모드로 Kerberos만 허용합니다. 두 번째 옵션을 사용하면 끝점이 NTLM 인증과 Kerberos 인증을 모두 지원합니다.
인증을 수행할 때 Kerberos 프로토콜은 상호 인증과 같은 기본 제공 기능을 사용하여 향상된 보안을 제공합니다. 이는 서버와 클라이언트 모두의 ID가 인증됨을 의미합니다.
Kerberos 인증을 사용하면 SQL Server 실행 계정과 SPN(서비스 보안 주체 이름)을 연결해야 합니다. 자세한 내용은 Http.sys를 사용하여 Kerberos 서비스 사용자 이름 등록을 참조하십시오.
특정 사용자나 그룹에 대한 끝점 연결 권한 제한
배포에 필요한 끝점을 만든 후에는 GRANT CONNECT 및 ALTER ON ENDPOINT 등의 Transact-SQL 문으로 끝점 연결 권한을 설정하여 끝점에 보안을 설정합니다. 연결 권한을 할당할 때는 구체적이어야 하며 SQL Server에 끝점 액세스가 예약된 특정 사용자나 특정 그룹에게만 권한을 부여합니다.
일반적으로는 개별 사용자만 끝점에 연결할 수 있도록 권한을 제한해야 합니다. public 역할에 액세스 권한을 부여하는 것은 바람직하지 않습니다. 대신 SQL Server의 권한 모델을 완전히 이해하는 것이 좋습니다. 권한 모델을 사용하면 끝점에 대한 액세스를 적절히 제어할 수 있습니다.
.gif "중요 정보") 중요 |
|---|
public 역할은 모든 SQL Server 사용자가 속하는 특수한 데이터베이스 역할입니다. 이 역할에는 데이터베이스에 액세스할 수 있는 모든 사용자를 위한 기본 액세스 권한이 포함됩니다. 이 데이터베이스 역할은 SQL Server의 기본 제공 기본 역할로, Windows 권한에서의 Everyone 또는 Authenticated Users 권한과 비슷하게 모든 사용자에게 액세스 권한을 부여하는 기능을 하기 때문에 SQL Server에서 권한을 구성할 때는 주의해야 합니다. |
자세한 내용은 GRANT 끝점 사용 권한(Transact-SQL)를 참조하십시오.
중요한 데이터를 교환할 때 SSL(Secure Sockets Layer) 사용
SSL(Secure Sockets Layer) 프로토콜은 안전한 TCP/IP 소켓(IP 주소와 TCP 포트 번호의 조합) 인터페이스를 통해 데이터의 암호화 및 암호 해독 모두를 지원합니다. SQL Server 끝점에서 SSL 암호화를 제공하려면 먼저 인증서를 구성해야 합니다.
기본 SSL 포트 443을 위한 인증서를 등록할 때는 다른 응용 프로그램이 동일한 인증서를 공유할 수 있음을 유의해야 합니다. 예를 들어 IIS(인터넷 정보 서비스)가 동일한 포트에서 SSL 트래픽을 호스팅할 수 있으며 이러한 경우 이 구성이 IIS 사용자에게도 영향을 줄 수 있습니다. SSL 포트와 해당 인증서의 공유로 인해 보안 문제가 발생할 수 있습니다.
자세한 내용은 SSL에 사용되는 인증서 구성을 참조하십시오.
방화벽 뒤에 SQL Server 사용
최상의 보안을 위해서는 네이티브 XML 웹 서비스를 방화벽 뒤에서 사용해야만 합니다. 끝점을 설정할 때는 HTTP 액세스를 제공하기 위해 사용하는 모든 TCP 포트 번호가 방화벽에 의해 보호되도록 해야 합니다. 방화벽의 보호 없이 시스템의 SQL Server에 인터넷 클라이언트가 직접 액세스하도록 하는 것은 바람직한 네트워크 구성이 아닙니다. 자세한 내용은 SQL Server 설치에 대한 보안 고려 사항을 참조하십시오.
서버에서 Windows Guest 계정이 비활성화되어 있는지 확인
Guest 계정은 대부분의 Microsoft Windows 버전에서 제공되는 기본 제공 사용자 계정입니다. Guest 계정은 기본적으로 Windows Server 2003에서 비활성화되어 있으며 Windows 2000 Server 및 Windows NT Server 4.0에서는 활성화되어 있습니다.
끝점 사용 중에 노출 공격 위험을 줄이려면 SQL Server가 실행되는 서버에서 Guest 계정을 비활성화해야 합니다. 자세한 내용은 Windows 도움말에서 "로컬 사용자 계정을 사용하거나 사용하지 않으려면" 항목을 참조하십시오.
필요에 따라 끝점 상태 제어 및 업데이트
CREATE ENDPOINT(Transact-SQL)를 사용하여 끝점을 만들 때 STATE = STARTED를 지정하여 기본 상태를 명시적으로 STARTED로 설정하지 않은 경우 기본 상태는 STOPPED입니다. 기존 끝점의 상태를 제어하려면 ALTER ENDPOINT(Transact-SQL)를 사용하여 STOPPED, STARTED 또는 DISABLED 중 하나를 지정합니다.
예를 들어 이전에 생성된 sql_endpoint 끝점을 시작하거나 중지하려면 다음 문을 사용합니다.
ALTER ENDPOINT sql_endpoint STATE=STARTED
ALTER ENDPOINT sql_endpoint STATE=STOPPED
또한 끝점을 사용하지 않을 것으로 예상되는 경우에는 끝점을 비활성화하거나 끝점 자체 또는 끝점의 특정 웹 메서드를 삭제해야 합니다.
다음 예에서는 끝점을 비활성화하는 방법을 보여 줍니다.
ALTER ENDPOINT sql_endpoint STATE=DISABLED
[!참고]
끝점을 비활성화하고 나면 SQL Server 서비스(MSSQLServer)를 다시 시작할 때까지 끝점을 다시 시작할 수 없습니다.
끝점에서 웹 메서드를 삭제하려면 다음 형식과 비슷한 문을 사용합니다.
ALTER ENDPOINT sql_endpoint
FOR SOAP
(
DROP WEBMETHOD 'SayHello'
)
끝점을 삭제하려면 DROP ENDPOINT를 사용합니다.
가능한 한 안전한 끝점 기본값 사용
CREATE ENDPOINT 또는 ALTER ENDPOINT를 사용하여 끝점을 만들거나 수정할 때는 명시적으로 달리 설정하지 않는 한 다음 옵션 기본값이 적용됩니다.
BATCHES = DISABLED
끝점에 대해 Transact-SQL일괄 처리 모드를 비활성화합니다.
LOGIN_TYPE = WINDOWS
끝점 사용자에 대해 Windows 인증만 허용합니다.
응용 프로그램 배포에 필요한 액세스나 기능을 지원하기 위해 이러한 설정을 수정해야 하는 경우가 아닐 때는 가능한 한 옵션 기본값을 사용하는 것이 바람직합니다.
암호화 알고리즘을 선택하는 방법은 암호화 알고리즘 선택을 참조하십시오.
성능을 위한 최선의 구현 방법
네이티브 XML 웹 서비스를 배포하려면 다음과 같은 최선의 성능 구현 방법을 고려해 보십시오.
적절한 시나리오로 배포
SOAP 기반의 솔루션을 계획하는 경우 추가 서버 리소스 고려
요구 사항에 적합한 WSDL 옵션 구성
적절한 시나리오 배포
네이티브 XML 웹 서비스는 다음과 같은 요구 사항이 있는 시나리오에 가장 적합합니다.
응용 프로그램이 XML 데이터를 반환하거나 사용합니다.
응용 프로그램이 비즈니스 논리를 저장 프로시저에 크게 의존합니다.
비즈니스 솔루션의 일부로 SQL Server가 호스팅하는 웹 서비스 응용 프로그램을 다른 웹 서비스 응용 프로그램과 통합하여 SOA(Service Oriented Architecture) 목표를 달성합니다.
웹 서비스를 동일한 서버에 함께 배포하기 위해 SQLXML 중간 계층 솔루션을 위한 보다 나은 성능의 대안이 필요합니다.
SQL Server 2005 Reporting Services 이상에서 제공하는 풍부한 기능 집합과 추가 오버헤드로도 사용자의 요구 사항을 모두 해결할 수 없는 인트라넷 웹 사이트에 대한 정적 보고서를 생성하고 게시하려고 합니다.
다음과 같은 요구 사항이 있는 시나리오에서는 네이티브 XML 웹 서비스를 사용하는 것이 바람직하지 않습니다.
응용 프로그램을 사용하여 큰 binaryimage 또는 text 값 등의 BLOB(Binary Large Object) 데이터를 삽입하거나 검색합니다.
현재 사용 중인 응용 프로그램에는 실시간 트랜잭션 처리와 필수적인 업무 처리를 위한 응답 시간이 중요합니다.
TPC Benchmark C(TPC-C) 응용 프로그램과 같은 다른 처리 집중형 응용 프로그램과 함께 SQL Server를 사용합니다.
SOAP 기반의 솔루션을 계획하는 경우 추가 서버 리소스 고려
용량 계획이 목적인 경우에는 TDS(Tabular Data Stream) 프로토콜과 달리 SOAP 성능은 응용 프로그램에 따라 달라지며 추가 서버 리소스 오버헤드가 필요할 수 있습니다. 예를 들어 큰 XML 문서를 반환하는 시나리오를 이용하여 SQL Server 제품 팀이 수행하는 SQL Server 2005에 대한 테스트에서 SOAP 기반 액세스 도구는 TDS 기반 액세스보다 20%~30% 오래 걸립니다.
요구 사항에 적합한 WSDL 옵션 구성
네이티브 XML 웹 서비스를 배포하기 전에 사용자 솔루션에 필요한 모든 클라이언트와 운영 체제를 지원할 수 있도록 WSDL 옵션을 적절하게 설정해야 합니다.
웹 서비스 클라이언트에 Windows가 아닌 운영 체제가 포함된 이기종 환경에서 상호 운용성을 최대화하려면 단순 WSDL을 사용합니다. Microsoft Visual Studio 2005로 Windows 전용 환경을 개발하는 경우 기본 WSDL을 사용하여 Visual Studio 2005의 풍부한 유형 지원을 이용할 수 있습니다.
경우에 따라 타사 SOAP 클라이언트에는 상호 운용성을 위해 사용자 지정 WSDL이 필요할 수 있습니다. 자세한 내용은 사용자 지정 WSDL 지원 구현을 참조하십시오.