인시던트 리스폰스는 보안 또는 신뢰성 문제의 발생을 빠르게 감지하고, 제한하고, 복구하는 공식적인 분야입니다. IBM의 2021년 분석에 따르면, 테스트된 인시던트 리스폰스 팀을 보유한 조직의 침해 비용 평균은 3,250만 달러비교를 해보면 5,710만 달러 조직이 이 능력을 갖고 있지 않다면, 차이점은 54.9%.
2시가 넘어 지연된 결제 웹후크가 실패하기 시작합니다. 모바일 대시보드는 빨간색으로 변하고, API 오류율이 오르고, 누군가는 문제가 앱, CDN, 또는 결제 제공자에 있는지 물어봅니다. 개발자는 릴리스 콘솔을 열고, 운영 엔지니어는 로그를 검색하고, 제품 매니저는 고객이 거래를 잃고 있는지 알고 싶어합니다. 누구도 노력하지 않습니다. 팀은 공유 운영 모델이 없다는 것입니다.
그것이 실제적인 사고 대응의 정의입니다. 그것은 영웅적인 디버깅 세션이나 급한 채팅 메시지의 연속이 아닙니다. 그것은 문제를 감지하는 반복 가능한 방법, 범위의 이해, 손실의 제한, 원인 제거, 서비스 복원, 그리고 시스템 향상입니다. NIST 지침은 사고 대응을 정의된 활동과 측정 가능한 성과를 가진 조직 능력으로 대신 임의적인 화재 훈련으로 다룹니다. CTOs를 위한 사고 대응 가이드 는 기술 활동을 리더십 결정, 소유권, 그리고 비즈니스 연속성과 연결하는 데 유용합니다.
모바일 및 크로스 플랫폼 팀을 위한 릴리스 메커니즘은 자체적으로 응답 시스템의 일부가 됩니다. 실시간 업데이트 플랫폼은 팀이 배포 채널을 동결하고 사용자를 알려진 좋은 버전으로 되돌려주고, 오류가 영향을 받은 장치로 전달되었는지 관찰할 수 있습니다. 스토어 리뷰 주기까지 기다리지 않고. 이 안내서의 나머지 부분은 실제 예시와 함께 이 생명 주기를 설명합니다. Capacitor, Electron, API, CDN, 그리고 서비스를 더 안전하게 관리하는 사람들에 대한 예시입니다.
목차
- 사고 대응: 잘못된 것이 발생했을 때
- 사고 대응 프로그램의 6 단계
- 팀 내 역할과 책임
- 사용할 수 있는 플레이북 및 루네크북
- 성과 지표 및 사고 후 검토를 통한 프로그램 개선
- 도구, 자동화 및 실시간 업데이트 위치
- 규정 준수 및 커뮤니케이션 최적화
사고 대응: 잘못된 경우
처음으로 호출되는 사람들은 전체 스토리를 모두 알지 못한다. 그들은 증상만 볼 수 있다: 결제 실패, 빈 화면, 인증 오류, 또는 비정상적인 충돌 보고 증가. 그들의 첫 번째 책임은 근본 원인을 추측하는 것이 아니다. 그것은 통제를establish하는 것이다.
유용한 대응은 사고를 선언하고 전용 커뮤니케이션 채널을 열어, 사고 команд자를 할당하고 현재 사실을 기록하는 것이다. 그 다음 팀은 작은 집합의 근거를 제공하는 질문을 묻는다:
- 무엇이 바뀌었나: 최근에 앱 번들, API 배포, 기능 플래그, 인증서, 또는 CDN 구성이 변경되었는가?
- 누구에게 영향을 미치는가: 실패은 한 플랫폼, 앱 버전, 지역, 고객 세그먼트, 또는 릴리스 채널에만 제한되는가?
- 사태 확산을 막을 수 있는 것은 무엇인가: 팀은 기능을 비활성화할 수 있나요, 채널을 동결할 수 있나요, 자격 증명을 취소할 수 있나요, 서비스를 분리할 수 있나요?
- 증거가 살아남아야 하는 것은 무엇인가: 로그, 배포 기록, 장치 보고서 및 요청 추적이 보존되어야 하는 것은 무엇인가?
보안 이벤트에만 적용되는 인시던트 리스폰스but 동일한 학문적 분야는 신뢰성 인시던트에도 도움이 됩니다. 취약한 자격 증명, 악성 패키지 및 결제 통합 오류는 모두 다른 원인일 수 있지만, 응답자는 여전히 감지, 분석, 격리, 복구 및 학습이 필요합니다. 모든 이벤트를 생명주기로 다루면 팀이 즉시 위험한 해결책으로 뛰어들지 못하게 됩니다.
실용적인 규칙: 상황을 안정화하기 전에 해결책을 최적화하지 마세요. 역전할 수 있는 격리 조치는 종종 빠르지만 irreversible 변경보다 더 가치가 있습니다.
NIST의 인시던트 리스폰스 자료는 응답을 더 광범위한 위험 관리 내에 배치합니다. 준비는 정책, 자산 인식, 강화, 모니터링 및 복구 계획을 포함합니다. 감지 및 응답은 그 기반 위에 의존합니다. IBM의 침해 연구는 이에 대한 금전적 중요성을 보여줍니다. 2021년 연구 결과에 따르면 평균적으로 침해를 감지하고 격리하는 데 287일이 소요되었습니다. 287일, 구성: 212일 감지 그리고 75일 동안 격리하는 시간. 그 숫자는 운영준비가 직접 노출 시간과 복구 비용과 연결된다. Capgo 사고 대응 가이드 모바일과 데스크톱 릴리스에 대해서도 동일한 사고 대응 방법을 적용한다. 나쁜 업데이트를 릴리스 채널과 롤백 제어를 통해 격리할 수 있다.
성숙한 프로그램은 2시가 더 나빠지지 않도록 한다. 중요한 질문에 대한 답변이 경보가 도착하기 전에 준비되어야 한다. 사람들은 롤백을 승인할 수 있는 사람을 알고, 신뢰할 수 있는 아티팩트를 알고, 증거가 저장된 곳을 알고, 고객과 소통할 팀을 알고 있다. 사고 대응은 압박을 조정된 행동으로 바꾸는 시스템이다.
사고 대응 프로그램의 6단계
NIST의 지침은 4단계의 생명주기를 설명한다. 격리, 제거, 복구를 함께 묶어 놓았다. 팀들은 종종 모델을 6단계의 작업 단계로 구현한다. : 준비, 감지, 분석, 격리, 제거 및 복구, 사고 후 활동. 레이블은 중요하지 않다. 각 단계는 다른 질문에 답한다. 하나를 생략하면 나중에 위험을 초래한다.사고 대응 프로그램의 6단계를 나타내는 다이어그램, 준비부터 교훈을 얻는 단계까지.
사고 대응 프로그램의 6단계
OTA 배포 전 Capacitor 팀은 생산 채널, 릴리즈 소유자, 롤백 권한, 경보 임계값 및 증거 소스를 정의해야 합니다. runbook은 마지막으로 잘 작동한 버전을 식별하고, 이행을 위해 최고 경영진의 승인을 기다리지 않고 반응자가 취할 수 있는 액션을 지정해야 합니다. 준비도는 반응 계획을 테스트하는 것뿐만 아니라 문서 시스템에만 저장하는 것이 아닙니다.
탐지 시작
잘못된 배포 패키지가 생산 채널에 도달하고 사용자가 빈 체크아웃 화면을 보고 시작합니다. 충돌 보고서, 실패한 API 호출, 수용 데이터 및 지원 티켓은 별도의 신호를 제공합니다. 탐지는 팀에게 변화가 발생했다는 것을 알려줍니다. 분석은 문제가 클라이언트 배포 패키지, 백엔드 의존성, 네트워크 경로 또는 관련 없는 이벤트 중 어디인지 결정합니다.
반응자는 릴리즈 히스토리, 영향을 받은 앱 버전, 장치 플랫폼 및 고객 세그먼트와 관련된 경보를 상관합니다. 심각도는 범위, 데이터 노출, 비즈니스 영향 및 문제가 계속 퍼지는지 여부에 따라 결정됩니다.
blast radius를 제한
사고 책임자로 인한 영향을 제한
사고 책임자는 영향을 받은 채널을 잠금합니다. 엔지니어는 관련된 기능 플래그를 비활성화하고, 더 이상의 전파를 중단하고, 실패한 패키지 및 로그를 보존합니다. 제한은 진행 중인 피해를 줄이고, 조사하기 위한 충분한 증거를 보존해야 합니다.
팀은 불량한 code 또는 설정을 식별하고 수정하고 관련된 결함을 확인합니다. 보안 침해가 포함된 사고의 경우, 제거도 영구적인 존재를 제거하고 취약한 접근 권한을 취소하고 원래의 진입점을 해결하는 것을 의미합니다. 롤백은 나쁜 릴리즈를 포함할 수 있지만, 이는 원인 분석의 대체는 아닙니다.
복구는 서비스를 신중하게 복원합니다.
응답자는 사용자를 마지막으로 알려진 좋은 버전으로 되돌려주거나, 더 넓은 홍보 이전에 제한된 테스트 대상으로 수정된 버전을 공개합니다. 그들은 시작, 체크아웃, 인증, 충돌 및 API 동작을 검증합니다. 복구는 단지 대시보드가 초록색으로 바뀌었을 뿐만 아니라, 고장 원인이 돌아오지 않았는지 증명하는 것이 완료된 것입니다. 팀은 고장에 대한 증거가 고장에 대한 수정이 적용되었는지 확인합니다.
사고 후 활동은 시스템을 개선합니다.
팀은 시간선도, 결정, 알림, 고객 영향 및 복구 증거를 기록합니다. 그 다음에 구체적인 개선 사항을 assign합니다. 예를 들어, 새로운 전판 확인, 강화된 채널 경계 또는 더 나은 알림입니다. 구조화된 실패 분석 프로세스 는 기술적 원인과 기여하는 조건을 분리하는 데 도움이 됩니다. 예를 들어, 불분명한 소유권 또는 테스트되지 않은 롤백과 같은.
사고 생명 주기는 지속적입니다. 사고 후 활동은 다음 이벤트의 준비가 됩니다. 따라서 대부분의 응답 품질은 페이지를 받기 전에 결정됩니다.
역할과 책임은 팀 전체에 걸쳐 있습니다.
A response program doesn’t require every company to build a large security operations center. It does require named ownership. When nobody is clearly responsible for decisions, engineers investigate in parallel, executives receive inconsistent updates, and recovery actions wait for approval.
The incident commander owns the response process. They set priorities, declare severity, assign work, decide when containment is sufficient, and coordinate the move into recovery. They don’t need to perform every technical task. Their value comes from maintaining a clear operating picture.
The engineering lead directs diagnosis, containment, remediation, and restoration. For a mobile team, that might include freezing an OTA channel, identifying the affected bundle, checking API compatibility, and validating the corrected release. security lead security lead
handles evidence, access revocation, threat analysis, and regulatory escalation when a security event is involved. A scribe maintains the timeline and records decisions, timestamps, owners, and unresolved questions. A 소통 책임자 내부, 최고 경영진, 고객, 및 공공 업데이트를 준비합니다. The 제품 담당자 고객 영향 설명, 비즈니스 критカル 워크플로우 우선순위, 지원 및 고객 성공을 동기화합니다.
| 역할 | 주요 단계 | 핵심 책임 |
|---|---|---|
| 사고 지휘자 | 모든 단계 | 우선순위 설정, 작업 assign, 전환 승인, 결정 조정 |
| 기록자 | 탐지부터 사고 후 활동까지 | 사고 대응의 사실, 행동, 시간대, 증거, 결정 기록 |
| 엔지니어 리드 | 재구축을 통해 분석 | 오류를 진단하고 영향력을 제한하고 서비스를 복원하고 |
| 보안 리드 | 사고 후 활동을 통해 감지 | 증거를 보존하고 침해를 조사하고 접근 제어를 관리하고 보고를 권고 |
| 커뮤니케이션 리드 | 재구축을 통해 감지 | 내부 상태 업데이트 유지하고 외부 메시징을 조정 |
| 상품 리레이션 | 재구축을 통해 분석 | 기술적 영향력을 고객과 기업의 우선순위로 번역하세요. |
작은 팀은 이러한 자리를 압축합니다. 한 창업가가 사령관, 기록자, 및 커뮤니케이션 리드 역할을 맡을 수 있으며 개발자가 엔지니어링을 담당합니다. 이러한 배치는 한정된 사고에 대해 작동할 수 있습니다. 만약 모든 사람이 역할을 명확하게 밝히면. 규제 기업은 종종 이를 분리하여 의사결정 independency, 증거의 품질, 및 커뮤니케이션 컨트롤을 보장합니다.
역할은 직책이 아닙니다. 사고의 기간 동안 할당된 책임입니다.
사고 채널 및 runbook에 역할 assignement을 기록하고, 만약 채용하거나 보안 기능을 정의한다면, 구조화된 보안 분석가 직책 template이 조사, 모니터링, 및 경보 예상치를 명확하게 할 수 있습니다. 중요한 테스트는 간단합니다: 모든 응답자가 결정하는 사람, 시스템을 변경하는 사람, 증거를 기록하는 사람, 및 고객에게 말하는 사람을 알 수 있는지 확인하세요. 사고 대응 플레이북 및 Runbook 사고 대응 플레이북은 사고의 결정 논리를 설명합니다. 사고 대응 Runbook은 운영자에게 정확한 동작을 수행하는 방법을 알려줍니다. 플레이북은 '우리가 어떤 상황에 있는지, 그리고 어떤 경로를 선택해야 하는지'를 알려줍니다. Runbook은 '다음으로 어떤 콘솔, 명령, 또는 워크플로우를 사용해야 하는지'를 알려줍니다.
사고 대응 플레이북
사고 대응 Runbook 사고 대응 플레이북 사고 대응 Runbook 사고 대응 플레이북은 사고의 결정 논리를 설명합니다. 사고 대응 Runbook은 운영자에게 정확한 동작을 수행하는 방법을 알려줍니다.
A OTA 배포 오류에 대한 빠른 대응을 위한 1 페이지 플레이북은 다음과 같이 생길 수 있습니다.
- 신호를 확인하세요. 알림을 릴리스 기록, 충돌 보고서, 장치 로그 및 영향을 받은 버전과 비교하세요.
- 배포를 중지하세요. 제품 채널의 홍보를 중단하고 추가 장치가 배포 패키지를 받지 못하도록 방지하세요.
- 롤백 경로를 평가하세요. 이전 배포가 깨끗하고 호환되는지 확실하다면 롤백을 승인하세요. 그렇지 않다면 영향을 받은 기능을 분리하고 실패한 아티팩트를 조사하기 위해 보존하세요.
- 관련자에게 알리세요. 사고 채널, 지원 팀, 제품 관리자 및 심각도에 따라 연락하는 최고 경영자에게 업데이트 하세요.
- 회복을 확인하세요. 시작, 중요 워크플로우, 오류, 수용 및 실패 보고서를 확인하기 전에 홍보를 재개하세요.
- 증거로 마무리하세요. __CAPGO_KEEP_0__
사고 대응 플레이북은 다음 항목을 포함해야 합니다.
사고 대응 플레이북은 비즈니스 프로세스에 대한 실용적이고 실행 가능한 플레이북과 런북을 만드는 데 도움이 되는 구조화된 인포그래픽 가이드입니다.
인증 정보 유출 런북
- 인증 정보 유출은 더 구체적인 지침이 필요합니다: 첫 번째 단계는 다음과 같습니다:
- 노출된 토큰이나 키를 비활성화하고, 그 토큰이나 키를 사용하는 활성 세션을 무효화하는 것을 확인합니다. 두 번째 단계는 다음과 같습니다:
- 대체 인증 정보를 생성하고, 의존하는 서비스를 업데이트하고, 애플리케이션에서 새로운 값을 사용하는 것을 확인합니다. 세 번째 단계는 다음과 같습니다:
- 사용된 노출된 인증 정보를 검색하고, 관련된 기록을 보존하고, 영향을 받은 리소스를 식별합니다. 권한 상승, 비정상적인 배포, 데이터 접근 또는 새로운 지속성을 확인하세요.
- 정확하게 의사소통하세요: 지원 및 리더십에게 사실적인 영향 statement을 제공하세요. 알려지지 않은 노출에 대해 추측하지 마세요.
- gap을 닫으세요: 원본 제어 및 빌드 아티팩트에서 비밀을 제거하고, 유사한 누출을 감지하는 감지기를 추가한 후, 소스 제어 및 빌드 아티팩트에서 비밀을 제거하세요.
실시간으로 업데이트할 수 있는 앱의 경우, runbook에는 JavaScript 또는 CSS 핫픽스를 capped beta 채널에 게시하고, 모니터링을 확인하고, 승인된 리뷰어가 정상적인 동작을 확인할 때까지 배포를 승인하는 단계가 포함됩니다. incident 기록에 bundle 해시, 승인, 릴리즈 노트 및 롤백 대상이 포함됩니다. 재난 복구 지침 재난 복구와 더 넓은 백업 및 지속성 계획과 연결하는 유용한 컨텍스트를 제공합니다.
최선의 문서는 피로한 상태에서도 사용할 수 있는 길이입니다. runbook에 대시보드, 소유권 정보, 결정 기준, 유효성 검사에 대한 링크를 직접 포함하세요. 기억에 의존하는 단계를 제거하세요.
KPI 및 Post-Incident Reviews That Improve the Program
지표는 '잘 응답했는가?'라는 모호한 질문을 여러 답변할 수 있는 질문으로 바꿉니다. 탐지 시간 평균시스템이 의미 있는 신호를 표면하는 데 걸리는 시간, 또는 MTTD를 측정합니다. Mean time to contain시스템의 영향력을 제한하는 데 걸리는 시간, 또는 MTTC를 측정합니다. Mean time to recover or remediate안정적인 서비스로 돌아가기까지의 경로를 측정하는 MTTR, 일반적으로 MTTR이라고 부릅니다. A rollback 또는 fix 성공률 시스템이 복구되거나 수정되기까지의 시간을 측정합니다.
각각의 지표는 스택의 원천에 연결되어야 합니다:
- MTTD: alert 시간표, SIEM 이벤트, 앱-건강 모니터링, 고객 보고서 및 충돌 보고서.
- MTTC: 채널 동결 기록, 기능 플래그 변경, 자격 증명 취소 이벤트 및 분리 작업.
- MTTR: 배포 기록, 롤백 완료, 복구 확인 및 서비스 복원 기록.
- 롤백 또는 고치기 성공: 배포 패키지 수용, 실패 통계, 충돌 패턴, API 건강 및 지원 확인.
이것들을 엔지니어 개인의 성과 지표로 간주하지 마세요. 높은 MTTD는 미등록의 통계를 나타낼 수 있습니다. 높은 MTTC는 권한의 불명확성을 드러낼 수 있습니다. 롤백 결과가 약한 경우 호환성 결함, 완전한 검증이 미흡하거나 복구 아티팩트가 테스트되지 않은 경우를 지적할 수 있습니다. 이 지표는 시스템 문제를 식별하는 데 사용되며, 개인을 비난하는 데 사용되어서는 안 됩니다.
IBM은 2026년까지 평균적으로 침해를 식별하고 격리하는 데 소요되는 시간이 247일로 개선되었다고 보고했습니다. 전 세계 평균 침해 비용은 기록적인 $4.99 백만 달러으로 달성되었습니다. 이러한 수치는 응답 시간을 줄이기 위한 비즈니스 이유를 강화하지만, 지역 측정치로 대체되어서는 안 됩니다. 팀은 자신의 지연 시간을 알 필요가 있으며, 특히 경보, 결정, 격리 및 확인된 복구 사이의 지연 시간을 알 필요가 있습니다. 작업을 생산하는 리뷰: 사고 후 리뷰는 비난하지 말고 구체적이어야 합니다. 시스템이 이 사건을 발생시킨 이유와 응답이 어떻게 진행되었는지 설명해야 합니다.
MTTR:
Deployment history, rollback completion, recovery checks, and service restoration records.
이 시퀀스를 사용하세요:
- 사고 statement: 고객 또는 시스템의 영향에 대한 간단한 설명을 작성하세요.
- 시간표: 탐지, 승인, 결정, 격리, 치료, 복구 및 폐쇄를 기록하세요.
- contributing 요인: code
- 설정 모니터링
- 프로세스 소유권
- 통신 조건 각 개선에 대해 1명의 책임자와 구체적인 마감일을 할당하세요.
- Verification: 팀이 각 행동이 반응 능력을 어떻게 증명할 것인지 정의하세요.
문서가 발행되면 리뷰가 끝난 것으로 간주하지 마세요. 리뷰는 결과적인 변경 사항이 구현되고 테스트될 때 끝납니다. 팀은 사용자 대면의 측정치를 반응 점수 카드와 연결하기 위해 앱 헬스 모니터링 관행 을 사용할 수 있습니다.
앱 헬스 모니터링 관행
을 사용할 수 있습니다.
| 반응 점수 카드와 사용자 대면의 측정치를 연결하기 위해 | 앱 헬스 모니터링 관행 | 을 사용할 수 있습니다. |
|---|---|---|
| 시스템 관리 및 로그 PIPELINES | 시스템 간에 무슨 일이 일어났는가? | 사용자 ID, API, 인프라 및 애플리케이션 이벤트를 상호 연관시킨다. |
| EDR 및 런타임 보호 | 어떤 엔드포인트 또는 프로세스가 영향을 받는가? | 호스트를 분리하고 동작을 검사하고 악성 활동을 차단한다. |
| SOAR | 자동으로 실행할 수 있는 승인된 액션은 무엇인가? | 권한을 취소하고 인시던트를 열거나 소유주에게 알리거나 격리 조치를 트리거한다. |
| 관찰성 | 사용자가 무엇을 경험하는가? | 오류, 추적, 충돌, 지연, 및 릴리스 버전을 비교한다. |
| 백업 및 code | 어떻게 깨끗하게 복원할 수 있을까요? | 서비스를 재구축하고 데이터를 복원하고 신뢰할 수 있는 환경을 재현합니다. |
| 릴리즈 및 라이브 업데이트 도구 | 사용자들이 실행해야 하는 클라이언트 버전은 무엇인가요? | 채널을 잠근 후 배포를 되돌리고 올바른 릴리즈를 준비합니다. |
code는 모바일 및 크로스 플랫폼 팀에게 릴리즈 도구가 응답 계획에 속해야 합니다. 네이티브 스토어 릴리즈는 검토 및 배포 지연을 유발할 수 있습니다. OTA 메커니즘은 플랫폼 및 정책이 업데이트를 허용하는 code의 응답 옵션을 변경합니다. 팀은 여전히 관리, 호환성 검사, 서명, 그리고 적절한 릴리즈 정책이 필요하지만 더 짧은 feedback 루프로 작동할 수 있습니다.
Capgo는 CapacitorJS 및 Electron 앱을 위한 서명된 자바스크립트, CSS, 구성, 복사본, 및 자산 배포를 대상 채널을 통해 제공합니다. 문서화된 제어에는 채널 기반 배포, 버전 기록, 장치별 로그, 수용 및 실패 메트릭, 그리고 자동 롤백 보호가 포함됩니다. 사고 시 팀은 영향을 받은 프로덕션 채널을 잠근 후, 작은 베타 청중에게 수정된 배포를 전송하고, 모니터링을 검사하고, 유효성을 검사한 후 더 광범위하게 릴리즈합니다. 차등 업데이트는 변경된 콘텐츠의 양을 줄일 수 있으며, 채널 가드레일은 사전 승인된 릴리즈 액션을 더 쉽게 적용할 수 있습니다.
컨테이먼트는 부분적으로 모바일 팀의 릴리즈 결정입니다. 가장 안전한 버전은 식별, 배포, 유효성 검사, 그리고 역전할 수 있는 버전입니다.
The Capgo는 Capacitor의 라이브 업데이트 설명입니다. 이 모델과 업데이트 흐름은 더 자세히 설명합니다. 더 넓은 원칙은 하나의 제품에만 적용되지 않습니다: 릴리스 기록을 관찰성과 연결하고 롤백 대상이 명확하고, 응답자가 장치가 필요한지 여부를 확인할 수 있도록 하세요.
규정 준수 및 의사소통 최선의 관행
사고 대응 또한 기술 팀이 독점적으로 소유하지 않는 의무를 보호합니다. 보안, 법률, 개인 정보 보호, 규정 준수, 제품 및 고객 지원은 사고가 발생했는지, 보고해야 하는지, 고객에게 무엇을 알릴지 결정하는 공유 프로세스를 필요로 합니다.
NIST SP 800-61은 일반적으로 사고 대응 활동을 프레임워크 및 산업 요구 사항과 일치시키기 위한 실용적인 기초로 사용됩니다. 팀은 준비, 감지, 격리, 복구 및 학습 활동을 SOC 2 제어, GDPR 침해 과정, HIPAA 사고 처리 또는 PCI DSS 요구 사항에 매핑할 수 있습니다. 정확한 의무는 조직, 관련 데이터, 관할 구역 및 계약 의무에 따라 달라지므로 법률 및 개인 정보 보호 소유자는 사고 전에 알림 기준 및 결정 권한을 정의해야 합니다.
의사소통은 사실에 따라야 합니다:
- 내부 상태: 응답자에게 알려진 것, 변경되는 것, 다음 행동의 주인을 알려주세요.
- 최고 경영자 업데이트: 고객 영향, 사업 위험, 격리 상태 및 필요한 결정에 대해 설명하세요.
- 고객 의사소통: 영향을 받은 기능, 실질적인 고객 단계 및 다음 업데이트 시간을 알려주세요.
- 공개 검토: 사고 대응 후 조사 및 개선이 성숙한 후 사실적인 사고 후 보고서를 발행하십시오.
내부 통신은 일반적으로 최초로 진행되며, 영향과 지침이 명확해지면 고객 통신이 뒤따르고, 팀이 사건을 책임 있게 설명할 수 있을 때만 공개 사후 분석이 진행됩니다. 작성된 보안 정책 자원
다음의 표면 연습 이전에, 다음을 확인하십시오. 사고 채널이 정의되어야 합니다., 온콜 회전이 최신 상태입니다., 모든 중요 서비스가 검토된 runbook을 가지고 있습니다., 최근의 훈련이 기록된 날짜를 가지고 있습니다., 그리고 롤백 경로가 테스트되었습니다.. 이 다섯 가지 확인은 모든 사고를 예방하지는 않지만, 경보가 도착했을 때 팀이 훨씬 더 좋은 시작 위치를 가질 수 있도록 합니다.
Capgo은 CapacitorJS와 Electron 팀에게 서명된 라이브 업데이트, 채널을 통해 릴리스를 목표로 하는, 장치당 수락 및 실패를 관찰하는, 그리고 회복 중 rollback 보호를 사용할 수 있는 제어된 방법을 제공합니다. Visit Capgo 사고 대응 계획과 모바일 릴리스 도구를 연결하여 격리 및 회복을 더 의도적으로 하기 위해 보라.
