도메인 트러스트 없이 Excel에서 파트너의 SQL Server로

다른 조직의 SQL Server에서 테이블을 여는 Excel 통합 문서에는 보통 하나로 논의되는 세 가지가 필요합니다. 서버가 받아들이는 ID, 클라이언트가 검증하는 전송, 그리고 양쪽이 허용하는 네트워크 경로입니다. 도메인 트러스트는 첫 번째를 충족하는 한 방법이며 가장 넓습니다. TLS는 두 번째를 충족하고 첫 번째에 대해서는 아무 말도 하지 않습니다. 경로는 세 번째를 충족하며 그 자체로는 아무것도 보호하지 않습니다.

이 셋을 분리하면 스프레드시트는 관리 관계가 아니라 작고 검토 가능한 요청이 됩니다.

질문이 숨긴 세 가지 결정

ID는 데이터베이스가 당신을 누구로 보는가입니다. 신뢰된 도메인의 Windows 계정, 자체 암호를 가진 SQL 로그인, 또는 인증서 기반 ID입니다. 전송은 세션이 암호화되는지, 클라이언트가 서버의 인증서 체인을 확인하는지입니다. 경로는 패킷이 리스너에 도달하는 방식이며 VPN, 프라이빗 링크, 방화벽 규칙이 있는 공용 엔드포인트일 수 있습니다. 각각 다른 곳에 있고 각각 단독으로 실패할 수 있습니다.

포리스트 트러스트는 첫 번째에 폭넓게 답하며 통합 문서 하나의 설정이 아니라 조직 간의 관계입니다. 또한 아무것도 암호화하지 않는데, 트러스트가 보안 통제라고 가정한 사람들은 이에 놀랍니다.

포리스트 트러스트 없는 ID

대상 환경에 의도적으로 마련한 계정은 클라이언트 워크플로가 사용할 수 있다면 트러스트 없이도 더 좁은 요구를 충족할 수 있습니다. 정책이 허용할 때 SQL 인증이 또 다른 흔한 답입니다. 로그인은 자체 자격 증명 수명 주기를 가지며 도메인에 가입하지 않고 Windows 통합 인증을 만들지 않습니다. 인증서나 토큰 기반 ID는 최신 플랫폼의 세 번째 선택지입니다. 무엇을 고르든 통합 문서에 실제로 필요한 데이터베이스 권한만 부여하십시오.

누군가의 개인 로그인보다 전용 계정을 선호하십시오. 스프레드시트에 공유된 자격 증명은 언젠가 터질 지원 문제이며, 이름 있는 계정은 프로젝트가 끝날 때 권한 회수를 가능하게 합니다.

암호화는 하되 인증서를 신뢰할까

ODBC Driver 18에서는 Encrypt=Yes;TrustServerCertificate=No 이 인증서가 실제로 확인되는 암호화 세션을 요구합니다. 그러면 연결 문자열은 인증서가 포괄하는 서버를 지정해야 하고, 클라이언트는 그 체인을 신뢰해야 합니다. Driver 18은 이전 버전과 달리 기본적으로도 암호화하므로 오래된 연결 문자열이 말하지 않은 채 TLS를 협상할 수 있습니다. 명시적 설정은 의도한 정책을 모든 컴퓨터에서 보이게 하며, 여러 사람이 같은 통합 문서를 유지할 때 중요합니다.

TrustServerCertificate=Yes 은 암호화하고 검증을 건너뛰는데, 이는 이름 불일치나 신뢰할 수 없는 체인에 대한 동등한 수리가 아닙니다. 클라이언트가 잘못된 엔드포인트에 도달했다고 알려 줄 신호를 없애므로, 대신 인증서나 이름을 고치십시오.

서버 측 강제는 별도의 통제입니다. 암호화가 모든 클라이언트에 적용되어야 한다면 서버의 강제 암호화 설정을 구성하고 확인하십시오. 협조적인 연결 문자열 하나가 강제하는 것은 없습니다.

네트워크 경로는 보호가 아니다

VPN을 통해 도달하는 프라이빗 리스너는 노출을 줄이며, 그것이 작동하려면 VPN이 올바른 대상 및 반환 경로를 전달해야 합니다. 작동하는 터널은 인증의 필요성이나 인증서 검증을 없애지 않으며, TLS는 어떤 원격 시스템이 연결을 시도할 수 있는지 제한하지 않습니다. 이는 세 가지 별개의 관찰입니다. TLS 핸드셰이크, VPN 로그인, 승인된 쿼리. 세 번째만이 통합 문서가 읽도록 허용된 데이터를 읽었음을 증명합니다.

그러므로 데이터베이스를 인터넷에 노출하여 트러스트 질문에 답하는 지름길을 거부하십시오. 좁은 답은 보통 전용 계정, 검증된 암호화, 승인된 하나의 경로이며 그 순서입니다.

일반적인 Excel 워크플로로 확인하십시오. 허용된 ID, 유효한 권한, 협상된 암호화를 각각 서버 자체의 세션 보기로 점검합니다.