쌓이는 보안 공지,
매칭되지 않는 우리 서버
매일 쏟아지는 취약점 및 악성 패키지 공지 중, 정작 우리 서버에 영향을 미치는 항목을 식별하고 우선순위를 정하는 것은 여전히 수동 작업에 의존하고 있습니다.
핵심 기능
설치 없는 SSH 점검
등록한 SSH 계정으로 접속해 정해진 수집 명령만 실행합니다. 대상 서버에 수집 프로그램을 올리지 않고, 권한 설정도 바꾸지 않습니다.
취약점·악성 패키지 검사
OS 패키지와 npm·pip·Maven 등 앱 의존성의 버전을 취약점 정보와 대조하고, 악성으로 공지된 패키지를 찾습니다. 버전 판정은 AI가 아닌 규칙으로 합니다.
해킹 시도·보안 로그 검사
인증·웹 서버 로그에서 SSH 반복 실패, 실패 후 성공, 웹 공격 의심 패턴을 기간별로 집계합니다.
AI 증거 검토
연결한 LLM이 수집 자료를 읽고 근거와 함께 정리합니다. AI가 요청하는 추가 수집은 모두 관리자 승인을 거치며, LLM 없이도 점검할 수 있습니다.
컨테이너까지 위치 표시
Docker 컨테이너 안 경로와 호스트 경로를 나란히 보여 줘, 어디를 고쳐야 하는지 바로 찾습니다.
예약 점검과 이어서 점검
정기 점검을 예약합니다. 한도에 걸려 멈춘 점검은 다시 실행하면 수집한 자료를 재사용해 남은 부분부터 진행합니다.
우선순위별로
해결할 작업을 정리합니다
OS 업데이트, 이미지 재생성, 의존성 갱신 같은 작업을 P1~P4 단계로 나누어 우선순위를 정하고, 위치·버전·사용 여부까지 확인해 조치 계획을 제시합니다.
- 위치와 목표 버전까지작업을 펼치면 패키지, 현재·목표 버전, 정확한 위치가 나옵니다. 커널은 재부팅 필요 여부도 표시합니다.
- 사용 여부부터 확인할 항목은 따로캐시·CI 산출물처럼 실제 운영에 쓰이는지 불분명한 위치는 ‘사용 여부 확인’으로 따로 모읍니다.
- 담당자에게 바로 전달조치 계획 HTML, 작업 목록 CSV, 상세 보고서로 저장해 공유합니다.
확인한 것과
놓친 것을 구분합니다
결과가 없다고 안전한 건 아닙니다. 여섯 개 검사 영역별로 확인 상태를 표시해, 점검하지 못한 부분도 드러납니다.
- 영역별 점검 상태확인 완료·부분 확인·미검사를 구분해 위험 항목이 없어도 빠진 영역을 확인할 수 있습니다.
- 핵심만 쏙 정리‘확인된 사실, 주의할 위험, 점검 미완료 범위, 권장 조치 사항’을 보고서 제일 앞면에 알기 쉽게 정리해 드립니다.
점검 한 번이 보고서가 되기까지
점검 중에 패치, 파일 삭제, 서비스 중단, 공격 재현은 하지 않습니다.
웹 콘솔과 CLI,
같은 권한으로
점검 대상 서버, 점검 프로필, LLM, 예약, 취약점 정보를 한국어 웹 콘솔에서 관리합니다. 브라우저를 쓸 수 없는 환경에서는 guard CLI로 같은 작업을 같은 권한으로 처리합니다.
관리 화면은 허용한 IP에서만 열리고, SSH 키와 모델 키는 암호화해 보관합니다.
대표 활용 사례
- 긴급 취약점 공지 대응취약점 정보를 갱신하고 다시 점검해, 해당 위치와 필요한 조치를 바로 확인합니다.
- 공급망 공격 점검악성 패키지 공지에 오른 패키지·버전이 서버 어디에 있는지 찾습니다.
- 폐쇄망 서버 정기 점검취약점 정보를 파일로 반입하고, 사내 LLM이나 규칙 대조만으로 예약 점검합니다.
- 보안 점검 결과 공유조치 계획과 검사 범위를 담은 보고서를 조치·감사 담당자에게 전달합니다.
설치와 운영
- —관리 서버 한 대에 설치, 별도 DB 서버나 메시지 큐 불필요
- —점검 대상 서버에는 별도 수집 프로그램을 설치하지 않음
- —보안 공지는 온라인 갱신 또는 파일 반입, OS 패키지용 스캐너 DB는 별도 준비
- —설정·점검 기록·보고서를 한 번에 백업하고 복원
관리 서버는 Ubuntu 22.04·24.04 x86_64를 우선 지원합니다. 대상 서버 호환성과 처리 규모는 도입 환경에서 함께 확인합니다.
자주 묻는 질문
대상 서버에 무엇을 설치해야 하나요?+
별도 수집 프로그램은 설치하지 않습니다. 등록한 SSH 계정으로 접속해 정해진 명령으로 자료를 읽고, 실행 버전을 확인하려고 서버와 컨테이너에 이미 있는 실행 파일의 버전 명령을 실행합니다. 기본 Linux 명령과 읽기 권한이 필요하고, 컨테이너를 점검하려면 Docker 조회 권한이 필요합니다. 명령이나 권한이 없는 범위는 미수집으로 남습니다. 프로필에서 허용하면 이미 부여된 비대화형 sudo 권한을 쓰며, sudo 설정은 바꾸지 않습니다.
어떤 서버와 소프트웨어를 점검할 수 있나요?+
SSH로 접속할 수 있는 Linux 서버와 실행 중인 Docker 컨테이너가 대상입니다. npm·pip·Composer·RubyGems·Cargo·Go·NuGet·Maven 등 앱 의존성은 GitHub 보안 공지와, OS 패키지는 관리 서버에 준비한 취약점 스캐너 DB와 대조합니다. PHP·Node·Python·Java 등 런타임과 OpenSSL·nginx·Apache는 실행 버전을 수집하지만, 버전 수집과 취약점 판정은 별개이며 런타임의 별도 보안 릴리스 기준은 현재 PHP·Node.js에 적용합니다. Windows 서버와 Kubernetes는 현재 점검 범위에 포함되지 않으며, 정지된 컨테이너는 미수집으로 표시합니다.
서버가 안전하다고 판정해 주나요?+
아닙니다. 확인한 범위에서 찾은 위험과 확인하지 못한 범위를 함께 보고합니다. 취약한 버전이나 공격 시도가 발견되었다는 것만으로 침해를 확정하지 않습니다. 공개되지 않은 제로데이 취약점까지 찾아낸다고 보장하지 않습니다.
우선순위는 어떻게 정하나요?+
공지와 규칙의 심각도에 따라 P1(Critical)부터 P4(Low·Info)까지 나누고, 같은 등급 안에서는 실제 설치·실행 버전, 설정, 로그 근거를 잠금 파일 같은 선언보다 앞에 둡니다. 실제 노출이나 악용 가능성을 계산한 점수는 아니므로 항목마다 순위 근거를 함께 표시합니다.
인터넷이 없는 폐쇄망에서도 쓸 수 있나요?+
보안 공지, 스캐너 DB, 내부 모델을 준비하면 폐쇄망에서 운영할 수 있습니다. 인터넷 PC에서 만든 보안 공지 파일 묶음을 반입하면 관리자가 구성과 건수·체크섬을 검증한 뒤 적용합니다. 체크섬은 전달 중 손상을 확인하는 용도이며 파일을 만든 사람을 보증하지는 않습니다. OS 패키지용 스캐너 DB는 따로 반입하고, AI 검토는 사내 LLM을 연결하거나 생략합니다. 외부 통신이 없는지는 도입 환경에서 함께 검증합니다.
AI가 서버에서 명령을 실행하나요?+
아닙니다. AI는 임의 명령을 실행할 수 없습니다. 추가 수집이 필요하면 미리 등록된 점검 도구로만 요청할 수 있고, 관리자가 승인한 뒤 MiWork Guard가 권한과 한도를 다시 확인해 실행합니다. 비밀번호·키 같은 비밀값은 가린 뒤 AI에 전달하지만 모든 민감정보가 제거된다고 보장하지는 않으므로, 외부 모델 사용 여부는 관리자가 정책으로 정합니다.
문제를 찾으면 자동으로 고쳐 주나요?+
자동으로 고치지 않습니다. 조치 계획에 목표 버전과 명령 예시를 안내하고, 실제 조치는 담당자가 판단해 수행한 뒤 다시 점검해 확인합니다.
점검이 서버 운영에 부담을 주지 않나요?+
점검 프로필에서 실행 시간, 읽을 파일 수, 출력 크기의 한도를 정하고 같은 서버에 점검이 겹치지 않게 합니다. 대상에서 파일 읽기와 버전 명령이 실행되므로 부하가 전혀 없지는 않으며, 업무가 적은 시간대로 예약해 운영할 수 있습니다.
확인한 근거로, 먼저 고칠 것부터.
점검할 서버 환경과 컨테이너 사용 여부, 폐쇄망 여부, 사용할 수 있는 LLM에 맞는 MiWork Guard 구성을 함께 확인해 보세요.