AWS와 Azure를 함께 쓰는 조직에서는 "이 사람이 무엇을 할 수 있는가"라는 질문을 두 곳에서 따로 확인해야 합니다. 이 글은 새로 화면을 연 것이 아니라, 이미 올린 실습 글에서 직접 읽은 화면만 모아 같은 질문으로 나란히 놓은 비교입니다. 직접 보지 못한 항목은 확인하지 않은 대응 표에 따로 모았고, 문서에 근거한 설명은 그렇다고 적었습니다.
근거가 된 글은 다음과 같습니다.
- AWS: IAM 정책 시뮬레이터 읽기, EC2에 IAM 역할 연결, IAM 정책 JSON과 시뮬레이터, IAM 비밀번호 정책과 보안 상태 읽기
- Entra ID: 사용자와 그룹 읽기, 관리자 역할 읽기, 보안 기본값 읽기, 앱 등록과 자격 증명 만료 읽기
먼저 이름 문제가 있습니다. 같은 역할이라는 말이 AWS에서는 사람이나 서비스가 맡아 쓰는 신원(IAM 역할)이고, Entra ID에서는 관리 권한을 묶어 둔 목록(관리자 역할)이라 뜻이 다릅니다. 두 서비스는 제품 구조가 달라서 화면이 일대일로 대응하지 않습니다. 아래 표는 같은 질문에 답하는 화면을 짝지은 것이며, 기능이 똑같다는 뜻은 아닙니다.
1. 한눈에 보는 대응표
| 질문 | AWS IAM에서 본 것 | Entra ID에서 본 것 |
|---|---|---|
| 사람 계정은 어디서 보는가 | IAM 사용자 목록. 마지막 활동, MFA, 암호 수명 열이 점검 단서였습니다 |
사용자 목록. 사용자 계정 이름, 사용자 유형(구성원, 게스트), 온-프레미스 동기화 열이 있었습니다 |
| 계정 수 현황 | IAM 대시보드의 리소스 칸에 사용자 17, 역할 40, 사용자 그룹 0, 정책 1이 표시되었습니다 | 사용자 목록에 14행이 보였고 그룹은 26개로 표시되었습니다(서로 다른 환경의 값) |
| 권한을 묶는 단위 | 이 AWS 계정에는 사용자 그룹이 0개였습니다. 권한은 정책을 사용자나 역할에 붙이는 방식으로 보였습니다 | 그룹이 26개였고, 화면에 보인 12행은 유형이 Microsoft 365와 보안, 멤버십 유형이 할당됨이었습니다 |
| 권한을 부여하는 단위(층위가 다름) | 정책 JSON의 Effect, Action, Resource. 허용 문이 없으면 시뮬레이터에서 암묵적 거부로 표시되었습니다 |
관리자 역할 목록. 역할마다 이름, 설명, 권한 있음 배지, 할당 수(과제)가 있었습니다. 권한을 적는 방식은 이 목록에서 보지 못했습니다 |
| 기계가 쓰는 신원(같은 종류가 아님) | IAM 역할. EC2에 역할을 붙이고 신뢰 정책과 권한 정책을 나눠 읽었습니다. 장기 액세스 키를 쓰는 IAM 사용자는 이 실습에서 열지 않았습니다 | 앱 등록. 인증서 및 암호 열에 만료됨, - 같은 표시가 있었습니다. 키 없이 쓰는 관리 ID는 이 실습에서 보지 않았습니다 |
| 자격 증명 점검 | 보안 인증 보고서 화면(보고서는 내려받지 않았습니다)과 IAM 대시보드의 보안 권장 사항 칸 | 앱 등록 목록의 인증서 및 암호 열, 사용자 상세의 인증 방법 메뉴(메뉴 이름만 확인) |
| 계정 전체 기본 보호(성격이 다름) | 계정 설정의 암호 정책. 기본 정책은 최소 8자, 만료 없음이었습니다 | 속성의 보안 기본값. 이 테넌트에서는 꺼져 있다는 경고가 있었습니다. Entra ID의 암호 정책 화면은 이 실습에서 보지 않았습니다 |
2. 사용자와 그룹
두 서비스 모두 사람 계정을 목록으로 보여 주고, 점검할 때 먼저 볼 열이 있습니다. AWS 쪽은 마지막 활동과 MFA, 암호 수명처럼 쓰임을 보여 주는 열이 중심이었고, Entra ID 쪽은 사용자 유형이 중심이었습니다. 사용자 유형은 조직 안의 계정인 구성원과 외부에서 초대한 게스트를 나눕니다. AWS IAM 사용자 목록에서 외부 사용자를 나누는 같은 열은 이 실습에서 보지 못했습니다. 반대로 Entra ID에서는 마지막 활동이나 MFA 열을 사용자 목록에서 읽지 못했고(인증 방법과 로그인 로그 메뉴는 이름만 확인했습니다), 두 서비스의 점검 열이 같지 않습니다.
그룹은 차이가 컸습니다. 이 실습의 AWS 계정은 사용자 그룹이 0개였고, 읽은 Entra ID 테넌트는 그룹이 26개였습니다. 두 환경은 규모와 구성이 서로 달라서 이 차이를 서비스 설계의 차이로 읽으면 안 됩니다. 확실히 말할 수 있는 것은 두 서비스 모두 그룹이라는 단위를 가지고 있고, 권한을 그룹에 붙이는 편이 사람이 팀을 옮길 때 관리하기 쉽다는 설명이 Entra ID 글(Microsoft 문서 기준)에 있다는 점까지입니다. AWS에서 정책을 그룹에 붙였을 때의 화면은 이 실습에서 확인하지 않았습니다.
3. 권한을 적는 방식
AWS에서는 정책 JSON이 권한의 본체입니다. 한 문장이 Effect(허용 또는 거부), Action, Resource로 이루어지고, 시뮬레이터에서 작업과 리소스를 넣어 보면 허용인지 암묵적 거부인지 계산해 줍니다. 허용 문이 없으면 거부된다는 기본 규칙을 화면으로 확인했습니다.
Entra ID에서 읽은 것은 관리자 역할이었습니다. 역할은 미리 정의된 기본 제공 역할이 목록으로 나오고, 권한 있음 배지가 권한 상승으로 이어질 수 있는 역할을 표시했습니다. 사용자별 할당 화면에서 적격 할당과 활성 할당 탭 이름을 확인했고 활성 할당 탭은 비어 있었습니다(적격 할당은 PIM이 있어야 쓴다는 설명은 문서 기준이고 적격 할당 탭은 열지 않았습니다).
두 방식은 용도가 다릅니다. AWS 정책은 서비스와 리소스 단위로 허용 범위를 직접 쓰는 방식이고, 이 글에서 읽은 Entra ID 역할은 Entra ID와 Microsoft 365 일부 서비스의 관리 작업을 묶어 둔 목록입니다(문서 기준, 목록의 가상 방문 관리자는 Microsoft 365 쪽 역할로 보입니다). Azure 리소스(VM, 스토리지 등)에 대한 권한은 Azure의 역할 기반 접근 제어(RBAC)에서 따로 다루며, 이 실습에서는 그 화면을 열지 않았습니다. 따라서 "AWS 정책 대 Entra ID 역할"을 같은 층위로 비교하면 안 됩니다. 가장 가까운 대응은 AWS 정책과 Azure RBAC이지만, 이 글에서는 Azure 쪽을 직접 보지 못했습니다.
4. 기계가 쓰는 신원
AWS에서는 EC2 같은 서비스가 쓰는 신원을 IAM 역할로 만들고, 역할에 두 가지를 둡니다. 누가 이 역할을 맡을 수 있는지 정하는 신뢰 정책과, 맡은 뒤 무엇을 할 수 있는지 정하는 권한 정책입니다. 이 글들에서는 역할을 인스턴스에 연결해 액세스 키 없이 쓰도록 구성하는 과정을 읽었습니다. 인스턴스에서 실제로 S3를 읽는 것까지는 시험하지 않았습니다.
Entra ID에서는 앱 등록이 코드와 자동화의 신원입니다. 목록에서 읽을 수 있었던 핵심은 인증서 및 암호 열의 만료 상태였습니다. 28개 앱 중 일부에 만료됨이 붙어 있었습니다. 다만 이 둘은 같은 종류의 신원이 아닙니다. 키 없이 인스턴스가 맡아 쓰는 EC2 IAM 역할과 더 가까운 Entra ID 쪽 대응은 관리 ID(문서 기준)이고, 클라이언트 암호를 쓰는 앱 등록과 더 가까운 AWS 쪽은 장기 액세스 키를 가진 IAM 사용자로 알려져 있습니다. AWS에도 액세스 키의 교체 점검이 필요하며 보안 인증 보고서에 그 항목이 있다고 앞선 글에 적었습니다. 관리 ID 화면과 IAM 사용자의 액세스 키 화면은 이 실습에서 열지 않았으니 이 부분은 짝을 맞춘 비교가 아닙니다.
5. 기본 보호 설정
AWS 계정 설정의 암호 정책은 기본값이 최소 8자, 대문자와 소문자, 숫자, 영숫자 외 문자 중 3종류 이상, 만료 없음이었습니다. 사용자 지정으로 바꾸면 최소 길이와 문자 종류, 만료, 재사용 제한 같은 항목을 고를 수 있었습니다.
Entra ID의 보안 기본값은 테넌트 전체에 Microsoft 권장 보호를 한꺼번에 켜는 스위치로 보였습니다. 이 테넌트에서는 꺼져 있었고 패널의 선택지는 사용(권장)과 비활성화(권장하지 않음) 두 가지였습니다. 두 화면은 성격이 다릅니다. AWS 암호 정책은 비밀번호 규칙을 세부 항목으로 정하고, Entra ID 보안 기본값은 묶음 단위로 켜고 끕니다. Entra ID에도 비밀번호 관련 정책이 있는 것으로 알려져 있으나 이 실습에서 그 화면은 보지 않았으므로, 위 설명은 두 화면의 성격 차이만 말한 것입니다. AWS에서 MFA를 계정 전체에 강제하는 같은 스위치가 있는지는 이 실습에서 확인하지 않았습니다. 또 Entra ID 보안 기본값이 구체적으로 무엇을 요구하는지는 문서에서 확인해야 하며 이 글에서 시험하지 않았습니다.
6. 두 곳을 함께 점검할 때의 순서
직접 읽은 화면을 바탕으로 정리한 점검 순서입니다.
- 계정 수와 구조: AWS는 IAM 대시보드의 리소스 칸, Entra ID는 사용자와 그룹 목록에서 현황을 봅니다.
- 사람 계정의 상태: AWS는 마지막 활동과 MFA 열을 읽었습니다. Entra ID는 이 실습에서 같은 점검을 하지 못했고 사용자 유형과 동기화 열만 읽었습니다.
- 관리자 권한: AWS는 사용자에게 붙은 정책을 권한 탭에서 읽고 시뮬레이터로 평가하며, Entra ID는 관리자 역할 목록의
권한 있음배지와 할당 수를 봅니다. - 기계가 쓰는 신원: AWS는 역할의 신뢰 정책과 권한 정책, Entra ID는 앱 등록의 인증서 및 암호 열을 봅니다.
- 전체 기본 보호: AWS는 계정 설정의 암호 정책, Entra ID는 보안 기본값 상태를 봅니다.
확인하지 않은 대응
아래 항목은 직접 화면을 열지 못했거나 서로 대응하는 화면을 보지 못했습니다.
| 항목 | 이유 |
|---|---|
| Azure 리소스에 대한 RBAC 역할 할당 | 이 실습에서는 화면을 열지 않았습니다 |
| Entra ID 관리 ID와 AWS IAM 사용자의 액세스 키 | 두 화면 모두 이 실습에서 열지 않았습니다 |
| Entra ID 조건부 액세스와 AWS의 조건 키 | 조건부 액세스 화면은 접근 권한 오류로 열리지 않았습니다 |
| 로그인과 감사 기록의 대응 | Entra ID 로그인 로그와 감사 로그 메뉴는 메뉴 이름만 확인했고 내용 화면은 열지 않았습니다. AWS는 CloudTrail 이벤트 기록 읽기에서 읽었습니다 |
| 외부 ID 연동(AWS IAM Identity Center와 Entra ID) | 이 실습에서 다루지 않았습니다 |
| 라이선스 등급에 따른 기능 차이 | Entra ID 라이선스는 정확한 값을 확인하지 않았습니다. 사용자 지정 역할이 P1 이상을 요구한다는 안내는 화면에서 읽었고, 그룹에 역할을 할당하는 기능의 요건은 문서에서 읽었습니다 |
읽을 때 주의할 점
- 이 비교는 서로 규모와 구성이 다른 실습 환경 두 곳에서 읽은 값을 놓은 것입니다. 숫자(사용자 수, 그룹 수 등)를 두 서비스의 우열로 읽으면 안 됩니다.
- 표의
본 것은 해당 글의 화면에서 직접 읽은 내용으로 한정했고, 문서 기준인 부분은 괄호로 표시했습니다. 화면 문구는 각 글의 실습 시점의 한국어 콘솔 기준입니다. - 문서에 근거한 설명(적격 할당의 PIM 요건, 사용자 지정 역할의 라이선스 요건, 관리 ID 같은 대안)은 이 실습에서 직접 시험하지 않았습니다.
이어서 해 볼 것
- 두 서비스 모두에서 관리자 권한을 가진 계정이 MFA를 쓰는지 확인하는 점검표를 만들어 봅니다
- Azure RBAC 역할 할당 화면을 열 수 있으면 이 글의
확인하지 않은 대응첫 줄을 채워 봅니다 - 같은 방식으로 네트워크 계층(보안 그룹과 네트워크 보안 그룹)과 로그 계층의 대응표도 만들어 봅니다
이 글의 다음 단계
- AWS Budgets로 월별 비용 예산과 알림 만들고 지우기AWS Budgets의 월별 비용 예산 템플릿으로 월 10달러 예산을 만들고, 템플릿이 자동으로 붙이는 세 가지 알림 조건과 이메일 수신자의 인증 대기 상태를 화면에서 읽습니다. 확인이 끝나면 예산을 삭제합니다.
- AWS CloudTrail 이벤트 기록에서 누가 언제 무엇을 했는지 읽기CloudTrail 이벤트 기록 화면에서 최근 변경 이벤트를 보고, 리소스 이름으로 걸러 한 보안 그룹의 생성부터 삭제까지를 추적합니다. 이벤트 상세와 JSON 레코드에서 사용자, 시각, 호출 내용, MFA 여부를 읽는 방법을 정리합니다.