HM WIKI

정보보호

무엇을 지키는가. 정보보호의 세 가지 목표와 그 목표들이 서로 충돌한다는 사실, 그리고 보안이 결국 균형을 정하는 활동인 이유를 설명합니다.

정보보호의 세 가지 목표

정보보호는 흔히 세 요소로 설명됩니다. 영문 머리글자를 따 CIA 라고 부릅니다.

  • 기밀성: 허가된 사람만 정보에 접근할 수 있어야 합니다.
  • 무결성: 정보가 허가되지 않은 방법으로 변경되지 않아야 합니다.
  • 가용성: 필요할 때 정보와 시스템을 사용할 수 있어야 합니다.

세 목표는 종종 서로 부딪힙니다. 접근을 엄격히 막을수록 기밀성은 높아지지만 가용성은 떨어지고, 업무 속도도 느려집니다. 보안을 강화했더니 현업이 우회로를 만들어 쓰더라는 이야기는 이 충돌에서 나옵니다. 그래서 정보보호는 위험을 없애는 활동이 아니라, 위험의 크기에 맞춰 균형점을 정하는 활동에 가깝습니다.

통제의 세 갈래

보호를 위해 적용하는 수단을 통제라고 하며, 대체로 셋으로 나눕니다.

  • 관리적 통제: 정책, 규정, 절차, 교육, 책임자 지정처럼 사람과 조직을 다루는 통제입니다.
  • 기술적 통제: 접근 권한, 암호화, 방화벽, 로그 기록처럼 시스템으로 구현되는 통제입니다.
  • 물리적 통제: 출입 통제, 시건 장치, 저장 매체의 보관과 파기처럼 공간과 물건을 다루는 통제입니다.

기술적 통제만 잔뜩 사 두고 관리적 통제가 비어 있는 조직이 많습니다. 솔루션은 도입되어 있는데 그 로그를 아무도 보지 않고, 권한 대장은 만들었는데 갱신되지 않는 상태입니다. 통제는 도입이 아니라 운영에서 완성됩니다.

정보보호와 개인정보 보호의 차이

둘은 겹치지만 같지 않습니다. 정보보호는 정보 자산 전반을 지키는 것이 목적이고, 개인정보 보호는 특정 개인을 알아볼 수 있는 정보를 어떻게 다루는가 를 규율합니다.

예를 들어 고객 정보를 완벽히 암호화해 보관하고 접근 통제도 철저히 했다고 합시다. 정보보호 관점에서는 훌륭합니다. 그런데 그 정보를 수집 목적과 무관한 마케팅에 활용했다면 개인정보 보호 원칙을 위반한 것입니다. 기술적으로 안전한 것과 법적으로 적법한 것은 다른 문제이고, 보안 부서만 있고 개인정보 담당이 없는 조직이 자주 걸려 넘어지는 지점입니다. 자세한 내용은 개인정보 문서에서 다룹니다.

보안이 실패하는 지점

사고의 원인을 따라가 보면 최신 공격 기법보다 평범한 것들이 더 자주 나옵니다. 퇴직자 계정이 살아 있었고, 공용 계정을 여럿이 나눠 썼고, 패치가 밀려 있었고, 담당자가 첨부파일을 열었습니다.

정보보호가 어려운 이유는 새로운 위협을 모르기 때문이 아니라, 이미 아는 것을 계속 지키기가 어렵기 때문입니다. 보안은 한 번의 구축이 아니라 유지의 문제입니다.

위험 평가 (리스크 진단)

모든 위험을 없앨 수는 없으므로, 무엇부터 막을지 정해야 합니다. 자산과 위협, 취약점, 영향의 관계를 통해 위험을 판단하고 대응을 선택하는 방법을 설명합니다.

정의

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

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

구성 요소

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

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

정성적 평가와 정량적 평가

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

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

위험 대응

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

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

잔여 위험

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

퇴직자 잔존 접근권한

사용자 계정을 막은 뒤에도 세션, API 키, 공유 링크, 개인 기기에 남을 수 있는 접근 경로를 살펴봅니다.

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

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

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

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

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

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

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

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

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

실무에서 확인할 항목

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

읽을 수 있는 로그 설계

사고가 난 뒤 쓸 수 있는 로그를 만들기 위해 시각, 사용자, 행위, 결과와 보존 정책을 어떻게 설계해야 하는지 설명합니다.

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

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

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

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

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

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

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

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

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

실무에서 확인할 항목

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

SaaS 보안 공백

설정 화면 밖에 남는 데이터, 외부 연동, 관리자 권한과 계약 종료 시 반출 및 삭제 문제를 다룹니다.

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

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

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

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

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

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

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

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

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

실무에서 확인할 항목

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

서비스 계정 관리

자동화와 시스템 연동에 사용하는 계정의 책임자, 권한, 인증정보와 업무 의존성을 관리합니다.

담당자는 바뀌었지만 작업은 계속됩니다

한 점검에서 계정 이름에 이미 퇴직한 이전 담당자의 흔적이 남아 있는 것을 발견했습니다. 지금도 그 계정으로 배치 작업이 매일 실행되고 있었지만, 비밀번호를 누가 관리하는지는 아무도 명확히 답하지 못했습니다.

서비스 계정은 사람이 직접 로그인하기보다 프로그램이 작업을 수행하는 데 사용하는 계정입니다. 사용자가 퇴직했다고 같은 방식으로 중지하면 업무가 멈출 수 있습니다.

소유자와 사용처

저는 계정마다 업무 책임자와 기술 관리자를 연결합니다. 만든 사람보다 현재 용도와 변경 영향을 설명할 수 있는 사람이 필요합니다. 접근하는 시스템, 수행하는 작업, 실행 주기를 확인하며, 사용 기록이 드물어도 월말 처리나 비상 복구에 쓰일 수 있으므로 마지막 접속일만으로 폐기를 정하지 않습니다.

권한과 인증정보

관리자 권한이 정말 필요한지, 여러 업무가 하나의 계정을 공유하는지 살핍니다.

  • 가능한 환경에서는 용도별 계정과 사람의 로그인 제한을 검토합니다.
  • 비밀번호와 키는 소스코드나 공유 문서에 직접 두지 않고 적절한 비밀정보 관리 수단을 씁니다. 플랫폼이 지원하면 관리형 식별자 등 별도 비밀번호 보관을 줄이는 방식도 검토합니다.

교체가 필요한 순간

인증정보를 바꾸기 전에는 연결 작업과 시험·복구 방법을 확인하고, 교체 후에는 새 정보의 작동뿐 아니라 이전 정보가 더 이상 유효하지 않은지도 점검합니다. 계정 관리 목록에는 "사용 중"보다 무엇이 이 계정에 의존하는지가 보여야, 권한 축소나 폐기를 결정할 때 업무 영향을 함께 판단할 수 있습니다.

정리

정리하면, 서비스 계정은 사람 계정과 다른 기준으로 관리합니다. 소유자와 의존 업무를 밝히고 권한을 최소화하며, 인증정보 교체는 연결 작업까지 확인한 뒤 마칩니다.

보안 예외 관리

보안 기준을 일시적으로 다르게 적용할 때 허용 범위, 기간, 승인과 남은 위험을 관리합니다.

끝나지 않는 임시 허용

한 사례에서 장애 조치를 위해 접근 제한을 잠시 해제했습니다. 업무는 곧 정상화됐지만 설정은 그대로 남았고, 해제 당시의 담당자가 바뀌면서 원상복구할 이유도 함께 잊혔습니다. 임시 허용이 사실상 상시 허용이 된 것입니다.

저는 예외 요청에서 시작일과 종료 조건을 같이 봅니다. "필요할 때까지"라는 표현은 언제 만료되는지 판단하기 어렵습니다.

필요한 만큼의 범위

특정 파일 하나를 전달하려는데 외부 전송 전체를 허용해야 하는지 살피고, 대상 계정·경로·시간을 좁힐 수 있는지 검토합니다. 추가 로그, 별도 승인, 접근 장소 제한 등을 보완 조치로 둘 수 있습니다. 다만 기록을 더 남기는 조치가 전송 자체를 막는 조치와 같은 효과를 낸다고 보지는 않습니다.

승인과 책임

요청 사유, 대안 검토, 허용 범위와 남은 위험을 승인권자가 이해할 수 있게 제시합니다. 내부 승인으로 법령이나 계약상의 제한까지 해소되는 것은 아닙니다. 설정 변경 기록과 승인 문서를 연결하고, 가능하면 만료 시 권한이 자동 회수되도록 구성하되 업무 영향이 있으면 사전 안내와 종료 확인을 함께 둡니다.

반복되는 예외의 의미

같은 예외가 계속 요청되면 승인자를 늘리는 것만으로 해결되지 않습니다. 기본 통제가 업무와 맞지 않거나 필요한 기능이 빠져 있을 수 있습니다. 연장할 때는 실제 사용 여부와 사고·오류 발생 여부도 확인해, 반복 예외를 정식 절차로 바꿀지 업무 방식을 바꿀지 판단할 자료로 삼습니다.

정리

정리하면, 예외는 범위와 기간과 책임이 정해질 때만 통제됩니다. 종료 조건 없는 임시 허용을 남기지 않고, 반복되는 예외는 통제 자체를 다시 볼 신호로 읽습니다.

비인가 AI 사용 관리

승인되지 않은 AI 사용을 파악하고 업무 목적, 입력 자료와 결과 활용에 따라 허용 범위를 정합니다.

개인 계정에 올라간 업무 문서

한 부서에서 긴 문서를 빨리 요약하려고 개인 계정의 AI에 파일을 통째로 올렸습니다. 사용자는 편리한 기능을 쓴 것뿐이지만, 조직은 어떤 자료가 외부로 전달되었는지 알기 어려웠습니다.

비인가 AI는 별도 챗봇만을 뜻하지 않습니다. 문서 도구, 브라우저 확장, 회의 서비스에 추가된 기능도 관리 범위에 들어올 수 있습니다.

서비스 이름만으로 정하지 않습니다

저는 서비스, 계정 유형, 입력 데이터, 사용 목적을 함께 봅니다. 같은 서비스라도 계약과 설정에 따라 데이터 처리 조건이 다를 수 있습니다. 공개 자료의 문장 정리와 내부 조사자료 분석을 같은 수준으로 허용하기는 어렵고, 무료·유료 여부만으로 안전성을 구분하지도 않습니다. "학습에 사용하지 않는다"는 조건도 보관, 관리자 접근, 외부 처리 문제를 모두 설명하지는 않으므로 필요한 처리 조건을 각각 확인합니다.

파악과 대안 제공

사용 현황은 담당자 설명, 도입 목록, 적법하게 운영하는 보안 관리 자료 등으로 확인할 수 있습니다. 현황 파악을 이유로 개인 계정의 내용까지 무제한으로 열람하는 방식은 적절하지 않습니다. 사용 목적을 함께 확인해야 대안을 마련할 수 있고, 대안 없이 금지된 도구가 하던 업무를 수행할 방법이 없으면 사용이 다른 곳으로 이동합니다.

이미 사용한 자료의 처리

입력 범위와 공유 상태, 서비스의 삭제·보관 조건을 확인합니다. 이후 판단에 필요한 정보를 확보하면서 추가 입력과 노출을 제한합니다. 승인 목록에는 서비스 이름만 적기보다 허용 데이터와 업무 범위를 붙여, 사용자가 자신의 작업이 그 범위에 드는지 판단할 수 있게 합니다.

정리

정리하면, 비인가 AI는 이름이 아니라 입력 자료와 사용 목적으로 판단합니다. 현황을 과도한 열람 없이 파악하고 대안을 함께 제시해야, 금지가 사용을 음지로 옮기지 않습니다.

세션 토큰 탈취와 MFA의 한계

다중요소 인증을 적용했더라도 인증 후 발급된 세션 정보가 탈취되면 비정상 접근이 발생할 수 있습니다. 로그인 이후의 접근도 보호해야 합니다.

사례로 보는 문제

가상의 사례입니다. 회사가 MFA를 적용했는데 사용자가 승인하지 않은 파일 다운로드가 확인됐습니다. 해당 행위 직전에 추가 인증 요청은 없었습니다. 이때 비밀번호 유출뿐 아니라 기존 세션의 악용 가능성도 조사해야 합니다. 다만 추가 인증이 없었다는 사실 자체는 침해의 증거가 아닙니다.

세션이 재사용되는 조건을 확인합니다

서비스는 로그인 후 매번 인증하지 않도록 세션 쿠키나 토큰을 이용합니다. 공격자가 이를 탈취하고 서비스가 해당 정보의 재사용을 허용하면 사용자를 가장한 접근이 가능할 수 있습니다. 모든 토큰이 같은 방식으로 재사용되는 것은 아니며, 유효기간·사용 대상·기기 결합 여부 등이 영향을 줍니다.

탈취 경로에는 피싱과 단말 악성코드 등이 있습니다. 접속 IP의 변화만으로 행위자나 감염을 확정하지 않고, 인증기록과 서비스 이용기록, 기기 정보와 시간 흐름을 대조합니다. VPN·모바일망·프록시의 영향도 확인합니다.

인증과 세션 보호를 함께 적용합니다

MFA는 여전히 중요한 보호수단입니다. 피싱 저항성이 높은 인증, 관리되는 기기에서의 접근, 세션 보호와 이상행위 탐지를 함께 검토합니다. 피싱에 강한 인증을 사용해도 이미 감염된 단말의 모든 위험이 사라지는 것은 아닙니다.

침해 대응에서는 비밀번호 변경만으로 끝내지 않습니다. 계정 차단, 세션·토큰 무효화와 탈취 원인 제거를 서비스 특성에 맞게 수행합니다. 무효화가 기존 접근 토큰이나 서비스 세션에 즉시 적용되는지는 별도로 확인해야 합니다.

실무에서 확인할 사항

  • 인증·토큰 발급·파일 열람 및 다운로드 기록의 연결
  • 정상 업무와 다른 IP·기기·사용자 에이전트·행위
  • 피싱·악성코드 등 탈취 경로를 뒷받침하는 자료
  • 세션·토큰 무효화의 적용 범위와 실제 차단 결과
  • 로그 보존 범위와 재발 방지 설정

협력사 원격접속 관리

협력사 원격접속은 도구의 승인뿐 아니라 접속자, 대상 시스템, 권한, 작업 내용과 허용 시간을 함께 관리해야 합니다.

사례로 보는 문제

가상의 사례입니다. 서버 장애 대응을 위해 협력사 원격접속을 허용했지만 작업 종료 후에도 무인접속 설정이 남아 있었습니다. 공용 계정을 사용해 협력사의 어느 직원이 접속했는지도 확인하기 어려웠습니다.

도구의 승인과 작업의 승인은 다릅니다

정품 프로그램이고 설치가 승인됐다는 사실만으로 모든 접속이 정당해지는 것은 아닙니다. 합법적인 원격지원 도구도 계정 탈취나 설정 오용으로 악용될 수 있습니다. “업체에 허용”하는 수준을 넘어 누가 어느 시스템에서 어떤 작업을 언제까지 수행하는지 정해야 합니다.

원격접속의 보호수단으로 개인별 식별, 다중요소 인증과 최소 권한을 권고합니다. 적용 법령·계약·내부 규정에서 요구하는 조치를 확인하고, 작업 요청을 실제 접속·변경기록과 연결합니다. 제품 자체에 필요한 기능이 부족하다면 접근 게이트웨이 등 보완수단이나 다른 접속 방식을 검토합니다.

작업 종료 후의 접근까지 관리합니다

종료 시 임시 계정·권한·활성 세션을 회수하고, 상시 유지보수 접속은 승인된 운영 기준에 따라 관리합니다. 무인접속을 일률적으로 금지하거나 모든 작업 후 프로그램을 제거하는 것이 유일한 관리 방식은 아닙니다.

업무시간 밖 접속은 긴급 작업 승인과 실제 수행 내용을 확인합니다. 접속 성공 기록만으로 전체 작업이 파악되지는 않으므로 시스템 변경기록과 파일 전송기록 등 필요한 근거를 확보합니다. 화면 녹화를 사용하는 경우에는 민감정보 노출과 보관·열람 범위도 함께 관리합니다.

실무에서 확인할 사항

  • 승인 도구와 실제 설치·실행 도구의 일치 여부
  • 접속자 식별·인증 및 대상·시간·권한 제한
  • 파일 전송·클립보드 공유 등 부가 기능의 필요성
  • 작업 요청과 접속·변경기록의 일치 여부
  • 종료 후 권한 회수와 상시 접속의 정기 검토

기업 내 부정·비리, 디지털 데이터로 끝까지 규명합니다

상담 문의
전화문의