접근 통제 정책 기반 방화벽 (DB 방화벽)

핵심 인사이트 (3줄 요약)

본질: DB 방화벽 (Database Firewall)은 네트워크 L7 계층에서 데이터베이스 프로토콜과 SQL (Structured Query Language) 구문을 심층 분석하여, 비정상적인 쿼 실행과 비인가 접근을 실시간으로 차단하는 데이터 보호의 최종 방어선이다.

가치: 기존 네트워크 방화벽이 차단하지 못하는 SQL 인젝션 (SQL Injection) 공격과 내부자의 악의적 데이터 유출(대량 조회, 스키마 삭제 등)을 방지함으로써, 컴플라이언스 준수와 무결성 (Integrity)을 보장한다.

융합: 최신 DB 방화벽은 머신러닝 기반의 쿼리 행위 분석 (UBA, User Behavior Analytics)과 연동되어 제로 데이 (Zero-day) 데이터 탈취 시도를 탐지하며, DAM (Database Activity Monitoring) 아키텍처와 결합해 보안 가시성을 극대화한다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: 접근 통제 정책 기반 DB 방화벽은 데이터베이스로 유입되는 모든 트래픽을 프록시 (Proxy) 또는 스니핑 (Sniffing) 방식으로 가로채어, 사전에 정의된 IP (Internet Protocol), 포트, 접근 시간, 계정, 그리고 실행하려는 SQL 구문의 패턴까지 종합적으로 평가한 뒤 통과(Allow) 또는 차단(Deny)을 결정하는 지능형 보안 솔루션이다.
필요성: 전통적인 네트워크 방화벽이나 IPS (Intrusion Prevention System)는 L3/L4 계층의 IP와 포트 번호만을 검사한다. 따라서 정상적인 서비스 포트 (예: Oracle 1521, MySQL 3306)를 통해 들어오는 트래픽이 합법적인 비즈니스 쿼리인지, 아니면 관리자 권한을 탈취하려는 악성 UNION SELECT 공격인지 구분하지 못한다. 또한, 내부망에 이미 접속 권한을 가진 개발자나 외주 인력이 새벽 시간에 대량의 고객 정보를 SELECT 하거나 실수로 DROP TABLE을 실행하는 내부 위협 (Insider Threat)을 막을 물리적 통제 수단이 데이터베이스 자체 권한 관리만으로는 턱없이 부족하다. DB 방화벽은 이러한 페이로드 (Payload) 내부의 SQL 구문적 맥락을 이해하고 통제할 수 있는 유일한 수단이다.
등장 배경 및 발전 과정:
1. 경계 보안의 한계: 초기에는 방화벽과 VPN (Virtual Private Network)만으로 내부망을 보호할 수 있다고 믿었으나, 웹 애플리케이션의 취약점을 통한 SQL 인젝션이 급증하면서 DB 자체를 방어할 전용 계층이 필요해졌다.
2. 컴플라이언스 강화: 개인정보보호법, ISMS (Information Security Management System) 등에서 데이터베이스 접근에 대한 최소 권한 원칙과 엄격한 감사 로그 (Audit Log)를 요구하면서, 단순히 막는 것을 넘어 모든 SQL 실행 이력을 기록하는 DAM (Database Activity Monitoring) 기능이 필수화되었다.
3. 문맥 기반(Context-aware) 통제: 최근에는 정적 룰 (Static Rule) 기반 차단을 넘어, 특정 사용자의 평소 접속 시간과 쿼리 패턴을 기계학습으로 프로파일링하여 평소와 다른 이상 행위 (Anomaly)를 동적으로 차단하는 지능형 방화벽으로 진화하고 있다.

이 다이어그램은 왜 일반 방화벽만으로는 데이터베이스를 보호할 수 없는지, DB 방화벽이 어떻게 페이로드 내부를 검사하여 공격을 차단하는지를 직관적으로 보여준다.

  ┌─────────────────────────────────────────────────────────────┐
  │         일반 방화벽 vs DB 방화벽의 검사 계층 비교               │
  ├─────────────────────────────────────────────────────────────┤
  │                                                             │
  │  [공격자] "SELECT * FROM Users WHERE 1=1--"                 │
  │     │                                                       │
  │     ▼ 패킷 발생 (Source IP: 1.2.3.4, Dest Port: 3306)       │
  │                                                             │
  │  ┌───────────────── 일반 네트워크 방화벽 (L4) ────────────────┐ │
  │  │ 검사 항목: 출발지 IP (1.2.3.4) → 허용 목록에 있음 (Pass)     │ │
  │  │            도착지 포트 (3306)  → 열려 있음 (Pass)           │ │
  │  │ 결과: 패킷 내부의 SQL은 보지 않고 통과시킴 🟢                │ │
  │  └──────────────────────────────────────────────────────────┘ │
  │     │                                                       │
  │     ▼ (위험한 SQL 구문 통과)                                   │
  │                                                             │
  │  ┌────────────────── DB 방화벽 (L7 Proxy) ──────────────────┐ │
  │  │ 검사 항목: 접속 시간 (새벽 3시) → (시간 통제 정책 위반 ❌)  │ │
  │  │            명령어 (SELECT *)  → (대량 조회 제한 ❌)       │ │
  │  │            SQL 패턴 ("1=1")   → (인젝션 시그니처 일치 ❌)   │ │
  │  │ 결과: SQL 파싱 트리를 분석하여 악성 행위로 판별, 즉시 세션 차단 🔴 │
  │  └──────────────────────────────────────────────────────────┘ │
  │     │                                                       │
  │     ▼ (접근 차단됨)                                            │
  │  [데이터베이스 서버] (안전하게 보호됨)                           │
  └─────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이 도식의 핵심은 방화벽의 인지 계층 차이다. 네트워크 방화벽은 봉투의 겉면(주소와 우표)만 보고 통과시키기 때문에, 봉투 안에 폭탄(악성 SQL)이 들어있는지 알 수 없다. 반면 DB 방화벽은 TCP/IP 페이로드를 조립한 뒤 데이터베이스 프로토콜 (예: TNS, TDS)을 디코딩하고, SQL 파서 (Parser)를 통해 구문 트리 (Syntax Tree)를 생성한다. 이를 통해 쿼리의 구조적 변형(1=1과 같은 참인 명제 주입)을 탐지하여, DB 서버에 명령이 도달하기 전에 선제적으로 TCP 세션을 끊어버리거나 에러 메시지를 반환한다. 따라서 DB 방화벽은 네트워크 보안 장비라기보다, SQL 언어를 이해하는 애플리케이션 보안 장비로 분류된다.

📢 섹션 요약 비유: 건물 1층 경비원(네트워크 방화벽)이 출입증만 보고 들여보낸 사람을, 금고문 앞의 전문 감정사(DB 방화벽)가 가방 속 내용물과 반출 사유서까지 꼼꼼히 확인한 뒤에야 금고를 열어주는 이치와 같습니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

구성 요소 및 동작 메커니즘

DB 방화벽은 단순한 패킷 필터가 아니라, 실시간 SQL 파싱 엔진을 탑재한 복잡한 미들웨어다.

요소명	역할	내부 동작	프로토콜 연동	비유
프로토콜 디코더 (Protocol Decoder)	DB 벤더별 고유 통신 규격 해독	TCP 스트림 재조립 후 Oracle TNS, MS-TDS 등 해석	DB 전용 프로토콜	각국 언어 통역기
SQL 파서 (SQL Parser)	수신된 텍스트 쿼리를 구문 트리로 변환	예약어, 식별자, 연산자 토큰화 (Tokenization)	ANSI SQL 규격	문장 문법 분석가
정책 엔진 (Policy Engine)	5튜플 + SQL 메타데이터 룰 매칭	사용자, IP, 시간, 사용된 테이블/명령어 비교	접근 통제 리스트 (ACL)	세관 심사관
마스킹 모듈 (Masking Module)	응답 데이터 내 민감 정보 동적 난독화	정규식 기반 주민번호/카드번호 탐지 및 `***` 치환	데이터 전송 계층	문서 검열 매직펜
감사 로거 (Audit Logger)	모든 요청과 응답, 정책 매칭 결과를 저장	WORM (Write Once Read Many) 스토리지에 위변조 방지 기록	Syslog, SIEM 연동	비행기 블랙박스

DB 방화벽의 가장 중요한 아키텍처적 결정은 네트워크상에 장비를 **어떻게 배치할 것인가(Deployment Mode)**이다. 이는 성능, 가용성, 그리고 보안 통제 수준(적극적 차단 vs 소극적 차단)을 결정짓는 핵심 트레이드오프다.

  ┌──────────────────────────────────────────────────────────────────┐
  │              DB 방화벽 구축 아키텍처 (Proxy vs Sniffing)         │
  ├──────────────────────────────────────────────────────────────────┤
  │                                                                  │
  │  [A. 인라인 프록시 (In-line Proxy) 방식]                         │
  │                                                                  │
  │     [Client] ──────▶ [ DB 방화벽 ] ──────▶ [Database]           │
  │                  차단! ── 🛑                                     │
  │                                                                  │
  │     - 특징: 모든 패킷이 방화벽을 통과. 악성 쿼리 100% 사전 차단. │
  │     - 단점: 방화벽 장애 시 DB 접속 불가 (SPOF 발생 가능성).      │
  │             세션 프록싱에 의한 네트워크 레이턴시 (Latency) 증가. │
  │                                                                  │
  │  [B. 스니핑 (Sniffing / Out-of-Path) 방식]                       │
  │                                                                  │
  │                     L4/L2 Switch (Port Mirroring)                │
  │     [Client] ─────────────┬──────────────▶ [Database]            │
  │                           │                                      │
  │                      복사본 전달                                  │
  │                           ▼                                      │
  │                      [ DB 방화벽 ] ── TCP RST(Reset) 주입 ─┐     │
  │                                                            │     │
  │     - 특징: 원본 트래픽에 영향 없음. 무중단 보장, 성능 저하 없음.│     │
  │     - 단점: 악성 쿼리가 DB에 도착한 후 방화벽이 인지할 수 있음.  │     │
  │             뒤늦게 세션을 끊더라도 첫 쿼리는 이미 실행될 위험(Race).│
  └──────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이 아키텍처 비교는 DB 보안 설계 시 가장 빈번하게 논의되는 트레이드오프를 보여준다. 인라인 프록시(In-line Proxy) 방식은 애플리케이션의 DB 연결 문자열(Connection String)을 방화벽의 IP로 변경하여, 방화벽이 클라이언트와 DB 사이의 대리인 역할을 하도록 강제한다. 이는 악성 쿼리를 논리적으로 파싱하고 DB에 도달하기 전에 패킷을 드롭(Drop)할 수 있는 완벽한 차단 능력을 제공한다. 하지만 방화벽 자체가 병목 지점(Bottleneck)이 되며, 장비 장애 시 전체 서비스가 중단되는 단일 장애점(SPOF, Single Point of Failure)이 될 수 있어 고가용성(HA) 구성이 필수적이다. 반면 스니핑(Sniffing) 방식은 스위치의 포트 미러링 (Port Mirroring) 기능을 이용해 패킷 복사본만 방화벽으로 던진다. 원본 트래픽 흐름을 방해하지 않으므로 서비스 가용성과 속도 측면에서 완벽하지만, 방화벽이 악성 쿼리를 발견하고 TCP RST(Reset) 패킷을 보내 세션을 끊기 전에, DB가 이미 첫 번째 공격 쿼리를 수신하고 처리해버릴 수 있는 근본적인 레이스 컨디션 (Race Condition) 약점을 지닌다. 따라서 스니핑은 차단보다는 감사(Auditing)에 초점을 맞출 때 주로 사용된다.

세밀한 접근 통제(Fine-Grained Access Control) 매커니즘

DB 방화벽의 정책 엔진은 다차원적인 조건을 AND 조건으로 결합하여 평가한다.

IP / MAC 통제: 인가된 터미널이나 서버 대역인지 확인.
시간 (Time) 통제: 야간 배치가 아닌 주간 근무 시간에만 DDL 허용.
애플리케이션 통제: 접속 툴이 sqlplus, Toad, DBeaver인지 패킷의 클라이언트 식별자를 통해 구분. (업무망에서 개발 툴 직접 접속 차단)
객체 (Object) 통제: 특정 테이블(예: TB_PAYROLL)에 대한 접근 자체를 금지.
쿼리 유형 (Command) 통제: SELECT는 허용하되 UPDATE, DELETE, DROP, TRUNCATE는 차단.
결과 행 수 (Row-count) 제한: 반환되는 레코드 수가 설정치(예: 10,000건)를 초과하면 세션을 강제 종료하여 대량 데이터 덤프 탈취 방지.

📢 섹션 요약 비유: 공항 검색대에서 엑스레이(X-Ray)로 수화물 안의 폭발물 형태를 분석하듯, DB 방화벽은 데이터 패킷의 압축을 풀고 그 안의 SQL 문법이라는 뼈대를 분석하여 위험한 의도를 찾아냅니다.

Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)

네트워크 보안 장비 간 심층 비교

DB 방화벽은 WAF, 일반 방화벽과 방어하는 계층과 초점이 완전히 다르다. 이를 혼동하면 보안 사각지대가 발생한다.

비교 항목	일반 방화벽 (FW)	웹 방화벽 (WAF)	DB 방화벽 (DB FW)
동작 계층	L3 / L4 (네트워크/전송 계층)	L7 (HTTP / HTTPS 프로토콜)	L7 (DB 전용 프로토콜 / SQL)
방어 대상	포트 스캐닝, 비인가 IP 접근	크로스 사이트 스크립팅(XSS), 웹 기반 SQLi	SQL 구문 변조, 내부자 데이터 대량 유출
분석 페이로드	패킷 헤더 (IP, Port)	HTTP Request/Response Body	SQL 텍스트, DB 반환 결과 셋
내부자 위협 대응	불가능 (내부망 접속 허용 시 무방비)	불가능 (DB 직접 접속 툴은 웹을 안 거침)	강력함 (DB 직접 접속 시에도 쿼리 통제)
동적 마스킹	미지원	HTML 내 패턴 마스킹 제한적 가능	DB 반환 값(주민번호 등) 원천 난독화

이 표에서 가장 주목해야 할 트레이드오프는 보안 범위와 성능의 반비례 관계다. WAF는 클라이언트가 웹 서버로 보내는 HTTP 요청을 검사하여 1차적으로 SQL 인젝션을 막지만, 만약 내부 직원이 Toad 같은 DB 클라이언트 툴을 사용해 내부망에서 DB 서버로 직접 접속한다면 WAF는 이 트래픽을 아예 볼 수 없다. DB 방화벽은 DB 서버 바로 앞단에 위치하므로, 웹을 거쳐 오든 내부망에서 직접 붙든 모든 데이터베이스 I/O를 통제할 수 있는 유일한 관문이다.

아키텍처 융합 관점

운영체제 (OS) 및 인프라: 프록시 모드 DB 방화벽은 네트워크 병목을 유발할 수 있으므로, 고성능 패킷 처리를 위해 DPDK (Data Plane Development Kit) 기술이나 커널 바이패스 (Kernel Bypass) 기법을 OS 단에서 융합하여 네트워크 레이턴시를 1ms 이하로 억제해야 한다.
클라우드 아키텍처 (Cloud): AWS RDS나 Aurora 같은 관리형 DB 환경에서는 물리적인 스니핑 구성이 불가능하다. 따라서 클라우드 네이티브 환경에서는 DB 인스턴스에 에이전트(Agent)를 설치하거나, AWS Network Firewall 등과 연동하는 SECaaS (Security as a Service) 형태의 클라우드형 DB 방화벽 아키텍처가 부상하고 있다.
📢 섹션 요약 비유: WAF가 성벽 외곽에서 적군의 투석기를 막는 방패라면, DB 방화벽은 왕의 침소 바로 앞에서 독살과 배신자를 걸러내는 왕실 근위대와 같습니다.

Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)

실무 시나리오 및 의사결정

시나리오 — 내부자 대량 데이터 유출 방어: 콜센터 외주 직원이 고객 정보 조회 화면을 이용해 하루에 수만 건의 데이터를 조금씩 긁어모아 USB로 유출하려는 정황이 의심된다. 애플리케이션 로그만으로는 이를 식별하기 어렵다.
- 의사결정: DB 방화벽의 정책 엔진에 임계치 기반 통제 룰을 추가한다. "특정 IP 대역에서 하루 누적 SELECT 반환 건수가 5,000건을 초과할 경우 해당 IP의 DB 접근을 즉시 차단하고 보안팀에 SIEM (Security Information and Event Management) 알람을 발송하라"는 룰을 적용하여 물리적 복제를 차단한다.
시나리오 — 레거시 시스템의 암호화 의무 대응: 10년 된 노후화된 사내 ERP 시스템에 주민등록번호가 평문으로 저장되어 있으나, 애플리케이션 코드를 수정하여 암호화 모듈을 태우기에는 리스크와 비용이 너무 크다. (개인정보보호법 위반 위기)
- 의사결정: DB 방화벽을 프록시 모드로 앞단에 구성하고, 동적 데이터 마스킹 (Dynamic Data Masking) 기능을 활성화한다. 쿼리 결과로 주민번호 패턴이 반환될 때 방화벽이 이를 가로채어 800101-1****** 형태로 변환해 애플리케이션에 넘긴다. 소스 코드 수정 없이 컴플라이언스 요건을 단기간에 충족시키는 전략적 우회로다.

방화벽 아키텍처 선택을 위한 의사결정 플로우

운영 환경에 맞는 DB 방화벽 구축 방식을 선택하는 것은 시스템 안정성과 직결된다.

  ┌───────────────────────────────────────────────────────────────────┐
  │           DB 방화벽 구성 방식 결정을 위한 의사결정 트리            │
  ├───────────────────────────────────────────────────────────────────┤
  │                                                                   │
  │   [DB 방화벽 도입 목적 명확화]                                    │
  │                │                                                  │
  │                ▼                                                  │
  │      사전 차단(Prevention)이 필수적인가?                          │
  │          ├─ 예 ─────▶ [네트워크 아키텍처 검토]                       │
  │          │                     │                                  │
  │          │                     ▼                                  │
  │          │             지연(Latency)에 매우 민감한가?             │
  │          │                ├─ 예 ──▶ 고성능 프록시 장비 이중화 적용 │
  │          │                └─ 아니오 ─▶ 일반 프록시 (In-line) 구성 │
  │          │                                                        │
  │          └─ 아니오 (감사 및 모니터링 중심)                        │
  │                │                                                  │
  │                ▼                                                  │
  │      클라우드 관리형 DB(RDS 등) 인가?                             │
  │          ├─ 예 ─────▶ [Agent 방식 또는 클라우드 전용 프록시]       │
  │          └─ 아니오 ──▶ [스니핑 (Port Mirroring) 방식 적용]          │
  │                                                                   │
  │   판단 포인트: "성능 저하의 감수" vs "보안 사고의 감수"           │
  └───────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 실무에서 가장 실패하기 쉬운 지점은 성능 테스트 없이 무작정 인라인 프록시 모드를 도입하는 것이다. 초당 수만 건의 트랜잭션(TPS)을 처리하는 증권사나 게임사 DB 앞에 프록시를 두면, 파싱 오버헤드로 인해 서비스 전체가 마비될 수 있다. 따라서 지연에 매우 민감하거나 사전 차단보다 사고 후 책임 추적(감사)이 주 목적이라면 스위치 미러링을 통한 스니핑 방식을 채택하는 것이 기술사적 관점에서 합리적이다. 반대로, 데이터 유출 시 기업의 존립이 흔들리는 민감 데이터 구역이라면, 성능을 일부 희생하더라도 인라인 구성을 하고 장비 이중화(Active-Active)를 통해 SPOF를 제거하는 아키텍처 설계가 필수적이다.

도입 체크리스트 및 안티패턴

체크리스트: 트래픽 폭증 시 방화벽이 어떻게 동작할 것인지 (Fail-Open vs Fail-Close 정책) 정의되어 있는가? (일반적으로 DB 접속을 무조건 보장하려면 Fail-Open, 보안이 최우선이면 Fail-Close 선택)
안티패턴: 바인드 변수 (Bind Variable) 파싱 누락. 애플리케이션이 Prepared Statement를 사용하여 바인드 변수를 넘길 때, DB 방화벽이 변수 값 내부의 악성 페이로드를 매칭하지 못하고 껍데기 쿼리 구조만 보고 안전하다고 판단해 통과시키는 설정 오류는 최악의 보안 홀 (Security Hole)을 만든다.
📢 섹션 요약 비유: 어떤 집에 보안 문(프록시)을 달지, 아니면 CCTV(스니핑)만 달지 결정할 때는 집 주인이 "문을 열 때 조금 느려지는 불편함"과 "도둑이 1초라도 집에 들어올 수 있는 위험" 중 무엇을 더 싫어하는지 따져봐야 하는 것과 같습니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	미적용 환경	DB 방화벽 적용 환경	개선 효과
정량	개인정보 평문 노출 위험	동적 마스킹 (Dynamic Masking)	애플리케이션 수정 비용 제로화, 규제 완벽 대응
정량	사고 후 원인 추적 시일	감사 로그 (Audit Log) 100% 기록	포렌식 타임 수일 → 수 분으로 단축
정성	내부 직원의 무분별한 DB 툴 접속	클라이언트 툴 통제 및 시간 제어	개발/운영 직무 분리(SoD) 원칙 기술적 강제

미래 전망

AI 기반 UEBA 연동: 기존의 정적 시그니처 매칭을 넘어, 사용자 엔티티 행동 분석 (UEBA, User and Entity Behavior Analytics)과 결합하여 "A 부서 직원이 평소에는 보지 않던 B 부서의 통계 테이블을 조회하는 행위" 자체를 이상 탐지 (Anomaly Detection) 스코어로 환산하여 차단하는 지능형 모니터링 체계로 발전하고 있다.
제로 트러스트 (Zero Trust) 데이터 아키텍처: 클라우드 네이티브 환경에서 고정된 IP 기반 통제가 무의미해짐에 따라, 마이크로서비스 간의 데이터 접근 권한을 지속적으로 검증하고 쿼리 단위로 토큰을 인가하는 방식으로 아키텍처 패러다임이 이동 중이다.

참고 표준

개인정보의 안전성 확보조치 기준 (제6조): 접근 통제 시스템 설치 및 운영 의무화
PCI-DSS (Payment Card Industry Data Security Standard) v4.0: 카드 데이터 환경(CDE) 내 데이터베이스 모니터링 및 암호화/마스킹 요구사항

DB 방화벽은 단순한 보안 솔루션을 넘어, 데이터 중심의 기업에서 "누가 내 데이터에 무슨 짓을 했는지"를 증명할 수 있는 유일한 시스템 기록자다. 클라우드 도입으로 인프라 경계가 모호해질수록, 최종 저장소인 데이터베이스 바로 앞단을 지키는 이 기술의 중요성은 시스템 아키텍처 설계에서 결코 배제될 수 없는 최우선 고려 사항이 될 것이다.

📢 섹션 요약 비유: 기술이 아무리 발전해도 가장 중요한 보물을 지키는 마지막 자물쇠는 항상 보물 상자 바로 문턱에 달려 있어야 하며, 그것이 날이 갈수록 똑똑해지고 있는 이유입니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
SQL 인젝션 (SQL Injection)	DB 방화벽이 차단해야 하는 가장 대표적이고 치명적인 외부 웹 취약점 공격 기법이다.
WAF (웹 방화벽)	외부 HTTP 트래픽을 일차 방어하며, DB 방화벽과 결합해 심층 방어 (Defense in Depth) 아키텍처를 완성한다.
DAM (Database Activity Monitoring)	방화벽의 차단 기능을 넘어, 모든 쿼리 라이프사이클을 추적하고 감사하는 컴플라이언스 핵심 프레임워크다.
스니핑 (Sniffing)	포트 미러링을 통해 성능 저하 없이 네트워크 패킷을 복제하여 방화벽에 분석 데이터를 제공하는 비침해적 통신 기법이다.
데이터 마스킹 (Data Masking)	쿼리 결과를 사용자에게 반환하기 전 실시간으로 민감 데이터를 별표(*) 처리하여 정보 유출 면적을 최소화한다.

👶 어린이를 위한 3줄 비유 설명

데이터베이스는 우리 반 친구들의 비밀 일기장이 모여 있는 금고예요. 일반 경비 아저씨는 "우리 학교 학생" 표찰만 있으면 그냥 통과시켜 줘요.
하지만 DB 방화벽 선생님은 금고문 바로 앞에 서서, 친구들이 가방 속에 몰래 일기장을 훔쳐갈 큰 자루를 숨겨오지 않았는지, 그리고 남의 일기장을 열어보려고 하는 건 아닌지 꼼꼼하게 검사해요.
만약 나쁜 마음을 먹은 쿼리(명령어)가 발견되면 즉시 쫓아내고, 비밀번호 같은 중요한 내용은 아예 먹물로 까맣게 칠해서 보여주는 똑똑한 보디가드랍니다!