다음을 통해 공유

보안 캐시 개념

적용 대상:SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

이 문서에서는 SQL Server가 보안 캐시를 사용하여 보안 개체에 액세스해야 하는 보안 주체의 사용 권한의 유효성을 검사하는 방법을 설명합니다.

목적

데이터베이스 엔진은 권한으로 보안을 설정할 수 있는 보안 개체라고 하는 엔터티의 계층적 컬렉션을 구성합니다. 가장 눈에 띄는 보안 개체는 서버 및 데이터베이스이지만 사용 권한도 더 세부적으로 설정할 수 있습니다. SQL Server는 보안 개체에 대한 보안 주체의 작업을 적절한 권한이 있는지 확인하여 제어합니다.

다음 다이어그램은 사용자 Alice가 서버 수준에서 로그인하고 서로 다른 각 데이터베이스에서 동일한 로그인에 매핑된 세 명의 다른 사용자를 보여 주는 다이어그램입니다.

다이어그램은 Alice가 서버 수준에서 하나의 로그인을 가질 수 있고 서로 다른 각 데이터베이스에서 동일한 로그인에 매핑된 세 명의 다른 사용자를 가질 수 있음을 나타냅니다.

인증 프로세스를 최적화하기 위해 SQL Server는 보안 캐시를 사용합니다.

캐시 워크플로 없음

보안 캐시가 유효하지 않으면 SQL Server는 캐시 없음 워크플로를 따라 사용 권한의 유효성을 검사합니다. 이 섹션에서는 캐시 없음 워크플로에 대해 설명합니다.

보여 주려면 다음 쿼리를 고려하세요.

SELECT t1.Column1,
       t2.Column1
FROM Schema1.Table1 AS t1
     INNER JOIN Schema2.Table2 AS t2
         ON t1.Column1 = t2.Column2;

보안 캐시가 잘못되면 서비스는 쿼리를 확인하기 전에 다음 워크플로에 설명된 단계를 완료합니다.

다이어그램은 캐시 없음 워크플로를 나타냅니다.

SQL Server의 경우 보안 캐시가 없는 작업에는 다음이 포함됩니다.

  1. 인스턴스에 연결합니다.
  2. 로그인 유효성 검사를 수행합니다.
  3. 보안 컨텍스트 토큰 및 로그인 토큰을 만듭니다. 이러한 토큰의 세부 정보는 다음 섹션에서 설명합니다.
  4. 데이터베이스에 연결합니다.
  5. 데이터베이스 내에 데이터베이스 사용자 토큰을 만듭니다.
  6. 데이터베이스 역할의 멤버 자격을 확인합니다. 예를 들어 db_datareader, db_datawriter 또는 db_owner.
  7. 모든 열에 대한 사용자 사용 권한 확인(예: 사용자의 t1.Column1 사용 권한 및 t2.Column1.
  8. 모든 테이블(예: table1 및 table2)에 대한 사용자 권한과 Schema1 및 Schema2에 대한 스키마 권한을 확인합니다.
  9. 데이터베이스 사용 권한을 확인합니다.

SQL Server는 사용자가 속한 모든 단일 역할에 대해 프로세스를 반복합니다. 모든 권한을 획득한 후 서버는 사용자가 체인에 필요한 모든 권한을 보유하고 체인에 단일 거부 항목이 없는지 확인하기 위해 검사를 수행합니다. 권한 검사가 완료되면 쿼리 실행이 시작됩니다.

자세한 내용은 사용 권한 검사 알고리즘의 요약을 검토하세요.

SQL Server는 유효성 검사를 간소화하기 위해 보안 캐시를 사용합니다.

보안 캐시 정의

보안 캐시는 데이터베이스 또는 서버의 다양한 보안 개체에 대한 사용자 또는 로그인에 대한 권한을 저장합니다. 이점 중 하나는 쿼리 실행 속도를 높일 수 있다는 것입니다. SQL Server는 쿼리를 실행하기 전에 스키마 수준 권한, 테이블 수준 사용 권한 및 열 권한과 같은 다른 데이터베이스 보안 개체에 필요한 권한이 있는지 확인합니다.

보안 캐시 개체

이전 섹션에서 설명하는 워크플로를 더 빠르게 만들기 위해 SQL Server는 보안 캐시 내에 다양한 개체를 캐시합니다. 캐시되는 개체 중 일부는 다음과 같습니다.

토큰 설명
SecContextToken 주체의 서버 전체에 대한 보안 컨텍스트는 이 구조 내에서 유지됩니다. 여기에는 사용자 토큰의 해시 테이블이 포함되며 다른 모든 캐시의 시작 지점 또는 기본으로 사용됩니다. 로그인 토큰, 사용자 토큰, 감사 캐시 및 TokenPerm 캐시에 대한 참조를 포함합니다. 또한 서버 수준에서 로그인에 대한 기본 토큰 역할을 합니다.
LoginToken 보안 컨텍스트 토큰과 유사합니다. 서버 수준 주체의 세부 정보를 포함합니다. 로그인 토큰에는 SID, 로그인 ID, 로그인 유형, 로그인 이름, isDisabled 상태 및 서버 고정 역할 멤버 자격과 같은 다양한 요소가 포함됩니다. 또한 sysadmin 및 보안 관리자와 같은 서버 수준의 특수 역할을 포함합니다.
UserToken 이 구조는 데이터베이스 수준 원칙과 관련이 있습니다. 여기에는 사용자 이름, 데이터베이스 역할, SID, 기본 언어, 기본 스키마, ID, 역할 및 이름과 같은 세부 정보가 포함됩니다. 로그인에 대한 데이터베이스당 하나의 사용자 토큰이 있습니다.
TokenPerm UserToken 또는 SecContextToken에 대한 보안 개체에 대한 모든 권한을 기록합니다.
TokenAudit 키는 보안 개체의 클래스 및 ID입니다. 항목은 개체에 대한 감사 가능한 각 작업에 대한 감사 ID를 포함하는 일련의 목록입니다. 서버 감사는 권한 검사를 기반으로 하며 특정 사용자가 특정 개체에 대해 가지고 있는 감사 가능한 각 작업을 자세히 설명합니다.
TokenAccessResult 이 캐시는 쿼리 계획당 하나의 항목으로 개별 쿼리에 대한 쿼리 권한 검사 결과를 저장합니다. 쿼리 실행 중에 가장 먼저 검사되므로 가장 중요하고 일반적으로 사용되는 캐시입니다. 임시 쿼리가 캐시를 초과하지 않도록 하려면 쿼리가 세 번 실행되는 경우에만 쿼리 권한 검사 결과를 저장합니다.
ObjectPerm 이 레코드는 데이터베이스 내의 모든 사용자에 대해 데이터베이스의 개체에 대한 모든 권한을 기록합니다. TokenPerm과 ObjectPerm의 차이점은 TokenPerm이 특정 사용자를 위한 것이지만 ObjectPerm은 데이터베이스의 모든 사용자에 대한 것일 수 있다는 것입니다.

보안 캐시 저장소

토큰은 다른 캐시 저장소 내에 저장됩니다.

상점 설명
TokenAndPermUserStore 다음 개체를 모두 포함하는 하나의 큰 저장소:

- SecContextToken
- LoginToken
- UserToken
- TokenPerm
- TokenAudit
SecCtxtACRUserStore ACR(액세스 확인 결과) 저장소입니다. 모든 로그인에는 고유한 별도의 보안 컨텍스트 사용자 저장소가 있습니다.
ACRUserStore 액세스 검사 결과 저장소
<unique id> -
<db id>
- <user id>

모든 사용자에게는 개별 ACR 사용자 저장소가 있습니다. 예를 들어 두 개의 서로 다른 데이터베이스에 5명의 사용자가 있는 두 개의 로그인은 2 SecCtxtACRUserStore 개와 10 ACRUserStore개에 해당합니다.
ObjectPerm 데이터베이스 ObjPerm 토큰당 1개. 데이터베이스 내의 모든 다른 보안 개체입니다.

알려진 문제

이 섹션에서는 보안 캐시와 관련된 문제를 설명합니다.

보안 캐시 무효화

다양한 시나리오는 데이터베이스 또는 서버 수준에서 보안 캐시 무효화를 트리거할 수 있습니다. 무효화가 발생하면 모든 현재 캐시 항목이 무효화됩니다. 이후의 모든 쿼리 및 권한 검사는 캐시가 다시 채워 질 때까지 전체 "캐시 없음" 워크플로를 따릅니다. 모든 활성 연결이 캐시된 항목을 다시 빌드해야 하므로 무효화는 서버 성능에 큰 영향을 미칠 수 있습니다. 캐시 무효화가 반복하면 이 영향을 더 악화시킬 수 있습니다. 데이터베이스의 master 무효화는 서버 전체의 무효화로 처리되어 인스턴스의 모든 데이터베이스에 있는 캐시에 영향을 줍니다.

SQL Server 2025에는 특정 로그인에 대해서만 캐시를 무효화하는 기능이 도입되었습니다. 즉, 보안 캐시 항목이 무효화되면 영향을 받는 로그인에 속하는 항목만 영향을 받습니다. 예를 들어 로그인 L1에 새 권한을 부여하면 로그인 L2에 대한 토큰은 영향을 받지 않습니다.

초기 단계로 이 기능은 CREATE, ALTER 및 DROP 로그인 시나리오 및 개별 로그인에 대한 권한 변경에 적용됩니다. 그룹 로그인은 서버 수준 무효화를 계속 경험합니다.

아래 표에서는 보안 캐시를 무효화하는 모든 보안 DDL(데이터 정의 언어) 작업을 나열합니다.

조치 주제 범위
CREATE/ALTER/DROP APPLICATION ROLE
SYMMETRIC KEY
ASYMMETRIC KEY
AUTHORIZATION
CERTIFICATE
ROLE
SCHEMA
USER		 지정된 데이터베이스
DROP 어떤 개체든 sys.all_objects에 나타나는 것이나 데이터베이스 또는 스키마 범위의 보안 개체 목록에 나열된 어떤 보안 개체든 상관없습니다. 지정된 데이터베이스
GRANT/DENY/REVOKE 데이터베이스 또는 스키마에 포함된 보안 개체에 대한 모든 권한. 지정된 데이터베이스
CREATE/ALTER/DROP LOGIN
(SERVICE) MASTER KEY		 SQL Server 인스턴스
ALTER DATABASE 지정된 데이터베이스

TokenAndPermUserStore의 크기가 증가할 때의 쿼리 성능

높은 CPU 사용량 및 메모리 사용량 증가와 같은 성능 문제는 TokenAndPermUserStore 캐시의 과도한 항목으로 인해 발생할 수 있습니다. 기본적으로 SQL Server는 내부 메모리 압력을 감지할 때만 이 캐시의 항목을 정리합니다. 그러나 RAM이 많은 서버에서는 내부 메모리 압력이 자주 발생하지 않을 수 있습니다. 캐시가 늘어나면 다시 사용할 기존 항목을 검색하는 데 필요한 시간이 늘어나게 됩니다. 이 캐시는 스핀 잠금으로 관리되므로 한 번에 하나의 스레드만 검색을 수행할 수 있습니다. 따라서 이 동작으로 인해 쿼리 성능이 저하되고 CPU 사용량이 높아질 수 있습니다.

해결 방법

SQL Server는 TokenAndPermUserStore 캐시에 대한 할당량을 설정하는 데 사용할 수 있는 두 개의 TF(추적 플래그)를 제공합니다. 기본적으로 할당량은 없으므로 캐시는 무제한의 항목을 보유할 수 있습니다.

  • TF 4618: TokenAndPermUserStore의 항목 수를 1024로 제한합니다.
  • TF 4618 및 TF 4610: TokenAndPermUserStore의 항목 수를 8192로 제한합니다. TF 4618의 낮은 진입 수 제한으로 인해 다른 성능 문제가 발생하는 경우 추적 플래그 4610 및 4618을 함께 사용하는 것이 좋습니다. 자세한 내용은 DBCC TRACEON - 추적 플래그(Transact-SQL)를 참조하세요.

자세한 내용은 TokenAndPermUserStore 캐시 - SQL Server의 과도한 항목으로 인해 성능 문제가 발생할 수 있는 문서를 참조할 수 있습니다.

모범 사례

이 섹션에서는 보안 워크플로를 최적화하는 모범 사례를 나열합니다.

비피크 시간 동안 사용자 관리

보안 캐시(데이터베이스/서버 수준)의 높은 수준의 무효화 특성을 감안할 때 서버 부하가 낮은 비사용 시간 동안 보안 DDL을 수행합니다. 워크로드가 많은 동안 보안 캐시 무효화가 발생하는 경우 보안 캐시가 다시 채워질 때 전체 서버에 눈에 띄는 성능 영향이 있을 수 있습니다.

사용 권한 수정에 단일 트랜잭션 사용

동일한 트랜잭션 내에서 여러 보안 DDL(데이터 정의 언어) 작업을 수행하면 다른 활성 연결과 교착 상태가 발생할 가능성이 크게 높아질 수 있으므로 이러한 위험을 완화하려면 단일 트랜잭션에서 여러 보안 DDL을 실행하지 않는 것이 좋습니다. 대신 별도의 트랜잭션에서 보안 관련 DDL 작업을 실행하여 잠금 경합을 최소화합니다.

관련 콘텐츠