동일한 로그인을 사용하여 두 데이터베이스를 연결하기 위해 세 번째 데이터베이스를 통과하는 것이 더 안전합니까?

다음과 같은 설정이 있습니다.

• 데스크탑 소프트웨어에서 사용하는 개인 데이터를 포함하는 여러 프로덕션 데이터베이스
• 개인 데이터베이스의 일부 데이터가 필요한 공용 웹 사이트의 웹 데이터베이스
• 개인 데이터베이스에서 데이터를 가져 오는 몇 가지보기 및 저장 프로 시저가 포함 된 중개 데이터베이스

현재 웹 사이트는 웹 데이터베이스에 로그인하고 웹 데이터베이스는 중간 데이터베이스에 연결하여 프로덕션 데이터베이스에서 데이터를 가져 오거나 저장 프로 시저를 실행합니다. 모든 데이터베이스는 동일한 SQL 인스턴스에 있으며 전체 프로세스는 동일한 사용자 계정을 사용합니다.

사용자 계정은 웹 데이터베이스 및 중개 데이터베이스에 대한 전체 액세스 권한을 갖지만 개인 데이터베이스의 특정보기 및 저장 프로 시저에만 액세스 할 수 있습니다.

공용 데이터베이스를 개인 데이터베이스에 직접 연결하는 것보다 이것이 더 안전한가요?

동일한 로그인을 사용하여 모든 데이터베이스의 데이터에 액세스하기 때문에 중개 데이터베이스가 문제를 복잡하게하는 것처럼 보이며 이미 개인 데이터베이스에 필요한보기 / SP로 제한되어 있습니다. 나는 그것을 제거하기를 바라고있다.

한 가지는 여기서 뛰어납니다.

전체 프로세스는 동일한 로그인 자격 증명 세트를 사용합니다.

문제

따라서 가상 userX (Excel을 사용하는 미트 백 또는 IIS AppPool Identity)는 일부 뷰와 코드를 볼 수 있습니다. userX가 3 개의 데이터베이스에 설정되어 있기 때문에 이러한 뷰와 코드가 어떤 데이터베이스에 있는지는 중요하지 않습니다.

그러나 이와 같은 소유권 체인은 손실됩니다.

WebDB.dbo.SomeProc전화를 해봅 시다 PrivateDB.dbo.SomeTable. UserX는 두 개체 모두에 대한 권한이 필요합니다. 이것이 OneDB.WebGUI.SomeProc사용 중이 면 권한 OneDB.dbo.SomeTable만 OneDB.WebGUI.SomeProc필요합니다. 소유자가 같은 참조 된 개체에 대한 권한은 확인되지 않습니다.

참고 : 데이터베이스 간 소유권 체인을 너무 깊이 살펴 보지 않았습니다 . 난 단지 평범한 구식 알고있다 "소유권 체인을" 잘

이제 의견에 따라 실제로 결합 할 수있는 2 개의 데이터베이스가 있습니다. 원래는 암시 된 3이 아닙니다. 그러나 중간과 웹을 결합 할 수 있습니다.

다른 "비공개"데이터베이스는 결합 될 수 있지만 별도의 문제가 될 것입니다. "하나의 데이터베이스 또는 다수"에 대한 자세한 내용은 하단 링크를 참조하십시오.

해결책?

추가 데이터베이스가 코드 컨테이너 일 경우 스키마가 더 좋습니다.

이것은 "스키마"를 사용해야하는 "데이터베이스"(MySQL이 아닌 SQL Server 의미)를 사용한 것 같습니다. WebGUI 스키마, 도우미 또는 공통 스키마 (중간 데이터베이스를 대체하기 위해) 및 데스크톱 스키마가 있습니다. 이렇게하면 클라이언트를 기반으로 권한을 분리하고 하나의 데이터베이스 만 가질 수 있습니다.

하나의 데이터베이스 ( "소유권 체인"외에)를 사용하면 인덱스 된 뷰, SCHEMABINDING (항상 사용) 및 별도의 데이터베이스로는 수행 할 수없는 데이터베이스 를 고려할 수 있습니다.

스키마에 대한 자세한 내용은 다음 질문을 참조하십시오.

• 스키마 디자인-모범 사례?
• 스키마를 과도하게 사용하거나 올바르게 사용합니까?

마지막으로 "트랜잭션 무결성이 필요하지 않음"에 따라 별도의 데이터베이스를 보유 할 이유가 없습니다. 이 설명하는이 질문을 참조하십시오 새 데이터베이스 대 비 DBO 스키마를 사용하는 경우에 의사 결정 기준을

대답은 다음과 같습니다. 개인 데이터베이스에 내부 LAN 외부에서 (또는 VPN을 통해서만) 액세스 할 수없는 경우이 체계는 웹 사이트의 자격 증명을 사용하는 사람이 해당 개인 DB 서버에 대한 액세스를 제한했을뿐 아니라 추가 작업이 필요하므로 보안을 추가합니다. 내부 네트워크에 침입-침입을 발견하고 구멍을 막는 데 편리한 시간).

그렇지 않다면 복잡성을 제외하고는 아무것도 추가하지 않는다고 생각합니다.

편집하다:

IntermDb가 빈 데이터베이스 단지 PrivateDB에 연결 : 나는 귀하의 질문에, 내가 제대로 이해한다면 보자 오해 한 것 같다 또는 그 데이터를 검색 할 PrivateDB에 연결은 '자신의의 / 절차 전망이 DB입니다 ?

첫 번째 경우, WTF? 찢어 누군가가 PrivateDB에 대한 액세스를보다 느리게 프로파일 링하기 위해 감사하고 싶지 않고 WebApp 개발자가 더 열심히 일하도록하지 않는 한 가치가 없습니다. SQL 프로파일 러는 DB_ID를 사용하여 필터링 할 수 있습니다 ...

두 번째 경우에는 이전 답변을 유지합니다.

편집 : "동일한 SQL 인스턴스에있는 3 개의 데이터베이스와 3 개의 데이터베이스에 사용 된 로그인이 동일하고 액세스 만 할 수 있기 때문에 프라이빗 DB를 퍼블릭 db에 직접 연결하는 것보다 이것이 더 안전한지 여전히 알지 못합니다. 개인 DB의 특정 뷰 및 저장 프로 시저 "

중개자가 있다는 것은 침입자가 코드를 파헤쳐 야한다는 것을 의미합니다 알고 IntermDB의 실존을 - 그리고 그것은 그가 PrivateDB 존재를 알고에 코드를 파고있다.

PrivateDB를 조직 LAN / WAN 내부의 다른 서버에 배치하면 (가능한 경우) 관리자가 침입 시도를 감지하고 차단하는 데 충분한 시간을 제공 할 수 있습니다. 동의어를 사용하면 기존 코드로 다시 작성하기 만하면됩니다.

또한 모든 이점은 PrivateDB의 데이터에 액세스하기 위해 모든 코드가 IntermDB를 통과해야하기 때문에 개발자가이를 우회 하려는 유혹을받지 않으며, SQL Server 프로파일 러에서 PrivateDb 데이터 요청의 DB_ID로 쉽게 시도 할 수 있습니다. WebAppDb입니다.