Azure 환경 보호
이제 환경을 제어하고 배포 파이프라인을 보호하는 방법을 이해하므로 제어된 환경에 대한 사용자 액세스를 사용하지 않도록 설정할 수 있습니다. 이 단원에서는 Azure 환경에 대한 사용자의 권한을 구성하는 방법을 알아봅니다. 긴급 상황에서 액세스를 허용하는 방법 및 Azure 자산에서 발생하는 변경 내용을 감사하는 방법을 포함합니다.
사용자 액세스 차단
제어된 환경에 대한 사용자 액세스를 차단하여 우발적이거나 악의적인 변경이 팀의 검토 및 자동화된 배포 프로세스를 우회할 수 없도록 합니다. 사용자 액세스를 차단하지 않으면 누군가가 리포지토리와 파이프라인 전체에서 계획하고 구현하는 데 많은 시간을 소비한 컨트롤을 무심코 우회할 수 있습니다.
컨트롤을 차단하지 않으면 누군가가 실수로 무언가를 쉽게 손상할 수도 있습니다. 예를 들어, 사용자에게 열려 있는 Azure Portal 복사본이 두 개 있다고 가정합니다. 하나는 테스트 환경을 위한 것이고 다른 하나는 프로덕션 환경을 위한 것입니다. 사용자가 브라우저 탭 간에 앞뒤로 전환하는 경우 테스트 환경을 위한 프로덕션 환경을 실수로 변경하기 쉽습니다.
사용자 액세스를 차단하려면 Azure RBAC(역할 기반 액세스 제어)를 사용할 수 있습니다. RBAC에서 다음을 정의하는 역할 할당을 만듭니다.
- 정의된 Azure 리소스 세트에 액세스할 수 있는 사용자, 그룹 또는 서비스 주체(범위).
- 해당 사용자, 그룹 또는 서비스 주체가 리소스에 액세스할 때 수행할 수 있는 작업(역할).
Azure RBAC는 다음을 비롯한 다양한 기본 제공 역할 유형을 제공합니다.
- 읽기 권한자 - 환경에 대한 읽기 전용 액세스 권한을 보유합니다.
- 참가자 - 리소스를 수정할 수 있습니다.
- 소유자 - 리소스를 수정하고 다른 사용자에게 액세스 권한을 부여할 수 있습니다.
적절한 범위에서 액세스 권한을 부여하는 것이 중요합니다. 조직에서 각 환경에 전용 Azure 구독을 사용하는 권장 사례를 따르는 경우 Azure 관리 그룹을 사용하여 역할 할당의 범위를 간소화하는 것이 좋습니다. 조직에서 모든 환경에 단일 Azure 구독을 사용하는 경우 제어된 환경을 포함한 모든 리소스가 해당 권한을 상속하므로 사용자에게 전체 구독에 대한 액세스 권한을 부여하지 마세요.
팁
역할 할당은 ARM(Azure Resource Manager) 리소스입니다. 즉, Bicep을 사용하는 등의 방법으로 코드에서 Azure RBAC 역할 할당을 구성할 수 있습니다.
역할 할당을 계획할 때 조직에 적합한 항목을 결정해야 합니다. 예를 들어, 조직에서 각 환경에 대해 별도의 구독을 만든다고 가정합니다. 관리자와 개발자에게 제어된 환경에 대한 읽기 권한자 액세스 권한을 부여하도록 선택할 수 있습니다. 해당 역할을 사용하면 Azure Portal 내에서 프로덕션 환경에 액세스하여 리소스 구성을 검토하고, 메트릭 및 로그를 보고, 환경을 변경하지 않고도 문제 또는 버그를 조사할 수 있습니다.
Azure 관리자와 코드, 스크립트를 작성하는 개발자를 위해 장난감 회사의 환경에 대한 역할 할당을 구성하는 방법은 다음과 같습니다.
| 환경 이름 | 컨트롤 수준 | 관리자 권한 | 개발자 권한 |
|---|---|---|---|
| 개발 | 제어 | 읽기 권한자 | 읽기 권한자 |
| 테스트 | 제어 | 읽기 권한자 | 읽기 권한자 |
| 스테이징 | 제어 | 읽기 권한자 | 읽기 권한자 |
| 생산 | 제어 | 읽기 권한자 | 읽기 권한자 |
| 데모 | 제어되지 않음 | 소유자 | 참가자 |
| 성능 테스트 | 제어되지 않음 | 소유자 | 없음 |
| 침투 테스트 | 제어되지 않음 | 소유자 | 없음 |
| PR 검토 | 제어되지 않음 | 소유자 | 소유자 |
| 개발 샌드박스 | 제어되지 않음 | 소유자 | 소유자 |
역할 할당을 계획하는 경우 역할 할당을 철저히 테스트해야 합니다. 경우에 따라 관리 작업에 명확하지 않은 권한이 필요할 수 있습니다. 팀 멤버에게 사용하려는 권한으로 모든 일상적인 작업을 테스트할 기회를 제공합니다. 발생한 문제를 검토합니다.
정기적으로 역할 할당을 감사합니다. 실수로 잘못된 사용자에게 액세스 권한을 부여하거나 너무 넓은 액세스 권한을 부여하지 않았는지 확인합니다.
데이터 평면 액세스
Azure에는 다음 두 가지 유형의 작업이 있습니다.
- 컨트롤 플레인 작업 - 구독의 리소스를 관리합니다.
- 데이터 평면 - 리소스가 노출하는 기능에 액세스합니다.
예를 들어 컨트롤 플레인 작업을 사용하여 스토리지 계정을 만듭니다. 데이터 평면 작업을 사용하여 스토리지 계정에 연결하고 해당 계정에 포함된 데이터에 액세스합니다.
Azure 리소스에 대한 직접 사용자 액세스를 차단하는 경우 이 제한이 데이터 평면 작업에 적용되는 방식도 고려합니다. 예를 들어 배포 프로세스는 관리자가 액세스할 수 있는 위치에 스토리지 계정의 키를 저장할 수 있습니다. 관리자는 잠재적으로 키를 사용하여 컨트롤을 우회하고 스토리지 계정의 데이터 평면에 직접 액세스할 수 있습니다.
점점 더 많은 Azure 리소스가 Microsoft Entra ID를 사용하여 데이터 평면 액세스 제어 구성을 지원하고 있습니다. 이 지원을 통해 키를 유출하거나 실수로 데이터 평면 액세스 권한을 부여할 가능성이 줄어듭니다. 가능한 어디에서나 데이터 평면 액세스를 위해 Microsoft Entra ID를 사용하는 것이 좋습니다.
긴급 액세스
경우에 따라 긴급 상황이 발생하고 누군가가 신속하게 프로덕션 환경에 액세스하여 문제를 조사하거나 해결해야 합니다. 이 긴급 상황이 발생하기 전에 해당 상황에 대응하는 방법을 계획하고 예행 연습하는 것이 중요합니다. 중단 기간 중에 대응하기 위해 서두를 필요가 없기를 원합니다.
고려해야 할 하나의 접근 방식은 사용자가 일반적으로 보유하는 것보다 더 높은 수준의 권한을 보유한 특수 사용자 계정인 비상 계정입니다. 화재 경보 패널에서 유리를 깨는 것과 비슷하게 자격 증명에 액세스하기 위해 비정상적인 것이 필요하기 때문에 비상 계정이라고 합니다. 운영자가 비상 계정의 자격 증명에 액세스하는 안전한 방법을 제공할 수 있습니다. 그런 다음, 이 운영자는 긴급 변경을 수행하기 위해 해당 계정으로 로그인할 수 있습니다.
비상 계정을 사용하는 단계의 시퀀스는 다음과 같습니다.
- 사용자가 일반 계정을 사용하여 긴급 변경을 수행하려고 하지만 일반 사용자 계정에 충분한 권한이 없으므로 작업이 차단됩니다.
- 사용자는 비상 계정의 자격 증명에 액세스하고 해당 사용자로 로그인합니다.
- 이 사용자(비상 계정 역할 수행)는 작업을 수행할 수 있습니다.
비상 계정을 사용하려면 높은 수준의 분야가 필요합니다. 해당 계정 사용은 진정한 긴급 상황을 위해 예약되어야 합니다. 계정의 권한이 높기 때문에 자격 증명을 신중하게 관리하고 보호합니다. 비상 계정의 자격 증명을 자주 변경하여 노출되거나 손상될 가능성을 최소화하는 것이 좋습니다.
비상 계정은 팀 내에서 공유되는 경우가 많으므로 계정을 사용한 사용자, 해당 사용자가 수행한 작업을 추적하기가 어렵습니다. 비상 계정에 대한 또 다른 방식은 Microsoft Entra PIM(Privileged Identity Management) 기능을 채택하는 것입니다. 사용자 소유 계정에 더 높은 수준의 권한을 일시적으로 부여할 수 있습니다.
PIM을 사용하는 단계의 시퀀스는 다음과 같습니다.
사용자가 일반 계정을 사용하여 긴급 변경을 수행하려고 하지만 일반 사용자 계정에 충분한 권한이 없으므로 작업이 차단됩니다.
사용자가 PIM에 연락하고 임시 권한 상승을 요청합니다.
PIM은 조직에 대해 구성된 방식에 따라 사용자 ID의 추가 유효성 검사를 수행하거나 누군가의 승인을 요청할 수 있습니다.
요청이 승인되면 PIM은 사용자의 권한을 일시적으로 업데이트합니다.
사용자는 작업을 수행할 수 있습니다.
정의된 기간이 경과한 후 PIM은 사용자에게 부여한 더 높은 권한을 철회합니다.
PIM과 Azure는 상승된 권한을 요청한 사용자와 그 이유를 이해하는 데 도움이 되는 포괄적인 감사 로그를 작성합니다. 또한 로그는 권한이 부여되었을 때 사용자 환경에서 수행한 작업을 추적합니다.
참고 항목
PIM에는 Microsoft Entra ID에 대한 프리미엄 라이선스가 필요합니다.
긴급 상황이 끝난 후
긴급 상황이 끝난 후 정상 작업으로 돌아가는 프로세스가 있어야 합니다. 너무 많은 시간이 경과하기 전에 이 프로세스를 수행해야 하며, 그렇지 않으면 중요한 정보를 잊어버리거나 구성을 안전하지 않은 상태로 남겨 둘 위험이 있습니다.
Azure 및 PIM 감사 로그를 신중하게 검토하여 제어된 환경, 특히 프로덕션 환경에서 수행된 변경을 이해합니다.
중요
PIM 또는 비상 계정을 사용하는 누군가는 일반 사용자 계정에 필요한 것보다 더 광범위한 액세스 권한을 부여할 기회가 있을 수 있습니다. 또한 임시 권한을 사용하여 해당 권한이 철회된 후 계속 사용할 수 있는 데이터 평면 키에 대한 액세스 권한을 얻을 수 있습니다.
비상 계정 또는 PIM의 모든 사용을 신중하게 감사합니다. 긴급 상황 중에 노출되었을 수 있는 키를 철회하거나 회전합니다.
긴급 상황 직후에는 긴급 상황 중에 변경된 내용을 사용하여 IaC(Infrastructure as Code) 자산을 다시 동기화합니다. 예를 들어, 긴급한 문제를 해결하는 과정에서 관리자가 Azure App Service 요금제의 SKU를 수동으로 증가시켰다고 가정합니다. 리소스 구성에 새 SKU를 포함하도록 배포 템플릿을 업데이트합니다. 그렇지 않으면 파이프라인에서 다음 정기 배포 중에 SKU가 이전 값으로 다시 설정되고 또 다른 중단이 발생할 수 있습니다.
Azure 환경에 대한 변경 내용 감사
또한 전체 Azure 환경에서 감사와 로깅을 구성하고 특정 이벤트 또는 위협을 모니터링하는 것이 좋습니다.
Microsoft Sentinel과 같은 SIEM(보안 정보 및 이벤트 관리) 도구를 사용하는 것이 좋습니다. 이 도구를 사용하여 Azure 자산은 물론 Azure DevOps, GitHub, 기타 시스템에서도 로그를 수집하고 분석할 수 있습니다. Sentinel을 사용하여 Azure 리소스에 대한 예기치 않거나 승인되지 않은 변경을 모니터링할 수 있습니다. 파이프라인의 감사 로그를 가져오며, 관리자가 리포지토리에서 분기 보호 정책을 변경하는 경우와 같이 이벤트가 발생할 때 경고를 트리거할 수도 있습니다.