AZ-104의 스토리지 도메인(15~20%)에서 공식 출제 범위의 첫 번째 묶음은 "스토리지 액세스 구성"입니다. 방화벽과 가상 네트워크, SAS 토큰, 저장된 액세스 정책, 액세스 키, Azure Files의 ID 기반 액세스가 모두 여기에 들어 있고, 문제은행에서도 방화벽과 접근 권한을 다루는 문항이 스토리지 문제의 절반 가까이를 차지합니다. 문제는 이 기능들이 서로 다른 층에서 동작한다는 점입니다. 방화벽을 열어도 권한이 없으면 403이 나오고, 권한이 있어도 방화벽이 막으면 접근할 수 없습니다.
이 글은 스토리지 요청이 통과해야 하는 두 관문, 즉 네트워크와 권한을 나눠서 정리합니다. 공용 네트워크 액세스 설정과 방화벽 규칙, 네 가지 인증 방식, SAS 세 종류와 저장된 액세스 정책, 액세스 키 회전과 Shared Key 끄기, Azure Files의 ID 기반 액세스, 그리고 저장 데이터 암호화까지 다룹니다. 중복성·액세스 계층·수명 주기 같은 기본기는 스토리지 관리 완전 정복에서 먼저 다뤘습니다.
---
스토리지 요청이 통과해야 하는 두 관문
회사 건물에 들어가려면 먼저 정문 경비실을 지나야 하고, 그다음 사무실 문에서 출입증을 찍어야 합니다. 정문을 통과했다고 아무 사무실에나 들어갈 수 있는 것은 아니고, 출입증이 있어도 정문이 닫혀 있으면 건물에 들어갈 수 없습니다. Azure Storage도 모든 요청을 두 번 검사합니다.
| 관문 | 확인하는 것 | 설정 위치 | |------|------|------| | 1. 네트워크 | 요청이 어디서 왔는가 (인터넷, 특정 VNet, 특정 IP, 프라이빗 엔드포인트) | 스토리지 계정 → 네트워킹 | | 2. 권한 | 요청한 사람이 이 작업을 해도 되는가 (키, SAS, Entra ID, 익명) | 액세스 키, SAS, 액세스 제어(IAM), 컨테이너 액세스 수준 |
!스토리지 요청은 네트워크 관문과 권한 관문을 모두 통과해야 한다
시험 팁: "SAS 토큰이 유효한데 특정 사무실에서만 접근이 거부된다"면 권한이 아니라 네트워크 관문(방화벽 규칙)을 의심하세요. 반대로 "VNet 규칙을 추가했는데 403 권한 오류가 난다"면 RBAC 데이터 역할이나 SAS 권한을 확인합니다.
---
네트워크 관문: 공용 네트워크 액세스와 방화벽 규칙
스토리지 계정의 네트워킹 화면에서 가장 먼저 고르는 것은 공용 네트워크 액세스 수준입니다.
| 설정 | 동작 | |------|------| | 모든 네트워크에서 사용 | 인터넷 어디서든 접근 가능 (권한 관문만 남음) | | 선택한 가상 네트워크 및 IP 주소에서 사용 | 아래 규칙에 맞는 요청만 허용, 나머지는 차단 | | 사용 안 함 | 공용 엔드포인트 차단, 프라이빗 엔드포인트로만 접근 |
"선택한 네트워크"를 고르면 허용 규칙을 조합합니다.
| 규칙 | 허용 대상 | 기억할 점 | |------|------|------| | 가상 네트워크 규칙 | 특정 VNet의 특정 서브넷 | 서브넷에 Microsoft.Storage 서비스 엔드포인트가 필요 (포털은 자동 생성) | | IP 네트워크 규칙 | 공용 IP 주소나 범위 | 사설 IP(10.x, 172.16~31.x, 192.168.x)는 불가, /31·/32는 개별 IP로 입력 | | 리소스 인스턴스 규칙 | 특정 Azure 리소스 인스턴스 | 같은 테넌트의 리소스, 할 수 있는 작업은 그 리소스의 역할 할당이 결정 | | 신뢰할 수 있는 서비스 예외 | 신뢰 목록에 있는 Azure 서비스 | VNet이나 IP로 격리할 수 없는 서비스용 |
IP 규칙에는 자주 출제되는 함정이 있습니다. IP 네트워크 규칙은 스토리지 계정과 같은 Azure 지역에서 오는 요청에는 효과가 없습니다. 같은 지역의 서비스는 사설 Azure IP로 통신하기 때문입니다. 같은 지역의 VM에서 오는 접근을 허용하거나 제한하려면 가상 네트워크 규칙을 써야 합니다. 또 서브넷에 서비스 엔드포인트를 켜면 그 서브넷의 트래픽은 사설 IP를 원본으로 쓰므로, 그 서브넷의 공용 IP를 허용하던 IP 규칙은 더 이상 적용되지 않습니다.
프라이빗 엔드포인트는 VNet 안에 스토리지 계정용 사설 IP를 만들어 주므로, 공용 네트워크 액세스를 "사용 안 함"으로 꺼도 프라이빗 엔드포인트로 들어오는 트래픽은 계속 통과합니다. 서비스 엔드포인트와 프라이빗 엔드포인트의 차이는 초보자도 이해하는 VNet, NSG, DNS, Load Balancer에서 그림으로 비교했습니다.
시험 팁: "온프레미스 사무실의 공용 IP 203.0.113.10에서만 접근 허용"은 IP 네트워크 규칙, "같은 지역 VNet1의 Subnet1에서만 허용"은 가상 네트워크 규칙 + 서비스 엔드포인트, "인터넷에서 완전히 차단하고 VNet의 사설 IP로만 접근"은 프라이빗 엔드포인트 + 공용 네트워크 액세스 사용 안 함입니다.
---
권한 관문: 네 가지 인증 방식
네트워크를 통과한 요청은 다음 네 가지 중 하나로 권한을 증명합니다.
| 방식 | 증명 수단 | 특징 | |------|------|------| | Microsoft Entra ID | 사용자·그룹·관리 ID의 토큰 + RBAC 데이터 역할 | Microsoft 권장, 조건부 액세스와 감사 가능 | | Shared Key | 계정 액세스 키 | 키 하나로 계정 전체 데이터에 전체 권한 | | SAS | 서명된 URL 토큰 | 기간·권한·대상을 제한한 위임 | | 익명 읽기 | 없음 | 계정에서 허용한 뒤 컨테이너 수준에서 켜야 동작 |
Microsoft는 Entra ID와 관리 ID를 기본으로 쓰고, 키는 꼭 필요할 때만 쓰라고 안내합니다. Entra ID로 Blob을 읽고 쓰려면 Storage Blob Data Reader나 Storage Blob Data Contributor 같은 데이터 역할이 필요하다는 점은 AZ-104 RBAC 역할 할당 해석하기에서 자세히 다뤘습니다.
---
SAS 세 종류와 저장된 액세스 정책
SAS(공유 액세스 서명)는 호텔 객실 카드키와 비슷합니다. 프런트가 정해진 방에, 정해진 날짜까지만 열리는 카드를 발급합니다. 다만 무엇으로 서명했는지에 따라 세 종류로 나뉩니다.
| 종류 | 서명 | 대상 | 저장된 액세스 정책 | Shared Key를 끄면 | |------|------|------|------|------| | 사용자 위임 SAS | Entra 자격 증명으로 받은 사용자 위임 키 | Blob(데이터 레이크 포함), 큐, 테이블, Azure Files | 사용 불가 | 계속 동작 | | 서비스 SAS | 계정 액세스 키 | 한 가지 스토리지 서비스 | 사용 가능 | 거부됨 | | 계정 SAS | 계정 액세스 키 | 하나 이상의 서비스, 서비스 수준 작업까지 | 사용 불가 | 거부됨 |
Microsoft는 SAS가 필요하면 사용자 위임 SAS를 쓰라고 권장합니다. 계정 키가 아니라 Entra 자격 증명으로 보호되기 때문입니다. 사용자 위임 키는 최대 7일 동안 유효하므로, 사용자 위임 SAS의 만료 시간도 7일을 넘길 수 없습니다.
저장된 액세스 정책
저장된 액세스 정책은 컨테이너, 큐, 테이블, 파일 공유에 미리 만들어 두는 "카드키 발급 규칙"입니다. 서비스 SAS가 이 정책을 참조하면 시작 시간, 만료 시간, 권한을 정책에서 물려받습니다.
컨테이너(또는 큐·테이블·공유) 하나에 최대 5개 정책을 만들거나 바꾸면 적용까지 최대 30초가 걸릴 수 있음 정책을 삭제하거나, 이름(식별자)을 바꾸거나, 만료 시간을 과거로 바꾸면 연결된 SAS가 모두 무효화 서비스 SAS에서만 쓸 수 있고, 사용자 위임 SAS와 계정 SAS는 즉석(ad hoc) SAS만 가능
이미 발급한 SAS를 무효화하는 방법
| 방법 | 영향 범위 | |------|------| | 만료 시간까지 기다림 | 해당 SAS만 (가장 안전한 기본값은 짧은 만료) | | 저장된 액세스 정책 삭제·변경 | 그 정책을 참조하는 서비스 SAS 전부 | | 서명에 쓴 계정 키 다시 생성 | 그 키로 서명한 모든 서비스 SAS·계정 SAS + 그 키를 쓰던 모든 앱 | | 사용자 위임 키 해지 | 그 계정의 모든 사용자 위임 SAS |
시험 팁: "다른 SAS나 앱에 영향을 주지 않고 발급한 SAS 묶음만 즉시 무효화"할 수 있게 하려면 처음부터 저장된 액세스 정책과 연결한 서비스 SAS로 발급해야 합니다. 키를 다시 생성하는 방법은 영향 범위가 가장 넓어 오답 보기로 자주 나옵니다.
---
액세스 키 관리와 Shared Key 끄기
스토리지 계정을 만들면 512비트 액세스 키가 두 개 생깁니다. 두 개인 이유는 앱이 끊기지 않게 키를 회전하기 위해서입니다.
앱이 key1을 쓰고 있다면 먼저 앱 설정을 key2로 바꿈 key1을 다시 생성 앱 설정을 새 key1로 바꾼 뒤 key2를 다시 생성
Microsoft는 키를 Azure Key Vault에 보관하고 정기적으로 회전하라고 권장합니다. 액세스 키는 계정의 모든 데이터에 대한 전체 권한과 SAS 발급 능력을 함께 주기 때문에, 키를 볼 수 있는 역할(Owner, Contributor, Storage Account Contributor 등)을 누구에게 주는지도 관리 대상입니다.
더 나아가 스토리지 계정의 "스토리지 계정 키 액세스 허용"을 끄면(AllowSharedKeyAccess = false) 계정 키로 서명한 요청은 모두 거부되고 Entra ID 요청만 통과합니다. 이때 서비스 SAS와 계정 SAS도 함께 막히고, 사용자 위임 SAS만 계속 동작합니다. 키를 쓰는 오래된 도구나 서비스가 함께 멈출 수 있으니 영향 범위를 먼저 확인해야 합니다.
시험 팁: "모든 클라이언트가 Microsoft Entra ID로만 인증하도록 강제"는 Shared Key 액세스를 허용하지 않도록 설정하는 것입니다. 그래도 SAS가 필요하면 사용자 위임 SAS를 고르세요.
---
Azure Files의 ID 기반 액세스
Azure Files를 SMB로 쓰는 직원들은 사무실 파일 서버처럼 자기 계정으로 접속하고, 폴더마다 다른 권한을 받기를 기대합니다. 이를 위해 Azure Files는 Kerberos 기반의 ID 인증을 지원합니다. 저장소 계정 하나에는 아래 ID 원본 중 하나만 쓸 수 있고, 계정 안의 모든 파일 공유에 적용됩니다.
| ID 원본 | 맞는 환경 | |------|------| | 온프레미스 AD DS | 기존 Active Directory가 있고 클라이언트가 도메인 컨트롤러에 연결되는 환경 | | Microsoft Entra Domain Services | Azure에 관리형 도메인을 두고 그 도메인에 VM을 가입시키는 환경 | | Microsoft Entra Kerberos | 도메인 컨트롤러 연결 없이 하이브리드 ID나 클라우드 ID로 접속하는 환경 |
인증이 끝나면 권한은 두 겹으로 확인합니다.
| 단계 | 설정 방법 | 예 | |------|------|------| | 공유 수준 권한 | Azure RBAC 역할 또는 모든 인증된 ID에 주는 기본 공유 수준 권한 | Storage File Data SMB Share Reader / Contributor / Elevated Contributor | | 디렉터리·파일 수준 권한 | Windows ACL (NTFS 권한) | 회계 폴더는 회계팀만 수정 |
두 단계를 모두 통과해야 파일에 접근할 수 있습니다. Microsoft가 가장 안전하다고 안내하는 구성은 공유 수준 권한은 특정 Entra 사용자나 그룹에 주고, 세부 권한은 Windows ACL로 나누는 방식입니다. Entra ID로 동기화되지 않는 AD 계정(컴퓨터 계정 등)은 RBAC를 받을 수 없으므로 기본 공유 수준 권한을 씁니다. 또 SMB는 TCP 445 포트를 쓰므로, 클라이언트 쪽 네트워크가 445 아웃바운드를 막고 있으면 인증 설정과 상관없이 연결되지 않습니다.
시험 팁: "사용자가 파일 공유의 NTFS 권한을 수정할 수 있어야 한다"는 Storage File Data SMB Share Elevated Contributor, "공유에 파일을 읽고 쓰기만"은 Storage File Data SMB Share Contributor입니다.
---
저장 데이터 암호화
출제 범위의 "스토리지 계정 암호화 구성"은 주로 키를 누가 관리하느냐를 묻습니다. Azure Storage의 서버 쪽 암호화(256비트 AES)는 모든 스토리지 계정에 항상 켜져 있고 끌 수 없습니다.
| 선택지 | 내용 | 기억할 점 | |------|------|------| | Microsoft 관리형 키 | 기본값, Microsoft가 키를 관리·회전 | 아무 설정도 필요 없음 | | 고객 관리형 키 | Key Vault 또는 Managed HSM에 있는 내 키로 암호화 | Key Vault에 일시 삭제와 제거 보호가 모두 켜져 있어야 함, 스토리지 계정은 관리 ID로 키에 접근 | | 인프라 암호화 | 인프라 수준에서 한 번 더 암호화 (이중 암호화) | 스토리지 계정을 만들 때만 켤 수 있고 나중에 켜거나 끌 수 없음 | | 암호화 범위 | 컨테이너나 Blob 단위로 다른 키 사용 | 한 계정에 여러 고객 데이터를 나눠 보관할 때 |
시험 팁: "이미 만든 스토리지 계정에 이중 암호화를 켜라"는 요구는 그대로는 불가능합니다. 인프라 암호화를 켠 새 계정을 만들고 데이터를 옮겨야 합니다. "규정상 암호화 키를 직접 회전하고 폐기할 수 있어야 한다"는 고객 관리형 키입니다.