이 문서에서는 Azure DevOps를 사용하여 Microsoft Sentinel 통합 및 배포 작업을 자동화하는 방법을 설명합니다. 배포 보안을 위해 Microsoft Sentinel 기능을 사용하여 Azure DevOps를 구현합니다. 그런 다음 DevSecOps 프레임워크를 사용하여 대규모로 Microsoft Sentinel 아티팩트를 관리하고 배포합니다.
아키텍처
다음 다이어그램에서는 Azure DevOps 및 Microsoft Sentinel IaC 설정을 보여 줍니다.
이 아키텍처의 Visio 파일을 다운로드합니다.
데이터 흐름
- 스크럼 마스터 및 제품 관리는 Azure DevOps를 사용하여 프로젝트 백로그의 일부로 에픽, 사용자 스토리, 제품 백로그 항목을 정의합니다.
- 스크럼 마스터 및 제품 관리는 Azure Boards를 사용하여 백로그를 만들고, 스프린트에서 작업을 예약하고, 프로젝트 보드를 검토하고, 리포지토리 구조를 만들고, 승인 워크플로 및 분기와 같은 보안 규칙을 설정합니다.
- Azure Git 리포지토리는 스크립트를 저장하고 Microsoft Sentinel 아티팩트를 IaC(Infrastructure as Code)로 관리할 수 있습니다.
- 아티팩트 및 원본 제어는 Azure Resource Manager 템플릿 도구 키트 및 PowerShell Pester와 같이 솔루션에 사용되는 DevSecOps 워크플로의 확장 및 업데이트 패키지 또는 구성 요소를 유지 관리합니다.
- Microsoft Sentinel 아티팩트:
- 정책. SIEM 엔지니어는 참조 아키텍처에서 Azure 정책을 사용하여 Azure 서비스의 진단 설정을 구성하고 크기를 조정합니다. 정책은 Azure Key Vault와 같은 Microsoft Sentinel 데이터 커넥터의 배포를 자동화하는 데 도움이 됩니다. 정책은 OMSIntegration API에 따라 달라집니다.
- 커넥터. Microsoft Sentinel은 논리 커넥터인 Azure Data 커넥트ors를 사용하여 Microsoft Entra ID, Azure 리소스, Microsoft Defender 또는 타사 솔루션과 같은 지원되는 데이터 원본에서 감사 또는 메트릭과 같은 보안 데이터를 수집합니다. 데이터 커넥터의 기본 목록은 SecurityInsights API에서 관리됩니다. 다른 사용자는 OMSIntegration API를 사용하며 Azure Policy 진단 설정으로 관리됩니다.
- 관리 ID. Microsoft Sentinel은 관리 ID를 사용하여 플레이북, 논리 앱 또는 자동화 Runbook 및 키 자격 증명 모음과 상호 작용하는 동안 MSI(관리 서비스 ID)를 대신하여 작동합니다.
- 자동화. SOC 팀은 조사 중에 자동화를 사용합니다. SOC 팀은 Azure VM(가상 머신) 관리 연속성 또는 Microsoft Defender용 eDiscovery(프리미엄)와 같은 Azure Automation을 사용하여 디지털 포렌식 데이터 취득 절차를 실행합니다.
- 분석. SOC 분석가 또는 위협 사냥꾼은 기본 제공 또는 사용자 지정 분석 규칙을 사용하여 Microsoft Sentinel의 데이터를 분석 및 상호 연결하거나 위협 및 인시던트가 식별될 경우 플레이북을 트리거합니다.
- 플레이북. 논리 앱은 인시던트 할당, 인시던트 업데이트 또는 VM 격리 또는 포함, 토큰 해지 또는 사용자 암호 재설정과 같은 수정 작업을 수행하는 등 SecOps 반복 가능한 작업을 실행합니다.
- 위협을 헌팅합니다. 위협 사냥꾼은 데이터 처리, 데이터 조작, 데이터 시각화, 기계 학습 또는 딥 러닝과 같은 고급 사용 사례를 위해 Jupyter Notebook과 결합할 수 있는 사전 위협 헌팅 기능을 사용합니다.
- 통합 문서. SIEM 엔지니어는 통합 문서 대시보드를 사용하여 추세 및 통계를 시각화하고 Microsoft Sentinel 인스턴스 및 해당 하위 구성 요소의 상태 봅니다.
- 위협 인텔리전스 위협 인텔리전스 플랫폼 피드를 Microsoft Sentinel에 융합하는 특정 데이터 커넥터입니다. TAXII 및 Graph API의 두 가지 연결 방법이 지원됩니다. 두 방법 모두 보안 API에서 tiIndicator 또는 위협 인텔리전스 지표 역할을 합니다.
- Microsoft Entra ID. ID 및 액세스 관리 기능은 Microsoft Sentinel, 논리 앱 및 자동화 Runbook에 대한 관리 ID, 서비스 주체, Azure RBAC(역할 기반 액세스 제어)와 같은 참조 아키텍처에 사용되는 구성 요소에 전달됩니다.
- Azure Pipelines: DevOps 엔지니어는 파이프라인을 사용하여 CI/CD(지속적인 통합 및 지속적인 업데이트) 파이프라인을 사용하여 샌드박스 및 프로덕션 환경과 같은 다양한 Azure 구독을 관리하기 위한 서비스 연결을 만듭니다. Azure 환경당 여러 구독을 대상으로 하는 경우 승인 워크플로를 사용하여 예기치 않은 배포 및 분리된 서비스 주체를 방지하는 것이 좋습니다.
- Azure Key Vault. SOC 엔지니어는 키 자격 증명 모음을 사용하여 서비스 주체 비밀 및 인증서를 안전하게 저장합니다. 이 아키텍처 구성 요소는 Azure Pipeline 서비스 연결에서 사용할 때 코드에 비밀이 없다는 DevSecOps 원칙을 적용하는 데 도움이 됩니다.
- Azure 구독. SOC 팀은 이 참조 아키텍처에서 두 개의 Microsoft Sentinel 인스턴스를 사용하며, 두 개의 논리적 Azure 구독 내에서 분리되어 프로덕션 및 샌드박스 환경을 시뮬레이션합니다. 테스트, 개발, 사전 프로덕션 등과 같은 다른 환경으로 요구 사항을 스케일링할 수 있습니다.
데이터 흐름 예제
- 관리자는 Microsoft 365 구성 파일의 포크에 항목을 추가, 업데이트 또는 삭제합니다.
- 관리자는 변경 내용을 커밋하고 포크된 리포지토리에 동기화합니다.
- 그런 다음, 관리자는 PR(끌어오기 요청)을 만들어 변경 내용을 주 리포지토리에 병합합니다.
- 빌드 파이프라인은 PR에서 실행됩니다.
구성 요소
- Microsoft Entra ID 는 ID 및 액세스 제어를 관리하는 다중 테넌트 클라우드 기반 서비스입니다.
- Azure DevOps는 코드에 대해 협업하고, 앱을 빌드하고 배포하거나 작업을 계획하고 추적하는 클라우드 서비스입니다.
- Azure Key Vault는 비밀을 안전하게 저장하고 액세스하기 위한 클라우드 서비스입니다. 비밀은 API 키, 암호, 인증서 또는 암호화 키 등에 대한 액세스를 엄격하게 제어하려는 항목입니다.
- Azure Policy는 Azure 환경에서 정책 정의를 만들고, 할당하고, 관리하기 위한 서비스입니다.
- Microsoft Sentinel은 확장성 있는 클라우드 네이티브, SIEM(보안 정보 및 이벤트 관리), SOAR(보안 오케스트레이션, 자동화 및 응답) 솔루션입니다.
- Azure Automation은 프로세스 자동화를 통해 클라우드 관리를 간소화하기 위한 서비스입니다. Azure Automation을 사용하여 장기간 실행하고, 수동으로 작업하고, 오류가 발생하기 쉽고, 자주 반복되는 작업을 자동화합니다. 자동화는 회사의 안정성, 효율성, 가치 창출 시간을 개선하는 데 도움이 됩니다.
시나리오 정보
SOC(보안 운영 센터) 팀은 Microsoft Sentinel을 Azure DevOps와 통합할 때 종종 어려움을 겪습니다. 프로세스에는 여러 단계가 포함되며 설치에는 며칠이 걸리고 반복이 포함될 수 있습니다. 이 개발 부분을 자동화할 수 있습니다.
클라우드를 현대화하기 위해 엔지니어는 중요한 비즈니스 자산을 보호하고 보호하기 위한 새로운 기술과 기술을 지속적으로 학습해야 합니다. 엔지니어는 변화하는 보안 환경과 비즈니스 요구 사항에 보조를 맞추는 강력하고 확장 가능한 솔루션을 빌드해야 합니다. 보안 솔루션은 개발 초기 단계에서 유연하고 민첩하며 신중하게 계획해야 합니다. 이 초기 계획 방법론을 shift-left라고 합니다.
이 문서에서는 Azure DevOps를 사용하여 Microsoft Sentinel 통합 및 배포 작업을 자동화하는 방법을 설명합니다. 여러 엔터티, 구독 및 다양한 운영 모델이 있는 복잡한 조직에 대한 솔루션을 확장할 수 있습니다. 이 솔루션에서 지원하는 운영 모델 중 일부는 로컬 SOC, 글로벌 SOC, CSP(클라우드 서비스 공급자), MSSP(관리형 보안 서비스 공급자)를 포함합니다.
이 문서는 다음 대상 그룹을 위한 것입니다.
- 분석가 및 위협 사냥꾼과 같은 SOC 전문가
- SIEM(보안 정보 및 이벤트 관리) 엔지니어
- 사이버 보안 설계자
- 개발자
잠재적인 사용 사례
다음은 이 아키텍처의 일반적인 사용 사례입니다.
- 빠른 프로토타입 생성 및 개념 증명. 이 솔루션은 클라우드 위협 범위를 개선하거나 IaC(Infrastructure as Code) 및 Microsoft Sentinel을 사용하여 SIEM 인프라를 현대화하려는 보안 조직 및 SOC 팀에 적합합니다.
- Microsoft Sentinel as a Service. 이 개발 프레임워크는 서비스 수명 주기 관리 원칙을 통합합니다. 이러한 원칙은 Azure DevOps 및 Azure Lighthouse의 기능을 결합하면서 여러 고객 테넌트에서 반복 가능하고 표준화된 작업을 실행하는 MSSP와 같이 단순하거나 복잡한 팀에 적합합니다. 예를 들어 새 위협 행위자 또는 진행 중인 캠페인에 대해 Microsoft Sentinel 사용 사례를 게시해야 하는 팀이 이 솔루션을 사용할 수 있습니다.
- 위협 탐지를 위한 SOC 사용 사례를 빌드합니다. 많은 그룹 및 위협 인텔리전스 플랫폼은 MITRE Att&ck 콘텐츠 및 분류를 사용하여 고급 무역 기술 또는 기술 및 전술 절차에 대한 보안 태세를 분석합니다. 이 솔루션은 MICROSOFT Sentinel 아티팩트 개발 내에 MITRE Att&ck 용어를 통합하여 위협 탐지 엔지니어링 사례를 개발하기 위한 구조화된 접근 방식을 정의합니다.
다음 그림에서는 MITRE Att&ck 클라우드 시나리오를 보여 줍니다.
이 아키텍처의 Visio 파일을 다운로드합니다.
MITRE 기반 위협 정의 공격 시나리오
이 표에서는 공격 시나리오의 중요한 측면에 대한 용어, 정의, 세부 정보를 보여 줍니다.
| 데이터 항목 | 설명 | Microsoft Sentinel 아티팩트 |
|---|---|---|
| 제목 | 공격 벡터 특성 또는 기술 설명을 기반으로 하는 공격 시나리오의 설명 이름입니다. | MITRE 매니페스트 |
| MITRE ATT&CK 전술 | 공격 시나리오와 관련된 MITRE ATT&CK 전술 | MITRE 매니페스트 |
| MITRE ATT&CK 기술 | 공격 시나리오와 관련된 기술 또는 하위 기술 ID를 포함한 MITRE ATT&CK 기술입니다. | MITRE 매니페스트 |
| 데이터 커넥터 원본 | 센서 또는 로깅 시스템에서 수집한 정보의 원본으로, 수행 중인 작업, 일련의 작업 또는 악의적 사용자가 수행한 작업의 결과를 식별하는 것과 관련된 정보를 수집하는 데 사용할 수 있습니다. | Microsoft Sentinel 데이터 커넥터 또는 사용자 지정 로그 원본 |
| 설명 | 기술 관련 정보, 기술 정의, 일반적으로 사용되는 항목, 악의적 사용자가 해당 기술을 활용할 수 있는 방법, 사용 방법에 대한 변형입니다. 기법 관련뿐 아니라 실전 사용 참조에서도 기술적 정보를 적절하게 설명하는 신뢰할 수 있는 문서에 대한 참조를 포함합니다. | |
| 감지 | 악의적 사용자가 사용한 기술을 식별하는 데 유용한 개략적인 분석 프로세스, 센서, 데이터, 검색 전략입니다. 이 섹션에서는 분석 작성 또는 센서 배포와 같은 작업을 수행할 수 있도록 네트워크 방어자와 같은 악의적인 동작을 감지하는 담당자에게 알립니다. 유용한 방어 방법론을 가리키는 충분한 정보와 참조가 있어야 합니다. 특정 기술 검색이 항상 가능하지는 않을 수 있으며 이와 같이 문서화해야 합니다. | 분석 위협 헌팅 |
| 완화 방법 | 기술이 작동하거나 악의적 사용자가 원하는 결과를 갖지 못하게 하는 구성, 도구 또는 프로세스입니다. 이 섹션에서는 네트워크 방어자 또는 정책 입안자와 같이 악의적 사용자를 방어하는 담당자에게 정책 변경 또는 도구 배포와 같은 조치를 취할 수 있도록 합니다. 지정된 기술을 항상 완화할 수 있는 것은 아니며 이와 같이 문서화해야 합니다. | |
| 완화 방법 | 기술이 작동하거나 악의적 사용자가 원하는 결과를 갖지 못하게 하는 구성, 도구 또는 프로세스입니다. 이 섹션에서는 네트워크 방어자 또는 정책 입안자를 위해 악의적인 공격의 영향을 줄이는 방법을 설명합니다. 정책을 변경하거나 도구를 배포하는 단계를 다룹니다. 특정 기술을 항상 완화할 수 있는 것은 아니며 이와 같이 문서화해야 합니다. | 플레이북, 자동화 Runbook |
고려 사항
이러한 고려 사항은 워크로드의 품질 개선에 사용할 수 있는 일련의 기본 지침인 Azure Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Microsoft Azure Well-Architected Framework를 참조하세요.
보안
우수한 보안은 중요한 데이터 및 시스템에 대한 고의적인 공격과 악용을 방어합니다. 자세한 내용은 보안 요소의 개요를 참조하세요.
일반적으로 보안이 포함된 자동화는 작업 효율성을 높이는 동시에 위협 감지 엔지니어링, 위협 인텔리전스, SOC, SOAR 사용 사례와 같은 보다 복잡한 사용 사례에서 시간을 절약합니다. DevOps 팀은 Microsoft Sentinel CI/CD의 컨텍스트에서 IaC를 안전하게 사용할 수 있는 위치를 알아야 합니다. 이 프로세스에서는 서비스 주체 및 관리 ID라고 하는 Microsoft Entra ID의 비인간 계정에 사용되는 특정 ID를 사용합니다.
다음 표에는 서비스 주체에 대한 보안 고려 사항과 Microsoft Sentinel 및 Azure DevOps 릴리스 파이프라인에서 다루는 주요 사용 사례가 요약되어 있습니다.
| 사용 사례 | 요구 사항(최소 권한) | 역할 할당 기간 | 권한 범위 | 트러스티 | 보안 고려 사항 |
|---|---|---|---|---|---|
| Microsoft Sentinel 커넥터 사용 | 보안 관리자** 소유자* Microsoft Sentinel 기여자 판독기 |
JIT(일회성 활성화) 의도적(새 구독 및 커넥터가 배포할 때마다) |
테넌트 | SPN | 키 자격 증명 모음을 사용하여 SPN(서비스 사용자 이름) 비밀 및 인증서를 저장합니다. SPN 감사를 사용하도록 설정합니다. SPN에 대한 권한 할당(SPN용 Azure Privileged Identity Management) 또는 의심스러운 활동을 주기적으로 검토합니다. 권한 있는 계정에 대해 Microsoft Entra 인증 기관 및 다단계 인증(지원되는 경우)을 사용합니다. 보다 세분성을 위해 Microsoft Entra 사용자 지정 역할을 사용합니다. |
| 통합 문서, 분석, 규칙, 위협 헌팅 쿼리, Notebook, 플레이북과 같은 Microsoft Sentinel 아티팩트 배포 | Microsoft Sentinel 기여자 Logic Apps 기여자 |
영구 | Microsoft Sentinel의 작업 영역 또는 리소스 그룹 | SPN | ADO(Azure DevOps) 워크플로 승인 및 검사를 사용하여 이 SPN으로 파이프라인 배포를 보호합니다. |
| Microsoft Sentinel에 로그 스트리밍 기능을 구성하는 정책 할당 | 리소스 정책 기여자** | 의도적(새 구독 및 커넥터가 배포할 때마다) | 모니터링할 모든 구독 | SPN | 지원되는 경우 권한 있는 계정에 대해 Microsoft Entra ID, CA 및 MFA를 사용합니다. |
* Microsoft Entra 진단 설정만 관련됩니다.
** 특정 커넥터에는 Microsoft Sentinel 작업 영역, Microsoft Entra ID, Microsoft 365 또는 Microsoft Defender 및 Azure Key Vault와 같은 PaaS(Platform as a Service) 리소스로의 스트리밍 데이터를 허용하려면 "보안 관리자" 또는 "리소스 정책 기여자"과 같은 추가 권한이 필요합니다.
권한 있는 액세스 모델
권한 있는 액세스 모델 전략을 채택하여 권한 있는 액세스에 대한 높은 영향 및 가능성이 높은 공격으로 인한 회사의 위험을 신속하게 줄이는 것이 좋습니다. DevOps 모델의 자동 프로세스의 경우 ID는 서비스 주체 ID를 기반으로 합니다.
권한 있는 액세스는 모든 회사에서 최상위 보안 우선순위여야 합니다. 이러한 ID가 손상되면 매우 부정적인 영향을 미칩니다. 권한 있는 ID는 중요 비즈니스용 자산에 액세스할 수 있으며, 공격자가 이러한 계정을 손상시킬 경우 거의 항상 큰 영향을 미칩니다.
권한 있는 액세스의 보안은 다른 모든 보안 보증의 기본이기 때문에 매우 중요합니다. 권한 있는 계정을 컨트롤하는 공격자는 다른 모든 보안 보증을 약화시킬 수 있습니다.
따라서 최소 권한 원칙에 따라 서비스 주체를 다른 수준 또는 계층으로 논리적으로 분산하는 것이 좋습니다. 다음 그림에서는 액세스 유형 및 액세스가 필요한 위치에 따라 서비스 주체를 분류하는 방법을 보여 줍니다.
수준 0 서비스 주체
수준 0 서비스 주체에는 가장 높은 수준의 권한이 있습니다. 이러한 서비스 주체는 특정 인원에게 테넌트 전체 또는 루트 관리 그룹 관리 작업을 수행할 수 있는 전역 관리자 권한을 부여합니다.
보안상의 이유와 관리 편의성을 위해 이 수준을 가진 서비스 주체는 하나만 있는 것이 좋습니다. 이 서비스 주체에 대한 권한은 유지되므로 필요한 최소 권한만 부여하여 계정을 모니터링하고 보호하는 것이 좋습니다.
이 계정의 비밀 또는 인증서를 Azure Key Vault에 안전하게 저장합니다. 가능한 경우 전용 관리 구독에서 키 자격 증명 모음을 찾는 것이 좋습니다.
수준 1 서비스 주체
수준 1 서비스 주체는 비즈니스 조직 수준에서 관리 그룹으로 제한되고 범위가 지정된 상승된 권한입니다. 이러한 서비스 주체는 범위에 속한 관리 그룹에 속한 특정 인원에게 구독을 만들 수 있는 권한을 부여합니다.
보안상의 이유와 관리 편의성을 위해 이 수준을 가진 서비스 주체는 하나만 있는 것이 좋습니다. 이 서비스 주체에 대한 권한은 유지되므로 필요한 최소 권한만 부여하여 계정을 모니터링하고 보호하는 것이 가장 좋습니다.
이 계정의 비밀 또는 인증서를 Azure Key Vault에 안전하게 저장합니다. 가능한 경우 전용 관리 구독에서 키 자격 증명 모음을 찾는 것이 좋습니다.
수준 2 서비스 주체
수준 2 서비스 주체는 구독 수준으로 제한됩니다. 이러한 서비스 주체는 특정 인원에게 구독 하에서 관리 작업을 수행할 수 있는 권한을 부여하며 이 인원은 구독 소유자 역할을 합니다.
보안상의 이유와 관리 편의성을 위해 이 수준을 가진 서비스 주체는 하나만 있는 것이 좋습니다. 이 서비스 주체에 대한 권한은 유지되므로 필요한 최소 권한만 부여하여 계정을 모니터링하고 보호하는 것이 가장 좋습니다.
이 계정의 비밀 또는 인증서를 Azure Key Vault에 안전하게 저장합니다. 전용 관리 리소스 그룹에서 키 자격 증명 모음을 찾는 것이 좋습니다.
수준 3 서비스 주체
수준 3 서비스 주체는 워크로드 관리자로 제한됩니다. 일반적인 시나리오에서는 모든 워크로드가 동일한 리소스 그룹 내에 포함됩니다. 이 구조는 서비스 주체 권한을 이 리소스 그룹으로만 제한합니다.
보안상의 이유와 관리 편의성을 위해 워크로드당 하나의 서비스 주체만 사용하는 것이 좋습니다. 이 서비스 주체에 대한 권한은 유지되므로 필요한 최소 권한만 부여하여 계정을 모니터링하고 보호하는 것이 가장 좋습니다.
이 계정의 비밀 또는 인증서를 Azure Key Vault에 안전하게 저장합니다. 전용 관리 리소스 그룹에서 키 자격 증명 모음을 찾는 것이 좋습니다.
수준 4 서비스 주체
수준 4 서비스 주체는 가장 제한된 권한을 가집니다. 이러한 서비스 주체는 하나의 리소스로 제한된 관리 작업을 수행할 수 있는 권한을 부여합니다.
가능한 경우 관리 ID를 사용하는 것이 좋습니다. 관리되지 않는 ID의 경우 수준 3 비밀이 저장되는 Azure Key Vault에 비밀 또는 인증서를 안전하게 저장합니다.
운영 우수성
운영 우수성은 애플리케이션을 배포하고 프로덕션에서 계속 실행하는 운영 프로세스를 다룹니다. 자세한 내용은 운영 우수성 핵심 요소 개요를 참조하세요.
Microsoft Sentinel 솔루션은 완벽하고 성공적인 작업을 보장하는 세 가지 블록으로 구성됩니다.
첫 번째 블록은 필수 아키텍처 요소를 구성하는 환경 정의입니다. 이 블록의 주요 관심사는 배포할 프로덕션 및 비프로덕션 환경의 수를 고려한 다음, 모든 경우에서 설정이 동일한지 확인하는 것입니다.
두 번째 블록은 Microsoft Sentinel 커넥터 배포로, 팀에서 요구하는 커넥터 종류와 이를 사용하도록 설정하는 데 필요한 보안 요구 사항을 고려합니다.
세 번째 블록은 구성 요소의 코딩, 배포, 사용 또는 제거를 다루는 Microsoft Sentinel 아티팩트 수명 주기 관리입니다. 예를 들어 이 블록에는 분석 규칙, 플레이북, 통합 문서, 위협 헌팅 등이 포함됩니다.
아티팩트 간의 이러한 종속성을 고려합니다.
- 분석 규칙에 정의된 자동화 규칙
- 새 데이터 원본 또는 커넥터가 필요한 통합 문서 또는 분석
- 기존 구성 요소의 업데이트 관리
- 아티팩트 버전 관리 방법
- 업데이트되거나 완전히 새로운 분석 규칙을 식별, 테스트, 배포하는 방법
인프라 빌드, 테스트, 배포
Microsoft Sentinel 솔루션 및 DevOps를 관리할 때 엔터프라이즈 아키텍처의 연결 및 보안 측면을 고려하는 것이 중요합니다.
Azure DevOps는 Microsoft 호스팅 에이전트 또는 자체 호스팅 에이전트를 사용하여 작업을 빌드, 테스트, 배포할 수 있습니다. 회사의 요구 사항에 따라 Microsoft 호스팅, 자체 호스팅 또는 두 모델을 조합하여 사용할 수 있습니다.
- Microsoft 호스팅 에이전트. 이 옵션은 전체 조직의 공유 인프라이므로 Azure DevOps 에이전트를 사용하는 가장 빠른 방법입니다. 파이프라인에서 Microsoft 호스팅 에이전트를 사용하는 방법에 대한 자세한 내용은 Microsoft 호스팅 에이전트를 참조하세요. Microsoft 호스팅 에이전트는 하이브리드 네트워킹 환경에서 작동하여 IP 범위에 대한 액세스 권한을 부여할 수 있습니다. 이러한 에이전트가 액세스 권한을 부여하는 IP 범위를 다운로드하려면 Azure IP 범위 및 서비스 태그 – 퍼블릭 클라우드를 참조하세요.
- 자체 호스팅 에이전트. 이 옵션은 빌드 및 배포에 대한 종속 소프트웨어를 설치할 때 전용 리소스 및 더 많은 제어를 제공합니다. 자체 호스팅 에이전트는 Azure에서 VM, 확장 집합, 컨테이너를 통해 작업할 수 있습니다. 자체 호스팅 에이전트에 대한 자세한 내용은 Azure Pipelines 에이전트를 참조하세요.
GitHub 실행기
GitHub는 빌드, 테스트, 배포와 관련된 작업에 GitHub 호스팅 실행기 또는 자체 호스팅 실행기를 사용할 수 있습니다. 회사의 요구 사항에 따라 GitHub 호스팅, 자체 호스팅 또는 두 모델을 조합하여 사용할 수 있습니다.
GitHub 호스팅 실행기
이 옵션은 전체 조직에서 공유하는 인프라이므로 GitHub 워크플로를 사용하는 가장 빠른 방법입니다. 자세한 내용은 GitHub 호스팅 실행기 정보를 참조하세요. GitHub 호스팅 에이전트는 특정 네트워크 요구 사항에 따라 하이브리드 네트워킹 환경에서 작동합니다. 네트워크 요구 사항에 대한 자세한 내용은 지원되는 실행기 및 하드웨어 리소스를 참조하세요.
자체 호스팅 실행기
이 옵션은 회사에 전용 리소스 인프라를 제공합니다. 자체 호스팅 실행기는 Azure의 VM 및 컨테이너에서 작동하며 자동 스케일링을 지원합니다.
실행기 선택에 대한 고려 사항
Microsoft Sentinel 솔루션에서 에이전트 및 실행기에 대한 옵션을 선택할 때 다음 요구 사항을 고려합니다.
- 회사에는 Microsoft Sentinel 환경에서 프로세스를 실행하기 위한 전용 리소스가 필요한가요?
- 프로덕션 환경 DevOps 작업에 대한 리소스를 나머지 환경과 격리하려고 하나요?
- 내부 네트워크에서만 사용할 수 있는 중요한 리소스 또는 리소스에 액세스해야 하는 특정 사례를 테스트해야 하나요?
릴리스 프로세스의 오케스트레이션 및 자동화
Azure DevOps 또는 GitHub를 사용하여 배포 프로세스를 설정할 수 있습니다. Azure DevOps는 YAML 파이프라인 또는 릴리스 파이프라인 사용을 지원합니다. Azure DevOps에서 YAML 파이프라인을 사용하는 방법에 대한 자세한 내용은 Azure Pipelines 사용을 참조하세요. Azure DevOps에서 릴리스 파이프라인을 사용하는 방법에 대한 자세한 내용은 릴리스 파이프라인을 참조하세요. GitHub Actions를 이용한 GitHub 사용에 대한 자세한 내용은 GitHub Actions 이해를 참조하세요.
Azure DevOps
Azure DevOps 배포에서 다음 배포 작업을 수행할 수 있습니다.
- YAML 파이프라인을 사용하여 PR 승인을 자동으로 트리거하거나 요청 시 실행합니다.
- Azure DevOps 그룹을 사용하여 다양한 환경에 대한 서비스 연결을 관리합니다.
- 중요한 환경의 경우 서비스 연결 기능 및 Azure DevOps 그룹을 사용하여 배포 승인을 설정한 후 팀의 특정 사용자 권한을 할당합니다.
GitHub
GitHub 배포에서 다음 배포 작업을 수행할 수 있습니다.
- GitHub를 사용하여 PR 또는 배포 활동을 만듭니다.
- GitHub 비밀을 사용하여 서비스 주체 자격 증명을 관리합니다.
- GitHub와 연결된 워크플로를 통해 배포 승인을 통합합니다.
Microsoft Sentinel 인프라를 사용한 자동 배포
엔터프라이즈 아키텍처에 따라 하나 이상의 Microsoft Sentinel 환경을 배포할 수 있습니다.
- 프로덕션 환경에서 여러 인스턴스가 필요한 조직은 각 지리적 위치별로 동일한 테넌트에서 서로 다른 구독을 설정할 수 있습니다.
- 프로덕션 환경의 중앙 집중식 인스턴스는 동일한 테넌트에서 하나 이상의 조직에 대한 액세스를 제공합니다.
- 프로덕션, 사전 프로덕션, 통합 등과 같은 여러 환경이 필요한 그룹은 필요에 따라 환경을 만들고 삭제할 수 있습니다.
물리적 환경 정의와 논리적 환경 정의 비교
환경 정의 설정 시 두 가지 옵션(물리적 또는 논리적)을 선택할 수 있습니다. 둘 다 서로 다른 옵션과 장점이 있습니다.
- 물리적 정의 - Microsoft Sentinel 아키텍처의 요소는 IaC(Infrastructure as Code)에 대한 다음 옵션으로 정의됩니다.
- Bicep 템플릿
- ARM 템플릿(Azure Resource Manager 템플릿)
- Terraform
- 논리적 정의 - 그룹에서 다른 팀을 설정하고 환경을 정의하기 위한 추상화 레이어 역할을 합니다. 정의는 실제 인프라 레이어를 사용하여 배포 파이프라인 및 워크플로에서 빌드 환경에 대한 입력으로 설정됩니다.
논리 환경을 정의할 때 다음 사항을 고려합니다.
- 명명 규칙
- 환경 식별
- 커넥터 및 구성
코드 리포지토리
이전 섹션에 표시된 환경 접근 방식을 고려할 때 다음 GitHub 코드 리포지토리 조직을 고려합니다.
물리적 정의 - IaC 옵션에 따라 기본 배포 정의에 연결된 개별 모듈 정의를 사용하는 방법을 생각해 보세요.
다음 예제에서는 코드를 구성하는 방법을 보여 줍니다.
물리적 수준에서 아키텍처를 정의하는 팀으로 이 리포지토리에 대한 액세스를 제한하여 엔터프라이즈 아키텍처에서 동일한 정의를 보장합니다.
분기 및 병합 전략을 각 조직의 배포 전략에 맞게 조정할 수 있습니다. 팀에서 정의부터 시작해야 하는 경우 Git 분기 전략 채택을 참조하세요.
ARM 템플릿에 대한 자세한 내용은 Azure 리소스를 배포할 때 연결된 템플릿 및 중첩된 템플릿 사용을 참조하세요.
Bicep 환경 설정에 대한 자세한 내용은 Bicep 도구 설치를 참조하세요. GitHub에 대한 자세한 내용은 GitHub 흐름을 참조하세요.
논리적 정의는 회사의 환경을 정의합니다. Git 리포지토리는 다양한 회사 정의를 수집합니다.
다음 예제에서는 코드를 구성하는 방법을 보여 줍니다.
리포지토리는 서로 다른 팀에서 수행한 PR 작업을 반영합니다. 여러 환경은 서로 다른 팀에서 정의하고 회사의 소유자 또는 승인자가 승인합니다.
환경 배포를 실행하기 위한 권한 수준은 수준 2입니다. 이 수준은 필요한 보안 및 개인 정보를 사용하여 환경에 대한 리소스 그룹 및 리소스를 만들도록 합니다. 또한 이 수준은 프로덕션 환경, 프로덕션, 사전 프로덕션에서 허용되는 작업에 대한 사용자 권한을 설정합니다.
테스트 및 개발을 위해 주문형 환경과 테스트를 완료한 후 환경을 삭제하는 기능을 원하는 조직은 Azure DevOps 파이프라인 또는 GitHub 작업을 구현할 수 있습니다. Azure DevOps 이벤트 또는 GitHub 작업을 사용하여 필요에 따라 환경을 삭제하도록 예약된 트리거를 설정할 수 있습니다.
Microsoft Sentinel 커넥터 자동 구성
Microsoft Sentinel 커넥터는 Microsoft Entra ID, Microsoft 365, Microsoft Defender, 위협 인텔리전스 플랫폼 솔루션 등 엔터프라이즈 아키텍처 환경의 다양한 요소와의 연결을 지원하는 솔루션의 필수적인 부분입니다.
환경을 정의할 때 커넥터 구성을 사용하여 동종 구성으로 환경을 설정할 수 있습니다.
서비스 주체 수준 모델에서 DevOps 모델의 일부로 커넥터를 사용하는 것을 지원해야 합니다. 이렇게 하면 다음 표와 같이 적절한 수준의 사용 권한을 보장할 수 있습니다.
| 커넥터 시나리오 | 권한 액세스 모델 수준 | Azure 최소 권한 | 워크플로 승인 필요 |
|---|---|---|---|
| Microsoft Entra ID | 수준 0 | 전역 관리 또는 보안 관리자 | 권장 |
| Microsoft Entra ID 보호 | 수준 0 | 전역 관리 또는 보안 관리자 | 권장 |
| Microsoft Defender for Identity | 수준 0 | 전역 관리 또는 보안 관리자 | 권장 |
| Microsoft Office 365 | 수준 0 | 전역 관리 또는 보안 관리자 | 권장 |
| Microsoft Cloud App Security | 수준 0 | 전역 관리 또는 보안 관리자 | 권장 |
| Microsoft Defender XDR | 수준 0 | 전역 관리 또는 보안 관리자 | 권장 |
| Microsoft Defender for IOT | 수준 2 | 참가자 | 권장 |
| Microsoft Defender for Cloud | 수준 2 | 보안 Reader | 선택 사항 |
| Azure 활동 | 수준 2 | 구독 읽기 권한자 | 선택 사항 |
| 위협 인텔리전스 플랫폼 | 수준 0 | 전역 관리 또는 보안 관리자 | 권장 |
| 보안 이벤트 | 수준 4 | None | 선택 사항 |
| syslog | 수준 4 | None | 선택 사항 |
| DNS(미리 보기) | 수준 4 | None | 선택 사항 |
| Windows 방화벽 | 수준 4 | None | 선택 사항 |
| AMA를 통한 Windows 보안 이벤트 | 수준 4 | None | 선택 사항 |
Microsoft Sentinel 아티팩트 배포
Microsoft Sentinel 아티팩트 구현에서 DevOps는 각 회사에서 공격을 방지하고 수정하기 위해 여러 아티팩트가 생성되므로 관련성이 높아집니다.
아티팩트 구현은 한 팀 또는 여러 팀이 담당할 수 있습니다. 자동 빌드 및 아티팩트 배포는 가장 일반적인 프로세스 요구 사항이며 에이전트 및 실행기의 접근 방식과 조건을 결정합니다.
Microsoft Sentinel 아티팩트 배포 및 관리를 위해서는 Microsoft Sentinel REST API를 사용해야 합니다. 자세한 내용은 Microsoft Sentinel REST API를 참조하세요. 다음 다이어그램은 Azure REST API 스택의 Azure DevOps 파이프라인을 보여 줍니다.
PowerShell을 사용하여 리포지토리를 구현할 수도 있습니다.
팀에서 MITRE를 사용하는 경우 아티팩트를 다양하게 분류하고 각 아티팩트마다 전술 및 기술을 지정하는 것이 좋습니다. 각 아티팩트 형식에 해당하는 메타데이터 파일을 포함해야 합니다.
예를 들어 Azure ARM 템플릿을 사용하여 새 플레이북을 만들고 파일 이름이 Playbook.arm.json인 경우 Playbook.arm.mitre.json이라는 JSON 파일을 추가합니다. 이 파일의 메타데이터에는 사용 중인 MITRE 전술 또는 기술에 해당하는 CSV, JSON 또는 YAML 형식이 포함됩니다.
이 사례에 따라 팀은 사용하는 다양한 아티팩트 유형을 설정하는 동안 수행되는 작업을 기반으로 MITRE 검사를 평가할 수 있습니다.
빌드 아티팩트
빌드 프로세스의 목적은 최고 품질의 아티팩트를 생성하는 것입니다. 다음 다이어그램에서는 수행할 수 있는 빌드 프로세스 작업 중 일부를 보여 줍니다.
이 아키텍처의 Visio 파일을 다운로드합니다.
- JSON 또는 YAML 형식의 설명 스키마에 아티팩트 정의를 기반으로 한 다음, 구문 오류를 방지하기 위해 스키마의 유효성을 검사할 수 있습니다.
- ARM 템플릿 테스트 도구 키트를 사용하여 ARM 템플릿의 유효성을 검사합니다.
- PowerShell을 사용하여 사용자 지정 모델에 대한 YAML 및 JSON 파일의 유효성을 검사합니다.
- 관심 목록 설정의 유효성을 검사하고 정의한 CIDR(Classless Interdomain Routing) 레코드가 올바른 스키마(예: 10.1.0.0/16)를 따르는지 확인합니다.
- 구문 수준에서 유효성을 검사할 수 있는 분석 규칙, 헌팅 규칙, 라이브 스트림 규칙에 대해 구문 수준에서 유효성을 검사할 수 있는 KQL(키워드 쿼리 언어) 쿼리를 사용합니다.
- KQL 로컬 유효성 검사를 하나의 옵션으로 설정합니다.
- DevOps 파이프라인에 KQL 인라인 유효성 검사 도구를 통합합니다.
- Azure Automation용 PowerShell을 기반으로 하는 논리를 구현하는 경우 다음 요소를 사용하여 구문 유효성 검사 및 단위 테스트를 포함할 수 있습니다.
- 아티팩트에 포함된 메타데이터 파일을 기반으로 MITRE 매니페스트 메타데이터 보고서를 생성합니다.
아티팩트 내보내기
일반적으로 여러 팀이 여러 Microsoft Sentinel 인스턴스에서 작업하여 필요한 아티팩트를 생성하고 유효성 검사를 수행합니다. 회사에서는 기존 아티팩트 재사용을 목표로 기존 환경에서 아티팩트 정의를 가져오기 위한 자동 프로세스를 설정할 수 있습니다. Automation은 설치 중에 다른 개발 팀에서 만든 모든 아티팩트 정보를 제공할 수도 있습니다.
다음 다이어그램에서는 아티팩트 추출 프로세스의 예를 보여 줍니다.
이 아키텍처의 Visio 파일을 다운로드합니다.
아티팩트 배포
배포 프로세스의 목표는 다음과 같습니다.
- 출시 시간을 단축합니다.
- 여러 팀에서 솔루션 설정 및 관리와 관련된 성능을 향상합니다.
- 환경 상태를 평가하도록 통합 테스트를 설정합니다.
개발 팀은 이 프로세스를 사용하여 개발 중인 아티팩트 사용 사례를 배포, 테스트, 유효성을 검사할 수 있는지 확인합니다. 아키텍처 및 SOC 팀은 QA 환경에서 파이프라인 품질의 유효성을 검사하고 공격 시나리오에 대한 통합 테스트를 사용합니다. 테스트 사례에서 팀은 일반적으로 분석 규칙, 수정 플레이북, 관심 목록 등으로 다양한 아티팩트가 결합됩니다. 각 사용 사례의 일부에는 수집, 검색, 수정에서 전체 체인이 평가되는 공격 시뮬레이션이 포함됩니다.
다음 다이어그램은 아티팩트가 올바른 순서로 배포되도록 하는 배포 프로세스 시퀀스를 보여 줍니다.
이 아키텍처의 Visio 파일을 다운로드합니다.
Sentinel 아티팩트를 코드로 관리하면 작업을 유지 관리하고 CI/CD DevOps 파이프라인에서 배포를 자동화할 수 있는 유연한 방법을 제공합니다.
Microsoft 솔루션은 다음 아티팩트를 위해 자동화 워크플로를 제공합니다.
| 아티팩트 | 자동화 워크플로 |
|---|---|
| 관심 목록 | 코드 검토 스키마 유효성 검사 배포 관심 목록 및 항목 만들기, 업데이트, 삭제 |
| 분석 규칙 결합 Microsoft 보안 ML 동작 분석 변칙 예약됨 |
코드 검토 KQL 구문 유효성 검사 스키마 유효성 검사 Pester 배포 만들기, 사용, 업데이트, 삭제, 내보내기 경고 템플릿 지원 |
| 자동화 규칙 | 코드 검토 스키마 유효성 검사 배포 만들기, 사용, 업데이트, 삭제, 내보내기 |
| 커넥터 | 코드 검토 스키마 유효성 검사 배포 작업: 사용, 삭제(사용 안 함), 업데이트 |
| 헌팅 규칙 | 코드 검토 KQL 구문 유효성 검사 스키마 유효성 검사 Pester 배포 작업: 만들기, 사용, 업데이트, 삭제, 내보내기 |
| 플레이북 | 코드 검토 TTK 배포 작업: 만들기, 사용, 업데이트, 삭제, 내보내기 |
| 통합 문서 | 배포 작업: 만들기, 업데이트, 삭제 |
| Runbook | 코드 검토 PowerShell 구문 유효성 검사 Pester 배포 작업: 만들기, 사용, 업데이트, 삭제, 내보내기 |
선택한 자동화 언어에 따라 일부 자동화 기능이 지원되지 않을 수 있습니다. 다음 다이어그램은 언어에서 지원되는 자동화 기능을 보여 주는 다이어그램입니다.
* 아직 문서화되지 않은 개발 기능
** Microsoft Operational Insights 또는 Microsoft Insights 리소스 공급자 API에서 지원하는 자동화 방법
Azure Automation
다음 다이어그램에서는 관리형 서비스 ID를 사용하여 Microsoft Sentinel 액세스를 간소화하는 구성 요소를 보여 줍니다.
이 아키텍처의 Visio 파일을 다운로드합니다.
다른 리소스에 대한 액세스 권한을 부여해야 하는 경우 관리 ID를 사용하여 모든 중요한 작업에 고유한 ID를 보장합니다.
플레이북 설정에는 Azure Automation을 사용합니다. 다음과 같이 복잡한 작업과 자동화 기능에는 PowerShell 스크립트를 사용합니다.
- 다양한 수준의 자격 증명이 필요하고 Microsoft Entra ID 또는 사용자 지정 자격 증명을 기반으로 하는 타사 솔루션과 통합:
- Microsoft Entra 사용자 자격 증명
- Microsoft Entra 서비스 주체 자격 증명
- 인증서 인증
- 사용자 지정 자격 증명
- 관리 ID
- 조직 스크립트를 다시 사용하는 솔루션 또는 플레이북으로 복잡한 변환을 방지하기 위해 PowerShell 명령을 사용해야 하는 솔루션 구현:
- PowerShell 기반 솔루션
- Python 기반 솔루션
- 수정 작업이 클라우드 및 온-프레미스 리소스에 영향을 줄 수 있는 하이브리드 시나리오에서 솔루션 구현
Microsoft Sentinel 리포지토리
숙련된 DevOps 팀은 Azure DevOps에서 빌드된 CI/CD 파이프라인을 사용하여 IaC(Infrastructure as Code)에서 Microsoft Sentinel을 관리하는 것을 고려할 수 있습니다. 제품 그룹은 고객과 파트너가 Azure DevOps 보안 아키텍처를 빌드할 때 직면하는 과제를 이해하므로 다음 두 가지 이니셔티브가 도움이 될 수 있습니다.
- 참조 아키텍처 문서화
- Ignite 2021에서 “Microsoft Sentinel 리포지토리”라고 하는 새로운 솔루션 개발
다음 표에서는 팀의 요구 사항에 맞는 솔루션 선택을 지원하기 위해 기능과 기술 기준을 비교합니다.
| 사용 사례 및 기능 | Azure DevOps 및 GitHub 사용자 지정 접근 방식 | Microsoft Sentinel 리포지토리 |
|---|---|---|
| 에이전트, 파이프라인, Git, 대시보드, wiki, 서비스 주체, RBAC, 감사 등과 같은 Azure DevOps 아키텍처 구성 요소를 정의하는 데 시간을 할애하지 않고 Microsoft Sentinel 아티팩트 배포를 빠르게 시작하려고 합니다. | 권장하지 않음 | 권장 |
| CI/CD 파이프라인을 관리하기 위한 소규모 팀이 있고 기술 수준은 낮습니다. | 권장하지 않음 | 권장 |
| CI/CD 파이프라인의 모든 보안 측면을 제어하고 관리하려고 합니다. | 지원됨 | 지원되지 않음 |
| 개발자가 원본 제어, 코딩 검토, 롤백, 워크플로 승인 등과 같은 배포 파이프라인을 트리거할 수 있도록 허용하기 전에 게이트 및 분기를 통합하여 통합을 감독해야 합니다. | 지원됨 | 부분적으로 지원됨 |
| 사용자 지정된 Git 또는 리포지토리 구조가 있습니다. | 지원됨 | 지원됨 |
| 아티팩트 빌드에는 Resource Manager 또는 Bicep IaC 언어를 사용하지 않습니다. | 지원 여부 | 지원되지 않음 |
| 단일 Microsoft Entra 테넌트에서 여러 Microsoft Sentinel 작업 영역에 아티팩트 배포를 중앙에서 관리하려고 합니다. | 지원됨 | 지원됨 |
| 여러 Microsoft Entra 테넌트에서 CI/CD 파이프라인을 통합하거나 확장하려고 합니다. | 지원됨 | 지원됨 |
| 구독, 위치, 환경 등에 따라 매개 변수화가 다른 플레이북이 있습니다. | 지원됨 | TBD, 문서화할 지침 |
| 동일한 리포지토리에 서로 다른 아티팩트가 통합되고 사용 사례를 작성하려고 합니다. | 지원됨 | 지원됨 |
| 아티팩트 대량 제거 기능이 필요합니다. | 지원됨 | 지원되지 않음 |
가용성, 성능, 확장성
회사에서 Microsoft Sentinel 시나리오를 위한 Azure DevOps 에이전트 아키텍처를 선택할 때 다음 요구 사항을 고려합니다.
- 프로덕션 환경에서는 Microsoft Sentinel 환경 작업을 위해 전용 에이전트 풀이 필요할 수 있습니다.
- 비프로덕션 환경에서는 특히 CI/CD 사례별로 팀의 다양한 요구를 처리하기 위해 에이전트 풀을 많은 수의 인스턴스와 공유할 수 있습니다.
- 공격 시뮬레이션 시나리오는 전용 에이전트가 필요할 수 있는 특별한 경우입니다. 테스트 요구 사항에 전용 풀이 필요한지 여부를 고려합니다.
- 하이브리드 네트워킹 시나리오에서 작업하는 조직은 네트워크 내부에 에이전트를 통합하는 것을 고려할 수 있습니다.
조직은 컨테이너를 기반으로 에이전트에 대한 자체 이미지를 만들 수 있습니다. 자세한 내용은 Docker에서 자체 호스팅 에이전트 실행을 참조하세요.
Azure DevOps를 사용하여 Microsoft Sentinel 테넌트 간 관리
전역 SOC 또는 MSSP로 여러 테넌트를 관리해야 할 수 있습니다. Azure Lighthouse는 여러 Microsoft Entra 테넌트에서 동시에 확장된 작업을 지원하여 관리 작업을 보다 효율적으로 만듭니다. 자세한 내용은 Azure Lighthouse 개요를 참조하세요.
테넌트 간 관리는 다음 시나리오에서 특히 효과적입니다.
- 고객 테넌트에서 Microsoft Sentinel 리소스를 관리합니다.
- 여러 테넌트에서 공격을 추적하고 보안 경고를 확인합니다.
- 테넌트에 걸쳐 분산되어 있는 여러 Microsoft Sentinel 작업 영역에서 인시던트를 봅니다.
고객 온보딩 방법
고객을 온보딩하는 두 가지 옵션에는 관리형 서비스 제품과 ARM 템플릿이 있습니다.
ARM 템플릿을 사용한 수동 온보딩
Azure Marketplace에 서비스 공급자로 제안을 게시하지 않으려는 경우 또는 일부 요구 사항을 충족하지 않는 경우 ARM 템플릿을 사용하여 수동으로 고객을 온보딩할 수 있습니다. 동일한 엔터프라이즈에 여러 테넌트가 있는 엔터프라이즈 시나리오에서 가장 가능성이 높은 옵션입니다.
다음 표에서는 온보딩 방식을 비교합니다.
| 고려 사항 | 관리 서비스 제품 | ARM 템플릿 |
|---|---|---|
| 파트너 센터 계정 필요 | 예 | 예 |
| Silver 또는 Gold 클라우드 플랫폼 역량 수준 또는 Azure Expert MSP(관리형 서비스 공급자) 상태 필요 | 예 | 예 |
| Azure Marketplace를 통해 신규 고객에게 제공 | 예 | 예 |
| 특정 고객으로 제안을 제한할 수 있음 | 예(CSP 프로그램의 재판매인을 통해 설정된 구독에서 사용할 수 없는 프라이빗 제안에만 해당) | 예 |
| Azure Portal을 통한 고객 동의 필요 | 예 | 예 |
| 자동화를 사용하여 여러 구독, 리소스 그룹 또는 고객을 온보딩할 수 있음 | 예 | 예 |
| 새로운 기본 제공 역할 및 Azure Lighthouse 기능에 즉시 액세스 제공 | 항상 그렇지는 않음(약간의 지연 후 일반적으로 사용 가능) | 예 |
관리형 서비스 제품을 게시하는 방법에 대한 자세한 내용은 Azure Marketplace에 관리형 서비스 제품 게시를 참조하세요.
ARM 템플릿을 만드는 방법에 대한 자세한 내용은 ARM 템플릿 만들기 및 배포를 참조하세요.
다음 다이어그램은 AZURE Lighthouse 및 Microsoft Sentinel을 사용하여 MSSP 테넌트와 고객의 리소스 공급자 테넌트 간의 상위 수준 아키텍처 통합을 보여 줍니다.
이 아키텍처의 Visio 파일을 다운로드합니다.
- MSP 제품은 ARM 템플릿 또는 Azure Marketplace 서비스 제품을 통해 통합됩니다.
- Azure 위임 리소스 관리는 파트너 테넌트에서 요청한 것임을 확인하고 관리형 서비스 리소스 공급자를 호출합니다.
- 관리형 서비스 리소스 공급자는 RBAC를 사용하여 MSP의 액세스를 제어합니다.
- MSP는 고객 리소스에 대한 SecOps 작업을 완료합니다.
- 청구 프로세스는 비용을 고객 요금으로 처리합니다. 고객 엔터티에 동일한 Microsoft Entra 테넌트에 별도의 작업 영역이 있는 경우 분할 청구가 가능합니다.
- 데이터의 보안 및 주권은 고객의 테넌트 경계에 따라 달라집니다.
여러 테넌트에서 식별
Azure DevOps를 사용하여 Microsoft Sentinel을 관리하려면 구성 요소에 대한 다음 디자인 결정을 평가합니다.
| 사용 사례 | 장점 |
|---|---|
| DevOps 작업을 관리하기 위한 글로벌 ID, 단일 서비스 주체 | 이 사례는 모든 테넌트가 포함된 전역 배포 프로세스에 적용됩니다. 통합 ID를 사용하면 다른 테넌트에서 쉽게 액세스할 수 있지만 특정 테넌트에서 승인 작업을 관리하는 프로세스가 복잡할 수 있습니다. 관련 전역 영향으로 인한 권한 없는 사용을 방지하려면 이러한 종류의 ID에 대한 보호 메커니즘 및 권한 부여 모델도 매우 중요합니다. |
| DevOps 작업, 여러 서비스 주체를 관리하기 위한 전용 ID | 이 사례는 배포 프로세스가 각 테넌트 전용이거나 테넌트 작업에 승인이 필요한 경우에 적용됩니다. 이 경우 영향은 줄어들지만, 이 ID 사용을 보호하고 권한을 부여하는 권장 사항은 전역 사례와 동일합니다. |
코드 리포지토리 조직
| 사용 사례 | 장점 |
|---|---|
| 모든 테넌트에 대한 단일 버전의 코드가 있는 통합 리포지토리 | 이 경우 리포지토리에서 통합 코드 버전을 쉽게 사용할 수 있습니다. 이 경우 테넌트에 대한 특정 버전을 관리하는 코드의 통합 버전에서 각 사례에 대한 분기를 지원해야 할 수 있습니다. |
| 테넌트별 특정 코드 폴더가 있는 통합 리포지토리 | 이 사례는 단일 리포지토리 사례를 보완합니다. 여기서 폴더 구조는 테넌트별 전용 아티팩트로 분할할 수 있습니다. |
| 테넌트별 전용 리포지토리 | 이 방법은 코드 아티팩트 관리 시 격리를 제공합니다. 이렇게 하면 팀 또는 요구 사항이 서로 다른 테넌트 간에 더 쉽게 진화할 수 있습니다. 변경 내용을 통합하려면 리포지토리 간에 프로세스를 설정해야 하며, 이를 유지 관리하려면 노력이 필요할 수 있습니다. |
빌드 및 배포 프로세스
| 사용 사례 | 장점 |
|---|---|
| 모든 테넌트에서 단일 빌드 프로세스 | 모든 테넌트가 동일한 버전의 아티팩트에서 작동하는 경우 생성 및 패키지를 구현하기 위한 가장 간단한 옵션입니다. |
| 테넌트별 빌드 프로세스 | 각 테넌트마다 다른 버전의 코드가 배포됩니다. |
| 모든 테넌트에서 전역 배포 프로세스 | 새 배포 및 배포 업데이트는 모든 테넌트에 적용됩니다. 배포 및 업데이트 프로세스의 단계는 모든 테넌트에서 사용됩니다. |
| 테넌트별 전역 배포 프로세스 | 새 배포 및 배포 업데이트는 하나 이상의 테넌트에 적용됩니다. |
| 테넌트별 전용 배포 프로세스 | 배포 프로세스는 각 테넌트별로 조정됩니다. |
비용 최적화
비용 최적화는 불필요한 비용을 줄이고 운영 효율성을 높이는 것입니다. 자세한 내용은 비용 최적화 핵심 요소 개요를 참조하세요.
솔루션 비용은 다음 요인에 따라 달라집니다.
- 회사에서 Microsoft Sentinel Log Analytics 작업 영역에 매월 공급하는 데이터의 양
- PAYG(종량제)와 같이 선택한 약정 계층 또는 청구 방법
- 테이블 또는 전역 수준에서 데이터 정책의 보존 속도
자세한 내용은 Azure 데이터 형식 보존을 참조하세요.
가격 책정을 계산하려면 Microsoft Sentinel 가격 책정 계산기를 참조하세요. 고급 가격 책정 고려 사항 및 예제에 대한 자세한 내용은 Microsoft Sentinel에 대한 플랜 비용을 참조하세요.
다음 구성 요소를 사용하여 솔루션을 확장하는 경우 추가 비용이 발생할 수 있습니다.
- 플레이북 - Azure Logic Apps 및 Azure Functions용 런타임 자세한 내용은 가격 책정 정보를 참조하세요.
- Azure Data Explorer, Event Hubs 또는 Azure Storage 계정과 같은 외부 스토리지로 내보내기
- 기계 학습 작업 영역 및 Jupyter Notebook 구성 요소에서 사용하는 컴퓨팅입니다.
시나리오 배포
다음 섹션에서는 다양한 DevOps 프로세스를 다루는 샘플 사용 사례의 형태로 이 시나리오를 배포하는 단계를 설명합니다.
Microsoft Sentinel 프레임워크 빌드 및 릴리스
먼저 다양한 프로세스에서 생성하는 릴리스를 사용할 수 있는 전용 리포지토리에서 필요한 NuGet 구성 요소를 설정합니다.
Azure DevOps를 사용하는 경우 PowerShell용 Microsoft Sentinel 프레임워크에서 다른 NuGet 패키지를 호스트하는 구성 요소 피드를 만들 수 있습니다. 자세한 내용은 NuGet 패키지 시작을 참조하세요.
팀에서 GitHub 레지스트리를 선택하는 경우 피드 프로토콜과 호환되므로 NuGet 리포지토리로 연결할 수 있습니다. 자세한 내용은 GitHub 패키지 소개를 참조하세요.
사용 가능한 NuGet 리포지토리가 있는 경우 파이프라인에는 NuGet에 대한 서비스 연결이 포함됩니다. 이러한 스크린샷은 Microsoft Sentinel NuGet 프레임 연결이라는 새 서비스 연결에 대한 구성을 보여 줍니다.
피드를 구성한 후 특정 포크의 GitHub에서 직접 PowerShell 프레임워크를 빌드하기 위한 파이프라인을 가져올 수 있습니다. 자세한 내용은 GitHub 리포지토리 빌드를 참조하세요. 이 경우 새 파이프라인을 만들고 GitHub를 코드 원본으로 선택합니다.
또 다른 옵션은 Git 리포지토리를 Git을 기반으로 하는 Azure DevOps 리포지토리로 가져오는 것입니다. 두 경우 모두 파이프라인을 가져오려면 다음 경로를 지정합니다.
src/Build/Framework/ADO/Microsoft.Sentinel.Framework.Build.yml
이제 파이프라인을 처음으로 실행할 수 있습니다. 그런 다음, 프레임워크는 NuGet 피드를 빌드하고 릴리스합니다.
Microsoft Sentinel 환경 정의
Microsoft Sentinel로 시작하고 이러한 샘플을 사용할 때 회사의 환경(예: EaC(Environment as Code))을 정의합니다. 각 경우에서 환경을 구성하는 다양한 요소를 지정합니다.
Microsoft Sentinel 아키텍처에는 Azure의 다음 요소가 포함됩니다.
- Log Analytics 작업 영역 - 이 작업 영역은 솔루션의 기초를 형성합니다. 보안 관련 정보는 여기에 저장되며 작업 영역은 KQL(Kusto 쿼리 언어)의 엔진입니다.
- Log Analytics 작업 영역에 대한 Microsoft Sentinel 솔루션 - 이 솔루션은 SIEM 및 SOAR 기능을 포함하도록 Log Analytics 작업 영역의 기능을 확장합니다.
- Key Vault - 키 자격 증명 모음은 수정 프로세스 중에 사용되는 비밀과 키를 유지합니다.
- Automation 계정 - 이 계정은 선택 사항이며 수정 프로세스에 사용됩니다. 사용하는 수정 프로세스는 PowerShell 및 Python Runbook을 기반으로 합니다. 이 프로세스에는 모범 사례에 따라 다양한 리소스에서 작동하는 시스템 관리 ID가 포함됩니다.
- 사용자 관리 ID - 이 기능은 Microsoft Sentinel 플레이북과 Runbook 간의 상호 작용을 관리하는 Microsoft Sentinel 통합 ID 레이어의 역할을 합니다.
- 논리 앱 연결 - 사용자 관리 ID를 사용하는 Microsoft Sentinel, 키 자격 증명 모음, 자동화에 대한 연결입니다.
- 외부 논리 앱 연결 - 수정 프로세스에 관여하고 플레이북을 기반으로 하는 외부 리소스에 대한 연결입니다.
- Azure Event Hubs - 이 기능은 선택 사항이며 Microsoft Sentinel과 Splunk, Azure Databricks, 기계 학습, 복원력과 같은 다른 솔루션 간의 통합을 처리합니다.
- Storage 계정 - 이 기능은 선택 사항이며 Microsoft Sentinel과 Splunk, Azure Databricks, 기계 학습, 복원력과 같은 다른 솔루션 간의 통합을 처리합니다.
리포지토리의 예제를 사용하면 JSON 파일로 환경을 정의하여 다른 논리적 개념을 지정할 수 있습니다. 환경을 정의하는 데 사용할 수 있는 옵션은 리터럴 또는 자동일 수 있습니다.
리터럴 정의에서 이 예제와 같이 환경의 각 리소스에 대한 이름과 요소를 지정합니다.
{
{
"SubscriptionId": "<subscription-identifier-associated-with-service-connection>",
"Name": "<environment-name>",
"NamingConvention": "<naming-convention-template-for-automatic-cases>",
"Location": "<environment-location>",
"ResourceGroup": {
"Type": "Literal",
"ResourceGroupName": "<resource-group-name>"
}
},
"Resources":
{
"Sentinel":
{
"Type": "Literal",
"LogAnalyticsWorkspaceName": "<Log-Analytics-workspace-name>",
"ManagedIdentityName": "<user-managed-identity-name>",
"SentinelConnectionName": "<Sentinel-API-connection-name>",
"KeyVaultName": "<Key-Vault-name>",
"KeyVaultConnectionName": "<Key-Vault-API-connection-name>"
},
"Automation":
{
"Type": "Literal",
"AutomationAccountName": "<automation-account-name>",
"AutomationAccountConnectionName": "<automation-account-API-connection-name>"
},
"Integration":
{
"Type": "Literal",
"EventHubNamespaces": [
"<Event-Hubs-namespace-1-name>",
"<Event-Hubs-namespace-2-name>",
"<Event-Hubs-namespace-3-name>",
"<Event-Hubs-namespace-4-name>",
"<Event-Hubs-namespace-5-name>",
"<Event-Hubs-namespace-6-name>",
"<Event-Hubs-namespace-7-name>",
"<Event-Hubs-namespace-8-name>",
"<Event-Hubs-namespace-9-name>",
"<Event-Hubs-namespace-10-name>",
],
"StorageAccountName": "<storage-account-name>"
}
}
}
자동 정의에서 요소 이름은 이 예제와 같이 명명 규칙에 따라 자동으로 생성됩니다.
{
{
"SubscriptionId": "<subscription-identifier-associated-with-service-connection>",
"Name": "<environment-name>",
"NamingConvention": "<naming-convention-template-for-automatic-cases>",
"Location": "<environment-location>",
"ResourceGroup": {
"Type": "Automatic"
}
},
"Resources":
{
"Sentinel":
{
"Type": "Automatic"
},
"Automation":
{
"Type": "Automatic"
},
"Integration":
{
"Type": "Automatic",
"MaxEventHubNamespaces": 5
}
}
}
Microsoft Sentinel 환경 경로 아래의 GitHub 리포지토리에서 샘플을 찾고 사용 사례를 준비하는 데 참조로 샘플을 사용할 수 있습니다.
Microsoft Sentinel 환경 배포
하나 이상의 환경이 정의된 경우 Azure 서비스 연결을 만들어 Azure DevOps와 통합할 수 있습니다. 서비스 연결을 만든 후 연결된 서비스 주체를 소유자 역할 또는 대상 구독과 유사한 권한 수준으로 설정합니다.
이 파일에 정의된 대로 새 환경을 만들기 위한 파이프라인을 가져옵니다.
src/Release/Sentinel Deployment/ADO/Microsoft.Sentinel.Environment.Deployment.yml다음으로 환경을 나타내는 서비스 연결의 이름을 입력합니다.
리포지토리에서 환경 정의에 대한 분기를 선택합니다.
Azure 환경 연결 상자에 구독에 대한 Azure DevOps 서비스 연결 이름을 입력합니다.
서비스 연결 시 동일한 구독의 여러 환경을 확인하는 데 사용할 수 있는 환경 이름을 입력합니다.
커넥터에 적용할 작업을 선택합니다.
PowerShell 프레임워크 구성 요소의 시험판 버전을 사용하려면 PowerShell 시험판 아티팩트 사용을 선택합니다.
파이프라인에는 배포 흐름의 일부로 다음 단계가 포함됩니다.
- NuGet 구성 요소를 배포합니다.
- 아티팩트 리포지토리와 함께 NuGet 도구를 사용하여 연결합니다.
- 피드를 확인합니다.
- 필요한 모듈을 설치합니다.
- 환경 정의를 가져옵니다.
- 대상에 있는 리소스의 유효성을 검사합니다.
- 작업 영역에 없는 경우 Log Analytics 및 Microsoft Sentinel을 추가합니다.
- Log Analytics가 이미 있는 경우 Log Analytics 인스턴스에 Microsoft Sentinel을 추가합니다.
- Microsoft Sentinel과 Logic Apps 간의 상호 작용을 나타내는 관리 ID를 만듭니다.
- Azure Key Vault를 만들고 비밀 및 키를 관리하기 위한 역할 할당을 관리 ID로 설정합니다.
- 해당하는 경우 Azure Automation 계정을 만들고 시스템이 할당한 관리 ID를 켭니다.
- 시스템이 할당한 관리 ID에 대한 키 자격 증명 모음을 통해 역할 할당을 설정합니다.
- Event Hubs 정의가 없는 경우 만들고 정의에 통합 요소가 포함되어 있는지 여부를 설정합니다.
- 시스템이 할당한 관리 ID에 대한 키 자격 증명 모음을 통해 역할 할당을 설정합니다.
- 스토리지 계정 정의가 없는 경우 만들고 정의에 통합 요소가 포함되어 있는지 여부를 설정합니다.
- 시스템이 할당한 관리 ID에 대한 키 자격 증명 모음을 통해 역할 할당을 설정합니다.
- 커넥터 작업 배포
- Automation 계정에 통합 Runbook을 배포합니다.
- Logic Apps 연결이 환경의 일부로 정의된 경우 배포합니다.
Microsoft Sentinel 환경 삭제
개발 또는 테스트 환경의 경우처럼 환경이 더 이상 필요하지 않은 경우 이 파일에 정의된 대로 삭제할 수 있습니다.
src/Release/Sentinel Deployment/ADO/Microsoft.Sentinel.Environment.Destroy.yml
환경 파이프라인을 배포할 때와 마찬가지로 환경을 나타내는 서비스 연결의 이름을 지정합니다.
Microsoft Sentinel 환경 작업
환경이 준비되면 다양한 사용 사례를 설정하기 위한 아티팩트 만들기를 시작할 수 있습니다.
이 파일에 정의된 대로 작업 중인 환경에서 아티팩트를 내보냅니다.
src/Release/Artifacts Deployment/ADO/Microsoft.Sentinel.Artifacts.Export.yml리포지토리에서 환경 정의에 대한 분기를 선택합니다.
Azure 환경 연결 상자에서 내보낼 환경에 대한 Azure DevOps 서비스 연결 이름을 입력합니다.
PowerShell 프레임워크 구성 요소의 시험판 버전을 사용하려면 PowerShell 시험판 아티팩트 사용을 선택합니다.
분석 및 헌팅 규칙의 형식을 선택합니다.
아티팩트 출력 파일은 결과에서 사용할 수 있습니다. 아티팩트가 있으면 Git 리포지토리에 출력 파일을 포함할 수 있습니다.
Microsoft Sentinel 환경에서 아티팩트 빌드
Microsoft Sentinel MITRE 사용 사례 경로 아래에 아티팩트 배치 다양한 아티팩트 유형에 따라 폴더 구조를 설정합니다.
이 파일에 정의된 대로 빌드 프로세스를 시작합니다.
src/Build/Artifacts/ADO/Microsoft.Sentinel.Artifacts.Build.yaml리포지토리에서 환경 정의에 대한 분기를 선택합니다.
아티팩트 빌드를 위한 분기를 선택하는 방법을 보여 주는 다이어그램](./media/build-artifacts-pipeline.png)
PowerShell 프레임워크 구성 요소의 시험판 버전을 사용하려면 PowerShell 시험판 아티팩트 사용을 선택합니다.
파이프라인은 다음 단계로 구성됩니다.
- NuGet 구성 요소를 배포합니다.
- NuGet 도구를 아티팩트 리포지토리에 연결합니다.
- 피드를 확인합니다.
- 필요한 모듈을 설치합니다.
- ARM 템플릿의 유효성을 검사하기 위한 테스트 도구 키트 프레임워크를 가져옵니다.
- ARM 템플릿의 유효성을 검사합니다.
- PowerShell Runbook 코드의 유효성을 검사하고 구문 유효성 검사를 수행합니다.
- 해당하는 경우 Pester 단위 테스트를 실행합니다.
- 헌팅 및 분석 규칙에서 KQL 구문의 유효성을 검사합니다.
Microsoft Sentinel 환경에 아티팩트 배포
아티팩트 배포 시 이 리포지토리에서 Microsoft Sentinel 리포지토리 또는 배포 파이프라인 샘플을 사용할 수 있습니다. 자세한 내용은 리포지토리에서 사용자 지정 콘텐츠 배포를 참조하세요.
Microsoft Sentinel 리포지토리
Microsoft Sentinel 리포지토리를 사용하는 경우 각 Microsoft Sentinel 인스턴스에 연결된 리포지토리에 아티팩트가 포함되도록 릴리스 프로세스를 설정할 수 있습니다. 아티팩트가 리포지토리에서 커밋되면 파이프라인을 만들고 Microsoft Sentinel 리포지토리를 사용하도록 설정하는 과정의 일부로 일부 단계가 자동으로 수행됩니다.
또한 이 문서에 설명된 사례에 따라 Microsoft Sentinel 리포지토리가 수행하는 배포 프로세스를 사용자 지정할 수 있습니다. 고려해야 할 중요한 측면 중 하나는 다음 접근 방식에 따라 설정할 수 있는 릴리스 승인입니다.
- 아티팩트 커밋 시 PR 승인 자세한 내용은 끌어오기 요청 만들기를 참조하세요.
- 배포를 실행할 때 파이프라인 승인을 해제합니다. 자세한 내용은 승인 및 검사 정의를 참조하세요.
Microsoft Sentinel 배포 파이프라인 샘플
Microsoft Sentinel 배포 파이프라인 샘플을 사용하여 릴리스 프로세스를 설정할 수 있습니다.
이 파일에 정의된 대로 릴리스 프로세스를 설정합니다.
src/Release/Artifacts Deployment/ADO/Microsoft.Sentinel.Artifacts.Deployment.yml리포지토리에서 환경 정의에 대한 분기를 선택합니다.
Azure 환경 연결 상자에서 내보낼 환경에 대한 Azure DevOps 서비스 연결 이름을 입력합니다.
PowerShell 프레임워크 구성 요소의 시험판 버전을 사용하려면 PowerShell 시험판 아티팩트 사용을 선택합니다.
참가자
Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.
보안 주체 작성자:
- Kevin Kisoka | 연결 설계자
비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.
다음 단계
- 단일 테넌트 아키텍처용 DevOps를 사용하는 Microsoft Sentinel에 대한 자세한 내용은 Microsoft Sentinel을 코드로 배포 및 관리를 참조하세요.
- MSSP 다중 테넌트 아키텍처에 대한 자세한 내용은 Azure Lighthouse와 Microsoft Sentinel의 DevOps 기능 결합을 참조하세요.
- Microsoft Sentinel을 사용하는 관리 ID에 대한 자세한 내용은 새로운 기능: Microsoft Sentinel Logic Apps 커넥터용 관리 ID를 참조하세요.
- Microsoft Sentinel 리포지토리에서 콘텐츠를 배포하는 방법을 알아보려면 리포지토리에서 사용자 지정 콘텐츠 배포를 참조하세요.
- Azure DevOps Security 고려 사항에 대한 자세한 내용은 기본 권한 빠른 참조를 참조하세요.
- Azure DevOps 리포지토리를 보호하는 방법을 알아보려면 리포지토리 리소스에 보호 추가를 참조하세요.
- Azure DevOps 서비스 연결 보안을 관리하는 방법에 대한 자세한 내용은 Azure Pipelines의 서비스 연결을 참조하세요.