포함된 데이터베이스를 사용하는 보안 모범 사례
적용 대상:
SQL ServerAzure SQL Managed Instance
포함된 데이터베이스에는 SQL Server 데이터베이스 엔진 관리자가 이해하고 완화해야 하는 몇 가지 고유한 위협이 있습니다. 대부분의 위협은 데이터베이스 엔진 수준에서 데이터베이스 수준으로 인증 경계를 이동하는 USER WITH PASSWORD 인증 프로세스와 관련이 있습니다.
사용자와 관련된 위협
db_owner 멤버 및 db_accessadmin 고정 데이터베이스 역할과같은 ALTER ANY USER 권한이 있는 포함된 데이터베이스의 사용자는 지식이나 사용 권한 또는 SQL Server 관리자 없이 데이터베이스에 대한 액세스 권한을 부여할 수 있습니다. 포함된 데이터베이스에 대한 액세스 권한을 사용자에게 부여하면 전체 SQL Server 인스턴스에 대한 잠재적인 공격 노출 영역이 증가합니다. 관리자는 이 액세스 제어 위임을 이해하고 포함된 데이터베이스 의 사용자에게 ALTER ANY USER 권한을 부여하는 데 매우 주의해야 합니다. 모든 데이터베이스 소유자에게 ALTER ANY USER 권한이 있습니다. SQL Server 관리자는 포함된 데이터베이스의 사용자를 주기적으로 감사해야 합니다.
게스트 계정을 사용하여 다른 데이터베이스 액세스
ALTER ANY USER 권한이 있는 데이터베이스 소유자 및 데이터베이스 사용자는 포함된 데이터베이스 사용자를 만들 수 있습니다. SQL Server 인스턴스의 포함된 데이터베이스에 연결한 후 포함된 데이터베이스 사용자는 다른 데이터베이스가 게스트 계정을 사용하도록 설정한 경우 데이터베이스 엔진의 다른 데이터베이스에 액세스할 수 있습니다.
다른 데이터베이스에서 중복 사용자 만들기
일부 애플리케이션에서는 사용자가 둘 이상의 데이터베이스에 액세스해야 할 수 있습니다. 이 작업은 각 데이터베이스에 동일한 포함된 데이터베이스 사용자를 만들어 수행할 수 있습니다. 암호로 두 번째 사용자를 만들 때 SID 옵션을 사용합니다. 다음 예제에서는 두 개의 데이터베이스에 동일한 두 사용자를 만듭니다.
USE DB1;
GO
CREATE USER Carlo WITH PASSWORD = '<strong password>';
-- Return the SID of the user
SELECT SID FROM sys.database_principals WHERE name = 'Carlo';
-- Change to the second database
USE DB2;
GO
CREATE USER Carlo WITH PASSWORD = '<same password>', SID = <SID from DB1>;
GO
데이터베이스 간 쿼리를 실행하려면 호출하는 데이터베이스에서 TRUSTWORTHY 옵션을 설정해야 합니다. 예를 들어 위에서 정의한 사용자(Carlo)가 DB1에 있는 경우 실행 SELECT * FROM db2.dbo.Table1;하려면 데이터베이스 DB1에 대해 TRUSTWORTHY 설정이 설정되어야 합니다. 다음 코드를 실행하여 TRUSTWORTHY 설정을 설정합니다.
ALTER DATABASE DB1 SET TRUSTWORTHY ON;
로그인을 복제하는 사용자 만들기
SQL Server 로그인과 동일한 이름을 사용하여 암호가 포함된 데이터베이스 사용자를 만들고 SQL Server 로그인이 포함된 데이터베이스를 초기 카탈로그로 지정하여 연결하는 경우 SQL Server 로그인을 연결할 수 없습니다. 연결은 SQL Server 로그인을 기반으로 하는 사용자 대신 포함된 데이터베이스에 암호 주체가 있는 포함된 데이터베이스 사용자로 평가됩니다. 이로 인해 SQL Server 로그인에 대한 의도적이거나 우발적인 서비스 거부가 발생할 수 있습니다.
sysadmin 고정 서버 역할의 멤버는 초기 카탈로그 옵션을 사용하지 않고 항상 연결을 고려하는 것이 가장 좋습니다. 이렇게 하면 로그인이 master 데이터베이스에 연결되고 데이터베이스 소유자가 로그인 시도를 오용하려는 시도를 방지할 수 있습니다. 그런 다음, 관리자는 USE<데이터베이스 문을 사용하여 포함된 데이터베이스>로 변경할 수 있습니다. 로그인의 기본 데이터베이스를 포함된 데이터베이스로 설정하여 로그인을 마스터로 완료한 다음, 포함된 데이터베이스로 로그인을 전송할 수도 있습니다.
SQL Server 로그인과 이름이 같은 암호를 가진 포함된 데이터베이스 사용자를 만드는 것이 가장 좋습니다.
중복 로그인이 있는 경우 초기 카탈로그를 지정하지 않고 master 데이터베이스에 연결한 다음 USE 명령을 실행하여 포함된 데이터베이스로 변경합니다.
포함된 데이터베이스가 있는 경우 데이터베이스가 포함되지 않은 데이터베이스 사용자는 초기 카탈로그를 사용하거나 포함되지 않은 데이터베이스의 데이터베이스 이름을 초기 카탈로그로 지정하지 않고 데이터베이스 엔진에 연결해야 합니다. 이렇게 하면 데이터베이스 엔진 관리자가 직접 제어하지 않는 포함된 데이터베이스에 연결할 수 없습니다.
데이터베이스의 포함 상태를 변경하여 액세스 증가
dbcreator 고정 서버 역할의 멤버와 같은 ALTER ANY DATABASE 권한이 있는 로그인과 control DATABASE 권한이 없는 데이터베이스의 사용자(예: db_owner 고정 데이터베이스 역할의 멤버)는 데이터베이스의 포함 설정을 변경할 수 있습니다. 데이터베이스의 포함 설정이 NONE에서 PARTIAL 또는 FULL로 변경된 경우 암호가 포함된 데이터베이스 사용자를 만들어 사용자 액세스 권한을 부여할 수 있습니다. 이렇게 하면 SQL Server 관리자의 지식이나 동의 없이 액세스할 수 있습니다. 데이터베이스가 포함되지 않도록 하려면 데이터베이스 엔진에 포함된 데이터베이스 인증 옵션을 0으로 설정합니다. 선택한 포함된 데이터베이스에서 암호가 있는 포함된 데이터베이스 사용자의 연결을 방지하려면 로그인 트리거를 사용하여 암호가 포함된 데이터베이스 사용자의 로그인 시도를 취소합니다.
포함된 데이터베이스 연결
포함된 데이터베이스를 연결하면 관리자가 원치 않는 사용자에게 데이터베이스 엔진 인스턴스에 대한 액세스 권한을 부여할 수 있습니다. 이 위험에 대해 우려하는 관리자는 RESTRICTED_USER 모드에서 데이터베이스를 온라인 상태로 전환하여 암호가 포함된 데이터베이스 사용자에 대한 인증을 방지할 수 있습니다. 로그인을 통해 권한이 부여된 보안 주체만 데이터베이스 엔진에 액세스할 수 있습니다.
사용자는 사용자가 생성될 때 적용되는 암호 요구 사항을 사용하여 만들어지고 데이터베이스가 연결될 때 암호를 다시 검사하지 않습니다. 더 엄격한 암호 정책을 사용하여 시스템에 취약한 암호를 허용하는 포함된 데이터베이스를 연결하면 관리자가 데이터베이스 엔진 연결에서 현재 암호 정책을 충족하지 않는 암호를 허용할 수 있습니다. 관리자는 연결된 데이터베이스에 대해 모든 암호를 재설정하도록 요구하여 취약한 암호를 유지하지 않도록 할 수 있습니다.
암호 정책
데이터베이스의 암호는 강력한 암호여야 할 수 있지만 강력한 암호 정책으로 보호할 수는 없습니다. Windows에서 사용할 수 있는 보다 광범위한 암호 정책을 활용하려면 가능하면 언제든지 Windows 인증을 사용합니다.
Kerberos 인증
암호가 포함된 데이터베이스 사용자는 Kerberos 인증을 사용할 수 없습니다. 가능하면 Windows 인증을 사용하여 Kerberos와 같은 Windows 기능을 활용합니다.
오프라인 사전 공격
암호가 있는 포함된 데이터베이스 사용자의 암호 해시는 포함된 데이터베이스에 저장됩니다. 데이터베이스 파일에 대한 액세스 권한이 있는 사용자는 누구나 감사되지 않는 시스템에서 암호가 있는 포함된 데이터베이스 사용자에 대해 사전 공격을 수행할 수 있습니다. 이 위협을 완화하려면 데이터베이스 파일에 대한 액세스를 제한하거나 Windows 인증을 사용하여 포함된 데이터베이스에 대한 연결만 허용합니다.
포함된 데이터베이스 이스케이프
데이터베이스가 부분적으로 포함된 경우 SQL Server 관리자는 포함된 데이터베이스에 있는 사용자 및 모듈의 기능을 주기적으로 감사해야 합니다.
AUTO_CLOSE 통한 서비스 거부
포함된 데이터베이스를 자동으로 닫도록 구성하지 마세요. 닫힌 경우 사용자를 인증하기 위해 데이터베이스를 열면 추가 리소스가 사용되며 서비스 거부 공격에 기여할 수 있습니다.
참고 항목
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기