RTO vs RPO vs MTTR vs MTBF: the Security+ metrics people mix up, and how to keep them straight

출처: Dev.to
SY0-701 시험에서 시나리오 문제가 주어집니다. 회사의 데이터베이스는 최대 15분 동안의 트랜잭션을 잃을 수 있으며, 고장 발생 후 2시간 이내에 복구되어야 합니다. 문제는 15분이 어느 지표가 설명하는지 묻습니다. 멈추고 생각해야 한다면 혼자가 아닙니다.
복구 및 위험 지표는 시험에서 가장 쉽게 획득할 수 있는 점들이자 동시에 가장 쉽게 포기할 수 있는 점들이며, 네 가지가 거의 동일하게 들리기 때문에 출제자는 이를 알고 있습니다.
제가 이것들을 확고히 할 수 있었던 방법은 다음과 같습니다.
둘 다 시간과 관련이 있지만 측정하는 대상이 다릅니다. 트릭은 고장 발생 시점을 기준으로 각 지표를 앵커링하는 것입니다.
RPO(Recovery Point Objective)는 고장 발생 시점을 기준으로 역방향으로 측정합니다. “우리는 얼마나 많은 데이터를 감당할 수 있는가?” 라는 질문에 답합니다. RPO가 15분이라면 백업 또는 복제본은 15분 이상의 작업을 잃지 않도록 충분히 최신 상태여야 합니다. RPO는 백업 빈도를 결정합니다.
RTO(Recovery Time Objective)는 고장 발생 시점을 기준으로 전방향으로 측정합니다. “우리는 얼마나 오래 지속될 수 있는가?” 라는 질문에 답합니다. RTO가 2시간이라면 서비스를 복구할 수 있는 시간은 2시간이며, 그 이후의 영향이 받아들일 수 없게 됩니다. RTO는 복구 계획과 핫, 워밍, 혹은 콜드 사이트 선택을 결정합니다.
위 시나리오에서 15분은 RPO이고 2시간은 RTO입니다. 제 자신을 바르게 잡아주는 한 줄은: RPO는 데이터에 관한 것이고, RTO는 가동 중단 시간에 관한 것입니다.
이들을 전체 수명 주기 동안의 하드웨어와 시스템을 설명하며, 단일 사건만을 위한 것이 아닙니다.
MTBF(평균 고장 간격)는 평균적으로 Something이 고장하기 전까지 작동하는 시간을 의미합니다. 값이 클수록 좋습니다. 이를 통해 신뢰성을 예측하고 교체를 계획합니다.
MTTR(평균 복구 시간)는 고장이 난 후 수리를 하는 데 걸리는 시간을 의미합니다. 값이 작을수록 좋습니다.
시험은 이 지표들을 유지보수 또는 구매 시나리오와 함께 배치하는 것을 좋아합니다. 문제가 부품이 얼마나 자주 고장나는지 묻는다면那是 MTBF이며, 빠르게 다시 가동할 수 있게 하는 시간을 묻는다면那是 MTTR입니다. 하나는 수명에 관한 것이고, 다른 하나는 복구 속도에 관한 것입니다.
스와프하지 않기 위한 빠른 방법은 “between failures”라는 표현에 고장이라는 단어가 들어 있으므로 이는 고장 사이의 간격을 의미합니다. “time to repair”은 라벨에 복구라는 단어가 이미 포함되어 있습니다.
Security+가 요구하는 다른 계산 장소는 정량적 위험 분석입니다.
이 세 가지는 외울 필요 없이 짧은 수식 체인일 뿐입니다.
먼저 자산 가치(AV)를 확인하세요. 자산이 얼마나 가치가 있는지입니다. 노출 요인(EF)는 한 사건에서 그 가치를 잃게 될 백분율입니다.
SLE(단일 손실 기대)=AV×EF. 하나의 불운한 사건의 비용입니다.
ARO(연간 발생 빈도)=일년 동안 예상되는 발생 횟수입니다.
ALE(연간 손실 기대)=SLE×ARO. 연간 비용입니다.
사례 연구: 노트북 군단은 50,000달러 가치가 있습니다. 절도 사건은 보통 그 가치의 20%를 차지하므로 EF는 0.2입니다. SLE는 50,000×0.2=10,000입니다. 연간 3건의 절도가 예상되면 ARO는 3이며, ALE는 10,000×3=30,000입니다.
이제 연간 30,000달러 이하의 비용을 들여 컨트롤을 구현할 수 있습니다.
마지막으로 ALE와 컨트롤 비용 사이의 비교가 보통 실제 문제의 핵심 포인트입니다.
이 네 가지 지표와 SLE‑to‑ALE 체인을 자동으로 익히면, 바로 확보할 수 있는 보장된 점들이 있어, 다른 사람들은 데이터 손실을 떠올리느라 답변 선택지에 애를 쓰는 동안 기다립니다.