적용 대상:SQL Server on Linux
SQL Server를 처음 사용하는 Linux 사용자인 경우 다음 작업에서 몇 가지 보안 작업을 안내합니다. 이 보안 작업은 Linux에 고유하거나 특정하지 않으며 추가로 조사할 영역에 대한 아이디어를 제공하는 데 도움이 됩니다. 각 예제에서는 해당 영역의 심층 설명서에 대한 링크가 제공됩니다.
이 문서의 코드 샘플은 AdventureWorks2025 또는 AdventureWorksDW2025 샘플 데이터베이스를 사용합니다. 이 데이터베이스는 Microsoft SQL Server 샘플 및 커뮤니티 프로젝트 홈페이지에서 다운로드할 수 있습니다.
로그인 및 데이터베이스 사용자 만들기
master 문을 통해 데이터베이스에 로그인을 만들어 SQL Server에 대한 액세스 권한을 다른 사용자에게 부여합니다. 예시:
CREATE LOGIN Larry
WITH PASSWORD = '<password>';
주의
암호는 SQL Server 기본 암호 정책을 따라야 합니다. 기본적으로 암호는 8자 이상이어야 하며 대문자, 소문자, 0~9까지의 숫자 및 기호 네 가지 집합 중 세 집합의 문자를 포함해야 합니다. 암호 길이는 128자까지 가능하며 되도록 길고 복잡한 암호를 사용합니다.
로그인은 SQL Server에 연결하고 master 데이터베이스에 대한 액세스 권한(제한된 권한 포함)을 가질 수 있습니다. 사용자 데이터베이스에 연결하려면 데이터베이스 사용자라고도 하는 데이터베이스 수준의 해당 ID가 로그인에 필요합니다. 사용자가 각 데이터베이스에 한정되며 액세스 권한을 부여하려면 각 데이터베이스에서 별도로 만들어야 합니다. 다음 예제에서는 AdventureWorks2025 데이터베이스로 이동한 다음, CREATE USER 문을 사용하여 Larry라는 로그인과 연결된 Larry라는 사용자를 만듭니다. 로그인과 사용자가 서로 연결되어 있지만(서로 매핑됨) 서로 다른 개체입니다. 로그인은 서버 수준 보안 주체입니다. 사용자는 데이터베이스 수준 보안 주체입니다.
USE AdventureWorks2022;
GO
CREATE USER Larry;
GO
- SQL Server 관리자 계정은 모든 데이터베이스에 연결할 수 있으며 모든 데이터베이스에서 추가 로그인과 사용자를 만들 수 있습니다.
- 누군가 데이터베이스를 만들면 해당 데이터베이스에 연결할 수 있는 데이터베이스 소유자가 됩니다. 데이터베이스 소유자는 더 많은 사용자를 만들 수 있습니다.
나중에 다른 로그인에 ALTER ANY LOGIN 권한을 부여하여 추가 로그인을 만들 권한을 부여할 수 있습니다. 데이터베이스 내에서 다른 사용자에게 ALTER ANY USER 권한을 부여하여 추가 사용자를 만들 권한을 부여할 수 있습니다. 예시:
GRANT ALTER ANY LOGIN TO Larry;
GO
USE AdventureWorks2022;
GO
GRANT ALTER ANY USER TO Jerry;
GO
이제 로그인 Larry는 더 많은 로그인을 만들 수 있으며 사용자 Jerry는 더 많은 사용자를 만들 수 있습니다.
최소 권한으로 액세스 권한 부여
사용자 데이터베이스에 가장 먼저 연결하는 사람은 관리자 및 데이터베이스 소유자 계정입니다. 그러나 이러한 사용자에게는 데이터베이스에서 사용할 수 있는 모든 권한이 있습니다. 이는 대부분의 사용자에게 부여해야 하는 것보다 더 많은 권한입니다.
이제 막 시작하는 경우 기본 제공 고정 데이터베이스 역할을 사용하여 몇 가지 일반적인 범주의 권한을 할당할 수 있습니다. 예를 들어 db_datareader 고정 데이터베이스 역할은 데이터베이스의 모든 테이블을 읽을 수 있지만 변경할 수는 않습니다.
ALTER ROLE 문을 사용하여 고정 데이터베이스 역할의 멤버 자격을 부여합니다. 다음 예제에서는 Jerry 고정 데이터베이스 역할에 사용자 를 추가합니다.
USE AdventureWorks2022;
GO
ALTER ROLE db_datareader ADD MEMBER Jerry;
고정 데이터베이스 역할 목록은 데이터베이스 수준 역할을 참조 하세요.
나중에 데이터에 대한 보다 정확한 액세스를 구성할 준비가 되면(권장됨) CREATE ROLE 문을 사용하여 사용자 정의 데이터베이스 역할을 만듭니다. 그런 다음 사용자 지정 역할에 특정 세분화된 권한을 할당합니다.
예를 들어 다음 문은 Sales 이름이 지정된 데이터베이스 역할을 만들고, Sales 그룹에 Orders 테이블에서 행을 보고, 업데이트하고, 삭제할 수 있는 기능을 부여한 다음, 사용자 Jerry를 Sales 역할에 추가합니다.
CREATE ROLE Sales;
GRANT SELECT ON OBJECT::Sales TO Orders;
GRANT UPDATE ON OBJECT::Sales TO Orders;
GRANT DELETE ON OBJECT::Sales TO Orders;
ALTER ROLE Sales ADD MEMBER Jerry;
권한 시스템에 대한 자세한 내용은 데이터베이스 엔진 권한 시작
행 수준 보안 구성
행 수준 보안을 사용하면 쿼리를 실행하는 사용자에 따라 데이터베이스의 행에 대한 액세스를 제한할 수 있습니다. 이 기능은 고객이 자신의 데이터에만 액세스할 수 있도록 하거나 작업자가 해당 부서와 관련된 데이터에만 액세스할 수 있도록 하는 시나리오에 유용합니다.
다음 단계에서는 Sales.SalesOrderHeader 테이블에 대한 서로 다른 행 수준 액세스 권한이 있는 두 사용자를 설정하는 방법을 안내합니다.
행 수준 보안을 테스트할 사용자 계정을 두 개 만듭니다.
USE AdventureWorks2022;
GO
CREATE USER Manager WITHOUT LOGIN;
CREATE USER SalesPerson280 WITHOUT LOGIN;
두 사용자에게 Sales.SalesOrderHeader 테이블에 대한 읽기 권한을 부여합니다.
GRANT SELECT ON Sales.SalesOrderHeader TO Manager;
GRANT SELECT ON Sales.SalesOrderHeader TO SalesPerson280;
새 스키마 및 인라인 테이블 반환 함수를 만듭니다. 이 함수는 SalesPersonID 열의 행이 SalesPerson 로그인 ID와 일치하거나 쿼리를 실행하는 사용자가 Manager 사용자인 경우 1을 반환합니다.
CREATE SCHEMA Security;
GO
CREATE FUNCTION Security.fn_securitypredicate
(@SalesPersonID INT)
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN
SELECT 1 AS fn_securitypredicate_result
WHERE ('SalesPerson' + CAST (@SalesPersonId AS VARCHAR (16)) = USER_NAME())
OR (USER_NAME() = 'Manager')
테이블에서 필터 및 차단 조건자로 이 함수를 추가하는 보안 정책을 만듭니다.
CREATE SECURITY POLICY SalesFilter
ADD FILTER PREDICATE Security.fn_securitypredicate(SalesPersonID) ON Sales.SalesOrderHeader,
ADD BLOCK PREDICATE Security.fn_securitypredicate(SalesPersonID) ON Sales.SalesOrderHeader
WITH (STATE = ON);
다음을 실행하여 SalesOrderHeader 테이블을 각 사용자로 쿼리합니다.
SalesPerson280은(는) 자체 판매에서 95개 행만 표시되고 Manager은(는) 테이블의 모든 행을 볼 수 있는지 확인합니다.
EXECUTE AS USER = 'SalesPerson280';
SELECT *
FROM Sales.SalesOrderHeader;
REVERT;
EXECUTE AS USER = 'Manager';
SELECT *
FROM Sales.SalesOrderHeader;
REVERT;
정책을 사용하지 않도록 보안 정책을 변경합니다. 이제 두 사용자가 모두 모든 행에 액세스할 수 있습니다.
ALTER SECURITY POLICY SalesFilter
WITH (STATE = OFF);
동적 데이터 마스킹 사용
동적 데이터 마스킹을 사용하면 특정 열을 완전히 또는 부분적으로 마스킹 하여 애플리케이션 사용자에게 중요한 데이터의 노출을 제한할 수 있습니다.
ALTER TABLE 문을 사용하여 EmailAddress 테이블의 Person.EmailAddress 열에 마스킹 함수를 추가합니다.
USE AdventureWorks2022;
GO
ALTER TABLE Person.EmailAddress
ALTER COLUMN EmailAddress
ADD MASKED WITH (FUNCTION = 'email()');
테이블에 대한 TestUser 권한이 있는 새 사용자 SELECT를 만든 다음, TestUser로 쿼리를 실행하여 마스킹된 데이터를 확인합니다.
CREATE USER TestUser WITHOUT LOGIN;
GRANT SELECT
ON Person.EmailAddress TO TestUser;
EXECUTE AS USER = 'TestUser';
SELECT EmailAddressID,
EmailAddress
FROM Person.EmailAddress;
REVERT;
마스킹 함수가 첫 번째 레코드의 전자 메일 주소를 다음과 같이 변경하는지 확인합니다.
| EmailAddressID | EmailAddress |
|---|---|
| 1 | ken0@adventure-works.com |
into
| EmailAddressID | EmailAddress |
|---|---|
| 1 | kXXX@XXXX.com |
투명한 데이터 암호화 사용
데이터베이스에 대한 한 가지 위협은 누군가가 하드 드라이브에서 데이터베이스 파일을 도용할 위험이 있다는 것입니다. 이 문제는 문제가 있는 직원의 작업이나 파일이 포함된 컴퓨터(예: 랩톱)를 도용하여 시스템에 대한 높은 액세스 권한을 얻는 침입으로 인해 발생할 수 있습니다.
TDE(투명한 데이터 암호화)는 하드 드라이브에 저장되어 있는 데이터 파일을 암호화합니다. SQL Server 데이터베이스 엔진의 master 데이터베이스에는 암호화 키가 있으므로 데이터베이스 엔진이 데이터를 조작할 수 있습니다. 키에 액세스하지 않고는 데이터베이스 파일을 읽을 수 없습니다. 상위 수준의 관리자는 키를 관리, 백업 및 다시 만들 수 있으므로 데이터베이스를 이동할 수 있지만 선택한 사용자만 데이터베이스를 이동할 수 있습니다. TDE를 구성하면 tempdb 데이터베이스도 자동으로 암호화됩니다.
데이터베이스 엔진은 데이터를 읽을 수 있으므로 TDE는 메모리를 직접 읽거나 관리자 계정을 통해 SQL Server에 액세스할 수 있는 컴퓨터 관리자의 무단 액세스로부터 보호하지 않습니다.
TDE 구성
- 마스터 키 만들기
- 마스터 키로 보호되는 인증서 만들기 또는 획득
- 데이터베이스 암호화 키 만들기 및 인증서로 보호
- 암호화를 사용하도록 데이터베이스 설정
TDE를 구성하려면 CONTROL 데이터베이스에 대한 master 권한과 사용자 데이터베이스에 대한 CONTROL 권한이 필요합니다. 일반적으로 관리자가 TDE를 구성합니다.
다음 예제에서는 AdventureWorks2025 이름이 지정된 서버에 설치된 인증서를 사용하여 MyServerCert 데이터베이스를 암호화하고 암호 해독하는 방법을 보여줍니다.
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<master-key-password>';
GO
CREATE CERTIFICATE MyServerCert
WITH SUBJECT = 'My Database Encryption Key Certificate';
GO
USE AdventureWorks2022;
GO
CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE MyServerCert;
GO
ALTER DATABASE AdventureWorks2022
SET ENCRYPTION ON;
TDE를 제거하려면 다음 명령을 실행합니다.
ALTER DATABASE AdventureWorks2022
SET ENCRYPTION OFF;
암호화 및 암호 해독 작업은 SQL Server에 의해 백그라운드 스레드로 예약됩니다. 이러한 작업의 상태를 보려면 이 문서의 뒷부분에 나오는 목록의 카탈로그 뷰 및 동적 관리 뷰를 사용합니다.
Warning
TDE를 사용하도록 설정된 데이터베이스의 백업 파일도 데이터베이스 암호화 키를 사용하여 암호화됩니다. 따라서 이러한 백업 파일을 복원하려면 데이터베이스 암호화 키를 보호하는 인증서를 사용할 수 있어야 합니다. 즉, 데이터베이스 백업뿐만 아니라 데이터 손실을 방지하기 위해 서버 인증서의 백업도 유지 관리해야 합니다. 인증서를 더 이상 사용할 수 없는 경우 데이터가 손실됩니다. 자세한 내용은 SQL Server Certificates and Asymmetric Keys을 참조하세요.
TDE에 대한 자세한 내용은 TDE(투명한 데이터 암호화)를 참조하세요.
백업 암호화 구성
SQL Server에는 백업을 만드는 동안 데이터를 암호화하는 기능이 있습니다. 암호화 알고리즘 및 암호기(인증서 또는 비대칭 키)를 지정하여 백업을 생성할 때 암호화된 백업 파일을 만들 수 있습니다.
Warning
항상 인증서 또는 비대칭 키를 백업하고, 암호화에 사용된 백업 파일과 다른 위치에 백업하는 것이 좋습니다. 인증서 또는 비대칭 키가 없으면 백업을 복원할 수 없으므로 백업 파일을 사용할 수 없게 됩니다.
다음 예제에서는 인증서를 만든 후 인증서로 보호되는 백업을 만듭니다.
USE master;
GO
CREATE CERTIFICATE BackupEncryptCert
WITH SUBJECT = 'Database backups';
GO
BACKUP DATABASE [AdventureWorks2022]
TO DISK = N'/var/opt/mssql/backups/AdventureWorks2022.bak'
WITH COMPRESSION,
ENCRYPTION (ALGORITHM = AES_256, SERVER CERTIFICATE = BackupEncryptCert),
STATS = 10;
GO
자세한 내용은 Backup 암호화를 참조 하세요.