Azure 스크립트와 도구를 사용하여 Azure에서 작업을 자동화해야 할 때, 서비스 계정이나 Azure 서비스 주체를 사용하는 것을 고려할 수 있습니다. 일부 사람들은 새로운 서비스 계정을 만들고 원하는 모든 관리 역할을 할당하고 MFA에서 제외하는 것이 흔한 방법입니다.
I know what you’re thinking – “that is a horrible idea”. Of course, it is! And for sure, your IT Sec will give you a lot of grief if you did all that.
하지만 대안은 무엇일까요? 제한된 범위의 특권 자격 증명을 사용하여 MFA에서 제외되지 않는 방법은 무엇일까요? 다행히도 이 문서에서는 이에 대해 알려드릴 것입니다.
이 문서에서는 Azure 서비스 주체가 무엇인지에 대해 알아볼 것입니다. 또한 비밀번호, 비밀 키 및 인증서와 같은 다양한 유형의 자격 증명으로 서비스 주체를 만드는 방법에 대해 배울 수 있을 것입니다.
Azure 서비스 주체를 만들기 위한 여러 도구가 있습니다. 이러한 도구에는 Azure 포털, Azure Active Directory 관리 센터, Azure AD PowerShell, Azure CLI 및 Azure PowerShell이 포함됩니다. 이 문서에서는 Azure PowerShell에 초점을 맞출 것입니다.
아직 관심이 있으신가요? 계속해서 읽어보세요!
요구 사항
이것은 실습 기사이므로, 따라갈 수 있도록 일부 전제 조건을 제시합니다.
- Azure 구독에 액세스할 수 있어야 합니다. 테스트 테넌트에서 작업하는 것이 가장 좋습니다. 없는 경우, 무료 평가판을 등록할 수 있습니다.
- PowerShell 5.1을 실행하는 Windows 10 컴퓨터에 액세스해야 합니다.
- Azure PowerShell 모듈이 설치되어 있어야 합니다.
Azure 서비스 주체 vs. 서비스 계정
자동화 도구 및 스크립트는 종종 관리자 또는 특권 액세스가 필요합니다. 예를 들어, 스토리지 계정을 프로비저닝하거나 일정에 따라 가상 머신을 시작하고 중지하는 것입니다. 대부분의 관리자는 스크립트에 대한 자격 증명 요구 사항을 설정하기 위해 완전한 특권 사용자 계정(서비스 계정이라고 함)을 사용합니다.
A service account is essentially a privileged user account used to authenticate using a username and password. And, if used with automation, a service account is most likely excluded from any conditional access policies or multi-factor authentication.
반면, Azure 서비스 주체는 사용자 이름과 암호 또는 인증서를 사용하여 설정할 수 있습니다. 사용자가 없는 사용자 ID라고 생각하면 됩니다. 대신 응용 프로그램의 ID입니다.
Azure 서비스 주체는 구체적인 단일 Azure 리소스에 대해 최소한의 액세스만 할당할 수 있습니다. 예를 들어, 전체 구독 또는 단일 Azure 가상 머신에 대한 역할 기반 액세스를 가진 Azure 서비스 주체를 생성할 수 있습니다.
Azure 서비스 주체를 만들기 위한 주요 고려사항
Azure 서비스 주체를 만들기 전에, 계획해야 할 기본 세부 정보를 알고 있어야 합니다. 이러한 세부 사항은 간단해 보일 수 있지만, Azure 서비스 주체를 효율적으로 만들고 가능한 쉽게 만들 수 있도록 도와줍니다.
표시 이름. 이름으로 시작하며, Azure 서비스 주체는 이름이 있어야 합니다. 여기에는 규칙은 없지만, 조직에서 규정한 명명 규칙이 있을 수 있습니다.
- 사용할 자격 증명 유형. 암호 또는 인증용 인증서를 사용하는 Azure 서비스 주체를 만들 수 있습니다. 이는 한 가지만 선택해야 한다는 의미는 아닙니다. 둘 다 사용할 수 있습니다.
서비스 주체의 사용자 이름과 비밀번호는 애플리케이션 ID와 비밀 키로 더 적절하게 표현됩니다.
- 자격 증명의 유효 기간. 암호 또는 인증서 자격 증명을 할당할 때, 유효성의 시작과 종료 날짜를 정의해야 합니다. 자격 증명의 유효 기간은 일반적으로 인증서와 암호를 얼마나 자주 교체하고 갱신할지에 따라 달라집니다.
- 액세스 범위. Azure 서비스 주체가 구독, 리소스 그룹 또는 선택한 리소스에 액세스할 것인지를 정해야 합니다.
- 역할. Contributor, Reader, Owner 등 여러 역할이 있습니다. 서비스 주체에게 “충분히” 맞는 역할을 정의해야 합니다.
자동으로 할당된 비밀 키로 Azure 서비스 주체 생성하기
Azure에서 새로운 서비스 주체를 생성하는 핵심은 New-AzAdServicePrincipal
cmdlet입니다. 이 예제에서는 다음과 같은 값을 가지는 새로운 서비스 주체를 생성합니다:
DisplayName: AzVM_Reader
Scope: AzVM1 (가상 머신)
Role: Reader
Password: <자동으로 할당됨>
자격 증명 유효 기간: 1년
대상 Scope(가상 머신)의 ID 가져오기
위 예제에서 보시다시피, 이 새로운 서비스 주체의 Scope는 AzVM1이라는 가상 머신에 대해서만 적용됩니다. 그러나 -Scope
매개변수는 단순히 이름만 받지 않고, 리소스의 전체 ID를 받아야 합니다. 따라서, 이 예제에서 먼저 해야 할 일은 AzVM1 가상 머신의 ID를 가져오는 것입니다. 이를 위해 아래 코드를 사용하세요.
위의 코드를 PowerShell에서 실행하면, 아래 스크린샷과 유사한 VM 이름과 ID 목록이 표시됩니다.

비밀 키와 함께 Azure 서비스 주체 생성하기
이제 대상 Scope인 AzVM1 가상 머신의 ID를 가지고 있으므로, 아래 명령어를 사용하여 reader 역할을 가진 새로운 서비스 주체를 생성할 수 있습니다. 새로운 서비스 주체의 속성은 $sp
변수에 저장됩니다.
위 명령어의 결과로, 아래 값들을 가지는 서비스 주체가 생성되었습니다.

비밀 키의 복호화
이제 ApplicationID와 Secret이 서비스 프린시펄의 사용자 이름과 비밀번호입니다. 그러나 Secret의 값은 System.Security.SecureString으로 표시됩니다. 이 비밀을 확인하려면 아래 명령을 사용하여 비밀을 일반 텍스트로 변환하십시오.
위의 명령은 $sp.Secret
의 보안 문자열 값을 일반 텍스트로 변환합니다. 참조를 위해 아래 이미지를 참조하십시오.

Azure 서비스 프린시펄 역할 할당 확인
작업이 작동했는지 어떻게 알 수 있습니까? Azure Portal을 사용하여 리소스의 액세스 제어 목록을 확인할 수 있습니다. 예를 들어 아래 이미지에서 AzVM_Reader 서비스 프린시펄이 이제 Reader 액세스 권한을 가진 AzVM1 가상 머신을 볼 수 있습니다.

또한 Get-AzRoleAssignment -ObjectID $sp.id
명령을 사용하여 Azure 서비스 프린시펄의 역할 할당을 가져올 수 있습니다. 예를 들어 아래 스크린샷을 참조하십시오.

비밀번호를 사용하여 Azure 서비스 프린시펄 생성
Azure 서비스 프린시펄에 할당되는 비밀번호나 비밀 키를 더욱 제어하려면 서비스 프린시펄 생성 중에 -PasswordCredential
매개변수를 사용하십시오. 이렇게 하면 비밀번호가 복잡성 요구 사항을 충족해야 하는 경우 특히 유용합니다.
이 예에서 새 Azure 서비스 프린시펄은 다음 값과 함께 생성됩니다:
DisplayName: ATA_RG_Contributor
Scope: ATA (ResourceGroup)
역할: 기여자
비밀번호: 20자리이며 6개의 비알파벳 문자를 포함해야 함
자격증명 유효기간: 5년
대상 범위 (리소스 그룹)의 ID 가져오기
이 새로운 서비스 주체의 범위는 ATA라는 전체 리소스 그룹을 포함합니다. 먼저 ATA 리소스 그룹의 ID를 가져와야 합니다. 아래 코드를 사용하여 -Name
매개변수의 값을 리소스 그룹 이름으로 변경해야 합니다.
그런 다음, 이제 $Scope
변수에 저장된 리소스 그룹의 ResourceID
를 볼 수 있어야 합니다.

비밀번호 문자열 생성
다음 단계는 20자리이며 6개의 비알파벳 문자를 포함해야 함 복잡성을 따르는 비밀번호를 생성하는 것입니다. 이를 위해 .NET 정적 메서드 GeneratePassword()
를 활용할 수 있습니다.
위의 코드 GeneratePassword(20, 6)
에서 첫 번째 값은 비밀번호의 길이를 의미하고, 두 번째 값은 포함할 비알파벳 문자의 수를 의미합니다. 결과는 아래 스크린샷에 표시됩니다.

GeneratePassword()
static method비밀번호 자격 증명 객체 생성
이제 암호 문자열을 가지고 있으므로 다음 단계는 Microsoft.Azure.Commands.ActiveDirectory.PSADPasswordCredential
개체를 만드는 것입니다. 이 개체에는 $password
변수에 저장된 암호 문자열과 5년의 유효 기간이 포함됩니다. 아래의 코드를 복사하여 Azure PowerShell 세션에서 실행하세요.
위의 코드를 PowerShell에서 실행하면 자격 증명 개체가 $PasswordCredential
변수에 저장됩니다. 예상 결과는 아래와 유사합니다.

암호로 서비스 주체 생성
이제 Azure 서비스 주체를 생성하기 위해 필요한 매개 변수 값이 준비되었습니다. 아래의 코드는 표시 이름이 ATA_RG_Contributor이고 $PasswordCredential
변수에 저장된 암호를 사용하여 서비스 주체를 생성합니다.
코드를 실행한 후에는 새로운 서비스 주체가 생성되고 속성이 $sp
변수에 저장됩니다. 아래의 예시 결과를 참조하세요.

역할과 범위 할당
이전 섹션에서 Azure 서비스 주체가 생성되었지만 Role과 Scope가 없습니다. 이는 -Role
및 -Scope
매개 변수를 -PasswordCredential
매개 변수와 함께 사용할 수 없기 때문입니다. 따라서 서비스 주체에 역할과 범위를 할당하기 위해 추가 단계가 필요합니다.
아래 코드는 New-AzRoleAssignment
cmdlet을 사용하여 Azure 서비스 주체의 범위와 역할을 할당합니다.
아래 스크린샷은 역할과 범위가 Azure 서비스 주체에 할당된 후의 예상 결과를 보여줍니다.

서비스 주체의 암호를 반드시 저장하십시오. 저장하지 못하거나 잊어버리는 경우 복구할 수 없습니다.
서비스 주체 암호로 Azure에 연결하기
이제 서비스 주체를 사용할 차례입니다. 사용자 계정을 사용하여 Azure PowerShell에 로그인하는 대신, 아래 코드는 서비스 주체 자격 증명을 사용합니다.
위의 코드를 실행한 후, ATA_RG_Contributor 서비스 주체 및 비밀 자격 증명을 사용하여 Azure PowerShell에 로그인해야 합니다.

인증서를 사용하여 Azure 서비스 주체 생성
Azure 서비스 주체는 비밀 자격 증명 외에도 인증서 기반의 자격 증명을 가질 수 있습니다. 연결된 인증서는 인증 기관에 의해 발급된 것이거나 자체 서명 될 수 있습니다.
이 예제에서는 다음과 같은 값으로 새 Azure 서비스 주체가 생성됩니다:
표시 이름: VSE3_SUB_OWNER
범위: VSE3 (구독)
역할: 소유자
인증서 유효성: 2년
대상 범위(구독)의 ID 가져오기
이 새 서비스 주체의 범위는 VSE3라는 Azure 구독을 포함합니다. 먼저 VSE3 구독의 ID를 가져와야 합니다. 이를 위해 아래의 코드를 사용하지만 -SubscriptionName
매개 변수의 값을 자신의 리소스 그룹 이름으로 변경해야 합니다.
다음으로, 새 Azure 서비스 주체 및 자체 서명된 인증서의 이름을 지정합니다.
자체 서명된 인증서 생성
다음 코드는 이름이 CN=VSE3_SUB_OWNER인 개인 인증서 저장소에 자체 서명된 비밀번호를 만듭니다. 인증서의 유효 기간은 2년으로 설정됩니다. 인증서의 속성은 $cert
변수에 저장됩니다.
아래 스크린샷은 인증서가 생성되었음을 보여줍니다.

더 익숙한 보기(GUI)에서 새 인증서를 확인하려면 Certificates 콘솔(certmgr.mmc)에서 찾을 수 있습니다. 아래 이미지는 인증서를 보여줍니다.

다음은 자체 서명된 인증서의 Base64 인코딩 값을 가져와 $keyValue
변수에 저장하는 것입니다.
인증서와 함께 서비스 주체 생성
인증서를 생성했으므로 다음 단계는 새로운 Azure 서비스 주체를 생성하는 것입니다. 아래 코드는 자체 서명된 인증서를 자격 증명으로 사용할 Azure 서비스 주체를 생성합니다. 자격 증명의 유효 기간은 인증서의 유효 기간과 일치합니다.
다음과 같은 출력을 받게 됩니다. 아래 이미지와 같이 보입니다.

역할 및 범위 할당
Azure 서비스 주체는 아직 역할과 범위가 할당되지 않은 상태입니다. 따라서 서비스 주체에 역할과 범위를 할당하는 추가 단계가 필요합니다.
아래 코드는 New-AzRoleAssignment
cmdlet을 사용하여 서비스 주체의 VSE3 구독에 소유자 역할을 할당합니다.
코드를 실행하면 아래 스크린샷에서 역할 할당이 완료되었다는 확인이 표시됩니다.

서비스 주체 인증서를 사용하여 Azure에 연결
이제 인증서 기반 자격 증명으로 서비스 주체를 생성했습니다. 이는 암호를 사용하지 않고 Azure에 연결할 수 있다는 것을 의미합니다. 대신 컴퓨터에 있는 인증서를 인증 방법으로 사용할 것입니다.
이 예제에서 서비스 주체의 표시 이름은 VSE3_SUB_OWNER이고, 인증서 이름은 CN=VSE3_SUB_OWNER입니다. 아래 코드는 개인 인증서 저장소에서 인증서의 썸프린트를 가져와 로그인 자격 증명으로 사용합니다.
아래 스크린샷은 위의 코드를 사용하여 ApplicationID, Tenant 및 Certificate ThumbPrint만 사용하여 Azure PowerShell에 로그인하는 데 성공했음을 보여줍니다.

결론
Azure 서비스 주체는 Azure 리소스에 액세스하는 자동화 작업 및 도구에 대한 자격 증명을 생성할 때 고려해야 할 보안 주체입니다. 적용할 범위와 역할을 선택하여 “필요한 만큼”의 액세스 권한을 부여할 수 있습니다.
이 글에서는 PowerShell을 사용하여 Azure Service Principals를 생성하는 방법을 배웠습니다. Azure Service Principals는 암호, 비밀 키 또는 인증서 기반 자격 증명을 가질 수 있습니다. 이러한 유형의 자격 증명은 각각의 장점과 적용 가능한 사용 시나리오를 가지고 있습니다.
암호 또는 비밀 키 자격 증명을 가진 서비스 주체는 이동성이 더 높지만 자격 증명이 평문으로 공유될 수 있어 보안이 덜 강력합니다. 반면, 인증서 기반 자격 증명은 더 안전한 옵션입니다만 유지 관리에 조금 더 노력이 필요합니다.
이 글에서 배운 기술들은 Azure 서비스 주체를 자동화하는 데 필요한 기본 사항만 다루고 있습니다. 자격 증명을 추가, 제거 및 재설정하는 등 Azure 서비스 주체를 구성하는 더 많은 방법들이 있습니다. 발견하는 것은 여러분에게 달려 있습니다.
읽어 주셔서 감사합니다!
추가 학습 자료
이 글과 함께 유용한 자료들입니다.
Source:
https://adamtheautomator.com/azure-service-principal/