SQL Server on Linux의 보안 기능에 대한 연습

적용 대상:SQL Server - Linux

SQL Server를 접하는 Linux 사용자인 경우 다음 작업에서 몇 가지 보안 작업을 안내합니다. 이 보안 작업은 Linux에 고유하거나 특정하지 않으며 추가로 조사할 영역에 대한 아이디어를 제공하는 데 도움이 됩니다. 각 예제에서는 해당 영역에 대한 심층 설명서에 대한 링크가 제공됩니다.

이 문서에는 AdventureWorks2022 Microsoft SQL Server 샘플 및 커뮤니티 프로젝트 홈페이지에서 다운로드할 수 있는 샘플 데이터베이스가 필요합니다.

로그인 및 데이터베이스 사용자 만들기

CREATE LOGIN 문을 사용하여 데이터베이스에 로그인을 만들어 다른 사용자에게 master SQL Server에 대한 액세스 권한을 부여합니다. 예시:

CREATE LOGIN Larry WITH PASSWORD = '************';

참고 항목

항상 이전 명령의 별표 대신 강력한 암호를 사용합니다.

로그인은 SQL Server에 연결하고 데이터베이스에 대한 액세스 권한(제한된 권한 포함)을 master 가질 수 있습니다. 사용자 데이터베이스에 연결하려면 데이터베이스 사용자라고도 하는 데이터베이스 수준의 해당 ID가 로그인에 필요합니다. 사용자는 각 데이터베이스에 한정되며 액세스 권한을 부여하려면 각 데이터베이스에서 별도로 만들어야 합니다. 다음 예제에서는 데이터베이스로 AdventureWorks2022 이동한 다음 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 문을 사용하여 고정 데이터베이스 역할의 멤버 자격을 부여합니다. 다음 예제에서는 db_datareader 고정 데이터베이스 역할에 사용자를 Jerry 추가합니다.

USE AdventureWorks2022;
GO

ALTER ROLE db_datareader ADD MEMBER Jerry;

고정 데이터베이스 역할 목록은 데이터베이스 수준 역할을 참조 하세요.

나중에 데이터에 대한 보다 정확한 액세스를 구성할 준비가 되면(권장) CREATE ROLE 문을 사용하여 사용자 정의 데이터베이스 역할을 만듭니다. 그런 다음 사용자 지정 역할에 특정 세분화된 권한을 할당합니다.

예를 들어 다음 문은 이름이 지정된 Sales데이터베이스 역할을 만들고, 그룹에 테이블에서 행 Orders 을 보고, 업데이트하고, 삭제할 수 있는 기능을 부여 Sales 한 다음, 사용자를 JerrySales 역할에 추가합니다.

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 이 로그인 ID SalesPerson 와 일치하거나 쿼리를 실행하는 사용자가 Manager 사용자인 경우 1을 반환합니다.

CREATE SCHEMA Security;
GO

CREATE FUNCTION Security.fn_securitypredicate(@SalesPersonID AS 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 문을 사용하여 테이블의 열에 마스킹 함수를 EmailAddressPerson.EmailAddress 추가합니다.

USE AdventureWorks2022;
GO

ALTER TABLE Person.EmailAddress
ALTER COLUMN EmailAddress ADD MASKED
    WITH (FUNCTION = 'email()');

테이블에 대한 권한이 있는 SELECT 새 사용자를 TestUser 만든 다음, 쿼리 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(투명한 데이터 암호화)는 하드 드라이브에 저장될 때 데이터 파일을 암호화합니다. master SQL Server 데이터베이스 엔진의 데이터베이스에는 암호화 키가 있으므로 데이터베이스 엔진이 데이터를 조작할 수 있습니다. 키에 액세스하지 않고는 데이터베이스 파일을 읽을 수 없습니다. 상위 수준의 관리자는 키를 관리, 백업 및 다시 만들 수 있으므로 선택한 사용자만 데이터베이스를 이동할 수 있습니다. TDE를 구성하면 tempdb 데이터베이스도 자동으로 암호화됩니다.

데이터베이스 엔진 데이터를 읽을 수 있으므로 TDE는 메모리를 직접 읽거나 관리자 계정을 통해 SQL Server에 액세스할 수 있는 컴퓨터 관리자의 무단 액세스로부터 보호하지 않습니다.

TDE 구성

  • 마스터 키 만들기
  • 마스터 키로 보호되는 인증서 만들기 또는 가져오기
  • 데이터베이스 암호화 키 만들기 및 인증서로 보호
  • 암호화를 사용하도록 데이터베이스 설정

TDE를 CONTROL 구성하려면 데이터베이스에 대한 master 권한과 CONTROL 사용자 데이터베이스에 대한 권한이 필요합니다. 일반적으로 관리자가 TDE를 구성합니다.

다음 예제에서는 이름이 지정된 MyServerCert서버에 설치된 인증서를 사용하여 데이터베이스를 암호화하고 암호 해독하는 AdventureWorks2022 방법을 보여 줍니다.

USE master;
GO

CREATE MASTER KEY ENCRYPTION BY 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 암호화를 참조 하세요.