SQL Server 2005 기반의 데이터베이스 자습서가 있기 때문에 여기에 사용된 샘플 데이터베이스는 SQL Server 2005용 AdventureWorks이고 내 컴퓨터에는 SQL Server 2008이 설치되어 있으며 샘플 데이터베이스는 SQL Server 2008용 AdventureWorks입니다. 처음에는 SQL Server 2005용 AdventureWorks와 SQL Server 2008용 AdventureWorks의 데이터베이스 구조가 유사해야 한다고 생각했습니다. 그러나 연습 중에 두 데이터베이스의 많은 테이블 구조가 여전히 매우 다르다는 것을 발견했습니다. . 그래서 원활한 연습을 위해 Microsoft 다운로드 센터에서 SQL Server 2005용 샘플 데이터베이스 AdventureWorks를 다운로드하여 SQL Server 2008에 연결하기로 결정했습니다. SQL Server 2008의 최고 관리자 계정 "sa"를 사용하여 SQLSERVER2008 인스턴스에 로그인했습니다.
SQL Server 2005용 샘플 데이터베이스 AdventureWorks를 연결하면 다음 그림이 나타납니다. up 오류:
"물리적 파일을 열거나 생성하는 동안 CREATE FILE에서 운영 체제 오류 5(액세스 거부)가 발생했습니다.."라는 기본 메시지를 자세히 살펴보았습니다. .)'을 보면 첨부할 데이터 파일에 대한 작업 권한이 부족하다는 것을 한눈에 알 수 있습니다. 일반적인 사고 습관에 따라 작업 권한이 부족한 파일에는 충분한 작업 권한을 부여합니다. 예를 들어 일부 네티즌들은 “첨부할 데이터 파일과 해당 로그 파일에 대한 권한을 모두에게 부여하라”고 주장했다. 인증 과정은 다음 3개의 스크린샷에 나와 있다(데이터 파일과 로그 파일 모두 인증이 필요하다는 점 참고). 🎜>
(사진 1: 인증된 데이터 파일) (사진 2: 데이터 파일 인증 후) (그림 3: 로그 파일 인증 후) 모든 사람에게 데이터 파일과 로그 파일에 대한 [읽기 및 실행] 및 [읽기] 권한 부여 권한을 얻은 후 SQL Server 2008에서 다시 데이터베이스 연결을 시도했는데 연결에 성공했습니다! 이대로 문제가 해결되나요? 이것이 옳은 일입니까? “실제 데이터베이스 관리 과정에서 데이터 파일과 로그 파일의 권한을 모두에게 확대한다면 이는 확실히 잘못된 일입니다. 모든 사람에게 [읽기 및 실행] 및 [읽기] 권한만 부여하더라도 데이터베이스의 보안이 크게 손상될 수 있으므로 여전히 데이터 유출 위험이 있습니다. 정상적인 접근 조건에서는 데이터 파일이 최소한의 접근 권한을 갖도록 보장해야 합니다. 이전에는 모든 사용자에게 권한을 부여했기 때문에 모든 사용자 또는 계정이 해당 파일을 작동할 수 있으므로 절대 안전하지 않습니다. 그렇다면 최소한의 액세스 권한을 어떻게 부여할 수 있나요? 생각해 보십시오. 우리는 SQL Server 2008을 사용하여 해당 데이터 파일을 첨부하고 "액세스 거부" 오류를 보고합니다. 즉, 현재 SQL Server 2008에는 이러한 파일에 액세스할 수 있는 권한이 없습니다. 아래 그림과 같이 파일을 마우스 오른쪽 버튼으로 클릭하고 파일 속성으로 이동하여 파일의 권한을 확인합니다. (해당 데이터의 원래 권한 파일) 두 그룹 또는 사용자 SYSTEM과 xrm만이 이 데이터 파일을 조작할 수 있는 권한을 가지고 있는 것으로 확인되었습니다. SYSTEM은 사용자 그룹, 즉 [Local System] 그룹이고 xrm은 그림과 같이 관리자 사용자입니다. (xrm 사용자 정보) SYSTEM 사용자 그룹과 관리자 사용자 xrm은 이 데이터 파일과 로그 파일을 조작할 수 있는 권한을 가지고 있습니다. 그러나 SQL Server 2008의 슈퍼 관리자 SA 연결로 인스턴스에 로그인한 후에는 SQL Server에는 이 데이터 파일에 액세스할 수 있는 권한이 없습니다. 즉, SQL Server 2008 최고 관리자 SA 연결을 사용하여 인스턴스에 로그인한 후 로그인한 ID는 SYSTEM 사용자 그룹에도 없고 관리자 xrm도 아닙니다. 그게 무엇일까요?SQL Server 2008의 현재 인스턴스 서비스 관련 정보를 보면 알 수 있다. SQL Server 구성 관리자(SQL Server Configuration Manager)를 열어서 현재 연결되어 있는 인스턴스 서비스 관련 정보를 확인하면 다음과 같다. 그림:
(현재 인스턴스 서비스 관련 정보)
현재 인스턴스의 로그인 ID가 SQLSERVER2008인 것으로 확인되었습니다. "NT AUTHORITYLocalService" 즉, 시스템에서 승인한 [Local Service] 작업인 경우 로컬 서비스도 사용자 그룹입니다. 즉, [Local Service] 사용자 그룹(Everyone 대신)에게만 권한을 부여한다면 SQL Server 2008에서 sa 계정을 사용하여 데이터베이스를 연결할 수 있어야 합니다. 이를 위해 방금 해당 데이터 파일 및 로그 파일에 부여한 권한을 모두 삭제한 후 해당 데이터 파일 및 로그 파일에 대한 권한을 LocalService 사용자 그룹에 부여한 후 해당 데이터베이스를 다시 연결을 시도하여 첨부 파일이 있는지 찾아보십시오. 정말 성공할 수 있어요! 말할 필요도 없이 [로컬 서비스] 사용자 그룹에 운영 체제 권한을 부여하는 것이 모든 사람에게 부여하는 것보다 확실히 훨씬 안전합니다.
위에서 언급한 방법으로 데이터 파일의 원래 권한 범위를 변경했습니다(원래 권한 범위는 SYSTEM, [로컬 시스템] 사용자 그룹 및 xrm 시스템 관리자만 해당). 더 좋은 방법은 데이터 파일의 권한 범위를 변경하지 않는 것입니다. 여전히 연결되어 있고 SA로 로그인되어 있는 SQL Server 2008 인스턴스도 해당 데이터 파일에 액세스할 수 있습니다. 이 목표를 달성하려면 해당 인스턴스의 로그인 ID를 SYSTEM [로컬 시스템] 사용자 그룹으로 변경하기만 하면 됩니다. SYSTEM도 해당 데이터 파일의 권한 내 사용자 그룹이며 SQL Server 인스턴스는 다음과 같이 실행됩니다. 로컬 시스템의 보안이 강화됩니다. 다음 그림과 같이 SQL Server 구성 관리자에서 해당 SQL Server 인스턴스의 로그인 ID를 [로컬 시스템]으로 변경할 수 있습니다.
( 로그인 수정 인스턴스의 ID)
(인스턴스의 로그인 ID는 LocalSystem이 됩니다.)
그런 다음 해당 인스턴스 서비스를 다시 시작하고 다시 시작합니다. - SA ID 연결을 사용하여 해당 SQL Server 2008 인스턴스에 로그인하고 데이터베이스 연결을 시도하면 데이터베이스도 성공적으로 연결할 수 있습니다. ! !
실제로 해당 데이터베이스를 연결하기 위해 해당 SQL Server 2008 인스턴스에 SA로 특별히 로그인할 필요가 없다면 해당 인스턴스에 연결할 때 SQL Server 2008의 경우 인증을 위해 [Windows 인증]을 선택하면 위에서 설명한 대로 별도의 수정 없이 데이터베이스를 연결할 수 있습니다. 그 이유는 [Windows 인증]은 현재 운영 체제의 사용자 권한을 사용하기 때문입니다. 일반적으로 충분합니다. 또한, [SQL Server 구성 관리자]에서 인스턴스 서버에서 할 수 있는 작업을 Windows [서비스]
SQL Server에 연결된 데이터베이스의 오류 5123에 대한 올바른 해결 방법에 대한 관련 기사를 더 보려면 PHP 중국어 웹사이트를 주목하세요!