주제 3.9 — 업무 연속성 및 재해 복구

보건·돌봄에서 대규모 시스템 장애는 IT 문제이기 전에 환자 안전 사건이므로, 시스템이 다운된 동안 돌봄을 계속 제공하고 이를 완전하고 신속하게 복구하는 능력은 기술적 각주가 아니라 핵심적인 임상 및 대중 신뢰의 역량이다.

보건·돌봄에서 이것이 중요한 이유#

기술이 멈춘다고 돌봄이 멈추지는 않는다. 전자 환자 기록, 전자 처방 플랫폼, 검사실 결과 시스템이 병원 전체에서 실패해도, 임상의는 엔지니어가 작업하는 동안 치료를 멈출 수 없다. 환자를 계속 보고, 약을 처방하고, 결정을 내려야 하며, 흔히 실패한 시스템이 평소 제공하는 알레르기 경고, 용량 점검, 과거 병력 없이 그렇게 해야 한다. 그래서 장애는 다운타임 시간과 서비스 크레딧만이 아니라 지연된 진단, 놓친 상호작용, 취소된 수술, 눈 감고 일하는 모든 임상의가 짊어지는 추가 위험으로 측정된다. 업무 연속성은 최악의 일이 일어날 때 돌봄이 가능한 한 안전하게 유지되도록 하는 규율이다.

위험은 국가적이고 잘 기록되어 있다. 2017년 WannaCry 랜섬웨어 공격은 잉글랜드 NHS 트러스트의 약 3분의 1을 마비시키고, 수천 건의 예약과 수술을 취소시키고, 구급차를 우회시켰으며, 일부 영상 및 병리 장비를 포함해 사람들을 치료하는 데 필요한 바로 그 기기에서 직원을 차단했다. NHS에 추정 9,200만 파운드의 비용을 입혔고, 더 중요하게는 보건 인프라에 대한 사이버 공격이 단순한 데이터 보안 사건이 아니라 임상 위기로 닥친다는 것을 보여 주었다. 그 이후 회복탄력성은 서버실에서 이사회 테이블로 옮겨 갔고, 마땅히 그래야 한다.

이 주제는 주제 3.8 — 서비스 관리 및 라이브 운영의 운영 규율을 확장하되, 초점을 일상 운영에서 대규모 중단, 곧 중요한 서비스를 몇 시간 또는 며칠 동안 다운시킬 위협이 되는 화재, 홍수, 사이버 공격, 공급업체 붕괴, 지역 장애로 옮긴다. 이는 주제 1.7 — 정보 거버넌스, 데이터 보호 및 사이버 보안(랜섬웨어 복구가 이제 핵심 연속성 시나리오이므로), 주제 4.0 — 기술 아키텍처, 클라우드 및 레거시(회복탄력성은 사후에 덧붙이는 것이 아니라 설계에 내장되므로), 주제 6.4 — 거버넌스 및 보증(누군가 계획을 소유하고, 시험하고, 책임져야 하므로)과 긴밀히 이어진다. 이를 제대로 하면 중단은 나쁜 하루가 되고, 잘못하면 공적 조사가 된다.

핵심 개념#

업무 연속성과 재해 복구. 업무 연속성 계획(BCP)은 중단성 사건 중과 후에 미리 정의된 허용 수준으로 제품이나 서비스 — 여러분의 경우 안전한 돌봄 — 를 계속 제공하는 역량이다. IT 재해 복구(DR)는 그 서비스를 떠받치는 시스템, 데이터, 인프라를 복원하는 데 관련된 더 좁은 기술적 부분집합이다. 업무 연속성은 더 넓은 약속("환자는 계속 치료받는다")이고, 재해 복구는 그 수단 중 하나("결과 시스템이 4시간 안에 복구된다")다. 둘 다 필요하며, 복원된 서버를 복원된 서비스와 혼동해서는 안 된다.

업무 연속성 관리와 업무 영향 분석. 업무 연속성 관리(BCM)는 위협을 식별하고 조직의 회복탄력성을 구축하는 지속적인 관리 프로세스이며, 일회성 문서가 아니다. 그 토대는 업무 영향 분석(BIA)이다. 각 서비스를 구조적으로 평가하여 그 상실이 얼마나 빨리 용납할 수 없는 해악을 낳는지, 무엇에 의존하는지, 데이터를 시간상 얼마나 거슬러 잃을 수 있는지 묻는다. BIA는 임상적 판단이 엔지니어링에 들어오는 곳이다. 산과 시스템과 직원 인트라넷에서 "용납할 수 없는"이 무엇인지는 기술자만이 아니라 임상의가 정의해야 한다.

복구 시간 목표와 복구 시점 목표. 두 숫자가 모든 복구 계획을 고정한다. 복구 시간 목표(RTO)는 실패 후 서비스를 복원하는 데 허용되는 최대 시간이다. 복구 시점 목표(RPO)는 허용되는 최대 데이터 손실량으로 시간으로 표현된다. 15분의 RPO는 마지막 15분의 입력까지만 잃는 것을 감내할 수 있다는 뜻이다. 핵심 임상 시스템에서는 몇 분일 수 있고, 보고용 웨어하우스에서는 며칠일 수 있다. 서비스별로 이를 정직하게 정하는 것이 내릴 수 있는 가장 유용한 단일 연속성 결정이다.

백업과 시험된 복원. 백업은 손실 후 원본을 복원할 수 있도록 다른 곳에 저장한 데이터 사본이다. 업계의 기준선은 3-2-1 규칙이다. 사본 세 개를, 두 종류의 매체에, 하나는 외부에 보관한다(그리고 랜섬웨어 시대에는 하나를 변경 불가 또는 오프라인으로 보관). 결정적으로, 복원해 본 적 없는 백업은 통제가 아니라 희망이다. 랜섬웨어는 네트워크에서 닿을 수 있는 백업을 일상적으로 암호화하고, 시험되지 않은 복원은 당일에 일상적으로 실패한다. 규율은 "백업하는가?"가 아니라 "마지막으로 종단 간 복원에 성공한 것이 언제이고 얼마나 걸렸는가?"이다.

고가용성, 이중화, 페일오버. 고가용성(HA)은 구성 요소 실패에도 시스템을 계속 운영하는 설계 속성으로, 보통 가동 시간의 "나인(nines)"으로 측정한다. 핵심 구성 요소를 의도적으로 복제하는 이중화와, 주 구성 요소가 실패할 때 대기 구성 요소나 사이트로 자동 전환하는 페일오버로 달성한다. 고가용성은 장애의 빈도를 줄이고, 재해 복구는 뚫고 들어온 장애를 처리한다. 둘은 대안이 아니라 보완이며, 혼동하면 위험한 틈이 남는다.

단일 장애점과 핵심 의존성. 단일 장애점(SPOF)은 실패하면 서비스 전체가 멈추는 모든 구성 요소다. 하나의 네트워크 링크, 하나의 인증 서비스, 하나의 공급업체, 하나의 데이터베이스, 또는 어떤 것이 어떻게 작동하는지 혼자 아는 한 사람이다. SPOF와 핵심 의존성(서비스가 조용히 기대는 상위 서비스와 제3자)을 지도로 그리는 것이 회복탄력성의 분석적 핵심이다. 현대 보건 IT에서 의존성은 지역적인 경우가 드물다. 싱글 사인온 서비스, 국가 스파인 연결, 클라우드 리전 하나가 여러 시스템을 한꺼번에 다운시킬 수 있다.

임상 다운타임과 업무 연속성 절차. 보건·돌봄에는 일반 IT에 없는 독특한 통제가 있다. 임상 다운타임 절차, 곧 디지털 시스템을 쓸 수 없을 때 돌봄을 제공하는 연습된 안전한 대비책(보통 종이)과, 시스템이 돌아오면 그 종이 기록을 시스템에 대조해 넣는 재입력 프로세스다. 이것이 침상에서 구체화된 업무 연속성이며, 연속성 계획이 현실과 가장 자주 만나는 곳이다.

랜섬웨어와 사이버 복구. 랜섬웨어는 데이터를 암호화하고 대가를 요구하며, 보건 시스템의 결정적 연속성 위협이 되었다. 2017년 WannaCry 랜섬웨어 공격이 기준 사례다. 그래서 사이버 복구, 곧 격리하고, 깨끗한 백업에서 다시 구축하고, 다시 연결하기 전에 무결성을 검증하는 것이 이제 모든 진지한 계획의 일급 시나리오다.

연속성 표준. ISO 22301은 업무 연속성 관리 시스템의 국제 표준이다. 연속성 역량을 구축하고 감사하기 위한 인정된 구조(맥락, 리더십, 계획, 지원, 운영, 평가, 개선)를 제공하며, 공식 인증을 추구하든 아니든 유용한 뼈대다.

모범 사례#

  1. IT만이 아니라 임상의가 소유하는 업무 영향 분석으로 시작하라. 서비스가 실패할 때 끼치는 임상적 해악과 그 해악이 얼마나 빨리 견딜 수 없게 되는지에 따라 모든 서비스의 순위를 매기고, 각각에 구체적인 RTO와 RPO를 부여하라. 그 결과를 감당하는 임상의와 운영 관리자와 함께 하라. "이것 없이 얼마나 안전하게 운영할 수 있는가?"는 인프라 질문이 아니라 돌봄 질문이기 때문이다. 산출물은 한정된 회복탄력성 예산을 어디에 먼저 쓸지 알려 주는 우선순위 목록이다.

  2. 중요도에 비례하는 회복탄력성을 설계하라. 엔지니어링을 영향에 맞추라. 핵심 시스템(응급실, 환자 행정, 전자 처방)은 고가용성, 지리적 이중화, 자동 페일오버가 정당화되고, 중요도가 낮은 시스템은 더 긴 복구와 더 단순한 백업을 받아들일 수 있다. 핵심 시스템의 과소 엔지니어링과 사소한 시스템의 과잉 도금을 모두 피하라. 아키텍처와 연속성은 함께 설계되어야 한다(주제 4.0 — 기술 아키텍처, 클라우드 및 레거시 참조). 취약한 설계에 회복탄력성을 사후에 덧붙일 수는 없기 때문이다.

  3. 단일 장애점과 숨은 의존성을 추적하라. 각 핵심 서비스의 의존성 — 네트워크, 인증, DNS, 국가 연결, 전력, 냉각, 핵심 공급업체, 핵심 인력 — 을 체계적으로 지도로 그리고 한 번의 실패가 연쇄하는 곳을 식별하라. 싱글 사인온이나 공통 통합 엔진처럼 실패하면 많은 시스템이 한꺼번에 다운되는 공유 서비스에 특히 주의하라. 지도로 그리지 않은 의존성은 장애 중에 발견하게 될 의존성이다.

  4. 랜섬웨어에서 살아남도록 백업하고, 복원을 시험해 증명하라. 3-2-1 규칙을 따르고 적어도 하나의 백업 사본을 변경 불가 또는 물리적 오프라인으로 보관하여, 네트워크에 닿은 공격자가 마지막 방어선을 암호화할 수 없게 하라. 그런 다음 일정에 따라 복원을 시험하고, RTO에 대해 시간을 재고 RPO에 대해 데이터 무결성을 검증하라. 4시간 목표에 이틀 걸리는 복원은 아직 알아채지 못했을 뿐인 실패한 통제다. "마지막 성공한 전체 복원"을 가정하는 업무가 아니라 보고하는 지표로 다루라.

  5. 임상 다운타임 절차를 작성하고, 자원을 대고, 연습하라. 모든 핵심 임상 시스템에 대해, 직원이 장애 중에 안전한 돌봄을 계속 제공하게 해 주는 시험된 종이(또는 오프라인) 대비책과, 그 데이터를 나중에 손실이나 중복 없이 재입력하는 명확한 프로세스를 유지하라. 다운타임 양식은 네트워크와 프린터도 다운되었을 때 닿을 수 있는 곳에 보관하라. 일선 직원과 연습하라. 폴더에만 있는 절차는 위기 중 새벽 3시에 발견되지도, 이해되지도, 신뢰받지도 못하기 때문이다.

  6. 실제 사이트 페일오버가 있는 재해 복구 계획을 유지하라. 각 핵심 시스템에 대해 정확히 어떻게 복구되는지 문서화하라. 무엇이 어디서 어떤 순서로 실행되는지, 누가 발동을 결정하는지, 어떻게 복귀(failback)하는지다. 영향이 정당화하는 곳에서는 진정으로 별도의 복구 사이트나 클라우드 리전을 운영하고 그것으로 전환할 수 있음을 증명하라. 시스템에는 순서를 정하는 의존성이 있으므로 복구 순서가 중요하다. 시험되지 않은 DR 사이트는 비싼 가정이다.

  7. 계획을 훈련하라. 시험되지 않은 계획은 실패하는 계획이다. 다양한 범위에 걸쳐 정기적으로 훈련을 실행하라. 시나리오의 책상 위 도상 훈련, 기술적 페일오버 시험, 임상 대비책을 포함한 가끔의 전체 라이브 시뮬레이션이다. 훈련은 틈, 곧 오래된 연락처 목록, 아무도 모르는 비밀번호가 필요한 복구 단계, 직원이 종이 프로세스를 안다는 가정을 안전할 때 드러낸다. 교훈을 기록하고, 고치고, 다시 시험하라. 후속 조치 없는 훈련은 연극이다.

  8. 연속성을 공급업체와 클라우드로 확장하라. 회복탄력성은 핵심 서비스가 의존하는 제3자만큼만 강하므로, 연속성을 계약과 보증의 문제로 만들라. 공급업체에게 자체 RTO/RPO, DR 시험, 사이버 복구의 증거를 요구하고, 클라우드 제공자의 공유 책임 모델을 이해하라. 가용성 영역과 리전은 일부 실패는 막아 주지만 여러분이 소유한 잘못된 구성이나 계정 침해는 막아 주지 않는다. 핵심 공급업체가 랜섬웨어에 당하는 시나리오를 포함해 공급업체 자체의 실패에 대비해 계획하라(주제 6.3 — 조달 및 상업 계약 참조).

  9. 인정된 표준을 채택하고 연속성을 거버넌스 아래 두라. ISO 22301을 구조화된 뼈대로, NHS와 국가 지침을 분야별 덧입힘으로 사용하고, 이사회에 보고하는 지정된 임원에게 업무 연속성에 대한 책임을 부여하라. 아무도 소유하거나, 재원을 대거나, 검토하지 않는 연속성은 사건이 그것을 드러낼 때까지 조용히 부패한다. 이를 보증 체계에 연결하여(주제 6.4 — 거버넌스 및 보증 참조) 계획이 위기에 재발견되지 않고 일상으로 유지, 시험, 개선되게 하라.

팀과 논의할 질문#

  1. 핵심 임상 시스템 각각에 대해 임상의와 실제로 어떤 RTO와 RPO에 합의했으며 — 현재 그것을 충족할 수 있는가? 이 질문은 열망과 역량 사이의 간극을 드러내게 한다. 많은 조직이 명시적 복구 목표를 정한 적이 없거나, 임상의의 입력 없이 IT에서 정했으므로, "허용 가능한" 다운타임은 사실상 현재 아키텍처가 우연히 제공하는 것일 뿐이다. 임상적 필요(응급 시스템은 몇 분)가 백업과 DR이 실제로 달성할 수 있는 것(아마 하루)과 충돌하는 곳을 토론하라. 그 간극이 이름을 붙이든 말든 지고 있는 관리되지 않은 임상 위험이기 때문이다. 마지막 실제 또는 시험된 복구를 구체적으로 보라. 얼마나 걸렸고, 얼마의 데이터를 잃었을 것이며, 이것이 안전하다고 누가 승인했는가? 좋고 정직한 답은 시스템별로 구체적 숫자를 명명하고, 아직 충족할 수 없는 곳을 인정하며, 각 간극을 편안한 침묵이 아니라 재원이 있는 조치로 바꾼다.

  2. 오늘 밤 랜섬웨어가 핵심 시스템과 백업을 암호화한다면, 내일 환자를 어떻게 안전하게 지킬 것이며 — 완전히 복구되기까지 얼마나 걸리는가? 이것은 실제 보건 시스템을 강타한 시나리오이므로 안심이 아니라 구체적이고 흔들림 없는 점검이 필요하다. 두 절반을 정직하게 탐구하라. 즉각적인 임상 연속성(다운타임 절차가 며칠 동안 병원 전체를 종이로 운영할 만큼 연습되고, 자원을 받고, 신뢰받는가?)과 기술적 복구(백업이 변경 불가이고 오프라인인가, 깨끗한 사본으로 다시 구축하는 것을 시험했는가, 복구 순서를 아는가?)다. 불편한 의존성을 드러내라. 싱글 사인온, 통합 엔진, 핵심 공급업체가 다운되면 그와 함께 얼마나 많은 것이 무너지는가? 누가 중대 인시던트를 선언하고, 누가 직원, 환자, 언론에 말하며, 누가 시스템을 다시 연결해도 안전하다고 결정하는지 생각하라. 강한 답은 지정된 역할과 시험된 복원이 있는 연습된 계획을 설명하고, 약한 답은 백업이 괜찮고 종이 프로세스가 그냥 작동할 것이라고 가정한다.

  3. 마지막으로 연속성과 재해 복구 계획을 종단 간 시험한 것은 언제이며, 무엇을 배웠는가? 여기서의 목적은 살아 있는 역량과 선반 위의 문서를 구별하는 것이다. 훈련되지 않은 계획은 시험되지 않은 것이며, 시험되지 않은 계획은 현실과 접촉하면 일상적으로 실패한다. 연락처 목록이 낡았고, 복구 단계에 아무도 가지고 있지 않은 자격 증명이 필요하며, 다운타임 양식이 다운된 시스템에 저장되어 있다. 실제로 하는 훈련의 범위를 논의하라. 도상 시나리오, 기술적 페일오버 시험, 서버 복원만이 아니라 일선 임상 대비책을 포함한 전체 시뮬레이션이다. 과거 사건과 훈련의 교훈이 실제로 고쳐지고 다시 시험되었는지, 기록되고 잊혔는지 파고들라. 좋은 답은 정기적인 훈련 일정, 찾아 해소한 틈의 증거, 계획의 어느 부분이 여전히 입증되지 않았는지에 대한 정직함을 보여 준다.

  4. 우리가 통제하지 못하는 핵심 의존성은 무엇이며 — 그중 하나가 실패하는 날의 계획은 무엇인가? 현대 보건 IT는 홀로 실패하는 일이 드물다. 그 밑의 서비스와 공급업체를 통해 실패한다. 팀을 소유한 시스템 너머로 단지 의존하는 시스템으로 밀어붙이라. 국가 스파인 연결, 싱글 사인온 제공자, 클라우드 리전, 통합 엔진, 외주 데이터센터, 복구의 열쇠를 쥔 관리 서비스 파트너다. 각각에 대해 그것이 하루 동안 사라지면 돌봄에 무슨 일이 일어나는지, 계약이 제3자에게 우리의 임상적 필요에 맞는 복구 목표를 의무화하는지, 입찰서의 안심시키는 문단이 아니라 그들의 DR 시험 증거를 본 적이 있는지 물으라. 불편한 진실은 실패가 다른 사람의 자산에 있기 때문에 값을 매긴 적 없는 잔여 위험을 짊어질 수 있다는 것이다. 정직한 답은 각 핵심 서비스의 구체적 외부 의존성을 명명하고, 어느 것이 계약으로 보증되고 어느 것이 단지 신뢰되는지 밝히며, 회복탄력적으로 만들 수 없는 의존성에 대해 — 수작업이라도 — 대비책을 식별한다.

  5. 중대 인시던트가 닥칠 때 누가 무엇을 결정하고, 누가 누구에게 소통하며, 모두가 그날 이전에 자신의 역할을 아는가? 연속성은 백업만큼이나 지휘와 소통의 문제이며, 연습된 계획과 즉흥적인 혼란이 갈라지는 곳이다. 인간적인 안무를 따져 보라. 누가 중대 인시던트를 선언하고 계획을 발동할 권한이 있는지, 누가 운영 대응을 이끄는지, 누가 시스템을 다시 연결해도 안전하다고 결정하는지, 누가 직원, 환자, 언론, 규제 기관, 그리고 사이버 공격에서는 법 집행 기관에 말하는지다. 인시던트 중 자체 도구의 실패를 생각하라. 장애가 조율에 보통 쓰는 이메일, 전화번호부, 인트라넷을 다운시킬 수 있기 때문이다. 빨리 움직이는 것과 안전하게 움직이는 것 사이의 긴장, 그리고 대중에게 보내는 메시지를 잘못했을 때의 평판 위험을 드러내라. 강한 답은 지정되고 대리인이 있는 역할을 가진 시험된 인시던트 지휘 구조, 대역 외 소통 채널, 미리 합의된 메시지 템플릿을 가리키고, 약한 답은 올바른 사람들이 그냥 모여 무엇을 할지 알 것이라고 가정한다.

  6. 2년 동안 아무 일도 없을 때 연속성에 어떻게 재원을 대고, 소유하고, 살려 두는가? 회복탄력성은 사건 사이의 틈에서 조용히 부패하며, 이 질문은 그것이 썩지 않게 하는 조직적 규율과 맞선다. 연속성은 눈에 보이고 긴급한 임상 및 디지털 우선순위와 돈과 주의를 두고 경쟁하며, 미성숙하지만 운이 좋은 조직은 그렇지 않게 되는 날까지 성숙한 조직과 똑같아 보인다. 임원 수준에서 누가 진정으로 연속성을 소유하는지, 빌린 선의가 아니라 재원이 있는 항목이 있는지, 시스템과 직원이 바뀜에 따라 계획, 의존성 지도, 연락처 목록이 어떻게 최신으로 유지되는지 토론하라. 이사회가 실제로 무엇을 보는지 물으라. 시험된 보증과 정직한 격차인가, 녹색 등급과 보관된 문서인가? 좋은 답은 지정된 책임, 반복되는 예산과 훈련 일정, 유지되고 시험된 연속성을 다음 위기에 재발견하는 대신 일상으로 다루는 거버넌스의 리듬을 설명한다.

실제 사례: 보건·돌봄 예시#

Meadowvale NHS Foundation Trust는 600병상 급성기 병원을 운영한다. 어느 화요일 아침, 직원들이 출근해 보니 전자 환자 기록(EPR), 병리, 영상 시스템이 몸값 요구문으로 잠겨 있다. 공격자들은 열흘 전 공급업체의 원격 접속 계정을 통해 들어왔다. 최고정보책임자는 한 시간 안에 중대 인시던트를 선언하고, 트러스트의 업무 연속성 계획이 가동된다.

트러스트가 업무 영향 분석을 해 두었기 때문에 EPR과 병리가 합의된 복구 목표를 가진 가장 중요도가 높은 시스템임을 알았고, 다운타임 절차는 지난가을 연습한 상태였다. 병동은 종이 약물 차트와 미리 인쇄된 관찰 양식으로 전환한다. 공유 드라이브가 아니라 각 병동의 물리적 캐비닛에 의도적으로 보관해 둔 것이다. 응급실은 종이 경로로 되돌아간다. 그 주의 선택 수술은 연기되어 환자에게 통지되고, 구급차는 가장 바쁜 시간대에 우회된다. 돌봄은 저하되었지만 안전하게 계속된다. 직원들이 그렇게 일하는 법을 연습했기 때문이다.

복구는 복원보다 어렵다. 보안 팀은 확산을 막으려고 네트워크를 격리한 뒤, 오프라인으로 보관된 변경 불가 백업, 곧 공격자가 닿을 수 없던 사본에서 핵심 시스템을 다시 구축한다. 그 백업은 분기마다 복원 시험을 해 왔기 때문에 팀은 프로세스가 작동하고 대략 얼마나 걸리는지 알았다. EPR은 8시간의 RTO 안에 복구되고, 의존성이 더 복잡한 병리는 이틀이 걸린다. 15분의 RPO는 짧은 구간의 데이터만 잃었음을 뜻하며, 직원은 약물과 결과를 이중 점검하면서 통제된 재입력 프로세스로 종이 기록을 시스템에 대조해 넣는다.

사후 보고에서 트러스트는 실제 틈을 발견한다. 싱글 사인온이 복구 중 임상의 접근을 지연시킨 단일 장애점이었고, 공급업체의 원격 접속은 트러스트 자체의 연속성 보증에 포함되어 있지 않았다. 둘 다 소유자와 일자와 함께 이사회의 위험 등록부에 올라가고, 다음 전체 훈련이 예정된다. 나쁜 한 주였지만 재앙은 아니었다. 계획이 존재했고, 자원을 받았고, 시험되었기 때문이다.

부문별 관점#

스타트업#

디지털 보건 스타트업에는 여분의 데이터센터가 거의 없으므로 연속성 전략은 거의 전적으로 클라우드 네이티브 회복탄력성과 규율 있는 백업에 기댄다. 가용성 영역에 걸친 내장 고가용성을 가진 관리형 서비스를 쓰고, 랜섬웨어와 침해된 클라우드 계정 모두에서 살아남도록 변경 불가한 계정 외부 사본으로 백업을 자동화하며, 깨끗한 환경으로의 복원을 실제로 연습하라. 고객인 NHS 트러스트와 통합 돌봄 시스템은 DTAC 같은 프레임워크와 공급업체 보증을 통해 RTO, RPO, DR 시험의 증거를 점점 더 요구할 것이므로, 연속성을 간접비가 아니라 영업 자산으로 다루라. 소규모 공급업체의 존재적 위험은 한 번의 사건, 또는 배포를 혼자 이해하는 창업자가 단일 장애점이 되는 것이다.

소규모 사업체#

확립된 소규모 제공자 — 일반의 진료소, 지역 약국, 요양원, 재가 돌봄 기관, 단일 사업장 클리닉 — 는 장애를 거치며 환자를 안전하게 지킬 대형 트러스트와 같은 의무를 지지만, 실제 환자가 있고, 현금은 빠듯하며, 흔히 전담 IT 직원이 전혀 없다. 여기서 연속성은 의도적으로 실용적이다. 실패하면 안전한 돌봄을 멈출 한두 시스템(임상 기록, 조제나 eMAR 시스템)이 무엇인지 알고, 시스템 공급업체가 자체 백업, RTO, RPO의 증거를 대도록 요구하며, 화면이 꺼졌을 때 직원이 닿을 수 있는 곳에 단순하고 인쇄된 다운타임 팩 — 종이 약물 차트, 핵심 전화번호, 최근 환자 목록 — 을 두라. 한 명의 진료소 관리자나 단독 IT 계약자가 설정을 이해하는 유일한 사람인 경우가 많으므로 복구 단계를 적어 두고 두 번째 사람이 따라 할 수 있게 하라. 랜섬웨어와 끊어진 광대역 회선이 일상적 위협이므로, 감당하거나 운영할 수 없는 정교한 DR 사이트보다 오프라인 또는 변경 불가 백업 사본과 대비 업무 방식이 더 중요하다.

대기업#

대형 NHS 트러스트, 통합 돌봄 시스템, 큰 보건 기술 공급업체는 어떤 단일 시스템보다 의존성과 공유 서비스를 지도로 그리는 것이 가장 어려운 문제인 방대하고 서로 얽힌 자산을 갖고 있다. ISO 22301에 맞춘 공식 BCM 프로그램, 유지되는 의존성 지도, 핵심 시스템용 DR 사이트나 리전, 임상 대비책을 포함한 순환 훈련 일정에 투자하라. 규모는 SPOF가 흔히 공유 서비스, 곧 신원, 통합 엔진, 네트워크 코어이며 그 실패가 수십 개 시스템에 연쇄한다는 뜻이다. 거버넌스가 구속 조건이다. 팀과 공급업체가 많을 때 연속성은 지정된 임원이 소유하고 이사회가 종이 계획이 아니라 시험된 보증을 검토할 때만 유지된다.

정부#

NHS England, 지방분권 보건 부처, UKHSA 같은 국가 기관은 인구와 체계 규모에서 회복탄력성을 생각해야 하며, 국가 서비스나 널리 쓰이는 공급업체의 실패는 그 자체로 분야 전체의 연속성 사건이다. 표준과 기대(복구 목표, 사이버 복구, 의무적 훈련)를 정하고, 공유 보호 역량에 재원을 대며, 전국 랜섬웨어 캠페인 같은 중대 사건에 대한 분야 전체의 대응을 조율하라. WannaCry 대응이 국가 정책을 재형성한 것은 바로 영향이 수백 개 조직을 한꺼번에 가로질러 공통의 약점을 드러냈기 때문이다. 여기서 책임은 공적이고 의회적이므로, 알려진 위험에 대한 투명성과 준비 상태에 대한 정직한 보고가 기술적 통제 자체만큼 중요하다.

흔한 실패 양상#

  • 복원해 본 적 없는 백업. "매일 밤 백업한다"를 "복구할 수 있다"와 혼동한다. 시험되지 않은 복원은 일상적으로 실패하거나 RTO를 넘긴다. 백업 완료가 아니라 성공한 종단 간 복원을 측정하고 보고하라.
  • 랜섬웨어가 닿을 수 있는 백업. 모든 백업을 온라인, 네트워크 연결 상태로 두어 공격자가 프로덕션과 함께 암호화한다. 적어도 하나의 변경 불가 또는 오프라인 사본을 보유하라.
  • 서비스가 아니라 서버를 보호하는 DR. 데이터베이스는 복원하지만, 그것을 쓸 수 있는 임상 서비스로 만드는 의존성, 통합, 접근은 복원하지 않는다. 서비스 전체를 의존성 순서대로 복구하고 시험하라.
  • 종이에 관한 종이로만 존재하는 다운타임 절차. 연습된 적 없거나, 실패하는 시스템에 저장되었거나, 일선 직원이 모르는 대비 계획. 돌봄이 실제로 이루어지는 곳에서 연습하라.
  • 지도로 그려지지 않은 의존성과 공유된 SPOF. 싱글 사인온, DNS, 공급업체 하나가 모든 것을 떠받치고 있었음을 장애 중에 발견한다. 인시던트 중이 아니라 전에 의존성을 지도로 그리라.
  • 감사관을 위해 쓰고 한 번도 훈련하지 않은 계획. 필요한 날까지 시험되지 않은 채 부패하는 준수 문서로서의 연속성. 시험되지 않은 계획은 실패하는 계획이다.
  • 공급업체와 클라우드 연속성 무시. 증거 없이 제3자가 회복탄력적이라고 가정하고 공유 책임 모델을 잊는다. 연속성을 계약으로 만들고 보증하라.

성숙도 모델#

차원 시작 발전 표준화 관리 조율
복구 목표 RTO/RPO 없음; 복구는 장비가 허용하는 만큼 일부 시스템에 IT가 단독으로 RTO/RPO 설정 모든 핵심 시스템에 임상의와 RTO/RPO 합의 목표를 시험 결과에 대해 추적하고 소유자에게 KPI로 보고 목표를 정기 시험으로 입증하고 지속적으로 조율
백업과 복원 백업은 실행되나 복원은 시험된 적 없음 가끔 임시 복원 시험 일정에 따른 복원 시험, 일부 변경 불가/오프라인 사본 복원 성공, 시간, 무결성을 RTO/RPO에 대해 측정하고 보고 자동화되고, 시간을 재며, 무결성을 점검하는 복원이 있는 변경 불가 백업
임상 다운타임 문서화된 대비책 없음 종이 절차는 있으나 연습되지 않음 핵심 시스템의 다운타임과 재입력을 연습 훈련 참여와 재입력 정확도를 측정하고 격차를 적극 관리 잦은 훈련; 직원이 능숙하고 양식과 접근이 보증됨
재해 복구 DR 계획 없음; 희망과 영웅적 분투 DR 계획은 문서화되었으나 시험되지 않음 핵심 시스템에 대해 DR 사이트/리전을 시험 페일오버 결과, 복구 시간, 의존성 범위를 목표까지 추적 정기 페일오버 시험, 의존성 순서, 사이버 복구 포함
거버넌스와 훈련 소유자 없음, 훈련 없음 소유자는 지명되었으나 훈련은 드묾 ISO 22301에 맞춘 임원 소유 BCM, 정기 훈련 연속성 지표와 보증된 통제를 이사회가 목표에 대해 검토 이사회가 보증, 모든 사건과 훈련에서 지속적 개선

체크리스트#

  • 임상의와 함께 소유하는 업무 영향 분석이 모든 서비스의 순위를 매기고 각 핵심 시스템에 명시적 RTO와 RPO를 설정한다.
  • 핵심 시스템에 임상적 중요도에 비례하는 고가용성과 이중화가 있다.
  • 단일 장애점과 핵심 의존성(공유 서비스와 공급업체 포함)을 지도로 그리고 완화한다.
  • 백업이 3-2-1 규칙을 따르며 적어도 하나의 사본은 랜섬웨어가 닿을 수 없는 변경 불가 또는 오프라인이다.
  • 복원을 일정에 따라 시험하고 RTO/RPO에 대해 시간을 재며, "마지막 성공한 복원"을 지표로 보고한다.
  • 모든 핵심 임상 시스템에 연습된 다운타임 절차와 통제된 데이터 재입력 프로세스가 있다.
  • 재해 복구 계획이 복구 단계, 순서, 결정 권한, 복귀를 정의하고 DR 사이트/리전이 시험된다.
  • 사이버 복구 시나리오(격리, 깨끗한 백업에서 재구축, 검증, 재연결)가 문서화되고 훈련된다.
  • 공급업체와 클라우드 연속성이 계약으로 요구되고, 증거가 제시되며, 공유 책임 모델을 포함해 보증된다.
  • 연속성이 ISO 22301에 맞춰지고, 지정된 임원이 소유하며, 일정에 따라 훈련되고, 이사회에 보고된다.

주요 출처#

  • NHS England — Business Continuity Management Toolkit 및 Emergency Preparedness, Resilience and Response (EPRR) Framework and Core Standards.
  • National Cyber Security Centre (NCSC) — 오프라인/변경 불가 백업, 랜섬웨어 완화, 인시던트 대응에 관한 지침.
  • ISO 22301:2019 — Security and resilience — Business continuity management systems — Requirements (International Organization for Standardization).
  • ISO/IEC 27031 — Guidelines for information and communication technology readiness for business continuity.
  • Business Continuity Institute (BCI) — Good Practice Guidelines.
  • National Audit Office — Investigation: WannaCry cyber attack and the NHS (2017)와 Department of Health 교훈 검토.
  • NHS England / Data Security and Protection Toolkit (DSPT) — 업무 연속성과 인시던트 대응을 포함한 데이터 보안 표준.
  • GOV.UK Service Manual — 라이브 서비스의 회복탄력성, 모니터링, 복구 지침.

참고문헌#

  1. Business continuity planning — Wikipedia — https://en.wikipedia.org/wiki/Business_continuity_planning
  2. IT disaster recovery — Wikipedia — https://en.wikipedia.org/wiki/IT_disaster_recovery
  3. ISO 22301 — Wikipedia — https://en.wikipedia.org/wiki/ISO_22301
  4. Backup — Wikipedia — https://en.wikipedia.org/wiki/Backup
  5. High availability — Wikipedia — https://en.wikipedia.org/wiki/High_availability
  6. Redundancy (engineering) — Wikipedia — https://en.wikipedia.org/wiki/Redundancy_(engineering)
  7. Failover — Wikipedia — https://en.wikipedia.org/wiki/Failover
  8. Single point of failure — Wikipedia — https://en.wikipedia.org/wiki/Single_point_of_failure
  9. Ransomware — Wikipedia — https://en.wikipedia.org/wiki/Ransomware
  10. WannaCry ransomware attack — Wikipedia — https://en.wikipedia.org/wiki/WannaCry_ransomware_attack
  11. ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements — International Organization for Standardization — https://www.iso.org/standard/75106.html
  12. Investigation: WannaCry cyber attack and the NHS — National Audit Office — https://www.nao.org.uk/reports/investigation-wannacry-cyber-attack-and-the-nhs/
  13. Emergency Preparedness, Resilience and Response (EPRR) — NHS England — https://www.england.nhs.uk/ourwork/eprr/
  14. Offline backups in an online world — National Cyber Security Centre — https://www.ncsc.gov.uk/blog-post/offline-backups-in-an-online-world
  15. Data Security and Protection Toolkit — NHS England — https://www.dsptoolkit.nhs.uk/

GitHub에서 이 페이지 편집 — 이 책이 신뢰할 수 있는 기준이며, 이 사이트는 그것을 보여 줄 뿐입니다.