AWS vs Azure – 클라우드 권한 관리 개념 비교

AWS와 Azure는 모두 클라우드 리소스에 대한 권한 관리 기능을 제공하지만, 설계 철학과 구성 방식에 약간의 차이가 있습니다. 아래는 주요 차이점입니다:


🔐 1. 기본 권한 관리 개념

항목AWSAzure
정책 기반 관리IAM 정책(Policy)을 사용자, 그룹, 역할(Role)에 직접 부여RBAC(역할 기반 접근 제어)을 사용해 역할을 리소스에 부여
역할 중심 여부역할과 정책은 분리되어 있음대부분의 권한은 역할(Role)에 의해 관리됨
정책 문법JSON 형식의 세밀한 정책 설정 가능 (허용/거부 명시 가능)Role 정의는 정해진 역할 또는 사용자 정의 역할(JSON 기반)

👥 2. 권한 관리 부여 대상

항목AWSAzure
사용자IAM 사용자Azure AD 사용자
그룹IAM 그룹Azure AD 그룹
역할 기반 접근IAM Role (주체에 대해 위임)Azure Role (정의된 역할을 주체에 할당)
외부 사용자페더레이션, SSO, Cross-Account RoleAzure AD B2B, 외부 테넌트 초대

📄 3. 정책/역할 부여 위치

항목AWSAzure
권한 부여 위치사용자/그룹/Role 단위로 정책을 부여구독, 리소스 그룹, 리소스 수준에서 Role Assignment
상속 구조계정 수준부터 리소스까지 다층 구조상위 리소스 그룹 권한이 하위로 상속됨

🔍 4. 권한 관리 설정 방식 예시

  • AWS 예시:
json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::my-bucket"
    }
  ]
}

Azure 예시 (CLI):

bash

az role assignment create \
  --assignee user@example.com \
  --role "Reader" \
  --scope "/subscriptions/xxx/resourceGroups/my-rg"

🧩 5. 사용자 정의 권한

항목AWSAzure
사용자 정의 정책JSON 기반 IAM 정책 생성사용자 정의 역할 생성 (정해진 권한 집합 사용)
정책의 유연성매우 세밀한 제어 가능 (조건, Tag 등)상대적으로 제한적이나 관리가 쉬움

✅ 6. 요약

항목AWSAzure
접근 제어 모델정책 기반 (Policy Based Access Control, PBAC)역할 기반 (Role Based Access Control, RBAC)
권한 부여 단위사용자/그룹/역할리소스 단위로 역할 부여
정책 표현력매우 유연하고 세밀함관리가 쉽고 직관적임
대표 도구IAM + JSON 정책Azure AD + RBAC 역할

✅ 7. [실무 관점] AWS IAM 권한 부여 절차

📌 A. 권한 설계 절차

  1. 리소스 정의: 어떤 리소스(S3, EC2 등)에 권한을 줄 것인지 결정
  2. 행동 정의: 리소스에서 어떤 작업(List, Get, Put 등)을 허용할 것인지 결정
  3. 정책 작성: JSON 형식의 정책 생성
  4. 정책 연결: 사용자, 그룹, 역할(Role)에 정책 연결
  5. 검증 및 모니터링: IAM Access Analyzer, CloudTrail 등으로 활동 점검

🛠️ B. 실습 예시 (S3 읽기 전용 권한 부여)

json

// s3-read-only-policy.json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-bucket",
        "arn:aws:s3:::my-bucket/*"
      ]
    }
  ]
}
bash

# 정책 생성
aws iam create-policy --policy-name S3ReadOnly --policy-document file://s3-read-only-policy.json

# 사용자 생성
aws iam create-user --user-name test-user

# 정책 연결
aws iam attach-user-policy --user-name test-user --policy-arn arn:aws:iam::<account-id>:policy/S3ReadOnly

✅ 8. [실무 관점] Azure RBAC 권한 부여 절차

📌 A. 권한 설계 절차

  1. 리소스 스코프 정의: 구독, 리소스 그룹, 리소스 단위 중 어디에 권한을 줄지 결정
  2. 역할(Role) 선택 또는 정의: Reader, Contributor, Owner 등 기본 역할 또는 사용자 정의 역할
  3. 주체(Assignee) 선택: 사용자, 그룹, 서비스 주체
  4. 역할 할당: az role assignment create 또는 포털에서 설정
  5. 검증: az role assignment list, 액세스 리뷰 등

🛠️ B. 실습 예시 (Reader 역할 부여)

ash

# 사용자에게 리소스 그룹 읽기 전용 권한 부여
az role assignment create \
  --assignee user@example.com \
  --role "Reader" \
  --scope "/subscriptions/<sub-id>/resourceGroups/my-rg"

🔍 포털에서도 “IAM(액세스 제어)” → “역할 할당 추가”로 설정 가능


🎯 9. Best Practices 비교

항목AWS Best PracticeAzure Best Practice
최소 권한 원칙필요한 권한만 명시정해진 역할 중 최소 권한 사용
권한 상속 관리정책은 상속되지 않음, 명시적 부여리소스 그룹에 설정 시 하위 리소스에 상속됨
태그 기반 제어정책에서 Condition으로 태그 기반 접근 제어Azure에서는 사용자 정의 역할에 제한적 적용 가능
모니터링CloudTrail, Access AnalyzerAzure Monitor, Access Reviews, PIM
정책 관리정책을 분리, 재사용 구조로 관리역할 중심이므로 정의된 역할 재사용 권장

Leave a Reply

Your email address will not be published. Required fields are marked *

error: Content is protected !!