Azure ID, 액세스 및 보안 설명

 

Azure ID, 액세스 및 보안 설명

Azure의 아이디(ID)와 액세스 관리 기능은 클라우드 환경에서 각종 데이터 및 리소스에 대한 접근을 안전하게 제어하는 데 필수적입니다. 이 시스템은 사용자, 기기 및 소프트웨어가 적시에 적절한 리소스에 접근할 수 있도록 보장합니다.

Azure Entra ID

Azure Entra ID(이전 Azure Active Directory, Azure AD)는 Microsoft의 클라우드 기반 ID 및 액세스 관리 서비스로, 기업이 통합된 방식으로 사용자 아이디를 관리하도록 지원합니다. Entra ID는 다수의 안전한 인증 방법을 제공하며, 이를 통해 조직은 보안성을 높일 수 있습니다. 예를 들어, 단일 로그인(SSO) 기능을 통해 사용자는 여러 애플리케이션에 대해 한번의 로그인으로 접근할 수 있습니다. 또한 다단계 인증(MFA)을 통해 추가적인 보안 계층을 제공하여, 사용자 계정의 보호를 강화합니다17.

액세스 제어 메커니즘

Azure는 역할 기반 액세스 제어(RBAC)를 통해 리소스에 대한 접근을 세밀하게 관리할 수 있습니다. RBAC는 권한을 역할에 부여하고, 이러한 역할을 사용자에게 할당하여 리소스에 대한 접근을 제어합니다. 이로 인해 관리자는 각 사용자에게 필요한 최소한의 권한만을 부여하여 보안 사고의 위험을 줄일 수 있습니다34.

보안 모범 사례

Microsoft는 Azure의 ID 관리 및 액세스 제어에 대한 여러 보안 모범 사례를 제공합니다. 이 문서에서는 관련 기능을 활용하여 ID 관리 및 액세스를 강력하게 구축하는 방법에 대해 설명하고 있습니다. 예를 들어, 주기적인 권한 검토 및 감사 로그를 통해 비정상적인 활동을 모니터링하고 신속하게 대응하는 것이 권장됩니다24.

결론

Azure ID 및 액세스 관리 기능은 조직의 보안을 강화하고, 사용자 경험을 향상시키는 중요한 요소입니다. Microsoft의 다양한 기능을 통해 효과적으로 ID를 관리하고, 제어할 수 있는 환경을 조성할 수 있습니다.

---

Azure ID 관리 및 보안에 대한 추가적인 모범 사례로는 다음과 같은 요소들이 포함됩니다.

• 조건부 액세스: 사용자가 리소스에 접근할 때 다양한 조건(위치, 디바이스 상태 등)에 따라 접근 권한을 제어할 수 있습니다. 이를 통해 보안 정책을 강화하고 위험을 줄일 수 있습니다.
• 정기 보안 강화 계획: IT 관리자는 정기적으로 보안 검토 및 강화를 위한 계획을 세워야 하고, ID 보안 점수를 사용해 개선 방법을 평가하는 것이 좋습니다.
• 중앙 집중식 ID 관리: 온-프레미스 디렉터리와 클라우드 디렉터리를 통합하여 사용자 계정을 중앙에서 관리하고, 이를 통해 사용자 접근성을 높이고 관리의 복잡성을 줄일 수 있습니다.
• 다단계 인증 적용: 모든 사용자, 특히 관리자에 대해서는 다단계 인증을 필수적으로 요구하는 것이 권장됩니다. 이를 통해 계정 탈취 시도에 대한 보안성을 대폭 강화할 수 있습니다.

이러한 추가적인 보안 수칙을 통해 Azure의 ID 관리 체계는 한층 더 robust한 보안을 구축할 수 있습니다.

 

Azure 디렉터리 서비스 설명

 

Microsoft Entra ID는 Microsoft 클라우드 애플리케이션과 개발하는 클라우드 애플리케이션 모두에 로그인하고 액세스할 수 있는 디렉터리 서비스입니다. Microsoft Entra ID에서 온-프레미스 Active Directory 배포를 유지 관리하는 데도 도움이 될 수 있습니다.

온-프레미스 환경의 경우 Windows Server에서 실행되는 Active Directory는 조직에서 관리하는 ID 및 액세스 관리 서비스를 제공합니다. Microsoft Entra ID는 Microsoft의 클라우드 기반 ID 및 액세스 관리 서비스입니다. Microsoft Entra ID를 사용해 ID 계정을 관리하며 Microsoft에서 해당 서비스를 전역적으로 사용할 수 있도록 지원합니다. Active Directory를 사용해 왔다면 Microsoft Entra ID가 익숙할 것입니다.

Active Directory를 사용하여 온-프레미스에서 ID를 보호하는 경우 Microsoft는 로그인 시도를 모니터링하지 않습니다. Microsoft Entra ID와 Active Directory를 연결하는 경우 Microsoft는 추가 비용 없이 의심스러운 로그인 시도를 감지하여 사용자를 보호할 수 있습니다. 예를 들어 Microsoft Entra ID는 예기치 않은 위치 또는 알 수 없는 디바이스에서의 로그인 시도를 감지할 수 있습니다.

Microsoft Entra ID는 누가 사용하나요?

Microsoft Entra ID는 다음을 위한 것입니다.

• IT 관리자 관리자는 Microsoft Entra ID를 사용하여 비즈니스 요구 사항에 따라 애플리케이션 및 리소스에 대한 액세스를 제어할 수 있습니다.
• 앱 개발자 개발자는 Microsoft Entra ID를 사용하여 앱에 SSO 기능을 추가하거나 사용자의 기존 자격 증명을 사용하여 앱을 사용할 수 있도록 설정하는 등 자신이 빌드하는 애플리케이션에 기능을 추가하는 표준 기반 접근 방식을 제공할 수 있습니다.
• 사용자. 사용자는 ID를 관리하고 셀프 서비스 암호 재설정과 같은 유지 관리 작업을 수행할 수 있습니다.
• 온라인 서비스 구독자 Microsoft 365, Microsoft Office 365, Azure 및 Microsoft Dynamics CRM Online 구독자는 이미 Microsoft Entra ID를 사용하여 계정을 인증하고 있습니다.

Microsoft Entra ID는 무엇을 하나요?

Microsoft Entra ID는 다음과 같은 서비스를 제공합니다.

• 인증: 여기에는 애플리케이션 및 리소스에 액세스하기 위한 ID 확인이 포함됩니다. 셀프 서비스 암호 재설정, 다단계 인증, 금지된 암호의 사용자 지정 목록 및 스마트 잠금 서비스와 같은 기능도 포함됩니다.
• Single Sign-On: SSO를 사용하면 한 가지 사용자 이름과 한 가지 암호만 기억하면 여러 애플리케이션에 액세스할 수 있습니다. 한 ID가 한 사용자에게 연결되므로 보안 모델이 간소화됩니다. 사용자 역할이 변경되거나 사용자가 조직을 떠날 때 액세스 수정이 해당 ID에 연결되어 있으므로 계정을 변경하거나 비활성화하는 과정이 대폭 축소됩니다.
• 애플리케이션 관리: Microsoft Entra ID를 사용하여 클라우드 및 온-프레미스 앱을 관리할 수 있습니다. 애플리케이션 프록시, SaaS 앱, My Apps 포털, Single Sign-On 등의 기능이 더 나은 사용자 환경을 제공합니다.
• 장치 관리: Microsoft Entra ID는 개별 사용자의 계정뿐만 아니라 디바이스 등록도 지원합니다. 디바이스를 등록하면 Microsoft Intune과 같은 도구를 통해 디바이스를 관리할 수 있습니다. 또한 디바이스 기반 조건부 액세스 정책을 통해 요청하는 사용자 계정에 관계없이 이전에 접속했던 디바이스의 액세스 시도만 허용할 수 있습니다.

온-프레미스 AD를 Microsoft Entra ID와 연결할 수 있나요?

Active Directory를 실행하는 온-프레미스 환경과 Microsoft Entra ID를 사용하는 클라우드 배포가 있는 경우 두 개의 ID 집합을 유지 관리해야 합니다. 그러나 Active Directory를 Microsoft Entra ID에 연결하여 클라우드와 온-프레미스 간에 일관된 ID 환경을 사용할 수 있습니다.

Microsoft Entra ID를 온-프레미스 AD와 연결하는 한 가지 방법은 Microsoft Entra Connect를 사용하는 것입니다. Microsoft Entra Connect는 온-프레미스 Active Directory와 Microsoft Entra ID 간에 사용자 ID를 동기화합니다. Microsoft Entra Connect는 두 ID 시스템 간에 변경 내용을 동기화하므로 SSO, 다단계 인증 및 셀프 서비스 암호 재설정과 같은 기능을 사용할 수 있습니다.

Microsoft Entra Domain Services란?

Microsoft Entra Domain Services는 도메인 가입, 그룹 정책, LDAP(Lightweight Directory Access Protocol) 및 Kerberos/NTLM 인증과 같은 관리되는 도메인 서비스를 제공하는 서비스입니다. Microsoft Entra ID 지원 인프라를 유지 관리하지 않고도 디렉터리 서비스를 사용할 수 있는 것처럼 Microsoft Entra Domain Services를 사용하면 클라우드에서 DC(도메인 컨트롤러)를 배포, 관리 및 패치할 필요 없이 도메인 서비스의 이점을 얻을 수 있습니다.

Microsoft Entra Domain Services 관리되는 도메인을 사용하면 최신 인증 방법을 사용할 수 없거나 디렉터리 조회가 항상 온-프레미스 AD DS 환경으로 돌아가는 것을 원하지 않는 클라우드에서 레거시 애플리케이션을 실행할 수 있습니다. 클라우드에서 AD DS 환경을 관리할 필요 없이 레거시 애플리케이션을 온-프레미스 환경에서 관리되는 도메인으로 리프트 앤 시프트할 수 있습니다.

Microsoft Entra Domain Services는 기존 Microsoft Entra 테넌트와 통합됩니다. 이러한 통합을 통해 사용자는 기존 자격 증명을 사용하여 관리되는 도메인에 연결된 서비스 및 애플리케이션에 로그인할 수 있습니다. 또한 기존 그룹 및 사용자 계정을 사용하여 리소스에 대한 액세스를 보호할 수도 있습니다. 이러한 기능은 Azure에 대한 온-프레미스 리소스의 원활한 리프트 앤 시프트를 제공합니다.

Microsoft Entra Domain Services는 어떻게 작동하나요?

Microsoft Entra Domain Services 관리형 도메인을 만들 때 고유한 네임스페이스를 정의합니다. 이 네임스페이스는 도메인 이름입니다. 그런 다음, 두 개의 Windows Server 도메인 컨트롤러가 선택한 Azure 지역에 배포됩니다. 이 DC 배포를 복제본 세트라고 합니다.

이러한 DC를 관리, 구성 또는 업데이트할 필요가 없습니다. Azure 플랫폼은 Azure Disk Encryption을 사용한 저장 데이터 백업 및 암호화를 포함하여 관리되는 도메인의 일부로 DC를 처리합니다.

정보가 동기화되었나요?

관리되는 도메인은 Microsoft Entra ID에서 Microsoft Entra Domain Services로의 단방향 동기화를 수행하도록 구성됩니다. 관리되는 도메인에서 직접 리소스를 만들 수 있지만 Microsoft Entra ID로 다시 동기화되지는 않습니다. 온-프레미스 AD DS 환경이 포함된 하이브리드 환경에서 Microsoft Entra Connect는 ID 정보를 Microsoft Entra ID와 동기화한 다음 관리되는 도메인과 동기화합니다.

그러면 관리되는 도메인에 연결되는 Azure의 애플리케이션, 서비스 및 VM에서 도메인 조인, 그룹 정책, LDAP 및 Kerberos/NTLM 인증과 같은 일반적인 Microsoft Entra Domain Services 기능을 사용할 수 있습니다.

LDAP, Kerberos, NTLM 인증 개요 및 작동 방식

LDAP, Kerberos, NTLM은 모두 사용자 인증 및 리소스 접근 제어를 위한 프로토콜로 사용됩니다. 각 프로토콜은 목적과 작동 방식에서 차이가 있으며, 특정 환경에 따라 적합한 솔루션으로 선택됩니다.

1. LDAP (Lightweight Directory Access Protocol)

개요

• LDAP는 디렉토리 서비스와 통신하기 위한 프로토콜로, 사용자 인증 및 정보 조회를 지원합니다.
• 중앙 집중식 데이터베이스(예: Active Directory)를 통해 사용자 정보와 권한을 관리합니다12.

작동 방식

1. 클라이언트가 LDAP 서버에 사용자 이름과 비밀번호를 제출합니다.
2. LDAP 서버는 디렉토리 데이터베이스에서 해당 정보를 확인합니다.
3. 인증이 성공하면 사용자는 요청한 리소스에 접근할 수 있습니다12.
4. LDAP는 기본적으로 암호화되지 않은 텍스트로 데이터를 전송하지만, SSL/TLS를 사용하여 보안을 강화할 수 있습니다3.

사용 사례

• 웹 애플리케이션 로그인
• 이메일 시스템 인증
• VPN 및 파일 서버 접근 제어9.

보안 강화

• LDAPS(LDAP over SSL/TLS)를 사용하여 데이터 암호화.
• SASL(Authentication and Security Layer)을 통해 Kerberos와 같은 보안 메커니즘 통합 가능3.

2. Kerberos

개요

• Kerberos는 티켓 기반 인증 프로토콜로, 암호화된 티켓을 사용하여 네트워크 상에서 안전하게 사용자 인증을 수행합니다.
• Microsoft Active Directory 환경에서 기본 인증 프로토콜로 사용됩니다45.

작동 방식

1. Authentication Server (AS):
   • 클라이언트가 AS에 요청을 보내고, AS는 사용자의 자격 증명을 확인한 후 **Ticket Granting Ticket (TGT)**를 발급합니다.
2. Ticket Granting Server (TGS):
   • 클라이언트는 TGT를 TGS에 제출하여 서비스 티켓을 요청합니다.
3. Service Ticket (ST):
   • 클라이언트는 ST를 사용해 애플리케이션 서버에 접근하며, 서버는 이를 검증하여 접근을 허가합니다456.

특징

• 암호화된 티켓을 사용하여 패스워드가 네트워크를 통해 전송되지 않습니다.
• 티켓의 유효 기간이 제한되어 있어 보안성을 강화합니다6.

사용 사례

• 대규모 네트워크 환경
• Active Directory 기반 시스템
• 파일 서버 및 데이터베이스 접근56.

3. NTLM (Windows New Technology LAN Manager)

개요

• NTLM은 Microsoft에서 개발한 Challenge-Response 기반 인증 프로토콜입니다.
• 레거시 시스템과 로컬 로그인을 지원하며, Kerberos 이전의 Windows 기본 인증 방식입니다711.

작동 방식

1. 클라이언트가 서버에 사용자 이름과 도메인 정보를 전달합니다.
2. 서버가 난수(Challenge)를 생성해 클라이언트에게 보냅니다.
3. 클라이언트는 난수를 자신의 패스워드 해시 값으로 암호화하여 응답(Response)을 생성합니다.
4. 서버는 응답 값을 도메인 컨트롤러(DC)에 전달하여 검증하고, 일치하면 인증을 허가합니다71315.

특징

• 패스워드 해시를 사용해 네트워크 상에서 패스워드 전송을 방지.
• Kerberos보다 보안성이 낮으며, 현대 시스템에서는 주로 호환성 목적으로 사용됩니다712.

취약점

• 패스워드 해시 탈취 공격(Pass-the-Hash)에 취약.
• 다중 요소 인증(MFA)을 지원하지 않아 보안성이 떨어짐812.

LDAP vs Kerberos vs NTLM 비교

항목LDAPKerberosNTLM

인증 방식	디렉토리 기반	티켓 기반	Challenge/Response
보안성	중간 수준	높은 수준	낮은 수준
주요 사용 사례	중앙 사용자 관리	Active Directory 환경	레거시 시스템 및 로컬 로그온
암호화 여부	선택적	암호화된 티켓	패스워드 해시 사용
확장성	높음	매우 높음	낮음
취약점	디렉토리 데이터 노출 가능	설정 복잡성	중간자 공격 및 해시 탈취 위험

 

결론

LDAP는 중앙 집중식 사용자 관리와 디렉토리 서비스 통합에 적합하며, Kerberos는 대규모 네트워크에서 강력한 보안을 제공합니다. NTLM은 레거시 환경이나 도메인 컨트롤러 연결이 끊긴 상황에서 유용하지만, 현대적인 시스템에서는 Kerberos로 대체하는 것이 권장됩니다.

 

 

FIDO2 보안 키

FIDO(Fast IDentity Online) Alliance는 공개 인증 표준을 알리고 암호를 인증 형태로 사용하는 것을 줄이도록 지원합니다. FIDO2는 WebAuthn(웹 인증) 표준을 통합하는 최신 표준입니다.

FIDO2 보안 키는 모든 폼 팩터로 제공할 수 있으며, 피싱이 불가능한 표준 기반의 암호 없는 인증 방법입니다. FIDO(Fast Identity Online)는 암호 없는 인증을 위한 공개 표준입니다. FIDO를 사용하여 사용자와 조직은 사용자 이름 또는 암호 없이 외부 보안 키 또는 디바이스의 기본 제공 플랫폼 키로 해당 리소스에 로그인할 수 있습니다.

사용자는 로그인 인터페이스에서 FIDO2 보안 키를 등록한 다음에 인증의 기본 수단으로 선택할 수 있습니다. 이러한 FIDO2 보안 키는 일반적으로 USB 디바이스이지만 Bluetooth 또는 NFC를 사용할 수도 있습니다. 인증을 처리하는 하드웨어 디바이스를 사용하면 노출되거나 추측될 수 있는 암호가 없으므로 계정의 보안이 강화됩니다.

 

FIDO2 보안 키 개요

FIDO2 보안 키는 FIDO(Fast Identity Online) Alliance에서 개발한 비밀번호 없는 인증(passwordless authentication) 표준을 구현한 물리적 하드웨어 장치 또는 소프트웨어입니다. 이 키는 **공개 키 암호화(public-private key cryptography)**를 사용하여 온라인 서비스에 안전하게 로그인할 수 있도록 설계되었습니다. FIDO2는 기존의 비밀번호 기반 인증의 취약점을 해결하고, 사용자 경험과 보안을 동시에 강화합니다.

FIDO2 인증 작동 방식

1. 공개 키 암호화 기반 인증

• 키 쌍 생성:
  • 사용자가 FIDO2 지원 서비스에 등록하면, 클라이언트 장치가 고유한 공개 키와 개인 키 쌍을 생성합니다.
  • 공개 키는 서비스에 등록되며, 개인 키는 사용자 장치 내에서 안전하게 저장됩니다.
• 로그인 과정:
  1. 사용자가 로그인 요청을 하면, 서비스는 고유한 **챌린지(Challenge)**를 생성하여 클라이언트에 보냅니다.
  2. 클라이언트는 개인 키로 챌린지를 서명하고, 서명된 데이터를 서비스에 반환합니다.
  3. 서비스는 공개 키를 사용해 서명을 검증하여 사용자를 인증합니다.

2. 사용자 확인

• FIDO2 보안 키는 PIN, 생체 인식(지문, 얼굴 인식) 또는 버튼 누르기와 같은 사용자 제스처를 통해 인증 요청을 승인합니다.

3. 로컬 데이터 저장

• 개인 키와 생체 데이터는 장치에서만 저장되며, 서버로 전송되지 않습니다. 이를 통해 데이터 유출 위험을 줄이고 프라이버시를 보호합니다.

FIDO2 보안 키의 유형

1. Roaming Authenticator (이동형 인증기)
   • USB, NFC, 또는 Bluetooth를 통해 다양한 장치와 연결 가능.
   • 예: YubiKey, 스마트폰, 웨어러블 디바이스.
   • 여러 플랫폼에서 사용 가능하며 휴대성이 뛰어남.
2. Platform Authenticator (플랫폼 인증기)
   • 특정 장치(예: 스마트폰, 노트북)에 내장된 생체 인식 센서나 PIN 잠금 기능을 사용.
   • 예: Windows Hello, Apple Touch ID/Face ID.

FIDO2 보안 키의 주요 장점

1. 보안 강화

• 피싱 방지: 개인 키가 로컬에 저장되고 도메인에 바인딩되므로 피싱 공격이 실패합니다36.
• 중간자 공격(MITM) 방지: 암호화된 티켓과 도메인 검증으로 중간자 공격 차단3.
• 비밀번호 제거: 비밀번호가 필요 없으므로 약한 비밀번호나 재사용으로 인한 취약점 제거57.

2. 사용자 편의성

• 비밀번호를 기억하거나 입력할 필요 없이 간단한 제스처(지문 스캔, 버튼 누르기)로 인증 가능45.
• 하나의 FIDO2 보안 키로 여러 계정에 로그인 가능5.

3. 프라이버시 보호

• 각 서비스마다 고유한 암호화 키 쌍을 생성하므로 서비스 간 사용자 추적이 불가능46.
• 생체 데이터와 개인 키는 장치 내부에만 저장되어 유출 위험이 없음17.

4. 비용 절감 및 확장성

• 비밀번호 관리 및 재설정 비용 감소.
• 오픈 표준(FIDO2/WebAuthn)을 기반으로 다양한 브라우저 및 플랫폼에서 호환 가능56.

FIDO2 보안 키의 활용 사례

1. 기업 환경
   • 직원들이 회사 시스템에 안전하게 로그인하도록 지원.
   • 민감한 데이터와 애플리케이션 접근 제어.
2. 전자 상거래 및 금융
   • 고객이 은행 계좌나 결제 시스템에 안전하게 접근.
3. 공공 기관 및 규제 산업
   • 높은 수준의 인증 요구 사항을 충족하기 위해 다중 요소 인증(MFA) 구현.
4. 일반 사용자
   • 개인 이메일 계정, 소셜 미디어 계정 등에서 비밀번호 없는 로그인.

FIDO2 보안 키의 한계점

1. 초기 비용 부담:
   • 하드웨어 구매 및 배포 비용 발생4.
2. 물리적 손실 위험:
   • 보안 키 분실 시 계정 복구 프로세스가 필요함4.
3. 사용자 교육 필요성:
   • 새로운 기술에 대한 이해 부족으로 초기 도입 시 교육이 필요할 수 있음4.

결론

FIDO2 보안 키는 비밀번호 기반 인증의 취약점을 해결하고 강력한 보안을 제공하는 현대적인 인증 솔루션입니다. 특히 피싱 방지와 사용자 편의성을 동시에 제공하며, 기업과 개인 모두에게 적합합니다. 앞으로 더 많은 서비스와 플랫폼에서 FIDO2 기술이 채택될 것으로 기대됩니다.

 

조건부 액세스 예시

조건부 액세스를 언제 사용할 수 있나요?

조건부 액세스는 다음 경우에 유용합니다.

• 요청자의 역할, 위치 또는 네트워크에 따라 애플리케이션에 액세스하려면 MFA(다단계 인증)가 필요합니다. 예를 들어 일반 사용자가 아닌 관리자 또는 회사 네트워크 외부에서 연결하는 사용자에게 MFA를 요구할 수 있습니다.
• 승인된 클라이언트 애플리케이션을 통해서만 서비스에 액세스하도록 요구합니다. 예를 들어 메일 서비스에 연결할 수 있는 메일 애플리케이션을 제한할 수 있습니다.
• 사용자가 관리 디바이스에서만 애플리케이션에 액세스하도록 요구합니다. 관리 디바이스는 보안 및 규정 준수 표준을 충족하는 디바이스입니다.
• 알 수 없거나 예기치 않은 위치에서의 액세스와 같이 신뢰할 수 없는 소스로부터의 액세스를 차단합니다.

 

Azure 역할 기반 액세스 제어 설명

 

여러 IT 및 엔지니어링 팀이 있는 경우 클라우드 환경의 리소스에 대한 액세스를 어떻게 제어할 수 있나요? 최소 권한 원칙은 작업을 완료하는 데 필요한 수준까지만 액세스 권한을 부여해야 한다고 말합니다. 스토리지 Blob에 대한 읽기 권한만 필요한 경우 해당 스토리지 Blob에 대한 읽기 권한만 부여받아야 합니다. 해당 Blob에 대한 쓰기 액세스 권한은 부여되지 않아야 하며 다른 스토리지 Blob에 대한 읽기 권한도 부여해서는 안 됩니다. 따라야 할 좋은 보안 사례입니다.

그러나 전체 팀에 대한 사용 권한 수준을 관리하는 것은 지루할 것입니다. 각 개인에 대한 자세한 액세스 요구 사항을 정의한 다음, 새 리소스가 생성되거나 새 사람이 팀에 합류할 때 액세스 요구 사항을 업데이트하는 대신 Azure를 사용하면 Azure RBAC(역할 기반 액세스 제어)를 통해 액세스를 제어할 수 있습니다.

Azure는 클라우드 리소스의 퍼블릭 액세스 규칙을 설명하는 기본적인 역할도 장착하고 있습니다. 임의로 역할을 정의할 수도 있습니다. 각 역할에는 해당 역할과 관련된 액세스 권한의 연결된 세트가 있습니다. 하나 이상의 역할에 할당되는 개인 또는 그룹은 연결된 액세스 권한을 모두 부여받습니다.

따라서 새 엔지니어를 고용하여 엔지니어를 위해 Azure RBAC 그룹에 추가하면 동일한 Azure RBAC 그룹의 다른 엔지니어와 동일한 액세스 권한이 자동으로 부여됩니다. 마찬가지로 추가 리소스를 추가하고 Azure RBAC를 가리키는 경우 해당 Azure RBAC 그룹의 모든 사용자는 이제 새 리소스와 기존 리소스에 대한 권한을 갖게 됩니다.

리소스에 역할 기반 액세스 제어는 어떻게 적용되나요?

역할 기반 액세스 제어는 이 액세스가 적용되는 리소스 또는 리소스 세트인 ‘범위’에 적용됩니다.

다음 다이어그램은 역할과 범위 간의 관계를 보여 줍니다. 관리 그룹, 구독 또는 리소스 그룹에 소유자 역할이 부여될 수 있으므로 제어 및 권한이 향상됩니다. 업데이트를 수행할 것으로 예상되지 않는 관찰자에게 동일한 범위에 대한 읽기 권한자 역할이 부여되어 관리 그룹, 구독 또는 리소스 그룹을 검토하거나 관찰할 수 있습니다.

범위는 다음과 같습니다.

• 관리 그룹(여러 구독의 컬렉션)
• 단일 구독
• 리소스 그룹
• 단일 리소스

관찰자, 리소스를 관리하는 사용자, 관리자, 자동화된 프로세스는 일반적으로 다양한 역할 각각에 할당되는 사용자 또는 계정의 종류를 보여 줍니다.

Azure RBAC는 계층 구조입니다. 부모 범위에서 액세스 권한을 부여할 때 해당 권한은 모든 자식 범위에서 상속됩니다. 예를 들면 다음과 같습니다.

• 관리 그룹 범위에서 사용자에게 소유자 역할을 할당하면 해당 사용자는 관리 그룹 내에서 모든 구독의 모든 항목을 관리할 수 있습니다.
• 구독 범위에서 그룹에 읽기 권한자 역할을 할당하면 해당 그룹의 멤버는 구독 내의 모든 리소스 그룹 및 리소스를 볼 수 있습니다.

Azure RBAC는 어떻게 적용되나요?

Azure RBAC는 Azure Resource Manager를 전달되는 Azure 리소스에 대해 시작되는 모든 작업에 적용됩니다. Resource Manager는 클라우드 리소스를 구성하고 보호하는 방법을 제공하는 관리 서비스입니다.

일반적으로 Azure Portal, Azure Cloud Shell, Azure PowerShell 및 Azure CLI에서 Resource Manager에 액세스합니다. Azure RBAC는 애플리케이션 또는 데이터 수준에서 액세스 권한을 적용하지 않습니다. 애플리케이션 보안은 애플리케이션에서 처리해야 합니다.

Azure RBAC는 허용 모델을 사용합니다. 역할이 할당되면 Azure RBAC를 사용하여 해당 역할 범위 내에서 작업을 수행할 수 있습니다. 리소스 그룹에 대한 읽기 권한을 부여한 역할 할당이 있는 반면 동일한 리소스 그룹에 대한 쓰기 권한을 부여하는 역할 할당의 경우 사용자는 해당 리소스 그룹에 대한 읽기 및 쓰기 권한을 가지게 됩니다.

 

 

제로 트러스트 모델 설명

 

•  

제로 트러스트는 최악의 시나리오를 가정하고 해당 기대 수준에 따라 리소스를 보호하는 보안 모델입니다. 제로 트러스트는 처음부터 위반을 가정한 다음, 제어되지 않은 네트워크에서 시작된 것처럼 각 요청을 확인합니다.

오늘날 조직에는 최신 환경의 복잡성에 효과적으로 적응하고, 모바일 인력을 수용하며, 위치에 관계없이 사용자, 디바이스, 애플리케이션, 데이터를 보호할 수 있는 새로운 보안 모델이 필요합니다.

이 새로운 컴퓨팅 분야를 해결하기 위해 Microsoft는 다음 지침 원칙을 기반으로 하는 제로 트러스트 보안 모델을 적극 권장합니다.

• 명시적으로 확인 - 사용 가능한 모든 데이터 요소에 따라 항상 인증하고 권한을 부여합니다.
• 최소 권한 액세스 사용 - JIT/JEA(Just-In-Time and Just-Enough-Access), 위험 기반 적응 정책 및 데이터 보호를 사용하여 사용자 액세스를 제한합니다.
• 위반 가정 - 폭발 반경 및 세그먼트 액세스를 최소화합니다. 엔드투엔드 암호화를 확인합니다. 분석을 사용하여 가시성을 얻고, 위협 탐지를 추진하고, 방어를 향상시킵니다.

제로 트러스트 조정

일반적으로 회사 네트워크는 제한되고 보호되며 일반적으로 안전하다고 가정했습니다. 관리형 컴퓨터만 네트워크에 조인할 수 있고, VPN 액세스가 엄격하게 제어되었으며, 개인 디바이스가 자주 제한되거나 차단되었습니다.

제로 트러스트 모델은 해당 시나리오를 뒤집습니다. 디바이스가 회사 네트워크 내에 있기 때문에 안전하다고 가정하는 대신 모든 사용자가 인증해야 합니다. 그런 다음, 위치가 아닌 인증에 따라 액세스 권한을 부여합니다.