녹스블리 기술 블로그

안전한 AI 창작을 위한 기술과 경험을 공유합니다.

AI 창작부터 보안, 아키텍처, 배포까지 녹스블리의 기술을 소개합니다.

[Open-Source] ARTEX: AI 기반 자율형 침투 테스트 프레임워크 소개 및 사용법

보안 점검 방식이 점차 자동화되고 AI와 결합하는 흐름 속에서, 오픈소스 자율형 침투 테스트 도구인 ARTEX 가 많은 관심을 받고 있습니다. 이번 글에서는 ARTEX의 주요 특징부터 Docker를 활용한 구축, Target IP 설정 및 실행 방법까지 한눈에 보기 쉽게 정리해 드립니다. 1. ARTEX란? ARTEX 는 LLM(대형 언어 모델) 기반의 AI 에이전트를 활용하여 취약점 탐지, 공격 시나리오 수행, 타겟 시스템 분석을 자율적으로 수행하는 오픈소스 자율형 침투 테스트(Automated Penetration Testing) 프레임워크 입니다. ARTEX 대시보드 주요 특징 AI Agent 기반 자율 점검: 단순 스크립트 기반 스캔을 넘어, LLM 에이전트가 상황 판단 및 공격 흐름(Exploit)을 유도합니다. 직관적인 Web UI 관리: 작업(Task), 자산(Asset), 차단 규칙(Interception Rules) 등을 웹 인터페이스에서 한눈에 관리할 수 있습니다. 쉬운 컨테이너 배포: Docker 및 Docker Compose 환경을 기본 지원하여 빠른 환경 구축이 가능합니다. 2. ARTEX 설치 및 실행 (Docker Compose) ARTEX는 PostgreSQL 데이터베이스와 통합되어 동작하며, Docker Compose를 이용하면 복잡한 빌드 과정 없이 한 번에 실행할 수 있습니다. # 1. 저장소 클론 및 이동 git clone https://github.com/Hinln/ARTEX.git cd ARTEX # 2. 환경설정 파일 복사 (POSTGRES_USER, POSTGRES_PASSWORD, POSTGRES_DB 설정) cp .env.example .env # 3. Docker Compose로 컨테이너 백그라운드 실행 docker compose up -d Tip: 로컬에서 소스 코드를 직접 컴파일해야 하는 경우 go 개발 환경 설치 후 CGO_ENABLED=0 go build -tags embedui -o artex ./cmd/artex 명령어로 바이너리를 빌드할 수 있습니다. 3. 웹 관리자 화면에서 Target IP 설정하기 ARTEX 웹 대시보드( http://localhost:8787 ) 접속 후 점검 대상(Target IP)을 설정하는 과정입니다. 새 작업 생성: 좌측 [작업] 탭에서 우측 상단의 + 새 작업 버튼을 클릭합니다. Target IP 및 범위 지정: 자산 추가: 도메인과 대상 단일 IP( 192.168.1.100 ) 또는 대역( 192.168.1.0/24 )을 입력합니다. 작업 이름 및 설명: 해당 점검 작업의 목적과 배경을 작성합니다. 점검 실행: 생성 버튼을 누르면 작업(Task)이 즉시 대기 상태로 등록되고, 메인 에이전트가 탐색 프로세스를 시작합니다. 웹사이트 침투를 위한 탐색 4. 트러블슈팅 & FAQ Port 8787 Conflict 오류 발생 시: macOS나 Linux에서 8787 포트가 이미 점유 중인 경우 sudo lsof -i :8787 로 프로세스를 확인 후 종료하거나, docker-compose.yml 의 외부 포트를 8788:8787 등으로 변경합니다. model_error 또는 LLM 호출 실패 시: LLM API 키 설정 문제이거나 대체 모델(Fallback Provider) 설정이 누락된 경우가 많으므로 웹 화면의 System > LLM 메뉴에서 API 설정 및 네트워크 통신 상태를 점검해야 합니다. ( LLM API 키 필수 ) 마치며 ARTEX는 AI 에이전트를 보안 점검 프로세스에 이식하여 침투 테스트의 공수(工數)를 크게 줄여주는 유용한 도구입니다. 내부 자산 보안 점검 시 유용하게 활용해 보시기 바랍니다. • • • 참고사이트 https://github.com/Hinln/ARTEX https://github.com/jiwoochris/artex-ko GitHub - Hinln/ARTEX: ARTEX 源码备份：基于 Autumn-27/ARTEX v0.3.15，保留原始提交历史与 AGPL-3.0 许可证。 ARTEX 源码备份：基于 Autumn-27/ARTEX v0.3.15，保留原始提交历史与 AGPL-3.0 许可证。 - Hinln/ARTEX github.com GitHub - jiwoochris/artex-ko: ARTEX 한국어판 · AI 자율 침투 테스트 프레임워크(upstream: Autumn-27/ARTEX, AGPL-3.0) ARTEX 한국어판 · AI 자율 침투 테스트 프레임워크(upstream: Autumn-27/ARTEX, AGPL-3.0) - jiwoochris/artex-ko github.com

IT 인사이트

量子力學·Oct 10, 2026

#artex#ai#자율 침투#모의 침투#보안도구

📌 Featured

업로드된 HTML이 보안검사를 거쳐 안전한 미니 앱으로 배포되는 과정

안전한 미니 앱을 위한 보안 검사와 정제 웹페이지를 만드는 일이 예전보다 훨씬 쉬워졌습니다. 이제는 개발자가 아니더라도 생성형 AI에 원하는 기능을 설명하면 계산기, 학습 도구, 시뮬레이터, 게임과 같은 HTML 콘텐츠를 만들 수 있습니다. 하지만 만들어진 HTML을 인터넷에 올려 누구나 실행할 수 있게 만드는 일은 파일을 저장하는 것과 조금 다릅니다. HTML은 단순한 문서가 아니라 버튼을 누르고, 데이터를 입력받고, 외부 사이트와 연결하고, 프로그램 코드를 실행할 수 있는 작은 애플리케이션이기 때문입니다. 녹스블리 서비스에서 사용자가 등록한 HTML을 바로 공개하지 않고 보안 검사와 정제 과정을 거치는 이유도 여기에 있습니다. HTML 컨텐츠의 순화·검증 (Sanitization) HTML은 문서이면서 프로그램입니다 사진이나 PDF 파일은 일반적으로 화면에 내용을 보여주는 역할을 합니다. 반면 HTML은 브라우저 안에서 여러 동작을 수행할 수 있습니다. 예를 들어 HTML에는 다음과 같은 기능이 포함될 수 있습니다. 버튼을 클릭하면 프로그램 코드를 실행합니다. 사용자가 입력한 정보를 처리합니다. 외부 서버나 웹사이트에 연결합니다. 다른 웹페이지를 화면 안에 불러옵니다. 새로운 창을 열거나 다른 주소로 이동시킵니다. 브라우저에 정보를 저장하거나 읽어 옵니다. 이러한 기능은 정상적인 웹서비스를 만드는 데 꼭 필요합니다. 그러나 사용자의 의도와 다르게 작동하거나, 검증되지 않은 외부 코드가 포함되면 보안상 문제가 될 수도 있습니다. 따라서 “HTML 파일이 정상적으로 열리는가”와 “여러 사용자에게 안전하게 공개할 수 있는가”는 서로 다른 문제입니다. 악의가 없어도 위험 요소는 포함될 수 있습니다 보안 검사는 악의적인 사용자만을 막기 위한 절차가 아닙니다. 생성형 AI가 만든 HTML이나 인터넷의 예제를 참고한 코드에는 제작자가 인식하지 못한 외부 스크립트, 오래된 라이브러리 또는 불필요한 접근 기능이 포함될 수 있습니다. 코드를 직접 작성한 사용자도 복사한 코드가 정확히 어떤 동작을 하는지 모두 알기 어려울 수 있습니다. 예를 들어 다음과 같은 상황이 발생할 수 있습니다. 출처를 확인하기 어려운 외부 스크립트를 불러오는 경우 클릭과 동시에 원하지 않는 사이트로 이동하는 경우 입력한 정보를 외부 서버로 전송하는 경우 화면을 가리는 팝업이나 반복 동작이 실행되는 경우 다른 사용자의 브라우저 환경에 영향을 줄 수 있는 코드가 포함된 경우 보안 지원이 종료된 외부 라이브러리를 사용하는 경우 코드를 등록한 사람이 위험한 행동을 의도하지 않았더라도 결과적으로 다른 사용자에게 불편이나 위험을 줄 수 있습니다. Sanitization은 무엇인가요? Sanitization은 업로드된 HTML의 구조와 속성을 검사하고, 서비스 정책에 맞지 않거나 위험할 가능성이 있는 요소를 제거하거나 제한하는 과정입니다. 쉽게 비유하면 건물에 들어가기 전 보안 검색대를 통과하는 것과 비슷합니다. 모든 방문자를 위험한 사람으로 판단하는 것이 아니라, 여러 사람이 함께 사용하는 공간에 반입하기 어려운 물건이 있는지 확인하는 절차입니다. HTML 보안 검사에서는 일반적으로 다음과 같은 항목을 확인합니다. 1. 실행 코드 검사 브라우저에서 자동으로 실행되는 스크립트와 이벤트 속성을 확인합니다. 서비스 환경에서 허용하기 어려운 코드는 제거하거나 실행을 제한할 수 있습니다. 2. 외부 연결 검사 HTML이 어떤 외부 서버, 이미지, 라이브러리 또는 프레임을 불러오는지 확인합니다. 신뢰할 수 있는 출처인지 검토하고 정책에 따라 연결을 허용하거나 제한합니다. 3. 위험한 주소 형식 검사 링크처럼 보이지만 클릭했을 때 프로그램 코드를 실행하거나 예상하지 못한 위치로 이동시키는 주소가 포함되어 있는지 확인합니다. 4. 입력 및 전송 기능 검사 사용자가 입력한 정보가 어디로 전달되는지 확인합니다. 개인정보나 계정 정보가 의도하지 않은 외부 서버로 전송될 가능성을 줄이기 위한 과정입니다. 5. 실행 환경 분리 검사를 통과한 콘텐츠도 녹스블리의 주요 서비스 화면과 분리된 환경에서 실행합니다. 하나의 콘텐츠에서 문제가 발생하더라도 다른 사용자나 서비스 전체에 미치는 영향을 줄이기 위한 방어 장치입니다. 모든 코드를 삭제하는 과정은 아닙니다 보안 검사의 목적은 HTML의 기능을 없애는 것이 아닙니다. 창작물의 핵심 기능은 최대한 유지하면서, 여러 사용자가 함께 이용하는 환경에서 허용하기 어려운 동작을 찾아 제한하는 것이 목적입니다. 그러나 일부 기능은 보안 정책에 따라 정상적으로 동작하지 않을 수 있습니다. 예를 들어 허용되지 않은 외부 스크립트, 자동 이동, 과도한 팝업, 검증되지 않은 데이터 전송 기능 등 은 수정이나 제거가 필요할 수 있습니다. 녹스블리는 다음 두 가지 가치 사이에서 균형을 유지하려고 합니다. 창작자가 의도한 기능을 가능한 한 유지하는 것 콘텐츠를 실행하는 사용자를 안전하게 보호하는 것 보안이 지나치게 느슨하면 사용자가 위험해지고, 반대로 모든 기능을 막으면 창작물을 실행할 수 없습니다. 따라서 콘텐츠의 목적과 위험 수준에 따라 적절한 기준을 적용하는 것이 중요합니다. 한 번의 검사로 모든 위험을 막을 수는 없습니다 Sanitization은 중요한 보안 단계이지만 이것만으로 모든 위험을 완전히 방지할 수 있는 것은 아닙니다. 새로운 공격 방식이 계속 등장하고 외부 라이브러리의 상태도 바뀔 수 있기 때문입니다. 안전한 서비스 운영을 위해서는 여러 방어 수단이 함께 적용되어야 합니다. 녹스블리는 업로드 단계의 보안 검사뿐 아니라 다음과 같은 다층적인 보호 구조를 지향합니다. 업로드 콘텐츠의 위험 요소 검사 허용된 외부 리소스와 도메인 관리 실행 영역과 서비스 영역의 분리 콘텐츠 보안 정책 적용 접근 권한과 공개 범위 관리 배포 이후의 모니터링과 정책 개선 보안 검사는 창작을 제한하기 위한 장벽이 아니라, 더 많은 사용자가 창작물을 안심하고 실행할 수 있게 만드는 기반입니다. • • • 안전해야 창작물이 서비스가 됩니다 AI와 웹 기술의 발전으로 누구나 아이디어를 빠르게 HTML로 만들 수 있게 되었습니다. 그러나 파일을 만드는 것과 여러 사람이 사용할 수 있는 서비스로 운영하는 것 사이에는 안전성이라는 중요한 단계가 있습니다. 녹스블리는 AI 또는 사용자가 만든 웹 창작물이 단순한 파일에 머무르지 않고, 안전하게 실행하고 공유할 수 있는 미니 앱으로 성장하도록 돕고자 합니다. 그 시작이 바로 업로드된 HTML에 대한 보안 검사와 정제입니다.

보안

量子力學·Sep 26, 2026

#웹보안#미니앱#ai창작#sanitization#mini app

📌 Featured

React·Vue·Next.js의 빌드 과정을 하나로 묶을 수 있을까?

프레임워크는 서로 다르지만, 빌드 과정에는 공통된 흐름이 있습니다. 이 공통점을 기준으로 여러 프로젝트를 하나의 파이프라인에서 처리할 수 있는지 살펴봅니다. 다른 프레임워크, 비슷한 빌드 흐름 React, Vue, Next.js는 프로젝트 구조와 결과물에 차이가 있습니다. React와 Vue는 주로 브라우저에서 실행할 정적 파일을 만들고, Next.js는 설정에 따라 정적 사이트 또는 서버가 필요한 애플리케이션을 만들 수 있습니다. 그럼에도 일반적인 빌드 과정은 비슷합니다. 프로젝트 정보를 분석하고, 적절한 Node.js 환경을 준비한 뒤, 의존성을 설치하고 빌드 명령을 실행합니다. 마지막으로 생성된 결과물이 실제로 배포 가능한 형태인지 확인합니다. 프로젝트 분석 실행 환경 준비 의존성 설치 빌드 실행 결과물 수집 공통 빌드 과정에서 사용하는 대표적인 명령 프로젝트의 의존성 구조에 따라 설치 방식은 달라질 수 있습니다. 다음은 의존성 충돌이 있는 프로젝트에서도 사용할 수 있는 대표적인 빌드 명령 예시입니다. $ npm install --legacy-peer-deps $ npm run build 의존성 충돌이 있을 때 npm install --legacy-peer-deps 를 사용하는 이유 npm install 은 package.json 을 기준으로 프로젝트에 필요한 라이브러리를 설치합니다. 이때 오래된 프로젝트나 여러 UI 라이브러리를 함께 사용하는 프로젝트에서는 패키지가 요구하는 peer dependency 버전이 서로 맞지 않아 설치가 중단될 수 있습니다. --legacy-peer-deps 옵션은 이러한 충돌을 npm의 과거 방식처럼 비교적 유연하게 처리합니다. 다양한 시기에 작성된 프로젝트를 동일한 환경에서 빌드해야 할 때, 엄격한 peer dependency 검사로 설치가 즉시 실패하는 상황을 줄이는 데 도움이 됩니다. 다만 이 옵션이 실제 호환성을 보장하는 것은 아닙니다. 설치 단계는 통과하더라도 빌드 또는 실행 과정에서 문제가 나타날 수 있으므로, 이후 빌드 결과와 오류 로그를 반드시 확인해야 합니다. npm run build 를 사용하는 이유 npm run build 는 package.json 의 scripts.build 에 정의된 명령을 실행합니다. 같은 명령을 입력해도 React 프로젝트는 Vite나 Create React App을, Vue 프로젝트는 Vue CLI나 Vite를, Next.js 프로젝트는 Next.js 빌더를 실행할 수 있습니다. 즉, 파이프라인은 프레임워크별 세부 명령을 직접 알 필요 없이 프로젝트 작성자가 정의한 표준 진입점을 호출할 수 있습니다. 이것이 서로 다른 프레임워크를 하나의 빌드 흐름으로 묶을 수 있는 핵심 근거입니다. 차이는 설정과 결과 판별로 분리한다 package.json 의 dependencies와 scripts를 확인하면 사용 중인 프레임워크, 필요한 실행 환경, 빌드 가능 여부를 어느 정도 판단할 수 있습니다. 의존성 설치와 빌드 실행은 공통 단계로 유지하고, 프레임워크별 차이는 환경 설정과 결과물 판별 단계에서 처리할 수 있습니다. 빌드가 성공했다는 사실만으로 배포 준비가 끝난 것은 아닙니다. 출력 폴더가 생성됐는지, 시작 문서와 정적 자원이 존재하는지, 서버 런타임이 필요한 결과물인지 등을 추가로 확인해야 합니다. Next.js는 실행 방식까지 확인해야 한다 React와 Vue는 대체로 정적 파일을 생성하지만, Next.js는 정적 내보내기뿐 아니라 서버 렌더링, API Route 등 서버 실행이 필요한 기능도 지원합니다. 따라서 Next.js 프로젝트는 빌드 성공 여부와 함께 결과물이 정적 배포 대상인지, 별도의 서버 런타임이 필요한지도 구분해야 합니다. 이 차이는 통합 파이프라인이 불가능하다는 뜻이 아닙니다. 앞부분의 분석·설치·빌드는 공유하고, 결과물의 유형에 따라 마지막 실행 방식만 분기하면 됩니다. NOXBLY 자동 파이프라인 녹스블리는 업로드된 SPA 프로젝트의 프레임워크를 자동으로 감지하고, React·Vue·Next.js 등 각 개발 환경에 맞는 빌드 과정을 거쳐 배포 가능한 결과물로 변환합니다. 녹스블리 SPA (Vue/React/Next.js) 업로드 화면 핵심은 프레임워크가 아니라 표준화다 통합 빌드의 목적은 모든 프레임워크를 완전히 동일하게 취급하는 것이 아닙니다. 반복되는 과정은 표준화하고, 꼭 필요한 차이만 분기하는 것입니다. 이렇게 구성하면 새로운 프레임워크나 빌드 도구가 추가되더라도 전체 흐름을 다시 만들지 않고 분석 규칙과 결과물 처리 방식만 확장할 수 있습니다. 정리 npm install --legacy-peer-deps 로 다양한 프로젝트의 의존성을 설치하고, npm run build 로 프로젝트가 정의한 빌드 절차를 실행하면 React·Vue·Next.js를 공통 파이프라인에서 처리할 수 있습니다. 다만 의존성 호환성, 출력 형식, 정적 배포 가능 여부와 서버 실행 방식은 별도의 검증 단계로 남겨야 합니다.

개발

22.5c·Sep 7, 2026

#react#vue#next.js#build#pipeline

📌 Featured

HTML 배포를 위한 2단계 보안·품질 검증 체계

위험한 코드는 저장 전에 차단하고, 공개 콘텐츠는 저장 후에 다시 검수합니다. 녹스블리 는 AI가 생성한 HTML과 사용자가 직접 작성한 HTML을 웹사이트에 실시간으로 배포하는 기능을 제공합니다. 브라우저에서 실행되는 코드인 만큼, 사용자가 업로드하는 HTML을 단순히 저장하는 것만으로는 안전과 품질을 함께 보장하기 어렵습니다. 이번 글에서는 안전한 HTML 배포를 위한 2단계 보안·품질 검증 체계에 대해서 소개하고자 합니다. 2단계 보안 검사·품질 검사 가 필요한 이유 보안 검사와 품질 검사는 서로 다른 영역에 해당합니다. 첫 번째는 “이 코드를 실행해도 안전한가?” 를 확인하고, 두 번째는 “이 결과물을 다른 사용자에게 공개해도 되는가?” 를 판단합니다. FIRST LINE - 저장 전 보안 검사 악성 스크립트, 위험 코드, 유해 콘텐츠를 업로드 단계에서 검사하고 차단합니다. SECOND LINE - 저장 후 품질 · 정책 검수 저장된 결과물의 완성도와 공개 정책 준수 여부를 승인 전에 다시 확인합니다. 첫 번째 방어선: 저장 전 보안 검사 업로드되는 HTML은 저장 전에 다단계 보안 검사를 거칩니다. 단일 파일, ZIP, 다중 파일, 리믹스 등 업로드 방식과 관계없이 같은 원칙을 적용합니다. HTML Sanitize → Content Filter → Security Audit HTML Sanitize — 허용된 태그와 속성만 통과시키고 실행 가능 요소를 별도로 검증합니다. Content Filter — DB 규칙과 AI 판정을 결합해 욕설·혐오·불법 콘텐츠를 확인합니다. Security Audit — 의심스러운 코드 패턴과 보안 위험 요소를 추가로 확인하고 후속 검토를 지원합니다. Standard Web Security Assessment 두 번째 방어선: 저장 후 품질·정책 검수 보안 검사를 통과했더라도 바로 공개되지는 않습니다. 쇼케이스와 리믹스에 등록되는 콘텐츠는 구조, 반응형, 접근성, 기능, 콘텐츠, 코드 품질을 기준으로 다시 평가합니다. 정적 분석과 실제 브라우저 렌더링을 함께 사용해 모바일 화면 깨짐, 접근성 누락, 동작하지 않는 링크와 리소스, 플레이스홀더 문구 등을 확인합니다. 검사 결과에 따라 자동 반려하거나 관리자 검토 대상으로 분류합니다. 완전한 면제보다 단계적인 신뢰 회원 등급이 높아지면 일부 제작 제한을 완화할 수 있지만, 핵심 필터와 공개 후 방어는 계속 적용됩니다. 신뢰 등급은 보안을 제거하는 권한이 아니라 검증된 사용자에게 제한적으로 더 넓은 제작 자유도를 제공하는 기준입니다. 하나의 일관된 원칙 두 방어선은 차단 기준과 검사 방식이 다르지만 목표는 같습니다. AI가 만들었든 사용자가 직접 만들었든, 실제 서비스로 공개되는 HTML에 보안·품질·신뢰 라는 동일한 원칙을 적용하는 것입니다. • • • 안전한 공개는 한 번의 검사가 아니라 과정입니다 저장 전에는 실행 위험을 줄이고, 저장 후에는 공개 품질을 확인합니다. 이 책임 분리가 녹스블리의 안전한 HTML 배포 구조를 만듭니다.

보안

量子力學·Sep 6, 2026

#security#audit#sanitize#filtering

📌 Featured

글로벌 웹 서비스를 위한 계층형 보안 아키텍처

웹서비스를 글로벌하게 운영하면 다양한 지역의 사용자뿐 아니라 자동화된 스캔과 비정상적인 접근도 함께 증가합니다. 따라서 글로벌 서비스에서는 애플리케이션 개발뿐 아니라 네트워크, 웹 서버, 보안 계층을 함께 고려한 구조가 필요합니다. 대다수 중대형 웹서비스의 경우 백엔드는 스프링부트(SpringBoot) 기반의 JAVA 언어를 주로 사용하며, 프론트엔드는 과거 php/jsp에서 2022년 이후로는 React나 Vue.js등 SPA가 대세를 이루고 있습니다. 스프링부트(SpringBoot)로 백엔드를 웹서비스를 개발했다고 가정했을경우 결과물(jar, war등)은 WAS(Web Applcation Server)에 탑재해서 실행 되겠지만, 안정적인 서비스를 위하여 ModSecurity(웹방화벽), Fail2Ban(침입 방지)등 다양한 보안 소프트웨어도 필연적으로 연동하여야 합니다. 위 그림은 오픈소스 보안 기술을 활용한 일반적인 웹 서비스 보안 구성 예시입니다. 그림에서와 같이 소프트웨어 개발과는 별개로 인프라, 네트워크, 서버(Linux), 정보보안(Information Security)도 서비스 구성을 위한 핵심 요소이므로 글로벌 서비스 출시를 위해서는 반드시 관심을 가져야 할 것 입니다. 위에서 언급한 보안 소프트웨어들과 OpenStreetMap을 연동하여 침입을 시도하는 IP 주소에 대해서 그려 본 세계지도입니다. 보안 소프트웨어를 연동한 지 며칠 지나지 않았음에도 여러 국가에서 비정상적인 접근과 공격 시도가 발생하고 있음을 확인할 수 있습니다. ModSecurity와 Fail2Ban을 연동하여 공격성 IP 주소에 대해 글로벌 서비스 차단 위의 세계지도는 Fail2Ban 와 ModSecurity에서 생성한 로그정보를 기반으로 구성한 것입니다. 아래 사이트에서 정보를 참고해주세요 - OWASP ModSecrurity - https://modsecurity.org/ - Fail2Ban - https://github.com/fail2ban - OpenStreetMap - https://www.openstreetmap.org/ 보안은 하나의 제품이 아니라 계층입니다 글로벌 서비스의 보안은 특정 솔루션 하나로 완성되지 않습니다. 네트워크, Reverse Proxy, WAF, 접근 제어, 애플리케이션, 모니터링 등 여러 계층이 서로 보완할 때 공격에 대한 대응력을 높일 수 있습니다. 중요한 것은 모든 공격을 완벽하게 막는다고 가정하는 것이 아니라, 각 계층에서 위험을 줄이고 이상 징후를 지속적으로 관찰할 수 있는 구조를 만드는 것입니다.

아키텍처

바람의 언덕·Aug 27, 2026

#security#architecture#fail2ban#modsecurity