앞 장에서는 국가기관, 플랫폼 기업, 직장과 학교, 가까운 사람, 공동체의 관리자처럼 서로 다른 행위자가 어떤 권한과 능력을 가질 수 있는지 살펴보았다. 그러나 가능한 위협을 많이 아는 것만으로는 어떤 보안 조치를 선택해야 하는지 결정할 수 없다.
모든 위험을 같은 정도로 막을 수는 없다. 사용할 수 있는 시간과 비용, 기술적 역량은 제한되어 있으며, 보안 조치 자체도 불편과 새로운 위험을 만든다. 모든 계정을 익명화하고 모든 통신을 여러 계층으로 암호화하는 방식이 어떤 사람에게는 필요할 수 있지만, 다른 사람에게는 유지하기 어려운 복잡성만 늘릴 수 있다.
위협 모델링은 세상에 존재하는 모든 위협을 찾아내는 작업이 아니다. 자신이 하는 구체적인 활동에서 무엇을 보호하려 하는지, 어떤 사건이 실제 피해를 일으킬 수 있는지, 누가 어떤 경로로 그 사건을 일으킬 수 있는지를 분석하고 대응의 우선순위를 정하는 과정이다.
위협 모델에는 하나의 정답이 없다. 같은 메신저와 같은 기기를 사용하는 사람도 처한 관계와 활동, 예상되는 피해에 따라 다른 결론에 도달할 수 있다. 공개적으로 활동하는 단체와 가명으로 글을 쓰는 개인, 스토킹 상황에 놓인 사람, 공동 서버를 운영하는 관리자는 서로 다른 것을 보호해야 한다.
따라서 “어떤 도구가 가장 안전한가”를 묻기 전에 다음을 물어야 한다.
- 어떤 활동을 분석하려 하는가?
- 무엇을 보호하려 하는가?
- 그 활동은 무엇에 의존하고 있는가?
- 어떤 일이 일어나지 않기를 바라는가?
- 누가 어떤 경로로 그 일을 일으킬 수 있는가?
- 그 일이 일어날 가능성과 피해는 어느 정도인가?
- 어떤 대응을 실제로 지속할 수 있는가?
- 그 대응은 누구에게 새로운 권한과 부담을 만드는가?
- 어떤 위험은 여전히 남는가?
- 언제 이 판단을 다시 검토해야 하는가?
위협 모델링의 목적은 두려움을 최대화하는 것이 아니다. 막연한 공포를 구체적인 조건과 선택의 문제로 바꾸는 것이다.
위협 모델링은 공포의 목록이 아니다
보안 조언을 가능한 한 많이 적용하는 방식이 언제나 적절한 것은 아니다. 모든 계정을 익명화하고, 모든 통신을 Tor를 통해 전송하고, 활동별로 여러 기기를 분리하며, 모든 서비스를 직접 운영하면 이론적으로 보호 범위는 넓어질 수 있다. 그러나 비용과 복잡성, 피로도 함께 커진다.
복잡한 체계는 더 많은 설정 오류를 만들 수 있다. 절차가 일상생활에서 감당하기 어려우면 사용자는 이를 우회하거나 포기하게 된다. 보안 규칙이 지나치게 복잡한 공동체에서는 구성원이 암호화된 시스템 대신 익숙한 메시지를 사용하거나, 복잡한 계정 복구 절차를 피하기 위해 비밀번호를 공유할 수도 있다.
보안 조치가 많다는 사실과 보안이 잘 작동한다는 사실은 같지 않다. 실제로 지킬 수 없는 엄격한 규칙보다 위험과 한계를 이해하면서 지속할 수 있는 절차가 더 유용할 수 있다.
따라서 위협 모델링의 목적은 최대한 많은 보안 도구를 사용하는 것이 아니다. 실제 피해 가능성이 크거나 결과가 중대한 위험에서 제한된 시간과 자원을 우선 배분하는 것이다.
이 과정에서 모든 위험을 제거하려 해서는 안 된다. 어떤 위험은 줄일 수 있고, 어떤 위험은 다른 사람이나 시스템으로 이전할 수 있으며, 어떤 위험은 활동을 지속하기 위해 감수해야 한다. 중요한 것은 위험을 알지 못한 채 받아들이는 것과, 조건과 결과를 검토한 뒤 받아들이는 것을 구분하는 일이다.
분석할 상황의 범위를 정한다
“내 디지털 생활 전체”를 한꺼번에 분석하려 하면 범위가 지나치게 커진다. 모든 계정, 기기, 관계, 플랫폼을 한 번에 검토하려 하면 분석이 끝나지 않거나 피로 때문에 중단되기 싶다.
먼저 하나의 구체적인 활동이나 관계를 선택하는 편이 좋다.
- 가명으로 정치적 글을 게시하는 활동
- 집회 참가 신청과 연락망 관리
- 퀴어 청소년 상호부조 채팅방
- 독립 출판물의 원고와 필자 정보 관리
- 공동체가 운영하는 Matrix 서버
- 직장 기기에서 개인 계정을 사용하는 상황
- 스토킹 상황에서 위치정보와 계정을 보호하는 일
범위는 구체적일수록 분석하기 쉽다. ‘온라인 활동’보다는 ‘가명 블로그에 글을 게시하고 독자와 이메일로 연락하는 활동’이 낫다. ‘공동체 운영’보다는 ‘행사 참가 신청을 받고 참가자에게 장소와 시간을 전달하는 과정’이 낫다.
활동의 시작과 끝도 정해야 한다. 집회 연락망을 분석한다면 신청서를 작성하는 순간부터 행사가 끝난 뒤 참가자 정보를 삭제하는 시점까지를 범위로 삼을 수 있다. 행사 당일의 현장 촬영이나 교통 수단 이용은 별도의 위협 모델로 분리할 수 있다.
범위를 좁히는 것은 다른 위험을 무시하자는 뜻이 아니다. 한 번에 다룰 수 있는 크기로 문제를 나누자는 뜻이다.
무엇을 보호하려 하는가
보호 대상을 단순히 ‘개인정보’나 ‘보안’이라고 적으면 이후의 판단도 모호해진다. 보호하려는 정보, 관계, 자원, 활동 가능성을 구체적으로 구분해야 한다.
예를 들어 다음과 같은 것들이 보호 대상이 될 수 있다.
- 법적 이름과 가명 사이의 분리
- 참가자의 전화번호와 소속
- 메시지와 파일의 내용
- 누가 누구와 연락했는지에 관한 관계 정보
- 접속 위치와 이동 경로
- 계정에 계속 접근할 수 있는 능력
- 게시물을 보존하고 배포할 수 있는 능력
- 공동체가 서비스를 계속 운영할 수 있는 능력
- 구성원이 자유롭게 참여하고 이의를 제기하며 떠날 수 있는 능력
- 관리자가 교체되어도 시스템을 유지할 수 있는 능력
무엇이 중요한지는 상황에 따라 다르다. 가명 필자에게는 실명과 필명 사이의 분리가 가장 중요할 수 있다. 공동체 서비스 운영자에게는 서비스의 지속성과 백업이 더 중요할 수 있다. 스토킹 상황에서는 위치정보와 계정 복구 수단이 핵심일 수 있다.
보호 대상에는 다른 사람의 정보도 포함될 수 있다. 관리자가 자신의 신원을 공개할 의사가 있더라도, 서버 로그나 연락망에는 공개에 동의하지 않은 구성원의 정보가 들어 있을 수 있다. 한 사람이 감수할 수 있다고 판단한 위험을 다른 사람에게도 자동적으로 적용해서는 안 된다.
또한 보호 대상 사이에는 충돌이 생길 수 있다. 기록을 오래 보관하면 공동체의 의사결정 과정을 증명하기 쉬워지지만, 압수나 유출 시 피해가 커질 수 있다. 익명성을 강화하면 참여자의 신원은 보호되지만, 지속적인 괴롭힘에 대응하기 어려워질 수도 있다. 위협 모델링은 무엇을 보호할지만 아니라, 보호 대상 사이의 우선순위와 충돌도 다룬다.
활동이 무엇에 의존하는지 파악한다
보호할 대상만 확인해서는 충분하지 않다. 그 활동이 어떤 사람, 기기, 계정, 서비스와 물리적 환경에 의존하는지도 파악해야 한다.
가명 블로그 활동은 다음과 같은 요소에 의존할 수 있다.
- 글을 작성하는 노트북과 휴대전화
- 운영체계와 브라우저
- 이메일 계정과 복구 수단
- 블로그 플랫폼이나 서버
- 도메인 등록기관과 DNS 사업자
- 인터넷 통신사
- 결제 수단
- 원고를 검토하는 동료
- 백업이 저장된 장치나 클라우드
이를 흔히 공격 표면이라고 부르기도 하지만, 모든 의존 요소가 곧 취약점이라는 뜻은 아니다. 중요한 것은 하나의 활동이 생각보다 많은 중개자와 장치에 의존한다는 사실을 확인하는 것이다.
의존 관계를 파악할 때는 다음을 물을 수 있다.
- 이 요소가 중단되면 활동도 중단되는가?
- 이 요소를 관리하는 사람은 어떤 정보에 접근할 수 있는가?
- 한 계정이 침해되면 다른 계정도 함께 복구되거나 탈취되는가?
- 대체할 수 있는가?
- 한 사람이나 한 서비스에만 의존하고 있는가?
- 누가 실제 소유권이나 최종 결정권을 가지고 있는가?
예를 들어 공동체가 자체 서버를 운영하더라도 도메인과 호스팅 비용이 한 운영자의 개인 계정과 카드에 묶여 있다면, 그 사람의 부재나 갈등으로 서비스 전체가 중단될 수 있다. 기술적으로 분산된 시스템도 운영상의 의존 관계 때문에 중앙집중적일 수 있다.
어떤 사건을 막으려 하는가
다음으로 일어나지 않기를 바라는 사건을 구체적으로 적는다. 이 단계에서는 공격자를 먼저 정하지 않는 편이 좋다.
예를 들면 다음과 같다.
- 가명과 법적 신원이 연결된다.
- 참가자 연락망 전체가 외부에 공개된다.
- 관리자가 구성원을 일방적으로 추방한다.
- 기기를 잃어버린 뒤 저장된 메시지가 읽힌다.
- 플랫폼이 계정을 정지하여 기록과 연락처에 접근할 수 없게 된다.
- 동료 한 명의 계정 탈취로 공동 문서 전체가 유출된다.
- 사진의 배경과 메타데이터를 통해 장소가 식별된다.
- 서버 고장으로 유일한 백업까지 사라진다.
- 관리자의 갑작스러운 부재로 아무도 서비스를 복구하지 못한다.
- 탈퇴한 구성원의 개인정보가 계속 보관된다.
“해킹당한다”나 “감시당한다” 같은 표현은 지나치게 넓다. 무엇이 누구에게 노출되고, 어떤 기능이 상실되며, 그 결과가 무엇인지 적어야 한다.
예를 들어 “계정이 해킹당한다”보다 다음과 같은 표현이 더 구체적이다: “공동 문서 관리자 계정이 탈취되어 참가자의 실명과 전화번호가 외부로 유출되고, 공격자가 기존 문서를 삭제한다.” 구체적인 사건을 적으면 한 사건 안에서도 기밀성, 무결성, 가용성의 문제가 서로 다르게 나타난다는 사실을 확인할 수 있다.
누가 어떤 경로로 그 사건을 일으킬 수 있는가
앞 장에서 살펴본 행위자 분류와 능력 기준을 이 단계에 적용한다. 같은 사건에서도 여러 행위자와 경로가 관련될 수 있다.
예를 들어 “가명과 법적 신원이 연결된다”는 사건은 다음과 같은 경로로 발생할 수 있다.
- 플랫폼이 가입할 때 받은 전화번호를 계정과 연결한다.
- 지인이 글의 내용과 문체를 알아본다.
- 사진의 위치정보나 배경이 노출된다.
- 두 계정이 같은 이메일 복구 주소를 사용한다.
- 결제 기록이나 도메인 등록 정보가 확인된다.
- 실명 계정과 가명 계정에 같은 사용자 이름이나 프로필 사진을 쓴다.
- 같은 브라우저와 추적 식별자를 통해 여러 계정이 연결된다.
- 기기가 압수되거나 잠금이 해제된다.
- 함께 활동한 사람이 신원을 공개한다.
이 단계에서는 반드시 ‘누가’와 ‘어떻게’를 함꼐 적는 것이 좋다. “기업이 위험하다”보다 “플랫폼 사업자는 가입할 때 받은 전화번호와 접속 기기 정보를 이용해 가명 계정을 다른 계정과 연결할 수 있다”가 더 유용하다. 마찬가지로 “동료가 자료를 유출할 수 있다”도 “참가자 명단에 접근할 수 있는 운영자의 개인 이메일 계정이 탈취되면, 공격자는 공유 문서의 링크와 저장된 연락처를 함꼐 확보할 수 있다”처럼 구체화할 수 있을 것이다.
가능한 경로를 적을 때 지나치게 희귀한 공격을 끝없이 상상할 필요는 없다. 상대가 실제로 가진 접근권한과 능력, 과거 사례, 활동의 성격을 기준으로 현실적인 경로부터 검토한다.
현재의 보호 조치를 확인한다
새로운 도구를 선택하기 전에 이미 적용된 보호 조치를 기록해야 한다. 기존 조치를 확인하지 않으면 같은 기능을 중복 도입하거나, 실제로는 작동하지 않는다고 오해할 수 있다.
예를 들어 다음과 같은 조치가 이미 존재할 수 있다.
- 기기 전체 암호화
- 화면 잠금과 자동 잠금
- 다중 인중
- 종단간 암호화
- 운영체제와 애플리케이션 자동 업데이트
- 참가자 정보 최소 수집
- 관리자 권한 분리
- 암호화된 백업
- 데이터 자동 삭제
- 계정 복구 코드의 별도 보관
- 관리자 교체 절차
보호 조치가 있다는 사실만 기록해서는 안 된다. 실제 적용 범위와 한계도 확인해야 한다.
예를 들어 메신저가 종단간 암호화를 사용하더라도 잠금이 해제된 기기에는 메시지를 읽을 수 있다. 다중 인증을 사용하더라도 복구 이메일이 탈취되면 계정이 넘어갈 수 있다. 백업이 있어도 복구 절차를 시험하지 않았다면 실제 사고 때 사용할 수 없을 수도 있다.
따라서 각 조치에 대해 다음을 확인한다.
- 무엇을 막는가?
- 무엇은 막지 못하는가?
- 누가 설정하고 관리하는가?
- 실제로 작동하는지 시험했는가?
- 사용자가 일상적으로 지킬 수 있는가?
- 실패했을 때 어떤 징후가 나타나는가?
가능성과 피해를 평가한다
모든 위협을 같은 수준으로 처리할 수 없으므로 발생 가능성과 피해의 크기를 평가해야 한다.
정밀한 숫자 계산까지 요구할 필요는 없다. 위험을 하나의 수치로 표현하면 근거 없는 정확성을 만들 수 있다. 낮음, 중간, 높음 정도로 구분하되, 왜 그렇게 판단했는지 근거를 함께 기록하는 편이 낫다.
발생 가능성을 평가할 때는 다음을 묻는다.
- 과거에 비슷한 일이 있었는가?
- 상대가 실제로 이 정보나 활동에 관심을 가질 이유가 있는가?
- 필요한 능력과 접근권을 가지고 있는가?
- 공격에 필요한 시간과 비용은 어느 정도인가?
- 표적을 특정해서 공격해야 하는가, 아니면 자동화할 수 있는가?
- 한 번의 실수만으로 발생할 수 있는가?
- 현재 적용된 보호 조치가 있는가?
피해의 크기를 평가할 때는 다음을 묻는다.
- 신체적 안전에 영향을 주는가?
- 주거, 생계, 학업, 의료 접근에 영향을 주는가?
- 다른 구성원에게 피해가 확산되는가?
- 신원이나 관계가 되돌릴 수 없게 노출되는가?
- 계정이나 자료를 복구할 수 있는가?
- 피해가 일시적인가, 장기간 지속되는가?
- 당사자가 피해 사실을 빠르게 알 수 있는가?
- 피해를 줄이거나 중단시킬 수 있는가?
발생 가능성이 낮지만 피해가 치명적인 사건과 자주 발생하지만 복구하기 쉬운 사건을 구분해야 한다. 가능성과 피해가 모두 높은 사건은 우선 대응해야 한다. 가능성은 낮지만 피해가 치명적인 사건에는 비상 절차외 피해 제한 조치를 마련할 수 있다.
하지만 가능성 평가는 현재 상황에 대한 판단일 뿐이다. “지금까지 일어나지 않았다”는 사실만으로 앞으로도 일어나지 않을 것이라고 결론 내려서는 안 된다. 반대로 구체적인 근거 없이 최악의 상황만을 기준으로 모든 활동을 제한해서도 안 된다.
대응의 우선순위를 정한다
위험을 평가한 뒤에는 어떤 것부터 대응할지 정한다. 이때 가능성과 피해만 아니라 대응의 비용과 실행 가능성도 함께 고려해야 한다.
다음과 같은 기준을 사용할 수 있다.
- 적은 비용으로 큰 위험을 줄일 수 있는가?
- 한 번의 조치로 여러 위험을 줄일 수 있는가?
- 현재 가장 큰 단일 실패 지점을 제거하는가?
- 구성원이 실제로 사용할 수 있는가?
- 유지 관리가 필요한가?
- 잘못 설정했을 때 새로운 피해가 생기는가?
- 긴급한 조치인가, 장기적으로 개선할 조치인가?
예를 들어 모든 통신 인프라를 즉시 교체하는 것보다 사용하지 않는 관리자 계정을 삭제하고, 관리자에게 다중 인증을 적용하며, 참가자 명단의 보관 기간을 줄이는 일이 더 빠르고 효과적일 수 있다.
완벽한 체계를 한 번에 구축하려 하지 않아도 된다. 조치를 다음과 같이 나눌 수 있다.
- 즉시 적용할 수 있는 저비용 조치
- 일정한 학습과 준비가 필요한 중기 조치
- 인프라나 운영 구조를 바꾸는 장기 조치
- 사건 발생 시 실행할 비상 조치
위협 모델링은 이상적인 보안체계를 묘사하는 문서라기보다, 현재 위치에서 다음에 무엇을 바꿀지 정하는 문서여야 한다.
대응책을 선택한다
대응책은 보안 프로그램이나 장비만을 뜻하지 않는다. 정보를 수집하지 않는 결정, 운영 구칙, 권한 구조, 복구 절차고 모두 대응책에 포함된다.
수집하지 않기
필요하지 않은 실명, 전화번호, 위치 정보, 소속을 처음부터 받지 않는다. 수집하지 않은 정보는 유출 및 압수되거나 다른 목적으로 사용될 수 없다.
이미 수집한 정보도 필요가 끝났다면 삭제할 수 있다. 그렇지만 삭제 주기와 책임자를 정하지 않으면 ‘나중에 삭제하자’는 결정이 사실상 영구 보관으로 이어지기 쉽다.
분리하기
가명과 실명 계정, 개인 기기와 업무 기기, 관리자 계정과 일반 계정, 공개 연락망과 민감한 연락망을 분리한다.
분리는 하나의 계정이나 기기가 침해되었을 때 피해가 다른 영역으로 확산되는 것을 줄이다. 그러나 지나치게 많은 계정과 기기를 사용하면 관리 부담과 실수 가능성이 커질 수 있으므로, 필요한 수준의 분리를 선택해야 한다.
접근을 제한하기
암호화, 최소권한, 다중 인중, 기기 잠금, 관리자 역할 분산 등을 적용한다.
접근 권한은 실제 업무에 필요한 범위와 기간에 맞춰 부여한다. 모든 운영자에게 모든 자료의 접근권을 줄 필요는 없다. 역할이 끝나거나 구성원이 떠났을 때는 권한을 회수해야 한다.
탐지할 수 있게 하기
침해를 완전히 막을 수 없다면 가능한 한 빨리 알아차릴 수 있어야 한다. 새로운 기기 로그인 알림, 관리자 작업 기록, 파일 변경 이력, 서비스 상태 점검 등이 이에 해당한다.
하지만 탐지를 위해 과도한 로그를 수집하면 새로운 감시와 유출 위험이 생길 수 있다. 무엇을 얼마나 오래 기록할지 역시 위협 모델에 따라 결정해야 한다.
피해 범위를 제한하기
하나의 계정이나 서버가 침해되어도 모든 자료가 함께 노출되지 않도록 한다. 자료를 목적과 민감도에 따라 나누고, 오래된 정보를 삭제하며, 관리자 권한을 분리하는 것이 여기에 포함된다.
기술적 침입을 완전히 막지 못하더라도 공격자가 얻을 수 있는 정보의 양과 활동 범위를 줄일 수 있다.
복구하고 이탈할 수 있게 하기
백업, 복구 코드, 관리자 교체 절차, 데이터 내보내기, 대체 연락망을 준비한다.
복구는 기존 상태로 돌아가는 것만을 뜻하지 않는다. 문제가 생긴 플랫폼이나 관리 구조를 떠나 다른 시스템으로 이동하는 것도 복구의 한 형태다. 따라서 서비스와 자료가 특정 관리자나 사업자에게 묶이지 않게 해야 한다.
위험을 이전하기
일부 위험은 다른 서비스나 전문 조직에 맡길 수 있다. 직접 서버를 운영하지 않고 신뢰할 수 있는 호스팅 서비스를 이용하면 운영 실수의 위험을 줄일 수 있다. 반대로 서비스 사업자에게 데이터와 결정권이 집중되는 위험은 커질 수 있다.
위험의 이전은 위험의 제거가 아니다. 누가 새롭게 권한과 책임을 갖게 되는지를 확인해야 한다.
위험을 받아들이기
모든 위험을 없애려 하면 활동 자체가 불가능해질 수도 있다. 위험의 가능성과 피해, 대응 비용을 이해한 뒤 감수하는 결정도 위협 모델의 일부다.
하지만 위험을 받아들이는 사람과 피해를 부담하는 사람이 같아야 한다. 관리자가 운영 편의를 위해 위험을 수용했는데, 실제 피해는 참가자나 다른 구성원이 부담한다면 정당한 결정이라고 보기 어렵다.
대응책이 만드는 새로운 위험을 확인한다
보안 조치는 위험을 단순히 없애기보다 다른 형태로 바구거나 다른 사람에게 이동시키는 경우가 많다.
- 실명 확인은 외부인의 반복 가입을 줄일 수 있지만 참가자의 익명성을 없앤다.
- 중앙 관리자는 사고 대응을 빠르게 할 수 있지만 권한을 집중시킨다.
- 메시지 자동 삭제는 기기 압수와 계정 침해 시 노출을 줄이지만 공동체의 의사 결정 기록도 없앨 수 있다.
- 자가 호스팅은 기업 의존을 줄이지만 운영자에게 새로운 권한과 책임을 준다.
- 강한 기기 잠금은 정보를 보호하지만 인지적·신체적 접근성을 낮출 수 있다.
- 자세한 접근 로그는 침해 탐지에 유용하지만 구성원의 활동 기록을 새로 만든다.
- 관리자의 다중 승인 절차는 권한 남용을 줄이지만 긴급 대응을 느리게 할 수 있다.
- 활동별 기기 분리는 신원 연결을 줄이지만 비용과 관리 부담을 높인다.
따라서 대응책을 선택한 뒤에는 반드시 다음을 물어야 한다: “이 조치로 위험은 누구에게서 누구에게로 이동하는가?”
추가로 다음 질문도 필요하다.
- 이 조치를 결정한 사람은 누구인가?
- 비용과 불편을 실제로 부담하는 사람은 누구인가?
- 새로운 접근 권한을 얻는 사람은 누구인가?
- 조치를 따르기 어려운 사람은 배제되는가?
- 조치의 효과와 부작용을 다시 평가할 수 있는가?
- 당사자가 거부하거나 다른 방식을 선택할 수 있는가?
보안 조치의 효과만 평가하고 권력관계와 부담의 분배를 무시하면, 외부의 위험을 줄이면서 내부의 통제를 강화할 수 있다.
개인과 공동체의 위협 모델링은 다르다
개인은 자신의 위험과 감당할 수 있는 부담을 스스로 결정할 수 있다. 그러나 공동체의 위협 모델에서는 한 사람의 판단이 다른 사람에게 영향을 준다.
공동체 관리자가 참가자의 실명과 전화번호를 수집하기로 결정하면, 정보가 유출되었을 때 피해를 입는 사람은 관리자만이 아니다. 기술에 익숙한 구성원이 복잡한 보안 절차를 정하면, 이를 수행하기 어려운 구성원이 활동에서 배제될 수도 있다.
따라서 공동체의 위협 모델은 관리자나 보안 담당자만 작성해서는 안 된다. 정보가 수집되는 사람, 규칙을 따라야 하는 사람, 사고 발생 시 피해를 입을 사람이 결정 과정에 참여할 수 있어야 한다.
모든 세부 정보를 전체 구성원에게 공개할 수는 없더라도 최소한 다음은 설명되어야 한다.
- 어떤 정보를 왜 수집하는가
- 누가 접근할 수 있는가
- 얼마나 오래 보관하는가
- 어떤 사고를 예상하고 있는가
- 어떤 보안 조치를 요구하는가
- 그 조치가 구성원에게 어떤 부담을 주는가
- 사고가 발생하면 누구에게 어떻게 알리는가
- 정보 삭제와 이탈을 어떻게 요청할 수 있는가
공동체의 보안은 구성원을 보호의 대상으로만 취급하지 않고, 위험을 판단하고 선택할 수 있는 주체로 인정해야 한다.
남는 위험을 기록한다
대응책을 적용한 뒤에도 위험은 남는다. 이를 숨기거나 실패로 취급해서는 안 된다.
예를 들어 가명 계정을 실명 계정과 분리하고 Tor를 사용하더라도 문체, 활동 시간, 게시 내용, 지인의 추측을 통해 신원이 연결될 수 있다. 공동체가 참가자 정보를 최소화하더라도 각 참가자의 기기와 통신사 기록까지 통제할 수는 없다.
남는 위험을 기록하면 구성원이 안전의 범위를 오해하는 일을 줄일 수 있다. 보안 도구를 설치한 뒤 ‘이제 익명이다’ 또는 ‘이제 유출될 수 없다’고 믿는 것이 오히려 위험할 수 있다.
남는 위험을 기록할 때는 다음을 포함할 수 있다.
- 현재 막지 못하는 사건
- 막을 수 없는 이유
- 사고가 발생했을 때 예상되는 피해
- 피해를 줄일 비상 절차
- 구성원에게 알려야 할 한계
- 나중에 다시 검토할 조건
위협 모델은 안전을 보증하는 문서가 아니라, 현재의 판단과 한계를 투명하게 기록하는 문서다.
재검토 시점을 정한다
위협 모델은 한 번 작성하고 끝내는 문서가 아니다. 활동과 관계, 기술, 법률이 변하면 기존 판단도 달라진다.
다음과 같은 상황에서는 위협 모델을 다시 검토할 필요가 있다.
- 새로운 관리자가 추가되었을 때
- 구성원이 떠나거나 조직 내부에 갈등이 발생했을 때
- 활동의 공개 범위나 대상이 달라졌을 때
- 새로운 플랫폼이나 통신수단을 사용하기 시작했을 때
- 서비스 약관이나 법률이 바뀌었을 때
- 새로운 종류의 개인정보를 수집하기 시작했을 때
- 예상했던 위협이나 피해가 실제로 발생했을 때
정기적인 검토 시점도 정할 수 있다. 다만 형식적으로 매달 문서를 확인하는 것보다, 실제 변화와 사고를 기준으로 검토하는 편이 유용할 수 있다.
위협 모델을 수정할 때는 과거의 판단을 무조건 실패로 취급하지 않아야 한다. 당시에는 합리적이었던 결정도 상황 변화에 따라 부적절해질 수 있다. 중요한 것은 기존 결정을 방어하는 것이 아니라 현재의 조건에 맞게 다시 판단하는 것이다.
사례: 집회 참가 신청과 연락망
소규모 집회를 준비하는 공동체가 온라인 신청서를 통해 참가자를 모집하고, 일정과 장소 변경을 문자나 메신저로 전달한다고 가정해보자.
분석 범위
온라인 신청서를 작성하는 순간부터 행사가 끝난 뒤 참가자 정보를 삭제하는 시점까지를 분석한다. 집회 현장의 촬영과 이동 경로는 별도의 위협 모델로 다룬다.
보호 대상
- 참가자의 이름이나 가명
- 전화번호 또는 연락 계정
- 집회 참가 사실
- 참가자 사이의 관계
- 장소와 시간에 관한 비공개 정보
- 주최 측이 참가자에게 계속 연락할 수 있는 능력
- 참가자가 자신의 정보를 삭제하도록 요청할 수 있는 능력
의존 요소
- 신청서 플랫폼
- 주최자의 관리자 계정
- 연락용 메신저나 문자 서비스
- 참가자 명단을 저장한 문서
- 인터넷 통신사
- 명단에 접근할 수 있는 운영자
원치 않는 사건
- 신청서 링크가 예상하지 않은 대상에게 퍼진다.
- 참가자 명단이 외부에 공개된다.
- 관리자 계정 탈취로 전체 연락망이 유출된다.
- 행사 이후에도 개인정보가 계속 보관된다.
- 한 운영자가 조직 갈등 중 명단을 다른 목적으로 사용한다.
- 플랫폼이나 수사기관의 요구를 통해 신청 정보가 제공된다.
- 관리자 부재로 일정 변경을 전달하지 못한다.
가능한 경로
- 신청서가 링크를 아는 누구에게나 전체 응답을 보여준다.
- 운영자가 명단 파일을 개인 이메일로 전송한다.
- 관리자 계정에 다중 인증이 적용되어 있지 않다.
- 여러 운영자가 하나의 비밀번호를 공유한다.
- 참가자의 실명과 전화번호를 필요 이상으로 수집한다.
- 개인정보 삭제 시점과 책임자가 정해져 있지 않다.
- 연락 수단이 한 명의 개인 계정에만 의존한다.
위험 평가
명단 전체의 유출은 한 번의 계정 침해로 여러 참가자에게 피해가 확산될 수 있으므로 피해가 크다. 반면 참가자 한 명의 연락 실패는 발생 가능성이 높더라도 피해 범위는 상대적으로 제한적일 수 있다.
특정 수사기관이 명단을 요구할 가능성은 집회의 성격과 당시 상황에 따라 달라진다. 막연히 높거나 낮다고 판단하기보다 과거 사례와 법적 권한을 별도로 확인해야 한다.
현재 조치
- 신청서는 관리자만 응답을 볼 수 있다.
- 관리자 계정에 다중 인증을 사용한다.
- 행사에 필요하지 않은 주소와 주민등록번호는 수집하지 않는다.
- 참가자는 실명 대신 가명을 사용할 수 있다.
그러나 관리자 세 명이 같은 계정을 공유하고 있고, 명단 삭제 시점이 정해져 있지 않다는 문제가 남아 있다.
선택한 대응
- 공유 관리자 계정을 없애고 개인별 계정을 부여한다.
- 참가자에게 필요한 최소한의 연락수단만 받는다.
- 명단 접근 권한을 실제 연락 담당자에게만 준다.
- 행사 종료 후 정해진 기간 안에 원본 명단을 삭제한다.
- 삭제 시점과 예외 사유를 신청서에 설명한다.
- 일정 변경을 위해 대체 공지 채널을 마련한다.
- 관리자 계정 복구 수단을 한 사람에게만 맡기지 않는다.
새로 생기는 위험과 부담
명단을 빠르게 삭제하면 사고나 분쟁이 발생했을 때 참가 사실을 확인하기 어려울 수 있다. 관리자 계정을 분리하면 계정 관리 부담이 늘어난다. 대체 공지 채널은 참가자의 추가 가입이나 기술적 학습을 요구할 수 있다.
남는 위험
주최 측의 조치만으로 참가자 개인 기기의 알림, 통신사의 접속 기록, 집회 현장의 촬영까지 보호할 수는 없다. 이를 참가자에게 분명히 설명하고 별도의 현장 보안 안내를 제공해야 한다.
이 사례에서 위협 모델링은 ‘가장 안전한 신청서 서비스’를 하나 고르는 것만으로 끝나지 않는다. 어떤 정보를 받을지, 누가 접근할지, 언제 삭제할지, 관리자가 사라져도 연락을 계속할 수 있을지까지 함께 설계하는 과정이다.
위협 모델 기록 양식
다음 양식을 복사하여 개인이나 공동체의 상황에 맞게 사용할 수 있다.
분석 대상
- 활동:
- 분석 범위:
- 참여하거나 영향을 받는 사람:
- 작성일:
- 다음 검토 시점 또는 조건:
보호 대상
- 보호하려는 정보:
- 보호하려는 관계:
- 유지하려는 활동과 접근 가능성:
- 보장하려는 이탈 가능성:
- 보호 대상 사이의 충돌:
의존 요소
- 기기:
- 계정:
- 플랫폼과 통신 사업자:
- 관리자와 협력자:
- 물리적 공간:
- 결제·도메인·복구 수단:
- 단일 실패 지점:
원치 않는 사건
- 사건:
- 예상되는 피해:
- 영향을 받는 사람:
- 복구 가능성:
행위자와 경로
- 관련 행위자:
- 행위자가 가진 접근권과 능력:
- 사건이 발생할 수 있는 경로:
- 필요한 시간과 비용:
- 현재 존재하는 보호 조치:
위험 평가
- 발생 가능성: 낮음 / 중간 / 높음
- 판단 근거:
- 피해의 크기: 낮음 / 중간 / 높음
- 판단 근거:
- 대응 우선순위:
선택한 대응
- 수집하지 않을 정보:
- 분리할 계정·기기·자료:
- 제한할 접근 권한:
- 탐지 방법:
- 피해 범위 제한:
- 복구와 이탈 절차:
- 받아들이기로 한 위험:
대응의 부작용
- 새롭게 생기는 권한:
- 비용과 불편함을 부담하는 사람:
- 점근성에 미치는 영향:
- 새롭게 생기는 정보와 기록:
- 거부하거나 대체할 방법:
남는 위험
- 현재 막지 못하는 위험:
- 그 이유:
- 사고 발생 시 대응:
- 사용자와 구성원에게 알려야 할 한계:
위협 모델링은 미래를 정확히 예측하는 기술이 아니다. 불확실한 상황에서도 무엇을 중요하게 여기며 어떤 위험을 먼저 줄일지 결정하는 방법이다. 좋은 위협 모델은 가장 많은 공격을 상상한 문서가 아니라, 실제 선택과 행동으로 이어지고 변화한 상황에 따라 수정할 수 있는 문서다.