Azure 보안 용어집: 실습형 PoC 전에 알아둘 핵심 개념

첫 Azure 보안 실습에서 가장 어려운 일은 Portal의 버튼을 찾는 것이 아니다. Identity, resource, policy와 alert가 각각 어느 경계에서 관리되는지 구분하는 일이다.

Azure 보안은 플랫폼을 서로 연결된 세 영역으로 나누면 훨씬 이해하기 쉽다.

Identity와 접근 제어   -> Microsoft Entra
Resource와 거버넌스   -> Azure Resource Manager
탐지와 대응           -> Defender for Cloud + Microsoft Sentinel

이 글은 실습형 PoC 전에 꼭 구분해야 하는 용어만 원본 용어집에서 압축해 정리한다. AWS 비교는 이해를 돕는 가장 가까운 비유일 뿐, 서비스가 완전히 같다는 뜻은 아니다.

1. 먼저 경계를 구분한다

Microsoft Entra tenant와 directory

Microsoft Entra tenant는 사용자, 그룹, 디바이스, 애플리케이션 및 Identity 정책을 담는 독립된 ID 경계다. Azure Portal 문맥에서 directory는 대체로 이 tenant를 Identity 데이터 관점에서 부르는 표현이다.

Work or school account는 tenant 안에 존재하는 Identity다. 리소스와 비용 경계인 AWS account와는 의미가 다르다.

Azure subscription

Azure subscription은 비용 청구와 리소스 관리 범위이며 Azure role을 할당할 수 있는 범위 중 하나다.

각 subscription은 Identity를 제공하는 Microsoft Entra tenant 하나를 신뢰한다. 하나의 tenant는 여러 subscription에 Identity를 제공할 수 있다. 따라서 tenant의 Global Administrator라고 해서 모든 subscription의 Owner가 되는 것은 아니며, subscription Owner도 자동으로 tenant의 Global Administrator가 되지 않는다.

Management group, resource group과 resource

Azure resource 계층은 다음과 같다.

Management group
  -> Subscription
    -> Resource group
      -> Resource

• Management group은 여러 subscription에 거버넌스와 접근 기준을 적용한다.
• Resource group은 관리 목적이나 수명주기가 비슷한 resource를 묶는다.
• Resource는 VM, VNet, Key Vault, Log Analytics workspace 같은 실제 서비스 인스턴스다.

Resource group은 수명주기 관리에는 유용하지만 그 자체로 네트워크 또는 보안 격리 경계가 되는 것은 아니다.

2. Authentication과 authorization을 분리한다

**Authentication(인증)**은 “당신이 누구인가?”에 답하고, **authorization(권한 부여)**은 “무엇을 할 수 있는가?”에 답한다.

Microsoft Entra ID가 사용자를 인증하고 token을 발급한 뒤, Azure role-based access control이 그 Identity가 Storage Account를 읽거나 VM을 재시작하거나 Key Vault를 변경할 수 있는지 판단한다.

이 차이를 이해하면 다음 두 역할 체계도 쉽게 구분할 수 있다.

통제	관리 대상	역할 예시
Microsoft Entra role	Directory object와 Identity 설정	User Administrator
Azure RBAC role	정의된 범위의 Azure resource	Reader, Contributor, Owner

Azure role assignment는 다음 세 요소로 기억하면 된다.

security principal + role definition + scope

Scope는 management group, subscription, resource group 또는 개별 resource가 될 수 있다. 업무를 수행할 수 있는 가장 좁은 role과 scope를 선택한다.

3. 로그인과 특권 접근을 보호한다

Multifactor authentication

**Multifactor authentication(MFA)**은 서로 다른 종류의 인증 요소를 두 개 이상 요구한다. 같은 종류의 비밀값을 두 번 묻는 방식이 아니며 passwordless 인증 방식도 포함할 수 있다.

Conditional Access

Conditional Access는 Microsoft Entra의 Zero Trust 정책 엔진이다. 사용자, 대상 리소스, 디바이스, 위치, client 및 risk 신호를 평가해 접근 허용, MFA 같은 추가 통제 요구, session 제한 또는 차단을 결정한다.

PoC에서는 전용 pilot group과 report-only 평가로 시작한다. 처음부터 모든 사용자와 모든 리소스를 대상으로 하지 않는다. 강제 적용은 sign-in 결과 관찰, emergency access 검증 및 rollback 문서화를 마친 뒤 별도 변경으로 처리한다.

Privileged Identity Management

**Privileged Identity Management(PIM)**은 상시 관리자 권한을 줄이는 서비스다. Eligible user는 필요할 때만 특권 role을 활성화하고, 구성과 라이선스에 따라 제한 시간, 사유 입력, MFA 또는 승인 통제를 적용할 수 있다.

Emergency access account

Emergency access account는 일반 관리자 로그인이 실패했을 때 사용하는 복구 경로이며 흔히 break-glass account라고도 부른다. Cloud-only로 유지하고, 사용을 엄격히 모니터링하며, 전체 lockout을 일으킬 수 있는 정책에서 제외하고, 평소 업무에 사용하지 않은 채 정기적으로 검증해야 한다.

4. 거버넌스와 보안 태세 관리를 혼동하지 않는다

Azure Policy

Azure Policy는 Azure resource가 조직 표준을 준수하는지 평가한다. Policy definition이 규칙을 설명하고, assignment가 적용 범위를 지정하며, effect가 Audit, Deny, Modify 또는 DeployIfNotExists 같은 동작을 결정한다.

허용되지 않은 region의 resource를 감사하거나 특정 서비스의 public network 노출을 거부하는 것이 예다. AWS와 비교하면 Azure Policy는 AWS Organizations SCP와 AWS Config의 역할을 일부 결합한 영역에 가깝다.

Microsoft Defender for Cloud

Microsoft Defender for Cloud는 cloud security posture를 평가하고, 관련 plan을 활성화한 경우 지원되는 workload를 보호한다. Recommendation은 구성과 위험 개선 기회를 보여주며 그 자체가 실제 공격이 발생했다는 alert는 아니다.

Defender for Cloud secure score는 보안 태세 개선 기회를 수치로 요약한다. 점수는 개선 우선순위를 정하는 데 도움이 되지만 무침해 상태나 가장 중요한 attack path 제거를 증명하지 않는다.

두 서비스의 차이는 다음처럼 기억할 수 있다.

Azure Policy       -> 어떤 구성을 허용하거나 요구할 것인가?
Defender for Cloud -> 어떤 보안 태세와 workload 위험을 먼저 개선할 것인가?

5. Platform event에서 조사까지의 흐름을 본다

Activity Log, diagnostic setting과 DCR

Azure Activity Log는 관리 작업뿐 아니라 Policy, Service Health 및 Resource Health 등을 포함한 subscription 수준 control-plane event를 기록한다.

Diagnostic setting은 지원되는 platform log와 metric을 Log Analytics, Storage 또는 Event Hubs 같은 대상으로 보낸다. **Data collection rule(DCR)**은 Azure Monitor Agent, custom log 등 지원되는 source의 수집 pipeline, transformation 및 destination을 정의한다. 목적은 겹쳐 보이지만 서로 대체 가능한 같은 설정은 아니다.

Log Analytics workspace와 KQL

Log Analytics workspace는 Azure Monitor와 Microsoft Sentinel이 사용하는 log data를 저장하고 query한다. **Kusto Query Language(KQL)**는 이 데이터를 필터링하고, 연결하고, 요약해 조사하는 query language다.

AzureActivity
| where TimeGenerated > ago(1h)
| summarize Operations = count() by ActivityStatusValue

이 예시는 실제 호출자나 resource 식별자를 공개하지 않고 최근 Activity Log를 상태별로 요약한다.

Microsoft Sentinel

Microsoft Sentinel은 Microsoft의 cloud-native SIEM 및 보안 운영 플랫폼이다. 여러 cloud와 on-premises source의 보안 데이터를 연결하고, 탐지, hunting, 조사 및 대응을 지원한다.

기본 탐지 흐름은 다음과 같다.

Data connector
  -> Log Analytics data
    -> Analytics rule
      -> Alert
        -> Incident

• Analytics rule은 데이터에서 의심 조건을 평가한다.
• Alert는 규칙 또는 연결된 보안 제품이 만든 개별 신호다.
• Incident는 관련 alert와 증적을 하나의 조사 단위로 묶는다.
• Entity는 조사 대상으로 매핑한 사용자, host, IP, file 등의 object다.

대응 단계에서 automation rule은 지원되는 incident 또는 alert trigger가 언제 action을 실행할지 결정한다. Playbook은 Azure Logic Apps로 구현한 대응 workflow다. 계정 비활성화 같은 고위험 action은 학습용 PoC에서도 명시적 승인과 rollback 기준을 두는 편이 안전하다.

6. 저장된 secret보다 workload identity를 우선한다

Service principal은 tenant 안에서 application을 나타내는 local security principal이다. Managed identity는 Azure resource를 위해 Azure가 관리하는 Identity로, workload가 client secret을 코드에 저장하지 않고 token을 요청할 수 있게 한다.

Azure Key Vault는 secret, 암호화 key 및 certificate를 보관하고 접근을 통제한다. 권장 순서는 다음과 같다.

가능하면 managed identity 사용
  -> 필요한 Key Vault 권한만 부여
    -> secret이 불가피할 때만 실행 시점에 조회

Credential을 Terraform state, Git history, pipeline log, screenshot 또는 공개 실습 증적에 넣지 않는다.

7. AWS 비교는 근사치로만 사용한다

Azure 개념	가장 가까운 AWS 학습 비유	중요한 차이
Microsoft Entra tenant	IAM Identity Center directory와 organization 문맥	AWS에는 동일한 단일 tenant object가 없음
Azure subscription	AWS account	비용, Identity trust 및 계층 모델이 다름
Management group	Organizations OU	정책 종류와 상속 모델이 다름
Resource group	Resource Groups, tag 및 stack	AWS에는 동일한 필수 부모 container가 없음
Azure RBAC	IAM role, policy 및 permission set	평가와 resource policy 모델이 다름
Azure Policy	SCP와 AWS Config	AWS에서는 Deny와 Audit 역할이 나뉨
Defender for Cloud	Security Hub CSPM, GuardDuty, Inspector 등	Azure는 posture와 workload protection을 한 제품군으로 제공
Microsoft Sentinel	Security Lake, Security Hub, 자동화 및 SIEM	완전한 단일 대응 서비스가 없음
Managed identity	Instance profile, task role 또는 Lambda execution role	서비스별 연결과 token 흐름이 다름

이 비교는 기존 지식을 옮기는 데는 유용하지만, 실제 architecture는 각 cloud의 권한과 resource model을 기준으로 설계해야 한다.

8. 기억해야 할 10문장

1. Tenant는 Identity 경계이고 subscription은 resource와 비용 범위다.
2. Directory는 Portal 문맥에서 대체로 Entra tenant를 뜻한다.
3. Microsoft Entra role은 directory를, Azure role은 Azure resource를 관리한다.
4. Authentication은 Identity를 증명하고 authorization은 허용된 action을 부여한다.
5. Conditional Access는 sign-in 신호를 평가하고 PIM은 상시 특권을 줄인다.
6. Azure Policy는 표준을 평가하고 Defender for Cloud는 posture와 workload 위험을 우선순위화한다.
7. Activity Log는 control-plane event를 기록하고 diagnostic setting과 DCR은 지원되는 telemetry를 전달한다.
8. Log Analytics는 query 가능한 log를 저장하고 KQL은 이를 증적으로 바꾼다.
9. Analytics rule은 alert를 만들고 관련 alert는 incident로 묶일 수 있다.
10. Automation rule은 대응을 조정하고 playbook은 Logic Apps workflow를 실행한다.

안전한 첫 PoC 순서

먼저 올바른 tenant와 subscription을 확인한다. 범위를 제한한 resource group, tag, budget 및 audit 중심 거버넌스를 만든다. Identity 정책은 pilot group과 report-only로 시험한다. 최소 log 경로를 확보한 뒤 KQL 탐지를 만들고, 마지막에 탐지를 incident와 되돌릴 수 있는 대응 workflow에 연결한다.

목표는 제품 이름을 외우는 것이 아니다. 각 통제가 어떤 위험을 줄이고, 어느 경계에서 동작하며, 무엇을 증적으로 확인해야 하는지 설명할 수 있어야 한다.

References

• Azure subscription과 Microsoft Entra ID의 연결 관계
• Microsoft Entra Conditional Access 개요
• Azure role-based access control 개요
• Azure Policy 개요
• Defender for Cloud secure score
• Microsoft Sentinel 개요