현재 DP-900 공식 출제 범위에는 보안이 별도 항목으로 들어 있지 않습니다. 하지만 Microsoft Learn의 Azure SQL, Azure Storage, Azure Cosmos DB 단원에는 암호화, Microsoft Defender for SQL, 감사, Microsoft Entra ID 인증 같은 보안 기능이 함께 소개되고, 문제은행과 예전 자료에는 SQL 방화벽 규칙, 동적 데이터 마스킹, Always Encrypted를 묻는 문제가 꾸준히 나옵니다. 시험 비중은 크지 않지만 이런 문제에서 막히지 않도록 기본기를 정리해 두는 글입니다.
이 글은 DP-900 학습자료 중 SQL 문 유형 편의 보충편입니다. 그 글의 DCL(GRANT·REVOKE)에서 시작한 권한 이야기를 넓혀, 데이터의 세 가지 상태, 계층별 방어, Azure SQL Database의 보안 기능, Azure Storage와 Cosmos DB의 인증·암호화를 순서대로 살펴봅니다.
---
데이터의 세 가지 상태와 보호 방법
현금을 지키는 방법을 떠올려 보세요. 금고 안에 있을 때, 현금 수송차로 옮길 때, 계산대 위에서 셀 때 각각 다른 방법으로 지킵니다. 데이터도 저장 중, 전송 중, 사용 중이라는 세 가지 상태마다 보호 수단이 다릅니다.
| 상태 | 의미 | Azure의 보호 수단 | |------|------|------| | 저장 중 (at rest) | 디스크·백업에 저장된 데이터 | Azure SQL의 TDE, Azure Storage 서비스 암호화(SSE), Cosmos DB 기본 암호화 | | 전송 중 (in transit) | 네트워크를 지나는 데이터 | TLS(HTTPS), 스토리지 계정의 보안 전송 필수 설정 | | 사용 중 (in use) | 쿼리·처리 중인 데이터 | Always Encrypted(보안 엔클레이브 포함), 동적 데이터 마스킹으로 노출 최소화 |
Azure의 데이터 서비스는 대부분 저장 중 암호화가 기본으로 켜져 있습니다. Azure Storage는 모든 스토리지 계정에서 256비트 AES 암호화가 적용되고 끌 수 없으며, Cosmos DB도 저장 데이터 암호화가 기본값입니다.
시험 팁: "디스크에 저장된 데이터베이스 파일과 백업을 앱 변경 없이 암호화" → TDE(저장 중). "네트워크를 지나는 데이터 보호" → TLS(전송 중).
---
계층별로 막는다: 심층 방어
성에 들어가려면 해자를 건너고, 성문에서 신분을 확인받고, 출입이 허락된 방에만 들어갈 수 있습니다. 한 겹이 뚫려도 다음 겹이 막아 주는 이 방식을 심층 방어라고 합니다. 데이터에 닿는 요청도 네트워크, 인증, 권한 부여, 데이터 보호 계층을 차례로 거칩니다.
!요청이 데이터에 닿기까지 거치는 보안 계층
| 계층 | 묻는 질문 | 대표 기능 | |------|------|------| | 네트워크 | 어디서 접속하는가? | 방화벽 규칙, 가상 네트워크, 프라이빗 엔드포인트 | | 인증 | 누구인가? | Microsoft Entra ID, SQL 인증, 액세스 키 | | 권한 부여 | 무엇을 할 수 있는가? | Azure RBAC, GRANT·DENY·REVOKE, SAS, ACL | | 데이터 보호 | 데이터 자체를 어떻게 지키는가? | TDE, TLS, Always Encrypted, 동적 데이터 마스킹 | | 모니터링 | 이상한 일이 생기지 않았는가? | 감사, Microsoft Defender for SQL·Storage |
모든 계층에 공통으로 적용되는 원칙이 두 가지 있습니다. 최소 권한은 업무에 꼭 필요한 권한만 주는 것이고, 제로 트러스트는 "명시적으로 확인하고, 최소 권한을 쓰고, 이미 침해되었다고 가정한다"는 세 원칙으로 내부 네트워크도 무조건 믿지 않는 것입니다.
시험 팁: "보고서 담당자에게 읽기 권한만 부여" → 최소 권한. "한 가지 보안 장치에만 의존하지 않고 여러 겹으로 보호" → 심층 방어.
---
Azure SQL Database 보안
방화벽 규칙: 서버 수준 vs 데이터베이스 수준
새 논리 서버를 만들면 서버 수준 방화벽이 공용 엔드포인트로 들어오는 모든 접속을 막습니다. 접속을 허용할 IP 주소 범위를 규칙으로 추가해야 연결할 수 있습니다.
| 구분 | 서버 수준 IP 방화벽 규칙 | 데이터베이스 수준 IP 방화벽 규칙 | |------|------|------| | 적용 범위 | 논리 서버의 모든 데이터베이스 | 특정 데이터베이스 하나 | | 설정 방법 | Azure Portal, PowerShell, T-SQL | T-SQL로만 (sp_set_database_firewall_rule) | | 저장 위치 | master 데이터베이스 | 해당 데이터베이스 | | 검사 순서 | 데이터베이스 수준에서 맞는 규칙이 없을 때 | 먼저 검사 |
"Azure 서비스 및 리소스의 액세스 허용" 설정을 켜면 다른 Azure 서비스에서 오는 연결을 허용하며, 서버 방화벽 규칙 하나로 계산됩니다. 공용 인터넷을 아예 거치지 않으려면 가상 네트워크 규칙이나 프라이빗 엔드포인트를 씁니다.
인증과 데이터 보호 기능
Azure SQL은 사용자 이름과 암호로 로그인하는 SQL 인증과, 조직 계정으로 통합 관리하고 단일 로그인을 지원하는 Microsoft Entra 인증을 모두 지원합니다. 그 위에 다음 기능으로 데이터를 지킵니다.
| 기능 | 하는 일 | 기억할 점 | |------|------|------| | TDE (투명한 데이터 암호화) | 데이터베이스·백업·트랜잭션 로그를 저장 시 실시간 암호화 | 새 Azure SQL Database에 기본 적용, 앱 변경 불필요 | | Always Encrypted | 클라이언트 드라이버가 민감한 열을 암호화해서 보냄 | 키가 데이터베이스 엔진에 노출되지 않아 DBA도 평문을 못 봄 | | 동적 데이터 마스킹 | 권한 없는 사용자의 쿼리 결과에서 민감한 값을 가림 | 저장된 데이터는 바뀌지 않음 | | 행 수준 보안 | 사용자에 따라 볼 수 있는 행을 제한 | 예: 영업 사원은 자기 지역 고객만 | | 감사 | 데이터베이스 이벤트를 감사 로그에 기록 | 규정 준수, 이상 활동 확인 | | Microsoft Defender for SQL | 취약성 평가 + 지능형 위협 보호 | SQL 주입 공격, 비정상적인 접근 패턴을 탐지해 경고 |
시험 팁: "콜센터 직원에게는 이메일 주소 일부만 보이게" → 동적 데이터 마스킹. "데이터베이스 관리자도 주민번호를 평문으로 볼 수 없어야 한다" → Always Encrypted. "SQL 주입 시도를 탐지해 경고" → Microsoft Defender for SQL. "특정 사무실 IP에서만 한 데이터베이스에 접속 허용, T-SQL로 설정" → 데이터베이스 수준 방화벽 규칙.
---
Azure Storage와 Cosmos DB 보안
Azure Storage
Azure Storage의 데이터는 저장 시 256비트 AES로 자동 암호화되고 이 암호화는 끌 수 없습니다. 기본은 Microsoft 관리 키이고, 필요하면 Blob Storage와 Azure Files에 고객 관리 키를 쓸 수 있습니다. 데이터에 접근하는 권한은 다음 방법으로 줍니다.
| 방법 | 특징 | 권장 여부 | |------|------|------| | Microsoft Entra ID + Azure RBAC | 사용자·관리 ID에 역할을 부여, 키를 코드에 넣지 않음 | Microsoft 권장 | | 공유 키 (계정 액세스 키) | 계정 전체에 대한 전체 권한 | 노출 위험이 커 가급적 피함 | | 공유 액세스 서명 (SAS) | 기간·권한·범위를 제한한 위임 토큰 | 쓸 때는 사용자 위임 SAS 권장 | | ACL (Data Lake Gen2) | 파일·폴더별 POSIX 권한 | 계층 구조 네임스페이스에서 |
네트워크 측면에서는 스토리지 방화벽과 가상 네트워크 규칙, 프라이빗 엔드포인트로 접근 경로를 좁히고, 보안 전송 필수 설정으로 HTTPS만 허용합니다. Microsoft Defender for Storage는 비정상적인 접근이나 악성 파일 업로드 같은 위협을 탐지합니다.
Azure Cosmos DB
Cosmos DB도 저장 데이터 암호화가 기본으로 켜져 있습니다. 데이터 접근은 계정 키(기본·보조 키)로 할 수도 있지만, Microsoft는 Microsoft Entra ID 기반의 데이터 평면 역할 기반 액세스 제어와 관리 ID로 최소 권한을 적용하라고 권장합니다. 키를 계속 써야 한다면 정기적으로 교체하고, 공용 네트워크 접근을 끄고 프라이빗 엔드포인트만 쓰는 구성이 권장됩니다.
시험 팁: "임시 외부 협력사에게 특정 컨테이너를 7일 동안 읽기 전용으로 공유" → SAS. "앱이 키 없이 스토리지에 접근" → 관리 ID + Azure RBAC. "스토리지 계정 암호화를 끌 수 있는가" → 끌 수 없음.
---
시나리오로 연습하기
먼저 답을 떠올린 뒤 오른쪽 열을 확인해 보세요.
| 문제 상황 | 정답 | 판단 근거 | |------|------|------| | 새로 만든 Azure SQL 논리 서버에 사무실 PC가 접속하지 못한다 | 서버 수준 방화벽에 사무실 IP 규칙 추가 | 기본적으로 모든 공용 접속 차단 | | 개발자가 운영 DB를 조회할 때 카드 번호 뒤 4자리만 보여야 한다 | 동적 데이터 마스킹 | 결과만 가리고 저장값은 그대로 | | 클라우드 운영자도 급여 열을 볼 수 없어야 한다 | Always Encrypted | 키가 DB 엔진에 노출되지 않음 | | 데이터베이스 파일과 백업을 앱 변경 없이 암호화 | TDE | 저장 중 실시간 암호화, 기본 적용 | | 영업 사원마다 자기 지역 주문만 조회 | 행 수준 보안 | 사용자별 행 필터 | | 비정상적인 로그인과 SQL 주입 시도를 탐지해 알림 | Microsoft Defender for SQL | 지능형 위협 보호 | | 외부 업체에 특정 Blob을 하루 동안만 읽게 허용 | 공유 액세스 서명(SAS) | 기간과 권한이 제한된 위임 | | Azure 앱이 연결 문자열 없이 Cosmos DB에 접근 | 관리 ID + 데이터 평면 RBAC | 키 없는 최소 권한 인증 |
---
시험 핵심 정리
시험장 가기 전 마지막으로 확인할 핵심 포인트입니다.
| 구분 | 핵심 암기 사항 | |------|------| | 데이터의 세 가지 상태 | 저장 중(TDE·SSE), 전송 중(TLS), 사용 중(Always Encrypted) | | 심층 방어 | 네트워크 → 인증 → 권한 부여 → 데이터 보호, 여러 겹으로 방어 | | 최소 권한 · 제로 트러스트 | 필요한 권한만, 명시적 확인·최소 권한·침해 가정 | | SQL 서버 수준 방화벽 | 서버의 모든 DB, Portal·PowerShell·T-SQL, master에 저장 | | SQL DB 수준 방화벽 | 특정 DB, T-SQL로만, 먼저 검사 | | Microsoft Entra 인증 | 조직 계정 통합, 단일 로그인, SQL 인증보다 권장 | | TDE | 저장 중 실시간 암호화, 새 Azure SQL DB에 기본 적용 | | Always Encrypted | 클라이언트 측 암호화, 키가 DB 엔진에 노출되지 않음 | | 동적 데이터 마스킹 | 권한 없는 사용자에게 결과를 가림, 저장값 불변 | | Defender for SQL | 취약성 평가 + SQL 주입 등 위협 탐지 | | Storage 암호화와 접근 | 256비트 AES 자동·해제 불가, Entra ID + RBAC 권장, SAS는 기간 제한 위임 | | Cosmos DB 접근 | 기본 암호화, 키보다 Entra ID 데이터 평면 RBAC 권장 |
---
다음 단계
보안 기본기를 정리했다면, 권한 부여의 출발점인 GRANT·DENY·REVOKE를 다룬 SQL 문 유형(DDL·DML·DCL)과 제약 조건을 함께 복습하세요. 스토리지의 ACL과 계정 구조는 Azure Storage 심화, Azure SQL 제품군의 차이는 관계형 데이터 기본 개념에서 이어집니다.
실전 감각을 익히고 싶다면 DP-900 모의고사로 보안 기능을 고르는 문제를 직접 풀어 보세요. 마스킹·암호화·방화벽처럼 비슷해 보이는 기능은 "누구에게서 무엇을 숨기는가"를 기준으로 구분하면 헷갈리지 않습니다.