SQL 인젝션 탐지에서 오탐이 다수 발생한 적이 있습니다. 저는 경고 알림만으로 판단하지 않고 탐지된 쿼리를 확인했습니다. 정상 쿼리로 확인한 뒤 오탐으로 판단했고, 탐지 패턴을 정교화했습니다.이 경험에서 제가 강조하고 싶은 것은 정상처럼 보이는 내용 안에도 공격 요소가 숨어 있을 수 있다는 점입니다. 오탐을 줄이는 과정에서도 실제 공격을 탐지하는 기준을 함께 살펴야 합니다. 이 글에서는 오탐과 미탐의 발생 원인, SQL 인젝션 경고의 확인 항목, 패턴 조정 시 판단 기준을 정리합니다.오탐과 미탐은 경고의 유무만으로 판단하지 않습니다False Positive는 정상 행위를 위협으로 잘못 탐지한 ‘오탐’이며, False Negative는 실제 위협을 탐지하지 못한 ‘미탐’입니다. 반대로 위협을 올바르게 탐..

임직원의 업무용 PC와 서버의 IP 대역을 vlan이든 방화벽이든 물리적이나 논리적으로 나눴는데도, PC에서 데이터베이스와 서버 관리 포트까지 접속할 수 있다면 보안 경계는 충분히 작동하지 않는 상태다. 네트워크 세분화의 효과는 나눈 망의 개수보다 ‘업무에 필요 없는 연결이 실제로 거부되는가’를 확인할 필요가 있다.이 글에서는 영역 단위의 네트워크 세분화와 워크로드 단위의 마이크로세그멘테이션을 구분하고, 기업이 어떤 통신부터 확인해서 통제할지 판단하는 기준을 살펴본다. 정책표와 적용 순서는 설계를 돕기 위한 가상 예시와 실무 제안이다.망을 분리하는 것과 통신을 통제하는 것네트워크 세분화는 하나의 네트워크를 업무·보안 요구에 따라 여러 영역으로 나누는 방식이다. 사용자망, 운영 서버망, 개발망, 관리망처럼..

VPN에 로그인한 직원이 업무와 무관한 시스템에도 접속할 수 있다면, 회사 네트워크 안으로 들어오는 절차와 개별 자원에 접근하는 권한이 충분히 구분되지 않은 상태일 수 있습니다. 계정이 탈취되거나 단말이 감염되면 넓게 열린 접근 범위가 피해를 키울 수 있습니다. Zero Trust는 이때 ‘어디에서 접속했는가’만으로 신뢰를 부여하지 않고, 어떤 주체가 어떤 자원을 어떤 조건에서 사용할 수 있는지 판단하는 보안 모델입니다. Zero Trust는 내부망이라는 이유만으로 신뢰하지 않는 모델NIST SP 800-207은 네트워크 위치나 자산 소유권만으로 사용자와 자산에 암묵적 신뢰를 부여하지 않는다고 설명합니다. 회사 사무실에서 회사 노트북을 사용하더라도 그것만으로 모든 업무시스템에 접근할 근거가 되지는 않습..

웹서버를 두 대로 늘렸는데도 특정 서버만 바쁘거나, 새로고침할 때마다 로그인이 풀리는 일이 생길 수 있다. 서버를 추가하는 것과 여러 서버가 하나의 서비스처럼 동작하게 만드는 것은 서로 다른 작업이기 때문이다. 로드밸런서는 들어오는 트래픽을 여러 서버에 나누어 전달한다. 하지만 분산 기준, 서버 상태 확인, 세션과 파일 저장 방식이 맞지 않으면 기대한 효과를 얻기 어렵다. 부하 분산 구조를 이해할 때는 요청이 어느 서버로 전달되는지와 함께, 서버가 바뀌어도 같은 서비스를 제공할 수 있는지를 살펴봐야 한다. 로드밸런서는 요청을 처리할 서버를 선택 로드밸런서는 클라이언트가 접속하는 서비스의 진입점에서 요청이나 연결을 받을 서버를 선택한다. 하나의 요청을 모든 서버에 복제하는 장치가 아니라, 정해진 기준..

업무용 NAS에서 삭제한 파일을 스냅샷으로 되살렸다면, 장비가 고장 나도 같은 방법으로 복구할 수 있을 것처럼 느껴질 수 있다. 그러나 같은 저장 공간에 남겨 둔 복구 시점은 그 저장 공간을 잃는 사고까지 해결해 주지 않는다. 데이터 보호를 설계할 때는 복구 메뉴의 유무보다 원본이 사라져도 복구에 필요한 데이터와 권한이 남는지부터 확인해야 한다. 스냅샷은 시점 보존 기술, 백업은 복구를 위한 체계스냅샷은 특정 시점의 데이터 상태를 보존하는 기술이다. 파일시스템이나 스토리지의 로컬 스냅샷은 원본과 데이터 블록을 공유하고, 변경 전 블록이나 참조 정보를 유지하는 방식으로 구현되는 경우가 많다. 생성할 때마다 전체 데이터를 다른 장치에 복사하는 방식과는 다르며, 구현에 따라 저장 위치와 복구 조건도 달라진다..

주문 등록 화면에서 저장 버튼을 눌렀는데 응답이 끊겼다. 다시 누르면 주문이 두 번 들어가는지, 잠시 기다리면 되는지 판단하기 어렵다. 이 상황을 이해하려면 화면의 응답, 서버의 업무 처리, 데이터베이스의 저장 완료를 구분해야 한다.기업 IT 시스템의 데이터는 대체로 입력, 검증, 업무 처리, 저장, 조회, 후속 처리의 흐름을 거친다. 이 글은 주문 등록을 가상 예시로 사용한다. 특정 회사의 실제 구성이나 수행 경험을 설명하는 사례는 아니며, 파일 저장과 DB 저장의 역할부터 장애 확인 기준까지 살펴본다.같은 데이터라도 트랜잭션 위치에 따라 용도가 다름사용자가 입력한 주문 수량은 처음에는 브라우저나 앱의 메모리에 있다. 서버로 전송되면 애플리케이션이 해석하고 계산할 수 있는 값이 된다. 이후 데이터베이스..

직원이 외부 제안서를 AI에 올리고 비교 요약을 요청했다. 그런데 AI가 제안서 속 문장을 지시로 받아들여 특정 업체를 우선 추천하거나 요청하지 않은 작업을 시도한다면 문제의 성격이 달라진다. 프롬프트 인젝션은 AI가 읽어야 할 자료와 따라야 할 지시 사이의 경계를 흔드는 공격이다.자료의 내용이 업무 지시로 바뀌는 지점생성형 AI 서비스는 사용자 요청, 서비스 운영 규칙, 검색 결과, 첨부파일 등을 모델에 전달한다. 이때 신뢰할 수 없는 입력이 모델의 응답이나 행동을 의도하지 않은 방향으로 바꾸면 프롬프트 인젝션 문제가 발생한다. OWASP의 LLM01 설명은 직접·간접 입력을 통한 행동 변경과 그 영향을 다룬다.자료 안에 명령문이 있다는 사실만으로 공격이라고 판단해서는 안 된다. 매뉴얼의 작업 지침을 ..

직원이 생성형 AI에 사내 출장비 규정을 물었는데, 회사 기준과 다른 답변이 돌아왔다고 가정해 보자. 모델이 일반적인 출장 제도를 알고 있어도 우리 회사의 개정 규정까지 아는 것은 아니다. 이때 관련 내부 문서를 찾아 질문과 함께 모델에 전달하는 방식이 RAG다.RAG는 답변 전에 근거를 찾아 제공하는 방식RAG는 Retrieval-Augmented Generation의 약자로, 검색 증강 생성이라고 부른다. 질문에 맞는 자료를 검색하고, 검색 결과를 참고 문맥으로 제공해 언어모델이 답변하도록 구성한다. AWS의 설명처럼 내부 지식을 활용하기 위해 매번 모델을 재학습하는 과정이 필수인 것은 아니다.예를 들어 출장비 규정의 관련 조항을 찾아 모델에 전달하면, 모델은 그 내용을 바탕으로 지급 기준을 설명할 ..

2026년 10월 21일 PHP 개발팀이 인증 없이 원격 코드 실행으로 이어질 수 있는 취약점 두 건과 수정 버전을 공개했다. 22일 국내에서도 긴급 대응 소식이 이어졌다. 홈페이지 담당자에게 필요한 것은 불안한 제목보다 우리 서비스의 PHP 사용 여부, 수정본 적용 여부, 실제 운영 프로세스의 교체 여부를 확인하는 일이다.PHP는 홈페이지 뒤에서 실행되는 프로그램이다PHP는 웹서버에서 동작하는 프로그래밍 언어다. 방문자가 페이지를 요청하면 서버가 PHP 코드를 실행해 게시물과 데이터베이스 정보를 처리하고, 결과를 HTML 등으로 브라우저에 전달한다. 방문자 PC에 PHP를 설치하는 구조가 아니므로, 이번 대응의 중심도 이용자의 브라우저 업데이트가 아니라 서버 운영 환경이다. 영국 NCSC — PHP 긴..

클라우드 두 곳에 시스템을 나누어 올렸다고 장애 대응 능력이 두 배가 되는 것은 아니다. 한쪽의 애플리케이션이 다른 쪽의 데이터베이스를 계속 호출한다면, 두 환경 중 하나만 멈춰도 같은 업무가 중단될 수 있다. 멀티클라우드의 효과는 사업자 수보다 업무를 나누는 방식과 환경 사이의 의존성에 달려 있다.이 글에서는 멀티클라우드의 장점을 얻을 수 있는 조건, 운영이 복잡해지는 지점, 도입 전에 확인할 판단 기준을 살펴본다. 클라우드별 기능을 모두 비교하기보다 기업이 추가로 책임져야 할 연결과 운영에 초점을 맞춘다.1. 멀티클라우드는 배치 전략이고, 무중단은 별도 설계다멀티클라우드는 둘 이상의 클라우드 사업자 서비스를 함께 사용하는 방식이다. 여기서는 AWS와 Google Cloud처럼 서로 다른 퍼블릭 클라우..