두 번째 발걸음자산목록에 업무와 의존성을 함께 적는다

서버 목록에 장비 이름과 IP 주소가 모두 적혀 있어도 무엇부터 복구할지 답하지 못할 수 있습니다. 어떤 서버가 주문과 결제에 쓰이는지, 어떤 외부 서비스에 의존하는지, 자료의 소유 부서가 어디인지 빠져 있기 때문입니다. 자산 식별은 물건의 개수를 세는 일에서 시작할 수 있지만, 위험을 분석하려면 그 자산이 어떤 업무와 사람을 지탱하는지까지 알아야 합니다.

하드웨어 자산에는 PC, 서버, 네트워크 장비, 보안 장비와 저장매체가 있습니다. 소프트웨어 자산에는 운영체제, 상용 제품, 직접 개발한 프로그램, 라이브러리와 설정이 있습니다. 정보자산에는 고객자료, 주문기록, 설계 문서, 인증정보 등이 있습니다. 클라우드의 계정과 관리 권한, 외부 서비스 계약, 핵심 지식을 가진 인력도 업무 의존성에 영향을 줍니다. 직접 소유하지 않았다는 이유로 위험 분석에서 제외할 수는 없습니다.

각 자산에는 소유 또는 책임 주체를 정합니다. 여기서 소유자는 반드시 법적 소유권자만 뜻하지 않습니다. 업무적 가치와 사용 목적, 허용 범위를 결정하고 변경을 승인할 책임자를 뜻할 수 있습니다. 운영자는 이를 실제로 구성하고 관리합니다. 정보의 가치를 가장 잘 아는 업무 부서와 설정을 바꿀 수 있는 기술 부서가 연결되어야 과도하거나 부족한 통제를 줄일 수 있습니다.

자산 중요도는 가격표만으로 정하지 않습니다. 값이 싼 인증 장비 하나가 멈추면 관리자 모두가 복구 작업을 못 할 수 있습니다. 공개된 안내 페이지의 기밀성 요구는 낮아도 허위 안내로 바뀌면 이용자가 피해를 입으므로 무결성이 중요합니다. 작은 직원 건강자료 파일은 용량이 적어도 노출 시 개인에게 큰 피해를 줄 수 있습니다. 기밀성·무결성·가용성의 관점에서 각각 영향을 평가합니다.

구성도는 정보가 어디서 들어와 어디에 저장되고 어떤 경계를 지나가는지 보여 줘야 합니다. 사용자의 요청이 웹 서버와 응용 프로그램, DB, 외부 결제로 이어지는 길을 표시하면 보호할 접점이 보입니다. 네트워크 구성도에는 구간과 연결, 허용 경로를, 데이터 흐름도에는 처리 목적과 자료 이동을 나타낼 수 있습니다. 선을 많이 그리는 것보다 실제 접근과 의존성을 정확히 표현하는 것이 중요합니다.

그다음 위협과 취약점을 자산에 연결합니다. 외부 공격자, 내부자의 실수나 남용, 장비 고장, 화재, 공급업체 중단은 서로 다른 위협 원인입니다. 과도한 권한, 갱신되지 않은 소프트웨어, 검증하지 않은 백업, 빈약한 계약은 그 위협이 피해로 이어질 조건이 됩니다. 취약점 목록만 있으면 어떤 일이 얼마나 중요한지 알기 어렵고, 위협 이름만 있으면 무엇을 고칠지 알기 어렵습니다. 구체적인 사고 시나리오로 묶어야 합니다.

예를 들어 ‘고객 DB가 중요하다’보다 ‘퇴사 계정이 남아 있고 외부 접속이 가능해 고객 주소가 무단 열람될 수 있다’가 대응에 유용합니다. 현재 존재하는 통제도 함께 기록합니다. 다중요소 인증과 접근 제한이 이미 있는지, 실제로 적용되는지에 따라 남는 가능성이 달라집니다. 새로운 서비스와 계정이 생기거나 외부 연계가 바뀌면 자산목록과 위험 분석도 갱신합니다. 과거의 정확한 목록은 현재의 정확한 목록을 대신하지 못합니다.

참고　[2] · [284]