2012-02-01 2 views
4

이전 Access 2007 프로젝트를 MS SQL Server 2008 Express로 마이그레이션하는 작업은 담당합니다. 첫 번째 단계는 Access 폼과 보고서를 클라이언트에서 유지하면서 MS Access 데이터베이스에서 SQL 서버로 모든 데이터를 이동하는 것입니다.MS Access 2007에서 MS SQL 서버로 ODBC 연결을위한 암호 저장

이제 데이터가 이동되고 SQL Server 사용자 (해당 데이터베이스에만 액세스하기 위해)가 만들어지고 테이블은 ODBC 연결을 통해 Access 데이터베이스에 연결됩니다. 그러나 Access 데이터베이스를 열 때 Access에서 정기적으로 사용자 암호를 묻습니다.

서버 PC 및 클라이언트 PC의 사용자가 모두 로컬 컴퓨터에 로그온합니다. 즉, 사용자가 독립 도메인 서버에서 확인되지 않았습니다. 나는이 해결하는 방법에는 여러 가지가 있습니다 참조

: 사용자가 로그온 할 수 있도록 자동으로 자신의 Windows 로그인에 의해 권한을 위임 받아

  • 1) 통합 보안 모델을 구성은 (즉, "신뢰할 수있는 연결을 사용 "). 서버 PC가 클라이언트 PC에서 사용자를 인식하지 못한다면 어떻게 할 수 있을지 확신하지 못합니다. 이 작업을 지금 시도하면 사용자가 신뢰할 수없는 도메인에서 연결하는 중 오류가 발생합니다.
  • 2) SQL Server 사용자 암호를 클라이언트 측에 저장하십시오. 나는 이것이 가능하다는 것을 확신하지 못한다. 일부 구성 파일에 암호를 유지하는 것을 알고 있거나 응용 프로그램 구성에 난독 화 된 보안을 낮추는 것으로 간주해야하지만이 설정은 주어진 설정에 적합합니다.
  • 3) 아마도 SQL Server 테이블을 Access로 연결하는 다른 방법이 있을까요?

답변

12

최상의 솔루션은 분명히 Windows 보안을 사용하는 것입니다.

이 적합하지 않은 경우, 여기에 가능한 대안 트릭는 프로그램이 종료 될 때까지 액세스가 열려있는 모든 연결을 기억하고 있다는 사실을 악용, 수 있습니다 :

  1. 은 테이블 중 하나의 연결 문자열을 복사
  2. passthru 쿼리 "ptqConnect"를 작성하고 그 안에 빠른 SQL 문을 입력하십시오 (예 : SELECT 1
  3. ). 연결 문자열을 PTQ Connect 특성에 붙여 넣은 다음 PWD=something;을 추가하십시오.
  4. 앱의 시작 절차에서 해당 PTQ를 호출해야합니다. DCount("*", "ptqConnect")과 같은 것입니다.

그게 전부입니다. Access는 닫을 때까지 열려있는 연결을 기억하므로 db를 닫더라도 연결된 테이블 연결 문자열에 암호가 저장되지 않은 경우에도 다른 테이블이 열리지 않습니다.
PWD가 포함 된 연결 문자열을 노출시키지 않으려면 VBA에서 연결을 시작하고 MDE를 제공하거나 코드를 보호하는 암호만으로 코드를 숨길 수 있습니다.

이 동작에 대한 설명은 here에서 찾을 수 있습니다.

+1

정말 최고의 솔루션입니다. 아름다움은 연결 문자열에 사용자 + 암호를 포함 할 필요조차 없다는 것입니다. 시작시 작은 로그온 상자에서 작은 패스를 실행하면 PRESTO- 모든 연결된 테이블이 작동합니다. 따라서 테이블을 다시 링크하지 않아도됩니다. 물론 DSN 적은 연결 및 일부 테이블 연결 코드가 필요합니다. 처음 연결하거나 테스트 서버와 프로덕션 서버간에 전환해야하는 경우 –

+0

3 단계를 추가해야합니다. 또한 응답에 UID 매개 변수도 제공해야합니다. . ODBC 연결 테이블은 UID와 PWD를 모두 저장하지 않으므로 VBA 코드로 제공해야합니다. 그렇지 않으면 SQL Server 로그인 대화 상자가 나타납니다. – Passiday

1

사용자에게 조직의 보안 정책이 암호 저장을 금지한다는 것을 알립니다. 따라서 데이터베이스를 열 때마다 암호를 제공해야합니다. 이 정책은 승인되지 않은 사용자가 권한이 부여 된 사용자의 컴퓨터에서 데이터베이스를 열 수 없음을 설명합니다. 암호가 어떤 식 으로든 저장 되었다면, 악의적 인 사람이 무인 기계에 앉아서 데이터베이스를 열 수 있습니다.

신뢰할 수있는 연결을 사용할 수 없기 때문에 가장 안전한 방법입니다. 예, 사용자는 데이터베이스를 열 때마다 암호를 제공해야하지만 데이터를 안전하게 유지하기 위해서는 암호가 필요합니다.

편집 : 옵션 # 2가 허용되므로 ODBC 연결 테이블의 연결 문자열에 uid와 pwd를 저장할 수 있습니다. 여기

내가 브라우저 디스플레이의 한 줄의 문자열을 분할 connectionstrings.com

Driver={SQL Server Native Client 10.0}; 
Server=myServerAddress; 
Database=myDataBase; 
Uid=myUsername;Pwd=myPassword; 

에서 복사 한 예입니다. 각 링크가 가리키는 테이블을 식별해야합니다. 현재 링크 연결 문자열을 검사하여 어떻게 수행되는지 확인하십시오.

uid와 pwd는 일반 텍스트이며 연결 속성을 볼 수있는 모든 사람이 볼 수 있습니다. 그러나 나는 당신에게 걱정되는 어떤 징후도 보지 못했습니다.

+0

그것은 좋은 조언이지만, 지금은 한 문자로 암호를 변경해야 할 것 같습니다. 그들은 중앙 도메인 서버를 설치하는 것이 다른 PC의 Access 응용 프로그램에서 SQL 서버 데이터를 바닐라로 사용하는 것을 너무 번거롭게하는 것처럼 느낍니다. 결국 나는 "안전하지 않은"SQL 서버 사용자의 권한을 완전히 제어 할 수 있으며 서버의 로컬 방화벽으로 연결을 제한 할 수 있다는 것에 동의하는 경향이 있습니다. – Passiday

+0

방화벽 문제가 제 머리 위로 치닫습니다. 방화벽이 Bob의 PC에서 SQL Server 로의 연결을 허용한다면 Bob이 Bob의 PC에 앉아있는 사람이라는 것을 어떻게 알 수 있습니까? Bob이 예기치 않게 호출되어 Windows 세션에서 로그 아웃하는 것을 잊었을 때 앉았던 그늘진 캐릭터가 아닙니다. 잠궈? – HansUp

+0

아니요, 원래 LAN에서 _another_ PC를 사용하여 그늘진 캐릭터에 대해 생각했다고 가정했습니다. 물론 당신이 언급 한 시나리오는 잠재적 위험 일 뿐이지 만 그늘진 캐릭터가 무인 사용자의 컴퓨터를 몰래 빠져 나왔을 때 심각한 문제가 발생했습니다. – Passiday

0

Access를 사용하여 원격으로 내 직장 SQL Server에 연결하는이 문제가 발생했습니다. 나는 Access 2013을 가지고 있지만, 2010 년부터 ODBC 연결처럼 기본 사항을 변경하지 않았다고 생각합니다. 신뢰할 수있는 연결이 아니기 때문에 연결할 때마다 서버에 로그인해야합니다. 데이터베이스 이것은 단지 기본 보안입니다. 왜 앱이 신뢰할 수없는 네트워크에서 연결을 원하지 않는지 생각할 수 없습니다.따라서 데이터베이스를 열 때 로그인해야합니다.

그러나, 내가 노력 매번, 내가 암호를 묻는 된 테이블를 열고, 그냥 한 번,하지만 두 번, 그리고 나는를 사용해야 할 것이 무엇 미친 날 운전이었다 생성시 무작위로 생성 된 13 자 암호! 그래서 말할 필요도없이 완전히 받아 들일 수없는 것이 었습니다.

액세스는 sys 테이블 MSysOBjects에 연결 정보를 유지하지만 최소한 암호는 저장하지 않습니다. 내 데스크톱과 동기화 된 클라우드 서버에 저장된 액세스 DB를 사용하므로 내 직장 데스크톱에 원격으로 연결하지 않고 로컬 복사본을 열 수 있습니다. 이 방법은 훨씬 빠릅니다.

그러나 Access에서 db를 로컬 파일로 사용한다는 것은 DSN 연결 이름을주의 깊게 살펴 봤음을 의미합니다. 모든 컴퓨터에서 이 절대적으로 동일하면 일뿐입니다. 따라서 ODBC32 Windows 도구에서 작업 할 때 내 DSN "ProductsDBIII"라는 이름을 지정하면 가정에서이 이름을 사용해야합니다. 실제 연결 문자열은 다르지만 Access는 그것에 대해 신경 쓰지 않습니다. 그러나 여기에 속임수가 있습니다. 예를 들어 직장에서 하루를 보낸 후 처음으로 DB를 집에서 가져온 경우 Access의 연결된 테이블 관리자에서 연결을 새로 고쳐야합니다. 필요한 테이블/뷰 또는 "모두 선택"을 선택하고 이동하십시오. Access는 아마도 로그인을 요구하는 연결을 만들고 MSysObjects 테이블의 "연결"문자열 필드를 신속하게 새로 고칩니다. 그 이유는 적어도 신뢰할 수있는 액세스에서 전환하는 경우에는 달라지기 때문입니다.

나는 테이블을 열 때마다 더 이상 단일 또는 이중 도전을하지 않습니다. 내가 원격 DB에서 테이블을 처음 열 때 처음 연결할 때 한 번 묻겠지만, 그게 전부입니다.

희망이 있으면 도움이됩니다.

0

ODBC 연결을 설정하기 위해 Passthrough QAuery를 다시 사용하십시오.

데이터베이스 옵션에서 시작 폼으로 인용 된 양식은 자동 실행하기 전에 실행됩니다. 양식에서 연결된 테이블을 인용 할 수 없거나 인용해서는 안됩니다. 또는 아무 것도 남겨 두지 마십시오. autoexec에 양식을 설정하십시오.

은 그렇지 않으면 당신은 여전히, 액세스 2010, ODBC 연결

일반적인 문제 시나리오는 연결된 데이터베이스 나는이 문제를 가지고있다

1

의 표와 스위치 보드 폼을 사용하기위한 PWD를 입력하라는 메시지가 표시됩니다 SQL Azure에 연결했지만 매우 간단했습니다. 테이블을 연결할 때 암호를 저장하기 위해 각 테이블에 체크 상자 옵션이 있습니다.

테이블을 다시 연결하고이 옵션을 선택하면 문제가 분류됩니다. 이 방법은 안전하지 않을 수도 있지만 모든 데이터베이스가 기밀 데이터를 포함하지는 않는다는 경고를 제공합니다.

+0

비밀번호 저장 체크 박스가 없습니다. 그리고 수동으로 연결 문자열 (TableDef.Connect = connectionString)을 업데이트하려고하면 pwd 설정을 무시하는 것 같습니다. – Hill