인시던트 후 검토 프로세스
- 7분
인시던트 후 검토의 핵심 부분은 인시던트 비선형 특성을 반영하는 공유되고 정확한 시간론을 생성하는 것입니다.
비선형성이라는 것은 사건들이 거의 항상 단순히 "이런 일이 일어나서, 저런 일이 일어나고, 우리는 알아차리고, 조치를 취하고, 그리고 모든 것이 끝났다는 식은 아니다"라는 뜻입니다. 사람들은 오고 가고, 여러 사람이 알아차리고 다른 것들을 시도하는 과정에서 어떤 것은 효과가 있고, 어떤 것은 효과가 없습니다. 그리고 여러 사람이 동시에 일하는 경우 이러한 일도 동시에 발생할 수 있으므로 조금 더 복잡합니다.
이와 같은 타임라인을 만들기 위해 복잡한 타임라인도 항상 중요한 첫 번째 단계인 데이터 수집이 있습니다.
데이터 수집
인시던트 후 검토를 수행하려면 먼저 데이터를 수집해야 합니다. 특히, 이벤트에 포함된 모든 중요한 데이터를 사용할 수 있도록 이벤트를 둘러싼 대화와 컨텍스트(기술 및 비기술 모두)를 최대한 많이 수집해야 합니다. 중단 또는 인시던트 중에 발생한 팀 구성원 간의 대화는 가장 풍부한 정보 원본 중 하나가 될 것입니다.
또한 모니터링 시스템 및 인시던트에 관련된 사람들이 컨텍스트를 그린 다른 위치에서 데이터를 수집해야 합니다. 인시던트가 발생했을 때 시스템에서 어떤 정보를 얻게 되었나요?
마지막으로, 가능하면 인시던트 발생 시 변경 내용이 요인에 영향을 주는 경우가 많기 때문에 인시던트 이전과 도중에 변경된 내용을 더 잘 파악하는 것이 도움이 될 것입니다.
이 프로세스를 세 가지 개별 부분으로 볼 수 있습니다.
- 대화 수집: 이 학습 경로의 다른 모듈에서는 인시던트 중에 사람들이 통신할 수 있는 특정 장소를 개척하는 것이 중요하다고 언급했습니다. 이 사건 동안, 이상적으로 사람들은 무엇이 효과가 있었는지, 실패한 것, 시도하기를 주저하는 것, 과거에 시도한 것을 공유하는 것이 좋습니다. 사람들이 문제를 해결하고 작업하는 동안 이 대화는 학습의 가장 좋은 원천입니다.
- 컨텍스트 확인: 인시던트에 있는 사용자가 다양한 위치에서 신호를 받고 있습니다. 한 가지 주요 위치는 모니터링 시스템입니다. 이 학습 경로의 이전 모듈에서 견고한 모니터링 시스템을 갖는 것의 중요성에 대해 설명했습니다. 이상적으로 모니터링 시스템을 살펴보고 인시던트 전후 또는 관련 기간 동안 특정 시점 스냅샷을 빌드할 수 있어야 합니다.
- 변경 내용 찾기: 활동 및 감사 로그를 통해 이 작업을 수행할 수 있습니다.
데이터를 수집하는 데 도움이 되는 Azure 도구
Azure 이 프로세스를 지원할 수 있는 다양한 도구를 제공합니다.
인시던트에 대한 메타데이터를 보관하기 위한 Azure DevOps
이 학습 경로의 이전 모듈에서는 Azure DevOps 제품군의 Azure Boards 사용하여 초기 응답에서 시작하는 인시던트에 대한 모든 정보를 수집하는 방법에 대해 설명했습니다. 인시던트가 처음 선언된 시간, 통화 중인 사람, 인시던트에 할당된 사람 등에 대한 질문을 하는 데 도움이 됩니다. 또한 Azure DevOps Wiki를 중앙 집중식 방법으로 사용하여 인시던트 자체와 인시던트 중에 발생한 대화에 대한 일부 정보를 가져올 수도 있습니다.
대화 추출을 위한 Microsoft Graph API
Microsoft Graph API 이 특정 인시던트에 관련된 Teams 채널 내에서 수집된 대화를 검색하는 프로그래밍 방식의 방법을 제공합니다. 검색된 데이터에는 타임스탬프, 작성, 편집, 회신 및 일부 시스템 메시지가 포함되며, 모두 시간론을 생성할 때 도움이 될 수 있습니다.
Microsoft Graph API를 시작하는 한 가지 쉬운 방법은 Microsoft Graph 탐색기를 사용하는 것입니다. Microsoft Graph 탐색기는 샘플 쿼리 패널에서 API 호출을 선택하고 대화형으로 시도할 수 있는 웹 기반 API 브라우저입니다.
쿼리를 실행하기 전에 사용 중인 사용자 또는 앱에 선택한 액세스 모드에 필요한 권한과 동의가 있는지 확인합니다. 위임된 시나리오에서는 팀 목록은 Team.ReadBasic.All, 채널 목록은 Channel.ReadBasic.All, 채널 메시지를 읽으려면 ChannelMessage.Read.All가 필요합니다. 나중에 앱 전용 액세스로 워크플로를 자동화하려면 위임 전용 /me/joinedTeams 별칭 대신 애플리케이션 권한을 사용하여 GET /users/{id | user-principal-name}/joinedTeams을(를) 사용하세요. 채널별 읽기 단계의 경우 최소 권한 앱 전용 옵션은 ChannelSettings.Read.Group 리소스별 동의를 통해 채널을 나열하고 ChannelMessage.Read.Group 메시지를 읽는 것입니다.
Microsoft Graph v1.0 "Microsoft Teams" API 호출 집합을 단계별로 실행하여 대화를 검색합니다. (채널 메시지는 몇 년 전에 베타에서 v1.0으로 이동했기 때문에 이 시나리오에서는 베타 엔드포인트가 더 이상 필요하지 않습니다.) 각 단계에서는 쿼리를 선택하고 쿼리를 실행한 다음 응답에서 다음 단계를 수행하는 데 도움이 되는 정보를 선택합니다. 그런 다음 이 정보를 사용하여 다음 요청을 생성합니다. 예를 들어 먼저 팀 ID 목록을 쿼리하여 소속 팀을 표시합니다. 응답에서 필요한 ID를 선택하고 이 ID를 다음 쿼리 URL에 삽입하여 해당 팀의 채널 목록을 가져옵니다.
다음은 Microsoft Graph v1.0 엔드포인트로 표시된 단계입니다.
-
GET /me/joinedTeams(위임된 시나리오에서 사용하는 팀의 팀 ID를 찾기 위해) 또는GET /users/{id | user-principal-name}/joinedTeams(앱 전용 시나리오에서 동일한 작업을 수행하려면) -
GET /teams/{team-id}/channels(해당 인시던트에 사용한 채널의 채널 ID를 찾으려면). -
GET /teams/{team-id}/channels/{channel-id}/messages?$expand=replies스레드된 대화를 검색합니다. -
@odata.nextLink및replies@odata.nextLink을(를) 필요에 따라 따르거나,GET /teams/{team-id}/channels/{channel-id}/messages/{message-id}/replies에 전화하여 더 큰 스레드를 탐색합니다.
공유 채널을 사용한 경우 API는 joinedTeams 사용자가 직접 구성원인 공유 채널에 대한 호스트 팀을 반환하지 않습니다. 이 주의 사항은 호출 GET /me/joinedTeamsGET /users/{id | user-principal-name}/joinedTeams여부에 관계없이 적용됩니다. 이 경우 알려진 팀 및 채널 식별자에서 시작하거나 연결된 팀 API를 사용하여 호스트 팀을 찾습니다.
그래프 탐색기에서 이러한 URL을 직접 입력하거나 Microsoft Teams의 기본 제공 샘플 쿼리 패널에서 해당 항목을 선택할 수 있습니다.
나중에 이러한 각 단계를 수행하는 프로그램을 구성하려는 경우(실제로 수행) 요청 창에는 다양한 프로그래밍 언어로 해당 쿼리에 대한 샘플 코드를 제공하는 코드 조각 옵션이 있습니다.
팀이 Teams를 사용하는 방법에 따라 메시지 기록에는 구성원이 추가되거나 제거된 시기를 설명하는 데 도움이 되는 시스템 메시지가 포함될 수도 있습니다. 그러나 채널 멤버 자격 또는 액세스 변경에 대한 신뢰할 수 있는 감사 내역이 필요한 경우 이 데이터를 Microsoft 365 감사 로그로 보완합니다.
컨텍스트 표시를 위한 대시보드와 워크북
Azure 대시보드와 Azure Monitor 통합 문서는 모두 인시던트 중에 운영자가 본 컨텍스트를 재구성하는 데 도움이 될 수 있습니다. 대시보드는 Azure 서비스에서 한눈에 볼 수 있는 운영 개요에 유용합니다. 통합 문서는 차트와 함께 더 풍부한 쿼리, 매개 변수, 드릴다운 및 설명 텍스트를 지원하므로 일반적으로 인시던트 분석에 더 적합합니다.
올바른 신호를 캡처하는 대시보드 또는 통합 문서가 이미 있는 경우 해당 시간 범위를 인시던트 주변 기간으로 설정하고 이를 사용하여 당시 사람들이 본 내용을 재구성합니다. 이는 여러 리소스에서 메트릭, 로그 및 경고의 상관 관계를 지정할 때 특히 유용할 수 있습니다.
공유 대시보드는 Azure 리소스로, 여전히 포털에서 JSON으로 내보낼 수 있습니다. 해당 내보내기/가져오기 경로는 대시보드의 버전을 지정하거나 템플릿을 지정하려는 경우에 유용합니다. 그러나 대부분의 인시던트 후 조사 시나리오에서 통합 문서는 시각화, KQL 쿼리 및 설명 텍스트를 단일 아티팩트에 결합할 수 있으므로 보다 유연한 도구입니다.
변경 탐색을 위한 활동 로그, 리소스 로그 및 Log Analytics
Log Analytics 작업 영역은 Azure 활동 로그, Azure 리소스 로그 및 서비스별 진단을 비롯한 여러 원본의 데이터를 사용할 수 있습니다. 먼저 새 Log Analytics 작업 영역을 만듭니다. 그런 다음, Azure 포털에서 모니터 → 활동 로그를 열고 창 맨 위에서 엑스포트 활동 로그를 선택합니다. 그러면 Azure 구독에 대한 활동 로그를 작업 영역으로 보낼 수 있는 진단 설정이 열립니다.
짧은 시간 안에 KQL(Kusto Query Language)을 사용하여 데이터 원본을 연결한 이후 해당 구독에서 발생한 변경 내용에 대한 자세한 정보를 검색할 수 있습니다.
예를 들어 다음 쿼리는 변경되거나 삭제된 리소스에 대한 정보를 보여 줍니다. 로그 기능에서 인시던트 직전 기간을 더 정확히 설정할 수 있습니다.
AzureActivity
| where CategoryValue == 'Administrative'
| where OperationNameValue endswith "write" or OperationNameValue endswith "delete"
| project TimeGenerated, Level, ResourceGroup, ResourceId, OperationName, OperationNameValue, ActivityStatusValue, Caller
| order by TimeGenerated desc
이 쿼리는 관리 평면 변경에 유용하지만 표시되지 않는 내용을 기억합니다.
AzureActivity 는 만들기, 업데이트, 삭제 및 정책 작업과 같은 컨트롤 플레인 작업을 캡처합니다. 서비스 내에서 데이터 평면 또는 애플리케이션 수준 변경 내용을 캡처하지 않습니다. 이를 조사하려면 이 쿼리를 Azure 리소스 로그, 서비스별 감사 로그, 배포 기록, CI/CD 또는 소스 제어 레코드와 페어링합니다.
한 가지 빠른 참고 사항: Azure 활동 로그를 내보내면 정보가 해당 시점부터 Log Analytics 작업 영역으로 흐르기 시작합니다. 연결하기 전에 발생한 이벤트에 대해 해당 작업 영역을 소급하여 쿼리할 수 없습니다.
이러한 도구는 사고 후 검토 시 사용할 타임라인에 필요한 정보를 효과적으로 수집할 수 있도록 도와야 합니다. 인시던트 후 검토를 진행하기 전에 몇 가지 일반적인 트랩에 대해 경고합니다. 이것이 다음 단원의 주제입니다.