데이터 API 작성기는 REST 및 GraphQL 엔드포인트를 통해 데이터를 노출합니다. API를 보호하려면 인증 (누가 호출하는가?), 권한 부여 (수행할 수 있는 작업) 및 전송 보안 (연결이 보호되나요?)의 세 가지 핵심 영역에 주의해야 합니다.
보안의 세 가지 핵심 요소
| 핵심 요소 | 답변하는 질문 | 주요 개념 |
|---|---|---|
| 인증 | 호출자는 누구인가요? | ID 공급자에서 토큰 유효성 검사 |
| 승인 | 그들은 무엇을 할 수 있는가? | 엔터티에 대한 역할 기반 권한 |
| 수송 | 연결이 안전한가요? | 모든 트래픽에 대한 TLS(전송 계층 보안) 암호화 |
인증 공급자 선택
Data API Builder는 여러 인증 공급자를 지원합니다. 배포 시나리오와 일치하는 항목을 선택합니다.
| 공급자 | 사용 사례 | 가이드 |
|---|---|---|
| 인증되지 않음 | DAB는 ID를 처리하는 신뢰할 수 있는 프런트 엔드 뒤에 있습니다(기본값). | 인증되지 않은 공급자 구성 |
Microsoft Entra ID (EntraID/AzureAD) |
Microsoft ID를 사용하는 프로덕션 앱 | Microsoft Entra 인증 구성 |
| JWT(사용자 지정 JSON 웹 토큰) | 타사 IDP(Okta, Auth0, Keycloak) | 사용자 지정 JWT 인증 구성 |
| App Service | Azure App Service EasyAuth(플랫폼 헤더) 뒤에서 실행되는 앱 | App Service 인증 구성 |
| 시뮬레이터 | 로컬 개발 및 테스트 | 시뮬레이터 인증 구성 |
| OBO(사용자 위임) | 실제 사용자 ID가 필요한 SQL 데이터베이스(행 수준 보안, 감사) | OBO 인증 구성 |
메모
이 섹션에 설명된 Data API Builder 2.0 기능은 현재 미리 보기 상태이며 일반 공급 전에 변경될 수 있습니다. 자세한 내용은 버전 2.0의 새로운 기능입니다.
인증
인증은 호출자의 ID를 확인합니다. 데이터 API 작성기는 JWT 전달자 토큰(, )의 유효성을 검사하거나 플랫폼에서 제공하는 ID 헤더(EntraID/AzureADCustom, AppService)를 신뢰하여 요청을 인증합니다. StaticWebApps
Simulator 는 개발을 위한 외부 유효성 검사를 건너뜁니다.
작동 방식
- JWT 공급자의 경우 클라이언트는 ID 공급자로부터 토큰을 획득합니다.
- 클라이언트가 헤더(JWT 공급자)에
Authorization: Bearer <token>토큰을 보내거나 플랫폼이 ID 헤더를 삽입합니다(EasyAuth/SWA). - 데이터 API 작성기가 토큰 또는 플랫폼 헤더(JWT 공급자의 발급자, 대상 그룹, 서명)의 유효성을 검사합니다.
- DAB는 토큰 또는 ID 헤더에서 사용자의 역할을 추출합니다.
빠른 참조
| 설정 | 설명 |
|---|---|
runtime.host.authentication.provider |
인증 공급자(Unauthenticated,, EntraID/AzureADCustom, AppService, ) StaticWebAppsSimulator |
runtime.host.authentication.jwt.audience |
JWT 공급자에 대한 예상되는 청중 요구(이는 AppService, StaticWebApps, 시뮬레이터, 인증되지 않은 경우 사용되지 않음) |
runtime.host.authentication.jwt.issuer |
JWT 공급자에 대한 예상 발급자/기관(AppService/StaticWebApps/Simulator/Unauthenticated에서 사용되지 않음) |
공급자별 구성은 이 섹션의 인증 가이드를 참조하세요.
Authorization
권한 부여는 인증된(또는 익명) 사용자가 수행할 수 있는 작업을 결정합니다. 데이터 API 작성기에서는 RBAC(역할 기반 액세스 제어)를 사용하여 엔터티 및 작업에 대한 액세스를 제한합니다.
작동 방식
- DAB는 토큰 및 헤더를 기반으로 요청에 역할을 할당합니다.
- DAB는 해당 역할에 대한 엔터티의 권한을 조회합니다.
- 역할에 요청된 작업에 대한 권한이 있는 경우 DAB는 쿼리를 실행합니다.
- 그렇지 않은 경우 DAB는 응답을 반환합니다
403 Forbidden.
시스템 역할 및 사용자 역할
| 역할 유형 | 설명 |
|---|---|
Anonymous |
인증된 ID가 없을 때 할당됨 |
Authenticated |
요청이 인증되고(JWT가 수락되거나 신뢰할 수 있는 플랫폼 헤더) 특정 사용자 역할이 선택되지 않을 때 할당됨 |
| 사용자 역할 |
roles 클레임(또는 플랫폼 역할)에서 사용자 지정 역할을 헤더 X-MS-API-ROLE를 통해 선택함. |
기본적으로 보안 적용
엔터티에는 기본적으로 권한이 없습니다. 액세스 권한을 명시적으로 부여해야 합니다.
{
"entities": {
"Book": {
"permissions": [
{ "role": "authenticated", "actions": ["read"] }
]
}
}
}
자세한 구성은 권한 부여 개요를 참조하세요.
행 수준 및 필드 수준 보안
세분화된 액세스 제어를 사용하여 엔터티 수준 권한 이상으로 이동합니다.
| 특징 | 설명 | 가이드 |
|---|---|---|
| 데이터베이스 정책(행 수준 보안) | 정책 식을 클레임 또는 세션 컨텍스트에 따라 행을 필터링하는 쿼리 조건자로 변환 | 행 수준 보안 구현 |
| 필드 수준 보안 | 역할당 특정 열 포함 또는 제외 | 필드 접근 |
| On-Behalf-Of(OBO) | 데이터베이스가 실제 호출 사용자로 인증되도록 들어오는 사용자 토큰을 다운스트림 SQL 토큰에 교환합니다(mssql만 해당). | 사용자 위임 인증 |
역할 상속
DAB 2.0은 엔터티 권한에 대한 역할 상속을 도입합니다. 상속 체인은 named-role → authenticated → anonymous입니다. 역할이 엔터티에 대해 명시적으로 구성되지 않은 경우 다음 광범위한 역할에서 상속됩니다. 권한을 한 번 anonymous 정의하면 모든 광범위한 역할에 동일한 액세스 권한이 부여됩니다. 자세한 내용은 역할 상속을 참조하세요.
전송 및 구성 보안
전송 보안
- 모든 연결에 TLS 사용: 클라이언트와 DAB 간의 트래픽 암호화
- 레거시 TLS 버전 사용 안 함: TLS 1.2 이상만 사용
- HTTPS 엔드포인트 사용: 프로덕션 환경에서 암호화되지 않은 HTTP를 통해 DAB를 노출하지 않음
자세한 내용은 보안 모범 사례를 참조하세요.
구성 보안
-
환경 변수에 비밀 저장: 구성에서 사용
@env('SECRET_NAME') -
Azure Key Vault 사용:
@azure('key-vault-uri')를 사용하여 비밀 참조하다 -
비밀 커밋 안 함:
dab-config.json암호 및 연결 문자열 사용 안 함
{
"data-source": {
"connection-string": "@env('SQL_CONNECTION_STRING')"
}
}
모니터링 및 업데이트
- 액세스 모니터링: Application Insights를 사용하여 요청 추적 및 변칙 검색
- 로그 검토: 실패한 인증 시도 및 권한 거부 확인
- DAB 업데이트 유지: 최신 버전으로 업그레이드하여 보안 패치 적용
빠른 시작 가이드
| 과업 | 가이드 |
|---|---|
| DAB에서 JWT 유효성 검사 없이 신뢰할 수 있는 프런트 엔드 사용 | 인증되지 않은 공급자 구성 |
| Microsoft Entra ID 인증 설정 | Microsoft Entra 인증 구성 |
| Okta 또는 Auth0 사용 | 사용자 지정 JWT 인증 구성 |
| Azure App Service 뒤에서 실행 | App Service 인증 구성 |
| 로컬로 권한 테스트 | 시뮬레이터 인증 구성 |
| 사용자별 행 제한 | 행 수준 보안 구현 |
| 역할 할당 이해 | 권한 부여 개요 |