4

로그인 및 사용자와 혼동 스럽습니다. 기사에서 다음을 찾았습니다. "로그인"은 주 항목을 SERVER에 부여합니다. "사용자"는 단일 DATABASE에 로그인 항목을 부여합니다. 하나의 "로그인"은 많은 사용자 (데이터베이스 당 하나)와 연관 될 수 있습니다.SQL 서버 로그인 및 사용자

이론적으로는 이해할 수 있습니다. 그러나 나는 이것이 사실상 이해하지 못했을 것이라고 생각한다.

SQL Server 2008 관리 스튜디오에서 SERVERNAME => SECURITY => LOGIN을 마우스 오른쪽 버튼으로 클릭하여 로그인을 만들었습니다. 기본 데이터베이스는 "master"입니다. 이제이 로그인 이름과 암호로 SQL Server에 로그인 할 수 있습니다. 로그인 속성의 기본 데이터베이스를 특정 데이터베이스로 변경하면이 자격 증명으로 다시 로그인 할 수 없다는 것을 알게되었습니다. 나는 "주인"에게 되돌아 갔다. 여기 뭔 일 있었 니?

또한 사용자가 필요한 이유는 무엇입니까? DATABASENAME => SECURITY => USERS를 마우스 오른쪽 버튼으로 클릭하여 사용자를 생성했습니다. 이 사용자 자격 증명으로 다시 로그인 할 수 없습니다. 그래서, 우리가 이것을 위해 필요한 목적은 무엇입니까? 나는이 해답의 이론을 이해할 수 있지만 이해하기 위해서는 더 많은 설명이 필요하다.

또한 .net 개발자이기 때문에 SQL 연결 문자열에 제공된 자격 증명이 무엇인지 알고 싶습니다. 로그인 또는 사용자 또는 이들 중 하나 일 수 있습니까?

+0

이 문제에 도움이 되셨습니까? – sam113

답변

4

가장 간단한 설명은 SQL Server 로그인이 서버로 연결되고 해당 로그인의 설정이 각 데이터베이스에서 작동하는 방식을 제어한다는 것입니다.

잠시 동안 데이터베이스 로그인에 대해 걱정하지 마십시오. 이미 SERVERNAME => SECURITY => LOGIN에갔습니다. 이 로그인으로 무엇을하는지 보도록하겠습니다. 이미 로그인을 생성 한 경우 마우스 오른쪽 버튼을 클릭하고 속성으로 이동하십시오. 아래의 역할을보십시오 - 서버에는 용도가 다른 여러 가지가 있습니다. 그러나 앱의 경우 일반적으로 일반 사용자는 공개적 역할 만 가져야합니다.

데이터베이스 로그인에 관해서는 매핑 섹션으로 이동하여 액세스 할 필요가있는 데이터베이스를 로그인으로 지정하십시오. 로그인을 데이터베이스에 매핑하면 DATABASENAME => SECURITY => USERS에없는 데이터베이스 로그인이 생성됩니다. 매핑이 문자 그대로 로그인에 데이터베이스의 데이터를 볼 수있는 기능을 제공하는 가장 중요한 부분입니다.

응용 프로그램의 경우 서버 로그인을 사용하고 있습니다. 매핑에 필요한 데이터베이스에 대한 링크를 설정하면 실제로 데이터베이스 수준의 로그인 정보를 생각할 필요가 없습니다.

+0

Jerry에게 감사드립니다. 이것은 내가 훨씬 더 나아갈 수있게 도와주었습니다. 몇 가지 질문이 더 있습니다. 그러나 먼저 내가 더 깊이 이해 한 것을 설명하게하겠습니다. SERVERNAME => SECURITY =>를 마우스 오른쪽 단추로 클릭하면 내 서버 권한이 표시됩니다. UserMapping은 특정 사용자 이름으로 특정 데이터베이스에 매핑되었음을 보여줍니다. 따라서 궁극적으로 모든 사용자는 로그인에 매핑되어야합니다. 이제 DATABASENAME => SECURITY => USERS를 마우스 오른쪽 버튼으로 클릭하여 사용자를 다시 작성하고 "로그인 이름"필드를 이해했습니다. 이 필드는 새로 생성 된 사용자를 로그인에 매핑합니다. – sam113

+0

이제 동일한 로그인에 동일한 데이터베이스에 연결된 여러 사용자를 만들 수 있는지 알고 싶습니다. 나는 "로그인이 이미 다른 사용자 이름으로 된 계정을 가지고있다"라는 오류를 시도했다. Ok, 나는 그 오류를 이해한다. 그러나 로그인과 사용자간에 일대일 매핑 만 허용되는 경우 이러한 로그인과 사용자가 필요한 이유는 무엇입니까? 왜 로그인만으로는 목적을 달성하지 못합니까? – sam113

+0

짧은 버전은 서버마다 고유 한 로그인 이름을 하나만 작성한 다음 필요한 데이터베이스에 매핑해야한다는 것입니다. 어쩌면 이유가 있지만 데이터베이스 로그인 목록에 갈 필요가 전혀 없습니다. 연결로 간주하고 변경할 필요가 없습니다. –

1

로그인은 서버 수준에서만 존재하므로 마스터 데이터베이스에 자동으로 매핑됩니다.

사용자는 개별 데이터베이스에 대한 액세스를 제어합니다. 사용자를 만들 때 로그인에 매핑 할 수 있습니다 (구문은 Create User on MSDN 참조).

이 작업을 수행하는 한 가지 이유는 단일 서버가 모든 사람이 아닌 많은 데이터베이스를 호스트하는 멀티 테넌트 환경을 허용하기 위해서입니다. 누가 액세스 할 수 있어야 서버에 액세스 할 수 있습니다. 예를 들어 A 사와 B 사에 서비스를 제공하고 동일한 서버에 각각 데이터베이스를 호스팅한다고 가정 해 봅시다. 회사 A의 직원 (또는 중요한 것은 회사 A의 직원의 자격 증명을 손상시킨 사람)이 회사 B의 데이터에 액세스 할 수 없기 때문에 회사 A의 로그인 사용자 만 만들 수 있습니다. 회사 A 데이터베이스.당신은 별도의 분리 된 보안/권한 설정이 필요하고 이러한 세트 중 하나 이상을 가지고 한 사용자가 필요한 경우

-- This script assumes whoever is running it has sysadmin permissions on the instance of 
-- SQL Server on which it is running. Do not run this on a production instance. 

-- Create a database for each company on the server instance. 
create database CompanyA; 
create database CompanyB; 
go 

-- Create a login for each company on the server instance. 
-- SQL Server integrated security has it's issues, but it's useful for an example like this. 
create login CompanyA_Login with password = 'pa55wOrd1', default_database = CompanyA; 
create login CompanyB_Login with password = 'pa55wOrd2', default_database = CompanyB; 
go 

-- Create a user in the appropriate database for each login. 
-- We need to tell the server that we want to use a specific database 
use CompanyA; 
create user CompanyA_User for login CompanyA_Login; 
-- We're granting it dbo for the purposes of our example here; 
-- a broad permission set like that is a bad practice. 
alter role db_owner add member CompanyA_User; 
go 

-- Repeat the process... 
use CompanyB; 
create user CompanyB_User for login CompanyB_Login; 
alter role db_owner add member CompanyB_User; 
go 

-- Create a table in each database and populate it with some data. 
use CompanyA; 
create table dbo.sensitiveInformation 
(
    sensitiveInformation NVARCHAR(50) NOT NULL 
); 

insert dbo.sensitiveInformation (sensitiveInformation) 
values ('Oh man, it would be bad if this got out!'); 
go 

use CompanyB; 
create table dbo.sensitiveInformation 
(
    sensitiveInformation NVARCHAR(50) NOT NULL 
); 

insert dbo.sensitiveInformation (sensitiveInformation) 
values ('Oh man, it would be even worse if THIS got out!'); 
go 

-- Now, feel free to log in as either user and see what you can and can't do. 
-- You will find that the CompanyA_Login will never be able to access CompanyB's 
-- data and vice versa. This allows for secure multi-tenant environments. 

-- Once you're done playing around, we'll clean up our samples. 
use CompanyB; 
drop table dbo.sensitiveInformation; 
drop user CompanyB_User; 
go 

use CompanyA; 
drop table dbo.sensitiveInformation; 
drop user CompanyA_User; 
go 

use master; 
drop login CompanyB_Login; 
drop login CompanyA_Login; 

drop database CompanyB; 
drop database CompanyA; 

, 당신은 데이터베이스 역할을 사용하려면 : 당신이 실험을 위해 여기에서 간단한 코드를 설정합니다. Tech Republic에서 제공하는 This article은 역할의 장점에 대해 잘 설명합니다. 그러나 MSDN에서 가장 최신의 방법을 확인하는 것이 좋습니다.