정보보호

정의

위험 평가는 조직이 보유한 자산에 어떤 위협이 있고, 그것이 현실화될 가능성과 영향이 어느 정도인지를 분석해 대응의 우선순위를 정하는 절차입니다.

출발점은 냉정한 전제입니다. 모든 위험을 없앨 수는 없습니다. 자원은 유한하고, 완벽한 보안은 업무를 마비시킵니다. 그러므로 위험 평가의 진짜 목적은 위험을 발견하는 것이 아니라 어디에 먼저 투입할지를 정하는 것 입니다.

구성 요소

• 자산: 지켜야 할 대상입니다. 데이터, 시스템, 설비, 인력이 모두 포함됩니다. 자산 목록이 없으면 위험 평가는 시작할 수 없습니다.
• 위협: 자산에 해를 끼칠 수 있는 잠재적 사건이나 행위자입니다. 해킹, 내부자 유출, 화재, 장비 고장, 담당자의 실수가 모두 위협입니다.
• 취약점: 위협이 파고들 수 있는 약한 지점입니다. 패치되지 않은 서버, 과도하게 부여된 권한, 존재하지 않는 승인 절차, 훈련되지 않은 담당자.
• 가능성과 영향: 그 일이 얼마나 일어날 법한지, 일어나면 얼마나 큰 손실이 생기는지입니다.

위협과 취약점은 짝을 이룰 때만 위험이 됩니다. 아무리 강력한 공격 기법이 존재해도 우리 환경에 해당 취약점이 없으면 위험은 작고, 반대로 사소한 취약점이라도 그것을 노리는 위협이 실제로 존재하면 위험은 커집니다.

정성적 평가와 정량적 평가

정성적 평가는 높음, 중간, 낮음 같은 등급으로 표현합니다. 빠르고 적용하기 쉽지만 기준이 주관적이어서, 평가자가 바뀌면 결과도 바뀔 수 있습니다.

정량적 평가는 예상 손실액처럼 숫자로 표현합니다. 비교가 명확하고 투자 판단에 직접 쓸 수 있지만, 신뢰할 만한 데이터가 있어야 성립합니다. 근거 없는 숫자는 오히려 잘못된 확신을 줍니다. 실무에서는 정성적 평가를 기본으로 하고 중요한 항목만 정량화하는 절충이 흔합니다.

위험 대응

• 감소: 통제를 도입해 가능성이나 영향을 낮춥니다. 가장 흔한 선택입니다.
• 전가: 보험이나 계약을 통해 다른 주체에게 넘깁니다. 다만 평판의 손상처럼 전가되지 않는 것도 있습니다.
• 회피: 위험을 발생시키는 활동 자체를 하지 않습니다. 수집하지 않은 개인정보는 유출되지도 않습니다.
• 수용: 대응 비용이 예상 손실보다 크다면 감수하기로 결정합니다.

네 번째가 중요합니다. 수용은 방치가 아닙니다. 누가, 어떤 근거로, 무엇을 감수하기로 했는지가 기록으로 남아야 수용입니다. 아무도 결정하지 않아 그대로 남아 있는 위험은 수용이 아니라 방치이고, 사고가 나면 그 차이가 책임을 가릅니다.

잔여 위험

통제를 적용한 뒤에도 남는 위험을 잔여 위험이라고 합니다. 잔여 위험이 0 이 되는 일은 없습니다. 위험 평가가 끝났다는 것은 위험이 사라졌다는 뜻이 아니라, 남은 위험의 크기를 조직이 알고 있고 그것을 감당하기로 했다는 뜻입니다.

계정 하나를 잠그는 것으로 끝나지 않습니다

퇴직 처리 목록에는 계정 비활성화 완료라고 적혀 있습니다. 저는 그다음에 활성 세션, 모바일 앱 로그인, API 키, 개인 액세스 토큰을 봅니다. 비밀번호를 바꾸거나 계정을 중지해도 이미 발급된 토큰이 일정 기간 유효한 서비스가 있기 때문입니다.

클라우드와 SaaS가 늘면서 한 사람의 접근권한은 사내 계정 하나에만 묶여 있지 않습니다. 그룹 계정, 협업 공간의 게스트 권한, 외부 저장소, 자동화 계정에 연결될 수 있습니다. 인사 시스템의 퇴직 정보가 모든 서비스로 전달되지 않으면 권한 회수의 빈틈이 생깁니다.

권한의 소유자를 사람 단위로 다시 묶습니다

서비스별 계정 목록만 보면 같은 사람이 여러 이름으로 존재할 수 있습니다. 회사 이메일, 별칭, 개인 이메일 초대, 외주 계정이 따로 남습니다. 저는 계정을 사람과 역할에 연결한 뒤, 고용 상태와 실제 필요성을 확인합니다.

공용 계정은 더 어렵습니다. 사용자가 바뀌어도 계정은 그대로여서 누가 언제 사용했는지 분리하기 어렵습니다. 불가피하게 공용 계정을 쓴다면 사용 승인, 비밀정보 변경, 접속 기록을 별도로 관리해야 합니다.

퇴직 절차는 당일 작업이 아니라 생명주기 관리입니다

입사 때 부여한 권한, 부서 이동 때 추가된 권한, 프로젝트 종료 후 남은 권한을 계속 관리하지 않으면 퇴직일에 모든 연결을 찾아내기 어렵습니다. 정기적인 권한 검토가 필요한 이유입니다.

회수 결과도 남겨야 합니다. 계정 중지 여부뿐 아니라 세션 종료, 토큰 폐기, 공유 링크와 게스트 권한 정리, 회사 기기 회수, 예외 승인 내역을 기록합니다. 누락을 줄이는 가장 현실적인 방법은 인사, IT, 현업이 같은 체크리스트를 쓰는 것입니다.

실무에서 확인할 항목

• 활성 세션, 토큰, API 키와 앱 비밀번호
• 게스트, 개인 이메일 초대와 공유 링크
• 공용 및 자동화 계정의 실제 소유자
• 인사 상태 변경과 권한 회수 절차의 연결

기록은 있는데 질문에 답하지 못합니다

접속 로그 파일은 남아 있지만 사용자 값이 비어 있고 시각의 기준도 적혀 있지 않습니다. 저는 이런 상태를 로그가 있다고 표현하기 어렵다고 봅니다. 용량을 소비하며 저장된 문자열과 조사에 쓸 수 있는 기록은 다릅니다.

로그는 나중에 물을 질문에서 거꾸로 설계해야 합니다. 누가, 언제, 어디서, 무엇을 시도했고, 허용되었는지 실패했는지를 구분할 수 있어야 합니다. 관리자 권한 변경, 대량 조회, 파일 다운로드처럼 위험이 큰 행위는 대상과 결과까지 남기는 편이 좋습니다.

모든 로그를 오래 보관하는 것이 답은 아닙니다

저장 기간을 무작정 늘리면 비용과 개인정보 위험이 함께 커집니다. 반대로 시스템 기본값만 따르면 사고를 인지했을 때 필요한 구간이 이미 지워질 수 있습니다. 저는 위협 시나리오, 탐지 주기, 법적 보존 요구, 저장 비용을 함께 놓고 기간을 정합니다.

원본 시스템과 중앙 수집 구간의 손실도 확인합니다. 네트워크 단절이나 수집기 장애가 발생했을 때 누락을 알리는 장치가 없으면 조용한 공백이 생깁니다. 로그 수집 성공 여부 자체도 감시 대상입니다.

시각과 식별자가 연결의 기준입니다

여러 시스템의 기록을 맞추려면 시계 동기화와 일관된 사용자 식별값이 필요합니다. 직원 이름만 남기면 동명이인과 계정 변경을 구분하기 어렵습니다. 계정 식별자, 기기 식별자, 세션 식별자를 함께 남기면 한 행위의 흐름을 연결하기 쉬워집니다.

중요 로그는 변경이나 삭제 권한을 제한하고, 접근 자체를 기록합니다. 사고 당사자가 운영 권한을 가진 상황까지 생각해야 합니다. 평소에는 잘 보이지 않는 설계 차이가 조사 가능 범위를 정합니다.

실무에서 확인할 항목

• 사용자, 시각, 행위, 대상, 결과 필드
• 시계 동기화와 시간대 표기
• 로그 수집 누락 및 지연에 대한 감시
• 보존기간, 접근권한과 위변조 방지

구매가 끝난 뒤부터 자산이 늘어납니다

협업 도구 하나를 도입하면 계정만 생기는 것이 아닙니다. 문서, 대화, 첨부파일, 외부 앱 연동, 공유 링크가 함께 늘어납니다. 저는 서비스 이름보다 그 안에서 어떤 정보가 만들어지고 어디로 이동하는지 먼저 정리합니다.

SaaS는 운영 인프라를 직접 관리하지 않아도 된다는 장점이 있지만, 책임까지 서비스 제공자에게 넘어가는 것은 아닙니다. 사용 조직이 정해야 할 접근권한, 공유 범위, 보존기간, 퇴직자 처리와 사고 대응 역할이 남습니다.

기본 설정은 조직의 기준이 아닙니다

외부 공유가 기본으로 허용되거나, 누구나 앱을 연결할 수 있거나, 관리자가 과도하게 많은 경우가 있습니다. 저는 초기 설정값을 그대로 받아들이지 않고 정보의 민감도와 업무 방식에 맞춰 바꿉니다. 다만 통제를 지나치게 닫으면 개인 계정이나 승인되지 않은 도구로 우회할 수 있어 사용 흐름도 함께 봅니다.

연동 앱은 별도의 데이터 경로입니다. 일정, 메일, 파일 저장소에 접근하는 권한을 한 번 승인하면 이용자가 잊은 뒤에도 연결이 남을 수 있습니다. 승인 주체와 권한 범위, 마지막 사용 시점을 정기적으로 검토합니다.

종료할 때 데이터를 꺼낼 수 있어야 합니다

서비스를 해지하거나 계약이 끝날 때 자료를 어떤 형식으로 내보낼 수 있는지, 삭제는 언제 완료되는지, 백업에는 얼마나 남는지 확인해야 합니다. 사고 조사에 필요한 로그를 제공받을 수 있는지도 계약 전에 보는 편이 낫습니다.

SaaS 목록만으로는 관리가 충분하지 않습니다. 데이터 종류, 관리자, 인증 방식, 외부 공유, 연동 앱, 로그 제공 범위, 종료 절차를 한 장에서 볼 수 있어야 합니다. 이 문서가 최신 상태인지 확인하는 책임자도 필요합니다.

실무에서 확인할 항목

• 처리 데이터와 저장 위치, 외부 이전 여부
• 관리자, 외부 공유와 게스트 정책
• 연동 앱의 권한과 마지막 사용 시점
• 계약 종료 시 데이터 반출, 삭제와 로그 확보