연결된 서버 위험


10

여러 서버의 데이터베이스 데이터가 필요한 새로운 기능을 구현하고 있습니다. 이 모든 서버의 데이터를 통합하고 정렬하면됩니다. 생각 나는 두 가지 옵션은 다음과 같습니다.

  1. 연결된 서버를 사용하고 간단한 쿼리를 작성하여 한 서버에서 실행될 데이터를 통합하고 다른 서버에서 데이터를 수집합니다.

  2. 응용 프로그램을 사용하여 모든 서버에서 데이터를 수집 한 다음 SQL Server로 다시 보내 정렬합니다 (응용 프로그램에서 정렬을 구현하고 싶지 않음).

SQL Server 2008 r2의 활성 / 활성 클러스터에서 서버를 실행합니다. 하나의 데이터베이스 / 서버에 액세스 할 수있는 경우 모든 데이터베이스에 동일한 권한이 있습니다. 이것은 공개 응용 프로그램입니다 (사용자 로그인 필요).

연결된 서버를 사용하면 어떤 위험이 있습니까? 걱정해야 할 보안 결함이 있습니까? 활성 / 활성 클러스터에서 연결된 서버를 실행하는 데 문제가 있습니까? 대안에 비해 중요한 성능 문제가 있습니까?

링크 된 서버에 대한 일반적인 부정적인 "버즈"가있는 것 같습니다만, 실제 문제가 있다고 생각할만한 구체적인 내용은 없습니다.


향후 참조 질문을 여러 번 게시하지 않는 것이 가장 좋습니다. 귀하의 질문에 대해 이미 SO에 대한 의견이 있습니다. 중재자의 관심을 끌기 위해 질문에 플래그를 지정하고 질문을 DBA.SE로 마이그레이션하도록 요청할 수 있습니다. stackoverflow.com/questions/16045441/linked-server-risks

답변:


13

연결된 서버는 다음과 같은 의미를 생각하는 한 매우 잘 작동 할 수 있습니다.

  1. 보안 : 주요 고려 사항은 연결된 서버가있는 경우 서버가 손상되면 모두 위험에 노출 될 수 있다는 것입니다. 각 사용자마다 다른 자격 증명이있는 경우에도 다른 공격자 (유일한 공격 경로가 유출 / 발견 / 추측 된 자격 증명 일 경우 공격자가 다른 리소스를 얻지 못하게 됨)는 링크가 모든 것을 우회 할 수 있습니다. 또한이 링크는 하나 이상의 서버가 공용 인터페이스에 데이터를 제공하지 않는 경우와 같이 공용 네트워크에서 다른 데이터베이스를 숨기는 보호를 우회하므로 일반적으로 방화벽을 통해 어떤 방법으로도 표시되지 않습니다. "복제에 있어서도 같은 위험이 위험하지 않습니까?"라고 생각할 수도 있습니다. 대답은 ' 그렇지만'복제는 개별 애플리케이션 데이터베이스간에 이루어지며 링크 된 서버 라우트는 링크가 DB 레벨이 아닌 서버 레벨에있을 때 동일한 서버의 다른 데이터베이스를 손상시킬 수 있습니다 (물론 사용자 액세스를 신중하게 제어하여이 위험을 완화 할 수 있음) 권리는 있지만 최소한 계획에 대해서는 알고 있어야합니다. 보안 관련 참고 사항 : 서버가 같은 사이트에 있지 않은 경우 공용 인터페이스에서 SQL Server를 사용할 수 있도록하는 대신 VPN을 사용하여 서버를 연결해야합니다.

  2. 대역폭 : 모든 서버가 서로간에 훌륭하고 빠르고 계량되지 않은 연결로 동일한 DC에있는 경우이 서버에 대해 걱정할 필요가 없지만 특히 사용자가 광고를 실행할 수있는 경우 더 멀리있는 연결에주의해야합니다. 몇 가지 다양한 질문. VPN 링크 수준에서의 압축은 대부분의 데이터 세트에서 크게 도움이되지만 지연 시간이 길어 효율성 문제가 악화 될 수 있습니다 (아래 참조).

  3. 효율성 : 단순히 데이터 청크를 줄이면 이는 큰 문제가 아니지만 (잠금 고려 : 다음 요점 참조) 조인을 통해 무언가를 수행하자마자 제한 사항이 있습니다. 쿼리 플래너는 요청을 최적화하기 위해 수행 할 수 있습니다. 네트워크 대기 시간으로 인해 서버가 서로 로컬이 아닌 경우 매우 느리게 실행되는 쿼리를 생성하는 많은 인덱스 검색을 수행해야하는 경우 (로컬 서버에도 동일한 문제가 있지만, 물론 더 적은 범위에서) 대신 인덱스 스캔 (대기 시간 이점을 얻기 위해 대역폭 사용을 상쇄)을 사용하고 잠금을 유지하는 경우 (더러운 읽기 문제 등을 피하기 위해) 이것은 응용 프로그램의 다른 부분에도 영향을 미칩니다.

  4. 잠금 / 동시성 : 서버 외부로 이동하면 쿼리 실행 시간이 증가하여 아직 모르는 잠금 문제가 악화되어 응용 프로그램의 동시성 및 확장 성이 크게 저하됩니다. 잠금 문제를 주시하고 적절하게 플래너 힌트를 제공하는 정기 및 / 또는 장기 실행 크로스 서버 쿼리를 사용하는 경우 매우주의해야합니다.

보안 및 성능 문제를 관리하기위한 충분한 준비가되어있는 한, 연결된 서버를 사용하는 데는 문제가 없지만 동일한 방법을 달성하는 데 더 나은 / 안전 / 더 신뢰할 수있는 / 쉬운 방법이있을 수 있습니다. 결과.


1

동일한 부정적인 "버즈"를 경험했지만 링크 된 서버에서 직면 한 유일한 문제는 네트워크를 통해 많은 양의 데이터를 쉽게 가져올 수 있다는 것입니다. DBA의 관점에서 볼 때, DBA가 아닌 사람이 남용하지 않겠다고 약속하더라도이를 수행 할 수없는 경우에는 무섭습니다.

귀하의 경우 여전히 데이터를 이동해야하기 때문에 자신의 응용 프로그램을 작성하면 아무런 이점이없는 것 같습니다. 매우 간단한 권한 모델이있는 것처럼 들리므로 환경에 따라 링크가 필요하지 않은 곳에 링크를 사용하지 않도록 특수 권한을 설정하는 것이 좋습니다.


0

연결된 서버는 개발자에게 거의 "마법의"상태를 만듭니다. 그러나 한 번의 요청으로 5 개의 서버에서 수십만 개의 레코드를 반환 할 수있는 하나의 쿼리로 네트워크를 압도하는 것이 매우 쉬워 질 수 있으며 5 대의 서버 모두에서 레코드를 잠글 수도 있습니다. 한 번의 쿼리로 모든 데이터베이스를 잠그는 위험에 대해 1 ~ 2 명의 최고의 개발자를 교육시킬 때까지 노련한 DBA를 제외한 누구도 쿼리를 쓰지 못하게 할 것입니다.

연결된 서버는 약물과 같습니다. 일단 사용하면 다시 돌아가서 왜 이전에 사용하지 않았는지 궁금 할 것입니다. 나는 문제가 없었지만 항상 조심했다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.