DP-300 시험에서 인증·권한 파트는 '누가 데이터베이스에 들어올 수 있는가'와 '들어온 뒤 무엇을 할 수 있는가'를 어떻게 설계하느냐를 묻습니다. 두 질문은 각각 인증(Authentication)과 권한 부여(Authorization)로 나뉘고, Azure SQL 환경에서는 구현 계층이 완전히 다릅니다. 시나리오 속 선택 근거를 묻기 때문에 각 옵션이 어떤 상황에서 등장하는지 파악하는 것이 핵심입니다.
SQL Authentication vs Microsoft Entra ID 인증
회사 건물에 출입하는 방법이 두 가지라고 상상해 보세요. 하나는 건물 자체 관리사무소가 발급한 비밀번호, 다른 하나는 본사 HR이 발급한 사원증입니다. SQL Authentication은 전자입니다. DB 엔진이 직접 사용자명과 비밀번호를 저장하고 검증합니다. 온프레미스 SQL Server와 동일한 방식이라 기존 애플리케이션 호환성이 좋지만, 비밀번호 순환과 퇴사자 계정 비활성화를 별도로 관리해야 합니다.
Microsoft Entra ID 인증은 사원증 방식입니다. 조직의 중앙 ID 시스템이 인증을 처리하므로 SQL 엔진에 비밀번호를 따로 보관하지 않아도 됩니다. 직원이 퇴사해 Entra ID 계정이 비활성화되면 SQL 접근도 자동으로 차단됩니다. MFA, 조건부 액세스, 그룹 기반 권한 관리가 모두 가능합니다.
Entra ID 인증 세부 모드: (온프레미스 AD 페더레이션 자동 로그인), (Entra ID 계정 직접 로그인), (MFA 포함 대화형 로그인), ·(애플리케이션용 비대화형 인증).
!SQL 인증 vs Microsoft Entra ID 인증
Login, User, Contained User
음식점에 들어가려면 먼저 문을 열고(입장 자격), 그다음 자리를 배정받아야 합니다(좌석 권한). SQL Server 보안 모델도 이 두 단계로 나뉩니다.
은 인스턴스 수준의 보안 주체로 DB에 저장됩니다. 는 특정 데이터베이스 안에서의 보안 주체입니다. Login을 특정 DB의 User에 매핑해야 테이블에 접근할 수 있습니다. 문제는 DB를 다른 서버로 이동할 때 드러납니다. DB 내에 User는 있지만 새 서버에 Login이 없는 '고아 사용자(orphaned user)'가 발생합니다.
가 이를 해결합니다. master DB의 서버 수준 Login 없이 해당 데이터베이스 자체에 인증 정보를 보관하므로, DB를 이동해도 인증이 끊기지 않습니다. Azure SQL Database 권장 방식입니다. Entra ID 사용자는 로 생성하고, 그룹 전체를 등록하면 멤버 전체가 한 번에 접근 권한을 얻습니다.
역할 기반 권한 모델
100명이 근무하는 사무실에서 사람마다 열쇠를 나눠주는 것은 비현실적입니다. '영업팀 카드'·'개발팀 카드'처럼 역할별 카드를 만들면 팀을 옮겨도 카드만 교체하면 됩니다.
서버 수준 Fixed Server Role: (최고 권한), (DB 생성·수정·삭제), (Login 생성 + GRANT/REVOKE/DENY). 주의: 은 자신이 보유하지 않은 권한도 타 사용자에게 부여할 수 있어 사실상 수준 에스컬레이션이 가능합니다.
데이터베이스 수준 Fixed Database Role: (DB 내 모든 작업), (모든 테이블 SELECT), (INSERT·UPDATE·DELETE), (역할 관리 + GRANT/REVOKE 전담), (사용자 계정 추가·제거만). Azure SQL Database에서는 PaaS 특성상 이 지원되지 않으므로 User-Defined Database Role을 사용합니다.
GRANT·DENY·REVOKE
창고 관리자가 직원 A에게 특정 창고 출입을 허락했는데, 나중에 민감한 물건이 들어왔습니다. 관리자는 A의 출입을 어떻게 막을까요?
는 권한 부여, 는 부여된 권한 제거, 는 명시적 거부입니다. 핵심 규칙: 는 보다 항상 우선합니다. 역할 멤버십을 통해 간접적으로 를 받았더라도 직접 가 있으면 접근이 차단됩니다. 을 추가하면 권한을 받은 사용자가 같은 권한을 타인에게도 줄 수 있습니다. 스키마 수준 GRANT는 그 안의 모든 객체에 적용되고, 객체 수준 GRANT는 특정 테이블·뷰만 대상으로 합니다. 최소 권한 원칙은 항상 가장 좁은 범위부터 시작합니다.
Managed Identity — 코드에 비밀번호가 없어도 된다
앱 개발자가 connection string에 계정과 비밀번호를 하드코딩했다가 공개 저장소에 올라가면 큰 문제가 됩니다. Managed Identity는 이 위험을 원천 차단합니다.
Managed Identity는 Azure 리소스(가상 머신, App Service, Azure Functions)에 자동으로 부여되는 Entra ID 기반 ID입니다. Azure 플랫폼이 자동으로 토큰을 발급하고 교환하므로 코드나 구성 파일에 비밀번호·인증서를 저장하지 않아도 됩니다. System-Assigned Managed Identity는 리소스와 생명주기가 같고, User-Assigned Managed Identity는 여러 리소스가 공유합니다. Azure SQL에서는 Managed Identity를 Entra ID 관리자로 설정하거나 Contained User로 등록한 뒤 역할을 부여합니다.
인증 방식 비교
| 시나리오 | 추천 방식 | |----------|-----------| | 레거시 앱, 온프레미스 SQL과 동일 방식 | SQL Authentication | | 조직 계정 + MFA 필요 | Entra ID Universal with MFA | | 온프레미스 AD 도메인 자격 증명 자동 로그인 | Entra ID Integrated | | 코드에 자격 증명 없이 Azure 앱이 SQL 연결 | Managed Identity | | 서비스 간 인증, 비밀 직접 관리 | Service Principal |
SQL Authentication과 Entra ID 인증의 가장 큰 차이는 자격 증명 관리 위치입니다. 조직 ID 라이프사이클(입사·퇴사·부서 이동)과 연동하려면 Entra ID 인증이 필수입니다.
실무 함정
도서관 사서가 모든 책의 마스터 키를 가진다면 최소 권한이 아닙니다. DP-300 시험은 이런 과도한 권한 부여 함정을 즐겨 씁니다.
"SQL 비밀번호 관리 없애기" → Entra ID 인증. "모든 테이블 읽기만 허용" → (는 과잉). "권한 부여·회수만 위임" → (은 사용자 계정 추가·제거만). "코드에 자격 증명 저장 없이 SQL 연결" → Managed Identity(Service Principal은 비밀 관리 필요). Azure SQL Database에서 은 PaaS 환경이라 실패합니다. 은 자신이 갖지 않은 권한도 부여 가능해 sysadmin 수준 에스컬레이션 위험이 있습니다.
시험 핵심 정리
"SQL 비밀번호 관리 없애기, 회사 계정으로 DB 로그인" -- Microsoft Entra ID 인증 "코드에 자격 증명 없이 Azure 앱이 SQL 연결" -- Managed Identity "온프레미스 AD 도메인 자격 증명 자동 로그인" -- Entra ID Integrated (AD 페더레이션 필요) "MFA 포함 대화형 로그인" -- Universal with MFA "DB 이동 시 인증 유지" -- Contained Database User "Entra ID 그룹을 DB에 등록" -- CREATE USER [그룹명] FROM EXTERNAL PROVIDER "읽기 전용 최소 권한" -- db_datareader "권한 부여·회수 전담" -- db_securityadmin "사용자 계정 추가·제거만" -- db_accessadmin "DENY는 GRANT보다 항상 우선" -- DENY 우선순위 규칙 "서버 수준 권한 부여 위임, 위험한 역할" -- securityadmin (사실상 sysadmin 수준) "Azure SQL Database에서 CREATE SERVER ROLE 실패" -- PaaS, User-Defined Database Role 사용
Microsoft Entra ID = 중앙 ID 연동, Managed Identity = 코드 비밀 없음, Contained User = 서버 이동 안전, DENY = 항상 우선